Workflow View Driven Cross-Organizational ... - Springer Link

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

Workflow View Driven Cross-Organizational Interoperability in a Web Service Environment DICKSON K.W. CHIU ∗

[email protected] Dickson Computer Systems, 7A Victory Avenue, 4th Floor, Homantin, Kowloon, Hong Kong S.C. CHEUNG and SVEN TILL {scc,till}@cs.ust.hk Department of Computer Science, Hong Kong University of Science and Technology, Clear Water Bay, Hong Kong KAMALAKAR KARLAPALEM

[email protected]

International Institute of Information Technology, Gachibowli, Hyderabad 500 019, India QING LI [email protected] Department of Computer Engineering and Information Technology, City University of Hong Kong, Tat Chee Avenue, Kowloon, Hong Kong ELEANNA KAFEZA [email protected] Department 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 framework for implementing e-services over the Internet. Such e-services typically require collaborative enactment of workflows across multiple organizations. In this paper, we propose the use of workflow views as a fundamental support mechanism for the interoperability of multiple workflows across business organizations. We present a meta-model of workflow views and their semantics using a cross-organization workflow example based on a supply-chain e-service. We also formulate an interoperation model of workflow views and its consistency criteria. Finally, this paper presents an implementation of the model based on XML and contemporary Web services technologies, with adaptation to our E-ADOME workflow engine. Keywords: e-service, cross-organizational workflow, workflow views, Web services, interoperation protocol, workflow view consistency

1.

Introduction

Recent advances in Internet technologies have created a global platform for organizations and individuals to communicate with each other, carry out various commercial activities, and provide value-added services. There is an urgent need for supporting these activities with cross-organizational workflows, especially because many organizations may have already been employing some kind of workflow technologies. Advanced Workflow 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 model these activities (such as [8,9,13,26,33,38,44,46]). In addition, advanced WfMSs can provide various services such as coordination, interfacing, maintaining a process repository, 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 activities, which collectively realize a business objective or policy goal. Workflow is the computerized facilitation or automation of a business process. WfMSs can assist in the specification, decomposition, coordination, scheduling, execution, and monitoring of workflows. In addition to streamlining and improving routine business processes, WfMSs help in documenting and reflecting upon business processes. Often, traditional WfMSs can only coordinate workflows and their enacting agents (sometimes limited to software processes) within a single organization. However, contemporary WfMSs can now interact with various types of distributed agents over the Internet. We adapt the concepts of views from databases to workflows. Views help balance 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 fully controlled and comprehensible manner. Moreover, each party needs only minor, or none, modification to its own workflow to successfully arrive at a commonly agreed upon and interoperable 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 organizations, different views of a workflow can be presented to different organizations according to their respective requirements. Due to the popularity of e-commerce, there has been great demand for cross-organizational workflows, which are managed adequately together with agreed upon interaction models. An interaction model refers to a detailed plan of a business transaction carried out by at least two parties. It focuses on the cross-organizational communication part and the exchange of data necessary for the accomplishment of the transaction. We have demonstrated the feasibility of modeling and enacting composite e-services as workflow extensions, and proposed a novel approach for applying workflow views [18] to e-contracts in a cross-organizational workflow environment. As follow-up work, the contributions and coverage of this paper are as follows: (i) a refined metamodel of workflow views, (ii) a cross-organizational interoperation model of workflow views subject to a set of consistency criteria, (iii) details on the facilitation of workflow views and cross-organizational interoperability with XML and the contemporary Web services [19] technologies, and (iv) the adaptation of E-ADOME to support the workflow view model. The rest of the paper is organized as follows. Section 2 presents a motivating example to illustrate the concept of workflow views in a cross-organizational workflow environment. Section 3 presents the meta-model of workflow views followed by its interoperation model in section 4. Section 5 presents the E-ADOME architecture to illustrate 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 research in section 7. 2.

Motivating example

