Jae-yoon Jung, Wonchang Hur, Hoontae Kim, and Suk-Ho Kang

Transcription

1 Business Process Choreogrphy for B2B Collortion Je-yoon Jung, Wonchng Hur, Hoonte Kim, nd Suk-Ho Kng Deprtment of Industril Engineering, Seoul Ntionl University, Seoul, , Repulic of Kore Astrcts We propose methodology for usiness process choreogrphy. Our methodology provides specifictions of two types of usiness processes (Contrct Process nd Executle Process), nd n interfce protocol to represent interoperility ptterns etween the processes. Through our pproch, existing processes usully mnged y compnies own internl WFMS cn e put together to cooperte nd controlled following consistent procedure. We lso implemented prototype usiness process mngement system to support our usiness process choreogrphy methodology. The system is uilt on top of existing WFMS s. It fcilittes cretion nd instntition of Contrct Processes, nd mnges n utomtic execution of the Interfce Protocol. Keywords: Business process choreogrphy, Process interoperility ptterns, B2B collortion 1. INTRODUCTION Tody s e-usiness environment urges mny compnies to cooperte with ech other. For costeffective nd rpid provision of good services, compny needs to interchnge documents nd relted informtion with mny usiness prtners which include suppliers, customers, nd vrious service providers. In such n environment, usiness processes inevitly get more entngled nd entils collortion etween distriuted nd heterogeneous pltforms which re not esy to mnge. Therefore, systemtic nd utomted mngement of usiness process execution hs drwn gret concern mong compnies nd orgniztions tht necessitte collortive usiness process. BPM (Business Process Mngement) cn e defined s set of services nd tools tht provide explicit process mngement (e.g., process nlysis, definition, execution, monitoring nd dministrtion), including support for humn nd ppliction-level integrtion. 1 It is ssocited with numer of technologies, such s workflow, Enterprise Appliction Integrtion (EAI), B2Bi, nd lso with concepts such s Business Process Reengineering (BPR), Business Process Automtion (BPA) nd Business Process Integrtion (BPI). 2 In n effort to relize the concept of BPM, vrious usiness process specifictions re recently proposed, nd they mke it possile to define structure of usiness process, exchngele messges nd opertions. They lso mke it possile to incorporte externl we services for modeling collortion with externl service providers. 3 However, they do not provide solutions to comine existing workflow or internl processes semlessly in the collortion design. In more intimte e-usiness environments such s supply chin mngement, more ctive collortion is needed t the process level nd t the service nd ppliction level.

2 In this pper, we propose usiness process choreogrphy methodology. Our methodology provides two specifictions tht cn e used to represent two types of usiness processes (Contrct Process nd Executle Process) nd protocol specifiction (Interfce Protocol) used to represent interction etween the processes. Through our pproch, existing processes which re usully mnged y compnies own internl WFMS cn e put together nd controlled following consistent procedure. We lso implemented prototype usiness process mngement system to support our usiness process choreogrphy methodology. The system is uilt on top of existing WFMS s which mnge Executle Processes, nd fcilittes cretion nd instntition of Contrct Processes, nd mngement of utomtic execution procedure of the Interfce Protocol. 2. COLLABORATIVE BUSINESS PROCESSES In this chpter, we first provide clssifiction of usiness processes in we-sed B2B environment, nd then descrie how to orgnize them into collortion. The essence of our usiness process choreogrphy is forml methodology to represent interoperility ptterns etween two usiness processes nd to provide wy to systemticlly utomte the ptterns. In our pproch, we chrcterize collortive usiness process s prticulr contrct mong usiness prtners. The contrct my involve severl internl processes of the prtners, nd clerly descrie how to ssocite the involved processes. Becuse the contrct itself hs logicl procedure, it lso cn e represented s form of usiness process. We cll the logicl procedure of the contrct Contrct Process (CP), nd the prtners own internl processes Executle Process (EP). A prticulr communiction protocol, clled Interfce Protocol (IP), is defined to specify interctions etween CP nd EP. These concepts cn e defined more specificlly s follows. [Definition of Contrct Process (CP)] CP defines procedurl usiness trnsctions tht ech usiness prtner prticiptes in nd crries out for the purpose of collortion. It is descried s sequence of usiness logics tht contin elements of dt formts, logicl endpoints, security levels, etc. CP cn e expressed y using recently proposed specifictions such s BPML, BPEL4WS nd exml BPSS. [Definition of Executle Process (EP)] EP represents n internl, routine process performed y individul usiness prtners involved in CP. Usully, EPs re controlled y the prtners own WFMS, so it cn e specified using XPDL, which is stndrd workflow definition lnguge. EP itself my not hve ny reltion with specific CP, ut it cn e relted to the CP through IP. [Definition of Interfce Protocol (IP)] IP is used to descrie interoperility reltionships tht one or more EP in usiness prtner intercts with one CP. The reltionships re expressed y mens of interoperility ptterns which will e discussed in the next chpter. Figure 1 shows the reltionship mong CP, EP nd IP in we-sed B2B environment. The figure illustrtes three possile scenrios of n orgniztion intercting with other prtners through our usiness process choreogrphy concept. In the first scenrio, the orgniztion communictes only with externl ppliction services (e.g., we services) of the Prtner 1 through CP. In the second, the orgniztion s CP intercts with EP of the Prtner 2 s well s externl ppliction services of the Prtner 1. The lst one shows n independent collortion scenrio, in which the orgniztion s CP intercts with CP of ll the prtners, s well s EP nd we service.

