SOA Industry Usage

First time usage of SOA tends to highlight the need for semantic interoperability.  While SOA provides framework for integration of cross Business operations with information flow in real time, there is also a major semantic interoperability conflict that is not being addressed directly by the SOA. Thus, the usage of information repositories has been the inevitable result. 

It must be said that the vast majority of implementers of SOA are still in the first, wrapping stage.  It would be great if we were in a period when legacy applications have been integrated. It is hoped that within the next couple of years, applications will be able to communicate with web services in a native fashion, and will also be able to deliver industry specific functionality in a native fashion. Such a new breed of services would be very different from the monoliths that are typically used in today’s Business environment. Granular Business functions will be delivered that fits perfectly into the fabric of SOA standards in a way that can be orchestrated by Business-oriented individuals as a means of delivering enterprise wide agility.

Will such a standards fabric resemble?

It will have to cover five separate areas:

• The services bus,
• The registry or repository,
• Event handling,
• Policy, and
• Instrumentation.

The standards will be expected to address the semantic level, in addition to the syntax and the protocol.

The Service Bus

Services bus is like basic communications channel that allows services to be inter-connected within SOA. While service bus may resemble one gigantic thing that everything else is expected to plug into, it is a lot more complex than that.  An enterprise services bus breaks down into a variety of different components.  The contemporary trend is to transform these components into plug and play, with an interoperability that spans numerous vendors. This is what customers are looking for – interoperability via standards.

The Registry

Registry can be viewed as a control center in which descriptions of services are stored that enables run time discovery.  In modern day usage, its contents tend to be rather primitive. Most Businesses simply want to define what a particular service is, as well as how to describe it and organize it. But when a Business moves to SOA, different relationships become exposed, such as that between the consumer and the producer, the schemas and the service, and between the services and Business process. The enterprise has to manage all these relationships – if it does not, then it will be unable to cope with any changes that take place.  A registry thus helps to define such services. It does not, however, describe relationships.  It is for this reason that a lot of people believe enterprises need to undergo a transition to repositories, which are able to store a wider range of semantic data, or to the Semantic Web.

Event Handling

Event handling middleware enables the outside world to connect with the infrastructure of the service.  It provides real time response and input.  Such a connection can be developed via an event driven architecture that interfaces to sensors and telemetry while providing aggregation, correlation, filtering, as well as complex event processing. EDA is sometimes viewed as a competitor to SOA, but in actuality the two compliment one another.  It is predicted that in the future, event processing will play a bigger role – if today is the era of services, then an era of events is soon to follow.

Instrumentation

If a Business is going to adapt its IT infrastructure via service orchestration, it would require data about what the infrastructure is doing and how it performs.  Instrumentation provides this feature.  This is one of the great benefits of SOA.  It provides the capability of management dashboards.  At the semantic level, standardization is required in order to enable the design of generic dashboards that will instrument both infrastructure and Business oriented services.

Policy

Policies can be thought of as the means by which design time decisions about such facets as service levels and security may be enforced in a run time environment.  For the agility of an enterprise, a policy’s definition must be kept separate from its implementation, so that the user is not required to understand the underlying technology. Standard policy formats must be developed, with composite policies to be enforced and interpreted by intermediaries in the management.  The main issue at stake for this future task is how management policies will be enabled for multi product and multi vendor type implementations.

Next Page: The Key to SOA Functionality