Next Generation SOA

A Real-World Guide to Modern Service-Oriented Computing

by Pethuru Raj Cheliah, Torsten Winterberg, Bernd Trops, Hajo

Normann, Bertold Maier, Clemens Utschig-Utschig, Thomas Erl
Publisher: Prentice Hall
Published: June 17, 2014

Contents
1. Introduction [This content is currently in development.]................................................4
2. Case Study Background .....................................................................................................5
2.1 Company Background ..............................................................................................5
2.2 System Landscape .....................................................................................................6
2.3 Integration Spaghetti ..............................................................................................10
2.4 Business / IT Partnership .......................................................................................10
3. SOA Fundamentals ...........................................................................................................13
Introduction...................................................................................................................13
3.1 SOA Overview .........................................................................................................14
3.2 Components of a Next Generation Service Oriented Enterprise........................26
3.3 Supporting the Service Lifecycle ...........................................................................31
4. SOA The First 10 Years .................................................................................................45
4.1 History of Service-Oriented Architecture .............................................................45
4.2 State of Technology .................................................................................................47
4.3 Methodology ............................................................................................................54
4.4 Industry Penetration...............................................................................................60
5. Next Generation SOA Technologies.................................................................................64
5.1 Service Implementation with Service Component Architecture (SCA) .............64
5.2 Technology Independent Data Access through Service Data Objects (SDO).....69
5.3 Composition Technologies for Task Services ........................................................72
5.4 Model Driven Software Design (MDSD) and ESB for Standardized Contracts75
5.5 Orchestration Technologies for Automated Processes .........................................78
5.6 Next Generation Business Process Management System (BPMS)......................81
5.7 Service Oriented Business Intelligence..................................................................86
5.8 Master Data Management......................................................................................88
5.9 Event-Driven SOA ..................................................................................................93
5.10 Enterprise Portal.................................................................................................102
5.11 Mobile Computing ..............................................................................................108
5.12 Agent-driven SOA for Awareness and Smartness ............................................ 111
5.13 Semantic SOA for Automation and Dynamism................................................ 112
5.14 Service Virtualization for Simpler Service Plug & Play .................................. 114
5.15 Web APIs.............................................................................................................. 115
6. Next Generation SOA Practices..................................................................................... 119
6.1 Next Generation SOA Principles ......................................................................... 119
6.2 Next Generation SOA Design Patterns ...............................................................147
6.3 Technology Direction ............................................................................................160
7. Next Generation Service-Oriented IT Enterprise ........................................................173
Introduction.................................................................................................................173
7.1 Building a Next Generation SOA Infrastructure ...............................................174
7.2 Next Generation SOA as a Strategic Business Asset ..........................................179
2

7.3 Next Generation SOA-Enabled Business Models...............................................185

8. Next Generation SOA Governance Considerations .....................................................206
8.1 SOA Planning Fundamentals...............................................................................206
8.2 SOA Project Fundamentals..................................................................................209
8.3 SOA Governance Fundamentals.......................................................................... 211
8.4 Governing SOA Projects.......................................................................................212
8.5 Service Information and Policy Governance ......................................................214
8.6 SOA Governance Vitality .....................................................................................216
8.7 Next Generation SOA Governance......................................................................217
SOA Industry Standards ..................................................................................................231
1. Executive Summary ..............................................................................................231
2. What are Architectural Standards? ..............................................................231
3. Industry Standards for SOA ............................................................................233
4. Service Oriented Architecture Modelling Language (SoaML) [2]........240
5. The Reference Architecture (RA) for SOA [3] ..........................................247
6. SOA Ontology ........................................................................................................266
7. The Open Group Service Integration Maturity Model (OSIMM)..............275
8. SOA Governance Framework ................................................................................282
9. A Holistic View of SOA Standards ................................................................285
Conclusion ..................................................................................................................289
References ..................................................................................................................290
SOA Industry Standards ..........................................................................................291
A. Case Study Conclusion [This content is currently in development.]......293
B. The SOA Manifesto [This content is currently in development.]..............294
C. SOA Principles Reference [This content is currently in development.] 295
D. SOA Patterns Reference [This content is currently in development.]....296
E. SOA Governance Reference [This content is currently in development.] 297

1. Introduction [This content is currently in development.]

This content is currently in development.

2. Case Study Background

This book discusses the current state of SOA and its future. Numerous case
study examples are provided to supplement the discussions with some
real-world context. All of these examples relate to the background established
in this chapter. To make navigation easier, light gray shading has been applied
to all case study content subsequent to this chapter.
2.1 Company Background
The upcoming sections provide background information for a case study
covering the Rent Your Legacy Car (RYLC) company. It is a rental car
company with the goal of being one of the three companies in the car rental
segment with the highest turnover in the coming years.
For quite some time, the Management of RYLC has been facing an
increasingly more aggressive market situation. In recent years, RYLC has been
continually losing its market share. The competition was able to offer new
products and better service more quickly, while RYCL could not keep up
because of its slow response to market conditions and its inability to deliver
new system capabilities quickly. To address these main problem points, the
company devised the following approach.
As a unique selling point (USP), a new, high-quality service should be
introduced that would clearly differentiate RYCL from the competition. Both
business and private customers are guaranteed to be supplied with a rental car
at their requested collection point within one hour. If desired, upon arrival to
their final destination, the car can be picked up by a RYLC representative at no
extra charge. If customers pick up or return the car at a rental location
themselves, they would receive a discount.
Until now, the company was represented exclusively through the direct sales
channel at central hubs such as airports, central train stations and ports. In
the future, additional sales channels such as the Web and mobile will be
introduced.
The guaranteed quality of rental cars would be increased through better
monitoring of each vehicles condition (cleanliness, maintenance interval) to
improve customer satisfaction and turnaround times.

Market share could be increased disproportionately by taking over suitable,

smaller competitors.
2.2 System Landscape
As proposed by the CIO, the management first commissioned an external
consulting firm to analyze the actual status of the RYLC system landscape, the
summarized results of which are listed below:
Confusing application landscape, which has evolved capriciously over time
Mixture of very different application architectures (monolithic, client-server,
EAI)
Need for multiple batch runs to compensate for lack of integration depth
Dwindling expertise due to outdated technology and departing employees
No tight controls and governance over master data
No centralized user and rights management
Table 2.1 contains a detailed description of the findings.
Table 2.1. Analysis of RYLC weaknesses.

Figure 2.1 depicts the RYLC system landscape.

Figure 2.1. RYLC has a number of legacy applications that evolved
over time.

After taking inventory, the lead architect and his team analyzed the existing
RYLC system landscape for possible problems and ways to facilitate rapid
implementation of the business strategy described above. The main results of
the analysis are presented below:
The system landscape consists of many legacy applications with a wealth of
uncontrolled connections to the neighboring systems (batch).
The potential for automating workflows and processes cannot be exploited
because of multiple interfaces and protocols as well as inadequate system
integration capabilities.
100% online processing is impossible due to the asynchronous integration
usually via nightly batch runs.
Security is often only implemented within the individual systems and can
only be granted by the IT department. No comprehensive SSO capabilities
exist.
Data is stored at different locations and, in some cases, duplicated. Data
quality differs widely from application to application.
The process that defines access to the customer data is poorly standardized.
It largely exists in the employees heads and in the variety of isolated
applications. Little automation exists.

The aforementioned problems are not new to RYLC. The management has
been trying to overcome them for years. To be able to calculate customer
trends and extract data from the different systems, a data warehouse was
introduced. To improve data quality, a team of students was employed to
manually perform maintenance operations.
However, these measures did not solve the problems facing RYLC, as they
only addressed the symptoms, not the causes. The architecture continued to
prove too inflexible. As a result, about a year ago, the CIO decided to introduce
an integration engine, which was intended to solve existing problems and
some of the integration challenges.
2.3 Integration Spaghetti
The newly acquired integration platform contained a number of key
capabilities that RYLC wanted to leverage, most importantly Enterprise
Service Bus (ESB) and a Business Process Management (BPM) engine. The
ESB contained all the integration capabilities necessary to glue RYLC systems
together. The BPM engine was intended to be used for automating long
running and human-facing processes.
The integration between the car rental application and the CRM system was
implemented using the integration solution as part of a proof of concept. The
rental and sales processes were automated via the BPM engine. The
integration between the automated processes and applications was achieved
via web service adapters. Using a legacy adapter provided by the integration
engine, different functions of the CRM system were orchestrated and accessed
directly. The necessary transformation logic for the data mapping between
different systems was stored directly in the integration definitions.
This approach led to business process logic and integration logic being
interwoven within the BPM automated processes. As a result, the
implemented business processes and their sub-processes were almost
impossible to reuse.
2.4 Business / IT Partnership
Tight coupling between process and integration logic did not support RYLC
goals of growth through acquisitions or faster speed to market. The need to
integrate systems or deliver new functionality quickly could not be achieved in
this situation. Efficiency is difficult to achieve when processes and systems are
10

tightly coupled, as the underlying processes must be fundamentally changed

for each integration or new product introduction.
The problems with the new integration platform showed management that the
solution was too strongly influenced by IT- and application-centric
considerations. In order to address this issue, the lead architect advised the
company to set up an Enterprise Architecture Board (EAB) with an emphasis
on SOA/BPM. It would be empowered to design and govern solutions with a
broad, enterprise wide perspective. The focus of the EAB would be directed at
the important business processes and information, which was spread across
multiple applications and departments.
As a result of establishing the Enterprise Architecture Board, the company
was able to quickly move towards separating process and integration logic,
establishing SOA and BPM strategies and governance mechanisms, creating a
comprehensive system roadmap, and prioritizing IT investments. The
following steps were outlined as a way to achieve the business objectives
outlined earlier.
1. Strengthen CRM integration in the rental process in order to achieve
better data quality for customer satisfaction. Further measures can be
devised on the basis of this data.
To achieve this, the rental application would have to be expanded and the
rental process would need to access services from the CRM application.
The implementation would eliminate the batch interface with the CRM
system, which would improve the quality and concurrency of data.
2. Automate the fleet maintenance process to minimize breakdowns and
increase customer satisfaction.
From a target process view, it would also be necessary to expand the
rental application in order to trigger an automated check within the
buy/sell/repair car application when a customer returns a vehicle. This
check can lead to a service being triggered automatically in the rental
application, which removes the car from the rental process. Services
would be developed to communicate with the buy/sell/repair car and
rental applications.
3. Develop a new sales process that allows customers to book rental cars
via the Web or mobile platforms.

11

To achieve this, the rental application needs to provide the rental process
or its sub-processes a service that can be accessed via the Web. Additional
user and rights management capabilities are required to allow customers
to access this process directly. In addition, a new, channel-specific user
interface could be developed to be used by both internal employees and
customers. This user interface could also be utilized if additional sales
offices had to be served as a result of an acquisition.

12

3. SOA Fundamentals
Introduction
Implementing next generation SOA will fundamentally change the way that
organizations use IT to support their business activities. Many individuals
within each organization will define their activities in terms of services,
though the term service itself will have subtly a different meaning depending
on the context in which it is being used:
To a business executive or business professional, a service corresponds to a
capability or necessary business activity performed either by the organization
itself or a business partner. High-level examples of such business services
include accounting, human resources, or marketing. Business users want the
maximum quality and flexibility of such services at minimum overall cost.
To a business analyst, services represent an elegant and complete way of
modeling the details of how any organization functions. Large-scale business
services, such as those described above, can be broken down into a succession
of smaller subsidiary services representing processes, sub-processes etc, and
decomposed eventually into a number of relatively simple services
representing leaf level business tasks. Many of the services representing
processes, sub-processes and tasks are repeatedly used across multiple
business activities.
To an IT professional, services provide a series of highly
structured contracts that define the interfaces of IT systems that support the
business. Service contracts provide details as to what each service does, how
to use it, what the inputs and outputs are, any error conditions that might
occur, and details of performance, security and availability.
Note
It is a common misconception to equate services with Web Services. Web
Services is an important technology used to implement many services, but
there are alternative service implementation technologies, such as DDS and
REST.

13

In this chapter, we shall attempt to describe how to use a service-oriented

approach, and how it can provide elegant solutions to real business problems
and issues.
How Case Studies Are Used in This Chapter
This chapter will use a case study to outline how a typical organization
might justify a transformation to SOA, how it might go about it, and what
benefits it might hope to achieve as a result.
3.1 SOA Overview
SOA is a Business Architecture
Enterprises, be they commercial or governmental, have to operate within a
highly complex set of forces and constraints, such as market forces, legal and
contractual rules and regulations, budgets, shareholder or public opinion.
To survive and prosper in such a complex environment, organizations form
highly complex organizational structures constructed from elements such as:
Entities such as customers, products, assets, taxes, equipment, employees...
Processes such as manufacturing, sales, HR, payroll, order processing...
Relationships such as provider-supplier, employer-employee...
Domains representing groups of entities, processes and relationships
related to a specific aspect of the enterprises operations
Even a small organization rapidly becomes so complex that it is difficult or
impossible for a single individual to fully grasp the intricate details of how
these elements interact on a day-to-day basis. In order to manage or control
an organization, various executives and professionals work with abstract
models that provide a simplified view, updated regularly to maintain
currency:
Business executives and managers work with an organizational model that
defines the set of operating units and their individual the roles,
responsibilities, goals, obligations and constraints. Abusiness plan outlines a
set of targets and budgets for a specified period.

14

 Business analysts and IT use static entity-relationship (ER) models to map

corporate data and dynamic business process models, such as use cases to
describe their business activities.
In a service oriented enterprise, a single service model can combine all these
into a single consistent and holistic picture of the enterprises operations. In a
service model:
Individual operating units and business partners provide services to each
other. Business partners typically charge for providing these services, while
operating units generally have budgets to support the services they provide to
other units within the enterprise.
Relationships between operating units and business partners are governed
by explicit contractsthat describe the terms and conditions under which the
service provider agrees to perform a specific operation or service for each
authorized service requestor. The services contractual terms and conditions
include definition of the activityto be performed, and which business entities
will be involved, modified or created as that activity is carried out; for example,
a sell products service will involve entities such as customer, order,
and invoice... The contractual terms also include a Service Level Agreement or
SLA that defines when the service will be available, how it will be supported,
any charge for usage, and how long it will take to perform.
The service model is an abstract model that emphasizes the interdependencies
between the operating units and individuals within the organization. This
makes it especially suitable as a tool for assisting the governance and
management of large complex enterprises.
Figure 3.1 below shows a representation of how a business process model, a
business development plan, an organizational model and Business object
domain model can be combined into a single abstract enterprise service
model:
An enterprises business processes define those activities and tasks that the
enterprise has to perform in order to compete effectively in its marketplace
A business process model decomposes these business processes into a
hierarchy of services, each of which represents a service providerperforming
some amount of useful work for a service requestor. Services may range in
size and complexity from long-running complex processes to simple tasks.
15

 The business development plan determines the priority in which the services
in the abstract service model will be realized as physical IT assets. Once these
services become operational, monitoring their individual usage can provide
real-time insight into the vitality enterprises operations, and the degree to
which it is meeting its business targets.
The organizational model helps define the requestors and providers of each
service. Services with many requestors should be given a high development
priority.
The business object domain(BOD) model, which defines the business entities,
maps them to a set of business domains and defines a set of relationships
between business entities, is used to define the inputs and outputs of each
service. Enterprises that use a standard industry model have a huge advantage
when it comes to interoperability with customers, suppliers, and the process
of performing business mergers and acquisitions.
Figure 3.1. Inputs to the Service Model

16

The Enterprise Service Model combines business process, organization and

data models into a single unified view of the business and its development
priorities
As stated above, the enterprise service model itself is an abstract model i.e. a
purely conceptual simulation of how the enterprise operates. This type of
model can be applied to any organization.
A major value of developing such a service model for an enterprise is that
many of the services contained in this model can be delivered directly by IT
assets, using, for example, automated business processes, or as transactional
units of business logic running on an application server.
The set of services that have been physically implemented for an enterprise is
termed the service inventory.
Using a unified service model to define a physical inventory of services to be
implemented as IT assets provides four major benefits:
It provides a common language to allow business and IT professionals to
better understand each others priorities, needs and expectations, helping
achieve the optimum benefit from investment in IT, and helping IT to become
a more valued and trusted business partner than is typically the case in many
organizations.
It encourages the development of IT solutions that map accurately to the
business processes that they support, and providing much more integrated
and holistic support to business activities, enhancing both business efficiency
and its ability to capitalize on new opportunities and respond to new
challenges.
The service approach readily identifies repeated tasks that are common to
multiple different business units and business processes. These reusable
services need only be automated once, avoiding unnecessary duplication and
simplifying the overall complexity of the IT domain. Some technical services,
for example security, monitoring and reporting services, are highly reusable
across all business domains.
Since the physical services in the inventory mirror business processes,
activities and tasks, monitoring their execution can provide a real-time picture

17

of how the enterprise is performing relative to its business targets, in a way

that is generally impossible with commercial applications packages.
SOA as a Technical Architecture
Good technical solutions should comply with a widely recognized set of
architectural principles, including:
Parsimony provide the simplest possible solution that meets all the
technical requirements, adding no unnecessary complexity or unwanted
features.
Componentization construct the solution from a series of modular
components. These components should be reusable, and, if possible,
commercially available rather than custom made.
Separation of Concerns each component should perform a single
function. This makes it much easier to replace or upgrade any single
component without adversely affecting other components.
Layering - when a process involves a series of sequential technical
operations, the components that perform each operation should be grouped
into layers; components in one layer may communicate only with
components in the same layer or a direct neighbor. This makes it easier to
change a component or layer without rebuilding the entire architecture. An
example of a layered approach would be an IT system with a user
interface layer, a communications layer, a task processing layer and a data
storage layer.
While many Web-based systems embrace these principles reasonably well,
most older legacy systems do not. Many commercial application packages, for
example, are monolithic rather than modular and have functionality and user
interface pre-defined by the vendor, which cannot be modified without
extensive customization that makes the whole package difficult to maintain.
Figure 3.2. A traditional Approach to IT connects clients such as
web browsers directly to applications running on servers or
mainframes.

18

The traditional approach to IT was to deploy a series of application packages

to perform specific business tasks. This is not a layered architecture; for
example, each application package typically manages its own security, user
interface, business logic and data.
While it is possible to perform some limited integration between applications,
this has to be performed on a point-to-point basis, requiring expensive
customization that leads to maintenance problems when new releases of
commercial packages are issued, and customization activity needs to be
repeated.
Since the application packages support specific business tasks, this approach
often leads to the development of application silos in large organizations,
where each business unit maintains its own dedicated set of application
packages, making it difficult or impossible for their IT systems to integrate
with the enterprises other business units and business partners.
SOA, however, does embrace the four architectural principles described above
and makes it much easier to provide consistency and ease of integration of
systems, not just within an organization, but also with its customers and
suppliers.

19

To enable this, SOA adds eight additional architectural principles. The formal
definitions of these are listed below, with explanatory notes in braces:
Standardized Service Contract Services within the same service inventory
are in compliance with the same contract design standards (e.g. they are based
on a single consistent business model).
Service Loose Coupling Service contracts impose low consumer coupling
requirements and are themselves decoupled from their surrounding
environment (i.e. their use is independent of the technology platforms of
either the service consumer or service provider, allowing, for example, .Net
clients to use services implemented in Java and vice versa)
Service Abstraction Service contracts only contain essential information
and information about services is limited to what is published in service
contracts (the service contract contracts does notdefine any details of how the
service will be implemented giving the IT department the ability to change
the technical implementation of the service in the future, provided they can
still honor its contractual terms).
Service Reusability - Services contain and express agnostic logic and can be
positioned as reusable enterprises resources (i.e. services do not represent
tasks that have to be executed in a specific sequence, and each service can be
executed as a completely separate unit of work. This both simplifies their use,
and enables the service provider to deploy multiple separate physical
instances of a service within their network).
Service Statelessness Services minimize resource consumption by
deferring the management of state information when necessary.
Service Discoverability Services are supplemented with communicative
meta data by which they can be effectively discovered and interpreted (so that,
for example, a new user can locate, bind to, and execute any service that they
are authorized to use, without being explicit enabling action from the service
provider. This enables dynamic runtime discovery and execution of services).
Service Composability Services are effective composition participants,
regardless of the size and complexity of the composition (i.e. in order to
perform the desired action, a service may invoke any other service or services
it chooses)
20

Note
these are described in detail in the book SOA Principles of Service Design
In a service-oriented approach, service requestors and service providers
interact using a standardized set of service interfaces. Service requestors and
service providers can be individuals, applications, automated or manual
processes, or other service requestors or providers.
This approach provides superior levels of intercommunication between
business professionals, applications, business units, and business partners
that can help improve the organizations overall flexibility and business agility.
Application packages still exist in the service-oriented IT model and remain an
appropriate primary tool for clerical tasks and specialized activities such as
word processing; functionality from some applications may also be exposed
through service interfaces, to make it more generally accessible.
Compared with an application-centric approach:
Services provide much more flexibility in how technology supports business
processes
Services provide much more modular access to IT functionality
Services provide any-to-any connectivity between requestors and providers;
any service provider may also make requests to other service providers to
fulfill the terms of its contract.
The SOA infrastructure implements a layered architecture that handles
security, monitoring of delivery quality and routing of requests to the most
appropriate provider resource
Services should use a consistent information model to represent any
business entity involved in their execution. If an application package or
database acting as specific service provider uses a different format for one or
more business entities, a component within the SOA infrastructure called
the Enterprise Service Bus or ESB handles most data transformation, making
the process completely transparent to the service requestor.
Unlike applications that require their end users to establish some form of a
session, the majority of services are transactional. The ESB routes each service

21

request to the most appropriate instance of a service provider, then returns

the response back to the requestor. The service requestor is not informed of
(and does not need to know) any details of the resources that were used to
satisfy their request.
Figure 3.3. A Service Oriented Approach to IT allows any-to any
connection between service requestors and service providers

Figure 3.3 above shows how SOA takes a more layered approach to its
technical architecture. Note especially the symmetry between the set of service
requestors on the left and the set of service providers on the, right,
demonstrating the way SOA provides any-to-any connectivity.

22

The four layers have the following characteristics:

The Service Requestor is a software construct, such as a PC, server or
mainframe application, acting on behalf of an end user or an automated
business process. Logic within the service requestor assembles the data
needed for the service request, packages it into the appropriate message
structure, then transmits it to the service end point located on the service
interface layer. Once the service has been executed, the service requestor also
has to parse and interpret the response.
Details of the structure of the input and output service messages and
the location of the service logical end point are part of the service
meta-data. Mostenterprises use a commercial service registry to store
and publish their service meta-data. While the process of assembling
and parsing service messages may sound complex, code to perform
these actions, in, for example, Java or .Net can readily be generated
automatically from the service meta-data.
The entire process of service discovery, binding, execution and handling
the response can be completely automated, making it possible to create
a highly dynamic service environment.
The Service Interface provides the sole view of the service visible to the
requestor. The Service Interface contains sub-layers responsible for:
Providing an end point (i.e. a URL address) to allow requestors to
access each service.
Maintaining service security, including encryption/decryption,
authentication of the requestors identity, establishing and
controlling their level of access.
Monitoring the execution of each service request to ensure that all
services fulfill the contractual terms set out in the Service Level
Agreement that concern its availability, performance and reliability.
Recording details of all service executions, both as an audit trail,
and to monitor service usage.
The Message Routing and ServiceMediation layer is responsible for:
Selecting an appropriate service provider and routing messages
between the service provider and the service end point.
23

 Protocol transformation between the service requestor and the

provider application
Generally, a commercial Enterprise Service Bus product is used to
perform both of these activities.
Service Providers may be almost any IT or human asset that can perform
useful work or that needs to be notified of a specified event. For example:
Function provided by a third party, such as a customer,
supplier, a commercial service provider, or a cloud computing
application, typically implemented as a Web Service.
A Manual Process or Activity performed by a human operator;
typically these are either manual steps or requests for management
approval within a process whose overall execution is managed by an
automated Business Process Execution Language or BPEL model.
An Automated Process or Sub-process initiated bya message
from an authorized requestor.
A human or IT system that needs to be alertedby a business or
systems management event
Mainframe or Server Applications that act as service
providers, or that are initiated by business or systems management
events
Databases that act as service providers to services that read or
write data directly
Services that provide some useful function within the execution
of more complex compositeservices
Utility Services that contain no business logic but that perform
useful common tasks, such as printing, email distribution....
Note that there is complete mirror symmetry between the left and right sides
of Figure 3.3. A given software construct or node may act as a service provider
in some activities, and as a service requestor in others.
Enterprise Architecture and SOA
Enterprises embarking on an SOA journey typically will benefit from having
an Enterprise Architecture (EA) program in place. This is because SOA and
EA cannot be easily separated. From a high level, SOA is a subset of

24

Enterprise Architecture, even through some of its elements lie outside of EA

jurisdiction. This relationship, depicted in Figure 3.4, indicates that without a
strong Enterprise Architecture program in place, SOA cannot be truly
successful.
Figure 3.4. SOA is a subset of Enterprise Architecture

One aspect of service orientation is that it represents a style of realizing an

enterprise architecture approach to design, development and operation of IT
solutions. While it is not the only style that can be used to implement EA,
many organizations are now convinced that it is the optimum approach.
As well as enforcing separation of concerns through the creation of services
that provide a shareable resource to perform common functions for any
requestor, SOA decouples consumers and providers of business and technical
function. This enables rapid yet transparent change of a backend
implementation of any IT system. This has a significant business value when it
comes to replacing obsolete IT solutions, or when merging IT systems as part
of a business acquisition.
SOA represents a complete end-to-end style of implementing EA. Unlike the
traditional IT software development style that focuses on coarse-grained
software assets, such as commercial product implementations or application
development projects, SOA style focuses on supporting an optimized set of
more fine-grained services through a complete cradle to grave lifecycle. A
service oriented enterprise will typically have many services under design,
construction, testing, deployment, operation or retirement at any given time.

25

3.2 Components of a Next Generation Service Oriented Enterprise

Next generation SOA creates a complete eco-system that integrates and
supports both business and IT assets and operations, providing full
integration between business objectives, processes, standards, rules,
governance, and IT infrastructure and assets.
Business Assets of a Next Generation SOA Enterprise
The primary physical components of a next generation SOA enterprise are a
business heat map, aninformationmodel, a service model and the service
inventory:
A Heat Map defines the core business priorities and is used to determine
the sequence in which the service model and service inventory are to be
constructed. A heat map consists of a matrix where the columns represent
operating units within the business and the rows represent principal
capabilities or activities of that operating unit in other words the high level
services that unit consumes. Cells within the heat map are colored to indicate
the perceived priority or importance of that capability or service. Figure 3.8 in
the case study at the end of this chapter contains an example heat map for the
RLYC company.
An Information Model determines how business entities should be
represented when they are exchanged between service consumers and service
providers.
For a manufacturing company such as RYLC, the informationmodel
would describe business entities such as customer, vehicle, rental
agreement, service history etc. Services that access any of these entities
should ideally conform to the e format defined in the information
model.
Enterprises should base their Informationmodel on an industry
standard model, to make it easier to integrate their custom services
with third parties such as business partners.
The Service Model was described in Section 3.1 above. Development of the
service model should start with the high-level services defined as being
priority areas in the enterprise heat map, which are then decomposed into
progressively finer-grained services representing business activities, processes

26

and tasks. Conceptual services in the service model should document any
business entities are involved in their execution.
The Service Inventory contains the set of services from the service model
that have been physically realized as IT assets, either purchased commercially,
developed internally, or provided by third parties. The service inventory is a
subset of the service portfolio, which includes services that are planned to be
developed, and services that have been retired or re-versioned as well as
operational services. The sequence for adding candidate services to the service
inventory should be determined by a combination of their business value,
implementation cost, and reusability across the enterprise and its business
partners.
Software Components to Support SOA
SOA is maturing rapidly, and many commercial software packages, both
closed and open source, exist to support the development, testing and
operation of services. Figure 3.4 below shows a simplified view of a typical
SOA environment. SOA implements a tiered architecture, where the three
tiers
are
the client tier,
the middle tier,
and
the Enterprise
InformationSystems Tier.
The client tier contains the service requestors, the Enterprise Integration
Systems tier contains major business applications and databases, while the
middle tier contains the code to route and transform messages, manipulate
data, and coordinate and monitor service execution. The business logic for a
service may reside in either the middle tier or the EIS tier, depending on the
nature of the service requestor.
Fig. 3.5. A Typical SOA Environment Implements a 3-tier
Architecture

27

Most SOA enabled enterprises use commercial middleware packages to

perform some or all of the logical functions shown above. The purpose of each
of component is as follows:
Web Servers
Web Servers act as the service interface layer depicted earlier in Figure 3.3.
Their role is to:
Act as the service endpoint i.e. provide a physical URL for the service
Handle security, including identity management, authorization and message
encryption/decryption
Caching frequently-accessed content
Message protocol bridging
SLA Monitors

28

These tools continuously monitor the quality of service delivery, in terms of

availability and performance, providing real-time alerts in the event of SLA
violations
Service Registry
The service registry provides an accessible catalog of the enterprises services,
enabling authorized potential consumers to locate and bind to services. It also
contains the metadata that describes the service contract, both in terms of the
formal contract that defines the input and output service messages and the
terms and conditions of the associated SLA.
Some vendors combine their service registry product with a service
repository that contains all the code and metadata associated with each
service; other vendors supply these as two separate packages.
Application Servers
An application server is a piece of system software that provides an execution
environment for applications and service business logic. Application servers
provide a set of utilities to help generate and execute service code, providing
access to system resources such as memory and processsor management,
loading and unloading of pre-requisite software modules, management of
state data and systems management and monitoring.
Some services run entirely on an application server, while some execute code
for the service business logic on the application server, but obtain some or all
application function or data from IT resources in the EIS layer.
Application servers also provide an execution environment for BPEL
execution engines that enable executable business models to operate and
communicate with other business systems, services and end users.
Since it provides a generalized execution environment, some of the
components of the SOA infrastructure, such as the ESB, SLA monitor or the
service registry are likely to also to run on an application server. In practice,
most enterprises have multiple networked application servers.
Enterprise Service Bus
The Enterprise Service Bus or ESB may be either an architectural approach or
a software package or to provide complete interconnectivity between service
29

business logic components, service requestors and service providers. This

interconnectivity is achieved through a combination of message routing and,
where necessary, transformation of data formats between the message
originator and the messsage receiver. The ESB supports multiple instances of
service requestors, either to provide availability and resilience, or to provide
premium levels of performance for critical consumers.
Service Development & Testing Kits (SDKs)
There are several vendors who provide sophisticated tools for assisting the
analysis, design, development, testing and deployment of services, for a range
of differing technologies. These tools ensure commonality of approach as well
as providing major productivity enhancements.
SOA Governance Automation Tools
Several vendors now provide products that automate several aspects of SOA
governance, such as providing automation for the workflow of governance
processes, provide an audit trail across the entire life of each service, and
automate policy compliance testing.
Business Process Management
This component is responsible for executing automated business processes,
and for maintaining state information for any long-running processes.
Typically these business processes are implemented as executable Business
Process Execution Language (BPEL) models.
Business Rules Engine
This component evaluates business rules in a production execution
environment. Business rules may represent business or governance policies,
workflow decision points, or what action to use in the event of a business
event,
Cloud Computing Platform
This component enables the enterprise to either use or deploy IT assets in a
cloud computing environment.

30

3.3 Supporting the Service Lifecycle

The life of all services follows a similar pattern beginning with an original
concept, then passing through a series of phases leading to realization of the
service as a functional IT asset. Eventually services that become obsolete will
need to pass through a further phase where they are discarded or replaced.
The complete set of phases in the lifetime of a service is termed the service
lifecycle.
In this section, we shall describe the phases in this service lifecycle and outline
the techniques and skills that best support them.
Fig. 3.6. the service lifecycle is supported by a rich technical
environment, especially for service design, development and
deployment.

31

Commercial software tools help to provide an integrated environment to

support the lifecycle of identification, development, deployment and version
management of an optimal set of services. In addition to the tools depicted
above, there are multiple commercial tools available to support requirements
analysis, service and business modeling and automated testing.
The Importance of SOA Governance
While some enterprises have achieved great results with SOA, quite a few have
struggled to make much impact. Enterprises thatdo succeed with SOA are
invariablytheones that have implemented an effective approach to governig
SOA. SOA governance is the process by which the organizations efforts
towards SOA transformation are planned, aligned, nurtured and controlled.
This complex topic includes:
Establishing a set of architectural standards, management policies and best
practices to facilitate transformation to SOA and maximize its impact on the
organization
Ensuring that there is an organziational structure, such as a Center of
Excellence group to support the initial move towards service orientation
Ensuring that there organization has all the necessary skills to succeed with
SOA
Establishing a consistent approach to supporting the service lifecycle,
including regular quality inspection points, and full functional and
performance tests along the analysis, design, development, deployment and
operations stages of service realization, as well as a well organized approach to
their later update, retirement or replacement if necessary
Ensuring that the scope and quality of the heat map, informationmodel,
service model and service inventory are at the optimum level, and that there
are suitable resources to maintain them
Establishing, monitoring and enforcing a set of Service Level Agreements
between service requestors and service suppliers to ensure the quality of
delivery of services continually meets or exceeds acceptable standards
Ensuring the vitality of the technical infrastructure and tools needed to
support SOA
32

 Monitoring and reporting service usage, status, and the current overall
impact on business profitability, flexibility and agility
Note
SOA Governance is covered in detail in the book SOA Governance in this
series
Initial Preparation
The end goal of next generation SOA is to ensure the success of the enterprise
by integrating IT infrastructure, SOA, IT and corporate governance,
automated and manual business processes and software assets to provide the
best possible support for its business goals and objectives.
This integrated approach needs to be constructed on top of firm foundations.
These include:
Effective corporate and IT governance: Its difficult to implement SOA
governance succesfully unless there is an established base of governance, both
at a corporate and IT level. This would include the existence of a formal set of
corporate policies, rules and regulations that control working practices, a
clearly defined set of responsibilities, authorization levels and permissions,
together with an organizational structure, such as a Program Office, to enforce
them and to allow exceptions to the rules in rare cases when it is absolutely
necessary.
As well as having its own set of well-defined roles and responsibilities,
IT governance should include policies that determine how projects will
be prioritized and funded, how systems and end users should be
supported, and how capacity should be managed.
An Existing Architectural Approach to IT: Its virtually
impossible to impliment SOA succesfully unless the enterprise is
already committed to taking an architectural approach to IT.
Evidence for such an approach includes the existence of:
Architectural standards that define the enterprises authorized
list of applicable technology and techniques. These should be more
open than vendor-dependent standards.
Architectural Principles to which new IT systems or solutions
must conform
33

 A Formal Design and Development Methodology that

documents all aspects of IT projects, such as the architectural
decisions and their rationale, detailed requirements, design
specifications, test plans and results, and approach to deployment of
IT systems
A Model Based Approach to systems development. For
example, the enterprise should be commited to using formal
Entity-Relationship and/or data models for systems development.
These should be based on a standard industry model, with minimal
customization
A set of design patterns and best practices to ensure
consistency of approach across all designers and developers
An Architecture Board that meets regularly to establish and
maintain all the above items, with power to enforce compliance to
them
Executive Commitment to Service Orientation: For an organization
to fully embrace SOA, it must be prepared to make some major changes to its
approach to prioioritizing and funding IT projects, ownership, access and
support of IT assets, and the way that different business units within the
organization interact and intercooperate. This level of change will not occur
without full executive commitment to implementing SOA. Under the radar
implementations of SOA by an IT department exploring the technology are
unlikely to lead to real business benefit.
Investment in SOA Infrastructure: For an organization to fully
embrace SOA, it must be prepared to make some major changes to its
approach to prioioritizing and funding IT
The Service Discovery and Analysis Phase
If the service is to be of real value, it must be based on a real business need.
Using a business heat map to establish the priority high-level services is a
good way to ensure that the service inventory closely reflects the real business
priorities.
Constructing a full service model for an organization requires a considerable
amount of skill and effort, so its development should be phased, starting with

34

the heat map priority capabilities, then decomposing them progresssively into
a set of services representing sub-pocesses, sub-process, tasks and so on...
The set of candidate services derived from this approach is likely to grow
rapidly, and few enterprises are likely to have sufficient resources to rapidly
implement all of them, so it is vital to prioritize their development. The first
services to be developed or purchased should be those that:
Have high business benefit, and
Have low development or purchase cost, and
Are reusable across multiple business units
In the first instance, when requirements analysis is incomplete and design has
not even started, such an assessment will be mainly subjective, but it should
be possible to triage the list of candidate services to a more manageable set
small enough that their requirements can be analyzed in more detail.
A key aspect of SOA is to create reusable services that support the whole
enterprise, rather than build functional silosspecific to each business
operating unit. While it would be unreasonable to expect to identify and
satisfy the needs of all potential users for each candidate service, competent
business analysts should be able to identify many of the instances where
separate business units share a common functional need that could be
implemented as a shared service.
The end product of the service discovery and analysis phase should be a set of
prioritized candidate services, each of which has a detailed set of requirements,
a definition of who should be authorized to utilize it, plus any modifications it
requires to the standard set of SLAs. Good SOA governance requires a formal
review at this stage.
The Service Design Phase
The principal software toolsthat support this activity are the service
registry/repository and business process modeling tools. Typically, this phase
is split into two segments, high-level design and detailed design:
High-level design involves activities such as deciding on the optimum
technology to create the service, what standards it should embrace, and which
35

