Service Oriented Architecture

Problem :

In todays business environment, where customer requirements and demands are changing frequently and businesses are operating in heterogeneous markets, business process automation requirements are becoming more complex and new changes to business processes are coming so frequently. Business are asking for software systems which are highly integrated, easy to modify , highly scalable and customizable so that the changes to business processes and requirements can be accommodated easily with less cost and efforts.

To achieve all these business need, software systems has to be highly modular, business functionality from different business units should be divided into distributed components and these components should be accessible in location transparent way and should be highly interoperable.  System components should be deployed across process and machine to deal with performance bottleneck, to introduce security boundary and to facilitate enterprise level reuse.

Question is how do we do it?

Here, Service Oriented Architecture Comes as rescue. SOA is an architectural style or I would say a reference architecture which guides architects on, how they should decompose business functionality into components and how does the functionality of these components is available to other components. SOA brings the concepts of public contracts, policies and interoperability. Because of these concepts, system components can communicate with each other without worrying about the technology, other component has been implemented.  SOA also posses some constraints on component design and the design of communication links between components.

What is Service?

The term service has different meaning at different level of abstractions. At system architecture level, service is a business functionality which is distributable and is accessible to consume in some way.  It is a window through which business functionality cab be reached. 

Consider the application architecture in Following figure. The client application represents an Agency Management

System that includes many chunks of business functionality such as Certificate Issuance, General Ledger, CRM, and Reporting. The client application coordinates access to these features by consuming business components directly. In

this case, components are not distributable in such a way that they can be location transparent, thus they are not services.

 

So how do you implement a service in SOA?

You expose your system components as serviced components using different distributed technologies. Some of the technologies you can use are : Enterprise Services, a .NET Remoting component, an ASMX web service , or a WCF service. Any of these technologies can be useful in exposing the business logic in such a way that the client can reach that functionality at remote locations in a distributed environment, without communicating directly with the business

components.

Following is an updated diagram of Agency Management System. Here each business functionality is exposed using one of the distributed technologies. Serviced components are reached using DCOM over TCP,.NET Remoting components via RPC over TCP,ASMX web services via SOAP over HTTP, and WCF services via SOAP over any protocol.

The point is that services are not necessarily web services—they are merely chunks of business functionality exposed in some way such that they respect the tenets of SOA.

Some of the constraints SOA poses on serviced components

1. Service boundaries are explicit : Services are responsible for exposing a specific set of business functionality through a well-defined contract, where the contract describes a set of concrete operations and messages supported by the service. Services completely encapsulate the coordination of calls to business components in response to operations it exposes to clients. Implementation details behind the service are unknown to clients so that any technology platform could be invoked behind the service without impact to the client. In addition, the location of the service isn’t important to the client as long as the client knows where to reach it. All the distributed technologies provide a way to expose your system components by following this constraint.

2. Services are autonomous : Services encapsulate business functionality, but they must also encapsulate other dependencies of the business tier. In this way the entire service should be moveable or even replaceable without impact to other services or system functionality. A service represents a major chunk of business functionality that owns its own business components, data access components and data storage if applicable. It should be able to perform key functions without external dependencies. This is what is meant by atomicity.

3. Clients and services share contracts, not code : As service boundaries are explicit, Contracts are used to define this boundary to client application. The contract must not change once published, or must at a minimum remain backward compatible to existing clients.

4. Compatibility is based upon policy: While contracts describe the business functionality available at a service boundary, policy describes other constraints, such as communication protocols, security requirements, and reliability requirements.

If the above information is useful, Please provide your valuable feedback.

Thanks.