SOA Link - Half Full or Half Empty?

SOA Link - Half Full or Half Empty?

A group of vendors have recently announced service oriented architecture SOA Link which they describe as an “an end-to-end service oriented architectureSOA Governance Interoperability Initiative.”

I presented a session on SOA Governance at the recent OMG SOA service oriented architecture, MDA and Web Services Workshop. In the presentation I highlighted the challenge of governance in the Service lifecycle when potentially so many different tools are involved in the end-to-end process. For example, the complete set of meta data that specifies the service might be dispersed to several products, across different stages of the lifecycle.

The figure below (which can be expanded) illustrates that

Changing state may mean moving from tool to tool and changing level of abstraction
Service is defined in many different tools. How is consistency of specification maintained? How is the compliance with the specification checked?
How can Policies be applied across different tools? Policies may be defined in a tool specific mechanism. How is compliance maintained?

This isn’t a new problem per se, but traditional configuration management approaches do not address new requirements raised by service oriented architecture SOA, and CM tools may not even recognize Service as an asset type – at least not at all levels of abstraction or in terms of all of the artefacts that might be part of the Service Specification or related to it.

The service oriented architecture SOA Link ought therefore to be a timely announcement. It should be recognized though that this is not a standards group. Rather, it is just a commitment by the various vendors involved to provide interoperability between their respective products. However, because they will not be developing formal interoperability standards it is likely that there will be different links between different products

You can view this as the glass being half full or half empty. Clearly there is a need to start somewhere and this is a step forward in addressing what will be a genuine issue as organizations increase their service oriented architecture SOA maturity. On the other hand the lack of focus on interoperability standards sounds like it may result in a spaghetti of point-to-point interfaces.

According to Infravio the prime vendor behind service oriented architecture SOA Link there will be 3 levels of link that will be shown in the catalogue they will be publishing.

At the lowest level is just the publication by the vendor of the link.
At the secont level the vendors will provide additional such as use cases, etc
At the strongest level the link will show validation by customers
An acid test will be the extent to which the group actually applies service oriented architecture SOA to the problem. If all that results from the initiative is a bunch of proprietary file transfer mechanisms that tightly couple one product to another then it will be of limited usefulness, yet alone contrary to the spirit of service oriented architecture SOA service oriented architecture. If on the other, it prompts some of the vendors to publish proper Service Interfaces with well defined schemas this will be more useful. If those Services can go on to become de facto standards, or submitted to a standards body for further refinement and approval then so much the better.