UNIT - II

Web services
Service descriptions
Messaging with SOAP
Message exchange Patterns
Coordination
Atomic Transactions
Business activities
Orchestration
Choreography
Service layer abstraction
Application Service Layer
Business Service Layer
Orchestration Service Layer

WEB SERVICES
SERVICES (AS WEB SERVICES) :
Definition :
Web-based applications that dynamically interact with other
Web applications using open standards that include XML,
UDDI and SOAP.
A Service-Oriented Architecture (SOA) is a collection of
services or software agents that communicate freely with
each other.
A Web service is a software application identified by a URI,
whose interfaces and binding are capable of being defined,
described and discovered by XML artefacts and supports
direct interactions with other software applications using
XML based messages via internet-based protocols

Current distributed infrastructure

Microsoft:
DCOM/COM+
SUN:
Java RMI
CORBA:
Try to be a standard specification ( but complex to use)
Disadvantages
Vendor Specific
Platform Specific
No interoperability
Configuring Firewalls

According to the SOA

A Web service is:
An interface that describes a collection of network
accessible operations
Described using a service description language
Published by making this service description available to
users
Found by sending queries to a registry matching service
descriptions
Bound-Invoked by using the information contained in the
service description
Composed with other services to create new services
(service orchestration)

 Fundamentally, every Web service can be

associated with:
a temporary classification based on the roles it
assumes during the runtime processing of a message
a permanent classification based on the
application logic it provides and the roles it assumes
within a solution environment

We explore both of these design classifications

in the following two sections:
service roles (temporary classifications)
service models (permanent classifications)

 SERVICE ROLES:
A Web service is capable of assuming different roles, depending on
the context within which it is used. For example, a service can act as
the initiator, relayer, or the recipient of a message.
The fundamental service roles are ,
Service provider
Service requestor
Intermediaries
Initial sender and ultimate receiver
Service compositions
Service provider
The service provider role is assumed by a Web service under the
following conditions:
The Web service is invoked via an external source, such as a
service requestor
service provider entity (the organization or individual
providing the Web service)
service provider agent (the Web service itself, acting as an
agent on behalf of its owner)

Figure shows the recipient of a request message, the Web service

is classified as a service provider.

 Service requestor ( Service Consumer )

Any unit of processing logic capable of issuing a request
message that can be understood by the service provider is
classified as a service requestor.
The Web service invokes a service provider by sending it a
message.
A service requestor can represent both the Web service
itself as well as the Web service owner
service requestor entity (the organization or individual
requesting the Web service)
service requestor agent (the Web service itself, acting as
an agent on behalf of its owner)

Figure The sender of the request message is classified as a

service requestor.

 Intermediaries:
Web services and service agents that route and process a
message after it is initially sent and before it arrives at its
ultimate destination are referred to as intermediaries or
intermediary services. Because an intermediary receives
and submits messages, it always transitions through service
provider and service requestor roles.
There are two types of intermediaries :
Passive intermediary
Active intermediaries

Figure shows the intermediary service transitions through service

provider and service requestor roles while processing a message.

 The first, known as a passive intermediary, is typically

responsible for routing messages to a subsequent location .It
may use information in the SOAP message header to
determine the routing path, or it may employ native routing
logic to achieve some level of load balancing
Figure 5.6. A passive intermediary service processing a
message without altering its contents.

 An active intermediaries also route messages to a forwarding

destination. Prior to transmitting a message, however, these
services actively process and alter the message contents.
Figure shows an active intermediary service.

 Initial sender and ultimate receiver

Initial senders are simply service requestors that initiate
the transmission of a message. Therefore, the initial sender
is always the first Web service in a message path.
The ultimate receiver identifies service providers that
exist as the last Web service along a message's path
Figure Web services acting as initial sender and ultimate
receiver

 Service compositions (service assemblies )

It composite relationship between a collection of services . Therefore, each
service that participates in a composition assumes an individual role of
service composition member
Figure A service composition consisting of four members

The concept of service composability is very important to service-oriented

environments.

 SERVICE MODELS:
