SOA undoubtedly represents a significant growth area for software vendors, particularly (at this early stage of deployment) for providers of software infrastructure to enable the SOA environment. However, this has attracted so many entrants to the market that there is a real problem in differentiating between products, while practical experience of implementing SOA also shows that there are many complexities to be resolved.
‘Virtual services’ is likely to be adopted as a generic buzzword, with every likelihood that the term will be so poorly defined as to be useless as a means of describing functionality (just as the term ‘enterprise service bus’ has been stretched in different directions to suit the product capabilities of many different vendors). This is a shame, because it does represent a genuine requirement.
SOA abstracts the physical properties of location, platform, programming paradigm, ownership, etc., by delivering an interface that is defined in terms of technology-neutral messages. All that is required to use a service is to send it an appropriate message. It will do its job and reply by sending another message.
This is a very effective model, but leaves a number of open ends. Particularly when conducting processes outside of the organization, messages received might be in the wrong format to be understood by the recipient. Still more challenging, the sender might be delivering a send-and-forget asynchronous message while the receiving service might be built to work in a synchronous conversation.
The security requirements and capabilities of requester and responder might be different. It might be required to route the message to one of several versions of a service to provide prioritization, load balancing, failover, etc. The underlying message protocols might be radically different, needing simple object access protocol (SOAP) over HTTP to be converted to XML over simple network management protocol (SNMP), or one of many other permutations.
All of these are examples of situations that can be fixed by plugging additional intelligence into the message delivery capability of the SOA infrastructure. The notion being described as ‘virtual services’ implies the establishing of a separate layer in the SOA infrastructure that deals with all of these transformations.
Until now, these requirements have been addressed piecemeal by specific features that have been regarded as extensions to the service bus. Different vendors have provided sets of capabilities and worked with partners to deliver the missing pieces as needed – not all implementations will need all of these features in the early stages of implementation.
What now seems to be happening is that the components that deliver the business-visible logic (the business process management, orchestration, business rules engine, etc.) are being separated out from those that simply exist to deal with the mismatch of expectations between service requester and service provider. This is a sound distinction and could be useful in removing ambiguity from product descriptions.
More importantly, delivering products in this way would provide a single place for administering the transformational operations, with the business logic being managed from a separate integrated capability. Unfortunately, most product sets are not yet built this way, and the desire to incorporate ‘best-of-breed’ functional components is likely to cause long-term difficulty in delivering this needed level of integration.
Prospective purchasers should look beyond the marketing terms and understand the specific functionality supported, and the administration and management implications of the way it is delivered.
Source: OpinionWire by Butler Group (www.butlergroup.com)