In this section, we present a motivating example of cross-organizational workflows based on a supply chain e-service scenario, as depicted in figure 1. The workflows are specified as UML activity diagrams. UML (Unified Modeling Language) is chosen because of its clear semantics and its popularity for describing object-oriented software requirements and designs [40]. Note that incoming (outgoing) transitions connected to a synchronization 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 organizations involved, viz., end-users, system integrators, and parts vendors. Each organization has its own individual, rather simple, workflow. Nevertheless, these cross-organizational interactions increase the complexity and raise some interesting and complicated issues discussed 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 server system. First, quotation enquiries are sent to a number of system integrators. The received quotations containing price and product information are evaluated. A purchase order is then issued to the selected system integrator. The server system is then received and checked. Finally, payment is arranged. A system integrator’s workflow starts when a quotation request is received. The first step is to check from its parts vendors the lead-time and the updated prices of major parts, especially those with a large price fluctuation (e.g., CPU and memory). After the evaluation, a quotation is sent to the end-user. While the end-user evaluates the quotation, the system integrator may need to provide additional or updated information for the bid. After a purchase order is received, the successful system integrator orders necessary missing parts, which are not in stock and estimates a delivery schedule. When all 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. Assuming this is the end of the supply chain, the vendor has all necessary information to reply to the system integrator with up-to-date parts information and prices. Assuming that 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 integrator (cf. figure 2) has the following requirements. The end-user’s company profile and other background information are made available on request so that the system in-


225

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

tegrators can design more personalized proposals. The supplier should be notified of any changes in delivery requirements or payment arrangements. The enquiry process in particular 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 workflow view with the following requirements (cf. figure 3). The system integrator’s company profile and technical specifications of the parts used in the proposed server are made available 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. Supplementary details of the “service preparation” process are available to the end-user to enable the user to monitor the progress of the job and to estimate the delivery date. During the evaluation process of the end-user an updated quotation (price) might be sent to the enduser with an event-triggering mechanism upon a significant aggregate price change in parts. 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 quotation request of the end user, the system integrator checks its parts database and inventory stocks, 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 with the received data from the parts vendor. After receiving a correct purchase order from the end user, the system integrator commences the service preparation by checking the availability of all necessary part, and if necessary by ordering the missing parts. The order of the parts is directly accompanied by the payment. The parts vendor should be notified of any changes in parts’ requirements or payment arrangements. Since the parts vendor is not involved in the remaining workflow the processes can be concealed in this view.


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 integrators with an event-triggering mechanism. Technical specifications and related information for the parts are made available upon request. Updates in software drivers and firmware will 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 be notified of any changes in lead-time. 3.

Workflow views

As shown in the above example, a business process usually involves many participating organizations in a B-to-B e-commerce environment (i.e., such a business process involves several interoperating and interacting workflows from different organizations). This is known as a cross-organizational workflow. To support workflow interoperability, we need a mechanism to allow authorized external parties to access only the related and relevant parts of a workflow while maintaining the privacy of other unnecessary or proprietary information. Motivated by views of federated object databases, we propose the use of workflow views as a fundamental mechanism for cross-organizational workflow interaction. The integrity between a workflow view and its base workflow will be discussed later in section 4.2. 3.1. A meta-model of workflow views The use of workflow views facilitates sophisticated interactions among WfMSs and allows these interactions to interoperate in a gray box mode (i.e., they can access each other’s internal information to some extent). The artifact of workflow views is therefore a handy mechanism to enact and enforce cross-organizational interoperability over the Internet. In addition, workflow views are useful in providing access to business processes 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 of the business processes in which they are participating. They might be required to provide 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 restrict the 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 activities and a set of input/output messages. A workflow view is a structurally correct subset of a workflow. This workflow view model is a refinement of our previous model proposed in [18]. The refinement focuses on the development of an interoperation model and the consistency of workflow views. Figure 7 presents an implementation of our meta-model in XML. Most contemporary WfMSs use a hierarchical composition approach, i.e., a workflow is composed of activities, which may be iteratively expanded into other workflows until leaf-nodes consisting of atomic activities. For example, the Service Preparation activity in figure 1 is expanded into another workflow. This gives the opportunity to describe a workflow at different levels of granularity. The use of granularity depends on the level of trust between the involved organizations, and what details of an internal process an organization wants to disclose to external organizations. A workflow view can be made available as a subset of a workflow. For instance, certain activities and their detailed composition may be concealed. The activities in a workflow view may also bear different names from those of the original workflow. To facilitate business organizations exercising different perspectives of a business process, they are classified into groups, also called classes or roles. A role represents a collection of business organizations with similar responsibilities [37]. The role concept is reminiscent of the “group ids” and “group access rights” of a UNIX system, and also of the security model used in Enterprise JavaBeans [45]. A business organization playing a certain role or several roles exercises its access rights at the view level according to the rights assigned to the specified roles. This approach has been studied for many years [5,23], and the National Institute of Standards and Technology (NIST) has tried to unify the most frequently referred to role-based access control (RBAC) models and has proposed a standard for RBAC [24]. Messages are data objects exchanged in crossorganizational interactions. The attribute user_access of a message may assume a value of either output or input. The value specifies whether the message is an input or output 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 that can possibly be constructed using the notations of UML activity diagram. However, the description of such workflow views requires a complex XML schema, such as the BPEL4WS [6] or the Collaboration Protocol Profile [21]. This leads to lengthy workflow view descriptions. From our experience, most workflow views can be expressed with sequential activities, augmented with optional and iterative constructs as in regular expressions [35]. Therefore, our implementation includes a simplified way to specify a workflow view, which will be used in our subsequent discussions. Figure 7 describes