The manner in which services are being utilized in the real
world, though, has led to a classification based on the nature of
the application logic they provide, as well as their businessrelated roles within the overall solution. These classifications
are known as service models.
The basic set of common service models.
Business service model
Utility service model
Controller service model
Business service model :
It encapsulates a distinct set of business logic within a
well-defined functional boundary. It is fully
autonomous .
Business services are used within SOAs as follows:
as fundamental building blocks for the representation
of business logic
to represent a corporate entity or information set
to represent business process logic
as service composition members

 Utility service model

Any generic Web service or service agent designed for
potential reuse can be classified as a utility service.
Utility services are used within SOAs as follows:
as services that enable the characteristic of reuse within
SOA
as solution-agnostic intermediary services
as services that promote the intrinsic interoperability
characteristic of SOA
as the services with the highest degree of autonomy
Controller service model
Controller services are used within SOAs as follows:
to support and implement the principle of composability
to leverage reuse opportunities
to support autonomy in other services
Note that controller services themselves can become
subordinate service composition members.

Figure shows a service composition consisting of a master

controller, a sub-controller, four business services, and one
utility service.

SERVICE DESCRIPTIONS (WITH WSDL)

The Web Services Description Language (WSDL) is the most
fundamental technology standard associated with the design of
services.
WSDL definitions are a central part of all aspects of service
design.
It consist of two definitions ,
Abstract definition
Concrete definition
The abstract definition contains a series of parts that include
types, message, and port type (or interface), whereas the
concrete definition is comprised of binding and service parts.

 WSDL and SOA :

The creation of WSDL definitions is an important part of
the SOA delivery lifecycle.
Key design issues of WSDL are ,
Standardized use of namespaces- Use standard name
space wsdl specification
Modular service definitions- WSDL supports the
capability for service definitions to be composed [ for
reuse and centralized maintenance ]
Compatibility of granularity - Service interface
granularity ideally corresponds to XML document
granularity

 Service endpoints and service descriptions :

A WSDL describes the point of contact for a service
provider, also known as the service endpoint or just
endpoint. It provides a formal definition of the endpoint
interface and also establishes the physical location
(address) of the service.
A WSDL service description (also known as WSDL service
definition or just WSDL definition) can be separated into
two categories:
abstract description
concrete description

Figure WSDL document consisting of abstract and concrete parts that

collectively describe a service endpoint

 Abstract description :
An abstract description establishes the interface
characteristics of the Web service without any reference to
the technology used to host or enable a Web service to
transmit messages.
Three main parts are ,
portType - a high-level view of the service interface
Operation - Each operation represents a specific action
performed by the service.
Message -Therefore, an operation consists of a set of
input and output messages

 Concrete description:
The execution of service application logic always involves
communication, the abstract Web service interface needs to
be connected to a physical transport protocol. This
connection is defined in the concrete description portion of
the WSDL file, which consists of three related parts:
Binding - describes the requirements for a service to
establish physical connection ( eg. SOAP )
Port ( end point ) It represent the physical address at
which a service can be accessed with a specific protocol.
Service It is used to refer to a group of related
endpoints.

 Metadata and service contracts:

Metadata :
Each of these three( WSDL definition,XSD schema and
policy) service description documents can be classified as
service metadata, as each provides information about the
service.
Service Contracts :
A set of conditions that must be met and accepted by a
potential service requestor to enable successful
communication.

Figure A service contract comprised of a collection of service

descriptions and possibly additional documents.

 Semantic descriptions:
The most challenging part of providing a complete
description of a Web service is in communicating its
semantic qualities.
Examples of service semantics include:
how a service behaves under certain conditions
how a service will respond to a specific condition
what specific tasks the service is most suited for
Service description advertisement and discovery:
These repositories allow humans (and even service
requestors) to:
locate the latest versions of known service descriptions
discover new Web services that meet certain criteria

 Private( Own orgn.) and public( any Orgn.) registries

Service descriptions can be dynamically discovered by humans or
applications, using private or public service registries.

Figure Service description locations centralized in a registry.

 Binding templates and tModels

