Integrating BPMN and SoaML - cs.vu.nlpatricia/Patricia_Lago/IBM_Course_files... · Associated BPMN...

Integrating BPMN and SoaML

Based on an example from SoaML spec

Motivation •  BPMN and SoaML are complimentary

–  Demand-side view: outward facing view of an entities value proposition, responsibilities and what it requires of others

–  Supply-side view: a design of the activities an entity has chosen to accomplish its goals and providing services to deliver its value

•  Together they address the organization, information and behaviors from different perspectives: –  SoaML: Structure of systems of collaborating systems –  BPMN: Dynamic behavior

Some requirements for Integrating BPMN and SoaML

•  Support the construction and consumption of services 1.  Identify SoaML Capabilities (or candidate services) from BPMN

processes 2.  Identify, specify and implement services using SoaML 3.  Use BPMN to define a method to implement an Operation of a

SoaML ServiceInterface provided by a Participant 4.  Invoke a service operation defined by a SoaML

ServiceInterface and provided by SoaML Participant as a ServiceTask in a BPMN process

5.  Share information specifications (classes, data types, messages) between BPMN and SoaML

6.  Use SoaML to define lifecycles for data objects in BPMN that can respond to business events

•  Separate the architecture of the services from the processes that drive or use them

Guiding Principles

•  Identify BPMN issues that: –  Would improve the quality of BPMN –  Would facilitate integration whenever or however we

decide to do it •  Minimize undesirable coupling between

specifications and metamodels •  Specifications should be able to be used

independently as well as together •  Minimize implementation vendor burden •  Focus on complimentary modeling capabilities,

not overlap

Approaches to Integration •  None

–  Assumes specifications and tools are independent with intentional overlap –  Does not leverage complimentary capabilities –  Document best practices for using each specification

•  Model-to-model Mapping –  Focuses on specification overlap –  Results in redundant models increasing life-cycle management and reconciliation

issues –  Minimal effect on integration tool support –  Can represent a CIM to PIM mapping –  Not clear this would need to be standardized as there could be different

mappings for different purposes •  Metamodel Integration

–  Provides best integration, but at higher development and integration costs –  Can be accomplished with a metamodel extension, separate bridging metamodel

using package merge, or possibly UML profiles –  Standardize on a shared ontology of BPM and SOA

Approach to defining the integration to meet the requirements

•  Identify topics fulfilling the requirements in a language independent manner, without regard to BPMN or SoaML

•  Start by developing a complete example using both standards –  Covers a set of topics including structure and behavior –  What services are provided and consumed by whom –  How the services are implemented and used

•  Use the example to explore commonality and variability •  Develop a mapping table (ok to have gaps and overlaps) •  Design an integration that exploits the strengths of each

specification •  Demonstrate how the integration satisfies the requirements •  Publish a discussion paper describing the integration and best

practices for using the BPMN and SoaML together •  Develop a roadmap to provide the proposed integration

Topics to Explore •  Encapsulation: Description of a encapsulating element

or “component” including its potential interactions with other prototypical components

•  Contract: Specification of the potential interactions between components that the agree to adhere to

•  Behavior: Representation of a component’s internal behavioral implementation (orchestration) –  How the component consumes and provides services according

to the agreed upon contract •  Structure: Internal structure of a component as an

assembly of other components –  How the components are connected in order for the interactions

to occur –  At the class level and/or part level

The description of a component’s interaction with other components

•  Interactions between components involve the following: – The specification of the messages exchanged – The grouping of those messages into logical,

cohesive units – The valid sequence, protocol or choreography

that constrains the order of those messages •  We need to look at how BPMN and

SoaML address each of these dimensions

Figure 84 “The OrderProcessor Service Provider” in SoaML

A Participant provides services through ServicPoints and

consumes them through RequestPoints

Participants must provide a method implementing each of their provided

service operations

A Service Port is typed by a

ServiceInterface and describes the expected

interactions the participant has

