XML-RPC, SOAP, and data persistence

Discussion in 'Python' started by Mark Carter, Oct 13, 2003.

  1. Mark Carter

    Mark Carter Guest

    I had a play with XML-RPC the other day, and it seemed really simple
    to use; which really made an impression on me. But you can't make data
    persist on the server (not without rolling your own mechanism, at any
    rate). I'm thinking here about thin clients, where the main process
    runs on a server.

    Is there any free solution to this problem? Is SOAP the answer?
     
    Mark Carter, Oct 13, 2003
    #1
    1. Advertising

  2. On 13 Oct 2003 03:34:47 -0700,
    Mark Carter <> wrote:
    > to use; which really made an impression on me. But you can't make data
    > persist on the server (not without rolling your own mechanism, at any
    > rate). I'm thinking here about thin clients, where the main process
    > runs on a server.


    I don't follow the connection you're trying to make here. XML-RPC and SOAP
    are network protocols used for communication between a client and a server;
    what the server or client *do* with the data they receive is up to them and
    not part of the protocol definition. You simply have to roll your own
    mechanism, or use an existing module such as pickle, ZODB, or an RDBMS.

    --amk
     
    A.M. Kuchling, Oct 13, 2003
    #2
    1. Advertising

  3. (Mark Carter) wrote in message news:<>...
    > I had a play with XML-RPC the other day, and it seemed really simple
    > to use; which really made an impression on me. But you can't make data
    > persist on the server (not without rolling your own mechanism, at any
    > rate). I'm thinking here about thin clients, where the main process
    > runs on a server.
    >
    > Is there any free solution to this problem? Is SOAP the answer?


    You can use Pickle or look at Twistedmatrix.com for a full featured solution.

    RodrigoB.
     
    Rodrigo Benenson, Oct 13, 2003
    #3
  4. Mark Carter

    Mark Carter Guest

    "A.M. Kuchling" <> wrote in message news:<>...
    > On 13 Oct 2003 03:34:47 -0700,
    > Mark Carter <> wrote:
    > > to use; which really made an impression on me. But you can't make data
    > > persist on the server (not without rolling your own mechanism, at any
    > > rate). I'm thinking here about thin clients, where the main process
    > > runs on a server.

    >
    > I don't follow the connection you're trying to make here. XML-RPC and SOAP
    > are network protocols used for communication between a client and a server;
    > what the server or client *do* with the data they receive is up to them and
    > not part of the protocol definition. You simply have to roll your own
    > mechanism, or use an existing module such as pickle, ZODB, or an RDBMS.
    >
    > --amk


    I was thinking in terms of thin clients, where you have to deal with
    processes which persist after the call. Maybe you have computationally
    intensive simulation software which runs on the server. The client is
    a simple GUI that sends events to a process that runs on the server.
    Pickling and databases don't really help here - although I suppose
    that the server process could periodically dump some useful results
    for the client to pick up.

    XML-RPC appears to deal with remote procedure calls, but doesn't
    address process persistence issues. It has a missing piece in the
    "distributed computing" puzzle. Maybe SOAP can do better, because it
    has objects. That's mu question.
     
    Mark Carter, Oct 14, 2003
    #4
  5. Mark Carter wrote:
    > XML-RPC appears to deal with remote procedure calls, but doesn't
    > address process persistence issues. It has a missing piece in the
    > "distributed computing" puzzle. Maybe SOAP can do better, because it
    > has objects. That's mu question.


    I strongly recommend you to takea look at Pyro,
    http://pyro.sourceforge.net

    With a few extra lines of code you can make Python
    objects in your application remotely accessible as
    if they were just regular local objects.

    Pyro server objects are long running processes that
    sit there and wait till someone invokes methods on
    them. You can create per-user objects instances too.

    Have a look!

    --Irmen de Jong

    PS Pyro is only suitable for a 100% python environment.
    (both client and server are written in Python).
     
    Irmen de Jong, Oct 14, 2003
    #5
  6. On 14 Oct 2003 03:20:29 -0700,
    Mark Carter <> wrote:
    > XML-RPC appears to deal with remote procedure calls, but doesn't
    > address process persistence issues. It has a missing piece in the
    > "distributed computing" puzzle. Maybe SOAP can do better, because it
    > has objects. That's mu question.


    No, SOAP doesn't address persistence any more than XML-RPC does; both
    implement remote procedure calls with more or fewer bells and whistles. SOAP
    has the additional disadvantage that the spec is very complicated, making it
    hard for Python implementations to be up-to-date.

    --amk
     
    A.M. Kuchling, Oct 14, 2003
    #6
  7. Mark Carter

    Mark Carter Guest

    "A.M. Kuchling" <> wrote in message
    > No, SOAP doesn't address persistence any more than XML-RPC does; both
    > implement remote procedure calls with more or fewer bells and whistles. SOAP
    > has the additional disadvantage that the spec is very complicated, making it
    > hard for Python implementations to be up-to-date.


    Thanks. I once saw a thick book on XML at the office, but soon put it
    back as there was an aweful lot to it. But looking at XML-RPC, I saw
    how easy it was to implement RPCs. It's so fuss-free and generic that
    its difficult to imagine wanting to use any other mechanism.

    Kinda makes you wonder what the whole point of .Net is.

    The above comments are, of course, off-the-cuff remarks.
     
    Mark Carter, Oct 15, 2003
    #7
  8. In article <>,
    Mark Carter <> wrote:

    >XML-RPC appears to deal with remote procedure calls, but doesn't
    >address process persistence issues. It has a missing piece in the
    >"distributed computing" puzzle. Maybe SOAP can do better, because it
    >has objects. That's mu question.


    SOAP doesn't specifically have persistence, but you could use either
    SOAP or XML-RPC's data representation for persistence.

    It is not true that there are objects in SOAP.

    Cheers,

    Duncan.

    --
    -- Duncan Grisby --
    -- --
    -- http://www.grisby.org --
     
    Duncan Grisby, Oct 15, 2003
    #8
  9. Mark Carter wrote:

    > "A.M. Kuchling" <> wrote in message
    >> No, SOAP doesn't address persistence any more than XML-RPC does; both
    >> implement remote procedure calls with more or fewer bells and whistles.
    >> SOAP has the additional disadvantage that the spec is very complicated,
    >> making it hard for Python implementations to be up-to-date.

    >
    > Thanks. I once saw a thick book on XML at the office, but soon put it
    > back as there was an aweful lot to it. But looking at XML-RPC, I saw
    > how easy it was to implement RPCs. It's so fuss-free and generic that
    > its difficult to imagine wanting to use any other mechanism.
    >
    > Kinda makes you wonder what the whole point of .Net is.


    It hinges first around MSIL, a bytecode similar to the Java's VM but
    with some enhancements to make it more suitable for "ahead-of-time"
    (installation time) compilation to machine code, as well as for some
    slightly less-traditional languages (e.g., tail-recursion optimization
    for Scheme and many other such languages); secondly around the CRL,
    Common Runtime Library, and many other libraries (for windowing, both
    local and on-net; database access; etc, etc) extending it; thirdly
    around web services (centered on the more ambitious SOAP protocol as
    "designed-by-committee" richer successor of XML-RPC); and keeps layering
    on top of this. FWIW, I do agree that SOAP is much more complicated
    than XML-RPC, and that this is an important disadvantage, but no doubt
    the vast committee (of which MS was but a part) could not reach any
    agreement for simpler things -- it IS harder to make something "so
    simple it obviously has no deficiencies", so it ends up instead being "so
    complicated it has no obvious deficiencies", as Hoare put it -- and this
    goes double with design-by-committee.

    ".NET" is a huge, vastly layered (and sometimes not WELL layered) blob
    of things kept together first and foremost by marketing needs (but is
    J2EE really ALL that different in this respect...?-). Using SOAP
    instead of XML-RPC is a drop in the .NET ocean, IMHO.


    Alex
     
    Alex Martelli, Oct 15, 2003
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. javaguy44
    Replies:
    10
    Views:
    985
    Michael Berg
    May 18, 2004
  2. Pere Montolio

    XML RPC to ONC XDR RPC

    Pere Montolio, Aug 11, 2004, in forum: XML
    Replies:
    0
    Views:
    731
    Pere Montolio
    Aug 11, 2004
  3. Kenneth P. Turvey

    Java Persistence API and persistence.xml

    Kenneth P. Turvey, Mar 15, 2008, in forum: Java
    Replies:
    2
    Views:
    17,338
    Kenneth P. Turvey
    Mar 16, 2008
  4. Ymtrader
    Replies:
    1
    Views:
    584
    Adam Tauno Williams
    Mar 15, 2011
  5. Vladimir Konrad

    rpc (not xml-rpc)

    Vladimir Konrad, Sep 2, 2005, in forum: Ruby
    Replies:
    5
    Views:
    138
    Austin Ziegler
    Sep 3, 2005
Loading...

Share This Page