A scenario is a behavioral view – Orchestrating services by scenario integration Dirk Fahland Humboldt-Universität zu Berlin, Institut für Informatik, Unter den Linden 6, 10099 Berlin, Germany fahland@informatik.hu-berlin.de Abstract. The construction of a complex service orchestration is a te- dious and error-prone tasks as multiple service interactions with a single orchestrating service must be specified and combined. We suggest to specify a service orchestration in terms of behavioral scenarios that cap- ture a specific aspect of service interaction, a behavioral view in isolation. By synchronizing the different scenarios, the views get integrated and de- fine the behavior of a complex service orchestration. Our formal model for scenarios and their integration is a class of Petri nets called oclets. Keywords: service choreography, view, scenario, Petri nets 1 Behavioral views for service orchestration In service-oriented computing [1], services serve as building blocks for complex, distributed systems. A service orchestration is a means to coordinate n services by a (n + 1)st service, called orchestrator that communicates with each of the n given services directly and coordinates the overall exchange by its internal logic [2]. Process modeling languages like BPEL combine workflow modeling with the SoC paradigm for specifying and executing orchestrator services. While specifying the orchestrator’s interaction with a specific, individual ser- vice is usually straight forward, the coordination of all interactions with all partner services remains a challenge. If service interactions are sufficiently com- plex and depend on each other, the resulting orchestrator logic will be complex, and so will be the orchestrator model. Constructing a comprehensible orchestra- tor model with appropriate sub-processes etc. is a tedious task. The sub-process hierarchy usually needs to be remodeled if another service interaction, that cuts across the present hierarchy, is to be integrated into the model. The problem itself is not new and relates to the problem of process integra- tion for classical (non-communicating) process models [3]. A recurring solution approach for behavioral integration takes inspiration from databases where a complex relational database is constructed by integrating the views of the var- ious users on the database [4]. A database view is, in principle, a projection of a complete database onto a few specific somehow connected objects of interest. Such a view has a valid interpretation in isolation. Conversely, a “complete” CEUR ceur-ws.org Workshop ISSN 1613-0073 Proceedings set of views describes the entire database; hence it can be constructed from its views. If the set of views is not complete or do not fit, they have to be adjusted, viz. integrated. In this paper, we propose the concept of a behavioral view for the construction of behavioral models. In analogy to databases, a behavioral view is, in princi- ple, a projection of a complete behavioral model onto a specific behavior, i.e. a partial process execution also called scenario. Conversely, a “complete” set of behavioral views describes the entire behavior. A behavioral view can have arbi- trary structure (as longs as it is a connected partial execution); it may therefore cut hierarchies and hence is a means to express cross-cutting concerns in pro- cess models. While the definition of a behavioral view is straight forward, the converse, their integration to form a complete behavioral model is non-trivial. We argue that a well-founded approach for behavior modeling by view in- tegration requires an appropriate formal model. In [5] we proposed the Petri net class of oclets as a formal model for scenarios (or behavioral views) on the basis of a formal, operational semantics [6]. Intuitively, this formal model con- structs complex behavior by concatenating and merging “fitting” scenarios. This reduces the problem of behavioral integration to make a given set of scenarios “fitting” to each other. In general, the solution is to unify the tasks and resources occurring in the scenarios appropriately. In the remainder of this paper, we first substantiate the concept of a behav- ioral view in Sect. 2 as we introduce oclets, and their semantics at an intuitive level. We subsequently explain the problem of behavioral integration and sug- gest a procedure for process integration by the help of an example. We conclude the paper with a discussion of related work and a presentation of open research problems in Section 4. 2 Scenario-based service modeling with oclets For formally modeling services, the Petri net class of open nets has been estab- lished. Open nets allow for a rigorous analysis of behavioral properties of services while industrial service modeling languages can be translated to open nets [7], and vice versa [8]. The behavior of an open net is defined by standard Petri net semantics; this operational semantics defines the (partially-ordered) runs of the modeled service. As every service model is finite, these runs are not arbitrary, but exhibit a certain structure, e.g. transitions always fire in a specific order. Scenario-based models exploit this regularity of the runs: One can identify various repeating patterns (scenarios) that are partial executions of the service. The entire service behavior is composed of these scenarios. A scenario-based model makes a scenario a modeling artifact. The entire service behavior is ex- pressed as a set of scenario; a corresponding formal semantics describes how scenarios compose to runs. In [5], we propose the Petri net class of oclets for formally describing scenar- ios with an operational formal semantics. An oclet is an acyclic Petri net with a local precondition describing which requirements must be satisfied in order to execute the subsequent scenario. We denote service communication by anno- tating transitions by incoming arrows (receive a message) and outgoing arrows (send a message). TR - taxi register Figure 1 depicts some oclets; the minimal await (no predecessor) grey-shaded places denote PS - passenger standard taxi the precondition of the oclet. Our running await pass. get "taxi example is a passenger-taxi coordination ser- available" get taxi taxi await vice which is specified in two views: request taxi data pass. trip (1) The first view (oclet PS) specifies that data TS - taxi standard data taxi a passenger can send a pickup request to pick avail. taxi data the service, which it processes by picking an pick avail. taxi available taxi and returning taxi number and no.pass. arrival time. send taxi no. trip and arr. time data (2) The second view (oclets TR and TS) send trip await specifies that an available taxi can register at details pass. the service at any time. If taxi data is reg- istered at the service, the service will pick Fig. 1. Standard service interac- a matching passenger and send the corre- tion with passengers and taxis. sponding trip details to the taxi. Figure 3 depicts a partially ordered run of PR - passenger reset the oclets PS, TR, TS as an acylic Petri net. The trip run is constructed by merging (copies of) oclets data pick avail. at equally labeled nodes in the obvious and in- PC - pass. cancel taxi. tuitive manner. The run of Fig. 3 shows explic- pass. cancel- led taxi data data itly that the passenger view and the taxi view get cancel are not related to each other, while each makes request reset sense on its own. cancel- await led pass. We can easily extend our view based model with another view, see Fig. 2: A passenger may Fig. 2. Service cancelation by cancel a request at any time (oclet PC); the passenger and service reset. service resets its processing subsequently (PR). This allows to construct the run depicted in Fig. 4. Thereby oclet PS of Fig. 1 is not executed completely (transition send taxi no is not enabled because get cancel request of PC occurred. Instead, oclet PR is ap- pended by merging transitions pick avail. taxi of PS and PR. The run of Fig. 4 shows again that the given behavioral views do not fit to each other; the taxi still gets notified about the passenger although the request has been canceled. The views must be integrated. 3 View integration with scenarios We just have introduced oclets as a modeling language for behavioral views and show that if behavioral views do not fit to each other, they cannot be composed to a run. In this section, we sketch how behavioral views of services can be integrated to define a consistent orchestrator service. await await await await pass. taxi pass. taxi get taxi get "taxi get taxi get "taxi request available" request available" trip taxi await trip taxi pass. req. data taxi pass. req. data data data await pick avail. pick avail. pick avail. pick avail. taxi taxi pass. taxi pass. taxi trip taxi trip no. data no. data send taxi no. send trip get cancel send trip and arr. time details request details await cancelled pass. get taxi get "taxi get "taxi request reset available" available" pass. trip taxi await await taxi await data req. data taxi pass. data taxi Fig. 3. A standard run constructed from Fig. 4. A run with service cancellation scenarios ps, tr, ts. constructed from scenarios ps, tr, ts, pc, tc. We suggest the following integration procedure depicted in Fig. 5. The orches- trator’s interaction with each of its partner services is specified in a behavioral view. To integrate the different views, (1) all views are refined to the same gran- ularity of resources and tasks; (2) a modeler identifies points of synchronization (specific resources or tasks) and defines integration options. Finally, (3) synchro- nization is made explicit in each scenario by applying the integration options. This adjusts the different scenarios to each other s.t. the formal semantics of oclets constructs the orchestrator’s behavior by concatenating and merging the now fitting scenarios. Possibly, some integration issues are not visible after the first integration step, so steps (2) and (3) are iterated until satisfaction. The grey tasks of Fig. 5 require interaction with a human modeler. As all oclets of our example process already have equal granularity, the first step changes nothing. We now have to define integration options for our scenarios in order to unify the given oclets accordingly. An integration option maps a set of transitions of the oclets to be integrated to a (possibly new) transition. For some kinds of integrations like parallel synchronization the resulting integrated transition is a function of the integration inputs; see [3]. In our example, the standard behavior in Fig. 3 suggests to integrate the views via transitions pick avail. taxi and pick avail. pass by the parallel compo- sition depicted in Fig 6. Further, the reset oclet pr of Fig. 2 must be extended to properly handle cancelation also in the service’s interaction with the taxi. Applying this integration on all oclets in the subsequent unification step re- open view 1 view' 1 view'' 1 issues unify define opt. 1 ... granu- ... integration ... unify ... larity options opt. m views view n view' n view'' n integrated done Fig. 5. Procedure for integrating behavioral views. places transitions pick avail. taxi and pick avail. pass each by the integration re- sult match request; see oclets PS2, TS2, and TCS in Fig. 7. One can quickly see that this trip trip taxi taxi integration option alone is insuffi- req. req. data data cient: The reset transition of TCS pick avail. match pick avail. taxi request pass. only resets the passenger thread of taxi trip trip taxi the process while the taxi thread is no no. data data unmodified. A human modeler who inspects the integration result TCS Fig. 6. View integration option can detect this problem. Hence, an- TS2 - taxi standard synch other (obvious) integration option trip taxi req. data that extends transition reset of Fig. 7 PS2 - passenger standard synch match by the dashed dependencies must await request pass. be specified. After this integration taxi trip no. data step, the passenger view and the get taxi request send trip taxi view are integrated, but still taxi details trip exist in isolation. pass. req. data data TCS - taxi cancel synch The integrated service model is match request trip taxi now given by oclets PS2, TR, TS2, taxi trip req. data PC, and TCS. Figure 8 depicts a no. data cancel- match send taxi no. request standard run of the integrated ser- and arr. time led taxi trip vice while Fig. 9 depicts a run with await no. data cancelation. Thereby, the match re- pass. reset quest transitions of the various oclets await taxi are merged upon construction of the pass. data runs as they are now pairwise com- patible in term of enabling condi- Fig. 7. Integrated oclets with unified tran- tion and effect. The integration of sitions and enabling conditions. the different scenarios on common transitions is a consequence of our formal model [6]. await await await await pass. taxi pass. taxi get taxi get "taxi get taxi get "taxi request available" request available" trip taxi await pass. trip taxi pass. req. data taxi data req. data data await match get cancel match taxi request request request taxi trip taxi trip no. data no. data send taxi no. send trip cancelled and arr. time details reset await await taxi pass. pass. data Fig. 8. A standard run of the integrated Fig. 9. A run with service cancelation of scenarios ps2, tr, ts2. the integrated scenarios ps2, tr, ts2, pc, tcs. 4 Conclusion We proposed scenarios as behavioral views for modeling complex service orches- trations. The interaction of an orchestrating service with each of its partner services is modeled separately in terms of their interaction scenarios. In a sub- sequent integration step, the different views are first unified in granularity; then integration options for synchronizing different views are defined by the modeler; finally, the views are unified according to the integration options. We proposed the Petri net class of oclets as a formal model for scenarios; their operational semantics allow to construct the behavior of the orchestrator directly from the unified scenarios. Our proposition is a contribution to the relatively novel field of service (or process construction) by view integration [9]. Currently, there exists no system- atic solution for behavioral process integration. Initial works like [4, 10] consider the problem from an information system perspective where database schema in- tegration is extended by considering behavior of data processing as well. The problem of behavioral integration is now also being research in isolation. The general line of research aims on constructing complex, integrated process models by merging smaller process models (the views) on synchronization points. In [11, 12] different behavioral process integration options are considered for construct- ing such merged process models. These integration options can be applied when merging UML activity diagrams for constructing complex process models [3]. Similar results are available for Petri net based models [10] and EPCs [13]. One markable observation in all these approaches is that prior to integration, the process models have to be flattened in order to define and apply the inte- gration options. While some sort of task grouping can still be applied [10], the modeler essentially works on an ever growing complex model. Because process integration involves frequent human interaction (see Sect. 3), this complexity becomes a problem. One of the main problems appears to be that in classi- cal models, behavioral integration is achieved only by model composition. The notion of behavioral view must essentially be given up in order to integrate. Be- cause, at the same time, the model must be flattened, there are no abstraction techniques available to support the modeler in reducing the complexity. We argue that a scenario-based service model, as the one suggested on this paper, preserves the advantages of view-based service definitions. We have that different behavioral views can be unified in a way that they yields behavioral integration of the views while preserving each view. Only local changes must be made to achieve integration. Thus original view, and integrated views can still be related to each other. This provides smaller modeling artifacts, and hence an abstraction technique that suits the problem of process integration. The formal semantics of oclets yields a precise behavioral definition. While the formalization of a scenario as an oclet and its formal semantics are available, the following questions remain to be answered for actually applying oclets for service integration: If two oclets specify behavior at different levels of granularity, how can a common granularity be achieved? What are the available options to integrate two given oclets of same granularity? Can these options be computed automatically? How does the integration of two oclets affect the integration of other oclets? Given a set of integration options, are the unified oclets that realize the integration canonical? Are the integrated oclets consistent? Can inconsistencies be computed automatically? We do not claim this list to be complete, but we consider answers to these questions to be fundamental for a systematic solution for process integration, whether using oclets or any other approach. Acknowledgements We would like to thank Jan Mendling for bringing this topic to our attention and for the reviewers’ comments and suggestions that helped improving this paper. D. Fahland is funded by the DFG-Graduiertenkolleg 1324 “METRIK”. References 1. Papazoglou, M.P.: Agent-oriented technology in support of e-business. Commun. ACM 44(4) (2001) 71–77 2. Dijkman, R.M., Dumas, M.: Service-oriented design: A multi-viewpoint approach. Int. J. Cooperative Inf. Syst. 13(4) (2004) 337–368 3. Grossmann, G., Ren, Y., Schrefl, M., Stumptner, M.: Behavior based integration of composite business processes. In: BPM’05. Volume 3649 of LNCS. (2005) 186–204 4. Schmitt, I., Saake, G.: A comprehensive database schema integration method based on the theory of formal concepts. Acta Inf. 41(7-8) (2005) 475–524 5. Fahland, D., Woith, H.: Towards process models for disaster response. In: Work- shops of the BPM’08, Milan, Italy (September 2008) LNBIP to appear. 6. Fahland, D.: Oclets - a formal approach to adaptive systems using scenario-based concepts. Informatik-Berichte 223, Humboldt-Universität zu Berlin (2008) 7. Lohmann, N., Massuthe, P., Stahl, C., Weinberg, D.: Analyzing interacting WS- BPEL processes using flexible model generation. Data Knowl. Eng. 64(1) (January 2008) 38–54 8. Lohmann, N., Kleine, J.: Fully-automatic Translation of Open Workflow Net Mod- els into Human-readable Abstract BPEL Processes. In: Modellierung 2008. Volume P-127 of LNI., GI (March 2008) 57–72 9. ACM, C.: Special issue: Developing and integrating enterprise components and services. Commun. ACM 45(10) (Oct. 2002) 10. Preuner, G., Conrad, S., Schrefl, M.: View integration of behavior in object- oriented design. Data Knowl. Eng. 36 (2001) 153–183 11. Shen, J., Grossmann, G., Yang, Y., Stumptner, M., Schrefl, M., Reiter, T.: Analysis of business process integration in web service context. Future Generation Comp. Syst. 23(3) (2007) 283–294 12. Grossmann, G., Schrefl, M., Stumptner, M.: Classification of business process correspondences and associated integration operators. In: ER (Workshops). (2004) 653–666 13. Mendling, J., Simon, C.: Business process design by view integration. In: Business Process Management Workshops. (2006) 55–64