What Is SOA Anyway: Part IV, SOA Defined

To be able to converge between the technical and business viewpoints, we first need to differentiate between an architectural style and its application. Once we define what SOA is, we can apply it at an organization level to get an SOA initiative where services will encapsulate business function. However, we can also apply SOA on a single project and get services whose content revolves around technical issues, such as security or management.

We also need to differentiate between design goals such as loose coupling or business alignment and architectural building blocks and constraints like coarse-grained services or policy-based interactions.

Lastly, if we look at definitions of other architectural styles like Client/Server, Layered, or REST we can see that we can see that architectural styles are defined in terms of components, their attributes, their relations and the rules or constraints that govern them.

Based on that we can define Service-Oriented Architecture as an architectural style for building systems based on interacting coarse grained autonomous components called services. Each service expose processes and behavior through contracts, which are composed of messages at discoverable addresses called endpoints. Service's behavior is governed by policies which are set externally to the service itself. you can see the SOA componets and their relations in this diagram.

Let's take a look at each of these components (excerpted from my upcoming SOA Patterns book).

Service. The central pillar of SOA is the service. Merriam Webster defines service as "a facility supplying some public demand". A Service should provide a high cohesion and distinct function. Services should be coarse grained pieces of logic. A Service should implement at least all the functionality promised by the contracts it exposes. One of the characteristics of services is service autonomy. Autonomy means the services should be self-sufficient, at least to some extent, and manifest self healing properties.

Contract. The collection of all the messages supported by the Service is collectively known as the service's contract. The contract can be unilateral, meaning a closed set of messages the service chooses to provide. A contract might also be multilateral or bilateral, that is, between a predefined group of parties. The contract can be considered the interface of the Service akin to interfaces of object in object-oriented languages.

Endpoint. The Endpoint is an address, a URI, a specific place where the service can be found and consumed. A specific contract can be exposed at a specific endpoint.

Messages. The unit of communication in SOA is the message. Messages can come in different forms and shapes; for instance, http GET messages (part of the REST style), SOAP messages, JMS messages,and even SMTP messages are all valid message forms. The differentiator between a message and other forms of communication such as plain RPC, is that messages have both a header and a body. The header is usually more generic and can be understood by infrastructure and framework components without understanding, and consequently coupling to, every message type. The existence of the header allows for infrastructure components to route reply messages (e.g. correlated messages pattern) or handle security better (see Firewall pattern).

Policy. One important differentiator between Object Orientation or Component Orientation and SOA is the existence of policy. If an interface or contract in SOA lingo, separates specification from implementation. Policy separates dynamic specification from static/semantic specification. Policy represents the conditions for the semantic specification availability for service consumers. The unique aspects of policy are that it can be updated in run-time and that it is externalized from the business logic. The Policy specify dynamic properties like security (encryption, authentication, Id etc.) , auditing, SLA etc.

Service Consumer. A service doesn't mean much if there isn't someone/something in the world that uses it. So to complete the SOA picture we need Service Consumers. A service consumer is any software that interacts with a service by exchanging messages with the service. Consumers can be either client applications or other "neighboring" services their only requirement is that they bind to an SOA contract.

Posted by Arnon Rotem-Gal-Oz at 03:07 AM  Permalink