SOA Reference Architecture

Defining The Key Elements Of A

Successful SOA Technology Framework

May 2006
TABLE OF CONTENTS

INTRODUCTION......................................................................................................................... 3

SOA REFERENCE ARCHITECTURE........................................................................................ 4

SERVICES: THE UNDERLYING BUILDING BLOCKS OF SOA....................................................... 5
MESSAGING: ENABLING SERVICES TO COMMUNICATE AND INTERACT ..................................... 6
REGISTRY: PROVIDING THE BASIS FOR REUSE ....................................................................... 7
SERVICES MANAGEMENT: ADDRESSING SERVICE LEVELS AND GOVERNANCE .......................... 7
ORCHESTRATION: LINKING SERVICES INTO BUSINESS PROCESSES.......................................... 8
ANALYSIS: ENABLING CONTINUOUS PROCESS IMPROVEMENT ............................................... 10
USER INTERACTION: INCORPORATING PEOPLE INTO THE SOA EQUATION.............................. 11
SUMMARY................................................................................................................................ 12

©2006 webMethods, Inc. All rights reserved. Page 2

INTRODUCTION

Companies across all industries and geographies are becoming increasingly interested in
service-oriented architecture (SOA). The basic concept behind SOA is not new – that is,
the idea of accelerating return on IT investment by turning those assets into reusable
building blocks from which new business functionality can be assembled quickly and
efficiently. But what makes SOA different is that, for once, the IT industry as a whole has
backed the concept and the core underlying technologies, giving SOA massive support
and evolving a wide range of standards to make the idea really work. As a result, it has
become possible to bring together a broad spectrum of heterogeneous IT assets into a
uniform collection of reusable parts, thereby enabling the rapid and efficient assembly of
the new systems that modern business demands.

There are many aspects to SOA that must be addressed in order to succeed. Perhaps
the most important is a clear understanding that SOA is not just about technology – it is
also an IT strategy to support business transformation and, as such, SOA has extensive
organizational, procedural, and process implications. These factors aside, when focusing
on the technology dimension of SOA the critical success factor is to ensure that the
necessary framework of tools and technologies is in place.

This paper addresses these particular issues by introducing an SOA reference

architecture that can be used as a blueprint for delivering the appropriate technology
environment for SOA success. Among other objectives, this reference architecture
provides a checklist of the key functional areas required to get the most out of SOA
investments.

©2006 webMethods, Inc. All rights reserved. Page 3

SOA REFERENCE ARCHITECTURE

The webMethods SOA reference architecture is designed to cover all areas of

functionality required to support a successful SOA implementation, and it is the result of a
logical set of deductions based on the nature and objectives of SOA and webMethods’
experience in the real-world issues of deploying SOA-based production solutions.

The starting point for building the reference architecture is services. An SOA is built
around the concept of a business service, this being a reusable piece of logic designed to
execute a piece of business process with standard access and invocation interfaces. So
the first capability of any SOA reference architecture has to deal with service creation,
whether formed of old components or newly written ones.

Once these services have been created, the power of an SOA is derived from joining
these services together. The most flexible way to achieve this is to opt for the ‘loosely-
coupled’, platform-independent approach of messaging. Now services can be joined
together, but there will be no reuse unless it is easy to find out what services exist and
what they do, and so a registry capability is required where services can be catalogued
in a central repository. Once services become a key part of business operations, the next
challenge involves understanding the actual behavior and usage of these services in the
production environment. This requires a level of services management technology that
not only follows what is happening with the services, but also provides essential
governance functionality.

An important aspect of SOA services is that they are clearly related to pieces of business
functionality, rather than simply being an IT-centric piece of code. This now allows these
services to be assembled into a complete business process by using orchestration
technology that can handle service flows to ensure correct execution of the process,
based in its business rules and policies. This relationship between business processes
and the IT components that underpin them now makes it possible to look at the behavior
of the operational system in business terms, and this in turn makes it possible to use
analysis technology to understand and predict business performance and the impact of
change.

