Post on 16-Feb-2019
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
ScheduleShippingRequest
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
Encapsulation Issues and Resolutions
• 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
Encapsulation Issues and Resolutions
• 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]
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
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]
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
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]
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
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
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]
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
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
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
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
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
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
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
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
BPMN 2.0 Process (with Definitional Collaboration, Conversation, and Messages)
Request Product
SchedulingS
hipp
ing
[Con
vers
atio
n]In
voic
ing
[Con
vers
atio
n]S
ched
ule
[Con
vers
atio
n]
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
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.
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 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
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
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
ScheduleShippingRequest
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
Initiate Price Calculations
Complete Price
Calculations
Send Shipping Schedule
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
Initiate Price Calculations
Complete Price
Calculations
Send Shipping Schedule
Process Schedule
Process Invoice
SendInvoice
Schedule
PurchaseOrder
CustomerInfo
ShippingInfo
PurchaseOrder Invoice
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
Initiate Price Calculations
Complete Price
Calculations
Send Shipping Schedule
Process Schedule
Process Invoice
Schedule
PurchaseOrder
CustomerInfo
ShippingInfo
PurchaseOrder Invoice
Ord
er[C
onve
rsat
ion] Send
InvoiceReceiveOrder
For SoaML integration, the Lanes are now set
to use defined Conversations (from
the definitional Collaboration)