Information Technology and Management 5, 221–250, 2004 2004 Kluwer Academic Publishers. Manufactured in The Netherlands.

Workflow View Driven Cross-OrganizationalInteroperability in a Web Service Environment

DICKSON K.W. CHIU ∗ kwchiu@acm.orgDickson Computer Systems, 7A Victory Avenue, 4th Floor, Homantin, Kowloon, Hong Kong

S.C. CHEUNG and SVEN TILL {scc,till}@cs.ust.hkDepartment of Computer Science, Hong Kong University of Science and Technology, Clear Water Bay,Hong Kong

KAMALAKAR KARLAPALEM kamal@iiit.netInternational Institute of Information Technology, Gachibowli, Hyderabad 500 019, India

QING LI itqli@cityu.edu.hkDepartment of Computer Engineering and Information Technology, City University of Hong Kong,Tat Chee Avenue, Kowloon, Hong Kong

ELEANNA KAFEZA kafeza@aueb.grDepartment of Marketing and Communications, Athens University of Economics and Business, Athens,Greece

Abstract. Workflow technology has recently been employed not only within businesses but also as a frame-work for implementing e-services over the Internet. Such e-services typically require collaborative enact-ment of workflows across multiple organizations. In this paper, we propose the use of workflow views asa fundamental support mechanism for the interoperability of multiple workflows across business organiza-tions. We present a meta-model of workflow views and their semantics using a cross-organization workflowexample based on a supply-chain e-service. We also formulate an interoperation model of workflow viewsand its consistency criteria. Finally, this paper presents an implementation of the model based on XML andcontemporary Web services technologies, with adaptation to our E-ADOME workflow engine.

Keywords: e-service, cross-organizational workflow, workflow views, Web services, interoperation proto-col, workflow view consistency

1. Introduction

Recent advances in Internet technologies have created a global platform for organiza-tions and individuals to communicate with each other, carry out various commercialactivities, and provide value-added services. There is an urgent need for supportingthese activities with cross-organizational workflows, especially because many organiza-tions may have already been employing some kind of workflow technologies. AdvancedWorkflow Management Systems (WfMSs) are now web-enabled and recent research ef-

∗ Corresponding author.

222 CHIU ET AL.

forts in workflow technologies are exploring cross-organizational workflows to modelthese activities (such as [8,9,13,26,33,38,44,46]). In addition, advanced WfMSs canprovide various services such as coordination, interfacing, maintaining a process repos-itory, process (workflow) adaptation and evolution, matchmaking, exception handling,data and rule bases, and so on, with many opportunities for reuse.

A business process is carried out through a set of one or more interdependent ac-tivities, which collectively realize a business objective or policy goal. Workflow is thecomputerized facilitation or automation of a business process. WfMSs can assist inthe specification, decomposition, coordination, scheduling, execution, and monitoringof workflows. In addition to streamlining and improving routine business processes,WfMSs help in documenting and reflecting upon business processes. Often, traditionalWfMSs can only coordinate workflows and their enacting agents (sometimes limited tosoftware processes) within a single organization. However, contemporary WfMSs cannow interact with various types of distributed agents over the Internet.

We adapt the concepts of views from databases to workflows. Views help bal-ance trust and security. That means, only information necessary for process enactment,enforcement and monitoring of the service is made available to both parties, in a fullycontrolled and comprehensible manner. Moreover, each party needs only minor, or none,modification to its own workflow to successfully arrive at a commonly agreed upon andinteroperable interface. This kind of adaptation is only required on the first interaction,and is subsequently reusable, unless their respective workflows are changed drastically.Because an organization is probably interoperating with many other different organiza-tions, different views of a workflow can be presented to different organizations accord-ing to their respective requirements. Due to the popularity of e-commerce, there hasbeen great demand for cross-organizational workflows, which are managed adequatelytogether with agreed upon interaction models. An interaction model refers to a de-tailed plan of a business transaction carried out by at least two parties. It focuses onthe cross-organizational communication part and the exchange of data necessary for theaccomplishment of the transaction.

We have demonstrated the feasibility of modeling and enacting composite e-ser-vices as workflow extensions, and proposed a novel approach for applying workflowviews [18] to e-contracts in a cross-organizational workflow environment. As follow-upwork, the contributions and coverage of this paper are as follows: (i) a refined meta-model of workflow views, (ii) a cross-organizational interoperation model of workflowviews subject to a set of consistency criteria, (iii) details on the facilitation of workflowviews and cross-organizational interoperability with XML and the contemporary Webservices [19] technologies, and (iv) the adaptation of E-ADOME to support the workflowview model.

The rest of the paper is organized as follows. Section 2 presents a motivatingexample to illustrate the concept of workflow views in a cross-organizational workflowenvironment. Section 3 presents the meta-model of workflow views followed by itsinteroperation model in section 4. Section 5 presents the E-ADOME architecture toillustrate how a flexible WfMS engine can be extended to coordinate distributed agents.

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 223

Figure 1. Cross-organizational workflow of a supply-chain example.

Section 6 compares related work. We conclude the paper with plans for further researchin section 7.

2. Motivating example

In this section, we present a motivating example of cross-organizational workflows basedon a supply chain e-service scenario, as depicted in figure 1. The workflows are specifiedas UML activity diagrams. UML (Unified Modeling Language) is chosen because of itsclear semantics and its popularity for describing object-oriented software requirementsand designs [40]. Note that incoming (outgoing) transitions connected to a synchroniza-tion bar, which is represented as a thick line in UML, follow the semantics of AND-joins.Other transitions follow the semantics of XOR-join. There are three types of organiza-tions involved, viz., end-users, system integrators, and parts vendors. Each organizationhas its own individual, rather simple, workflow. Nevertheless, these cross-organizationalinteractions increase the complexity and raise some interesting and complicated issuesdiscussed in this paper.

224 CHIU ET AL.

Figure 2. Workflow view of an end-user towards a system integrator.

The end-user goes through an acquisition workflow, say, for an advanced serversystem. First, quotation enquiries are sent to a number of system integrators. The re-ceived quotations containing price and product information are evaluated. A purchaseorder is then issued to the selected system integrator. The server system is then receivedand checked. Finally, payment is arranged.

A system integrator’s workflow starts when a quotation request is received. Thefirst step is to check from its parts vendors the lead-time and the updated prices of majorparts, especially those with a large price fluctuation (e.g., CPU and memory). Afterthe evaluation, a quotation is sent to the end-user. While the end-user evaluates thequotation, the system integrator may need to provide additional or updated informationfor the bid. After a purchase order is received, the successful system integrator ordersnecessary missing parts, which are not in stock and estimates a delivery schedule. Whenall the parts are ready, the system integrator assembles, tests and delivers the server.Finally, the workflow terminates after the payment is received.

