Web Services and Contemporary SOA Part I: Activity Management and Composition

1
Chapter 6

• Web Services and Contemporary SOA (Part I
  Activity Management and Composition)

2
Table of Contents

• Introduction
• 6.1 Message Exchange Patterns
• 6.2 Service Activity
• 6.3 Coordination
• 6.4 Atomic Transactions
• 6.5 Business Activities
• 6.6 Orchestrations
• 6.7 - Choreography

3
Introduction

• To execute an automated business task, we must
  coordinate and compose a set of available
  services.
• This requires that we have control over messaging
  that occurs between the composed services.
• This chapter explains the concepts that define
  the message-based services activity model.
• It also discusses the role and context of
  concepts derived from WS- specifications that
  implement standardized activity management and
  composition mechanisms.

4
6.1 Message exchange patterns

• Regardless of how complex a business task is,
  almost all require the transmission of multiple
  messages.
• The challenge is in coordinating the messages in
  a particular sequence so the individual actions
  performed by the message are executed properly
  and in alignment with the overall business tasks.

5
Message Exchange Patterns (MEPs)
Represent a set of templates that provide a group
of already mapped out sequences for the exchange
of messages
6
Primitive MEPs

• Before the arrival of contemporary SOA
• A common set of primitive MEPs have been in
  existence for some time
• Request-response
• Fire-and-forget
• Complex MEPs

7
Request and Response
The most common example is a request and response
pattern In plain English an MEP is like a type
of conversation. Its not a long conversation
it actually only covers one exchange between two
parties. Establishes a simple exchange a
message is first transmitted from a source
(service requestor) to a destination (service
provider). Upon receipt, the destination then
responds with a message back to the source.
8
Fire-and-Forget

• Based on unidirectional transmission of messages
  from a source to one or more destinations
• Several variations
• Single-destination pattern a source sends a
  message to one destination only
• Multi-cast pattern a source sends messages to a
  predefined set of destinations
• Broadcast pattern similar to multi-cast, except
  that message is sent to a broader range of
  recipient destinations
• Fundamental characteristic a response to a
  transmitted message is not expected

9
Complex MEPs

• Primitive MEPs can be assembled in various
  configurations to create complex MEPs
• Classic example is the publish-and-subscribe
  model. Services involved with this model have
  new roles publishers and subscribers
• Two steps involved
• Step 1 subscriber sends message to notify
  publisher that it wants to receive messages on a
  particular topic
• Step 2 upon availability of requested
  information, publisher broadcasts messages on
  particular topic to all of the topics subscribers

10
Publish-and-subscribe model
11
MEPs and SOAP

• SOAP (Simple Object Acces Protocol) standard
  provides its own messaging framework to support
  single-direction message transfer
• Extensible nature of SOAP allows many messaging
  characteristics and behaviors to be implemented
  via SOAP header blocks

12
MEPs and WSDL

• MEPs play a larger role in WSDL service
  descriptions as they coordinate the input and
  output messages associated with an operation
• Within WSDL specification, theyre often simply
  referred to as patterns
• Release 1.1 of WSDL specification provides
  support for four message exchange patterns

13
Four message exchange patterns applied to service
operations

• Request-response upon receiving a message,
  service must respond with a standard message or a
  fault message
• Solicit-response upon submitting a message to a
  service requestor, service expects a standard
  response message or fault message
• One-way service expects a single message and is
  not obligated to respond
• Notification service sends a message and expects
  no response

14
The four message exchange patterns
15
MEPs and SOA

• Individually, MEPs simply relate to an
  interaction between two services
• They are a fundamental and essential part of any
  Web services-based environment, including SOA

16
6.2 Service Activity

• Completion of business tasks is an obvious
  function of any automated solution
• Tasks are comprised of processing logic that
  executes to fulfill a number of business
  requirements
• In service-oriented solutions, each task can
  involve any number of services
• Interaction of a group of services working
  together to complete a task is a service activity

17
Multiple web services collaborating to do work
18
Primitive and complex service activities

• Simple or primitive activity is typified by
  synchronous communication and thus consist of two
  services exchanging information using a standard
  request-response MEP
• Complex activities can involve many services (and
  MEPs) that collaborate to complete multiple
  processing steps over a long time.

19
Service activities and SOA

• Scope of a service activity is primarily
  concerned with the processing and communication
  between services only
• Underlying application logic of each Web service
  is generally not mapped as part of a service
  activity.

20
6.3 - Coordination

