HAL Id: inria-00099489https://hal.inria.fr/inria-00099489

Submitted on 26 Sep 2006

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Dynamic Interconnection of Enterprise WorkflowProcesses

Karim Baïna, Khalid Benali, Claude Godart

To cite this version:Karim Baïna, Khalid Benali, Claude Godart. Dynamic Interconnection of Enterprise Workflow Pro-cesses. 10th ISPE International Conférence on Concurrent Engineering : Research and Applications,R. Jardim-Goncalves, Jul 2003, Madère, Portugal. �inria-00099489�

Dynamic Interconnection of Enterprise Workflow Processes

Karim Baïna, Khalid Benali, and Claude GodartLORIA - INRIA - CNRS (UMR 7503)BP 239, F-54506 Vandœuvre-lès-Nancy Cedex, France{baina,benali,godart}@loria.fr

ABSTRACT : Due to business process automation development, process interconnection becomes an importantmatter. Actually, process interconnection mechanisms are indispensable to co-ordinate business processes wi-thin and beyond organisation boundaries, aiming, for instance, to strength awareness inside virtual enterprises,to facilitate multinational e-transactions, etc. Therefore, thinking and proposing mechanisms to ensure intercon-nection between organisational business processes is becoming a hot research topic. Actually, existing businessprocess modelling and enactment systems (workflow systems, project management tools, shared agendas, todo lists, etc.) have been mainly developed to suit enterprise internal needs. Thus most of these systems are notadapted to inter-enterprise co-operation. As we are interested in workflow process integration, we aim, throughthis paper, to provide a model supporting dynamic inter-enterprise workflow process interconnection. We consi-der the interconnection of enterprise workflow processes as the management of a “workflow of workflows” inwhich several heterogeneous workflow management systems (WFMS) coexist. This paper introduces our pro-cess interconnection model, its implementation, and its validation through an experimentation.keywords : integration and interoperability of enterprise workflow applications, Internet-based inter-enterprise business process collaboration, co-operative information systems, business process wrappers, inter-organisational service integration, process interconnection contracts, out-sourcing based workflow interconnec-tion, workflow systems, service exchange paradigm.

1 INTRODUCTION

Our purpose is to provide a framework to supportdynamic enterprise workflow process interconnection.By interconnection of enterprise workflow processes,we mean the management of a “workflow of work-flows” in which several heterogeneous workflow ma-nagement systems will coexist. By dynamics of en-terprise workflow process interconnection, we meanthat process interconnection does not consider neitherpredetermined communication primitives, nor sche-duled points of rendezvous. In other terms, an en-terprise, aiming to interconnect its workflow processwith another organisation workflow process (e.g. forout-sourcing of a piece of specific software develop-ment, for an online command of a service, for dataexchange rendezvous in a virtual enterprise, etc.), hasto discover and co-decide an interconnection contractat runtime. In fact, we have transformed the problemof interconnection of two workflow processes into theproblem of dynamic out-sourcing between these pro-cesses. To be interconnected with other processes, aworkflow process out-source dynamically parts of it

to the other workflow processes. This enables inter-actions resulting from workflow interconnection to belimited in the time (i.e. to the out-sourcing period) andthen to be well managed and controlled. Our paper’saim is to present our process service interconnectionmodel, and is structured as follows : section 2 presentsthe process interconnection state of the art, section 3formalises our process service interconnection model,section 4 presents an implementation of our model,and finally section 5 gives some hints on experimen-tation we made to validate our approach.

2 PROCESS INTERCONNECTION : PROBLEMS ANDSTATE OF THE ART

Due to business process automation development,process interconnection becomes an important matter.Although a wide spectrum of tools for process model-ling and enactment exists (workflow systems, projectmanagement tools, shared agendas, to do lists, etc.),they have been developed to suit the intern needs ofenterprises, and thus, are not adapted to inter-enterpriseinterconnection. Compared to other enterprise process

systems, workflow processes are the most mature andoperational. Meanwhile, they still have many draw-backs when considering enterprise process intercon-nection. In spite of WFMS normalisation efforts achie-ved by the WfMC (Workflow Management Coalition)((WFMC 1996), (WFMC 1998), (WFMC 2000)), the OMG(Object Management Group) ((OMG 2000a), (OMG 2000b))and the IETF (Internet Engineering Task Force) ((Whi-tehead and Wiggins 1998), (IETF 1999)), existing workflowmanagement systems are :

– heterogeneous : considering their definition andexecution environments (disparate syntax and se-mantics of business process definition languages-BPDL-, ad-hoc process instance management),and their access means (non standard compliantAPI) ;

– and monolithic : considering the absence or thepoorness of their API, and the black box processinstance encapsulation.

Because of heterogeneous and monolithic aspectsof workflow management systems, developping ge-neric models for enterprise workflow process inter-connection is a big deal. In fact, there exist severalapproaches for interconnecting enterprise processes,among which, we highlight the six most important :

– Process message oriented communication :(Baker,Georgakopoulos,Schuster, Cassandra, and Cichocki 1999),(Casati and Discenza 2000), and BizTalk (Microsoft 2000)describe several techniques for workflow processcommunication through asynchronous typed mes-sage passing, with interest to adapt paradigmslike subscribe-notify, push, pull to workflow pro-cesses ;

