Tutorials SOAIt will have to cover five separate areas: the services bus, event handling, the registry or repository, policy, and instrumentation. The standards will be expected to address the semantic level, in addition to the syntax and the protocol.
The services bus can be thought of as the basic communications channel that allows services to be interconnected within Service Oriented Architecture. While it may resemble one gigantic thing that everything else is expected to plug in to, it is a lot more complex than that. An enterprise services bus breaks down in to a variety of different components.
The contemporary trend is to transform these components in to plug and play, with an interoperability that spans numerous vendors. This is what customers are looking for – interoperability via standards.
Descriptions of services are stored in the registry. This enables run time discovery. The registry can be viewed as the orchestration’s control center. In modern day usage, its contents tend to be rather primitive. Most businesses in today’s day and age 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 Service Oriented Architecture, 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 that 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 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.
Event Driven Architecture is sometimes viewed as a competitor to Service Oriented Architecture, 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.
Were a business to adapt its Information Technology infrastructure via service orchestration, it would need data about what the infrastructure is doing and how it performs. Instrumentation provides this feature. This is one of the great benefits of Service Oriented Architecture, actually – the ease of instrumentation. 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.
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.
Service Oriented Architecture must be standardized in the following arenas in order to fulfill its promises – services bus, event handling, policy, repository, and instrumentation. The fact remains that a single vendor environment is just not healthy. Standards must emerge to serve as the equalizer.
But standards on their own will not be enough. They must then be used in order to meet the goals of a business. The business architecture is the fundamental architecture in any SOA situation. It provides the services and the means to codify business processes as services. In other words, the architecture of the future will not be up to the standards of good technology. Rather, it will be wholly contingent on there being good architects to provide the needed services.
First Page: SOA Future