• Something that is happening or executing has
  meaning during its lifetime, and description of
  its meaning is classified as context information
• More complex an activity, the more context
  information it brings with it.

21
Complexity of an activity

• The complexity of an activity can relate to
  various factors, including the
• Amount of services participating in the activity
• Duration of the activity
• Frequency with which nature of activity changes
• Whether or not multiple instances of activity can
  concurrently exist

22
Coordination
23
Coordinator composition

• The coordinator composition consists of the
  following services
• Activation service creates a new context and
  associates this context with a particular
  activity
• Registration service allows participating
  services to use context information to register
  for a supported context protocol
• Protocol-specific services represent protocols
  supported by the coordinators coordination type
• Coordinator controller service of this
  composition, also known as the coordination
  service

24
Coordination types and 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 type extensions provide a set of
  coordination protocols, which represent unique
  variations of coordination types and consist of a
  collection of specific behaviors and rules

25
Coordination contexts and coordination
participants

• A context created by the activation service is
  referred to as a coordination context
• Types of data held within a coordination context
  include
• Unique identifier that represents the activity
• Expiration value
• Coordination type information
• A service that wants to take part in an activity
  managed by WS-Coordination must request the
  coordination context from the activation service

26
Activation and registration process

• Coordination service composition is initiated
  when an application service contacts the
  activation service
• Via a CreateCoordinationContext request message,
  it asks the activation service to generate a new
  set of context data
• Once passed back with the ReturnContext message,
  the application service now can invite other
  services to participate in the coordination
• Any Web service in possession of this context
  information may issue a registration request to
  the registration service

27
The registration process
The WS-coordination registration process
28
The completion process
The application service can request that a
coordination be completed by issuing a completion
request message to the coordination service, as
depicted above
29
Coordination as it relates to other parts of SOA
30
6.4 Atomic transactions
Atomic transactions implement the familiar commit
and rollback features to enable cross-service
transaction support
31
ACID Transactions

• ACID represents
• Atomic either all of the changes within the
  scope of the transaction succeed, or none of them
  succeed. This introduces the need for the
  rollback feature responsible for restoring any
  changes completed as part of a failed transaction
  to their original state.
• 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 must not interfere with each
  other
• Durable upon completion of a successful
  transaction, changes made as a result of the
  transaction can survive subsequent failures

32
Atomic transaction protocols

• To participate in an atomic transaction, a
  service first receives a coordination context
  from the activation service
• These primary transaction protocols are provided
• A Completion protocol, 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 data

33
The atomic transaction coordinator

• Coordinator controller service is referred to as
  this when WS-Atomic-Transaction protocols are
  used
• Plays a key role in managing the participants of
  the transaction process
• Tasked with responsibility of deciding the
  outcome of a transaction

34
Atomic transaction coordinator two phases

• Prepare phase during this, all participants are
  notified by the coordinator, and each is asked to
  prepare and then issue a vote. Votes are either
  a commit or abort request
• Commit phase after votes are counted, atomic
  transaction coordinator reviews all votes and
  decides whether to commit or rollback the
  transaction. If any one vote requests an abort,
  or if any participants fail to respond,
  transaction is aborted

35
Atomic transaction coordinator actions
36
Atomic transactions and SOA

• Being able to guarantee an outcome of an activity
  is a key part of enterprise-level computing
• Atomic transactional capabilities lead to a
  robust execution environment for SOA activities
  they also promote interoperability when extended
  into integrated environments

37
Atomic transaction relating to other parts of SOA
Allows the scope of an activity to span different
solutions built with different vendor platforms,
still guaranteeing an all or nothing outcome
38
6.5 Business activities

• They govern long-running, complex service
  activities
• Business activity distinguished from regular
  complex activity in that its participants are
  required to follow specific rules defined by
  protocols
• For example, business activities dont offer
  rollback capabilities, since they are
  long-running, they wouldnt be expected to offer
  ACID-type transaction functionality

39
Business activity protocols

• WS-BusinessActivity is a coordination type
  designed to leverage the WS-Coordination context
  management framework, providing two different
  protocols
• BusinessAgreementWithParticipantCompletion
  allows a participant to determine when it has
  completed its part of the business activity
• BusinessAgreementWithCoordinatorCompletion
  requires that a participant rely on the business
  activity coordinator to notify it that it has no
  further processing responsibilities.

40
Business activity coordinator

• WS-Coordination controller service assumes a role
  specific to the coordination type in this case
  it becomes a business activity coordinator

41
Business activity states

