XML-RPC, SOAP, and data persistence

M

Mark Carter

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?
 
A

A.M. Kuchling

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
 
R

Rodrigo Benenson

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.
 
M

Mark Carter

A.M. Kuchling said:
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.
 
I

Irmen de Jong

Mark said:
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).
 
A

A.M. Kuchling

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
 
M

Mark Carter

A.M. Kuchling said:
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.
 
D

Duncan Grisby

Mark Carter said:
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.
 
A

Alex Martelli

Mark said:
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
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top