[
Lists Home |
Date Index |
Thread Index
]
> 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.")
|
