Modeling Service Choreographies with Rule-enhanced Business Processes
•Download as PPT, PDF•
0 likes•532 views
The research community has so far mainly focused on the problem of modeling of service orchestrations in the domain of service composition, while modeling of service choreographies has attracted less attention. The following challenges in choreography modeling are tackled in this paper: i) choreography models are not well-connected with the underly-ing business vocabulary models. ii) there is limited support for decoupling parts of business logic from complete choreography models. This reduces dynamic changes of choreographies; iii) choreography models contain redundant elements of shared business logic, which might lead to an inconsistent implementa-tion and incompatible behavior. Our proposal – rBPMN – is an extension of a business process modeling language with rule and choreography modeling support. rBPMN is defined by weaving the metamodels of the Business Process Modeling No-tation and REWERSE Rule Markup Language. To evaluate our proposal, we use service-interaction patterns and compare our approach with related solutions.
Recommended
More Related Content
Similar to Modeling Service Choreographies with Rule-enhanced Business Processes
Similar to Modeling Service Choreographies with Rule-enhanced Business Processes (20)
More from Dragan Gasevic
More from Dragan Gasevic (20)
Recently uploaded
Recently uploaded (20)
Modeling Service Choreographies with Rule-enhanced Business Processes
- 1. Modeling Service Choreographies with Rule-enhanced Business Processes Milan Milanović1 and Dragan Gašević2 1 University of Belgrade, Serbia 2 Athabasca University, AB, Canada
- 2. Problem Domain Process modeling and service composition Orchestrations – CASCON 2009 Business processes from one participant’s side Choreographies Business processes from a global perspective
- 3. Available languages (e.g., BPMN) Challenges How to support business vocabularies/rules? How to manage redundant elements? MODELS 2009 Choreography Modeling
- 4. Extension of the BPMN2 language Software language engineering Adding support for vocabularies and rules Building on the previous related work iBPMN [Decker & Puhlmann, 2007] MODELS 2009 Approach Greetings for the EDOC friends from the International Conference on Software Language Engineering http://planet-sl.org
- 5. Rule-enhanced BPMN - rBPMN Interconnection and interaction models Evaluation mechanism – expressiveness Service Interaction Patterns MODELS 2009 Result
- 6. Processes & Rules – Option 1 Complete processes modeled by rules With reaction and production rules Some issues What’s the identity of a business process? Which languages to use? Are the languages at the same level?
- 7. Processes & Rules – Option 2 Hybrid approaches BP stays, but rules are added for control flow decisions, data constraints, and process composition [Graml et al., 2007]
- 8. MODELS 2009 The BPMN Language
- 9. Rules and Business Processes Challenges to have rules as first class concepts in BPs to support vocabularies/ontologies to define message and event typing to formalize defining conditions to enable declarative (parts of) processes MODELS 2009
- 10. Representational Analysis Based on the BWW model PΔR - Symmetric Difference; P R – Intersection; P/R & R/P -Relative Complement∩ Vid Prezel
- 11. Representational Analysis Based on the BWW model Vid Prezel
- 12. Rule Modeling REWERSE I1 Rule Markup Language (R2ML) with a UML-based graphical concrete syntax MODELS 2009
- 13. REWERSE I1 Rule Markup Language MODELS 2009 Extension for Rule Models rBPMN metamodel weaving
- 14. rBPMN in Action
- 15. rBPMN in Action
- 18. Multiplicity of participants – ||| References – to distinguish participants Correlation information – who sent a message MODELS 2009 Interaction Models
- 19. MODELS 2009 Service Interaction Patterns Contingent requests pattern
- 20. MODELS 2009 Service Interaction Patterns Contingent requests pattern
- 21. Case Study
- 22. Case Study
- 23. Rules in Choreography EDOC 2009
- 24. Case Study
- 25. Rules in Choreography EDOC 2009
- 26. Case Study
- 27. Case Study
- 28. Case Study
- 29. Rule in Choreography EDOC 2009
- 30. Expressiveness comparison Service Interaction Patterns Language Pattern group Pattern Let’s Dance BPMN WS- CDL iBPMN rBPMN Send + + + + + Receive + + + + +1) Send/Receive + + + + + Racing incoming messages + + + + + One-to-many send + - +/- + + One-from-many receive + - + + + 2) One-to-many send/receive + - +/- + + Multi-responses + + + + + Contingent requests +/- - +/- +/- +3) Atomic multicast notification - - - - - Request with referral + - + + + Relayed request + - + + +4) Dynamic routing - - +/- - +/-
- 31. rBPMN Editor Implementation of BPMN2 + R2ML Eclipse plug-in based on GMF and EMF Binaries available for download Going out as open source shortly Looking fwd to your feedback http://rbpmneditor.googlecode.com/ http://www.youtube.com/user/rbpmn
- 32. rBPMN Editor
- 33. rBPMN Heroes Language design and implementation Milan Milanovic Luis Rocha
- 34. MODELS 2009 Conclusion REWERSE I1 Rule Markup Language MODELS 2009 Extension for Rule Models rBPMN metamodel weaving
- 35. MODELS 2009 Conclusion REWERSE I1 Rule Markup Language MODELS 2009 Extension for Rule Models rBPMN metamodel weaving MODELS 2009 Service Interaction Patterns Contingent requests pattern
- 36. MODELS 2009 Conclusion REWERSE I1 Rule Markup Language MODELS 2009 Extension for Rule Models rBPMN metamodel weaving MODELS 2009 Service Interaction Patterns Contingent requests pattern MODELS 2009 Service Interaction Patterns Contingent requests pattern
- 37. MODELS 2009 Conclusion REWERSE I1 Rule Markup Language MODELS 2009 Extension for Rule Models rBPMN metamodel weaving MODELS 2009 Service Interaction Patterns Contingent requests pattern MODELS 2009 Service Interaction Patterns Contingent requests pattern Expressiveness comparison Service Interaction Patterns
- 38. MODELS 2009 Conclusion REWERSE I1 Rule Markup Language MODELS 2009 Extension for Rule Models rBPMN metamodel weaving MODELS 2009 Service Interaction Patterns Contingent requests pattern MODELS 2009 Service Interaction Patterns Contingent requests pattern Expressiveness comparison Service Interaction Patterns rBPMN Editor
- 39. Usability Semi-structured English vs. visual Interaction vs. interconnection model Quality and empirical issues of rBPMN MODELS 2009 Future Work
- 40. Usability Semi-structured English vs. visual Interaction vs. interconnection model Quality and empirical issues of rBPMN MODELS 2009 Future Work Community call: We need a corpus!
- 41. Language formalization affairs Static and operational semantics e.g., OWL2 and mCRL2 Coupled co-evolution of rules & processes MODELS 2009 Future Work
Editor's Notes
- <number> BPMN -> OMG specification.
- <number> In the contingent requests pattern, a participant sends a request to another participant. If this second participant does not respond within a given period of time, the request is sent to another (third) participant. Again, if no response comes back, a fourth participant is contacted, and so on. For the decision about delayed responses, we propose using rule gateways with attached reaction rules. If a late (time-outdated) response from some earlier participant came during the processing of the contingent request (by a Pool 2 participant in Fig. 2), a reaction rules attached to the rule gateway R1 decides if such a response should be accepted or not.
- <number> In the contingent requests pattern, a participant sends a request to another participant. If this second participant does not respond within a given period of time, the request is sent to another (third) participant. Again, if no response comes back, a fourth participant is contacted, and so on. For the decision about delayed responses, we propose using rule gateways with attached reaction rules. If a late (time-outdated) response from some earlier participant came during the processing of the contingent request (by a Pool 2 participant in Fig. 2), a reaction rules attached to the rule gateway R1 decides if such a response should be accepted or not.
- <number> In the contingent requests pattern, a participant sends a request to another participant. If this second participant does not respond within a given period of time, the request is sent to another (third) participant. Again, if no response comes back, a fourth participant is contacted, and so on. For the decision about delayed responses, we propose using rule gateways with attached reaction rules. If a late (time-outdated) response from some earlier participant came during the processing of the contingent request (by a Pool 2 participant in Fig. 2), a reaction rules attached to the rule gateway R1 decides if such a response should be accepted or not.
- <number> In the contingent requests pattern, a participant sends a request to another participant. If this second participant does not respond within a given period of time, the request is sent to another (third) participant. Again, if no response comes back, a fourth participant is contacted, and so on. For the decision about delayed responses, we propose using rule gateways with attached reaction rules. If a late (time-outdated) response from some earlier participant came during the processing of the contingent request (by a Pool 2 participant in Fig. 2), a reaction rules attached to the rule gateway R1 decides if such a response should be accepted or not.