design patterns should be used to construct it. Design patterns represent tried
and tested approaches for solving specific types of business or technical
problem; see the book SOA Design Patterns for more detail on this topic.
At this stage, a decision should be made on whether it is feasible to
continue with realizing the service provider, and, if so, how it will be
sourced. Options include: purchasing from a commercial vendor,
constructing it using existing modules or creating it from scratch.
Next generation SOA provides a wealth of possible technology
platforms for creating and deploying services, including:
Web services, DDS and REST for simple transactional services
Business Process Management and business rules engines for
business process automation
Automated event management to respond to business-related or
systems management events
The ability to move some or all responsibility for service execution
to or from the cloud
The outline design should be assessed to determine whether the service
is likely to be capable of meeting the performance targets contained
within its SLAs.
The high-level design should also specify how security, monitoring and
systems management will be performed for the service.
Detailed Design involves defining the business logic for the service, and
specifying what, if, any data transforms are needed to convert between the
format used by the service provider and the format defined by the
informationmodel.
It is appropriate at this stage to create a detailed test plan and a set of
test data for the service to be used during service development to
confirm the validity and performance of the service as it is being
developed. The complete set of error messages that the service might
return should also be defined at this stage.
Formal SOA governance reviews should confirm that these two steps have
been completed succesfully before the service is passed to the developers.
The Service Development Phase
36

This is the phase where the actual service is constructed and unit tested. The
development approach for each service will depend on the technology selected
for its implementation. In virtually all cases, the quality and consistency of
code development can be improved, and associated development costs
reduced by using commercial System/Service Development Kits or SDKs that
automate the development process, as well as the service registry/repository
and code repository tools shown in Fig. 3.6 above.
Virtually all these SDKs adopt a model-driven approach, where the designer
or developer works with a visual model of the service artifact, progressively
refining it to the point where the physical source code can be generated
automatically.
For some service technologies, for example Web Services created in Java ,
some further physical programming may be required to add business logic to
the generated code, but in many other cases, the complete source code for the
service can be generated directly from a model. Fully functional BPEL, a
language in which executable business processes are written, forexample, can
be directly generated from a process model, BPMN, or a business process
modeling tool.
Functional unit testing is an integral part of service development. A good
practice is to implement code walkthroughs where the physical code for each
service is peer reviewed. This process helps to spot deviations from the
required standards or design patterns, helps ensure a consistency of coding
standards and approach, and also acts as a means for mentoring the more
junior developers.
Service Testing Phase
In this phase, services are subject a rigorous suite of functional and
performance tests to determine all aspects of service quality. The enterprise
needs to establish separate physical environments for functional and
performance testing that emulate a real production environment. If the
service fails any test, it is returned to the developer for rework, and, once that
is completed, the service should again be subject regression testing i.e.
re-applying the complete battery of tests to ensure its integrity.
Many commercial tools are available to help automate service testing; these
are especially useful for regression testing.

37

The final test in the series is an acceptance test, where the IT operations group
confirms that the service is not only functionally correct and meets its
performance SLAs, but that it can be systems managed and monitored in a
production-like environment.
Service Deployment Phase
The physical deployment process of a service depends on its development
technology and the physical environment in which it will execute. The
objective of service deployment is to ensure that no service is deployed to
production that might damage either the production environment or the
reputation of the service developers.
In a deployment phase, a collection of related services, known as a
deployment unit, is moved into an environment that emulates the production
environment in all respects, where it is subject to simulated traffic. This test is
to check for memory leaks (modules that acquire computer memory resources
but fail to release them once they complete) that could cause problems over an
extended period. This simulated operational period is sometimes known as
soak.
Once a service or deployment unit passes the soak test, there should be a
formal SOA governance certification review, to confirm that the service is redy
in all respects for accredited requestors to begin using it.
Service Operational Phase
This is the working phase of the services life. Every time a service is executed,
an audit trail should be kept to record:
The service requestor
Which service provider handled the request
The date and time
How long the service took to execute
Whether the service completed normally or returned an error code
The physical details of how this information is recorded depend on the service
technology and the production environment. For example, monitoring of Web
38

services can be performed at the Web Server, while automated business

processes have to include their own execution statistics recording.
Such event-level monitoring can provide invaluable data on the volume of
business transactions, helping executives and management obtain a real-time
view of how well the enterprise is meeting the targets in its business plan.
Numbers of service executions and growth in the number of individual
requestors can provide real information on the impact SOA is having on the
business.
In the event of a service failing to meet its SLAs, a systems management event
should be raised to recitfy the problem urgently.
Service Retirement
However carefully the services are designed and implemented, inevitably
some of them will eventually require maintenance or replacement. If this can
be done without violating the service contract (when changing the physical
service povider, adding additional functionality, or returning additional
output data, for example) then the physical service can be replaced at any time,
subject to complete regression testing and certification.
In the event that the terms of the service contract can no longer be maintained,
the enterprise must deploy a new version of that service. One of the important
SOA governance policies is to determine how this versioning process is
managed. This policy should define:
Will requestors will be required to migrate to the later version, and if so, how
much time will they be allowed to take?
How many versions of a service are allowed to be in production at any one
time?
How will requestors be informed of service version changes?
Fortunately, the service metrics collected in the operational phase of each
service allow the identities and individual usage of each service requestor to be
tracked.
Case Study Example

39

RYLC first created a business heat map to help create a consensus on the
priority business issues:
Fig. 3.7. RYLCs heat map established their principal business
priorities.

The highest priority area was customer relations, which urgently needed
improving since it was adversely affecting profitability; joint second
priorities were vehicle maintenance (which was a contributor to the
customer relations issue) and the provision of a new Internet sales channel.
RYLC then began creating a conceptual service model of these priority areas.
Two high-level services were immediately identified:
A customer profile service that would provide a single point of contact
for accessing, updating or creating all stored information about each customer,
including vehicle preferences, home address, driving license and credit card
details
A vehicle profile service that would provide a similar service for each
vehicle, including vehicle history and information about when the vehicle is
due for servicing
For each of these services there would be associated operations to search for,
create or edit matching profiles. Both of these services would be highly
40

reusable by multiple IT systems, and were crucial to creating the new

Internet sales channel.
Currently, thenecessary customer and vehicle data was scattered across IT
multiple systems, with much duplication of information, and these
disparate systems often had conflicting data. Muchvehicle and customer
information wasmaintained at the RYLC location that operated the vehicle
or where each customer rented a vehicle. This meant that some customers
might have conflicting profile information stored at multiple RYLC rental
locations, and the history information of vehicles rented at one location and
returned to another would be fragmented and incomplete.
Originally, the rationale for maintaining local data was to ensure that each
RYLC location could continue to function during a communications outage,
but now RYLC recognized that the use of alternative communication
channels (broadband, dial-up, wireless, cellular) made such outages
extremely rare.
RYLC had already tried to address these incompatibility issues by
employing a part-time team of students to manually correct the records, but
the scale of the problem was too large for this to succeed.
RYLC decided to implement new customer and vehicle profile services,
delivered over a private cloud to provide high availability. While vehicle
history information could be obtained by reconciling information from all
the RYLC rental locations, reconciling any conflicting customer profiles
could not. The option of scrapping all the existing customer informationand
starting again with a new clean set of profiles was immediately ruled out
because of the inconvenience that approach would cause to all existing
customers who would have to repeat all their details to a call center
operator.
Fortunately, the newly-appointed lead service architect, Ken Graham, came
up with an innovative and elegant solution, that addressed all the customer
profile migration and integrity issues, and provided a simple migration path
away from the current set of multiple inconsistent data silos.
In his approach:
A new cloud customer profile service to query, enter and maintain
customer profiles was created and implemented on a private cloud. Initially,
this cloud-based profile store was empty.

41

A new composite customer profile migration service was created to

assist the gradual migration of customer information to the new
cloud-based profile store. This migration service would be invoked
whenever a cloud customer profile search returned no hits for a RYLC
client. This customer profile migration service would then:
Invoke a series of subordinate services that wrapper legacy RYLC systems to
determine if any of them contain information that matches the customer
search criteria, then return any matching records to the RYLC staff member
serving that client.
If no matching records are found, the client must be a new customer, and
the profile migration service invokes the interface to the cloud
customer profile service, to allow the staff member to record the profile
of the new customer.
If a single matching record is found, profile migration service invokes
the interface to the cloud customer profile service to allow the staff
member to determine that the profile is valid and up-to-date, make any
necessary changes, then store it as a new entry to the cloud customer
information store
If multiple customer records are found, the profile migration
service displays the set of matching records to allow the staff member to
select the most valid record (if any), then invokes the interface to the cloud
customer profile service to allow the staff make any necessary updates,
then store it as a new entry to the cloud customer information store
The elegance of this approach lies in the fact that it ensures the accuracy
and integrity of information of the cloud profile information store, while at
the same time making a minimal impact on existing RYLC customers; each
customer is asked to verify their profile information only once, the first time
they do business with RYLC after the new cloud based profile service is
implemented.
This approach migrates existing customers to the new service gradually, and
efficiently, without the need for a sudden death switchover to new
technology. This makes it much less risky and reduces its impact on IT
resources.
Fig. 3.8. Flowchart for the customer profile and customer profile
migration services

42

For the technically minded, this solution uses several of the patterns
described in the SOA Design Patterns book in this series, including:
The multi-channel endpoint design pattern which coordinates multiple
physical sources to provide a virtual service provider
The legacy wrapper pattern which hides legacy systems behind a structured
service faade
There were some technical issues in creating legacy wrappers for some of
the legacy systems, but the new cloud-based customer and vehicle profile
services became operational in around four months. They were an instant
success, and RYLC surveys showed a steady increase in customer
satisfaction and returning customers.

43

The design team for the new Internet rental channel was involved in the
details of the design of these two services, which also represented the
foundation for the development of the new RYLC customer website.
Summary of Key Points
Next Generation SOA represents a holistic approach for delivering IT
support to the enterprise in a manner that enhances its productivity, flexibility
and agility.
Next Generation SOA adds new technologies such as Business Process
Management, Business rule execution engines, SOA governance automation
and Cloud computing
Good governance practices should ensure that business needs analyzed and
prioritized to define the most cost effective order for service development and
deployment
To develop and deploy service most efficiently, enterprises should
implement a production line methodology that comprehensively governs and
supports and each service through its entire lifecycle from the original
conception, through a series of analyses, prioritization, contract and internal
design, testing, deployment and re-versioning or retirement.

44

4. SOA The First 10 Years

Today, there are very few people in the IT industry that have not heard about
service-oriented architecture. In fact, many savvy business leaders are also
familiar with SOA. In the last ten years, SOA has gained a significant
momentum, industry support, and adoption. Indisputably, it has become a
mainstream component of almost every IT organization. SOA has helped
transform many businesses to make them more efficient and agile. In this
chapter, we will discuss the evolution of service-oriented architecture and
examine where it is today.
How Case Studies Are Used in this Chapter
Case studies in this chapter will describe what existing SOA platforms and
methodologies Rent Your Legacy Car (RYLC) company has employed to
date. Since RYLC has embarked on a significant SOA transformation, it has
been able to adopt a number of SOA technology solutions and approaches,
which we will discuss in more detail.
4.1 History of Service-Oriented Architecture
The term Service Oriented Architecture or SOA was first coined by Gartner
analyst Yefim V. Natis in his research paper published on April 12, 1996. In it,
he defined SOA as a software architecture that starts with an interface
definition and builds the entire application topology as a topology of interfaces,
interface implementations and interface calls. SOA didnt get much traction
until 2001 when web services technology became widely adopted. In many
respects, web services gave SOA the foundation it needed to become widely
accepted.
Widespread adoption and industry recognition typically results in significant
amount of hype. Service-oriented architecture did not escape this fate. It
quickly became the domain of vendors trying to capitalize on the hype.
Commercial products such as UDDI registries and Enterprise Services Buses
started appearing in and around 2001. Many vendors began promoting their
SOA solution suites. Shortly thereafter, UDDI registries evolved into Registry
and Repository products that provided a more comprehensive view of existing
services.

45

The advent of Business Process Management term, or BPM, added yet

another dimension to service-oriented architecture and its vendor landscape.
While this was not a new technology, the term was. Like everything else that
was new and shiny, BPM generated a significant amount of hype, which, in
turn, helped prolong the hype associated with SOA. Incidentally, the term
BPM was arguably first invented by another Gartner analyst, David W. McCoy,
in 2000.
Gartner did not stop there. It went on to postulate such terms as Event-Driven
Architecture (EDA), Web Oriented Architecture (WOA), Web 2.0, Cloud
Computing, and others that were not as successful. While Gartner did not
invent the technologies, its analysts were able to recognize the trends and
aptly name them. This focus and new, exciting terminology helped keep SOA
well hyped and at the forefront of IT efforts.
Unfortunately, the economic meltdown that hit the USA in late 2008 and the
entire world shortly after put a damper on SOA activities and, in large respect,
helped transition SOA to its current state. The investment into strategic,
transformational initiatives, such as SOA, largely ceased as a result. The hype
disappeared with the bleak economic outlook. As a result, SOA has become a
widely accepted component of business and IT strategies and is no longer
called out as a single, unique differentiator.
Figure 4.1. Service-oriented architecture evolution followed a
typical hype cycle in the past 10 years.

46

Figure 4.1 represents a historical evolution of service-oriented architecture

modeled after a well known Gartner Hype Cycle. Today, SOA can be squarely
placed onto the Slope of Enlightenment moving quickly towards the Plateau of
Productivity.
4.2 State of Technology
The technology landscape supporting service-oriented architecture has
evolved significantly since its early days. Today, there is a number of major
technology platforms supporting service orientation in the enterprise. They
include:
Enterprise Service Bus (ESB)
Registry / Repository
Run-time Management
SOA Testing

47

A variety of other tools and technologies that are emerging now or are related
to emerging service orientation trends are covered in the subsequent chapters.
In this section, we will discuss only those technologies that have been well
established or widely recognized. It is important to note that most of SOA
vendors today offer an integrated technology stack that contains most, if not
all of these capabilities.
Enterprise Service Bus
The Enterprise Service Bus technology was the first player in the SOA market.
It generally evolved from the integration middleware. However, the ESB
vendors that exist today have taken different paths to establishing their
products. These approaches can be summarized as:
Building a product from scratch
Adding SOA capabilities to an existing integration platform
Adding integration and message routing capabilities to an application server
platform
Acquiring and building on other products
Many books and articles have been written about ESB capabilities, usage, and
benefits. We will not recap them here. However, to capture the current state of
the Enterprise Service Bus technology, it is worthwhile to understand where
the natural product evolution cycle is today.
ESBs remain the centerpiece of many service-oriented architecture
approaches. They are primarily used as real-time and asynchronous
communication hubs between various systems providing and consuming
shared services. Figure 4.2 contains a generalized depiction of an ESB
platform and its capabilities.
Figure 4.2. Enterprise Service Bus platforms provide a variety of
capabilities to their consumers.

48

In general, ESBs offer the following capabilities:

Message routing routing synchronous and asynchronous calls to the
appropriate parties based on explicit protocol, defined rules, or message
context
Transformation translation of messages from one format to another
Mediation reconciliation of security credentials, protocols, and technology
stacks
Orchestration combining a variety of services together to create a
composite service
Instrumentation logging, alerting, monitoring, auditing, and other
management capabilities
In addition to the capabilities described above, some ESB products also offer
Business Process Management, process choreography, policy management,
SLA enforcement, event processing, and business activity monitoring
functionality.

49

Registry / Repository
The Registry / Repository (RegRep) platforms and their capabilities have
been covered in great detail in the Service-oriented Computing Series SOA
Governance book. It is, however, worth describing the history and current
state of the Registry technologies.
Registries first appeared around 2001 when Web Service standards were
introduced. The initial incarnation of this technology was the UDDI registry.
It enabled registration and discovery of web services, based on UDDI and
WSDL protocols. The functionality was generally limited to registering WSDLs
with the registry and allowing users to discover them at design- or run-time.
UDDI standards evolved over time, added some additional features, and
expanded beyond web services. Unfortunately, UDDI never became widely
adopted due to lack of key features supporting the SOA lifecycle and related
technology platforms.
This gave rise to the new breed of registry products that included capabilities
to store, manage, and publish service metadata, govern the lifecycle of these
services, and integrate with many elements of the SOA ecosystem. These
products became known as Registries/Repositories. Figure 4.3 represents the
current evolution of the Registry/Repository platform and its impact on the
SOA lifecycle.
Figure 4.3. A Registry/Repository platform plays a central role in
the SOA ecosystem and service lifecycle.

50

Typical Registry/Repository products play a central role in governing the

service lifecycle and supplying metadata for run-time management. They
integrate with the key elements of the SOA ecosystem such as Enterprise
Service Bus, run-time management platform, testing tools, etc. Many products
contain SOA governance management and automation capabilities that
introduce efficiencies in the service lifecycle.
Run-time Management
Many vendors started introducing run-time management capabilities even
before the ESB products hit the market. They were probably the first building
blocks in the SOA ecosystem.
As the run-time management products were first introduced, they focused on
providing capabilities to manage web services. The functionality was typically
limited to ensuring smooth operation of the managed web services and better
recognizing critical situations. As the products continued to evolve, a

51

comprehensive set of features found in most run-time management platforms

today was gradually added. These included:
Ability to manage a variety of services
Ability to define a comprehensive set of policies for each service under
management
Enforcement of these policies at run-time
Integration with other technologies in the SOA ecosystem including ESBs,
Registry/Repositories, governance platforms, and others
Rudimentary SOA governance capabilities
Business and service activity monitoring
Run-time metrics collection
Service consumer management
Service discovery
Many organizations started building their SOA ecosystems by introducing
run-time management platforms. This allowed them to discover all the
existing services, register them and start actively managing them. While
run-time management platforms are typically complex and hard to implement,
the benefits introduced typically outweigh the disadvantages.
SOA Testing
As the service-orientation entered the mainstream, specialized SOA testing
products started becoming more prevalent. Their roots can be traced to a
couple of different testing technologies unit testing and functional testing.
Both of these have been in existence for a while and offered significantly
different sets of capabilities. Unit tests and frameworks were used by
developers to test the basic functions of the code. Functional testing tools were
used to exercise functionality of applications, typically through their user
interface.
The SOA testing tools grew as a bridge between these two testing mechanisms.
They introduced a unit test like functionality against service interfaces, with
52

ability to record and play back the execution of these tests. Many concepts and
approaches were borrowed from unit and functional testing platforms.
Today, the SOA testing tools provide a complete quality and regression testing
capabilities for a variety of service interfaces. While these tools started with
purely Web Service testing capabilities, they evolved to encompass a much
wider array of protocols, messaging mechanisms, and interfaces. Many
products even offer load testing capabilities that can test how the existing test
cases perform under load.
Since testing plays an important role in the service lifecycle, many SOA
governance platforms and SOA testing tools integrate with each other. This
enables a much better cohesion between SOA governance mandates and
testing outcomes.
Case Study Example
As you recall, RYLC has identified three business processes to be
implemented by the IT as a priority to make it competitive again. They
included strengthening CRM integration with the rental process,
automation of the fleet maintenance process, and development of a new
sales process.
In order to establish the right foundation for this transformation, RYLC
decided to implement the following technologies:
A BPM engine for implementing the new processes that should no longer be
hardwired into the applications.
An ESB in order to address the pending integration scenarios and provide a
virtualization layer for services that are orchestrated by the BPM engine.
The use of a rule engine was classified as important in order to gain
flexibility with implementing frequently changing rules, but it was
scheduled for the next phase. No Registry / Repository, Business Activity
Monitoring (BAM) or event processing was included in the initial platform
rollout because no short-term benefits were expected.
Summary of Key Points

53

 Well established elements of todays SOA ecosystem include Enterprise

Service Bus (ESB), Registry / Repository, Run-time Management, and SOA
testing platforms.
Each technology platform has evolved separately and has its roots in
different IT areas.
4.3 Methodology
A number of SOA methodologies were created since service orientation hit the
mainstream. Many consulting companies and technology vendors offering
SOA infrastructure solutions developed their own methodologies. Some of the
standard groups embellished, formalized, and published them or evolved their
own. IT organizations that embarked on the SOA journey modeled their
approaches after these popular methodologies or frequently developed their
own. Regardless of how they were developed, all of the existing SOA
methodologies could be generally categorized as follows:
SOA Maturity Models
SOA Governance Models
Service Delivery Models
While we will not explore each and every methodology in full detail, general
details of each will be discussed in the subsequent sections.
SOA Maturity Models
The purpose of an SOA Maturity Model is to define a specific roadmap for an
organization to establish and mature its SOA Program over time. Typically,
these models include specific steps that need to be taken or objectives
achieved to move the SOA Program to the next maturity level. Each level is
well defined and signals a specific evolutionary plateau an organization can
reach as a result of the steps prescribed in the Maturity Model. All the steps or
objectives are usually divided across predefined dimensions that relate to
specific organizational or technology aspects that need to be influenced to
increase the overall maturity level.
The typical maturity levels found in various SOA Maturity Models can be
categorized as following:
54

1. Undisciplined / ad-hoc SOA

2. Minimally organized / defined SOA
3. Well organized / defined SOA
4. Well governed SOA
5. Optimized SOA
Some of the existing maturity models may have different amount of levels
(although 4-5 seems to be the norm). Also, the focus of each level may be
different some models measure the organizational maturity, while others
concentrate on the type of services being produced or how they are being
delivered. Nevertheless, the general pattern and spirit of the maturity
evolution remain the same as defined above.
Many maturity models break the evaluation of the maturity at each stage of
the model across multiple dimensions. They typically include:
Business
Organization
Program / Project / Process Management
Governance
Architecture
Technology
Operations
As mentioned above, each dimension contains a number of specific steps that
need to be taken, objectives met, or state reached. Typically, the next maturity
level is reached when all the objectives or steps within each dimension have
been achieved.
Figure 4.4 contains an example of an SOA Maturity Model. It contains a
number of well-defined maturity levels and dimensions that form the basis of
the implied maturity progression.
Figure 4.4. A typical SOA Maturity Model defines specific objectives
across a number of dimensions and maturity levels.
55

Many IT organizations tend to take an existing SOA Maturity Model as a base

and customize it to fit their specific needs, environment, objectives, and
desired path to maturity.
SOA Governance Models
SOA Governance is not an exact science. Many models and approaches are
specifically tailored to fit a particular organization type or reality. Therefore,
there is no definitive set of SOA Governance models that is widely recognized
as a norm. However, in general, SOA Governance can be broken up into
several basic components that each model tries to address.
Organizational model
Funding model
Service portfolio management
Technical architecture of services
Service design and development
Project delivery alignment with SOA

56

 Information / data
Security / policies
Supporting technology / automation
All of these specific models and aspects of SOA Governance are described in
detail in the Service-oriented Computing Series SOA Governance book.
Therefore, we will not delve too deep into each of these categories. Instead, we
will recap the state of SOA Governance to establish a solid foundation for the
discussions later on in the book.
The primary goal of SOA Governance is to ensure proper delivery of shared
services. This is typically achieved through several means:
Governance processes
Checkpoints / gates
Integration with change and release management
In typical SOA Governance models, various processes are established to
ensure that both service consumers and providers know what steps they
should execute, when, and how. Many aspects of SOA Governance identified
above are managed through these processes. Since they have to integrate with
overarching IT governance and its processes, seamless integration between
the two is often sought.
SOA Governance checkpoints typically represent transition stages between
key steps within an SOA Governance process. They are needed to ensure that
the previous step or phase has been completed properly. There may be a
formal review of the produced deliverables, and a formal approval to proceed
may need to be granted. Typical SOA Governance checkpoints include:
Architecture board review
Design review
Code review
Pre-production validation / review

57

As mentioned earlier, SOA Governance should be closely integrated with IT

governance and its processes. This includes change and release management,
which specify how changes are introduced into the production and other
environments. Since services are custom software components, they need to
be deployed in the same fashion as the rest of internally built software.
Therefore, SOA Governance processes, methodologies and practices need to
closely align with existing IT change and release management policies.
Most of the SOA Governance models, either published or privately
implemented, contain many of the elements described above. They may be
automated through the Registry / Repository or other SOA Governance
automation platforms.
Service Delivery Models
Throughout SOA evolution, numerous models were created to define how
services should be delivered, what deliverables should be expected, and how to
ensure repeatability of this process. These models can be generally categorized
as:
Business process decomposition
Service blueprinting
Project-based delivery
In a business process driven approach, services are identified by decomposing
existing business processes into system vs. human executable steps. By
discovering common patterns across various business processes, a
comprehensive set of shared services can be established. Since it is virtually
impossible and often impractical to model the complete enterprise or even a
single domain, this approach is typically used in conjunction with others to
identify and deliver shared services.
Service blueprinting model is very similar to business process decomposition.
It has been described exhaustively in other Service-oriented Computing Series
books. The basic approach is to establish a single service blueprint or multiple
ones aligned with particular domains. The blueprints would drive the
identification, delivery, and priority of services being delivered. Since
blueprints can evolve over time, this technique can be used by itself or in
conjunction with others.
58

A project-based approach to delivering services defines a method to iteratively

identify, create, enhance, and evolve service inventory based on project
demand. The entire project portfolio is evaluated, and potential service
candidates are identified across all current projects. Services are delivered in
conjunction with each project. The service inventory evolves over time in
response to opportunities identified through individual projects. This model
concentrates more on the mode of service delivery rather than identification
as opposed to the previously described models. Therefore, it can be used in
conjunction with any other service identification approach.
Case Study Example
RYLC recently began its SOA journey by implementing BPM and SOA
initiatives. It outlined a series of major system overhaul efforts aimed at
increasing its maturity and agility. Early in the process the RYLC chief
architect recognized that this would help transition the SOA Program from
level 1 maturity (Undisciplined / ad-hoc SOA) to level 2 (Minimally
organized / defined SOA). As part of this transition, he defined the initial
SOA governance mechanisms that included:
Enterprise Architecture Board (EAB) that was empowered to design and
govern solutions with a broad, enterprise wide perspective
SOA reference architecture
Service blueprint
Service lifecycle definition and transition rules including service definition,
design, development, versioning, and retirement
The service delivery model was specifically chosen to be business process
driven, as RYLC began its SOA initiative by identifying key business
processes to automate. Later, however, as the SOA reference architecture
and service blueprinting model were developed, the process-centric
approach shifted to a more service inventory and blueprint based one.
Summary of Key Points
Existing SOA methodologies can be categorized as maturity, governance, or
service delivery models.

59

 SOA maturity models typically define a collection of steps or objectives that

span across multiple dimensions and maturity levels.
SOA governance models guide how services are delivered and what
organizations look like by influencing key organizational and executing
elements.
Service delivery models define how services are identified and delivered
either through top-down or bottom-up approaches.
4.4 Industry Penetration
Since its inception more than 10 years ago, SOA has become a necessary part
of the IT strategy. Most organizations today have some kind of SOA program
underway. Some programs are further along than others. Some industries are
also further along than others in their SOA adoption and degree of penetration.
This is based on several factors that are described in Table 4.1. It captures
some general trends that have been observed as related to SOA adoption
across various industries and organizations.
Table 4.1. SOA adoption potential depends largely on the industry
that drives how companies are structured and what technology
solutions they use.

60

61

As you can see, SOA adoption potential depends largely on the industry, which,
in turn, drives how companies are structured and what technology solutions
they use. Despite the general patterns, some visionary or cutting edge
organizations will buck the trend and join an earlier group of adopters. The
SOA adoption potential, regardless of the industry, company size, or its
technology landscape, largely depends on several factors.
Visionary business and/or IT leaders
Strategic direction requiring significant efficiencies and agility on the
business and/or IT side
Competitive pressures
Market shrinkage or profit erosion
Similarly, inability of many companies to adopt or successfully implement
SOA programs hinges on several factors.
Culture
62

 Lack of strong leadership

High degree of decentralization
Lack of investment or trust in IT
Inability to establish partnerships between business and IT
Throughout its evolution, SOA ceased to be a competitive advantage and
became a standard part of IT strategy for most companies. There are very few
organizations left that do not have some kind of SOA strategy implemented or
being developed.
Summary of Key Points
SOA adoption potential depends largely on the industry, which, in turn,
drives how companies are structured and what technology solutions they use.
Many companies have bucked the general trends by leading their industry in
SOA adoption or lagging behind.

63

5. Next Generation SOA Technologies

Implementing SOA solutions based on the seven principles outlined
in Chapter 3 requires a solid understanding of available technologies,
implementation concepts and their impact on SOA solution delivery. With
more and more products and technologies becoming available every day, the
architects job expands beyond just designing a solution blueprint. Architects
need to knowledgeably navigate the technology and product maze, trying to
determine the best solution for each specific problem.
This chapter highlights the critical tools in the architects next generation SOA
toolbox. It discusses the available technologies and their applications, from
the service implementation layer through Service Component Architecture all
the way up to the human consumer and business analysts that need a more
accurate understanding of what goes on in business processes and services.
Additionally, it introduces complementary architecture concepts, such as
Master Data Management (MDM) and Event Driven Architecture (EDA),
allowing real time response rather than delayed mining of data.
How Case Studies Are Used in this Chapter
Case studies in this chapter will describe what next generation SOA
approaches the Rent Your Legacy Car (RYLC) company has implemented
SOA through its various modernization initiatives. Since RYLC embarked
on a significant SOA transformation, it had to adopt a number of modern
SOA technology solutions and approaches. In order to stay competitive and
make its operations more efficient, RYLC carefully considered the entire
technology landscape and selected the most appropriate technologies and
solutions to meet its needs. Case studies in this chapter examine what was
implemented, how it was achieved, and why specific decisions were made.
5.1 Service Implementation with Service Component Architecture (SCA)
In 2007 middleware vendors came together in the OSOA organization to
develop a platform and technology independent model allowing assembly
components
into
service
compositions
(http://www.osoa.org/display/Main/Service+Component+Architecture+Spec
ifications). The resulting efforts were mainly the assembly specification. Since
2009, they were covered under to OASIS OpenCSA umbrella. These
64

specifications were implemented by commercial vendors (such as Tibco, IBM

and Oracle) as well as open source projects such as Apache Tuscany.
Concepts
We have been bombarded with an array of building blocks for structuring
business software such as procedure, data, object, component, agent, aspect,
service, event, model and now composition. Object-orientation (OO),
aspect-oriented programming (AoP), agent-based software development
(ABSD), service-oriented programming (SOP), component-based architecture
(CBA), composite-oriented architecture (COA), etc., are some of the
prominent software engineering principles. Services are uniquely positioned
for coexisting and collaborating with other building blocks in order to bridge
the gap between the business and the IT domains.
Leveraging the proven architectures, frameworks, reusable assets, toolsets and
engines, service developers and providers have begun producing
multi-functional, media, modal, channel, net, device, and platform services.
Composites will become commonplace everywhere as simple services are
combined and orchestrated into more sophisticated composite services,
designed to ensure business agility and flexibility, to guarantee high elasticity,
scalability and availability.
Figure 5.1. From Object Orientation to Service Orientation:
Evolution of building block granularity

The Evolution of Software Building Blocks

The standard that many vendors embarked on for creating composites is
Service Component Architecture (SCA). SCA is best described through the
mission statement from http://osoa.org/display/Main/Home:
Service Component Architecture aims to provide a model for the creation of
service components in a wide range of languages and a model for assembling
service components into a business solution - activities which are at the heart
of building applications using a service-oriented architecture.

65

Problem Being Addressed

SOA services expose functionality that potentially leverages many different
implementation technologies for business logic and data access logic. These
technologies range from Mainframe-based CICS web services, Java EJBs and
stored procedures to modern technologies such as BPEL and rule engines.
Within an SCA composite, components can be implemented through many
different technologies. The description and representation of their exposed
service interfaces is technology neutral. Hence, the SCA container
implementation must take care of possible data format conversions (e.g.
WSDL <-> Java, Java <-> C++).
Impact on Architecture
From the architecture point of view, SCA is a composite and component based
development (CBD) approach on the service paradigm. In general, SCA
component based development follows the key SOA principles, such as
reusability through encapsulation with an external service contract and
assembly model to deploy and maintain the internally used artifacts as one
complete module.
This principle allows integration of any existing components like Rule Engine,
Process Engine, Human Task Engine, etc. into the SCA and making them
usable during development of service composites. In order to make the
service-oriented approach usable on each architectural level, the main SCA
design concept is the independence from transport protocol and
implementation technology. To achieve this, external communication protocol
is bound separately to the composite. This means that SCA services do not
have any primary dependency to the SOAP based Web Service. Many
protocols including popular Representational State Transfer (REST) can be
bound to the SCA assembly model without influencing the internally used
service components architecture.
With this approach, service composition and application design can
encompass all architectural layers. SCA composites are not restricted to
integration aspects. It is possible to create an SCA composite that embeds
BPMN 2.0 based business processes, BPEL based integration processes, Java
based application logic, Rule Engine based rule logic, and even database
access logic. Architects need to understand this and provide clear guidance for
the developers in order to stick to the separation of concerns principle and
66

forbid mixing integration logic with database access logic in the same SCA
composite. SCA provides a language-neutral syntax using XML for configuring
and wiring disparate and distributed service components together to create
business-aware composites. One SCA composite may comprise of several
components that are wired together in order to provide coherent functionality.
Examples for component technologies can be:
ESB type of functionality for routing and data transformation
Executable BPMN 2.0 processes
Executable BPEL processes
Rules in a Rule Engine
Java
Java Spring Beans (EJBs are not an SCA component, yet the SCA spec
standardizes a binding)
Microsoft Windows Azure AppFabric
C++ or COBOL components
The standard SCA does not dictate that all specified implementation
technologies must be supported by an SCA-based middleware. In the specs
section about conformance and compliance, it is stated that, as a minimum, a
container must understand the assembly model, at least one of the sanctioned
implementation languages and the binding for web services.
An SCA composite is typically designed in a graphical editor. You can visually
configure the operations and channels of the service that the composite
exposes to its consumers as well as the references that provide the bindings to
external resources that the composite depends upon such as deeper level
services or adapters. That is, the implementation can utilize other providers
services hosted elsewhere. As an example, an SCA composite that is
categorized as a Task Service can call several SCA composites that are
categorized as Entity Services or Utility Services. An ESB can be used as an
intermediary to establish further decoupling. Through the SCA visual

67

framework, you can wire together the components needed for each operation,
for example a BPEL process and some supporting Java Spring Beans.
An implementation may also have one or more configurable properties. A
property is a data value that can be externally configured, and this activity
affects the business function of the implementation.
The SCA assembly layer captures the configuration of components and their
dependencies on other components services that have been created based on
the SCA programming model. SCA comes with a proven mechanism to build
coarse-grained components as assemblies of fine-grained components. SCA
offers a mechanism to package and deploy sets of closely related components
that are developed (the spec uses the word contributed) and deployed
together as a unit. It decouples service implementation and assembly from the
details of infrastructure capabilities.
Thus, SCA relieves programmers from the drudgery of traditional middleware
programming by abstracting it from business logic. It allows developers to
focus solely on writing business logic.
Case Study Example
The application landscape of the car rental company RYLC encompasses
two CRM systems due to historical reasons. A process analysis revealed that
during the car rental process customer data that comes from both systems
must be accessed. The architects found a solution in which a task service
provides a unified customer related interface for an executable BPMN 2.0
process and internally consolidates customer data from both CRM systems.
The internal details of the implementation are hidden from the consumers
of this task service. It could be two references to existing services, a BPEL
process or a technical adapter to a master data management solution that
integrates with both CRM systems. SCA is used as a composite container for
either implementation. The consumer of the task service only knows the
interface to access the appropriate customer data and does not need to
know where this data comes from and whether its implementation station
strategy has changed.
Summary of Key Points
SCA is a container concept that allows assembling and virtually embedding
pieces of functionality based on standard contracts
68

 SCA provides a language-neutral syntax using XML for configuring and

wiring disparate and distributed service components together to create
business-aware composites
SCA is a maturing standard for streamlining service-based application
development
While SOA is a design approach, SCA shines as a development mechanism
producing effective service implementations.
There are both commercial-grade and open source SCA containers.
5.2 Technology Independent Data Access through Service Data Objects (SDO)
Data access and concurrency is one of most recognized problems faced by
service-oriented systems. Access to and synchronization of distributed data
across various middleware platforms, multiple layers, and technology stacks
can be quite problematic. Service Data Objects offer a solution.
Problems Being Addressed
Concurrent Access
In long-running processes, data inconsistencies can quickly occur: an entity
service receives a request and compiles a response message, e.g. about a
customer and his address. This message is processed by a process service, e.g.
it sends a product to that customer. If the customer now calls and makes a
correction to this address, it is too late for the process it is working on
obsolete data.
This is where the service data object (SDO) standard comes in. The idea is that
a service, e.g. a business process, works on the basis of a pointer to the
physical data storage location rather than on historical data.
In the service data object world, there are two fundamental concepts for
dealing with changes of data:
1. The data access service is responsible for the provision of data and also
implements the functions for returning modified data to the source
system. This is the mainstream mechanism in current SOA designs.

69

2. The service data object, which stores data not only in the form of a
hierarchical tree (e.g. employee address street), but also stores a
change summary documenting changes (e.g. a newly created street).
This is the approach taken with Service data objects (SDOs) as depicted
in Figure 5.2.
Figure 5.2. Service data object (graph including change summary)

Source:http://www.osoa.org/download/attachments/36/Java-SDO
-Spec-v2.1.0-FINAL.pdf

Technology Neutral Transmission of Data

The second problem SDO solves is the inherent technology conversion
problem within distributed architectures. While a provider interface might be
based on Java, the consumer may be implemented through .NET. Hence,
Java-native data streams need to be converted on the client side to .NET
through a provider-native API.
SDOs fix this problem, as XML is used as the interchange format, and
serialization to and from XML takes place automatically, on the provider as
well as the consumer side based on a standardized API.
70

