SOA terminology overview, Part 1: Service,

architecture, governance, and business terms

Level: Introductory

Bertrand Portier (bportier@ca.ibm.com), IT Architect, IBM

Learn some basic SOA terminology in this first part of a series. Bertrand Portier defines terms including
service, architecture, Service-oriented architecture, governance, and business process -- and explains why
they are fundamental to the success of SOA. He also introduces key graphics from the IBM SOA foundation.

Introduction

Semantics are essential in any domain and especially in Service-oriented architecture (SOA). Since SOA
spans teams and organizations, agreement upon relevant terms is crucial. This series provides a tour of SOA
by defining terms and the key concepts behind them. You will learn the vocabulary necessary to
communicate in the SOA field. For each term, you will understand why it is important for SOA, what it
means in this context, what the relevant standards are, and how the term differs from others.

A note about organization

The terms listed below are not organized alphabetically, nor are they shown in order of importance. Rather,
they are organized in a building-block fashion. We begin with "service", as it is probably the most
fundamental concept for an understanding of the SOA framework. We build upon service with definitions of
"architecture", "governance", and "business" concepts. In many cases we've broken down the larger terms
into their components.

Service

Services are obviously at the heart of Service-oriented architecture, and the term service is widely used.
However, it means different things to different people and the question "What is a service?" often leads to
long arguments. I have heard people talk about business tasks, business services, application functions,
technology services, or infrastructure services. Let me give you a definition, based on the IBM Rational®
Method Composer Plug-in for SOA Governance and the IBM Rational® Unified Process for Service-Oriented
Architecture. Please see the Resources section for more information).

"A service is a discoverable resource that executes a repeatable task, and is described by an externalized
service specification."

It is a difficult task to start this article by defining "service" because of the variety of definitions it elicits.
For example, you may find the above definition too technical. Please bear in mind that it is important not
to rely too much on a formal definition of a service, but rather focus on the key concepts behind services,
including:

• Business alignment: Services are not based on IT capabilities, but on what the business needs.
Services business alignment is supported by service analysis and design techniques.
• Specifications: Services are self-contained and described in terms of interfaces, operations,
semantics, dynamic behaviors, policies, and qualities of service.
• Reusability: Services reusability is supported by services granularity design decisions.
• Agreements: Services agreements are between entities, namely services providers and consumers.
These agreements are based on services specification and not implementation.
 • Hosting and discoverability: As they go through their life cycle, services are hosted and
discoverable, as supported by services metadata, registries and repositories.
• Aggregation: Loosely-coupled services are aggregated into intra- or inter-enterprise business
processes or composite applications.

These combined characteristics show that SOA is not just about "technology", but also about business
requirements and needs.

It is also important to note that not everything is a service. For example, there are IT functions that should
not be exposed as services. Analysis techniques such as IBM's Service-Oriented Modeling and Architecture
(SOMA) exist to identify the list of appropriate services based on the concepts listed above. We will cover
these aspects (including all of the bold terms in this section) in detail in the course of this article.

Architecture

Like services, it is difficult to find an agreed-upon definition of architecture. However, unlike services,
architecture is sometimes forgotten when people talk about SOA, and it clearly should not be! In fact,
enterprise architecture and Service-Oriented Architecture share common goals around supporting the
business with an integrated IT strategy. Enterprise architects, for example, are key to the success of SOA,
as they look at the strategic evolution of an enterprise’s IT systems based on evolving business needs and
demands.

The Open Group Architecture Forum (TOGAF) provides two definitions for architecture, based on context:

1. "A formal description of a system, or a detailed plan of the system at component level to guide its
implementation.
2. The structure of components, their interrelationships, and the principles and guidelines governing
their design and evolution over time."

These two definitions are relevant to understanding the "A" of SOA. Breaking it down even further, we find
that architecture is necessary to do the following:

• Design and model at different levels of abstractions

• Separate specification from implementation
• Build flexible systems
• Make sure business requirements are addressed
• Analyze the impact of a change in requirements
• Ensure principles are followed

Enterprise architecture

Here is the definition from Wikipedia:

"Enterprise architecture is the practice of applying a comprehensive and rigorous method for describing a
current and/or future structure and behavior for an organization's processes, information systems,
personnel and organizational sub-units, so that they align with the organization's core goals and strategic
direction.

The primary purpose of creating an enterprise architecture is to ensure that business strategy and IT
investments are aligned. As such, enterprise architecture allows traceability from the business strategy
down to the underlying technology."

You may think of "architecture" at the project-level, and "enterprise architecture" at the organization level.
Note the reference to processes, information systems, personnel, goals, strategy, and business IT
alignment.
Service-Oriented Architecture
Service Orientation

As described in the IBM SOA foundation white paper, "... service orientation is a way of integrating a
business as a set of linked services." Please see Resources to learn more about IBM’s SOA foundation.

A key word here is "business". For example, service orientation provides the flexibility of implementing
business processes with services from one line of business (LOB), across LOBs, and with business partners.

SOA foundation reference model

The IBM SOA foundation includes an SOA reference model, as in in Figure 1, which shows the key capabilities
equired to support Service-Oriented Architecture.

Because this model is itself based on service orientation, it allows for the incremental adoption of SOA as
new business requirements arise, starting from small projects, and gradually broadening integration across
the enterprise. Please refer to the Resources section for links to more information on the SOA foundation.

Figure 1. The SOA foundation reference model

Service-Oriented Architecture

SOA is defined by IBM's SOA foundation as follows:

"Service-Oriented Architecture (SOA) is an architectural style for creating an enterprise IT architecture

that exploits the principles of service-orientation to achieve a tighter relationship between the business
and the information systems that support the business."

SOA has the following characteristics:

• It enhances the relationship between enterprise architecture and the business.

 • It allows the building of composite applications as a set of integrated services.
• It provides flexible business processes.

Service-Oriented Architecture implies new roles in the enterprise, new ways of collaborating, new
supporting frameworks and new types of software artifacts in an evolutionary (as opposed to a
"revolutionary") way.

SOA solution stack

The SOA solution stack, shown in Figure 2, is an SOA reference model depicting the conceptual (high level of
abstraction) view of an SOA solution.

Sometimes referred to as "the SOA layered architecture", this model introduces layers and concepts such as
business process, service, or service component, as well as the relationships between them.

It is independent of the technology used for implementation. This separation is important, as you will see in
the Model-Driven Architecture (MDA) section in Part 2 of this series.

Figure 2. The SOA solution stack

The five functional layers are as follows (bottom to top):

• Operational systems: Represents existing IT assets, and shows that IT investments are valuable and
should be leveraged in an SOA.
• Service components: Realize services, possibly by using one or more applications in the operational
systems layer. As you can see on the model, consumers and business processes do not have direct
access to components, but just services. Existing components can be internally reused, or leveraged
in an SOA if appropriate.
• Services: Represents the services that have been deployed to the environment. These services are
governed discoverable entities.
• Business Process: Represents the operational artifacts that implement business processes as
choreographies of services.
• Consumers: Represents the channels that are used to access business processes, services, and
applications.

The four nonfunctional layers are (left to right):

 • Integration: Provides the capability to mediate, route, and transport service requests to the correct
service provider.
• Quality of service: Provides the capability to address the nonfunctional requirements of an SOA (for
example, reliability and availability).
• Information architecture: Provides the capability to support data, metadata, and business
intelligence.
• Governance: Provides the capability to support business operational life cycle management in SOA.

Refer to the "Design an SOA solution using a reference architecture" article for a more detailed explanation
of the SOA solution stack.

Governance

Governance is necessary for the successful adoption of SOA partly because of the cross-organizational
nature of SOA where service funders, designers, implementers, maintainers, or consumers are not located in
the same organization, business, IT department, LOB, division, or enterprise.

This section contains definitions from the IBM Rational Method Composer Plug-in for SOA Governance. It
defines governance, IT governance, SOA governance, and the difference to management or compliance. It
also describes the challenges addressed by SOA governance. Please see the Resources section for links to
more information on Rational Method Composer.

Governance

"Governance is about:

• Establishing chains of responsibility, authority, and communication to empower people (decision

rights)
• Establishing measurement, policy, and control mechanisms to enable people to carry out their
roles and responsibilities

Governance looks at assigning the rights to make decisions, and deciding what measures to use and what
policies to follow to make those decisions. The decision rights are assigned to roles, not to individuals.
Management, on the other hand, includes assigning staff to the roles and monitoring the execution of
policies.

Part of any governance solution is meeting the organization's compliance requirements. Compliance is
documenting and proving that governance is in place and is being executed: decisions are documented and
decision policies are followed."

IT governance

"IT governance refers to the aspects of governance that pertains to an organization's information
technology processes and the way those processes support the goals of the business."

IT governance may be characterized by assigning decision rights and measures to IT processes.

SOA governance

"SOA governance is an extension of IT governance specifically focused on services and other SOA artifacts'
lifecycle."

Specifically, SOA governance focuses on the methods and processes around service identification, funding,
ownership, design, implementation, deployment, reuse, discovery, access, monitoring, management, and
retirement.
"SOA governance addresses challenges such as:

• What new organizational roles and structures facilitate service identification, design, and sharing?
• What metrics support investment, maintenance, vitality, and sharing of services?
• How do businesses decide to invest in service creation and maintenance?
• What is an enterprise’s service-orientation maturity?
• What education, training, or mentoring is required?"

Life cycle

Service life cycle

Service life cycle comprises the states services may be in and the events that trigger transitions between
these states.

Through their lives, services go through many stages or phases (like us ;-) ). Think of a service's life cycle as
a business state machine with states (positions) in which services can exist, and transitions that make them
evolve from one state to another.

