--- Stefan Tilkov <[EMAIL PROTECTED]> wrote:
> (1) WS-* is "protocol independent", while REST (in all practical
> relevance) is tied to HTTP.
> (2) The WS-* specs address "enterprise" concerns that REST/HTTP can't
> handle
> (3) It's much easier to expose an existing system that has a
> "transactional" interface (in the TP monitor sense) via WS-* than via
> REST, since the latter requires a real architectural change and the
> former doesn't
>
> Are there any other benefits that WSDL/SOAP/WS-* is claimed to have
> over REST/HTTP?
> > (1) WS-* is "protocol independent", while REST (in all practical
> > relevance) is tied to HTTP.
> > (2) The WS-* specs address "enterprise" concerns that REST/HTTP
> can't
> > handle
> > (3) It's much easier to expose an existing system that has a
> > "transactional" interface (in the TP monitor sense) via WS-* than
> via
> > REST, since the latter requires a real architectural change and the
> > former doesn't
With regards to #3, I see an large amounts of work undertaken to "SOA
enable" one's transactional systems into more business-relevant
services, using every manner of infrastructure (BPM, ESB, Data
Services, etc.). Usually this is part of a larger initiative (as
"SOA for its own sake" tends to be a very hard sell).
In my experience, shifting an IT department's mindset towards SOA tends
to require a lot of architectural change. It's mixed as to how a
business may accomplish this:
- some are throwing out their old applications and buying packages like
SAP (which want to SOA-your-world). This is often $100m+ of work.
- others are rebuiliding their systems on Java or .NET , perhaps with
some best-of-breed packages to fill in some areas. Again, this can
may many $m.
- many are just layering service infrastructure on top of the old
stuff but doing a big rethink as to how re-route access through the new
layer. Fewer $m, but still significant.
I don't think the issue with REST being "hard to adopt in the
enterprise" is a lack of desire for investment in new infrastructure
and in re-thinking. That's happening with SOA. I think the reason
for this disconnect is probably more fundamental, similar to the
eternal pendulum debates of behaviour-centric vs. data-centric design.
Here is my take on the disconnect:
1. Data-centric approaches to architecture are not popular. Yet, REST
approaches are data-centric. It isolates the importance of data --
identifiers, provenance, temporal relevance -- and singles them out as
some of the *most important aspects* of a shared information system
architecture.
Anyone that has dealt with data quality, data warehousing, etc. knows
that this is a huge problem, but is often ignored outside of small
circles in the enterprise. Perhaps this is why so much integration is
still accomplished through ETL and batch transfer -- they're the ones
that pay attention to the semantics of data & integrity of the
identifiers ;-)
Roy, in his thesis, even underlines this in Chapter 1, noting that the
vast majority of software architecture -- even in the academic
community! -- ignores studying the nature of data elements. His
conclusion -- "It is impossible to evaluate [a network-based
application] architecture without considering data elements at the
architectural level."
COM, CORBA, WS-*, MOM, etc. look at the data elements as messages.
They are envelopes, like IP. They don't consider data elements beyond
this: send whatever you data want, deal with data issues your way.
REST, on the other hand, looks at this explicitly, even covering data
stewardship -- ("Cool URI's don't change", and "The naming authority
that assigned the resource identifier, making it possible to reference
the resource, is responsible for maintaining the semantic validity of
the mapping over time.")
The bright side is that these differences don't preclude COM, CORBA,
WS-* from adopting constraints that explicitly deal with data.
2. SOAP Web Services were originally created to be an XML-oriented
replacement for COM, CORBA, and RMI/EJB. This is documented
history.
They were intended to:
a. simplify integration, and solve the problems of these old approaches
-- make them more MOM-like and asynchronous, and less RPC-focused.
b. also allow richer data structures through XML (vs. the old
approaches that required custom marshalling or proprietary
serialization).
c. give a chance for Microsoft to get "back in the game" of enterprise
systems, as J2EE had pretty muched eclipsed DNA. They would do this
by eliminating the competition over programming models & core protocols
- changing their old Microsoft-centric stance.
d. traverse firewalls by piggybacking on HTTP
The focus was clearly on XML as a marshaling format. The hidden
assumption seems to be that if we fix the above, the "distributed
object nirvana" that we longed for from the COM / CORBA days would take
hold. SOA added "governance" to this mix. And while SOA governance
may deal with data problems in isolated cases, there is little
consistent *architectural* treatment of data in these aproaches. It's
still a mishmash of CBD, object-orientation, and message architecture.
Some articles to read....
September 1999: Lessons from the Component Wars, an XML Manifesto
http://msdn2.microsoft.com/en-us/library/aa468562.aspx
April 2001: A Brief History of SOAP
http://webservices.xml.com/pub/a/ws/2001/04/04/soap.html
Interesting quotes:
"SOAP's original intent was fairly modest: to codify how to send
transient XML documents to trigger operations or responses on remote
hosts"
"Component technology has been the cause of many arguments,
disagreements, and debates. This component-induced friction can be
traced to two primary factors:
1. Different organizations and corporations want to be the de facto
provider of component infrastructure.
2. Component technology provides more opportunities for different
programming cultures to interact.
There are many lessons to be learned from examining these two factors
closely. In this article, we will examine how component technology has
evolved to XML."
Today -- SOAP 1.2 and WS-* have evolved this purpose into a general
purpose asynchronous protocol, it really is still a way to create a
vendor-independent, interoperable replacement for MOM.
This is not to say there is no value in a better MOM -- just that there
might also be a lot of value in a better way to integrate data in a
distributed system.
I'll end this by noting returning to the original point of the thread
-- what I think are the benefits of other approaches vs. REST:
- When you just need to remotely access or manipulate an object and
want to make it feel like developer's local API as much as possible,
without need for data sharing, or evolution. CORBA interfaces on
network switches are an example of this. They're fine. SOAP and XML
are being applied here too. RESTful services may even use these
things.
- When you're tightly coupled, control all the endpoints, and want
distributed transactions. SOAP and XML are being applied here (but
WS-AtomicTransaction isn't known to be widely implemented or
interoperable yet). Arguably this might be easier than IIOP or TIP,
the protocols used by CORBA or COM+. Maybe it'll be more
interoperable than XA resource drivers, which tend to be the most
common way to integrate these transactions. There's some benefit
here.
- When you want a vendor independent MOM for stateful in-order,
reliable, non-idempotent messages, and don't have time or inclination
to make your data easily reused, study whether your interactions are
safe/idempotent (which obviates the need for dupe detection), or your
application doesn't lend itself well to statelessness (which obviates
the need for an infrastructure to handle retries & dupes). See
WS-ReliableMessaging.
I think this is the approach that many vendors & enterprise architects
are thinking will be the ultimately desirable scenario for WS-*. I'm
curious how this will pan out, as I don't see a lot of discussion about
the tradeoffs of this approach. It likely will succeed to a
reasonable degree, though I don't think it actually helps a lot of the
SOA desires for agility. Perhaps this is the area where the WS/REST
bridges need to be built.
- When you need stateful, real-time communication. This is clearly
for two-way streamed communication, like voice/video. You probably
wouldn't use SOAP for this, either. BitTorrent is an interesting
hybrid case, where they use HTTP for signalling and discovery, and the
BitTorrent protocol for the actual exchange.
- High speed pub/sub event notification. While there are plenty of
attempts to extend and/or emulate this in HTTP, not many have caught
on. Of course, that this generally is the case with SOAP today too,
since WS-Eventing isn't really implemented or ratified. So there's
still a lot of room for MQ, JMS, TIBCO/RV, etc.
I don't really include security in this, as RESTful web services can
already reuse XML Signatures, XML Encryption, S/MIME, SSL, and allows
for username/password, OpenID, Kerberos/SPNEGO, and SAML assertions
already. WS-Security is just a wrapper for most of these approaches.
Though, a RESTful multi-party secure conversation protocol might be
an interesting development in the future.
Cheers
Stu
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
