Are Web services the path of least resistance to SOA?

Amir Shevat asks the question that many have been wondering: Are SOA and Web services synonymous?  His answer, in short, is no, but... Web services (or more precisely, XML Web services) are probably the best way to get to where we are going.

With appreciation to Malte Poppensieker for this definition, an SOA is based on loosely-coupled and coarse-grained services with well-defined interfaces that provide business functionality and can be discovered and accessed through a supportive infrastructure. This allows internal and external system integration as well as the flexible reuse of application logic through the composition of services to support an end-to-end business process. 

Note that XML Web services is not mentioned in this definition, nor should it be.

Shevat points out a couple of issues with XML Web services. First, the fact that most Web services implementations are based on HTTP as a transport protocol.

"This fact sets a very big limitation when you use WS to implement SOA. HTTP is a request-response protocol that confines the SOA implementation to a client-server type of services. What do we do if we want asynchronous service invocation? What do we do if we want to build an SOA-event-driven application?"

Shavat also talks about the verbosity of XML as an issue that could slow down SOAs:

"XML is hardly the most efficient communication protocol... As oppose to binary data, XML is very easy to edit and understand. Those attributes of XML are a big advantage when one uses XML as a way to configure an application. However, this does not necessarily mean that XML is the suitable means to pass information between applications. We would have computers communicate through spoken language if 'comprehensible to humans' was our primary concern in choosing a protocol."

Shavat observes that "other services are better implemented with other technologies. Asynchronous services, for instance, might be better implemented by asynchronous messaging (such as JMS)."

And, as I observed on previous occasions in this Weblog, just because a company has a JBOWS architecture (Just a Bunch of Web Services) doesn't mean it's an SOA. An effective and well-functioning SOA that meets the definition above requires enterprise-level governance, orchestration, management, and scalability.

But the bottom line is that an SOA can be constructed on almost anything imaginable, and doesn't have to have a single XML Web service anywhere in the messaging chain. In fact, an enterprise can construct a framework entirely on its own home-grown standards.

In a recent Weblog post, Infravio's Miko Matsumura, who chairs the OASIS SOA Adoption Blueprints committee, points out that SOA is in the eye of the beholder, and not for anyone else to judge whether it's right or wrong:

"Our definitions of SOA are going to hinge upon people’s requirements. And we expect that some of those requirements are not going to be pretty, or even not real “macho,” SOA. Or, some weird implementer is going to come up with a weird way to do it using something weird. But that’s okay. But if it barks like a dog, it’s a dog. If it barks like a dog, we’re satisfied."

But Matsumura makes it clear that in his view, Web services is the path of least resistance on the way to SOA. "If someone requires interoperability, transparency, intermediation, and policy enforcement, then a Web services approach probably is the best answer. Trying to meet such requirements with other systems is probably going to be unnecessarily hard."

When push comes to shove, why spend a lot of time creating, testing, and deploying your own interfaces when there are industry-proven specifications already in existence?