3 Orgniztion Prtner 1 Users Applictions EP IP CP ppliction service Prtner 2 EP IP CP IP EP EP EP Prtner 3 EP IP CP CP IP EP EP Figure 1. Collortion scenrios This pproch hs severl dvntges s follows over other pproches. - Reusility Our choreogrphy methodology does not require ny modifiction or dpttion of EPs, therefore EPs re totlly reusle. We do not need to use different workflow processes definitions for ech prtner, ut use common definitions if they re identicl. Reuse of EP helps gile nd flexile response to new usiness requirements. - Independence IP gurntees design independence of EP nd CP. In other words, design of IP hs no effect on tht of EP or CP, which implies EP nd CP cn e designed without considering how it will e incorported in IP. Moreover, if it is necessry to modify some usiness logics of EP or CP, we cn modify the CP or EP independently, if the modified prts re not relted to IP. - Flexiility An orgniztion only hs to modify IP, not CP or EP, if he wnts to mke usiness trnsction with new prtner. The process logics of the orgniztion need not to e modified or ltered. Becuse CP supports three collortion scenrios, the orgniztion cn flexily collorte with new usiness prtners in vrious types of collortion environments, shown s Figure PROCESS INTEROPERABILITY In B2B collortion environment, there cn e vrious ptterns of interction mong usiness processes. To support n effective control of the interction, it is required to identify interoperility ptterns nd formlly represent the ptterns. In this chpter, we provide systemtic methodology to fcilitte the forml representtion of the interoperility ptterns. 3.1 Interoperility Ptterns We nlyzed vrious types of interopertion etween usiness processes, nd identified 6 primitive interoperility ptterns which cn e used s uilding locks to express complex interctions. These primitives re extended from WfMC s interoperility models: chined model, nested model, nd synchronized model. 4 First of ll, in chined model, process triggers the cretion nd enctment of nother process, nd then tkes no further interest in the newly creted process. This model is sudivided into the following two types. - Chined Sustitutive (CS) process termintes right fter inititing new process. The newly creted process replces the originl process. - Chined Additive (CA) process just goes on its own execution fter inititing new