A parts vendor’s workflow also starts when a quotation request is received. As-suming this is the end of the supply chain, the vendor has all necessary information toreply to the system integrator with up-to-date parts information and prices. Assumingthat B-to-B orders on standard parts are usually performed together with the payment,this workflow ends after the delivery of the ordered parts.

In this example, the workflow view of the end-user presented to the system in-tegrator (cf. figure 2) has the following requirements. The end-user’s company profileand other background information are made available on request so that the system in-

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 225

Figure 3. Workflow view of a system integrator towards an end-user.

tegrators can design more personalized proposals. The supplier should be notified ofany changes in delivery requirements or payment arrangements. The enquiry process inparticular is concealed so that the system integrators can bid fairly and independently.

In response, the system integrator may wish to present to the end user a workflowview with the following requirements (cf. figure 3). The system integrator’s companyprofile and technical specifications of the parts used in the proposed server are madeavailable on request so that the end-user can evaluate the quotations more accurately.The end-user should be notified of any changes in the delivery date. Supplementarydetails of the “service preparation” process are available to the end-user to enable theuser to monitor the progress of the job and to estimate the delivery date. During theevaluation process of the end-user an updated quotation (price) might be sent to the end-user with an event-triggering mechanism upon a significant aggregate price change inparts.

Another workflow view is presented by the system integrator to the parts vendor(cf. figure 4) as follows. Based on the system requirements specified in the quotationrequest of the end user, the system integrator checks its parts database and inventorystocks, and inquires updated product and price information of missing parts or parts

226 CHIU ET AL.

Figure 4. Workflow view of a system integrator towards a parts vendor.

Figure 5. Workflow view of a parts vendor towards a system integrator.

with a high price fluctuation. The quotation for the server system can be finalized withthe received data from the parts vendor. After receiving a correct purchase order fromthe end user, the system integrator commences the service preparation by checking theavailability of all necessary part, and if necessary by ordering the missing parts. Theorder of the parts is directly accompanied by the payment. The parts vendor should benotified of any changes in parts’ requirements or payment arrangements. Since the partsvendor is not involved in the remaining workflow the processes can be concealed in thisview.

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 227

Figure 6. Workflow view meta-model in UML class diagram.

A workflow view of the parts vendors is presented to the system integrator(cf. figure 5). Updated prices for the inquired parts are sent to the system integratorswith an event-triggering mechanism. Technical specifications and related informationfor the parts are made available upon request. Updates in software drivers and firmwarewill be broadcast to all affected system integrators using an event-triggering mechanism(which in turn can notify the end-users). In addition, the system integrators should benotified of any changes in lead-time.

3. Workflow views

As shown in the above example, a business process usually involves many participat-ing organizations in a B-to-B e-commerce environment (i.e., such a business processinvolves several interoperating and interacting workflows from different organizations).This is known as a cross-organizational workflow. To support workflow interoperabil-ity, we need a mechanism to allow authorized external parties to access only the relatedand relevant parts of a workflow while maintaining the privacy of other unnecessary orproprietary information. Motivated by views of federated object databases, we proposethe use of workflow views as a fundamental mechanism for cross-organizational work-flow interaction. The integrity between a workflow view and its base workflow will bediscussed later in section 4.2.

3.1. A meta-model of workflow views

The use of workflow views facilitates sophisticated interactions among WfMSs and al-lows these interactions to interoperate in a gray box mode (i.e., they can access eachother’s internal information to some extent). The artifact of workflow views is there-fore a handy mechanism to enact and enforce cross-organizational interoperability overthe Internet. In addition, workflow views are useful in providing access to businessprocesses for external customers or users, including B-to-C e-commerce. For example,external customers or users may want to check the progress or intermediate results ofthe business processes in which they are participating. They might be required to pro-vide additional information or make decisions during business processes. Even within

228 CHIU ET AL.

an organization, workflow views are useful for security applications, such as to restrictthe access to a workflow system (resembling the use of views in databases).

A meta-model of workflow views in UML class diagram is shown in figure 6,illustrating their components and relations. A workflow includes a flow graph of activi-ties and a set of input/output messages. A workflow view is a structurally correct subsetof a workflow. This workflow view model is a refinement of our previous model pro-posed in [18]. The refinement focuses on the development of an interoperation modeland the consistency of workflow views. Figure 7 presents an implementation of ourmeta-model in XML.

Most contemporary WfMSs use a hierarchical composition approach, i.e., a work-flow is composed of activities, which may be iteratively expanded into other workflowsuntil leaf-nodes consisting of atomic activities. For example, the Service Prepa-ration activity in figure 1 is expanded into another workflow. This gives the oppor-tunity to describe a workflow at different levels of granularity. The use of granularitydepends on the level of trust between the involved organizations, and what details of aninternal process an organization wants to disclose to external organizations. A workflowview can be made available as a subset of a workflow. For instance, certain activitiesand their detailed composition may be concealed. The activities in a workflow view mayalso bear different names from those of the original workflow.

To facilitate business organizations exercising different perspectives of a businessprocess, they are classified into groups, also called classes or roles. A role represents acollection of business organizations with similar responsibilities [37]. The role conceptis reminiscent of the “group ids” and “group access rights” of a UNIX system, and also ofthe security model used in Enterprise JavaBeans [45]. A business organization playinga certain role or several roles exercises its access rights at the view level according tothe rights assigned to the specified roles. This approach has been studied for manyyears [5,23], and the National Institute of Standards and Technology (NIST) has triedto unify the most frequently referred to role-based access control (RBAC) models andhas proposed a standard for RBAC [24]. Messages are data objects exchanged in cross-organizational interactions. The attribute user_access of a message may assume avalue of either output or input. The value specifies whether the message is an input oroutput data object in the context of a given workflow view.

3.2. Workflow views in XML

Theoretically, the control flow of a workflow view can be as complicated as one thatcan possibly be constructed using the notations of UML activity diagram. However,the description of such workflow views requires a complex XML schema, such as theBPEL4WS [6] or the Collaboration Protocol Profile [21]. This leads to lengthy work-flow view descriptions. From our experience, most workflow views can be expressedwith sequential activities, augmented with optional and iterative constructs as in regularexpressions [35]. Therefore, our implementation includes a simplified way to specifya workflow view, which will be used in our subsequent discussions. Figure 7 describes

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 229

Fig

ure

7.W

orkfl

owvi

ewm

eta-

mod

elin

XM

L.

230 CHIU ET AL.