• During lifecycle of a business activity, the
  business activity controller and the activity
  participants transition through a series of
  states.
• The actual point of transition occurs when
  special notification messages are passed between
  these services

42
Business activity states (cont)

• Participant can indicate its completed the
  processing it was required to perform by issuing
  a completed notification, moving the participant
  from an active state to a completed state.
• If things dont go as planned during a business
  activity, several options available
• Participants can enter a compensation state
  during which they attempt to perform exception
  handling
• A cancelled state can be entered. Results in
  termination of any further processing outside of
  the cancellation notifications that need to
  distributed
• Participating services are not required to remain
  participants for the duration of the activity
  they may leave the business activity after their
  contributions have been performed. When doing
  so, participants enter an exit state by issuing
  an exit notification message to the business
  activity controller

43
Business activities and SOA
They fully complement the composable nature of
SOA by tracking and regulating complex activities
while also allowing them to carry on for long
periods of time Through use of the compensation
process, business activities increase SOAs
quality of service by providing built-in fault
handling logic
44
6.6 - Orchestration

• It is a centrally controlled set of workflow
  logic that facilitates interoperability between
  two or more different applications.
• A common implementation is the hub-and-spoke
  model that allows multiple external participants
  to interface with a central orchestration engine
• With orchestration, different processes can be
  connected without having to redevelop the
  solutions that originally automated the processes
  individually
• Orchestration bridges this gap by introducing new
  workflow logic and reducing the complexity of
  solution environments.
• Workflow logic is more easily maintained than
  when embedded within individual solution
  components.

45
Example of orchestration
Within SOA, orchestrations themselves exist as
services
46
Business protocols and process definition

• Workflow logic that comprises an orchestration
  can consist of numerous business rules,
  conditions, and events
• These parts of an orchestration establish a
  business protocol that defines how participants
  can interoperate to achieve completion of a
  business task

47
Sequences, flows and links

• Basic and structured activities can be organized
  so that the order in which they execute is
  predefined
• Flows contain groups of related activities, but
  they introduce different execution requirements
• Pieces of application logic can execute
  concurrently within a flow
• There is not a requirement for one set of
  activities to wait before another finishes
• Links are used to establish formal dependencies
  between activities that are part of flows Before
  an activity can complete, it must ensure that any
  requirements established in outgoing links first
  are met
• Rules provided by links are also referred to as
  synchronization dependencies

48
Orchestration and SOA

• Business process logic is at the root of
  automation solutions, and orchestration provides
  an automation model where process logic is
  centralized.
• Orchestrations themselves establish a common
  point of integration for other applications
• These lead to increased organizational agility
  because
• Workflow logic encapsulated by an orchestration
  can be modified or extended in a central location
• Positioning an orchestration centrally can
  significantly ease the merging of business
  processes
• By establishing potentially large-scale
  service-oriented integration architectures,
  orchestration can support the evolution of a
  diversely federated enterprise

49
Orchestration becomes the heart of SOA
50
6.7 - Choreography
The requirement for organizations to interoperate
via services is becoming increasingly real and
increasingly complex
51
Collaboration

• Choreographies are intended for public message
  exchanges
• Goal is to establish a kind of organized
  collaboration between services representing
  different service entities
• No one entity (organization) controls the
  collaboration logic

52
Components of choreographies

• Roles and participants
• Within a choreography, a Web service assumes one
  of a number of predefined roles
• Relationships and channels
• Every action within a choreography is broken down
  into a series of message exchanges between two
  services. Each potential exchange is defined as
  a relationship
• Interactions and work units
• Actual logic behind a message exchange is
  encapsulated within an interaction, which is the
  fundamental building block of choreographies

53
Reusability, composability, and modularity
Each choreography can be designed in a reusable
manner, allowing it to be applied to different
business tasks comprised of the same fundamental
actions
54
Orchestrations and choreographies

• Orchestration expresses organization-specific
  workflow. This means that an organization owns
  and controls the logic behind an orchestration,
  even if that logic involves interaction with
  external business partners
• Choreography is not necessarily owned by a single
  entity it acts as a community interchange
  pattern
• An orchestration can be viewed as a
  business-specific set of a choreography

55
Orchestrations and choreographies (cont)
Orchestration is based on a model where
composition logic is executed and controlled in a
centralized manner choreography typically
assumes there is no single owner of the
collaboration logic
56
Choreographies and SOA
Choreographies natively supports composabilty,
reusability, and extensibility, but can also
increase organizational agility and discovery