Distributed computing using SOAP. What about speed ?

[Graham Dumpleton]

Tim Daneliuk <tundra at tundraware.com> wrote in message news:<3B61A061.2634D595 at tundraware.com>...
> Thomas Weholt wrote:
> >
> > What do you mean by "reliability"? I think we're talking about different
> > worlds here; I'm developing a system for normal users, who can accept
> > infrequent failures and some downtime without ending in financial ruin.
> 
> For end-user computing, you may be right.  For back-office computing
> I think the risk is way too high.

And I would agree. There is a big difference between having someone
sitting at a browser and after a while making their own decision that
their request has failed in some way because no response has come
back,
and some application trying to make the same decision. If an
application is relying on a single RPC communication to do something
and it dies
after they have sent the request but before they get a response, is it
mean't to assume it worked or that it indeed may have got through. If
it did get through and it has changed something on the server side,
what
about the results which may have been returned, how is it going to get
that back. Yes, a human would have similar problems to deal with, but
human operators tend to be a bit more adaptable in as far as working
out
what should be done. Thus for a back end system, a proper transaction
mechanism is needed which may involve multiple communications. SOAP
might well be used as a base communication for this, but it isn't
necessarily
an ideal medium for doing it. I would imagine that a lot of the effort
being put in by Microsoft with .NET would be trying to address this
particular
issue.

> > Companies spending millions on huge projects cannot. SOAP is supported by
> > IBM, Microsoft etc. and would they risk promoting, even building complex
> > systems like .NET on this technology if it wasn't suitable at all?
> 
> Umm, yes they would.  Microsoft built a multi-billion dollar empire
> on buggy, unreliable software that is "good enough" for consumer-grade problems.
> As you point out above "reliable" depends in what context and by what measure
> you are working.

And what has just happened. On www.theregister.co.uk, it talks about
how
Microsoft is putting back to 2003-2004 the introduction of its full
.NET
infrastructure. The article mentions that some of the specifications
it
is going to rely on need to mature, but one could also speculate that
getting the reliability required for back end systems that corporate
customers are going to require, isn't as easy as they may have thought
it was. Remember that they are trying to push this as an eventual
replacement
for COM+ but in a distributed context. The stuff they have put out so
far
has only been to address the user/server case and isn't necessarily
appropriate
for server/server by itself. I can't seem them going away from their
existing
transactactional queueing systems real soon now. Right now .NET is no
more
than yet another buzz word as has in no way proved itself. As with
lots of
Microsoft stuff, the end result will probably be very different to
what they
thought it would be at the start. But of course, they will always say
that
it was what was always intended. :-)