a workflow view meta-model that does not contain concurrent activities in XML schema.For ease of comprehension, the schema is given in a tree format generated by the soft-ware tool XML Spy Version 5 from Altova [53]. A workflow view consists of multipleactivities; each of which may in turn be decomposed into another sequence of activ-ities until leaf elements of atomic activities are reached. An atomic activity containsan activityName and maps to an activity in the original workflow, referred to asworkflowActivity. A communication activity may contain a set of messages thatmay take a user_access value of either input or output. An activity receives allits input messages and dispatches all its output messages at the beginning or end of theactivity, respectively. The execution element specifies whether the associated activityis optional or iterative. The default is that the activity will be executed once. A work-flow view is made available to a set of roles identified by their role names. A workflowview may contain an optional set of transitions. If no transitions are explicitly specified,activities in a workflow view are executed sequentially; otherwise, they are executed ac-cording to the transitions augmented with an attribute specifying either an XOR-join orAND-join semantics. The provision of transitions allows specification of complex work-flow views that could not be specified in the simplified version (figure 7), as for example,the AND-join of multiple concurrent activities.

Figure 8 shows the hierarchical structure of the XML-compliant document of aworkflow view presented by Dickson Computer Systems to an end user through a set ofnested containers. The diagram is generated using the development tool XML Spy [53].An XML element that contains child elements is marked by a tiny up-arrow in a grayside bar on the left. The integer parameter 11 in activity(11) indicates the num-ber of activity elements in the sequence. An attribute is denoted with the “=” icon,e.g., = workflowviewName. Actual activities in the original workflow are describedin the element workflowActivity. This element is only available to the providerof the workflow view; it relates activities in the workflow view to those in the originalworkflow. Elements shaded with a light-gray background are optional.

The workflow view D1, as shown in figure 8, includes among others the workflowview name, the provider of the view and a sequence of workflow view activities. Someof these processes, such as Order_missing_parts, are represented in a gray boxmanner through sub workflow views. Furthermore, all necessary incoming and outgoingmessage objects (e.g., QuotationRequest and QuotationResponse) and otherview details, such as the organizations, that have access to the view, are listed.

Figures 8–11 present the four example workflow views of the involved parties,one of an end-user, one of a parts vendor and two of Dickson Computer Systems.Dickson Computer Systems provides two different views, viz. D1 (cf. figure 8) and D2(cf. figure 10). The first view is intended for communication with an end user and thelater for the interoperation with a parts vendor. The view E1 is provided for a supplierby an end user. Finally, the parts vendor grants a view P1 of its workflow to a supplier.These four workflow views are derived from their corresponding workflows depictedin figure 1. The views will be further used in subsequent sections for illustrating thebusiness process interoperation between these two parties.

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 231

Figure 8. Workflow view of a system integrator towards an end-user in XML.

232 CHIU ET AL.

Figure 9. Workflow view of an end-user towards a system integrator in XML.

4. Cross-organization interoperability with workflow views

In this section, we present a model for cross-organizational workflow interoperabilitybased on workflow views with their consistency checking criteria, and show how thismodel can be realized with Web services [19].

4.1. Cross-organizational interoperation model based on workflow views

Based on the workflow view mechanism explained in the previous section, we nowproceed to describe its application in the domain of cross-organizational interopera-tion model. As depicted in figure 12, an interoperation protocol consists of workflowviews, communication scenarios between these views, and a set of interoperation pa-rameters. This information should be stored by each party, which is involved in the

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 233

Figure 10. Workflow view of a system integrator towards a parts vendor in XML.

business process. The communication scenario is represented as a list of communica-tion links. A communication link is associated with one exchanged message, and withits sender and receiver processes, respectively. Furthermore, the response-request rela-tion between communication links can be modeled for storing the partial order of theoccurrence of messages.

In this paper, we concentrate on the situations involving only two organizations,because these are (the basis for) the majority of interoperation scenarios. Furthermore,business processes involving multiple organizations are often solely composed of pair-wise interactions (e.g., end-user with the supplier, supplier with the parts vendor, but notend-user with the part vendor directly).

During the interoperation of a business process the two parties have to agree on acommon workflow, activity assignments, and cross-organizational message exchanges.For example, figure 13 depicts a communication scenario between Dickson ComputerSystems and an end-user in UML sequence diagram. Each organization has its owninternal workflow. In order to interoperate, each organization must be able to view a

234 CHIU ET AL.

Figure 11. Workflow view of a parts vendor towards a system integrator in XML.

Figure 12. Interoperation model in UML.

subset of the other organizations’ workflow that specifies the activities they are obligedto perform. A key issue here is that in every protocol we have to balance two concepts:trust and security. When two organizations interoperate, we assume that there is trustbetween them and that all information necessary for the specification, enforcement andmonitoring of the process are available to both organizations. At the same time, for se-curity reasons no organization wants to reveal more information than necessary. In ourworkflow protocol model, the balance is achieved through the workflow view mecha-nism. Each organization specifies a view of its internal workflow that is accessible to theother one. For example, the end-user specifies at the view level that the activity evaluatequotation becomes visible to Dickson Computer Systems. At the same time, details, i.e.,the sequence of activities, that describe how the quotation is evaluated are not disclosed,

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 235

Figure 13. A communication scenario of an interoperation protocol between two workflow views.

since the user does not want the other organization to get to know the internal evaluationprocedure.

Although we may assume a mechanism that enforces the flow of control in eachorganization’s workflow, the control flow has to be augmented with cross-organizationalcommunications in order to support the specific business process. These communi-cations are useful for information exchange, control exchange and synchronization.In our interoperation model, there are some activities in each workflow view, calledcommunicating activities, through which two organizations communicate. The cross-organizational control and data flow is specified within communicating activities andtheir associated communication links. We associate the message with a label of thecommunication link. Furthermore, each communicating activity receives and sends aset of messages. The order in which these messages occur is crucial. Therefore, withevery communicating activity, a partial order is imposed on each message requiring itto send/receive. For example in figure 13, the Quotation Evaluation activity of the end-user’s workflow has to interact with the Prepare Quotations and Prepare Extra Infoactivities of Dickson Computer Systems. As a result of the Prepare Quotations activity,the end-user receives a QuotationResponse. Afterwards, if desired, he can get additionalinformation by receiving an ExtraInfoResponse message but only after he has sent anExtraInfoRequest.

In addition, synchronization achieved by cross-organizational messages is sym-bolized with a short heavy bar in figure 1. This synchronization symbol representsan and-join. For example, the Quotation Evaluation activity can only be started uponreceiving the QuotationResponse message from Dickson Computer Systems.

236 CHIU ET AL.

4.2. Consistency of interoperation model

An interoperation model will be consistent, if and only if, it satisfies the criteria of in-tegrity and correctness. The integrity criteria concern the consistency between workflowviews and their parent workflows, while the correctness criteria concern the consistencybetween workflow views and their target communication scenarios. Based on automatatheory [35], we develop the following consistency model.

