On the Impact of Concurrency for the Enforcement of Entailment Constraints in Process-driven SOAs

Transcription

1 On he Impac of Concurrency for he Enforcemen of Enailmen Consrains in Process-driven OAs Thomas Quirchmayr and Mark rembeck Insiue for Informaion ysems, New Media Lab, WU Vienna, Ausria Absrac. Enailmen consrains, such as muual exclusion or binding consrains, are an imporan means o specify and enforce business processes. However, he inheren concurrency of a disribued sysem may lead o omission. uch failures impac he enforcemen of enailmen consrains in a process-driven OA. In paricular, he impac of hese failures as well as he corresponding counermeasures depend on he archiecure of he respecive process engine. In his paper, we discuss he impac of omission failures on he enforcemen of enailmen consrains in process-driven OAs. In his conex, we especially consider if he respecive process engine acs as an orchesraion engine or as a choreography engine. 1 Inroducion A process-driven OA (see, e.g., [6]) is specifically buil o suppor he definiion, he execuion, and monioring of inra-organizaional or cross-organizaional business processes. In order o conrol and coordinae he services in a process-driven OA, we have o ensure ha he execuion of he differen services adheres o he process flow defined via he corresponding business process. In his conex, a process engine is a sofware componen ha is able o conrol he process flow in a process-driven OA. In general, wo archiecural opions for such process engines exis (see, e.g., [2, 10, 11]). An orchesraion engine acs as a cenral coordinaor ha communicaes wih differen services and conrols he process flow. If we use an orchesraion engine, he services usually have no knowledge abou heir involvemen in one or more business processes. In conras, service choreography relies on collaboraing choreography engines. Each of hese choreography engines conrols a cerain par of he business process (e.g. a cerain sub-process). Thus, in order o execue an enire business process he differen choreography engines (and hereby he services conrolled via hese choreography engines) need o be aware of heir involvemen ino a larger process (o a cerain degree). 1.1 Task-based Enailmen Consrains In a business process conex, a ask-based enailmen consrain places some resricion on he subjecs who can perform a ask x given ha a cerain subjec has performed anoher ask y (see Figure 1 and 2). Enailmen consrains are an imporan means o assis he specificaion and enforcemen of business processes. Muual exclusion and binding consrains are ypical examples of enailmen consrains (see, e.g., [4, 12, 15]).

2 1 2 Business Process User a b c d f e a b RB 1 B c d RB 3 f ervices a b c e d f DME e Execue BP flow Invoke RB 2 Fig. 1. Business Process Example in a OA Fig. 2. Exemplary Enailmen Consrains Muual exclusion consrains can be subdivided ino saic muual exclusion (ME) and dynamic muual exclusion (DME) consrains. A ME consrain defines ha wo asks (e.g. Order upplies and Approve Paymen ) mus never be assigned o he same role and mus never be performed by he same subjec (o preven fraud and abuse). A DME consrain is enforced a he insance-level by defining ha wo asks mus never be performed by he same subjec in he same process insance. In conras o muual exclusion consrains, binding consrains define ha wo bound asks mus be performed by he same eniy. In paricular, a subjec-binding (B) consrain defines ha he same individual who performed he firs ask mus also perform he bound ask(s). imilarly, a role-binding (RB) consrain defines ha bound asks mus be performed by members of he same role bu no necessarily by he same individual. Mos ofen, enailmen consrain are defined in he conex of a corresponding access conrol model. Process-relaed models define enailmen consrains and corresponding access conrol polices in a business process conex (see, e.g., [3, 13, 15]). In a process-driven OA, he respecive process engine mus ensure he consisency of process-relaed models (see, e.g., [8]). 1.2 Moivaion In a process-driven OA (see [6]), he allocaion of asks o subjecs requires ha he process engine and he services exchange corresponding messages. However, in a disribued sysem (see, e.g., [5]) omission failures may occur ha impede he message exchange and hereby he enforcemen of he enailmen consrains. An omission failure occurs, if eiher a message is los (e.g. due o a nework failure) or if a machine crashes. In his conex, orchesraion engines and choreography engines apply differen sraegies o deal wih such failures and o ensure he correc enforcemen of enailmen consrains. 2 Archiecural Opions for Enforcing Enailmen Consrains Figure 3 shows hree basic opions o enforce access conrol policies and enailmen consrains in a process-driven OA. Figure 3(a) shows he mos simple opion where he process engine and all services (in Figure 3 (Web) services are indicaed by circles

3 invoke Domain clien reques Clien PDP use Process Engine Reposiory (a) Local Process Engine clien reques invoke Domain x PDP ub a b PDP clien reques use invoke PDP ub Orchesraion Engine Domain y Reposiory (b) Orchesraion Engine c d invoke a b Domain x clien reques PDP Choreography Engine x use Reposiory invoke c d Domain y clien reques PDP Choreography Engine y use Reposiory (c) Choreography Engines e invoke Domain z clien reques PDP Choreography Engine z use Reposiory iner-domain communicaion inra-domain communicaion Fig. 3. Three archiecural opions o enforce access conrol policies and consrains in a OA including a capial ) ha are conrolled via his process engine are locaed a he same physical machine. This configuraion has he advanage ha he messages ha need o be exchanged beween he process engine and he services do no have o ravel over a nework. Furhermore, because all messages are exchanged on a single machine i is sraighforward o mainain a local hisory log of all ask allocaions and access conrol decisions. However, in an acual OA such a localized archiecure is mos ofen no a viable opion (see, e.g., [6, 7]). Thus, Figures 3(b) and 3(c) skech he archiecures resuling from he use of an orchesraion engine or ineracing choreography engines respecively. Boh opions demand he exchange of messages over a nework (in Figure 3 messages sen over a nework are indicaed by dashed lines). 3 Mainaining Task-allocaion Hisories in Process-driven OAs Figure 4(a) shows ha he allocaion of ai requires an allocaion-reques sen from he orchesraion engine (OE) o Domain x (D x ) which hoss he corresponding service a. In a choreography engines archiecure he asks are allocaed locally (see Figure 4(b)). Addiionally, o allocae asks in process-driven OAs o corresponding enailmen consrains, each process engine a leas needs o know cerain pars of he process hisory. Figure 5 shows differen communicaion schemes of eniies paricipaing in he disribued example business process from Figure 1. I illusraes he process flow and he message exchange ha is necessary o allocae ask insances a runime. An orchesraion engine conrols he enire business process and hus can allocae he ask insances

