Microsoft Word - Service Oriented ArchitectureDocument Transcript
D. Ananda Sarma
P. Praveen Kumar
In IT enterprises and Federal organizations, the infrastructure is heterogeneous across
operating systems, applications, and software systems. These have to continuously adapt to the
changing business environment based upon regulations, mandates, and stakeholder
requirements. So, starting new infrastructure from scratch is not an easy option. Enterprises
should quickly respond to business changes, leveraging existing investments in applications to
address newer business requirements.
Service-Oriented Architecture (SOA), with its loosely coupled nature allows enterprises to
plug in new services or upgrade existing services to address the new business requirements and
provides an option to make the services consumable across different channels. Though, the use
of DCOM or Object Request Brokers (ORBs) based on CORBA are considered as the first
specifications for Service-Oriented Architecture, unlike them, SOA based on web services has
tremendous industry and customer support, because of its loosely coupled nature.
Also, the business results of an organization can be improved by adopting SOA. This
approach architects and organizes the IT and business functionality that helps the organization in
achieving the business goals by managing the change. Adoption of SOA helps an organization to
get the business values such as increased agility, less risk, greater return of investment and
This whitepaper on SOA gives information about what is an SOA, why an organization
should adopt it, the underlying architecture and key characteristics of SAO. It also explains briefly
about the components and infrastructure of SOA. The authors of this whitepaper have tried to
give a brief note on the implementation standards and best practices that an organization should
follow to get the business values in the best possible way. Through this whitepaper one can also
know the benefits that an organization gets and the challenges that the organization faces, when
SOA is adopted.
Executive Summary ............................................................................................................ 2
1. Introduction ................................................................................................................. 4
2. Key Characteristics and Architecture .......................................................................... 6
3. Components of an SOA solution................................................................................. 7
4. SOA infrastructure ...................................................................................................... 9
5. Implementation Standards and Best Practices .......................................................... 12
6. Performance .............................................................................................................. 13
7. SOA Using JBoss ...................................................................................................... 14
8. Business Value .......................................................................................................... 15
9. Benefits and Challenges ............................................................................................ 16
10. Conclusion............................................................................................................. 17
11. Bibliography .......................................................................................................... 18
A service is a function that is well-defined, self-contained, and does not depend
on the context or state of other services. The collection of such services, which
communicate with each other, is termed as ‘Service-Oriented Architecture’. These
services are loosely coupled, platform-independent interfaces, and are reusable, which
means that an application need not know the technical details of another application to
communicate with it. This communication can be either passing of simple data or
coordination of two or more services for some activity. In either way, there should be a
means of connecting the services to each other.
SOAs promise to speed development and decrease integration time and effort,
but only if they are implemented correctly. Basically, SOA is a higher level of application
development that focuses on business processes such as verification of credit card
transaction or processing a purchase order, using standard interfaces that help to hide
the underlying technical complexity of IT environment.
The concept of SOA can be best explained with the following figure. The service
consumer at the right sends a service request message to the service provider at the left.
The service provider returns a service response message to the service consumer. The
request and response connections are defined in such a way that both the service
consumer and service provider understands them. A service provider can also be a
Though the term, Service-Oriented Architecture may be new, the concept is not a
new thing. The use of DCOM or Object Request Brokers (ORBs) based on the CORBA
specification is considered as the first service-oriented architecture by many people. The
most likely connection technology of service-oriented architectures is the technology of
‘Web Services’. But, SOA is not just CORBA in new form. Unlike CORBA, which is a
tightly coupled application connection, SOA is loosely coupled one, such as web
services. In tightly coupled applications, it is hard to adapt to changing business
requirements, as modifications to one application forces to make changes to the other
In IT enterprises, the infrastructure is heterogeneous across operating systems,
applications, and software systems. So, starting new infrastructure from scratch isn’t an
option. Enterprises should quickly respond to business changes, leveraging existing
investments in applications to address newer business requirements. SOA with its
loosely coupled nature allows enterprises to plug in new services or upgrade existing
services to address the new business requirements and provides an option to make the
services consumable across different channels.
The following figure shows how an enterprise could create SOA based supply
chain composite application using a set of existing applications that expose the
functionality via standard interfaces.
Role of Web services in an SOA:
There is a general confusion about the relationship between SOA and web
services. SOA is a software design principle, where as web services are about
technology specifications and web services’ WSDL is an SOA-suitable interface definition
Basically, SOA is an architectural pattern, while web services are services
implemented using a set of standards and web services is a way of implementing SOA
pattern. The benefit of implementing SOA with Web services is that a platform-neutral
approach to accessing services and better interoperability is achieved as more and more
vendors support more and more web services specifications.
It is important to note that SOA does not require web services and web services
can be deployed without an SOA. But, some believe that building an SOA with web
services is an ideal approach. However, web services must be implemented properly to
create an SOA. A web service, if properly implemented, is little more than an SOA that
uses SOAP and WSDL.
On the other hand, companies SOA can be built without using web services.
Instead, IBM’s WebSphere MQ can be used as a messaging and integration layer to
connect legacy systems with the front-end applications. Some other companies build
SOA based on publish-subscribe system without web services, where Java Message
Service is used as a message layer on top of a web server and an application server.
These also use enterprise service bus from Sonic Software to integrate and movement of
data. Here, the services are designed like web services without the web service interface.
2. Key Characteristics and Architecture
The following are the key characteristics of an SOA solution.
a) SOA services have self-describing interfaces in platform-independent XML
documents. Web Services Description Language (WSDL) is the standard used to
describe the services.
b) SOA services communicate with messages that are defined via XML schema
(XSD) and this communication among consumers and providers or services
happens in heterogeneous environments, with less knowledge about the
provider. Messages between services can be are key business documents
processed in an enterprise.
c) SOA services are maintained in the enterprise by a registry that acts as a
directory listing. Applications can look up the registry and invoke the service.
Universal Description, Definition, and Integration (UDDI) is the standard used for
d) 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 invoke
To implement SOA, enterprises need service architecture similar to the following.
Several service consumers invoke services by sending messages, which are
transformed and routed by a service bus to an appropriate service implementation. This
architecture can provide a business rules engine that allows business rules to be
incorporated in a service or across services. This also provides a service management
infrastructure that manages services and activities like auditing, billing, and logging. In
addition, the enterprises can have agile business processes and can change individual
services without affecting the other services.
3. Components of an SOA solution
Generally, SOA should describe the following points regarding the services.
a) What a service is how it is constructed, used, evolved and maintained?
The architecture must define the structure of a service and how to build
and use one. For each type of service, the architecture should specify
• The appropriate size of the service, known as Granularity
• The guidelines for interface design, through which the business services
are accessed to pass the documents.
• The standard mechanisms for configuring the services.
• The artifacts that support a service both at runtime and design time such
as specifications, documents and test plans etc.
• The specific design patterns that should be followed to keep the services
independent and reusable.
• The complete lifecycle of service including the versioning and backward
compatibility requirements to maintain the services.
b) How existing legacy systems are integrated into the service environment?
In the enterprises today, much of the business functionality is not in the
form of a service. Hence, the essential part of an SOA is how this existing
functionality can be exposed as services and connected to the service
environment. The SOA must specify the general mechanism for defining these
services, wrapping them, and connecting them.
c) How different services are combined?
The SOA must describe methods, tools and infrastructure for combing
the services into larger business processes and services.
d) How services connect to each other and pass information at a technical level?
A service must be designed to fit into a specific technical, semantic and
operational environment and this environment and services it provides must be
described by the architecture. The service bus is a key component of the
application infrastructure. It provides the communications infrastructure (e.g.
ESB) to enable the services to integrate. The SOA must specify the service bus
along with the guidelines to use that infrastructure.
e) How services share the common meanings for that information at a semantic
The SOA must define the common semantic environment in which the
services operate, such as the data schema that is common across services for
consistency and interoperability.
f) How services contribute to the enterprise business model, goals and strategy?
A business model is a key for understanding the requirements of a
common enterprise, especially for shared data. The SOA need not define a
business model, but must define how the business model is used to design the
services and enterprise business processes
g) What processes, frameworks and tools are needed to support SOA at the
The architecture must enable the easy and efficient creation of the
services. Framework and tools is the key for allowing independent organizations
to create the consistent services.
The key components of SOA can be illustrated by the following figure.
To run and manage SOA applications, enterprises need an SOA infrastructure
that is part of the SOA platform. An SOA infrastructure must support all the relevant
standards and required runtime containers. An SOA infrastructure may look like the
SOAP, WSDL, UDDI:
These 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
another important part required for service testing and interoperability. Service providers
use the Basic Profile test suites to test a service’s interoperability across different
platforms and technologies.
J2EE and .Net:
Though the J2EE and .Net are the dominant platforms for SOA applications,
SOA is not limited to these platforms. Platforms such as J2EE not only provide
framework for developers to participate in SOA, but also, bring a proven infrastructure for
scalability, reliability, availability, and performance to the SOA world.
Quality of Services:
Existing mission-critical systems in enterprises address advanced requirements
such as security, reliability and transactions. The basic web services like WSDL, SOAP,
and UDDI do not fulfill these advanced requirements also known as Quality of Services
(Qos), when the enterprises adopt SOA for developing and deploying the applications.
Hence, standard bodies like World Wide Web Consortium (W3C) and the Organization
for the Advancement of Structured Information Standards (OASISI) have come up with
numerous specifications related to QoS. The following are the some of the QoS artifacts
The ‘Web Services Security’ specification address message security and focuses
on credential exchange, message integrity, and message confidentiality. This
specification leverages existing security standards, such as Security Assertion Markup
Language (SAML), and allows the usage of these standards to secure web services
In an 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 are important in mission-critical
systems using service architecture. WS-Reliability and WS-Reliable Messaging are two
such standards that address the issues of reliable messaging.
Service providers may sometimes require service consumers to communicate
with certain policies, for example, a service provider may require a Kerberos security
token for accessing the service and 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.
In SOA, services can be used to integrate data, applications and components
and while integrating applications, 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.
In an enterprise, as the no. of services and business processes that are exposed
grow, a management infrastructure that helps system administrators to manage the
services running in a heterogeneous environment becomes more important. Web
Services for Distributed Management (WSDM) specifies that any service implemented
according to WSDM will be manageable by a WSDM-compliant management solution.
Also, the coordination between partners and transactions involving multiple
services are being addressed in the WS-Coordination and WS-Transaction
The major goal of an SOA is to build a library of services that can be combined
together into business processes to support and improve the enterprise business goals.
To achieve this, it is not sufficient if the services are built at random, even though they
are well-designed individually. The architecture of SOA must deal with both the
construction of services and combination of them, so that the services can be constructed
by individual organizations.
Logical SOA tiers and Components:
The following figure illustrates the primary logical tiers from the application
perspective within a SOA. The three middle tiers (Presentation, Business, and
Intermediary tiers) primarily exist to connect clients to resources in an efficient and
scalable manner that minimizes the effect and scope of changes. Within the system,
there are three basic elements, Domain Objects, Business Services, and Technical
4. Implementation Standards and Best Practices
The following are the implementation standards and the best practices that
are to be followed while building an SOA.
The following Points are to be considered in implementing large-scale SOA.
a) Services need to share a common semantic. Otherwise, we will have
services that do not speak the same business language, and cannot call
each other without complex data transformation.
b) A repository of components such as services and objects is needed to be
usable by developers and structured around knowledge sharing.
The service in a large SOA should be independent of the implementation details.
Web service implementation is just one possibility among many others. A message
based integration via a MOM, a call to a method on an EJB interface, a call to a rules
engine, a call to a mainframe transaction etc. are all valid implementation details of a
business service. Not doing so will introduce unnecessary technical rigidity that limits
a) It is very easy for companies, especially large enterprises with distinct
operations, to buy new technologies or integrate applications without regard
to how they fit into the overall plan. The challenge in building an SOA is to
keep both IT and business people focused on the architecture goals.
b) IT architects also need to identify the right level of service to provide and
those services also shouldn’t be too fine that defeats the goal of services. On
the other hand, if the focus is too narrow, more services are needed, which
increases development time. Also, too many services may bring up the
c) The quality of service needs to be taken into account when implementing
SOAs. A loosely coupled architecture is good for systems that do not require
real-time responses. In such systems, if information doesn’t get where it
needs to be on time, the consequences are minor. For example,
implementing SOA for air-traffic control system is a bad idea.
IT architectures that are provisioned to satisfy unpredictable application
consumption require a comprehensive service application platform. A Grid infrastructure
combined with SOA addresses this need by serving as a virtual service execution
platform focused on application, hardware and data virtualization. By distributing
application workload across shared system and data sources, the service execution
platform inherent in an effective Grid infrastructure drives new level of business
performance. The following are the key benefits that enterprises can achieve by
deploying an effective Grid infrastructure to support the SOA strategies.
a) Application Performance:
If Grid infrastructure is used, there will 25 to 50 times improvement in the
application performance speed, measured by response time and throughput
b) Resilience and Reliability:
With guaranteed task execution and mechanisms to ensure recovery and
migration in the event of system error, application failure rates can drop by up to
90 percent or more.
c) Flexibility and API independence:
The Grid layer supports a wide variety of clients that can be quickly
virtualized, including Java, .NET, SOAP, C++ and binary executables.
d) Rapid development and Deployment:
The Grid layer can simplify the development and streamline deployment
by providing a standards-based, flexible and intuitive programming model.
The following figure shows the separation between the use of batch-
oriented and SOA-based grid infrastructure software that defines the types of grid
enablement scenarios, which can be applied to the different degrees of grid
adoption. It also helps to define the performance profiles for each scenario.
6. SOA Using JBoss
JBoss positioned ‘JBoss Enterprise Middleware Suite (JEMS)’ as the open
source platform for SOA. JEMS can be used for deploying enterprise SOA in mission
critical environments such as financial services, media and insurance. JBoss is also
expanding JEMS to include an Enterprise Service Bus (ESB) to easily develop and
deploy SOA to automate business processes and improve enterprise competitiveness.
JBoss ESB aims to combine open source products and components to deliver
SOA to the market in an easily consumed product. The goal of JBoss is to leverage SOA
principles within the ESB architecture itself and present them to third parties and
customers. This means JBoss will not tie itself to one standard, but enable greater
flexibility with a plug-and-play architecture. It also supports the Java Business Integration
(JBI) standard and also supports other ESB and SOA plug-in standards as well. JBoss
ESB enables the widest choice of service architectures, such as web services, EJB3, and
Seam/Web Beans. Seam can integrate an SOA deployment into Web 2.0 rich clients as
well. The following figure illustrates JBoss ESB release.
Logical SOA tiers and JBoss Products:
JBoss Enterprise Middleware Suite provides components and products for all the
server-side tiers needed to build an SOA. The following figure shows, how the JBoss
products span the presentation, business, intermediary, and resource tiers.
7. Business Value
SOA is about improving the business results. It is an approach to architecting
and organizing the IT and business functionality that enables an organization to achieve
the business goals with managing the change. The business values that an organization
gets by adopting SOA are as follows.
a) Increased agility:
SOA helps the organization to be agile to change and helps to quickly
respond to the new customer priorities and rapidly introduce new services to a
broader set of users and implement new initiatives enterprise wide.
b) Less Risk:
With SOA, organization can maintain and improve the security and
continuity of business operations as well as enable regulatory compliance, while
reducing the impact of technology deployments on people and processes.
c) Greater return:
An SOA deployed according to the business needs of can reduce the
cost of maintaining the applications across the organization, including the legacy
systems. At the same time, the cost of application integration can also be
reduced, as the business processes across customers, partners and suppliers
d) Improved performance:
When SOA is used, the IT’s ability to respond to changing the business needs
can be improved as the views of data for more effective decision-making are created. As
a result, the IT investments can be shifted from maintenance to innovation by increasing
both the customer and partner satisfaction. Also, the operational efficiency is increased
by automating and streamlining the tasks.
8. Benefits and Challenges
The various benefits and challenges of building an SOA can be summarized as
Benefits of an SOA:
IT organizations may need to evolve to completely get the benefits of SOA like
reusability and agility.
a) The services of an SOA are loosely coupled, i.e., the service interface is
independent of the implementation and developers can build applications by
composing one or more services without the knowing the services’
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.
b) SOAs work very well in heterogeneous environments and developers need
not spend too much of time in writing new lines of code to connect
applications. Instead, standard protocols such as web services can be used.
Also, as most of the SOA code is reusable, the development costs are
reduced and SOA also takes legacy investments such as SAP, Siebel,
Oracle etc. to make them work together.
c) By identifying the capabilities of existing systems and controlling them, the
value of the IT systems can be maximized while minimizing the risks. Also,
building services using either Simple Object Access Protocol (SOAP) or Web
Services Description Language (WSDL), not only simplifies the integration
process, but also, lets customers and business partners share information
more easily across company firewalls.
d) Another benefit of an SOA is that it forces IT architects to think in terms of
business architectures, not technical architectures. So, to build a better
system, the operations people together with the IT architects can think of the
best way to design it based on business flows and how to meet the needs of
the business. And implementing that design, which involves large scale of
integration, becomes an easy task. For that to work, the business people
have to think of the best ways to run their business and the processes that
need to be put in place to improve the level of customer service. By exposing
and sharing information across applications, companies can get more
business performance data in real-time, improving business intelligence.
e) In addition, IT architects can easily incorporate new technologies into SOA,
reducing risk and expense while speeding the development of new
applications and finally, the benefits of easier integration leads to greater
Challenges in building an SOA:
Though there are many benefits that an SOA provides with, the organizations
have to face some challenges such as the following.
a) The biggest challenge is security. It is always easier to secure a closed
system than an open architecture. To overcome some of these challenges,
the companies should move slowly when setting up an SOA, focusing first on
business processes that don’t require a high level of security. Managing the
complexity of services configuration requires a good SOA governance model.
b) When a complex net-centric business process is created, monitoring and
auditing requirements also become complex. For example, when any
transaction in a service-oriented architecture fails, finding out what went
wrong and where the transaction dropped can be a challenge.
c) Because of the loosely coupled nature of SOA, changes in or degradation of
performance for one service could break many applications within the SOA.
Tracing the interactions across the loosely coupled implementations to see
whether a new application is creating measurable load on the existing
services becomes a challenge.
d) The final issue is the cost. Building an SOA isn’t cheap. Reengineering the
existing systems architecture costs lot of money. It also requires significant
human resources, including business analysts to lay out the business
processes, systems architects to turn processes into specifications,
engineers to develop the code, and project managers to track it all.
Federal Organizations have to continuously adapt to the changing
business environment based upon regulations, mandates, and stakeholder
requirements. Generally, the IT response to such changes would be to work on
new projects involving new applications, hardware, software, and services that
take months or years to complete.
A Service-Oriented Architecture (SOA) helps in overcoming the software
infrastructure challenges for organizations that require more flexible applications
and systems, and greater alignment of IT with business goals. This is an IT
strategy based on building IT systems with the common parts that enables the
business transformation. Unlike CORBA or DCOM, SOA based web services has
tremendous industry and customer support. The value of SOA can be better
known from the concept of re-use and the flexibility and the agility gained from
being able to reuse the components to address the new business requirements.
The re-use of internal and external services accelerates the return on investment
for an SOA strategy.