4 process. Two processes do not interct gin with ech other. Secondly, in nested model, fter process invokes nother process, the invoking process tkes execution results from the invoked process t prticulr ctivity. We sudivide this model into three ptterns. - Nested Synchronous (NS) return point where process tkes ck the execution results is the sme s the invoking point of the process. The invoked process plys role of su-process sustituting n ctivity in the invoking process. - Nested Deferred (ND) return point is deferred to certin ctivity tht comes fter the invoking point. The intervening ctivities etween the two points re overridden y the new process. - Nested Prllel (NP) NP is the sme s NR except tht the invoking process cn e ctivted fter ll the intervening ctivities re completed. Finlly, the synchronized model is descried s follows. - Prllel Synchronized (PS) two processes re synchronized t specific point. Only fter oth of them rech the point, they cn continue their execution. Figure 1 shows the primitive interoperility ptterns which cn hppen etween two processes. c c c c c e d d CS () chined CA NS ND NP () nested PS (c) synchronized Figure 2. Primitive interoperility ptterns etween two processes One thing tht you need to consider here is the concept of process encpsultion. 5 Encpsulting usiness process is to concel detiled specifiction of the process from externl entities. In other words, if process is not encpsulted, we cn get informtion out how to invoke ctivities in the process, nd directly ctivte them. To interoperte with n encpsulted process, we hve to send messges or rise events to trget enctment system tht controls the process. 3.2 Expression of Interoperility Ptterns To formlly specify the interoperility ptterns, we define 5 interoperility opertions. The opertions represent tomic functions tht re required for process to initite or ctivte services of nother process. The opertions fcilitte messges exchnge or event notifiction etween usiness processes. First of ll, it is required tht process instnce mkes connection with certin process instnce. Instntite opertion requests the other prty s enctment system to crete n instnce

5 of trget process nd return the key of the instnce. Initite opertion requests the system to find one of existing instnces which wit for connection fter previous ctivities hve een done. Next, n invoking process instnce needs opertions to interct with the process instnce which hs een decided y Instntite or Initite opertion. Resume opertion notifies the invoking instnce, which re witing or suspended immeditely fter its invoction, to continue its next ctivities. But, Trnsit opertion sends the notifiction of continution to the invoking instnce which hs done or een doing ppointed ctivities fter its invoction. Finlly, Synchronize opertion expresses Synchronized pttern, tht is, the opertion mkes two process instnces continue their next ctivities fter oth of their ppointed ctivities re done. The chrcteristics of interoperility opertions re compred in Tle 1. First two columns shows Trnsit, Resume nd Synchronized opertions should follow Instntite nd Initite opertions. And in the next two columns, Instntite nd Resume opertions hve the enctment system tret the request immeditely. But Initite, Trnsit, Synchronize opertions hve the enctment system check trnsitions of the trget ctivity ecuse the system should exmine whether or not the previous ctivities of the instnce hve een done. opertions connector follower Tle 1. Process interoperility opertions immedite execution check trnsition stte ttriute Wf-XML Instntite O O O CreteProcessInstnce Initite O O O Notify Trnsit O O O Notify ChngeProcessInstnc Resume O O O estte Synchronize O O Notify Additionlly, ll the opertions, except Synchronize, hve stte ttriutes which descrie sttes of invoking processes fter the execution of opertions. The stte ttriute cn hve one of the following vlues: wited, suspended, terminted, disconnected, nd continued. And, Synchronize opertion implicitly hs continued vlue s its stte ttriute. The stte of Initite nd Invoke opertions decides interoperility ptterns of two processes. To support the effective implementtion of the opertions, Wf-XML messges, shown in the tle, my e exploited. The Wf-XML stndrd provides XML specifictions tht fcilitte XML-sed communiction etween heterogeneous workflow systems. 6 For instnce, the Initite opertion cn request nother process engine to crete trget process instnce y sending the CreteProcessInstnce messge in the Wf-XML specifiction. By composing theses opertions, we cn express the primitive interoperility ptterns descried in the previous section. The expressions of the ptterns re shown in Tle 2. For exmple, the pttern NS cn e expressed y using two opertions of Instntite(stte= wited ) nd Resumed, which implement su-process overriding n ctivity. Tle 2. Expression of primitive interoperility ptterns y interoperility opertions Pttern Expression CS Instntite/Initite(stte= terminted ) Chined CA Instntite/Initite(stte= disconnected ) Nested NS Instntite/Initite(stte= wited ) Resume