4 Domain x Domain y Domain z Domain x Domain y Domain z OrchesraionmEngine +maccessmconrol User a b c d e 1 2 f Reposiory PDP x Choreography Engines User a b 1 2 c d f e ervices x PDPmub x x PDPmub x a b c d e x (a) Disribued Business Process Example wih an Orchesraion Engine f PDPmub x l+laccess Conrol ervices x PDP x Reposiory x a b c d e PDP x Reposiory x (b) Disribued Business Process Example wih Choreography Engines f PDP x Reposiory Fig. 4. Business Process Examples in a OA based on differen Process Engines in accordance wih he corresponding enailmen consrains based on a cenral process hisory (see Figure 5(a)). 1. Mainaining hisory informaion in a choreography engines archiecure, on he oher hand, is more complex as here does no exis a single hisory a a cenral locaion (see Figures 5(b) o 5(f)). Differen approaches can be applied o obain hese informaion. Firs, i is possible o reques he allocaion informaion (which subjec, execuing a specific role, is allocaed o a specific ask insance) from he corresponding process engine before a ask insance is o be allocaed (Hisory Pull). The second possibiliy is o send allocaion informaion of ask insances o cerain process engines ex ane (Hisory Push). Boh approaches may operae a he ask level (ask-based), he process-engine level (), or on a global level (cumulaive). A Cumulaive Hisory Push (CU-P) communicaion scheme operaes on a global level (i.e. i involves all choreography engines in a process-driven OA) and exends he hisory wih each access decision and ask allocaion. In a Task-based Hisory Push (TB-P) communicaion scheme a choreography engine noifies he oher engines as soon as a ask is allocaed o an execuingsubjec. In an Engine-based Hisory Push (EB-P) communicaion scheme he hisory push akes place when he process flow is passed from one choreography engine o anoher. In a Task-based Hisory Pull (TB-PL) communicaion scheme a choreography engine performs and on demand requess (pull) for he execuion hisory of a paricular ask.in a Engine-based Hisory Pull (TB-PL) communicaion scheme a choreography engine requess he enire execuion hisory from anoher choreography engine (i.e. he hisory of all corresponding ask insances). 1 The square brackes in Figure 5(a) o 5(f) encompassing he ask insances ci, di and ei indicae, ha exacly one of hem has o be allocaed (see also Figures 1, 2 and 4).