Registry records follow the same logic in that they store
binding information in a separate area, called the binding
template.
The tModel section of a UDDI record provides pointers to
actual service descriptions

 WSDL Elements
The definitions element
This is the root or parent element of every WSDL document. (
contains service definition & location )
For Example,
<definitions name="Employee"
targetNamespace="[Link]
xmlns="[Link]
</definitions>

The types element

The types construct is where XSD schema content is placed.
to represent the XML content of message bodies
For exmaple,
</schema>
<complexType name="ReturnCodeType">
<sequence>

<element name="Code" type="xsd:integer"/>

<element name="Message" type="xsd:string"/>
</sequence>
</complexType>
</schema>

 The message and part elements

For every message a service is designed to receive or transmit, a message
construct must be added. This element assigns the message a name and
contains one or more part child elements that each are assigned a type
For Example ,
<message name="getEmployeeWeeklyHoursRequestMessage">
<part name="RequestParameterelement="act:EmployeeHoursRequestType"/>

</message>
<message name="getEmployeeWeeklyHoursResponseMessage">
<part name="ResponseParameter element="act:EmployeeHoursResponseType"/>
</message>

The portType, interface, and operation elements

Service operations are defined within the portType area of the WSDL definition.
For example,
<portType name="EmployeeInterface">
<operation name="GetWeeklyHoursLimit">
... </operation>
<operation name="UpdateHistory">
...
</operation>
</portType>

 The input and output elements (when used with operation)

That represent the request and response messages the
operation is capable of processing.
<operation name="GetWeeklyHoursLimit">
<input message="tns:getWeeklyHoursRequestMessage"/>
<output message="tns:getWeeklyHoursResponseMessage"/>
</operation>

MESSAGING WITH SOAP

1. Messages:
Simple Object Access Protocol, the SOAP specification's
main purpose is to define a standard message format.
Envelope, header, and body
Every SOAP message is packaged into a container known as an
envelope. The envelope is responsible for housing all parts of the
message.
Each message can contain a header, an area dedicated to hosting meta
information.
The actual message contents are hosted by the message body, which
typically consists of XML formatted data.

Fig .The basic structure of SOAP

Message .

 The SOAP envelope

The SOAP <Envelope> is the root element in every SOAP
message, and contains two child elements, an optional
<Header> and a mandatory <Body>.

The SOAP header

The SOAP <Header> is an optional sub-element of the SOAP
envelope, and is used to pass application-related information
that is to be processed by SOAP nodes along the message path.

The SOAP body

The SOAP <Body> is a mandatory sub-element of the SOAP
envelope, which contains information intended for the ultimate
recipient of the message.

The SOAP fault

The SOAP <Fault> is a sub-element of the SOAP body, which is
used for reporting errors.

Header blocks

 Header blocks includes

processing instructions that may be executed
by service intermediaries or the ultimate
receiver
routing or workflow information associated
with the message
security measures implemented in the
message
reliability rules related to the delivery of the
message
context
and
transaction
management
information

 2. Nodes
The programs that services use to transmit and receive
SOAP messages are referred to as SOAP nodes.
Fig. A SOAP node transmitting a SOAP message received by
the service logic.

SOAP nodes must conform to the processing standard set forth

in the versions of the SOAP specification they support.

 It is what guarantees that a SOAP message sent by the SOAP

node from service A can be received and processed by a SOAP
node (supporting the same version of the SOAP standard) from
any other service.
Node types
SOAP sender - a SOAP node that transmits a message
SOAP receiver - a SOAP node that receives a message
SOAP intermediary - a SOAP node that receives and
transmits a message, and optionally processes the message
prior to transmission
initial SOAP sender - the first SOAP node to transmit a
message
ultimate SOAP receiver - the last SOAP node to receive a
message

 Fig. Different types of SOAP nodes involved

with processing a message

 3. Message paths:
A message path refers to the route taken by a message
from when it is first sent until it arrives at its ultimate
destination. Therefore, a message path consists of at least
one initial sender, one ultimate receiver, and zero or more
intermediaries.
Fig. A message path consisting of three Web services.

 A SOAP message path is comprised of a