– Process event synchronisation : (Alonso, Agrawal,and Abbadi 1996), ICN (Ellis 1999), OPERA (Hagenand Alonso 1999), WfMC (WFMC 1996), and WF-nets (van der Aalst 1999) upgrade process messagecommunication paradigms with event coordina-tion languages and algebras for synchronising in-terleaving workflow processes ;

– Process data and interface interoperability : Wf-XML (WFMC 2000), PIP (RosettaNet 2000), e-speak(HP 2001), and WfMC (Fischer 2000) establish inter-operability frameworks for standardising work-flow process data structures and interfaces.

– Process data concurrency and access control :(Alonso, Agrawal, and Abbadi 1996), (Edwards 1996),(Dewan and Shen 1998), and IETF WebDAV (IETF1999) & SWAP (Bolcer and Kaiser 1999) go beyondsimple data interoperability to control access wi-thin shared workflow process dataspaces ;

– Process transactional exchange control : ECOO(Godart, Perrin, and Skaf 1999), TRANSCOOP (Puust-järvi 1999), WIDE (Grefen 1999), WISE (Alonso, Ha-gen, and Lazcano 1999), and MQSeries (Leymann andRoller 2000) consider workflow process as advan-ced transactions, and propose transactional mo-dels forworkflow process execution and data sha-ring management ;

– Process service exchange approach : Serviceconcept has been defined in many research fields :Object Oriented research (OMG 1997), Process Mo-delling research (Georgakopoulos, Schuster, Cichocki,and Baker 1999; Piccinelli 1998; Godart, Perrin, and Skaf1999; Klingemann, Wasch, and Aberer 1999a; Casati, Il-nicki, Jin, and Shan 2000; Grefen, Aberer, Hoffner, andLudwig 2000), Distributed System research (Kutvo-nen 1998; Benatallah, Dumas, Fauvet, and Rabhi 2003),etc. In the field of workflow research, CMI (Geor-gakopoulos, Schuster, Cichocki, and Baker 1999), OCoN(Giese and Wirtz 2000), Crossflow (Grefen, Aberer, Hoff-ner, and Ludwig 2000) & (Klingemann, Wasch, and Abe-rer 1999b), eFlow (Casati, Ilnicki, Jin, and Shan 2000),define process service contracts for workflow pro-cess interconnection. A process service can beseen as a software entity presenting process par-ticularities and outcomes without totally revea-ling the process structure (i.e. its workflow im-plementation). A process service shows a func-tional abstraction of a process (or parts of a pro-cess) provided by an organisation. It specifies theamount of work that the organisation promises tocarry out with a specific quality of service. It alsospecifies which parts of a workflow process it co-vers and how the requester could access to them.Proces service concept has been studied from se-veral point of view : process service executionsemantics abstraction (Georgakopoulos, Schuster, Ci-chocki, and Baker 1999), sub-workflow process ser-vice selection (Klingemann, Wasch, and Aberer 1999a),dynamic process service activities configuration(Casati, Ilnicki, Jin, and Shan 2000), process servicecontrol flow level abstraction (Grefen, Aberer, Hoff-ner, and Ludwig 2000), service methods and eventswrapping (Benatallah, Medjahed, Boughettaya, Elmagar-mid, and Beard 2000), etc. Process service structureis to be seen as a co-operation pattern that rele-vantly supports dynamic workflow process inter-connection and cooperation behaviours.

Compared to other approaches, process service ex-change approach supports enterprise cooperation mo-delling in a very effective way. Actually, by it forcesof abstracting enterprise workflow processes to be in-terconnected, process services are the most adaptedto build high level models for enterprise cooperationand generic models independent of workflow processparticularities. Moreover, process service exchange

approach offers a high level paradigm which is veryopen to extensions dealing with other approches ba-sic paradigms (e.g. communication : message passing,data interoperability ; coordination : event synchroni-sation ; execution control : data access control, tran-saction management, etc.).Hence, to build our dynamic enterprise workflow pro-cess model, we have chosen the process service ex-change approach.

Our process service interconnection model will en-able co-operating enterprises to structure, classify, andcompare process services, to select dynamically a pro-vided process service among those matching a requi-red process service, and finally to keep possible theirbusiness processes co-operating through process ser-vice wrapping. This process service wrapping will rea-lize the out-sourcing based interconnection of eachworkflow process interconnected couples. A processservice may concern either long e-transactions (e.g.outsourcing the development of pieces of software,subscription to full e-learning sessions, etc.), or shorte-transactions (e.g. online book commands, enactmentof administrative processes, data exchange rendezvousin a virtual enterprise, etc.).

Figure 1 – An e-learning interconnection example

Example To illustrate our approach, let us considerthe following example within an e-learning context

(figure 1). It is inspired from a real case of e-learningenterprise (Baïna, Baïna, Baïna, Baïna, Humbert, and Hum-bert 2002). Let

�������������(an knowledge management

and e-learning enterprise) be a service requester enter-prise. Let �� �������

(a web agency enterprise), ������������� �(a site hosting enterprise), and

"!$# �$� �% (an e-learningcontent collection enterprise) be three (among other)service provider enterprises. On the one hand,

�&�'�(!��������

