Chapter 5

4/9/2013

1

Business Process MethodologyChapter 5- Process Choreographies

Prepared by:Rao Majid Shamshad

University of Education, Lahoreemail: [email protected]

http://bpm-ue.blogspot.com/

PROCESS CHOREOGRAPHIES

• business-to-business collaboration

• To realize these collaborations, processorchestrations interact with each other,typically by sending and receiving messages.

• ensuring interoperability between processorchestrations, each of which is performed bya participant in a business-to-businesscollaboration.

Prepared by Rao Majid Shamshad, UE Township campus, Lahore 2

STANDARDIZED CHOREOGRAPHIES

• RosettaNet for the supply chain domain,

• SWIFTNet for financial services,

• Health Level Seven (HL7) for health careservices.

They all define rules for the collaboration thatcompanies need to comply with in order tocollaborate with each other.


NEED & ADVANTAGES

• companies increasingly join forces to combine their services and products to provide added-value products to the market.

• costs for the individual companies are reduced

• New companies can join the market more easily,

• depend on the number of interacting partners and the desired level of automation.


mailto:[email protected]

http://bpm-ue.blogspot.com/

4/9/2013

2


• The first activity to be performed by Company 1 isreceive activity A1. This activity waits to receive amessage sent by activity B2. Assuming thatcommunication is synchronous, i.e., the receiveactivity A1 is blocking, the process orchestrationrun by Company 1 cannot proceed. Analogously,Company 2 waits in activity A2 to receive amessage from activity C1 to be sent by Company1. As a result, both process orchestrations cannotproceed: they are stuck in a permanent deadlocksituation. To avoid these kinds of problems, thepartners involved in a process choreography needto agree on the process choreography.


5.2 DEVELOPMENT PHASES

• Business engineers are mainly involved in thechoreography design phases, includingscenario modelling, domain scoping,milestone definition, and participantidentification. Business engineers areresponsible for business-related aspects of theprocess choreography; they need to makesure that the collaboration contributes to thegoals of the enterprise, similarly toorganizational business processes.

Prepared by Rao Majid Shamshad, UE Township campus, Lahore 7 Prepared by Rao Majid Shamshad, UE Township campus, Lahore 8

4/9/2013

3

• System architects are responsible for the

architectural aspects of the implemented process

choreography. System architects are at the border

of design and implementation, as sketched in

Figure 5.4. This means that they are involved in

the design of process choreographies as well as in

their implementation. In particular, they are

involved in the specification of the behavioral

interfaces, discussed later in this chapter.


• Once the process choreography design iscompleted, developers are responsible forrealizing the process orchestrations in a waythat the overall business-to-businesscollaboration as specified in the processchoreography is realized. Behavioral interfacesare important artifacts for designing theindividual process orchestrations.


SCENARIO MODELLING

• Scenario modelling is at the heart ofchoreography design: scenarios describe theoverall setting and goals of the processchoreography. They are also useful forintegrating the results of the other designphases. To model a particular scenario, adomain in which the cooperation will takeplace needs to be specified. This is performedduring the domain scoping phase by businessengineers.


• Formal notations are not required in scenariomodelling and domain scoping, so that thescenario and the domain can be described in alanguage that allows expressing the relevantconcepts. Depending on the specific setting ofthe project, plain English text enriched withinformally specified graphical diagrams can beused.


4/9/2013

4

PARTICIPANT IDENTIFICATION

• The participant identification phase is devotedto defining different roles of choreographyparticipants. There are two options for doingthis. These roles are specified in a way thatallows for the selecting of concrete processparticipants on the basis of their properties aslaid out in the participant roles. In the contextof process choreographies, the term processparticipant refers to an organization, ratherthan to an individual.


MILESTONE DEFINITION• In the milestone definition phase, the

participants define certain states of thechoreography in which the cooperation hasachieved certain results, typicallycharacterized by intermediate products. Thesestates are called milestones.

• Milestones and their ordering describebehavioral aspects of the choreography from ahigh level of abstraction.


MESSAGE IDENTIFICATION

• In the message identification phase, theinteractions in the scenario are used toidentify and design messages that realize thevarious interactions. This phase has businessaspects as well as technical aspects; it istherefore located on the border of the designand implementation of processchoreographies. The design aspects includethe business content of the messages, whilethe implementation aspects include thetechnical realization of these messages andconcrete message formats.


CHOREOGRAPHY DEFINITION PHASE

• Finally, the choreography definition phasecombines the message identification and themilestone definition phases of the modelledscenario.

• The result of this phase is a detailedspecification of the interactions between theparticipants, the messages to realize theinteractions, and the milestones that arereached during the resulting conversation inthe instance layer.


4/9/2013

5