To examine the integrity criteria let us first develop an execution model for work-flows and workflow views. In the model, we assume that each workflow activity ina workflow or workflow view is uniquely labeled. Examples of labels in the SystemIntegrator workflow include Check Parts Info and PrepareQuotation. Fur-ther, we map a communication workflow activity to the name of the exchangedmessage. For example, the workflow activity of receiving an enquiry by the Sys-tem Integrator from the End User is labeled as QuotationRequest. The follow-ing are four example workflow activity sequences exhibited by the System Integrator(cf. figure 1):

(1) 〈QuotationRequest, Check Parts Info, PartsInfoRequest,PartsInfoResponse, PrepareQuotation, QuotationResponse〉

(2) 〈QuotationRequest, Check Parts Info, PartsInfoRequest,PartsInfoResponse, PrepareQuotation, QuotationResponse,ExtraInfoRequest, Prepare Extra Info, ExtraInfoResponse,SystemOrder, Verify&Confirm〉

(3) 〈QuotationRequest, Check Parts Info, PartsInfoRequest,PartsInfoResponse, PrepareQuotation, QuotationResponse,ExtraInfoRequest, Prepare Extra Info, ExtraInfoResponse,SystemOrder, Verify&Confirm, Service Preparation〉

(4) 〈QuotationRequest, Check Parts Info, PartsInfoRequest,PartsInfoResponse, PrepareQuotation, QuotationResponse,ExtraInfoRequest, Prepare Extra Info, ExtraInfoResponse,SystemOrder, Verify&Confirm, Order Missing Parts,DeliveryRequest, DeliveryResponse, Assemble System,Install Software, System Testing〉Furthermore, a composite workflow activity can be replaced by its constituent ac-

tivities, e.g., Service Preparation in example (3) is replaced by its constituentactivities as shown in example (4) above. In addition, concurrent activities can be rep-resented as interleaving activity sequences [29]. For instance, if the receipt of Quota-tionRequest occurs concurrently with Check Parts Info, the workflow activ-ity sequence in the example (1) above will be accompanied by the following sequencein example (5).

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 237

(5) 〈Check Parts Info, QuotationRequest, PartsInfoRequest,PartsInfoResponse, PrepareQuotation, QuotationResponse〉To examine the relation between workflows and workflow views let us define s ↑ L

to be a projection of a sequence s onto a set of labels L, where all labels absent from L

are removed from s. Thus, we have:

(6) 〈QuotationRequest, Check Parts Info, PartsInfoRequest〉 ↑{QuotationRequest, PartsInfoRequest}= 〈QuotationRequest,PartsInfoRequest〉In our model, workflow views are projections of a workflow. We say a workflow

view V is a legitimate projection of a workflow W , if and only if, it satisfies the followingintegrity criteria:

Seq(V ) ⊆ Seq(W) ↑ L(V ),

where Seq(X) and L(X) denote the minimal set containing all possible sequences ex-hibited by X and the set of labels occurred in X, respectively.

That means, the integrity criteria requires a workflow view V exhibiting no activitysequence not found in the original workflow W .

A communication scenario specifies some sequences of messages exchanged be-tween two parties. This scenario is supported collaboratively by two workflow views,one from each party. The following are two possible message sequences specified by thescenario in figure 13.

(7) 〈QuotationRequest, QuotationResponse, ExtraInfoRequest,ExtraInfoResponse, SystemOrder, PartsNotAvailable,Payment〉

(8) 〈QuotationRequest, QuotationResponse, ExtraInfoRequest,ExtraInfoResponse, ExtraInfoRequest, ExtraInfoResponse,SystemOrder, PartsNotAvailable, Payment〉The correctness criteria of these workflow views are that they must be able to

support the prescribed scenario. As before, let Seq(U) and L(U) denote the minimalset containing all sequences specified by a scenario U and the labels of messages in U ,respectively. We say a workflow view V supporting a scenario U satisfies the correctnesscriteria, if and only if:

Seq(U) ⊆ Seq(V ) ↑ L(U).

That means, the correctness criteria requires a workflow view V capable of exhibit-ing all activity sequences as specified in a given communication scenario U . Workflows,workflow views and communication scenarios may evolve as far as they satisfy both theintegrity and correctness criteria after the evolution.

238 CHIU ET AL.

Figure 14. The example communication scenario from figure 13 expressed in XML.

4.3. Implementation of interoperation model in Web services

After two parties have decided to interoperate, they have to arrive at an interoperationprotocol, which specifies the details. If two parties want to form a protocol, first theywill have to decide on the value of the interoperation parameters, as in the followingexample (based on figure 13).

From the above example, we can see that since there is no need for centralizedcontrol, each party to the protocol defines the communicating activities so that it canreceive and send messages appropriately, thus manifesting the required communications.The next step towards an interoperation would be the implementation of the externalinteroperation interface and its configuration.

Web services [19] provide a new interoperable platform for Internet applications.These applications typically offer self-contained and self-describing services that can be

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 239

published, located, and invoked across the Internet. Web services perform functions thatcan be anything from a simple request to complicated processing of business data. Oncea Web service is deployed other applications and Web services can discover and invokethe Web service based on the technologies that support:

(1) a mechanism to register a service;

(2) a mechanism to find a service; and

(3) a mechanism for two parties to communicate.

A service can be invoked by either an application call or a HTTP request througha Web-based interface. This ensures that software systems can be coupled at differ-ent application levels. The Web service architecture is suitable for cross-organizationalcollaboration in a highly dynamic environment as it supports just-in-time integration,encapsulation and interoperation. This allows the implementations to be programminglanguage neutral and communications mechanism independent.

Emerging standardized frameworks, such as the Universal Description, Discov-ery and Integration (UDDI) [47] specifications, support and simplify the way to publishand discover information about Web services. In particular, UDDI aims at enablingbusinesses to find each other, and define how they interact over the Internet and shareinformation in a global registry architecture. Thereby, organizations are enabled to (i) de-scribe their business and their services, (ii) discover other organizations that offer desiredservices, and (iii) integrate with these other businesses.

Web services are described through their interface definitions in the Web ServiceDescription Language (WSDL [52]), which is an XML-based language developed toaddress the following questions about a Web service: (a) What does the service do?(b) How can it be accessed? and (c) Where can it be accessed? These three questionsare mapped to the abstract specification of a service, a specific implementation of thatservice, and the location of the service implementation. The implementation of Webservice interfaces is based on the exchanged messages. In particular, the content and thestructure of the interfaces reflect the exchanged business entities.