through this interaction point

A service port represents a capability the

participant exposes as a

service

A request port represents a

need the participant

expresses as a request for a

service

Interfaces define the available

operations that do things

InvoicingService ServiceInterface Specifies the

provided interface and operations

Specifies the required

interface and operation

A use case can describe the

requirements for the service interface A service interface can

define a role in a service contract

An activity (or interaction) can

specify the protocol for using and providing the

service

These parts represent the service and request ports at the end of a service channel

connector connecting consumers and providers of

the service

The activity shows the permissible sequence of

invocations of the operations

SoaML ServiceInterface defines the valid messages, message grouping and choreography and is used to define the type of Service and Request Ports

The activity partitions represent the parts of the

service contract, the participants connected

through a service channel

Associated BPMN 2.0 Collaboration O

rder

P

roce

ssor

Cus

tom

er

Sch

edul

er

Order

Invo

icer

PriceData

Shi

pper

Invoice

Price DataUpdate

Invoice

ShippingResponse

Schedule

ShippingRequest Schedule

RequestShedule

Response

Pools/Participants represent

PartnerEntities (at any level) and/or

PartnerRoles

The Message Flow are unordered and

ungrouped.Grouping by Conversation

can be hidden.

Associated BPMN 2.0 Conversation (Collaboration)

Ord

er

Pro

cess

or

Cus

tom

er

Sch

edul

er

Order

Invo

icer

Shi

pper

Invoice Shipping Schedule

Conversations group Message Flow based on

business level info or Correlation Keys

Associated BPMN 2.0 Conversation (showing mini-Choreography)

Ord

er

Pro

cess

or

Cus

tom

er

Sch

edul

er

Invo

icer

Shi

pper

Invoicer

Establish Price

Order Processor

Invoicer

Update Price

Order Processor

Invoicer

Create Invoice

Order Processor

PriceData

Price DataUpdate

Invoice

ScheduleShipping

Order

Associated BPMN 2.0 Choreographies (per Conversation)

Invoicer

Establish Price

Order Processor

Invoicer

Update Price

Order Processor

Invoicer

Create Invoice

Order Processor

PriceData

Price DataUpdate

Invoice

Scheduler

Organize Schedule

Order Processor

ScheduleRequest

SheduleResponse

Customer

Deliver Invoice

Order Processor

Customer

Order Product

Order Processor

Order

Order Shipping

Invoice Schedule

Shipper

Prepare Shipping

Order Processor

ShippingResponse

ScheduleShippingRequest

Shipper

Finalize Shipping

Order Processor

Encapsulated Conversation (and Choreography)

Invoicer

Establish Price

Order Processor

Invoicer

Update Price

Order Processor

Invoicer

Create Invoice

Order Processor

PriceData

Price DataUpdate

Invoice

Invoicing

Not Normative

For future consideration

Associated BPMN 2.0 Choreography (Complete)

Customer

Order Product

Order Processor

Scheduler

Organize Schedule

Order Processor

Shipper

Prepare Shipping

Order Processor

Invoicer

Establish Price

Order Processor

Invoicer

Update Price

Order Processor

Invoicer

Create Invoice

Order Processor

PriceData

Price DataUpdate

Invoice

ShippingResponse


ScheduleRequest

SheduleResponse

Order

Invoice

Customer

Deliver Invoice

Order Processor

Shipper

Finalize Shipping

Order Processor

Encapsulation Issues and Resolutions

•  Issue: The information about the interactions is spread across three diagrams in BPMN with unclear connections between them: –  There’s no way to connect a choreography to a particular conversation

to indicate the valid sequences of the messages in that conversation –  Should be possible to drill down a conversation to see the messages

grouped and their valid choreography –  This could be done using naming conventions

•  Resolution: Collaboration and Communication have been merged –  Each conversation can have an associated choreography that indicates the valid

sequences of messages through that conversation –  Conversations group messages in a collaboration –  All three diagrams are still supported, but collaboration and conversation can be

