Implementation and Execution CIM to PIM Model Transforma-

This section presents the implementation of the software architectures coordination pat- ters, which we introduced in Section 4.1.2, in model transformations. These model transformations take EPCs as input and produce service-oriented models (PIM4SOA) as output.

Brokerless Architecture

Using the brokerless architecture (see Section 4.1.2 and Figure 4.3), ESs are derived from the CBP descriptions that interact through collaborations. These binary collab- orations are composed to more sophisticated collaborations and protocols. We have described and implemented the transformations rules for the brokerless architecture in [248] for EPC to BPDM model transformations. This version of BPDM [98, 218] is a predecessor of PIM4SOA. Hence, we will describe the transformation process for PIM4SOA via the Sourcing process of the case study’s example.

Figure 4.7: PIM4SOA model for brokerless architecture

From each PP of the Sourcing-CBP description, one ES is derived. As one can see in Figure 4.7 two service provider instances for PreliminarySOR and SADistribute are generated. For each pair of service providers that communicate, a collaboration is instantiated (PreSOR-SADist). The service providers participate in this collaboration via collaboration uses.

The collaborations of the ESs are realized via multiple binary collaborations. To avoid loss of information (especially about the complete Sourcing CBP description), these collaborations are grouped to composite collaborations (see Figure 4.8). In the example, the Sourcing composite collaboration is composed of the binary collaboration patterns between the ESs.

4.1 Transforming CIM to PIM 69

Collaborative Process

Collaborative Process

Composite Collaboration

Figure 4.8: PIM4SOA model using composite collaboration

Central Broker Architecture

Like for the brokerless architecture, we encoded the central broker architecture in trans- formations (cp. Section 4.1.2) from EPC to BPDM models (see [24, 25]). In this section we illustrate the transformation process via a PIM4SOA model that is generated from the Sourcing CBP model of the case study’s example.

The central broker architecture (see Figure 4.4) is realized by a coordinating exe- cutable broker process and several ESs in PIM4SOA. Like in the brokerless architec- ture, for each PP of the Sourcing CBP description one ES is generated, e.g. for the pro- cesses PremliniarySOR and SADistribute. These ESs do not directly communicate but exchange messages with a central broker component. The ESs communicate with a bro- ker service provider via separate collaborations (PreSOR-Borker and SADist-Broker). For the Sourcing CBP one executable service provider is instantiated that fulfils the centralised broker’s functionality (see the SourcingBroker in Figure 4.4). This broker service provider implements the coordination of the message exchange described by the SourcingCBP description.

Decentral Broker Architecture

To represent the decentral broker architecture (see Figure 4.5) with PIM4SOA models, one has to make use of the CBP extension of PIM4SOA described in Section 2.2.3. We present a model transformation from EPC cross-organisational business process de- scription to PIM4SOA. This model transformation realizes and implements the decentral broker architecture [26]. It is described by rules consisting of source and target patterns.

Transforming the CBP Structure The following rules (Rule 1.1-1.3) describe the procedure that transforms the structural part of the CBP description to PIM4SOA mod- els, e.g. the definitions of the ESs.

Collaborative Process Coll. Process PP PP

Central Broker

Figure 4.9: PIM4SOA instance central broker

Rule 1.1

Src: A CBP is modelled in an EPC with row display containing a swimlane concept. Trg: A collaboration process, which is an abstract service provider, is instantiated. Rule 1.2

Src: The EPC describing the CBP is structured by swimlanes separating the process

modules of the different participants.

Trg: For each swimlane a VP is instantiated and connected to the collaboration process

it participates in. The name of the VP, i.e. of the service provider, is the name of the department participating in the CBP and realizing roles of the collaboration.

Rule 1.3

Src: In the case the source and target process module of a control flow edge lie in

different swimlanes, there is a collaboration between the two roles represented by swimlanes.

Trg:

(a) For each pair of roles that collaborates according to the source pattern, one

collaboration and the two collaborating roles are instantiated. The two roles are assigned to the collaboration. For each pair of role that collaborates, one and only one collaboration is instantiated.

(b) Two VPs, which were derived from the swimlanes (Rule1.2), belong to the two

roles participating in the collaboration. For each of the two VPs a collaboration use is instantiated referencing the collaboration.

(c) Bindings are instantiated that specify for the collaboration uses, which roles of

VPs (boundRole) realize the roles of the collaboration (role).