Using these technology areas, IT systems can be matched much more closely to
business needs, and change can be handled quickly and efficiently. The final piece of the
puzzle is to ensure that the end-user can take advantage of these new capabilities with
minimal disruption and retraining. User interaction technology such as personalized
portals and role-based tools will limit the disruption of SOA deployments—in terms of
changes introduced on the user’s desktop—while improving user productivity and
effectiveness.

©2006 webMethods, Inc. All rights reserved. Page 4

The diagram below summarizes the SOA reference architecture.

Services: The Underlying Building Blocks Of SOA

The two key requirements of the services functionality in the reference architecture are
(1) to allow new services to be created from scratch, for example in Java or .NET, and (2)
to enable existing applications to be exposed as SOA services. The most commonly used
approach is to make services available as Web services, making use of the considerable
standards work done in this area.

Dealing with new services is relatively easy. The main requirement is to ensure that these
services are container-independent – that is, the caller of the service should need no
knowledge of the environment in which this service will be running. Tools should be
provided to support the development of these services and to register them in the
corporate repository.

Exposing existing applications as services is more problematic and requires smart

technology, such as adapters to the different systems and application environments used
by the applications, and wrappers to make these applications look like standard Web
services. The problem is that the caller must be shielded from understanding anything
about the environment in which the application is running. Therefore, it may be necessary
to map different protocols or data formats, using features found in the messaging layer of
the reference architecture. But, in addition, decisions may need to be made about the
level of service granularity to be used. For example, consider a service for obtaining
customer details, including address, contact information, and transaction history, where

©2006 webMethods, Inc. All rights reserved. Page 5

these three operations are actually carried out by three separate mainframe applications.
Turning each mainframe application into a service might look obvious, but might prove to
perform badly since anyone wanting customer details from outside the mainframe would
need to make three service calls with six associated trips to and from the mainframe as
well as any associated data mappings. An alternative would be to provide some sort of
linkage mechanism on the mainframe side that could combine the three operations into a
single service.

Key areas of differentiation in this services layer are the ease with which services can be
created or exposed, the number of legacy environments supported, and the skill levels
required. This last point is particularly important given that services might be built up of
parts running in completely different environments such as mainframes or UNIX or
Windows servers.

Messaging: Enabling Services To Communicate And Interact

The messaging layer represents the communications capability that allows different
components and services to interact within the SOA. The term ‘messaging’ reflects the
fact that messaging middleware is frequently the best choice for addressing this need,
because of the specific requirements. First, the connectivity must be able to deal with a
multi-platform environment, since many platforms may be involved. Second, it needs to
be ‘connection-independent’ – that is, the service requestor and service provider should
be loosely coupled rather than tightly bound. This is important to achieving the goal of
container-independent services and provides the inherent flexibility and operational
stability of an SOA. This is usually implemented by using an asynchronous messaging
approach, although synchronous messaging may also be required.

Now, just providing the connectivity to allow components and services to interact in a
connection-independent way is not enough. In order to achieve clean interfaces between
services, data formats may have to be manipulated. The issue is that different programs
may have different expectations for data formats; therefore, in order to establish the level
of independence an SOA requires, it may be necessary to map one data format into
another. In this way, each program receives and outputs data in its native format, with the
messaging layer transforming between data formats as required.

Finally, in order to create business services, it is often necessary to implement business

rules. For example, a funds transfer service might need to have a supervisory approval
step if transferring more than a specified amount. For this reason, the messaging layer
also needs to offer some intelligent routing capability to allow the process flow making up
the service to be altered based on business policies and conditions.

Differentiators within this layer include the reliability of the messaging layer and its
performance capabilities. Some operations may well require guaranteed, once-only
communications while others will want to optimize performance rather than recoverability.
Another differentiator will be the extent to which the use of standards is a concern. In fact,
most messaging layers will make use of the Java specification for message services,
JMS.

©2006 webMethods, Inc. All rights reserved. Page 6

