SOA Future
SOA: The Past
It is often asked as to why haven’t people been using SOA for the last twenty years? As far as SOA is concerned, in order to build a system out of parts, you require a standard method of representing software parts. If no such standard exists, then building such a system can become incredibly difficult.
Though Service Oriented Architecture is not exactly a new thing, Businesses have spent the last fifteen years trying to come up with a set standard. While CORBA and DCOM have been in existence for a while, they never became worldwide standards.
Internet has set up standards in more than one way viz., HTTP and HTML, which link together people all over the globe. Businesses witnessing the growth and the development of the Internet decided to use similar strategies to link their own computer systems together.
Such Businesses first came up with Web services standards which were based on technologies that originated on the Internet and made use of technologies such as XML and HTTP as a means for representing software parts and linking together a number of different computer systems.
There has been an adoption of web services as the standards to base Service Oriented Architecture. Software vendors such as webMethods have brought out a variety of products onto the market that have made Service Oriented Architecture quite useful.
SOA: The Future
In recent years there have been meaningful debate on what standards Service Oriented Architecture should be based upon in order to optimize functionality in future scenarios.
Researchers have found that there is an obvious pattern to first time Service Oriented Architecture implementations. Applications that are currently being used by an organization will be wrapped up and then plugged into a service bus. Then, perhaps a registry will be added as a means of enabling service discovery.
There may very well be instrumentation for the monitoring of performance. Generally all these functions perfectly, but there has not been much of a change made to the underlying enterprise architecture – it is now being expressed using a different language, that of Service Oriented Architecture.
The main organizational value of Service Oriented Architecture lays in its deliverance of enterprise agility. A Business should not try to change this aspect of the architecture. The main corporate Business of Service Oriented Architecture lies in the fact that its service reconfiguration is flexible. Changes can be completed in a period of a few days by business people, whereas before it took weeks for changes to be made by specialists in the field of technology. Yet this also infers that technical and business architectures have to be aligned.
In today’s world, however, this tends not to be the case in the vast majority of businesses. It is not enough to express existing application architecture in terms of Service Oriented Architecture. The services themselves have to be oriented towards Business if you expect Business people to orchestrate them.
First time usage of Service Oriented Architecture tends to highlight the need for semantic interoperability. While Service Oriented Architecture might provide the framework for the integration of cross business operations with information flow in real time as required by developments in the modern day oil industry, there is also a major semantic interoperability conflict that is not being addressed directly by the Service Oriented Architecture. Thus, the usage of information repositories has been the inevitable result.
It must be said that the vast majority of implementers of Service Oriented Architecture 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. They will fit perfectly in to the fabric of Service Oriented Architecture 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, 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.