In Figure 4.10 one can see the target PIM4SOA model that is generated by apply- ing the transformation rules 1.1-1.3 to the EPC model of the case study example (cp. Section 4.1.3). A collaboration process is instantiated for the Sourcing CBP modelled in Figure 4.6. The collaboration process is an abstract service provider. By apply- ing Rule 1.2 three VPs are generated, one for each organisation that takes part in the CBP, i.e. the engineering department of the OEM (Org1-ENG), the supplier relation- ship management of the PO, which is often the OEM (Org2-PU/SRM), and the customer relationship management of the SU (Org3-ENG/CRM).

An association connects the view process (+views) to the collaboration process (+col- laboration). For each pair of roles that collaborate in the Sourcing CBP, one collabora- tion and one role for each of the collaborating roles are instantiated for the PIM4SOA model (Rule 1.3a); in Figure 4.10 these are the roles OEM and PO. The participation of

4.1 Transforming CIM to PIM 71 VP VP VP CBP Collaborative Process

Figure 4.10: Application of transformation rules 1.1-1.3

the organisations’ departments in the collaboration is represented by collaboration uses that connect the VPs with the collaboration (Rule 1.3b). A binding (Rule 1.3c) is used to specify by which role (+boundRole) a service provider realizes a role (+role) (OEM) in collaboration.

Considering the decentral broker architecture depicted in Figure 4.5 the collabora- tion process of the PIM4SOA CBP-extension is a collaborative process as defined in Section 2.2.2. It represents the protocol description (message exchange) between the publicly visible abstract processes. These abstract processes are realized by the VPs that are executable service providers. The collaboration process is an abstract service provider and groups the VPs that belong to one CBP.

Transforming the CBP Behaviour Rule 2 describes the transformation of the be- havioural part of the CBP description to PIM4SOA models, i.e. the process flow of the CBP.

Rule 2

Src: A CBP is modelled in an EPC with row display based on a swimlane concept. Trg: For each VP, which has been derived from the CBP, a process is instantiated

describing the VPs behaviour. The control flow of the CBP description can be taken over with a few modifications to the VP’s behaviour description:

1. Each process module, belonging to the swimlane of the VP, is replaced by a view task.

2. ’Send’ and ’receive’ tasks are added to the control flow of the VP at the points, where the VP interacts with other VPs (i.e. where the source and the target pro- cess module of a control flow edge lie in different swimlanes).

3. The ’send’ and ’receive’ tasks reference the appropriate collaboration use with their collaborationUsePath. With the interactions represented by the tasks the VP takes apart in the collaboration.

4. All process modules which do not belong to the swimlane of the VP are removed from the process flow.

VP

abstract process the VP provides to the CBP

Figure 4.11: Application of transformation rule 2

Figure 4.11 shows the generation of VPs’ behaviour description at the example of the Org1-ENGview process. The behaviour of the view process, i.e. the service provider, is described by a process. This process consists of steps which are derived from the Sourcing CBP according to the algorithm described in Rule 2. Two view tasks Pre- liminarySORand OfferEvaluation(OEM) are instantiated for the corresponding process modules of the Sourcing CBP. Since the Org1-ENG VP has three interactions with other VPs, two times it invokes another process and one time it is invoked, two send and one receivetasks are added to the control flow of the VP that participates in the collabora- tions. In case of the Org1-ENG VP all tasks reference the same collaboration use, since the VP only participates in the OEM-PO collaboration. In Figure 4.11 the control flow is depicted in a simplified version for clarity reasons as arrows with dashed lines. It shows the complete description of the VP’s executable process. Those parts of the executable process that are relevant for publicly visible abstract process, are bound to the respective collaborative process (see Figure 4.10).

Connecting Private Processes to View Processes Rule 3.1 and Rule 3.2 connect the PPs and the VPs that are generated from ESs. This has to be done both for the structural and the behavioural part of the PIM4SOA model.

Rule 3.1

Src: VPs abstract from PPs and PP offer functionality to cross-organisational collabora-

tions with the help of VPs.

Trg: A VP references all PPs it abstracts. A PP references all VP over which it offers

func-tionality to cross-organisational collaborations.

Rule 3.2

Src: View tasks are used to describe the behaviour of a VP. They encapsulate tasks,

which describe the more detailed behaviour of PPs.

Trg: For each view tasks all tasks are reference the view task encapsulates.

The Org1-ENG VP is bound to two processes, PreliminarySOR and OfferEvalua- tion(OEM), by applying Rule 3.1 (see Figure 4.12). In addition the view tasks of the VP’s behaviour description reference the tasks of the PPs they abstract from (abstract-

4.2 Transforming PIM to PSM 73

VP

PP PP

Figure 4.12: Application of transformation rules 3.1-3.2

edSteps). For example the PreliminarySOR view tasks abstracts from the EstablishRe- quirementsand TargetSetting tasks.