Table 1 summarizes a set of possible Web services implemented by Dickson Com-puter Systems to support the incoming external events and their immediate responsesthat are identified from the data requirement analysis of the supply-chain example. Ap-pendix A gives the definition of the QuotationServiceWeb service in Web ServiceDescription Language (WSDL). In this example, the incoming events and their imme-diate responses are handled by one Web service. For example, QuotationRequestis the input message and the QuotationResponse the output message of the Webservice QuotationService. The similarity between the input and the output mes-sages of a communication activity and the interface definition in the Web service de-scription provides a hint to the derivation of potential Web services, especially due tothe fact that all the message exchanges are already represented in XML format. In [12],we further describe how Web services can be derived in detail, and how they can be usedto provide workflow extensions for cross-organizational interoperability.

240 CHIU ET AL.

Table 1Some Web services to be provided by Dickson computer systems.

1. Name: QuotationServiceLocation/Provider:

System IntegratorInput: QuotationRequest

– CustomerInformation

• Name• Address• Customer number

– SystemConfiguration

• NumberOfUnits• Part List• Dimensions

Output: QuotationResponse

– Quotation

• CustomerInformation• SystemConfiguration• ItemizedPriceList• TotalDiscountedPrice• ShippingInformation• TermsOfServices• ExpiryDateOfOffer• DeliveryDate

2. Name: reqPartsQuotationLocation/Provider: Parts VendorInput: PartsQuotationRequest

– CustomerInformation

• Name• Address• Customer number

– RequestedPart

• Part number• Price• Dimensions• NumberOfUnits

Output: PartsQuotationResponse

– Quotation (Pricelist)

• Service• Price• Components

3. Name: reqExtraInfoLocation/Provider:

System IntegratorInput: ExtraInfoRequest

– Customer number• Customer Name• Extra info request number• Quotation/offer number• Quotation date• Request date• Questions

• Question number• Reference to quotation• Intrinsic question

– Requested response time

Output: ExtraInfoResponse

– Supplied extra info

• Extra info request number• Extra info request date• Answers:

∗ Questions number∗ Intrinsic answer

4. Name: payInvoiceLocation/Provider:

SystemIntegratorInput: Payment

– Invoice number– Invoice date– Payer– Payee– Invoice amount

Output: PaymentAcknowledgement

– result (Boolean) successful/unsuccessful

5. Name: orderSystemLocation/Provider:

System IntegratorInput: SystemOrder

– Customer number– Parts quotation/offer number– Delivery address– Requested delivery date– Amount– Total price

Output: OrderConfirmation

– Order successful/unsuccessful– Invoice

• Invoice number• Invoice date• Due date of payment• Bank account info

– Scheduled delivery date

6. Name: orderPartsLocation/Provider: Parts vendorInput: PartsOrder

– Customer number– Parts quotation/offer number– Delivery address– Requested delivery date– Article number– Number of articles– Amount– Article price– Total price– Credit card number/ or other

proof of payment

Output: PartsDelivery

– Order successful/unsuccessful– Bill– Scheduled delivery date

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 241

5. E-ADOME architecture enhanced with Web service

We extend a flexible, web-enabled workflow management system, ADOME-WfMS[15,17,31], into E-ADOME to provide support for specifying, executing and monitor-ing inter-organizational workflows. The most recent updates are the introduction of theWorkflow View Sub-layer and the employment of Web service support [19] to replacea traditional web server. The key features of ADOME-WfMS are as follows: (i) ef-fective coordination of agents (both software and human agents) and an object-orientedcapability-based approach to match activities and agents; (ii) automatic resolution ofexpected exceptions and exception driven workflow recovery; (iii) dynamic binding ofexception handlers to activities with scoping, and to classes, objects and roles; (iv) addi-tion, deletion and modification of exception handlers at run-time through workflow evo-lution support; (v) specifying and reusing exception handlers upon unexpected excep-tions and system-assisted exception handling; and (vi) application of workflow evolutionand workflow recovery in exception handling. As shown in figure 15, the E-ADOMEarchitecture can be divided into the following layers:

1. ADOME/OODBMS Layer – this layer basically consists of an OODBMS and someadditional ADOME facilities. ADOME was developed to enhance the knowledge-level modeling capabilities of OODBMS models [33], in order to more adequatelydeal with data and knowledge management requirements of advanced informationmanagement applications, especially WfMSs.

2. ADOME-WfMS Layer – this is a flexible WfMS built upon ADOME facilities, sup-porting effective management of agents, on-line workflow evolution, and automaticand cooperative exception handling [15,16].

3. E-ADOME Layer – this is the main enhancement layer to the WfMS for ADOME-WfMS to interact with various types of external agents through the Internet, includingcross-organization workflows. This layer consists of the Access Security Sub-layer,Internet Interface Sub-layer, and Workflow View Sub-layers as explained in the nextsub-section.

4. Agents – these are agents, users or organizations providing services or solving prob-lems, and are external to the E-ADOME system.

5.1. E-ADOME layer

The E-ADOME Internet Interface Sub-layer allows ADOME-WfMS to interact withagents through the Internet. It supports effective management of agents, cooperative ex-ception handling, user-driven computer supported resolution of unexpected exceptions,and workflow evolution with a number of key components (cf. figure 15). In particular,Internet Message Sender alerts users and agents via ICQ [30] or e-mail; this modulealso sends out requests to other software agents using a compatible API. An InternetEvent Interceptor receives responses or alerts from software agents through a compati-ble API and translates them to ADOME events (which include exceptions). Note that an

242 CHIU ET AL.

Fig

ure

15.

E-A

DO

ME

arch

itect

ure.

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 243

agent may be internal or external to the organization and may itself be another WfMS.Furthermore an Access Security Sub-layer is added to handle security issues such asauthentication, authorization, and identification.

In order to deal with the interoperation issues in a cross-organizational workflow,the Workflow View Sub-layer has been added. The duties of this sub-layer resemble thetasks of a filter. It decides, based on defined workflow views, if a message or event gener-ated by the WfMS is forwarded to an external agent and if yes, to where and how. On theother hand, incoming messages are checked, and finally, blocked, or distributed to thecorresponding activities. In addition, the workflow views may be used to transform theexchanged data accordingly. The layer may be implemented by means of XML transfor-mation and process languages such as eXtensible Stylesheet Language Transformation(XSLT) [54].

The newly added Web Service Interface module enables E-ADOME to interoperatewith other WfMSs to allow for more advanced activity execution and control in foreignWfMSs. It also enables human agents or users to interact with E-ADOME, to access thedatabase, and to report work progress, in addition to programmed web interface. TheWeb Service Interface module has been integrated without changing underlying layers.

5.2. Discussion

In this section, we have presented the E-ADOME architecture for enacting cross-organizational interoperability in a workflow environment. The enabling power andapplicability mainly rely on the additional Internet interface layer on top of ADOME-WfMS. This interface layer can send and receive messages through the Internet in orderto communicate with distributed users and other service agents. The arrival of incomingmessages can be detected as events to trigger actions of the WfMS specified by bothregular workflow specifications and Event-Condition-Action rules [31]. In particular,the WfMS interface module, now equipped with Web Service mechanism, further facil-itates a cross-organizational workflow enactment. As the E-ADOME extension is builton top of ADOME-WfMS, it is perceived that the techniques presented in this papershould be applicable to other similar WfMSs or other information systems. In order touse this power effectively, we further develop a workflow view mechanism as detailedin previous sections.

