Skip Links

SOA: Understanding the architecture

By Srikanth Seshadri, CIO
August 08, 2007 09:35 AM ET
  • Print

Service-oriented architecture or SOA is an architecture style, not a product or a project. It's an improvement over past architectures in that it captures and uses the best practices of the architectures that came before it. As such, SOA is an evolution in architecture, not a revolution.

Typically the IT department of every organization has applications that can be broadly classified into a back-end and a front-end. The back-end can be considered as the combination of all the business tiers and data tiers of the organization. The front-end layer is the combination of all the presentation tiers.

IT's back-end comprises all the applications developed on J2EE, Microsoft .NET, CICS mainframes and various other technologies that contain the business logic of the organization. It also includes the stored procedures, data in the databases or in various other formats.

The front-end includes all possible business channels, whether Web-based or on the desktop, Web services or Enterprise JavaBeans (EJB) exposed to partners and clients.

SOA comes to play in the back-end. It's an architecture for the organization's backbone. SOA describes a better way of organizing the back-end, providing mainly high flexibility (faster response to change) and the reuse of existing IT assets. These two characteristics are what make SOA most attractive as an enterprise architecture.

For SOA to work, the back-end must be broken up into a set of services. Each service performs a specific business task. Once the services comprising a set are identified, they can be strung together to form a business process.

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 the execution of business processes.

We can use BPEL to build the process logic, but how do we build a service? A service is a specific business task. The first step in building a service is to identify the desired services within the system. A business analyst should identify the reusable business tasks and also provide the granularity of the task. Such a task can be exposed as a service.

In a bank, for example, business analysis can help to determine whether the task of checking an account balance should be a service or whether a cash transfer should be a service. In the latter case, the transfer amount service could be part of a larger business process.

Once the service is identified, the next step would be to implement it. A service must be both loosely coupled and autonomous. In systems developer terms, 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.

  • Print

Videos

rssRss Feed