requires three types of services : a portal deve-lopment service ( )�� � � � ��* "+�#,�-+

), a portal hosting ser-vice ( )�� � � � �������$� #.�-+

), and an e-learning content collec-tion service ( / �10�2�� �����3� (� �$� �4#,�%+

). Such requested ser-vices can be implemented by several provided ser-vices. On the other hand, �� �������

proposes an Inter-net site development process service ( 5 �6�7 �����$� ��8#.�-+

),������������� � proposes an Internet site hosting process ser-vice ( 9����$�;: � � ��#.�-+

), and;!<# �$� �% proposes an e-learning

content construction process service ("!=� � 6 ��� #,�%+

). Af-ter process service matching and negotiation sessions,�&�����������

chooses >� ��������with its process service 5 �6?!

7 ����$� ��4#,�%+which matches )�� � � � ��* "+�#,�-+

, �����@�������$� withits process service 9(��$�;: � � ��#,�%+

which matches )�� � � � � !����$� #,�%+

, and;!<# �$� �% with its process service

;!A� � 6 ��� #,�-+which matches / �10�2�� �����3� (� �$� �4#,�-+

.

3 OUR PROCESS SERVICE INTERCONNECTIONMODEL

The modelling of process service interconnectionis based on a metamodel describing our service orien-ted approach, on structures participating to our enter-prise process service interconnection model and onfacilities presenting the dynamics of our model andits operational aspects

3.1 Process Service Approach : Meta ModelTo tackle enterprise process interconnection pro-

blems, our approach considers three abstraction levels(or three layers) : workflow layer, process layer, andprocess service layer (c.f. figure 2).

Figure 2 shows that our oriented process service ap-proach aims to present enterprise workflow processes,evolving inside monolithic and heterogeneous work-flow management systems, as processes able to be in-terconnected through process services. This intercon-nection yields an inter-enterprise process that repre-sents “a workflow of workflows” whose managementis distributed on all interconnected entreprises as fol-lows :

B processes :C Each enterprise possesses several processes ;C A process is composed of several process

activities.B workflows :

C Each process delegates the execution of its

Figure 2 – Interconnection Approach : Meta Model

activities to a workflow ;� The management of a workflow is speci-

fic to its WFMS engine (workflow mana-gement system).

� process services :� A enterprise process activity can be achi-

ved by the entreprise means or by an exter-nal service. We call a service achieving aprocess activity a process service ;

� Each enterprise possesses a requested pro-cess service space and a provided processservice space ;

� A requested process service describes needsto accomplish a process activity ;

� A provided process service encapsulates aprocess that represents an ability to achievea process activity ;

� Process interconnection is done through thewrapping of their requested and providedprocess services.

Figure 3 describes enterprise collaboration withinour process service oriented approach. The operation< ������� � � >represents the publishing (requesting and pro-viding) of a process service, the operation < �� �� >represents the discovery of process service, while theoperation < ���������� ����� >represents a process service pa-rameters negotiation. Finally, the operation < ���� �� >represents the dynamic interconnection between anabstract process service (a requested process service)and a concrete process service offer (a provided pro-cess service). Beside the fact that our approach sup-

ports negotiation facility (which is not ensured by clas-sical service approaches), its strengthens these approa-ches with symmetric aspects of process service publi-shing, discovery, negotiation and interconnection.

Figure 3 – Interconnection Approach : Collaborations

3.2 Process Service Interconnection model : Struc-tures

3.2.1 Process StructureOur process interconnection model is initially ba-

sed on the F. Leymann and D. Roller process defini-tion model (Leymann and Roller 2000). If this model canbe applied very well for traditional workflows (withinone enterprise), it does not consider explicitly processinterconnection. Our objective is to enrich this mo-del with new concepts and definitions in order to sup-port some process interconnection aspects. Most ofstudied interconnection process models focus on pro-cess control flow and data flow definition without ca-ring about two important process access points : pro-cess instance methods and process instance notifica-tion events.

The UML class diagram of the figure 4 defines theenterprise process structure as follows :

– a process is defined by a process graph and a pro-cess interface ;

– a process graph describes the process control-flow structure (Leymann and Roller 2000). It is thecomposition of nodes (process activities), edges(process activities transitions) and conditions (tran-sition guards defined by business rules predicates) ;

– a process interface (or API) is the compositionof methods (gathers all process instance readingand updating methods) and events (process eventnotification that are triggered off from a processinstance during its execution). Process interfacedepends on the process definition and is not com-mon to all processes.

Figure 4 – Process Structure

Example Let us present a process example (figure5) :

Figure 5 – ����������� Process Graph

� ��������� process instance method��� fetchProcessInstanceState(..)��� fetchActivityInstanceState(..)��� fetchWorkItem(..)��� getProcessInstanceAttributeValue(..)��� fetchWorkItemAttribute(..)��� getWorkItem(..)��� fetchActivityInstanceAttribute(..)��� fetchActivityInstance(..)��� getActivityInstance(..)����� getWorkItemAttributeValue(..)����� getActivityInstanceAttributeValue(..)����� fetchProcessInstanceAttribute(..)

� �������� � process instance event!"� TerminatedProcessInstanceNotification!#� StartedProcessInstanceNotification!#� TerminatedActivityInstanceNotification!$� StartedActivityInstanceNotification!#� AvailableNewDataNotification

3.2.2 Process Service StructureThe UML class diagram of the figure 6 defines the

process service structure as follows :– a process service is defined as a specific process

wrapper that has a category, a profile and a visi-bility contract ;

– a process service category determines the pro-cess object type and its classification ;

– a process service profile describes a relationalstructure defining a set of process named-typed-values attributes ;

– a process service visibility contract represents asubset of the wrapped process interface. Other-wise, process service visibility contract "hides"process interface.

Example Let us present a process service example :�����������&% �'��($)+*#*�,.-.��/102/43 process service structure(category = e_learning_portal_development,name = " � �������� �5% �'��(#)+*#*�,.-.��/607/83 ",profile = (duration=3 (month),

price=100 (Keuro),dynamic_sites = true,dbms = "MySQL",XML_use = true,Java_use = true,JSP_use = true,flash_use = false),

process = site_development_process)