Impact on Architecture
If SDOs are used to transmit data between services, less data must be sent
upon changes. Only the change summary is sent rather than the entire object
or a large XML message.
SDOs can be used throughout the service categories (except for utility services)
Entity Services retrieve data from databases and expose it via SDOs that are
used by Task Services to assemble complex data types. SDOs will have an
impact on the structure of data Task Services will expose insofar as the
original structure of the entities will stay intact when assembled.
SDOs are not a silver bullet. They require all involved services to be working
through middleware that provides SDO support and a binding mechanism to
the underlying data store. Thus, there is a coupling involved that implies a
high price that must be weighed against the benefits of live objects on the
consumer side and performance gains through the reduced payload size.
Case Study Example
In the architecture of the RYLC systems, SDOs are used to access large-scale
business objects such as customer or car, but only small attribute chunks of
these business objects are really needed in a specific context. Entity services
for customer or car are taking care of all the attribute changes within the
entities they are managing. In many use cases, transferring the complete
object graph through the whole service chain would violate performance
SLAs. For these contexts, entity services provide representations of their
business objects as SDOs that manage transparently only the respective
change set and transfers it to their consumers. RYLC found this solution to
involve little implementation overhead and to provide excellent throughput
and performance characteristics.
Summary of Key Points
Service data objects (SDO) store and pass data in the form of hierarchical
trees and change summaries
SDOs can limit the amount of data being sent between service consumers
and providers

71

 The application of SDO can replace old CRUD based SOA application
designs
Business services can work directly on their datasets without being
concerned about backend synchronization
5.3 Composition Technologies for Task Services
In todays SOA world, there are plenty of composition technologies that are
being used. This section discusses the best way to orchestrate and
choreograph task and other services.
Concepts
A service inventory consists of a task service layer and a basic service layer
that provides highly reusable utility services and entity services. Task services
expose functionality in their contract that are motivated by specific needs of
concrete business process activities or use cases. Internally they use the
services of the basic layer to assemble the data and functionality needed by the
consumer of the task service. The definition of that assembly line is called
composition. It defines the flow in which atomic basic services (their
operations) are invoked, their data gathered and a complex data structure that
fits the consumers specific needs is constructed.
Problem Being Addressed
A typical characteristic of currently SOA-labeled solution architecture is the
lack of a dedicated task service layer. Instead, you will find classic model view
control (MVC) architecture, where view and controller components are JEE
or .NET based. The model consists of Entity Services that access a database.
These Entity Services expose core business objects such as customer or
product. Yet, in the context of concrete use cases and process steps, we need
combined entities that group specific data from other entities (e.g. a customer
and its orders) and provide a use case specific view on this data. This logic
resides classically near the frontend, because here the use case specific bundle
of data is needed.
This architecture prohibits realization of the following potential associated
with Next Generation SOA:

72

 The components that assemble data and functionality for concrete use cases
are not yet realized as Services. Thus, they do not allow reuse outside of this
concrete context.
Monitoring and the corresponding analysis of service behavior and
monitoring of SLAs through Business Intelligence are possible only through
great effort. Task Services ease this effort by acting as entry points and facades
for services that together support a process step or use case. It is easy to set up
gateways at these access points that capture BI relevant information.
Central error handling is harder to establish. Task Services consolidate
faults and translate them to standardized meaningful error messages that can
be forwarded to a central error handling system or process.
An important design decision is whether Task Services gather compound data
by accessing the database directly or via Entity Services. The indirection via
Entity Services has the drawback of potentially less efficient data access (if
service-to-service communication is not optimized) compared to retrieving
complex structures with optimized access technology such as stored
procedures. Establishing Entity Services as the single point of entry and
facades for data access has the following benefits:
Entity Services provide access to core business objects for a large number of
user scenarios and contexts when using a common data representation format.
Thus, they have the highest potential for reuse. If database access is embedded
in Task Services, this reuse potential is lost.
Databases exist in functional silos and represent a limited view to core
business objects. See section on Master Data Management for a more in-depth
discussion. Tight coupling between task services and a database stands in the
way of crossing the functional boundaries for data access.
Impact on Architecture
The composition in Task Services is realized as an external stateless
integration process that calls several services through a well-defined flow and
uses a data transformation to build a complex data type exposed at the
interface of the service. While such an implementation can hold state
internally, state should not be exposed to the consumer thus making calls
atomic.
73

A good technology candidate for realizing integration processes is Business

Process Execution Language (BPEL). BPEL is intended to be utilized for this
specific purpose. BPEL engines provide standardized features that allow unit
based orchestration and optimized invocation of Web Service calls and
especially ease error handling with compensation mechanisms.
Some SOA middleware vendors, such as SAP, position BPMN 2.0 or Microsoft
XAML for integration processes instead of BPEL.
From the technical point of view, most ESB implementations are also able to
create such composite services. However, the main conceptual usage of ESB
should be for virtualization, adaptation, routing, policy and security
enforcement and should not have business logic on a lower integration level.
The data transformation is typically realized via XSLT, although XQuery is a
valid alternative. The key is tool support to graphically creating the mapping.
Case Study Example
As you may recall, RYLC built a task service that hid details of how
customer data was assembled from various sources. Over time the
architecture was refined so that the integration logic for the concrete CRM
system was moved to entity services. The only thing left as part of the task
service implementation was the orchestration of the entity service calls to
the underlying CRM systems. This solution proved beneficial when one of
the CRM systems was phased out and the interfaces exposed through task
or entity services did not have to be changed. As a result, none of the
consuming systems had to be modified.
Summary of Key Points
A typical characteristic of currently SOA-labeled solution architecture is the
lack of a dedicated task service layer
It is beneficial to establish Entity Services as the single point of entry and
facades for data access
Composition of Task Services is best realized as an external stateless
integration process that calls several services as part of a predefined flow

74

 BPEL and BPMN are good candidates to enable orchestration of task

services
5.4 Model Driven Software Design (MDSD) and ESB for Standardized
Contracts
Standardization of contracts across the enterprise is critical for a successful
SOA implementation. This section discusses how model-driven design
practices and reliance on ESB can help streamline this practice.
Concepts
In the late 1990s, when object orientation was the predominant software
development paradigm, many thought leaders and IDE vendors advocated for
the use of the model driven architecture (MDA). The idea was to completely
model the relevant part of the business domain related to the software
application under development. UML or a similar Domain Specific Language
(DSL) notation would be used to generate large portions of executable
software from those models. This approach, while successful in some areas,
did not become mainstream.
Just like MDA, Model Driven Software Design (MDSD) is an approach that
focuses on the model and that generates code directly without the proposed
MDA model transformation in between. MDSD tackles much smaller scope of
solution designs than a more global claim of MDA. MDSD addresses distinct
parts of the overall architecture, namely the ones that are especially feasible
for a model driven approach. A prime example is the automated generation of
standardized service contracts and chosen parts of the distinct technology
representation based on centralized models. This application of MDSD is
discussed below. Other areas where MDSD approaches will evolve are the
generation of GUI elements or tool-specific page flow solutions, which would
be generated from simplified BPMN models.
The ultimate goal of MDSD is to establish a service factory. MDSD fosters a
more standardized and automated software development where the creativity
moves from individual software artifacts to the centrally government code
generators. This increases reusability and updateability of components and
reduces maintenance efforts since design changes can be applied at a central
place as shown in Figure 5.3.
Problem Being Addressed
75

One of the most important characteristics of the Next Generation SOA is

domain wide, ideally enterprise-wide standardization of service contracts.
This is a precondition for Task Services to act as functional building blocks for
business processes and frontends without complex integration efforts. The
standardization of service contracts is a main goal for sustainable and holistic
SOA governance.
Figure 5.3. Design changes can be applied at a central location

Generated Contracts
To achieve this, it is crucial that Task Services behave like LEGO blocks that
are easy to plug in and interchange with one another. Together they form a set
of functional building blocks that can be used to create new process steps or
use cases. To achieve this, it is crucial that the contract of these task services is
based on domain wide standards. This is true for the user data portion of the
contract that should be based on the canonical data model as well the data
types specified in the meta-data used across all services. Such meta-data can
include business context, time stamps that indicate time and length of usage,
76

business fault types, technical fault types etc. If all these types are based on
heterogeneously structured XML types, the integration efforts needed to use a
service are unacceptably high and have the potential to jeopardize the
adoption of SOA.
Therefore, standardization of service contracts plays a key role in supporting
the cultural change of designing services in a top-down rather than bottom-up
fashion. One way to achieve this standardization is by establishing an SOA
Governance Program Office (SGPO), as described in the SOA Governance
chapter. Here, senior SOA architects create guidelines and quality gates.
The standard data types are stored in a centralized repository. SOA
governance mechanisms ensure that they are used in all the services, that is,
the services conform to the SOA guidelines. This type of governance implies
large manual efforts.
The approach above implies manual creation of service contracts, WSDLs, and
a process to review these contracts by the SOA governance team. In Next
Generation SOA, we will find model-based generators that create contracts
automatically and thus help to reduce programming and governance efforts
while increasing the level of standardization and automation.
Impact on Architecture
The data types contained in the service contracts are defined semantically in a
natural object model and are stored in a central repository. . These models
contain the entity definitions of the canonical data model as well as meta-data
that are part of all service contracts for a specific service category. Architects
typically develop WSDL generators based on these models.
The payload of individual service contracts is defined by service contract
designers based on the canonical data types who feed it into the generator.
The generator uses this payload definition and combines it with related
meta-data in order to create a standardized WSDL. This produces the service
interface specification as the final output.
At runtime, SOAP messages based on these contracts are exchanged between
service consumers and providers. In order to ensure standardization of the
SOAP headers, a centralized storage and management approach should also
be considered. This is necessary because these SOAP headers contain
information needed to assess critical service KPIs.
77

An ESB can be used to populate the correct SOAP headers at runtime. Because
ESB configuration can be setup once, developers responsible for exposing a
service do not need to be involved in this activity.
Summary of Key Points
Model Driven Software Design (MDSD) focuses on the model and generates
code
One of the most important characteristics of the Next Generation SOA is
standardization of service contracts
SOA Governance is critical in ensuring that services are designed in a
top-down rather than bottom-up fashion
The standard data types should be stored in a centralized repository
ESB is a critical piece in ensuring standards compliance and automating it
5.5 Orchestration Technologies for Automated Processes
Two of the technical goals that SOA supports are integration of heterogeneous
systems and enabling business driven process and application design,
primarily through process automation. Task services are the building blocks
for executable processes and front ends. They act as a facade for business logic
exposed as part of integration efforts.
In the task services section, we discussed the use of BPEL-based integration
processes that orchestrate entity services. In this section, we will look at
another type of automated processes, the ones encapsulating business process
flows. It is important that technical details are implemented as part of the
orchestrated task services instead of inside the executable business processes.
Several methods exist to describe Business Processes and complex
interactions between them. By far the most well-known is the Event-driven
Process Chain (EPC), developed in 1992 at the Institute for Information
Systems (IWI) at the University of Saarland. These process chains are part of a
larger method, the ARIS House.
At the core of EPCs are four elements, allowing the analyst to model events
(such as new order created), functions executed (review order conditions),
78

and gateways / rules (customer credit enough?) for decisions and resources
(such as organizations and systems).
While EPCs can be used to create high-level models (e.g. strategic objectives),
it is fairly resource intensive to model down to the executable business process.
The Business Process Modeling Notation (BPMN 2.0), on the other hand,
allows Business and IT resources to collaboratively develop a process that can
later be executed.
According to the OMG, the idea behind the Business Process Modeling
Notation can be described as: The primary goal of BPMN is to provide a
notation that is readily understandable by all business users, from the
business analysts that create the initial drafts of the processes, to the technical
developers responsible for implementing the technology that will perform
those processes, and finally, to the business people who will manage and
monitor those processes. Thus, BPMN creates a standardized bridge for the
gap between the business process design and process implementation.
(http://www.omg.org/cgi-bin/doc?dtc/10-06-04.pdf, Page 31, Paragraph 1).
While the first major incarnation of BPMN, Version 1.x, was solely created to
describe processes in a formalized method (focus on notation), the explicit
goal behind 2.0 was the ability to have a technical person implement the same
model, without transforming it first, e.g. into the Business Process Execution
Language (BPEL).
The enriched model (through the implementation perspective) containing
technical details (such as data associations, send task or receive message) is
directly deployable to a BPMN 2.0 compliant engine that can execute the
process graph natively.
The two major differences between WS-BPEL (formal OASIS name of the
specification) and BPMN are:
Semantic structure of the language. BPEL is forward-block-based, whereas
BPMN represents a directed graph. Hence, while a BPEL process can only
execute top to bottom (or side, on the same level), block after block, BPMN
can jump back and forth between tasks, modeled through transitions.
Though BPMN 2.0 incorporates many of the BPEL features in order to be
easily executable, it allows a business user to design a process without any

79

dependency on technology or existing systems through multiple perspectives.

BPEL only contains one (implementation) perspective, centered on Web
Services.
Additionally, since BPMN is based on a directed graph, it is much easier
to have a business analyst design process flows in a natural way, left to
right, over multiple swim lanes, rather than through blocks (scopes)
that have natural top to bottom transitions.
BPMN 2.0 is not always the best solution for automating business processes
that involve heavy human interaction. The definition of the micro flow that
guides development of UI elements is addressed by specific Page Flow
Languages that will be discussed in the Portals section. Sometimes BPMN is
too rigid for the more ad hoc nature of many user scenarios.
Impact in Architecture
Executable business processes use a mechanism to arrange services based on a
predefined flow, making them a kind of cohesive unit. This is called
orchestration. The difference between this and composition in task
services lies technically in the different role that process state plays the time
a business process waits for an invoked service to answer is potentially long
and process state needs to be tracked in explicit variables. Orchestration
details in a business processes should be abstracted from the underlying
technology. Technical details should be handled by the integration
technologies in task services. BPMN 2.0 presents a viable foundation for
automated business processes.
A BPMN 2.0 process contains business rules that guide decisions as to which
route a process execution should take. It is a best practice to externalize these
rules outside of BPMN 2.0, typically in a rules engine. This allows maintaining
rules centrally and governing changes made to them more consistently. When
rules become more complex, rules engines provide specific solutions for
dealing with this complexity. Decision tables, non-deterministic rule
execution, and back propagation are all examples of features built into
industrial strength rules engines.
The basic data rules rely on is called facts. In external rules engines, the
definition of facts is very time consuming. In order to achieve effective process
development and change management, a consolidated design environment
should be established to facilitate the definition of rules in the same
80

environment as the definition of business processes. One approach to achieve

this is to define the process as a component in an SCA composite and the
decision rules as rule components in the same SCA composite. This way, the
designer can easily drag and drop the facts for the rules from the predefined
SCA variables.
Case Study Example
In RYLC, the car rental process was modeled and executed in BPMN 2.0.
The main challenge lied in the decomposition strategy for the process
models that affected their granularity. Many discussions revolved around
whether its better to model the complete process end-to-end or to break it
along longer logical boundaries. One overarching end-to-end process has
the benefit of showing the critical steps in single model. Yet, over time the
process structure can change because certain aspects of the process change
more often than others. RYLC architects and business analysts decided that
it was more practical to isolate each sub-process rather than keeping the
entire process as a whole.
Summary of Key Points
BPEL and BPMN are two key orchestration standards used in the next
generation SOA systems
BPMN processes contain business rules; it is a best practice to externalize
these rules, typically in a rules engine
5.6 Next Generation Business Process Management System (BPMS)
Business Process Management is closely associated with SOA. The two
architectural approaches have become almost synonymous and extremely
synergetic. One of the key features of the next generation SOA is this close
relationship between SOA and BPM.
Concepts
Business Process Management (BPM) is a modern approach that implies both
technical and business aspects. BPM differs from previous approaches such as
Business Process Reengineering due to its more direct binding between
process model and executable processes to align IT and business process

81

design. This implies iterative steps towards a gradually improving business/IT

alignment where IT enables a business driven enterprise.
Business Process Management Systems are a toolset in combination of a
methodology that allows to model and execute business processes in usage of
the established SOA Services. In an ideal scenario, process steps would use
automated Task Services as functional building blocks to interact with
external systems.
Problem Being Addressed
BPM today is still often applied only in the context of a closed business unit
without the required direct binding to the established technical SOA service
and architecture style. From an end-to-end process perspective, current
projects address pieces of processes that can be found at a deep level in the
process chain.
The goal of BPM is to look at a business process not just as a business function
but as an enterprise wide cross functional initiative. Locally identified services
and processes should be designed with the globally defined SOA rules in mind
in order to participate in enterprise wide processes. Consequently at the
highest level of a process chain, you find the core value adding chains that
reflect the ultimate business goals. If value chains drive BPM efforts, we can
make sure that each improvement on a local level is mapped to enterprise
business goals. Additionally, it is possible to identify areas of improvement on
the macro level, such as maximization of profit, quality improvement and
customer satisfaction.
Impact on Architecture (SWAT)
The following challenges arise when dealing with processes that span
organizational functions and systems and can be analyzed, assessed and
improved as a whole:
How can an overarching process interact with heterogeneous process island,
such as existing BPMN, BPEL or XAML processes that run on a different
middleware platform or processes that are embedded in Packaged
Applications, e.g. from SAP, Oracle or Microsoft?
How can we maximize users productivity and application flexibility by
decoupling presentation logic from application code? How can we create
82

homogeneous user interfaces that encapsulate heterogeneous sources (e.g.

two different applications) of logic and data, so that a user is not forced to
copy and paste data between different applications?
How can we centralize the Human Task Worklist provided by each
individual process engine or application to improve global process
atomization in combination with positive user experience?
Impacts of BPM on SOA
Typically, Task Services provide the functionality needed by process steps. The
bulk of the Task Services that support a process step is not directly invoked by
BPMN 2.0. This applies to the fully automated process steps. If they require
human intervention, a user interaction layer needs to be established between
the BPMN process and the supporting task services. This layer is further
discussed in the process portals section.
BPMN 2.0 is the language de jour for BPM. However, in some areas BPMN
will evolve and may be complemented by alternative approaches.
BPMN is well equipped to define micro flows that algorithmically describe
chains of steps. Yet, when human users need to make decisions, BPMNs
enforcement of specific routes to follow is often seen as arbitrary and too rigid.
In real life, things are more adaptive. This is reflected in the rise of Adaptive
Case Management (ACM).
BPMN lacks ways to express Business Architecture related information. If
business stakeholders want to assign such aspects to process steps as business
goals, SLAs, assignment to specific areas in organizational charts, etc, they are
unlikely to achieve this through the language meta model. BPMN provides
extension mechanisms, yet most BPMN editors lack the necessary modeling
items.
Figure 5.4. Cross-departmental, multi-project BPM / SOA
shared-service program affect tool selection and solution designs

83

Features of Comprehensive BPM/SOA Initiatives

The processes typically span multiple departments and even company
boundaries (orchestration vs. choreography). Process steps can have widely
differing implementations. Therefore, the way in which BPM tools are used
must be described using an SOA methodology and be in harmony with the
SOA governance model. This provides an ideal link, especially if
architecture-compliant processes can be generated directly from BPM models
using adaptable generation templates.
Functionality is reused at the level of task business services that are created
using a shared service factory (or are often reused at a domain level). To this
end, SOA governance describes how to progress from an emerging demand for
new or modified functionality to services where an existing service is extended
without its core functionality being re-developed. Implementation of the ESB
pattern is essential to achieve this in addition to the typical tasks such as
service detection, transformation, adaptation, and reuse. Through
virtualization and creation of proxy services on an ESB, different logical
versions of the same services can be operated in parallel, which is essential for
effective SOA governance.

84

Information schema should ideally be defined using a canonical data model,

on which all departments and communication partners participating in the
SOA interactions must agree. It is advantageous to divide up the canonical
data model by domains (i.e. department clusters) in order to get a handle on
the coordination cost, which may already be considerable. Repository-based
management is necessary for the central management of services and data.
ESB type of functionality is required in entity services for translating external,
uncontrollable dialects to and from the canonical data model.
Ideally, business rules are collected explicitly and declaratively in a rules
engine by technical staff together with specialized developers. Business users
should be enabled to access and modify these business rules if necessary. This
arrangement would provide maximum efficiency for both IT and business
operations.
The overall behavior of processes and services is widely distributed. Processes
span departments, applications, databases, etc. Thus, the control of
functionality along with memory and performance is a challenge that should
not be neglected in a complex SOA environment. Control of these functions
should be distributed or full control cannot be achieved at all. SOA, just like
any every distributed development paradigm, can prove to be a nightmare for
those that wish to control the entire application stack.
Case Study Example
As discussed earlier, RYLC modeled a new car rental process. It
encompassed:
New Enterprise Portal that allows unified access to customer data
Car rental system that checks for availability of requested car types at
specific locations and provides vehicle retrieval services
Billing system that finalizes financial transactions
All involved departments had to build a service layer on top of their existing
systems in order to enable this new process. These services were registered
in a shared registry/repository that provided all the relevant service
metadata. The repository also maintained the relationship between services
and their consumers. This was critical for the maintenance and the

85

enhancements of the services as well as an impact analysis in case major

changes to services were needed.
Summary of Key Points
Business Process Management Systems provide a toolset that allows to
model and execute business processes
The goal of BPM is to elevate business processes to the level of an enterprise
wide cross functional initiative
BPMN 2.0 is the language of choice for many BPM systems
BPM technologies should be used in conjunction with and governed through
SOA Governance mechanisms
5.7 Service Oriented Business Intelligence
SOA forced changes in many areas. Business Intelligence saw an impact as
well, both from the technology and general approach perspectives. This
section discussed and assesses this impact.
Concepts
In the BPM section, we described the need for cultural change away from a
departmental silo view towards a cross organizational unit end-to-end view on
processes. These processes place the goals of the overarching value chain
higher than those of individual organizational units. Upper management and
business units continue to embrace this change and expect it to provide better
insight into problem areas and to ease identification of potential
improvements.
The tools that allow for respective consolidated analytics in business user
friendly dashboards are grouped under the umbrella term Business
Intelligence (BI). They are a crucial building block of Next Generation SOA,
since they allow linking Enterprise Architecture models and business process
models with historical and real time data. The desired outcome of a BI effort is
an Enterprise Architecture Management Dashboard that allows holistic
insights into static and dynamic aspects of the IT landscape and their impact
on the critical core business processes.

86

Today, both SOA/BPM and BI disciplines are still largely monolithic

implementations that do not realize the potential that could be achieved by
combining them. SOA infrastructure contains middleware that includes SCA
containers, process engines, ESB, BAM and CEP. Business Intelligence tools
include Enterprise Performance Management, Reporting, Analytics and Data
Warehousing.
A typical characteristic of current BI is the time delay that happens due to the
complexity of the consolidation and analysis operations. Thus, they typically
run in nightly batches. This way, many critical KPIs can be analyzed but the
reaction to violated SLAs etc. does not happen in real time. Business Activity
Monitoring (BAM) is conceptually different from BI and is a good foundation
for the Next Generation BI. Unlike BI, its goal is to use direct monitoring of
running process instances to gain insight into critical events in business
processes.
Problem Being Addressed
The connection between Business Intelligence and business processes is a
major challenge for enterprises that want to understand and optimize their
core value chains. The integration of these two disciplines offers insight into
the real inner workings of a company, in a more detailed way than could be
achieved by process simulation. Decision makers are promptly enabled to
react, for example, by triggering other processes or actions. Many actions can
be triggered automatically in real time without human involvement when
certain patterns are discovered in business processes.
Impact on Architecture
Enterprises use software that tracks critical business KPIs such as amount of
orders per day or SLAs for tracking downtime of important sub systems. Yet,
the complexity and heterogeneity of IT infrastructures and of the application
landscape are a huge challenge. This is another reason why SOA and BI tools
should become more synergetic.
The core disciplines of next generation BI are:
a) Insight Driven Business Processes: Direct coupling from BI to the
processes in order to gain insight and being able to act manually.

87

b) Automated reporting, alerting and delivery: Dashboards and Reports

are updated or sent automatically, when the system detects aberrations of
defined TO BE states.
c) Predictive analytics: Complex Event Processing and intelligent Rule
Engines can be used to determine and create adaptive recommendations
to predict areas for action.
d) Business process analysis: The SOA infrastructure generates large
amounts of run-time data, from which BI can derive real process
behavior that can be condensed to high-order, more meaningful
information.
Case Study Example
In order to get real time information on Sales, Purchasing, and Customer
behavior, newly engineered processes were instrumented with business
activity monitors that displayed aggregated information on rented and
available cars as well as current trends to business users. In the future,
Complex Event Processing was envisioned to help identify trends and
aggregate in-house transactional data with external market events. All this
data would be fed into the global data warehouse system in order to
evaluate and analyze trends over time.
Summary of Key Points
Both SOA and BI disciplines still rely on incongruent technology stacks
The connection between Business Intelligence and business processes is a
major challenge for enterprises but, when in place, offers invaluable insight
into the real inner workings of a company
Enterprises should strive to combine SOA, BPM, and BI practices into a
cohesive discipline
5.8 Master Data Management
Historically, system landscape has become fragmented because of point
solutions introduced in different organizational units throughout enterprise.
Service-orientation as a paradigm strives to disentangle this spider web
through the introduction of services that cleanly abstract business
functionality and decouple consumers from providers. However, with

88

fragmentation of data across systems, data quality statistically goes down, and
day to day changes (e.g. attributes of a customer) become daunting IT tasks,
resulting in inconsistency all across.
The discipline of Master Data Management (MDM) cares about the creation
and maintenance of these basic data objects (entities) any organization needs
to conduct business (e.g. a customer). They are used upstream within business
processes (e.g. Order-to-Cash) to support the creation of transactional entities
(e.g. sales orders) that are responsible to create cash flow or products.
Transactional entities are characterized as ones that span functional
boundaries and change their state (e.g. received, confirmed, fulfilled and
billed) frequently throughout the lifecycle of a process.
Master data objects can be grouped into three functional clusters:
People
Business Partners (Suppliers, Customers), Patients, Employees
etc.
Products (Things)
Machines, Material, Contracts, Goods (e.g. Semi finished, Finished)
etc.
Locations
Plants, Addresses, Zip-codes, States, GIS-Coordinates etc.
In most companies, these objects are maintained independently of each other,
in different systems, but accuracy and their relationships become increasingly
important, especially in regulated businesses (e.g. Pharmaceuticals), where
stringent reporting requirements exist (e.g. within an intermediate batch,
which raw material came from which vendor).
In order to introduce master data management into an organization, three
dimensions need to be considered:
Data Definition
The definition of a golden standard record structure (entity definition), which

89

is largely an issue of harmonization between systems through establishing a

common, organizationally agreed-upon structure.
Processes
The definition of governance processes including the ownership and
maintenance rules for data standards
Enabling Technology
The definition of how master data management technology fits into corporate
system landscape (e.g. master of record system, batch vs. real time, ...)
The dimensions identified above should be implemented sequentially in two
phases.
First phase should include the creation of the standardized entity definition
based on a business readable information model and the establishment of
maintenance processes. By doing so, the organization is implicitly changing its
view from a silo perspective to a process / service perspective with clearly
defined rules. While there is no standardized enabling technology, master data
objects are maintained through a well defined process, in which
responsibilities are clearly defined and participants utilize common attributes
in a system independent manner. Mappings from physical systems to the
logical, independent information model are created in this phase. At this stage,
abstract service definitions should be defined as well. These will be entity
rather than business capability centric. Consequently, each entity should get
its own basic service definition. Relationships (e.g. contract to customer)
should be established as composite services.
The second phase should largely concentrate on how enabling technology is
used to support the processes defined and implemented during the first phase.
Here, the technological paradigm used to integrate existing applications as
well as the rules and principles for newly created applications is selected.
Challenges
Master data management starts at the organization level. Defining clear
ownership of data and its structures is by far its biggest challenge. Most
organizations are still function-oriented (e.g. Sales department). While at the
first glance it seems obvious that customer data should be owned by this
function, the finance backbone (Accounts Receivable) organization has a big

90

stake in this information as well (e.g. bill-to address). Information

Architecture, one of the four Enterprise Architecture quadrants, helps in
managing those dependencies through proven methods and tools.
The second challenge is the vast array of applications. Organizational units
run different systems (Sales works on a CRM system, Finance on an ERP one)
and those often store the same data (e.g. a legal entity name) in differently
named sets of attributes, based on different unique identifiers. This needs to
be standardized before a golden standard can be established. Here
Information Architecture plays a critical role in mapping a logical, business
understandable information model to the physical implementations contained
within those systems allowing semantic harmonization.
Master Data Management & Service-Orientation
An important, if not the most critical aspect (see Chapter 8) of service
orientation is the establishment of governance processes that implicitly
enforce accountability from design to operations. Without governance in place,
an SOA initiative will fail, and so will a Master Data Management one. Clearly
defined information responsibility helps to set the roadmap for basic (entity)
service design. Each centrally managed entity needs to be accessible
(discoverable, callable, queryable) enterprise wide.
In a service-oriented world, there is only a one service (e.g.
CustomerInformationManagement) that is responsible for each master data
object. However, in most organizations there are many applications storing
certain attributes of an object (e.g. in CRM only the outbound facing sales
information of a customer, and in ERP the backend shipping and billing
addresses). Without master data management, the relationship between those
two occurrences must be kept somewhere in order to match them. This can be
either implicitly (same name, same guide) or explicitly through one record
containing the ID of the other. Creating a composite service that merges the
data between these systems can be a difficult task, as either key mapping or, in
the worst case, data field matching (e.g. fuzzy logic) has to occur. Building this
logic (especially the update functionality) can easily result in reinventing the
functionality of a master data management platform.
Impact on Architecture
After processes and ownership have been defined and implemented (usually
through dedicated teams), the next step is to implement a platform to support
91

MDM. This platform should be carefully researched and considered because of

the significant impact to the system landscape.
Most large business systems databases only work if they contain an entire tree
of data (e.g. a customer including bill/ship-to address and so forth) as they
tightly interweave transactional data and master data (e.g. an order is tightly
linked to a customer). Changing the unique identifier after the fact in order to
have equal primary keys across systems is nearly impossible.
Hence, these legacy systems will become consumers rather that providers of
data. The master data platform must be able to map different data structures,
as well as keep a reference to the identifier for each system in order to
propagate changes of the master record.
On the other hand, introducing a service centric approach enforces that data is
kept in a single place and that consuming systems using data for transactional
processing should only store a reference to each accessed record rather than a
copy of the whole tree.
Many vendors have offered MDM platforms that not only centralize and
manage master data records but also come with a comprehensive and
customizable set of service interfaces. This enables enterprises to reach the
goal of cohesive master data management through a modern platform that
includes a set of related capabilities.
While this is the nirvana when it comes to service orientated architecture, it
implies stringent operational governance and a near zero downtime policy for
the master data management platform. Secondly, for auditing reasons, the
platform must offer versioning capabilities, so that basic services built around
it must offer the data and its version identifier. Both of these need to be stored
on the consumer side in order to guarantee traceability for auditing.
Case Study Example
The first goal of RYLCs transition was to move from an application
integration based landscape towards services. In phase two of the transition,
data quality was tackled through the introduction of central Master Data
Management. Key entities such as Customers, Cars and Rental Locations
were covered by the initial implementation. In order not to completely
dismantle the system landscape, a virtual MDM system was constructed.
It took care of data key mapping and management between different
92

systems in order to get a central view of where the store of record for each
data element was.
Several vendor products are being considered to replace the home grown
approach. Once a specific vendor is selected, RYLC plans to migrate
management of each key entity to the new platform. A set of services would
be defined to expose the consumption and updating of each managed entity.
Summary of Key Points
Master Data Management strives to establish a clear relationship between
data and its store of record
Defining clear ownership of data and its structures is by far MDMs biggest
challenge
Without governance in place, a Master Data Management initiative will fail
Introducing a service centric approach to MDM is the ideal approach
5.9 Event-Driven SOA
Event-driven Architecture (EDA) has been touted as the solution for a lot of
enterprises problems dealing with non real time transactions. It is based on
the publish-subscribe concepts and heavily utilizes many of SOA approaches
and design patterns. Some consider EDA an asynchronous version of SOA.
However, as discussed in this section, it goes far beyond that.
Concepts
If we look at real companies and their business transactions, we see that the
real world operates on a much more event-oriented basis. Typical events are
the result of any state transition that can be a result of various activities such
as a new customer is created in the system, a car reservation is made, a car is
returned, a car has to go to the garage, etc. We can support all of these
functions with services and often with specified process chains. However,
complex business processes can rarely be automated in one piece, as the
real-life exceptions and dependencies of various business transactions are
highly dynamic. Thus, the concept of loosely coupled events and event
consumers in our architectural approaches becomes very helpful.

93

Figure 5.5 shows an example of a technical event description in the form of an

XML message. Events can also be defined as Java or .Net objects, proprietary
formatted messages, etc.
In many respects, events are very similar to traditional messages exchanged
via Message Oriented Middleware (MOM). There are no large payloads, and
the content may be supplemented by the event processors. We will outline
some differences between them below.
Figure 5.5. Example of a technical event expressed in XML

An event-driven architecture (EDA) refers to a system architecture that, in

the simplest case, executes and manages rules in the following format: IF the
reality deviates from the expectations, THEN update the expectations and
arrange a response. The following describes the eventing concepts based on
this trivial rule.
Simple, Stream and Complex Events
We generally differentiate three types of event processing simple, stream,
and complex.

94

In simple event processing (SEP), only relevant events are placed in the
event channel for processing. For example, Car class XY is sold out or Stock
threshold not reached for winter tires. This is very similar to the
message-based systems. The processing logic evaluates the event type and
content and then reacts accordingly.
In event stream processing (ESP), in addition to the relevant events, usual
events are published in the event channel, e.g. generally all purchase orders,
RFID events etc. This places more stringent demands on event processing but
also permits more possibilities for analysis.
Lastly, complex event processing (CEP) deals with the concurrence of
different (simple) events in order to derive actions from these. The events in
the event channel can have different event types and occur over long periods.
The event correlation can be content-based, time-based or spatial. Therefore,
CEP is frequently used to detect anomalies, risks or opportunities in business
naturally with the aim of gaining advantages over traditional reporting
solutions on the basis of more up-to-date information and ultimately
beating the competitors.
The primary difference between different event processing types lies in how
they deal with events. ESP relates to the processing of streams, where an event
stream is a chronologically ordered sequence of events (e.g. a stock ticker).
Conversely, CEP works on event clouds. An event cloud is the result of many
event-generating activities from different parts of an IT system. An event
cloud could contain multiple streams. A stream is therefore a special case of a
cloud.
The acceptance of the chronological sequence within a stream has its
advantages processing is fast, as only a few events have to be stored in the
buffer. Conversely, in clouds, the dependencies are important what
dependent events have occurred or, even more significantly, what events may
have been omitted?
This illustrates that event stream processing is designed for high speed
processing (Figure 5.6), while the focus of CEP is on the extraction of
information from the event clouds. In practice, the differences between ESP
and CEP become blurred, so the more powerful CEP wins out.
Figure 5.6. Event stream processing
95

Problem Being Addressed

In most companies, business-relevant information is collected and available
data is aggregated. This is generally the domain of data warehouses that
usually receive information in nightly batch runs following past events. The
primary focus is on the data, not on the process information, which is actually
much more interesting. We miss out on the possibility of (virtually) real-time
processing of business information that would enable a much faster response
by the management to recent events. The discipline of business intelligence is
developing rapidly to keep up with this topic.
Impact on Architecture
While we have emphasized the importance of loose coupling in SOA, EDA
goes a step further: as an event is generated by an event source and is then
sent to the processing middleware, it is not known which functionality is
triggered afterwards. In SOA, the concrete service call would have had to be
made. For this reason, we speak of decoupling in EDA rather than loose
coupling.
96

An event-driven application consumes processes and generates events in a

decoupled way as described above. Event Driven Architecture supports
event-driven applications. The processing middleware accepts the events,
evaluates the contents, checks them against a set of criteria where applicable,
and then notifies interested consumers (Publish/Subscribe). The consumers
process the event and can themselves be implemented as a service.
Event Processing
Event processing refers to the operations performed on events, e.g. read,
change, generate and destroy.
A prerequisite for EDA is that the reality must deviate from expectations.
Therefore, the expectations as well as the significant deviation and the
corresponding response behavior must be specified.
Figure 5.7 shows a typical event processing chain: the event sources
(generators) generate events and place these in an event channel (notification).
Either a simple Service or a complex event processing engine (CEP) processes
the events from the event channel and triggers corresponding actions. In the
case of the specialized CEP processing, the engine correlates different
messages from multiple sources and produce in usage of the deposited logical
business rules new event. This resulting event normally triggers loosely
coupled SOA Service or Processes.
It is important that the event producer has no knowledge of any consumers
and thus no request-response message exchange pattern (MEP) exists. The
event flow always travels in only one direction.
From the architecture point of view, a separate Event Delivery Infrastructure
parallel to the ESB must be established for fast and reliable event processing.
Figure 5.7. Event processing chain

97

One acute problem in our current, complex architectures is that functional

events are often inadequately defined and handled. Individual events are not
meaningful and take no account of important functional correlations. They
occur too frequently for the causes and effects of each event to be analyzed
and properly handled. Filtering the relevant events only reduces their quantity,
but the meaning does not become clearer. This is called event detection phase.
After being detected, the events must be set in correlation (event correlation
phase). The events must be set in correlation to each other as the functional
significance of event correlations is much higher than that of individual events.
The number of events to be further processed is also reduced by the event
correlations. The challenge in this phase is that event correlations are often
difficult to identify, and the events are usually distributed throughout the
entire application landscape. Pattern identification within the mass of events
therefore acquires special significance as a result.
In the third phase, event processing takes place. It is possible to react to
simple events without any difficulty, e.g. by service calls or status reports.
There are plenty of platforms and software packages available for this ESB,
BPM, BAM dashboards, etc. Currently, however, status information is
generally interpreted in the users head or in a manual system. There are no
automatic comparisons with complex event patterns or combinations of
events from different sources. The current potential for reaction therefore
98