SOA governance is about planning, defining, enabling, and measuring around the service life cycle. SOA
governance defines what the service states are, what actions need to happen to move from state to state
(transitions), how (processes and methods), and by whom (roles, guards).

For example, SOA governance can define that services states are identified, funded, specified,
implemented, approved, operational, published, deprecated, and retired.

The underlying SOA framework then needs to support services through their life cycles and make sure the
processes in place are followed. For example, service registries and repositories need to allow users to take
action so that services evolve through their life cycle. Collaboration and portfolio management tools need
to allow users (and just those who have the rights) to make decisions that will move services from one state
to another, and notify users that need to take action.

SOA life cycle

The IBM SOA foundation uses four phases in its definition of the SOA life cycle:

• Model includes business analysis and design (requirements, processes, goals, key performance
indicators) and IT analysis and design (service identification and specification).
• Assemble includes service implementation and the building of composite applications.
• Deploy includes application deployment and runtimes such as Enterprise Service Buses (ESB).
• Manage includes the maintenance of the operating environment, service performance monitoring,
and service policy enforcement.

SOA governance and processes , as defined above, underpins these four phases. This is displayed in Figure 3.
 Figure 3. The SOA life cycle

Business

Businesses nowadays need to be able to recognize change and react to it quickly while maintaining their
ecosystem of employees, partners, customers. Technology needs to be fully leveraged in order to achieve
this, as described by IBM On Demand Business . Please see the Resources section for information about IBM
On Demand Business.

Because of external demands such as customers and regulatory compliance, and changes such as
competition and markets, businesses have to be flexible and agile. Service-Oriented Architecture helps
achieve this and allows businesses to quickly adapt to change.

Business alignment

Key to the success of SOA is the reuse of existing IT assets such as legacy applications. SOA, however, allows
businesses to focus their technology efforts on services that will support their business capabilities or
processes -- for example, service operations can correspond to business tasks -- as opposed to services
based on siloed information systems. This business alignment provides better convergence and easier
communication between business and IT. In a later part of this series we’ll cover top-down, bottom-up, and
meet-in-the-middle approaches to SOA analysis and design to understand how business models can be
refined into IT models, and how key existing functionality can be leveraged.

Being business aligned, however, doesn’t mean having business capabilities and IT implementations tightly
coupled. One of the key SOA concepts is loose coupling and the separation between specification (business
model, interface) and implementation (technology), which allows for the impact of a change, such as
replacing a service provider, for example, to be minimized.

Business componentization

IBM Component Business Model® is a strategic method that allows businesses to focus on core competencies
-- the parts of the business that differentiate them from their competitors, see how resources are
consumed, and better align business and IT. Please see the Resources section for more information on the
Component Business Model. The integration of these business components’ interaction as well as flexibility,
such as outsourcing a component, is needed and achieved with service orientation: business components
have a unique business purpose and collaborate through a set of business services they provide to or
consume from other components. This can be seen as being part of the "business architecture".

Business modeling

Business Modeling is defined by IBM Rational Unified Process® as follows:

"The Rational Unified Process Business Modeling discipline provides specific guidance on how to describe
the "as-is" or the "to-be" business using a number of approaches and techniques at different levels of
formality."

Business modeling introduces concepts, deliverables, and roles; it describes and organizes tasks around
business strategy, business vision, business objectives, business goals, business vocabulary, business
architecture, business analysis and design, business rules, business value, business use cases, business
entities, and business processes. The next section offers more details.

SOA is a long-term strategy about reorganizing business and IT systems in order to be able to quickly react
to changes. The Resources section has a link to the IBM Systems journal, volume 44, number 4, on SOA,
which offers a more detailed view on the business aspects of service-oriented thinking.

Business process

A business process consists of a sequence of activities that produces a valuable result.

A business process has related business items (data) that flow through it, including those used as the
process’ input and output.

Business activities and tasks

Business activities and tasks are the elements that, when connected, make up a business processes.

You can associate duration, cost, revenue, resources, input and output to business activities. They are the
elements used to decompose business processes. Service identification techniques include the
decomposition of business processes into activities and tasks from which existing or to-be-developed
services (and their operations) are identified. These services are sometimes referred to as "business"
services.

Modeling business processes

An organization's business processes (current, "as-is") can be complex because they are often the result of a
significant number of changes to the process that was originally defined. Understanding, formally defining,
and documenting business processes is critical. Also, modeling and simulating "as-is" and "to-be" (future)
business processes will allow for the identification of costs, delays, or areas for automation.

Modeling business processes not only provides a visual representation, but when done within a framework
that provides underlying metadata, which we’ll cover in Part 2 of this series, it allows for elements of the
business process model to later be refined into or linked to IT design elements.

Human tasks

Quite often, human interactions are needed in the course of a process (e.g., travel approval or loan
approval). During business process modeling, a task is identified as manual, and different roles are assigned
to each of these human tasks. When deployed, the SOA environment will then need to support human tasks
as part of the execution of a process. For example, products like IBM WebSphere Process Server will provide
users with a list of human tasks awaiting their action. Combined with this, collaboration products like IBM
WebSphere Portal and Lotus Sametime will also allow users to collaborate with colleagues if needed, and
notify the system of their decision so that execution of the process can carry on. This human aspect is
critical to the success of SOA.

BPEL
IBM, Microsoft and others have contributed to the Business Process Execution Language (BPEL) for Web
services specification as a means to formally specify business processes and interaction protocols.

Version 1.1 was published in May 2003, and an OASIS committed draft has been published for version 2.0,
now called Web Services Business Process Execution Language WSBPEL. Please see the Resources section for
a link.

Industries

Business processes can be specific to a domain or industry, such as an insurance claim process. Industry
consortiums define industry business processes. For example, the TeleManagement Forum defines the
enhanced Telecom Operations Map (eTOM) for the telecom industry. In addition to these, enterprises can
differentiate themselves from their competitors by internally adopting proven business processes like the
ones from the IBM Industry Models. Please see the Resources section for a link to the IBM Insurance
Application Architecture (IAA), which is one of the IBM Industry Models.

Business Process Management

Business Process Management (BPM) looks at the full life cycle of business processes to improve their
efficiency, flexibility and control.

BPM is about modeling, simulating, optimizing, deploying, running, managing and monitoring business
processes before feeding the results back to improve the models and to follow a continuous improvement
cycle. IBM WebSphere provides a variety of products needed around BPM.

Conclusion

In this article, Part 1 of the SOA terminology series, we defined the core SOA terms, namely Service, SOA,
and how SOA relates to Architecture. We defined two terms, Service Life cycle, and SOA Governance, which
are core elements of SOA. Finally,we talked about the relationship between SOA and the Business, and
described Business Processes. This is just the beginning. Following parts of the series will define SOA terms
related to IT design, development, runtime, and management. So stay tuned to developerWorks!
 SOA terminology overview, Part 2: Development
processes, models, and assets

Level: Introductory

Bertrand Portier (bportier@ca.ibm.com), IT Architect, IBM, Intel, Microsoft,HP

05 Apr 2007

Learn some basic SOA terminology. In this second part of the series, Bertrand Portier defines terms
including development processes, models, and assets -- and explains why they are fundamental to the
success of SOA. He also introduces key standards in this area.

Introduction

Semantics are essential in any domain and especially in Service-oriented architecture (SOA). Since SOA
spans teams and organizations, agreement upon relevant terms is crucial. This series provides a tour of SOA
by defining terms and the key concepts behind them. You will learn the vocabulary necessary to
communicate in the SOA field. For each term, you will understand why it is important for SOA, what it
means in this context, what the relevant standards are, and how the term differs from others.

Part 1 in the series has a business focus and sets the stage by defining terms such as service and SOA. This
article presents the software engineering methods and processes needed for successful SOA adoption, as
well as the artifacts needed to deliver SOA solutions, such as models and assets.

Development processes and methods

Successful software development requires:

• Principles to be understood and followed.

• Formally described methods and techniques based on proven best practices.
• Processes that can be tailored.

Method content

Method content describes what needs to be produced, how the work is performed, and by whom.

Method content artifacts include:

• Roles: Defined skills and work product responsibilities. Software Architect is an example of a role.

• Work products: Results of tasks, whether deliverables or not. Service Model is an example of a
work product.

• Tasks: The sequence of steps that specific roles perform. Tasks use input work products to produce
or modify output work products. Identify Services is an example of a task.

• Guidance: Documentation. Glossaries, templates, examples, and tool mentors are examples of
guidance.
Process

A process is used to organize method contents into a development cycle and specify the sequence of the
work to be done. The sequence of work to be done is independent of a development life cycle model (such
as waterfall or iterative). Think of processes as workflows or breakdown structures. Processes enable
project managers to see who is required and which work products are modified in each phase of the
project. If you are familiar with the Rational Unified Process® (RUP), think of RUP disciplines such as
analysis and design implementation as method content, and think of RUP phases such as elaboration and
construction as process elements.

It is important to separate the two concepts of method and process and to have a framework that supports
their independent modifications.

Rational Method Composer

IBM Rational® Method Composer (RMC) is an Eclipse-based method and process authoring platform used to
integrate, tailor, codify, and publish processes. Out-of-the-box, RMC offers a catalog of processes that are
ready to be used or customized, such as the Rational Unified Process (RUP). Project managers responsible
for maintaining processes, project managers, and program managers typically use RMC, which supports the
concepts described in this section.

The output of the work performed in RMC is a process that is published as HTML (usually in the form of a
Web site). The organization meant to follow the process can then use the process site.

Software Process Engineering Metamodel

