SOA Definitions and Certification

Service Oriented Architecture is a design that enables Business and computational resources to be linked together on demand as a means of achieving the results desired for service consumers – which may be end users or other services. Service Oriented Architecture has been defined by the Organization for the Advancement of Structured Information Standards as a paradigmatic approach for the utilization and organization of distributed capabilities that might be under the control of conflicting ownership domains.

Service Oriented Architecture provides a single means of offering, interacting, discovering and using different capabilities to produce the effects that are desired and consistent with measurable expectations and preconditions. Of course, there are a number of different definitions of Service Oriented Architecture. To an extent, it depends on how you wish to employ it and or view it. The more open definitions, however, take into consideration the fact that Service Oriented Architecture very well might be applied to Business domains and technological entities.

While some definitions of Service Oriented Architecture limit themselves to technology or web services, this sort of limitation is typically enforced by technology vendors. In the year 2003, for example, the talk regarding SOA revolved mainly around Internet services, while in the year 2006, the talk revolved mainly around process engines and events.

Most Recent SOA Definition

As of the year 2007, service oriented architecture is viewed by industry professionals as an underlying structure that supports communications among different services. In such a context, a service can be thought of as a unit of work that is performed on behalf of some form of computer entity, which might be a human user or another program.

Service Oriented Architecture is now viewed as a method for two separate computer entities, such as programs, to interact in a way that enables one of those entities to perform a unit of work on behalf of the other entity it is connected to. Service interactions are viewed through the utilization of a description language. Every interaction is self contained and coupled loosely, enabling every interaction to be independent of any other interaction.

Simple Object Access Protocol, or SOAP based web services have evolved as the most common SOA implementation. There are, however, non web service implementations that exist that provide similar benefits. Service Oriented Architecture’s protocol independence thus means that consumers can communicate with the service in a variety of ways. In an ideal set up, there should be a management layer that is situated between protocols and consumers as a method for ensuring total flexibility in terms of implementation protocols.

Whether you are aware of it or not, you have most likely come in to contact with Service Oriented Architecture – most likely when you made an online purchase.

Researchers have found that there is an obvious pattern to first time SOA implementations.  Applications that are currently being used by an organization will be wrapped up and then plugged in to 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. 

All these functions perfectly generally, but there has not been much of a change made to the underlying enterprise architecture – it is now just being expressed using a different language, that of Service Oriented Architecture.  Of course the main organizational value of Service Oriented Architecture lays in its deliverance of enterprise agility. When a Business tries to change this aspect of the architecture, then a crunch comes.

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.