229

Figure 7. Workflow view meta-model in XML.


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 software tool XML Spy Version 5 from Altova [53]. A workflow view consists of multiple activities; each of which may in turn be decomposed into another sequence of activities until leaf elements of atomic activities are reached. An atomic activity contains an activityName and maps to an activity in the original workflow, referred to as workflowActivity. A communication activity may contain a set of messages that may take a user_access value of either input or output. An activity receives all its input messages and dispatches all its output messages at the beginning or end of the activity, respectively. The execution element specifies whether the associated activity is optional or iterative. The default is that the activity will be executed once. A workflow view is made available to a set of roles identified by their role names. A workflow view 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 according to the transitions augmented with an attribute specifying either an XOR-join or AND-join semantics. The provision of transitions allows specification of complex workflow 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 a workflow view presented by Dickson Computer Systems to an end user through a set of nested 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 gray side bar on the left. The integer parameter 11 in activity(11) indicates the number of activity elements in the sequence. An attribute is denoted with the “=” icon, e.g., = workflowviewName. Actual activities in the original workflow are described in the element workflowActivity. This element is only available to the provider of the workflow view; it relates activities in the workflow view to those in the original workflow. Elements shaded with a light-gray background are optional. The workflow view D1, as shown in figure 8, includes among others the workflow view name, the provider of the view and a sequence of workflow view activities. Some of these processes, such as Order_missing_parts, are represented in a gray box manner through sub workflow views. Furthermore, all necessary incoming and outgoing message objects (e.g., QuotationRequest and QuotationResponse) and other view 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 the later for the interoperation with a parts vendor. The view E1 is provided for a supplier by 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 depicted in figure 1. The views will be further used in subsequent sections for illustrating the business process interoperation between these two parties.


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

