1. Integrating BPMN and SoaML Based on an example from SoaML spec

2. 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

3. Proposal for Integrating BPMN and SoaML Supports construction and consumption of services –BPMN defines business requirements that identify candidate services –SoaML provides a way of identifying, specifying and implementing serivces –BPMN can be used to choreography SoaML services to meet some business need –Use BPMN to create implementations of SoaML Services Separates the architecture of the services from the processes that drive or use them

4. Integration Requirements 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

5. Approaches to Integration None –Assumes specifications and tools are independent with intentional overlap –Does not leverage complimentary capabilities 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 Metamodel Integration –Provides best integration, but at higher development and integration costs –Can be accomplished with a separate bridging metamodel

6. Approach to defining the integration 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 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

7. Topics Description of a component through its potential interactions with other “prototypical components” Representation of a component’s behavioral implementation –Public process: observable behavior as seen from the outside –Internal processes: those that implement and use services Service Contract, component’s interactions (collaboration, conversation, choreography) between components describing how they interact Assembly of components or structural implementation –At the class level, dependencies between components –At the instance level, connected parts in an assembly defined by usages of component types

8. 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 service 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

9. 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

10. 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

11. Associated BPMN 2.0 Collaboration

12. Associated BPMN 2.0 Conversation

13. Associated BPMN 2.0 Conversation (showing mini-Choreography)

14. Associated BPMN 2.0 Choreographies (per Conversation) Order Shipping Invoice Schedule

15. Associated BPMN 2.0 Choreography (Complete)

16. 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.

17. Role / Type: Examples ContextRoleType CompanyEngineerPerson CompanyHeadquartersBuilding CarLeft Front WheelWheel Stage PlayPartPerson BrokeringSellerEconomic Agent

18. Role / Type: Metamodel Roles are owned by contexts. Types are “reusable”. Implicit metamodel: Context RoleType has

19. Role / Type: BPMN Context RoleType Process CallActivityProcess Activity Activity Resource / Performer Resource Collaboration CallCollaborationCollaboration ParticipantPartnerEntity/Role Collaboration Message FlowMessage Interface OperationMessage

20. Role / Type: UML Context RoleType Class Property (“part”) / Port Class / Interface Class ConnectorAssociation Collaboration Property (“role”)Class / Interface Activity CallBehaviorActionBehavior Interaction LifelineClass Interaction InteractionUseInteraction

21. Role / Type: SoaML (UML+) Context RoleType Participant Service / Request PortServiceInterface Services Architecture Property (“part”)Participant Property (“part”)Participant ServiceChannelN/A Service Contract Property (“role”)ServiceInterface

22. Potential Issues 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 communication to indicate the valid sequences of the messages in that communication –Should be possible to drill down a communication to see the messages grouped and their valid choreography –This could be done using naming conventions Relationship between orchestration and collaboration, communication and choreography –How the orchestrations conform to the interaction protocols –Possibility of lanes representing communications Relationship to BPMN services and interfaces is unclear –Relationship between messages and service operations needs to be defined

23. Mappings SoaML TermBPMN Mapping ServicesArchitecture (a UML Collaboration) or a specification Participant Overview Choreography ParticipantParticipant representing PartnerEntity (within definitional collaboration Service PortOne end of a communication between participants in a communication diagram: Interface of the above participant Request PortThe 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 communication 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 communication 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

24. Topics Description of a component through its interaction with other “prototypical components” Representation of a component’s implementation Assembly of components

25. Figure 86 “The processPurchaseOrder Service Operation Design” in SoaML An activity partition represents 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)

26. Associated BPMN 2.0 Process (with Definitional Collaboration)

27. Potential Issues Unclear how the orchestration of the OrderProcessor is connected to the operation of the service being provided 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 Conventions for using lanes to correspond to communications is informal Encapsulation is broken by showing message exchanges that cross participant boundaries and connect to specific activities – results in increased coupling between participants 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?

28. Mappings SoaML TermBPMN Mapping Activity CallOperationAction including target InputPin and Pins for Parameters SendSignalAction AcceptCallAction AcceptEventAction ControlFlow ObjectFlow Etc.

29. Topics Description of a component through its interaction with other “prototypical components” Representation of a component’s implementation Assembly of components

30. 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

31. 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

32. 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

33. Associated BPMN 2.0 Choreography

34. Backup Detailed slides, or those that define intermediate model states that indicate how the models might be developed

35. Associated BPMN 2.0 Definitional Collaboration invoicingShipping scheduling

36. Associated BPMN 2.0 Process

37. Associated BPMN 2.0 Process (Lanes)