Registry: Providing The Basis for Reuse
In typical SOA scenarios, the registry is positioned as the repository for information
related to Web services. In this reference architecture, however, the registry layer has a
broader definition in that it also encompasses the tools required for the registry to play its
key role in the SOA implementation effectively. So, at the basic level, tools must be
provided that enable services to be modeled, created, and stored. In addition, an
import/export capability should be required – some services may have already been
created using different technologies or products, and sharing services is a useful and
important productivity aid.

Because of the importance of the registry, it is necessary to provide interfaces to

monitoring and management tools through which registry activity can be controlled and
also to ensure the availability and performance characteristics of the registry. For
instance, because the registry will be key to real-time operations, it may be desirable to
federate the registry across a range of different locations and environments. Replication
might also be of interest to protect against any impact to this critical data store, and a fail-
over capability combined with the ability to re-route around problems will help to ensure
that registry availability is not an issue.

Then there is the question of usability. For an SOA to be effective, it is vital that
programmers can easily find services they can reuse. Otherwise, developers might be
tempted to take the potentially more interesting option of writing the functionality
themselves, creating redundancy and detracting from one of the key advantages of an
SOA. So the registry layer of the reference architecture must offer easy-to-use browse
facilities and clear descriptive information about the services so that programmers can
quickly identify the specific services that will be of value to them. In addition, because a
successful SOA strategy will result in high levels of reuse, it becomes essential that
programmers are alerted to any changes to services in the registry, since these changes
might affect the way different parts of business operations work.

The registry should also hold a range of associated attributes for each service. These
might be dependent on business policies, for example when and where information
should be encrypted as it passes between SOA components, or could be installation-
relevant attributes such as the name of the service creator. The important factor to
consider is that the registry should hold all relevant information regarding each service
and present it to browsers in an easily digestible way.

The key differentiator in the registry layer will be the extent to which functionality extends
beyond the basic repository requirement to encompass all the other ancillary areas. Many
companies looking to SOA have the idea that the registry is just a repository for Web
services definitions such as WSDL (Web services Definition Language), but in reality it is
much more than this.

Services Management: Addressing Service Levels and Governance

So far, the reference architecture has dealt largely with the mechanics of creating or
exposing services, linking them together, and managing their use. However, for success

©2006 webMethods, Inc. All rights reserved. Page 7

from a run-time operations perspective it will be imperative that support is provided for
managing these services, particularly as numbers start to climb from tens to hundreds or
thousands. There are essentially two different areas to consider in this regard: services
execution and governance.

On the execution front, facilities are needed to monitor the availability of services and
their performance and take appropriate actions when quality-of-service problems occur
(such as slow response time). Reporting mechanisms are required, ideally providing both
real-time and off-line statistical summaries of operational activity. Support must be
provided to allow services to be quiesced, taken off-line, and restarted. Fault avoidance
and fault tolerance mechanisms should also be put in place, such as fail-over support
and the ability to re-route around failures. Once performance is being monitored, it also
becomes desirable to start tracking the Service-Level Agreement (SLA) status of
individual services. This is important when trying to ensure that the SOA is serving the
business appropriately and delivering the expected benefits. Businesses should be able
to specify what the service level requirements are for individual services, and then IT
should have the ability to monitor the SLA to detect any out-of-compliance situations.

From a governance perspective, controls are needed to manage development- and

change-time access requirements and the processes around modifying and changing
services. Audit trail requirements will demand a logging capability, and it should also be
possible to track the occurrence of particular business events. This business event
tracking is based upon the characteristic of an SOA where services actually represent
some distinct business operation. This enables operational information to be related to an
actual business event rather than a technical occurrence. In addition, change
management will require a clear picture of dependencies between services as well as
some sort of service versioning support.

Orchestration: Linking Services into Business Processes

One of the major attractions of SOA is the ability to support dynamic process
reconfigurations, delivering much improved business agility. But this cannot be achieved
unless some sort of process orientation can be layered on top of the technology
components. This is the purpose of the orchestration layer in the reference architecture.
The orchestration layer allows processes to be declared in business flow-chart terms,
mapping beneath the covers to the individual services that make up the process. Now,
when the process needs to be changed to support a new business objective, this can be
done quickly and easily by simply linking into the new supporting services.