231

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 interoperability based on workflow views with their consistency checking criteria, and show how this model 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 now proceed to describe its application in the domain of cross-organizational interoperation model. As depicted in figure 12, an interoperation protocol consists of workflow views, communication scenarios between these views, and a set of interoperation parameters. This information should be stored by each party, which is involved in the


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 communication links. A communication link is associated with one exchanged message, and with its sender and receiver processes, respectively. Furthermore, the response-request relation between communication links can be modeled for storing the partial order of the occurrence 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 pairwise interactions (e.g., end-user with the supplier, supplier with the parts vendor, but not end-user with the part vendor directly). During the interoperation of a business process the two parties have to agree on a common workflow, activity assignments, and cross-organizational message exchanges. For example, figure 13 depicts a communication scenario between Dickson Computer Systems and an end-user in UML sequence diagram. Each organization has its own internal 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 obliged to 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 trust between them and that all information necessary for the specification, enforcement and monitoring of the process are available to both organizations. At the same time, for security reasons no organization wants to reveal more information than necessary. In our workflow protocol model, the balance is achieved through the workflow view mechanism. Each organization specifies a view of its internal workflow that is accessible to the other one. For example, the end-user specifies at the view level that the activity evaluate quotation 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,


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 evaluation procedure. Although we may assume a mechanism that enforces the flow of control in each organization’s workflow, the control flow has to be augmented with cross-organizational communications in order to support the specific business process. These communications are useful for information exchange, control exchange and synchronization. In our interoperation model, there are some activities in each workflow view, called communicating activities, through which two organizations communicate. The crossorganizational control and data flow is specified within communicating activities and their associated communication links. We associate the message with a label of the communication link. Furthermore, each communicating activity receives and sends a set of messages. The order in which these messages occur is crucial. Therefore, with every communicating activity, a partial order is imposed on each message requiring it to send/receive. For example in figure 13, the Quotation Evaluation activity of the enduser’s workflow has to interact with the Prepare Quotations and Prepare Extra Info activities of Dickson Computer Systems. As a result of the Prepare Quotations activity, the end-user receives a QuotationResponse. Afterwards, if desired, he can get additional information by receiving an ExtraInfoResponse message but only after he has sent an ExtraInfoRequest. In addition, synchronization achieved by cross-organizational messages is symbolized with a short heavy bar in figure 1. This synchronization symbol represents an and-join. For example, the Quotation Evaluation activity can only be started upon receiving 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 integrity and correctness. The integrity criteria concern the consistency between workflow views and their parent workflows, while the correctness criteria concern the consistency between workflow views and their target communication scenarios. Based on automata theory [35], we develop the following consistency model. To examine the integrity criteria let us first develop an execution model for workflows and workflow views. In the model, we assume that each workflow activity in a workflow or workflow view is uniquely labeled. Examples of labels in the System Integrator workflow include Check Parts Info and PrepareQuotation. Further, we map a communication workflow activity to the name of the exchanged message. For example, the workflow activity of receiving an enquiry by the System Integrator from the End User is labeled as QuotationRequest. The following 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 activities, e.g., Service Preparation in example (3) is replaced by its constituent activities as shown in example (4) above. In addition, concurrent activities can be represented as interleaving activity sequences [29]. For instance, if the receipt of QuotationRequest occurs concurrently with Check Parts Info, the workflow activity sequence in the example (1) above will be accompanied by the following sequence in example (5).


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 following integrity criteria: Seq(V ) ⊆ Seq(W ) ↑ L(V ), where Seq(X) and L(X) denote the minimal set containing all possible sequences exhibited by X and the set of labels occurred in X, respectively. That means, the integrity criteria requires a workflow view V exhibiting no activity sequence not found in the original workflow W . A communication scenario specifies some sequences of messages exchanged between two parties. This scenario is supported collaboratively by two workflow views, one from each party. The following are two possible message sequences specified by the scenario 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 minimal set 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 correctness criteria, if and only if: Seq(U ) ⊆ Seq(V ) ↑ L(U ). That means, the correctness criteria requires a workflow view V capable of exhibiting 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 the integrity 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 interoperation protocol, which specifies the details. If two parties want to form a protocol, first they will have to decide on the value of the interoperation parameters, as in the following example (based on figure 13). From the above example, we can see that since there is no need for centralized control, each party to the protocol defines the communicating activities so that it can receive and send messages appropriately, thus manifesting the required communications. The next step towards an interoperation would be the implementation of the external interoperation 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


239

