Electronic business relationships over the internet, such as the linking of cross-organizational business processes in virtual supply chains and other scenarios enjoy an increasing interest in the business world. Especially the use of XML as a domain-independent encoding standard for business documents has led to the development of standardized business frameworks, and the development of interoperability mechanisms that support these standards is underway. In this paper we describe an architecture for the support of crossorganizational workflows through XML messages. This architecture has been implemented and tested within the AFRICA1 project at the University of Muenster, Germany. While our work is based upon the emerging Wf-XML standard of the Workflow Management Coalition, it contains a number of significant enhancements that provide a secure, reliable management of global workflow processes.
In the area of workflow interoperability, a number of standardization efforts have been in place, namely by standardization organizations like the Workflow Management Coalition, the Object Management Group and the Internet Engineering Task Force.
The reference model of the Workflow Management Coalition (WfMC) identifies five functional interfaces, that
connect a workflow management system with external application systems, of which Interface 4 deals with
workflow interoperability [
The Object Management Group (OMG) has standardized a facility that provides workflow services through an
object request broker [
The Simple Workflow Access Protocol (SWAP) was created in 1998 through an industry consortium under the
auspices of Netscape, Oracle, SUN [
Recently a number of standardization organizations for XML business frameworks have appeared on the Internet. The most well-kown organizations of this kind are BizTalk and RosettaNet2.
The BizTalk forum was created by Microsoft and aims at the definition of guidelines for the publication of
XML schemas by independent vendors [
The RosettaNet consortium was formed by various manufacturers and suppliers of hard- and software in order
to standardize supply chain processes within the IT industry domain [
The AFRICA project was initiated in October 1999 with the aim of building a reliable infrastructure for business-to-business workflows, using XML for message encoding. The focus was on incorporating complex, non-sequential process models involving multiple partners and the integration of a global monitoring service. Since the project team had a number of commercial workflow management systems available for testing and integration purposes, it was decided not to implement a workflow engine with interoperability features, but instead an add-on component (wrapper), that can be added to existing workflow installations. A reference implementation of this wrapper was finished by March 2000, clearly demonstrating the potential of XML-based process communication.3 3.1
For the design of the AFRICA prototype, a number of design principles were employed, to make the system usable in a large number of contexts, namely system independence, reusability, security and support for n-party processes.
System independence: The AFRICA prototype should enable companies to participate in cross-organizational workflows without modifying existing workflow management systems. For this reason, the prototype was implemented as a wrapper that sits on top of an existing application system and encapsulates the Wf-XML message handling from the underlying system. Vendor supplied APIs are used to access the respective systems, leaving the system integrity untouched.
Reusability: The AFRICA prototype was designed with the goal of using as much of the system code as possible in different environments. Therefore, a three tier architecture was developed, separating the transport layer, process logic layer and abstraction layer. For changing transport protocols or security mechanisms, only the transport layer needs to be adjusted, while during the migration to a different workflow management system only the abstraction layer is changed accordingly, leaving the transport and process layer intact.
Security: Communication between two AFRICA-enabled systems should be secure and reliable. In order to achieve this, additional information have been inserted in the transport section of the Wf-XML messages that are evaluated by the transport layer of the wrapper.
Support for n-party processes: While most interoperability frameworks focus on the peer-to-peer interaction between two business partners, the goal of the AFRICA project was the support for an arbitrary number of involved parties (e. g. a complex supply chain with several involved parties). In order to maintain the overall consistency of the process as well as to provide monitoring information about a global process regardless of the local enactment, the notion of a GlobalProcessID was added to the Wf-XML messages. 3.2
The AFRICA wrapper uses an extended Wf-XML format for the exchange of messages. Each message consists of the four parts Transport, Security, <<W?fxMmelssvaegres>ion="1.0"?> Header and Body. <WfTransport>
The WfTransport section groups those elements that are relevant at ... tlroacnaslpporrotacteisosnintismtaen,cbee,feo.reg.ththeemseenssdaegrearnedacrheceispiitesnetvoefntthuealmreescsipagieenat,si.we.elal <<W/fW.Sf.eT.cruarnistpyo>rt> as a correlation key for the identification of request/response pairs. </WfSecurity>
The WfSecurity section contains a unique identifier for each message <WfMessageHeader> and a timestamp. This information is used to identify lost, obsolete or <./.W.fMessageHeader> intercepted messages and to acknowledge the receipt of the message by the <WfMessageBody> transport layer (see section 3.3). ...
The WfMessageHeader section contains – different from the original </W<f/MWefsMseasgsea>geBody> Wf-XML standard – the global process identifier that this message relates to. Each wrapper only needs to know the mapping between the global process and its own local process instances, but does not need to keep track Figure 1. Overall message structure of the local naming schemas of other involved parties. The header section also contains the identifier of the operation to be executed in order to enable the preprocessing of this information.
The WfMessageBody section contains the details about the operation to be executed as well as the context data, i. e. the data that gets passed to the local workflow management system for further processing. We assume 3 See http://pcwi501.uni-muenster.de/africa/index.html no predefined structure of the context data, this way, data schemas that have been standardized by other organizations (cf. section 2.2) can be inserted here.
In addition to the operations defined by the Wf-XML standard, a number of additional operations were introduced, in order to facilitate global process management and the handling of monitoring information. These operations are PassProcessInstance, GetHistory and Notify.
PassProcessInstance hands the control of the global process over from one party to the next. The sender switches into the state “suspended” and is re-activated, when his wrapper receives a PassProcessInstance command himself. If a local process instance exists, the wrapper sets the state of this instance to active.running. If no local instance for the global process exists, the wrapper instantiates a new local instance, starts it and updates its lookup table with the local process ID. Note that the suspend and resume function only affects the state machine of the Africa wrapper. If the local workflow instance contains multiple threads (i. e. multiple concurrent paths within the workflow model), the suspend does not prohibit the continuous execution of these threads.
GetHistory requests monitoring information from a remote party. If the remote party has passed the process control to several other parties, the command is cascaded until the currently active party returns information about its current process status. The parties located in the middle between the sender and the final recipient of the command add their own process status information and pass a merged set of data on until it finally reaches the sender of the GetHistory command.
Notify actively “pushes” process status information to the observer of a remote process instance. If a remote party sees the necessity to inform the observer about certain events, the Notify command is used. 3.3
In order to facilitate reuse and encapsulation of information from lower levels, the AFRICA wrapper was designed using a three-tier architecture. Figure 2 illustrates the architecture of the system, using an incoming WfXML message as an example.
The transport layer handles the reliable and secure transfer of Wf-XML messages between AFRICA-enabled systems. The prototype uses TCP/IP port-to-port communication and SSL encryption for security measures. For other transport protocols or security mechanisms the transport layer has to be changed accordingly, but the process logic and abstraction layer remain untouched. When a message is received by the TCP Socket Listener, it is forwarded to the Open SSL Decryption unit, where the message is decoded. The plain-text XML message is then handed over to the security validation mechanism, that evaluates the timestamp and the security token of the message. The security token is sent back to the originator of the message to acknowledge the receipt. The wrapper keeps a backlog of the messages received during the last 20 minutes, older messages and messages with a duplicate security token are discarded as obsolete. The XML message is then sent to the process logic layer for further processing.
Open SSL Decryption
Valid
Process Instance One per Workflow
Case
Audit Trail Context Data
interaction WFMS Message
Handler: One per Request/ Response Pair Operation Handler One per Command Command, Audit Trail Data Fromat Specifications
Encrypted XML
Message: Qx65hk1KShHjS8
TCP Socket
Listener
Within the process logic layer, the XML message is parsed, the Wf-XML command is separated from the context data of the message and a standardized call of abstraction layer API functions is issued. After the receipt of the message from the transport layer, the Message Handler component determines whether the message is a response to a request issued earlier (then the appropriate instance of the Message Handler is identified) or if the message is a request itself (in which case a new Message Handler is instantiated). The Message Handler extracts the Wf-XML command from the message and sends it with the context data and audit trail information to the Process Instance handler. This component reads the GlobalProcessID of the message and matches it with the local process instance that exists within the local workflow management system. It translates the global command into a local instance specific command and passes it on to a new instance of the Operation Handler. The Operation Handler then transforms the context data into the format required by the local workflow schema and passes the command and the context data through an API call to the abstraction layer. Depending on the content of an interoperability contract, the semantic interpretation of the context data is carried out in this layer. The resulting context data XML tree can be transformed in various ways, matching the requirements of the application system behind the abstraction layer.
The abstraction layer encapsulates proprietary API calls to the workflow management system of a specific vendor and exhibits a standardized API to the process logic layer. For the prototype two abstraction layers were completed, one for interaction with a custom-made web server and one for the Business Workflow component of an SAP R/3 system. Within this scenario, the command and context data received from the process logic layer are translated into SAP-specific BAPI (Business Object API) calls. In order to accommodate workflow management systems of different vendors, only the abstraction layer needs to be changed, leaving process logic layer and transport layer untouched.4
A FRICA Wrapper
I P
A Web Front-end
Problem Information Request
Solution User
Problem Form
Monitoring Component
A FRICA Wrapper
I P
A Helpdesk Workflow System KnoBwalseedge
Problem Information Request Solution
A FRICA
Wrapper A FWRrIaCpAper I P A
Vendor
VWeonSrdykosfrltoewm
System
The AFRICA prototype was implemented using a 2-stage helpdesk scenario as an example. Within this scenario, a client has contracted an external service provider to perform helpdesk tasks, in case an employee of the client encounters soft- or hardware-related problems. The helpdesk then tries to solve the problem using his internal knowledge base. He may choose to either escalate the problem to a soft- or hardware vendors, send a solution to the client or request additional information from the client. The vendors in turn have the option of either sending a solution back or a request for additional information, which in turn is passed on to the client. Figure 3 gives an overview of the implementation scenario.
The client application of the helpdesk scenario can be used using only a web browser. Data entry and requests are handled via database-driven web pages.
The interaction between the web frontend and the AFRICA wrapper is handled via server-side API calls, transparent for the user. Figure 4 shows the monitoring of a remote workflow instance through the web interface. After the problem was entered using a HTML form, the data was then sent to the helpdesk. The 4 The process of sending out a Wf-XML message through the AFRICA wrapper is exactly reverse to the process described above: The workflow system calls out to the abstraction layer, the process logic layer transforms the command and the context data into a well-formed Wf-XML message and integrates the GlobalProcessID, and the transport layer adds security information, encrypts the message and sends it to the appropriate recipient. responsible workflow participant at the helpdesk site was unable to solve the problem and sent the problem description to the vendor site, where a developer is working on a solution and has given an estimate of the remaining processing time. From this screen, the user can review or update the problem description, actively request the audit trail of the process or cancel the workflow instance, which leads to a cascaded termination of workflow instances, that have been created at vendor sites by request from the helpdesk. 4
The Interworkflow Project at the Kanagawa Institute of Technology, Japan, focuses on the definition of a global
workflow model for an interorganizational business process [
The CrossFlow project [
WISE (Workflow-based Internet Services) is a project conducted at the Swiss Federal Institute of Technology
[
The FlowJet prototype [
In this paper we have presented the AFRICA framework for business-to-business workflow applications. It combines a standardized, extensible message format with a flexible and adaptable technical architecture. The applicability of this framework has been demonstrated by the implementation of a prototype scenario using commercial workflow management systems and a custom-made web-front-end. The extensions to the existing Wf-XML framework have been submitted to the WfMC for consideration in the next version of the Wf-XML standard. In the future our framework will be extended to accommodate a number of different workflow products. We are currently investigating the automated negotiation of communication parameters such as security mechanisms and protocol standards between AFRICA-enabled workflow systems as well as the automatic mapping of XML context data schemes into the proprietary format of the underlying workflow management systems.
The authors would like to thank the members of the AFRICA project team, Leif Jakob, Lutz Michaelsen and Simon Schwingel for their effort. Furthermore, we would like to thank the members of the WfMC Working Group 4, especially Rainer Weber and Keith Swenson for many useful comments on the AFRICA XML message format. Finally, we would like to thank the anonymous referees for their comments, which greatly helped to improve the quality of this paper.