depends primarily on the employees and their experience and acute attention
span. Complex event processing engines can help with these tasks.
The discipline of complex event processing clearly differs from the traditional
queue- or database-based processing mechanisms. Caches are required that
permit complex correlations of very different events, including over extended
time horizons. This is also referred to as in-stream processing, which is
becoming increasingly important and can be seen in the emergence of
SQL-type, stream-based query languages. Rules engines also become an
important part of event processing, as they are typically used to define and
execute all the rules associated with event routing, processing, and
correlation.
Event Server Infrastructure
The Event Delivery Network (EDN) infrastructure necessary for event servers
can be realized through messaging infrastructures that are suitable for
transporting and routing the events. They provide the required quality of
service capabilities like reliable, transactional and secure delivery. This is
important since message ordering is not specified in EDA. The enhancements
needed for Enterprise SOA in comparisons to a classical Event Delivery
Network is the automatic event propagation across domains and distributed
clusters. An SOA-ready EDN needs to provide specialized adapters that
support
the
WS-Eventing
Specification
[W3-2009 http://www.w3.org/Submission/WS-Eventing/] for standardized
SOA event definition and connectivity.
To filter, aggregate and correlate events, complex event processing engines are
used. These engines process the events in a real-time streaming behavior
without taking account of off any previous delivered event. CEP Engines are
mostly integrated with an ESB or Process Engine via a service contract.
Two implementation aspects must be highlighted. Event servers should posses
the core properties of being lightweight and linearly scalable. The end users
are integrated via business activity monitoring (BAM), dashboards or separate
service or process calls. Figure 5.8 shows a typical infrastructure layout.
Figure 5.8. Event server infrastructure

99

SOA vs. EDA

EDA is sometimes called asynchronous SOA. This is because both
architectural styles use similar approach to deal with specific problems they
are trying to solve. However, as outlined earlier, the real world operates in a
more event-oriented than service-oriented basis.
Hallmarks of SOA include loose coupling of services, one-to-one correlation
between
providers
and
consumers,
and
usually
synchronous
(request-response) behavior. Hallmarks of EDA are decoupled interactions,
many-to-many communication, event-controlled actions, and asynchronous
operations.
There is no need to choose one option over the other, however. SOA provides a
very solid basis for EDA, and applications should typically use both styles.
A component should use SOA for a service call if:
A functional style and sequential flow is required
It is known precisely which service interface should be called
The service should be called exactly once
A response when service execution completes is expected
100

 A response is expected
A component should use EDA for an event publication if:
All recipients that may be interested in the event should be notified
It is not exactly known which and how many recipients are interested in the
event
It is not known how recipients respond to this event
Different recipients respond differently to the same event
Only one-way communication from the sender to the recipient is possible
In this respect, the popular equation 2 + 2 > 4 can be applied here, as the
total of the combination of both architectural styles is greater than the sum of
its parts. SOA carries communication patterns when executing predefined
processes and logic via a request-response mechanism. EDA applications use
the typical publisher/subscriber pattern and sometimes process large volumes
of events in order to generate a subset of new, actionable events.
SOA and EDA are complementary: together, they permit the creation of
on-demand applications with significant business benefits.
Case Study Example
The first consideration in applying EDA within RYLC was to SOA-enable
legacy systems. With little effort, COBOL based legacy CRM system could be
easily SOA enabled though the use of events. An XML-based event structure
would need to be created for each business transaction. Each event based on
this structure could then be posted to an accessible queuing system. The
Event Delivery Network would act as a consumer and deliver the events to
all listening SOA Services and BPMN Processes.
Within the RYLC Enterprise Portal, users have the capability to store their
own places of interest. This functionality is currently achieved by invoking
the backend COBOL APIs. This hook can be used to create an event and
send it to the EDN in parallel. An SOA-enabled BPM Process can be
registered to listen to the profile Change Event. After receiving the event,
SOA process engine would start and execute a new BPMN process called
Advertisement of new Mobile-Holidays.
101

In addition, EDA is also used for real time decision making. It is often the
case that more cars are returned to one location than another. To have a
more balanced delivery, the car check-in and check-out services can
generate an event that would send check-in and -out information to the
EDN. The CEP engine can pick up the produced events and create new
business events dependent on the specific business rule and additional
event streams like customer traveling close to the location. To deal with the
inventory imbalance issue, RYLC created a rule to create special
advertisements when more than 50% of the cars are delivered to a single
location.
Summary of Key Points
Real world largely operates on an event-oriented basis
There are three types of event processing simple, stream, and complex
Real -time processing of business events enables organizations to respond
faster to market conditions and customer demands
It is important that the event producer has no knowledge of event consumers
Enterprise service bus or messaging infrastructure is suitable for
transporting and routing the events
SOA and EDA are complementary, not incompatible architecture approaches
5.10 Enterprise Portal
Portals and portal technologies have been around for a while. Even though
they do not represent groundbreaking advances in technology or architecture,
the advent of SOA and BPM have had a significant impact on portals. Today,
portals are sophisticated mechanisms that are based on many next generation
technologies discussed throughout the chapter.
Concepts
A hierarchical end-to-end process chain can be decomposed to a fine-grained
level that contains process steps expressed as human executable tasks or
automated system interactions via task services. Enterprise Portals are
positioned at this level in the process chain.
102

Process steps conducted by humans are called human tasks. Examples of

human tasks include:
Capture of order details through a dealer onto the customer himself
Manual review of a large customer agreement
Receiving of a complaint in the call center
Removal of a bug from a fully automatic process
Specific business goals associated with each process step can be achieved
through a series of sub-tasks. These details can be graphically modeled inside
an Enterprise Portal as page flows. A page flow controls the order (the flow)
of the screens with which the participants interact.
There are different flavors of implementation strategies that stem from the
type of modeling being utilized and the translation mechanisms used to
convert these models into user forms. A rigid, BPMN type of sequence can
lead to fine grained micro forms along the process chain. The sequence of
micro steps is determined by gateways that decide whether a next step is
conducted in parallel or sequentially. This strictness can, however, lead to
inadequate or often non user friendly design.
Adaptive Case Management (ACM) is a new approach that addresses this issue.
It introduces a model that only determines the goal of the process step along
with some mandatory steps that are needed to fulfill this goal. This type of
model does not prescribe the exact flow the user has to take. An ACM based
UI provides all the necessary tools to execute a task. Thus, it provides the
users with more freedom to decide which route to take.
Impact on Architecture (SWAT)
There are multiple types of portals. Next generation SOA impacts each of
them differently.
Enterprise Portal
Figure 5.9 shows the components of an Enterprise Portal and how they are
embedded into a SOA middleware landscape.

103

Figure 5.9. Enterprise Portal and its relationship to SOA

middleware

The characteristics of each component of the Enterprise Portal are discussed

in the table below.

104

Portal
The mere graphical aspects of the enterprise portal are gathered in the
component called Portal. A portal consists of portlets for the task list, user
entry forms and enhancements for Enterprise 2.0 Collaboration.
The Portal is a container for displaying Portlets or Gadgets that is based on
open standards such as JSR 286 (the follow-up to JSR 168), WRSP, HTML 5,
REST, EDA, etc.
Transactional Enterprise Websites
Until recently, a typical solution architecture consisted of JSR 168-based
portlets that were embedded into interactive HTML-based Web forms. With
the advent of modern technologies, such as JSR 286, AJAX, JSF 2.0 and
HTML5, Enterprise Portals became capable of supporting the requirements to
build interactive websites and forms that talk to each other via Inter-Portlet
communication. This allows the creation of pluggable pieces of graphical user
interfaces that can be embedded into existing portals. A good example of this
is a newly built highly interactive unified task list when one task is selected,
an existing portlet is shown to the user. The end goal of this is a front end
architecture that follows SOA principles and comprises of loosely coupled UI
components.
The increasing support for HTML5 features can dramatically change portal
architectures. HTML5 enables creation of a kind of rich client inside the
browser that resembles the look-and-feel and feature richness of classical fat
client based applications that interactively communicate with backend
systems and processes.
Social Networks Enabled Websites
Some type of process steps need close collaboration between a number of
participants in order to jointly and efficiently achieve a business goal. An
enterprise portal can benefit from Web 2.0 type of collaboration features that
enable it to interact with existing social networks such as Facebook and to
resemble corresponding social network features inside the enterprise.
OpenSocial(http://www.opensocial.org/) standard has emerged as a way to
communicate with a variety of social networks. Such standards as oAuth,
OpenID and SAML provide a unified mechanism to handle all security aspects.
Social Networks such as LinkedIn, MySpace and Facebook are themselves
105

built on these standards and thus easily integrate with Enterprise Portals built
on these technologies.
Monolithic Workflow Solutions
One alternative to Portlet-based Enterprise Portals are proprietary workflow
editors and engines that allow creation of monolithic Web applications. They
are tightly coupled to the data supporting the automated processes.
These applications often have a tight coupling between the modeled process
and the UI forms. These forms are often automatically generated based on
data structures defined in the process model. They rarely support the use of
data from external systems. The benefit of this type of a solution is that it can
rapidly create automated processes. However, its drawback is lack of support
for integration and reuse of existing front ends from heterogeneous
applications.
HumanTask Specification as an Enabler for a Loosely Coupled Frontend
Architecture
A modern enterprise system has the potential to reuse pieces of existing front
ends and to allow the creation of automated transactional and homogeneous
use cases. For this type of Enterprise Portal, a unified task handling
component
is
crucial.
The
HumanTask
OASIS
specification
[http://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cd-07.html]
was created specifically for this purpose.
HumanTask based task handling implementations provide a standard API
that allows consumers to access data and actions in the context of a process
that stopped to wait for a human interaction. Any portal or even existing
application can access process information from their frontends. This allows
for a seamless and unified user view of the currently running process.
The combination of task handling built on HumanTask and HTML 5-based
forms allows a much more efficient and user-friendly, holistic and feature-rich
expert system type of user interaction when compared to the isolated
workflow forms typical built on top of proprietary workflow engines. This can
establish the foundation for an Adaptive Case Management type of frontend
architecture.
REST in Portals
106

REST,
or
Representational
State
Transfer
[http://en.wikipedia.org/wiki/Representational_State_Transfer], provides an
elegant and interoperable alternative to SOAP-based service calls. REST
enables fine-grained and fast access to process information and data.
REST-based Portals work best in combination with other technologies such as
HTML5, JSON and OData.
JSON is a data format that allows transporting data from backend systems
into frontend forms. JSON is a lightweight and compressed alternative to
XML for bundling data. As in XML, data is structured in JSON. JSON is
translated into XML through a server-side component that resides near the
front-end. This is necessary in order to communicate with XML-based task
services.
OData is a protocol for the retrieval and transport of data structures.
Presentation Service Category
In order to create reusable graphical user interface components, portlets
should be treated similar to backend services. They should:
Be registered in a global enterprise repository
Have a contract that defines actions data and possible events
Have the unique address, ideally a REST URL
Have a well defined SLA
These types of services are called Presentation Services. They show the
following additional architectural characteristics, when compared to other
types of services:
The callback must be asynchronous through a defined endpoint that consists
of an address and context at the end of the dialogue. Synchronous calls are
only allowed to retrieve status or fine-grained context specific data.
At the end of the use case, the processing of the transaction is triggered via a
asynchronous task service.
The UI components do not trigger follow-up tasks themselves. Instead, a
process engine decides on the next business process step and executes it. If it
107

is a human interaction, it is done via a task in the HumanTask-based

interaction component.
REST is used to transport relevant data into the forms.
Summary of Key Points
Portals benefit significantly from advent of SOA and BPM
Many emerging standards including HTML5, OpenSocial, HumanTask, and
others have an impact on portal technology and architecture
Portals benefit from using REST and JSON
5.11 Mobile Computing
Concepts
For the next 20 years, analysts foresee growth of small computers and
extinction of typical Jack of all trades machines such as PCs or laptops.
Mobile solutions are based on the basic principles: anyplace - anytime. This is
the old promise of the dotcom era. PCs or laptops, while technically ready due
to broadband Internet connection and WLAN or UMTS based Internet access,
are simply too large, cumbersome for many everyday uses.
Additionally, people are way more mobile today than any time in the past.
Thus, many communication services are based on mobile phones or
smart-phones. Apps are optimized for specific usage scenarios and therefore
are very easy to use and can be applied almost anywhere. Apple has launched
a real revolution with the iPhone, aided by the fact that mobile Internet has
become faster and significantly cheaper. The concept of specialized helpers for
every imaginable task and entertainment option drove the creation of app
stores that enabled users to install new functionality on their devices with a
single click. The expression Theres an app for everything... became the
motto of todays mobile and connected world. New opportunities arise
through the use of built-in sensors, such as Google Maps integration, location
based services, augmented reality, etc. The built-in cameras are more powerful
and increasingly replace compact cameras. Video telephony begins to prevail
over traditional telephone and cell phone services with such offerings as Skype
and Apple FaceTime. The speed of innovation is enormous and will continue
to accelerate. We are entering an app world, with things like tablets, Mac OS
108

and new Windows releases continuing to expand the horizons of mobile

computing.
More and more companies are creating mobile solutions as a way to speed up
business processes and include external partners in order to reduce their own
process costs and open new markets. We already use large amounts of B2C
(business to consumer) functionality through mobile apps: flight or train
reservations, package tracking, delivery date notifications, stock trading, and
others. Enterprises require creativity in building mobile solutions. Increasing
customer loyalty is often the target. While the dissemination of B2C
applications is already well underway, the B2B business evolves slowly.
Offering more performance to the business partners through the use of mobile
devices is one of the key new issues.
Impact on Architecture (SWAT)
Mobile solutions have a very close connection with SOA. Apps that work on
the enterprise level almost always need to communicate with backend systems.
Simply said, mobile front ends provide just another channel for existing
applications to be exposed to potential consumers. This introduces a number
of challenges. Mobile applications represent a new trend in UI design. They
have different resolutions from small to medium-sized and large screen.
They interact via touch, pen or keyboard, and they have a number of
restrictions related to server communication. Thus, existing interfaces cant be
transferred to mobile devices one-to-one or through automated scripts. This
also changes granularity of services supporting these applications. Still, all
SOA principles should be applied, so that the service-oriented paradigm is
fully implemented but with slightly different technologies than in the typical
enterprise context.
On the server side, communicating with mobile apps often requires a new
channel specific technical layer on top of a well-established SOA service layer.
Mobile applications are considered first class citizens in automated business
processes. They must be able to trigger a business process or fully participate
in one. Enabling users to provide input through mobile applications as part of
their business process activities requires a dedicated type of service that can
cope with the characteristics of mobile user interface technologies. RESTful
services are a more effective communication mechanism than SOAP-based
services to provide connection with mobile presentation services for reading
data from the backend. The primary reason lies in reduced overhead. Cache
109

settings in the REST/HTTP protocol allow data caching and are thus tolerant
to offline mobile operation.
JSON is used in mobile scenarios within REST services for data exchange.
JSON is a lightweight data format and has benefits over XML in terms of
performance and flexibility. The new service layer that provides specific
features for mobile app interaction translates the canonical data model that
task and entity services expose to the mobile client format.
The services transmit requested data to the client, which may save it into the
local web storage of an HTML 5 browser. This allows the client to work offline.
Additional resources that are needed to optimize the presentation, such as
select lists or suggestions, are provided as REST services that communicate
with existing data sources.
REST based addressing mechanisms are based on unique URIs. This allows
embedding SOA service functionality (function and data) in any local app.
Thus, inside mobile apps, objects and functions from different services can be
combined to create desired features. Since REST does not encompass
standards for asynchronous interactions with the backend, HTML 5 based
mechanisms, such as Web Sockets for server push and addressing principles
of WS-Addressing, will be merged with REST. Similarly, security solutions will
stem from existing industry standards, since REST does not provide its own
security mechanisms. For authentication and single sign one, it is a good idea
to use OpenID (openid.net), which has an established base through a variety
of social web sites. OAuth (http://oauth.net/) can be used for authorization.
There are no REST specific encryption standards and new ones need to evolve.
Case Study Example
To generate more business, RYLC started a mobile strategy consisting of
three steps.
The first step included the possibility for the customer to rent a car either
via classical web interface or through a mobile device (e.g. smartphone
application). Customers would be able to order a car on the run, maybe with
premium features such as delivery to a specific location within 30 minutes.
Alternatively, as in use today, customers could use instant checkout via
self-service terminals instead of waiting to complete all the details at a
customer representatives counter.

110

Another possibility to incorporate a mobile approach was found in

paperless damage management. Representatives used mobile devices to
record damages. The report was then routed electronically to the service
station.
Lastly, another business model as whole, called reverse logistics (that is the
outsourced collection) of cars from different locations became possible. In
this model, routing information for the collecting agency could be provided
though mobile devices.
Summary of Key Points
Mobile solutions have a very close connection with SOA
Communicating with mobile apps requires a new channel specific technical
layer on top of a well-established SOA service layer
RESTful services are a more effective communication mechanism than
SOAP-based services to provide connection with mobile presentation services
for reading data from the backend
5.12 Agent-driven SOA for Awareness and Smartness
Agent-driven software designs are not new. They have been used before SOA
has become a reality. However, applying agent-based approaches in
conjunction with SOA creates a powerful combination that provides effective
and agile solutions.
Concepts
A software agent is a piece of software that acts autonomously to perform
tasks on behalf of users. The design of software agents is based on the idea
that the users only needs to specify their high-level goals, constraints and
other relevant details instead of issuing explicit and formal instructions,
leaving the how and when decisions to the agents. An agent exhibits a
number of extraordinary features that make it beneficially different from other
traditional software components. The distinguishing features are autonomy,
goal-orientation, collaboration, extreme flexibility, self-starting and
disconnected operations, and mobility. Agent-like services are being
developed and deployed for specialized purposes.
Impact on Architecture (SWAT)
111

Agents are extremely crucial for dynamic service discovery, binding and
composition. Composition can be intelligently achieved by deploying
specialized agents. The standard lifecycle of composition processes includes
lookup for selection, matching of compatible and conforming functionalities,
and making decisions on calling and using the identified services. Agents
contribute in fully automating these sub-processes. Many times, reactive / late
composition is imperative due to unpredictable and swinging business
momentum. New services are being constantly added into the global service
repository by individual developers, open source community, and even the IT
units of large corporations. The Internet is truly global, and hence keeping the
unique functionality of each service being added, advertised and articulated in
local / remote and private / public service inventories is a really tough job. All
this promotes dynamic service interaction and orchestration. Agents are
critical in achieving this goal. Variety of approaches and products exist that
guarantee the efficacy of software agents in fulfilling the seamless composition
of services at runtime.
Semantic technologies contribute immensely and immeasurably in ensuring
meaningful and dynamic composition of services. Agents can be empowered
to perform completely automated composition through the use of semantic
technologies. Service composition could be performed dynamically through
agent collaboration without predefining abstract plans. Agent technology
offers excellent mechanisms to formally express and utilize richer semantic
annotations. Human intervention, interpretation and instruction will all
benefit from the ensuing association between SOA and the agent concepts.
Summary of Key Points
A software agent is a piece of software that acts autonomously to perform
tasks on behalf of users
Agents are critical for dynamic service discovery, binding and composition
Semantic technologies play a big role in agent-based design
5.13 Semantic SOA for Automation and Dynamism
Semantic computing has been a dream for many architects. It enables
disparate systems to speak in the same language without necessarily
implementing standard message definitions. Semantic computing represents a
112

natural extension to SOA due to ubiquitous nature of SOA and its underlying
technologies.
Concepts
Attaching semantics to all kinds of IT resources (applications, components,
services, data, etc.) is gaining momentum. This is needed to empower them to
capture process and unambiguously understand users preferences, prevailing
situations, and impending needs in order to contact all the right services to
implement the identified requirements. In a nutshell, semantics-attached
resource modules and models are necessary for delegating more work to
scores of distinct and distributed automation devices. New technologies
enabling IT systems to determine the best action based on the specific context
or current state are starting to emerge. They bring a potential to significantly
shift the way IT systems are architected and implemented.
The semantic web facilitates building and deploying semantic services and
systems. It considers the web as a globally linked database where web pages,
applications, service components and agents are marked up with semantic
annotations in order to be machine-processable and understandable. These
annotations are assertions about the variety of web resources and their
properties expressed in the Resource Description Format (RDF). Along with
RDF, one can use RDF Schema to express classes, properties, ranges, and
documentation for resources and the OWL-S ontology to represent deeper
relationships and/or properties like equivalences, lists, and data types. With
the semantic web infrastructures in place, applications can be written that use
annotations and suitable inference engines that automatically discover,
corroborate, compose, and correlate services.
With faster adoption of SOA technologies and approaches, the relevance of
semantic methods becomes more important since present day services do not
have the intrinsic support for empowering machines themselves to make
context-sensitive and cognition-enabled decisions and actions. This hampers
dynamic invocation of applicable service operations. That is, the automated
discovery of the capability and fit of participating services for specific
occasions. The goal is to minimize human intervention, so that service
collaboration can happen in a systematic and task-driven way. Combining
semantic technologies with SOA could introduce complementary capabilities
that would advance SOA to the next level of maturity and productivity.

113

Impact on Architecture (SWAT)

Semantic services are typically defined as self-contained, self-describing, and
semantically marked-up resources that can be published, discovered,
choreographed and executed in an automated fashion. The vision is to enable
both static as well as dynamic resources with semantics to facilitate
meaning-based processing. As a result, next-generation systems can mimic
humans in their assignments. Semantic SOA can move us towards fully
automated business systems. Semantic enterprise service bus (S-ESB)
becomes the key integration platform for connecting, mediating, transforming,
routing, and securing distributed semantic services.
Summary of Key Points
Semantic web facilitates building and deploying semantic services and
systems
5.14 Service Virtualization for Simpler Service Plug & Play
As complexity of SOA environments grows, infrastructure solutions must take
on more responsibility to alleviate this complexity. Virtualization, akin to
cloud computing, is the next step in evolution of the SOA platform.
Concepts
SOA sharply reduces the cost and complexity of constructing newer and
modular business systems through reusability. The corollary is that if the
library of services in a company grows, so do the benefits of SOA. However the
complexity of service-based environments goes up when there is an increased
number of services getting deployed and used. Generally, service-based
applications are more complex than standalone applications due to the fact
that application modules (services) need to communicate with one another in
order to fulfill the business functionality. This communication factor, if more
number of services are utilized in an IT environment, inherently induces
performance degrade (due to more code for enabling services to
communicate), deadlocks, security implications and even mishaps.
Application servers hosting several types of web components (beans, POJOs,
aspects, etc.) provide a community of common services for threat, thread and
transaction management, security and session management, resource pooling,
infrastructure support and access, etc., so that developers can spend their time
and energy for setting the flow and the functionality right. For services too, we
114

need robust containers to abstract those communication aspects and

externalize them to be invoked and involved during runtime.
Impact on Architecture (SWAT)
Any service-based application in a fast-growing environment typically
involves an orchestration of services (Java, .NET, C++, or PHP services) and
these services have to be configured, cared and made to communicate. Service
virtualization is an emerging approach for effectively deploying and managing
services by providing the common plumbing required by all service-based
applications. To do this, new services must be written to run as components in
a service container, which has to provide the relevant features so that newly
deployed services can be invoked as well as can invoke other services. The
separation between the service logic and its communication with other
services determines the effectiveness of service virtualization. Current ESBs
do not provide this facility and this important requirement is being taken care
of by SOA governance solutions.
Summary of Key Points
Complexity of service-based environments goes up when there is an
increased number of services getting deployed and used
Service virtualization is an emerging approach for effectively deploying and
managing services by providing the common plumbing required by all
service-based applications
5.15 Web APIs
With the explosion of social media and popular web sites, many other web
sites utilize services provided by them. This includes adding content from
other accounts, mashing content with maps, embedding videos, etc. To
facilitate these interactions, many of the popular web sites created their own
APIs. While most of them are based on existing technologies such as SOAP,
REST, JavaScript, AJAX, JSON, and others, many web-oriented APIs utilize a
slightly different paradigm. As a result, they need to be treated differently.
Some vendors have even started to offer products and services aimed at this
emerging market.
Concepts

115

There is a variety of ways that web sites enable consumers to access their
content.
Web Services these are typical Web Services aimed at providing content
from its parent site or execution of business logic. They are primarily intended
to be used from inside the application logic. Examples include Google and
eBay API.
RESTful Services these are services designed to be called directly from
other web sites or mobile platforms. RESTful calls are faster and more
lightweight than SOAP calls and thus are better suited for these uses.
Examples include some of the Google APIs and Yahoo Search API.
JavaScript APIs these are APIs provided through JavaScript libraries
supplied by the target web sites. They enable developers to integrate these web
site contents and operations into their own sites. Examples include some of
the Google APIs and Facebook APIs.
There is, however, a new trend worth exploring further. Web-oriented APIs
are emerging as a new way to enable users to access content and functionality
of other web sites. These APIs leverage HTTP as a transport but pass
operation name and parameters through the URL and therefore are not
RESTful. Examples of web-oriented APIs include Flickr API and GoogleMap
API.
Impact on Architecture
Web-oriented APIs should be treated separately from typical services. Because
they represent a transactional HTTP request, existing approaches, patterns,
principles, and tools targeting typical services might not be appropriate. By
the same token, practices applicable to standard web-based transactional
operations are not suitable either because they primarily deal with
transactional web sites, not services.
Due to the web-based interaction paradigm, many of the same approaches and
practices should be applied to the web APIs as are used with any cloud-based
service. Fault tolerance, failover, privacy, security are just some of the
elements applications utilizing web APIs should address in their architecture.
Regardless of how web APIs are implemented and accessed, web sites relying

116

on them should account for

incompleteness of transmission.

potential

latency,

unavailability,

or

A relatively new market has sprung up to perform API management services

via third party platforms. A number of vendors have begun offering API
management solutions that include:
API definition
Content, policy and lifecycle management
Billing
Intermediation
Security
QoS management
Consumer contract monitoring
Management of traffic from individual apps
Analytics
Reporting
Auditing
Alerting and monitoring
These are typically cloud-based offerings that can be hosted in the public or
private clouds. They help web API consumers account for all the concerns
discussed above. More importantly, these offerings help companies publishing
their APIs create a sustainable platform without significant investment on
their part.
Successful maturation of the web API market can create a collection of
services hosted by a virtual cloud of existing web servers. They can establish a
foundation for programmable web. Embedding these APIs into other
applications or web sites can become seamless and effortless. APIs from
different providers can be mashed together to create new content, interesting
117

linkages, and innovative applications. With the continued adoption of web API
management, API consumers will become better protected from unexpected
outages, spikes, and breaches. Web sites wishing to monetize their content
will have a viable platform and approach for doing so.
While standards for web APIs still do not exist, the future of programmable
web holds API registries that would enable potential consumers to discover
appropriate APIs, request access to them, and bind to the right interface at the
run time. API management vendors will integrate with these registries to not
only document and publish policy for each set of web APIs but also to manage
runtime aspects of API operations.
Summary of Key Points
Web APIs leverage HTTP as a transport but pass operation name and
parameters through the URL and therefore are not RESTful
A number of vendors are starting to offer web API management services
A cohesive collection of web APIs can establish a foundation for
programmable web

118

6. Next Generation SOA Practices

SOA is in a transition stage. It is moving from a much hyped, must-have silver
bullet approach to a widely adopted mainstream reality. Many organizations
have established SOA programs that bring significant benefits. Others may
just be starting on their SOA journey, but there is little doubt whether SOA is
the right approach for them. SOA has proven itself and became a widely
accepted norm for moving organizations forward.
As SOA evolved, so did its practices. The core service-orientation principles
that lay at the foundation of every successful SOA program evolved to
encompass a larger domain. As the technology and focus of SOA shifted to
accommodate the enterprise needs, organizations started to expand the reach
and scope of their SOA programs. The state of SOA practices, processes and
principles changed to incorporate this expanded scope, changing technology
landscape, and new SOA focus.
In this chapter, we will discuss the influencing factors behind SOA practice
changes and outline the patterns of evolution in reaching the next generation
SOA. We will describe what the next set of SOA principles, design patterns,
and practices look like while drawing parallels to those currently adopted and
widely available. While the technologies are addressed in detail in other
chapters, we will connect the dots between SOA technology and practice
evolution.
How Case Studies Are Used in this Chapter
Case studies in this chapter will describe what steps the Rent Your Legacy
Car company has employed to compete in the global marketplace. Since
RYLC embarked on a significant SOA transformation, it was able to adopt a
number of SOA technology solutions and approaches, which now need to
evolve to meet competitive pressures. As most of its major competitors
started to branch out beyond the typical SOA implementation, RYLC must
also adopt some of the emerging SOA practices to keep and further the
gains it was able to make in its quest to become a leader in this space.
6.1 Next Generation SOA Principles
Evolution of the service-oriented computing has taken SOA beyond its
traditional roots. While its focus is still primarily on services and their reuse,
119

many more architectural constructs now fit under the SOA umbrella. These
new areas are covered extensively in the Next Generation SOA Technologies
chapter. To provide continuity from this content, lets highlight the most
relevant ones. The modern architectural elements that are important to
consider for all subsequent discussions in this chapter include:
Business Process Management (BPM)
Business Rules Engines (BRE)
Cloud Computing
Event Driven Architecture (EDA)
Complex Event Processing (CEP)
Web Oriented Architecture (WOA)
Service Oriented Business Intelligence (SOBI)
Grid Computing
Master Data Management (MDM)
As a result of adding these new architecture constructs to SOA, the core
service-orientation principles need to expand. This, however, does not mean
that the existing SOA principles become irrelevant or dont need to be
followed. On the contrary, adherence to them becomes much more important
as additional architectural concerns only dissipate the architects focus and
they become harder to enforce.
The core service-orientation principles are well documented in the
Service-oriented Computing SeriesSOA: Principles of Service Design book. To
recap, the following design principles are considered critical for SOA.
Service Contracts
Service Coupling
Service Abstraction
Service Reusability
120

 Service Autonomy
Service Statelessness
Service Discoverability
Service Composability
In the subsequent sections we will discuss how the changes to the SOA
landscape and practices affect all the SOA principles.
Service Contracts
The Service Contracts principle guides all services to share a standardized
contract. It enables services and their consumers to communicate in a
pre-defined fashion. There are multiple levels, at which contracts are
standardized. They include:
Functional Service Expressions
Service Data Representation
Service Policies
These represent standard parts of the contract, thus enabling successful
communication between services and their providers.
When designing service contracts, several considerations need to be kept in
mind.
Data transformations
Granularity
Service models
This is where the impact of modern SOA practices is felt the most. While the
general idea behind the Service Contracts principle remains the same, how it
is applied demonstrates real differences. Thus, several extensions to the
Service Contracts principle are needed. They involve several areas of a service
contract:

121

 Service faade service faade should be introduced to guard against

changes in the underlying technology, implementation, or architectural
principles
Service invocation independence regardless of the way a service is
invoked or accessed, its contract should remain standardized
Contract specificity service contracts should have explicit definitions
with semantic meaning standardized across consumers and providers
Table 6.1 contains all the details of the extensions to the Service Contracts
principle and their implications.
Table 6.1. Extensions to the Service Contracts principle.

122

123

The risks associated with the new extensions outlined above remain the same
as already documented.
Versioning: introducing faade contracts complicates the versioning
considerations to an extent. While the same logic needs to be applied as before
when considering whether to create a new version of the service or not, faade
contracts may or may not need to be versioned. Even though it is preferable
not to version faade contracts, it may be necessary under some circumstances.
On the other hand, however, service faade may provide a way to postpone
versioning until it is absolutely essential. By addressing specific consumer
needs through a faade contract, the standard contract may not need to
change at all.
Technology Dependencies: since services need to remain technology agnostic
and contracts independent of service endpoint or type, specific technologies
used to implement a service or its contract should not have any impact on its
execution or consumption.
Development Tool Deficiencies: even though the development tools have
evolved significantly since the early days of SOA, many of them still present
many challenges. Overreliance on development frameworks or
auto-generation tools can cause problems if they are not used carefully.

124

Overall, the Service Contracts principle is still very relevant and should be
widely adapted to make SOA program successful.
Service Coupling
The Service Coupling principle emphasizes loose coupling between services,
their internal implementations, and consumers. This SOA principle lies at the
core of service-orientation.
There are several coupling types that have been identified:
Service Contract
Logic-to-Contract Coupling
Contract-to-Logic Coupling
Contract-to-Technology Coupling
Contract-to-Implementation Coupling
Contract-to-Functional Coupling
Service Consumer
Consumer-to-Implementation Coupling
Consumer-to-Contract Coupling
Based on the modern state of service-orientation, existing coupling types can
be further extended. These extensions are necessary to further protect the
consumers from constant evolution in technology and architectural principles,
incorporate new patterns and architecture styles into contract definitions, and
ensure a more complete abstraction. These extensions can be summarized as
follows:
Contract-to-Logic Coupling avoid any coupling with the underlying
technology platforms, especially in those cases when these platforms are
SOA-enabled or make exposing services very easy
Contract-to-Technology Coupling avoid including any underlying
technology details into the contract, especially in situations when this is made
easy by the implementation platform

125

 Contract-to-Implementation Coupling avoid exposing any

implementation details through the service contract, especially when
underlying platforms automatically generate service contracts
Contract-to-Functional Coupling avoid exposing any service
functionality or internal logic, especially in those circumstances when this is
made easy by the implementation platform or technology
Consumer-to-Implementation Coupling always invoke services
through the published contract, especially if shortcuts are easily accessible
through the platform APIs or underlying technologies
Table 6.2 defines Service Coupling extensions, along with associated risks and
best practices.
Table 6.2. Extensions to the Service Coupling principle.

126

127

128

The modern approaches to SOA present additional challenges related to

coupling. Some of the platforms or technologies are relatively new, which
leads to their misuse due to lack of comprehensive best practices and
guidelines. Others are easy to subvert due to their nature. A couple of very
telling examples include an EDA implementation where messages being
consumed by the event engine contain details of their processing and/or
routing, cloud services that expose the information about their underlying
platform, or business rule services that provide rule execution details or allow
specific instructions to be passed into the rules engine. Many more coupling
scenarios will be uncovered as the modern platforms, technologies, and
approaches continue to evolve.
Service Abstraction
The Service Abstraction principle directs services to expose the minimal
necessary information about themselves to the consumers through their
contracts. In the modern state of SOA, the importance of this principle is
amplified by the pervasive nature of SOA, continued expansion of the
129

technology and platform solutions, and constant evolution of the SOA

techniques and approaches.
Several abstraction types have been identified:
Technology Information Abstraction
Functional Abstraction
Programmatic Logic Abstraction
Quality of Service Abstraction
Based on the modern state of service-orientation, these abstraction types can
be expanded to cover additional areas. They are necessary to accommodate
next generation SOA practices and architectures. These extensions can be
summarized as follows.
Technology Information Abstraction service contracts should be
abstracted from the details of the underlying technology and platforms
Functional Abstraction functional details or unnecessary information
about the service should not be exposed through the contract
Programmatic Logic Abstraction internal details of service
implementation should not be exposed, especially when it is easy to do
through the platform tools or out-of-the-box functionality
Quality of Service Abstraction service policy details should not be
exposed through the service contract
Table 6.3 details the extensions to the Service Abstraction principle, along
with associated risks and best practices.
Table 6.3. Extensions to the Service Abstraction principle.

130

131

132

The nature of the Service Abstraction principle doesnt change drastically with
the evolution of the service-orientation and service-oriented practices.
However, the new technologies that now participate in the SOA
implementation present new challenges to the architects and developers.
Special attention needs to be paid to abstracting all of the service
implementation details and platform specifics. Some of the newer
technologies and practices make it easy to exploit shortcuts, which may lead to
lack of abstraction if not used with caution. Additional maturity in the modern
SOA practices and tooling is needed to minimize potential circumvention of
the Service Abstraction principle.
Service Reusability
The Service Reusability principle lies at the core of the service-orientation. It
attempts to maximize the reuse of existing services, thus striving to attain one
of the core SOA goals. This principle is not impacted with the introduction of
modern SOA practices and technologies. However, these new factors extend
the reuse boundaries, best practices, and key premises. Extensions can be
defined for the following areas:
Service Interface reusability can be increased if a service can expose
multiple interfaces and facades to better serve its consumers
Service Functionality services exposing well defined, independent
functionality can significantly increase their reusability
Table 6.4 defines the extensions of the Service Reusability principle, along
with associated risks and best practices.
Table 6.4. Extensions to the Service Reusability principle.

133

134

With the modern SOA landscape, the abundance of ways to invoke, expose,
and integrate existing services provides additional challenges and may, in
some cases, limit services reusability potential. Special attention should still
be paid to how the service is intended to be used and who its potential
consumers will be. Specific platforms, tools, or implementation techniques
should not impact services reusability in any way. The continually changing
and evolving technology space still provides challenges to services reuse
potential, but proper application of the Service Reusability principle should
limit the overall impact.
Service Autonomy
The Service Autonomy principle calls for the services to exercise a high level of
control over their underlying runtime execution environment. This also

135

implies non-overlapping boundaries between the services. There may be

several levels of service autonomy.
Service Contract Autonomy
Shared Autonomy
Service Logic Autonomy
Pure Autonomy
Mixed Autonomy
Modern SOA technologies and practices do not significantly change the
Service Autonomy principle. However, the autonomy levels specified above
can be expanded to cover additional areas. These extensions can be
summarized as follows:
Service Contract Autonomy services should not contain any overlaps
in their contracts, especially when tools used to produce this contract make it
easier to do so
Shared Autonomy services should never be invoked through their
private interfaces, especially if these exist and are easy to consume
Service Logic Autonomy service design should identify and recognize
any shared assets used by the service implementation to ensure they can
comply with services SLAs
Pure Autonomy ensure proper autonomy level for each service and
recognize when pure autonomy can and should be achieved
Table 6.5 details the extensions of the Service Autonomy principle along with
associated risks and best practices.
Table 6.5. Extensions to the Service Autonomy principle.

136

137

Modern technologies, tools, and practices dictate a slightly different approach

to service autonomy. While services should strive to be autonomous in their
contracts and implementations, this goal becomes hard to achieve due to
excessively shared nature of modern technology. Platforms such as BPM,
business rule engines, clouds, grids, and event processing are designed to be
cross multiple functional and business boundaries, used by a variety of
consumers, and shared by a number of systems. It becomes inherently hard to
completely decouple service contracts and logic from these platforms.

138

Therefore, the emerging best practices dictate a strong, independent, and

proactive management of shared enterprise assets. This will lead to a solid
foundation of enterprise platforms that can be successfully used by enterprise
services should a need arise.
Service Statelessness
The Service Statelessness principle advocates minimization of state
management that a service performs. The less state information a service
handles or manages, the more scalable, reusable, and manageable it is.
Modern service-oriented technologies and practices highlight the importance
of the Service Statelessness principle. This is due to an increased level of
dependency between services and platforms being utilized in their
implementation. Services are more prone to utilize modern platform
capabilities to implement the necessary functionality and vice versa. Some
modern platforms are more state aware and therefore pose a greater challenge
to statelessness of the services they use.
Because modern technologies emphasize more stringent requirements for
service statelessness, the Service Statelessness principle should be extended
further. These extensions are related to specific next generation platforms and
therefore have different implications. They can be summarized as follows:
BPM avoid exposing any information about internal process state or
expecting processes to know about external state
Business Rules Engine ensure that rule services and business rules
invoked as part of a service execution do not carry state information or make
assumptions about internal rule state
Event Processing ensure that event services have no knowledge about
state of event processing engine or complex events being processed
Table 6.6 details extensions to the Service Statelessness principle along with
associated risks and best practices.
Table 6.6. Extensions to the Service Statelessness principle.

139

140

Regardless of the technologies used in the service-oriented environment,

service statelessness remains one of the key SOA principles. Modern
technologies and practices make it harder to implement because of the issues
cited above. Due to this, strong governance over service-orientation in any
way, shape, or form should exist to guide the appropriate application of the
Service Statelessness principle.
Service Discoverability
The Service Discoverability principle emphasizes the need for services to
publish metadata containing vital information that allows them to be
effectively discovered and interpreted. Services can be discovered at either
design-time or run-time. Even though run-time discovery has been the most

141

touted benefit of Web Services and registries when they first came out, the
focus has primarily shifted to design-time discovery.
Modern technologies and practices do not introduce significant changes to the
Service Discoverability principle. However, due to greater emphasis on
design-time discovery, establishing a more comprehensive service metadata,
governing the entire service lifecycle, additional extensions are necessary.
They can be summarized as follows:
Run-time run-time discovery should be used only when circumstances
allow it and semantic meaning of all contract elements are clearly understood
Design-time all services should be discoverable at design time, and this
process should be controlled through the SOA governance practices
Table 6.7 details these extensions to the Service Discoverability principle
along with associated risks and best practices.
Table 6.7. Extensions to the Service Discoverability principle.

142

Since design-time discovery is critical to success of the entire SOA program,

everyone in the organization must subscribe to the Service Discoverability
principle. Modern technologies and practices introduce an additional level of
complexity into this model, as they enable a variety of protocols and interfaces
to be used, change the dynamics of service invocation and usage, affect
services non-functional and metadata characteristics, and complicate the SOA
governance processes. On the other hand, however, modern SOA platforms
provide robust and comprehensive platforms supporting design-time
discovery and elevate the maturity of the entire service lifecycle and its
governance.
Service Composability
The Service Composability principle ensures that services can be effective
composition participants, regardless of the size and complexity of the
composition. Since the goal of SOA is to maximize service reuse, composition
of existing services plays a large part in achieving this goal.
Modern technologies and practices introduce some changes to the Service
Composability principle, primarily in how it is interpreted and applied. Its key
postulates remain the same, but their applications change. This is primarily
due to increased complexity modern technologies and practices introduce.
143

Each extension is related to a specific area of service design and

implementation.
Service Contract ensure that services are as atomic as possible and
adhere to all the SOA principles
Composition Implementation avoid custom coding
compositions and use appropriate next generation tools instead

service

Standards use the most appropriate standards and avoid very new or
unproven ones
Table 6.8 details the extension to the Service Composability principle along
with associated risks and best practices.
Table 6.8. Extensions to the Service Composability principle.

144

145

Modern SOA platforms such as cloud, grid, or event processing do not have
significant impact on the Service Composability principle, as they primarily
deal with service implementation. Event processes, however, need to be
employed in orchestrations carefully, as they are typically used to notify their
subscribers of specific events that occurred.
In practice, BPM engines and ESBs with process management capabilities
have become de-facto standards for implementing orchestrations. The key
decision that typically needs to be made is what types of orchestrations,
compositions, and choreography is performed on which platform.
Summary of Key Points
Modern SOA technologies and practices have a fundamental impact on the
existing SOA principles, although the core principles remain intact
Most of the extensions to the SOA principles stem from the increased
complexity of the SOA solutions and approaches as a result of the modern
SOA technologies and practices

146

6.2 Next Generation SOA Design Patterns

A number of SOA design patterns exist. Many of the proven and established
ones are described in detail in the SOA Design Patterns book from this series.
The complete, up to date SOA patterns catalog can be found at the SOA design
patterns web site soapatterns.org. As a public resource, new patterns are
being contributed every day.
Despite the general availability and extensibility of the existing SOA design
patterns, new ones continue to emerge every day. Modern SOA technologies
and practices provide a significant influence on the new patterns.
In this section, we will concentrate on defining the primary trends influencing
SOA patterns and identify what general impacts will be felt by all current and
future patterns. Since each modern SOA technology and practice provides a
distinct set of influences, we will examine each one and identify how it will
impact SOA patterns. Existing established patterns that fall under each
modern SOA area will be identified also.
Business Process Management
Business Process Management or BPM is not new. The technology has been
around for a while. In fact, BPM has been a major influencing factor in
increasing SOA adoption and industry penetration. However, effective
business process identification, modeling, and management practices,
especially as related to SOA, have emerged only recently.
Since much has already been written about the close relationship between
BPM and SOA, we will not reiterate why this is important or how the two
practices support each other. However, it should be noted that modern BPM
tools and practices rely almost exclusively on service-orientation for
integration with external systems, executing business logic, and performing
any activities outside of basic platform capabilities. To an extent, BPM and
SOA have become very closely coupled and virtually inseparable.
Several design patterns related to business process management already exist.
They include:
Process Abstraction addresses the problem of independent separation
and governance of non-agnostic process logic

147

 Process Centralization examines how abstracted business process

logic can be centrally governed
Compensating Service Transaction tackles the issue of consistently
accommodating composition runtime exceptions without requiring services to
lock resources
These patterns can also be broadly characterized as related to Orchestration or
Composition.
Modern BPM and SOA practices necessitate additional design approaches
beyond the design patterns specified above. Table 6.9 defines these
approaches along with potential applications.
Table 6.9. Design
Management.

approaches

related

to

Business

Process

148

Additional patterns and design approaches will invariably be created as SOA

and BPM practices continue to evolve. The close proximity between these two
computing areas pushes the boundaries of both disciplines and, as a result,
perpetuates the innovation and evolution cycle.
Business Rules Engines
Business rules engines (BRE) have been a major part of the IT landscape for a
while. Just like BPM, they enjoyed a close relationship with SOA. However, as
the two practice areas continue to evolve, their cohesion becomes stronger.
While business rule packages do not rely on service-orientation for their
internal implementation, almost all of them use SOA to expose executable
rules. Once these service interfaces are generated, they are treated as any
other third party service interfaces. There are, however, some important
149

differences that should be kept in mind when dealing with rule services. They
are documented in Table 6.10.
Prior to discussing extension to design approaches related to business rules
management, it is important to note that related patterns have already been
identified.
Rules Centralization determines how business rules can be abstracted
and centrally governed
Canonical Schema examines how services can be designed to avoid data
model transformation
Decoupled Contract defines how a service can express its capabilities
independently of its implementation
It is also important to keep in mind that service contracts and interfaces
exposed from the business rules engines are often customizable. Thus, it is
possible to establish a service interface that complies with majority of SOA
best practices and design patterns. However, because these services are
managed and generated by a third party software package, they should be
treated distinctly from those built in-house.
Modern SOA approaches warrant the extension of the existing patterns. These
are detailed in Table 6.10.
Table 6.10. Design
Management.

approaches

related

to

Business

Rules

150

Due to its close relationship with BPM, rule services sometimes fall under the
same context. It is important to make a differentiation which category a
service falls under when designing or invoking it. It is also important to keep
each service separate from external influences in order not to compromise the
design.
Event Driven Architecture
Event Driven Architecture (EDA) is an extension of SOA specifically related to
processing and routing of asynchronous events. It is based on the concept of
posting events to a central processing facility and allowing it to make
decisions on how to route or process the events. The primary differences
between EDA and SOA lie in EDAs strictly asynchronous nature. All other
concepts related to each architecture style are virtually identical.
Complex Event Processing (CEP) is a specific implementation of EDA that
provides dedicated facilities to subscribe to and process complex messages. In
this section, all of the concepts discussed in relation to EDA also apply to CEP.
151

Several SOA design patterns related to event processing have already been
identified. They include:
Event-Driven Messaging defines how service consumers can be
automatically notified of runtime service events
Intermediate Routing examines how dynamic runtime factors affect
the path of a message
Event Message identifies how messaging can be used to transmit events
from one application to another
Publish-Subscribe Channel deals with how the sender can broadcast
an event to all interested receivers
EDA is a relatively new additional to the service-orientation family. Therefore,
this space continues to evolve. Additional design approaches beyond those
already identified are documented in Table 6.11.
Table 6.11. Design
Architecture.

approaches

related

to

Event

Driven

152

153

Most ESBs today provide event processing capabilities. They are typically
based on existing ESB features, asynchronous messaging, transformation,
content-based routing, business rules, and publish-subscribe mechanisms.
Some vendors also provide distinct Complex Event Processing facilities. They
incorporate BPM, business rules, and long-running transaction functionality.
As the EDA practices continue to evolve, they will eventually become
indistinct from those falling under the SOA umbrella.
Cloud Computing
Cloud Computing is the most recent advancement in the technology space. It
describes an elastic computing resource pattern. While Cloud Computing
primarily refers to an architectural approach, a variety of products and vendor
offerings have already been established.

154

Cloud Computing has been universally recognized as synergetic and

complementary with service-orientation. This is because it fits very well with
the need for shared services to be scalable on demand and anticipate potential
peak loads. Cloud Computing eliminates the need for rigorous capacity
planning and creates the truly elastic scalable computing platform required
for SOA to succeed.
While there are no SOA design patterns directly attributable to Cloud
Computing, a number of existing patterns can be applied when dealing with
clouds. These include any patterns related to the message routing and
mediation, service bus, proxy capability, and asynchronous messaging. Based
on the state of SOA evolution and Cloud Computing maturity, additional
design approaches can be defined. They are detailed in Table 6.12.
Table 6.12. Design approaches related to Cloud Computing.

155

Cloud Computing brings a new dimension to service-orientation. It allows the

conceptual architecture to be implemented as-is, without adjustments for
capacity limitations or environmental issues. Due to its high degree of synergy
with SOA, this area will continue to evolve, and many more design patterns
are sure to be identified.
Web Oriented Architecture & REST
Web Oriented Architecture (WOA) is a term coined by Gartner that refers to
the simplification of protocols used in service-oriented systems, especially
those that are Web-based. REST is an example of a simplified communication
156

paradigm. In this section, we will refer exclusively to WOA and will not
address REST or other specific architectural approaches or principles directly.
This is due to the fact that WOAs umbrella covers a variety of protocols and
approaches.
While the primary difference between WOA and SOA is in the desired protocol
usage, all of the SOA design patterns and best practices still apply. WOA,
however, comes with its own unique set of design patterns, some of which
have already been identified. They include:
Alternative Format addresses how services can exchange data based on
less common or non-standard formats
Entity Linking defines how services can expose the inherent linkage
between business concepts in order to support loosely-coupled choreography
Layered Redirect determines how a service can be moved without
impacting its consumers
Transport Caching examines how temporal and activity-specific state
data can be efficiently persisted
Uniform Contract identifies how a service composition can be
reconfigured at run-time to take advantage of evolving alternative service
endpoints
Since WOA calls for simplification of interactions between consumers and
service providers, by extension, it implies avoidance of more robust protocols
such as Web Services. Because typical SOA programs attach strict
requirements to how services are exposed, used, managed, and discovered,
specific design approaches related to WOA should be established. Table
6.13 defines them in detail.
Table 6.13. Design
Architecture.

approaches

related

to

Web

Oriented

157

Even though the term WOA exists, it provides insignificant differentiation

from the established SOA practices. Despite the differences in the
communication and invocation mechanisms, architectural paradigms for
service exposure and consumption, protocols, and many other aspects of the
WOA approach being utilized, all of the governing principles, supporting
technologies, design patterns, and practices align almost exactly with SOA. In
the future, WOA will most likely be fully consumed by the SOA domain, and
its practices will become an indivisible part of SOA practices.
158

Semantic Computing
Semantic Computing represents a concept that allows software, services, and
possibly even specialized appliances to seamlessly interoperate. All of the
parties involved in the conversation would understand each other, even
though they may be speaking different languages. Semantics provides the
universal decoder that allows for this kind of interoperability. Semantic
computing envisions a common language or grammar that all of the enterprise
systems utilize to communicate with each other. Terms defined through this
grammar have the same meaning no matter how they are used.
While semantic SOA has not become widespread, some of its concepts have
become adopted throughout the industry. This includes Master Data
Management (MDM), semantic integration, canonical modeling, and others.
Related design patterns have also been created.
Canonical Expression defines how service contracts can be consistently
understood and interpreted
Canonical Schema examines how services can be designed to avoid data
model transformation
Aside from a common semantic foundation, services built on a semantic SOA
platform do not significantly differ from those that are not in terms of
following established SOA design patterns and best practices. All of the SOA
principles still apply to semantic services.
They key difference is integration. When all the services are based on the same
semantics, mapping between different fields and entities becomes
unnecessary. Service orchestrations, compositions, and choreography are
simplified to the level of executing the logic, controlling the flow of the process,
and returning a result. To achieve this level of simplicity, underlying platforms
such as ESBs, BPM engines, and others should become semantic-aware. MDM
can play a significant role in this.
Summary of Key Points
Each next generation technology influences SOA in its own way and
necessitates creation of related design patterns

159

 Regardless of the technology, existing SOA design patterns and practices

should be applied in appropriate situations
6.3 Technology Direction
SOA has become so pervasive that many technologies are now SOA-enabled.
Many more SOA infrastructure platforms have been introduced. As a result,
the typical SOA ecosystem has expanded beyond its original roots of pure
service-orientation. It now encompasses business-orientation, enterprise
agility, and end-to-end integration capabilities.
The established technology approach to SOA was primarily centered on the
Enterprise Service Bus and managing the service lifecycle. Besides the ESB,
typical SOA platforms included such capabilities as service registry, metadata
repository,
service
management,
integration,
orchestration,
and
security. Figure 6.1depicts a typical SOA platform view.
Figure 6.1. Typical SOA platform capabilities revolve around the
Enterprise Service Bus.

160

With continued expansion of the SOA platforms, capabilities, and related

components, the SOA ecosystem has become much more complex. It includes
or is closely associated with functions such as:
Business process management
Business rules management
Cloud Computing
Event processing
Business Intelligence
Master Data Management
Addition of these elements significantly extends the SOA platform for next
generation SOA, as shown inFigure 6.2 below:
Figure 6.2. Modern SOA platform is expanded to cover a much
more diverse set of technologies and capabilities.

161

The increased complexity of the SOA environment contributes to the

expansion in the related technology practices. Even though the existing
foundational principles remain intact, additions to the scope and breadth of
the SOA platforms necessitates this shift. There are several major influencers

162

that shape modern SOA technology practices. They are discussed in detail in
subsequent sections.
Cloud Computing
Cloud Computing helps shift the emphasis from tight governance over
computing capacity needs of shared services and consumer demands to
defining and adhering to service SLAs. Because Cloud Computing provides
elastic computing capacity virtually on demand, services that are hosted in the
cloud no longer need to worry having enough resources to serve their
consumers. Instead, the focus is shifted to managing services response time,
uptime, failover, and other vital run-time characteristics.
As more and more services are hosted in the cloud, the importance and
prominence of the service registries, repositories, and run-time management
tools become more evident. Several important practices emerge in response to
this need. They are captured in Table 6.14.
Table 6.14. SOA practices related to Cloud Computing.

163

Even though there are many benefits to Cloud Computing, it also introduces
additional concerns. Some SOA governance matters such as capacity planning
and careful demand forecasting are replaced by rigorous SLA definition and
management.

164

Business Process Management

Business Process Management tools have become a vital part of the SOA
environment. They are not only used to orchestrate or choreograph a number
of services, but they also help increase SOA adoption through automating and
service-enabling processes across the enterprise. Additionally, many ESBs
now include BPM capabilities. A number of other platforms have started
including business process modeling and/or execution functionality.
While BPM tools and technologies have their own specific best practices, there
are several areas that contribute directly to SOA. They are primarily related to
how BPM fits into the SOA environment and is engaged in the
service-oriented activities. Details are included in Table 6.15.
Table 6.15. SOA practices related to BPM.

165

As the BPM and ESB capabilities continue to evolve and merge, some of the
practices described above may become obsolete. However, while BPM engines
remain separate, the issues addressed through them will remain.
Business Rules Engines
Business rules engines have become as ubiquitous as the BPM tools. They
exist in many forms, shapes, and sizes. There are robust, standalone rules
management platforms. There are rules engines integrated with the BPM and
166

other solutions. There are also lightweight rules engines that are designed to
quickly and efficiently execute externalized sets of rules.
The specific rules platform being utilized brings with it a set of best practices.
This has impacts to services using these engines and how they are structured.
Since some ESBs may have their own rules execution capabilities, this
scenario should also be considered in the overall impact. SOA practices
related to usage and invocation of rules engines are presented in Table 6.16.
Table 6.16. SOA practices related to Business Rules Engines.

167

Rules engines are becoming more pervasive and standardized. They may soon
become a standard part of many packages, especially those that are part of the
SOA environment. This will change many of the existing practices.
Event Processing
To a large degree, event processing represents asynchronous SOA. Therefore,
it follows the same practices and approaches that apply to SOA today. There
are some notable differences, however. While events are posted
asynchronously and are eventually routed to their consumers, the processing
and routing logic may be quite complex. Therefore, rules engines often play a
big part in event processing. The same is true for BPM tools. They may be
utilized to manage the overarching flow and execution of the event processing
and routing logic. As a result, SOA, BPM, and rules management practices
apply.
Some vendors have begun offering Complex Event Processing (CEP) engines.
They are based on the same concepts as described above but are designed to
more efficiently implement the complex processing and routing logic.
On top of existing practices, event processing brings additional dimensions
that are discussed in Table 6.17.
Table 6.17. SOA practices related to event processing.

168

Because events are processed asynchronously, other technologies can be used

to make their handling more efficient. This includes grid technologies and
cloud computing. Grid can allow offloading complex event processing from a
proprietary to a fully distributed platform without adding any extra computing
capacity. Cloud computing can provide elastic computing resources for event
processing with unpredictable computing needs or usage patterns.
Master Data Management
Master Data Management (MDM) is an approach to consistently and
effectively manage key data entities across the enterprise. This typically
includes tools and processes that help consolidate, cleanse, distribute, and
expose this data. Additionally, services to access key data elements may be
offered through the MDM platform. Many vendors are offering specific tools
that provide Master Data Management capabilities and can expose a number
of vital services.
Services exposed through the MDM platform typically offer tremendous value.
This because key corporate data entities managed through MDM processes
are the most critical to the organization and are widely shared across
169

applications. As a result, almost all the services exposed by the MDM

platforms need to be treated as shared enterprise services.
MDM tools may be tied to other technologies described above. This includes
BPM, business rules, cloud computing, and others. All of this impacts
MDM-specific practices that are described in Table 6.18.
Table 6.18. SOA practices related to Master Data Management.

Master Data Management is not a new practice. However, it has not gained
large enough momentum until recently. As an approach, it will continue to be
important for years to come. Specific tools and implementations will
inevitable change. For example, some MDM solutions are starting to leverage
the power of cloud computing. The general trend within the MDM space
seems to be consolidation with integration, ESB, ETL, and other tools. All this
contributes to an ever shifting landscape of best practices.
Case Study Example

170

As RYLC started its transformation journey by automating its business

processes and introducing SOA, its architects came up with the architecture
shown in Figure 6.3.
Figure 6.3. RYLC conceptual architecture enables
automation and integration with backend systems.

process

Several next generation design patterns and SOA principles were adopted as
part of this architecture. All CRM services were exposed via the ESB. The
guiding principle to never call these services directly was followed in this
scenario. Workflow and rule services were invoked as part of the process.
Both of them used standard service interfaces that encapsulated the
underlying technology platforms and specific workflow or rule
implementations. These architectural decisions helped achieve loose
coupling between all of the supporting systems, services, and the underlying
processes.
171

Each of the services involved in the process used its own data model based
on the systems there were interacting with or exposing. The business
process relied on the canonical data model developed to streamline the
development and reduce semantic discrepancies. To address differences
between domain and canonical data models implemented in different parts
of the system, a faade pattern was used to help facilitate the translations.
The Notification service presented an example of an event service. Once car
rental was confirmed, a customer needed to be notified. The Notification
service was invoked asynchronously as the last step in the process. It
needed to deliver the message to the customer via the preferred delivery
method. The service interface was developed specifically to abstract the
available event subscribers, delivery methods, or communication
mechanisms. ESB and the rules engine were used to route the messages to
the appropriate consumers.
Summary of Key Points
On top of typical service-orientation functions, modern SOA practices
encompass business-orientation, enterprise agility, and end-to-end
integration capabilities.
The increased complexity of the SOA environment contributes to the
expansion in the related technology practices. Each modern SOA platform
requires its own practices to be successful.

172

7. Next Generation Service-Oriented IT Enterprise

Introduction
A next generation service oriented enterprise is one that uses leading edge
SOA technology both to optimize its business operations and to achieve its
strategic business goals. In such an organization, the IT department will
understand and be motivated by business issues and opportunities, while the
business executives will understand the potential value of next generation
technology.
In a next generation SOA Enterprise, the IT function will have two distinct
roles:
A tactical role of providing support to the other operating units that
comprise the enterprise. The support it provides will be in terms of providing
IT systems, provision of help desks, user training etc.
A strategic role of ensuring the enterprise meets its strategic business goals,
as well as identification of new technology-enabled business opportunities,
and application of new technology to solving any business issues.
Next generation SOA enterprises are characterized by having:
Mature and aligned business and technical architectures, where business
drives IT, and technology enhances the business. Information and business
models are used to drive IT investment, and IT produces measurable business
benefits and goals through the services it provides.
A large inventory of shared business services i.e. services that provide
important business functionality rather than technical services, such as
printing, communications etc.
A wide range of granularity of deployed services, ranging from basic business
transactions such as ordering supplies, to the automation of some complex
and/or long running business processes.
A well-defined service model of the primary business activities, together with
a roadmap for proposed next generation business solutions prioritized in
terms of:
173

1. The overall business value to the enterprise

2. The cost to implement the solution
3. The potential for reuse of the new services, automated processes
and infrastructure software
4. The budget and capacity of the IT department and its business
partners to provide that solution.
Business models that are driven by services technology, for example
discovery of new potential business partners, obtaining the best deal for
supplies by comparing multiple vendors, and on-boarding new suppliers.
A consumer-provider approach to conducting business between operating
units within the enterprise and between the enterprise and its business
partners, regulated by formal or informal service level agreements between
the two parties involved.
In this chapter, we will show how enterprises can use next generation SOA to
create new business opportunities. We will cover the capabilities of next
generation SOA from a business perspective and then examine various
strategic business models that are enabled or significantly enhanced by next
generation SOA.
How Case Studies Are Used in This Chapter
Pure technology is of little interest to business executives. It is
the application of technology to support strategic business objectives that
can radically improve an organizations ability to compete.
In the case study, we will demonstrate some of the ways that enterprises like
RYLC might apply next generation SOA technology both to solve current
business issues and to generate valuable new strategic business
opportunities. We will show the range of Next Generation SOA derived
business initiatives that RYLC considered, the ones they decided to
implement, and the rationale for their selection.
7.1 Building a Next Generation SOA Infrastructure
Since SOA relies on sharing common infrastructure, entity and utility services
across all IT solutions, migration to it requires significant up-front investment
in IT infrastructure, even though the eventual cost per unit of business logic is
considerably reduced. The difference is shown in figures 7.1 and 7.2 below.
174

Fig. 7.1. Application Silos lead to duplication of resources

Many established enterprises have a silo approach to application

development, where applications manage most or all of their environment and
housekeeping functions. Application 1 above is an example of a silo
application. This was a common architectural style in the early days of the
computer industry.
Improvements in system software technology, such as transaction
management software, such as IBMsInformation Management System
(IMS) or Customer Information Control System (CICS), and common
database management systems such as IBMs DB2 or Oracle Database,
allowed some sharing of common infrastructure, as shown in Application 2
and Application 3 above. Similar architectural approaches using Web
Application Servers are common.
However, sharing of any business logic on mainframes or Application Servers
remained uncommon until the advent of SOA, and many applications
continue to maintain their own security, systems management and
communications. Application-to-application connectivity in such a model is
technically possible, but extremely hard to implement in practice.
This full or partial silo approach has relatively low up-front system software
costs but has high costs for each new application. Applications can be
integrated with each other only an a pair-by-pair basis, making full
application integration prohibitively expensive.
175

Figure 7.2. Next Generation SOA Architecture makes heavy use of

shared infrastructure components and reuses many services

A next generation SOA environment uses common software infrastructure

components to perform housekeeping and common business functions for
most or all IT solutions. As the technology matures, more and more
functionality is provided by a shared infrastructure layer. The initial costs of
providing such IT infrastructure are relatively high, but the cost of adding
additional business functionality is much lower than for a silo approach and
continues to decrease as the level of SOA maturity increases. Some new
applications can eventually be realized just by extending an executable
business process model or by reusing, combining or modifying existing
services. In this model, application to application technology becomes the
norm rather than an exception.
The relatively high upfront cost of infrastructure has historically been an
inhibitor to the growth of SOA, though most large enterprises have now
implemented at least a basic SOA infrastructure. Creating a successful
business case for deployment of next generation SOA is dependent on building
an optimum roadmap of business solutions that it can enable and then
justifying any new infrastructure components on the basis of the business
needs they are needed to satisfy.

176

There are several options for IT deployment of next generation services:

Host locally i.e. run all services on an SOA infrastructure owned and
maintained by the enterprise
Outsource operation of services:
As part of outsourcing IT operations
Using a private cloud computing model i.e. one that runs behind
the enterprises firewall or over a virtual private network to a
specific service provider
Using a public cloud computing model i.e. accessing computing
resources on demand, as a commodity via the Internet.
These options can be hybridized (mixed and matched) in any combination.
For example, a functional or performance test environment could be set up
using virtualization over the cloud.
Making tactical use of Cloud computing and Software as a Service (SaaS) can
significantly reduce the initial entry costs to next generation SOA and is
especially appropriate when the demand on IT resources has wide variations,
such as seasonal peaks.
Example Vendor Approaches to Next Generation SOA
Many software vendors have developed offerings to assist enterprises wishing
to migrate to next generation SOA. Thanks to the growth in usage of common
standards, it is becoming increasingly possible to inter-operate offerings from
multiple vendors.
In this section we will briefly review the approaches taken by some of the
leading software vendors without attempting to compare or contrast them.
Some vendors, such as HP, IBM, Microsoft and Oracle, sell or lease their
infrastructure software through both cloud computing and conventional
customer-hosted channels, as well as marketing it commercially.
Amazon Web Services Elastic Compute Cloud(EC2)- provides a public
cloud environment, running within their own network infrastructure and
datacenters. Ec2 allows customers to increase or decrease IT capacity within
minutes, and customers pay only for what they use.

177

Fujitsus Triole Approachfor Dynamic Enterprises - Fujitsus Triole

is an initiative for building and maintaining dynamic IT capability. It is an
architecture and product strategy intended to support and streamline complex
IT operations and management, including a disciplined and refined process to
create industrialized IT infrastructure. Triole focuses on the optimal
management of IT infrastructures and services through the two core
technologies: virtualization and automation.
HPs Vision of Adaptive Enterprises - In HPs version of an adaptive
enterprise, business and IT are synchronized to capitalize on all kinds of
changes, be they business or technology related. It breaks away from the
inflexible, closed and silo-like systems of the past in favor of development of
open and forward-looking systems that deliver more value and vitality to the
business. The major gains from becoming an adaptive enterprise include such
items as:
Adding partners to supply chain system in hours
Doubling the pace of product introduction without sacrificing quality
attributes
Shifting IT
competencies

investment from

infrastructure maintenance to core

Increasing availability and continuity of business support systems

Enhanced IT consolidation and simplified services management
Dynamic collaboration to maximize productivity through sharing and
optimal utilization of IT resources
HP recently defined a new quality attribute of next-generation enterprises it
termed the Instant-On Enterprise where businesses have the ability to
provide real-time, instinctive, and instantaneous service offerings.
IBMs Smartcloud - IBMs cloud environment candeliver compute options
with virtual IT infrastructure support; a standard level of security for sharing
physical IT resources among many tenants and dedicated computing
environments for an extra level of protection. Enterprise clients can select key
characteristics of a public, private and hybrid cloud to match workload

178

requirements from simple Web infrastructure to complex business processes

along five dimensions, including Security and isolation, Availability and
performance, Technology platforms, Management Support and Deployment,
and Payment and Billing.
Microsofts Windows Azure provides a platform as a service (PaaS)
platform with dynamic and virtually infinite capacity, a service container, and
platform for building composite applications/services, and metering and
event processing.
Oracle On Demand provides software as a service, as well as hosted and
managed alternatives to on-premise deployment supporting both private
clouds and service providers that are building public clouds, providing both
platform as a service and infrastructure as a service.
7.2 Next Generation SOA as a Strategic Business Asset
Much of the business-related literature on SOA deals with how it may be used
as a tactical tool to improve the operational efficiency of an existing enterprise.
From a strategic viewpoint, SOA, and especially next generation SOA, can also
improve an organizations overall flexibility and agility.
The flexibility of an enterprise is a measure of its ability to respond to
external forces, such as changes in legislation, competitive threats and new
business opportunities. Automation of common business processes, providing
an ability to rapidly expand their usage or to modify their behavior, is an
excellent way to improve business flexibility.
The agility of an enterprise is a measure of the speed with which and
enterprise can change its organizational structure or business operations to
respond to market forces or new opportunities. A highly agile enterprise
would be able to rapidly:
Implement new products or projects
Outsource or sell off individual business operating units
Integrate new subsidiaries acquired through mergers and
acquisitions.
The maturity of the inventory of deployed services can have a dramatic
effect on the agility of an enterprise.

179

Next generation SOA not only helps leverage the ability of SOA to support an
enterprises business strategy but can also provide some significant new
business opportunities. In this section, we will examine some new business
strategies that have been enabled by next generation SOA.
New technology paradigms introduced to solve a specific business problem
often turn out to generate new business opportunities in their own right. The
Internet, for example, originally intended to provide resilient military
communications over unreliable networks by using multiple delivery paths,
has completely revolutionized the way that we both shop and work. In this
section we will discuss business opportunities generated next generation SOA
technology.
Properties of Next Generation SOA Technology
SOA technology focuses on improving business efficiency and agility by
deploying IT solutions in the form of services that automate business
processes, activities and tasks.
1. Services are controlled by formal contracts service contracts
define the functionality, inputs and outputs (including any error
conditions) of each service. While the service contract does not contain
any information about how the service is physically implemented, it does
provide all necessary information for an authorized service consumer to
access and execute the service, since the information modelthat defines
the inputs and outputs of each service provides a clear and unambiguous
description of the service inputs and outputs.
2. Services are technology and device independent the service
contract places no constraints on the physical type or technology of either
the requestor or the server, allowing true any-to-any connectivity. Service
requestors can range from simple Web appliances to major IT systems.
Services can be invoked by automated processes, on a timed basis, in
response to business events or by the execution of another service.
3. Services can perform business tasks very quickly and at very
high volumes and therefore allow an enterprise to execute orders of
magnitude more instances of some key business tasks than if they were
performed manually.
4. New service providers can be discovered and integrated into
the enterprises operations easily even though true seamless
180

discoverability requires semantic integration, next generation SOA

technologies allow discovery and reuse of existing services to be much
easier and effective.
5. Complex business processes can be automated even quite
complex business processes can be accomplished with little or no human
intervention. Automated processes can be created to monitor manual
tasks or activities and issue alerts if problems arise or planned activities
are not completed on time.
Business Implications of Next Generation SOA Technology
All enterprises, be they commercial or governmental, operate by providing
goods or services to customers in return for payment or state funding. To be
successful, any organization must establish a relationship of trust with its
customers, based on effective communications and a reputation for good
value.
The meteoric success of enterprises like Amazon.com and eBay show just
how much can be achieved by an early adopter of new technology with a
well-constructed business model.
From a business perspective, the characteristics of the next generation SOA as
listed above offer the following potential:
1. Formal Service Contracts ensure clarity and precision of business
communications, eliminating misunderstandings, confusion or delivery
failures that may occur in less regulated channels such as email,
telephone, or physical mail.
2. Device and technology independence allows the service provider
to use a single channel forany type of requestors. A single service can be
used in multiple business processes, form part of multiple composite
services, and be accessed by requestors using multiple delivery channels.
This dramatically reduces the complexity of implementing new or
enhancing existing business solutions.
3. Having
virtually
instantaneous
replies
to
service
requests allows many enterprises to consider multiple options or vendor
offerings before choosing a supplier or making an offer to a customer.
4. The ability to search for and access new service
providers rapidly allows an enterprise to readily locate and connect
181

with new potential suppliers or be contacted by new customers, on a

global scale.
5. Business Process Automation can radically reduce an
organizations overhead costs, ensure consistency of approach, provide
effective governance, and increase business flexibility.
Inhibitors to Global Trade
While the Internet has certainly been a factor in increasing the globalization of
trade, some inhibitors still remain. The key issues are trust, differences in
commercial law and in enforcement of those laws, and some missing
international standards.
There are issues of trust whenever two organizations do business with
one another. While Web standards help to provide secure communications,
proof of each others identity, and an audit trail of communications, they do
not provide the ability to guarantee that each organization will live up to its
contractual promises or that the quality of goods delivered or services
performed by a supplier will be of appropriate quality. This is especially
problematic when the two organizations operate in different countries.
Differences in commercial laws and their enforcement are a
problem both for enterprises and governments. Problems of trust are
exacerbated if an enterprise cannot be sure that a foreign suppliers
government will take appropriate action if that supplier breaches a business
contract. Governmental bodies, those especially involved in customs and
taxation, want to be sure that they are kept informed of the transfer or goods
or chargeable services into or from their countries. This can be difficult to
achieve if some or all of those transfers are performed electronically.
Few industries have standards that are truly international. For
example, most countries handle business accounting and taxation quite
differently from each other. Some items so familiar that they are taken for
granted in one country might be literally foreign in another country. Simple
attributes may have quite different meanings in two countries. Addresses, for
example, take many different forms around the globe, and while most
countries have a unique social security number or other unique identifier for
each citizen, some, like Japan, do not.
Addressing the Inhibitors to Global Trade
182

In this section, we will look at two approaches that have been taken to address
some of the inhibitors to global trade, Industry Watchdogs and Guarantors.
Industry Watchdogs protect the reputation of a specific industry either by
accrediting companies that have to meet specific standards or by rating them
based on customer feedback. While accreditation or a good reputation is no
guarantee of an organizations performance, it certainly helps to rule out the
less scrupulous traders and generally reduce risks.
Table 7.1 below describes the operating model of Industry Watchdogs.
Table 7.1. The Industry Watchdog Business Model

183

Guarantors use the classical insurance model to provide more active

protection to individual business transactions, ensuring that each party to a
specific single contract lives up to their obligations. This model is described
in Table 7.2 below.
Table 7.2. The Guarantor Business Model

184

7.3 Next Generation SOA-Enabled Business Models

In this section we shall discuss some new business models that have been
wholly or partly enabled through SOA technology.
We have identified seven business models that have been created directly
from next generation SOA technology or that have been significantly
enhanced by new technology to the extent that they represent significant new
opportunities. These are:
The Virtual Enterprise business model where several small to medium
business companies join together in a loose federation in order to compete
with major suppliers

185

 The Software as a Service business model, where business software is

delivered, on demand, typically on a fee per usage basis
The IT Capacity Trader business model, where IT capacity is sold to
customers in a cloud computing environment
The Enhanced Wholesaler business model, where the speed at which SOA
makes it possible to receive bids from suppliers allows a wholesaler to respond
more dynamically to demand, to reduce or eliminate storage costs and
maximize profits
The closely related Price Comparator business model, where a commercial
organization compares the offerings of multiple competing supplier to find the
best possible deal for a potential customer and charges a commission on each
sale rather than being an active participant in the deal
The Content Provider business model, where the owner of an information
asset sells that asset to consumers using a service interface
The Next Generation Job Market business model, where enterprises locate
suitably skilled contractors to perform specific tasks.
The Virtual Enterprise
Virtual enterprises allow multiple enterprises to collaborate to address a
specific business opportunity. They are dynamic partnerships that can form
rapidly and be later disbanded with relatively little impact to its members. As
far as their customers are concerned, virtual enterprises are indistinguishable
from physical enterprises.
Table 7.3. The Virtual Enterprise Business Model

186

187

Software as a Service
Software as a service (SaaS) is a mechanism for selling software on a usage
basis rather than charging a product license. It is especially popular with
organizations whose usage of a specific software product is either low or
highly variable, as it reduces their overall software expenditure.
Table 7.4. The Software as a Service Business Model

188

189

IT Capacity Trader
Cloud computing enables IT capacity to be treated as a commodity, where
parties with spare IT capacity sell it to clients who need extra capacity. IT
capacity traders buy and sell IT capacity.
Table 7.5. The IT Capacity Trader Business Model

190

The Enhanced Wholesaler

Traditional wholesalers buy products from multiple manufacturers and then
sell them to individual retailers. Their business model relies on being a one
stop shop to meet their retailers needs for a range of products and their
ability to reduce unit costs by buying large quantities from individual
manufacturers.

191

An enhanced wholesaler uses the same basic business model but uses SOA to
form more dynamic business relationships.
Table 7.6. The Enhanced Wholesaler Business Model

192

The Price Comparator

Price comparators perform the service of requesting and managing quotes
from multiple competing companies for common commodities such as
insurance, hotel accommodation, or rental cars. They typically charge a
commission fee to the successful vendor.
Table 7.7. The Price Comparator Business Model

193

194

The Content Provider

Content providers create textual, pictorial, audio or multimedia information
or data feeds to be accessed by consumers, including items such as news or
sports feeds, written material or movies.
Table 7.8. The Content Provider Business Model

195

The Next Generation Job Market

In the last few decades, the job market has become much more dynamic. In
the first half of the last century it was common for graduates to have a single
career specialization and even to be employed by the same company their
whole working life. Today new graduates expect to have multiple
specializations, multiple employers and often multiple careers. Increasingly,
more professionals are working as short-term contractors rather than as
long-term employees.
Table 7.9. The Next Generation Job Market Business Model

196

New Business Models - Summary

Next Generation SOA does not create radically new business models, but it
does provide significant opportunities to expand the scope of existing business
models, the range of customers, suppliers and business partners for each
enterprise, and, above all, the overall volume of business and the speed at
which it can be conducted.
Case Study Example

197

At the suggestion of the CIO, RYLC ran a two-day strategic planning

workshop to which they invited key thought leaders from both IT and the
business operating units. The invitees included representative executives,
managers, senior professionals, architects and business analysts. The
purpose of this workshop as to identify innovative ways that RYLC
operations and profitability could be improved by:
Recognizing and responding to business risks and opportunities
Improving business performance, for example by renting more cars
Reducing the cost of running the business, for example by improving
productivity
Day 1 focused on identifying the business challenges, risks and
opportunities.
The Marketing manager kicked off the workshop with an overview of the car
rental marketplace and the current RYLC strategic business plan..
The workshop continued with a series of presentations from business and
IT executives, managers and professionals, describing how their individual
business units operate, and what were their main dependencies, issues,
opportunities and inhibitors. Special attention was given to the principal
business priorities identified in the RYLC business heat map described
in Chapter 3.
At the end of the first day, the workshop attendees reviewed the set of issues,
opportunities and inhibitors, first rating their importance as extreme, high,
medium or low, and then ranking them in terms of overall impact.
Following a day that focused on problems, day 2 was dedicated to solutions.
The CIO began with a description of the strategic RYLC IT roadmap and an
overview of the capabilities of next generation technology, such as
automated business process models and cloud computing.
The workshop was then split up into a series of focus groups, consisting
typically of three to four members, each of which addressed a significant
issue, problem or opportunity. Each focus group contained a mix of
business professionals and analysts who were experts on the associated
subject, and experienced IT professionals such as architects.

198

The subjects of each focus group were selected to include a spread across
issues, opportunities and inhibitors. Each focus group looked for innovative
solutions to address their subject item, either by improving the underlying
business processes or by applying technology.
Individuals could move freely between focus group sessions, and each focus
group worked on multiple items. Some of the most serious issues were
worked on by more than one focus group. Some focus groups worked on the
key strategic areas identified in the RYLC heat map shown inFigure
3.6 earlier in this book.
The focus groups identified three issues and two potential opportunities:
Issues
1. Vehicle maintenance problems are impacting customer satisfaction
2. The aging billing system represents an unacceptable business risk
3. The complexity of RYLCs IT systems is an inhibitor to their strategy of
growth through mergers and acquisitions
Opportunities
1. Vehicle rental volumes could be increased by partnering with other
travel firms and making deals with travel comparison websites
2. IT running costs could potentially be reduced by using a cloud
computing model
The findings of the
7.10 through 7.14 below:

focus

groups

are

summarized

in tables

Table 7.10. RYLCs vehicle maintenance issue

199

200

Table 7.11. RYLCs billing system issue

201

Table 7.12. RYLCs Mergers and Acquisitions issue

202

Table 7.13. RYLCs new business partnerships opportunity

203

Table 7.14. RYLCs cloud computing capacity opportunity

204

Summary of Key Points

Next generation SOA technology offers some new models for provision of
computing resources within an enterprise, such as using on-demand cloud
computing for some IT systems rather than running them in-house.
Next Generation SOA technology has created some major new business
opportunities, typically through increasing an organizations ability to
communicate with multiple suppliers very rapidly.
Even though SOA is a relatively new approach, some early bird enterprises
have already made large fortunes exploiting the business opportunities
created by SOA. The next generation SOA offers significant additional
business opportunities.
While global trade is becoming increasingly globalized, some inhibitors still
remain, such as establishing trust between foreign organizations or sharing
common industry models across multiple countries. Solving these inhibitors
would significantly enhance global trade.

205

8. Next Generation SOA Governance Considerations

Many books and articles have been written about SOA governance. This is not
one of them. In fact, the entire SOA Governance book, part of Thomas Erl SOA
Computing Series, is dedicated to exactly this topic. Therefore, the treatment
of SOA Governance here will be at a very high level.
In this chapter, we will introduce some of the key SOA Governance concepts
but will not cover them in detail. Instead, once all the concepts are outlined,
we will concentrate on the new and emerging trends in SOA Governance and
its close alignment with IT Governance. We will examine how evolution in the
SOA space, from the technology and practices perspective, has affected SOA
Governance and what new approaches have been introduced as a result.
How Case Studies Are Used in this Chapter
Case studies in this chapter will describe what measures the Rent Your
Legacy Car (RYLC) company has taken to implement SOA governance
across the organization. Since RYLC embarked on a significant SOA
transformation, it was able to adopt a number of SOA technology solutions
and approaches, which evolved to meet competitive pressures. In order to
stay competitive and properly manage its SOA delivery lifecycle, RYLC
decided to implement a comprehensive SOA governance program. Case
studies in this chapter examine what was implemented, how it was achieved,
and how all of the existing processes and technologies were aligned with it.
8.1 SOA Planning Fundamentals
Governance, as with any other aspect of SOA adoption, begins with a planning
stage. This stage has a set of fundamental critical success factors, also known
as pillars. They include:
Teamwork Cross-project teams and cooperation are required.
Education Team members must communicate and cooperate based on
common knowledge and understanding.
Discipline Team members must apply their common knowledge
consistently.

206

 Balanced Scope The extent to which the required levels of Teamwork,

Education, and Discipline need to be realized is represented by a meaningful
yet manageable scope.
Each organization may transition through one or more of the following
common evolutionary levels:
Service Neutral awareness of SOA and service-orientation exists within
the organization, but no meaningful extent of teamwork, education, or
discipline has been established or yet identified.
Service Aware the four pillars have been established, relevant business
requirements and goals are defined, and the overall necessary organizational
foundation for the SOA initiative is in place.
Service Capable the organization has achieved the ability to deliver and
govern services and service compositions in response to business automation
requirements.
Business Aligned the organization has achieved meaningful alignment of
technology resources and current business automation requirements.
Business Driven service-encapsulated technology resources are not just
aligned with the current state of the business but have proven to remain in
alignment with how business requirements continue to change.
Additional levels exist when organizations proceed with SOA initiatives in the
absence of some or all of the previously described four pillars:
Service Ineffectual an organization has descended into a technological
backwater where the IT enterprise delivers services as silo-based or bottom-up
automation solutions under the pretense that it is adopting SOA.
Service Aggressive ITs enthusiasm for SOA and service technology has led
to a proliferation of services that the business doesnt want or need.
Figure 8.1 displays how an organization will commonly transition through
these maturity levels.
Figure 8.1. Common evolutionary levels of organizational maturity.

207

In order to properly plan the SOA delivery lifecycle, funding issues must be
addressed upfront. There are two fundamental levels of SOA funding:
Platform Funding This level provides funds for the delivery of collections
or inventories of services. Platform funding models are therefore generally
focused on establishing the supporting infrastructure for a given service
inventory. This funding model contains several distinct approaches.
Project Funding Model This model identifies appropriate
projects to acquire or to extend new or existing SOA platforms.
Central Funding Model With this model, the funding of the
platform is provided centrally.
Usage Funding Model The initial platform is funded centrally
but usage fees are charged for ongoing maintenance and support.
Service Funding This level provides funds for the delivery of individual
services. These services rely on an already-funded service inventory platform.
This funding model contains several distinct approaches.
Project Funding Model Individual projects build new or extend
existing reusable services.
Central Funding Model The funding of reusable services is
provided centrally.
Usage Funding Model The initial delivery of reusable services is
funded centrally but usage fees are subsequently charged.
208

 Hybrid Funding Model A combination of project and central

funding.
Once all the planning activities are complete, the implementation of the SOA
governance program can begin.
Summary of Key Points
SOA governance critical success factors should be established as part of the
planning process
The organization type should be understood to establish the right adoption
approach
A funding model should be established early in the process
8.2 SOA Project Fundamentals
There are several common and primary stages (or phases) related to SOA
projects and the overall service lifecycle. They include:
SOA Adoption Planning
Service Inventory Analysis
Service-Oriented Analysis (Service Modeling)
Service-Oriented Design (Service Contract)
Service Logic Design
Service Development
Service Testing
Service Deployment and Maintenance
Service Usage and Monitoring
Service Discovery
Service Versioning and Retirement

209

Each phase is defined and described in more detail in other books from the
SOA Computing series. The stages describe a state of a service or the entire
governance program. Each one contains specific goals and deliverables that
must be accomplished before the service or program can move forward.
To realize these goals, a distinct set of project roles and responsibilities should
exist, including those of:
Service Analyst
Service Architect
Service Developer
Service Custodian
Cloud Service Owner
Service Administrator
Cloud Resource Administrator
Schema Custodian
Policy Custodian
Service Registry Custodian
Technical Communications Specialist
Enterprise Architect
Enterprise Design Standards Custodian (and Auditor)
SOA Quality Assurance Specialist
SOA Governance Specialist
SOA Security Specialist
These are commonly used roles but variations or different combinations can
also exist. Multiple roles may be fulfilled by a single individual and vice versa.

210

Each role has specific deliverables and plays a particular set of functions in
each phase in the SOA project lifecycle.
Summary of Key Points
Each SOA project progresses through a variety of stages
A number of roles are necessary to effectively implement SOA governance
8.3 SOA Governance Fundamentals
The primary business goal of SOA governance is to ensure that an SOA
initiative achieves its targeted business outcome. This is achieved by
establishing an SOA governance system, which acts as a meta-decision system
that an organization puts in place to control and constrain decision-making
responsibilities related to the adoption and application of service-orientation.
The foundation of an SOA governance system resides within an SOA
Governance Program Office (SPGO) responsible for creating and
administering an SOA governance program.
There are several ways in which the SPGO may be established in an
organization.
Centralized Enterprise SGPO a single governance body that oversees SOA
governance on behalf of the entire IT enterprise.
Centralized Domain SGPO a single governance body that subjects all
domain service inventories on to a common SOA governance system.
Federated Domain SGPOs in this model, a central overarching SGPO
exists in addition to individual SGPOs, each responsible for a separate domain
service inventory.
Independent Domain SGPOs in absence of a central overarching SGPO,
each domain service inventory has its own SGPO, which has full governance
authority and jurisdiction over that domain.
The SGPO exists to create and maintain an SOA governance program. The
task of realizing it can be divided into three basic steps:
1. Assessing the Enterprise (or Domain), which is focused on:

211

 Current Governance Practices and Management Styles

SOA Initiative Maturity
Current Organizational Model
Current and Planned Balance of On-Premise and Cloud-based IT
Resources
2. Planning and Building the SOA Governance Program primary
elements include:
SOA Governance Precepts (i.e. rules, policies and standards)
SOA Governance Processes
SOA Governance Roles
SOA Governance Tools
SOA Governance Roadmap
3. Running the SOA Governance Program that includes the following
steps:
Collect the right metrics and have the right people use them
Provide transparency and foster collaboration
Ensure consistency and reliability
Ensure compliance and establish incentives
Provide education and communication
These elements establish a solid foundation for a successful SOA governance
program.
Summary of Key Points
The SOA Governance Program Office should be established to administer the
SOA governance program
The SGPO can be organized in a variety of ways
8.4 Governing SOA Projects
As discussed earlier, SOA projects typically go through a number of stages.
The SOA Governance Program Office establishes entry and exit criteria for
each stage. An effective approach to achieving this is to ensure that the quality
and completeness of outputs from each individual lifecycle stage are reviewed
and approved before proceeding to the next stage. To achieve this, a number
212

of review processes based on criteria established by related precepts are

established.
Each SOA project stage comes with a distinct set of precepts, processes, and
roles associated with it. There are some that are common across most, if not
all the stages.
Precepts
Service Profile Standards services within a given service
inventory need to be consistently documented
Service Information Precepts service information primarily
represents business-centric data to which clear meaning and context
has been assigned
Service Policy Precepts information describing operational
elements of a service
Logical Domain Precepts rules and guidelines for services based
on different types of service models
Security Control Precepts services unique security requirements
and concerns
SOA Governance Technology Standards SOA governance
technology products are standardized for the regulation of services
within a service inventory boundary
Metrics
Cost Metrics metrics describing costs associated with SOA
investments and ongoing work
Standards-related Precept Metrics metrics derived from the
results of corresponding review processes
Threshold Metrics hard limitations on the design-time or
runtime usage or management of a service
Vitality Metrics measure of a services on-going behavior
We will not discuss detailed governance mechanisms applied in each SOA
project phase, as this is covered in great detail in a separate book.
Summary of Key Points

213

 SOA governance projects are governed through a variety of precepts and

processes
8.5 Service Information and Policy Governance
Service information governance is the practice of identifying and evolving
governance controls that ensure the provision of timely and accurate
information. There is a distinct difference between data, information, and
knowledge. SOA governance can help ensure that services provide clear
understating of data and its meaning and that service consumers can trust this
information without requiring knowledge of its origins.
Policies represent information related to services non-functional
requirements, security, and other limitations. They can be described in human
or computer readable formats. Many service management platforms can
interpret and enforce such policies at runtime.
A number of precepts are required to position and regulate service
information and policy content.
Enterprise Business Dictionary/Domain Business Dictionary an official
reference for definitions of information terms and concepts that are core to
the organizations business. There may be an Enterprise Business Dictionary
and a Domain Business Dictionary established.
Service Metadata Standards data about a service focused on establishing
its functional meaning and context. This typically includes technology,
functional, programming logic, and quality of service information.
Enterprise Ontology/Domain Ontology the information at the basis of
ontology that originates from or relates to information in the business
dictionary as well as service metadata. Typical concern is with ensuring that
the ontology is current and in alignment with business dictionary and service
metadata content.
Business Policy Standards a set of standards related to how business is
conducted. The expectation is that any policy (human or machine-readable)
used within a given service inventory be standardized in terms of technology,
tooling, and vocabulary.

214

 Operational Policy Standards rules and guidelines that establish

constraints and requirements for how services operate and interoperate at
runtime. Policies that are in use are expected to be standardized within the
service inventory boundary.
Policy Centralization policy definition needs to be centralized when it
needs to be shared by multiple service contracts.
There is a number of governance processes that support the application of the
precepts described above. They provide controls for maintaining the quality
and alignment of service information and related policies.
Data Quality Review ensures data correctness.
Communications Quality Review addresses the communications quality of
data.
Information Alignment Audit ensures that the meaning is kept consistent
throughout the scope in which content is utilized.
Policy Conflict Audit resolves policy domain overlaps.
To attain the most effective service-oriented platform, an organization should
attempt to establish a comprehensive set of enterprise business models. To
achieve this, the following steps should be undertaken.
Establish a Service Information Governance Council chartered with
providing governance over information standards and is comprised of
members or department representatives from all affected lines of business.
Assign Business Information Custodians
maintenance of business dictionary and ontology.

support

creation

and

Assign Value to Business Information assign individual terms and

business entities a value ranking indicating its relative importance to the
organization.
Relate Service Information Governance to Master Data Management
ensure that if MDM is in use within an IT enterprise that is adopting SOA, it
should be related to and incorporated with service information and policy
governance precepts and processes.
215

Once all the precepts, processes, and governance mechanisms are established,
service information and policies can be effectively governed across the entire
SOA project lifecycle.
Summary of Key Points
Service policies and information are governed through a variety of precepts
and processes
8.6 SOA Governance Vitality
Once deployed and in use, services and supporting technologies become living
assets. The SOA governance program must therefore provide a means by
which these assets are routinely reviewed, kept current and accurate and,
most importantly, relevant to business needs. To address this evolutionary
aspect, the SOA governance program needs to make the notion of vitality part
of the SOA governance system being employed.
To accomplish this, the SOA program must implement a series of vitality
triggers as a mechanism of notification and reaction. They represent
pre-determined events and conditions that execute pre-determined activities
as part of a vitality process. There are five common types of vitality triggers:
Strategic Adjustments changes to the organizations business direction or
vision; IT changes pertaining to technology and resources.
Industry Shifts changes in business law, governmental policy, or even
economic or political factors; technology shifts that occur within proprietary
vendor platforms and product lines, as well as industry technology standards
communities.
Metrics metrics related to performance of various parts of an SOA
ecosystem; metrics exposing lack of compliance with industry or IT
regulations.
Organizational Shifts organizational events that affect the IT enterprise,
deliberately or inadvertently.
Periodic pre-defined vitality activities that are carried out at scheduled
intervals; review of assets using a pre-defined timescale.

216

A set of processes should exist to ensure SOA asset vitality is being addressed.
They are comprised of a series of activities that are carried out in response to
certain vitality concerns or requirements. They ensure execution of different
vitality activities, which include:
Identify Activity centers on capturing relevant information surrounding
the trigger and the circumstances of its execution.
Assess Activity encompasses tasks that focus on determining the effect of
carrying out a refresh, prior to moving on to the actual Refresh activity.
Refresh Activity governs the actual actions performed in response to the
previously identified vitality concern.
Approve Activity SOA Program Governance Office review that can result
in the acceptance or rejection of the refresh plan.
Communicate Activity the communication of the planned refresh to the
affected stakeholders, project teams, and others involved with the targeted
asset.
Together, the vitality triggers and activities that are kicked off in response
ensure that the SOA program remains current and viable. SOA program
vitality is the final element that underlines and supports all the previously
defined SOA governance mechanisms.
Summary of Key Points
SOA governance program must implement a series of vitality triggers to
determine qualifying events
In response to a trigger, a series of activities can be executed
8.7 Next Generation SOA Governance
As discussed in previous chapters, evolution of the service-oriented computing
introduced a number of new technology elements, practices, and patterns.
These had direct impact on the state of SOA governance. It had to adapt to the
rapidly changing service-oriented computing space. As a result, new SOA
governance practices and mechanisms had to be introduced.

217

The extensions to the existing SOA governance attributes are rooted in the
foundation described throughout this chapter. Instead of establishing
radically new approaches, they aim to coexist with and extend current SOA
governance program implementations. However, the shifts in the
service-oriented computing space necessitated expansion of the SOA
governance domain and scope.
Each next generation architecture element creates a need for related set of
governance mechanisms and practices. The subsequent sections discuss
specific precepts and processes that are introduced in each stage of an SOA
project.
Business Process Management
BPM has a profound impact on SOA. When applied correctly, it can
significantly enhance the value SOA already offers. Therefore, SOA
governance mechanisms should concentrate on maximizing the alignment
between the two disciplines but do so intelligently and for the right reasons.
Table 9.1 discusses how this can be accomplished in each SOA project stage.

218

219

SOA governance mechanisms related to Business Process Management.

220

The BPM approaches, tools, and technologies offer significant synergies with
SOA and its established precepts and processes. While this close relationship
should be exploited to its full potential, it will undoubtedly become even
stronger, as the technology evolves and maturity increases on both sides.
Business Rules Engines
Business Rules Engines bring a new dimension to service-orientation. They
provide capability to externalize business rules that services need to execute as
part of their logic. The rules may be maintained by external parties outside of
the organization that owns and manages the service. The changes to the rules
implemented through a rules engine need to be synchronized with the service
interface and other business logic the service may execute. The service itself
may be reduced to just a call to a rules engine.
The variety of rule engine technologies that exists today demands a careful set
of guidelines to be crafted in order to determine which platform is the most
appropriate to use in which situation. SOA governance mechanisms need to be
put in place to help guide rule service design and development in the most
effective way. Table 9.2 specifies which existing precepts and processes need
to be expanded to accommodate Business Rule Engine technology and
whether new ones need to established or not.

221

SOA governance mechanisms related to Business Rules Engines.

222

The business rule engine technology is becoming more pervasive and

lightweight. The evolutionary path of this platform points to significant
synergies with ESB and BPM technologies. The precepts and processes
outlined above may not be necessary in the future if rule engines become fully
integrated into the rest of SOA platform.
Event Driven Architecture
Event Driven Architecture represents a shift from typical service-oriented
approaches. In its simplistic form, it can be viewed as asynchronous SOA. In
its most complex representation, other technologies such as ESB, BPM,
business rules engines, and complex event processing platforms may be part
of the whole picture.
Event driven services and their consumers need to be governed from a
somewhat different perspective than their typical counterparts. Specific
provisions related to the complex and asynchronous nature of EDA should be
added to the SOA governance mechanisms. Table 9.3 discusses them in detail.

223

224

SOA governance mechanisms related to Event Driven Architecture.

As everything else, Event Driven Architecture continues to evolve. ESBs are
starting to provide support for events and complex event processing. Vendors
are introducing event processing platforms. Registries are building in support
225

for events and their subscribers as well as event registration and discovery.
Eventually, differentiation between EDA and SOA will cease to exist. Until
then, specific EDA inspired governance mechanisms are still necessary.
Cloud Computing
Cloud Computing governance concepts are covered in the SOA Governance
book, part of Thomas Erl SOA Computing Series. It is important to mention,
however, that this space continues to evolve. Progress is being made every day.
Cloud and distributed computing paradigm continues to mature. Even though
it largely remains in the hype stage, it quickly approaches the Plateau of
Productivity. Once there, existing governance mechanisms will need to be
reevaluated and adjusted to accommodate new trends, technologies, and
practices.
Business Architecture
Business architecture is the next battleground for SOA. On its path towards
full maturity, service-orientation has to become a part of business strategy and
should be supported by the specific guidelines and strategies outlined in the
business architecture vision. Without the full support and acceptance by the
business and executive leadership, SOA will remain a purely technology
initiative. This will reduce its value and bring limited benefits.
To avoid this issue, governance of SOA strategies and key decisions should be
executed as a partnership between business and IT. This can be accomplished
by expanding the role of the Executive Review Board (ERB) to align the SOA
program with both business and IT strategy. The SOA Governance Program
Office (SGPO) described above should be closely connected with this new
entity to ensure continuity of the business architecture strategy with the rest
of the SOA program. Figure 8.2 depicts how this relationship works.
Figure 8.2. Executive Review Board and SGPO should be closely
connected.

226

The Business Architecture governance body is typically comprised of business

and IT executives. Ideally, an Enterprise Architecture or SOA governance
function should be represented on the committee.
Similar executive steering committees may already exist in the organization. If
that is the case, the business architecture governance function can be
undertaken by one of them. Alternatively, the SGPO can add this function to
its charter but representatives from the business community should be added
in order to align SOA and business strategies.
Case Study Example
Once RYLC established its SOA program, the chief architect realized that it
lacked structured governance. A number of services were created and
continued to evolve with little oversight. The developers and architects
working on SOA projects complained that there was little guidance available
to them and they lacked proper documentation. The funding for services
being constructed was also unclear. Many projects complained that they
were unfairly taxed by being the first ones implementing services slated to
be reused by others later. Project managers were unclear on what
methodologies needed to be followed to create a service, what deliverables
were necessary, and how changes to existing services had to be introduced
and implemented.
In response to these concerns, the chief architect decided to institute an
SOA Governance program. He presented the case to the CIO to attain initial
funding and begin planning the SOA Governance program. As part of the
need for SOA Governance, he described RYLC as a Service

227

Aggressive organization and outlined the risks associated with this type of
approach to SOA.
At the outset, a central SOA Governance Program Office (SPGO) was
established, as shown inFigure 8.3.
Figure 8.3. RYLC established a central SGPO responsible for its
enterprise service inventory.

The SGPO was chartered with establishing all the SOA governance precepts
and processes, setting up a standard funding model, and continually
revitalizing the program. The CIO decided to let the chief architect chair the
SGPO and include representatives from each IT department as well as the
enterprise architects responsible for various domains including data,
security, infrastructure, and common assets.
The SGPO decided to establish a central platform funding approach to help
RYLC better manage its SOA platform investment and demand. It also
recommended establishing a hybrid funding model for service delivery work.
The SGPO felt that a combination of these models would provide the best
platform for RYLC to streamline its SOA program.
228

Next, SGPO tackled the SOA project lifecycle. It defined a comprehensive

set of precepts and processes along with the corresponding roles for each
stage in the lifecycle. Additionally, a set of operational metrics were defined
to measure how well each precept and process was performing.
To alleviate the issue of service discoverability and lack of centralized
documentation storage, SGPO recommended adopting one of the existing
Registry and Repository tools. A separate team was chartered with
exploring the existing product landscape and making a recommendation. It
developed a comprehensive roadmap describing what the SOA Governance
automation goal state looked like and what capabilities had to be present.
Based on this roadmap, the team evaluated a number of commercial and
open source products. The final recommendation was to purchase a
Registry / Repository platform from the same vendor that supplied the
companys ESB in order to leverage synergies and built-in integrations
between the two products. However, the proposed implementation
approach took a number of deliberate steps prior to fully implementing all
the features and introducing an end-to-end SOA Governance automation.
These steps included:
1. Building out Registry / Repository infrastructure and installing
software
2. Establishing a metadata model that fully describes all service
metadata
3. Registering all existing services
4. Allowing other groups to start registering their own services and
request access to existing services
5. Fully integrating Registry / Repository with ESB
6. Automating all established processes throughout each SOA project
lifecycle stage
Since RYLC wanted to leverage SOA as a strategic tool to gain competitive
advantage and become more agile, the CIO proposed to extend the SOA
Governance to the business. He proposed that an executive steering
committee responsible for aligning business and IT goals be created. RYLC
CEO, who was already impressed with the results achieved through the SOA
program, concurred and sanctioned establishing this new body. The new IT
Steering Committee included the CIO, chief architect, and all business
division heads, COO, and CFO. The CEO specifically chartered the group to

229

work closely with the SGPO in aligning business strategies with SOA and
measuring results.
Summary of Key Points
Existing SOA governance precepts and processes need to be extended in
response to technology and architecture evolution
Business Architecture should be closely aligned with SOA and SOA
governance

230

SOA Industry Standards

1. Executive Summary
This chapter is intended to serve as a guide to help readers differentiate and
select appropriate SOA standards based on their specific needs. The
specifications introduced and positioned here include:
o
o

o
o
o

The OASIS Reference Architecture for SOA Foundation

The OMG Service Oriented Architecture Modeling Language (SoaML)
Specification
The Open Group SOA Ontology
The Open Group SOA Governance Framework
The Open Group Service Integration Maturity Model (OSIMM)

These specifications are discussed in detail and contrasted with each other.
2. What are Architectural Standards?
System architecture is a formal description of a system, or a detailed plan of
the system at component level to guide its implementation. Architecture
represents the structure of components, their interrelationships, and the
principles and guidelines governing their design and evolution over time. It
also ensures a common understanding of what exists now or will be built in
the future. Architecture helps us compose complex solutions from simpler
building blocks. Architectural standards [1] are needed to address customer
architecture and deployment considerations. They are directed towards IT
architects and oriented towards consistency rather than interoperability.
Infrastructure standards are normative, product-driven, conformance-centric
and interoperability-focused.
Figure 1. The landscape of architecture standards

231

The types of Architectural Standards [1] are depicted in the diagram below.
Figure 2. Different types of architecture standards span from
abstract to concrete

The SOA standards described throughout this document can also range from
abstract to concrete. It is important to understand in which category an

232

architecture standard falls, so that it can be applied in the more effective

manner.
3. Industry Standards for SOA
Standardization is an important activity for any new paradigm to be widely
accepted. This section describes the types of standards that exist today,
organizations that maintain them, and typical building blocks of each
standard.
Audiences for SOA Standards
A number of different groups will benefit from applying or understanding
SOA standards.
o

Architects will find them useful as a starting point for customizing

their own reference and concrete architectures.
Developers/Practitioners will find them essential as a basis for
their development of service-oriented solutions.
Consumers / Adopters will find them useful for education purposes
they will not only be able to understand the common SOA terminology
but will also know what to from expect vendors and consultants.
Vendors (including suppliers of hardware and software, solution
providers, and service providers) will find them useful to provide a
consistent, standardized context in which to position and differentiate
their specific products and services. Standards also provide a shared
understanding between different types of vendors and customers.
Analysts will find them useful to help explain the relationships
between specifications, standards organizations, and vendor products
and services offerings.

As SOA continues to evolve and become more widely adopted, other groups,
such as business stakeholders, business and IT executives, QA practitioners,
and many others will become more interested and influenced by the SOA
standards.
The Active Standards Organizations in the SOA Space
Considering increasing significance of SOA in providing and performing
better business results, offerings and operations, several existing standards
bodies have begun drafting industry-strength, open specifications for various
critical contributors to SOA success. Consortiums of IT leaders and open
233

source communities have been working together to sustain and support the
deeper penetration of SOA into different industry segments. Government
agencies have also been contributing to the SOA standards and adoption.
There are three principal bodies responsible for setting SOA-related standards
the Open Group, OASIS and OMG, each of which represents a not-for-profit
vendor- and technology-neutral consortium. These three bodies are highly
collaborative and have many members in common.
The Open Group
The Open Group is a vendor- and technology-neutral consortium with over
300 member organizations from all over the world, ranging from major
corporations, government organizations and consortia to universities and
individuals, including most of the heavy hitters in SOA technology. The Open
Group platinum members (currently Capgemini, Hewlett-Packard, IBM,
Oracle, SAP and Shenzen Kingdee Middleware) represent heavy hitter
vendors in the SOA space who are committed to multi-vendor integration
through creation of products that are compliant to open standards,
certification and branding.
The Open Group has a series of forums responsible for setting standards in
areas such as architecture, security, real time and embedded systems and
enterprise systems management. The Open Groups SOA Working Group is
dedicated to creating and maintaining a wide range of SOA standards,
reference architectures, best practices and models like the Open Group Service
Integration Maturity Model (OSIMM), and The Open Group Architectural
Framework (TOGAF). This includes a database of industry standards, a
proven method for developing an organization-specific standards-based
architecture based on their specific business requirements, together with a
compendium of tools, working examples and case studies.
OASIS
The Organization for the Advancement of Structured Information Standards is
another not-for-profit consortium that drives the development, convergence
and adoption of open standards for cloud computing, SOA, Web services, the
Smart Grid, electronic publishing, emergency management, and other
technologies and architectural approaches. OASIS has some 5,000

234

participants representing over 600 organizations and individual members in

100 countries.
The OASIS SOA Reference Model Technical Committee is responsible
for developing a common SOA reference model (RM) and SOA architecture
(RA). The reference model defines a set of SOA-related entities and
relationships, intended to provide a common understanding and language for
SOA concepts, while the associated reference architecture comprises of
Business via Service view which lays the foundation for
conducting business in the context of Service Oriented Architecture
o Realizing Services view which addresses the requirements for
constructing a Service Oriented Architecture
o Owning Service Oriented Architecture view which focuses on
the governance and management of SOA-based systems.
o

OASIS has several member sections that focus on specific technical areas
including:
The Open Composite Services Architecture (CSA) Member
Section advances open standards intended to simplify SOA
application development
o The Semantic Execution Environment (SEE) Technical
Committee proposes a semantic Web Services platform to address
the problems of interoperability between data and behavior across
diverse organizations
o The SOA for Telecom Technical Committee (SOA-TEL TC)
plans to identify gaps in standards coverage for using Service
Oriented Architecture (SOA) techniques in a telecom environment
o The SOA
End-to-End Resource Planning Technical
Committee (SOA EERRP TC) focuses on the supply chain, with
particular reference to business quality of service, SLA management
and supplier credentials.
o

OMG
The Object Management Group membership includes hundreds of
organizations, with half being software end-users in over two dozen vertical
markets, and the other half representing virtually every large organization in
the computer industry and many smaller ones. OMG is responsible for the
Unified Modeling Language (UML) and Model Driven Architecture
235

(MDA) that enable powerful visual design, execution and maintenance of

software and other processes, as well as middleware standards and profiles
based on the Common Object Request Broker Architecture (CORBA).
Various OMG Task Forces develop enterprise integration standards for a wide
range of technologies, including Real-time, Embedded and Specialized
Systems, Analysis & Design, Architecture-Driven Modernization and
Middleware. These task forces cover an even wider range of industries such as
Business Modeling and Integration, C4I, Finance, Government, Healthcare,
Legal Compliance, Life Sciences Research, Manufacturing Technology,
Robotics, Software-Based Communications and Space.
OMG Task Forces include:
The Analysis and Design Task Force(ADTF) maintains
the Ontology Definition Metamodel (ODM) and the SOA
Modeling Language (SOAML) models. It is currently working on
the Information Management Metamodel (IMM) and issuing
requests for proposal for standards on SOA Governance (SOA
GOV RFP), Event Metamodel and Profile (EMP RFP)
and Agent Metamodel (AMP RFP).
o Business Modeling and Integration Task Force (BMI) has
a mission to develop models to support enterprise management,
inter-and intra- enterprise integration and collaboration of people,
systems, processes, and information. This task force has published
a Business Process Modeling Notation (BPMN) and
a Business Motivation Model(BMM).
o The Consultation, Command, Control, Communications,
and Intelligence (C4i) task force is focused on systems that
support crisis response, Search and Rescue (SAR), and military
operations such as surveillance and reconnaissance together with
sustainment disciplines such as logistics, weather and air traffic
control. This task force has delivered a Unified Profile for Defense
Architectures (UPDM).
o

Figure 3 below shows these working groups and their deliverables.

Figure 3. Standards bodies, their working groups and deliverables

236

While the potential benefits of SOA are clear, the standards picture still looks
less so. Forrester Research has counted around 115 standards floating around
in the SOA space in its most recent study on that topic. It also has found that
just confirming which vendors support which standards is virtually impossible,
mainly because of missing compliance tests. Since many of these standards
are not yet fully mature, the main challenge is to find an architectural
framework to help maintain integrity and integration while standards
continue to evolve.
Technical experts and architects have to navigate their adoption of standards
carefully until they mature and become widely accepted. Standards such as
SOAP and WSDL have already been well-adopted and others like WS-Security
are being increasingly accepted. Popular standards include SOAP, WSDL,
WS-I Basic Profile, UDDI, WS-Security, WS-BPEL, BPMN, WSRP, XML
Schema, XSLT, XPath, XQuery, XML Signature and XML Encryption.
There are many new terms emerging in the SOA space due to the arrival of
different players including IT service and solution organizations, consulting
companies, standards consortiums, academic institutions, governments,
customers, etc. This rapid expansion creates an urgent need for universal sets

237

of standards and terminologies if the goal of interoperability in the SOA

ecosystem is to be achieved.
Artifacts Used to Create SOA Standards
The set of artifacts that are used to document SOA standards includes:
Reference Models The OASIS Reference Model for SOA defines a
reference model as an abstract framework for understanding significant
relationships among the entities in any environment. It enables the
development of specific reference or concrete architectures using consistent
standards or specifications supporting that environment. A reference model
consists of a minimal set of unifying concepts, axioms, and relationships
within a particular problem domain and is independent of specific standards,
technologies, implementations, or other concrete details.
Reference Architectures Reference architectures, like other
architectures, can be defined at different levels of abstraction ranging from
foundation architectures to common systems architectures and
industry-specific architectures. The OASIS Reference Architecture (RA) for
SOA Foundation defines reference architecture as an architecture that models
the abstract architectural elements in the domain independent of the
technologies, protocols, and products that are used to implement the domain.
The Open Group SOA Reference Architecture defines reference architecture as
providing a template based on the generalization of a set of past successful
solutions. These solutions have been generalized and structured for the
depiction of both a logical and physical architecture based on the harvesting of
a set of patterns that describe observations in a number of successful
implementations. Further, it shows how to stitch these architectures together
into a solution. This is closer to the TOGAF Common Systems Architectures.
These RAs will be evolved and instantiated as an industry architecture or
organization-specific architecture for a particular domain of interest or for
specific projects. They are useful to guide the work of the solution team,
including constraining choices in developing flexible and effective solutions.
Ontology The concept of ontology has become critical for the vision of
semantic web. Typically, ontology is defined as an explicit and formal
specification of specific domain terms and relationships between them.
Ontologies are useful to ensure that all the terms and relationships are
precisely defined in a standard and coherent manner across teams. Ontologies
238

formally describe the elements of and provide a formal language for both
reference models and reference architectures. The formal representation
comes handy when evaluating consistency across domains and applying
reasoning to solve business problems using domain elements. The ontology
representation may also be used to support model interchange and
extensibility.
Maturity Models Maturity models are becoming increasingly common.
They help enterprises assess how far they have progressed along their
adoption roadmap, which in turn helps them define the most appropriate set
of goals, standards tools, techniques and training that will help them progress
to the next step in the program.
Modeling Languages With rising IT complexity, modeling has become an
indispensable process to represent a variety of things. Increasingly, majority
of the software and services development lifecycle consists of a progressive
top-down set of models, followed by a final stage when functional code is
generated rather than coded by hand. To achieve interoperability, formal
modeling languages are needed to define modeling notations, icons, terms,
interactions, states, transitions, messages and events. A typical modeling
language includes a metamodel and a set of notations that provide a standard
means of unambiguously representing artifacts in tools and communicating
information between tools and automated environments.
The Unified Modeling Language (UML) from the OMG is the most popular
tool for object-oriented software modeling. UML supports extensions via
stereotypes and profiles for specific needs. Besides UML, there are
domain-specific modeling languages targeting special domains such as
aeronautics, avionics, automotive electronics, etc. With services emerging as a
powerful building block for enterprise systems, a need for a distinct modeling
language to model services and service oriented systems is becoming more
prevalent. SoaML is the latest modeling language (obtained through an
extension of UML for the service world) designed specifically for
service-oriented applications.
Business Process Management space has a variety of modeling languages used
to describe business processes and their executable models. BPMN (Business
Process Modeling Notation) is a language that enables users to fully model
business processes, sub-processes, and individual tasks. BPEL (Business
Process Execution Language) is used to represent executable business process
239

models. Vendors and various BPM platforms support one or both of these
languages.
Additionally, there may be a variety of Domain Specific Languages (DSL)
defined for a variety of domains. Some of these DSLs are incorporated into
standards, while others remain on their own. DSLs, as any other modeling
languages, help people working within the domain standardize the syntax,
notation, and semantic of the information being presented by each model.
Concrete/Solution / Physical Architectures A concrete architecture is
a physical instantiation of a reference architecture achieved by substitution of
the general, logical, and abstract elements of the template with concrete or
physical realizations of vendor products and instances of technical products,
standards, protocols, and design/architectural decisions. Industries can
instantiate concrete architectures for their usage context. Concrete/solution
architectures are used directly to drive project implementations.
While we already briefly discussed SoaML, the next section is dedicated to
covering it in detail.
4. Service Oriented Architecture Modelling Language (SoaML) [2]
For many years, UML (unified modeling language) has been the key tool for
visually
specifying,
modeling,
representing
and
communicating
object-oriented software design. With the continued adoption of
service-orientation for enterprise engineering, there was a need for UML to be
extended to accommodate the unique principles and patterns of the service
paradigm. To address this need, OMG created the SoaML specification.
SoaML defines a UML profile and a metamodel that extends UML to support
a range of modeling requirements for SOA. The key requirements include the
specification of a system of services, individual service interfaces and service
implementations.
The SoaML metamodel extends the UML metamodel to support service
modeling. This extension is intended to support different service modeling
scenarios, such as single service description, service-oriented architecture
modeling, or service contract definition. SoaML has been designed to support
both the IT and business perspectives of SOA. A UML profile customizes UML
for a specific domain or purpose by using extension mechanisms such as

240

stereotypes and metaclasses. Figure 4 shows the main stereotypes defined in

the UML profile for SoaML.
Figure 4. Main UML extensions defined as stereotypes in the UML
Profile for SoaML

241

SoaML extends UML in six main areas participants, service interfaces,

service contracts, service architectures, service data and capabilities.
Participants are used to define service providers and consumers. A
participant may play the role of a service provider, consumer or both. When a
participant acts as a provider it contains service ports. Alternatively, when a
participant acts as a consumer, it acts as a port to issue requests.
Service interfaces are used to describe the operations provided and
required to complete the functionality of a service. A service interface can be
used as the protocol for a service port or a request port.
Service contracts are used to describe interaction patterns between service
entities. A service contract is used to model an agreement between two or
more parties. Each service role in a service contract has an interface that
usually represents a provider or a consumer.
Services Architecture is a network of participant roles providing and
consuming services to
Fulfill a purpose. The services architecture defines the requirements for the
types of participants and service realizations that fulfill those roles.
Service data is used to describe service messages and message attachments.
The message type is used to specify the information exchanged between
service consumers and providers. An attachment is a part of a message that is
attached to rather than contained in the message. A common approach is to
create a formalMessaging Model derived from a standard enterprise data
model that defines and constrains the data structures that are passed to and
from service instances.
Capabilities represent an ability to perform tasks or activities. Capabilities
identify or specify a cohesive set of functions or resources that a service
provided by one or more participants might offer. Capabilities can be used by
themselves or in conjunction with participants to represent general
functionality or abilities that a participant must have.
Approaches to Specifying Services The SoaML specification
recommends three different approaches for specifying a SOA service:

242

The simple interface based approach uses a UML interface to specify a

one-way service interaction. This focuses attention on a one-way interaction
provided by a participant on a port represented as a UML interface. The
participant receives operations on this port and may provide results to the
caller. This approach can be used with anonymous callers and the
participant makes no assumptions about the caller or the choreography of the
service.
The service contract based approach extends a UML collaboration to
specify a binary or n-ary service interaction. This defines service specifications
that describe the roles each participant plays in the service (such as provider
and consumer) and the interfaces they implement to play that role. These
interfaces are the types of ports on the participant, which obligates the
participant to be able to play that role in the service contract. The service
contract based approach extends a UML collaboration to model the structural
part of the service interaction. The approach can be used to specify services in
which there is a contractual obligation, i.e. an agreement, between two or
more parties. This is the case where you have an interaction pattern that
involves an exchange of messages specifying (simple) interfaces on both sides.
The service interface based approach extends a UML class to specify a
binary or n-ary service interaction. This is quite similar to the service contract
based approach in that it also focuses on binary and n-ary service interactions,
requiring that a set of related (simple) interfaces is specified as one service
specification. Whereas the service contract based approach prescribes using
UML collaboration, the service interface based approach focuses on UML
components and allows the interconnection between these components
through ports. In order to connect components through ports, the ports must
specify both required and provided interfaces. The service interface based
approach introduces the concept of a service interface and a conjugate
service interface to type the ports on the provider and consumer side
respectively.
Both the service contract and service interface based approaches entail the
specification of simple interfaces, typically one for each of the roles
participating in the service interaction. Thus, a service contract or a service
interface can be seen as an extension of the simple interface based approach.
An Illustration - The Dealer Network Architecture example from the SoaML
specification is explained here. The services architecture for this example is
243

illustrated in the Figure 5 below. The Dealer Network Architecture consists of

four participants (dealer, manufacturer, agent and shipper) interacting and
fulfilling their roles defined in the three service contracts: Secure Purchase
(specifying the roles buyer, seller and broker), Shipping Request (specifying
the roles sender and shipper) and Shipping Status (specifying the roles
receiver and shipper). In the services architecture, the participants are
bounded to the roles defined in the service contracts through the collaboration
that uses purchase (instance of Secure Purchase), ship (instance of Shipping
Request) and status (instance of the Ship Status).
Figure 5. The Services Architecture

There are three services identified (as service contracts): Secure Purchase,
Ship Status and Shipping Request. Some of these may, in fact, be simple
one-way interactions and could thus be modeled using the simple interface
based approach. Although the three different service specification approaches
of SoaML are different, they are still interconnected since simple interfaces

244

are structural parts in both the service contract and service interface based
approaches.
Aligning Business and IT Models using BPMN and SoaML - The
increasing popularity of the SOA paradigm relies on its close relationship to
business models, in particular business process models. The SOA concepts
apply to both business and system architectures. A Service Model is a
representation of how an enterprise functions internally and externally,
expressed in terms of contracts, responsibilities, capabilities and interactions
and collaborations, both with internal and external entities. From an IT
perspective, the Service Architecture describes the software components, their
service interfaces and the way these components can be coupled to form a
technical system architecture that supports the business requirements of the
enterprise.
Figure 6. Business and IT SOA perspectives

245

It should be noted that some of the language constructs defined in SoaML fit
on both the business and IT level. In particular, this applies to participants
that are used to define the service providers and consumers in a system. At the
business level, the participants typically represent business organization units
or roles, whereas on the IT level the participants typically represent IT
systems or software components. When a participant acts as a provider, it
contains service ports, and when a participant acts as a consumer, it contains
request ports.
SoaML is agnostic to the choice of modeling formalisms to define behavior.
The specification states that any UML behavioral constructs can be used to
describe behavior, e.g. service choreographies, and other formalisms, e.g. EPC
(event processing chain), business process modeling notation (BPMN), UML,
BPEL (business process execution language), etc. The SoaML specification
primarily describes the structure of the service architecture.
SoaML goals are:
o
o

o
o

o
o
o
o
o

Intuitive and complete support for modeling services in UML

Support for bi-directional asynchronous services between multiple
parties
Support for Services Architectures where parties provide and use
multiple services
Support for services defined to contain other services
Easy ability to map to a business process specification or become a part
of it
Compatibility with UML, BPDM and BPMN for business process
modeling
Direct mapping to web services
Top-down, bottom up or meet-in-the-middle modeling
Design by contract or dynamic adaptation of services
Ability to specify and relate service capability with its contract
No changes to UML notation

The SoaML modeling language was designed to generate services directly

from models. It provides a baseline modeling language for specification of any
services within a service oriented environment, including cloud-based services.
The SoaML language specifies some twenty main extensions to UML that
provide key language constructs for specifying the structure of services.

246

SoaML does not specify which kind of behavioral notation to use, so that
BPMN or any other standard can be used for specific behavioral modeling.
SoaML is supported by UML tool vendors and incorporated as part of their
service-oriented methodologies. In particular, IBM has incorporated SoaML
into its Service-Oriented Modeling and Architecture (SOMA) methodology
that is supported by its Rational Software Architect (RSA) modeling tool.
Other vendors that provide SoaML support are ModelDriven.org, NoMagic,
SOFTEAM and Sparx Systems (www.soaml.org). In addition, SoaML-based
tools and methods for model-driven engineering of service-oriented systems
were developed by the European research project SHAPE. The current tools
and methodologies using SoaML focus mainly on supporting the MDA
approach, which emphasizes models as the essential artifacts. Similarly, the
Architecture-Driven Modernization (ADM) (adm.omg.org) proposes to start
with knowledge discovery to recover models and to rebuild new systems in a
forward MDA process. The ADM initiative may be another starting point in
order to support migration of legacy systems to the cloud. The European
research project REMICS (www.remics.eu) aims to develop a complete
process including methods and tools for creating SoaML models from the
legacy artifacts and rebuilding cloud-based systems by applying SOA and
cloud patterns.
5. The Reference Architecture (RA) for SOA [3]
Different consortia have come out with different Reference Architectures
based on their views, purposes and perspectives. In this section, we discuss
the Reference Architecture standard proposed by the Open Group. The
purpose of a Reference Architecture is to help optimize service design,
streamline service modeling, and enable effective governance of the service
lifecycle. Architects should use reference architectures to help answer
questions such as:
o
o
o

What are the scope and constraints of the proposed solution?

What is the most appropriate technology for constructing that solution?
How can the proposed solution be organized in terms of individual
components with specific responsibilities?
How can a solution be designed in a manner that maximizes asset
reuse?
Can automated tools help take the guesswork out of architecture
validation and capacity planning?
247

This is the main motivation for Reference Architecture specification that

provides a high level abstraction of a layered and well-structured solution.
This layered architecture is constructed from a meta-model consisting of
layers, architectural building blocks (ABB), relations between ABBs and
between layers, interactions patterns, options and architectural decisions.
These will guide the architects in the creation and evaluation of designs based
on the Reference Architecture. Each building block represents only
alogical element of reusable functionality. The role of the architect is to define
the most appropriatephysical components to instantiate the most appropriate
ABBs for the enterprise.
Why SOA Reference Architecture?
The usage of an SOA Reference Architecture is a key enabler to achieve value
propositions promised by service-orientation. An SOA Reference Architecture
(SOA RA) is guaranteed to provide guidelines for making architectural, design,
and implementation decisions related to service-oriented systems. The goal of
an SOA RA is to provide a blueprint for creating or evaluating possible
architectural approaches. Additionally, it provides patterns and insights for
integrating fundamental SOA elements into the solution. Informally, an SOA
RA is designed to answer some of the key questions and issues encountered by
architects including:
What are the aspects of an SOA that need to be considered when
designing solutions based on service-oriented principles?
o
What are the building blocks that need to be included in each layer of
the proposed solution?
o
What are some of the key architectural decisions that need to be made
when designing a service-oriented solution?
o
Which roles in a project would benefit from using these principles and
guidelines?
o

An SOA Reference Architecture is used as a blueprint and includes templates

and guidelines for architects. These facilitate and ultimately enable
automating and streamlining processes of modeling and documenting the
architectural layers, architectural building blocks within them, options for
layers and ABBs, mapping of products to the ABBs and architectural and
design decisions that contribute to the creation of robust and resilient
SOA-based business solutions. It is intended to support organizations
adopting SOA, product vendors building service-oriented offerings,
248

integrators engaged in delivering SOA solutions, consultants and standards

bodies engaged in establishing SOA specifications.
Key Principles of SOA Reference Architecture
The Open Group SOA Reference Architecture has been defined and refined
with the following principles in mind:
1) SOA Reference Architecture should be a generic solution that is
vendor-neutral.
2) It is based on a model of standards compliance.
3) It should be capable of being instantiated to produce intermediary
industry architectures and concrete solution architectures.
4) It should use the fewest number of layers to depict the possible
combinations and elements of a service-oriented solution.
5) It should address multiple stakeholder perspectives
a) For organizations implementing SOA Reference Architecture for
internal use, the Reference Architecture should be generic enough to
be independent of vendor solutions. It should define standard building
blocks, architectural decisions and other attributes to create a
framework of understanding sufficient to enable an assessment of
conformance and a clear foundation for governance.
b) For product vendors, Reference Architecture should provide a set of
standards and enough specificity to drive evaluation of compliance
with underlying standards. The architecture of vendor products can be
easily understood by its customers if it is based on a particular
Reference Architecture.
c) For integrators, Reference Architecture should be used as a model to
define specific constraints and directions for SOA implementations.
d) For standards bodies, Reference Architecture should provide a
reference against which they can extend standards or provide
guidelines and more detailed levels of specificity.
The Elements and Layers of the SOA RA
The Open Group SOA Reference Architecture has nine layers that represent
key clusters of considerations and responsibilities that arise in the process of
designing SOA solutions. They include:

249

1. Operational Systems Layer

2. The Service Component Layer
3. Services Layer
4. Business Process Layer
5. Consumer Layer
6. Integration Layer
7. Quality of Service (QoS) Layer
8. Information Architecture Layer
9. Governance Layer
Each layer is designed to materialize and reinforce each of the various
perspectives of SOA business value. For each layer, it is practical to postulate
two aspects: logical and physical. The logical aspect includes all the
architectural building blocks, design decisions, options, KPIs, etc. The
physical aspect of each layer includes the realization of each logical aspect
using technology, standards and products that are determined by taking into
consideration different architectural decisions that are necessary to realize the
architecture and construct the solution.
This specification has a specific focus on the logical aspects of the SOA
Reference Architecture and provides a model for including key architectural
considerations and making architectural decisions through meta-model
elements. Three of the layers address the implementation and interface with a
service (Operational Systems Layer, Service Components Layer and Services
Layer). Two of them support the consumption of services (Business Process
Layer and Consumer Layer) while four of them support cross-cutting concerns
of a more non-functional nature (Information Architecture, Quality of
Service, Integration and Governance Layers). SOA Reference Architecture, as
a whole, provides the framework for support of all the SOA elements,
including all the components that support services and their interactions. This
logical view defines what layers and abstractions should be present in a typical
service-oriented solution.
The Core Elements of SOA Reference Architecture
SOA Reference Architecture enumerates fundamental elements of an SOA
solution and provides the architectural foundation for it. As shown in