5 h g h' g h'' g h''' g h g h' g OE D x D y alloc ai ai alloc bi bi alloc c/d/ei alloc fi ci di ei ai bi h' g h'' g ci di ei h'' g h'' g h'' g D z (a) Orchesraion Engine fi CE z (b) Choreography Engines - CU-P fi h ai h bi h CEx ai bi ai bi h ai h bi h ci ci di ei ci di ei h ci h di h ei CE z (c) Choreography Engines - TB-P fi CE z (d) Choreography Engines - EB-P fi h ai h bi h CEx ai bi ai bi h ai h ci h bi h ai h bi h'cex ci di ei ci di ei h ci CE z (e) Choreography Engine - TB-PL fi CE z (f) Choreography Engines - EB-PL Hisory Message BP Flow Task Allocaion OE... Orchesraion Engine CE... Choreography Engine D... Domain h... Hisory fi Fig. 5. Hisory Managemen in Process-driven OAs relaed o Figures 1, 2, and 4 4 Omission Failures 4.1 Los Reques or Los Reply Messages Depending on he process hisory scheme (see ecion 3) a los message may have differen consequences on ask allocaion procedures (see Figures 6 o 8). Figure 6 shows los messages in conex of an orchesraion engine archiecure. The reques from he orchesraion engine o allocae a specific ask o a subjec or he of he service domain D x may ge los. However, wihou confirming a ask allocaion he enire business process flow canno be coninued, because he allocaion of subsequen asks may depend on he respecive process hisory (see ecion 3).

6 In a choreography engines archiecure he main problem is he exchange of he process hisory beween he choreography engines. If a choreography engine canno access he process hisory, i canno allocae asks ha mus adhere o enailmen consrains. Figures 7(a) and 7(b) skech he loss of a ask-based respecively hisory push (indicaed as h bi and h respecively). Figure 7(c) shows he loss of a cumulaive hisory push sopping he enire business process (see ecions 1.1 and 3). OE alloc ai D x (a) Los Reques OE alloc ai ok D x ai (b) Los Response Fig. 6. Orchesraion Engine Message Loss h ai h bi h CEx h g h' g ai bi ai bi ai bi h ai h bi h' g ci (a) Los Noificaion ask-based ci (b) Los Noificaion ci (c) Los Noificaion cumulaive Fig. 7. Choreography Engines Message Loss (Hisory Push) h bi h bi bi bi bi bi h bi req ci (a) Los Reques req ci (b) Los Response req h bi ci (c) Los Reques ask-based req h bi ci (d) Los Response ask-based Hisory Message BP Flow Task Allocaion OE... Orchesraion Engine CE... Choreography Engine D... Domain h... Hisory Fig. 8. Choreography Engines Message Loss (Hisory Pull) Figure 8 shows los allocaion hisory reques and messages based on askbased and hisory pull. If a hisory reques (see Fig. 8(a)) or he respecive (see Figure 8(b)) is los, he enire business process may sop which means ha all asks ha have a binding or a muual exclusion consrain o preceding asks, canno be allocaed.