published, located, and invoked across the Internet. Web services perform functions that can be anything from a simple request to complicated processing of business data. Once a Web service is deployed other applications and Web services can discover and invoke the 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 through a Web-based interface. This ensures that software systems can be coupled at different application levels. The Web service architecture is suitable for cross-organizational collaboration in a highly dynamic environment as it supports just-in-time integration, encapsulation and interoperation. This allows the implementations to be programming language neutral and communications mechanism independent. Emerging standardized frameworks, such as the Universal Description, Discovery and Integration (UDDI) [47] specifications, support and simplify the way to publish and discover information about Web services. In particular, UDDI aims at enabling businesses to find each other, and define how they interact over the Internet and share information in a global registry architecture. Thereby, organizations are enabled to (i) describe their business and their services, (ii) discover other organizations that offer desired services, and (iii) integrate with these other businesses. Web services are described through their interface definitions in the Web Service Description Language (WSDL [52]), which is an XML-based language developed to address 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 questions are mapped to the abstract specification of a service, a specific implementation of that service, and the location of the service implementation. The implementation of Web service interfaces is based on the exchanged messages. In particular, the content and the structure of the interfaces reflect the exchanged business entities. Table 1 summarizes a set of possible Web services implemented by Dickson Computer Systems to support the incoming external events and their immediate responses that are identified from the data requirement analysis of the supply-chain example. Appendix A gives the definition of the QuotationService Web service in Web Service Description Language (WSDL). In this example, the incoming events and their immediate responses are handled by one Web service. For example, QuotationRequest is the input message and the QuotationResponse the output message of the Web service QuotationService. The similarity between the input and the output messages of a communication activity and the interface definition in the Web service description provides a hint to the derivation of potential Web services, especially due to the 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 used to provide workflow extensions for cross-organizational interoperability.

240

CHIU ET AL.

Table 1 Some Web services to be provided by Dickson computer systems. 1. Name: QuotationService Location/Provider: System Integrator Input: QuotationRequest – CustomerInformation • Name • Address • Customer number – SystemConfiguration • NumberOfUnits • Part List • Dimensions Output: QuotationResponse – Quotation • CustomerInformation • SystemConfiguration • ItemizedPriceList • TotalDiscountedPrice • ShippingInformation • TermsOfServices • ExpiryDateOfOffer • DeliveryDate 2. Name: reqPartsQuotation Location/Provider: Parts Vendor Input: PartsQuotationRequest – CustomerInformation • Name • Address • Customer number – RequestedPart • Part number • Price • Dimensions • NumberOfUnits Output: PartsQuotationResponse – Quotation (Pricelist) • Service • Price • Components

3. Name: reqExtraInfo Location/Provider: System Integrator Input: 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: payInvoice Location/Provider: SystemIntegrator Input: Payment – Invoice number – Invoice date – Payer – Payee – Invoice amount

5. Name: orderSystem Location/Provider: System Integrator Input: 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: orderParts Location/Provider: Parts vendor Input: 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: PaymentAcknowledgement Output: PartsDelivery – result (Boolean) successful/ – Order successful/unsuccessful unsuccessful – Bill – Scheduled delivery date


5.

241

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 monitoring inter-organizational workflows. The most recent updates are the introduction of the Workflow View Sub-layer and the employment of Web service support [19] to replace a traditional web server. The key features of ADOME-WfMS are as follows: (i) effective coordination of agents (both software and human agents) and an object-oriented capability-based approach to match activities and agents; (ii) automatic resolution of expected exceptions and exception driven workflow recovery; (iii) dynamic binding of exception handlers to activities with scoping, and to classes, objects and roles; (iv) addition, deletion and modification of exception handlers at run-time through workflow evolution support; (v) specifying and reusing exception handlers upon unexpected exceptions and system-assisted exception handling; and (vi) application of workflow evolution and workflow recovery in exception handling. As shown in figure 15, the E-ADOME architecture can be divided into the following layers: 1. ADOME/OODBMS Layer – this layer basically consists of an OODBMS and some additional ADOME facilities. ADOME was developed to enhance the knowledgelevel modeling capabilities of OODBMS models [33], in order to more adequately deal with data and knowledge management requirements of advanced information management applications, especially WfMSs. 2. ADOME-WfMS Layer – this is a flexible WfMS built upon ADOME facilities, supporting effective management of agents, on-line workflow evolution, and automatic and cooperative exception handling [15,16]. 3. E-ADOME Layer – this is the main enhancement layer to the WfMS for ADOMEWfMS to interact with various types of external agents through the Internet, including cross-organization workflows. This layer consists of the Access Security Sub-layer, Internet Interface Sub-layer, and Workflow View Sub-layers as explained in the next sub-section. 4. Agents – these are agents, users or organizations providing services or solving problems, 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 with agents through the Internet. It supports effective management of agents, cooperative exception 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 module also sends out requests to other software agents using a compatible API. An Internet Event Interceptor receives responses or alerts from software agents through a compatible API and translates them to ADOME events (which include exceptions). Note that an

