June 10, 2007

What are the benefits of WS-* or proprietary services?

This was originally part of a post on the Yahoo! SOA mailing list.

I'm firmly a proponent of RESTful architectures (independent of whether they're over HTTP, or SOAP, or whatever underlying transfer protocol), as I believe they objectively lead to more scalable, interoperable and evolvable information systems.

Of course, nothing's perfect, and the implementations & tooling out there doesn't live up to the theory.

So when are alternatives appropriate? Stefan Tilkov suggests three simple factors:

  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

I think #1 tends to be somewhat theoretical. I've seen lots of MQ out there, but not a lot of SOAP over MQ, for example. Such an approach is not overly interoperable, though I can see benefits of reusing WS-* infrastructure with proprietary infrastructure when within the bounds of a single vendor's stack, like IBM.

#2 true, but the implicit problem is that the term "enterprise" is sort of like "scalability"... it's often a way to shut down debate without studying the specific concerns. Debates on "Reliability", "Security", and "Transactions" for example, tend to require specialist knowledge and, lacking that, seem to hold a mystical status that cloudens debate when RESTful approaches may have very different views on these topics (even if they are well-founded).

I have a longer discussion & historical perspective on #3, which will be in a subsequent entry.

In the meantime, here's my (incomplete) list of scenarios of when you'd want an alternative to a RESTful protocol....

  • 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 as a benefit of other approaches. 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. Authorization rule engines tend to also be independent of whether something is RESTful (whether they're XACML, or proprietary, etc.) Though, a RESTful multi-party secure conversation protocol might be an interesting development in the future.

update: Just a quick clarification, as Stefan notes, that the three points he made were somewhat taken out of context from the SOA mailing list. He doesn't necessarily believe them to be true, just that they are common viewpoints.

Posted by stu at June 10, 2007 03:02 PM