When two organizations are interested in interoperating for a certain businessprocess, they exchange initial workflow views of themselves, to disclose their companyprofiles, and to inform the other party of procedures involved in their organization (suchas details of service packages of the service provider and the procurement procedure ofthe end-user). These views also contain information and the coordination requirementsof both parties. However, these requirements often vary in different organizations, i.e.,workflows from different organizations may often have mismatches. As long as there isno standardized workflow specification at an application level for each trade or servicebusiness, we perceive that workflow adaptation is a hard, tedious, yet pertinent problem,which must be adequately addressed. The following different levels of workflow adap-tation may be required for interoperation among different organizations. Note that the

244 CHIU ET AL.

use of workflow views can offer the advantage of shielding their underlying workflowsfrom unnecessary modifications.

1. Workflow views can be modified to accommodate for interface mismatch and minorprocedural differences without the need to modify the internal workflow.

2. Internal workflows need minor adaptation to accommodate for missing proceduresand minor logistic differences (e.g., some companies may not usually pay a deposit,therefore they need to add this activity). This adaptation can be permanent if the orga-nization believes that it is useful for improving the business process (in dealing withother companies or for other reasons); this is known as workflow evolution. A de-tailed description of workflow evolution supported by ADOME-WfMS is availablein [17]. Alternatively, the adaptation can be just a deviation, which is only employedin dealing with this particular business partner.

3. Because there may be major differences in workflows of the two parties, one or bothof them may decide to re-compose their workflows to accommodate the cooperation.Alternatively, and so especially if the business relationship is not a long term one, oneof the two parties may choose to fall back on a manual or semi-manual mode of co-operative work-around. E-ADOME supports interfacing with human users through aWeb-based interface (e.g., the end-user may designate a staff member to enter the or-der form manually through the web page of Dickson Computer Systems), subsequentinteractions can thus be accomplished through email, ICQ alerts [30], and customizedweb pages.

Because an organization may interoperate with many other organizations, differentviews of a workflow may be presented by E-ADOME to different organizations accord-ing to different requirements. For example, Dickson Computer Systems provides twodifferent views of the same workflow, one to an end user and another to a parts vendor.In addition, workflow adaptations, which are sometimes required, are also well sup-ported in E-ADOME. Thus, cross-organizational workflows can be developed fast andmanaged with interoperation protocols adequately. In addition, E-ADOME also supportseffective manual interaction through customized web pages. Furthermore, it should benoted that in all these three cases, the workflow view mechanism is still necessary forproviding controlled external access, security, information hiding, and interoperabilitythrough views as a new mechanism of workflow adaptation.

6. Related work

Our preliminary approach of workflow views has been presented in [14]. This approachhas been motivated by views in object-oriented data models, which dates back to [20],and in particular by imaginary objects in [1]. Gardarin et al. [25] discussed federatedOODBMS and views for objects in a distributed environment. Liu and Shen [36] pre-sented an algorithm to construct a process view from a given workflow, but did notdiscuss its correctness with respect to inter-organizational workflows.

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 245

Van der Aalst and Kumar [1] presented a workflow schema exchange in an XMLdialect called “XRL” but it does not include the support for workflow views. Besides,van der Aalst [3] modeled inter-organizational workflows and the inter-organizationalcommunication structures by means of Petri Nets and message sequence charts (MSCs),respectively. The soundness and consistency of the inter-organizational workflow canbe analyzed by checking the consistency of Petri Nets against target MSCs. Since theauthor abstracted from data and external triggers, the proposed communication protocolis not as complete as the interoperation protocol presented in this paper. To addressthe derivation of private workflows from inter-organizational workflows, van der Aalstand Weske [2] used the concept of workflow projection inheritance introduced in [4].A couple of derivation rules are proposed so that a derived workflow is behaviorallybisimilar to the original workflow based on branching semantics, in contrast to the tracesemantics adopted in our proposed model.

Modeling of interoperation protocols dates back to the Contract Net Protocol [43].However, the authors only concentrated on low-level transaction aspects. Grosof [28]introduced a declarative approach to business rules in e-commerce contracts by com-bining Courteous Logic Program and XML. Recently, Karlapalem et al. [32] proposeda meta-model for e-contracts with E–R diagrams and the generation of workflows tosupport them, but did not consider the notion of workflow views or detailed interop-eration protocols. The COSMOS project [27] developed an Internet-based electroniccontracting service based on XML and CORBA components, but not based on workflowtechnologies.

Various formalisms have been proposed to study the properties of distributed com-municating processes [29,39,41]. Recent work has tried to adapt these formalisms to rea-son about interfacing communicating processes [10,11] and inter-organizational work-flows [4]. These formalisms reason properties, such as bisimulation or failure equiv-alence, of communicating processes that jointly compose more complex processes.However, workflow views are different from these communicating processes. They are,in essence, projections from some parent workflow process. Furthermore, each activ-ity in workflow view can be uniquely labeled. This eliminates the need to handle non-determinism in the workflow view model. As such, a flow control model based on execu-tion traces is formulated to reason about the correctness and integrity of workflow views.Therefore, the model can be further refined to combine the reasoning of flow control andinformation structure following similar approaches as adopted for e-commerce proto-cols [48].

DartFlow [8] is one of the first Web-based WfMS using transportable agents,CGI and Java technologies. WebWork [38] described some issues in web-based work-flow recovery, but only for WfMS and Web related failures without covering user-defined workflow exceptions. Eflow [9] is one of the closest commercial systemswith features like E-ADOME for handling e-services. However, Eflow does not ad-dress matching of agents directly with activities. Instead, it uses the concept of genericservice node and service selection rules. Currently, several commercial WfMSs suchas TIB/InConcert [46] and Staffware 2000 [44] have provided web user interfaces.

246 CHIU ET AL.

In addition, I-Flow [22] has a Java workflow engine. WW-flow [33] provides a hierar-chical control scheme over workflows implemented in Java for both the workflow engineand the client interfaces. It allows sub-workflows to be executed in different workflowengines across the web.

Besides E-ADOME, CrossFlow [26] is another notable system using related ap-proaches to support cross-organizational workflows. CrossFlow models virtual enter-prises based on a service provider-consumer paradigm, in which organizations (ser-vice consumers) can delegate tasks in their workflows to other organizations (serviceproviders). High-level support is obtained by abstracting services and offering advancedcooperation support. Virtual organizations are dynamically formed by protocol-basedmatchmaking between service providers and consumers. Though CrossFlow includesdetailed work for protocols, it does not provide such a sophisticated mechanism asworkflow views for information and control exchange between workflows of differ-ent organizations. Protocol enforcement is also not as straightforward as that providedby E-ADOME workflow views equipped with ECA-rules mechanisms based on cross-organizational events.