This section addresses the development processes. Software Process Engineering Metamodel (SPEM) is the
standard specification that formally describes the software development processes. As an Object
Management Group (OMG) standard, SPEM is vendor, method, and framework-agnostic. Version 1.1 was
officially published in January 2005. Version 2.0, a major update, is currently being developed.

Rational Unified Process

Based on best practices adopted by thousands of projects worldwide, the Rational Unified Process (RUP) is a
software development process that can easily be tailored for specific projects. RUP includes key principles
around priority balancing, iterative development, visual modeling, software quality, and team
collaboration. RUP defines disciplines (method contents) and phases (process), as shown in Figure 1.
 Figure 1. The Rational Unified Process (RUP)

Rational Unified Process for Service-Oriented Modeling and Architecture

The Rational Unified Process for Service-Oriented Modeling and Architecture (RUP Plug-In for SOMA) is built
on top of RUP and provides guidance on developing service-oriented solutions. Version 2.4 (see Resources)
provides a unified method that combines previous RUP for SOA content and the IBM Global Business Services
(GBS) SOMA method. The RUP Plug-In for SOMA includes specific guidance for software architects and
designers on the analysis, architecture, and design of service-oriented solutions.

Specialized Unified Modeling Language (UML) profiles exist for the modeling of domain-specific solutions,
including SOA, and go hand-in-hand with specialized processes. For example, there is a UML 2.0 profile for
Software Services that supports the RUP Plug-In for SOMA.

Note: Processes related to Management are addressed in subsequent articles in this series.

IBM techniques

As described in Part 1 of this series, Component Business Modeling, or CBM, helps organizations gain
significant new insights into strategy, technology, operations, and investment alignment. CBM enables the
identification of differentiating business components and the analysis of key business processes.

Service-Oriented Modeling and Architecture (SOMA) provides guidance on the analysis and design of SOA
solutions. SOMA enables the identification, specification, and realization (at the design level) of business-
aligned services. This topic is described in detail in a later section.
Models, UML, assets, and patterns

Metadata

Metadata literally means data about data. For example, metadata about a recorded song might include
information about its artist, album, composer, length, or quality, whereas the data is the audio recording
itself.

Depending on the context, the same data can be actual data, or metadata. Consider the example of
development methods and processes, described in the previous section. When you codify a development
method in RMC, you define content that is typed (backed-up by metadata). For example, you might define
new instances of work products, tasks, and roles. At this level, work product, task, and role are metadata
elements, and the metadata also defines what the relationship is between these types (tasks that are
performed by roles). Now think about when designers defined the concepts around methods. Imagine that
they were modeling the concepts of work product, role, and task using UML. At this level, work product,
task, and role are the actual data, and UML is the metadata. This data will be later used as metadata in
RMC. So, for this example, UML can be considered meta-metadata!

Model

RUP describes a model as an abstract representation or simulation of a system that provides a complete
description of the system from a particular perspective. Models are often used to gain a better
understanding of how the system works or to document design decisions for the actual implementation.
Models are often made up of several different kinds of parts. These parts are categorized as model
elements.

Models are targeted to a group of people who understand them. For example, system analysts and designers
create and use analysis models, and database designers design and view data models. Models can be based
on text or graphics or both. Because modeling is about being rigorous and complete while reducing
complexity (such as describing at higher levels of abstraction), it is a good practice to use rich graphical
design notations, such as the Unified Modeling Language (UML), described in RUP as visual modeling. A
model is at a specific level of abstraction, and it can evolve into lower levels of abstraction. For example,
analysis models typically evolve into design models.

Part 1 in the series explained that collaboration is even more important with SOA. For example, your
company might have outsourced detailed design or implementation to another company. When you model,
remember that it is for others to use. Also, your SOA design and development platform should be able to
take a model and evolve it into another model.

Automations and transformations

An SOA design and development platform should allow for the semi-automatic transformation of models
from higher to lower levels of abstraction, and eventually to code. For example, think of a UML-to-Java™
transformation that can generate Java code from a UML class diagram.

The underlying framework should also allow for traceability, which is basically going back to higher levels of
abstraction. For example, imagine that you want to understand the impact that a change in a requirement
would have on your design. You should be able to tell how the requirement was addressed in the design
with the links (traces) that you added at the time you made design decisions to support that specific
requirement. Then, during your impact analysis, you should be able to see all of the design decisions related
(traced or linked) to that specific requirement, and you should start to understand what the impact of a
change in this requirement is on your design.

A metamodel is a model about a model. It is the model of a specific domain, and it defines concepts and
provides building elements to create models in that domain. For example, think of SPEM as the process
engineering metamodel.
Eclipse Modeling Framework

As an open-source Eclipse project, the Eclipse Modeling Framework (EMF) includes a model metamodel (a
metamodel in the modeling domain). Here is the definition from the EMF Web site:

"EMF is a modeling framework and code generation facility for building tools and other applications based on
a structured data model. From a model specification described in XML Metadata Interchange (XMI), EMF
provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes
that enable viewing and command-based editing of the model, and a basic editor.