250

the Figure 7 below, the SOA Reference Architecture meta-model includes the
following elements:
Figure 7. SOA Reference Architecture meta-model

Layer - An abstraction that contains a set of components such as ABBs,

architectural decisions, interactions among components and interactions
among layers.
o
Architectural Building Block (ABB) is a constituent of the
architecture model that describes a single aspect of the overall model.
Each layer can be thought to contain a set of ABBs that define the key
responsibilities of that layer. In addition, ABBs are connected to one
another across layers and thus provide a natural definition of the
association between layers. In this Reference Architecture, each ABB
resides in a layer, supports capabilities, and has specific responsibilities.
It contains attributes, dependencies, constraints and relationships with
other ABBs in the same or different layer.
o
Method Activity is a set of steps that involve ABBs within a layer. The
method activity provides a dynamic view of how different ABBs within a
layer will interact. Method activities can also be used to describe the
interaction between layers, so that an entire interaction from a service
invocation to service consumption is addressed.
o
Options are a collection of possible choices available in each layer that
impact other artifacts in a layer. Options are the basis for architectural
o

251

decisions within and between layers and have concrete standards,

protocols, and potentially instantiable solutions associated with them. An
example would be SOAP or REST style services. Which option has to be
selected is an architectural decision.
Architectural Decision is a decision derived from the options
available. The architectural decision is driven by architectural
requirements and involves governance rules and standards, ABBs, KPIs
(Key Performance Indicators) and NFRs (Non Functional Requirements)
to decide on standards and protocols to define a particular instance of an
ABB. This can be extended based on the instantiation of Reference
Architecture to the configuration and usage of ABBs. Existing
architectural decisions can also be reused by other layers or ABBs. The
documentation of architectural decisions should include a description of
the corresponding problem or ABB, different options that were
considered, including the pros and cons of each, the recommended option,
and the rationale for that decision.
Interaction Pattern is an abstraction of the various relationships
between ABBs. This includes diagrams, patterns, pattern languages and
interaction protocols.
Key Performance Indicator (KPI) - A key performance indicator
may act as input to an architectural decision.
Non-Functional Requirement (NFR) - An NFR may act as input
to an architectural decision. NFRs help address Service Level Agreement
attributes, (e.g. response time, etc.) and architectural cross-cutting
concerns such as security.
Enabling Technology is a technical realization of ABBs in a specific
layer.
Information Model is a structural model of the information
associated with ABBs including data exchange between layers and
external services. The information model includes meta-data about the
data being exchanged.

