Availale online at www.scienceirect.com Proceia Environmental Sciences 11 (2011) 511 517 An ECA-ase Control-rule formalism for the BPEL Process Moularization * Bang Ouyang, Farong Zhong **, Huan Liu Department of Computer Science,Zhejiang Normal University Jinhua 321004, Zhejiang Province, P. R. China,ouy888@163.com, zfr@zjnu.cn, liuhuan04jsj@126.com Astract Because usinesses are constantly changing, the control flow of usiness process must e pluggale, i.e., it shoul e efine in a flexile manner so that any change in the flow can e easily accommoate. The prolem of astraction with respect to languages for We Services Composition has gaine a lot of attention lately. In this paper, An ECAase control-rule formalism is introuce to moularize the monolithic BPEL process structure. Using such a formalism, usiness users not only can moel executale cross-organizational usiness processes, ut also can easily manage changing usiness environments. 2011 Pulishe y Elsevier Lt. Open access uner CC BY-NC-ND license. Selection an/or peer-review uner responsiility of the Intelligent Information Technology Application Research Association. Keywors:component: formalism; BPEL Process; composition language astraction; control-rules; 1.Introuction Business Process Execution Language (BPEL) [1], short for We Services Business Process Execution Language (WS-BPEL) is an OASIS stanar executale language for specifying actions within usiness processes with we services. Processes in Business Process Execution Language export an import information y using we service interfaces exclusively. BPEL has gaine a lot of attraction an support from inustry as well as acaemia. The momentum of BPEL is seen through case stuies, an a large numer of BPEL engine implementations in the inustry suggest that BPEL will e the stanar of choice for coorinate We service composition implementations. Service composition shares some common features with workflows [2]. BPEL is ase on the concepts of workflows. However, usinesses are constantly changing, the control flow must e pluggale, i.e., it shoul e efine in a flexile manner so that any change in the flow can e easily accommoate. Keeping this issue in min, a concept of control-rules has een introuce to capture the control flow. In this approach all the activities in the control flow are reay to execute in parallel as soon as the process 1878-0296 2011 Pulishe y Elsevier Lt. Open access uner CC BY-NC-ND license. Selection an/or peer-review uner responsiility of the Intelligent Information Technology Application Research Association. oi:10.1016/j.proenv.2011.12.081
512 Bang Ouyang et al. / Proceia Environmental Sciences 11 (2011) 511 517 starts, ut the execution sequence is governe y links that propagate from activity to activity. Using rules the moeler can specify the irection of flow from one activity to another ase on an optional conition. 2.Relate Works The prolem of astraction with respect to languages for We services composition has gaine a lot of attention lately. Researchers have approache this prolem from various angles having the same ojective, i.e., to facilitate the process of moeling service compositions. Zeng [3] has evelope a ynamic We service composition system that is capale of ynamic composition an moification of running workflows y using a usiness rule inference engine. Business rule templates are use to efine the usiness policies, which in turn are use to generate process schemas. These rules must e efine y omain experts prior to moeling. An XML ase language is evelope to map the process specifications into the composition engine which runs the process. Our approach on the other han, is uil on top of inustry stanar language an captures rules irectly from the moeler. SWORD [4] is another eveloper toolkit for uiling composite We services using rule-ase plan generation. To create a composite service, the service requestor only nees specify the initial an finial states for the composite service, the plan generation then can e achieve using a rule-ase expert system. Again, this system also oes not utilize BPEL or any other We service stanar, which reners the approach unfeasile in practical use. All the rule ase approaches mentione aove apply pure rule ase methoology. Charfi [5] claim that pure rule ase approach is not appropriate to capture all the aspects of We services composition an put forwar a hyri composition approach. The focus of this research is erive from Aspect Oriente Programming(AOP) an the usiness rules are propose to e implemente in an aspect-oriente extension of BPEL calle AO4BPEL [6]. The usage of such technique requires AO4BPEL complaint implementation, which has not yet een provie. Our approach iffers from the aove work as regars to supporting rule ase We services composition in the following manner: Only one classification of rules is efine that hanle the control flow part of the composition linking activities together. Instea of capturing control flow etails using eclarative if-then rules, which later on raises issues of refinement an transformation complexities, we use rule that are in BPEL native format. 3.Rule Base Composition 3.1.Overview Business rules are pieces of knowlege aout the usiness an it is not appropriate to ury that knowlege eep in coe where no one can ientify it as such [7]. Recently there has een a tren of introucing rules into We services composition [8, 9]. These approaches follow a pure rule ase approach for the composition an encapsulate the whole evelopment life cycle. This pure rule ase approach is not appropriate for eveloping We service compositions [5]. A multitue of rules makes the composition ifficult to unerstan an maintain. We therefore avocate the use of rules for capturing the *Supporte y the National Natural Science Founation of China uner Grant No.60873234. **Corresponing author.
Bang Ouyang et al. / Proceia Environmental Sciences 11 (2011) 511 517 513 control an ata flow only instea of specifying the whole composition process in terms of rules. Our partial rule approach allows for a more unerstanale service composition y reucing complexity an avoiing monolithic process efinitions. The authors in [5] also avocate that usiness rules cannot capture certain aspects of We services composition. For instance, we cannot efine a usiness rule that states that two services shoul e calle in parallel. In fact, what is neee is a tight integration etween rule-ase languages an We service composition languages in orer to e ale to use activities an variales as terms an facts in the rule language. By oing so we will have refine rules at a lower level of execution that can more easily efine control flow semantics of the composition language. Therefore, we propose using BPEL activities as terms in our rule formalism instea of conventional eclarative statements. In BPEL, the core composition specification only efines the asic control an ata flow etween the services to e compose. If we reak own the usiness logic unerlying the composition into several parts or moules, the composition ecomes more flexile since each of these parts can evolve inepenent of the rest an can e create, moifie or elete ynamically at runtime. The iea is to moularize the control flow into iniviual units, each represente as a rule, linking a single pre-activity with a single post-activity so that when usiness policies are suject to change, we only have to moify the corresponing units that moularize the implementation of the usiness process. Moreover, this moularization reuces the complexity of the composition an oosts the aaptaility. 3.2.Control-Rule Formalism Among various types of usiness rules ientifie y researchers [10, 11], one type is the Reaction Rules also known as ECA (Event-Conition-Action) rules that are concerne with the invocation of actions in response to events ase conitions uner which actions must e taken. The control-rules that we use are similar to ECA rules, in that an event is consiere to e completion of an activity, conition specifies the transition conition, an action efines another activity that will e reay to execute after the first activity completes its execution. The structure of a control-rule is as follows: ControlRule { From (activity) [TransitionConition (Boolean expression)] To (activity) Context (flow) } A control-rule links two activities together as a unit/moule. From specifies a source activity upon the execution of which the To or target activity shoul e execute. TransitionConition is an optional Boolean expression that functions as a guar for following this specifie link. If the transition conition is omitte, it is eeme to e present with the constant value true. An if the transition conition evaluate to false, the link is marke as negative an the target activity is not execute. The links following this target activity are also marke as negative, i.e., the consequence of this ecision is to propagate a negative status to the links ownwars. The significance of transition conitions (use along with join conitions) is actuate in the case of choice an ecision patterns. When joining the activities efine y control-rules, the whole control flow is prouce in the form of irecte graph. This graph ase approach oes not require the structure constructs of BPEL. Thus constructs like sequence, flow, an switch are astracte away from the moeler. The control flow is organize using noes that perform work an lines of control etween them escriing the flow of execution. Here an issue arises, i.e., when the processes grows in size an has iterative tasks then maintaining the process ecomes ifficult [12], ecause control lines in such cases may have many tangle inter-epenencies. Changing the flow also ecomes ifficult as the moeler nees to e aware of
514 Bang Ouyang et al. / Proceia Environmental Sciences 11 (2011) 511 517 epenencies of a particular noe across the entire flow. In orer to get ri of this prolem, we propose to use the while structure construct as an iterative activity. Another structure activity that we use is the pick activity which funamentally is more an event management activity than a structure activity. To moel a special case of simultaneously arriving messages we propose another structure activity calle MultipleReceive that is internally represente with a flow construct an can contain more than one receive activities. All these structure activities may constitute a control flow of their own. Thus the control-rules can e hierarchically neste within these structures an the level at which the rule occurs can e ientifie y the Context attriute of the control-rule. In summary the activity of a control-rule can e anyone of the primitive activities of BPEL; assign (for ata transformations); while (for looping); pick (iffere choice, or event); or our own efine MultipleReceive activity. 4.Patterns analyst It is important to analyze the approach regaring various control flow patterns that may e encountere uring moeling. This is to ensure that any possile scenario can e hanle using the control-rule formalism. In this chapter we analyze how the graph oriente structure of our approach can hanle the most commonly occurring workflow patterns. The control flow perspective provies an essential insight into usiness process moeling effectiveness an expressiveness. A conceptual moel shoul escrie all relevant static an ynamic aspects of the prolem at han. This implies that a process moeling technique shoul have sufficient expressive power in orer to moel all possile patterns [13]. As escrie in [14], a pattern is the astraction from a concrete form which keeps recurring in specific non aritrary contexts. Therefore it is important to analyze common patterns encountere in usiness process moeling. We evaluate our approach using a set of workflow patterns ocumente in [15] an communication patterns ocumente in [16] 4.1.Workflow Patterns The workflow patterns have een compile from an analysis of existing workflow languages an they capture typical control flow epenencies encountere in workflow moeling. These patterns are argualy suitale for analysis of We services composition moeling, since the situations they capture are also relevant in this omain. We shall consier the patterns that are supporte y BPEL only [2]. a a c c an a (a) Sequence () Parallel Split (c) Synchronization a c1 c2 c c or a a c3 c1 c2 c3 c () Exclusive Choice (e) Simple Merge (f) Multi-Choice Figure 1. Workflow patterns Sequence: An activity in a workflow process is enale after the completion of another activity in the same process. This pattern can e hanle y using control-rule without any transition conition, originating from an activity a to another activity (see Fig.1(a)). Parallel Split: A point in the process where a single threa of control splits into multiple threas of control which can e execute in parallel, thus allowing activities to e execute simultaneously or in
Bang Ouyang et al. / Proceia Environmental Sciences 11 (2011) 511 517 515 any orer. This pattern can e hanle y using control-rules without transition conitions, originating from one activity a an targeting at ifferent activities, c, to e execute in parallel (see Fig.1()) Synchronization: A point in the process where multiple parallel ranches converge into one single threa of control, thus synchronizing multiple threas. It is an assumption of this pattern that after an incoming ranch has een complete, it cannot e complete again while the merge is still waiting for other ranches to e complete. This pattern can e hanle y control-rules with no transition conition, originating from ifferent activities, c, an targeting at one activity a. An AND join conition must e specifie at the target activity (see Fig.1(c)). Exclusive Choice: A point in the workflow process where ase on a ecision or workflow control ata, one of several ranches is chosen. This pattern is hanle y control-rules originating from one activity a an targeting ifferent activities, c,. Each rule shoul e accompanie with a isjoint transition conition c1, c2 an c3(see Fig.1()) Simple Merge: A point in the workflow process where two or more alternative ranches come together without synchronization. It is an assumption of this pattern that none of the alternative ranches is ever execute in parallel. The pattern can e hanle y using control-rules originate from ifferent activities, c, an targeting at one activity a. An OR join conition must e specifie at the target activity(see Fig.1(e)) Multi-Choice : A point in the process, where, ase on a ecision or control ata, a numer of ranches are chosen an execute as parallel threas. This pattern can e hanle y control-rules originating from an activity a an targeting at ifferent activities, c,. A joint transition conition specifie will result in multiple threas of execution(see Fig.1(f)). Synchronizing Merge: A point in the process where multiple paths converge into one single threa. Some of these paths are active (i.e., they are eing execute) an some are not. If only one path is active, the activity after the merge is triggere as soon as this path completes. If more than one path is active, synchronization of all active paths nees to take place efore the next activity is triggere. This pattern is hanle in the same way pattern simple merge is hanle, i.e., using control-rules originate from ifferent activities, c, an targeting at one activity a an having an OR join conition at the target activity. Implicit Termination: A given su-process is terminate when there is nothing left to o, i.e., termination oes not require an explicit termination activity. Implicit termination is suppose y the flow construct an as we use flow construct to envelope the control flow, the process is terminate implicitly. Multiple Instances without Synchronization: Within the context of a single case, multiple instances of an activity may e create, i.e., there is a facility for spawning of new threas of control, all of them inepenent of each other. This pattern can e hanle y using a while activity with a conition an a context of the case that is spawning off new threa (say process A) an using an invoke activity insie the oy of while that is invoking an operation of another process (say B). The process B will e receiving message from the corresponing invoke of process A which is have the attriute createinstance assigne to yes. This can cause multiple instances. Multiple Instance with Synchronization: This pattern has three su categories. All can e hanle using our approach ecause the solution is ase on while an pick activity which our approach support. For more etails on the solution of these patterns, reaer is referre to [2] Deferre Choice: A point in a process where one among several alternative ranches is chosen ase on information which is not necessarily availale when this point is reache. This can e hanle using pick activity. Cancel Activity an Cancel Case: A cancel activity terminates a running instance of an activity, while canceling a case leas to the removal of an entire workflow instance. Cancel Case is solve with the
516 Bang Ouyang et al. / Proceia Environmental Sciences 11 (2011) 511 517 terminate activity, which is use to aanon all execution within a usiness process instance of which the terminate activity is a part. Cancel Activity is ealt with using fault an compensation hanlers, specifying the course of action in cases of faults an cancellations. 4.2.Communication Patterns. The Communication Patterns are relate to the way in which system moules interact in the context of Enterprise Application Integration (EAI). They are argualy suitale for the analysis of the communication moeling ailities involving We services composition, given the strong overlap etween EAI an We services technologies. Two types of communications are istinguishe, namely synchronous an asynchronous communication. Synchronous communication involves Request/Reply, One-Way an Synchronous Polling patterns, whereas asynchronous communication involves Message Passing patterns. All of these patterns are supporte in our approach using various arrangements of messaging activities, i.e., receive, invoke an reply. Accoring to the type of communication an the activity selecte y the moeler, the system coul attaches variale attriutes to the activity ase on the signatures of operations involve. 5.Contriutions an future research An ECA-ase control-rule formalism is introuce to moularize the monolithic BPEL process structure. A control-rule efines the irection of flow from one activity to another along with a transition conition an it captures the control flow etails of the usiness process. BPEL activities are use irectly as terms in the rule system instea of conventional if-then-else eclarative statements. This helps in efining more refine rules at the execution level that can capture the process ehavioral in more realistic fashion. Changes in usiness policies pertinent to the process flow can e easily incorporate just y changing the rules, proviing agility against change. As the flow is automatically generate using rules, the moeler oes not have to other aout the interepenencies of activities. Also the rules can e change inepenent to each other. Accoring to BPEL specification, an exception, event or a compensation action can span over the entire process, over a group of activities, or over a single activity. Currently exception/event/compensation hanling over the process level an single activity levels supporte. In the future, flexiility will e provie to the moeler to specify these hanlers over multiple activities. This can e achieve y introucing hanler over an iniviual or group of rules. As a single rule can accumulate two activities at a time, it can provie the asis for multiple activity grouping. References [1] OASIS. We Services Business Process Execution Language Version 2.0. OASIS Stanar 11. April 2007. http://ocs.oasis-open.org/wspel/2.0/os/wspel-v2.0-os.html [2] P. Wohe, W.M.P. vaner Aalst, M. Dumas, Arthur H.M. ter Hofstee, Analysis of We Services Composition Languages: The Case of BPEL4W In: Proceeings of the 22n International Conference on Conceptual Moeling (ER 03), Springer-Verlag, vol.2813, pp.200-215, Octoer 2003 [3] L. Zeng. Dynamic We Services Composition. Ph.D. thesis, The School of Computer Science an Engineering, University of New South Wales, August 2003 [4] S. R. Ponnekanti, A. Fox. SWORD: A eveloper Toolkit for We Service Composition. In: Proceeings of the 11th Worl Wie We Conference, Honolulu, HI, USA, 2002 [5] A. Charfi. Aspect-Oriente Workflow Languages: AO4BPEL an Applications. PhD thesis, TU Darmstat, Fachereich Informatik, 2007.
Bang Ouyang et al. / Proceia Environmental Sciences 11 (2011) 511 517 517 [6] A. Chaffi, M. Mezini. Aspect-Oriente We Service Composition with A04BPEL. In: L.J. Zhang, M. Jeckle, Proceeings of European Conference on We Services (ECOWS 04), Erfurt, Germany, Springer-Verlag, vol.3250, p.168., 2004 [7] B. von Halle. Business Rules Applie: Builing Better Systems using the Business Rules Approach. Wiley, 2001. [8] WANG Cong,WANG Zhi-xue,JIANG Guang-jie. Business Process Description Metho Base on ECA Rules. In: Journal of UEST of China. Vol.35 No.1, pp.104-107, Fe. 2006 [9] HE Chunlin, TENG Yun, PENG Renming. We Ser vice Oriente Workflow Moel Base on ECA Rules. In: Computer Science, Vol.36 No.8, pp.112-115, Aug 2009 [10] D. Hay, K. A. Healy. Defining Business Rules-What are they really?. Technical report 1.3, The Business Rules Group, July 2000 http://usinessrulesgroup.org/first_paper/r01c0.htm [11] K. Taveter, G. Wagner. Agent-Oriente Enterprise Moeling Base on Business Rules. In: H. S. Kunii, S. Jajoia, A. Selverg, Proceeings of the 20th International Conference on Conceptual Moeling, Yokohama, Japan, Springer-Verlag, vol.2224, pp.527-540, Novemer 2001. [12] D. Ganesarajah, E. Lupu. Workflow-Base Composition of We-Services: A Business Moel or a Programming Paraigm?. In: Proceeings of the 6th International Enterprise Distriute Oject Computing Conference (EDOC 02), Lausanne, Switzerlan, Septemer, pp.273-284, 2002 [13] B. Kiepuszewski. ExpressiVeness an Suitaility of Languages for Control Flow Moelling in Workflows. Ph.D. thesis, Faculty of Information Technology, Queenslan University of Technology, Novemer 2002 [14] D. Riehle, H. Zullighoven. Unerstaning an Using Patterns in Software Development. Theory an Practice of Oject Systems, 2(1), pp.3-13. 1996. [15] Workflow Management Coalition. Terminology&Glossary. Document Numer WFMC-TC-1011, Document Status- Issue 3.0, Feruary 1999 [16] W. A. Ruh, F. X. Maginnis, W. J. Brown. Enterprise Application Integration:A Wiley Tech Brief. John Wiley an Sons, Inc, 2001