©2006 webMethods, Inc. All rights reserved. Page 8

 Figure 2: Reference Architecture - Orchestration

In order to offer this facility, the orchestration layer needs to provide the ability to define
and model processes (see figure above), and to analyze them to understand the impacts
of any changes. As well as system-to-system interactions, the orchestration layer will also
need to deal with human workflow elements where the process passes through a human
touch-point. This places distinct requirements on the orchestration layer, such as the
ability to manage the assignment of work and tasks to individuals as well as groups, and
handle long-running tasks spanning days rather than seconds. This is an important
distinction given that in a human-intensive workflow, such as an insurance claims
assessment process, there may be long periods between different steps. This may
require the system to maintain transaction state for days or weeks, and this need must be
addressed by the orchestration layer of the SOA reference architecture.

Finally, the orchestration layer needs to provide support for monitoring and management
capabilities at the process level, rather than at the level of the individual service
components underneath. It must be possible to start and stop processes, rather than the
underlying services and components, and to understand how the process is behaving at
an end-to-end level.

©2006 webMethods, Inc. All rights reserved. Page 9

Analysis: Enabling Continuous Process Improvement
Once the SOA has been assembled and is operationally active, with a process view
enabled through the orchestration layer, attention can turn to business and operations
improvements. Because operations can be understood at the process level, it now
becomes possible to deal with business performance as it relates to process metrics and
business events rather than technology considerations. The analysis layer of the
reference architecture provides for these events to be tracked, recorded, and managed.
These events form a valuable view of the performance of the business and, as such,
provide excellent insight into understanding patterns of business operations and the
ability to evaluate them. A facility should also be provided to display the event-related
information in order to support improved management decision-making. In short, the
analytics layer is what enables businesses to refine and improve their operational
business effectiveness (see Figure 3).

Figure 3: Reference Architecture – Analysis

This ability to analyze operations from the business perspective can be particularly
valuable when putting in place necessary compliance measures and processes. Once
the business behavior of the real-time system can be monitored and understood, it
becomes possible to match that behavior to regulatory or corporate policy requirements
in order to detect out-of-line situations. This, in turn, ensures that companies can respond
much more quickly and effectively to compliance failures, mitigating any associated
penalties.

©2006 webMethods, Inc. All rights reserved. Page 10

User Interaction: Incorporating People Into The SOA Equation
The final layer in the SOA reference architecture reflects the fact that modern businesses
have to be highly reactive and agile, and users must be provided with radically
streamlined ways of interacting with business applications. Traditional application
programmers have to understand many complex factors in designing and developing
their applications, based on the fact that business logic is intertwined with technologies
and legacy implementations. But the SOA approach makes it possible for a new breed of
application developers to work in a highly personalized, simplified environment. The user
interaction layer provides facilities that enable the new breed of application developer to
assemble composite applications from a set of uniform building blocks, that is, SOA
services. This can be achieved in a portal-style environment where web applications are
assembled with no coding at all, simply bringing together different SOA services with an
individual portlet.

An effective user interaction layer will enable companies to achieve dramatic time-to-
market improvements for new initiatives, efficiently and without the need for high-cost
specialized skills.

©2006 webMethods, Inc. All rights reserved. Page 11

SUMMARY

SOA offers attractive advantages to companies across all industries as they strive to get
increased levels of return from IT investments while delivering the level of agility that
competitive business demands. The development productivity and quality of service
benefits of reuse offer the potential not just for IT to deliver better service in the near
term, but also to ensure that the benefits increase proportionally over time as levels of
reuse increase. At a higher level, the ability to gain a clearer view of process execution
across the business and to analyze, understand, and act upon this information presents
the opportunity for significant improvements to overall business performance and
effectiveness. Bringing all of this together, SOA enables companies to address new
business challenges with a great deal more agility, quickly composing new business
services without the need for extensive investment or skills.

