Build-out Service-Enabled Solutions
Without Having to Build-out the Entire Network

By Dave Hollander

A recent review of SOA products in InfoWorld highlights common flaws in perception regarding needs of the consumers and providers of Web Service and SOA technology.  The perspective given in the InfoWorld article on the evolution of SOA is that the technology focus will become increasingly middleware and large-IT centric.  I believe this analysis is flawed because it does not consider the needs and interests of service consumers and providers who want to source and consume data to and from their applications, without having to build out complex and costly networks. And, if the web taught us anything about the deployment of large-scale networks, it is these needs that will drive technology evolution.

Point 1: Standards. 

Regardless of the underlying messaging core, an ESB must somehow -- through open standards or by proprietary means -- create a foundation for reliable messaging. Until WS-* specifications for reliable messaging fall into place, that reliability continues to come from the likes of JMS (Java Message Service), homegrown messaging engines, proprietary MOM (message-oriented middleware), and J2EE servers.

The web grew out of a mixed set of standards and pseudo-standards from a wide variety of providers. HTML from the W3C, HTTP from IETF are most often thought of, but we can not forget GIF and JPEG, DNS, TCP/IP, Perl and a host of others.

SOA standards are just a likely to mix and match standards: XML, schemas and WSDL from W3C but also registries such as UDDI and reliable messaging from WSI and the Java development community and others. Note that The Java Community Process (JCP) is every bit as open and formal WSI or W3C--they are all defacto-standards bodies.

Second, email and http are valid, open transport protocols that are not listed. In the right application stack, they can be as reliable as any asynchronous protocol. Reliability can never be solely the responsibility of the transport.  While transport can assure that one and only one package arrives for each package sent and in the order sent, transport cannot assure that the message was acknowledged and accepted in its proper sequence by the application.  True application-level reliability designs can overcome transport limitations.

 

Point 2 – Connectivity.

Among the seven ESB packages in this roundup, all but two incorporate an old-school messaging subsystem; Fiorano Software and Sonic Software are based on proprietary messaging middleware. Iona Technologies extends its legacy EAI architecture. PolarLake and FusionWare take a server-centric, connector-based approach. Only Cape Clear Software and Cordys  use a truly open and distributed SOA.

I am not sure what the reviewer intended by “server-centric, connector-based approach” if this is contrasted to “truly open and distributed SOA”.  Server-centric v. distributed seems to imply that a service can only deployed on a single server. I know most, if not all, of these products have the ability to deploy and redeploy a service on multiple servers.  If “truly open” is being contrasted with “connector-based” what is more open than SMTP and HTTP supported by the other packages?

Further reading in the article seems to imply that server-centric is a limitation and makes a product unsuitable for deployment in large shops.  As a veteran of many large IT shops, a product that helped me expose the computing assets my group was responsible for is exactly what would interest me. The features dismissed as “server-centric” are the features I would have valued.

Server-centric computing has a large role in the emergent of SOA architectures. It is an ideal solution for providers and consumers to expose their compute resources to the SOA fabric without having to incur the costs and complexity of distributed management. In my opinion, the first web explosion illustrates the market relevance of an approach that is tailored for collaboration in a truly distributed environment where each compute resource owner must expose their resource in a SOA compatible way.

* * *

In summary, I believe that InfoWorld’s analysis of the current evolution of SOA is too middleware and large-IT centric.  The Web has shown us the path to large-scale, sustainable networks. Providers provide content, consumers access and use it while network service providers attempt to be invisible. The considerable effort InfoWorld put into reviewing these products seemed to take the viewpoint of the service provider or perhaps the mega-enterprise architect who is trying to build a large complex composite application.

The review did not however, consider the needs and interests of consumers and providers. They do not want to be consumed with the cost and burden of maintaining large complex, brittle networks. They want to source or consume data to or from their application and to do so in a way that is most interoperable with others.