Some technical stuff on it

My other post on SOA briefs you what SOA is all about in a very generic, real life scenario.

Now, lets talk some technical stuff here.

There's no standard definition for SOA, it is just a methodology followed, and each one has his own definition for it. The best I feel is

SOA is an architectural style of building business applications using loosely coupled services, that act like black boxes, that can be orchestrated in a particular fashion to attain a specific business functionality.

SOA aims at a greater alignment between your business and IT infrastructure.

For a service to be a candidate in a SOA Application, it has to adhere to certain principles, otherwise called SOA Principles

Below are the principles each individual candidate in a SOA Application has to satisfy, as defined by Thomas Earl

1. Standardized service contract – Services adhere to a communications agreement, as defined collectively by one or more service-description documents. Services express their purpose and capabilities via a service contract. The Standardized Service Contract design principle is perhaps the most fundamental part of service-orientation

2. Service Loose Coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.

3. Service Abstraction – Beyond descriptions in the service contract, services hide logic from the outside world. This principle emphasizes the need to hide as much of the underlying details of a service as possible.

4. Service reusability – Logic is divided into services with the intention of promoting reuse. The principle of Service Reusability emphasizes the positioning of services as enterprise resources with agnostic functional contexts.

5. Service autonomy – Services have control over the logic they encapsulate. significant degree of control over its environment and resources.

6. Service statelessness - Services minimize resource consumption by deferring the management of state information when necessary

7. Service discoverability – Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted. For services to be positioned as IT assets with repeatable ROI they need to be easily identified and understood when opportunities for reuse present themselves.

8. Service Composability – Services are effective composition participants, regardless of the size and complexity of the composition.

Any technology component that adheres to all these principles would be a candidate to be used in SOA, and the best software component that we could think of that satisfy all these features is a Webservice, and morevoer it is highly evolved, widely supported, and more that anything, ease of use. It has become the defacto standard for realizing SOA.

 The main goal of SOA is to connect disparate systems. In order that these disparate system work they should talk to each other seamlessly. SOA gives it a way of doing it thru ESB (Enterprise service bus) that acts like a reliable post office which guarantees delivery of messages between systems in a loosely coupled manner.

By organizing the enterprise IT around services instead of around applications, SOA helps companies to achieve faster time-to-service and respond more flexibly to fast-paced changes in business requirements.

It aims at building systems that are extendible, flexible and fit with legacy systems.

Hope this gave you a better understanding of SOA and its principles. My next post aims at introducing you to the Service Component Architecture which realizes all the SOA principles

Thanks for going through my post, feel free to provide a feedback!