The core EMF framework includes a metamodel (Ecore) for describing models and runtime support for the
models including change notification, persistence support with default XMI serialization, and a very efficient
reflective Application Programming Interface (API)
for manipulating EMF objects generically."
What is the difference between EMF and UML?
Unified Modeling Language (UML)
EMF is a modeling framework (that includes a
"The Unified Modeling Language (UML) is the metamodel), while UML is a specification.
industry-standard language for specifying, Consider the Eclipse UML2 project, which is an
visualizing, constructing, and documenting the EMF-based implementation of the UML metamodel
artifacts of software systems. It simplifies the that supports the development of UML modeling
complex process of software design, creating a tools for the Eclipse platform. From this
'blueprint' for construction." Source: Object perspective, you can see the EMF metamodel
Management Group (OMG) (Ecore) as the metamodel that is used to
implement the UML model on the Eclipse
The good thing about UML is that it has broad platform.
industry support. Originally submitted to the OMG in
1997, it is fully supported in many vendors' design and development environments, such as IBM Rational
Software Modeler (RSM) or IBM Rational Software Architect (RSA).

An OMG standard, the current formal version of the specification is 2.1.1. It defines 13 groups of concepts
and diagram types organized into two categories:

• Structure: Class, Object, Component, Composite Structure, Package, Deployment

• Behavior: Use Case, Activity, State Machine, Sequence, Communication, Timing, Interaction
Overview

A generic modeling language, one of the key strengths of UML is that it can be extended for domain-specific
modeling using UML profiles.

UML profile

UML profiles provide a simple extension mechanism to the domain-independent UML. Profiles enable the
definition of domain-specific entities and rules. UML profiles pair well with development processes. For
example, there is a UML Profile for Business Modeling that supports the Rational Unified Process (RUP) for
Business Modeling Plug-In.

Profiles consist mainly of stereotypes. A stereotype defines which UML class (meta-class) is associated with
it, properties on that class, and constraints on how stereotyped elements can be associated with other
elements. For example, in the UML 2.0 Profile for Software Services, the Service Specification stereotype
extends the Interface UML meta-class. It defines a property named published to indicate whether or not the
service specification has been published to a service registry. Finally, one of its constraints is that all
Service Specification operations should be marked public.

UML 2.0 Profile for Software Services

The UML 2.0 Profile for Software Services is a UML profile that "allows for the modeling of services, service-
oriented architecture (SOA), and service-oriented solutions. The profile (sometimes referred to as services
profile) has been implemented in IBM Rational Software Architect (RSA), used successfully in developing
models of complex customer scenarios, and used to help educate people about the concerns relevant to
developing service-oriented solutions."

The profile defines stereotypes such as Message, Service Specification, or Service. It also provides
distinctive graphical notations for these concepts. Figure 2 shows an example of UML diagram: a message
design model in the insurance domain (from IBM Rational Software Architect). It is represented as a class
diagram (a structural diagram) that uses the Message stereotype from the services profile.

Figure 2. A UML class diagram

Model-Driven Architecture

Model-Driven Architecture (MDA) provides an answer to having business and technology constantly changing
by having independent models for both. Here is the definition from the OMG MDA user guide:

"OMG's MDA is a vendor-neutral approach to using models in software development. MDA provides an
approach and enables tools to be provided for:

• Specifying a system independently of the platform that supports it

• Specifying platforms
• Choosing a particular platform for the system
• Transforming the system specification into one for a particular platform

The three primary goals of MDA are portability, interoperability, and reusability through architectural
separation of concerns."

At the core of MDA are concepts such as system (as-is or to-be), platform (provides functionality such as
J2EE or Web services), and viewpoint (an abstraction to focus on a particular concept).

MDA defines the following models:

• Computation-Independent Model (CIM): The domain model used to define the requirements for
functionality.
 • Platform-Independent Model (PIM): The business functionality and behavior model that is
independent of (evolving) technologies on which it can be built.
• Platform-Specific Model (PSM): Combines specifications of the PIM and how a specific type of
platform is used.

MDA defines a transformation as converting the model of a system to another model of the same system
(such as PIM to PSM). Transformations of one model to another are described with mappings.

One of MDA's primary goals is to enable the provision of design and development tools that support it.

Model-Driven Development

The things described so far in this section, specifically models and transformations, form the basis for
Model-Driven Development (MDD), sometimes referred to as Model-Driven Software Development (MDSD),
which is the software engineering approach for which MDA is a prescriptive standard. Model-Driven
Development (MDD) is a software development approach based on models and transformations. MDD
supports the semi-automatic generation of code, starting from high-level business analysis models to using a
set of model-to-model transformations and eventually to using model-to-code transformations. This is made
possible through the definition of a set of models, the completeness of model instances, and the mappings
between elements of different models used in transformations. Also, MDD enables the analysis of the impact
of changes.

The IBM Rational Software Delivery Platform (SDP) supports team development of end-end enterprise
solutions, following an MDD (or other) approach, such as Business-Driven Development. "Business-Driven
Development (BDD) is an integrated, role-based approach to software development that aligns business and
IT, enabling the dramatic improvement of business performance." BDD uses models as well, and it focuses
on the coordination of business and IT models across the SOA lifecycle (see Part 1 of the series). The IBM
BDD approach supports roles such as Business Analyst, IT Architect, J2EE Developer, or Integration
Developer, with the IBM Software Delivery Platform.

Refer to Resources for an IBM Systems Journal article containing an in-depth look at Model-Driven Software
Development by IBM thought leaders.

Asset

Assets and patterns are key to the success of SOA,
because they enable reuse. In fact, enterprises that
adopt an asset-based business model have
tremendous growth capabilities. They are no longer
limited by the productivity or number of their staff,
as in the traditional labor-based business model. The
proper use of assets can dramatically change
software investments. However, anyone who adopts
this model can tell you that it is not straightforward,
and it requires proper governance and infrastructure
support.
Creativity can be counter-productive with SOA.
Having architects, designers, and developers reinvent
the wheel with each new project is undesirable.
Similar requirements should lead to consistent
architectures and designs. Assets and patterns allow
the proper level or creativity, which enables you to reuse proven solutions wherever possible and then focus
all of your time and effort on what needs to be invented, such as the business logic that is particular to the
project.
Asset or service?
Assets and services share common characteristics
around the need for a description, their reuse
potential, and their granularity (fine-grained or
coarse-grained). A service can be a kind of asset,
which might require many assets to be
represented. Some elements of the service assets
are used more during development time, such as
business process models or test cases, while other
elements of the service assets are more
applicable to the run-time, such as Web Services
Description Language (WSDL), XML Schema
Descriptor (XSD), or Enterprise Archive (EAR). SOA
Governance defines the rules dictating the
lifecycle of such services and assets.
An asset is a collection of artifacts that provide a solution to a problem in context. In this context, artifacts
can be anything, such as a requirement, a design model, implementation code, or a test case. Think of an
artifact as a file on the file system. Critical to their success, assets include instructions on how to use,
customize, and extend the assets. See Reusable Asset Specification for more information about what makes
an asset.

Pattern

A pattern is a solution to a recurring problem in a Asset or pattern?

given context. A pattern is a specific type of reusable
asset. You can make the distinction between the
specification of a pattern (a description of the
problem, context, forces, and solution), and its
implementation, such as a Java bean. There can be
many implementations of a single pattern
specification.
Patterns fall into different categories, depending
which phase in the development process they fit
into. For example, the IBM Patterns for e-business
classifies patterns into the following categories:
business, integration, composite, application, and runtime. The Gang of Four (GoF) design patterns are also
well-known.
Assets and patterns both provide a proven
solution to a problem in context. So, what are the
subtle differences? An asset can contain artifacts
of any type, such as a movie, but also includes
patterns. A pattern is a special type of asset.
Assets are backed up with a standardized model
(RAS) on how to describe and structure them: a
model that can be extended with profiles. Think
of a pattern as its specification and its
implementation.

When you use patterns, you can be sure that the solution they provide or codify is correct, useful, and has
been validated. However, as with any type of reusable assets, adoption is possible only if a context and
method are given on when, why, and how to use the patterns. Many patterns exist, and that context is
necessary to get started. The patterns for e-business, for example, are presented with a process that, based
on skills and environment, helps you identify the relevant patterns that address your business problem.

Finally, one of the goals of patterns is to provide consistency so that you end up with the same architecture
based on the same set of requirements because you used patterns in your design.

Reusable Asset Specification

Adopted in 2005, the Reusable Asset Specification (RAS) is an OMG standard used to describe the structure,
content, and description of reusable software assets. The goal of RAS is to provide best practices on how to
package assets in a consistent and standard way. As defined in the specification, core characteristics of a
RAS asset include:

• Classification: The context in which the asset is relevant.

• Solution: The artifacts contained in the asset.
• Usage: The rules for installing, using, and customizing the asset.
• Related assets: How this asset relates to other assets.

Artifacts can have a type determined by their file name suffixes, such as .xml, .txt, .doc, or .java; or by
their purposes, such as use case model or analysis model. Because a software asset is a broad term, RAS
also provides profiles used to describe specific types of assets. This is the same concept as UML profiles.
There are UML profiles used to extend the domain-independent UML. Similarly, there are domain-specific
(such as Web services) RAS profiles used to extend the domain-independent RAS.

RAS assets have a .ras file extension, and they are packaged like .zip files, meaning that they have a
manifest and that you can open them using WinZip. Figure 3, from the RAS specification, illustrates the
major sections of a core RAS asset.
 Figure 2. The major sections of a core RAS asset

Conclusion

This article defines the terms around software engineering processes and methods. It defines software
artifacts used to build SOA solutions, such as models, assets, and patterns. Key standards are introduced,
such as SPEM, UML, or RAS.

Future articles will define SOA terms related to analysis, design, implementation, runtime, and
management. So, stay tuned to developerWorks!
 SOA terminology overview, Part 3: Analysis and design
Level: Intermediate

Bertrand Portier (bportier@ca.ibm.com), IT Architect, IBM

16 May 2007

Building on the previous articles in this series, Part 3 continues the Service-Oriented Architecture (SOA)
terminology journey. Learn a few new terms, including service identification, specification, realization, and
design principles, and find out why they are fundamental to the success of SOA.

Introduction

Semantics are essential in any domain, especially SOA. SOA spans teams and organizations, so agreement
upon relevant terms is crucial. This series provides a tour of SOA by defining terms and the key concepts
behind them. You'll learn the vocabulary necessary to understand and communicate in the SOA field. For
each term, you'll learn its importance, what it means in this context, what the relevant standards are, and
how the term differs from others in the SOA field.

Part 1 had a business focus and set the stage by defining terms like service and SOA. Part 2 covered
development processes, models, and assets. In this part, the third installment in the series, you explore the
terms and techniques associated with designing an SOA at a high level of abstraction (analysis) and how to
move forward to a lower level of abstraction (design) that's just above the code level.

A note about organization

The terms listed below are not organized alphabetically, nor are they shown in order of importance. Rather,
they are organized in a building-block fashion. Part 1 began with service, because it's probably the most
important concept to understand the SOA framework. The next parts of this series build on the service
concept and define other terms by grouping concepts that relate to specific disciplines, such as analysis and
design in this part.

Analysis and design

The IBM® Rational® Unified Process® (RUP®), described in Part 2 of the series, defines a discipline called
analysis and design, which sits between requirements and implementation. Analysis and design includes
activities that specify the initial IT architecture based on a set of functional and nonfunctional
requirements. It's also based on other activities that further detail this initial architecture from an analysis
level of abstraction to a design level that's detailed enough for developers to generate and write the
implementation code.

SOA analysis and design is also referred to as one or more of the following terms:

• Service modeling
• Service-oriented analysis and design
• Service-Oriented Modeling and Architecture (SOMA)
• Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA)

Analysis involves describing what the system to be built is at a high (conceptual) level of abstraction. The
input of analysis is a set of requirements and existing assets (or applications or systems). The output is a
description of what is to be built. Analysis is critical for SOA, because it's where IT meets the business
during service identification. The result of analysis is used as input for design.

Design involves describing what the system to be built is and, more importantly, how to build it.

Most of the architecture (described in Part 1) work is performed during the analysis and design workflow, in
the elaboration phase of a project.

Service-oriented analysis and design leverages existing analysis and design principles, such as the ones in
object-oriented or component-based development. For example, you may remember that there's something
called Object-Oriented Analysis and Design (OOAD). It’s important to note, however, that SOA efforts are
always centered on services (as opposed to objects or components).

Note: Analysis-level models often evolve into design-level models, so there's only one RUP discipline for
analysis and design.

The main output of a service-oriented analysis and design effort is a service model (previously referred to as
service specification) that documents all of the architecturally significant parts of the service-oriented
system and a design model that further details how the service model should be realized (implemented).
These two models fully specify the SOA design and are enough for developers to unambiguously perform
implementation.

In the following sections, you get an introduction to the terms associated with service-oriented analysis and
design with descriptions of the associated tasks.

Note: The terms identification and specification were used in component-based development, and the
terms specification and realization are defined by the Unified Modeling Language (UML). These three terms
form the core activities of RUP SOMA (with the same meaning).

Service identification

Service identification is the core service-oriented analysis activity. The goal of service identification is to
identify groups of conceptual services and their operations.

These identified services are needed by and meaningful for the business. In fact, business analysts help
software architects perform this exercise. In the next section about service design principles, you learn
about the need for logical groupings of services and business-relevant names for services and their
operations. These are decided during service identification, using techniques like the ones described in RUP
SOMA.

In Part 1, you learned about the SOA solution stack reference model, with its functional layers — consumers
and business processes at the top, services in the center, and operational systems and components at the
bottom. Based on this model, you can take different approaches to identify services (depending on whether
you start from the top or the bottom of the diagram). Let’s take a closer look at these:

Top-down approach

Starting from a set of business objectives and goals, it's typical in SOA projects that the business
architecture effort has identified one or more business processes to focus on. As a result of the business
modeling effort, there may be designed business processes (the to-be processes) that can be seen as the
functional requirements for the system under design.
The top-down approach is about decomposing business elements (mainly business processes and use cases)
and refining them into a granularity that makes sense for services. During a top-down approach, you
typically identify service operations from business tasks. The advantage of this is that you can be assured
that the identified services are business aligned!

Bottom-up approach

The bottom-up approach is about analyzing existing IT assets (such as legacy applications and systems) and
finding functionality that could be exposed as services, to be reused by many.