6 ND Instntite/Initite(stte= suspended ) Resume NP Instntite/Initite(stte= continued ) Trnsit/Synchronize Synchronized SP Synchronize Noticely, the primitive interoperility ptterns cn e extended to hyrid ptterns y comining ech other. Figure 5 illustrtes the hyrid ptterns comining two ritrry primitive ptterns except chined ptterns. They cnnot e lended with the other ptterns ecuse their connection is lost fter new process strts. The hyrid ptterns lso cn e expressed y the interoperility opertions. For exmple, in the figure, NS ND cn e represented y using three opertions of Initite(stte= wited ), Resume(stte= suspended ) nd Resume(stte= continued ). The other hyrid ptterns cn e expressed in the sme wy. NS ND NS NP ND NP NS PS ND PS NP PS Figure 3. The hyrid interoperility ptterns etween two processes 4. BUSINESS PROCESS CHOREOGRAPHY An overll procedure for usiness process choreogrphy consists of four steps. Firstly, ll prticipnts mke interoperility contrcts nd extrct usiness logics together, nd they design common CP for collortive usiness process. Secondly, ech prticipnt checks out his own internl processes, nd prepres EPs which re necessry for B2B collortion. Finlly, ech prticipnt nlyzes reltionships etween the common CP nd his EPs, nd defines his own IP which formlly specifies interctions etween the CP nd his EPs. Figure 3 illustrtes CP for purchsing process etween customer nd supplier. The CP defines usiness logics nd messge exchnge for the prticipnts to perform the purchsing process. And four EPs in the figure show workflow processes of customer nd supplier. RequestOrder EP R nd CheckInvoice EP C re the customer s own internl process for Purchsing CP P. The supplier lso prticiptes in the CP with CheckOrder EP O nd CreteInvoice EP I.

7 Customer Customer or Supplier Supplier START sendpo purchseorder receiverequest nlyzepo cretepo purchseorder sendrequest modifypo END () RequestOrder EP R cceptnce rejection receiveresponse sendacceptnce cceptnce rejection sendacceptnce sendrejection (d) CheckOrder EP O sendrejection receiveinvoice invoice creteinvoice invoice creteinvoice checkinvoice checkinvoice sendinvoice sendconfirmtion invoiceid sendconfirmtion invoiceid receiveconfirmtion () CheckInvoice EP C (c) Purchse CP R (e) CreteInvoice EP I Figure 4. An exmple of purchsing process To put the interctions into opertion, in the figure, the IP for the customer is defined y ssociting RequestOrder EP R nd CheckInvoice EP C with Purchse CP P. The IP for the supplier is lso defined in the sme wy. We ssume tht EP C is encpsulted nd EP R is not. Now, every interction in IP is trnslted into the interoperility ptterns, nd then specified y using the interoperility opertions. For instnces, s the interoperility pttern etween EP R nd CP P corresponds to the primitive pttern NP s descried in the previous chpter, the first interction etween EP R nd CP P is expressed y Instntite(stte= continued ) opertion nd he second y Trnsit(stte= continued ) or Trnsit(stte= terminted ) opertion. In the cse of EP C, we cn not ssocite CP P directly with ctivities of EP C ecuse of its encpsultion. Insted, the EP C is used only for instntition nd notifiction of its termintion to the invoking process CP P. We cn esily find tht nd the interoperility pttern etween them corresponds to NS, nd EP C cn e expressed y Instntite(stte= wited ) nd Trnsit(stte= terminted ) opertions Figure 4 shows how usiness processes for purchsing re intercted etween common CP nd EPs of the customer. IP contins informtion of the interoperility ptterns nd messge trnsformtion. And ll opertions in the ptterns re mtched to corresponding Wf-XML messges with input/output prmeters. For exmple, if ctivity sendpo in EP R sends CreteProcessInstnce.request messge with OserverKey, ContextDt, nd etc., IP trnsltes purchseorder to PO schem, nd requests CP R of its instntition. At lst, when the key of new CP P instnce is returned to EP R y mens of CreteProcessInstnce.response with ProcessInstnceKey, the first interction is completed.