series of SOAP nodes, beginning with the
initial SOAP sender and ending with the
ultimate SOAP receiver. Every node refers
to a physical installation of SOAP
software, each with its own physical
address.

Fig. A message path determined at runtime

MESSAGE EXCHANGE PATTERNS

Every task automated by a Web service can differ in both
the nature of the application logic being executed and the
role played by the service in the overall execution of the
business task.
Figure Not all message exchanges require both requests and
responses.

 Message exchange patterns (MEPs) represent a set of

templates that provide a group of already mapped out
sequences for the exchange of messages. The most common
example is a request and response pattern.
1. Primitive MEPs:
As a result, a common set of primitive MEPs has been in
existence for some time.
Request-response
Complex MEPs
Request-response
defines synchronous communication
The request-response MEP establishes a simple exchange
in which a message is first transmitted from a source
(service requestor) to a destination (service provider).
Upon receiving the message, the destination (service
provider) then responds with a message back to the source
(service requestor).

Figure The request-response MEP

Fire-and-forget
This simple asynchronous pattern is based on the
unidirectional transmission of messages from a source to one
or more destinations .

 A number of variations of the fire-and-forget MEP

exist, including:
The single-destination pattern, where a source sends a
message to one destination only.
The multi-cast pattern, where a source sends messages to
a predefined set of destinations.
The broadcast pattern, which is similar to the multi-cast
pattern, except that the message is sent out to a broader
range of recipient destinations.

Complex MEPs :([Link] into larger

patterns )
Primitive MEPs can be assembled in various
configurations to create different types of
messaging models, sometimes called complex
MEPs.

 A classic example is the publish-and-subscribe

model.
Step 1.
The subscriber sends a message to notify the publisher that
it wants to receive messages on a particular topic.

Step 2.
Upon the availability of the requested information, the
publisher broadcasts messages on the particular topic to all
of that topic's subscribers.

 MEPs and SOAP :

The SOAP standard provides a messaging framework
designed to support single-direction message transfer.
MEPs and WSDL:
- MEPs play a larger role in WSDL service
descriptions as they can coordinate the input and output
messages associated with an operation.
In WSDL 1.1 terms, they are represented as follows:
Request-response operation Upon receiving a message,
the service must respond with a standard message or a
fault message.
Solicit-response operation Upon submitting a message
to a service requestor, the service expects a standard
response message or a fault message.
One-way operation The service expects a single
message and is not obligated to respond.
Notification operation The service sends a message and
expects no response

 MEP support to eight patterns :

The in-out pattern, comparable to the requestresponse MEP
The out-in pattern, which is the reverse of the
previous pattern where the service provider
initiates the exchange by transmitting the
request .
The in-only pattern, which essentially supports
the standard fire-and-forget MEP.
The out-only pattern, which is the reverse of the
in-only pattern.

 The robust in-only pattern, a variation of the inonly pattern that provides the option of launching a
fault response message as a result of a transmission
or processing error.
The robust out-only pattern, which, like the outonly pattern, has an outbound message initiating
the transmission. The difference here is that a fault
message can be issued in response to the receipt of
this message.
The in-optional-out pattern, which is similar to the
in-out pattern with one exception.
The out-optional-in pattern is the reverse of the inoptional-out pattern, where the incoming message
is optional. Fault message generation is again
supported.

COORDINATION
A framework is required to provide a means for context
information in complex activities to be managed,
preserved and/or updated, and distributed to activity
participants. Coordination establishes such a framework .
It Includes ,
The complexity of an activity can relate to a number of
factors, including:
the amount of services that participate in the activity
the duration of the activity
the frequency with which the nature of the activity
changes
whether or not multiple instances of the activity can
concurrently exist

 Fig . Coordination provides services that introduce

controlled structure into activities

 1. Coordinator composition:
WS-Coordination provides a sophisticated context
management system that may be leveraged by WS-BPEL.
Figure The coordinator service composition
The coordinator composition consists of the following
services:
Activation service - Responsible for the creation of a new
context and for associating this context to a particular
activity.
Registration service - Allows participating services to
use context information received from the activation
service to register for a supported context protocol.
Protocol-specific services - These services represent the
protocols supported by the coordinator's coordination
type .
Coordinator - The controller service of this composition,
also known as the coordination service.

 2. Coordination types and coordination protocols :

Each coordinator is based on a coordination type,
which specifies the nature and underlying logic of
an activity for which context information is being
managed. Coordination types are specified in
separate specifications.
The two coordination types
WS-AtomicTransaction and
WS-BusinessActivity

 Coordination contexts and coordination participants

A context created by the activation service is
referred to as a coordination context. It contains a
collection of information that represents the
activity and various supplementary data.
Examples of the type of data held within a
coordination context include:
a unique identifier that represents the activity
an expiration value
coordination type information

 The activation and registration process :

The coordination service composition is
instantiated when an application service contacts
the
activation
service
Via
a
CreateCoordinationContext request message, it
asks the activation service to generate a set of new
context data.

 The completion process

The application service can request that a
coordination be completed by issuing a completion
request message to the coordination service.

 Coordination and SOA

It standardizes the management and interchange of
context information within a variety of key
business protocols.
Figure Coordination as it relates to other parts of
SOA.

ATOMIC TRANSACTIONS
Atomic transactions implement the familiar commit
and rollback features to enable cross-service
transaction support .

 1. ACID transactions
The protocols provided by the WS-AtomicTransaction
specification enable cross-service transaction functionality
comparable to the ACID-compliant transaction features
found in most distributed application platforms.
Atomic : Either all of the changes within the scope of the
transaction succeed, or none of them succeed. ( Roll Back
Feature )
Consistent : None of the data changes made as a result of
the transaction can violate the validity of any associated
data models.
Isolated : If multiple transactions occur concurrently, they
may not interfere with each other. Each transaction must be
guaranteed an isolated execution environment.

 Durable : Upon the completion of a successful transaction,

changes made as a result of the transaction can survive
subsequent failures
2. Atomic transaction protocols :
To participate in an atomic transaction, a service first
receives a coordination context from the activation service.
It can subsequently register for available atomic transaction
protocols.
The following primary transaction protocols are
provided:
A Completion protocol, which is typically used to
initiate the commit or abort states of the transaction.
The Durable 2PC protocol for which services
representing permanent data repositories should register.
The Volatile 2PC protocol to be used by services
managing non-persistent (temporary) data.
Most often these protocols are used to enable a twophase commit (2PC) that manages an atomic
transaction across multiple service participants.

 3. The atomic transaction coordinator :

When WS-AtomicTransaction protocols are used, the
coordinator controller service can be referred to as an
atomic transaction coordinator.
Figure The atomic transaction coordinator service model.

 4. The atomic transaction process :

It bases this decision on feedback it receives from all of the
transaction participants.
The collection of this feedback is separated into two
phases. During the prepare phase (Figure ), all
participants are notified by the coordinator, and each is
asked to prepare and then issue a vote. Each participant's
vote consists of either a "commit" or "abort" request (
Figure ).

Fig. The coordinator requesting that

transaction participants prepare to vote

 Fig .The transaction participants voting on

the outcome of the atomic transaction

 After the votes are collected, the atomic transaction

coordinator enters the commit phase. It now reviews all votes
and decides whether to commit or rollback the transaction.
The conditions of a commit decision are simple:
if all votes are received and if all participants voted to
commit, the coordinator declares the transaction
successful, and the changes are committed.
However, if any one vote requests an abort, or if any of the
participants fail to respond, then the transaction is
aborted, and all changes are rolled back

Figure The coordinator aborting the

transaction and notifying participants to
rollback all changes

 5. Atomic transactions and SOA

Atomic transactions therefore play an important role in
ensuring quality of service.
Figure Atomic transaction relating to other parts of SOA.

BUSINESS ACTIVITIES
Business activities govern long-running, complex service
activities. Hours, days, or even weeks can pass before a
business activity is able to complete.
A business activities provide an optional compensation
process that, much like a "plan B," can be invoked when
exception conditions are encountered

