Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec A -- By Mathias Weske

Motivation and Terminology

In today’s business scenarios, companies increasingly join forces to combine
their services and products to provide added-value products to the market.
These products are typically realized by business processes, which in many
cases take advantage of the existing software infrastructures of the participating
companies.
Because business-to-business collaborations are quite complex, and any
failure in the collaboration might have an immediate effect on the operational
business of the company, the cooperation between companies should be designed
very carefully. Process choreographies can be used for this endeavour.
The requirements of process choreography development depend on the
number of interacting partners and the desired level of automation. In business
environments, where the cooperation of business partners is realized through
traditional means like fax messages being sent and read and understood by
humans, where humans can pick up the phone and settle any ambiguities,
detailed and formal process choreographies are not essential.
However, if the cooperation is to be realized—at least in part—by information
systems, so that a high level of automation is achieved, there need
to be unambiguous models that specify in detail the nature of the collaboration
of business partners in the context of a process choreography. These
considerations are illustrated by an example.
Consider a bidding scenario in which the owner of a car uses an auctioning
service to sell his car to the highest bidder. Potentially, thousands of people
can participate in the auction and place their bids. Such scenarios require
agreement on how the participants need to interact with each other in order
to avoid problems that could appear as the result of wrong interaction.
To illustrate the problems that could arise from erroneous interaction,
consider a collaboration involving process orchestrations run by two companies.
The first activity to be performed by Company 1 is receive activity A1.
This activity waits to receive a message sent by activity B2. Assuming that
communication is synchronous, i.e., the receive activity A1 is blocking, the
process orchestration run by Company 1 cannot proceed.
Analogously, Company 2 waits in activity A2 to receive a message from
activity C1 to be sent by Company 1. As a result, both process orchestrations
cannot proceed: they are stuck in a permanent deadlock situation. To avoid
these kinds of problems, the partners involved in a process choreography need
to agree on the process choreography.
The behaviours are valid because each
process instance will perform a set of activity instances before it completes.
Deadlock situations, infinite loops, and other types of undesired behaviour
cannot appear.
The problem encountered is due to links between send and receive activities
in the process orchestrations. As the example illustrates, the viewpoint of
an individual process orchestration does not suffice for reasoning about the
interaction between process orchestrations; a global view on the interactions
between process orchestrations is required.
At the metamodel level, the Process Choreography Metamodel is
shown which provides the concepts to express Process Choreographies at the
model level.
Concrete instances of process choreographies are called Process Conversations,
which appear at the instance level. A Process Choreography Language
provides constructs to express process choreographies based on a process
choreography metamodel.
Each interaction model is associated with two objects of the class Communication
Activity Model. Communication activity models are activity models
in process orchestrations that exhibit a communication behaviour by sending or receiving messages. For the time being we focus on simple interactions
involving two activities.
As with process orchestrations, we can distinguish between models and
instances. The term Process Conversation refers to the concrete messages that are exchanged
as specified in a given process choreography. Therefore, process choreographies
serve as conversation models. Each process conversation consists of
a set of Interaction Instances, each of which is the concrete realization of a
message exchange as specified by the associated interaction model. Each interaction
instance is associated with Communication Activity Instances, which
are the concrete activity instances that send and receive messages.