Home Original page

Distributed computing using SOAP. What about speed ?

Graham Dumpleton grahamd at dscpl.com.au
Thu Jul 26 22:25:57 EDT 2001 
Tim Daneliuk <tundra at tundraware.com> wrote in message news:<3B5FC733.5186D588 at tundraware.com>...
> > OSE is implemented using an event driven system model. This includes the HTTP
> > servlet framework, such that multiple requests can be handled at a time etc.
> > It includes mechanisms for knowing when connections block due to slow HTTP
> > clients so you can stop sending data back etc.
> > 
> > OSE at its core is actually C++, with Python wrappers. Thus, you are getting
> > the efficiency of C++ but the simpler interfaces possible with Python.
> 
> I have a related question.  I come from a very high-scale, high-arrival
> rate transactional computing background.  In this world, connection-oriented
> solutions like RPCs across wide-area networks are a big "no no" for 
> a variety of reasons.  (If you care more about why, I wrote a paper, years
> ago, in grad school on this topic.  The specifics of the paper are quite
> out of date, but the general critique' of RPCs is still very much relevant,
> perhaps even moreso today with the proliferation of the internet.  You can
> find it at: http://www.tundraware.com/RPCpaper/rpcpaper.pdf)  The short
> reason for this is that connection-oriented solutions like RPCs create
> very "brittle" applications in highly distributed, high-performance
> environments.  I am thus less than enthusiastic about SOAP as a solution.
> 
> One really good alternative is transactional queuing with asynchronous
> read/write interfaces to the queues.  I'm wondering if anyone is doing 
> anything in this area with Python.

I have saved your document and will look at it, but be aware that OSE
actually supports publish/subscribe and request/reply modules of
communication using an asynchronous model. OSE uses messaging concepts
in its implementation as opposed to connection oriented RPCs. It does
however take a simple approach to this in that it isn't underlayed by
persistent message queues. This is still useful for many applications
and certainly makes the implementation easier. It hasn't been the
intention with OSE to target transactional environments so it would
more than likely not be useful for that sort of application, but there
are lots of other things it would be quite adequate for.

I will look at your paper. You may want to look further at the Python
manual for OSE and you might see it ain't quite what you first had in
mind.
More information about the Python-list mailing list