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 (EJBs) 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.
By being loosely coupled, SOA mandates that a service be invoked from any type of client, independently of its implementation language or platform. Web services or SOAP technology is one of the better ways of exposing a business service.
SOA strives for maximum reuse. 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.
As an example, a Microsoft .NET front-end application might use the J2EE back-end, exposed as a service to provide support for a business task. 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, while keeping the core business the same. Implementing the change would therefore require only modification or the creation of BPEL script, providing faster response to change.
If any of the business tasks is 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 the development itself.
While this outline describes SOA at a basic level, it may serve as a starting point for anyone who's in the process of trying to comprehend whether service-oriented architecture is applicable to their organization.B
Srikanth Seshadri is a technologist with Torry Harris Business Solutions (P) Ltd. Contact him at Srikanth_Seshadri@thbs.com
Related content:
White Paper: A Guide to SOA Implementation
SOA: It's architecture, not technology
Blocks of SOA: Building services with common symbols
Where to start SOA: Identifying the big business driver
SOA: A better ballgame with BTEP
SOA at work: Ontario's common components
icon.