• The choreography definition phase, just likethe message identification phase, includesbusiness aspects as well as technical aspects.Unsuccessful interaction behavior would ariseif, for instance, message formats were usedthat one or more participants would notunderstand. To avoid this problem, it isassumed that message formats as well as thesemantics of the messages are agreed uponby the participants.


• Domain standards, like the ones mentionedabove, are in place to provide a commonterminology, and, thereby, an understandingof the concepts used. These standards areenhanced with technical information, so thatdata structures and message formats areavailable. Business engineers, systemarchitects, and developers participate inchoreography definition and messageidentification.


BEHAVIORAL INTERFACES

• In the lower part of Figure 5.4, the phasesduring implementation of processchoreographies are shown. Based on thechoreography definition, behavioral interfacesof all roles in the process choreography aredefined. Behavioral interfaces serve asblueprints for the design of the individualprocess orchestrations realized by theparticipants of the process choreography.


5.3 PROCESS CHOREOGRAPHY DESIGN

• The design of process choreographies involvesa series of activities. In each of theseactivities, artefacts are developed. Theseactivities are described as follows:

1. High-level Structure Design: In high-levelchoreography design, the participant roles aswell as their communication structures areidentified. High level structure design isconducted during the Participantidentification phase.


4/9/2013

6

2. High-level Behavioural Design: High-levelbehavioural models specify the milestones ofthe collaboration and the order in which themilestones are reached. High-levelbehavioural design is done during themilestone definition phase.

Milestones have dependencies with respectto other milestones. For instance, the auctionhas to be set up before the bidding processcan be finished.



3. Collaboration Scenarios: High-levelchoreographies are refined by introducingdedicated collaboration scenarios that relate thereaching of milestones to the communicationbetween process participants. Collaborationscenarios are developed during the choreographydefinition phase, based on the scenariosinformally specified during scenario modelling.

In this phase, the interactions needed to proceedfrom one milestone to another are specified Oneor several collaboration scenarios show theinteractions and their dependencies that need tooccur between two milestones


4/9/2013

7


• Scenarios should be kept small, as it is easierto reach agreement on less complexinteraction behaviour.

• Additional scenario models might beintroduced to deal with special cases andexceptions.

• Behavioural Interfaces: From thesecollaboration scenarios, for each participantrole, a behavioral interface is derived.


• .


Compatibility• Compatibility is the ability of a set of

participants to interact successfully accordingto a given process choreography.

• Unsuccessful interaction behaviour couldarise, if, for instance, different messageformats were used in a collaboration and oneparticipant does not understand the contentof a message sent by another participant.

• Another source of incompatibility—which thissection will focus on—is due to wrong andmisaligned interactions.


4/9/2013

8

• If, for instance, a participant expects anotification at some point in its process beforeit can proceed, and none of the otherparticipants sends such a notificationmessage, then the process cannot continue,so a deadlock situation emerges. Compatibilityof interacting processes aims at avoiding thistype of undesired behavior due to erroneousinteractions between process orchestrations.


Structural Compatibility

• A process choreography is structurally compatibleif messages that can be sent by a participantcorrespond to messages that other participantscan receive. This property makes sure that allmessages that are sent can actually be receivedby participants. However, it does not rule out thatparticipants can receive additional messages thatnone of the partners can send.

• Different types of structural compatibility areintroduced to describe structural properties ofprocess choreographies.


1. Strong structural compatibility of a processchoreography is given if, for every messagethat can be sent there is a participant whocan receive it, and if for every message thatcan be received, there is a participant whocan send it.

2. Weak structural compatibility is given if allmessages sent by participants can bereceived by other participants. However, it isnot required that all messages thatparticipants can ever receive will actually besent by other participants.


5.4 PROCESS CHOREOGRAPHY IMPLEMENTATION

• After discussing the design of processchoreographies, this section looks at theimplementation of choreographies.Behavioural interfaces serve as blueprints forthe internal realization of processorchestrations, because each processorchestration needs to expose an externallyvisible behaviour that was specified as thebehavioural interface of the respectiveparticipant.


4/9/2013

9

5.5 SERVICE INTERACTION PATTERNSService interaction patterns can be classified according to

the following schemes.

• Number of participants involved: Bilateral interactions involve two participants, whereas multilateral interactions involve more than two participants.

• Number of messages exchanged: Single transmission versus multi-transmission interactions.

• Variations in message receiver : In case of two-way interactions, round-trip interaction means that the receiver of the message is necessarily the same as the sender, whereas routed interaction means that the receiver of the message in general differs from the sender.


• One-To-Many Send

• One-From-Many Receive

• One-To-Many Send/Receive

• Multi-Responses

• Contingent Requests

• Atomic Multicast Notification

• Request With Referral

• Relayed Request


Chapter 5

Technology

Transcript of Chapter 5