Reuse is an important part of SOA and critical to its success. As you probably know, your legacy applications
(that is those that have already been deployed) are your company’s most valuable assets and should be
leveraged. For example, the bottom-up approach analyzes existing Information Management System (IMS)
transactions or COBOL programs.

A word of caution about bottom-up analysis: You have to be careful not to blindly expose existing IT
capabilities. For example, Create Read Update Delete (CRUD) data services may be too fine-grained and not
business aligned.

Note also that the use of existing asset-analysis tools, such as IBM WebSphere® Studio Asset Analyzer, is
critical because often nobody knows exactly what is deployed and running!

Meet-in-the-middle approach

The meet-in-the-middle approach is about reconciling needs (the services identified by the top-down
analysis) and what's already provided by existing IT assets.

The meet-in-the-middle approach requires collaboration between business analysts, software architects,
and specialists for the legacy applications. Note that although it's valuable to perform bottom-up analysis
outside of the context of a specific project (for example, an enterprise architecture team doing inventory
of candidate services), in practice, however, efforts usually start with the top-down approach and the
decomposition of one or more business process as part of a project. Then, in this context, bottom-up
analysis occurs to try and find matches for the required services (meet-in-the-middle approach).

Based on the three described approaches, a set of services and their operations are identified, validated
(for example, validation makes sure that services don't already exist or are business aligned), and grouped
into logical categories (such as business components or business functional areas). Business items (such as,
policy or claim) are also identified, mainly from existing data legacy applications. The next step is to fully
specify what these services and their operations are in terms of structure and behavior.

Service specification

Service specification and realization are the core service-oriented design activities. Service specification is
about designing the structure and behavior of the service elements that are architecturally significant.

Service model

The main output of service specification is the RUP SOMA work product called service model, which includes
artifacts like service specifications (interfaces), service providers, and service collaborations. A service
model should be complete enough so that service providers and consumers unambiguously know what the
service is.

Specifying services includes designing the following:

Service specification
From the service model, a service specification artifact is an interface that describes the operations offered
by a service.

Optionally, service messages can be designed to act as operation input, output, or fault parameters.

You may recognize the interface and operation concepts from the object-orientated paradigm. The
emphasis on messages, collaborations, and policies (described later in this article) can be seen as the
evolution provided by service orientation.

A service specification is used as the contract between a service provider and a service consumer. It defines
the structure and behavior of a service.

Service provider

From the service model, a service provider artifact groups a set of related services together.

A service provider includes:

• Required service specifications (when the service is a composite one and part of a collaboration, as
described in the following section).
• Provided service specifications.
• Provided services.

For example, there may be a coarse-grained service provider called Sales Management, which supports the
sales management functional area. This service provider may provide two services called Account Activation
and Application Inquiry, with the Account Activation service typed as the Account Activation service
specification.

Service provider design is where principles from component-based development should be leveraged.
Service providers are typically represented at UML components and then services as UML ports on these
components. Note: The services (ports) are typed with service specifications.

Service collaboration

From the service model, a service collaboration artifact represents the communication between two or
more services. Service collaboration specifies the dynamic behavior of services within an environment with
other services.

Terms related and somewhat synonymous to collaboration are choreography, orchestration, or composition.

Atomic services are fine-grained services that don't require other services. Composite services are larger-
grained services that require other services to provide their services. Therefore, composite services act as
service consumers and always need to have associated service collaboration.

In Part 1, you saw that the Business Process Execution Language (BPEL) can be used to specify an
executable version of a business process flow. It also plays an important role in the area of service
collaboration as it can be used to implement a composite service as a collaboration of atomic services.

Note that, although this article doesn't go into it because it’s too detailed, service consumers and service
partitions (the structure of the SOA) also need to be addressed by the design.

Quality-of-service approach

As with traditional (non-SOA) approaches, the design needs to address both functional (such as use cases
and business processes) and nonfunctional (such as quality of service, or QoS) requirements.
A QoS description should be part of the service specification. Also, you should use proven design patterns to
address them. (Design patterns are typically heavily used during service realization.)

The policies regarding usage of services need to be tackled at the design level, too. Policy is covered in a
later part of this series.

Model-driven development (MDD) approach

For the design to be explicit, complete, and unambiguous, you need to rely on modeling languages, such as
UML (see Part 2) to design services. For example, remember that service providers are typically represented
by UML components with UML ports. Also, UML collaborations or sequence diagrams support the modeling of
service collaborations. More specifically, you should use UML profiles for service-oriented design, such as
the UML 2.0 profile for Software Services, introduced in Part 2.

MDD lets you model and specify elements at different levels of abstractions. You've probably noticed that
this series goes into lower levels of abstractions as it progresses. It started at the business level, moved to
analysis, and now design. In following installments of this series, you'll learn about implementation (at the
code level). MDD provides semiautomated transformations from one level of abstraction to another. For
example, you'll see that you can generate the Web Services Definition Language (WSDL) files from the
service model work product. Also, you can eventually generate the code (usually from the design model)
that will be used as the base for your SOA implementation.

The MDD approach also allows traceability, which is basically going from lower to higher levels of
abstraction. For example, you can link a design decision to the requirement(s) that it's addressing. This
allows rapid analysis of the impact on your design of a change in requirements.

Support

In this domain, I strongly recommend that you look at the following terms, which are described in previous
parts of this series. You can also find more information about them in the Resources section at the end of
this article:

• The Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA) process
• The IBM Rational Software Modeler (RSM) Rational Software Architect (RSA) tools
• The UML 2 Profile for Software Services
• The SOA design assets and patterns available on the developerWorks RAS repository
• Business services modeling, which provides a mapping between business process modeling elements
and UML elements

Service realization

Service realization is about designing how services will be implemented. It's the most detailed design, just
before the code level. It's not about implementing (constructing) services, as Part 3 will describe, but about
describing at the design level how the services should be implemented. Service realization is performed by
the software architect and the designer.

There's a fine line between specification and realization. Here's an easy way to look at it the difference
between them: If service specification is about what, then service realization is about how.

Design model

The design model, as defined by RUP SOMA, is the core output work product from service realization. It
describes the realization of the SOA and acts as an abstraction of the implementation (including code). The
output of service realization, it's used as input for service implementation.
Service component

The main design model artifact you should focus on is the service component — which represents how one or
more service specification is realized — and how all of the functional and nonfunctional requirements and
structural and behavior specifications are addressed.

A lot of new classes are also created during service realization to refine the service components and
services. The definition of the structure and behavior of these classes is thus performed as well.

As previously stated, service realization should make heavy use of design patterns (for example delegation,
singleton, and factory), which are typically applied to the classes designed during service realization.

WSDL and XML Schema

During realization, you make decisions about a variety of technologies. Web services have proven to be a
reliable platform of choice for SOA. From the service model, MDD tools like IBM Rational Software Architect
can generate the Web Service Definition Language (WSDL) for the service providers and specifications as
well as the associated XML schema files (.xsd) that define the messages that flow between service providers
and consumers. WSDL and XML Schema can arguably be an output of service realization or one of the initial
outputs of service implementation.

QoS and service partitions

Making technology choices has a huge impact on quality of service. Some technologies don't support the
requirements you may have. An example can be illustrated in terms of reliable message delivery or
performance (such as throughput). It's a good practice to map technology choices to partitions, as with
traditional (non-service-oriented) design. In the case of SOA, the service partitions that were defined during
service specification may need to be revised during realization to have associated service policies (access
channels, security, performance, and so on) addressed by specific technologies. Think, for example, of
performance requirements that would imply in-memory transactions, or interoperability requirements that
would imply the use of SOAP and Web services, or when to use local invocations instead.

After you're done with service design, the next step is to implement (construct) services based on this
design, as will be described in the next part of this series.

Service design principles

This section lists four service design principles that you should have in mind when designing SOA solutions.
Note, however, that this isn't an official or comprehensive list and that some of the concepts originate in
other paradigms, such as object orientation. These principles are important in the design of service-
oriented solutions.

Reuse

Always have reuse in mind when designing services. Usually, you have specific requirements from specific
service consumers at design time. However, if you want to reap the benefits of SOA, you want the services
you design to be reused by other consumers with slightly different requirements. You don't know these
consumers and what their requirements are at the time you create the design, so it's not an easy task!

Some of the things you can consider are:

• Providing a meaningful and descriptive name for services and their operations based on business
domain, not technology.
 • Making services discoverable by providing complete human and machine-readable specifications
published to a service registry (see the following parts of this series for more information).
• Quality of service for usage scenarios that are different from the initial one, for example, plan for
increased demands and workloads when the service becomes popular.
• The possibility of extending the initial functionality provided by the service (based on the initial set
of requirements) to make the service complete.
• The possibility of implementing a service specification on a number of different platforms.

Loose coupling

Coupling refers to how much entities or systems depend on one another. Within the SOA context, you can
think of coupling between a service specification and its provider or implementation, or coupling between a
service provider and a service consumer. To support the agility promised by SOA, coupling should be loose.

A service provider shouldn't have to know about a specific instance of a service consumer, and vice-versa.
Replacing a service provider or the implementation of a service should have only minimal or no disruptive
effects on consumers.

To help achieve loose coupling, consider the following:

• Separate service specification (the service and design model described in this article) from service
implementation. As described in the MDD section in Part 2, it's important to have full specifications
for services, which are independent of a particular implementation. Also, the service contract
should be at the specification level (not at the implementation level).
• Using tools, formally describe a service specification in both human-readable and standard machine-
readable format (for example, WSDL and WS-Policy) so that code generators can help with the
implementation of services (Part 4 of this series will have more information about this).
• When developing service consumer code, keep in mind that there may be service intermediaries or
other providers, and don't hardcode any information about an instance of a provider.

