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.
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]
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
18. Multiplicity of participants – |||
References –
to distinguish participants
Correlation information –
who sent a message
MODELS 2009
Interaction Models
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
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
<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.