Service-oriented architecture, or SOA, is a well-known acronym in the software industry. SOA has made quite a long journey from being a buzzword to being put into practice to solve enterprise business problems. Yet, arriving at a common definition of SOA is not easy. This article too does not aim to define SOA, but explains the concept of SOA. Understanding the concept is good enough to get a quick start on SOA and its applicability.

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, the 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.

The 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 include those that are Web-based and desktop-based, and business channels without front-ends include Web services and 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 the other is a J2EE-based application that deals with end-of-day batch clearance of checks 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 checks and clear them. A Web service- or EJB-based interface also is provided for use with external banks to handle automated clearance of checks 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, debiting the source account, credit destination account and, finally, logging 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. Business analysts 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, an analyst 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 its 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 check clearance facility for the employees of the bank.

The separation of 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 and cost of change, as well as development itself.