Re: What Does SOAP/WS Do that A REST System Can't?

[Michael Champion <michaelc.champion@gmail.com>]

On Fri, 01 Apr 2005 16:17:56 -0800, Tim Bray <Tim.Bray@sun.com> wrote:
> On Mar 30, 2005, at 12:32 PM, Michael Champion wrote:
> 
> > If on the other hand you are building systems that
> > handle confidential information, mission-critical services, and have a
> > bunch of legacy systems and protocols to integrate, I'd say the burden
> > of proof is on anyone suggesting something other than WS at this
> > point.
> 
> When you say "WS" I assume you mean "SOAP+WSDL", given that more or 
> less everything else in WS-* is either not yet implemented, or not yet 
> standardized, or exists in multiple competing versions from different 
> vendor factions. 

Definitely SOAP, if you are bridging a bunch of legacy systems it's
going to be desirable to have its protocol neutral headers to carry
around information that you might have gotten with one
protocol-specific field and need to get to the destination.

WSDL is not anybody's favorite spec, but it's handy for ordinary
mortals who just want their tool to generate that XML stuff so they
don't to get their hands dirty with it.  For better or worse there are
a lot of those people lurking around, and the chances are you will
have to deal with them at some point in your integration project.  So,
with some personal reluctance, I'd have to say that  WSDL is part of
the mix.

WS-Security is an OASIS standard, and leverages XML Encryption which
is a W3C Recommendation.  I don't know for sure how field proven it
is, but I'm comfortable saying that it makes sense to leverage all the
thought and experience that went into it unless you KNOW that you can
roll it yourself better than OASIS did.  All those picky little
details that it specifies are XML Encryption interop problems waiting
to happen if you roll your own, AFAIK.

WS-Addressing has been on the fast track at W3C after some pretty
heavy-duty discussions and prototyping carried out by the major WS
vendors.  Again, if you have the pain that it addresses, does it make
more sense to roll your own or go with the flow?  I'm confortable
suggesting that the burden of proof is on someone who thinks they can
do it better, and still support the functionality it offers.

OK, there's multiple versions of the WS specs for message reliability
with different vendor factions on one side or the other.  I guess you
go with whatever your enterprise vendor supports; if you have to
integrate across incompatible vendors, I guess you roll your own
solution for this particular bit. ... or consult with an "integration
tool integrator", sigh.

As for everything else in WS-KitchenSink, I really don't know -- I
haven't followed this stuff closely for more than a year.   A lot of
them may address problems that most people don't have yet, so the
chaos there is irrelevant.  A few general observations:  Sure, they
aren't  "standardized", but neither are all sorts of specs that the
XML world runs on: SAX, RSS, RDDL (increasingly in the MS world), and
SOAP/WSDL 1.1 for that matter.  The question is whether they have
enough real world functionality and interoperability to make it more
sensible to leverage them, roll your own, or wait for a Real Standard.
 That's a decision everyone just has to make for themselves.  Also, I
guess I really do think that anyone getting into an  swamp such as,
for example, the one which WS-Coordination / WS-AtomicTransaction /
WS-BusinessActivity tries to drain, owes it to themselves to make VERY
sure that they understand where the alligators are lurking better than
the very smart and experienced people who have been working on the
problem for some years now. Maybe your better answer is to build a
bridge over the swamp rather than drain it, I wouldn't have any reason
to disagree ... but that will offer you a whole new set of bleeding
edge problems to answer, and a lot fewer resources to draw on to help
you.

I have no particular personal or Day Job stake in WS-*, but after this
little thought experiment I do still think that anyone using XML and
"building systems that handle confidential information,
mission-critical services, and have a  bunch of legacy systems and
protocols to integrate" ought to be taking an extremely close look at
that stuff.  What's the practical alternative?  It's not  "rewrite
everything with all key components conceived of as abstract resources
that exchange XML representations, driven by hypermedia as the engine
of application state" or whatever.  Lotsa luck getting THAT by the
executives :-) There might be some pragmatic way to leverage Plain ol
XML and the Web more effectively than most organizations do now, but
AFAIK the major success stories for this involve public information,
non-mission critical services, and tend to be built from scratch for
the Web.    As Rich Salz has explained very lucidly earlier in this
thread, you do NOT get industrial-strength security, reliability, etc.
for free with your HTTP infrastructure.  I'm pretty sure that the most
currently viable alternative to WS-* is More Of The Same  -- MQ/COM
/CORBA/J2EE / armies of consultants / barrels of red ink that
enterprises are trying to get away from.  That provably kindof works,
but is provably expensive.  I don't know how that balances out vs WS-*
on the burden of proof scale.

I (personally) suspect that the long term answer to this will draw a
lot from both the simpler, more evolutionarily stable ideas that REST
tries to pin down and the complicated realities that WS-* attempts to
wrap up in somewhat tidier bundle.  The ideas that excite me involve
(surprise, surprise) XML-capable DBMS to do the heavy lifting for
transactions, reliability, authentication/access control, and
interfacing to the legacy infrastucture.  Patrick Thompson (then of
Rogue Wave) and I (then of Software AG) were trying to interest people
in a Ruple [XML Tuple Space prototype] / Tamino combination to do this
a few years ago.  In the very near future, <plug> the SQL Server 2005
Service Broker (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/sqlsvcbroker.asp?frame=true)
might hit a very similar sweet spot for "messaging in the database"
while presenting a somewhat REST-like minimal and uniform interface to
the client. </plug> .