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

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

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

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

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

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 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. Encapsulated Conversation (and Choreography)

16. Associated BPMN 2.0 Choreography (Complete)

17. 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 interactions and interfaces is unclear –Relationship between messages and service operations needs to be defined

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

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

20. Figure 86 “The processPurchaseOrder Service Operation Design” in SoaML A part 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) The target InputPin of the Action must be set to the Port represented by the part ActivityPartition the Action is in

21. Associated BPMN 2.0 Process (with Definitional Collaboration)

22. BPMN 2.0 Process (with Definitional Collaboration and Choreography)

23. BPMN 2.0 Process (with Definitional Collaboration and Conversation)

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

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 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 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 ActivityProcess CallOperationAction including target InputPin and Pins for Parameters SendSignalActionSend Task AcceptCallAction AcceptEventAction ControlFlowSequence Flow ObjectFlowData Association Etc.

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

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

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

34. Associated BPMN 2.0 Choreography

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

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

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

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

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

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

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

42. Associated BPMN 2.0 Definitional Collaboration invoicingShipping scheduling

43. Associated BPMN 2.0 Process

44. Associated BPMN 2.0 Process (Lanes)

46. 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?