Managing process and service fusion in virtual enterprises

lnfimmron Systems Vol. 24, No. 6. pp. 429-456, 1999 0 1999 Elsevier Smnce Ltd. All rights reserved Printed in Great Britain 0306-4379199 $20.00 + 0.00

Pergamon PII: SO306-4379(99)00026-S

MANAGING PROCESS AND SERVICE FUSION IN VIRTUAL ENTERPRISES+ DIMITRIOS GEORGAKOPOULOS,HANS SCHUSTER, ANDRZEJ CICHOCKI, and DONALD BAKER MCC, 3500 West Balcones Center Drive, Austin, Texas 78759, USA (Received

10 March

1999; in final revised

form

16 August

1999)

Abstract

Virtual Enterprises (VEs) are businesses providing services and products that rely on the resources of multiple enterprises. VEs can achieve their business objectives only through effective collaboration between the autonomous enterprises that comprise them. In this paper we advocate the position that effective multi-enterprise collaboration can be achieved by integrating the business (business) processes of the participant enterprises, and by managing the resulting multi-enterprise processes. A key requirement for this is developing multi-enterprise processes that explicitly capture and manage the functional and contractual relationships between the enterprises in a VE. In particular, this includes the inter-enterprise services each enterprise in a VE provides to others as needed to realize multi-enterprise processes. Current process management technology does not deal with the heterogeneity and autonomy of the processes that need to be integrated in a multi-enterprise process. In addition, existing solutions that combine services and multi-enterprise processes either lead to specification explosion or disallow conversations between process activities and services. The Collabomtion Management infrastructure (CMI) addresses these problems by extending an advanced workflow model with a comprehensive set of service management primitives. These include service interfaces, service activities, primitives for coordinating service activities, service wrapper processes, as well as service quality and contracts. A CM1 system that supports these has been developed by integrating existing software components, such as a commercial workflow system, with several prototype engines and tools that support the new primitives for multi-enterprise process and service management. TO illustrate how CM1 supports these, we use multi-enterprise process and service examples from the telecommunications industry. 01999 Elsevier Science Ltd. All rights reserved

Key words: Multi-Enterprise

Processes,

Process Modeling,

Services, Workflows

1. INTRODUCTION A Virtual Enterptise (VE) appears like a traditional enterprise to its customers but provides services and products that rely on the core business processes and the resources of multiple constituent enterprises. The enterprises that comprise a VE may be participating in a long-term strategic alliance or collaborate only for the duration of a single electronic commerce transaction. VEs can achieve their business objectives only through effective collaboration between their constituent enterprises. Although there may be other ways to achieve effective multi-enterprise collaboration, in this paper we consider a process-centered solution that emphasizes the integration of the core business processes of enterprises that participate in a VE and the management of the resulting multi-enterprise processes (MEPs). To illustrate the potential benefits of such a process-centered approach consider house construction as an example of a traditional VE. This involves a contractor that hires subcontractors to perform various construction tasks. Contractors come and go as they are needed, and the construction VE is dissolved when the house is completed. In such a VE, the construction processes can be designed to achieve various degrees of construction quality and efficiency. For example, the construction process may minimize the construction costs, maximize construction speedt, prevent injuries, etc., or achieve some other combination of objectives. Therefore, by focusing on the management of their MEPs, VEs can improve efficiency and can achieve their business objectives. Just like in process management in a traditional enterprise, MEP management involves capturing, evaluating, automating, and improving MEPs. However, unlike process management in traditional enterprises, MEP management must deal with the heterogeneity, autonomy, and effective distribution of the single-enterprise processes (SEPs), i.e., the internal processes of the +Recommended by Michael P. Papazoglou and Aphrodite SAn interesting case of construction process optimization than 3 hours has been reported in [20].

429

Tsalgatidou that resulted

in building a single story house in less

430

DIMITRIOS GEORGAKOPOULOS et al.