� ���������5% �'��(#)+*#*�,�-.��/102/83instance visibility contract method��� fetchProcessInstanceState(..)��� getProcessInstanceAttributeValue(..)����� getActivityInstanceAttributeValue(..)����� fetchProcessInstanceAttribute(..)

� ���������5% �'��(#)+*#*�,�-.��/102/83instance visibility contract event!"� TerminatedProcessInstanceNotification!#� StartedProcessInstanceNotification!#� AvailableNewDataNotification

3.2.3 Process Interconnection through Process Ser-vices

The WfMC has established a well known problemof process interconnection by nested sub-process mo-del. The WfMC nested sub-process model expresses

Figure 6 – Process Service Structure

that an instance of an activity ����� belonging to a pro-cess � � enacts remotely a known instance of an otherprocess ��� and waits for its completion (WFMC 1996).

Moreover, the WfMC has defined eight levels ofprocess interoperability. The coexistence is the secondlowest interoperability level (among these eight le-vels). Coexistent process interconnection are processesthat do not possess any common interoperability stan-dard. They meanwhile share, the same environment -machine or operating system or network- to be able tomanage and achieve parts of the same process (Fischer2000).

Process interconnection through process servicesaims to resolve the problem of coexistent process in-terconnection through a dynamic variant of nested sub-process model. That means that an instance of an ac-tivity ���� of a process � � discovers dynamically a pro-cess ��� that suits its realisation profile, adapts it, wrapsto it, instantiates it, enacts it dynamically, cooperateswith it, and waits for its completion.

Thus a process service structures will be the gluekeeping possible this dynamic coexistent process in-terconnection as shown in the UML class diagramof the figure 7. Our complete approach is detailed in(Baïna 2003).

3.3 Process Service Interconnection model : Dyna-mics

Process service structure is a wrapper that repre-sents a functional and semantic abstraction of a pro-cess. It enables the classification, the indexing, thecomparison, and the discovery of a certain type ofprocess. This supposes that enterprises, within eachbusiness community, agreed about common process

Figure 7 – Process Interconnection through Services

service language (e.g. business key concept ontolo-gies, business service taxonomies,. . . ) to define andunderstand process services. Research and normali-sation work are still emergent in this promising field(UDDI.Org 2000; W3C 2001; Microsoft 2000; UNCEFACT andOASIS 2000).

The dynamics of process service interconnectionmodel will be presented through its facilities of publi-shing, discovering, negotiating and interconnectiongprocess services.

3.3.1 Process Service SpacesThe UML class diagram of the figure 8 defines the

process service spaces structure as follows :

– a process service space is a set composed of pro-cess services ;

– an enterprise possesses four types of process ser-vice spaces :

– private process service space : gathering allprocess services that the enterprise createsand keeps private to other enterprises be-fore its publishing ;

– requested process service space : accessibleprocess service space gathering all processservices that the enterprise requests (expressesthe need of outsourcing to an external en-terprise). Each requested process service knowsits requester enterprise ;

– provided process service space : accessibleprocess service space gathering all processservices that the enterprise can achieve by

Figure 8 – Enterprise Process Service Spaces

her own means (expresses the capability tohandle a requested process service of an ex-ternal enterprise). Each provided process ser-vice knows its provider enterprise ;

– and wrapped process service space : acces-sible process service space gathering all pro-cess services that have been already wrap-ped (their requesting or providing expres-sion has been satisfied by an external pro-cess service). Each wrapped process serviceknows both its requester and provider en-terprise.

3.3.2 Process Service PublishingPublishing of a process service deals with the com-

munication of its description to other enterprises inorder to find common agreement about enterprise pro-cess interconnections. Publishing of a process serviceis the result of the following steps :

1. The enterprise creates its process service withinits private process space ;

2. the enterprise solicits its private process servicespace to publish (request of provide) its createdprocess service ;

3. the private process service space constructs a cloneof the process service and adds this clone to therequested process service space or to the provi-ded process service space depending of the pu-blishing type.

Actually, every subscribed enterprise possesses viewson other enterprise requested and provided processservice spaces. Publishing events notify all subscri-

bed enterprises of the updating of their views. Theseviews permits to every enterprise to discover, to ne-gotiate, and to be interconnected through other enter-prise published process services.

3.3.3 Process Service DiscoveryProcess service discovery deals with the applica-

tion of algorithms that enable the evaluation and com-parison of process services in order to help processservice requesters (or providers) to find the processservices that match their requested (or provided) pro-cess services in the best way. Discovery of a processservice (for instance a requested one) is the result ofthe following steps :

1. The enterprise creates and provides a process ser-vice we will name “ ��������� ��� ” ;

2. for ( � ��������� , i := 1; i <= n; i++) loop(a) the enterprise retrieves descriptions reques-

ted process services published in the provi-ded service space of the enterprise � � :������������������� � !��"���$#�%&�'����( %�)�)�)+* ;

(b) � ���,��� � ���.-/� ���0����������� ;end loop ;

