Pete Lacey’s Weblog

Tim Bray styles himself as the Loyal Opposition. Opposed, that is, to the rush towards web services and their attendent complexity. In a recent post he provided a balanced set of links illuminating the schism between the proponents and detractors of web services. Go read that to get up to speed on the debate and to sample not a small amount of vitriol.

If you are not inclined to read through all of those postings, I’ll summarize it here for you. Everyone agrees that sending standardized (XML) messages over the Internet is a good thing. Web service detractors, principally those in favor of the REST model, believe that they have the superior mechanism for doing this. While the web service proponents believe the same. In short, the RESTafarians think web services are too complex, and the WS crowd think REST is too simple.

And you know what? They’re both right!

Web services are complex, indeed, overly so. But a lot of that complexity is simply a reflection of the underlying technical challenges that the various WS specifications are attempting to address. As said elsewhere, web services are targeted at the business archictect/developer to whom reliability, security, asynchrony and the like are very, very important. Challenges simply not addressed in the REST model.

The REST model on the other hand, reflects the Web. Well, in fact, it is the Web, with all of the web’s simplicity, ubiquity, and power — and a dollop of XML. The RESTafarians prize simplicity above all, and are justly happy with the way their world works (though I have a few minor reservations).

So while REST perfectly solves the Internet messaging needs of the blogosphere, Technorati, and Yahoo, it is not sufficient for Citigroup, Ford, and AIG.

Now, on to that complexity. The seeming complexity of web services stems from a number of roots:

• Some of the standards are simply flawed
• Some of the standards are flawed simply because they’re built on top of other flawed standards
• Some of the standards aren’t standards. There’s too much duplication of functionality amongst competing specifications. Aka, vendor wars
• Web services are complex because technology is complex

In future posts I plan to address all of these items. Right now, though, I’d like to focus on the last one. As already mentioned, a lot of WS complexity is simply a reflection of the underlying complexity of the technology now being modeled in XML. Here’s the takeaway: The WS specifications are simply moving existing opaque and/or proprietary transport and wire protocols off the wire and into the message., and in doing so are opening up opportunities not previously available. While there’s not always a one-to-one mapping, maybe this table will help clarify things.

Once again, the various WS specs are mostly moving existing opaque technologies into XML, facilitating interoperability and intermediation. Furthermore, some of the WS specs are attempting to address technology challenges that the existing systems simply ignore. For instance, now that everyone speaks the same language, it would be nice if there was a standard means of discovering (at development time or runtime) what the configuration of a particular service is. Is it secure, if so how? Will it participate in a transaction? Where’s the interface contract (WSDL) it implements? Etc? From this we get WS-Policy and related domain specific policy languages (e.g., WS-SecurityPolicy), WS-Discovery, WS-MetadataExchange, and so on. Similar in many ways to protocols and APIs such as LDAP, JNDI, or DHCP.

So while all of this seems to be happening in a mad rush, and vendors are loosing imperfect and competing specifications on the public (the above are from Microsoft and IBM), one cannot say that WS specifications are complex without also saying that the sum of CORBA, RPCs, DCOM, RMI, PKI, SSL, Kerberos, MIME and S/MIME, PGP, LDAP/AD, Message Oriented Middleware, TP Monitors/XA, HTTP, HTML, CSS, SMTP/POP/IMAP, SNMP, object modeling, relational databases, application servers, and so on, and so on are also comple; which, admittedly, they are. The only real difference is that the WS versions of these protocols (not the implementations) are visible to the user.

Furthermore, while existing systems are inherently complex, one reason you don’t hear too much complaining about them is that the complexity is often hidden from the developer. It’s built into their tools and libraries and design practices. I should stress that the same is and will hold true for web services. The typical WS developer does have to know their craft, but they don’t have to know how each and every spec is implemented. For instance, there’s no good reason why WS-ReliableMessaging can’t be built behind JMS, and thus present no more complexity than MQ-Series does to the Java programmer. Similarly, there’s no reason for a developer to employ each and every one of these specifications; if reliability is not important, don’t use it. And remember, these specifications allow for business partners to participate. So, continuing our example, unlike MQ-Series, WS-ReliableMessaging allows, say, Visteon (if not the Internet at large) to reliably deliver messages into Ford’s systems, regardless of whether they use the same language or platform. That’s pretty powerful!

Well, I hope that helped a little. It’s not the end of the story, though. Yes, some complexity is inherent, but not a small amount of it is unnecessary. In future postings I hope to deconstruct the WS stack and build up a simpler, more sensible versions. In doing so, I want to keep compatibility with existing systems, but already fear that that won’t be fully possible. Not that it matters really as nobody knows me, and this blog is too new to get noticed. Besides, it’s not like IBM and Microsoft are going to build what I describe. It should be fun, though, and maybe educational.

Oh, as for the title of this entry. If Tim is the Loyal Opposition, then I, as someone who sees merit in both REST and web services, am, though an American, a loose fish.