Statelessness

Transactional state means that a service needs to have information about things that happened as part of a
long-running transaction between a specific instance of a service provider and a specific instance of a
service consumer. For example, the result of invoking a service operation is different if the operation has
already been invoked, or another operation needs to be invoked before an operation can be invoked.
Although it can be found in component-based development, transactional state should be avoided with SOA.

Data (information) state means that the state of data instances needs to be managed. Some services
typically need to manage data state. Take the example of a Claim service in the insurance industry. This
service has to manage the state of Claim instances, especially because these instances are accessed by
many different consumers over distinct business transactions. Note that services that hold state are
typically atomic (fine-grained). To address state requirements, you rely on the underlying technology used
for implementation, such as Java™ Platform, Enterprise Edition (Java EE) with stateful session beans.

Granularity

For service-oriented design, you can think of granularity at the service provider level (how many services
are provided) or at the service specification level, for example. A service specification is a logical grouping
of service operations. Here, logical means that it makes sense as far as the business is concerned. For
example, a Claim Processing interface in the insurance domain provides all of the operations needed in
claim processing usage scenarios. It also makes sense as far as IT implementation is concerned. For
example, all of the service’s identified operations are implemented in the same development iteration.

When designing services operations, consider collaborations, usage scenarios, and the messages (number
and size of them) that will flow between service providers and consumers. Coarse-grained operations
provide more business value and allow for easier modifications of implementation. Coarse-grained operation
parameters (using messages for input, output, and fault) are less error prone. Using fine-grained parameters
instead of messages, however, is usually more descriptive. For example, if a service operation signature is
determineEligibility(application: ApplicationMessage), then you need to look at the definition of
ApplicationMessage. If the signature is determineEligibility(customer : Customer, product : Product, date :
Date, amount : Amount), it's more descriptive. Also, the Customer or Product parameter types, for
example, can be reused in other operations, unlike the ApplicationMessage.

For service granularity, always keep in mind that services should be composable. This is related to reuse
and the ability to provide new functionality based on existing functionality. A set of services at a certain
granularity level can be choreographed, and the result would be another more coarse-grained service.
Think, for example, of having business tasks provided by services and then having a sequence of these
business tasks (a business process) provided as a service as well.

At the end, making a design decision on service granularity is always a tradeoff between performance (for
example, size and number of messages being exchanged and efficient implementation) and potential for
reuse. Also, a typical SOA contains both fine-grained (atomic) and coarse-grained (composite) services.

Conclusion