Figure A business activity controls the integrity of a service activity by providing participants
with a "plan B" (a compensation).

Business activity protocols

It provides two very similar protocols, each of which dictates
how a participant may behave within the overall business
activity.
The BusinessAgreementWithParticipantCompletion
protocol, which allows a participant to determine when it
has completed its part in the business activity.
The BusinessAgreementWithCoordinatorCompletion
protocol, which requires that a participant rely on the
business activity coordinator to notify it that it has no
further processing responsibilities.

 The business activity coordinator

When its protocols are used, the WS-Coordination
controller service assumes a role specific to the
coordination type in this case it becomes a business activity
coordinator

Figure The business activity coordinator service model

 Business activity states

During the lifecycle of a business activity, the business activity
coordinator and the activity participants transition through a
series of states
completed notification
A participant can indicate that it has completed the
processing by an activity .
This moves the participant from an active state to a completed
state.
Completed State - participant know that the business activity is
being successfully completed.
Participants can enter a compensation state during which they
attempt to perform some measure of exception handling.
It is a separate compensation process that could involve a series
of additional processing steps.

 A cancelled state can be entered. This typically results in the

termination of any further processing outside of the
cancellation notifications that need to be distributed.
An exit state by issuing an exit notification message to the
business activity coordinator.

Business activities and atomic transactions

It is important to note that the use of a business activity does
not exclude the use of atomic transactions. In fact, it is likely
that a long-running business activity will encompass the
execution of several atomic transactions during its lifetime

Fig. Two atomic transactions residing within the scope of a business activity

Business activities and SOA

Through the use of the compensation process, business
activities increase SOA's quality of service by providing builtin fault handling logic.

Figure A business activity relating to other parts of SOA

ORCHESTRATION

In these systems, a centrally controlled set of workflow logic facilitates

interoperability between two or more different applications. A common
implementation of orchestration is the hub-and-spoke model that allows
multiple external participants to interface with a central orchestration
engine.
Key Points :
Orchestration bridges this gap by introducing new workflow
logic(abstracted).
Orchestration can significantly reduce the complexity of solution
environments.
Orchestration can represent and express business logic in a
standardized, services-based venue.
Therefore, building upon orchestration logic standardizes process
representation across an organization, while addressing the goal of
enterprise federation and promoting service-orientation.

Figure An orchestration controls almost every facet of a complex activity.

A primary industry specification that standardizes

orchestration is the Web services Business Process Execution
Language (WS-BPEL).
Note :
WS-BPEL is the most recent name given to this
specification, which also is known as BPEL4WS and just BPEL.

 Business protocols and process definition

An orchestration establish a business protocol that defines
how participants can interoperate to achieve the completion
of a business task.
The details of the workflow logic encapsulated and
expressed by an orchestration are contained within a
process definition.
Process services and partner services
Identified and described within a process definition are the
allowable process participants. First, the process itself is
represented as a service, resulting in a process service.
Other services allowed to interact with the process service
are identified as partner services or partner links.

Figure A process service coordinating and exposing functionality from three partner services.

Figure The process service, after first being invoked by a partner service, then invokes another
partner service.

 Basic activities and structured activities

WS-BPEL breaks down workflow logic into a series of
predefined primitive activities. Basic activities (receive,
invoke, reply, throw, wait) represent fundamental workflow
actions which can be assembled using the logic supplied by
structured activities (sequence, switch, while, flow, pick).
Sequences, flows, and links
Sequence :
A sequence aligns groups of related activities into a list that
determines a sequential execution order. Sequences are
especially useful when one piece of application logic is
dependent on the outcome of another.
Flows :
Flows also contain groups of related activities, but they
introduce different execution requirements.

 Links :