As for standards, the Workflow Management Coalition (WfMC) has recently pro-posed Wf-XML [49], which is an interchange format specification for an XML languagedesigned to model the data transfer requirements for process specification. MeanwhileWfMC is working towards an industrial standard with the WfMC Reference Model [50]for WfMS to identify their characteristics, terminology [51] and components, and to en-able individual specifications to be developed within the context of an overall model forWfMS.

An upcoming standard for B-to-B integration is the electronic business XML(ebXML) [21]. The proposed framework contains the idea that two trading partnersagree on a collaboration protocol, which contains the messaging service interface re-quirements as well as the implementation details pertaining to the mutually agreedupon business processes. However, the paradigm of workflow views is more general.It provides mechanisms to bridge the external interfaces and the internal workflows ofa business party in a controlled way. Nevertheless, ebXML can be used, among otherlanguages, to implement workflow view details for establishing cross-organizational co-operation. For the sake of simplicity we show only the essential elements in this pa-per. More exhaustive and more precise schemas have been proposed in emerging stan-dards, such as the RosettaNet [42] open e-business language that includes the PartnerInterface Processes (PIPs), (proposed by the RosettaNet consortium designed to alignprocesses between supply chain partners on a global basis), the Business Process Exe-cution Language for Web Services (BPEL4WS) [6] (a successor of Web Service FlowLanguage, WSFL), and ebXML [21] in particular, the Collaboration Protocol Profiles(CPP). Other emerging standards such as XSLT [54] can be exploited for the imple-mentation of the interoperation in particular for the processing of the exchanged XMLmessages.

According to Kumar and Zhao [34], our proposed approach belongs to the Webstage four, during which workflow features are added to the Web technology to improve

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 247

interoperability. In order to archive this goal, we have employed in our solution bothwell-established and emerging Internet standards, such as XML and Web services tech-nologies.

7. Conclusions

This paper has presented an advanced cross-organizational workflow environment withpragmatic features in cooperating with other organizations over the Internet for work-flow enactment. We have illustrated, in the context of E-ADOME, how its ADOME-WfMS engine (a flexible WfMS based on ADOME active OODBMS with role and rulefacilities) has been extended to accomplish such objectives. We have also detailed theemployment of contemporary Web service technology in specifying and enacting cross-organizational interoperability with workflow view support.

Compared with other research efforts on this topic, E-ADOME provides an im-proved environment for various types of process enactment, which can adapt to chang-ing requirements, with extensive support for reuse. This paper has introduced the use ofworkflow views for interfacing different WfMSs, possibly belonging to different organi-zations, and its applications in a cross-organizational environment. We have proposed aninteroperation model based on workflow views, simplifying the process of developingcross-organizational workflows. An example has been given to illustrate how cross-organizational business processes can be facilitated by the workflow view mechanism.

For workflow views, we are working on further details of formal definitions, con-struction and verification algorithms, more detailed taxonomy, view update mechanisms,and more operations support. For interoperation protocols, we are working on fur-ther details of process adaptation for interoperability, multiple-party protocols and sub-protocols, interoperation protocol negotiation, a more comprehensive methodology forinteroperation protocol enforcement (including preventive measures), based on cross-organization workflows and the workflow view mechanism. We consider further thefollowing as future research issues: expanding the possible interfaces and coordinatingdifferent types of agents, graphical workflow evolution tools, and interoperation withother WfMSs.

Finally, we are interested in the application of E-ADOME into various advancedreal-life e-commerce environments, such as procurement, finance, stock trading and in-surance. We are investigating workflow adaptation and view formation in compliancewith the Internet Open Trading Protocol (IOTP) [7]. We are also interested in wrappersto interface with legacy software agents. E-ADOME is currently being built on top ofthe ADOME-WfMS prototype system, with a Web-based user interface to accommodatethe whole range of activities.

Acknowledgements

The work was supported by a grant from the Hong Kong Special Administrative Region,China, Project No. HKUST6170/03E.

248 CHIU ET AL.

Appendix A. WSDL definition of QuotationService Web service

Figure 16. WSDL definition of QuotationService Web service.

References

[1] W.M.P. van der Aalst and A. Kumar, XML based schema definition for support of inter-organizationalworkflow, Information Systems Research 14(1) (2003) 23–46.

[2] W.M.P. van der Aalst and M. Weske, The P2P approach to interorganizational workflows, in: Proceed-ings of 13th International Conference Advanced Information Systems Engineering (CAiSE 2001),Interlaken, Switzerland, Lecture Notes in Computer Science, Vol. 2068 (Springer, Berlin, 2001)pp. 140–156.

[3] W.M.P. van der Aalst, Interorganizational workflows: An approach based on message sequence chartsand Petri nets, Systems Analysis–Modelling–Simulation 34(3) (1999) 335–367.

[4] T. Basten and W.M.P. van der Aalst, Inheritance of behavior, Journal of Logic and Algebraic Pro-gramming 47 (2001) 47–145.

[5] B. Biddle and E. Thomas, Role Theory: Concepts and Research (Robert E. Krieger Publishing Com-pany, New York, 1979).

[6] Business Process Execution Language for Web Services, http://www-106.ibm.com/developerworks/library/ws-bpel/

[7] D. Burdett et al., Internet Open Trading Protocol (McGraw-Hill, New York, 2000).[8] T. Cai, P.A. Gloor, and S. Nog, DartFlow: A workflow management system on the Web using trans-

portable agents, Technical report PCS-TR96-283, Dartmouth College, Hanover, N.H. (1996).

WORKFLOW VIEW DRIVEN CROSS-ORGANIZATIONAL INTEROPERABILITY 249

[9] F. Casati et al., Adaptive and dynamic service composition in eFlow, HP Laboratories TechnicalReport HPL-2000-39 (March 2000).

[10] S.C. Cheung and J. Kramer, Context constraints for compositional reachability analysis, ACM Trans-actions on Software Engineering and Methodology 5(4) (October 1996) 334–377.

[11] S.C. Cheung and J. Kramer, Checking safety properties using compositional reachability analysis,ACM Transactions on Software Engineering and Methodology 8(1) (January 1999) 49–78.

[12] S.C. Cheung, D.K.W. Chiu and S. Till, A data-driven approach to extending workflows across organi-zations over the Internet, in: Proceedings 36th Hawaii International Conference on System Sciences(HICSS36), CDROM, January 2003 (IEEE Press, 2003) 10 p.