enterprises that participate in the VE. SEPs are typically heterogeneous and must be integrated to develop a MEP, since the enterprises that comprise a VE often model their internal process using different conceptual, process, and/or execution models. Current process management technology, such as the workflow process models provided by the Workflow Management Coalition (WfMC) [9] and many traditional Workflow Management Systems (WfMSs) (e.g., FlowMark [lo] and InConcert [12]), cannot effectively capture and support the integration of business processes in a VE. This is either due to the lack of necessary modeling flexibility or the resulting process models are too complex and resemble low level programs where the MEP integration activities becomes a significant part of the MEP specification. This leads to specification explosion, i.e., a combinatorial explosion of MEP specifications that become difficult to understand and manage. Another significant problem in MEP management is SEP autonomy. This problem is caused by enterprises that do not expose their (internal) processes to other enterprises, since knowledge of their (internal) processes can be used for competitive intelligence (e.g., analyzed or mined to reveal efficiency secrets, or weaknesses in responding to a market demand). To allow access to their SEPs the enterprises in a VE typically expose only the services they provides to each other. Such inter-enterprise services are functional abstractions of a collection of SEPs provided by a single enterprise. Services may support functional interfaces for quality of service (QoS), control of service (CoS), and/or awareness of service (AoS). These may be explicitly provided via service contracts. MEP integration of SEPs via inter-enterprise services, is a novel concept with important implications. In particular, inter-enterprise services in a VE may involve a complex conversational protocol between the requester of a service, i.e., the client, and the service provider that is far beyond the usual invocation/termination semantics of activities in traditional workflow process models. Services are not captured well by traditional activities as provided by current workflow technology [24, 28, 321. As we discuss later in this paper, related research solutions are also in preliminary stages [l, 2, 7, 8, 15, 191. When there are more than one service and corresponding SEPs that achieve the same objective, the distribution of a MEP in SEPs and the utilization of alternative SEPs that are provided by services in different locations and enterprises is an important problem in MEP management. Related work in this area often attempts to generalize results in distributed workflow execution assuming that the all SEPs in a MEP use the same process model and the entire MEP (including the SEPs) is globally designed [16]. Clearly, this popular assumption does not allow SEP heterogeneity and autonomy. Thus, it is difficult to apply such solutions in most practical VEs. The ColZabomtion Management Injkastructure (CMI) has been developed at MCC to manage collaboration processes in VEs as well as in traditional enterprises. To achieve these objectives CM1 provides a sophisticated ColZabomtion Management Model (CMM) that combines process and service management in a single model. CMM is designed to allow SEP heterogeneity and autonomy in a VE, and provides a novel approach and primitives for SEP integration via interenterprise services. Furthermore, CMM does not rely on any specific MEP distribution strategy, such as subcontracting or chaining. In CMM a MEP is composed entirely of SEPs, i.e., there is no separate MEP process beyond the union of its SEPs. CMM manages only the dependencies between each pair of SEPs and does not rely on any specific distribution strategy. It should be also noted that CMM is intended to support the process management needs of a broad range of application domains that are currently unsupported by existing process models. To achieve these objectives, CMM draws from existing primitives of workflow and groupware models and introduces new primitives for previously unsupported process requirements. Such novel primitives include application-specific activity states and operations, activity placeholders, and optional or unstructured activities. CMM consists of a Core Model (CORE) and several specialized extensions of it. CORE provides a common set ‘of process model primitives that constitute the basis for all extensions. The CMM extensions include models designed specifically to support coordination, services, awareness, and application-specific process models. In this paper we focus on the models for coordination and services and application-specific extensions of these. The Coordination Model (CM) provides primitives for coordinating participants and for automating process enactment. CM also provides

Managing

primitives interfaces, processes,

Process

and Service

Fusion in Virtual

Enterprises

431

that can be use to integrate SEPs in a MEP. The Service Model (SM) supports service activities, primitives for conversational service coordination, service and service contracts, as needed to support MEPs in VEs.

service

wrapper

A CM1 system has been developed by integrating existing software components, such as a. commercial workflow system and various groupware tools, with several prototype engines and tools that are required to support the new primitives for MEP management via inter-enterprise services. To illustrate how CM1 supports these, we use MEPs and related service examples form the telecommunications industry. CM1 support for other advanced application areas, such as crisis management and military command control are discussed in [6]. The rest, of this paper is organized as follows: Section 2 discusses problems related to the management of MEPs in a VE and provides an overview of the contributions of these paper. Section 3 outlines the CMM “CORE + extensions” approach. CORE primitives are described in Section 4, while CM and SM are elaborated in Section 5 and 6, respectively. The CM1 system architecture and a description of its implementation are provided in Section 7. Related work is discussed in Section 8. Section 9 concludes the paper.

2. ISSUES

AND CONTRIBUTIONS

IN MULTI-ENTERPRISE

PROCESS

MANAGEMENT

In this section we use examples from the telecommunications domain to describe key MEP management problems and corresponding solutions we contribute in this paper. In particular, in Section 2.1 we discuss a MEP for universal telecommunications service provisioning in a virtual In Section 2.2, we outline related requirements that cannot be telecommunications enterprise. effectively supported by existing process management, technologies, such as traditional workflow models, and provide an overview of the contributions of this paper. In the rest of this paper we introduce CMI’s Collaboration Management Model (CMM) and provide an overview of the CM1 system that implements it. We intend to illustrate that CMM addresses many key requirements for MEP management, including those described in Sections 2.1 and 2.2. 2.1. A Simple Multi-Enterprise

Process

A multi-enterprise process (MEP) is a fusion of processes that belong to different enterprises, Typically, the SEPs that comprise a MEP are heterogei.e., single-enterprise processes (SEPs). neous, autonomous, and distributed. As an example of a MEP consider an Universal Telecommunications Service Provisioning process that allows clients to request local, long distance, wireless, and internet service from a virtual telecommunications enterprise (referred to as the Unierersnl Service Provider). A simplified Universal Telecommunications Service Provisioning process is depicted in Figure 1. Its top-level process starts when a customer of the Universal Service Provider requests a Universal Telecommunications Service. Activity T, involves an operator collecting information from the customer, or a customer directly providing the information via a web browser. When sufficient customer data are collected, activity Ta is performed to (1) verify that the information provided by the customer is accurate, and (2) create a corresponding universal service order record. When Tb is completed, the top process starts a combination of the Provide Local Exchange Service, Provide Long Distance Service, Provide Wireless Service, and Provide Internet Service processes. These processes are managed by different enterprises. In Figure 1, we illustrate them as subprocesses of the top process. When all selected subprocesses are completed, activity T, is preformed to create a single bill for all telecommunications services that comprise the universal service. Finally, activity Td involves a human operator who calls the customer to inform him/her of the establishment of the requested universal service and to verify that the provided service meets the customer needs. Figure 2 illustrates the details of the Local Exchange Service Provisioning process in Figure 1. The Local Exchange Service Provisioning process in Figure 2 captures the activities of telephone Activity To involves processing the customer order for service provisioning for a new customer. universal service and extracting the portion of the order needed to create a service order for local

432

DIMITRIOSGEORGAKOPOULOS et al.

Provide Universal Telecommunications Service

Provide Local Exchange Service

Fig. 1: Multi-Enterprise Proceas for Universal Telecommunications

Provide Local Exchange Service

Service Provisioning

Provision

Fig. 2: Process for Local Exchange Service Provisioning

exchange. Next, activity 2’1 verifies that the information TO extracted from the universal service order is valid, and creates a corresponding local exchange service order record. On completion of TI , activities Tz, T3, and Td are initiated to perform three circuit provisioning activities. The objective of a provisioning activity is to construct a circuit from a customer location to the appropriate telephone switch and allocate equipment to connect the circuit. Only one of these provisioning activities should be allowed to complete, as all will result in a completed circuit, i.e., a set of lines and equipment that connects the customer to a telephone network (this requirement is not depicted in Figure 2). For example, assume that Ts, T3 and T4 achieve the same objectives but provide different guarantees/estimates for completion time and cost. In addition, Ts, T3 and T4 involve different paths for installations of new facilities. Tb captures manual work for new facility installation. The human activity Tb is initiated by providing installation instructions to the engineers (e.g., via mobile computers) and is completed when the human engineers provide the necessary work completion data. Activity TS involves changes in the telephone directory, while T7 updates the telephone switch to activate the local exchange service and then generates a bill for the Universal Service Provider. Ts informs the top process of the establishment of the requested local carrier exchange service, and passes the billing data to activity T, of the top process. As we noted earlier in this section, TC in Figure 1 uses the billing data from the local exchange service to create the combined customer bill for the universal service. From the perspective of MEP management, the SEPs for Long Distance, Wireless, and Internet Service Provisioning are similar to the Local Exchange Service Provisioning process, i.e., they all have ordering, provisioning, and fulfillment activities. Therefore, we do not discuss them in further detail. However, there are situations where these services (and the corresponding processes) must interact. Such intemctions require further synchronization. For example, consider the interaction

Managing Process and Service Fusion in Virtual Enterprises

433

between Provide Local Exchange Service and Provide Long Distance Service in Figure 1. This dependency exists because the Long Distance Service cannot be activated unless the Local Exchange Service receives necessary information from the Long Distance Service process, and vice versa. In particular, the fulfillment activity in the Local Exchange Service Provisioning process (activity T7 in Figure 2) must wait until the provisioning activity of Long Distance Service process produces the data required by the switch to activate long distance (e.g., the identification code of the long distance service provider). In addition, the Long Distance Service fulfillment activity that generates the long distance service bill for the Universal Service Provider must wait until the fulfillment activity in the Local Exchange Service Provisioning process updates the switch. Therefore, these processes must be coordinated to ensure this behavior. Our description of the Universal Telecommunications Service Provisioning process illustrates how a MEP can fuse together SEPs to achieve a specific objective, such as a providing customer service or product. However, in the following section we discuss that existing process management technology cannot effectively support the Universal Service MEP as it has been described in this section. 2.2.

Multi-Enterprise

Process

Management

Problems

and Contributions

of this Paper

MEPs such as our Universal Service Provisioning process are poorly supported by existing process models, such as the workflow process models provided by the WfMC [9] and many traditional WfMSs (e.g., FlowMark [lo] and InConcert [12]), for the following reasons: l

SEPs

l

specification

l

enterprises

may not expose

their

l

enterprises

provide

(instead

l

there

l

inter-enterprise

These issues

to be integrated

in a MEP may be heterogeneous

of MEPs

using existing

services

may be multiple

service

services

are discussed

process

(internal)

in more detail

suffers from specification

that

explosion

SEPs to other enterprises

of access to their SEPs)

providers

are typically

models

provide

to other enterprises

the same or a similar

service

conversational in the following

paragraphs.

SEP Heterogeneity: Different. enterprises typically model their process using different conceptual, process, and/or execution models. For example, a local exchange service provider may model its Local Exchange Service Provisioning processes as consisting only of pre-order and order activities. Pre-order may correspond to the order activity and part of the provision activity in the process in Figure 2, while service order includes the remaining of the provision and fulfil1 activities in Figure 2. A third local exchange service provider may have yet another process to implement its Local Exchange Service Provisioning that includes a billing activity before any service provisioning activity is performed. Even assuming the presence of workflow and data exchange standards, al1 three variants of the Local Exchange Service Provisioning SEP have to be handled differently by the universal service SEP that integrates them in the MEP. Such heterogeneous SEPs are designed by different service providers, at different times, and for different clients. Although there is no general solution for dealing with heterogeneity in any model, process models that capture application semantics and provide effective abstractions via subclassing can deal better with heterogeneity than other process models that bury integration semantics in the code of some integration program. Existing process models such as those used in many traditional WfMSs and proxy mechanisms such as SWAP [28] and OMG’s Workflow Management Facility [24] provide only the generic activity states and operations of the Workflow Management Coalition [32], e.g., running, completed, or terminated activity states. These generic activity states do not capture the application semantics of heterogeneous SEPs that are integrated in the MEP. CMM allows the modeling of SEP activities using application-specific states, such a ordered, provisioned, and fulfilled states for the Local Exchange Service Provisioning process in Figure 2. In addition, CMM provides explicit operations that cause transitions between such activity states. Finally, unlike any other process model we

434

DMTRIOS

GEORCAKOPOULOS

et al.

are aware of, CMM provide subclassing of application-specific activity states and operations so that they can be always generalized to a specific generic state. This allows clear semantics for inheritance and subtyping that apply well-understood advantages of object-oriented programming to a process model, i.e., the CMM. MEP Specification Explosion: In Figure 1 we represented each of the SEPs for Local Exchange, Long Distance, Wireless, and Internet Service Provisioning as a single traditional activity in the Universal Service Provisioning SEP (i.e., as subprocesses of the Universal Service Provisioning process). Figure 1 becomes increasingly more complex, if we use an existing process model to integrate these SEPs. In particular, capturing the integration of these SEPs in a traditional process model requires introducing additional invocation and/or feedback activities for each invocation and interaction between these SEPs. For example, assuming that the designer of the Universal Service Provisioning SEP has access to the Local Exchange Service Provisioning SEP, he/she may incorporate three additional feedback activities in the Universal Exchange Service Provisioning SEP that reflect the status of the ordering, provisioning, and fulfillment activities of the Local Exchange Service Provisioning SEP. In addition, the designer must introduce additional data and control flow that relate these activities with the rest of the activities in the Universal Service Provisioning process. The result of this modeling approach is a tight integration of the SEPs in the MEP. In particular, each SEPs must be designed to include at least one invocation activity for each interaction with another SEP, and may include at least one feedback activity for each of the states of another SEP that may result from an interaction with it. If we now consider that each constituent service of the Universal Telecommunications Service is offered by multiple providers and that the Universal Service Provider is able to choose the best service dynamically, a separate Universal Service Provisioning SEP has to be provided for each possible combination of service providers. This leads to specification ezploaion, i.e., a combinatorial explosion of MEP specifications that is not practically manageable. Thus, current process technology imposes severe restrictions on the scalability and flexibility of a MEP management. CMM introduces advanced activities and coordination primitives that allow the modeling, awareness, and control of any SEP from another enterprise as a single activity. For example, the designer of the Universal Service Provisioning SEP may use CMM to model the Universal Exchange Service Provisioning SEP as a single activity that has three application-specific states that are substates of the generic running state and reflect the status of the ordering, provisioning, and fulfillment activities of the Local Exchange Service Provisioning SEP. In addition of using these application-specific states to provide awareness of the state of the Local Exchange Service Provisioning SEP, CMM can be used to provide application-specific operations to control the execution of a collection of SEPs from a single activity. The CMM capabilities for such process control is discussed further in the following paragraphs on MEP Conversational Services. SEP Autonomy: Earlier in this section, we discussed that the integration of the SEPs in a MEP can be captured by the use of generic invocation and feedback activities. We also noted that using such existing process technology to integrate SEPs can only be accomplished by a tight integration of SEPs and this leads to specification explosion. An orthogonal problem is that SEP integration using generic low-level activities may not be possible at all, since it requires that the designer of an integrator SEP has detailed knowledge and access of the SEPs that are used by the other enterprises in the VE. This assumption and approach of MEP modeling is at odds with usual enterprise policies. Enterprises often protect their processes and their related implementation, since they can be observed, measured, and analyzed to reveal important details about the efficiency of an enterprise in delivering a service of a product (e.g., required cost, time, number of employes and resources). In addition, processes may indicate an enterprise’s weaknesses in dealing with market challenges or an inability to take advantage of new opportunities. CMM assumes that SEP designers require (1) no direct knowledge or access of the SEP models and implementations used by other enterprises, and (2) SEPs that belong to different enterprises are integrated and interact only via inter-enterprise services. CMM supported inter-enterprise services are functional abstractions of a collection of SEPs provided by a single enterprise. In particular, CMM services can capture the following:

Managing Process and Service Fusion in Virtual Enterprises Provide Universal Telecommunications Service

435

Local Exchange Service Activity

0

acuvity service activity

t--, -

interaction rmnmx

utilization

other service activities Long Distance Service Provider

Fig. 3: A Conversational

Local Exchange

Service Activity

Control of Service (CoS): Operations that start a SEP, provide input to the SEP, or synchronize the SEP with an activity of a client SEP, or cause the SEP to take a specific execution route.

Quality of Service (QoS): Qualitative and quantitative measures of the performance SEP(s) in the service, such as time and cost, and combination of these measures.

of the

Awareness of Service (AoS): Process events caused by specific activity state changes in a specific SEP and comprehensive abstractions via composition of such events.

The functional interfaces for CoS, QoS, and AoS are specifically provided via explicit CMM service contracts. Legal contracts between the service provider and its clients are also part of a service contract but they are outside the scope of this paper. CMM makes no particular assumptions about the implementation of the SEPs in a CMM service. Unlike many existing approaches that assume that SEPs in a service are implemented by a process management engine, such as a commercial WfMS, CMM allows a variety SEP implementations that include CORBA servers, basic programs, or even legacy information systems. MEP Conversational Services: A unique contribution of CMM is the integration of the traditional notions of activity and inter-enterprise service into a single CMM primitive, we refer to as a service activity. To illustrate this, consider again Figure 1 where we depicted the Local Exchange, Long Distance, Wireless, and Internet Service Provisioning SEPs as single activities of the Universal Service Provisioning SEP. Since in reality inter-enterprise services often encapsulate multiple SEPs, such services are typically conversational, i.e., they allow or require interaction where clients perform multiple service invocations and receive intermediate results that may be used in further invocations. For example, suppose that the Universal Service Provisioning Process (or any other client that uses the Local Exchange Service) needs to query the Local Exchange Service Provisioning service to determine whether the Local Exchange Service Provisioning process failed to complete its provisioning activity within the time frame the two enterprises have originally agreed on, e.g., as specified in the service contract of the Local Exchange Service Provisioning service. In this case, the Universal Exchange Service Provisioning Process may cancel the Universal Exchange Service or do necessary adjustments, e.g., notify its customer. Figure 3 depicts a simplified conversational service activity for local exchange provisioning. Please note that the illustration does not include replies for the service request, status, and cancellation invocations. In addition, Figure 3 does not depict the cancellation SEP and the control flow that results from this process. Finally, it should be noted that the status invocation is an alternative to defining application-specific activity states that reflect the status of the Local Exchange Service Activity as described earlier in this section. Conversational activities cannot be captured directly by existing process models [32, 28, 24, 10, 121 which assume that activities are invoked once, enter their running state, and they produce no data until they are completed or terminated (stopped). For example, if we use an existing

436

DIMITRIOS GEORGAKOPOULOS

etal.

process model to capture the cancellation of the Local Exchange Service we must add a Cancel Local Exchange Service activity after the Provide Local Exchange Service activity in the Universal Service provisioning Process in Figure 1. Therefore existing process models have the following limitations in capturing service request and cancellation: (1) the cancellation activity can only be invoked after the Local Exchange Service Provisioning SEP is stopped, i.e., cancellation of a service request in progress is not possible, and (2) the Local Exchange Service and corresponding service invocations in Figure 3 cannot be modeled as a single traditional activity. CMM supports these by introducing service activities that extend activity semantics to allow conversations as described above. CMM service activities are related primitives are discuss in detail later in this paper. Multiple Service Providers: As already indicated earlier in this section, there may be multiple service providers that offer the same or similar services, i.e., their SEPs can be used to achieve the same or similar objectives. To maintain market agility a VE may use the services (and corresponding service providers) that offer the most favorable terms in achieving its business objectives. To select the best collection of services that achieve its business objectives, an service integration SEP may perform dynamic SEP selection and SEP integration to dynamically constructing a MEP. For example, the Universal Service Provisioning SEP may dynamically select the actual service providers, integrate their SEPs in the Universal Service SEP, and use them to provide each component service whenever it is needed. The selection of each component service may depend on the &OS they provide as well as the AoS, CoS, and the compatibility of these with the integrator SEP. There are preliminary research contributions in the area of service quality and automatic service selection via service brokering, e.g., [7]. Although automatic service selection via service brokering is supported by CMM, in this paper we discuss only where these fit in CMM and the relationship of CMM primitives with service brokers. Limited discussion of service brokering in this paper is due to space limitations, the importance of this topic as a subject for a separate paper, and the fact that service selection in the telecommunications industry is currently manual because of the relatively small number of telecommunications companies around the world. The preliminary consensus in related research in MEP management for VEs [l, 7, 8, 15, 191 is that traditional process technology as exemplified by current workflow standards [24, 28, 91 is not sufficient to meet the needs of a VE [14]. However, as we discuss extensively in Section 8, related work provides only marginal improvements. In this paper we therefore introduce the collaboration management model (CMM) that combines advanced process modeling primitives with an explicit model of services in a process-oriented environment. CMM addresses the limitation of existing process and service models as follows: l

allows conversational

coordination

l

captures services using a object-oriented activity model that supports user-defined activity operations, subtyping of activity states, and subtyping of service interfaces

0 captures application-specific l

reduces specification

These contributions

of (service) activities

semantics

complexity

are gradually introduced

3. THE COLLABORATION

and discussed in detail in the rest of the paper. MANAGEMENT

MODEL (CMM)

CMM is a process-oriented model. It consists of a Core Model (CORE) and several specialized extensions of it (Figure 4). The CORE provides a common set of process model primitives that constitute the basis for all extensions. The CMM extensions include models designed specifically to support coordination, services, awareness, and application-specific process models. The Coordination Model (CM) provides primitives for coordinating participants and for automating process enactment. The Service Model (SM) supports service interfaces, service activities and related wrapper processes, and service contracts, as needed to support MEPs in VEs. The Awareness Model (AM) is a CORE extension that allows the monitoring of process related events,

Managing

Process

and

Service

Fusion

in Virtual

Enterprises

437

Application-specific

Fig. 4: CMM:

) Activity s,;,

variable

CORE

+ Extensions

1

Activity variable -

A -B: A 4B:AisaB

A is instance of B

A .->B: A-k

A containsB B:AhastypeB

Fig. 5: Basic

Primitives

1..*

(a) Input and output, helper resourcevariables (b) Input and output. role and local data variables

of the CMM

and the customized composition and delivery of such events only to these process participants that need them to perform their work. Further extensions can be introduced to support applicationspecific process models. Figure 4 indicates this by an application-specific extension atop of the CM, SM, and AM. The CORE, CM, and SM are discussed in detail in the following Sections 4, 5, and 6. AM is outside the scope of this paper and is described in [2, 61. CMM is a “C0R.E + extensions” model that has several advantages. It allows extensions to be used in a variety of combinations to provide increasingly powerful process modeling capabilities. In addition, it provides necessary extensibility for incorporating application-specific extensions in a seamless manner. CMM is driven by the need to develop a reasonable compromise between the flexibility, expressiveness, and complexity. This is accomplished by providing the appropriate mixture of meta types and types. In a process-oriented model such as CMM, meta types are used during the process specification phase to create new types as needed to model processes in a particular application domain. The set of types utilized for a specific application comprises the process model for this application. Therefore, the CMM meta types can used to create specialized process models (collections of types) for each application. These types are then instantiated and enacted in the process execution phase. Figure 5 illustrates the meta types and the corresponding types that are supported by CMM. In particular, CMM provides meta types for activity states (activity state meta type) and activities (bask activity meta type and process activity meta type). The activity state meta type is required

438

DIMITRIOS GEORGAKOPOULOS et al.

Fig. 6: Development of CMM Major Primitives in the CMM Submodels

to capture

application-specific activity states. For example, the activity state meta type can be used to create application-specific ordered, provisioned, and fulfill activity state types for an activity used to capture the Local Exchange Service in Figure 2. These application-specific activity states types can be subsequently re-used in capturing the states of other activities representing alternative Local Exchange Services, or other Services such as the Long Distance Service or the Wireless Service in Figure 1. The CMM activity meta types can be used to develop increasingly specialized application-specific process models by developing new activity types. For example, CMM activity meta types can be used to develop CMM activity types for Local Exchange, Long Distance, Wireless, and Internet Services. Such activity types constitute the specification and facilitate the validation of MEPs, e.g., in the MEP that provides Universal Telecommunications Services. Therefore, CMM’s activity state and activity meta types are particularly important in a VE environment. For resources and dependencies, CMM provides a resource meta type (resource meta type in Figure 5) that allows the creation of application-specific resource types, and prescribes a fixed set of dependency types (dependency type). Earlier in this section we noted that meta types allow capturing application semantics and provide more flexibility in modeling processes. However, this is typically achieved at the expense of increased modeling complexity. Therefore, it is a important design decision, whether a processoriented model such as CMM provides a fixed set of resource types and dependency types. For example, the commercial WfMS FlowMark [lo], provides meta types only for data resources, i.e., provides fixed activity state, activity, dependency, and participant resource types. The academic MOBILE WfMS [13,25] has a much more complicated process meta types including activity, activity state, resource, and dependency meta types. CMM achieves a reasonable compromise between flexibility and complexity by restricting the available dependency types to a fixed set. Issues related to creating process specifications from meta types or adapting meta types to different application areas are addressed in [16]. Figure 5 depicts the CMM activity, activity state, resource, and dependency types, how they are defined from CMM meta types, and how they are used to define activity and resource type objects for applications. Process activity types consist of an activity state variable, and activity, resource, and dependency variables. The activity state variable records the state of the process at any given point in time. The activity variables represent the subactivities of a process. The resource variables describe the resources needed during process execution, while dependency variables define the coordination rules for the subactivities of the process, e.g., their order of execution. Basic activity types have only an activity state variable and resource variables. Note that the activity and resource variables in Figure 5 are generalizations of the activity and resource primitives in the Workflow Management Coalition (WfMC) reference model [32] and similar primitives used in many commercial WfMSs. In the following sections we describe the CMM primitives as they are gradually introduced by the CMM submodels, i.e., the CORE, CM, and SM. This is depicted in Figure 6. The CORE introduces the primitives needed to support the subsequent extension models. It defines the CMM activity states, including both generic activity states and application-specific extension, and the CMM resources. The CORE also defines abstract activities and dependencies, i.e., model objects

Managing

Process

and Service

Fusion

in Virtual

Enterprises

439

statetransition A

B, A is substate of B

Fig. 7: Generic

Activity

State

Type

include only partial state but no operations are provided. For example, the CORE includes a single variable for each dependency indicating its existence. The CM enhances CORE’s activities and activity states with basic operations (e.g., start, terminate) that cause state transitions and introduces concrete dependencies. The SM extends further the CM primitives. In particular, it introduces service interfaces supporting application-specific operations and states, basic service activities, and service wrapper processes that capture the conversational nature of services and support the integration of heterogeneous SEPs. The CORE’s resources are adopted by both the CM and SM without further extensions.

4. THE

CORE

MODEL

The CORE is the kernel of the CMM. The CORE introduces the activity states and resource primitives depicted in Figure 5. As we discussed in the previous section, the CORE primitives are shared by the other submodels of the CMM. Section 4.1 discusses activity states and activity state types. An overview on the resources supported by the CORE is given in Section 4.2.

4.1. Activity States Each activity type contains an activity state variable that is associated with an activity state type which determines the possible activity states for instances of the respective activity type and corresponding state transitions. A transition from one activity state to another constitutes a (primitive) activity event. Events enable CORE extensions, in particular CM, AM, and SM, to communicate information about activity execution. Figure 7 shows the generic activity state type defined by the CORE. It is consistent with the proposed standard of the Workflow Management Coalition [31]. The activity state Uninitialized corresponds to not yet existing activity instances. When an activity instance becomes visible, i.e., it appears on the worklists of one or more participants, the activity state changes into Ready. A participant’s request to start an activity instance causes a transition to the Running state. While a process instance is in the running state, its subactivities may be performed. Depending whether an activity ends normally or is forced to terminate, the end state of an activity instance is either Completed or Terminated. Both are substates of the Closed state. The Suspended state is only applicable to process activity instances. It indicates that the execution of the process instance is temporarily suspended. No operations may be performed on a suspended process activity instance until its execution is resumed. It has to be emphasized that a CORE activity state type enumerates possible activity states and state transitions, but it does not define how and when a state transition occurs. Concrete implementations of state transitions are left to extension models of the CORE. Both the CM (Section 5) and the SM (Section 6) refine the CORE’s notion of a state transition. The generic activity states in Figure 7 capture application-independent behavior of activity instances. In addition to the generic activity states, CORE captures application-specific states of activities. This allows precise modeling of the application and facilitates SEP integration in a MEP. Other workflow process models, such as METEOR [17] allow for the definition of arbitrary

DIMITRIOS GEORGAKOPOULOS et al.

440

statetransition Refinedstatetransition A __I)

B: A is substate of B Fig. 8: Example of Application-Specific

States

states. This can lead to complex process models with activities that do not have common denominator with respect to activity states. Therefore, the CORE’s activity state meta model restricts the definition of application-specific activity states to substates of basic or already defined application-specific states. This leads to a forest of activity states where the basic activity states are the roots of the trees. A forest of activity states together with the corresponding state transition diagram comprise an activity state type. Note that state transitions must only connect the leaves of the forest. For example, consider the service interaction between the long distance and the local exchange services in Section 2.1. Suppose that Local Exchange Service Provisioning subprocess has two application-specific states, say preparing to fulfill local service and local service fulfilled. The Local Exchange Service Provisioning subprocess enters its preparing to fulfill state when it starts running, and changes its state to local service fulfilled when it updates the switch (with the local exchange and long distance information). Application-specific states allow MEPs to deal with service interaction. In particular, since the preparing to fulfill and local service fulfilled states axe visible to the Universal Service Provisioning process, this process can observe them and use these states in the definition of control and dataflow. For example, the Universal Service Provisioning process may use these states to determine whether to terminate the Long Distance Service Provisioning process or accept its charges if they are received before the Local Exchange Service Provisioning process is completed. In addition to facilitating the modeling of service interactions, application-specific states potentially provide support for dealing with SEP heterogeneity. For example, consider another Local Exchange Service Provisioning SEP that has only pre-order and order activities. The Running state of these activities can be modeled as preparing to fulfill and local service fulfilled states using a service wrapper process. This is discussed further in Section 6.1.4. activity

Figure 8 depicts the preparing to fulfill and local service fulfilled states as a refinement of the Running state. Note that only the preparing to fulfill state has a direct transition to the Terminated state. Similarly, transition to the Completed state occurs only through the local service fulfilled state. These restrictions are needed to disallow the process to enter Completed directly form the preparing to fulfill state or terminating the process after it has entered its local service fulfilled state which implies that the necessary resources have been allocated. For simplicity, transitions to and from the Suspended state are omitted from Figure 8. The definition of substates is a refinement of a state type, i.e., not a refinement of individual states. The activity state type shown in Figure 8 is a subtype of the generic Activity State Type in Figure 7. The refined state type is called a subtype of the original state type (referred to as the father type). When an activity state is refined, all state transitions of the refined activity state have to be replaced by transitions involving one or more of its substates. Such transitions are depicted as grey arcs in Figure 8. Suppose that C(hild) is a subtype of an activity state type F(ather). C is a valid activity state

Managing Process and Service

Fusion

in Virtual

441

Enterprises

subtype of F if and only if either a transition happens between two substates of the same parent state, or that there is a corresponding transition between the parent states in the father type. We can formally specify the constraints for the states and transitions of an activity state subtype as follows: l

l

An activity state type is a tuple (S, T) whereby S is the set of states transitions t = (~1, sg), where ~1, s2 E S and t E T.

For each subtype C of a father type F there is a function refine-state. The domain of the function is SF. It defines how the states of the father type are refined by t,he subtype, by mapping each father state to the corresponding set of substates. To enable an unambiguous state refinement, each substate must have exactly one father state, i.e.l (refine_state(sl) fl refine_state(sz) # 0 H 5-l = s2) A SC = CsESF refine-state(s)

A state subtype C of the father transition (~1, ~2) CETc: l

l

and T is the set of

type F is valid if one of the following

both s1 and s2 are refinements 3s E SF : S] E refine-State(S)

of the same state A S2

E

constraints

holds for each

in F, i.e.,

refine_State(S),

or there is a corresponding transition (s,, sb) in the father type F, i.e., 3s,,sb E SF : (sa,sb) E TF A s1 E refine_state(s,) A s2 E refine_state(sb).

This restriction on building application-specific (sub)states and activity state types ensures that application-specific extensions can always be generalized in a meaningful way to a father type, where the generic activity state type is the bottom of the activity state type lattice. 4.2. Resources The CORE distinguishes four basic kinds of resource types to be used during an activity execution: data, helper, participant, and context resources. The data, helper, and basic participant resources are similar those found in many workflow models and WfMSs. In particular, the CORE data resources are similar to the workflow internal and workflow relevant data in the workflow literature [13, 91. The helper resources are typically programs that provide auxiliary resources to implement basic activities, such as a text editor that is needed for a human to perform a writing activity. Helper resources correspond to invoked applications of the WfMC standard [9]. In addition to the traditional data and helper resources, CORE provides context and advanced participant resources. These novel resource types are critical in supporting MEPs in VEs, crisis management, and many other advanced applications [6]. The contezt resource is a collection of named resources (similar to a record structure in programming languages). Context resources can be accessed only via context references and enable a set of resources to be shared by multiple activities. Context resources are explicitly created and deleted either by declarative means in a process type, or by API calls performed within basic activities. The lifetime of a context resource instance is not necessarily bound to the lifetime of a particular process instance. While the lifetime of a context is often associated with the execution of a process instance, it is also possible to allow an arbitrary context lifetime by passing context references between process instances or making it globally accessible. In a MEP, concurrent SEPs use context resources for data exchange. Participant resources are either humans or programs. That is, such resources capture actors in the real world that take responsibility to start and perform activities. Both human and program individuals can play one or multiple roles. While static organizational roles are common in many process/organizational models supported by WfMSs, CMM provides a more advanced type of role that can be dynamically created and exist only within a (context) scope. We refer to such roles as scoped roles. Scoped roles are a key requirement for capturing dynamically evolving process, such as the dynamic creation of a task force of process designers to perform the integration of a SEP in a MEP, or to deal with an exception. Scoped roles also provide the means of providing awareness information to process participants. Scoped roles are outside the scope of this paper. They are discussed further in [S].

DIMITRIOS GEORGAKOPOULOS et al.

442

_w

A+

State transition B: A is substateof B

Fig. 9: Generic Activity

State

Type Refined by the CM

5. THE COORDINATION

MODEL

(CM)

The overall purpose of the CM-as its name suggests-is to provide primitives for the capture and enforcement of process coordination requirements. Sections 5.1 and 5.2 provide a brief overview of the basic data and control flow primitives that CM adopts from existing workflow technology [6, 131 and discuss CM enhancements. Section 5.3 describes advanced CM primitives for activity templates that can address MEP requirements for SEP dynamic service selection, integration, and flexibility. 5.1. Basic Activity Operations The central primitives of any process model are its activities. As we described in Section 4.1, the CORE provides the CMM primitives for modeling activity states. The CM enhances this notion of activities with execution semantics. In particular, CM defines generic operations that trigger the activity state transitions and describes how such operations can be implemented. In process-oriented models activity state transitions are triggered by operations on activities, like the start and termination of a (sub)activity. Many existing workflow process models, e.g., [lo, 311, use implicit activity operations. In such process models, activity operations are not explicitly mentioned in the process model. Instead, they are tightly coupled with the notion of an activity. Explicit activity operations are supported only by few WfMSs, e.g., the MOBILE WfMS [13,25]. Nevertheless, explicit activity operations are very useful for specifying activity state transitions, particularly if application-specific activity states are involved. CM supports explicit activity operations for creating, starting, finishing, terminating, suspending, and resuming activities. These generic operations can be invoked by the process participants when an activity appears in the participants’ worklists or by the CM1 coordination engine as described in the process specification. In addition to these operations, CM provides a state-changeaf _subactivity(ActivityVariable au, ActivityState newstate) operation that the CM1 coordination engine performs on a process activity instance whenever the CM1 coordination engine detects that a subactivity in this process instance has changed state. The invocation parameters of this operation are the activity variable of the subactivity that changed state and its new state. These operations are depicted in the generic state transition diagram in Figure 9. The state_change_of_subactivity() operation enables a process instance to react on its subactivities’ state changes. For example, the process instance may change its own state and perform subsequent control flow and/or data flow that are enabled by this a state transition. The generic state transition diagram (Figure 9) contains only state transitions that depend on generic activity states. Application-specific states and a corresponding state transition diagrams can be similarly defined. In this case, the activity variable parameter of the state_change_of_subactivity() operation can be used for triggering application-specific state transitions. This is illustrated in Figure 10

Managing

Process

and Service

Fusion

in Virt.ua!

Enterprises

state_chanfe_of_sub:Ic

State transition A

B. A is substate

of B

Fig.

10: Example

of Application-Specific

States

that depicts a fraction of the state transition diagram in Figure 8 enhanced with CM-provided generic operations. Suppose the state transition diagram in Figure 10 captures the activity states and corresponding operations of the Local Exchange Service Provisioning subprocess in Figure 2. Recall that activity T7 in Figure 2 activates the local exchange service by updating the telecommunications switch, while Ts bills the Universal Service Provider and when this activity completes this indicates the establishment of the requested Local Exchange Service. The activity operations that trigger transitions to/from these states of these activities are depicted in Figure 10. In particular, the successful completion of T7 is modeled by the application-specific state preparing to fulfill, while the successful completion of Ts is captured by the local service fulfilled state. The Local Exchange Service Provisioning subprocess enters the local service fulfilled state when activity T7 updates the switch. This occurs when the CM1 process coordination engine detects that T7 has completed and performs the state_change_of _subactivity(T7, Completed) operation. Next, activity Ts prepares the local billing information for the Universal Service Provisioning process. The Local Exchange Service Provisioning process is completed when Tg completes and the CM1 coordination engines performs state-change-of-subactivity (Ts, Completed). Therefore, CM provides execution semantics for state transitions involving application-specific states. The SM allows more explicit control of activity state changes by providing application-specific operations. We discuss these further in Section 6.1. 5.2. Basic Control and Dataflow Primitives The CM provides control flow transitions, which are virtually equivalent to the those provided by commercial WfMSs, e.g., FlowMark [lo], and the WfMC standard [32]. A control flow transition originates at exactly one activity variable and points to exactly one target activity variable. The originating and target activity variables must be different. A transition implies that the activity instances belonging t3 the originating, activity variable have to precede the activity instances of the target activity variable. Additionally, a condition may be attached to a transition (transition. condition) to control the validity of the transition. When multiple transitions point to the same target activity variable, this situation is called a JOIN in [32]. Transitions in a JOIN may be combined by a transition join policy which is attached to the target activity variable. A join policy is a boolean condition on the incoming transitions. Similarly to [la], the CM allows arbitrary join policies. This contrasts the approach taken in [lo, 321 where only pure AND (AND-SPLIT) or OR (OR-SPLIT) conditions are supported. To allow for CMM’s application-specific states having impact on control flow, the CM extends the traditional notion of control flow transitions by considering the state of the originating activity variable. A control flow transition (aw,,,,,, , s,,,~,,) -+ autarget has the semantics that the activity avsovrce has to enter state ssotLrcebefore the target activity avtarget can be performed, i.e., before it can enter the Ready state. If no state is specified for the source of a control flow transition, the

DIMITRIOS

444

GEOAGAKOPOULOS

et al.

target activity get enabled after the source activity reaches the Closed state. Dataflow dependencies are the means of copying resources that are output parameters of a set of activities into the input parameters of another set of activities. The current CM dataflow semantics are restricted to the traditional dataflow capabilities described in [lo, 321. In a CM process specification, a dataflow dependency originates from an activity variable (the resource producer) and points to another activity variable (the resource consumer). The consumer must be different from the producer. Dataflow dependencies define a mapping of the producer’s output resources to the consumer’s input resources. Just like dataflow in [lo, 181, CM dataflow has to follow control flow and has no control flow-related side effects. For each dataflow dependency a control flow path (i.e., a path of transitions, originating at the producer and leading to the consumer) must exist. This ensures that the input data of an activity is always available when the activity is started. 5.3.

Advanced Primitives

for Activity Templates

The terms process/activity template are used in CM1 to capture the situation that a process specification does not exactly represent the actual process instances that are performed by participants. Instead, a process template constitutes a “shallow” specification that leaves certain aspects of the actual process instances open to be concretized at runtime. In this paper we focus on only two CM primitives for activity templates. The activity placeholders enable service selection at runtime. Repeated optional dependencies can be used for supporting optional service tasks. primitives These primitives are discussed in the following sections. Additional template-related are discussed in [6]. 5.3.1.

Activity

Placeholders

Activity placeholders allow for activities whose concrete types are unknown or intentionally left open at process specification time. More specifically, activity placeholders allow for runtime assignment of an activity type to a given activity variable. Since services are represented by activity types (Section 6), activity placeholders are the foundation of enabling dynamic service selection at runtime. In our telecommunications MEP example, activity placeholders can be used to enable dynamic selection of the actual Local Exchange Service employed by the Universal Service Provisioning Process. Dynamic selection is key requirement for taking advantage of multiple service providers of the Local Exchange Service. Spedfication

time

Runtime Prorxasactivity instanceai of typzP

PI-typeP _-___-.-_ BV: Selcu from (Al, .... A,1 .-_-v-w---’ -

Conuol flow

>

,..

bansitions Fig. 11: Example of an Activity Placeholder

The left hand side of Figure 11 depicts an example of an activity placeholder within a process type P. An activity placeholder, more accurately an activity type placeholder, is used instead of a concrete activity type in the declaration of an activity variable in a process type. An activity placeholder has a selection policy attached, which is used at runtime to select the actual activity type for the placeholder’s activity variable. To ensure the consistency of the process type within which an activity placeholder is used, the set of activity types from which the selection policy chooses one has to be specified. Such specifications are either activity type enumerations or declarations. An activity type declaration includes an activity state type. Only those activity types may be selected to fill an activity placeholder that match the required activity state type or one of its subtypes. The input (output) resources used by dattiow to (from) the activity variable using the placeholder impose additional signature restrictions on the possible activity types that can be

Managing Process and Service Fusion in Virtual Enterprises

445

selected. Figure 11 illustrates that the actual type for the activity variable av can be chosen from the set {Al, . . . , A,}. The selection policy is not depicted. The right hand side of Figure 11 shows a snapshot of an instance of the process type P. We assume that the selection policy for the activity placeholder has already been evaluated to activity type AZ. The activity variable behaves now like a normal activity variable, i.e., an activity instance is instantiated for it which is performed by a participant. 5.3.2. Repeated Optional Dependencies Advanced collaborative applications are characterized by the fact that their objectives cannot be met by simply running an algorithm, e.g., in the form of a predefined process. Instead, the potential means to achieve the application’s objective are often known, but usually the timing and frequency of their usage cannot be predetermined. In process-oriented systems the means for achieving application objectives are activities that may be invoked within processes. However both the exact invocation place in the control flow path of the process and the number of invocations of an activity cannot be pre-specified. The decision when and how often these activities are performed can only be made by the participants involved in a particular process instance. Such flexibility is also required by even relatively simple services such as the Local Exchange Service in our telecommunication MEP example in Section 2. In particular, in Section 2.2 we discussed that a client may need to request the Local Exchange Service and query its progress as often as necessary to determine whether the Local Exchange Service Provisioning failed to complete its provisioning activity within the time frame the two enterprises had originally agreed upon. Then, if the client determines that the performance of the service provider is below its expectations, the client may cancel the service or do other necessary adjustments. For example, the client may notify its customer or delay some other service, say the Long Distance Service, that depends on the progress of the Local Exchange Service. Clearly, the service query is an optional and possibly repeated activity (or service task). The adjustment activities that may be performed by the client after a service query activity can be viewed as exception handling tasks. Finally, such unstructured activities may be necessary for service integration. We give an example of such a task in Section 6.1.4. Unfortunately, optional, arbitrarily repeated, and/or unstructured activities cannot be captured with traditional workflow functionality, since existing workflow models rely on the complete specification of the control flow of a process. CM’s repeated optional dependencies overcome this shortcoming of traditional workflow technology. The repeated optional dependency primitive consists of two parts: the repeated option creator and the repeated option terminator. The repeated option creator specifies that when an activity variable, say auOpt, is enabled by normal control flow, avOpt may be instantiated zero or more times. The time and number of instantiations is determined by the participant(s) assign to it. The repeated option terminator limits the time span within which av0,,t can be instantiated by the starting of another activity (e.g., avterm). That is, as soon as avterm starts no additional instances of av,,pt can be started. The process designer may specify an upper bound on the number of instances of avopt that can be performed in a given process instance. Activity variables constrained by repeated optional dependencies within a process have no impact on the remaining activities of this process or on the termination of the process. Figure 12 shows an example of the repeated optional dependency. The left hand side of the figure depicts a process type P containing the activity variable av which has a repeated optional dependency attached. If an instance of P is executed, the activity s has to be performed first, After s ends, the control flow transitions because it has no incoming control flow transitions. originating at s will evaluate to true since no user-defined conditions are attached to them in this example. As a consequence, the activity variable av gets enabled and is offered to the players of role R for execution. The right hand side of Figure 12 assumes that participant pz chooses to perform an activity instance of au. This causes the creation of an activity instance al. In addition, al is assigned to p2 and gets the input resources as specified for au. The activity variable au itself stays on the worklists of all players of role R. The remainder of the process (indicated as dots in Figure 12) proceeds independently of aw. If activity e is performed the terminator of the repeated

DIMITRIOS GEORGAKOPOULOS et al.

446

Runtime

Specification time

Procw activity instance0; of type P aftar p2 has chosento perform av

ProcessType P

_ _ _ +D Dar&lowdependency __+

Control flow transitions -)

--_D

Repeated option creator (mandatorypart) Repeated option tetinator

(optional part)

Fig. 12: Example

of a Repeated

Optional

Dependency

optional dependency will be triggered, disabling CW,and av will disappear from the worklists of those that play role R. Thus, in the interval between ending of activity s and starting activity e, the players of role R can freely choose to perform activity instances belonging to uv, or none at .. all. Activity variables with repeated optional dependencies cannot have outgoing control and dataflow dependencies, because there is no point where processing of such an activity variable ends. However, such activities can exchange resources through the usage of shared context resources. Both process and basic activities can have repeated optional dependencies. The composition of activity placeholders with repeated optional dependencies, and the composition of these with other CMM primitives for templates is discussed further in [S]. The repeated optional dependency is conceptually different from explicit operations that allow participants to skip activities. To emulate the effects of an optional activity using skip operations, optional activities would have to be explicitly inserted at any place in the process graph where this option can be theoretically taken, and the participants would have to explicitly waive the option by performing the corresponding skip operation. This does not constitute a practical solution since it promotes specification explosion and forces participants to perform the skip operations that are completely unnatural from their point of view.

6. THE SERVICE MODEL (SM) The Service Model (SM) is an extension of CORE and CM providing support for reusable components of business processes that are, in particular, targeted to facilitate MEP implementation in VEs. A service constitutes a semantically well defined task that is offered by a service provider. Dealing with the heterogeneity that is inherent to VEs is the primary issue. Nevertheless, just modeling a service and bridging the heterogeneity is not sufficient. A comprehensive description of the service is required to improve the ability to chose an existing service. In Section 6.1 we describe how services are captured in our process model. Service semantics and quality are discussed in Section 6.2. The service description data enables the dynamic selection of a service from a set of offered services during execution time of a MEP. Dynamic service selection is presented in Section 6.3. 6.1. Modeling of Services Services typically involve a complex protocol between the requester of a service, i.e., the client, and the service provider that is far beyond the usual invocation/termination semantics of traditional workflow activities. Service execution includes the service request, feedback, and control operations during the ongoing service performance, and the final delivery of the service results. The situation is further complicated by the heterogeneity between the service requester and the

Managing

Process

and

Service

Fusion

in Virtual

Enterprises

L!zt7

... ?

cancel() //i

_b

A ___I)

t

Statetransition B: A is substate of B

Fig.

13: Example

of an Activity

State

Type

of a Service

Activity

service provider. This includes both technical heterogeneity of the protocol between client and provider and semantic heterogeneity of the client’s needs and the functionality provided by the service. To deal with these issues, the SM supports the following: service interfaces, basic service activities, primitives for coordinating service activities, and service wrapper processes. 6..2.1. Service Interfaces Service interfaces are declarative specifications of service semantics. They include applicationspecijic activity operations AOp for CoS and application-specific states S for AoS. Service interfaces can capture complex interactions between clients and service providers as state transitions diagrams. In addition, service interfaces specify input and output parameters. A service interface is a purely abstract type declaration. It does not contain an implementation of the application-specific activity operations. In SM the interface of a service is included in its service contract. Since subtyping of (application-specific) activity states is provided by the CORE (Section 4.1), subtyping of service interfaces can be introduced in a straightforward manner. A service interface C(hiZd) is a subtype of a service interface F(ather) if A0p~ 2 AOpc and C’s activity state type SC is a subtype of F’s state type SF. As a consequence, SM’s service interfaces provide a powerful means to build abstractions from heterogeneous services. Figure 13 depicts a service interface example with application-specific states. The visible execution states of the service are represented by application-specific states (all substates of Running in Figure 13). In addition, tasks that can be performed by the service client are modeled by application-specific activity operations. To ensure that these activity operations are used consistently, they are related to the activity states. The implementation of a service interface can also cause state transitions. These are labeled with internal in Figure 13. Service interfaces are implemented by service activities which are discussed further in Section 6.1.2. When a client requests the service, the service provider provides a service contract that includes the service interface. If the client is satisfied with the contract it uses the service interface to: (1) control the service, and (2) request information about the service status or observes the service state changes to become aware of the service status. 6.1.2.

Basic Service Activities

Basic service activities are an extension of the CM’s basic activities. They implement a given service interface. Basic service activities are the front-end to a service and located in the client process. Basic service activities are not the implementation of the service, which usually constitutes intellectual property of the service provider and may therefore be kept secret (Section 2.2). Thus.

DIMITRIOS GEORGAKOPOULOS

448

etal.

basic service activities are a new application of the of the proxy principle [27] within a process model. The integration of a service by a basic service activity of the SM is conducted in two steps: 1. Declaration of the basic service activity: This involves the selection of the service interface that is supported by the basic service activity. 2. Implementation of a corresponding service activity program: The service activity program translates the application-specific activity operations to requests to the service provider’s SEPs and maps SEP states to service state transitions as specified by the service interface. In contrast to CMM process types and the basic service activity declaration, which are descriptive specifications, the service activity program is to be coded in a traditional programming language. The service activity program uses the CM1 system API to access its input, output, scoped resources, to trigger internal state transitions, and to publish its activity operations to the CM1 system. Hence, the service activity program is an advanced wrapper program [26] for the external service. The deployment of a real program for this purpose is necessary, because the service application program has to deal with the (possibly proprietary) communication protocols and formats of the provider and translate them to the format used in CMM. Note that a single service activity declaration can have multiple implementations, i.e., service activity programs, that belong to different service providers. New service providers can be added without changing the MEPs as long as their advertised services are consistent with already existing service activities. Thus, the service activity concept provides a strong abstraction from the heterogeneity in a VE. Clearly, the deployment of web technologies usually simplifies the implementation of service activity programs because of the existence of well-standardized communication protocols and forms. By allowing for application-specific states and operations, the SM provides a far more powerful model than SWAP [28] and the Workflow Management Facility [24]. Both of these propose a variant of a proxy mechanism that allow activity observers (or requesters). However, observers are limited to the states and operations defined in the WfMC standard [32], and are therefore not capable of capturing application semantics of services. 6.1.3.

Coordinating

Seruice Activities

Service activities capture the semantics of external services, i.e., their execution states and possible interactions of the client with the service provider. Since service activities can be used as any other CMM activity, the control flow primitives of the CM can be deployed to start of service activities. However, the CM primitives cannot coordinate running services, because the CM control flow capabilities are limited to control only the start operation of activities. Since service activities may have additional application-specific operations that can be performed on a running service, additional coordination primitives are needed to control these operations. Such coordination primitives enable inter-service coordination and to synchronize specific service operations with the rest of the process. To accomplish this, the SM extends the CM’s control flow transition primitive. Recall from Section 5.2 that the CM has defined control flow transitions between two activities av,,urce and avtarget of a process, denoted as (avsource, s,,~,,,) + avtarget. These control flow transitions have the semantics that activity avt arget gets enabled, i.e., can be performed, when activity avBourfe enters the state ssouree. The SM extends this primitive for target activities that are service activities. A SM control flow transition originating at an activity variable av,r9 and pointing to an activity service variable avservice defines to which activity state seervice of avser,,ice it applies. SM control flow transitions are denoted as (avorg, sorg) + (av,,,,ice, sservice). They indicate that state transitions of avser,,ice to the sgervice state are only possible after av,r9 enters state sorg . Note that in CM control flow transitions, the allowed state transition is always to the Running state and caused by the start operation. To ensure that the SM dependencies can be enforced, only those application-specific states may be enabled by SM control flow transitions that can only be entered by performing explicit activity operations. Transitions to states that can be entered by internal transitions are not allowed, because these transitions cannot be controlled by the CM1 system, since they are triggered by the external service. Consider again the service

Managing

Process

and Service

Fusion

in \iirt,ual

Enterprises

449

Provide Virtual Telephone Service Provide Local Exchange Service

(MEP

-State Service activity variable

Fig.

@f&f&

transition

d

Control flow

Service activity state

14: Inter-Service

Coordination

Example

depicted in Figure 13. A control flow transition may enable the Installing service state of this service, i.e., allow the confirm() operation to be performed, because the Installing service state can only be reached by an explicit operation. Enabling the Service ordered state is illegal, since this state cannot, be controlled and is entered by an internal transition. Figure 14 depicts an example of the extended control flow transitions that are provided by SM. The process fragment. in Figure 14 captures and coordinates the service interaction between the Local Exchange Service and the Long Distance (LD) Service we described in Section 2.1. Consider again that this service interaction exists because the installation of the LD Service requires the Local Exchange Service provider to record LD related information (such as the ID of the LD provider) in the switch where the Local Exchange Service is activated. This has to occur after the LD provider has finished its internal preparation of the LD service, i.e., has reached the LD activated state. This is accomplished by the provider of the Local Exchange Service that allows LD service providers to update its switches with their LD data. To enable such updates the Local Exchange Service provider provides a write_LD_number() operation to its clients. Since the provider of the local exchange service has to prepare the switch before it can be updated by the LD provider, the corresponding write-LD_number() operation can only be performed if Local Exchange Service has reached the Switch ready state. This can be accomplished by observing the states of the Local Exchange Service and the Provide Long Distance Service, and by performing the write_LD_nzLmber() operation after the Local Exchange Service reaches the Switch ready state and Provide Long Distance Service reaches the LD activated state. Thus, CMM enables the coordinated execution of these service activities. 6.1.4.

Service Wrapper Processes

Service interfaces constitute an abstraction of external services by defining application-specific states and operations for an abstract service. To make full use of the service abstraction, logically equivalent services, e.g., for Long Distance Service Provisioning, should be subsumed under the same service interface. However, although different service providers may offer similar services, typically there may be differences in the details of the service behavior. Introducing a separate service interface because of such heterogeneity would increase the complexity the specification of the MEP, because each available service would need a separate activity variable in the process specification. Furthermore, with each new service becoming available, the overall process would have to be adapted. To avoid these problems the concept of a service wrapper process is introduced by the SM. A service wrapper process addresses heterogeneity of services by repackaging service activities in a uniform way. A service wrapper process is an extension of the process primitive provided by the CM. Like basic service activities, it features application-specific states and application-specific activity oper-

450

DIMITRIOS GEORGAKOPOULOSet al. ProvideLone DistanceServiceWrautw T

8

\

ProvideLong DistanceService

Servicewrapper process

(Service)activityvariable

+

State transition

&

Serviceactivitystate

Fig. 15: Example

Service Wrapper

Controlflow -)

Repeatedoption

creator

Process

ations, i.e., it implements a service interface. Its objective is to wrap a basic service activity and to compensate for heterogeneity with a target service interface, which is implemented by the service wrapper process. Note that the interface of the service activity to be wrapped is a specialization of the service interface of the wrapper process. Thus, the activity state type of the wrapper process is a generalization of the service activity’s state type, and that the activity operations provided by the wrapper process are a subset of the ones provided by the basic service activity. Applicationspecific activity operations provided by the wrapper process are mapped to application-specific operations of the wrapped service activity. This ensures that application-specific operations of the wrapper process and its corresponding state transitions can always be enforced. The internal state transitions of the wrapper process are derived either directly from (internal) transitions of the wrapped service activity or from the additional activities contained in the wrapper process. Figure 15 depicts an example of a service wrapper processes. We assume that a LD provider offers a LD Service that generally complies with the services offered by other LD providers. However, there are some important differences from the other LD services. The first major difference is that this LD service provider immediately bills the service client as soon as the service is requested, and does not wait until the LD service is installed. Therefore, this service provider does not comply with the other LD providers described in Section 2.1 that bill their clients only after the installation of the LD service. The second difference is that this LD provider may report that the LD service has been activated before the installation of the appropriate information has been completed in the switch of the Local Exchange Service. Thus, the clients of this LD service must be able to check whether the LD service has been installed as expected. Figure 15 illustrates a service wrapper process that adapts this unconventional LD service to exhibit the behavior of other LD services. The wrapper process includes a service activity Provide Long Distance Service that represents the unconventional service that needs integration, a Refund billed amount activity, and a Check status activity. The Refund billed amount activity provides a refund to the client when the LD service is cancelled. The control flow transition (Provide Long Distance Service, Terminated) + Refund billed amount enables automatic execution of the Refind billed amount activity whenever the LD service is canceled. The Check status activity has a repeated optional dependency (as described in Section 5.3) and becomes enabled after the service has entered the LD activated state. Since this state of Provide Long Distance Service may not indicate that the LD service installation has been completed, this Check status activity allows the service wrapper process to check the status of service installation as many times as necessary. When the wrapper process verifies that the LD service is installed it reports this to its clients (e.g., via a LD activated state of the wrapper process). Otherwise, the wrapper process may cancel the LD service and indicate this to its clients by entering a terminated state.

Managing Process and Service Fusion in Virtual Enterprises

451

6.2. Service Semantics and Quality Usually, multiple service providers offer the same or similar services in a multi-enterprise en. AS we noted in the Section 6.1, this means that multiple implementations of the same service can exist. From an integration perspective, a service interface specification-including application-specific activity operations, states, a corresponding state transition diagram, and input/output resources-captures these parts of the service semantics that are required for the service to be used within a process. However, the service interface is not suitable for initial service discovery at process definition time or for the discovery of newly offered services, since it requires that the services are already modeled. Therefore, additional means to advertise and discover services in a VE environment are required that support the service life-cycle that covers the time before a service is captured and wrapped by a basic service activity and service wrapper processes. Ontologies [29] are a suitable means to create a semantic description of an enterprise. Service ontologies, capturing the semantics of services in a more user-friendly and technology-independent way, are a promising technology to support service discovery and modeling. In contrast to service interfaces that build service abstractions which may hide specific properties of a service, e.g., the additional effort needed for service cancellation in the example depicted in Figure 15, an ontological service description has to cover all relevant effects of a service. Further discussion of these issues is beyond the scope of this paper. For the remainder of this section, we will assume that services are already discovered and modeled as service activities. Therefore, we can rely on the service interface for service discovery at process runtime. Besides the service functionality, denoted by the service interface, the (expected) quality of the service to be used is an important characterization of a service and a service provider. Quality of service (QoS) includes, but is not limited to, classical non-functional parameters such as the throughput, response time, cost, reliability etc. Since in a VE environment several service providers may offer the same service, i.e., services implementing the same service interface, choosing the best implementation for the process that invokes the service is an important issue. It has to be emphasized that in general this decision cannot be made at specification time. Service providers may change the quality of their services over time and new service implementations may be offered. In addition, the notion of the “best” service may be relative to a specific MEP instance. For example, a MEP should use the fastest service implementation no matter what it costs, if the process is already close to the deadline. In contrast, if there is plenty of time left for the process to complete, a more cost-effective strategy can be chosen. To address these issues, each offered SM service has a set of QoS attributes attached that provide information on the expected QoS of the service execution. In addition, each activity variable in a process type that is bound to a service interface can have a description of the desired QoS. This description can include conditional statements to allow adaptation of the favored QoS to the current situation of a MEP instance. If there are multiple service providers, the provider should be selected whose service offer best matches the desired QoS goal. Selecting a suitable service provider is called brokering and performed by a dedicated system component, the service broker. The broker is a specialized server that in response to the request for providers of implementations of a service interface returns a list of available service providers plus information about the expected quality of service. The knowledge about service providers is gained by the broker through advertisements. The advertisements are constructed by service providers and sent to the broker. A more comprehensive discussion of service brokering and service selection strategies is beyond the scope of this paper. However, the brief discussion presented above makes clear that services that are used in a process differ from normal activities, because of the need to select a suitable service implementation at runtime. In the next section, we will point out how the CMM provides the basis for dynamic service selection. vironment

6.3. Dynamic Service Selection To represent services in a process type, the SM uses the activity placeholder primitive of the CM (Section 5.3). Activity placeholders leave the concrete type of an activity variable open at

452

DIMITRIOS GEORGAKOPOULOS

eta].

specification time; only a constraint on possible activity types to fill the placeholder is given. At runtime of a process instance, a selection policy selects exactly one activity type that is used to instantiate the activity variable. A dynamically selected service of SM is therefore modeled by an activity placeholder; the service interface is used as a constraint to determine possible service activity implementations. The selection policy has to be determined by the process designer. The process designer should be able to choose from a set, of predefined selection policies that rate service implementations according to given quality of service criteria. In addition to using predefined selection policies, the process designer can define new selection policies that are adapted to the specific needs of the service selection in the given process. Selection policies that involve humans fall into this category. The complexity of selection policies is not, limited by the SM. The designer may, for example, create a simple policy which first, retrieves a couple of alternative service implementations together with quality of service information from a broker and then lets a human decide which of them to chose. Selection policies, however, can also involve negotiation processes. Imagine a virtual enterprise that is just beginning to form itself is looking for an accounting service. Choosing this service is an important decision and will probably involve multiple managers who may negotiate with service the providers to reach adjustments of the advertised quality of service, if needed. 7. CM1 SYSTEM RUNTIME ARCHITECTURE

AND IMPLEMENTATION

The CM1 system implements CMM through a federation of commercial and MCC-developed components. The commercial components are IBM’s FlowMark [lo], Microsoft’s NetMeeting [21] and DataBeam’s neT.120 [4]. The CM1 components developed at MCC include the user tools and engines depicted in Figure 16. Implementing the CMM atop of commercial systems means in general that each CMM primitive has either to be mapped to a corresponding primitive provided by the commercial system or to be implemented by processes or process fragments of the commercial WfMSs. MCC-developed components implement all novel CMM capabilities. CM1 Client for Participants

CMI Client for Designers

CM1 Enactment System Coordination Engine

1

1

ServiceEngine

]

1

Awareness Engine I

+ IBM FlowMark neT.120 etc.

CORE Engine

+

CEDMOS

Fig. 16: CM1 System Run-Time Architecture

User tools in CM1 are organized into to separate clients for participants and designers. A CM1 participant is a human or program individual involved in a collaboration process. A designer is a usually human who creates and maintains CMM process specifications. Participants interact with the CM1 enactment system using CM1 client tools for participants. The client tools subsume the tools defined by the WfMC [9]. In particular, participant tools include a workht tool, a process monitoring tool, an awareness information viewer, and a hybrid tool that combines a worklist with some monitoring capabilities. The CM1 worklist divides the activities each participant is eligible to perform into mandatory and optional work items. Mandatory work items are similar to those provided by the worklist of commercial WfMSs. Optional work items correspond to CMM activities that have repeated optional dependencies. Optional work items appear in the CM1

Managing

Process and Service Fusion in Virtual Enterprises

453

worklist when such activities become enabled and disappear as soon as their terminator activity (if any) is executed (Section 5.3.2). The awareness knfonnation viewer is responsible for monitoring a participant’s awareness event queue and displaying awareness events to him/her. The viewer enables a number of capabilities from a delivered event including viewing the details of the event, monitoring the process that generated the event, and viewing the awareness specification that generated the event. Awareness specifications are part of the Awareness Model and not discussed in this paper. The process monitor is similar to those provided by commercial WfMSs. The hybrid tool combines worklist and monitoring capabilities, such as allowing participants to view the subset of the process that includes all ancestor activities of their work items. CM1 client tools for designers include tools for creating and maintaining process and awareness specifications. The process tool is similar to the build-time tools provided by commercial WFMSs. The differences are the additional dependencies and resources provided by CMM. At specification time, a process designer also authors a number of awareness specifications using the awareness specification tool. All client tools connect to the CM1 enactment system (Figure 16). The CM1 enactment system contains several engines that implement the CMM. The modularity of the CMM is used in defining the engines and their interconnections. The CORE Engine implements the primitives of the C0R.E and it is used by the other engines that are responsible for the CM, AM, and SM extensions of the CORE. Context resources and in particular their scoping effect are specific to the CMM. Consequently, they are implemented by the CORE engine. The Coordination Engine implements the CM. In particular, the Coordination Engine implements scoped-roles and primitives for activity templates that are beyond the functionality provided by commercial WfMSs. The CM implementation maps such primitives into fragments of WfMS processes. This translation process involves the introduction of hidden activities controlled by the CM1 Coordination Engine. The Awareness Engine that implements AM, which is not discussed in this paper, heavily leverages features provided by the event processing system, CEDMOS (Composite Event Detection and Monitoring System) (31. CEDMOS directly supports the event processing model on which awareness is based [2]. The Service Engine implements SM without the use of additional commercial technology. The interfaces between the engines in Figure 16 are derived only by the relationships of the models. An in-depth discussion of the implementation of the CM1 enactment system engines is beyond the scope of this paper. In [S] we focus on the issue of how CM1 engines capitalize on the use of commercial technologies. CM1 components integrate various commercial systems and tools, including IBM FlowMark [lo], Microsoft’s NetMeeting [21], DataBeam’s neT.120 [4], and MCC’s CEDMOS (Composite Event Detection and Monitoring System) [3]. The coordination and resource handling capabilities of commercial WfMSs, i.e., IBM FlowMark [lo], and commercial meeting tools are exploited by the Coordination and CORE Engines. 8. RELATED WORK The CMM process model presented in this paper provides a set of comprehensive primitives to capture MEPs that implement business processes in VE by integrating SEPs of the enterprises participating in the VE. In particular, CMM supports an object-oriented activity model that enables to model services with application-specific states and operations. Through the separation of service interfaces from the service implementation companies, i.e., service providers, can participate in a MEP without compromising their autonomy in implementing the service. In addition, both application-specific states and operations foster conversational coordination among service activities. The CMM offers consequently a comprehensive and integrated framework for MEP specification and enactment that goes beyond the capabilities of approaches found in the literature. Nevertheless, related work offers partial contributions to the MEP problem. Reuse of existing services, which are proprietary and often implemented by legacy applications, both in intra- and inter-organizational settings has been subject of research and commercial efforts for many years. Several middleware technologies, e.g., CORBA [23] and messaging systems like MQSeries [ll], have been developed to enable programs to (re)use existing services. CORBA allows to wrap an existing service by an object interface that is specified using IDL. The IDL

454

DIMITRIOS GEORCAKOPOULOS

et al.

interface is implemented by a wrapper program that maps the interface methods to the proprietary implementation of the service. Equivalently, if a messaging system is used for integration, a service is represented by a wrapper based on a message interface that is also implemented by a specific wrapper program. Such wrapper technology is being used in workflow environments to integrate external application programs into workflows, e.g., [26, 221. However, interfaces service defined by CORBA or messaging middleware do not capture service semantics beyond the enumeration of methods or message types. In particular, explicit modeling of service execution states is not supported. Consequently, CORBA and messaging middleware do not provide a contribution to support conversational coordination of services used within a MEP. Therefore, these middleware systems may serve as an enabling technology, e.g., to implement CMM’s basic service activities, but they do not replace the CMM concepts. While wrapper programs are a generic technique to access arbitrary services from arbitrary programs, workflow-related standards [32, 28, 241 address interoperability issues in workflow processes. The proposed interoperability mechanisms enable a process to invoke activities that are implemented by another process within another WfMS. Consequently, these standards support MEPs that simply call SEPs of the participating enterprises. However, these standard models, as well as many traditional WfMSs (e.g., FlowMark [lo] and InConcert [12]), provide only the generic activity states and operations; they do not capture the application semantics of SEPs. They assume that activities are invoked once, enter their running state, and then produce no data until they are completed or terminated (stopped). Conversational coordination is not supported. These technologies do not meet the needs of complex services that offer a variety of (control) operations. In addition, there is no notion of abstracting common supertypes from semantically similar activities/services. The preliminary consensus in related research in process support for VEs and MEPs [l, 15, 191 is that traditional process technology as exemplified by current workflow standards [9, 24, 281 is not sufficient to meet the needs of VE. However, related work provides only marginal extensions to capture services. Alonso et al. [l] suggest an architecture to implement MEPs that includes, for example, a component that documents semantics of services offered by VE participants. However, they do not provide a concrete process model to be used by the proposed architecture. Ludwig and Whittingham [19] and Klingemann et al. [15] suggest gateways to bridge enterprise boundaries. Gateways allow for the compensation of simple heterogeneities between service providers, e.g., differing naming schemes for the same service, and decouples the MEP from the implementation of the SEPs. In addition, Klingemann et al. [15] extends the activity model for services and provides so-called “control and notification events”. This idea is somewhat similar to CMM’s activity operations and application-specific activity states. However, they do not concretize their service model. In addition, it does not support application-specific activity states, subtyping of activity state types and service interfaces, and conversational coordination of services like CMM. Application-specific activity states, which are a cornerstone in CMM for service modeling and conversational coordination, have been used also in several other workflow projects, but in ways that are virtually unrelated to our approach and not in a VE setting. We discuss them here for the sake of completeness. The MENTOR project (301 relies on activity and state charts to model workflows. As a consequence, control flow within a process activity is specified by transitions between the states of the process. Therefore, process activity states are just a side effect of the use of the state chart formalism and are not visible outside the process. Therefore, process states in MENTOR cannot be used for conversational coordination, i.e., states of SEPs would be hidden from the MEP and the MEP cannot defined coordination constraints among the states of its participant SEPs. In addition, MENTOR’s activity states strictly correspond with a process implementation; they do not constitute an abstraction of a process’ behavior as CMM’s activity states do. The METEOR system [17] utilizes task structures and inter-task dependencies for specification of transactional workflows. Task structures define transaction-related states of activities and therefore a kind of applicationspecific states. However, METEOR does not support state refinement and generalization as well as activity operations in order to deal with heterogeneous services, which is vital in a MEP setting. Finally, the MOBILE workflow model [13] provides application-specific activity operations together with a state transition diagram that defines valid activity operation invocation sequences. As in

Managing Process

and Service Fusion in Virtual Enterprises

455

MENTOR, activity states are private to an activity. Thus, neither conversation coordination nor activity subtyping are possible. In this paper, we have focussed on a process model that supports the definition of MEPs and allows for late binding of services, i.e., SEPs. However, we did not deal with the problem of service discovery and selection at runtime, especially if there are large numbers of service providers. This problem area is covered by research on service brokering and is complementary to our work, because CMM’s activity placeholder primitive-in particular the service selection policy-provides the hook to integrate brokers into the CM1 system. Work in service brokering deals with issues like (service) contracts among a client and a service provider to capture the semantics of a particular service offer [8], cost-based service advertising and selection [7], as well as reliability issues of broker information [5]. 9. CONCLUSION In this paper we discussed key CM1 capabilities to capture and manage MEPs. The CMM, in particular its SM, provides a set of novel process modeling primitives that support conversational services. SM enables the definition of abstract service interfaces, that specify application-specific service semantics based on application-specific states and operations. Conversational service coordination is solely conducted on the basis of the service interfaces. Thus, service definition is strictly separated from service implementation. As a consequence, MEP modeling can be conducted independently of concrete service providers which reduces the complexity of MEP management in a VE enormously. Heterogeneity of service providers is encapsulated by the service implementation, i.e., basic service activities and service wrapper processes. In addition, service interfaces build the foundation for dynamic service selection and brokering by allowing for multiple implementations of a particular service. Hence, the CMM offers a solution for MEP implementation that goes far beyond the capabilities of current workflow standards [24, 28, 321 and is more comprehensive than other research approaches [I, 7, 8, 15, 191. Due to space limitations, we did not discuss how MEPs can be monitored and how MEP CM1 also provides an Awareness Model as a participants are kept aware of important events. This model captures timely, highly relevant information and its delivery to CORE extension. MEP participants. Information in AM is specified and delivered as awareness events. Such events include activity state changes, resource status events, dependency instance status changes (such as establishment of synchrony), and combinations of these, i.e., composite awareness events. Delivery of detected awareness events can be directed to users in either global or scoped roles. The CM1 Awareness Model is discussed further in [2]. Another important issue for MEPs is synchrony which is also not discussed in this paper. CMM’s primitives for synchronous coordination are presented in [S]. As we discussed earlier, CM1 is a general purpose technology. In addition to MEPs and services in telecommunications applications we are currently experimenting with advanced applications in We are constantly discovering that MEP the crisis management and command control domain. problems exist even in situations where a single organization is in control. Thus, the CMM primitives and strategies used for MEPs may be more broadly applicable. REFERENCES (11 G. Alonso, U. Fiedler, C. Hagen, A. Lascano, H. Schuldt, and N. Weiler. Wise: business to business ecommerce. In Proc. 9th Int. Workshop on Research Issues on Data Engineering (RIDE-VE’99), Sydney, pp. 132-139, IEEE Computer Society Press (1999). [2] D. Baker, D. Georgakopoulos, H. Schuster, A. Cassandra, and A. Cichocki. Providing customized process In Proc. 4th IFCIS Conference on and situation awareness in the collaboration management infrastructure. Cooperative Information Systems (CoopIS’99), Edinburgh, pp. 79-91, IEEE Computer Society Press (1999). [3] A.R. Cassandra, D. Baker, and M. Rashid. Cedmos Complex Event Detection and Monitoring System. Technical Report CEDMOS-002-99, Microelectronics and Computer Technology Corporation, Austin, TX (1999). [4] DataBeam.

neT.f.20,

http://www.databeam.com/netl20/index.html

(1999).

[5] P. Fankhauser and T. Tesch. Agents, a broker, and lies. In Proc. 9th Int. Workshop on Research Data Engineering (RIDE-VE’99), Sydney, pp. 56-63, IEEE Computer Society Press (1999).

Issues

in

456

DIMITRIOSGEORGAKOPOULOSet al.

[S] D. Georgakopoulos, H. Schuster, A. Cichocki, and D. Baker. Collobomtion Management Infractmctum in Crisis Response Situations. Technical Report CMI-009-99, Microelectronics and Computer Technology Corporation, Austin, TX (1999). [7) A. Geppert, Coopemtiue

M. Kradolfer, and D. Tombros. Market-based workflow management.. Information Systems (IJCIS), 7(4):297-314 (1998).

Intemationol

Journal

on

In Pnx. 9th Int. Workshop on Reaeorch Issues on Data [8] Y. Hoffner. Supporting contract match-making. Engineering (RIDE- VE’99), Sydney, pp. 64-71, IEEE Computer Society Press (1999). [9] D. Hollingsworth. Workflow Management Coalition The Workfiow Reference Model. Workflow Management Coalition, Document Number TCOO-1003 (1994). [lo] IBM. IBM FlowMark - Managing [ll]

IBM. MQSeries

(121 InConcert. [13] S. Jablonski International

Your Workf7ow. Version 2.3 (1996).

Family. http://www.software.ibm.com/ts/mqseries/

InConcert.

(1999).

http://www.inconcertsw.com/welcome.htm

(1999).

and C. BuOler. Workflow Manogement - Modeling Concepts, Anzhitectunz and Implementalion. Thomson Computer Press (1996).

[14] J. Jupperi, A. Lethola, 0. Pihlajamaa, A. Sladek, and J. Veijalainen. Usability of some workflow products In Pmt. IFIP WG 8.1 Working Conference on Information Syrtems for in an interorganizational setting. Distributed Orgonizotions, nondheim, pp. 81-95, Chapman & Hall (1995). Deriving service models in cross-organizational workfiowz. In [15] J. Klingemann, J. W&h, and K. Aberer. Pmt. 9th Int. Workshop on Reeeamh Issues on Data Engineering (RIDE-VE’99), Sydney, pp. 100-107, IEEE Computer Society Press (1999). [16] M. Koskinen and P. Marttiin. Developing a customizable process modeling environment: Lessions learnt and future prospects. In Pmt. 6th Eumpean Workshop on Softwore Pmcess Technology (EWSPT’98), Weybridge, pp. 13-27, Springer (1998). [17] N. Krishnakumar and A. Sheth. Managing heterogeneous multi-system tasks to support enterprise-wide ations. Distributed and Pamllel Datatier, An Intemotionol Jouma(, S(2):155186 (1995). (181 F. Leymann and W. Altenhuber. Joumcl, 95(2):326-348 (1994).

Managing

business

processes

as an information

resource.

oper-

IBM Systema

[19) H. Ludwig and K. Whittingham. VirtuaI enterprise coordinator - agreement-driven gateways for crozsorganizational workflow management. In Pmt. Int. Joint Confenxnce on Work Activities Coordination ond Collabomtion (WACC’99), San Francisco, pp. 29-38, ACM Press (1999). [Zo] T. Malone. Managing processes in the networked economy. Coordination and Coffabomtion (WACC’99), San Francisco, [21] Microsoft.

NetMeeting

In Keynote Int. Joint Conf. on Work Activitier p. 241, ACM Press (1999).

Veraion 2.1. http:// www.microsoft.com/netmeeting/

(1999).

[22] P. Muth, J. Weissenfels, M. Gillmann, and G. Weikum. Integrating light-weight workflow management systems within business environments. In Proc. of 15th Intemotionol Conference on Data Engineering (ICDE’99), Sydney, pp. 286-293, IEEE Computer Society Press (1999). [23] Object Management 2.2 (1998).

Group.

The Common Object Request Broker: Architecture

[24] Object Management Group. OMC Workflow Management Number bom/9&06-07 (1998). [25] H. Schuster.

Architektur

uerteilter

Foci&y,

Workflow-Management-Syrteme.

and Spccijkation,

Revised Submission,

Revision

OMG Document

DISDBIS 50. Infix (1998).

[26] H. Schuster, S. Jablonski, P. Heinl, and C. BuBler. A general framework for the execution of heterogenous programs in workflow management systems. In Pmt. First IFCS Int. Conf. on Coopemtive Information Syrfenw (CoopIS’96), Brussels, pp. 104-113, IEEE Computer Society Press (1996). (271 M. Shapiro. Structure and encapsulation in distributed systems: The proxy principle. In Pmt. of the 6th Int. Conf. on Distributed Computing Systems, Cambridge, pp. 198-204, IEEE Computer Society Press (1986). [28] SWAP Working Group. Simple WorkpOw Access Protocol (SWAP). http://www.ic.xuci.edu/‘ietfswap/ [ZQ] M. Us&old, M. King, S. Moralee, and Y. Zvrgios. The enterprise ontology. Speciaf Iuare on Putting Ontologier to Use, 13(1):31-90 (1998).

(1998).

The Knowledge Engineering Review,

(301 D. Wodtke, J. Weiasenfels, G. Weikum, and A. Kotz Dittrich. The mentor project: Stepe towards enterprisewide workflow management. In Pwx. 1Zth Innt. Conference on Data Engineering, New Orleans, pp. 556565, IEEE Computer Society Press (1996). [31] Work5ow Management Coalition. Workf7ow Monogement Application Pmgmmming Interface (Interface 2M) Specification, Document Number WfMC-TC-1009, Version 2.Oe (1998). [32] Workflow Management Coalition. Workflow Monogement Coalition Interface 1: Process Definition Prucerr Model, Version 7.04, Document Number WfMC TC-1016-P (1998).

intemhange