[
Lists Home |
Date Index |
Thread Index
]
On Feb 14, 2004, at 2:07 PM, Dennis Sosnoski wrote:
>
> The initial buzz around SOAP was all based on the rpc/encoded use (or
> Microsoft's "wrapped" variation) where method calls were
> "transparently" exposed as web services. Now that that's effectively
> deprecated in WS-I BP 1.0 (for good reason) SOAP currently offers very
> little (if any) functionality beyond what can be done using direct XML
> interchange over HTTP.
> ... It's embarrassing when I teach web services to be able to show so
> little benefit from SOAP, given all the attention it's received.
> People feel that with so much marketing hype there has to be more
> substance than I'm able to demonstrate.
>
Having spent much of the last two years on the work that led to
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/ and wrestling with
this question, I'm very sympathetic to this position. I came away
convinced that "Web Services" was invented by marketing people, and to
even coming up with a somewhat specific definition of the term (see
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#whatis )took a major
act of diplomacy. Nevertheless, I kindof like the bit at
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#SOAP where we talk
about SOAP (which is no longer an acronym for anything) being used as
both a "Simple Object Access Protocol" and a "Service Oriented
Architecture Protocol", and pointing out that SOAP essentially
"provides a standard, extensible, composable framework for packaging
and exchanging XML messages" in a network-independent manner. The
other stuff (like the RPC conventions and datatype encoding) is
optional. So, "SOAP" as people define it looking forward is not quite
the same as the "SOAP" that we have known for the last couple of years.
I have very mixed feelings on what this means about the real success
of and benefits for SOAP. On one hand, I agree that there's little
concrete today on the Web to point to showing the benefits of SOAP, and
the Visual Studio.NET approach of "transparently" exposing ordinary
objects as Web services via SOAP and WSDL was, uhh, well "misguided" is
about the most polite term that comes to mind :-)
On the other hand, even SOAP-RPC is being used effectively in
enterprise integration situations where the vendor neutrality, platform
neutrality, and protocol neutrality of XML/SOAP is necessary and the
support in tools such as VS.NET is very convenient (at least once
enterprise developers learn not to shoot themselves in the foot by
exposing fine-grained object interfaces as Web services). More
importantly, SOAP's header extension and processing model, and the
design pattern of using specialized intermediaries to support specific
standard headers (such as firewalls that understand WS-Security) is
showing real promise as the basis for the defacto standard Web services
architecture being laid down by the 800 lb gorillas (see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
dnwebsrv/html/wsoverview.asp ... and the "process document" at
http://www-106.ibm.com/developerworks/offers/WS-Specworkshops/ ). Of
course, we shall see if the WS-* stuff actually pays off in practice,
but there is an awful lot of energy being poured into it. I sure
wouldn't want to bet *against* the value of WS-Security and WSBPEL at
this point.
|
