Distributed and Parallel Databases, 12, 163–191, 2002 c 2002 Kluwer Academic Publishers. Manufactured in The Netherlands.
The Application of Workflow Technology in Semantic B2B Integration CHRISTOPH BUSSLER Oracle Corporation, 500 Oracle Parkway, Redwood Shores, CA 94065, USA
[email protected]
Recommended by: Boualem Benatallah and Fabio Casati
Abstract. Workflow Management Systems (WFMSs) are often used in context of B2B integration as a base technology to implement business-to-business (B2B) integration processes across enterprises. In this context the notion of “distributed inter-organizational workflows” is introduced to indicate the collaboration of enterprises on a process level. This notion requires a thorough examination presented in this article since WFMSs were not designed with inter-enterprise distribution as one of the design goals. At a closer look, the proposed use of WFMSs in context of B2B integration is often very na¨ıve and inappropriate. Consequently it does not address the real requirements found in enterprises. Enterprises do not share common workflow definitions, let alone common workflow instance execution state and have no intent to do so due to competitive knowledge protection. Furthermore, trading partner specific business rules within enterprises are not accounted for leading to an unwanted “explosion” of workflow definitions. This article clarifies the notion of “distributed inter-organizational workflows” as well as private and public processes. Based on this definition, the appropriate use of WFMSs is shown in context of an overall B2B integration solution that allows enterprises to protect their competitive knowledge while participating in B2B integration. Keywords: business-to-business integration, private and public process, business rules, workflow management, transformation, message exchange patterns, B2B standards
1.
Introduction
Business-to-business (B2B) integration is a “buzzword” that got a lot of attention in very recent years. It fundamentally refers to two or more organizations (businesses as well as government organizations or other) exchanging business data electronically like purchase orders, invoices or shipment notices over networks. However, the concept of sending business data electronically between organizations is not a novelty. B2B integration standards like EDI [19] have been developed since over 25 years and have been adopted by large sets of corporations. Since these have been put in place before the Internet was around, so-called value added networks (VANs) were the transport infrastructure of choice for business data. Each organization involved in B2B integration was connected to a VAN and this enabled the organization to send and to receive business data. B2B integration requires that business data are automatically extracted from back end applications (like enterprise resource management systems, ERP) to send them to trading partners and that business data are automatically inserted into back-end applications once received from trading partners. Only if this overall process was automated efficiency and accuracy could be improved significantly.
164
BUSSLER
Many organizations started by running only one back end application. In this situation the source and target of business data was only one application. Since EDI was the only standard available for supply-chain related business data, each organization had to only implement one standard for one back end application. That is a quite straight forward one-to-one mapping. Over time, organizations deployed more and more back end applications that on one hand side have to exchange data between each other and on the other hand side have to be part of the B2B integration infrastructure. At the same time the number of B2B integration standards increased rapidly (some of which are [16, 36, 40] and more can be found in [8]). The increase of B2B integration standards is mostly due to the fact that XML is used as the underlying syntax. With the simple structure of XML it became very easy to define documents types. With these two developments (increased number of back end applications as well as B2B integration standards) converging at the same time organizations are faced with a complex problem: how to manage the complex interactions or business processes between the back end applications and B2B integration standards. Casati et al. [10] and Georgakopoulos et al. [22] show examples of complex business processes. These are multi-step processes that define what actions have to be executed over time in order to achieve a business goal. For example, if an employee orders a laptop the order has to be recorded, the order has to be verified (is the ordered laptop from the preferred supplier?), has to be approved, funds have to be allocated for payment later on, a purchase order has to be sent to the supplier, the supplier has to send back a purchase order acknowledgment, a delivery date has to be provided by the supplier and so on. This is only one example of a complex business process. Workflow management with appropriate extensions for B2B integration standards as well as back end application integration standards is often considered the solution for the complex integration problem of organizations. While this solution is in general appropriate, workflow management technology can be applied in different ways. Later on a discussion of various possibilities will derive to an optimal deployment. In the following a detailed example of a B2B integration process is discussed that is used throughout as the running example. This process is intentionally simplified and reduced to a request/reply pattern to allow the detailed discussion in this article. However, the introduced concepts are by no means restricted to request/reply patterns at all and support the general case of all possible patterns like one-way messages, broadcast messages or multi-step message exchanges. A “famous” example in business-to-business integration is the “round-trip” exchange of a purchase order (PO) and a purchase order agreement (POA) between two organizations. In this example an organization (sender) extracts a PO from one of its back-end application systems like an enterprise resource management system (ERP), transforms it into the exchange format as agreed upon by the two organizations (for example EDI [19]), and sends it to the other organization (receiver). The receiver (receiving trading partner), once the PO is received, transforms it into the format as required by its ERP and stores it into its ERP. Once the PO is processed within the ERP, a POA is extracted by the receiver and send back to the sending trading partner. Once the sender stores the POA in its ERP the whole process is complete. Figure 1 shows the overall process between the two organizations in more detail.
165
THE APPLICATION OF WORKFLOW TECHNOLOGY
Network
Extract PO
Transform PO
Send PO
Receive PO
PO.amount > 10000
Transform PO
Store PO
PO.amount > 550000
ERP
ERP Approve PO
Store POA
Transform POA
Approve PO
Receive POA
Send POA
Transform POA
Figure 1. PO-POA round-trip inter-organizational process. ◦ Activity, data extraction and storage.
Extract POA
data flow and control flow and
Figure 1 shows that there are process steps that extract and insert documents into the ERPs of the trading partners. In addition, conditional approval steps are shown that indicate that the trading partners have internal business rules for approval amounts. The amounts are different for the two trading partners reflecting different internal business rules. Furthermore, send and receive steps are shown that transmit the documents over the Internet between the two trading partners. Transformation steps are shown that transform the message format used between the trading partners into the format required by the ERPs. Error handling is omitted for brevity of the representation. However, ample of error possibilities are there like lost messages, incorrect message content or duplicate messages that have to be accounted for in the overall process design. Looking at the overall process in figure 1 and being aware of workflow management system technology (WFMS) [28] leads easily to the believe that the process in figure 1 is a distributed inter-organizational workflow (represented as dashed box in figure 2). However, Network
Extract PO
Transform PO
Send PO
Receive PO
PO.amount > 10000
Transform PO
PO.amount > 550000
Approve PO
Store POA
Transform POA
Store PO
Receive POA
Approve PO
Send POA
Figure 2. PO-POA round-trip represented as one workflow. workflow.
◦ Activity,
Transform POA
Extract POA
data flow and control flow and
166
BUSSLER
the reminder of the paper will argue that distributed inter-organizational workflow is an inappropriate approach to B2B integration and will show how WFMSs can be used appropriately. The main criticism is that distributed inter-organizational workflow management requires the involved enterprises to share workflow types as well as workflow instances. Workflow types contain business rules that are considered proprietary and competitive knowledge and therefore enterprises avoid sharing those under all circumstances. Workflow instances show the state of execution revealing resource utilization and constraints. Again, this is often considered competitive knowledge. However, enterprises want to participate in B2B integration. This requires that enterprises must be able to use workflow management system technology in context of B2B integration while being able to conceal what they consider to be competitive knowledge. A solution will be presented that achieves this goal. Section 2 discusses fundamental problems with distributed inter-organizational workflow management. Section 3 introduces a first na¨ıve approach that solves some of the problems introduced in Section 2. Section 4 provides the final approach of how to use WFMSs appropriately in B2B integration. The main contribution of this article is the analysis of the problems related to distributed inter-organizational workflow management and providing a solution by introducing the concepts of public and private processes as well as a binding mechanism between both. 2.
Distributed inter-organizational workflow management
Section 2.1 introduces a definition of distributed workflow management and Section 2.2 introduced distributed inter-organizational workflow management. Based on these definitions, the fundamental problems with inter-organizational workflow management are shown in Section 2.3. 2.1.
Distributed workflow management
WFMSs [4, 15, 20, 21, 24, 26, 38, 42, 44] have an architectural component called a workflow engine. The workflow engine is an interpreter executing workflow instances. As such it provides the workspace in which workflow instances reside. A workflow engine is connected to a database that stores the states of executing workflow instances. If the state of a workflow instance has to be advanced (e.g. due to a finished workflow step), the workflow engine retrieves the state of the workflow instance in question, advances the workflow instance and stores the advanced state of the workflow instance back into the database. At any point in time a workflow instance is either persisted in the database or in state transition in the workflow engine. A workflow instance consists at least of a top level workflow that can contain none, one or several workflow steps [28]. Figure 2 shows a workflow instance that has several workflow steps like “send”, “receive” or “transform”. However, a workflow instance can be structured in a tree hierarchy whereby a workflow step is a workflow in itself that can contain workflow steps. These type of workflow steps are called subworkflows. Workflow steps that are not workflows in themselves are called elementary workflow steps. For example, figure 3 shows
167
THE APPLICATION OF WORKFLOW TECHNOLOGY
Network
Extract PO
Transform PO
Send PO
PO.amount > 10000
Receive PO
Figure 3. flow and
Transform POA
Store PO
PO.amount > 550000
Approve PO
Store POA
Transform PO
Receive POA
Approve PO
Send POA
Transform POA
Redesigned PO-POA round-trip workflow with subworkflows. ◦ Activity, workflow.
Extract POA
data flow and control
a slight redesign of the workflow of figure 2. The workflow steps that connect to the ERPs are collected in a subworkflow. These are also represented as dashed boxes. Since they are contained in another workflow (overall dashed box), they are subworkflows. In this case the workflow instance consists of two subworkflows and additional workflow steps. As figure 3 shows, the control flow starts and ends at the subworkflows, not at the elementary workflows any more. Also, the two elementary steps of the left subworkflow are now connected through a control flow arc since otherwise the execution order would not be defined any more. The database connected to a workflow engine also stores workflow definitions (or workflow types). If a new workflow instance is requested, the workflow engine retrieves the corresponding workflow type from the database, creates a new workflow instance for this workflow type and stores the newly created workflow instance into the database. From then on the workflow instance executes until it is finished. Depending on the particular implementation of a workflow engine it has to repeatedly retrieve the workflow type of a workflow instance to advance the state. Sometimes the workflow instance carries the workflow type information with it avoiding repeated access of the workflow engine for the workflow type. Figure 4 shows the components graphically with two invocation examples of the workflow engine. Distributed workflow management is defined as follows based on the architectural component of a workflow engine. This definition is original since it bases the classification pragmatically on the workflow instances as objects of distribution. This is relevant in the B2B integration context since organizations constitute domains of autonomous control. A workflow instance is distributed if it is in one of the following cases: • Workflow instance migration. A workflow instance can migrate from one workflow engine to another workflow engine, i.e. is stored in two different workflow engine databases at two different points in time. Figure 5(a) illustrates this case by indicating a workflow instance migration between two workflow engines. Workflow instance migration is only possible if
168
BUSSLER
Create Workflow Instance
Finish Workflow Step
Workflow Engine
Workflow Database Workflow Types
Figure 4.
Workflow engine with related database.
Workflow Engine
Workflow Engine
Workflow Database Workflow Types
Workflow Database
Workflow Instances
Workflow Types
Workflow Instances
(a) Figure 5.
Workflow Instances
Workflow Engine
Workflow Engine
Workflow Database Workflow Types
Workflow Database
Workflow Instances
Workflow Types
Workflow Instances
(b)
Distributed workflow management.
the two workflow engines execute workflow instances in exactly the same semantics. This is usually given when the two engines are two installations of the same workflow engine image. However, when these are based on two different implementations, migration is only possible if both workflow engines implement the same workflow instance execution semantics. • Workflow instance distribution. One or more of a workflow instance’s subworkflows reside in a different workflow engine, i.e. two different parts of a workflow instance are stored in two different workflow engine database at the same point in time. Figure 5(b) indicates this case by indicating a workflow instance in the left workflow engine that points to one of its subworkflows that resides in the right workflow engine. The granularity of distribution has to be defined in the case of workflow instance distribution. Figure 5(b) shows the distribution of subworkflows. In addition, it is possible to have elementary workflow steps distributed, too. • Workflow instance replication. A workflow instance is replicated in at least two workflow engine databases at the same point in time. Any change in one workflow engine is automatically, consistently and immediately reflected in all the other workflow engine
169
THE APPLICATION OF WORKFLOW TECHNOLOGY
databases. This case is not further discussed in the following since it does not contribute to the contents of the paper. The unit of distribution in workflow instance distribution is a subworkflow instance. Theoretically it is possible to distribute parts of a workflow instance that is not a subworkflow, but a subset of all steps of a workflow (“step network”). In this case the “master” workflow engine would initiate the initial steps of the remote step network (could be more than one) and would get back the results of the final steps of the network (could be also more than one). This case is not explicitly called out here since its properties are like the workflow instance distribution case where the master engine starts a remote subworkflow and waits for the result to come back. The remote workflow engine must have all the relevant workflow step types available and the master engine does not have to have those. Distributed workflow instance execution requires that the workflow engine that advances the state of a workflow instance has access to the corresponding workflow type. Only then can a workflow engine interpret the workflow instance and execute it according to the workflow type. If the workflow type information is not carried within the workflow instance then each of the workflow engines has to have a consistent copy within its database prior to starting or continuing to execute a workflow instance (in case of migration). With “consistent” is meant that all the workflow type copies in all the workflow engines that might execute the workflow type are the same for the same workflow type. One possibility is that a workflow administrator copies the workflow type manually to all workflow engines. Alternatively, a workflow engine migrating or distributing a workflow instance could find out if the workflow engine has the required workflow types (see 1 in figure 6). If not, 2 in figure 6) before it migrates the workflow instance (see 3 in it could send it (see figure 6). The automatic workflow type migration has the benefit that the workflow engine that is required to execute a workflow instance always receives the correct workflow type definition without any administration overhead and without any manual intervention. If the workflow type is carried within the workflow instance, it must either be fully resolved (i.e. contain the complete definition by resolving all references to data type or subworkflow) or, if it is not fully resolved, the parts of the definition (e.g. data types) have to be available in each workflow engine database as consistent copies. The benefit of this approach is that a workflow engine does not have to find out if the receiving workflow engine
① Check if workflow type exists Workflow Engine
② If not, migrate workflow type
Workflow Engine
③ Migrate workflow instance Workflow Database Workflow Types
Figure 6.
Workflow Instances
Automatic workflow type migration.
Workflow Database Workflow Types
Workflow Instances
170
BUSSLER
has the workflow type available. However, this approach means that workflow instances carry around more data. Furthermore, no late binding of subworkflows is possible any more since the workflow type is fully resolved. Any change in a subworkflow definition will only affect those workflow instances that are newly started. All already running workflow instances already resolved the workflow type and carry a copy of the subworkflow. The relevance of the workflow type discussion is that all workflow engines need access to the workflow type information for being able to advance the state of the workflow instance no matter how the workflow type is made available. In the case of migration the workflow type for the migrated workflow instance needs to be available (figure 5(a)). In the case of workflow distribution only the workflow type for the distributed subworkflows needs to be available, not for the complete workflow. In figure 5(b) that means that the workflow type for the subworkflow needs only be known to the workflow engine that hosts the subworkflow. However, the interface of the subworkflow (i.e. the data it requires and returns) needs to be known to the invoking WFMS. In this case the subworkflow interface is shared between the two workflow engines. 2.2.
Distributed inter-organizational workflow management
Based on the above definition of distributed workflow management it is possible to define distributed inter-organizational workflow management. Distributed inter-organizational workflow instances are those that are distributed and where the different workflow engines are located in different organizations. This implies that workflow instances can migrate from one workflow engine to another workflow engine in another enterprise or that different subworkflows of a workflow instance reside in different workflow engines of different organizations. Figure 7(a) and (b) shows the two cases. 2.3.
Fundamental problems with distributed inter-organizational workflow management
Like in distributed workflow management the inter-organizational workflow instance migration case requires that the workflow definitions are present in all workflow engine databases Network
Workflow Engine
Workflow Engine
Workflow Database Workflow Types
Network
Workflow Database
Workflow Instances
Workflow Types
Workflow Instances
Workflow Engine
Workflow Engine
Workflow Database Workflow Types
(a) Figure 7. Distributed inter-organizational workflow management.
Workflow Database
Workflow Instances
Workflow Types
(b)
Workflow Instances
THE APPLICATION OF WORKFLOW TECHNOLOGY
171
that participate in the execution of workflow instances (figure 7(a)). This means that each involved enterprise can see the complete workflow definition. Especially, it can determine the business rules of all the other enterprises involved in the distributed inter-organizational workflow execution as well as their internal back end application systems. All enterprises consider this information as proprietary and sometimes competitive knowledge since the business rules show (at least to some extend) the business practice. They do not want to share this information with their competitors or even their partners. For example, in an request for quotation process (RFQ) the receiver of the request would be able to see how the quotes will be selected by each of the enterprises that sends request for quotes. Based on this knowledge the receiver could structure future quotes in such a way that the sender’s selection will select his quote. Also, the requester would see how receivers respond to quotes. This would allow a requester to take this into consideration so that the request is structured in such a way that the quote will be very good. Since all enterprises share copies of the workflow types each change of the workflow definition would require that all enterprises involved agree on the changes. All have to make sure that the changes do not introduce problems to their internal back end systems like deadlocks or livelocks, endless loops or endlessly repeating error conditions. This is true also for changes that do not affect the workflow steps directly involved in the sending or receiving of messages since the whole workflow type is copied to all affected enterprises. In the inter-organizational workflow instance distribution case (figure 7(b)) only the interface of the subworkflow is shared, not the whole definition of the subworkflow. However, a tight coupling exists since the invoking workflow engine (“master”) controls the execution of the subworkflow instances (“slave”). This tight coupling means that the organization that executes the subworkflow does not have full control over the subworkflow instance. In course of a more complex interaction pattern between two organizations several subworkflows might have to be invoked. The organization executing the subworkflows has to make sure that each subworkflow is self-contained since no context can be maintained between the subworkflows. This is because subworkflows cease to exist upon termination. In summary, enterprises would be very tightly coupled with a distributed interorganizational workflow management approach. Based on the discussion it becomes clear that enterprises are not willing to participate in these tightly coupled situations. Instead, they prefer to be autonomous within their organization and only tightly coupled for the message exchange itself. This requirement leads to the following na¨ıve approach, namely cooperative inter-organizational workflow management. 3.
Na¨ıve approach: Cooperative inter-organizational workflow management
The cooperative workflow management approach removes the very tight coupling that exists in distributed inter-enterprise workflow management by dividing up the overall workflow. Each enterprise implements one workflow that is local to that enterprise, i.e. not distributed across the enterprises. Each workflow is independently modeled, executed and maintained. The cooperative workflow management does not incur the constraints of distributed workflow management since the workflow engines involved are independent from each other
172
BUSSLER
Network
Extract PO
Transform PO
Send PO
Receive PO
PO.amount > 10000
Transform PO
PO.amount > 550000
Approve PO
Store POA
Transform POA
Store PO
Approve PO
Receive POA
Figure 8. Cooperative workflows. ◦ Activity, passing between enterprises.
Send POA
Transform POA
data flow and control flow,
Extract POA
workflow and
message
because the workflow types are not distributed to each workflow engine. Figure 8 shows the cooperative workflows that are equivalent to the workflow shown in figure 3. Figure 8 shows clearly that the workflow types as well as workflow instances are local to the enterprises. The workflow instances communicate through the send and receive steps with each other. However, business data are communicated, not data about workflow instances, their state or their type. Those steps link the workflow instances with each other resulting in cooperative workflow instances. One implication is that each enterprise can use a WFMS of choice and those WFMSs do not have to be able to execute distributed workflow instances since the cooperative workflows are local and non-distributed workflow instances. Another minor implication is that additional control flow has to be introduced. In the left workflow the step “send PO” and “receive POA” must be ordered through an additional control flow due to the split of the overall workflow. This is the case since the split removes the original control flow dependency given by the right workflow. The right workflow had ordered the two workflow steps before the split. After the split the left side is independent and it must be defined that the receive can only happen after the send. If this control flow would not have been introduced the receive step could start at any time after the left workflow instance is created. (This is a similar situation to the introduction of subworkflows before. In that case control flow had to be introduced, too, since the subworkflow isolates the control flow.) The only data structure shared between the enterprises are the messages passed between the enterprises. That means that the enterprises only have to agree on the message formats, but not on the local and internal workflow types. In addition, the message sequencing needs to be agreed upon so that for each message sent by one enterprise there is a receiving step within the other enterprise. The local workflows have to make sure that they implement the same message sequences so that the collaborative workflows never get into a situation where a message is sent but there is no corresponding receiving step or if a receiving steps waits but there is not corresponding sending step. This approach is attributed as na¨ıve because of the following remaining problems.
THE APPLICATION OF WORKFLOW TECHNOLOGY
3.1.
173
Message exchange implementation
The message send and message receive sequencing for a given message exchange is encoded in the workflow itself. Each workflow that is developed needs to implement the message sequencing. If several workflow types use the same sequencing they have to implement the sequencing repeatedly. Any change in the sequencing would cause a re-design of all workflow types that implement that sequencing. An attempt to address this situation would be to encapsulate the message sequencing in a subworkflow that is reused whenever a workflow type requires it. However, this approach does not work due to the subworkflow execution semantics. This requires some more detailed explanation in the following. Once a subworkflow is started, it executes its internal steps until it is done. Only when the subworkflow comes to an end, it returns control to the superworkflow. Let’s assume that the “receive PO” and “send POA” workflow steps on the right side in figure 8 would be together in one subworkflow. There would be a control flow from “receive PO” to “send POA” in order to define that first the receive has to take place and then the send. If this subworkflow would be started, it would first receive the PO and then try to send the POA. After that it would return control to the superworkflow. However, after the “receive PO” control has to be given back to the superworkflow in order to pass on the PO to the “transform PO” step. Since the subworkflow cannot return control at this point because there are more steps to execute, the subworkflow would not work. Instead, the “receive PO” and the “send POA” have to remain two individual steps. Even in this very simple example the use of subworkflows is inadequate to implement the message exchange implementation. The fundamental underlying problem is that subworkflows cannot return control without being finished at the same time. The execution control is strictly tight to the successful execution like in method invocation in programming languages. However, the complementary message exchange could be implemented by a subworkflow. In this case the “send PO” would be executed before the “receive POA”. This approach works since there is no control to be given back to the superworkflow. However, since subworkflows cannot model all message exchanges, but only specific cases, subworkflows are inappropriate to define message exchanges. 3.2.
Message transformation
The transformation is performed within each workflow type. The transformation happens because back end applications usually require a format different from the one used for the messages. Figure 9 shows that if an EDI message must be sent to an SAP back end application then a transformation between the two formats must take place. If the same message needs to be sent to different back end applications then two or more transformations need to be performed conditionally within a workflow type depending to which back end application the messages go. This is shown in figure 9 by the “target” workflow step that determines the specific back end application and subsequently causes a different transformation to happen. This means that with a growing number of back end applications the number of transformations is increasing in the workflow itself. Each time a back end system is modified or added, all workflow types that connect to the back end system have to be revisited and their
174
BUSSLER
Network Receive EDI PO
Target SAP
Transform EDI to SAP PO
Transform Oracle EDI to Oracle PO
Store SAP PO
SAP PO.amount
>= 55000 AND TP1 OR >= 40000 AND TP2 Approve PO
EDI Transform SAP to EDI POA
Send EDI POA
Target
Extract SAP POA
RN
Transform SAP to RN POA
Transform RN to SAP PO
Receive RN PO
SAP
Target
Transform RN to Oracle PO
Store Oracle PO
Oracle PO.amount
Oracle >= 55000 AND TP1 OR >= 40000 AND TP2 Approve PO EDI
Send RN POA
Transform Oracle to EDI POA
Target RN
Extract Oracle POA
Transform Oracle to RN POA
Figure 9.
Workflow type for two message exchanges, two trading partners and two back end applications.
transformations potentially changed (see example in figure 10 where one trading partner is added). It is important to note here that defining transformations pose a significant manual task. Due to the semantic differences in formats and contents transformations require a domain expert familiar with the business data content to define the transformation. Related to the issue of message transformation is the business rule format discussion. The business rules usually need to access the business data to make a decision (like accessing “PO.amount” in figure 8). If different data formats are required for different trading partners or different back end applications then the same business rule needs to be implemented several times taking the specific formats into consideration. In figure 9 this is visible since one business rule operates on the SAP format whereas the other operates on the Oracle format. Any additional format due to a new back end application or trading partner requires to revisit all workflow types to accommodate the change. 3.3.
Business rules
Business rules are encoded in the workflow types. An example is the conditional approval based on the purchase order amount. The business rules might depend on the trading partner
175
THE APPLICATION OF WORKFLOW TECHNOLOGY
Receive EDI PO
Transform EDI to SAP PO
Target SAP
Transform Oracle EDI to Oracle PO
SAP PO.amount
Store SAP PO
>= 55000 AND TP1 OR >= 40000 AND TP2 OR >= 10000 AND TP3 Approve PO
EDI Send EDI POA
Transform SAP to EDI POA RN
Target
Extract SAP POA
OAGIS Transform SAP to RN POA Transform SAP to OAGIS POA Receive RN PO
Transform RN to SAP PO
Transform RN to Oracle PO
SAP
Target
Oracle PO.amount
Store Oracle PO
Oracle >= 55000 AND TP1 OR >= 40000 AND TP2 OR >= 10000 AND TP3 Approve PO EDI
Send RN POA
Transform Oracle to EDI POA
Target RN
Extract Oracle POA
OAGIS Transform Oracle to RN POA Transform Oracle to OAGIS POA Transform RN to SAP PO
Receive OAGIS PO
SAP
Target
Transform RN to Oracle PO
Oracle
Send OAGIS POA
Figure 10.
Workflow type for two message exchanges, three trading partners and two back end applications.
the message is coming from or going to. Figure 9 shows that the amount on which the approval depends is different for different trading partners since the trading partner name is contained in the conditional expression. This means that either there must be a conditional branch depending on trading partner in order to implement the different business rules (as
176
BUSSLER
done in figure 9) or there must be a different workflow type per trading partner. In the former case this means that every time a trading partner is added, changed or removed all the workflow types have to be revisited in order to determine if a change is required. In the latter case this means that for each new trading partner or back end application a new workflow type has to be defined. Since the workflow logic is the same, but the business rules are different, the workflow types look alike very much in their structure. Any structural change would have to be applied to all workflow types at the same time being a significant scalability issue. It would be possible to collect all business rules in a subworkflow. This would remove the business rules from the main workflow and changes would be localized in the subworkflow. While this achieves that business rules are localized, the subworkflow still would change every time a trading partner is added or removed or the business rules are changed. The main workflow would have to bind to a new version of the subworkflow every time a change occurs. Figure 9 shows the right side of figure 8 in more detail for two message exchange protocols (EDI [19] and RosettaNet (RN) [40]), business rules for two trading partner TP1 and TP2 and two back end applications Oracle [37] and SAP [41]. The boxes around the message exchange sequences and the back end applications are drawn to provide clarity; they are not indicating subworkflows (indicated by dashed lines, see above). Figure 9 shows the complications due to several B2B protocols and several trading partner specific business rules. A first distinction has to be made if an incoming PO is for “SAP” or “Oracle”. Depending on this decision the corresponding transformation is invoked. After that, once the document format for the back end application is generated by the transformation, the trading partner specific business rules can be executed. POs from “trading partner 1” need to be approved if the amount exceeds “55000” and those from “trading partner 2” have to be approved if the amount exceeds “40000”. Returning the POAs does not involve any business rules and only the appropriate transformation decision has to be made. Figure 10 shows the additional complexity if just one more B2B protocol is added for one more trading partner. The workflow type has to be changed significantly to incorporate the additional protocol as well as business rule. In summary, trying to model the complete integration in a workflow is possible. But to achieve consistency and scale the development as well as the maintenance is very difficult and resource consuming. The reason is that in the worst case all combinations of trading partner, message exchange protocol and back end application integration have to be explicitly modeled in every workflow type resulting in a large set of redundant development. The complexity of the workflow types increases dramatically every time a back end system or a trading partner is added. To address all these issues it would be best if the following concepts would be realized. • The message exchange protocols is modeled independently of the workflow itself. This allows for changes in either, the workflow and the message exchanges without affecting each other. Furthermore, the workflow would be able to connect to several message exchanges without having to accommodate them individually.
THE APPLICATION OF WORKFLOW TECHNOLOGY
177
• The required transformations take place before the workflow starts so that the workflow can operate on one format and hence is not concerned with transformation any more. This ensures that the workflow operates on the same format no matter what format a message exchange requires. • The business rules are defined and executed independently of the workflow so that any change caused by adding or removing trading partner or back end applications is isolated from the workflow. The next section introduces a model that implements these concepts and therefore avoids all the problems of the na¨ıve approach. 4.
Advanced approach: Public and private process management
In order to provide isolation between the message exchange protocol and the business logic the concepts of a private process and a public process are introduced [9]. Public processes describe the message exchange behavior between enterprises whereas private processes describe the message exchange behavior within enterprises. The concept of a binding is introduced in order to bind a public process to a private process. 4.1.
Public process
4.1.1. Concept. A public process defines an organization-external message exchange sequence. A public process is a set of process steps that are connected by control flow in order to define the step execution sequence (very much like a workflow). The basic control flow constructs are available like sequence, conditional branch, loop or parallelism. Public process steps either send or receive messages from and to trading partners, or send or receive messages from and to bindings (binding connect public processes to private processes, see below). Steps that send or receive messages from bindings are called “connection steps”. Connection steps serve two purposes. First, they pass messages to or receive messages from bindings. Second, they pass control to bindings or wait for control from bindings. A connection step that passes execution control to a binding does this in two directions (like a parallel branch), one continuing the public process execution and the other one to the binding for the binding to execute. Through this behavior the public process continues execution in parallel to the binding. Connection steps that wait for control from a binding also wait for control from previous steps in public processes. This is like a parallel join. This allows a public process to wait for a message from a binding before continuing. Public processes might look very different for different B2B protocols. Some implement time-out behavior, others do not. Some require the handling of acknowledgments, others do not. However, since public processes can be dynamically modeled any particular prescription by B2B protocols can be implemented. The public processes implement the document formats as required by the B2B protocols they implement. Examples are EDI [19], RosettaNet [40] or OAGIS [36].
178
BUSSLER
Public Process Receive EDI PO
From / to binding
Send EDI POA
Receive RN PO
From / to binding
Send RN POA
Figure 11.
Public processes.
Connection activity.
4.1.2. Example. Throughout Section 4 a complete example will be developed that shows an application of the introduced concepts. Figure 11 shows the public processes corresponding to figure 9 graphically. The first public process deals with messages in EDI format, the second public process deals with messages in RosettaNet format. In the first public the first step receives a purchase order from a trading partner. The second step is a connection step that will pass control to the binding as well as the message itself. It also passes control to the next step that is another connection step. This connection step waits for control from the binding in order to continue. It also will receive the return message that is sent out to a trading partner by the fourth and last step. 4.2.
Binding and normalized document format
4.2.1. Concept. A binding is a process that connects public processes on the one side and private processes on the other side. Since a binding is a process by itself, its definition contains process steps. These steps are connected by control flow like those in public processes. Steps can receive and send message to and from public processes as well as private processes. These steps are connected to connection steps in either public processes or private processes. This way message are transferred between public to private processes and vice versa. In addition, steps can execute document format transformations. A transformation either transforms a public process specific format in the normalized format as required by the private process or transforms the normalized format from the private processes in the specific
179
THE APPLICATION OF WORKFLOW TECHNOLOGY
one of the public process. As discussed above, the normalized format has the benefit that the private process does not have to be aware of all the different format as required by public processes (as well as back end applications). The binding is therefore the ideal location for transformations since it allows the public processes to completely operate on public process specific formats and private processes can completely operate on the normalized format. Furthermore, steps can consume messages or produce messages. This allows to take a message from a public process and not pass it on to the private process if not required by it. In contrast, if a public process needs a message that is not supplied by the private process, but can be created, the binding can create it. This allows to compensate for differences in public processes and private processes. 4.2.2. Example. Figure 12 shows two bindings, one for each public process. Each binding contains a transformation for each of the document formats involved. The transformation steps are connected to connection steps in order to transfer execution control as well as the messages. Figure 12 shows that the binding takes the specific format from the public process and transforms it to the normalized format before sending it to the private process. Conversely, it takes the normalized format from the private process and transforms it into the specific format as required by the public process. In that sense the binding provides an abstraction from the particular formats as used in the public process.
Public Process Receive EDI PO
Binding
Transform to normalized PO From / to private process Transform to EDI POA
Send EDI POA
Receive RN PO
Transform to normalized PO From / to private process Transform to RN POA
Send RN POA
Figure 12.
Bindings with transformation.
180 4.3.
BUSSLER
Business rules
4.3.1. Concept. Business rules implement domain specific behavior inside the private process. Through conditional expressions a specific context can be established. For example, the purchase order of a trading partner is larger than a specific amount. Depending on this context different branches in the private process are executed to specialize behavior for the specific context. For example, in case the purchase order is larger than a specific amount then an approval has to take place. Business rules are trading partner specific since different conditions apply to different trading partners. This means that business rules can be different for different trading partners. If a private process requires business rules then they have to be defined for each trading partner that can participate in the private process. Business rules address the domain semantics of the private process, i.e. the business logic that needs to be defined. A business rule is a concept that is independent of a private process. Definitions of business rules are outside and independent of private processes. However, they are bound to private processes by specific “binding steps” in order to determine the context as well as cause the specific behavior of the business process based on their result. The independence makes sure that changes in the trading partner population do not affect the definition of private processes but are independent of it. At runtime the generic workflow step will provide data to the externally specified business rules. The data given to business rules usually includes source (trading partner or application), target (trading partner or application) as well as the message itself. However, if a business rule does not need all of those only the required once have to be passed to it. The appropriate business rule is selected based on these data, executed and the result is returned to the generic workflow step. The language available to define business rules depends on the workflow management system that executes the private processes. If a workflow management system provides a complete language that can express arbitrary complex business rules independent of workflows, it should be used. If a workflow management system does not provide a complete language, then a ordinary programming language like Java must be used. In this case the workflow management system has to provide a mechanism by which programs can be linked to the workflow types. 4.3.2. Example. Figure 13 shows the generic workflow step “check need for approval” that determines if authorization has to take place. It will pass source, target and document to the business rules. Once the appropriate business rule is executed the result is returned to the generic workflow step. The result is of type Boolean. Based on the result either the “approve PO” workflow step takes place or it is skipped. It can be clearly seen that the workflow step implementation (i.e. business rule invocation) does the evaluation in contrast to a conditional expression in the workflow type itself. The implementation takes the specific source and target as well as the purchase order as input parameter and returns a Boolean that indicates if an authorization is required. This means that instead of determining the target as shown in figure 9 as a workflow step and subsequently determining if an authorization is required by a conditional branch in the workflow itself, the business rule implementation
181
THE APPLICATION OF WORKFLOW TECHNOLOGY
Public Process Receive EDI PO
Binding
Private Process
Transform to normalized PO
Check need for approval false true
Transform to EDI POA
Approve PO
Send EDI POA
Receive RN PO
Transform to normalized PO
Transform to RN POA Send RN POA
Figure 13.
Business rule independent workflow.
will do both and returns the result. Through this approach the workflow is trading partner independent since it does not refer to any trading partner or amount. The business rules look like this: check-need-for-approval(IN source, IN target, IN document, OUT result) begin /* business rule 1 * / if target == SAP and source == TP1 then if document.amount >= 55000 then result := true; else result := false; end-if; end-if; /* business rule 2 * / if target == SAP and source == TP2 then if document.amount >= 40000 then result := true; else result := false; end-if; end-if;
182
BUSSLER
/* business rule 3 * / if target == Oracle and source == TP1 then if document.amount >= 55000 then result := true; else result := false; end-if; end-if; /* business rule 4 * / if target == Oracle and source == TP2 then if document.amount >= 40000 then result := true; else result := false; end-if; end-if; /* if none of the business rules apply, error case * / result := error; end; The workflow step “check need for approval” calls the function “check need for approval” that contains all the business rules and branches depending on the result. The workflow step supplies the “IN” parameters and reads the “OUT” parameter. (The business rule is only implemented for the two initial trading partners). As can be seen, changes in the business rules are local to the function “check need for approval” and are invisible to the generic workflow step or the private process. The error cases are not considered in figure 13. This would require a third branch leaving “check need for approval” that would deal with the error case. 4.4.
Private process
4.4.1. Concept. Private processes are processes that implement the domain specific business logic of an organization. Private processes are implemented by workflow types and are executed as workflow instances. This is the appropriate and adequate use of workflow technology that avoids the problems as discussed in Section 3. All workflow modeling concepts are available that a workflow management system supports. The workflow modeler is free to use all the modeling concepts like workflow steps, subworkflows, control flow, data flow as required by the business logic. Connection steps are available as modeling constructs in order to connect to bindings. They are the explicit entry and exit points from private processes to bindings. Private processes operate on the normalized document format as provided by the binding. This means that the business rules do not have to take specific public process formats into consideration at all.
183
THE APPLICATION OF WORKFLOW TECHNOLOGY
Public Process Receive EDI PO
Binding
Private Process
Binding
Transform to normalized PO
Check need for approval false
Transform to SAP PO
Application Process
Store SAP PO
true Transform to EDI POA
Approve PO
Transform to normalized POA
Send EDI POA
Receive RN PO
Transform to normalized PO
Transform to Oracle PO
Transform to RN POA
Transform to normalized POA
Send RN POA
Figure 14.
Extract SAP POA
Store Oracle PO
Extract Oracle POA
Back end application binding.
4.4.2. Example. The workflow shown in figure 13 implements the private process. The connection to the back end applications follow the same approach as the public protocols and bindings. Each back end application has its own protocol that is bound to the workflow through a binding and connection steps. This is shown in figure 14. Figure 14 shows the definition of an overall integration with two public processes and two back end applications. At runtime, messages come in through either one of the public processes, not through both at the same time. Depending on which public process they are coming in the appropriate binding is selected. At runtime, one of the paths is taken whereas at define time all paths have to be defined. Figure 15 shows the situation for three trading partners instead of two. As can be seen, the private workflow is not affected at all by an additional trading partner using another, not yet implemented protocol. The workflow type does not have to be changed at all. The only change in addition to another binding is the business rule that has to provide the logic for one more trading partner. In summary, it is shown how all the problems discussed in Sections 2 and 3 can be addressed by the concepts in Section 4. Workflow management is used to implement the business logic independent of the particular public processes or back end application systems. The concept of the binding of public and private processes (and private and application specific processes) allows to abstract from behavior as well as document format. Evaluating business rules outside the workflows themselves assures that workflows are trading partner independent. The important aspects are that • the private process is independent of the particular public process behavior and the particular document format of the B2B protocol
184
BUSSLER Public Process Receive EDI PO
Binding
Private Process
Binding
Transform to normalized PO
Check need for approval false
Transform to SAP PO
Application Process
Store SAP PO
true Transform to EDI POA
Approve PO
Transform to normalized POA
Send EDI POA
Receive RN PO
Transform to normalized PO
Transform to Oracle PO
Transform to RN POA
Transform to normalized POA
Send RN POA
Receive OAGIS PO
Extract SAP POA
Store Oracle PO
Extract Oracle POA
Transform to normalized PO
Transform to OAGIS POA Send OAGIS POA
Figure 15.
Private process for three trading partners.
• the private process definition and the private process execution state cannot be seen from the outside of the enterprise • business rules are encoded outside the private process so that it does not depend on specific trading partner rules any more. This means that the goal of separating the internal behavior (private processes) from the external behavior (public processes) is achieved. 4.5.
Change management
The advanced approach with public and private processes provides clear abstractions on different levels. The public behavior (public process) is clearly separated from the private behavior (private process). Bindings tie both together and bridge the different abstractions. At the same time the public document formats are clearly abstracted from the private document formats whereby the binding provides the necessary transformations.
THE APPLICATION OF WORKFLOW TECHNOLOGY
185
An important topic is change management. In the ideal case, changes are local to either public processes, private processes or bindings. However, since all these three concepts are related, some changes have impact beyond local change. Local changes are discussed first, then non-local changes. Local changes are those that do not affect the connection steps or the documents exchanged between public processes, private processes or bindings. For example, the addition of an audit step in the outgoing processing of a POA in the private process is such a case. Only the private process would have an additional step, but this would not affect any binding. Another example is if a public process has to explicitly model transport acknowledgments. After receiving a message an acknowledgment is sent back to the sender or after sending a message an acknowledgment has to be received. Again, this does not affect the binding because the acknowledgments are not passed on to the private process. Non-local changes are those that go beyond changing only one of private processes, public processes or bindings. For example, if the document format of the private process changes to contain one more field, the transformation in the binding has to take care of this additional field. In the worst case the document format of the public process has to be changed, too. In this case all objects are affected by the change. While it appears to be a high impact that one single more field causes all model elements (like private and public processes, bindings, transformation) to change, it cannot be avoided. However, at the same time, in real deployment situations these changes do not happen every day by far. B2B protocols that define public processes are standardized (e.g. by RosettaNet) or negotiated between two trading partners. In case of standards, changes occur infrequently. Changes usually cause a ripple effect throughout all trading partners that implement a standard. A standards organization is usually very careful in avoiding frequent changes. In case of two trading partners negotiating their public processes changes are infrequent, too, once the public processes are in production. Each change disrupts business operations and corporations are very careful in allowing changes to happen frequently. While the matter of the fact requires non-local changes, the change frequency in real deployments is extremely low so that change management is not impeding scalability or flexibility. 4.6.
Scalability
The different abstractions provided by public processes, private processes, transformations, binding and business rules provide substantial scalability. In order to add a new B2B protocol standards, the public processes for that standard have to be modeled as well as the binding steps to bind them to the relevant private processes. Adding a new trading partner only requires to add business rules if there are trading partner specific business rules in the first place. If there are no trading partner specific business rules, adding a new trading partner does not require any change in the model. This assumes that the new trading partner complies to an already implemented B2B protocol and the necessary public processes are modeled. Otherwise, a new B2B protocol has to be added together with the new trading partner.
186
BUSSLER
Adding new back end application system is analogous to adding a new B2B protocol standard. The application processes have to be added as well as the corresponding binding steps to the private processes. Adding a new private process requires more work. First, the bindings to the existing B2B protocols have to be added but also the business rules have to be implemented for the private process (if business rules are required). It is significant that adding new B2B protocols, new back end application systems or new trading partners are local changes. The private process is not affected at all by any of these changes. In case of a new B2B protocol the applications are not affected and vice versa. In case of a new trading partner only business rules are affected, if at all. Adding a new private process does not change the public or application processes. The locality of change shows that the abstractions are very appropriate and enable excellent scalability. 5. 5.1.
Related work Standards
One standards addressing public processes is RosettaNet [40]. RosettaNet pre-defines domain specific public processes called Partner Interface Processes (PIPs). One example of a PIP is called 3A4. PIP 3A4 defines the exchange of a “create purchase order” message and a subsequent “purchase order acceptance” message between two organizations. Each organization plays a role, in 3A4 these are buyer and seller. 3A4 defines that the “create purchase order” message originates at the buyer and is sent to the seller. The seller receives the “create purchase order,” processes it and returns a “purchase order acceptance” message to the buyer. The buyer determines if the interaction was a success or failure based on the message content. This whole interaction is represented as a state graph with two types of nodes. One type of node is the sending of messages. The other type of node indicates the creation or processing of the message. Each node either belongs to the seller or to the buyer. The processing of the messages are not defined at all in PIPs. The processing states are only placeholders for concrete implementations of the processing. In addition, RosettaNet defines a lower level message exchange protocol called RNIF (RosettaNet Implementation Framework). RNIF provides a specification how messages are exchanged reliably over the Internet using techniques like message level acknowledgments, time-outs and sending retries. RNIF provides an abstraction layer for PIPs since PIPs assume the reliable message transmission and are not concerned about low level acknowledgments. PIPs assume a reliable message exchange layer and this is provided by RNIF. RNIF is not discussed further here since it is not relevant for the presented work. Two enterprises can inter-operate by virtue of being RosettaNet compliant. This requires that both enterprises have to implement RNIF as well as the PIPs as defined by RosettaNet. The enterprises do not have to negotiate how PIPs look like since these are defined by RosettaNet. The separation of public and private processes as well as their binding is not subject of the standard specification at all. RosettaNet completely focuses on public processes and their domain specific definition like purchase order exchange or
THE APPLICATION OF WORKFLOW TECHNOLOGY
187
shipment notices. A framework like the one presented must be available to deploy RosettaNet in a concrete integration scenario in order to provide the private process definition and execution. Another standard in this space is ebXML [16]. In contrast to RosettaNet ebXML does not predefine domain specific public processes. Instead, ebXML provides a general language (ebXML BPSS, business process specification schema) to define arbitrary public processes called collaborations. Therefore, in the case of ebXML two enterprises have to agree on a definition of their public processes first before they can exchange messages. This means on one hand side that enterprises have a lot more design work to do in order to establish and agree on their public processes. On the other hand side this is a benefit since the enterprises can model specific requirements into their public processes that would not be possible in case of RosettaNet. One example is that an enterprise might acknowledge a purchase order not in one purchase order acknowledgment message but in several acknowledging line items separately. Like RosettaNet ebXML specifies a lower level message exchange framework to guarantee reliable messages exchanges (called ebXML message service specification). EbXML (like RosettaNet) focuses on public processes and any implementation requires a framework like the one presented in order to implement private processes. Standards like EDI [19] are neither defining public processes nor providing a mechanism to define public processes. In this case enterprises need to borrow the mechanism from e.g. ebXML to define public processes. This means that a framework as described must be in place in order to define public and private processes in context of EDI (an similar standards that are only concerned about document definitions). WSFL [51] is concerned about a flow language describing web services composition. The same is true for XLANG [52] and BPML [6]. None of these proposals is concerned about the definition of public processes as reusable specifications. The standard proposals do not address the binding of public and private processes. Furthermore, they assume an underlying infrastructure like a basic message exchange functionality over networks. In that respect these are isolated elements of an overall framework for B2B protocols like the one proposed by RosettaNet or ebXML. 5.2.
Research
Leymann [33] shows an elaborate mechanism to invoke and to compose web services as workflow types. The examples shown use “simple” web services that consist of a single request/reply pattern. More complex web services that require a series of ordered invocations to the same web service are not discussed. In addition, the separation of public and private processes is not addressed. The reuse of private processes across public processes is not addressed. Crossflow [23, 25] is concerned about a methodology to establish and to maintain contracts between enterprises. Furthermore, a system is proposed to enforce the contracts. However, the system is not built do deal with arbitrary public processes and no standard definition language and semantics is provided for the enforcement of contracts between two enterprises. All enterprises involved are required to use the same software for contract enforcement. Ludwig and Hoffner [34] describes a framework for integrating enterprises.
188
BUSSLER
The notion of an integration facilitator is introduced. However, no model of private and public processes is introduced. The functionality of the integration facilitator is described on a coarse-grained functional level. In [1] an approach is presented whereby the private process inherits from the public process through workflow inheritance [7]. The inheritance makes sure that all steps of the public process are available in the private process. The private process can extend the public process with internal workflow steps. The problems with this approach are the same to those discussed in Section 3. This is the case because the private process contains the message exchange logic from the public process. In [1] this is achieved by inheritance whereby in Section 3 this was designed into the workflow without inheritance. No matter how the public process comes into the private process, the fact is that the private process contains the public process. Therefore all problems listed in Section 3 apply. Chiu et al. [14] recognize the fact that not all workflow steps of a private process should be visible to the outside world. The approach taken is that of workflow views. A workflow view is a subset of a workflow definition like a database view is a subset of the rows of a table. A workflow view only selects workflow steps, not any control flow or data flow specification. Since a workflow view selects specific workflow steps of a workflow to make them visible to other enterprises, control flow between the workflow steps in the view has to be defined in the workflow view. Like [1] the workflow view and the workflow itself are not independent (in [1] the workflow view corresponds to the public workflow from which the private workflow inherits). All the problems listed in Section 3 apply here also. The reason is that the workflow view is derived from the workflow itself. In addition [14] does not describe at all how the exchange of messages between enterprises take place, i.e. the logic the public processes have to follow. Kafeza et al. [29] introduce the notion of E-Contracts as additional concepts to those described in [14]. E-Contracts are two related workflow views whereby steps from each view are related to the other view indicating the messages sent back and forth. However, the introduction of E-Contracts does not resolve the issues as described in Section 3. Still, the workflow views that are necessary for the E-Contract definition are derived from workflows. Georgakopoulos et al. [22] describe concepts to integrate services into workflows by specific activities called service activities. If a service provider is remote to the workflow under execution, the corresponding service activity initiates the remote invocation and waits until the service invocation finished. Once the remote service invocation finished, the service activity finishes and the workflow continues its execution. This model requires that service activities must bridge the heterogeneity between the workflow and the remote service individually. For example, data type casts are necessary in case of data type mismatches. The approach taken by [22] is equivalent to the cooperative workflow approach discussed earlier. Workflow steps directly communicate with remote partners and no abstraction in terms of public or private processes are provided. Chen and Hsu [13] describe collaborative processes based on the notion of a logical process that is common amongst two trading partners. Each trading partner implements part of the logical process. This ensures that at runtime both trading partners collaborate exactly as defined and send the appropriate messages to each other at the correct state in the overall logical process. Chen and Hsu [13] confirms that some parts of a trading partner’s
THE APPLICATION OF WORKFLOW TECHNOLOGY
189
process should be invisible to the other trading partner. The way this is achieved is that specific steps in the overall logical process can be locally refined by subworkflows. The details of a step in the logical process can be undefined. Once deployed at a trading partner the step can be refined by adding subworkflows to it. This approach has the problem that the structure of the process is determined by the overall logical process. A trading partner cannot change the structure locally even for those parts that are irrelevant for the collaboration. For example, if the logical process defines one step that can be locally refined, the trading partner cannot define two in its place. Any change required by a trading partner’s private process logic causes the overall logical process to change. This is a fundamental drawback of the proposed approach. Furthermore, it is not possible to bind several different B2B protocols to the same private subworkflows. For each B2B protocol a separate overall logical process has to be defined. This results in duplication of the local implementations. Banerji et al. [3] and Kuno et al. [32] present a model of a web services conversation language (WSCL) that is contrasted to WSDL. In contrast to WSDL, WSCL is concerned about multiple related interactions. WSCL is therefore an attempt to define public processes. However, it is not defined how WSCL defined public processes are bound to private processes and how the binding is achieved (although it is mentioned that this is required functionality). Kuno and Lemon [31] discusses the implementation of a controller for executing WSCL specifications. Casati and Shan [11] and Casati et al. [12] describe a language and execution architecture for composite services. Not only can services be defined and composed, but also dynamically selected. Furthermore, composite services can be dynamically changed to adapt to changes in the service provider. The described approach focuses on composite services only and does not take private processes or the binding to them into consideration. Furthermore, only synchronous invocations are addressed. Asynchronous message exchanges are not discussed in [11, 12]. Krithivasan and Helal [30] describe a series of operations between enterprises to invoke services as well as inquire their state and transactional behavior. However, no formalism or language is presented of how to describe public processes and how these are bound to private processes. 5.3.
Systems
Products of vendors like [5, 27, 35, 39, 43, 46–48] support inter-enterprise message exchange following specific selected standards. However, it is impossible to derive from the data made available by the vendors how the internal implementation would support the approach proposed in this paper. References 1. W.M.P. van der Aalst, and M. Weske, “The P2P approach to interorganizational workflows,” in Proceedings of the 13th International Conference on Advanced Information Systems Engineering (CAiSE’01), vol. 2068 of Lecture Notes in Computer Science, Springer-Verlag, Berlin, 2001. 2. Action Technologies, www.actiontech.com.
190
BUSSLER
3. A. Banerji, C. Bartolini, D. Beringer, V. Chopella, K. Govindarajan, A. Karp, H. Kuno, M. Lemon, G. Pogossiants, S. Sharma, and S. Williams, Web Services Conversation Language (WSCL) 1.0. Hewlett-Packard, May 2001. 4. BEA Process Integrator, www.bea.com/products/weblogic/integrator/index.shtml. 5. BEA Weblogic Integration, www.bea.com/products/weblogic/integration/index.shtml. 6. BPML, www.bpmi.org. 7. C. Bussler, “Workflow class inheritance and dynamic workflow class binding,” in Proceedings of the Workshop Software Architectures for Business Process Management at the 11th Conference on Advanced Information Systems Engineering CAiSE*99, Heidelberg, Germany, June 1999. 8. C. Bussler, “B2B protocol standards and their role in semantic B2B integration engines,” Bulletin of the Technical Committee on Data Engineering, vol. 24, no. 1, 2001. 9. C. Bussler, “The role of B2B protocols in inter-enterprise process execution,” in Proceedings of the Workshop on Technologies for E-Services (TES 2001), Rome, Italy, September 2001. 10. F. Casati, U. Dayal, and M.-C. Shan, “E-Business applications for supply chain management: Challenges and solutions,” in Proceedings of the 17th International Conference on Data Engineering, Heidelberg, Germany, IEEE Computer Society, April 2–6, 2001. 11. F. Casati and M.-C. Shan, “Dynamic and adaptive composition of e-services,” Journal of Information Systems, vol. 26, 2001. 12. F. Casati, M. Sayal, and M.-C. Shan, “Developing e-services for composing e-services,” in Proceedings of The 13th Conference on Advanced Information Systems Engineering (CAISE’2001), Interlaken, Switzerland, June 2001. 13. Q. Chen and M. Hsu, “Inter-enterprise collaborative business process management,” Technical Report HPL2000-107, HP Laboratories, Palo Alto, August 2000. 14. D.K.W. Chiu, K. Karlapalem, and Q. Li, “Views for inter-organization workflow in an e-commerce environment,” in Proceedings of the 9th IFIP 2.6 Working Conference on Database Semantics (DS-9) Semantic Issues in e-Commerce Systems, Hong Kong, April 2001. 15. COSA workflow, www.ley.de/-englisch/cosa/index.htm. 16. ebXML, www.ebxml.org. 17. ebXML, “Business Process Specification Schema,” Version 1.01. May 2001, www.ebxml.org. 18. ebXML, “Collaboration-Protocol Profile and Agreement Specification,” Version 1.0. May 2001, www.ebxml.org. 19. EDI, www.x12.org. 20. Foro, www.foro-wf.com/web/default.html. 21. Fujitsu I-Flow, www.i-flow.com/. 22. D. Georgakopoulos, A. Cichocki, H. Schuster, and D. Baker, “Process-based e-service integration,” in Proceedings of the Workshop on Technologies for E-Services (TES 2000), Cairo, Egypt, September 2000. 23. 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, vol. 15, no. 5, 2000. 24. Hewlett-Packard Process Manager, www.ice.hp.com/cyc/af/00/. 25. Y. Hoffner, S. Field, P. Grefen, and H. Ludwig, “Contract-driven creation and operation of virtual enterprises,” Research Report, RZ 3328, #93374, Computer Science, IBM Research, February 2001. 26. IBM MQ Series Workflow, www-4.ibm.com/software/ts/mqseries/. 27. IONA Netfish XDI, www.iona.com/products/. 28. S. Jablonski and C. Bussler, Workflow Management. Concepts, Architecture and Implementation, International Thomson Publisher, 1995. 29. E. Kafeza, D.K.W. Chiu, and I. Kafeza, “View-based contracts in an e-service cross-organizational workflow environment,” in Proceedings of the Workshop on Technologies for E-Services (TES 2001), Rome, Italy, September 2001. 30. R. Krithivasan and A. Helal, “BizBuilder—An e-services framework targeted for internet workflow,” in Proceedings of the Workshop on Technologies for E-Services (TES 2001), Rome, Italy, September 2001.
THE APPLICATION OF WORKFLOW TECHNOLOGY
191
31. H. Kuno and M. Lemon, “A lightweight dynamic conversation controller for e-services,” in Proceedings of the Third International Workshop on Advanced issues of E-Commerce and Web-Based Information Systems (WECWIS 2001), Milpitas, California, USA, June 2001. 32. H. Kuno, M. Lemon, A. Karp, and D. Beringer, “Coversations + interfaces = business logic,” in Proceedings of the Workshop on Technologies for E-Services (TES 2001), Rome, Italy, September 2001. 33. F. Leymann, “Managing business processes via workflow technology,” in Proceedings of the 27th International Conference on Very Large Data Bases (VLDB 2001), Roma, Italy, September 2001. 34. H. Ludwig and Y. Hoffner, “CRAFT: A framework for integration facilitation in cross-organizational distributed systems,” Research Report, RZ 3286, #93332, Computer Science, IBM Research, November 2000. 35. Microsoft Biztalk Server, www.microsoft.com/biztalkserver. 36. OAGIS, www.openapplications.org/. 37. Oracle eBusinessSuite, www.oracle.com/applications/index.html?content.html. 38. Oracle Workflow, technet.oracle.com/docs/products/oracle8i/doc-library/817-doc/ ois.817/a85440/wf/wftop.htm. 39. Peregrine B2B Integration Platform, www.peregrine.com. 40. RosettaNet, www.rosettanet.org. 41. SAP, www.sap.com. 42. Staffware 2000, www.staffware.com. 43. TIBCO Active Exchange, www.tibco.com/products/activeexchange. 44. TIBCO TIB/Inconcert, www.tibco.com/products/in-concert/index.html. 45. UDDI: Universal Description, Discovery and Integration, www.uddi.org. 46. Versata Integration Server, www.versata.com. 47. Vitria Business Ware, www.vitria.com/products/businessware/overview.html. 48. WebMethods B2Bi, www.webmethods.com/content/1,1107,B2BiSolutions,FF.html. 49. Workflow Management Coalition (WfMC), www.wfmc.org. 50. WSDL, “Web Services Description Language,” Version 1.1. Ariba, IBM, Microsoft. January 2001, msdn.microsoft.com/xml/general/wsdl.asp. 51. WSFL, “Web Services Flow Language,” Version 1.0. IBM Software Group, May 2001, www-4. ibm.com/software/solutions/webservices/pdf/WSFL.pdf. 52. XLANG, www.gotdotnet.com/team/xml-wsspecs/.
