Workflow View Driven Cross-Organizational Interoperability in a Web-Service Environment DICKSON K.W. CHIU1, S.C. CHEUNG2, KAMALAKAR KARLAPALEM3, QING LI 4 and SVEN TILL2 1
2
Department of Computer Science and Engineering, Chinese University of Hong Kong, Shatin, NT, Hong Kong Department of Computer Science, Hong Kong University of Science and Technology, Clear Water Bay, Hong Kong 3 International Institute of Information Technology, Gachibowli, Hyderabad 500 019, India 4 Department of Computer Science, City University of Hong Kong, Tat Chee Avenue, Kowloon, Hong Kong email:
[email protected], {scc,till}@cs.ust.hk,
[email protected],
[email protected]
Abstract: In an E-service environment, workflow involves not only a single organization but also a number of business partners. Therefore, workflow interoperability in such an environment is an important issue for enacting workflows. In this paper, we introduce our approach of using workflow views as a fundamental support for Eservice workflow interoperability and for controlled (sub-)workflows visibility to external parties. We present a meta-model of workflow views and their semantics with example usage. We develop an interoperation model based on workflow views, with a supply-chain E-service cross-organization workflow example. We also propose an implementation of workflow view and cross-organizational interoperability based on contemporary Web service [17] technology, with respect to our E-ADOME workflow engine. Keyword: e-service, cross-organizational workflow, workflow management, workflow views, Web service, interoperation protocol
1. Introduction Workflow is the computerized facilitation or automation of a business process. A business process is a set of one or more interdependent procedures or activities, which collectively realize a business objective or policy goal. Workflow Management Systems (WFMSs) can assist in specification, decomposition, coordination, scheduling, execution, and monitoring of workflows. Besides streamlining and improving routine business processes, WFMSs can help in documenting and reflecting upon business processes. Traditional WFMSs often can only coordinate workflows and their enacting agents (often limited to software processes) within a single organization. However, contemporary WFMSs (such as [7], [9], [11], [22], [31], [36], [37], [40]) can now interact with various types of distributed agents over the Internet. In this paper, the term workflow is used to refer to this more general notion of process management. The Internet has recently become a global common platform where organizations and individuals communicate among each other to carry out various commercial activities and to provide value-added services. E-service refers to services provided via the Internet. Therefore, there is an impending need for supporting cross-organizational workflows to these activities, especially because many organizations may have already been employing some kind of workflow technologies. Advanced WFMSs are now webenabled and recent researchers in workflow technologies are exploring cross-organizational workflows to model these activities. In addition, advanced WFMSs can provide various services such as coordination, interfacing, process repository, process (workflow) adaptation and evolution, match-making, exception handling, data and rule bases, etc, with many opportunities for reuse. We have done some preliminary work [11] to demonstrate the feasibility of modeling and enacting composite E-service as workflow extensions, so that we can build E-service agents (i.e., a system that
WSeBT 2002
2
CHIU ET. AL.
provides E-service to be executed by agents when delegated to by the users), and the system for supporting them efficiently, with all the desirable features provided by the underlying WFMS. Furthermore, we have proposed a novel approach of applying workflow view for supply-chain management [12], and e-service enactment [13] in a cross-organizational workflow environment. As follow-up work, we detail in this paper how workflow views can be implemented with contemporary Web service [17] technology, with respect to our E-ADOME workflow engine extended with agent interfaces. Views help balance trust and security, that is, only information necessary for the process enactment, enforcement and monitoring of the service is made available to both parties, in a fully controlled and understandable manner. Moreover, each party only needs minor or even no modification to its own workflow, but can successfully arrive at a commonly agreed and interoperable interface. This kind of adaptation (fully supported by E-ADOME [12]) is only required upon their first interaction, and reusable subsequently, unless their 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 different requirements. Since the E-service arena is very competitive, cross-organization workflows can be developed fast and managed adequately, together with e-protocols. The contribution and coverage of this paper are as follows: (i) a cross-organization workflow approach for a composite E-service with the concept of workflow views, (ii) a cross-organizational interoperation model based on workflow views, (iii) details on the facilitation of workflow views and crossorganizational interoperability with contemporary Web service technology, (iv) demonstration of the applicability of E-ADOME in supporting E-service through these features. The rest of our paper is organized as follows. Section 2 presents a motivating example to illustrate the concept of workflow views in an E-service cross-organizational workflow environment. Section 3 presents our view-based model for e-protocols. Section 4 illustrates how workflow views facilitate eprotocol management, such as e-protocol definition and enforcement, in an E-service environment. Section 5 presents the E-ADOME architecture to illustrate how a flexible WFMS engine can be extended to coordinate distributed agents. Section 6 compares related work. Finally, we conclude this paper with our plans for further research in Section 7.
2. Motivating Example In this section, we present a motivating example of cross-organization workflow based on a supply chain e-commerce scenario, as depicted in Fig. 1. There are three types of organizations involved, viz., end-users, system integrators, and parts vendors. Each of the individual workflow is simple, but the crossorganizational interactions are more interesting and complicated. The end-user undergoes a requisition workflow, say, for an advanced server system. First, quotation enquiries are sent to a number of system integrators. The received quotations with 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 for. A system integrator’s workflow starts when an enquiry is received. The first step is to check from its parts vendors the lead-time and updated price of major parts, especially for those with a large price fluctuation (e.g., CPU and memory). After evaluation, a quotation is sent to the end-user. While the
Workflow View Based E-Protocols in a Cross-Organizational Workflow Environment
3
end-user evaluates the quotation, the system integrators may need to provide additional or updated information for the bid. After a purchase order is received, the successful system integrator then orders necessary missing parts that are not in stock, and estimates a delivery schedule. When all the parts are ready, the system integrator assembles, tests the server, and then delivers it. Finally, after receiving the payment, the workflow ends. A parts vendor’s workflow also starts when an enquiry is received. Assuming this is the end of the supply chain, the vendor has all necessary information to reply the system integrator with updated parts information and prices. Assuming that B-to-B orders on standard parts are usually performed together with payment, this workflow ends after the delivery of the ordered parts. End-User Quotation Enquiry
Begin
Quotation Evaluation
sn ot
av
Check & Receive System
Payment Authorization
End
Pa
er
ail ab le
ym en
t
Inf
Quotation
rd O
tr a o
Prepare Quotation
AND Pa rt
Ex
nfo aI xtr
Begin
tE es
Check Parts Info
ly pp Su
E
qu Re
AND ry ui nq
Purchase Order
AND Prepare Extra Info
AND
Verify & Confirm
Service Preparation
Deliver & Install
End
AND Service Preparation ar ts dP
Parts Vendor Begin
Begin ith rw t de en Or aym p
Up dat e
E nq uiry
Info
System Integrator
li v De
AND Parts Quotation
Deliver Parts
Order Missing Parts
Assemble System
Install Software
System Testing
End
AND
er y
End
Fig. 1: Cross-Organizational Workflow of a Supply-Chaining Example
In this example, the workflow view of the end-user presented to the system integrators has the following requirements. The end-user’s company profile and other background information are made available on request so that the system integrators can design more personalized proposals. Changes in delivery requirement or payment arrangement should notify the supplier. In particular, the enquiry process is concealed so that the system integrators can bid fairly and independently. The workflow view of the system integrator presented to the end-user has the following requirements. 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. Changes in delivery date should be notified to the end-user. Further details of the process “service preparation” are available to the end-user so that the user can further monitor the progress of the job and estimate the delivery date. Updated quotation (price) is sent to the end-user upon a significant aggregated price change in parts with event-triggering mechanism during the evaluation process of the end-user. The workflow view of the parts vendors presented to the system integrators has the following requirements. Updated price for the inquired parts is sent to the system integrators with event-triggering mechanism. Technical specifications and related information for the parts are made available upon request.
4
CHIU ET. AL.
Updates in software drivers and firmware will be notified to the system integrators using event-triggering mechanism (which in turn can notify the end-users). Changes in lead-time should be notified to the system integrators.
3. A Meta-model for Workflow Views In a B-to-B e-commerce environment, a business process usually involves many participating organizations (i.e., such a business process involves several interoperating and interacting workflows from different organizations). This is known as cross-organizational workflow. To support workflow interoperability, one of the basic requirements is a mechanism to let authorized external parties access and make use of only the related and relevant parts of a workflow, while maintaining the privacy of other unnecessary/unauthorized information. Motivated by views in federated object databases, we propose the use of workflow views as a fundamental mechanism for cross-organization workflow interaction. A workflow view is a structurally correct subset of a workflow definition (as in [22]). We propose to use the concept of workflow views (which is detailed in the next section) to help advanced interactions among WFMSs and allow them to interoperate in a white box mode (i.e., they can access each other’s internal information to some extent). Therefore, workflow views can provide a handy mechanism to support E-protocol enactment and enforcement across organizational boundary over the Internet. Since ADOME-WFMS [10][14-16] is event-driven, events and messages from other WFMS are intercepted by the E-ADOME layer and then presented to the ADOME-WFMS. As presented in the example in the previous section, an event from a workflow of another organization (e.g., an inquiry from a customer) can trigger the start of a workflow in the local ADOME-WFMS, or used for synchronization purposes (e.g., deposit payment triggers ordering of a leased line). Similarly, an event from the local ADOME-WFMS (e.g., an inquiry to a supply) can trigger the start of a workflow in another organization, or used for synchronizing tasks in another organization (e.g., an order triggers delivery from another organization). On the other hand, workflow views are also useful in providing access to business processes for external customers or users, including B-to-C e-commerce and e-service. 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 may be required to provide additional information or make decisions during business processes. Even within an organization, workflow views are useful for security applications, such as to restrict accesses (like the use of views in databases). 3.1. Components of a Workflow Views and Their Operations The components of a workflow include the process flow graph, input/output parameters, objects, rules, events, exceptions and exception handlers associated with the workflow. A workflow view is a structurally correct subset of a workflow definition. Thus, a view for a workflow also contains these components. Fig. 2 depicts our workflow view model in Unified Modeling Language (UML) while Fig. 3 depicts a simple workflow view definition language in accordance with our model. The XML schema of the language is given in Appendix A.
Workflow View Based E-Protocols in a Cross-Organizational Workflow Environment
5
* Workflow 1 1
Workflow View
View
* * Accessible_by 1..*
Roles
* Played_by 1..*
Agents
*
1
1
1
1
1 1 Associated
Associated
*
*
Associated * *
Process +visible_name
Transistion +visible_name
Object #Expression +User_access
*
*
*
Rule Read Attribute
#Expression
Event #Expression
1 Write Access
Read Access
Write Attribute *
Exception
Attribute +Protection Request Input
Send Output
Denied Attribute
Fig. 2: Workflow View Model in UML
• Process Flow Graph - Most contemporary WFMSs use a hierarchical composition approach, i.e., a process (workflow) is composed of sub-processes and so on down to leaf-nodes of atomic tasks. This provides a good granularity for providing views of the process flow graph. If a workflow view is to be made available, a fundamental provision is the topmost level process flow graph. However, the detailed composition of individual sub-process may be concealed. Thus a process in the flow graph can be presented in one of the following ways: (i) a white-box sub-process is specified with a sub-workflow view by a statement "process p1 view v1" (i.e., the details of the sub-process is further visible and subject to the restriction of a sub-workflow view); (ii) a black-box sub-process (e.g., “Quotation Enquiry” in Fig. 1) is limited from further details of its further internal composition1; (iii) a gray box where some sub-processes are visible while other sub-processes are concealed (e.g., the whole end-user procurement process). Furthermore, since the name of a sub-process or a transition label may reveal some information, it can be renamed with a rename statement (cf. Fig. 3). The statement "process p2 rename p3" renames a process p3 to p2 while the statement "transition t renames p4 to p5" renames the transition from process p4 to process p5 as t. • Objects associated with a workflow instance - An object associated with a workflow instance need not be present completely in a workflow view. Some attributes can be hidden from the view, some can be read only, and some are presented with write access, while composite attributes can further be composed of attributes with different access rights. Moreover, derived objects specified with objectSQL can be presented in a view. Input / output parameters are also objects specified for the interaction of the user. These parameters are actively received from or presented to the user upon interaction or certain events, with other regular objects in a workflow view being available only upon user's request. The "object" statement in Fig. 3 presents an object in a view. The optional expression is used to specify a derived object. The write option grants write access to the view user. The output option specifies the
1
Unless a view is specified for the sub-process, it is a black box.
6
CHIU ET. AL.
content of the object to be actively sent to the user. The input option specifies the object to be updated from the user. When the accesses of some attributes of an object are different from the default read or write access specified by the "object" statement, it can be overridden by the "attributes" statement, where explicit read, write or denied access can be specified. • Events and exceptions - When events and exceptions are presented in a view, a mechanism (such as a corresponding message) should notify the view user upon their occurrences. This is particularly useful in providing cross-organizational process synchronization and constraint enforcement. Events and exceptions are specified with "event" and "exception" statements, respectively. In addition, the view provider should support user-specified events based on all their accessible objects and process states. In this way, the user need not poll on their interested objects and thus increase the efficiency. For example, the end-user may specify that changes in the delivery date be an event so that the user can be notified when the delivery is earlier or later then expected. • Rules and exception handlers - Rules are presented in a view so that a user can be aware of some of the actions taken by the provider upon certain events or exceptions. This is useful because the process flow graph cannot specify workflow actions that are taken in an asynchronous or event-driven manner. Some of these actions are exception handlers in the view provider. In this way, the user can avoid duplicating some error handling procedures if the errors have already been taken care of. Rules are specified with the "rule" statement, where they can be specified in form or any composition of existing rules. In addition, constraints can be specified in the form of rules. Especially, rules can be used as integrity or semantic constraints in views. (We are investigating in this direction and further details are beyond the scope of this paper.) • Access Security Control - Each workflow view must be specified with one or more accessible roles. A role represents a collection of agents of similar properties [35] and therefore can also be used in specifying security context. 3.2. A Workflow View Specification view v of workflow w begin {process p1 view v1 ...} {process p2 renames p3 ...} {transition t renames p4 to p5 ...} {object o1(=expression1), o2(=expression2)... (write) (input) (output) ...) (attribute a1,a2,...,an write | read | denied ...} {event e1=expression1, e2=expression2, ...} {exception e1=expression1, e2=expression2, ...} {rule r1=expression1, r2=expression2, ...} {access role1, role2, ... } end
Fig. 3: Workflow View Definition Language
Workflow View Based E-Protocols in a Cross-Organizational Workflow Environment
7
view E1 of workflow End_user begin process Quotation_enquiry, Evaluate_quotation, Purchase_order, Check_rec_system view C1, Payment_authorization view Pl; object enquiry output, quotation input, extra_info request, order_form output, installation_and_delivery input, ...; event Change_schedule, ...; exception Payment_delay, ...; access supplier; end view D1 of workflow Dickson_computer_systems begin process Check_parts_info, Prepare_quotation, Prepare_Extra_Info, Verify_and_confirm view V1, Service_preparation view S1, Order_missing_parts view O1, Assemble_system view A1, Install_software view I1, System_testing view S2, Deliver_and_Install view D1; object enquiry input, quotation output, extra_info, order_form input, installation_and_delivery output, ...; event Change_schedule, Change_price, ...; exception Parts_not_available, ...; access customer; end
Fig. 4: Workflow Views Example
Fig. 4 depicts two example workflow views of the end-user and Dickson Computer Systems respectively. These two workflow views are derived from their workflows depicted in Fig. 1. An XML version of the example is given in Appendix B. They will be further used in subsequent sections for illustrating the business process interoperation between these two parties. Fig. 6 also presents these two views graphically.
4. Cross-Organization Interoperability with Workflow Views In this section, we present a model for cross-organizational workflow interoperability based on workflow views, and show how this model can be facilitated with Web services [17]. . 4.1. Cross-Organizational Interoperation Model based on Workflow Views
* Communication * Graph
Interoperation Protocol
1..* Workflow View
Interoperation Parameter
1
1
Message response
* 1 Communication Link * 0..1 request
1..* * sender Process 1 * receiver 1
transition
Fig. 5: UML Model of Interoperation Protocol Based On Workflow Views
8
CHIU ET. AL.
Based on the workflow view mechanism described in the previous section, we now proceed to describe its application in the domain of e-services, particularly, the cross-organization interoperation model. As depicted in Fig. 5, an interoperation protocol consists of workflow views, communication graphs between these views, and a set of interoperation parameters. This information should be stored at each of parties involved in the business process. In this paper, we concentrate on the situations of involving two parties only, because these are the (basis for) majority of interoperation scenarios. Furthermore, business processes involving multiple parties are often having pair-wise interactions only (e.g., end-user with the supplier, supplier with the part vendor, but not end-user with the part vendor directly). Every business process has some basic information to be captured by an information system. In our interoperation model, the interoperation parameters capture a set of attributes whose values describe the necessary information for the business process, which is usually in the form of parameters. Example attributes can be Accept, Offer, Goal, Schedule, Payment, Documents, QoS, Exception_Rules, Commit, etc., where Offer and Accept denotes the organizations that offers and accepts the protocol respectively; Goal is the objective why the protocol is formed; Schedule is a set of executing items to be carried out within specific dates and time, including when the protocol starts, finishes, and any milestone of progress; Payment is a set of rules and values for payment; Documents is a set of documents that have to be available to both parties before forming the protocol; QoS is a set of attributes for the required quality of service; Exception_rules are event-condition-action (ECA) rules to specify anticipated exceptions and their consequences; and Commit denotes whether the parties are committed to the protocol or not. Since different countries and organizations may pose different requirements for interoperation, and because of domain-specific requirements, there may be other attributes depending on the specific cases as well. During interoperation of the business process, besides the parameters, the two parties have to agree on a common workflow, task assignments, and cross-organizational message exchanges. For example, in Fig. 6 we have a protocol between Dickson Computer Systems and the end-user. Each party has its own internal workflow. In order to interoperate, each party must be able to view a subset of the other party’s workflow that will specify the tasks obliged to perform. A key issue here is that in every protocol we have to balance two concepts: trust and security. When two parties interoperate, we assume that there is trust between them and that information necessary for the specification, enforcement and monitoring is available to both parties. At the same time, for security reasons no party wants to reveal information more than necessary to the other party. In our workflow protocol model, the balance is achieved through the workflow view mechanism. Each party specifies a view of its internal workflow that is accessible to the other party. For example, the end-user specifies at the view level that the task evaluate quotation becomes visible to the Dickson Computer Systems. At the same time, details (i.e., the sequence of tasks) that describe how the quotation is evaluated are not disclosed, since the user does not want the other party to know the internal evaluation procedure. Although we may assume a mechanism that enforces the flow of control in each party’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 tasks in each workflow view, called communicating tasks, through which two parties communicate. The cross-organizational control and information flow is specified within communicating tasks and their associated communication links. We associate the message with a label of the communication link. Furthermore, each communicating task
Workflow View Based E-Protocols in a Cross-Organizational Workflow Environment
9
receives and sends a set of messages, the order in which these messages occur is crucial. Therefore, with every communicating task, we impose on the messages a partial order that has to send/receive. For example in Fig. 6, the Quotation Evaluation task of the end-user’s workflow has to interact with the Prepare Quotations and Prepare Extra Info tasks of Dickson Computer Systems. As a result, the end-user receives a QuotationResponse. In addition, synchronization achieved by cross-organizational messages is label with “AND” in the graph, to represent an and-join. For example, the Quotation Evaluation task can only be started upon receiving the Quotation message from Dickson Computer Systems. End User蕨 Workflow View Quotation Enquiry
e ns
t es
Prepare Quotation
Pa rt
er rd
po es
u eq
Begin
Check Parts Info
O em st
foR
Sy
In tra Ex
st ue
Check & Receive AND System
Purchase Order
oR I nf tra Ex
u Q
a ot
nR tio
eq
Quotation Evaluation AND QuotationResponse
Begin
sn ot
Payment Authorization
End
Pa
av ail ab le
AND Prepare Extra Info
Verify & Confirm
ym en
t
Communication Links
AND Service Preparation
Deliver & Install
End
AND Dickson Computer Systems E-service Provider's Workflow View
Fig. 6: A Communication Graph of an Interoperation Protocol between Two Workflow Views
4.2. Specification of the Interoperation Model with XML After two parties have decided to make an interoperation, they have to arrive at an interoperation protocol, which specifies the details. When two parties want to form a protocol, first they have to decide on the value of the interoperation parameters, like the following example based on Fig. 6. Create Description D Accept: User Offer: Dickson Computer Systems Goal: Internet Startup Service Schedule: {Start: June 30, 2001, Lease_line_installation: July 14, 2001, Server_installation: July 16, 2000, ..., Finish: July 30 2001} Payment: {Before June 30, 2001: $1000 (Deposit), ..., With 14 days after Finish: Balance } QoS: Certified_Professions; Exception_Rules: {Schedule_delay 30 days : ... Leased_line.not_installable : ...} Documents: Enquiry, Company_profiles, Order_form, Quotation Commit: Yes ...
Fig. 7: An Interoperation Interface Example
The description (cf. Fig. 7) is the proof that both parties have agreed on the formation of a protocol, and the interoperation protocol model depicts the details. An XML representation of the example is given as
10
CHIU ET. AL.
Appendix C. Then, each party has to present the view as specified in the interoperation protocol model, in order to allow access to workflows of each other, and to incorporate the protocol requirements on the data and control flow. (Fig. 4 depicts an example of the views employed in this protocol.) As these workflow views specify the data output and input requirements of both parties in the object statement, both parties can identify the communicating tasks of both workflow views. Then, by matching these input and output messages, both parties can derive the necessary communication links and their order. At the same time, this process also detects possible mismatches. Fig. 8 lists some example communication tasks and their links. The XML representation of the example is given as Appendix D. If there are mismatches, the parties have to go back to the negotiation or workflow adaptation phase (cf. subsection 4.4). node: Quotation Enquiry - Message: send QuotationRequest Other party task: Begin
node: Quotation Evaluation - Message: receive QuotationResponse Other party task: Verify and Confirm - Message: send ExtraInfoRequest Other party task: Prepare Extra Info - Message: receive ExtraInfoResponse Other party task: Prepare Extra Info
Fig. 8: Some example communication tasks and their links
From the above example, we can see that since there is no need for centralized control, each party of the protocol defines the communicating tasks so that they can receive and send messages appropriately, thus manifesting the required communications. 4.3. Design of Web Service Interfaces for Interoperability Web services [17] provide a new interoperable platform for Internet applications. These applications typically offer self-contained and self-describing services that can be published, located, and invoked across the Internet. Web services perform functions, which can be anything from simple requests to complicated processing of business data. Once a Web service is deployed, other applications and Web services can discover and invoke the Web services 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, encapsulating and true interoperability. This allows the implementations to be programming language-neutral and communications mechanism-independent. Web services are described through their interface definitions in the Web Service Description Language (WSDL [45]), 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. Especially the content and the structure of the interfaces reflex the exchanged business entities.
Workflow View Based E-Protocols in a Cross-Organizational Workflow Environment
11
Fig. 9 presents 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 E 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.
Name: QuotationService:
Name: reqExtraInfo
Name: orderSystem
Location/Provider: System Integrator Input: QuotationRequest CustomerInformation o Name o Address o Customer number SystemConfiguration NumberOfUnits o Part List o Dimensions o
Location/Provider: System Integrator Input: ExtraInfoRequest Customer number Customer Name Extra info request number Quotation/offer number Quotation date Request date Questions Question number o Reference to quotation o Intrinsic question o Requested response time Output: ExtraInfoResponse Supplied extra info o Extra info request number o Extra info request date o Answers: Questions number Intrinsic answer
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 o o Invoice date o Due date of payment o Bank account info Scheduled delivery date
Output: QuotationResponse Quotation o CustomerInformation o SystemConfiguration o ItemizedPriceList o TotalDiscountedPrice o ShippingInformation o TermsOfServices o ExpiryDateOfOffer o DeliveryDate Name: reqPartsQuotation: Location/Provider: Parts Vendor Input: PartsQuotationRequest CustomerInformation Name o Address o Customer number o RequestedPart o Part number o Price o Dimensions o NumberOfUnits Output: PartsQuotationResponse Quotation (Pricelist) o Service o Price o Components
Name: payInvoice Location/Provider: SystemIntgrator Input: Payment Invoice number Invoice date Payer Payee Invoice amount Output:PaymentAcknowledgement result (Boolean) successful/ unsuccessful
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: PartsDelivery Order successful/ unsuccessful Bill Scheduled delivery date
Fig. 9: Some Web Services to be Provided by Dickson Computer Systems
4.4. Further Issues on Workflow Adaptation and Interoperability Negotiation When two organizations are interested in interoperating for a certain business process, they exchange an initial workflow view of each other, to disclose their company profiles, and to inform the other party 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 the information and coordination requirements of both parties. However, these requirements often vary in different organization, 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
12
CHIU ET. AL.
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 interoperations among different organizations. Note that the use of workflow views can offer an 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 difference (e.g., some companies usually do not pay deposit, therefore they need to add this task). This adaptation can be permanent if the organization believes that it is useful for improving the business process (in dealing with other companies or other favorable reasons); this is known as workflow evolution. A detailed description of workflow evolution supported by ADOME-WFMS is available in [16]. 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 difference in workflows of the two parties, one or both of them may decide to re-compose their workflows to accommodate the cooperation. Alternatively, especially if the business relationship is not a long term one, one of the two parties may choose to fall back to a manual mode of cooperative (semi-manual) 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 System), subsequent interactions can thus be accomplished through email, ICQ alerts, and further customized generated web pages. Because an organization may interoperate with many other different organizations, different views of a workflow may be presented by E-ADOME to different organizations according to different requirements. 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.
Workflow View Based E-Protocols in a Cross-Organizational Workflow Environment
13
5. E-ADOME Architecture Enhanced with Web Service Agents
.. ai l. Em
Web Script Processor
C
Q,
Access Security Layer
e iv ct ra te n I e/ n ti v si o r a es pe S o o
Softwware API Agents
Internet Message Sender
Web Service Interface
e API Sof twar e / respo ns ion Ex cept
Human Agents
Sof tw Ra are A ise E x PI c all c ep tion /
Web Service Agents
IC
E-ADOME
WFMS initiated Web Session
Web-Script Agents
Internet Event Interceptor
Internet Interface Layer
ADOMEWFMS Layer
Recovery Manager
ADOME / OODBMS Layer
Workflow Executor
Exception Manager
Match Maker
Human Intervention
Organization Database
Workflow Editior
Ex ternal Ex ception / Ev ents
Log Manager
ADOME facilities: roles, events, rules etc. OODBMS
Fig. 10: E-ADOME Architecture
We extend a flexible, web-enabled workflow management system, ADOME-WFMS [13][16], into EADOME to provide support for specifying, executing and monitoring composite e-services. In particular, we strengthen the external interface layer to interact with different types of agents over the Internet more effectively. The most recent update is the employment of Web service support [17] to replace a traditional web-server. Because agents over the Internet probably originate from different organizations and often operate with different interfaces, we cannot change foreign public agents (such as their web pages) to the exact interface we want. Instead, adaptations are needed to accommodate for them. 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 tasks 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 Fig. 10, the E-ADOME environment can be divided into the following layers: 1. ADOME / OODBMS Layer – ADOME was developed to enhance the knowledge-level modeling capabilities of OODBMS models [31], so as to allow them to more adequately deal with data and knowledge management requirements of advanced information management applications, especially WFMSs.
14
CHIU ET. AL.
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 [13]. 3. Internet Interface Layer – this is the enhancement layer to the WFMS for ADOME-WFMS to interact with various types of external agents through the Internet. 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 Internet Interface Layer The E-ADOME Internet Interface 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. Fig. 10). In particular, Internet Message Sender sends alerts to users and agents via ICQ or E-mail; this module also sends out requests to other software agents using a compatible API. 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 agent may be internal or external to the organization and may itself be another WFMS. Furthermore, an Access Security Layer is added to handle external communications. Web Script Processor enables the E-ADOME to initiate an automatic conversation script with other interactive, web-based service providers without compatible software API, including most on-line ordering web pages or service report forms. (Without this facility, the WFMS would need a staff to perform this task manually.) The newly added Web Service Interface module enables E-ADOME to communicate with other WFMSs to allow for more advanced task execution and control in foreign WFMSs. It 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 can be integrated without changing of underlying layers. 5.2. Discussion In this section, we have presented the E-ADOME architecture for enacting cross-organization eservices in a workflow environment. The enabling power for e-service applicability mainly relies on the additional Internet interface layer on top of ADOME-WFMS. This interface layer can send and receive messages through the Internet, in order to communicate with distributed users and other service agents. Arrival of incoming messages can be detected as events to trigger actions of the WFMS specified by both regular workflow specification and Event-Condition-Action rules. In particular, the WFMS interface module, now equipped with Web Service mechanism, further facilitates cross-organizational e-service (workflow) enactment. As the E-ADOME extension is built on top of ADOME-WFMS, it is perceived that the techniques presented in this paper are applicable to other similar WFMSs or other information systems.
Workflow View Based E-Protocols in a Cross-Organizational Workflow Environment
15
6. Related Work Modeling of interoperation protocols can be dated back to the Protocol Net Protocol [38]. However, they only concentrated on low-level transaction aspects. [22] presented a framework for legal protocols, but not a mechanism for modeling interoperation protocols. [34] described a model for representing electronic trade procedures based on Petri Nets. [25] introduced a declarative approach to business rules in e-commerce protocols by combining Courteous Logic Program and XML. Recently, [30] proposed a meta-model for interoperation protocols with E-R diagrams and generation of workflows to support interoperation protocols, but did not consider the notion of workflow views and the notion of commitment in interoperation protocols. The COSMOS project [24] developed an Internet-based electronic protocoling service based on XML and CORBA components, but not based on workflow technologies. Our preliminary approach of workflow views have been presented in [12]. This approach has been motivated by views in object-oriented data models, which can be dated back to [19], and in particular by imaginary objects in [1]. [21] discusses federated OODBMS and views for objects in a distributed environment. [32] presented an algorithm for workflow view construction and verification, but did not discuss any of its applications. [2] introduced the concept of inheritance of a public workflow from a private workflow to achieve interoperability in a cross-organizational e-commerce environment. Dartflow [7] is one of the first web-based WFMS, using transportable agents, CGI and Java technologies. WebWork [36] described some issues in web-based workflow recovery, but only on WFMS and web related failures without covering user-defined workflow exceptions. Eflow [9] is one of the closest commercial systems with features like E-ADOME in handling e-Services. However, Eflow does not address matching of agents directly with tasks. Instead, it uses the concept of generic service node and service selection rules. Currently, several commercial WFMSs such as TIB/InConcert [40] and Staffware 2000 [37], provide web user interfaces too. In addition, I-Flow [20] has a Java workflow engine. WW-flow [31] provides a hierarchical control scheme over workflows implemented in Java for both the workflow engine and client interfaces. It allows sub-workflows to be executed in different workflow engines across the web. As for standards, Workflow Management Coalition (WfMC) has recently proposed Wf-XML [41], 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 [42] for WFMS so as to identify their characteristics, terminology [43] and components, and to enable the individual specification to be developed within the context of an overall model for WFMS. However, only very recently, WfMC published a white paper on event extension to WFMS [44], but they still do not specifically address exceptions. It is a new approach to E-service enactment based on an advanced WFMS engine. Besides E-ADOME, other notable systems using related approaches include Eflow [9] and Crossflow [22]. 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
16
CHIU ET. AL.
different organizations. Protocol enforcement is also not so straightforward as that provided by EADOME workflow views equipped with ECA-rules mechanisms based on cross-organizational events. [1] presents workflow schema exchange in an XML dialect called “XRL” but does not include support for workflow views. Furthermore, not all the above-mentioned WFMSs support various kinds of interactions with different kinds of agents, as in the E-ADOME interface layer. Very few commercial WFMSs provide support for handling exception and workflow adaptation comprehensively. Furthermore, few systems have advocated (let alone supported) an extensive meta-modeling approach based on agents, match-making, exception handling, etc. Compared with the systems close to ours, E-ADOME has the most features available to support E-services, interoperation protocols, and mobile agents on the Internet.
7. Conclusions This paper has presented an advanced cross-organizational workflow environment with pragmatic features in cooperating with other organizations over the Internet for E-service 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 rule facilities) is extended to accomplish such objectives. We have also detailed the employment of contemporary Web service technology in specifying and enacting Eservices with the 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 view for interfacing different WFMSs, possibly belonging to different organizations, and its applications in an e-service environment. We have proposed an interoperation model based on workflow views, to simplify the process of developing crossorganizational workflows. We have also illustrated how cross-organizational business processes can be greatly facilitated by the workflow view mechanism for security, information hiding, workflow adaptation, providing different interactions with different organizations. Moreover note that, E-ADOME specification of workflows is based on standardized Workflow Management Coalition workflows, many of the techniques presented in this paper can thus be applicable to any WFMSs for E-service enactment. 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 sub-protocols, 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 research issues on interfacing and interoperability important for extending the applicability of an advanced WFMS engine, which include: expanding the possible interfaces and coordinating different types of agents, graphical workflow evolution tools, and interoperating 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). We are also interested in wrappers to interface with legacy software agents. E-ADOME is currently being built on
Workflow View Based E-Protocols in a Cross-Organizational Workflow Environment
17
top of the ADOME-WFMS prototype system, with a web-based user interface to accommodate the whole range of activities.
References [1] W.M.P. van der Aalst and A. Kumar. XML Based Schema Definition for Support of Inter-organizational Workflow. In Proc. 21st International Conference on Application and Theory of Petri Nets (ICATPN 2000), Aarhus, Denmark (2000) [2] W. M. P. van der Aalst, M. Weske. The P2P Approach to Interorganizational Workflows. In Proceedings of 13th International Conference Advanced Information Systems Engineering (CAiSE 2001), Interlaken, Switzerland, June 2001, Springer LNCS 2068, pp140-156. [3] S. Abiteboul and A. Bonner. Objects and Views. In Proceedings of ACM SIGMOD Conference, 1991. [4] G. Alonso, et al. Exotica/FMDC: a workflow management system for mobile and disconnected clients. Distributed & Parallel Databases, 4(3):229-247, 1996. [5] K.L. Myers and P.M. Berry, At the Boundary of Workflow and AI. In proceedings of the AAAI-99 Workshop on AgentBased Systems in The Business Context held as part of AAAI-99, Orlando, Florida, July 1999. [6] D. Burdett, et. al. Internet Open Trading Protocol. McGraw-Hill, 2000. [7] Ting Cai, Peter A. Gloor, Saurab Nog, DartFlow: A Workflow Management System on the Web using Transportable Agents, Technical Report PCS-TR96-283, Dartmouth College, Hanover, N.H., 1996. [8] F. Casati, G. Pozzi. Modeling Exceptional Behaviours in Commercial Workflow Management Systems. In Proceedings of the 4th International Conference on Cooperative Information Systems (IECIS 98), IEEE Press, 1998. [9] F. Casati, et al. Adaptive and Dynamic Service Composition in eFlow. HP Laboratories Technical Report HPL-2000-39, March 2000. [10] D.K.W. Chiu. Exception Handling in an Object-Oriented Workflow Management System. Ph.D. Thesis, Computer Science Dept., Hong Kong University of Science and Technology, Aug 2000. [11] D.K.W. Chiu, K. Karlapalem and Q. Li. E-ADOME: A Framework for Enacting E-services. VLDB Workshop on Technologies for E-Services, Cairo, Eygpt, Sept. 2000. [12] D.K.W. Chiu, K. Karlapalem and Q. Li. Views for Inter-Organization Workflow in an E-Commerce Environment, 9th IFIP 2.6 Working Conference on Database Semantics (DS-9), Hong Kong, April 2001. [13] D.K.W. Chiu, K. Karlapalem, Q. Li, and E. Kafeza. Workflow View based E-protocols in a Cross-Organization E-service Environment. Distributed and Parallel Databases, 2002 (to appear). [14] D.K.W. Chiu, Q. Li and K. Karlapalem,. A Meta Modeling Approach for Workflow Management System Supporting Exception Handling. Information Systems, Pergamon Press, Elservier Science, 24(2):159-184, 1999. [15] 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, Cambridge International Science Publishing, Cambridge, England, vol 1 no.3, 2000. [16] D.K.W. Chiu, Q. Li and K. Karlapalem. Web Interface-Driven Cooperative Exception Handling in ADOME Workflow Management System. Information Systems, Pergamon Press, Elservier Science, 2001. [17] V. Chopra, et. al. Professional XML Web Services, Wrox Press, 2001. [18] GHG Corp. Clips Architecture Manual, Version 5.1. Jan 1992. (available at http://www.ghg.net/clips/CLIPS.html) [19] U. Dayal. Queries and Views in an Object-Oriented Data Model. In Proceedings of 2nd International Workshop on Database Programming Languages, 1989. [20] Enix Consulting Limited. An Independent Evaluation of i-Flow Version 3.5, 2000 (available at http://www.i-flow.com). [21] 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), 1997. [22] M. Gisler, K. Stanoevska-Slabeva, and M. Greunz, Legal Aspects of Electronic Protocols, In CAiSE*00 Workshop of Infrastructures for Dynamic Business-to-Business Service Outsourcing (IDSO'00) Stockholm, 5 - 6 June 2000. [23] P. Grefen, K. Aberer, Y. Hoffner, H. Ludwig; CrossFlow: Cross-Organizational Workflow Management in Dynamic Virtual Enterprises; International Journal of Computer Systems Science & Engineering, 15( 5):277-290, 2000. [24] F. Griffel, et al. Electronic Protocoling with COSMOS – How to Establish, Negotiate and Execute Electronic Protocols on the Internet. 2nd Int. Enterprise Distributed Object Computing Workshop (EDOC '98), 1998. [25] B. N. Grosof, A declarative approach to business rules in Protocols: Courteous Logic Programs in XML, Proceedings of the 1st ACM Conference on Electronic Commerce (EC99), Denver, Colorado, USA, Nov. 3-5, 1999. [26] A. ter Hofstede, M. Orlowska and J. Rajapakse. Verification Problems in Conceptual Workflow Specifications. Data & Knowledge Engineering, Pergamon Press, Elservier Science, 24(3) (1998) 239-256 [27] Hewlett Packard. Changengine Admin Edition (AdminFlow) Process Design Guide, 1998. [28] Itasca Reference Manual, Ibex Corporation, 1994. [29] ICQ. http://www.icq.com [30] K. Karlapalem, A Dani and P. Krishna. A Frame Work for Modeling Electronic Protocols. Proceedings of the 20th International Conference on Conceptual Modeling, Yokohama, Japan, Nov 2001, Springer LNCS 2224, pp193-207. [31] Y. Kim, S. Kang, D. Kim, J. Bae, and K. Ju. WW-Flow: Web-Based Workflow Management with Runtime Encapsulation. IEEE Internet Computing, 4(3):56-64, 2000. [32] D.-R. Liu and M. Shen. Modeling Workflows with a Process-View Approach, Proceedings of the 7th International Conference on Database Systems for Advanced Applications (DASFAA 2001), April 2001, Hong Kong, IEEE Computer Society, pp.260-267
18
CHIU ET. AL.
[33] D. McCarthy and S. Sarin. Workflow and Transactions in InConcert. IEEE Data Engineering,16(2) (1993) 53-56 [34] Ronald M. Lee. Documentary Petri Nets: A Modeling Representation for Electronic Trade Procedures. Business Process Management 2000: 359-375 [35] Q. Li and F. H. Lochovsky. ADOME: an Advanced Object Modelling Environment. IEEE Transactions on Knowledge and Data Engineering, 10(2):255-276, 1998. [36] John A. Miller, Amit P. Sheth, Krys J. Kochut, and ZongWei Luo. Recovery Issues in Web-Based Workflow. Proceedings of the 12th International Conference on Computer Applications in Industry and Engineering (CAINE-99), pp. 101-105, Atlanta, Georgia Nov. 1999. [37] Object Management Group. Foreword UML specification 1.4, September 2001. [38] R. G. Smith. The protocol net protocol: High Level Communication and Control in a Distributed Problem Solver, IEEE Transactions on Computers 29(12), December 1980, 1104-1113. [39] Staffware Corporation. Staffware Global - Staffware's Opportunity to Dominate Intranet based Workflow Automation, 2000, http://www.staffware.com [40] TIBCO Software Inc., which has acquired InConcert Inc., http://www.tibco.com [41] Workflow Management Coalition. Workflow Standard – Interoperability Wf-XML Binding, WFMC-TC-1023, May 2000. [42] Workflow Management Coalition. The Workflow Reference Model. (WFMC-TC-1003, 19-Jan-95, 1.1) [43] Workflow Management Coalition. Terminology and Glossay, WFMC-TC-1011, Feb 1999, 3.0. [44] Workflow Management Coalition - David Hollingsworth, ICL A&TC. White Paper – Events. April 1999. [45] http://www.w3.org/TR/wsdl
Workflow View Based E-Protocols in a Cross-Organizational Workflow Environment
19
Appendix A: XML Schema of the Workflow Definition Language in Fig. 3
2
CHIU ET. AL.
Workflow View Based E-Protocols in a Cross-Organizational Workflow Environment
3
Appendix B: XML of Workflow View Example in Figure 4 Check_parts_info Check_server_price Prepare_Quotation Prepare_Extra_Info Verify_and_confirm V1 Service_preparation S1 Order_missing_part O1 Assemble_system A1 Install_software I1 System_testing S2 Delivery_and_install D3 enquiry input quotation output order_form input installation_and_delivery output Change_schedule Change_price Parts_not_available customer
4
CHIU ET. AL.
Appendix C: The XML Representation of the Interoperation Interface Example in Fig. 7 User Dickson Computer System Internet Startup Service Start 2001-06-30 Lease_line_installation 2001-07-14 Server_installation 2001-07-16 Finish 2001-07-30 Before June 30,2001 $1000 deposit With 14 days after Finish Balance Certified_Professions Scheduled_day + 7 days reached Payment not received do_nothing Scheduled_day + 30 days reached Payment not received ... 2001-07-14 Lease_line.not_installable ... Enquiry Company_profiles Order_form Quotation true
Workflow View Based E-Protocols in a Cross-Organizational Workflow Environment
3
Appendix D: XML for the Communication Tasks and Links in Fig. 8 Quotation Enquiry QuotationRequest send Begin Evaluate Quotation QuotationResponse receive Prepare Quotation ExtraInforRequest send Prepare Extra Info ExtraInfoResponse receive Prepare Extra Info
4
CHIU ET. AL.
Appendix E: WSDL definition of QuotationService Web service
Workflow View Based E-Protocols in a Cross-Organizational Workflow Environment
Service to request a quotation
3