7 4.2 ender and Receiver Crash Figures 9(a) and 9(b) show he crash of a receiver in an orchesraion engine archiecure. In paricular, he crash occurs while rying o allocae a subjec o ask insance ai. In boh cases he allocaion fails and he business process canno be coninued (cf. ecions 1.1 and 3). Figures 10 and 11 depic crashes in a choreography engines archiecure based on hisory push. Figures 10(b), 11(b) and 11(d) show ha a sender crash may no impac he allocaion of subsequen asks (as long as anoher choreography engine conrols he curren business process flow) if he corresponding process hisory was previously delivered from o. A receiver crash may lead o difficulies (see Figures 10(a), 11(a) and 11(c). In paricular, if he receiver (in he example: ) is no able o recover (see, e.g., [5]) before he process flow is passed from o, he process execuion is sopped. On he oher hand, if he receiver recovers in ime, i is possible o allocae ei if we use a cumulaive or hisory push h g h g ' h g h g ' OE ai bi OE ai bi ai bi ai bi alloc ai alloc ai ok h g ' h g ' D x (a) Receiver Crash D x (b) Receiver Crash recovery ei (a) Receiver Crash ci (b) ender Crash Fig. 9. Orchesraion Engine Fig. 10. Choreography Engines - Cumulaive h ai h bi h bi h CEx ai bi bi ai bi bi h ai h bi h bi recovery (a) Receiver Crash ask-based ei ci recovery (b) ender Crash (c) Receiver Crash ask-based ei ci (d) ender Crash Fig. 11. Choreography Engines - Hisory Push h bi h bi bi bi bi bi req h bi ci (a) Receiver Crash ask-based req h bi ci (b) Receiver Crash ask-based req (c) ender Crash ci req ci (d) Receiver Crash Hisory Message BP Flow Task Allocaion OE... Orchesraion Engine CE... Choreography Engine D... Domain h... Hisory Fig. 12. Choreography Engines - Hisory Pull

8 scheme (see ecion 3). In case of a ask-based hisory push Figure 11(a) shows ha h ai could no be delivered and hus ei may no be allocaed. A crash in a choreography engines archiecure ha uses hisory pull scheme may also lead o ask allocaion problems. For example, in Figure 12(a) a crash of may inerrup he process flow because canno allocae ci wihou firs receiving he process hisory from. In a similar way, he process flow is inerruped if crashes afer has sen he process hisory (see Figures 12(b) and 12(d)). However, in he example from Figure 12(c) may crash afer i sen he process hisory o in such as scenario, he process flow will no be inerruped. As i is basically neiher possible for he receiver nor for he sender o clearly disinguish a crash from los messages i may be advanageous o esablish a so called hearbea scheme (see, e.g., [5]). 5 Discussion A Task-Based Hisory Push communicaion scheme requires one message (hisory) respecively wo messages (hisory and confirmaion) for each consraining ask a leas. Moreover, he payload of each message includes a single-ask allocaion record only. Because process conrol is disribued and he allocaion hisories are sen in advance for each consraining ask, he impac of omission failures is small. Moreover, we require an ordering mechanism o ensure he correc submission of mulicas messages (see, e.g., [9]). A choreography engine mulicass is enire allocaion hisory (muliple ask allocaion records) o all choreography engines ha conrol consrained asks. In his scheme, fewer messages are sen (one hisory and possibly a confirmaion message) bu he payload increases (ask allocaion hisory of an enire choreography engine). Also he impac of omission failures increases as he delivery of a hisory may be more ime-criical. Moreover, we require an ordering mechanism o ensure he correc submission of mulicas messages. A Cumulaive Hisory Push scheme requires he smalles number of messages o be sen. The hisory message conains all previous ask allocaion records of he respecive process. Because as single hisory is passed beween he choreography engines, is delivery is sill more ime-criical. However, as mulicasing is no necessary, we do no need o implemen an ordering mechanism. In he Task-Based Hisory Pull scheme, he respecive choreography engine has o reques he allocaion hisory of he consraining ask(s) before allocaing a consrained ask. imilar o ask-based hisory push he message size is small (a reques respecively a consising of a single ask-allocaion record). As he allocaion of a consrained ask heavily depends on he communicaion beween choreography engines, an omission failure may have significan effecs. However, as mulicasing is no necessary here is no need o implemen an ordering mechanism. In a Engine-Based Hisory Pull scheme, each choreography engine requess allocaion hisories when allocaing is firs consrained ask. imilar o hisory push, he number of messages decreases bu heir size increases compared o ask-based hisory exchange. Omission failures may delay ask allocaion for he allocaion of he firs consrained ask. However, as mulicasing is no necessary here is no need o implemen an ordering mechanism. In an Orchesraion Engine he enire business process hisory is

9 mainained locally bu i has o communicae wih he differen remoe services. As here is no need o exchange a hisory, he messages are allocaion requess of small size (a single reques and a respecive confirmaion for each ask o be allocaed). An orchesraion engine archiecure is mos impaced by omission failures. In case he orchesraion engine suffers a crash, he execuion of he enire business process freezes. Each crashed domain, hosing a ask o be allocaed nex, also sops a leas a par of he business process from working. However, as mulicasing is no necessary here is no need o implemen an ordering mechanism. In addiion, he following hree inerrelaed deerminans have o be considered in order o choose a proper process engine archiecure: he number of consrained asks per business process (degree of consrain; DOC), he number of paricipans in he business process (degree of disribuion; DOD) and he number of business process conrol ransiions beween differen paricipans in a business process insance (degree of neworking; DON). According o hese characerisics and he corresponding performance caegories, we can choose he approach ha bes fis a paricular OA. For example, a business process wih a high DOC, a high DOD, and a high DON may bes be handled wih a choreography engines archiecure using an hisory push approach wih confirmaion. On he oher hand, if our focus is on minimized size of messages and minimal coss for implemening an ordering mechanism, an orchesraion engine archiecure may be a beer choice. 6 Relaed Work everal approaches address he enforcemen of enailmen consrains during ask allocaion. In [14], Tan e al. presen an approach for consrain specificaion wihin a workflow auhorizaion schema. Furhermore hey define a se of consisency rules for consrains o preven inconsisencies and ambiguiies beween consrains. Xu e al. [16] consider concurrency in access conrol decisions hrough he developmen of XACML- A, a language o resolve he concurrency problem. However, hey focus on he adminisraion of session-aware models and do no discuss he problems of enforcing enailmen consrains in a disribued environmen. In paricular, hey assume fail-save paricipans and processes, reliable communicaion, as well as a cenralized workflow coordinaor. Ayed e al. [1] discuss he deploymen of workflow securiy policies for iner-organizaional workflow. However, he approach also assumes fail-save hard- and sofware. Our work is complemenary as i discusses he enforcemen of enailmen consrains in disribued sysems a runime considering omission failures. In paricular, we consider omission failures ha may occur in a process-driven OA. 7 Conclusion In his paper, we discussed he impac of omission failures on he enforcemen of enailmen consrains in process-driven OAs. Because he enforcemen of enailmen consrains relies on he availabiliy of a process hisory, we observe differen hisory schemes and examine he impac of failures on archiecures ha use an orchesraion engine or choreography engines respecively. This paper was inspired by our work on he specificaion and enforcemen of enailmen consrains in business processes (see,

10 e.g., [8, 12, 13]) and he implemenaion of a corresponding runime engine 2. In recen years, we see an increasing ineres in process-aware informaion sysems in boh research and pracice. In his conex, an increasing number of exising and fuure sysems will have o be exended wih respecive consisency checks. The discussion from his paper can help o address he challenges ha resul from he deploymen of a process engine in a disribued sysem. References 1.. Ayed, N. Cuppens-Boulahia, and F. Cuppens. Deploying securiy policy in inra and iner workflow managemen sysems evenh Inernaional Conference on Availabiliy, Reliabiliy and ecuriy, 0:58 65, A. Barker, C. D. Walon, and D. Roberson. Choreographing web services. IEEE Transacions on ervices Compuing, 2(2): , E. Berino, E. Ferrari, and V. Aluri. The specificaion and enforcemen of auhorizaion consrains in workflow managemen sysems. ACM Transacions on Informaion and ysem ecuriy, 2(1):65 104, Feb F. Casai,. Casano, and M. Fugini. Managing workflow auhorizaion consrains hrough acive daabase echnology. Informaion ysems Froniers, 3(3): , ep G. Coulouris, J. Dollimore, T. Kindberg, and G. Blair. Disribued ysems: Conceps and Design (5h Ediion). Addison Wesley, May C. Henrich and U. Zdun. Process-Driven OA: Paerns for Aligning Business and IT. CRC Press, Taylor and Francis, M. N. Huhns and M. P. ingh. ervice-oriened compuing: Key conceps and principles. IEEE Inerne Compuing, 9(1):75 81, Jan W. Hummer, P. Gaubaz, M. rembeck, U. Zdun, and. Dusdar. An inegraed approach for ideniy and access managemen in a OA conex. In Proceedings of he 16h ACM ymposium on Access Conrol Models and Technologies, ACMAT 11, UA, L. Lampor. Time, clocks, and he ordering of evens in a disribued sysem. Communicaion of ACM, 21(7): , July N. Milanovic and M. Malek. Curren soluions for web service composiion. IEEE Inerne Compuing, 8(6):51 59, Nov C. Pelz. Web services orchesraion and choreography. IEEE Compuer, 36(10), M. rembeck and J. Mendling. Generic algorihms for consisency checking of muualexclusion and binding consrains in a business process conex. In Proceedings of he 18h Inernaional Conference on Cooperaive Informaion ysems (CoopI), volume 6426 of Lecure Noes in Compuer cience (LNC), pages , M. rembeck and J. Mendling. Modeling process-relaed models wih exended UML aciviy models. Informaion & ofware Technology, 53(5): , K. Tan, J. Crampon, and C. A. Guner. The consisency of ask-based auhorizaion consrains in workflow sysems. In Proceedings of he 17h IEEE Workshop on Compuer ecuriy Foundaions, CFW 04, pages , UA, J. Wainer, P. Barhelmess, and A. Kumar. W- - a workflow securiy model incorporaing conrolled overriding of consrains. Inernaional Journal of Cooperaive Informaion ysems, 12:2003, M. Xu, D. Wijesekera, X. Zhang, and D. Cooray. Towards session-aware adminisraion and enforcemen wih XACML. In Proceedings of he 10h IEEE Inernaional Conference on Policies for Disribued ysems and Neworks, POLICY 09, UA, available from: hp://wi.wu.ac.a/home/mark/businessaciviies/library.hml