Figure 15. E-ADOME architecture.

242 CHIU ET AL.


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 as authentication, 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 the tasks of a filter. It decides, based on defined workflow views, if a message or event generated by the WfMS is forwarded to an external agent and if yes, to where and how. On the other hand, incoming messages are checked, and finally, blocked, or distributed to the corresponding activities. In addition, the workflow views may be used to transform the exchanged data accordingly. The layer may be implemented by means of XML transformation and process languages such as eXtensible Stylesheet Language Transformation (XSLT) [54]. The newly added Web Service Interface module enables E-ADOME to interoperate with other WfMSs to allow for more advanced activity execution and control in foreign WfMSs. It also enables human agents or users to interact with E-ADOME, to access the database, and to report work progress, in addition to programmed web interface. The Web 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 crossorganizational interoperability in a workflow environment. The enabling power and applicability mainly rely on the additional Internet interface layer on top of ADOMEWfMS. This interface layer can send and receive messages through the Internet in order to communicate with distributed users and other service agents. The arrival of incoming messages can be detected as events to trigger actions of the WfMS specified by both regular workflow specifications and Event-Condition-Action rules [31]. In particular, the WfMS interface module, now equipped with Web Service mechanism, further facilitates a cross-organizational workflow enactment. As the E-ADOME extension is built on top of ADOME-WfMS, it is perceived that the techniques presented in this paper should be applicable to other similar WfMSs or other information systems. In order to use this power effectively, we further develop a workflow view mechanism as detailed in previous sections. When two organizations are interested in interoperating for a certain business process, they exchange initial workflow views of themselves, to disclose their company profiles, and to inform the other party of procedures involved in their organization (such as details of service packages of the service provider and the procurement procedure of the end-user). These views also contain information and the coordination requirements of both parties. However, these requirements often vary in different organizations, i.e., workflows from different organizations may often have mismatches. As long as there is no standardized workflow specification at an application level for each trade or service business, we perceive that workflow adaptation is a hard, tedious, yet pertinent problem, which must be adequately addressed. The following different levels of workflow adaptation 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 workflows from unnecessary modifications. 1. Workflow views can be modified to accommodate for interface mismatch and minor procedural differences without the need to modify the internal workflow. 2. Internal workflows need minor adaptation to accommodate for missing procedures and 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 organization believes that it is useful for improving the business process (in dealing with other companies or for other reasons); this is known as workflow evolution. A detailed description of workflow evolution supported by ADOME-WfMS is available in [17]. Alternatively, the adaptation can be just a deviation, which is only employed in dealing with this particular business partner. 3. Because there may be major differences in workflows of the two parties, one or both of 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, one of the two parties may choose to fall back on a manual or semi-manual mode of cooperative work-around. E-ADOME supports interfacing with human users through a Web-based interface (e.g., the end-user may designate a staff member to enter the order form manually through the web page of Dickson Computer Systems), subsequent interactions can thus be accomplished through email, ICQ alerts [30], and customized web pages. Because an organization may interoperate with many other organizations, different views of a workflow may be presented by E-ADOME to different organizations according to different requirements. For example, Dickson Computer Systems provides two different 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 supported in E-ADOME. Thus, cross-organizational workflows can be developed fast and managed with interoperation protocols adequately. In addition, E-ADOME also supports effective manual interaction through customized web pages. Furthermore, it should be noted that in all these three cases, the workflow view mechanism is still necessary for providing controlled external access, security, information hiding, and interoperability through views as a new mechanism of workflow adaptation. 6.

Related work

Our preliminary approach of workflow views has been presented in [14]. This approach has 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 federated OODBMS and views for objects in a distributed environment. Liu and Shen [36] presented an algorithm to construct a process view from a given workflow, but did not discuss its correctness with respect to inter-organizational workflows.


245

