The construction of a complex service orchestration is a tedious and error-prone tasks as multiple service interactions with a single orchestrating service must be speci ed and combined. We suggest to specify a service orchestration in terms of behavioral scenarios that capture a speci c aspect of service interaction, a behavioral view in isolation. By synchronizing the di erent scenarios, the views get integrated and dene the behavior of a complex service orchestration. Our formal model for scenarios and their integration is a class of Petri nets called oclets.
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 t, 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 principle, a projection of a complete behavioral model onto a speci c 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 arbitrary 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 process models. While the de nition 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
integration requires an appropriate formal model. In [
In the remainder of this paper, we rst substantiate the concept of a behavioral view in Sect. 2 as we introduce oclets, and their semantics at an intuitive level. We subsequently explain the problem of behavioral integration and suggest 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
For formally modeling services, the Petri net class of open nets has been
established. Open nets allow for a rigorous analysis of behavioral properties of services
while industrial service modeling languages can be translated to open nets [
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 expressed as a set of scenario; a corresponding formal semantics describes how scenarios compose to runs.
In [
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 itatutlyiteiqtvuheaamltlyathnlaenbeprea.lesTdsehnneogredurensvoiinefwFthiagen. do3btvshhioeouwtsasxaeinxdvpileiincw-- PpdCaa-tsasp.ass. cancel lceadncel- pictkaaxiv.atdiala.xtia are not related to each other, while each makes geretqcuaensctel reset sensWeeoncaintseoawsinl y. extend our view based model lceadncel- paawsasit. with another view, see Fig. 2: A passenger may cancel a request at any time (oclet PC); the Fig. 2. Service cancelation by service resets its processing subsequently (PR). passenger and service reset. 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 appended by merging transitions pick avail: taxi of PS and PR.
The run of Fig. 4 shows again that the given behavioral views do not t to each other; the taxi still gets noti ed about the passenger although the request has been canceled. The views must be integrated. 3
We just have introduced oclets as a modeling language for behavioral views and show that if behavioral views do not t to each other, they cannot be composed to a run. In this section, we sketch how behavioral views of services can be integrated to de ne a consistent orchestrator service. taxi data pick avail.
pass. taxi data pick avail.
pass.
We suggest the following integration procedure depicted in Fig. 5. The orchestrator's interaction with each of its partner services is speci ed in a behavioral view. To integrate the di erent views, (1) all views are re ned to the same granularity of resources and tasks; (2) a modeler identi es points of synchronization (speci c resources or tasks) and de nes integration options. Finally, (3) synchronization is made explicit in each scenario by applying the integration options. This adjusts the di erent scenarios to each other s.t. the formal semantics of oclets constructs the orchestrator's behavior by concatenating and merging the now tting scenarios. Possibly, some integration issues are not visible after the rst 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 rst
step changes nothing. We now have to de ne 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 [
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 composition 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 uni cation step replaces transitions pick avail: taxi and pick avail: pass each by the integration result 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 insu - req. req. data data
cient: The reset transition of TCS picktaaxviail. rmeqautcehst picpkaassv.ail.
tohnelyprreosceetsss twhheilpeatshseentgaexri tthhrreeaadd oisf tanxoi tnaox.i datrtiap tdraipta
unmodi ed. 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
tbbhyeasttpheexectiednaedsdhs.etAdrafntdeseriptiteohnnidsreeninscetiteegosrfamFtiuigos.nt7 PS2 - passenger stapaawnsdasait.rd synch rteaqx.i rmeqautcehsdttraipta
step, the passenger view and the get taxi no. data
teaxxisiTtvhiniee wiisnotaleargteriaoitnne.tdegsreartveidce, mbuotdesltiilsl pdaatsas. retrrqierpme.qquauetceshstt tdaaxtia TCS - taxi tcraipncsedelenstydanitclrsihp taxi
now given by oclets PS2, TR, TS2, taxi trip req. data
sPtCa,ndaanrdd rTuCnSo.fFtihgeurinete8grdaetpeidctssera- saennndod.atrar.xtiimnoe. data lceadncel- taxi rmeqautcehst trip
vice while Fig. 9 depicts a run with await no. data
cancelation. Thereby, the match re- pass. reset
aqrueesmt etrragnedsiutipoonns ocfonthstervuacrtiioounsoofctlhetes paawsasit. tdaaxtia
runs as they are now pairwise
compatible in term of enabling condi- Fig. 7. Integrated oclets with uni ed
trantion and e ect. The integration of sitions and enabling conditions.
the di erent scenarios on common transitions is a consequence of our formal
model [
Fig. 9. A run with service cancelation of the integrated scenarios ps2; tr; ts2; pc; tcs.
We proposed scenarios as behavioral views for modeling complex service orchestrations. The interaction of an orchestrating service with each of its partner services is modeled separately in terms of their interaction scenarios. In a subsequent integration step, the di erent views are rst uni ed in granularity; then integration options for synchronizing di erent views are de ned by the modeler; nally, the views are uni ed 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 uni ed scenarios.
Our proposition is a contribution to the relatively novel eld of service (or
process construction) by view integration [
One markable observation in all these approaches is that prior to integration,
the process models have to be attened in order to de ne and apply the
integration options. While some sort of task grouping can still be applied [
We argue that a scenario-based service model, as the one suggested on this paper, preserves the advantages of view-based service de nitions. We have that di erent behavioral views can be uni ed 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 de nition.
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 di erent 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 a ect the integration of other oclets? Given a set of integration options, are the uni ed 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".