3. the enterprise computes a neighbourhood algo-rithm on the process service ��������� �12� among theset of possible requested process services � ��� .This algorithm iterates on each element of � ��� tofind out the requested process services that suitthe needs of the process service “ ��������� ��� ”. Thisneighbourhood algorithm is based on distancesand matching measures that could be instantia-ted according to the application ;

4. The discovery finishes by building a set of re-quested process services !�34�'�"#�%&34�'��(�%�)�)�)5* that areneighbour to the process service “ ��������� ��� ”.

Process service discovery is symmetric, it meansthat process service requesters can also discover pro-vided process services that suit their needs. More de-tails about matching and distance measures can befound in (Baïna, Benali, and Godart 2001).

Actually, views of subscribed enterprise possesseson other enterprise requested and provided processservice spaces are then organised using discovery mea-sures that permits them to browse a restricted compu-ted projection of the wide process service space.

3.3.4 Process Service NegotiationProcess service negotiation enables to decide dy-

namically and to adapt all interconnection parametersbetween processes to be interconnected (e.g. profile,visibility contract, process graph accessibility, etc.).

Negotiation of a process service is the result of thefollowing steps :

1. solicitation phase : the client contacts primarily

the server and expresses its negotiation request(e.g. a new process service profile, a new processservice visibility contract, etc.) ;

2. effective negotiation phase : the client and theserver exchange messages to build the set of ac-ceptable solutions. An exchange protocol handlesturn taking rules for expressing negotiation acts ;

3. selection phase : finally, the client or the serverchoose a solution among those expressed duringnegotiation phase. The server take its decisionsaccording to the selected solution (e.g. alloca-ting a solicited resource, tuning access rights forsome service, etc.).

Actually, each subscribed enterprise is not only ableto browse its views on other enterprise requested andprovided process service spaces. However, it can alsodynamically change these views by negotiating withprocess services publishers to customise their servicesfor suiting its workflow process out-sourcing needs oroffers.

More details about generic negotiation componentcan be found in (Munier, Baïna, and Benali 2000).

3.4 Process Service interconnection model in action :Protocol

Our process service interconnection protocol en-ables enterprise workflow processes to be intercon-nected and keep possible their cooperation by the fol-lowing four steps :

1. workflow processes definition : every workflowprocess is defined as a graph that manages pro-cess execution model within an enterprise cho-sen workflow management system ;

2. workflow processes adaptation :

– workflow process service provider adapta-tion : a workflow process providing servicesof a certain category has to be associatedto a program or an instance of a class thatimplements the �������������� ���������������������������� cor-responding to this category. This adaptationhas to be written in a language supported orinter-operable with the WFMS ;

– workflow process service requester adap-tation : a workflow process requesting ser-vices has to express that its activities thatneed to be outsourced (interface ������� ) areachieved by external process services. Thisadaptation has to program, in a languagesupported by the WFMS, the enactment ofthe requested process services and the co-operation protocol that will be used to in-teract.

3. dynamic workflow processes interconnection byprocess services :

(a) process service definition : process servicesare created by requester and provider enter-prises within their private process servicespaces. Process services are defined by theirname, textual description, category, profile,encapsulated process (if the process serviceis to be provided) and visibility contract thatdesires (if it is to be requested) or that au-thorises (if it is to be provided).

(b) process service publishing : process servicesare published by enterprises as provided orrequested in their respective accessible re-quested or provided process service spaces ;

(c) process service discovering : process ser-vices publisher can look for process servicesthat suit the needs of its process service de-finition ;

(d) process service negotiation : process servicespublishers can negotiate with each otherstheir process service requested and provi-ded definitions (profile and visibility contract)to agree on common satisfying process ser-vice definition ;

(e) process service wrapping : process serviceswrapping deals with committing and dis-patching agreed process service definitions(profile and visibility contract) on both pro-cess service views (the requester view andthe provider view).

4. workflow processes cooperation through processservices : workflow processes can begin their co-operation through process services that adapt them.This cooperation between wrapped process ser-vices can vary from method invocation or eventpassing (according to agreed visibility contract),to data exchange or synchronisation on processexecution states. workflow processes cooperationthrough process services is to be considered asa generic paradigm that admits a wide panel ofprocess cooperation modes.

4 IMPLEMENTATION

Our dynamic workflow process interconnection mo-del has been implemented within our co-operative en-vironment DISCOBOLE (DIStributed CO-operationand Business prOcess on LinE). DISCOBOLE in-tegrates process and process service structures withtheir manipulation algorithms as innovative CORBAapplication objects gathered inside an process inter-connection and cooperation facilities. Through thesefacilities DISCOBOLE supplies basic mechanisms forprocess interconnection and cooperation applications.

DISCOBOLE is implemented in Java on the CORBAbroker architecture JacORB (Brose and Noffke 2002).

– Process graph : Beside interfaces and classes pre-viously introduced, the UML class diagram ofthe figure 9 introduces the interface ����������� �������� ��� that represents a WFMS. A process graphand its components (interfaces ��������� , ��� � � , !�����and their realization classes) are implemented bya workflow inside a particular WFMS ;

– Process Interface : a process interface is repre-sented by an IDL interface specific to the processapplication domain. This concrete interface ex-tends the interface " �#��$��&%'% and specifies the newprocess category through its fields, methods andevents. Process interface is schematized, in theUML class diagram of the figure 9, by the in-terface ()��*$*�#��+,� " �#��$���%-%&./��+,�0�213�*$�� and its realizationclass ;