[13] D.K.W. Chiu, K. Karlapalem and Q. Li, E-ADOME: A framework for enacting e-services, in: Pro-ceedings VLDB Workshop on Technologies for e-Services, Cairo, Egypt (September 2000).

[14] D.K.W. Chiu, K. Karlapalem and Q. Li, Views for inter-organization workflow in an e-commerceenvironment, in: Proceedings 9th IFIP 2.6 Working Conference on Database Semantics (DS-9), HongKong (April 2001).

[15] D.K.W. Chiu, Q. Li and K. Karlapalem, A meta modeling approach for workflow management systemsupporting exception handling, Information Systems 24(2) (1999) 159–184.

[16] D.K.W. Chiu, Q. Li and K. Karlapalem, Facilitating exception handling with recovery techniques inADOME workflow management system, Journal of Applied Systems Studies 1(3) (2000) 467–488.

[17] D.K.W. Chiu, Q. Li and K. Karlapalem, Web interface-driven cooperative exception handling inADOME workflow management system, Information Systems 26(2) (2001) 193–261.

[18] D.K.W. Chiu, K. Karlapalem, Q. Li and E. Kafeza, Workflow views based e-contracts in a cross-organization e-service environment, Distributed and Parallel Databases 12(2–3) (2002) 193–216.

[19] V. Chopra et al., Professional XML Web Services (Wrox Press, 2001).[20] U. Dayal, Queries and views in an object-oriented data model, in: Proceedings 2nd International

Workshop on Database Programming Languages (1989).[21] eBXML, http://www.ebXML.org[22] Enix Consulting Limited, An Independent Evaluation of i-Flow, Version 3.5 (2000) (available at

http://www.i-flow.com).[23] D. Ferraiolo and R. Kuhn, Role-based access control, in: Proceedings 15th NCSC National Computer

Security Conference, Baltimore (1992).[24] D. Ferraiolo, R. Sandhu, S. Gavrila, R. Kuhn and R. Chandramouli, Proposed NIST standard for role-

based access control, ACM Transactions on Information and System Security (TISSEC) 4(3) (2001)224–274.

[25] G. Gardarin, B. Finance and P. Fankhauser, Federating object-oriented and relational databases: TheIRO-DB experience, in: Proceedings of the 2nd IFCIS International Conference on Cooperative In-formation Systems (CoopIS ’97) (IEEE Computer Society, 1997) pp. 2–13.

[26] P. Grefen, K. Aberer, Y. Hoffner and H. Ludwig, CrossFlow: Cross-organizational workflow manage-ment in dynamic virtual enterprises, International Journal of Computer Systems Science & Engineer-ing 15(5) (2000) 277–290.

[27] F. Griffel et al., Electronic protocoling with COSMOS – How to establish, negotiate and executeelectronic protocols on the Internet, in: Proceedings 2nd International Enterprise Distributed ObjectComputing Workshop (EDOC ’98) (1998).

[28] B.N. Grosof, A declarative approach to business rules in Protocols: Courteous Logic Programs inXML, in: Proceedings 1st ACM Conference on Electronic Commerce (EC99), Denver, Colorado,USA (November 3–5, 1999).

[29] C.A.R. Hoare, Communicating Sequential Processes (Prentice-Hall, New York, 1985).[30] ICQ, http://www.icq.com[31] E. Kafeza, D.K.W. Chiu and I. Kafeza, View-based contracts in an e-service cross-organizational

workflow environment, in: Proceedings 2nd VLDB Workshop on Technologies for E-Services, Rome,Italy, Lecture Notes in Computer Science, Vol. 2193 (Springer, Berlin, 2001) pp. 74–78.

250 CHIU ET AL.

[32] K. Karlapalem, A. Dani and P. Krishna, A frame work for modeling electronic contracts, in: Proceed-ings 20th International Conference on Conceptual Modeling, Yokohama, Japan, November 2001,Lecture Notes in Computer Science, Vol. 2224 (Springer, Berlin, 2001) pp. 193–207.

[33] K. Kim, S. Kang, D. Kim, J. Bae and K. Ju, WW-flow: Web-based workflow management withruntime encapsulation, IEEE Internet Computing 4(3) (2000) 56–64.

[34] A. Kumar and J.L. Zhao, Workflow support for electronic commerce applications, Decision SupportSystems 32 (2002) 265–278.

[35] H. Lewis and C. Papadimitriou, Elements of the Theory of Computation (Prentice Hall, 1981).[36] D.-R. Liu and M. Shen, Modeling workflows with a process-view approach, in: Proceedings 7th

International Conference on Database Systems for Advanced Applications (DASFAA 2001), April2001, Hong Kong (IEEE Computer Society, 2001) pp. 260–267.

[37] Q. Li and F.H. Lochovsky, ADOME: An advanced object modeling environment, IEEE Transactionson Knowledge and Data Engineering 10(2) (1998) 255–276.

[38] A.J. Miller, A.P. Sheth, K.J. Kochut and Z.W. Luo, Recovery issues in Web-based workflow, in:Proceedings 12th International Conference on Computer Applications in Industry and Engineering(CAINE-99) (Atlanta, Georgia, November 1999) pp. 101–105.

[39] R. Milner, Communication and Concurrency (Prentice-Hall, 1989).[40] Object Management Group, Foreword UML Specification 1.4 (September 2001).[41] J.L. Peterson, Petri Net Theory and the Modeling of Systems (Prentice-Hall, 1981).[42] RosettaNet, http://www.rosettanet.org[43] R.G. Smith, The protocol net protocol: High level communication and control in a distributed problem

solver, IEEE Transactions on Computers 29(12) (1980) 1104–1113.[44] Staffware Corporation, Staffware Global – Staffware’s Opportunity to Dominate Intranet Based Work-

flow Automation (2000), http://www.staffware.com[45] Sun Microsystems Inc., Enterprise Java Beans, http://java.sun.com/products/ejb/[46] TIBCO Software Inc., which has acquired InConcert Inc., http://www.tibco.com[47] UDDI, http://www.uddi.org[48] X. Wang, S.C. Cheung and J. Wei, A CSP and Z combined modeling of document exchange processes

in e-commerce protocols, Information and Software Technology 44(14) (2002) 875–889.[49] Workflow Management Coalition, Workflow Standard – Interoperability Wf-XML Binding, WFMC-

TC-1023, May 2000.[50] Workflow Management Coalition, The Workflow Reference Model (WFMC-TC-1003, 19-Jan-95,1.1).[51] Workflow Management Coalition, Terminology and Glossay (WFMC-TC-1011, Feb. 1999, 3.0).[52] WSDL, http://www.w3.org/TR/wsdl[53] XML Spy by Altova Inc., http://www.xmlspy.com[54] XSLT specification, http://www.w3.org/TR/xslt