An Overview of SOA
What is SOA?
SOA or Service Oriented Architecture can be defined as an Architectural design style
and principles that enable the integration of enterprise applications as linked loosely
coupled services. The services can be existing legacy applications modules that are
wrapped and exposed as web services or newly developed J2EE or .NET Web
services components. Linkage of services is done by a BPEL composite application1
deployed as part of an Enterprise Service Bus, ESB. The services collaborate with
each other to accomplish business tasks by exchanging well formatted messages via
To illustrate this concept with a very simple example, consider a travel agency (TA)
that provides hotels and flights booking services to its customers. SOA can be used to
architect the back end system of the TA business information system as shown in the
The SOA design style provides us with the capability to reuse services components
across multiple business processes. For example, the “check credit service” above can
be used for the flight booking and the hotel booking business processes. Also, since
the services are loosely coupled, new services can be quickly added to the system or
old services easily replaced with new ones. This enables a quick response to changes
in business requirements while at the same time reducing the cost of IT developments.
SOA Design Styles and Principles
The key ideas behind the SOA design style and principles can be summaries in the
following four axioms
Business is can be expressed as a collection of processes.
Processes can be implemented as services.
Processes change over time and the systems that supports them need to be
flexible enough to support the agile nature of processes. That is services need
to be loosely coupled, location transparent, interoperable and compos-able.
The return of investment (ROI) of an SOA implementation should be reflected
in the key performance indicators (KPI) of the Business it supports. Hence the
need of SOA governance.
From the business perspective SOA is not only an IT architectural design style and
principles that enables the implementation and orchestration of loosely couple
A composite application integrates the services in an SOA by orchestrating business processes. It can
be built using BPEL.
business services, but also a long term strategic business oriented IT discipline that
provide a flexible IT environment for business innovations.
Types of SOA Business Service
Within an SOA governance boundary, there are usually three broad categories, by
granularity, of business services. These are (a) Atomic services, (b) composite
services, and (c) process services.
Atomic services represent most granular form of SOA services. They are usually
implemented using a programming language like java or C# and expose as web
services. The implementation of atomic services is self-contained in that it does not
invoke other services. Atomic services exist in two main forms (i) services that
implement new business logics (new services) ,(ii) services that wrap existing legacy
applications API (adapter services).
These are usually more granular than atomic services. They are built by combining
two or more atomic services or other composite services. This can be done by
directly referencing the constituent services or by using some form of dependency
injection that auto wire constituent services are runtime. Sequence languages like
BPEL can also be used but are not required. The composite services abstract and hide
the interfaces of its constituent services. That is the consumer of a composite service
is not aware (and need not be aware) that the provider is a composite.
These services orchestrate business processes or sub business processes. They do this
by defining the sequence of messages flow across the services that implement the
activities within the process. Process services are usually implemented using a
sequence language like BPEL and deploy on a runtime BPEL Service Engine. Process
services can also be view as special case of composite services backed by a business
process. Figure 1 shows how these services fit with the SOA central middleware,
the Enterprise Service Bus (ESB).
1 Type of SOA Business Services
Figure 2.1 Type of SOA Business Services
The position of the BPEL Service Engine may differ from one SOA infrastructure
products suite to another. Some products deploy the Service Engine and the ESB
as two separate products, while others have the two deployed as parts of single
product. For example, OpenESB deploy the Service Engine and the ESB as single
product built on top of java business integration JBI framework.
When to use SOA
The implementation of SOA solutions requires huge investment in infrastructure
products such as enterprise service Bus ESB middle way and application serves in
others to avoid this huge upfront cost SOA implementation should an incremental
strategy. The initial face should reflect the companies long term IT vision. However
the solution should be tackled on project by project bases which means that the
company move forward with its SOA implementation gradually as it rips the benefits
of previous implementation.
Not all it projects require an SOA approach. Usually SOA can be applied in following
(i) When there is a need to integrate enterprise wide business applications. This
usually done in order to provide consistent data across the enterprise and to
automate the company business process.
(ii) SOA is good for enterprise solutions that involve long running business
processes such as order to cash process. Which involves validating customer
orders CRM system, checking inventory level (inventory management system,
billing customer, SAP finance system).
(iii) SOA is also excellent for automating agile business processes. For example
in the telecommunication industry where the services provided to the
customers change very frequently. An SOA approach to the service delivery
platform implementation will provide the company with the flexibility it
needs to provide value added bundle services to its customers.
(iv) SOA is also good for enterprise application integration involving a lot of
legacy application. This is because the SOA design style and principles
unable us to wrapped and expose legacy applications into services. In such
situations SOA might not be the right approach this includes.
This involve building of one standalone simple web applications.
When speed is the most important factor, SOA might be not the right
approach this is because SOA involves the use of open standards technologies
like web services which may be slow in such case proprietary standards may
Benefits of SOA
Most businesses are built with assumption that the business will continue to provide
revenue over a long period of time, the focus is on operations. However, the market
by nature is discontinuous. It forces the creation and destruction of services over time.
Companies that have a flexible information system response quickly to changes in the
market forces, they catch the train and earned visible business values. SOA design
style transforms a company’s information system from being merely one of the “cost
of doing business” to a fundamental tool for enabling the company to be more
competitive, profitable, and agile.
For IT, the following benefits can be obtained from and SOA implementation
Services are built once and use many times
New service (coarse grain services) can be created from existing services (fine
Services are built by contract
SOA promote consistent processes and tools across the organization
Allow for localization of functions and standardization of cross-cutting
Standardized integration and reduce solution complexity
To the business, the following benefits can be obtain from an SOA implementation
Increase in response to changes in business requirements. That is agility
Ability to easily transcend organization boundaries
Reduces new products or services development time and cost
Exposes commodities in business processes as services
The figure below shows results of the research conducted by IBM on 35 SOA projects
Figure 2 Reported SOA Benefits
In the figure above, 100% of the companies involved reported an increase in
flexibility brought about by SOA implementation. This confirms SOA as the key
technology for enabling agile business.
Return of Investment (ROI) for SOA as other IT investment is somehow difficult to
quantify, however, companies have seen the ROI for SOA reflected indirectly in their
business in terms of improve flexibility, decrease in operational cost, reduce risk,
increase revenue, ease of new products development, and increase in Quality of