This article covered the terms that relate to the IT architecture and design of SOA solutions. You saw where
IT meets the business needs during service-oriented analysis and moved down the abstraction level path to
further detail the design. Starting with a set of requirements, you learned about the activities that take
place (and their associated terminology) to design an SOA that meets the requirements. The result is a
design that's detailed and unambiguous enough to be used for implementation, which will be the topic of
Part 4 of this series. Stay tuned to developerWorks for more (and use the RSS feed link in the Resources
section to access the next installment as soon as it's available)!

Service Oriented Architecture (SOA) Entry Points

Learn about the SOA Entry Points

People: enables efficiency through interaction and collaboration

Process: offers tools and services to help streamline business process management
Information: enables access to complex, heterogeneous data sources
Connectivity: links people, processes and information for your business
Reuse: extends the value of your previous asset investments

People:
What is the people entry point?

Are your employees, partners, and customers enabled to take advantage of SOA to drive greater
productivity and collaboration? People can interact with SOA-based business services and composite
applications through an enabling framework of tools, and practices. The people entry point is a starting
point for SOA, enabling people to interact with application and information services that support business
processes. As a complement to the other entry points — process, information, reuse and connectivity—the
people entry point can facilitate real time decision making and dynamic collaboration, and immediate
execution. Overall, the people entry point approach to SOA drives business and operational flexibility and
improves end-user productivity and collaboration.

The value of people

Employee productivity, operational efficiency and the ability to innovate on the fly are paramount to
competitiveness and growth. Companies frequently struggle with siloed applications and information that
prevent customers, employees, and partners from working together effectively. Empowering people through
SOA solutions can bridge these challenges and provide a foundation for greater productivity and
collaboration. Because people drive the interaction with the SOA services that execute business results,
focusing on people is critical to the success of SOA implementations. The people entry strategy to SOA can
help:

• Accelerate productivity
• Reduce costs for access to multiple applications and information sources.
• Reduce time to deployment for new services.
• Increase access to process flexibility and orchestration.
• Enable collaboration inside and outside the enterprise.

Process:
What is the process entry point?

The process entry point is a business-centric starting point for service oriented architecture (SOA) that
provides specific tools and services to help streamline and improve processes across the enterprise. By
entering SOA from process vantage, you can establish the foundation for IBM's business process management
with SOA. Improve the efficiency, flexibility, and control of key business processes.

The value of process

Do your processes allow you to quickly respond to changing market conditions? By streamlining your
processes you can align your business and IT goals — reducing the complexity of building processes.
Leveraging SOA with a focus on process can help your business:

• Improve employee productivity.

• Increased collaboration.
• Accelerate speed to market.
• Respond quickly to business challenges.
• Implement new processes in less time.
• Maximize return on investment.

Reuse:
What is service creation and reuse?

Service creation and reuse is an IT-centric entry point to service oriented architecture (SOA) that focuses on
deriving continued value from previous asset investments, identifying services to be outsourced and
designing new services to fill portfolio gaps. By entering SOA from a service creation and reuse vantage, you
may expand access to proven systems and achieve greater value from your existing technology investments.
In fact, a study by Software Productivity Research found that it can be up to five times less expensive to
reuse existing services and applications than to rewrite them. Extend, enhance or create new processes
enabling you to substantially increase business flexibility and responsiveness through reduced development
time and elimination of duplicate processes.

The value of service creation and reuse

Improve efficiency. Reduce risk. Cut cost. The IBM entry strategy to SOA through service creation and reuse
can help:

• Reduce the amount of new code that must be created for business initiatives.
 • Lower maintenance cost by eliminating redundant systems.
• Expedite the roll-out of new business functions by creating composite function from within your
applications.
• Integrate tasks performed by your legacy applications into broader business functions to establish a
simple and effective means to enhance usefulness of mainframe-based systems.

Information
What is information as a service?

Information as a service is an entry point to service oriented architecture (SOA) that offers information
access to complex, heterogeneous data sources within your company as reusable services. These services
may be available both within the enterprise and across your value chain. By entering SOA from an
information vantage, you may improve the availability and consistency of information, while simultaneously
removing traditional barriers to information sharing. Drive innovation by better understanding your
organization’s operational, transactional, analytical, and unstructured information and making it available
in new ways through SOA.

The value of information as a service

Establish information as a service to ensure consistent definitions, packaging, and governance of key
business data. Provide information services that can be easily reused across processes and independently
maintained to enable more business flexibility and increase IT resource productivity. The IBM entry strategy
to SOA through information can help:

• Collect, clean and make your data accessible:

o Develop a unified view of their business with inline access to analytical data for improved
transparency and business insight.
o Generate and govern authoritative master data records with shared metadata and data
quality services for master data management.
• Reduce cost and risk:
o Reduce costs associated with infrastructure rationalization and migration by decoupling
information from siloed information sources.
o Reduce risk exposure through in line analytics and auditable data quality for risk and
compliance initiatives.
• Increase your organizations agility:
o Increase the agility for business transformation by providing reusable information services,
spanning structured and unstructured information that can be plugged into applications,
business processes, and portals. At the same time lower development costs associated with
accessing and transforming data.

Connectivity

What is service connectivity?

Service connectivity is an IT-centric entry point to service oriented architecture (SOA) designed to help
simplify your IT environment with a more secure, reliable and scaleable way to connect within and beyond
your business. Link people, processes and information in your business with a seamless flow of messages and
information from virtually anywhere at anytime using anything — that's true connectivity. SOA brings new
levels of flexibility to such linkages. Delivering real business value on its own, connectivity is also a core
building block for future SOA initiatives.

The value of service connectivity

Open your doors to customers by providing a variety of ways for them to interact with your company.
Enabling exceptional connectivity through your SOA you can deliver a consistent user experience regardless
of what business channel they choose. Also, by linking your business units or divisions across the multiple
parts of your company and your partners, you can build a foundation for success. IBM entry strategy to SOA
through service connectivity can help:

• Ensure seamless flow of information from anywhere at anytime using anything.

• Execute broad business processes that span your company and business partners.
• Build trusted relationships with your partners.
• Scale your business to grow smoothly.
• Deliver a consistent user experience regardless of channel or device.

When not to use an SOA

You'd think that with ZapThink's laserlike focus on the benefits of service-oriented architectures (SOAs),
we'd be of the opinion that SOAs were good for all users, systems, and situations. As a matter of fact, SOAs
are particularly valuable in certain circumstances -- namely, in heterogeneous IT environments that are
subject to frequent change. However, in many situations, for example, if your IT environment isn't
heterogeneous, or isn't expecting much in the way of change, then maybe an SOA isn't right for you. In these
cases, the advantages and benefits received by building and running an SOA -- greater business agility,
empowering business users, squeezing more value out of IT, reducing the cost of integration -- may actually
be outweighed by the cons of SOA, including its greater performance overhead, the increased need for
architectural discipline, and the requirement that companies change how they consume and produce IT
assets. Here, then, are four situations where you might not want to use an SOA.

1. ...when you have a homogeneous IT environment

If you are an organization that uses the technologies of a single vendor, then it's possible that the additional
overhead of an SOA would not be cost-effective for you. This situation is particularly true if your IT
infrastructure has a narrow purpose, say, running a Web site. If you have an application server, a database,
and two Web servers, then an SOA may not add sufficient value to your IT investment. Most small
companies, for example, have a small, homogeneous network behind their own firewall. For these
companies as well as larger companies who have staked their claim in a single-vendor technology
implementation, an SOA is frequently an impractical addition to an otherwise simple infrastructure.

Homogeneity, however, works on different levels -- hardware, software infrastructure, applications, and
data. Heterogeneous hardware environments may not benefit from an SOA unless you also have a
heterogeneous software infrastructure -- i.e., different operating systems or middleware. And even if you
have a homogeneous software infrastructure, a heterogeneous mix of applications may necessitate a
service-oriented (SO) approach to exposing application functionality.

Counterpoint: when you would like to expose external services

Yet, even when you buy all your hardware, software infrastructure, and applications from individual
vendors, you may still find an SOA to be a cost-effective architecture if offering software functionality as
services to external parties is a part of your business. In such cases, the SOA resolves issues of flexibility and
visibility across multiple firms, even when individual companies have homogeneous IT environments.

2. ...when true real-time performance is critical

I don't know about you, but I'm glad the antilock braking system in my car isn't an SOA. In fact, embedded
systems like those found in cars, specialty equipment, etc., often require responses in the millisecond range
or faster. As SOAs rely upon asynchronous communication to provide loose coupling between service
consumers and producers, SOAs are not well-suited to situations that require strictly enforced response
times. When a life depends on speed, I'd rather go with a tightly coupled architecture any day.
Counterpoint: there's "real-time" and then there's "right-time"
However, "real-time" means something quite different when you're talking about an embedded system vs. a
real-time enterprise. If an enterprise can get some critical business intelligence in 30 seconds rather than
having to wait overnight, that's real-time enough for most companies. And if an occasional query takes an
hour, that's usually OK, too. In fact, SOA is an excellent approach for companies looking for ways to speed
up onerous batch processing without having to throw away their legacy applications. In these cases, we're
not talking about real-time as much as right time, and when SOAs can provide business value at the right
time, they are the most valuable.

3. ...when things don't change

This is the "if it works, don't mess with it" situation. If your requirements for that dusty old legacy system in
the corner aren't expected to change, then why bother messing with it? In fact, this principle applies to
companies and networks of all sizes. How many of you have a perfectly good computer that's more than five
years old? Maybe running Windows 98 or Mac OS 8 or Solaris 1.x? Even the relative newcomer Windows 2000
is hitting its fourth anniversary.

These systems are likely just as good now at doing what it did five years ago -- as long as you don't mess
with them. We're not just talking about the systems themselves here, but also the applications running on
those systems. If there are few reasons to change the business logic, presentation, data flow, process, or
any other aspect of the application, converting these dinosaurs to an SOA might not return sufficient value
to make the effort worthwhile.

Counterpoint: SOAs can unlock business value in even the most crotchety old systems
This counterpoint probably won't apply to that ancient Macintosh, but many companies can benefit by
service-enabling enterprise legacy systems. In some cases, service enablement means installing new
software on the old box, but not necessarily. Today's next generation screen scrapers and other legacy
enablement solutions can turn that dinosaur's interface or print output into XML with little muss or fuss.

4. ...when tight coupling is a pro, not a con

Loose coupling is great for enabling communications between applications in a distributed computing
environment, and making it easier to change the elements of such an environment. After all, if you don't
have to know anything about the system at the other end of the line, then communication and change are
simple and straightforward. When building an application that will reside on a single computer, however,
loosely coupling the components of that application from each other introduces needless overhead. Indeed,
the developer controls all those components at once, so what does it matter that one component needs to
have an intimate understanding of the workings of another?

It's also important to remember that coupling of software is a spectrum, with degrees of looseness or
tightness. Object-oriented (OO) development, after all, does offer a certain looseness, because of the
encapsulation of individual objects. Objects are known by the methods they expose, not their inner
workings. In fact, OO and SO development are two sides of the same coin: as developers and their tools get
up to speed on SO development, it will become second nature to decide whether a particular bit of
software should be OO or SO, depending on how tightly our loosely coupled it should be from the other
software it will interact with.

Counterpoint: won't Moore's Law take care of the performance hit?

So, why not use SO development approaches for all your applications if performance is the only issue? If the
overhead of service interfaces is the problem (since XML is far more verbose than the binary protocols that
OO uses), then maybe we should just throw more hardware at the problem. It's true that there are many
hardware products in a variety of form factors coming to market that accelerate XML processing, and there's
also every indication that computers will keep getting faster and hard drives will keep getting bigger. So, in
the cases where you require tight coupling for high-performance communications among components of
your application, and you don't require loose coupling anyway, an SOA might not be appropriate.
Model and build ESB SOA frameworks
Adapt service-oriented architectures for easy application integration

Application integration is the biggest challenge today for many enterprises. Building an Enterprise Service Bus
(ESB) is probably the quickest and most cost-effective way to address this challenge. In this article, you gain
insight on ESBs, and how to model and construct ESB service-oriented architecture frameworks.
Service-Oriented Architecture (SOA) is an approach to defining integration architectures based on the concept of
a service.

The key components of a SOA include services, dynamic discovery, and messages.

• A service is a callable routine that is made available over a network. A service exposes an interface
contract, which defines the behavior of the service and the messages it accepts and returns. The term
service is often used interchangeably with the term provider, which specifically denotes the entity that
provides the service.
• Interfaces are often published in public registries or directories where they are categorized based on
different services offered, just as businesses and their phone numbers are listed in a phone book's Yellow
Pages. Clients (service consumers) can look up a particular service by dynamically querying for services
based on various categorization features. This process is referred to as the dynamic discovery of
services.
• Service consumers or clients consume services through messages. Because interface contracts are
platform- and language-independent, messages are typically constructed using XML documents that
conform to an XML schema.

Figure 1 illustrates the various roles in a SOA.

Figure 1. The roles in a SOA

Web services as a SOA

Web services are built on top of open standards and platform-independent protocols. A Web service uses the
XML-based Simple Object Access Protocol (SOAP) over HTTP for communication between service providers and
consumers. Services are exposed as interfaces defined by Web Service Definition Language (WSDL), whose
semantics are defined in XML. Universal Description, Discovery and Integration (UDDI), a language-independent
protocol, is used to interact with registries and look for services. All of these features make Web services an
excellent choice for developing SOA applications.

ESB: An Introduction
When you enable or add Web service interactions that use existing Internet and intranet infrastructure between
systems in an architecture, you can create many individual point-to-point integrations, which are difficult to
maintain. As organizations move towards service-oriented architectures, which host various deployed services,
they require infrastructure service that provides robust communication, intelligent routing, and sophisticated
translation and transformation of services.
Application servers provide features like life connection pooling, transaction management, and life cycle
management that free the programmer from writing new code for each application. Similarly, an ESB provides
common communication and integration services. Because ESBs also use industry standards for most of the
services they provide, they facilitate cross-platform interoperability and become the logical choice for companies
looking to implement SOA.
The ESB is not a new software product, but a new way to integrate applications, coordinate resources, and
manipulate information. Unlike many previous approaches for connecting distributed applications (such as RPC or
distributed objects), the ESB pattern enables the connection of software that runs parallel on different platforms,
is written in different programming languages, and uses different programming models.

Capabilities of the Enterprise Service Bus

An Enterprise Service Bus exhibits these minimum, or mandatory, capabilities:

• Communication
Supports routing and addressing for at least one messaging style (such as request/response, or
publish/subscribe), and at least one transport protocol that is or can be made widely available. This
enables location transparency and service substitution, which enables the decoupling of the consumer
view of services from their implementation.
• Integration
Supports several integration styles or adapters. It enables the provision of services based on these
integration capabilities, and decouples technical aspects of service interactions and the integration of
services in the enterprise.
• Service interaction
Supports an interface definition format and associated messaging model (such as WSDL and SOAP) to
allow the decoupling of technical aspects of service interactions.
• Management and autonomic
Provides a consistent administration model across a potentially distributed infrastructure, including
control over naming, routing, addressing, and transformation capabilities. This enables the management
of services in the enterprise.

More advanced ESBs typically offer a number of additional value-added features, including:

• Adapters, to enable connectivity to packaged and custom enterprise applications, as well as to leading
technologies.
• Service orchestration engines, to support both long-running (stateful) and short-running (stateless)
processes.
• Quality of service and service-level capabilities.
• Presentation services, to enable the creation of personalized portals that aggregate services from
multiple sources.

Typical architecture of an Enterprise Service Bus

The architecture of an ESB is centered on a bus. The bus provides message delivery services based on standards
such as SOAP, HTTP, and Java™ Messaging Service (JMS). It is typically designed for high-throughput,
guaranteed message delivery to a variety of service producers and consumers. The ESB enables the use of
multiple protocols (such as synchronous and asynchronous) and performs transformation and routing of service
requests. The ESB enables services to interact with each other based on the quality of service requirements of
the individual transactions. It also supports different standards such as SOAP, XML, WSDL, JMS, J2EE, JAX-RPC,
and so on.
Figure 2 illustrates component types that can connect to an ESB:

• Custom applications, based on standards like J2EE and Struts, which plug into the ESB to provide a user
interface to enterprise services.
• Service orchestration engine, which hosts long running business processes, based on standards like
Business Process Execution Language (BPEL).
• Adapters, typically built to the Java Connector Architecture (JCA) specification, enable integration with a
wide variety of enterprise applications.
• Presentation and portals enable the creation of personalized portals that aggregate services from
multiple sources.
• Data services which provides real time view of data from heterogeneous data sources.
• Web services provides a standard means of connectivity to legacy and proprietary integration
technologies.
Figure 2. ESB architecture

ESB use case scenario

In this section, I go through a use case scenario for a loan processing system and show how, by adapting an ESB
approach using a series of IBM® products as an example, you can deliver loosely coupled independent systems,
which interact through consuming messages independently.
Look at an example of a loan processing system with these requirements:

• The user can submit a request for the loan from a Web-based application.
• The loan processing information is submitted through a Web service.
• Based on some predefined rules, such as the type of customer, a workflow system is required to take
further actions for approving the loan.
• During the approval process, the loan approver interacts with various server providers to check the credit
history of the loan requestor and act accordingly. I assume that server providers provide Web services to
access credit history information.
• Once the loan information is approved, the loan information is updated to the legacy system.

With this information, you can provide a high-level framework design of an Enterprise System Bus using various
products. Figure 3 breaks down the architecture of your ESB.
Figure 3. Build ESB architecture with IBM products

As shown in Figure 3, you will use WebSphere® Business Integration Message Broker with Rules and Formatter
Extension and WebSphere MQ to deliver enterprise bus messaging facilities. The flow of your loan processing
application and the corresponding product implementations are:

• Use WebSphere Portal to build the Web-based application with various presentation rules.
• The portal submits Web service requests containing loan and customer information to the Enterprise
Services Bus layer.
• Configure appropriate rules and formatter extensions using the Rules and Formatter Extension options
provided with WebSphere Business Integration Message Broker to route soap requests to appropriate
WebSphere MQ Queues. With rules such as type of customer (high risk/low risk), your application can
extract information from the headers and routed appropriately.
• Model business processes for loan processing, which require human intervention, using MQSeries
workflow and then expose them as Web services. Set up the users required for human intervention in
LDAP or any user directory. In this scenario, the arrival of a message (based on appropriate WebSphere
queues using JMS protocol) triggers the appropriate business workflow.
• The loan approver interacts with various service providers to check the loan requestor credit history. To
implement this, route SOAP requests to multiple service providers using WebSphere Business Integration
Message Broker. Then consolidate multiple SOAP responses and provide the results to loan approver.
• Once the loan is approved, route the loan information to the appropriate WebSphere queue. The
WebSphere Business Integration Adapter listening on the queues picks up the message from the queue,
maps a message to the business object, which in turn is used to create the loan record in the legacy
system.

Benefits of ESB
Today's fast-paced business world demands the ability to change and adapt rapidly. With an Enterprise Service
Bus, you can integrate your business applications and processes quickly and easily as you respond to business
challenges and opportunities when they arise.
The ESB pattern can improve operational performance and reduce costs while it simplifies the task of connecting
dissimilar applications across a network of different operating systems using open standards such as SOAP, XML,
WSDL, JMS, J2EE, JAX-RPC, and others.
New to WebSphere and SOA
How WebSphere products fit into a service-oriented architecture solution

Service-oriented architecture. SOA. It's all the buzz! But what is it exactly and how can it help your company?
How does WebSphere® fit into an SOA solution? And where can you learn more? This page is a starting point for
you to learn more about SOA and WebSphere and how you can use them in an SOA solution.

What is SOA?
It seems, lately, that SOA is everywhere. But what exactly does it mean and why does it matter to your
business? As the name implies, SOA is an architecture--a business-centric IT architecture. The building blocks of
SOA are services, which represent discreet, repeatable, reusable business tasks. You can combine and re-
combine these tasks in many ways to build applications that integrate function from many sources to support
different business needs.
SOA can help your business:

• Reduce development cycles and costs

• Consolidate legacy parts into composite business processes
• Improve flexibility and make it easier to respond to and implement changes
• Automate business processes
• Respond to customers more quickly
• Link business processes to improve interaction

How do I get started with SOA and WebSphere?

Based on extensive field experience, IBM has defined five entry points for businesses getting started with SOA.
The entry points are divided into two categories: business-centric and IT-centric, and there are WebSphere
products to help you with each entry point.
The business-centric entry points are:
People
SOA helps you improve productivity by enabling you to collect and consolidate information into views that deliver
information and facilitate interaction in the context of a business process.
The following WebSphere products support the SOA People entry point:

• WebSphere Portal
• WebSphere Portlet Factory
• WebSphere Everyplace Deployment
• WebSphere Everyplace Connection Manager

Process
With SOA you can quickly deploy innovative business models with re-usable processes, which means you can
react fast to changing business needs.
The following WebSphere products support the SOA Process entry point:

• WebSphere Business Modeler

• WebSphere Business Monitor
• WebSphere Process Server
• WebSphere Integration Developer

Information
By delivering information as a service, SOA helps you improve business insight and reduce risk with trusted
information services delivered in-line and in-context.
The following WebSphere products support the SOA Information entry point:
 • WebSphere Federation Server
• WebSphere Product Center

The IT-centric entry points are:

Connectivity
When we talk about SOA connectivity, we're talking about the underlying connectivity that supports business-
centric SOA. Connectivity provides the ability to integrate service providers and consumers, and allows for the re-
use of services across multiple channels. WebSphere allows you to connect everything inside and outside your
company, which enables your SOA to deliver reliability and security with high performance and availability that
spans newly developed Web services and complex heterogeneous environments.
The following WebSphere products support the SOA Connectivity entry point:

• WebSphere Enterprise Service Bus (WebSphere ESB)

• WebSphere Message Broker and WebSphere Transformation Extender (WebSphere TX) for Message
Broker
• WebSphere DataPower SOA Appliances
• WebSphere MQ and MQ Extended Security Edition
• WebSphere Adapters

Re-use
With SOA, you can cut costs, reduce cycle times, and expand access to core applications through re-use of
services in various business applications. Use portfolio management to consider which assets you need to run
your company. Identify high-value existing IT assets and service-enable them for re-use. Satisfy remaining
business needs by creating new services. Finally, create a registry or repository to provide centralized access to
and control of these reusable services.
Some of the WebSphere products that support the SOA Re-use entry point are:

• WebSphere Application Server and WebSphere Application Server Community Edition

• WebSphere Service Registry and Repository
• WebSphere IP Multimedia Subsystem Connector (WebSphere IMS Connector)
• WebSphere Extended Deployment
• WebSphere Commerce

There is no "right" place to start with SOA. Where you start depends on your specific business needs. You can
use any one, or any combination of, these entry points to approach SOA incrementally. The IBM SOA Self-
Assessment can help you determine which entry points makes sense for you.

How does WebSphere support the SOA lifecycle?

Now that you understand the various SOA entry points you might choose, let's talk about how to start with your
own SOA project. IBM has defined four phases in the lifecycle of an SOA project. These phases make up the SOA
Foundation, which is a set of best practices, software, and patterns for implementing SOA in your business.
WebSphere products can help you with each phase of implementing an SOA project from model to deploy. The
phases of an SOA project are:
Model
During the model phase, you'll collect and assess your business needs and define your business processes. You'll
then design the services to support these processes. During this phase, you can use WebSphere Business
Modeler to build a model of your business and IT processes and goals. The model help you see whether the
resulting application meets your company's needs and can provide you with a benchmark for measuring business
performance.
Assemble
During the assemble phase, you create services out of existing assets, such as enterprise resource planning
(ERP) and financial systems, CICS applications and other solutions that run your business. If the necessary
function to support a business process doesn't exist, you can create and test a new service to deliver it. Once you
have the required services, you can combine them to create a business process. You can use the following
WebSphere products to help you with the assemble phase of an SOA project:

• WebSphere Portlet Factory helps you quickly and easily create and deploy portlets.
• WebSphere Integration Developer helps you assemble complex services into business processes.
 • WebSphere Service Registry and Repository enables you to store, access, and manage metadata to
support your SOA project.

Deploy
During the deploy phase, you configure your run-time environment to meet the service levels required by your
business processes. Then you can deploy it into a scalable, secure services environment. The services
environment is optimized to run critical business processes while having the flexibility to make dynamic updates
in response to changing business requirements. This service-oriented approach reduces the cost and complexity
associated with maintaining numerous point-to-point integrations. WebSphere provides many products to help
you with the deploy phase:

• WebSphere DataPower SOA Appliances are easy-to-deploy network devices that simplify, help secure,
and accelerate your XML and Web services deployments while extending your SOA infrastructure.
• WebSphere Process Server securely and consistently executes your critical business processes.
• WebSphere ESB provides standards-based Web Services connectivity and service-oriented integration.
• WebSphere Message Broker provides an advanced ESB that offers universal connectivity and any-to-any
data transformation, which allows for applications that do not conform to standards to connect to an
ESB.
• WebSphere Partner Gateway
• WebSphere Adapters provide predefined adapters and a build-your-own toolkit to help you quickly
integrate business applications into your SOA. The adapters service-enable your applications by
connecting them to the ESB, which powers your SOA.
• WebSphere Portal links people to information so they can execute tasks quickly and accurately, and
helps you quickly deploy content and applications in an SOA.
• WebSphere Everyplace Deployment extends SOA applications to the edge of your network.
• WebSphere Federation Server gives you access to disparate data sources and helps you build unified
business views.
• WebSphere Application Server and WebSphere Extended Deployment delivers the secure, reliable
application infrastructure you need for your SOA.

Manage
During the manage phase, you're concerned with establishing and maintaining service availability and response
times, as well as managing underlying services. By monitoring key performance indicators in real time, you can
get the information you need to help you prevent, isolate, diagnose and fix problems. Once you understand the
performance of your business processes, you can provide feedback to improve the business-process model as
needed. During th management phase, you also manage version control of the services that make up your
business processes.
One of the key products you can use to continuously monitor and improve your business processes is WebSphere
Business Monitor.