Van der Aalst and Kumar [1] presented a workflow schema exchange in an XML dialect called “XRL” but it does not include the support for workflow views. Besides, van der Aalst [3] modeled inter-organizational workflows and the inter-organizational communication structures by means of Petri Nets and message sequence charts (MSCs), respectively. The soundness and consistency of the inter-organizational workflow can be analyzed by checking the consistency of Petri Nets against target MSCs. Since the author abstracted from data and external triggers, the proposed communication protocol is not as complete as the interoperation protocol presented in this paper. To address the derivation of private workflows from inter-organizational workflows, van der Aalst and 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 behaviorally bisimilar to the original workflow based on branching semantics, in contrast to the trace semantics 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 combining Courteous Logic Program and XML. Recently, Karlapalem et al. [32] proposed a meta-model for e-contracts with E–R diagrams and the generation of workflows to support them, but did not consider the notion of workflow views or detailed interoperation protocols. The COSMOS project [27] developed an Internet-based electronic contracting service based on XML and CORBA components, but not based on workflow technologies. Various formalisms have been proposed to study the properties of distributed communicating processes [29,39,41]. Recent work has tried to adapt these formalisms to reason about interfacing communicating processes [10,11] and inter-organizational workflows [4]. These formalisms reason properties, such as bisimulation or failure equivalence, 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 activity in workflow view can be uniquely labeled. This eliminates the need to handle nondeterminism in the workflow view model. As such, a flow control model based on execution 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 and information structure following similar approaches as adopted for e-commerce protocols [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 workflow recovery, but only for WfMS and Web related failures without covering userdefined workflow exceptions. Eflow [9] is one of the closest commercial systems with features like E-ADOME for handling e-services. However, Eflow does not address matching of agents directly with activities. Instead, it uses the concept of generic service node and service selection rules. Currently, several commercial WfMSs such as 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 hierarchical control scheme over workflows implemented in Java for both the workflow engine and the client interfaces. It allows sub-workflows to be executed in different workflow engines across the web. Besides E-ADOME, CrossFlow [26] is another notable system using related approaches to support cross-organizational workflows. CrossFlow models virtual enterprises based on a service provider-consumer paradigm, in which organizations (service consumers) can delegate tasks in their workflows to other organizations (service providers). High-level support is obtained by abstracting services and offering advanced cooperation support. Virtual organizations are dynamically formed by protocol-based matchmaking between service providers and consumers. Though CrossFlow includes detailed work for protocols, it does not provide such a sophisticated mechanism as workflow views for information and control exchange between workflows of different organizations. Protocol enforcement is also not as straightforward as that provided by E-ADOME workflow views equipped with ECA-rules mechanisms based on crossorganizational events. As for standards, the Workflow Management Coalition (WfMC) has recently proposed Wf-XML [49], which is an interchange format specification for an XML language designed to model the data transfer requirements for process specification. Meanwhile WfMC is working towards an industrial standard with the WfMC Reference Model [50] for WfMS to identify their characteristics, terminology [51] and components, and to enable individual specifications to be developed within the context of an overall model for WfMS. An upcoming standard for B-to-B integration is the electronic business XML (ebXML) [21]. The proposed framework contains the idea that two trading partners agree on a collaboration protocol, which contains the messaging service interface requirements as well as the implementation details pertaining to the mutually agreed upon business processes. However, the paradigm of workflow views is more general. It provides mechanisms to bridge the external interfaces and the internal workflows of a business party in a controlled way. Nevertheless, ebXML can be used, among other languages, to implement workflow view details for establishing cross-organizational cooperation. For the sake of simplicity we show only the essential elements in this paper. More exhaustive and more precise schemas have been proposed in emerging standards, such as the RosettaNet [42] open e-business language that includes the Partner Interface Processes (PIPs), (proposed by the RosettaNet consortium designed to align processes between supply chain partners on a global basis), the Business Process Execution Language for Web Services (BPEL4WS) [6] (a successor of Web Service Flow Language, WSFL), and ebXML [21] in particular, the Collaboration Protocol Profiles (CPP). Other emerging standards such as XSLT [54] can be exploited for the implementation of the interoperation in particular for the processing of the exchanged XML messages. According to Kumar and Zhao [34], our proposed approach belongs to the Web stage four, during which workflow features are added to the Web technology to improve


247

interoperability. In order to archive this goal, we have employed in our solution both well-established and emerging Internet standards, such as XML and Web services technologies. 7.

Conclusions

This paper has presented an advanced cross-organizational workflow environment with pragmatic features in cooperating with other organizations over the Internet for workflow enactment. We have illustrated, in the context of E-ADOME, how its ADOMEWfMS engine (a flexible WfMS based on ADOME active OODBMS with role and rule facilities) has been extended to accomplish such objectives. We have also detailed the employment of contemporary Web service technology in specifying and enacting crossorganizational interoperability with workflow view support. Compared with other research efforts on this topic, E-ADOME provides an improved environment for various types of process enactment, which can adapt to changing requirements, with extensive support for reuse. This paper has introduced the use of workflow views for interfacing different WfMSs, possibly belonging to different organizations, and its applications in a cross-organizational environment. We have proposed an interoperation model based on workflow views, simplifying the process of developing cross-organizational workflows. An example has been given to illustrate how crossorganizational business processes can be facilitated by the workflow view mechanism. For workflow views, we are working on further details of formal definitions, construction and verification algorithms, more detailed taxonomy, view update mechanisms, and more operations support. For interoperation protocols, we are working on further details of process adaptation for interoperability, multiple-party protocols and subprotocols, interoperation protocol negotiation, a more comprehensive methodology for interoperation protocol enforcement (including preventive measures), based on crossorganization workflows and the workflow view mechanism. We consider further the following as future research issues: expanding the possible interfaces and coordinating different types of agents, graphical workflow evolution tools, and interoperation with other WfMSs. Finally, we are interested in the application of E-ADOME into various advanced real-life e-commerce environments, such as procurement, finance, stock trading and insurance. We are investigating workflow adaptation and view formation in compliance with the Internet Open Trading Protocol (IOTP) [7]. We are also interested in wrappers to interface with legacy software agents. E-ADOME is currently being built on top of the ADOME-WfMS prototype system, with a Web-based user interface to accommodate the 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-organizational workflow, 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: Proceedings 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 charts and 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 Programming 47 (2001) 47–145. [5] B. Biddle and E. Thomas, Role Theory: Concepts and Research (Robert E. Krieger Publishing Company, 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 transportable agents, Technical report PCS-TR96-283, Dartmouth College, Hanover, N.H. (1996).


249

[9] F. Casati et al., Adaptive and dynamic service composition in eFlow, HP Laboratories Technical Report HPL-2000-39 (March 2000). [10] S.C. Cheung and J. Kramer, Context constraints for compositional reachability analysis, ACM Transactions 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 organizations 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: Proceedings 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-commerce environment, in: Proceedings 9th IFIP 2.6 Working Conference on Database Semantics (DS-9), Hong Kong (April 2001). [15] D.K.W. Chiu, Q. Li and K. Karlapalem, A meta modeling approach for workflow management system supporting 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 in ADOME 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 in ADOME 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 crossorganization 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 rolebased 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: The IRO-DB experience, in: Proceedings of the 2nd IFCIS International Conference on Cooperative Information Systems (CoopIS ’97) (IEEE Computer Society, 1997) pp. 2–13. [26] P. Grefen, K. Aberer, Y. Hoffner and H. Ludwig, CrossFlow: Cross-organizational workflow management in dynamic virtual enterprises, International Journal of Computer Systems Science & Engineering 15(5) (2000) 277–290. [27] F. Griffel et al., Electronic protocoling with COSMOS – How to establish, negotiate and execute electronic protocols on the Internet, in: Proceedings 2nd International Enterprise Distributed Object Computing Workshop (EDOC ’98) (1998). [28] B.N. Grosof, A declarative approach to business rules in Protocols: Courteous Logic Programs in XML, 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: Proceedings 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 with runtime encapsulation, IEEE Internet Computing 4(3) (2000) 56–64. [34] A. Kumar and J.L. Zhao, Workflow support for electronic commerce applications, Decision Support Systems 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), April 2001, Hong Kong (IEEE Computer Society, 2001) pp. 260–267. [37] Q. Li and F.H. Lochovsky, ADOME: An advanced object modeling environment, IEEE Transactions on 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 Workflow 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, WFMCTC-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