Service-Oriented Architecture ( SOA )

Service-Oriented Architecture ( SOA )

Introduction:

In today’s technology-driven world with globalization, rapid business changes and with ever growing challenges posed by integration between globally distributed systems , there is a strong need to ‘loosely couple software systems’ to enable everyone to use them without dealing with issues concerning the platform and the language the systems are written in.

‘Service-Oriented Architecture’ makes this possible by integrating services provided by service-providers, with a system at the consumer-end that needs to avail those services. SOA is not simply a set of services. SOA is the policies, frameworks, and practices under which the correct services are provided.

SOA and Web Services - An Analysis

A common misconception about SOA is that using web-services technology makes whatever you are using SOA. The core reason for that is the poor naming choice for methods that are exposed through http which were named web-services. For example one of the popular books on SOA “Service oriented Technologies: a Field guide to integrating XML and Web-Services” by Thomas Earl gives the impression that SOA equals WS* (even though that buried in the book, there’s an explanation hat WS* is not the only possible technology for SOA). There are many other sources that give the same impression.


Nevertheless, Just a bunch of web-services (JBOWS as Joe McKinderik named them) does not an SOA make – in fact thatisn’t really different from Remote Procedure Calls (RPC) using any other technology be that CORBA, DCOM or anything else. The way I see it saying that SOA is using web-services is just plainly wrong and not away to define SOA.

One could argue that web services was the first step on the road to SOA. Is that statement true?
Yes and No.
No, in that you can have an SOA solution without using ASP.NET web services.
Yes, in that it is a great beginning to something much larger.

It is possible to have a web service that follows no SOA principles and a web service that exhibits wonderful SOA traits.

For example, a good web service is almost self-describing, providing useful information. I want to hit a web service that gives me stock quotes, or lets me buy or sell stocks, or tells me how my portfolio is doing.

In the case of the book publisher, I want a web service that tells me information about my order. These are web services that exhibit SOA traits.

Service Oriented architecture:

At the enterprise architecture level, it is always about the business. This is not a bad thing, on the contrary, the enterprise architecture perspective should be focused on the business needs in order to make sure IT serves the business and not vice versa.

The emphasis from the business perspective is on “service orientation”.

Consider for example the SOA definition from Service-Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology - Eric A. Marks, Michael Bell :

“SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network.

“Services” in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages.”

In a nutshell, they can be summarized as follows:

“from the business point of view SOA is about analyzing the business to identify business areas and business processes. Followed by defining services to represent these “areas” .

Services expose their capabilities through message interfaces. The services can then be choreographed or orchestrated to realize the business processes.

While the on the business side of the fence the emphasis is on” Service Orientation” or SO - on the technical front the emphasis is on the A of SOA – Architecture.

True, there isn’t a single unified definition for SOA; however, just like the many definitions of software architecture, there are several characteristics that are more common and frequent than others.
Looking at definitions of SOA such as the ones from Wikipedia, O’reily’s, JavaWorld , Windley, Microsoft etc. you can see that

SOA is commonly thought of as an architecture or an architecture style that builds on loosely coupled, interoperable and composable components or software agents called services.

Services have well-defined interfaces based standard protocols (usually web-services but most definitions mention that it is not the only possible implementation) as well as QoS attributes (or policies) on how these interfaces can be used by Service Consumers.

The W3C defines Service-Oriented Architecture as "A set of components which can be invoked and whose interface descriptions can be discovered and published"

The goal of SOA is to increase the alignment between business and IT and
achieve business agility – the ability to respond to changes quickly and efficiency.

 
 
 
 
 
 
 
 
 
Service: The central pillar of SOA is the service. Merriam Webster defines service as “a facility supplying some public demand”.

Contract: The collection of all the messages supported by the Service is collectively known as the service's contract.

End Point: 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.

 Message: 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 to handle security better.

 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-Oriented Architecture Principles:

Streams of information have been flowing from Microsoft in the forms of articles and white papers regarding its commitment to SOA, and in all of this information one of the big areas constantly stressed are the principles behind service orientation:

Explicit boundaries: Explicit boundaries mean that a service can be deployed anywhere and be easily and freely accessed by other services, regardless of the environment or development language of the other service.

Services communicate by sending messages across their boundary

All Communication occurs through messages

Autonomous services: This SOA principle states that each service must be managed and versioned differently so as to not affect other services in the process.

You can change a service without affecting client as long as clients can continue sending and receiving the same messages.

Policy-based compatibility: Policies also allow you to move a service from one environment to another without changing the behavior of the service.

Services can define the circumstances under which clients can communicate with them.

Shared schemas and contracts: " The contract contains information regarding the structure of the message. Services do not pass classes and types; they pass schemas and contracts. This allows for a loosely coupled system where the service does not care what type of environment the other service is executing on.

Contacts describe the messages services can send and receive.

Schemas define how the client and service construct the messages they exchange