shown on the same diagram if desired


•  Issue: Relationship between orchestration and collaboration, conversation and choreography –  How the orchestrations conform to the interaction protocols –  Possibility of lanes representing conversations

•  Resolution: collaboration and conversation are merged in the metamodel, but the separate notation is preserved

–  Orchestrations of activities have to be consistent with the choreography of the conversations through which the providing and consuming participants interact


•  Issue: Relationship to BPMN interactions and interfaces is unclear –  Relationship between messages and service operations needs to be

defined

•  Resolution: TBD –  How do service interfaces related to conversations? –  Can conversations have service interfaces to support RPC-style

interactions as well as message-based interactions? –  Can a conversation have both?

Mappings SoaML Term BPMN Mapping

ServicesArchitecture (a UML Collaboration) or a specification Participant

Overview Choreography

Participant Participant representing PartnerEntity (within definitional collaboration, denoted by a pool

Service Port One end of a conversation between participants in a communication diagram: Interface of the above participant (the line connecting the hexagon and the pool)

Request Port The other end of the communication, the one sending the first message

ServiceInterface (defining the type of a Service or Request Port)

Interface, but doesn’t support service protocols. Alternatively, a conversation in a communication diagram, including the corresponding messages in a collaboration diagram, and the choreography of those messages in a choreography diagram

Interface (realized or used by a ServiceInterface) Interface, but not clear how this relates to a conversation – possibly allowing RPC or message-based interaction specification

Operation or Reception (of an Interface) Operation of an Interface or Message, but not clear how this relates to an operation of an interface

Parameter (of an Operation) Message inputs and outputs for an Operation

Integration Topics to Explore •  Encapsulation: Description of a encapsulating element

or “component” through its potential interactions with other prototypical components

•  Behavior: Representation of a component’s behavioral implementation (orchestration) –  Public process: observable behavior as seen from the outside –  Internal processes: those that implement and use services

•  Contract: Service Contract, component’s interactions (collaboration, conversation, choreography) between components describing how they interact

•  Structure: Internal structure of a component as an assembly of other components –  At the class level, dependencies between components –  At the instance level, connected parts in an assembly defined by

usages of component types

Figure 86 “The processPurchaseOrder Service Operation Design” in SoaML

An activity partition can represent a

request port of the owning participant

This activity is owned by the

participant and is the method for

providing its service operation

A call operation action is an

invocation of a service operation available through the request port represented by

the activity partition

This is the receipt of a

callback from the consumer

through the request port’s

provided interface (a two-

way conversation)

Associated BPMN 2.0 Process (with Definitional Collaboration)

Request Product

Scheduling

Shi

ppin

g[C

onve

rsat

ion]

Invo

icin

g[C

onve

rsat

ion]

Sch

edul

e[C

onve

rsat

ion]

Request ShippingAssignment

Initiate Price Calculations

Complete Price

Calculations

Send Shipping Schedule

Process Schedule

Process Invoice

Schedule

PurchaseOrder

CustomerInfo

ShippingInfo

PurchaseOrder Invoice

Ord

er P

roce

ssor

Cus

tom

er

Order

Invo

icer

PriceData

Invoice

Price DataUpdate Invoice

ShippingResponse ScheduleShipping

RequestScheduleRequest

SheduleResponse

Ord

er[C

onve

rsat

ion]

SendInvoice

ReceiveOrder

Shi

pper

Sch

edul

er

BPMN 2.0 Process (with Definitional Collaboration and Choreography)

Request Product

SchedulingS

hipp

ing

[Con

vers

atio

n]In

voic

ing

[Con

vers

atio

n]S

ched

ule

[Con

vers

atio

n]



Complete Price

Calculations


Process Schedule

Process Invoice

Schedule

PurchaseOrder

CustomerInfo

ShippingInfo


Ord

er P

roce

ssor

Invo

icer

Ord

er[C

onve

rsat

ion]

SendInvoice

ReceiveOrder

Invoicer

Establish Price

Order Processor

Invoicer

Update Price

Order Processor

Invoicer

Create Invoice

Order Processor

PriceData

Price DataUpdate

Invoice

BPMN 2.0 Process (with Definitional Collaboration and Conversation)

Request Product

Scheduling

Shi

ppin

g[C

onve

rsat

ion]

Invo

icin

g[C

onve

rsat

ion]

Sch

edul

e[C

onve

rsat

ion]



Complete Price

Calculations


Process Schedule

Process Invoice

Schedule

PurchaseOrder

CustomerInfo

ShippingInfo


Ord

er P

roce

ssor

Invo

icer

Ord

er[C

onve

rsat

ion]

SendInvoice

ReceiveOrder

Invoicing

BPMN 2.0 Process (with Definitional Collaboration, Conversation, and Messages)

Request Product

Scheduling

Shi

ppin

g[C

onve

rsat

ion]

Invo

icin

g[C

onve

rsat

ion]

Sch

edul

e[C

onve

rsat

ion]



Complete Price

Calculations


Process Schedule

Process Invoice

Schedule

PurchaseOrder

CustomerInfo

ShippingInfo


Ord

er P

roce

ssor

Invo

icer

Ord

er[C

onve

rsat

ion]

SendInvoice

ReceiveOrder

InvoicingNot yet normative.

May become normative after

resolution of JIRA 334

A lane in a pool can represent

anything. In this case, it is used to

represent the conversation

through which interactions of the activities in the lane occur


Request Product

Scheduling

Shi

ppin

g[C

onve

rsat

ion]

Invo

icin

g[C

onve

rsat

ion]

Sch

edul

e[C

onve

rsat

ion]



Complete Price

Calculations


Process Schedule

Process Invoice

Schedule

PurchaseOrder

CustomerInfo

ShippingInfo


Ord

er P

roce

ssor

Invo

icer

Ord

er[C

onve

rsat

ion]

SendInvoice

ReceiveOrder

Invoicing

PriceData Price Data

UpdateInvoice

Note Associations between Messages and Conversation

Links

A message association can also be used to

indicate the conversation

through which interactions of an

activity occur.

BPMN 2.0 Process Option 1: Conversation Link extended to Process

Request Product

Scheduling



Complete Price

Calculations


Process Schedule

Process Invoice

Schedule

PurchaseOrder

CustomerInfo

ShippingInfo


Ord

er P

roce

ssor

Invo

icer

SendInvoice

ReceiveOrder

Invoicing

Cus

tom

er

Shi

pper

Sch

edul

er

Order

ShippingShedule

Conversation Links extended to connect to Process elements

BPMN 2.0 Process Option 2: Message Flow from Converation to Process

Request Product

Scheduling



Complete Price

Calculations


Process Schedule

Process Invoice

Schedule

PurchaseOrder

CustomerInfo

ShippingInfo


Ord

er P

roce

ssor

Invo

icer

SendInvoice

ReceiveOrder

Invoicing

PriceData

Price DataUpdate

Invoice

Cus

tom

er

Shi

pper

Sch

edul

er

Order

ShippingShedule

Message Flow used to connect

Conversations to Process elements

BPMN 2.0 Process Option 3: Both Conversation Link and Message Flow to Process

Request Product

Scheduling



Complete Price

Calculations


Process Schedule

Process Invoice

Schedule

PurchaseOrder

CustomerInfo

ShippingInfo


Ord

er P

roce

ssor

Invo

icer

SendInvoice

ReceiveOrder

Invoicing

Price DataUpdate

Invoice

Cus

tom

er

Shi

pper

Sch

edul

er

Order

ShippingShedule

Combination of cnv Links and Message Flow used to connect Conversations

to Process elements


Request Product

SchedulingS

hipp

ing

[Con

vers

atio

n]In

voic

ing

[Con

vers

atio

n]S

ched

ule

[Con

vers

atio

n]



Complete Price

Calculations


Process Schedule

Process Invoice

Schedule

PurchaseOrder

CustomerInfo

ShippingInfo


Ord

er P

roce

ssor

Invo

icer

Ord

er[C

onve

rsat

ion]

SendInvoice

ReceiveOrder

Invoicer

Invoicing

Order Processor

PriceData

Price DataUpdate

Invoice

Behavior Issues and Resolutions •  Issue: Unclear how the orchestration of the OrderProcessor is connected to

the operation of the service being provided •  Resolution: Information is capture in the metamodel

–  Can be viewed by having a lane represent the conversation –  Or can be viewed by using message associations connecting the activity and the

conversation

•  Issue: Conventions for using lanes to correspond to communications is informal

•  Resolution: Some usages of lanes are explicitly defined in BPMN

Behavior Issues and Resolutions •  Issue: Lots of low-level send and receive message activities in the process

instead of abstracting a service invocation interaction – describes how the service is implemented as message exchanges which is unnecessary and inappropriate for business processes

•  Issue: Encapsulation is broken by showing message exchanges that cross participant boundaries and connect to specific activities – results in increased coupling between participants

•  Resolution: This is the desired notation –  The messages can be elided from the diagrams if lanes are used to reference the

conversations –  Encapsulation can be highlighted by using communication instead of collaboration diagrams –  But they are combined in the metamodel so that encapsulation of the actual data is

preserved

Behavior Issues and Resolutions •  Issue: Not clear how the messages in a collaboration correspond to the

messages of an operation invoked with a service task –  May need to be able to associate an interface with a conversation through which the

messages for operations of that interface flow

•  Resolution: TBD

•  Issue: Unclear how to model multiple processes and services provided by the same participant

–  Multiple orchestrations in the same pool? –  Multiple pools with the same name, each showing a different process?

•  Resolution: TBD

Mappings SoaML Term BPMN Mapping

Activity Process

CallOperationAction including target InputPin and Pins for Parameters

ServiceTask

SendSignalAction Send Task

AcceptCallAction InitialNode

AcceptEventAction InitialNode

ControlFlow Sequence Flow

ObjectFlow Data Association

Etc.

Figure 87 “Assembling the Parts into a Deployable Subsystem” in SoaML

Participants can assemble reference to other participants needed to provide their services

A participant can delegate a service to one of its parts

Requests of one participant are connected to compatible services of another

Participants can adhere to a ServicesArchitecture by indicating what roles the parts in the assembly play in the services architecture

These parts represent references to instances of participants that will exist at runtime

Associated BPMN Mapping

•  Alternative 1 (preferred): Out of scope –  BPMN is used to describe process components and

their implementations –  BPMN does not describe the wiring of such

components Ø SoaML and BPMN are orthogonal and composable

•  Same relationship as SCA and BPEL

•  Alternative 2: Add relationship between partnerEntity and partnerRole –  Corresponding to SoaML wiring between request

point and component/its service point Ø Leads to undesirable overlap between specs

ServicesArchitecture A ServicesArchitecture defines the specification for the interaction between a set of participants collaborating to accomplish some end.

References to ServiceContracts specify the agreements between the participants, specifying how they interact in this services architecture

The behavior of the ServicesArchitecture specifies how the participants interact

Associated BPMN 2.0 Choreography

Customer

Order Product

Order Processor

Scheduler

Organize Schedule

Order Processor

Shipper

Prepare Shipping

Order Processor

Invoicer

Establish Price

Order Processor

Invoicer

Update Price

Order Processor

Invoicer

Create Invoice

Order Processor

PriceData

Price DataUpdate

Invoice

ShippingResponse


ScheduleRequest

SheduleResponse

Order

Invoice

Customer

Deliver Invoice

Order Processor

Shipper

Finalize Shipping

Order Processor

Backup

Detailed slides, or those that define intermediate model states

that indicate how the models might be developed

Role / Type

•  UML and BPMN employ the same implicit “reuse” pattern.

•  Making it explicit, just for discussion: – Things play roles in contexts. – Roles restrict the kinds (types) of things that

can play them. – Things only exist at “runtime”, but models are

explained by their effect on things.

Role / Type: Examples

Context Role Type Company Engineer Person

Company Headquarters Building

Car Left Front Wheel Wheel

Stage Play Part Person

Brokering Seller Economic Agent

Role / Type: Metamodel

•  Roles are owned by contexts. •  Types are “reusable”. •  Implicit metamodel:

Context Role Type has

Role / Type: UML Context Role Type

Class Property (“part”) / Port Class / Interface

Class Connector Association

Collaboration Property (“role”) Class / Interface

Activity CallBehaviorAction Behavior

Interaction Lifeline Class

Interaction InteractionUse Interaction

Role / Type: SoaML (UML+) Context Role Type

Participant Service / Request Port ServiceInterface

Services Architecture Property (“part”) Participant

Participant Property (“part”) Participant

Participant ServiceChannel N/A

Service Contract Property (“role”) ServiceInterface

Role / Type: BPMN Context Role Type

Process CallActivity Process

Activity Activity Resource / Performer Resource

Collaboration CallCollaboration Collaboration

Collaboration Participant PartnerEntity/Role

Collaboration Message Flow Message

Interface Operation Message

Associated BPMN 2.0 Definitional Collaboration

Entity

Role Role Role

O r d

e r P r

o c e s

s o r

I n v o

i c i n g

S e r v

i c e

S c h

e d u l i

n g S e

r v i c e

S h i

p p i n g

S e r v

i c e

A participant representing the role

ShippingService ( equivalent to a request

point in SoaML )

A participant representing the entity

OrderProcessor

The actual interfaces do not show up visually in the diagram. • The Interface of OrderProcessor defines the interface of the provided service

point . • The Interfaces of InvoicingService etc. define the interfaces of the required

request points .

Also note: • This mapping allows to have multiple request points using the same type, by

having several role participants using the same process .

invoicing Shipping scheduling

Associated BPMN 2.0 Process

Request Product

Scheduling

Request Shipping

ReceiveOrder

Assignment


Complete Price

Calculations


Process Schedule

Process Invoice

SendInvoice

Schedule

PurchaseOrder

CustomerInfo

ShippingInfo

PurchaseOrder

Invoice

Associated BPMN 2.0 Process (Lanes) S

hipp

ing

Invo

icin

gS

ched

ulin

g

Request Product

Scheduling

Request Shipping

ReceiveOrder

Assignment


Complete Price

Calculations


Process Schedule

Process Invoice

SendInvoice

Schedule

PurchaseOrder

CustomerInfo

ShippingInfo


The Lanes Represent the

Internal Departments

Responsible for the Activities

Associated BPMN 2.0 Process (Lanes)

Shi

ppin

g[C

onve

rsat

ion]

Invo

ice

[Con

vers

atio

n]S

ched

ule

[Con

vers

atio

n]

Request Product

Scheduling

Request Shipping

Assignment


Complete Price

Calculations


Process Schedule

Process Invoice

Schedule

PurchaseOrder

CustomerInfo

ShippingInfo


Ord

er[C

onve

rsat

ion] Send

InvoiceReceiveOrder

For SoaML integration, the Lanes are now set

to use defined Conversations (from

the definitional Collaboration)

Issues

•  Check execution for service task—to make sure what instance of a Participant will support the operation

•  Question: how are data associations connected to input/output messages of operation?

Integrating BPMN and SoaML - cs.vu.nlpatricia/Patricia_Lago/IBM_Course_files... · Associated BPMN...

Documents

Transcript of Integrating BPMN and SoaML - cs.vu.nlpatricia/Patricia_Lago/IBM_Course_files... · Associated BPMN...