[
Lists Home |
Date Index |
Thread Index
]
This is the same conclusion I came to but decided that it wasn't a good enough answer because it really doesn't justify the "web" in web services. From your point of view (and mine, I guess) SOAP adds better interop than existing distributed computing (RPC/message-based) solutions by eliminating many of the complexities (no pass by ref for example ) and being amenable to many off-the-shelf tools because it uses XML.
However, although I see it being likely that many intranet or similarly closed-network applications may begin to utilize SOAP and its family of related technologies instead of DCOM/CORBA/RMI etc. I'm not sure if there really is much applicability to the World Wide Web that isn't toy applications or even worse poor utilizations of the web.
I really need to take a deeper look at SOAP and GxA. Always so much to learn...
-----Original Message-----
From: Joshua Allen
Sent: Sun 4/21/2002 12:06 PM
To: Simon St.Laurent; xml-dev@lists.xml.org
Cc:
Subject: RE: [xml-dev] What does SOAP really add?
> XML-RPC when used in relatively simple and small environments, I have
> deep qualms about using RPC in general on any large scale over any
long
> period of time. RPC is brittle, breakable, etc. - we've been over
that
> before.
> Loose coupling is central to the nature of Web services-based
> application integration. That's why it seems to me that the right
model
> for XML in Web services is a message-oriented, document-based one
rather
> than one based on remote procedure calls.
OK, I hope you are reading this wrong. Bosworth is certainly making a
point in *favor* of XML message-passing formats like SOAP vs. things
like RMI, but is in no way making a case for REST. The
"loosely-coupled" in this comment comes from async and XML-based
messages. This is the Biztalk model. I'm not saying that Bosworth
isn't a believer in REST; just that the particular scenario described
here is not one that REST advocates find terribly comforting.
> there's a notion of a framework worth discussion, but to be honest, I
> can't see any real benefit. A vocabulary for fault codes? (Okay, a
> second wave of hype.)
Are you asking what benefit SOAP brings vs. everyone just rolling their
own XML serialization/envelope formats?
The basic answer is that it allows out-of-box interop (well, usually) so
things like VS.NET can work with BEA, and BEA can work with Apache, and
so on. This doesn't negate the value of loose-coupling -- it is still
beneficial to do loose-coupled async architectures even if the
message/document format is not SOAP. But the fact that 90% of clients
and servers support automatic SOAP mappings mean that SOAP is a safe bet
for an XML novice trying to whip up a loosely coupled architecture in a
hurry.
Furthermore, messages that use SOAP format will presumably be able to
work with future infrastructure that does WS-Routing, DIME, and so on.
These other layers of the "protocol stack" have to be able to depend on
some consistent features, and will naturally target something like SOAP
rather than try to support every naked XML format that anyone cooks up.
> the same kinds of questions. Now I wonder if maybe I should just wait
> for the Web Services hype to fade, and hope that XML (with REST, or
> something similar) gets a second chance afterward.
Honestly, I think the best way to grok what all of the fuss is about is
to try building some mock systems with imaginary (but realistic)
business partners. Pretend that your company has a PeopleSoft on Oracle
system you have to talk to, and your boss just bought a BEA Weblogic
server for your department, and you have to provide aggregated
information from the PeopleSoft HRMS on-demand to anyone who sends you
the appropriate JMS message. Your two main customers are departments
that use Microsoft SQL Server, so you have to be able to prove interop
with them (rather than just declare, "it uses XML so it is
interoperable, as long as those other idiots do the right thing.")
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
