Frank Cohen's Blog

A blog by Jason English at iTKO has me bothered. Jason praises an analyst report from ZapThink's Jason Bloomberg titled Divorcing SOA from Web Services. Neither iTKO nor ZapThink seem to get the vision behind SOA and Web services.

The IT industry has a long way to go to serve enterprises and organizations needing to well manage their efforts through information systems. Service Oriented Architecture (SOA) and Web Services (WS) are entirely appropriate to build information systems. The vision behind SOA and WS help us a lot and in different ways.

Here is a slide I have been presenting at various conferences for the past two years to explain the differences between the SOA vision and the WS vision.

The vision behind SOA and Web Services comes from enterprise and organization needs to save development effort and money by reusing software in the form of components.

The Web Services vision achieves reuse by building service components that autonomously discover at runtime other needed components needed to solve a business process. The SOA vision achieves reuse by aligning new software development projects to business goals through a governance plan. Both expect a registry of services will help avoid building the same software component twice.

In terms of architecture, SOA relies on composite applications and data services while Web Services relies on finely-grained, loosely coupled, discoverable services. A composite application is a piece of software that is able to talk multiple protocols to existing services to give you one view of either the customer or one view of the business process. For instance, you may have been in a situation where you've had to call an insurance company to try and find out two different things: the date they received your most recent payment and how to file a claim.

This example insurance company may have two systems - one system retrieves your most recent payment, but then the operator that you talk to might have to forward your call onto a different operator just to ask the question about filing a claim. With a composite application, you have a single piece of software that is able to speak the native protocol to the service to look-up your payment information. The composite application, typically on the same screen, can even speak the protocol of the claim center to place a claim directly.

As a customer, you are served better because you conclude your business with a single agent on a single phone call. And the insurance business saves money by serving you within that one phone call. Many companies PushToTest serves that have adopted SOA and Web Services find that composite applications are more easily built than trying to get the existing services to interoperate directly. These enterprises have a faster time to market advantage than their competitors.

Management techniques vary between SOA and Web Services. The SOA vision expects an enterprise to define a governance plan. Web services expect composite applications to register themselves with a dynamic repository of services to be dynamically discoverable at runtime. This is where SOA and Web Services diverge the most. Unfortunately, none of the information ontologists showed up to the Web Services party. There is no standard for categorizing composite applications or software components. That is a big challenge for any enterprise or organization to realize the vision of Web Services.

SOA and Web Services vary in an important way for message formats and protocols. The SOA vision says "whatever message format and protocol works is acceptable" whereas Web services mandates XML. This is an important point because it means that SOA may use Web Services.

What we have here is a success at communication! Communication between information systems has never been this good.

SOA and Web Services are useful visions to move us from the current XML, Platform, Application, and Service (I call this XPAD computing) into the future. IT has been wanting this kind of interoperability, reuse, and governance for decades, including in efforts like CORBA, OpenDoc, DCE, Client/Server, Web 1, Web 2.0, and Enterprise Web 2.0. Those were all efforts to be able to provide a component architecture where software could be reused to provide an enterprise with a faster time to market advantage and then lastly to provide an enterprise with a better view of the customer.

SOA keeps the WS component idea, focuses on composite applications for business workflows, and loses discoverable service idea for statically brokered endpoints, governance for choreography, business issues, troubleshooting, and Quality Of Service (QOS.)

It is just fine to me that sometimes enterprise architects and technology managers get the terminology of SOA and Web Services wrong. You won't see PushToTest talking about "divorce" in a family of technology that helps the world become better.