SOA - Distilled

Service Oriented Architecture or SOA is currently the most well known acronym in the software industry. But when you ask the definition of SOA to ten different people you will get ten different answers. Every organization defines SOA in its own way and there is nothing wrong their definitions. It’s very difficult to arrive at a common definition of SOA; also, the definition is immaterial if you understand the concept of SOA. This article explains the whole concept of SOA in a simplified manner.

Architecture Roadmap

The architecture roadmap started with monolithic architecture, followed by two-tier architecture and then came N-tier architectures. SOA is the next step in the architectural evolution. 

SOA is an evolution in architecture, not a revolution. SOA is not a completely new discovery; it’s an improvement over the past architectures. It captures and uses the best practices of the architectures that came before it. Like N-tier architecture, SOA is an architecture style; not a product or a project.



Applicability of SOA

Typically IT department of every enterprise has applications that can be broadly classified into Enterprise Backbone and Enterprise Front-ends. 
Enterprise Backbone comprises of all the backend systems. This includes the applications developed on J2EE, Microsoft .NET, CICS mainframes and various other technologies that contain the business logic of the enterprise. It also includes the stored procedures, data in the databases and data stored in various other formats in the enterprise. The Backbone can be considered as the combination of all the business tiers and data tiers of the enterprise. 

Enterprise front-end layer is the combination of all the presentation tiers of the enterprise. This layer includes all possible business channels of the enterprise. Business channels with front-ends – web based and desktop based; business channels without front-ends – web services, EJBs exposed to partners and clients.
Let’s consider an example of a Bank to better understand the enterprise backbone and front-end business channels. Let’s assume the Bank consists of two applications, one is a banking application developed using Microsoft .NET used by all the employees of the bank and other is a J2EE based application that deals with end-of-day batch clearance of cheques to other banks. 

The .NET based banking application is used both in the cash counter and also in ATM. As suggested by the N-tier architecture, this system will have a single business tier that caters to both the front-ends.

The J2EE based application has a web-interface for the treasury of the bank to validate the cheques and clear them. A web-service or EJB based interface is also provided for use with external banks to handle automated clearance of cheques across banks.

In this scenario, the enterprise backbone of the Bank consists of the J2EE backend and the .NET backend. The front-end business channels consist of the ATM interface and cash counter interface of the .NET application; the web based interface and the EJB interface of the J2EE applications. These are the channels through which the business is carried out by the bank.

With this understanding of the enterprise backbone and enterprise front-ends, let’s look at where SOA is applicable. 
SOA is applicable in the enterprise backbone. SOA describes a better way of organizing the enterprise backbone. It’s an architecture for the enterprise backbone.

Service-Orientation

As mentioned, SOA describes a better way of organizing the enterprise backbone. The architecture mainly provides high flexibility (faster response to change) and re-use of the existing IT assets. These two characteristics make SOA attractive to enterprises.

SOA requires the backbone to be broken up into a set of services. Each service performs a specific business task. Once the set of services are available they can be strung together to form a business process.

Let’s consider a Transfer Amount business process. This process consists of business tasks like checking the account balance for transfer, debit the source account, credit destination account and finally log the whole transaction. If each of these business tasks can be exposed as services, then the whole process can be built by connecting them in a desired order



Let’s consider a business process for withdrawal of money from the account. The tasks of checking the account balance and debiting the source account can be reused.

Essentially, SOA separates the process logic from the business logic. The business logic is made available as services. The process logic is constructed by linking these services. The procedure of linking the services to form a business process is also referred to as Orchestration. Languages like Business Process Execution Language (BPEL) are used to build the process logic. The Orchestration engines provide support for execution of BPEL thus facilitating execution of business processes.

Services

We can use BPEL to build the process logic, but how do I build a service? A service is a specific business task. The first step in building a service is to identify the services in the system. This is best done with the help of a Business Analyst (BA). BA can easily identify the reusable business tasks and also provide the granularity of the task. Such a task can be exposed as a service. In the Bank example, BA can help in determining whether the task checking account balance has to be a service or the whole transfer amount must be a service. In the latter case the transfer amount service can be part of a larger business process.
Once the service is identified the next step is to implement it. Services must be loosely coupled and autonomous. In developer terminology, a service can be compared to a static method of Java that takes as input (as parameters) all the data required for processing and returns the processed output. SOA mandates that a service can be invoked from any type of client independent of their implementation language or platform. Web-services/SOAP technology is one of the good ways of exposing a business service.

SOA Benefits

SOA strive for maximum re-use. The existing business logic can be exposed as services by writing wrappers around them; thus making the business logic available for various systems in the heterogeneous environment. If we consider the Bank example again, the Microsoft .NET front-end application can use the J2EE backend, exposed as service, to provide support for external cheque clearance facility for the employees of the bank.
The separation process logic from business logic makes the system more flexible. Most of the business changes are related to process logic rather than business logic. More often than not, new processes are introduced or existing processes modified keeping the core business the same; so implementing the change would warrant just modification/creation of the BPEL script, providing faster response to change.
If any of the business tasks are missing, only the service containing that business logic has to be developed and tested. Hence, this architecture supports incremental development from the very foundation; reducing the overall risk, cost of change and development itself.

Conclusion

This article describes the SOA at a basic level. However, it can serve as a good start to anyone who is in the process of comprehending Service Oriented architecture.