The Myth of Loosely Coupled Web Services

Which of these three statements is true?

1. Web services are inherently loosely coupled.
2. Loosely coupled communication is better than tightly coupled communication.
3. The WS-Reliability spec will help usher in a world of loosely coupled web services.

The answer is easy: none of them.

A core problem is that "loosely coupled" is not a well-defined concept. To some people, it just means that precise interfaces are specified, allowing anybody to invoke the services those interfaces describe. Yet by this definition, CORBA and other RPC-style mechanisms are loosely coupled, an assertion that most web services fans wouldn’t buy. Others think of loose coupling in an administrative sense, where the communicating applications can be owned by independent organizations. Again, though, this definition admits most RPC technologies, and so web services provide no real advance.

Another possible meaning of loose coupling, the one that I think is most meaningful, is that it’s what you get with asynchronous communication. Unlike the call/response lockstep of RPC, asynchronous communication typically relies on some kind of message queuing, and so senders need not wait for a response before continuing. Even better, all parties in the application need not be available at the same time, which really loosens those couples.

So are web services inherently loosely coupled? Of course not. The majority of web services interactions today use SOAP over HTTP in an RPC-style fashion. This isn’t a bad thing, as many useful applications work just fine when a call is followed by an immediate response. And is loosely coupled communication better than tightly coupled communication? No, it’s not. Some applications work better with synchronous communication, others with asynchronous communication. The battle between fans of both approaches ended years ago, and the result was widespread recognition that both have their place.

What’s really holding back loosely coupled web services is an agreed way to do SOAP-based reliable messaging. Microsoft and IBM, the people who’ve led the development of every major web services technology so far, were tardy in getting this spec out to the world. It’s finally appeared, however, with the release of WS-ReliableMessaging. As a result, Sun, Oracle, and a few other vendors beat them to the punch with their WS-Reliability specification, published a couple of months earlier. It’s hard to be sure, but this second group of vendors might think they’re helping us move toward a world of loosely coupled web services. They’re not.

I can understand the frustration these vendors must feel. Web services are the most important thing happening in distributed computing today, yet the core technologies are being created by a closed club. IBM and Microsoft are in the driver’s seat, with most other vendors hanging on to the fenders (although BEA is doing a good job of getting inside the car—they’re making their voice heard more and more). The urge to fill this important hole must have been overwhelming, especially for Sun, as must the desire to appear relevant. And given its roots in the ebXML Message Service, WS-Reliability may also be an attempt to salvage something from the wreckage of ebXML.

Nevertheless, WS-Reliability will if anything delay the widespread availability of loosely coupled web services. Now that Microsoft and IBM have published their spec, we’ll all wait patiently as each of these two approaches is promoted by a different group of vendors. Rather than near-instant agreement, as has happened with most web services technologies so far, we’re facing a period of conflict and confusion.

But the outcome is not in doubt. WS-ReliableMessaging will win, because what matters isn’t who ships specs, but rather who ships code. Together with BEA, a co-creator of WS-ReliableMessaging, Microsoft and IBM are the dominant providers of web services software in the terms that matter most: market share. Their agreement on SOAP gave birth to web services as a commercially viable idea, and their subsequent agreements on WSDL, WS-Security, and other specs have been filling in the gaps. By backing up those agreements with shipping products, these leading vendors have forced the others to follow along. This isn’t pretty, and it isn’t how standards are ideally supposed to be created, but the process has one huge advantage: it works. WS-Reliability is a distraction—at worst a small speed bump—on the way to interoperable, loosely coupled web services.

Thinking of web services as inherently more loosely coupled than earlier technologies isn’t really accurate. Yet adding support for WS-ReliableMessaging will go a long way toward achieving this goal. In spite of WS-Reliability, loosely coupled web services won’t be a myth much longer.

Now Available: Brian Arkill’s LDAP Directories Explained

Every modern directory is built around the Lightweight Directory Access Protocol (LDAP). LDAP Directories Explained provides a clear description of how LDAP works, including the namespace, the schema, and the protocol itself. The book also examines the leading LDAP-based directories, including OpenLDAP, Microsoft’s Active Directory, and the Sun ONE (formerly Netscape) Directory Server. The author, Brian Arkills, has worked extensively with LDAP-based directories as a software engineer at Stanford University and the University of Washington. To order a copy, visit Amazon.

LDAP Directories Explained is the third book in Addison-Wesley’s Independent Technology Guides series, for which I am the series editor. The books in this series provide big-picture views of important technologies, and they all have an easy-to-read layout with margin notes and plenty of diagrams. Each book also has distinct analysis sections, allowing the writer to clearly distinguish opinions, discussions of controversial issues, and other interesting topics. Watch for books on web services security, the semantic web, and other topics later this year.

• The Myth of Loosely Coupled Web Services
   
• Now Available: Brian Arkill’s LDAP Directories Explained

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, David helps information technology professionals around the world understand, use, market, and make better decisions about enterprise software technologies. David has given keynotes at conferences and in-house events in the U.S., Europe, Latin America, and the Middle East, and his seminars have been attended by tens of thousands of developers and decision makers in more than thirty countries. David’s books have been translated into ten languages and used in courses at MIT, ETH Zurich, and other universities. His consulting clients have included HP, Microsoft, Stanford University, and other technology vendors and users.

©Copyright2007 David Chappell and Associates
All rights Reserved.