– Provider workflow adaptation : both interfaces()��*$*�#��+,� " �#��$��&%'%&./��+,�4�/13�*$&� , (5�6��$0�2�&+,� " �2��$���%-% and their rea-lization class schematize provider workflow adap-tation. To provide a process service of a certaincategory, a workflow provider has to be adaptedby a specific concrete process interface imple-mentation.

– Process meta-information (reflective extraction) :the interface " �2��$���%-% possesses, among others, twooperations ��7�+8���*$8+ _ �0�#�095: ��;=< and �87�+8�#�*$�+ _ ��� � ;=< that ex-tract respectively the profile and the API of aprocess service that is able to encapsulate (i.e.to be provided by) a process. We have chosenJava language reflection to implement both ope-rations. For instance, this permits to dynamicallyexplore an implementation of the interface " �#�0�$&�&%-% , instantiate it by calling dynamically one ofits constructors, etc.

– Process service category, profile, and visibilitycontract : the process service category (class ()���+,� � ���2>�./?@��: ), profile (class " �2�495: �4./?@��: ), and visibi-lity contract (class AB� � ./?@��: ) handle extracted pro-cess meta-information on its interface, relationswith other interfaces, typed attributes, methodsand events;

– Process service : a process service (class C��0�2D � $����./?@��: ) handles process meta-information then makespossible the process service publishing, disco-very, negotiation, and process interconnection, andcontrolled access. A process service is relatedto a process proxy and to the process adapter(Gamma, Helm, Johnson, and Vlissides 1994).A process service is related to process proxy be-cause, it controls dynamically the access to theprocess it encapsulates (process method invoca-tion and process event notification rights). Ho-

wever, a process service cannot be assimilated toa process proxy because it does not supply com-plete or restricted process interface, it also offersmechanisms for discovery, negotiation and inter-connection.Moreover, a process service is related to processadapter because, it procures a new interface tothe process that it adapts (e.g. discovery, nego-tiation, interconnection). Additionally, a processservice is able to dynamically extract the cate-gory and the attributes defining the process it adaptsin order to build a profile enabling process dis-covery and comparison with other adapted pro-cesses. Meanwhile, a process service cannot as-similated to a process adapter because it ensuresadditionally process access control according tonegotiation results.

Figure 9 – Interconnection Model Implementation

5 EXPERIMENTATION

To experiment our enterprise workflow process in-terconnection model, we have deployed our e-learningenterprise context using DISCOBOLE. Each of thefour enterprises EGFH���*� � �4� , �&�IC�+,���2� , �JA � �4��$�> , and (5���6: �K ��%,+ uses a workflow management system to manageits business processes. DISCOBOLE is the environ-ment that will enable them to interconnect dynami-cally these processes.

As shown in figure 10, in our experimentation, weselected and used three heterogeneous WFMS to mo-

del enterprise business processes : a lightweight com-ponent based WFMS Breeze (DSTC 2002), an objectoriented PetriNets WFMS Renew (Kummer, Wienberg,and Duvigneau 2001), and a WfMC compliant WFMSWorkCoordinator (or WCO) (Hitachi 2002; Baïna, Cha-roy, Godart, Grigori, el Hadri, Skaf, Akifuji, Sakagu-chi, Seki, and Yoshioka 2002). These three WFMS arewritten in different languages and evolve in differentenvironments. In order to keep possible the intercon-nection of their defined workflow processes, adapta-tion is achieved according to the WFMS supportedlanguage and environment (c.f. section 3.4). Breezeworkflow processes adaptation has been programmedin Java on a CORBA architecture (ORBacus). WhileRenew workflow processes adaptation, it has been pro-grammed in Java on the same DISCOBOLE CORBAarchitecture (JacORB). Finally, for WorkCoordinatorworkflow processes, the adaptation has been program-med in C++ on WorkCoordinator CORBA architec-ture (VisiBroker).

Figure 10 – Example DISCOBOLE-Deployment

6 CONCLUSION AND PERSPECTIVES

Our paper is a contribution in enterprise workflowinterconnection domain which is a hot reseach topicas far as the current B2B (Business to Business) boomis concerned. In spite of normalisation efforts, WFMS

are still presenting monolithic and heterogeneous draw-backs. Thanks to processes and process services fra-meworks, our model bypasses these drawbacks by en-abling enterprise workflow processes interconnectionwithin a “workflow of workflows” in which severalworkflow management systems coexist. Our modelhas been developed to support a wide panel of work-flow management systems and experimented to provethe realisability of dynamic enterprise workflow pro-cesses.

ACKNOWLEDGEMENTSWe would like to thank W. Gaaloul and S. Baïna fortheir development participation within the project DIS-COBOLE. Moreover, we would like to thank Dr. F. A.Rabhi from School of Information Systems, UNSW,Sydney New South Wales, Australia as well as theanonymous reviewers of this paper.

REFERENCES

Alonso, G., D. Agrawal, and A. E. Abbadi (1996,October). Process Synchronisation in Work-flow Management Systems. In 8th IEEE Sym-posium on Parallel and Distributed Processing(SPDS’97), New Orleans, Louisiana.

Alonso, G., C. Hagen, and A. Lazcano (1999,June). Process in Electronic Commerce. InICDS workshop on Electronic Commerce andWeb-Based Applications, Austin, Texas, USA.

Baker, D., D. Georgakopoulos, H. Schuster,A. Cassandra, and A. Cichocki (1999, Septem-ber 2-4). Providing Customized Process and Si-tuation Awarness in the Collaboration Manage-ment Infrastructure. In 4th IFCIS Int. Conf. onCooperative Information Systems (CoopIS’99),Edinburgh, Scotland, pp. 79–91. IEEE Compu-ter Society Press.

Baïna, K. (2003). Un Modèle Orienté ServicesProcédés pour l’Interconnexion et la Coopé-ration des Procédés d’Entreprises. ComputerPhD Thesis, Université Henri Poincaré - Nancy1, LORIA, France.

Baïna, K., J. Baïna, S. Baïna, S. Baïna, C. Hum-bert, and J.-C. Humbert (2002, June 6-7). bio-expert, Knowledge Management Platform andExperiment for Bio-Medical e-Learning. In 4thInternational Workshop on Enterprise Networ-king and Computing in Health Care Indus-try, Technically co-sponsored by IEEE (Heal-thCom’02), Nancy, France, pp. 138–141.

Baïna, K., K. Benali, and C. Godart (2001, Sep-tember 5-7). A process service model for dy-namic enterprise process interconnection. InC. Batini, F. Giunchiglia, P. Giorgini, andM. Mecella (Eds.), 9th Int. Conf. on Coopera-tive Information Systems, In Cooperation with

IFCIS (CoopIS’01), Number 2172 in LNCS,Trento, Italy, pp. 239–254. Springer-Verlag.

Baïna, K., F. Charoy, C. Godart, D. Grigori,S. el Hadri, H. Skaf, S. Akifuji, T. Sakagu-chi, Y. Seki, and M. Yoshioka (2002, May 1-3). CORVETTE: A Cooperative Workflow De-velopment Experiment. In L. M. Camarinha-Matos (Ed.), 3rd IFIP Working Conference onCollaborative Business Ecosystems and VirtualEnterprises (PRO-VE’02), Sesimbra, Portugal,pp. 169–180. Kluwer Academic Publishers.

Benatallah, B., M. Dumas, M.-C. Fauvet, and F. A.Rabhi (2003). Patterns and Skeletons for Pa-rallel and Distributed Computing, Chapter To-wards Patterns of Web Services Composition,pp. 265–296. Springer-Verlag.

Benatallah, B., B. Medjahed, A. Boughettaya,A. Elmagarmid, and J. Beard (2000, Septem-ber 14-15). Composing and Maintaining Web-based Virtual Enterprises. In 1st Workshop onTechnologies for E-Services, In Cooperationwith VLDB’2000 (TES’00), Cairo, Egypt.

Bolcer, G. A. and G. Kaiser (1999, January-February). SWAP: Leveraging the Web Tomanage Workflow (SWAP). In IEEE Inter-net Computing. computer.org/internet/: IEEEComputer Society.

Brose, G. and N. Noffke (2002). JacORB,www.jacorb.org.

Casati, F. and A. Discenza (2000, March). Suppor-ting Workflow Cooperation Within and AcrossOrganisations. In 15th ACM Symposium on Ap-plied Computing (SAC’00), Como, Italy, pp.19–21.

Casati, F., S. Ilnicki, L. J. Jin, and M. C. Shan(2000, June 8-9). eFlow: an Open, Flexible,and Configurable Approach to Service Compo-sition. In 2nd International Workshop on Ad-vance Issues of E-Commerce and Web-BasedInformation Systems (WECWIS’00), Milpitas,California, pp. 125–132.

Dewan, P. and H.-H. Shen (1998). Flexiblemeta access-control for collaborative appli-cations. In Proceedings of ACM Conferenceon Computer-Supported Cooperative Work(CSCW’98), Primitives for Building FlexibileGroupware Systems, pp. 247–256. ACM Press.

DSTC (2002, February 15). Breeze : workflow withease. Australia, www.dstc.edu.au/Downloads/:DSTC (Distributed Systems TechnologyCentre).

Edwards, W. K. (1996, November). Policies androles in collaborative applications. In Procee-dings of the ACM Conference on Computer

Supported Cooperative Work, Boston, Massa-chusetts, USA, pp. 11–20. ACM Press.

Ellis, C. A. (1999). Computer Supported Coopera-tive Work, Chapter Workflow Technology. JohnWiley and Sons.

Fischer, L. (Ed.) (2000, October). The WorkflowHandbook 2001. Published in association withthe Workflow Management Coalition (WfMC).

Gamma, E., R. Helm, R. Johnson, and J. Vlis-sides (1994). Design Patterns, Elements ofReusable Object-Oriented Software. Massa-chusetts: Addition-Wesley.

Georgakopoulos, D., H. Schuster, A. Cichocki, andD. Baker (1999). Managing Process And Ser-vice Fusion In Virtual Enterprises. InformationSystems, Special Issue on Information SystemsSupport for Electronic Commerce 24(6).

Giese, H. and G. Wirtz (2000). The OCoN Ap-proach for Object-Oriented Distributed Soft-ware Systems Modeling. In Software Enginee-ring and Petri Nets, Workshop within the 21stInternational Conference on Application andTheory of Petri Nets, Aarhus, Denmark, June26.

Godart, C., O. Perrin, and H. Skaf (1999, March23-24). COO : a workflow operator to improvecooperative modelling in virtual processes. In9th International Workshop on Research Issueson Data Engineering : Information TechnologyFor Virtual Enterprises (RIDE-VE’99), Spon-sored by the IEEE Computer Society, Sydney,Australia.

Grefen, P. (1999). Advanced Architectures forTransactional Workflows or Advanced Tran-sactions in Workflow Architectures. In In-ternational Process Technology Workshop(IPTW’99).

Grefen, P., K. Aberer, Y. Hoffner, and H. Lud-wig (2000). CrossFlow: cross-organisationalworkflow management in dynamic virtual en-terprises. In International Journal of Compu-ter Systems, Science and Engineering (IJCS-SE’00), pp. 277–290.

Hagen, C. and G. Alonso (1999, May/June).Beyond the Black Box: Event-based Inter-Process Communication in Process SupportSystems. In 19th International Conference onDistributed Computing Systems (ICDCS’99),Austin, Texas, USA.

Hitachi (2002). WorkCoordinator Workflow Sys-tem. www.hitachi.co.jp/Prod/comp/soft1/wco/:Hitachi Ltd.

HP (2001, January). Architectural Specifica-tion, Release A.0, www.e-speak.net. www.e-speak.net: Hewlett Packard.

IETF (1999, February). HTTP Extensionsfor Distributed Authoring - WEBDAV.www.ics.uci.edu/ webdav: IETF (InternetEnegineering Task Force), Network WorkingGroup.

Klingemann, J., J. Wasch, and K. Aberer (1999a,June 14-18). Adaptative outsourcing in crossorganizational workflows. In 11th Internatio-nal Conf. On advanced Information SystemsEngineering (CaiSE’99), Heidelberg, Ger-many.

Klingemann, J., J. Wasch, and K. Aberer (1999b).Deriving service models in cross organizatio-nal workflows. In 9th International Workshopon Research Issues on Data Engineering: In-formation Technology for Virtual Enterprises(ITVE’99), Sydney, Australia. IEEE ComputerSociety Press.

Kummer, O., F. Wienberg, and M. Duvigneau(2001, July 3). Renew - User Guide. Germany,www.renew.de: University of Hamburg, De-partment for Informatics, Theoretical Founda-tions Group, Distributed Systems Group.

Kutvonen, L. (1998). Trading services in open dis-tributed environments. Computer PhD Thesis,Department of Computer Science, Universityof Helsinki, Finland.

Leymann, F. and D. Roller (2000). ProductionWorkflow, Concepts and Techniques. Prentice-Hall, Inc.

Microsoft (2000, December). Microsoft BizTalkServer : BizTalk Framework 2.0: Documentand Message Specification. www.biztalk.org.

Munier, M., K. Baïna, and K. Benali (2000, Sep-tember 6-8). A Negotiation Model for CSCW.In O. Etzion and P. Scheuermann (Eds.), 5thIFCIS Int. Conf. on Cooperative InformationSystems, In Cooperation with VLDB 2000 (Co-opIS’00), Number 1901 in LNCS, Eilat, Israel,pp. 224–235. Springer-Verlag.

OMG (1997, December 5). Autonomous Decentra-lized Service System (ADSS) Domain SpecialInterest Group Whitepaper ver 1.0 (ads/97-12-01). www.omg.org: OMG (Object Manage-ment Group).

OMG (2000a, February 14). Workflow Manage-ment Facility Convenience Document combi-ning dtc/99-07-05 dtc/2000-02-03 (WF RTF1.3 Report). www.omg.org: OMG (Object Ma-nagement Group).

OMG (2000b, April). Workflow Management Fa-cility Specification, V 1.2. ww.omg.org: OMG(Object Management Group).

Piccinelli, G. (1998, August 20-22). DistributedWorkflow Management: The TEAM Model. In

3rd IFCIS Int. Conf. on Cooperative Informa-tion Systems (CoopIS’98), Sponsored by IF-CIS, The Intn’l Foundation on Cooperative In-formation Systems, New York City, New York,USA, pp. 292–299. IEEE-CS Press.

Puustjärvi, J. (1999). Transactional Workflows. Ph.D. thesis, Department of Computer Science,University of Helsinki, Finland.

RosettaNet (2000, January 4). Partner In-terface Process (PIP) Release 1.3.www.rosettanet.org.

UDDI.Org (2000, September). Universal Descrip-tion, Discovery and Integration (UDDI) Tech-nical White Paper. www.uddi.org.

UNCEFACT and OASIS (2000, October 17).ebXML Technical Architecture Specification.www.ebXML.org.

van der Aalst, W. M. P. (1999). Interorganizationalworkflows: An approach based on message se-quence charts and Petri nets, System Analysisand Modeling, 34(3):335-367.

W3C (2001, March). Web Service Descrip-tion Language (WSDL) version 1.1.www.w3.org/TR/wsdl: W3C (World WideWeb Consortium).

WFMC (1996, October 20). Workflow Stan-dard - Interoperability, Abstract Specifica-tion, WFMC-TC-1012, V. 1.0. www.wfmc.org:WFMC (Workflow Management Coalition).

WFMC (1998, July). Workflow Management Ap-plication Programming Interface (Interface 2and 3) Specification, WFMC-TC-1009, V. 2.0.www.wfmc.org: WFMC (Workflow Manage-ment Coalition).

WFMC (2000, May 1). Workflow Standard - In-teroperability, Wf-XML Binding, WFMC-TC-1023, V. 1.0. www.wfmc.org: WFMC (Work-flow Management Coalition).

Whitehead, E. J. and M. Wiggins (1998,September-October). WebDAV: IETF Stan-dard for Collaborative Authoring on the Web.Software Engineering.