Links are used to establish formal dependencies between
activities that are part of flows
Rules provided by links are also referred to as
synchronization dependencies.
ORCHESTRATIONS AND ACTIVITIES :
An activity is a generic term that can be applied to any logical
unit of work completed by a service-oriented solution. The
scope of a single orchestration, therefore, can be classified as
a complex, and most likely, long-running activity.
Orchestration and coordination
Orchestration, as represented by WS-BPEL, can fully utilize
the WS-Coordination context management framework by
incorporating the WS-BusinessActivity coordination

 Orchestration and SOA

Business process logic is at the root of automation
solutions. Orchestration provides an automation model
where process logic is centralized yet still extensible and
compassable

Figure Orchestration relating to other parts of SOA.

 The workflow logic within an orchestration is broken down

into a series of basic and structured activities that can be
organized into sequences and flows.
Orchestration has been called the "heart of SOA," as it
establishes a means of centralizing and controlling a great deal
of inter and intra-application logic through a standardized
service model.

CHOREOGRAPHY
A choreography is a complex activity comprised of a service
composition and a series of MEPs.
Choreographies consist of multiple participants that can
assume different roles and that have different relationships.
Choreographies are reusable, composable, and can be
modularized.
The Web Services Choreography Description Language
(WS-CDL) is one of several specifications that attempts to
organize information exchange between multiple organizations

Figure A choreography enables collaboration between its participants.

 Collaboration
An important characteristic of choreographies is that they
are intended for public message exchanges.
The goal is to establish a kind of organized collaboration
between services representing different service entities,
only no one entity (organization) necessarily controls the
collaboration logic.
Roles and participants
Within any given choreography, a Web service assumes one
of a number of predefined roles. This establishes what the
service does and what the service can do within the context
of a particular business task. Roles can be bound to WSDL
definitions, and those related are grouped accordingly,
categorized as participants (services).

 Relationships and channels

Every action that is mapped out within a choreography can be
broken down into a series of message exchanges between two
services. Each potential exchange between two roles in a
choreography is therefore defined individually as a relationship.
Every relationship consequently consists of exactly two roles.
Channels do exactly that by defining the characteristics of the
message exchange between two specific roles.
Interactions and work units
Interactions are the fundamental building blocks of
choreographies because the completion of an interaction
represents actual progress within a choreography.
Related to interactions are work units. These impose rules and
constraints that must be adhered to for an interaction to
successfully complete.

 Reusability, composability, and modularity

A choreography can be assembled from independent
modules. These modules can represent distinct sub-tasks
and can be reused by numerous different parent
choreographies

Figure A choreography composed of two smaller choreographies.

 Orchestrations and choreographies

An orchestration expresses organization-specific business workflow.
This means that an organization owns and controls the logic behind an
orchestration, even if that logic involves interaction with external
business partners.
A choreography, on the other hand, is not necessarily owned by a
single entity. It acts as a community interchange pattern used for
collaborative purposes by services from different provider entities.

Figure A choreography enabling collaboration between two different orchestrations.

 One can view an orchestration as a business-specific

application of a choreography.
An orchestration is based on a model where the
composition logic is executed and controlled in a
centralized manner.
Choreography and SOA
Two services within a single organization, each exposing a
simple function, can interact via a basic MEP to complete a
simple task. Two services belonging to different
organizations, each exposing functionality from entire
enterprise business solutions, can interact via a basic
choreography to complete a more complex task. Both
scenarios involve two services, and both scenarios support
SOA implementations.

Figure Choreography relating to other parts of SOA.

SERVICE LAYER ABSTRACTION

In an enterprise model, the service interface layer is located
between the business process and application layers. This is
where service connectivity resides and is therefore the area of
our enterprise wherein the characteristics of SOA are most
prevalent.
To implement the characteristics we just identified in an
effective manner, some larger issues need to be addressed.
Specifically, we need to answer the following questions:
What logic should be represented by services?
How should services relate to existing application logic?
How can services best represent business process logic?
How can services be built and positioned to promote agility?

 What logic should be represented by services?

In existing ,we established that enterprise logic can be
divided into two primary domains: business logic and
application logic. Services can be modeled to represent
either or both types of logic, as long as the principles of
service-orientation can be applied.
This allows the automated representation of business
process logic to evolve independently from the technologylevel application logic responsible for its execution.
In other words, this establishes a loosely coupled
relationship between business and application logic.

 How should services relate to existing application logic?

