Distributed computing using SOAP. What about speed ?

[Graham Dumpleton]

Tim Daneliuk <tundra at tundraware.com> wrote in message news:<3B60EEA0.70BC492A at tundraware.com>...
> A gracious Graham Dumpleton wrote:
> <SNIP>
>  
> > 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.
> 
> I guess I should clarify something.  In order to have "transactional
> correctness" you have to have a reliable transport somewhere in the
> stack below the transactional elements (or transport reliability has
> to be synthesized at the transactional layer - a really bad idea).

In the end, I think we are perhaps talking from the perspective of
trying to address different problem domains. Ie., apples vs oranges.
So I am not sure how much consensus we will get. Anyway, you have given
me some more stuff to read and ponder.

Now to clarify a bit about OSE and what I originally mean't when I said
"connected". Firstly, the distributed ability of OSE isn't in any
way dependent on SOAP, XML-RPC or any other RPC over HTTP protocol. Thus,
it isn't relying on having to create connections for every message being
sent around.

In the simplest model for using OSE, and probably most easily understood, you
have a central message exchange process. Each client creates a connection
to that server process and keeps it connected. This server process acts
as the means of message passing between processes. This is just like a
lot of MOM software such as stuff from Tibco and BEA, and stuff like JMS.
Thus what I mean't by "connected" was that processes maintain a socket
connection at all times giving them the ability to route messages to other
processes without the cost of creating a connection each time.

As with the normal model for using many MOM type packages, so long as
processes are up and running, you are ensured that the message will get
through to its target. This is done without needing an explicit concept
of message queues as active entities are modelled as service objects.
Thus, you send a message direct to the service you are interested in and
don't need this separate concept of message queues as a proxy.

Because message queues aren't used, there isn't any concept of persistance.
Ie., that a service can receive messages that were sent when it wasn't
running isn't possible with OSE. There isn't actually any reason however that
persistent message queues can be added on top of what is there and at some
point that may well be done. Having such a feature at the lowest levels
just makes implementation complicated.

Where as you are coming from an area where every single message may have to be
accounted for, even when failures occur, I have come from an area more in
the real time data monitoring area. Ie., monitoring telco equipment for the
purpose of raising alarms when problems occur. Thus, you tend to be monitoring
the current state of things. In such a system, if you had persistent message
queues it could actually be quite bad. If a large failure occurred and your
monitoring systems went down as well, when it comes back up, you don't
necessarily want to then have to process all the historical data before you
can get to see where things are right then. Different requirements, different
approaches to the problem. In this area, the publish/subscribe features are
actually more important than that of request/reply.

Personally, I think this idea of using XML-RPC or SOAP over the Internet if
you want reliablity isn't a good idea. I believe these protocols can be useful
in the setting of a corporate network but within quite constrained ways.
If someone tells me they want something which provides gauranteed reliability
etc, then I will be the first to tell them to go use software from the likes
of Tibco, BEA or IBM.