Service Oriented Architecture
Pratidnya S. Hegde Patil
1. Service-Oriented Architecture (SOA): Concepts, Technology, and
by Thomas Erl
1. Service Oriented Architecture (SOA) For Dummies, 2nd Edition
by Judith Hurwitz, Robin Bloor, Marcia Kaufman, Fern Halper
2. Service-Oriented Architecture: A Field Guide to Integrating XML
and Web Services (The Prentice Hall Service-Oriented Computing
Series from Thomas Erl)
by Thomas Erl
3. SOA Using Java Web Services by Mark D. Hansen
A CD Player Example
Take a CD for instance. If you want to
play it, you put your CD into a CD player
and the player plays it for you. The CD
player offers a CD playing service. Which
is nice because you can replace one CD
player with another. You can play the
same CD on a portable player or on your
expensive stereo. They both offer the
same CD playing service, but the quality
of service is different.
Put Another Way
How would you rather pay the bill for your paper
The paperboy comes to the door, demands $2 for
that week's paper. Do you...
1) Tell the paper boy where your wallet is, turn
around to let the paperboy get your wallet out of
your back pocket, he pulls $2 out of your wallet,
closes it, puts it back in your pocket.
2) Give him $2.
What Does that Mean?
SOA is built on loose-coupling. How do you do
Tell objects what to do, don't ask them for their
Clients want the $2--the paper boy doesn't care if
it's in your cookie jar or your wallet or in a check
or quarters or a $2 bill or 2 singles
Systems are the same--objects are microcosms
Queries must be free of side effects: Either
Command OR Query--not both!
Decoupling is a Good Thing! 5
Focus on the Business– Process and Services
business service layer
.NET J2EE Legacy 6
Source: Service-Oriented Architecture, Thomas Erl
What are Services?
Bank tellers provide services to bank customers.
Different tellers may offer different services, and some
tellers may be specifically trained to provide certain types
of services to the customer.
Typical services include:
Account management (opening and closing accounts).
Loans (application processing, inquiries about terms and
conditions, accepting payments).
Withdrawals, deposits, and transfers.
Foreign currency exchange.
Several tellers may offer the same set of services to
provide load balancing and high availability.
What happens behind the counter does not matter to the
customer, as long as the service is completed.
Processing a complex transaction may require the customer
to visit several tellers and therefore implement a business
Behind the counter are the IT systems that automate the
The services are provided to the customer via the tellers.
The services implemented by the IT systems must match
and support the services provided by the tellers.
A consistent approach to defining services on the IT
systems that align with business functions and processes
makes it easier for the IT systems to support the goals of
the business and adapt more easily to providing the same
service through humans, ATMs, and over the Web.
The same service can be accessed from customers at the
ATM, tellers on the office network, or Web users from their
PCs. The services are designed and deployed to match the
services that customers need.
The implementation environments for the services don’t
matter; it’s the service that’s important. Two or more
services can easily be combined to create another service.
Conclusion of the bank example
The definition of software services aligns with the
business services that a bank offers to ensure
smooth business operations and to help realize
strategic goals such as providing ATM and Web
access to banking services in addition to
providing them in the branch office.
Deploying services in the context of an SOA
makes it easier to compose services into simple
as well as complex applications, which can also
be exposed as services that can be accessed by
humans and IT systems alike.
Business View - Services (SO of SOA)
The enterprise architecture perspective should be
focused on the business needs in order to make
sure IT serves the business and not vice versa.
“SOA is a conceptual business architecture where
business functionality, or application logic, is
made available to SOA users, or consumers, as
shared, reusable services on an IT network.
“Services” in an SOA are modules of business or
application functionality with exposed interfaces,
and are invoked by messages.”
In a NutShell
From the business point of view SOA is :
About analyzing the business to identify business
areas and business processes.
Followed by defining services to represent these
Services expose their capabilities through message
The services can then be choreographed or
orchestrated to realize the business processes.
The goal of SOA is to increase the alignment between
business and IT and achieve business agility – the
ability to respond to changes quickly and efficiency.
Technical View - Architecture (A of SOA)
SOA is commonly thought of as an architecture or an
architecture style that builds on loosely coupled,
interoperable and composable components or software
agents called services.
Services have well-defined interfaces based standard
protocols (usually web-services but most definitions
mention that it is not the only possible implementation) as
well as QoS attributes (or policies) on how these interfaces
can be used by Service Consumers.
SOA definitions mention the basic communication pattern
for SOA is request/reply but many definitions also talk
about asynchronous communications as well.
Loose coupling manifests itself in
the SOA paradigm as follows:
It helps to have an abstraction layer between the service
producers and service consumers.
Loose coupling promotes flexibility in changing the service
implementation without impacting the service consumers.
In the SOA approach, functionality is organized as a set of
modular, reusable shared services. These services have
well-defined interfaces that encapsulate the key rules for
accessing the services. They're also built without making
any assumptions of who will use or consume these services.
Thus, they are loosely coupled to the consumer of these
Earlier Approaches vs SOA
Earlier approaches to building IT systems tended to directly use
specific implementation environments such as object orientation,
procedure orientation, and message orientation to solve these
business problems, resulting in systems that were often tied to
the features and functions of a particular execution environment
technology such as CICS, IMS, CORBA, J2EE, and COM/DCOM.
Whereas in SOA business services (i.e., the services that an
organization provides to clients, customers, citizens, partners,
employees, and other organizations) are the key organizing
principle used to align IT systems with the needs of the business.
Previous approaches require you to focus more on the use of a
specific execution environment technology. Whereas service
orientation lets you focus on the description of the business
problem and services are developed better which aligns them with
solving business problems.
Earlier Approaches vs SOA
Previous implementations of SOA were based on a single
execution environment technology. Whereas in SOA due to
separating the service interface from the execution
technology, allows IT departments to choose the best
execution environment for each job (whether it’s a new or
existing application) and tying them together using a
consistent architectural approach.
Separating the service description from its technology
implementation in SOA means that businesses can think
about and plan IT investments around the realization of
operational business considerations, as represented by the
description, more so than the capabilities of any individual
product or software technology chosen to execute the
Earlier Approaches vs SOA
The real value of SOA comes from the later stages of deployment, when
new applications can be developed entirely, or almost entirely, by
composing existing services. When new applications can be assembled out
of a collection of existing, reusable services, the best value for effort can
be realized (that is, the lowest cost and fastest time to results and best
It’s easy to understand the benefit of reusing common business services
such as customer name lookup, ZIP Code validation, or credit checking.
In a pre service oriented development environment, these functions might
be performed by reusable code libraries or class libraries that are loaded
or linked into new applications. In SOA-based applications, common
functions such as these, as well as typical system functions such as
security checks, transaction coordination, and auditing are instead
implemented using services. Using services not only reduces the amount
of deployed code, but it also reduces the management, maintenance, and
support burden by centralizing the deployed code and managing access to
Service-Oriented Systems Require a Different
Service Oriented Architecture as an architectural
style for building systems based on interacting
coarse grained autonomous components called
Each service expose processes and behavior
through contracts, which are composed of
messages at discoverable addresses called
The Service’s behavior is governed by policies
which are set externally to the service itself.
The central pillar of SOA is the service. “A facility supplying
some public demand.”
A Service should provide a high cohesion and distinct
Services should be coarse grained pieces of logic.
A Service should implement at least all the functionality
promised by the contracts it exposes.
Service should satisfy autonomy. Autonomy means the
services should be self-sufficient, at least to some
extent, and manifest self healing properties.
The collection of all the messages supported by the Service
is collectively known as the service's contract.
The contract can be unilateral, meaning a closed set of
messages the service chooses to provide.
A contract might also be multilateral or bilateral, that is,
between a predefined group of parties.
The contract can be considered the interface of the
Service akin to interfaces of object in object oriented
The Endpoint is an address, a URI, a
specific place where the service can be
found and consumed.
A specific contract can be exposed at a
Unit of communication in SOA.
Ex : http GET messages (part of the REST style) ,SOAP
messages, JMS messages and even SMTP messages are all
valid message forms.
Has a header and body.
The existence of the header allows for infrastructure
components to route reply messages (e.g. correlated
messages pattern) or handle security better (see Firewall
Policy separates dynamic specification from
static/semantic specification. Policy represents
the conditions for the semantic specification
availability for service consumers.
The unique aspects of policy are that it can be
updated in run-time and that it is externalized
from the business logic. The Policy specify
dynamic properties like security (encryption,
authentication, Id etc.) , auditing, SLA etc.
A service consumer is any software that
interacts with a service by exchanging
messages with the service.
Consumers can be either client
applications or other “neighboring”
services their only requirement is that
they bind to an SOA contract.
Emphasis on Interface
SOA has a total of four different components that deal with
the interface :
messages which are the parts of the interface,
contract which is the collection of the messages,
endpoint where the contract is delivered and
policy which governs the behavior of the endpoint.
The focus on interfaces is what gives SOA the ability to
create loose coupling, composable components, reuse and
achieve the various design goals.
Service-oriented architecture is a way of designing,
developing, deploying and managing systems, in which
Services provide reusable business functionality.
Service consumers are built using functionality from
Service interface definitions are first-class artifacts.
An SOA infrastructure enables discovery, composition,
and invocation of services.
Protocols are predominantly, but not exclusively,
message-based document exchanges.
Services and Cost Efficiency
Services and Agility
Services and Adaptability
Services and Legacy Leverage
Components of a Service Oriented System
Three Basic Operations to Support Service-
Services repositories are queried for
services with desired characteristics.
Applications/service consumers are built
by integrating functionality provided by
Services are invoked and service code is
Motivation for Service Oriented Architecture
Rapidly-changing business environment
Ubiquity of the Internet & WWW has led to emergence of
platform-independent, web-based technologies as the standard
building blocks for enterprise integration.
There is an increase trend for sharing resource/data both within
companies and among companies in a flexible/standardized
In a service oriented approach, the complete value chain within
the company is divided into small modular functional units, or
A service oriented architecture focuses on how services are
described and organized to support the dynamic, automated
discovery and use.
Companies and their sub-units should be able to easily provide
services. Other business units can use these services in order to
implement their business processes.
A basic SOA architecture is composed of a
service provider, service, and an optional
Application-to-application messaging is
used in the information exchange.
First the service provider creates
a service and decides to expose it
and publish it. Publishing is done
by posting the service information
on the service directory.
On the other side, a service
requester, in need of a certain
service, searches the service
directory for one that meets the
Upon finding one and using the
information available on the
service directory, the service
requester is able to directly
contact the service provider in the
correct way to fulfill the business
• Service provider: Provider of services whose
invocation contract and location are published
• Service consumer: Consumer of services
matching his or her business need found in a
• Service directory: Directory for publishing and
listing available services for consumers
Requirements of SOA
Interoperability between different systems
and programming languages. (Use
standards; platform independent)
Clear and unambiguous description
Retrieval of the service
What is SOA?
Service-oriented architecture (SOA) is an evolution of
distributed computing based on the request/reply design
paradigm for synchronous and asynchronous applications.
An application's business logic or individual functions are
modularized and presented as services for consumer/client
What's key to these services is their loosely coupled nature;
i.e., the service interface is independent of the
Application developers or system integrators can build
applications by composing one or more services without
knowing the service’s underlying implementations.
For example, a service can be implemented either in .Net or
J2EE, and the application consuming the service can be on
a different platform or language. 42
What is SOA?
Conceptual view of SOA
Web Client, Rich Client, Enterprise Portal etc Application Frontend
A B C D E F G H I Services
.NET CRM JAVA KMS 43
SOA services have self-describing interfaces in platform-independent XML
documents. Web Services Description Language (WSDL) is the standard
used to describe the services.
SOA services communicate with messages formally defined via XML
Schema (also called XSD). Communication among consumers and
providers or services typically happens in heterogeneous environments,
with little or no knowledge about the provider. Messages between services
can be viewed as key business documents processed in an enterprise.
SOA services are maintained in the enterprise by a registry that acts as a
directory listing. Applications can look up the services in the registry and
invoke the service. Universal Description, Definition, and Integration
(UDDI) is the standard used for service registry.
Each SOA service has a quality of service (QoS) associated with it. Some
of the key QoS elements are security requirements, such as authentication
and authorization, reliable messaging, and policies regarding who can
The reality in IT enterprises is that infrastructure is
heterogeneous across operating systems, applications,
system software, and application infrastructure.
Some existing applications are used to run current business
processes, so starting from scratch to build new
infrastructure isn't an option.
Enterprises should quickly respond to business changes
with agility; leverage existing investments in applications
and application infrastructure to address newer business
requirements; support new channels of interactions with
customers, partners, and suppliers; and feature an
architecture that supports entire business.
SOA with its loosely coupled nature allows
enterprises to plug in new services or upgrade
existing services in a granular fashion to address
the new business requirements,
Provides the option to make the services
consumable across different channels, and
exposes the existing enterprise and legacy
applications as services, thereby safeguarding
existing IT infrastructure investments.
To implement SOA, enterprises need a
Several service consumers can invoke
services by sending messages.
These messages are typically
transformed and routed by a service bus
to an appropriate service
This service architecture can provide a
business rules engine that allows
business rules to be incorporated in a
service or across services.
The service architecture also provides a
service management infrastructure that
manages services and activities like
auditing, billing, and logging.
In addition, the architecture offers
enterprises the flexibility of having agile
business processes, better addresses the
regulatory requirements like Sarbanes
Oxley (SOX), and changes individual 47
services without affecting other services.
A typical SOA infrastructure
To run and manage
enterprises need an
that is part of the
support all the
and required runtime
SOAP, WSDL, UDDI
WSDL, UDDI, and SOAP are the fundamental pieces of the SOA
infrastructure. WSDL is used to describe the service; UDDI, to
register and look up the services; and SOAP, as a transport layer
to send messages between service consumer and service
provider. While SOAP is the default mechanism for Web services,
alternative technologies accomplish other types of bindings for a
service. A consumer can search for a service in the UDDI registry,
get the WSDL for the service that has the description, and invoke
the service using SOAP.
WS-I Basic Profile
WS-I Basic Profile, provided by the Web services Interoperability
Organization, is turning into another core piece required for
service testing and interoperability. Service providers can use the
Basic Profile test suites to test a service's interoperability across
different platforms and technologies. 49
J2EE and .Net
Though the J2EE and .Net platforms are the dominant
development platforms for SOA applications, SOA is not by any
means limited to these platforms. Platforms such as J2EE not only
provide the framework for developers to naturally participate in
the SOA, but also, by their inherent nature, bring a mature and
proven infrastructure for scalability, reliability, availability, and
performance to the SOA world.
Newer specifications such as Java API for XML Binding (JAXB),
used for mapping XML documents to Java classes, Java API for
XML Registry (JAXR), used for interacting with the UDDI registries
in a standard manner, and Java API for XML-based Remote
Procedure Call (XML-RPC), used for invoking remote services in
J2EE 1.4 facilitate the development and deployment of Web
services that are portable across standard J2EE containers, while
simultaneously interoperating with services across other platforms
such as .Net. 50
Quality of services
Existing mission-critical systems in enterprises address advanced requirements such as security,
reliability, and transactions. As enterprises start adopting service architecture as a vehicle for
developing and deploying applications, basic Web services specifications like WSDL, SOAP, and
UDDI aren't going to fulfill these advanced requirements. As mentioned previously, these
requirements are also known as quality of services. Numerous specifications related to QoS are
being worked out in standards bodies like the World Wide Web Consortium (W3C) and the
Organization for the Advancement of Structured Information Standards (OASIS). Sections below
discuss some of the QoS artifacts and related standards.
The Web Services Security specification addresses message security. This specification focuses on
credential exchange, message integrity, and message confidentiality. The attractive thing about
this specification is it leverages existing security standards, such as Security Assertion Markup
Language (SAML), and allows the usage of these standards to secure Web services messages. Web
Services Security is an ongoing OASIS effort.
In a typical SOA environment, several documents are exchanged between service consumers and
service providers. Delivery of messages with characteristics like once-and-only-once delivery, at-
most-once delivery, duplicate message elimination, guaranteed message delivery, and
acknowledgment become important in mission-critical systems using service architecture. WS-
Reliability and WS-ReliableMessaging are two standards that address the issues of reliable
messaging. Both these standards are now part of OASIS.
Service providers sometimes require service consumers to communicate with certain
policies. As an example, a service provider may require a Kerberos security token for
accessing the service. These requirements are defined as policy assertions. A policy may
consist of multiple assertions. WS-Policy standardizes how policies are to be communicated
between service consumers and service providers.
As enterprises embark on service architecture, services can be used to integrate silos of
data, applications, and components. Integrating applications means that the process
requirements, such as asynchronous communication, parallel processing, data
transformation, and compensation, must be standardized. BPEL4WS or WSBPEL (Web
Services Business Process Execution Language) is an OASIS specification that addresses
service orchestration, where business processes are created using a set of discrete services.
WSBPEL is now part of OASIS.
As the number of services and business processes exposed as services grow in the
enterprise, a management infrastructure that lets the system administrators manage the
services running in a heterogeneous environment becomes important. Web Services for
Distributed Management (WSDM) will specify that any service implemented according to
WSDM will be manageable by a WSDM-compliant management solution.
Other QoS attributes such as coordination between partners and transactions involving
multiple services are being addressed in the WS-Coordination and WS-Transaction
specifications, respectively, which are OASIS efforts as well.
SOA is not Web Services
There seems to be general confusion about the relationship between SOA
and Web services. Web Service is one of the ways to implement SOA.
In an April 2003 Gartner report, Yefim V. Natis makes the distinction as
follows: “Web services are about technology specifications, whereas SOA
is a software design principle.”
Notably, “Web services WSDL is an SOA-suitable interface definition
standard: this is where Web services and SOA fundamentally connect.”
Fundamentally, SOA is an architectural pattern, while Web services are
services implemented using a set of standards; Web services is one of the
ways you can implement SOA.
The benefit of implementing SOA with Web services is that you achieve a
platform-neutral approach to accessing services and better interoperability
as more and more vendors support more and more Web services
Role of Web Services in SOA
Enforce standards and, thus, promote
compatibility and portability.
Are cross-platform and cross-language.
Are widely supported, making SOA
relatively easy to adopt.
Provide faster tooling support, which
speeds the implementation of SOA.
Benefits of SOA
Service-oriented development provides the following
Reuse—The ability to create services that are reusable in
Efficiency—The ability to quickly and easily create new
services and new applications using a combination of new
and old services, along with the ability to focus on the data
to be shared rather than the implementation underneath.
Loose technology coupling—The ability to model services
independently of their execution environment and create
messages that can be sent to any service.
Division of responsibility—The ability to more easily allow
business people to concentrate on business issues,
technical people to concentrate on technology issues, and
for both groups to collaborate using the service contract. 55
Benefits of SOA
While the SOA concept is fundamentally not new, SOA differs from
existing distributed technologies in that most vendors accept it and have
an application or platform suite that enables SOA.
SOA, with a ubiquitous set of standards, brings better reusability of
existing assets or investments in the enterprise and lets you create
applications that can be built on top of new and existing applications.
SOA enables changes to applications while keeping clients or service
consumers isolated from evolutionary changes that happen in the service
SOA enables upgrading individual services or services consumers; it is not
necessary to completely rewrite an application or keep an existing system
that no longer addresses the new business requirements.
Finally, SOA provides enterprises better flexibility in building applications
and business processes in an agile manner by leveraging existing
application infrastructure to compose new services. 56
Role of ESB in SOA
An ESB plays an important role in an SOA.
At the base of its roles, it represents the
backbone and infrastructure capable of
connecting service providers and service
Role of ESB in SOA
Provides an integration infrastructure
consistent with the principles of SOA:
Enforces the use of explicit implementation-
independent interfaces to define services with
Uses communication protocols that stress
location transparency and interoperability
Promotes the definition of services that
encapsulate reusable business functionalities
Provides the means to manage the service
Role of ESB in SOA
Operates in the distributed, heterogeneous
environment because it:
Supports synchronous and asynchronous
Uses standard interfaces and standard
Centralizes control and distributes processing
Supports mediation to formulate the
request/response as needed between different
parties without the need of change in any
Applies security and QoS to the SOA project