8 cretepo START sendpo receivejudgment modifypo END () RequestOrder EP R receiveinvoice checkinvoice sendconfirmtion CretProcessInstnce OserverKey, ContextDt ProcessInstnceKey CretProcessInstnce OserverKey, ContextDt ProcessInstnceKey ChngeProcessInstnceStte Stte:Completed, ResultDt Encptultion="No" Pttern= NP" EP R.sendPO CP P.receiveRequest Instntite(stte= continued ) EP C EP C purchseorder PO EP R.receiveJudgment CP P.sendAcceptnce Notify Trnsit(stte= continued ) Notify Event ContextDt judgment cceptnce EP R.receiveJudgment CP P.sendRejection Notify Trnsit(stte= terminted ) Notify Stte:Completed, ResultDt judgment rejection Encptulted workflow process Encptultion="Ye s" Pttern= NS CP P. checkinvoice Instntite(stte= wited ) purchseinvoice invoice CP P. checkinvoice Resume(stte= terminted ) invoiceid invoiceid receiverequest sendrequest receiveresponse sendacceptnce sendrejection creteinvoice checkinvoice sendconfirmtion () CheckInvoice EP C (c) Purchse IP P (d) Purchse CP P Figure 5. IP design for purchsing process The Purchse IP P in Figure 4 is descried in XML specifiction s follows. The IP specifiction is sed on XML Schem which we defined for the prototype system. It hs two Coupling elements to couple EP R nd EP C with CP P. The first Coupling element expresses interoperility pttern NP, nd the second does pttern NS. <InterfceProcess Id= IP_P Nme= Purchse IP xmlns=...> <ContrctProcess Id= CP_P Nme= Purchse CP Encpsulted= No Key= /> <ExecutleProcess Id= EP_R Nme= RequestOrder Encpsulted= No Key= /> <ExecutleProcess Id= EP_C Nme= CheckInvoice Encpsulted= Yes Key= /> <Coupling Id= 1 > <Instntite From= EP_R To= CP_P Stte= continued > <Source Activity= epr:sendpo InputDt= epr:purchseorder /> <Destintion Activity= cpp:receiverequest OutputDt= cpp:po /> </Instntite> <Trnsit From= CP_P To= EP_R Stte= continued > <Source Activity= cpp:sendacceptnce InputDt= cpp:cceptnce /> <Destintion Activity= epr:receivejudgment OutputDt= epr:judgment /> </Trnsit> <Trnsit From= CP_P To= EP_R Stte= terminted > <Source Activity= cpp:sendrejection InputDt= cpp:rejection /> <Destintion Activity= epr:receivejudgment OutputDt= epr:judgment /> </Trnsit> </Coupling> <Coupling Id= 2 > </Coupling> </InterfceProcess>

9 Interoperility opertions Humn Interfce B2B Interfce Business Process Choreogrphy for B2B Collortion 5. SYSTEM DESIGN We implemented prototype system to support usiness process choreogrphy. The overll rchitecture of the system is presented in Figure 5. The system consists of two su-systems of WFMS nd BPMS. WFMS hs its own storge, client tools nd engine(wf_engine), nd tkes the chrge of EP control using them. BPMS hs storge nd n engine for mnging CP(BP_Engine). It lso hs storge nd n interpreter for processing IP(IP interpreter). XPDL XPDL import export` EP Storge IP Storge import CP Storge export` BPML XPDL WFMS BPMS Administrtor Users Admin tool Monitor tool Anlysis tool Worklist Mnger WF_Engine Process control Audits nlysis Tsk schedule Tsk disptch Wf-XML interpreter App. dpter IP Interpreter Pttern control Opertion hndler Schem trnsltor Wf-XML interpreter BP_Engine Process control Audits nlysis Service interfce App. Adpter we services WFMS BPMS Appliction services Interoperility opertions ERP SCM CRM Legcy Appliction Interfce Figure 6. Overll rchitecture of our usiness process choreogrphy system The system uses XML-sed process definitions, which re stored in XML dtse. In detil, workflow process definitions hve een stored in EP storge, sed on XPDL specifictions, defined y WfMC. 7 And collortion process definitions hve een stored in CP storge, sed on BPML specifiction, defined y BPMI. 8 Finlly, IP Storge hs stored IP specifictions, which follows XML schem we defined. WF_Engine nd BP_Engine re enctment engines of WFMS nd BPMS, respectively. Two engines mnipulte the process definitions y two techniques, XPth nd JAXB(Jv Architecture for XML Binging). And, the engines communicte with ech other through the IP interpreter. IP interpreter helps CP nd EP to interct, sed on informtion of interopertion ptterns, opertions nd schem trnsformtion in IP specifiction. Both of two systems hve Wf-XML interpreter nd Appliction dpter. Wf-XML interpreter plys role in trnsltor etween messges nd interoperility opertions. Appliction dpter supports utomted tsks in workflow or usiness collortions. Figure 6 illustrtes n opertion sequence of our system following the execution scenrio of purchsing order process.