Existing systems can impose any number of constraints,
limitations, and environmental requirements that need to be
taken into consideration during service design.
Applying a service layer on top of legacy application
environments may even require that some serviceorientation principles be compromised.
Services designed specifically to represent application
logic should exist in a separate layer.

 How can services best represent business logic?

Business logic is defined within an organization's business
models and business processes.
It is also useful to separately categorize services that are
designed in this manner.
How can services be built and positioned to promote agility?
The key to building an agile SOA is in minimizing the
dependencies each service has within its own processing logic.
Services that contain business rules are required to enforce and
act upon these rules at runtime.
Abstraction is the key :
The three layers of abstraction we identified for SOA are:
The Application Service Layer
The Business Service Layer
The Orchestration Service Layer

Figure The three primary service layers.

APPLICATION SERVICE LAYER

The application service layer establishes the ground level
foundation that exists to express technology-specific
functionality. Services that reside within this layer can be
referred to simply as application services .
Their purpose is to provide reusable functions related to
processing data within new or legacy application environments.
Application services commonly have the following characteristics:

they expose functionality within a specific processing context

they draw upon available resources within a given platform
they are solution-agnostic
they are generic and reusable
they can be used to achieve point-to-point integration with other application
services
they are often inconsistent in terms of the interface granularity they expose
they may consist of a mixture of custom-developed services and third-party
services that have been purchased or leased

 Typical examples of service models implemented as

application services include the following:
utility service
wrapper service (explained shortly)
The application service layer consists of application services
that represent technology-specific logic.
Typical incarnations of application services are the utility and
wrapper models.
Application services are ideally reusable utility services
composed by business services, but also can exist as hybrid
services that contain both business and application logic.

Figure The application service layer

BUSINESS SERVICE LAYER

The business service layer is comprised of business services, a
direct implementation of the business service model.
Business services are ideally also controllers that compose
application services to execute their business logic.
Even though hybrid services contain business logic, they are
not classified as business services
While application services are responsible for representing
technology and application logic, the business service layer
introduces a service concerned solely with representing
business logic, called the business service.

 They are responsible for expressing business logic through

service-orientation and bring the representation of corporate
business models into the Web services arena.
Business services, on the other hand, are always an
implementation of the business service model. The sole
purpose of business services intended for a separate business
service layer is to represent business logic in the purest form
possible.
In fact, when application logic is abstracted into a separate
application service layer, it is more than likely that business
services will act as controllers to compose available
application services to execute their business logic.

 Business service layer abstraction leads to the creation of two

further business service models:
Task-centric business service : A service that encapsulates
business logic specific to a task or business process. This
type of service generally is required when business process
logic is not centralized as part of an orchestration layer.
Task-centric business services have limited reuse potential.
Entity-centric business service : A service that
encapsulates a specific business entity (such as an invoice
or timesheet). Entity-centric services are useful for creating
highly reusable and business process-agnostic services that
are composed by an orchestration layer or by a service
layer consisting of task-centric business services (or both).

ORCHESTRATION SERVICE LAYER

The orchestration service layer consists of one or more process
services that compose business and application services according to
business rules and business logic embedded within process definitions.
Orchestration abstracts business rules and service execution sequence
logic from other services, promoting agility and reusability.
Orchestration is more valuable to us than a standard business process,
as it allows us to directly link process logic to service interaction
within our workflow logic.
This combines business process modeling with service-oriented
modeling and design. And, because orchestration languages (such as
WS-BPEL) realize workflow management through a process service
model, orchestration brings the business process into the service layer,
positioning it as a master composition controller.

Figure The orchestration service layer

 The orchestration service layer introduces a parent level of

abstraction that alleviates the need for other services to
manage interaction details required to ensure that service
operations are executed in a specific sequence. Within the
orchestration service layer, process services compose other
services that provide specific sets of functions, independent of
the business rules and scenario-specific logic required to
execute a process instance.