SOA Reference Architecture Layers

Any SOA implementation is constrained by the set of functional and
non-functional requirements. Functional requirements are business
capabilities imperative for business operations including business processes,
business and IT services, as well as components and underlying systems that
implement those services. Non-functional service aspects include security,
252

availability, reliability, manageability, scalability, latency, governance, and

integration capabilities. The underlying requirements that determine the
capabilities SOA supports are determined by:
A set of service requirements that includes business (functional) and
non-functional requirements of a service
o
Service requirements result in the documented capability that a service
needs to deliver or is expected to deliver
o
The provider view of a service requirement is the business and
technical capability that a service needs to deliver given the context of all
of its consumers
o
The consumer view of a service requirement is the business and
technical capability that the service is expected to deliver in the context of
that consumer alone.
o

A service requirement may be addressed through a combination of layers,

each of which has a specific responsibility. This is typically defined in the SOA
Reference Architecture. Services themselves have a contract element and
functional element. The contract defines what the service does for consumers,
while the functional element defines how the service is implemented. The
service contract is integrated with the underlying functional element through
a binding component that hides the physical implementation of the service
from its consumers, thereby allowing the physical implementation to be
changes without breaking the service contract.
This model addresses ability to service enable legacy assets, new assets,
services composed from other services or infrastructure services. For each
layer, there is a specific mechanism by which the service requirements
influence that layer. The identification of service requirements and the
mapping of those requirements to each of the layers in the SOA Reference
Architecture is a key element for implementing SOA in an enterprise.
Figure 8. Nine Layers of the SOA Reference Architecture

253

The Open Group SOA Reference Architecture defines nine layers that
represent various elements in the SOA solution. They are described in detail
below.
Layer 1: Operational Systems Layer
This layer captures new and existing organization infrastructure needed to
support the SOA solution. This includes:
1. Infrastructure needed to run all elements of the SOA solution.
2. All operational and runtime hosting platforms of the underlying
system components.
3. All assets required to support the functionality of a shared service,
including custom or packaged application assets, new services, services
created through composition or orchestration, infrastructure services,
and all other related components.
The capabilities supported by the Operational Systems layer include
integration of infrastructure services into the SOA solution, reuse of existing
assets composed within it, and the infrastructure elements required to
running the SOA platform. The Operational Systems Layer enables
organizations to implement an SOA solution without explicit knowledge of the
underlying infrastructure components, the hosting environment, and all of the
related specifics.

254

It is important to note that many services execute functionality through one or

more assets in this operational systems layer. For example, a patient record
update service that contracts to update patient records may do so using
different components running in application assets hosted in the operational
systems layer. A number of existing software systems are part of this layer.
These systems include:
o

o
o
o
o

Existing monolithic custom applications including JEE and .NET

framework applications
Legacy applications and systems
Existing transaction processing systems
Existing databases
Existing packaged applications and solutions including ERP and CRM
platforms

Layer 2: The Service Component Layer

This layer contains software components, each of which provides some or all
of the implementation or realization of an operation on a service. Service
components reflect the definition of the service they represent, both in its
functionality and its quality of service. They bind the service contract to the
implementation of the service in the operational systems layer. Service
components are hosted in containers that support a service specification. The
service component layer manifests the IT conformance with each service
contract defined in the services layer. It guarantees the alignment of IT
implementation with service description. Each service component
Provides an enforcement point for faithful service realization to
ensure quality of service and service level agreements
o
Enables business flexibility by supporting the functional
implementation of IT flexible services, their composition and layering
o
Enables IT flexibility by strengthening decoupling inside IT systems.
Decoupling is achieved by hiding volatile implementation details from
consumers.
o

Figure 9. Behavior abstraction through service component layer

255

In Figure 9, Service A is implemented using a combination of behaviors from

3rd party Package X and Application Y. Application B, the consumer, is
coupled only to the description of the exposed service. The consumer must
assume that the realization of the service is consistent with its published
description and it is the providers responsibility to ensure that such
compliance is achieved. The details of the realization, however, are of no
consequence to Application B. Service Component A acts as a service
implementation faade, aggregates available system behaviors and gives the
provider an enforcement point for service compliance. Application B invokes
and interoperates with a service contract and specification defined as part of
the Service A interface. Subsequently, the Provider organization may decide
to replace Package X with Package M. The required modifications are
encapsulated in Service Component A with the result that there is no impact
to any consumers of Service A. This example illustrates the value of the
Service Component layer in supporting IT flexibility through encapsulation.
Layer 3: Services Layer
This layer consists of all the services defined as part of the SOA
implementation. Unlike the Operational Systems and Service Components
layers, this layer is visible to service consumers. The service layer contains
service descriptions (design time and business architectural assets, as well as
runtime service contract descriptions) and the container for implementing the
services. The specification provides consumers with sufficient detail to invoke
the business functions exposed by the service provider. Ideally, this should be
done in a platform-independent manner. The service specification includes a
description of the abstract functionality offered by the service similar to the
abstract stage of a WSDL description. This information is not necessarily
WSDL. The service specification may include:
256

o
o
o

A policy document
SOA management descriptions
Attachments that categorize or show service dependencies.

Some of the services in the service layer may be versions of other services,
which means that a significant successor/predecessor relationship may exist
between them. Thus, exposed services reside in this layer. They can be
discovered and invoked or possibly choreographed to create a composite
service.
Services are functions that are accessible across a network via well-defined
interfaces of the Services Layer. This layer also provides a mechanism to
take enterprise scale components, business unit specific components and in
some cases project-specific components and externalizes a subset of their
interfaces in the form of service descriptions. Thus, the components provide
services through their interfaces. The interfaces get exported out as service
descriptions in this layer, where services exist in isolation (atomic) or as
composite services. For example, a service container in which the services
are hosted, is also a part of the Services Layer. The service container is
compliant with the standards for service specification being supported by the
service and runs on a hosting platform in the operational systems layer. This
layer contains the contracts that bind the provider and consumer. Services are
offered by service providers and are consumed by service consumers (service
requestors).
The layers and their underlying building blocks in the target architecture may
be defined according to the service identification activities that may be defined
through three complementary techniques of domain decomposition, existing
asset analysis and goal service modeling to identify, specify, and realize
services, components and flows. They represent the heart of the SOA value
proposition improved agility via the decoupling of business and IT. The
quality of these service definitions will have a significant impact on the benefit
of a given SOA effort.
Services should be accessible independent of implementation and transport.
This allows a service to be exposed consistently across multiple customer
facing channels. It is important to acknowledge that Service Components may
consume Services to support integration. The identification and exposure of
this type of Service, e.g. internal services, does not necessarily require the
same rigor as is required for a business service. While there may be a
257

compelling IT related reason behind the use of such services, they are not
generally tied back to a business process and, as such, do not warrant a
rigorous analysis required for business services.
In addition to being an important template for defining an SOA solution at a
logical level, the SOA Reference Architecture is also a useful tool in the design
of vendor neutral SOA solutions. This is because it enables the objective
identification of SOA infrastructure requirements. The SOA Reference
Architecture provides a well-factored decomposition of the SOA problem
space, which allows architects to focus on those parts of an SOA solution that
are important in the context of the problem they are solving and to map the
required capabilities onto vendor product capability rather than trying to
reverse engineer an SOA solution architecture from the capability of a
particular vendors products. This set of requirements can be used to better
leverage various capabilities provided by a mix of different vendors that may
offer the same architectural building blocks. Using the same SOA Reference
Architecture we can deliver SOA business services based on the same
deployment framework.
Layer 4: Business Process Layer
In a service-oriented world, business capabilities are realized by business
processes or collections of business processes. These business processes
include service orchestrations and compositions, as well as the ability to insert
human intervention and support long-living transactions. In particular,
compositions and choreographies of services exposed in Layer 3 are defined in
this layer.
The evolution of service composition into flows, or choreographies of services
bundled into a flow act together to establish an application. These applications
support specific use cases and business processes. Visual flow composition
tools can be used to design application flows. Figure 10 shows how a Business
Process P can be implemented using Services A, B, C and D from Services
Layer. Process P contains the logic to sequence and orchestrate service
invocation and execution. The services that are aggregated as a business
process can be an individual service or a composite service.
Figure 10. Process composed from a variety of services

258

The Business Process Layer covers the process representation, composition

methods, and building blocks for aggregating loosely coupled services as a
sequencing process aligned with business goals. Data flow and control flow are
used to enable interactions between services and business processes. The
interaction may exist within an enterprise or across multiple enterprises. This
layer includes information exchange flow between participants (individual
users and business entities), resources, and processes in a variety of forms to
achieve the business goal. Most of the information exchanged may also
include non-structured and non-transactional messages. The business logic is
used to form service flow as parallel or sequential tasks based on business
rules, policies, and other business requirements. From the data flow
perspective, the business context and metadata are used to support the
aggregation of services within an enterprise for business process orchestration
or across multiple enterprises for business process choreography. The lifecycle
management for business process orchestration and choreography is also
covered in this layer. In addition to the run-time process engine (e.g.
WS4BPEL engine), this layer covers all aspects of composition, collaboration,
compliance, process library, process service, and invocation elements.
Using the top-down approach, business processes are defined by business
analysts, based on customers requirements. In order to optimize the business
process for better IT implementation, we need to decompose a business
process into reusable services that can be modeled, analyzed, and optimized
based on business requirements including QoS (historical data described in
layer 7), flow preference, price, time of delivery, and customer preferences.
259

From the bottom-up perspective, after we have created a set of assets, we

would like to leverage them in a meaningful business context to satisfy
customer requirements. The flexibility and extensibility of service composition
guided by business requirements and composition rules enable business
process to address different types of customer pain points by reusing service
assets.
From the interaction perspective, the business process layer communicates
with the consumer layer (a.k.a. presentation layer) to gather inputs from and
display results to various actors (e.g. end-user, decision makers, system
administrator, etc.) through Web portals or business-to-business (B2B)
interfaces. Most of the control flow messages and data flow messages of the
business process may be routed and transformed through the integration layer.
The structures of the messages are most often defined by the data architecture
layer. The KPIs for each task or process could be defined in QoS and business
performance layer. The design of service aggregations is guided by the
Governance layer. Of course, all the services should be represented and
described by the Services Layer in the SOA Reference Architecture.
From the technical perspective, dynamic and automatic business process
composition poses critical challenges to researchers and practitioners in the
field of Web services. Business processes are driven by business requirements
that typically tend to be informal, subjective, and difficult to quantify.
Therefore, it is critical to properly formulate the descriptive and subjective
requirements into quantifiable, objective, and machine-readable formats in
order to enable automatic business process composition and execution. In
addition, the current web service specifications generally lack ability to define
comprehensive relationships among business entities, business services, and
operations. These relationships may be important to optimize business
process composition and execution. How to clearly specify search
requirements to discover the most appropriate Web services candidates
remains a challenge.
Lastly, a typical business process generally requires multiple web services to
collaborate in order to address its needs. Therefore, each service not only
needs to satisfy individual requirements, but also needs to coexist with other
services in order to fit within the overall composed business process. This
suggests that the entire business process needs to be optimized prior to
execution.
260

The business process layer in the SOA Reference Architecture plays a central
coordinating role in connecting business level requirements with IT-level
solution components through collaboration with integration layer, QoS and
business performance management layer, as well as data architecture and
services layers.
Layer 5: Consumer Layer
SOA supports a client-independent and channel-agnostic set of functionality
that is separately consumed and rendered through one or more channels. This
ability empowers organizations to use SOA to improve quality, increase
consistency and support enhanced reuse. The consumer layer provides the
capabilities required to deliver IT functions and data to end-users through a
variety of channels, such as portals, rich clients (mashups and Ajax), etc.,
application-to-application interfaces, and other services. Some recent
standards such as Web Services for Remote Portlets (WSRP) may leverage
web services at the application interface or presentation level. It is also
important to note that SOA decouples the user interface from the underlying
components. Examples include Service Component Architecture (SCA)
Components, portlets, WSRP and B2B.
The Consumer Layer of the SOA Reference Architecture provides the
capability to quickly create the front end of the business processes and
composite applications to respond to changes in the marketplace. It enables
channel-independent access to those business processes supported by various
applications and platforms. By adopting proven front-end access patterns (e.g.
portals) and open standards (e.g. WSRP), development and deployment cycle
times can be decreased through the use of many pre-built, proven and
reusable front end building blocks. Additionally, complexity and maintenance
costs are reduced due to use of these common building blocks. This approach
improves the usability of the business processes/applications created using it
and promotes a single unified view of knowledge presentation, a single unified
entry point to the supported business processes/applications that integrates
with other foundational services such as security (single sign-on, for example)
and trust.
The Consumer Layer allows for the plug-and-play of content sources (e.g.,
portlets) with portals and other aggregating web applications. It therefore
standardizes the consumption of services in portal front ends and the way in
which content providers write services for portals. Scenarios that motivate
261

WSRP-like functionality include: (1) Portal servers providing portlets as

presentation-oriented services that can be used by aggregation engines; (2)
Portal servers consuming presentation-oriented services provided by portal or
non-portal content providers and integrating them into a portal framework.
This description also applies to non-portal environments. WSRP allows
content to be hosted in the environment most suitable for its execution while
still being easily accessed by content aggregators. The standard enables
content producers to maintain control over the code that formats the
presentation of their content. By reducing the cost for aggregators to access
their content, WSRP increases the rate at which content sources may be easily
integrated into pages for end-users. It should be noted that Asynchronous
JavaScript and XML (AJAX), a way of exchanging XML contents over HTTP
without refreshing Web browsers, can be used to enhance SOA interaction
capability with Web users.
Layer 6: Integration Layer
The integration layer is a key enabler for SOA as it provides the capability to
mediate, transform, route and transport service requests from the service
requester to the correct service provider. It also provides support for a
common business rules capability used to ensure that relevant and
appropriate business rules are applied across all the different layers in the
architecture. This layer enables the integration of diverse and distributed
services through a reliable set of capabilities being offered by a
standards-compliant enterprise service bus (ESB) platform.
Figure 11. Integration Layer including ESB

262

An ESB provides a location-independent mechanism for integration. The

integration that occurs here is primarily the integration of the functional
layers in the SOA Reference Architecture (layers 2 through 4). For example,
this is where the binding (late or otherwise) of services occurs for process
execution. This allows a service to be exposed consistently across multiple
customer-facing channels such as Web, IVR, XML client, mobile, etc. The
transformation of response to HTML (for Web), Voice XML (for IVR), XML
String, wireless mark-up language can be done via XSLT or other built-in
transformation functionality supported by the ESB platform.
The integration layer provides a level of indirection between the consumer of
functionality and its provider. A service consumer interacts with the service
provider via the Integration Layer. Hence, each service interface is only
exposed via the integration layer (e.g. ESB), never directly. Consumers and
providers are decoupled, and this decoupling allows seamless integration of
disparate systems into new solutions.
Business Rules and Integration Layer
As widely known, business rules are a cross-cutting architectural concern.
They need to be consistently applied across the multiple layers in SOA or over
time. The integration layer provides a common business rules capability that
can be used by the ESB and the other layers in the SOA Reference Architecture.

263

The integration layer also incorporates the support for runtime service
virtualization using registry. Service virtualization abstracts (decouples) the
location of services for consumers. Services are exposed and can be discovered
through a registry, but the exact location is hidden to support versioning,
change of service locality and administration, without impacting the
consumer.
Layer 7: Quality of Service (QoS) Layer
SOA contains inherent characteristics that exacerbate existing QoS concerns
in computer systems. They include increased virtualization / loose coupling,
widespread use of XML, composition of federated services, heterogeneous
computing infrastructures, decentralized SLAs, need to aggregate IT QoS
metrics to produce business metrics, etc. These characteristics create
complications for QoS that require attention within any SOA solution. The
QoS layer provides the service solution lifecycle processes with the capabilities
required to ensure that the defined policies and non-functional requirements
are addressed.
The QoS layer deals with issues like monitoring and capture of service and
solution metrics from an operational perspective as well as signaling
non-compliance with non-functional requirements related to the salient
service qualities and policies associated with each SOA layer. Service metrics
are captured and connected with individual services to allow service
consumers to evaluate service performance, creating an increased level of
trust. This layer serves as an observer of the other layers and can create events
when a non-compliance condition is detected or (preferably) when a
non-compliance condition is anticipated. The QOS layer makes non-functional
requirements related issues the primary feature/concern and establishes a
focal point for dealing with them in any given solution. It provides the means
of ensuring that each service meets its requirements in the following
categories:
o
o
o
o
o

reliability
availability
manageability
scalability
security

264

Finally, the QoS layer enhances the business value of SOA by enabling
organizations to monitor business processes related to or supporting shared
services. In particular, SOA security, a significant issue with typical service
implementations due to their potential perimeter-less nature as opposed to
traditional, web-based, within the firewall, perimeter based security is a
capability realized by the QoS layer.
Layer 8: Information Architecture Layer
This layer includes information architecture, business intelligence, and
meta-data considerations. It ensures the inclusion of key considerations
pertaining to data and information architectures that can also be used as the
basis for the creation of business intelligence through data marts and data
warehouses. This includes meta-data content that is stored in this layer. For
industry-specific SOA solutions, this layer captures all the common
cross-industry and industry-specific data structures, XML-based meta-data
architectures (e.g. XML schema), and business protocols of exchanging
business data. Some discovery, data mining, and analytical modeling of data
are also covered in this layer. These common structures may be standardized
for the industry or an organization.
Layer 9: Governance Layer
SOA Governance ensures that the services and SOA solutions within an
organization adhere to the defined policies, guidelines and standards. SOA
governance activities need to conform to Corporate, IT & EA governance
principles & standards. The Governance layer will be adapted to match and
support the target SOA maturity level of the organization.
The governance layer includes SOA governance (governance of processes for
policy definition and enforcement) as well as Service governance (service
lifecycle). This covers the entire lifecycle of the services and SOA solutions
(from design to runtime and retirement) as well as portfolio management of
both the services and SOA solutions managing all aspects of services and SOA
solutions (e.g. SLA, capacity and performance, security and monitoring). This
layer can be applied to all the other layers in the SOA Reference Architecture.
From the quality of service and performance metrics perspective, it is well
connected with the QoS layer. From a service lifecycle and design time
perspective, it is connected with the Service layer. From an SOA solution
lifecycle perspective, it is connected with the Business Process layer. The goal
265

of the SOA Governance layer is to ensure consistency of the Service and

Solution portfolio and lifecycles processes. In this layer, the extensible and
flexible SOA governance framework will ensure that all aspects of SOA are
managed and governed. This includes:
o
o
o
o
o
o
o

Service lifecycle
SOA standards, precepts, and practices
SOA methodology
Governance processes and mechanisms
Service Level Agreements based on QoS and KPIs
Capacity and Performance management policies
Security enablement

The information in this layer that is collected and made available consists of:
o
o

o
o
o
o
o

Guidelines for SOA Governance

Guidelines for Service and SOA Solution lifecycle and portfolio
management
Best practices
Policies (e.g. security)
Standards
Service and SOA solution roadmaps
Compliance, Dispensation and Communication documentation

