Rule-Enhanced Business Process Modeling Language for Service Choreographies Milan Milanović1, Dragan Gašević2, Gerd Wagner3, and Marek Hatala4 1
University of Belgrade, Serbia Athabasca University, Canada 3 Brandenburg Technical University at Cottbus, Germany 4 Simon Fraser University, Canada
[email protected],
[email protected],
[email protected],
[email protected] 2
Abstract. To address problem of modeling service choreographies, the paper tackles the following challenges of the state of the art in choreography modeling: i) choreography models are not well-connected with the underlying 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 implementation 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 Notation (BPMN) and REWERSE Rule Markup Language (R2ML). Keywords: BPMN, R2ML, rules, processes, metamodels, MDE.
1 Introduction Responding to the increasing demands for developing advanced solutions to the integration of business processes in collaborative information systems, service-oriented architectures (SOAs) emerged as a promising approach. Considering the present state in the area of SOA, we can witness a need for the development of new software engineering approaches suitable for this development context. Being grounded on proven principles of business process modeling, service engineers have prevalently based their approaches on languages such as BPMN [4]. Such languages offer a suitable way for requirements elicitation from stakeholders, which can (semi-)automatically be bound to the existing services and transformed onto the executable service compositions (i.e., languages such as BPEL). In the service composition task, we generally have two main approaches [7]: i) service orchestration – composition of service from the perspective of one of the participants. Orchestrations are typically modeled w.r.t. control flows, while workflow patterns are used as best practices and evaluation framework for comparison of orchestration languages; ii) service choreographies – composition of services from a global perspective where service interaction is the primary focus. In this paper, we exactly focus on the problem of modeling choreographies in order to address challenges from we give in the abstract. A. Schürr and B. Selic (Eds.): MODELS 2009, LNCS 5795, pp. 337–341, 2009. © Springer-Verlag Berlin Heidelberg 2009
338
M. Milanović et al.
2 Background 2.1 BPMN Language: Graphical Concrete Syntax and Metamodel BPMN represents an OMG adopted specification [1] whose intent is to model business processes. Business process models are expressed in business process diagrams. Each business process diagram consists of a set of modeling elements. BPMN includes three types of flow objects which defines behavior: Events, Activities and Gateways. Events can be partitioned into three types, based on their position in the business process: start events are used to trigger processes; intermediate events can delay processes, or they can occur during processes [4] [7]; and end events signal the termination of processes. A BPMN activity can be atomic or non-atomic (represented by a rectangle). BPMN supports three types of activities: Process, Sub-Process and Task. Gateways are used for guiding, splitting and merging control flow. The key element of the definition of the BPMN language is a metamodel. Although BPMN is an OMG standard, there is presently no standard metamodel for BPMN. We choose a BPMN metamodel proposal given in [4], because it uses an explicit BPMN terminology; and its mapping relations to BPEL are clearer than in the case of other proposals. 2.2 Business Rules: REWERSE I1 Rule Markup Language REWERSE I1 Rule Markup Language (R2ML) is a general rule language [5]. R2ML is completely built by using model-driven engineering principles, which means that the R2ML language definition consists of the three main parts: i) metamodel – an abstract syntax in the Meta-Object Facility (MOF) language; ii) textual concrete syntax – an XML based syntax that facilitates rule interchange; and iii) graphical concrete syntax – a graphical notation suitable for modeling rules in a style similar to software modeling languages. In fact, its graphical syntax is defined as an extension of UML and named UML-based Rule Modeling Language (URML) [6]. There are different categories of business rules such as [7] integrity, derivation, reaction, and production. R2ML defines all of these four types of rules and provides modeling concepts for defining vocabularies. All R2ML rule definitions (e.g., ReactionRule) are inherited from the Rule class. Each type of rule is defined over the R2ML vocabulary, where elements of the vocabulary are used in logical formulas (e.g., LogicalFormula – with no fee variables) through the use of Atoms and Terms.
3 rBPMN Metamodel: Rule and Choreography Modeling The rBPMN metamodel is defined by importing the elements from the BPMN and R2ML metamodels. In Fig. 1, we show extension to the Process package of the rBPMN metamodel. RuleGateway is an element, which we added in the Process package of the BPMN metamodel and which actually relates to R2ML Rules. In this way, we enabled that R2ML Rule can be placed into a process as a Gateway, but in the same time not to break the R2ML Rule syntax and semantics. We should note here that one rule gateway could have one or more rules attached to it. This is quite important, as in some cases, we need to first derive or constrain some part of the business
Rule-Enhanced Business Process Modeling Language for Service Choreographies
339
logic, before being able to perform some other rules such as reaction or production. In Fig. 1, we can see that RuleGateway as a Gateway can be connected by using SequenceFlow with other FlowElements such as Tasks, Events and Gateways. This enables us to use rules in different places in rBPMN process models. Additionally, we added a RuleCondition concept, which is used to show rule condition directly attached to the RuleGateway in a business process diagram.
Fig. 1. Process package in rBPMN metamodel
We can have a rule as a valid element in a business process, but we should also have a way to connect underlying data models to business rules. In rBPMN, we use R2ML Vocabulary as an underlying data model, so that any BPMN message can be represented with an R2ML concepts. The StructureDefinition element is used to specify a Message structure. As the standard BPMN cannot capture several choreography aspects, as recognized in [3]. In order to fully support these patterns we need to integrate several aspects into rBPMN. Those aspects are as follows: Multiplicity of Participants, References and Correlation information.
4 Service Interaction Patterns: A Contingent Requests Example There are two approaches to modeling of choreographies: interaction models and interconnected interface behavior models (interconnection models) [2]. Interaction models are built up of basic interaction, while interconnected interface behavior models define control flows of each participant a choreography. As rBPMN can be used
340
M. Milanović et al.
for both modeling approaches, we here show an example of Contingent requests pattern [9] expressed in rBPMN only as interaction model, because lack of space. In the contingent requests pattern, a participant sends a request to another participant. If this second participant does not Fig. 2. The “Contingent requests” pattern 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. In this pattern, the “Send” task in Pool 1 selects participants to which a request will be sent. The participants are selected from the attached participant set (). The message is received by Pool 2, which uses its own logic represented with the rule gateway R2 to decide whether to respond or not. Pool 1 waits for some amount of time for a message from Pool 2 and when such a message arrives in, Pool 1 invokes its “Task”, which is followed by a rule gateway R1 to determine if this process will end or it will return to the event-based gateway to wait for new messages. Fig. 3. “Contingent requests” pattern (interaction model) If the message from Pool 2 is not received in a given amount of time, the intermediate timer event occurs and the sequence flow is returned to the start (the “Send” task).
Rule-Enhanced Business Process Modeling Language for Service Choreographies
341
The contingent requests pattern as an interaction model in rBPMN is shown in Fig. 3. In this model, we have a message that is sent on the start of the process from Pool 1 to one of the participants of the Pool 2 type, by using a reference to that participant from the participant set (). Then, response messages are expected from Pool 2 in a given amount of time. When the message arrives from Pool 2, the rule gateway is used to determine whether the process will end or it will be back to wait for another message. Another important implication of our model is that for each reaction rule in R2ML, we can also generate its implementation in a concrete rule-based language. In our experiments, we provide full definition several languages (e.g., Drools or Jess) by simulating semantics of reaction rules on production rule engines. We call such rules “how-to-use” rules, as they specify conditions under which a service can be used.
5 Conclusion and Future Work To the best of our knowledge, the presented work is the first modeling language that integrates business rules with a process-oriented language for modeling service choreographies. Our evaluation demonstrated that the proposed rule and choreography modeling support resulted in the improvement of modeling of service-interaction patterns comparing to other relevant languages. Another important contribution of our work is that the metamodel-based systematic integration of rules in choreography model is also advances the state of the art in the integration of rules into business process modeling. Given that our rule language of choice (R2ML) can define business rules and message types over business vocabularies, our models have two key benefits: process models and business vocabularies are integrated (i.e., type safety is improved); and we can make use of the transformations of R2ML into executable rule engines.
References 1. Eijndhoven, T., Iacob, M.E., Ponisio, M.L.: Achieving Business Process Flexibility with Business Rules. In: Proceedings of the 12th international IEEE EDOC Conf., pp. 95–104 (2008) 2. Decker, G., Puhlmann, F.: Extending BPMN for Modeling Complex Choreographies. In: Proceedings of the OTM Confederated International Conferences, pp. 24–40 (2007) 3. OMG, BPMN 1.0: OMG final adopted specification (2006), http://www.omg.org/cgi-bin/doc?dtc/2006-02-01 4. OMG, Business Process Model and Notation (BPMN) Specification 2.0, initial submission, http://www.omg.org/cgi-bin/doc?bmi/08-02-06 5. REWERSE Rule Markup Language, http://oxygen.informatik.tu-cottbus.de/rewerse-i1/?q=node/6 6. UML-based Rule Modeling Language, http://oxygen.informatik.tu-cottbus.de/rewerse-i1/?q=node/7 7. Wagner, G., Giurca, A., Lukichev, S.: A Usable Interchange Format for Rich Syntax Rules Integrating OCL, RuleML and SWRL. In: Proceedings of Reasoning on the Web, Edinburgh, Scotland (2006) 8. Weske, M.: Business Process Management. Springer, Heidelberg (2007) 9. Barros, A., Dumas, M., ter Hofstede, A.: Service Interaction Patterns: Towards a Reference Framework for Service-based Business Process Interconnection, TR FIT-TR-2005-02, QUT, Australia (2005)