This level of increased competitiveness is only possible by ensuring that the appropriate
groundwork has been done and that the foundations to support these benefits are in
place. From an IT perspective, the SOA reference architecture is designed as a blueprint
for this foundation, outlining each required layer and its associated capabilities so that
informed decisions can be made about product selection and implementation. These
details may differ between different technology suppliers, but as long as the general
principles of the SOA reference architecture are followed then the likelihood of SOA
success will be greatly increased.

©2006 webMethods, Inc. All rights reserved. Page 12

ABOUT WEBMETHODS, INC.

webMethods provides total business integration to the world’s Worldwide Headquarters

largest corporations and government agencies. webMethods’ 3877 Fairfax Ridge Road
South Tower
flagship product suite, webMethods Fabric, is the only Fairfax, VA 22030
integrated platform to deliver both SOA and BPM, delivering USA
Tel: 703 460 2500
rapid ROI to our 1,300 customers around the globe. With Fax: 703 460 2599
webMethods, customers can take a process-centric approach
to their business problems, allowing them to leverage their
existing IT assets, dramatically improve business process US West Coast
productivity and ROI, and rapidly create competitive 432 Lakeside Drive
Sunnyvale, CA 94088
advantage by making their business processes work harder USA
for their company. Tel: 408 962 5000
Fax: 408 962 5329
webMethods (NASDAQ: WEBM) is headquartered in Fairfax,
VA, and has offices throughout the United States, Europe,
Asia Pacific and Japan. European Headquarters
Barons Court
20 The Avenue
Egham, Surrey
Copyright © 2006 webMethods, Inc. All rights reserved. TW20 9AU
United Kingdom
Trademarks
Tel: 44 0 1784 221700
The webMethods logo, Get There Faster, Smart Services and Smart Processes Fax: 44 0 1784 221701
are trademarks or registered trademarks of webMethods, Inc.

Other product names used herein may be trademarks or registered trademarks

of webMethods or other companies.
Asia-Pacific Headquarters
Statement of Conditions 6 Temasek Boulevard, #24-01
Suntec Tower Four
webMethods, INC. PROVIDES THIS PUBLICATION "AS IS" WITHOUT 15 Blue Street
WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING Singapore
BUT NOT LIMITED TO 038986
Tel: +65 6389 3200
THE IMPLIED WARRANTIES OR CONDITIONS OF MERCHANTABILITY OR Fax: +65 6389 3299
FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL
WEBMETHODS BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF
BUSINESS, LOSS OF USE OR DATA INTERRUPTION OF BUSINESS, OR
FOR INDIRECT, SPECIAL, PUNITIVE, INCIDENTAL, OR CONSEQUENTIAL webMethods Japan KK
DAMAGES OF ANY KIND, EVEN IF WEBMETHODS HAS BEEN ADVISED Izumi Garden Tower 30F
OF THE POSSIBILITY OF SUCH DAMAGES ARISING FROM ANY DEFECT 1-6-1 Roppongi, Minato-ku
OR ERROR IN THIS PUBLICATION OR IN THE Tokyo 106-6030
Japan
WEBMETHODS SOFTWARE. Tel: 81 3 6229 3700
Fax: 81 3 6229 3701
webMethods, Inc. may revise this publication from time to time without notice.
Some states or jurisdictions do not allow disclaimer of express or implied
warranties in certain
transactions; therefore, this statement may not apply to you. www.webMethods.com

All rights reserved. No part of this work covered by copyright herein may be
reproduced in any form or by any means—graphic, electronic or mechanical—
including photocopying, recording, taping, or storage in an information retrieval
system, without prior written permission of the copyright owner.

RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the U.S.

government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of
the Rights in Technical Data and Computer Software clause at DFARS
252.227-7013 (October 1988) and FAR 52.227-19 (June 1987).
©2006 webMethods, Inc. All rights reserved.
The webMethods logo and Get There Faster
are trademarks or registered trademarks of
webMethods, Inc. All other names mentioned
are trademarks, registered trademarks or
service marks of their respective companies.