10 Internl WF_Engine IP Interpreter BP_Engine IP Interpreter Externl WF_Engine 1) Send Wf-XML messge with purchse order. CretProcessInstnce.Request CretProcessInstnce.Response 2) Execute corresponding opertion to BP_Engine. Initite(stte= continued ) receiverequest 3) Enct contrct process s its specifiction. Initite(stte= continued ) sendrequest 4) Trnslte opertion to Wf-XML messge nd send it to externl Engine. CretProcessInstnce.Request 5) Initite workflow process instnce nd return its key. 7) Receive cceptnce nd terminte the instnce. Notify Trnsit(stte= continued ) sendacceptnce Terminted receiveresponse CretProcessInstnce.Response ProcessInstnceStteChnged 6) Send cceptnce messge for purchse order nd terminte the instnce. Figure 7. Overll rchitecture of our usiness process choreogrphy system 1) Internl WF_Engine sends Wf-XML messge with purchse order to IP interpreter in order to strt new contrct process. 2) IP interpreter execute corresponding opertion to BP_Engine in order to initites the contrct process sed on IP specifictions. 3) BP_Engine cretes nd enct the contrct process instnce. And if it wnts to interct with workflow, it requests for IP interpreter to perform opertions in corresponding IP specifiction. 4) IP interpreter trnsltes opertions to Wf-XML messges nd send them to pre-defined Wf_Engines, which cn e externl WF_Engines. 5) Externl WF_Engine prses the Wf-XML messge. It cretes the workflow process instnce nd returns its key. 6) The Wf_Engine encts the workflow instnce. If the instnce trnsits or chnges its stte, the engine sends Wf-XML messges to its corresponding IP interpreter. 7) Internl WF_Engine receives the Wf-XML messges nd trnsits the corresponding workflow process instnce. 6. CONCLUSION In this pper we proposed methodology of choreogrphing usiness processes to chieve n utomted control of collortive interctions etween usiness prtners. The dvntge of our pproch is tht we cn estlish flexile nd extensile interctions etween prtners involved in B2B collortion without modifying structure of usiness processes of them. This is ecuse we seprted procedurl usiness logics required to complete the interctions from the individul processes involved, nd dopted coupling technique sed on interoperility ptterns etween usiness processes. References 1. Grtner group, Impct of BPM on Appliction Development, Grtner Symposium 2001, Orlndo, Fl., 2001.

11 2. J. Pyke, Wht s hppened to workflow? Informtion Mngement & Technology, vol. 35, no. 6, 2002, pp C. Peltz, We services orchestrtion- review of emerging technologies, tools, nd stndrds, Hewlett Pckrd, Co., WFMC-TC-1012, Workflow Stndrd Interoperility Astrct Specifiction, Workflow Mngement Colition, Winchester, UK, Y. Kim et l., WW-Flow: We-Bsed Workflow Mngement with Runtime Encpsultion, IEEE Internet Computing, vol. 4, no. 3, My/June 2000, pp WFMC-TC-1023, Workflow Stndrd Interoperility Wf-XML Binding, Workflow Mngement Colition, Lighthouse Point, Fl., WFMC-TC-1025, Workflow Process Definition Interfce XML Process Definition Lnguge, Workflow Mngement Colition, Lighthouse Point, Fl., A. Arkin, BPMI Proposed Recommendtion, Business Process Modeling Lnguge, Business Process Mngement Inititive, 2003.