The SOA Reference Architecture is a crucial component for constructing

competent service-oriented IT systems, as it can be applicable to any domain
and technology. Due to highly abstract and generic nature, any kind of
preferences can be imposed on the Reference Architecture.
6. SOA Ontology
The purpose of this technical standard is to contribute to the Open Group
mission of Borderless Information Flow by developing and fostering common
understanding of SOA in order to improve alignment between the business
and information technology communities and to facilitate SOA adoption. It
does this in two specific ways:
o

It defines the concepts, terminology and semantics of SOA in both

business and technical terms in order to create a foundation for further
work in domain-specific areas, enable communications between business

266

and technical people, and enhance the understanding of SOA concepts in

the business and technical communities
o
It provides a means to state problems and opportunities
unambiguously so as to promote mutual understanding. In the long term
scenario, it potentially contributes to model-driven SOA implementation.
The SOA ontology is designed to be used by:
a) Business people, to give them a deeper understanding of SOA concepts
and how they are used in the enterprise
b) Architects, as metadata for architectural artifacts
c) Architecture methodologists, as a component of SOA meta-models
d) System and software designers, for guidance in terminology and
structure
The SOA ontology is best represented using the Web Ontology Language
(OWL) defined by the World-Wide Web Consortium (W3C). OWL has three
increasingly expressive sub-languages: OWL-Lite, OWL-DL, and OWL-Full.
This ontology uses OWL-DL, the sub-language that provides the greatest
expressiveness possible while retaining computational completeness and
decidability. The SOA ontology contains classes and properties corresponding
to the core concepts of SOA. The formal OWL definitions are supplemented by
natural language descriptions of the concepts with graphic illustrations of the
relations between them and with examples of their use. For purposes of
exposition, the ontology also includes UML diagrams that graphically
illustrate its classes and properties. The natural language and OWL definitions
contained in this specification constitute the authoritative definition of the
ontology, and the diagrams are for explanatory purposes only.
The Core Concepts of SOA Ontology
The terms system and element are two core concepts of the SOA ontology.
Both are concepts that are often used by practitioners, including the notion
that systems have elements and that systems can be hierarchically combined
(systems of systems). What differs from domain to domain is the specific
nature of systems and elements. For instance, an electrical system has very
different kinds of elements than an SOA system. Relationships between
systems and elements are represented using the following constructs:
o

uses and usedBy

267

represents and representedBy

Element Class
<owl:Class rdf:about=#Element>
</owl:Class>
An element is an opaque entity that is indivisible at a given level of abstraction.
The element has a clearly defined boundary. The concept of element is
captured by the Element OWL class, as depicted in Figure 12.
Figure 12. Element class representation

Uses and usedBy Properties

<owl:ObjectProperty rdf:about=#uses>
<rdfs:domain rdf:resource=#Element/>
<rdfs:range rdf:resource=#Element/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID=usedBy>
<owl:inverseOf>
<owl:ObjectProperty rdf:ID=uses/>
</owl:inverseOf>
</owl:ObjectProperty>
Elements may use other elements in various ways. An element uses another
element if it interacts with it in some fashion. For example, an element simply
is a member of (used by) some system class or an element interacts with
(using) another element (such as a service) in an ad-hoc fashion or even a

268

strongly coupled dependency in a composition. The uses property and its

inverse usedBy capture the abstract notion of an element using another.
These properties capture not just transient relations. Instantiations of the
property can include uses at this instant, has used, and may in future
use.
Element Organizational Example
Using the example or an organization chart, typical instances of Element are
organizational units and people. Whether to perceive a given part of an
organization as an organizational unit or as the set of people within that
organizational unit is an important choice of abstraction level.
Inside the boundary of the organizational unit, we want to express the fact
that an organizational unit uses the people that are members of it. Note that
the same person can, in fact, be a member of (be used by) multiple
organizational units.
Outside the boundary, the internal structure of an organizational unit must
remain opaque to an external observer, as the enterprise wants to be able to
change the people within the organizational unit without having to change the
definition of the organizational unit itself.
This simple example expresses that some elements have an internal structure.
In fact, from an internal perspective they are an organized collection of other
simpler things (captured by the System class defined below).
System Class
<owl:Class rdf:ID=System>
<owl:disjointWith>
<owl:Class rdf:ID=Task/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID=Service/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about=#Element/>
</rdfs:subClassOf>
</owl:Class>

269

A system is an organized collection of other artifacts, specifically instances

of Element, each such instance having the used by relationship to the
system. The concept of system is captured by the SystemOWL class, which is
illustrated in Figure 13.
Figure 13. System class representation

In the context of the SOA ontology we consider in detail only functional

systems that belong to the SOA domain. Note that a fully described instance
of System should have by its nature (as a collection) a usesrelationship to at
least one instance of Element.
Since System is a subclass of Element, all systems have a boundary and are
opaque to an external observer (black box view). This excludes structures that
have no defined boundary from the Systemclass. From the
service-orientation perspective, this is not especially relevant, since most
typical SOA systems can be described from an outside (consumer) perspective.
Furthermore, having System as a subclass of Element allows us to naturally
express the notion of systems of systems the lower-level systems are simply
elements used by the higher-level system.
At the same time, along with supporting an external viewpoint (black box view,
see above), all systems must also support an internal viewpoint (white box
view) expressing how they are organized as a collection. As an example, from a
service perspective, these viewpoints would typically correspond to a service
specification view versus a service realization view (similar to the way that
SoaML defines services as having both a black box (specification) part and a
white box (realization) part).
It is important to realize that even though systems using elements express an
important aspect of the usesproperty, it is not necessary to invent a system
just to express that some element uses another. In fact, even for systems we
may need to be able to express that they can use elements outside their own
boundary though this in many cases will be expressed not at the system level,
but rather by an element of the system using that external Element instance.

270

System is defined as disjoint with the Service and Task classes. Instances of
these classes are considered not to be collections of other things. System is
specifically not defined as disjoint with the HumanActorclass since an
organization in many cases is, in fact, just a particular kind of system. We
choose not to define a special intersection class to represent this fact.
System Examples
Organizational Example
Continuing the organizational example from above, we can now express that
an organizational unit as an instance of System has the people in it as
members (and instances of Element).
Composition Example
Rent Your Legacy Car company (RYLC) has a series of rental lots or outlets.
Each outlet can be instantiated in a simple ontology in the following way:
A RYLCOutlet is an instance of System.
o
The OutletManager is an instance of Element and is (used
by/manager of) RYLCOutlet.
o
Each Rental
Agent or VehicleMaintenanceOperative is
an
instance of Element and is (used by/employed at) RYLCOutlet.
o

Represents and representedBy Properties

<owl:ObjectProperty rdf:about=#represents>
<rdfs:domain rdf:resource=#Element/>
<rdfs:range rdf:resource=#Element/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID=representedBy>
<owl:inverseOf>
<owl:ObjectProperty rdf:ID=represents/>
</owl:inverseOf>
</owl:ObjectProperty>
Any SOA environment is intrinsically composed in a hierarchical fashion. In
other words, the elements of SOA systems can be repeatedly composed to ever
higher levels of abstraction. One aspect of this has already been addressed by
the uses and usedBy properties, since we can use these to express the notion
of systems of systems. This is still a very concrete relationship and does not
271

express the concept of architectural abstraction. We find the need for

architectural abstraction in various places such as a role representing the
people playing that role, an organizational unit representing the people within
it (subtly different from that same organizational unit using the people within
it, as the represents relationship indicates the organizational unit as a
substitute interaction point), an architectural building block representing an
underlying construct (for instance, important to enterprise architects wanting
to explicitly distinguish between constructs and building blocks) and an
Enterprise Service Bus (ESB) representing the services that are accessible
through it (for instance, relevant when explicitly modeling operational
interaction and dependencies). The concept of such an explicitly changing
viewpoint,
or
level
of
abstraction,
is
captured
by
the represents and representedBy properties illustrated in Figure 13.
Figure 14. Represents and representedBy properties

It is important to understand the exact nature of the distinction between using

an element (E1) and using another element (E2) that represents E1. If E1
changes, then anyone using E1 directly would experience a change, but
someone using E2 would not experience any change. When applying the
architectural abstraction via the represents property there are three
different architectural choices that can be made:
a) An element represents another element in a very literal way, simply by
hiding the existence of that element and any changes to it. There will be a
one-to-one relationship between the instance ofElement and the
(different) instance of Element that it represents. A simple real-world

272

example is the notion of a broker acting as an intermediary between a

seller (that does not wish to be known) and a buyer.
b) An element represents a particular aspect of another element. There
will be a many-to-one relationship between many instances
of Element (each of which represents a different aspect), and one
(different) instance of Element. A simple real-world example is the
notion that the same person can play (be represented by) many different
roles.
c) An element is an abstraction that can represent many other elements.
There will be a one-to-many relationship between one instance
of Element (as an abstraction) and many other instances ofElement. A
simple real-world example is the notion of an architectural blueprint
representing an abstraction of many different buildings being built
according to that blueprint.
Note that in most cases an instance of Element will represent only one kind
of an entity. Specifically, an instance of Element will typically represent
instances
of
at
most
one
of
the
following
classes
System,Service, HumanActor, and Task (with the exception of the case
where the same thing is both an instance of System and an instance
of Actor). Service, HumanActor, and Task classes are described in the
subsequent sections.
Expanding further on the organizational example, assume that a company
wants to form a new organizational unit O1. There are two ways of doing this:
Define the new organization directly as a collection of people P1, P2, P3,
and P4. This means that the new organization is a leaf in the
organizational hierarchy, and that any exchange of personnel means that
its definition needs to change.
o
Define the new organization as a higher-level organizational construct,
joining together two existing organizations O3 and O4. Coincidentally, O3
and O4 between them may have the same four people P1, P2, P3, and P4,
but the new organization isnt really aware of this. Any member of O3 or
O4 can be changed without needing to change the definition of the new
organization. Furthermore, any member of O3 is intrinsically not working
in the same organization as members of O4 (in fact, the organization need
not even be aware of them) contrary to the first option where P1, P2, P3,
and P4 are all colleagues in the same new organization.
o

273

The abstraction aspect of represents property introduces an important

difference in the semantics of the collection defining the new organization.
Any
instantiation
of
the
ontology
can
and
should
use
therepresents and representedBy properties to clearly define the implied
semantics and lines of visibility/change.
RYLC Example
RYLC chooses to organize its business into two organizational units one for
the rental operations and Vehicle Maintenance for delivering and servicing the
vehicles. This can be instantiated in the ontology in the following way:
o

o
o

o
o

o
o

RYLCOutlet,
RentalSystem and VehicleMaintenanceSystem are
of System

all

instances

Rentals is an element representing a RentalSystem

VehicleMaintenance is
an element representing
a VehicleMaintenance System
RYLCOutlet (uses/has organizational unit) Rentals
RYLCOutlet also
(uses/has
organizational
unit) VehicleMaintenance
Each Rental Agent is (used by/works for) RentalSystem
Each VehicleMaintenanceOperative is
(used
by/works
for) VehicleMaintenanceSystem
The OutletManager is an instance of Element and remains (used
by/manager of) RYLCOutlet

There are more details about the still evolving SOA Ontology standard with a
number of examples and diagrams that can be found in the standards
document. As we strive to automate finding, binding and interacting with local
as well as remote services, the role and responsibility of Ontology becomes
critical. It can attach semantics to services, so that both consumers and
providers can speak the same language and thus interact in more dynamic
ways. This presents a precursor for a semantic web where all systems and
collaboration partners can easy understand each other and seamlessly
integrate across disparate channels.

274

7. The Open Group Service Integration Maturity Model (OSIMM)

OSIMM is a model against which the degree of organizations service
integration maturity can be assessed. It describes a process for assessing the
current and desired degree of service integration maturity of an organization.
As organizations adopt SOA and increasingly use services as fundamental
architectural building blocks, they encounter the need to assess where they are
in their evolutionary path and how best to achieve the expected benefit
derived from attaining greater levels of SOA maturity. OSIMM helps
organizations create a roadmap to guide incremental transformation towards
higher levels of service integration maturity in order to measure progress
towards the goal, understand pace of transformation, and formalize the goal
state as well as the path towards it. OSIMM is used to determine which
organizational characteristics are desirable in order to attain a new level of
maturity. This will help determine whether problems occurring at the current
level of service integration maturity can be solved by evolving to a higher level.
OSIMM is offered to the industry as a standardized model to help
organizations guide their SOA transformation journey. A standard maturity
model enables enterprises to benchmark their SOA levels and develop
roadmaps for transformation to assist their planning. It can also be used by
vendors to position their services and software against these benchmarks.
OSIMM may also serve as a framework for the transformation process that
can be customized to suit specific needs of organizations. This process consists
of the following steps:
Prepare the OSIMM assessment framework
o
Determine the initial level of maturity
o
Determine the target level of maturity
o
Identify the transformation path necessary for the organization to
achieve the desired level of maturity
o

OSIMM structures the assessment of the organizations current state in

service integration and flexibility (including service orientation) and its
desired or future state for different lines of business or enterprise, taking into
account pain points in flexibility or integration that need to be improved. It
provides a model for assisting the organization in determining its
architectural strategy when adopting service-orientation including the
creation of an architectural roadmap for initiatives in legacy transformation,

275

integration with one or more packaged applications, application renovation

and development, and systems integration. This roadmap helps to determine
the scope, focus, and incremental steps for different parts of the organization
in order to transform them towards a higher level of service-orientation and
service integration, with justifications in terms of anticipated business
benefits.
OSIMM provides a framework for surfacing insights and identifying IT
improvements in terms of component development, service integration, SOA,
and IT governance. OSIMM focuses on increasing levels of flexibility in seven
aspects of an organization or enterprise business, organization and
governance, methods and processes, application portfolio, architecture,
information, infrastructure, and operational management. Focus on these
aspects helps achieve greater agility by planning integration in advance and
constructing business models, processes, applications, and infrastructure with
flexibility in mind.
The base model defines the OSIMM framework and the maturity assessment
process. The base model is designed to be extended by allowing customers and
consulting organizations add additional maturity indicators. By extending the
model, the maturity assessment can be focused on the adoption of evolving
industry frameworks, new techniques, or organizational imperatives.
OSIMM may be used to conduct assessments of the current and desired levels
of maturity for an enterprise or line of business (LoB) within an organization
and design a plan of action to transform from the current to the desired levels.
For example, an organization may wish to apply OSIMM to a particular set of
applications in the organizations portfolio. A decision is made to partition the
large number of applications into a small number of partitions based on
affinity to business function. The current state of each partition is then
assessed using the maturity model. Based on the pain points, business drivers,
and goals, the target state for each partition is established. The transformation
increment for each partition (which may be different for individual partitions)
is then defined in order to achieve the target state for that partition.
The Maturity Levels and Dimensions of SOA Integration
OSIMM has seven dimensions across seven maturity levels. Each maturity
level represents a significant increase in the level of maturity necessary to
realize service-orientation. This concept is referred to as service integration
276

maturity within OSIMM. OSIMM may also be utilized as an SOA maturity

model. While many SOA techniques and practices are used to realize
service-orientation, OSIMM is intentionally inclusive of new and evolving
techniques for implementing services such as cloud computing, REST, event
services, etc. The extensibility of the OSIMM framework is intended to provide
a method to augment the base OSIMM model to include such concepts. Figure
15 shows the OSIMM maturity matrix. Subsequent sections discuss each
element of the model in more detail.
Figure 15. OSIMM Maturity Matrix

The Maturity Matrix

The columns of the matrix correspond to the maturity levels, and the rows
correspond to the dimensions. Each cell in the matrix defines the maturity
level for each of the dimensions in each column. The overall SOA maturity of
an organization is assessed by identifying its maturity level in each dimension.
277

For example, consider the cell Information x Silo, with the label
Application-Specific Data Solution. Maturity attributes are mapped to the
maturity indicators within OSIMM. If the maturity attributes suggest that the
Silo level maturity indicators are present for a particular assessed application
or system then the maturity of the Information dimension is considered to be
Silo (Level 1). Thus, the assessed application or system is characterized as
having an Application-Specific Data Solution. Each dimension may be
assessed in a similar way, leading to a level assessment for each dimension or
business view, organization, etc. The overall picture in terms of the assessed
maturity level for each dimension may itself be assessed to provide a view of
the overall maturity level of the organization.
Maturity Levels
At the heart of OSIMM are seven levels of enterprise business and IT service
integration maturity. Each of the seven levels reflects a possible abstract state
of an organization in terms of its maturity in the integration of its services
(business and/or IT) and SOA solutions. Each maturity level builds on the
foundation of its predecessors and will have a cumulative set of maturity
attributes.
Level 1: Silo
Individual parts of the organization are developing their own software
independently with no integration of data, processes, standards, or
technologies. This severely limits the ability of the organization to implement
business processes that require cooperation between different organizational
silos. IT systems cannot be integrated without significant manual intervention,
such as re-keying and re-interpretation of data.
Level 2: Integrated
Technologies have been put in place to communicate between the silos and to
integrate data and applications. The construction of an IT system that
integrates across different parts of the organization becomes possible.
However, integration does not extend to common standards in data or
business processes. Therefore, to connect two systems, it requires a possibly
complex conversion of data, operations, and protocols used by these systems.
Each such connection may require bespoke code and adapters, leading to a

278

proliferation of software that is difficult to manage and complex to code. It is

therefore not easy to develop or automate new business processes.
Level 3: Componentized
The IT systems in the silos have been analyzed and broken down into
component parts, with a framework in which they can be developed into new
configurations and systems. There may also be some limited analysis done of
the business functionality that can be broken into separate components.
Although components interact through defined interfaces, they are not loosely
coupled, which limits agility and interoperability between different segments
of the organization (or even different organizations within the business
ecosystem). This causes difficulties in development and deployment of
shared business processes. Business and infrastructure components are
discrete and re-usable through code and EAI re-use techniques. However, they
are often replicated and redundant.
Level 4: Service
Composite applications are built from loosely-coupled services. The way that
services may be invoked is based upon open standards and is independent of
the underlying application technology. Services run on an IT infrastructure
that is supported by the appropriate protocols, security mechanisms, data
transformation, and service management capabilities. The services may
therefore interoperate across all of the parts of the organization and even
across different organizations within the ecosystem and are often managed by
assigning responsibilities for managing Service-Level Agreements (SLAs) to
segments of the organization. The business functionality has been analyzed in
detail and is broken down into services residing within a business architecture
that ensures that services will interoperate at the business level. In addition, it
is possible to define services via a specification language such as WSDL or
SCA that unambiguously defines the operations performed by the service
permitting the construction of a service catalog. The combination of IT and
service architectures permits the construction of systems based on these
services, operating across the organizations in the ecosystem. However, at this
stage, the composition of services and flow of control within a composite
application are still defined by developers writing custom code rather than by
a declarative flow language. This limits the ability of the development of new
business processes as services.

279

Level 5: Composite Services

At this level of service maturity, it is now possible to construct a business
process for a set of interacting services, not just by custom development but by
the use of a composition or business process modeling language. Composite
services include static, process, and activity-based services. This allows
services to be assembled into composite business processes without
significant construction of code. Thus, the design and development of services
are agile and may be performed by developers under the close guidance of
business analysts.
Level 6: Virtualized Services
The business and IT services are now provided through a faade a level of
indirection. The service consumer does not invoke the service directly but
through the invocation of a virtual service. The infrastructure performs the
work of converting the virtual invocation into a physical call of the real service
and may, as part of this conversion, change the address, network, protocol,
data, and synchronization pattern that are contained in the call. Such
conversions may be a complex service in its own right, such as the
transformation of data from one data model to another. The virtual service
thereby becomes more loosely coupled from the infrastructure on which it is
running permitting more opportunities for the composition of services. This is
in contrast to the lower levels of service maturity, where the service is more
closely coupled to the infrastructure. Although virtualization has been used in
non-SOA systems, this level extends the concept (and advantages) of
virtualization to services.
Level 7: Dynamically Re-Configurable Services
Prior to this level, the business process assembly, although agile, has been
performed at design time by developers (under the guidance of business
analysts and product managers) using suitable tooling. Now, this assembly
may be performed at runtime, either assisted by the business analysts via
suitable tooling or by the system itself. This requires the ability to access a
repository of services and to query this repository by specifying the
characteristics of the required services. In its simplest form, these
characteristics may have been defined in advance, restricting the system to
selecting and locating specific instances of services.

280

Dimensions
An organizations level of SOA maturity can be assessed across the following
set of dimensions, which are essential indicators for effective SOA adoption.
Business
The Business dimension is focused on the business architecture,
organizations current business practices and policies, as well as design,
structure, implementation, and execution of business processes. The Business
dimension addresses how the cost of IT capabilities is allocated across the
enterprise, and how well the IT capabilities support the flexibility of the
business, operations, and SLAs. The Business dimension includes IT strategy
and thus includes the necessary value proposition for moving from one
maturity level to a higher maturity level.
Organization & Governance
The Organization & Governance dimension is focused on the structure and
design of the organization itself and the necessary measures of organizational
effectiveness in the context of SOA and SOA governance. The Organization
aspect is focused on organizational structure, relationships, roles, and the
empowerment necessary to adopt a service-oriented strategy. This includes
the types and extent of skills, training, and education that are available within
the organization. Governance is associated with formal management
processes to keep IT activities, service capabilities, and SOA solutions aligned
with the needs of the business. Governance guides many aspects of the other
maturity dimensions including how management is structured and costs are
allocated.
Method
The Method dimension is focused on the methods and processes employed by
the organization for its IT and business transformation and the organizations
maturity around the Software Development Lifecycle such as the use of
requirements management, estimation techniques, project management,
quality assurance processes, design methodologies and techniques, and tools
for designing solutions.
Application

281

The Application dimension is focused on application development style,

structure of IT applications, their functional decomposition, re-usability,
flexibility, reliability, and extensibility of the current applications,
understanding and uniform use of best practices and patterns, duplication of
functionality across multiple applications, and the availability of enterprise
schema and object models.
Architecture
The Architecture dimension is focused on the structure of the architecture
including topology, integration techniques, enterprise architecture decisions,
standards and policies, web services adoption level, experience in SOA
implementation, SOA compliance criteria, and typical artifacts produced.
Information
The Information dimension is focused on how information is structured and
modeled, the method of enterprise data access, abstraction of data access from
its functional use, data characteristics, data transformation capabilities,
service and process definitions, handling of identifiers, security credentials,
knowledge management, business information models, and content
management.
Infrastructure & Management
The Infrastructure & Management dimension is focused on the organizations
infrastructure capability, service management, IT operations, IT management,
IT administration, adherence to SLAs, monitoring, and availability of
integration platforms.
OSIMM, as any other maturity model, can help organizations assess the
current state and create a path towards the goal state. This framework is
largely focused on maturity around integration and business processes. If
organizations are interested in measuring its maturity across different
dimensions and maturity characteristics, the framework can be easily
extended to include those.
8. SOA Governance Framework
SOA has heightened the need and importance of having a formal SOA
governance program that sets expectations and eases the transition of an

282

organization to SOA by providing a means to reduce risk, maintain business

alignment, and show business value of SOA investments through a
combination of people, process, and technology. The role of the SOA
Governance program is to create a consistent approach across processes,
standards, policies and guidelines while putting compliance mechanisms in
place. Most organizations already have an IT governance program in place
covering project funding, development, and maintenance activities and
primarily concentrating on change and release management disciplines. These
tend to have been defined using either one of the formal standard IT
governance frameworks such as COBIT, ITIL or an informal in-house
governance framework that has been built over the years.
The Open Groups SOA Governance Framework Technical Standard consists
of SOA Governance Reference Model and SOA Governance Vitality Method.
Both are described in more detail below. The relationships between all the
components of the SOA Governance Framework are captured in Figure 16.
Figure 16. The Open Groups SOA Governance Framework
Technical Standard

The SOA Governance Reference Model (SGRM) is a generic model that

establishes a foundation of understanding and is utilized to expedite the
process of tailoring the SOA Governance program for an organization. All
283

aspects of the SGRM should be reviewed and considered for customization to

address each organizations specific environments. The SGRM defines a
number of constituent parts, including:
o
o
o
o
o
o

SOA Governance Guiding Principles

SOA Governing Processes
Governed SOA Processes
SOA Governance Process Artifacts
SOA Governance Roles and Responsibilities
SOA Governance Technology

Through its framework, SGRM creates a foundation for organizations to

establish their own SOA governance programs. While it is comprehensive, it
should only be treated as a framework, something that will accelerate creating
and establishing a working and successful SOA governance program. No
organization is the same. Therefore, each part of SGRM should be considered
for customization.
The SOA Governance Vitality Method (SGVM) is a process that utilizes the
SGRM as a baseline and follows a number of phased activities to customize
this baseline model to fit into the organizations environment. SOA
Governance should be viewed as a process and not a project. Therefore,
phases of SGVM should be viewed as a continuous improvement loop,
whereby progress is measured, and course correction and updates to the SOA
Governance regimen and SOA Governance roadmap are performed when
needed. The Four Phases of SGVM are depicted in the Figure 17.
Figure 17. Four phases of the SOA Governance Vitality Method

284

These phases are:

Plan Identify and analyze the core governance areas for
improvement. Establish objectives/plan and specific measures for a
proposed increment. Previously deployed increments are also evaluated
for any necessary improvement.
o
Define Define the SOA Governance Model transition plans required
to deliver the objectives defined in the Plan phase.
o
Implement Implement the transition plans including deployment
of processes, organization and technology aspects of the SOA Governance
Model.
o
Monitor Monitor the effectiveness of the currently deployed SOA
Governance Regimen and whether it is meeting its intended purpose.
This phase may start another iteration of the SGVM.
o

SOA governance framework is a critical element in the SOA lifecycle. It is

necessary to guarantee the success of the SOA program, attainment of
business and IT related benefits, and continual movement of the SOA
program in the right direction. The Open Groups SOA Governance
Framework Technical Standard provides a great starting point for
organizations to establish and execute their own SOA program.
9. A Holistic View of SOA Standards
Today, when businesses are executing SOA projects, they generally strive to
achieve compliance of their business process, information, and message
models with established industry standards. This becomes problematic when
there are competing standards and they have a high rate of change.
To meet this challenge, the authors of A Holistic View of Industry Standards
across SOA Solution Stack[6] describe a new approach that provides a
holistic view of these heterogeneous SOA models and corresponding industry
standards. Such a unified view must provide access to heterogeneous data
sources and models, allow them to be searchable as a single source across the
SOA Solution Stack (S3), and provide advanced services such as traceability,
scoping, and impact analysis. To validate the proposed holistic approach, the
authors have described a model catalog and repository system and present its
use on a field-based example. A holistic view enables ubiquitous access to
the models along with the option to search, browse, trace, scope, and execute
impact analysis. Mapping industry models to all other models in the SOA

285

solution stack (e.g., use case models, component business models, business
processes, service models, etc.) helps us better understand and follow
standards. It also serves as a platform for gap analysis. In short, this view
allows us to check whether all services required by the standards exist and
that there are no overlapping services. To implement such a view, a mapping
management system, referred to as the Mappings Catalog and Repository
System (MCRS), could be implemented. The authors have identified three
main needs for a holistic view of industry standards in the SOA solution stack,
based on the pain points of the user community dealing with these artifacts:
1) Enterprise Level
Managing a number of distinct models in the SOA era is a challenging
task. Typically, enterprises that adopt SOA have a significant amount of
enterprise level models that are historically tightly coupled. However,
SOA transformation makes these models more reusable and loosely
coupled, thus increasing the number of relationships created. Examples
of such models are business process models, governance models,
information models, service models, application maps, etc. The need to
have a holistic perspective of the models used in a service-oriented
enterprise (SOE) and then be able to focus on a specific area is inevitable.
2) SOA Project Lifecycle
One of the first tasks in a new SOA project is the identification of reusable
components and models such as service components or service
definitions created in previous projects. Unfortunately, models are
usually stored in disperse model repositories and formats. Serious efforts
are therefore required to discover these models. New projects also involve
a large number of new services and models created during different
project iterations. As such, users are looking for associations between the
projects models and industry standards. On top of all these needs, the
users main concern is the ability to trace changes in models, services, and
standards. Common questions include what does this requirement
affect, what will happen if we change this service definition, etc. Users
need to understand which artifacts in the solution stack are affected.
3) Tooling
Different models originating in a typical SOA project use different tools
that are stored in different formats. In each tool one can only see a

286

segment of the models, thus clouding the broad view of industry

standards across the SOA solution stack.
A Mappings Catalog and Repository System (MCRS) allows users to
store metadata about data sources and models, identify and trace models,
create relationships among their elements, and provide a query mechanism to
search for models and mappings. Moreover, MCRS offers semantic mapping,
gap analysis, scoping, and impact analysis capabilities for the SOA solution
stack and industry models. In this section, you can find the description of the
main services required from an MCRS to provide a holistic view of the
industry models in the SOA solution stack.
Mappings Catalog
This is one of the main services required is the cataloging of model elements.
A catalog is an inventory of models, with the most fundamental information
about each. A fine-grained representation, in which models are decomposed
into basic model elements and relationships (a.k.a. model shredding), is
recommended. Each shredded model element is associated with metadata
(eTag, author, etc.) and indexed. The indexing enables a unified view of the
modeling data used by the search and browse capabilities. The fine grained
representation allows users to effectively prune the model into consumable
pieces. The catalog offers keyword search over any models in any source, with
no setup time. In addition, it supports an interface to browse a number of SOA
solution stack models.
Semantic Mappings
Semantic mapping is a mandatory element in achieving a holistic view of
industry standards across the SOA solution stack. Semantic mapping enables
the interoperability of different heterogeneous systems by creating
relationships across different SOA models. The relationships between model
elements can be:
1. Defined by a model author or an industry standards body
2. Explicit links or mappings that are generated as a result of
transformation or model decomposition
3. Manually entered by a human with encoded semantics
4. Inferred from a change request or any other user action, user feedback,
etc.
287

5. Inferred based on semantics.

Relationships between model elements in the SOA solution stack exist
between elements of the same model (intra-model) and elements of different
models (inter-model). We can also consider external relationships for models
and model elements such as hyperlinks to physical occurrences of the SOA
solution stack artifacts, including wikis, asset repositories, web sites, standard
organizations, databases, documents, etc.
An MCRS system offers subject matter experts the ability to add, remove, or
alter relationships. However, the manual mapping of models and elements is
an overhead. In MCRS, automatic discovery of relationships and different
approaches to inference of mappings are based on relationship semantics.
Models, service definitions, and their mappings evolve, and changes occur too
often to deal manually with the semantics of relationships. Therefore,
semantics are encoded into the relationships themselves. Taxonomies and
ontologies are used for this purpose. Since these easily break down in evolving
SOA systems and new concepts are constantly introduced, the taxonomies are
used where classification schemes are permanent. Ontologies have the benefit
of being resilient to change and are used to capture alternative views and
terms for the same ideas. Ontologies change mapping definitions with
semantics and allow identification of appropriate mappings when required.
Encoded semantics enable search and validation of mappings. Together with
vertical industry models, ontologies allow semantic interoperability within the
SOA solution stack.
Orientation
Although search and browse are the bread and butter of an MCRS system,
more advanced services are needed to enable orientation in an SOA
multi-model environment. The user must be able to efficiently control the
information availability and harvest it when needed. A typical MCRS system
should offer the following capabilities:
1. Search and query search models and query by specific attributes
2. Traceability ability to trace changes across the models
3. Scoping define scope of search
Publish and Retrieve

288

Users often prefer to use their native tools in conjunction with the MCRS
system. Moreover, after using the MCRS scoping service to decide what their
focus will be, users like to continue work in their native environment. To meet
this need, the MCRS system exposes interfaces for several modeling tools in
which the user can:
1. Publish models to MCRS
2. Retrieve models from the MCRS by working with the results of a
scoping procedure that constructs the scoped (sub-set) models
3. Execute simple queries to retrieve additional models.
This tool-supported model enables users to more precisely and efficiently
determine what standards to use. This approach can enable a more holistic
view of the SOA standards, better understanding of relationships between
them, and greater level of standards adoption.
Conclusion
With SOA moving to the mainstream, different standards bodies established a
number of SOA-specific standards. As a result, industry-specific and generic
standards were introduced. With the emergence of a myriad of standards,
there is a possibility for potential overlaps and misinterpretations. To combat
this, several authors have taken up the task of bringing clarity and intuition
via holistic approaches and models, so that users could confidently consider,
select and use the most appropriate and relevant standards for their SOA
efforts.
Competent and correct standards enable SOA initiatives to be successful. This
chapter is written to help the SOA community to navigate the myriad of
overlapping specifications. Fortunately, there is a great deal of agreement on
the foundational core concepts across the many independent and open
standards for SOA. This could be explained by similar experiences and hurdles
companies face when implementing SOA, SOA governance, and SOA maturity
models. It is generally accepted that investing in SOA enablement and IT
transformation initiatives that incorporate and use these standards helps
mitigate risks that might compromise success of an SOA solution.
The specifications and standards described in this document can be used
together in many complementary ways. An excellent example is incorporating
the use of modeling techniques into an SOA project by using SoaML in concert
289

with an SOA Reference Architecture. In addition, the SOA reference models,

ontology, and reference architectures can be used as input to requests for
proposals (RFPs) that extend SoaML with additional modeling capabilities.
SOA Governance Framework can be greatly complemented by the use of the
SOA Maturity Model.
Users of the standards have to fully understand the strengths and weaknesses
of each of the standards and choose the best one. The primary goal should be
to maximize benefits of applying standards and deliver the most value to the
organization. Standards can be very helpful in achieving positive results in a
short period of time.
References
1. Pamela K. Isom, The Importance of Standards for Cloud Architecture
The Open Group, 2010
2. Brian Elvester, Arne-Jrgen Berre & Andrey Sadovykh, Specifying
Services Using the Service Oriented Architecture Modeling Language
(SOAML): A baseline for Specification of Cloud-based Services,2011
3. SOA Reference Architecture, Technical Standard, OASIS, 2009
4. Brian Elvester, Dima Panfilenko, Sven Jacobi & Christian Hahn,
Aligning Business and IT Models in Service-Oriented Architectures
using BPMN and SoaML, MDI2010, October 5, 2010, Oslo, Norway
5. Andrey Sadovykh, Brian Elvester & Einar Landre, Enterprise
Architecture Modeling with SoaML using BMM and BPMN MDA
Approach in Practice, 2010
6. Natalia Razinkov et al., A Holistic View of Industry Standards Across
SOA Solution Stack IEEE International Conference on Services
Computing, 2009
7. Service-Oriented Architecture Ontology, Technical Standard, The
Open Group, 2010.
8. Heather Kreger & Jeff Estefan, Navigating the SOA Open Standards
Landscape Around Architecture, 2009
9. Qiang Wang, Ying Chun Guo, Min Li, Xiao Feng Zhao, ACORD
Standards based SOA Solution for Insurance Industry Combine ACORD
eForms with Business Services through XForms Standard, IEEE
International Conference on e-Business Engineering, 2008

290

10. SOA Maturity Assessment Guiding the SOA Roadmap, An White

Paper by TMNS, 2009
11. JiuCheng Xu, ZhaoYang Bai, Arne J. Berre, & Odd Christer Brovig,
Model Driven Interoperability through Semantic Annotations using
SoaML and ODM, 2010
12. SOA Governance Framework, Technical Standard, The Open Group,
2009
13. The Open Group Service Integration Maturity Model (OSIMM),
Technical Standard, The Open Group, 2009
14. Service oriented architecture Modeling Language (SoaML)
Specification for the UML Profile and Metamodel for Services (UPMS),
OMG, 2009

SOA Industry Standards

The OASIS Reference Model for SOA (SOA RM) is the most abstract of
the specifications positioned. It is used for understanding of core SOA
concepts.
o
The Open Group SOA Ontology extends, refines, and formalizes some
of the core concepts of the SOA RM. It is used for understanding of core
SOA concepts and facilitates a model-driven approach to SOA
development.
o
The OASIS Reference Architecture for SOA Foundation is an abstract,
foundation reference architecture addressing the ecosystem viewpoint for
building and interacting within the SOA paradigm. It is used for
understanding different elements of SOA, the completeness of SOA
architectures
and
implementations,
and
considerations
for
cross-ownership boundaries where there is no single authoritative entity
for SOA and SOA governance.
o
The Open Group SOA Reference Architecture is a layered architecture
from the consumer and provider perspective with cross-cutting concerns
describing these architectural building blocks and principles that support
the realizations of SOA. It is used for understanding the different
elements of SOA, deployment of SOA in the enterprise, basis for an
industry or organizational reference architecture, implication of
architectural decisions, and positioning of vendor products in SOA
context.
o

291

The Open Group SOA Governance Framework is a governance domain

reference model and method. It is for understanding SOA governance in
organizations. The OASIS Reference Architecture for SOA Foundation
contains an abstract discussion of governance principles as applied to
SOA with particular application to governance across boundaries.
o
The Open Group SOA Integration Maturity Model (OSIMM) is a means
to assess an organizations maturity within a broad SOA spectrum and
define a roadmap for incremental adoption. It is used for understanding
the level of SOA maturity in an organization.
o
The Object Management Group (OMG) SoaML Specification supports
services modeling UML extensions. It can be seen as an instantiation of a
subset of The Open Group SOA Reference Architecture used for
representing SOA artifacts in UML.
o

292

A. Case Study Conclusion [This content is currently in

development.]
This content is currently in development.

293

B.

The

SOA

Manifesto

[This

content

is

currently

in

development.]
This content is currently in development.

294

C. SOA Principles Reference [This content is currently in

development.]
This content is currently in development.

295

D. SOA Patterns Reference [This content is currently in

development.]
This content is currently in development.

296

E. SOA Governance Reference [This content is currently in

development.]
This content is currently in development.

297