Distributed Architectures for Process Component Support Kevin A. Gary Electrical Engineering and Computer Science Department The Catholic University of America Washington, D.C. 20064
[email protected]
Tim Lindquist Computer Science and Engineering Department Arizona State University Tempe, AZ 85287-5406
[email protected]
ABSTRACT Component-based process support holds promise for building dynamic, interoperable, and reusable processes. We have espoused the benefits of this approach in other forums by presenting the Open Process Components Framework. Assuming one accepts component-based process support as a viable alternative, the question then becomes: how does one provide a distributed, scalable architecture for process components? We attempt to answer this problem by proposing a set of mechanisms for distributed, component architectures. We demonstrate the natural mapping of logically centralized components to distributed component implementations through the wrapping of a commercial-off-theshelf process tool. We hope that this paper sheds light not only on issues in component-based process architectures, but also contributes to the general discussion of how to build process architectures that scale in a widely distributed environment.
hope to show that process components naturally lend themselves to a distributed architecture. The next section will provide a brief overview of process components. Section 3 presents mechanisms for a distributed architecture for process components. Section 4 describes an implementation of process components in OPC that utilizes a Commercial off-the-shelf (COTS) process tool. 2. PROCESS COMPONENTS In order to discuss architectures for component-based process support, one must first understand what a process component is, and how the traditional activities of process modeling and enactment are performed in a componentbased environment. This section will briefly review the OPC framework. 2.1 Process Components
Keywords: Process Component, Software Process, Tool Wrapping, Distributed Architectures.
OPC offers the following definitions:
•
Process Component - a process component is an encapsulation of process information and behaviors at a given level of granularity.
•
Component-based Process Model - a component-based process model is a collection of process components that interact in meaningful ways. A component-based process model is itself a process component.
•
Component-based Process Enactment - componentbased process enactment refers to the creation of a component, the dynamic evolution of the component, its interaction with other process components, and its interaction with users and an environment in which the component is situated.
1. INTRODUCTION Open Process Components (OPC) is a framework for supporting component encapsulations of the process space. Process fragments are encapsulated behind component boundaries which provide a uniform means of interacting with process information. We have presented the Open Process Components approach in other forums [5][6], and discuss the merits of this approach for providing interoperable and reusable process models. Our attention in this paper turns to the problem of supporting process components in a distributed, scalable fashion. How does one provide a distributed, scalable architecture for process components? How does such an architecture compare to reference architectures in the literature? We
It is important to note that our notion of a component differs from how others apply component-based software design to
process. Specifically, our approach is a componentization in the process model space, and is not a componentization of process-supporting architectures. In this sense, our approach is similar to the Pynode [1] and DartFlow [3] projects, but unlike the Oz [2] project. A process component is an encapsulation of process information and behaviors at a given level of granularity. The process information is expressed in whatever formalism or language is used to represent the semantics of the component. OPC separates this information three ways: process schema, process states and transitions, and process implementation (see Figure 1). The process schema defines a vocabulary for the component, identifying entities and relationships that have meaning for a particular component. OPC defines a minimal, extendable, common schema for components. Process state and transitions between states are represented as a finite-state machine. The set of process states and valid transitions are defined per component, with a common set of meta-states identified within OPC. The process implementation is the underlying representation of the component and the machinery which interprets this representation. This may be a petri net, a process programming language, or whatever other means are used to represent process semantics. It may also be a process tool that has been wrapped to provide the process implementation, as we will show in Section 4. The implementation is encapsulated within each component, so that components interact without requiring homogeneous representations.
Meta-views Definer
a m he sc
Performer
state
n tio a t en lem p im
Observer
Owner
FIGURE 1. A process component OPC’s schema includes process Roles, which help bind process Agents to Processes. Traditional treatments of Roles assume a Role defines the set of performers of a process, and hence have a one-to-one relationship with a Process entity. In OPC, Process and Role entities engage in a one-tomany relationship, with each type of relationship referred to as a meta-role. This allows a separate Role to be identified for definition, enactment, ownership, or observation. Since there are different meta-roles which interact with a component, there are then different views of the process that a
component exposes to each Role, called meta-views. For example, a process performer is a meta-role which is not allowed to interact to access the definition view of a component. 3. PROCESS COMPONENT ARCHITECTURE CONSIDERATIONS OPC encapsulates process information and behaviors within process components. A component does not act in isolation to carry out the process; instead it must interact with other components and the outside world. These interactions require a supporting architecture and communication mechanisms for interacting with components. This section provides a high-level overview of OPC’s process component architecture. 3.1 Component Interaction Mechanisms An OPC process component supports three mechanisms for interaction: 1. Methods - a process component supports a standard set of methods derived from its process schema and process state transition graph. These methods define behaviors for modifying the process schema and the state transition graph, and enacting the process. 2. Messages - a process component can be sent a message requesting that the component change process state. OPC defines a message type and a message receiving method on a process component. When a component receives a message, it checks that the message is a request for a valid state transition, and if so, executes the transition. 3. Events - a process component generates and receives events. A component typically generates an event when its process state changes, or if its binding information changes. A process component with subprocesses typically receives events indicating when its subprocesses’ process states have changed. OPC provides a small number of standard event types and a rudimentary event service for components. Components and the supporting architecture make wide use of the event service and their own event types for arbitrary communication. 3.2 Process Component Contexts Process components are situated; at any given time a process component resides in some environment and interacts with that environment, and also with a meta-role and other process components. The situation a component is currently in is called the component’s context (see Figure 2).
Component Repository: A process component repository
FIGURE 3. OPC process component architecture FIGURE 2. Components and Contexts
As shown in Figure 2, a component context is important in that it brings together the concepts of meta-roles, metaviews, and component environments. A component is situated in an environment, acted upon by a meta-role, and presents a meta-view of itself. Meta-roles, meta-views, and environments may be extended in arbitrary ways. For example, a meta-role Measurer can be added with the relationship is_measurer added to the process schema. A corresponding OPCMeasurerTool could be provided, and given a reference to an OPCMeasurerEnv. OPC provides a general interface on components for retrieving named tools of arbitrary types. There is not necessarily a one-to-one mapping between meta-roles, meta-views, and environments. There may be many Roles identified as performers or definers of a particular component. A component may also provide more than one performer tool or more than one definer tool. Similarly, more than one instance of a performer environment may exist in a given context. Finally, it is tempting, but incorrect, to think of an environment as a client-side tool like a Worklist Handler. As the next section shows, multiple environments may exist within a single container, and this container should be thought of a participating in a distributed peer architecture, where different architecture components host different process components at different times. 3.3 Architecture Support for Process Components In traditional process support systems, process models are defined in process definition tools, stored in process repositories, instantiated and interpreted by process engines, and linked to users via electronic to-do lists. These are essentially the architecture components described by the WfMC’s Workflow Reference Model [7]. A component-based approach to process implies variations on this architecture. We discuss the notions of component repositories, component containers, and an event service in this section.
is a logically centralized container of process components and domain-specific process information. The process component repository provides a persistent store of process component references. The repository provides locationtransparency for components by providing a way to reference named process components that may or may not be physically managed by the repository. The repository also manages references to domain-specific information, such as specific users (Agents), and data storage (Product) management facilities. Component Containers: Client programs interact with the repository, but not directly with components. As explained above, meta-roles interact with meta-views (tools) of a component in some environment. In order to interact with a component, the client program requests a meta-view for a named component from the repository, and provides the component with the proper environment reference. The component then interacts with the environment, and may also rely on the client application for presentation services. Therefore, a client program hosts components, and provides them with environment references so they can interact in the environment. Note there are two relationships involved here. One is a client-server relationship between the client program and the repository, the second is a peer-to-peer interaction between component meta-views and environments. A software application that hosts components is a component container. The process component repository is an example component container. An object (or objects) that has the ability to host components, present components’ tools, and provide components with appropriate environment references is a container. Component containers provide environment-independent information, such as temporary directories and presentation resources. Environment-dependent information is provided by the respective environments. Containers do not interact with components directly, and do not perform process-specific interactions with components. Therefore, OPC does not specify an interface for component containers. It is important conceptually however, to realize that a component is always logically contained somewhere1.
Event Service: One of the communication mechanisms for a component is an event. An event may be generated by a process component to indicate a change in process state, a change in the component’s schema (bindings), or a failure of the component to perform some operation. OPC does define a small number of commonly used events. Components are free to define other domain-specific events as they see fit. Events that are used to communicate information between two or more process components are referred to as process events. All events do not have to be process events. Events may be used to communicate between any objects in the OPC system. For example, the repository is typically interested in events having to do with schema modifications of the components it stores, so that it may update its set of references. A process component’s meta-view tool registers interest in events that happen to the underlying component so that it may update its presentation of the component when the component’s state changes. OPC defines a rudimentary third-party event service. The event service allows objects implementing a particular interface to register interest in events. Any object may generate an event, it simply notifies the event service when an event occurs. The event service then notifies registered objects interested in the type of event that the event has occurred. Several different middleware layers, such as CORBA, Microsoft’s MAPI-WF, and Enterprise JavaBeans hold potential for realizing scalable component-supporting architectures. Our current implementation of OPC uses Java’s RMI facility as the underlying distribution mechanism. Section 4 discusses an application of OPC on top of RMI. 4. EXAMPLE: WRAPPING PROCESS WEAVER This section presents a wrapping of the COTS process tool Process Weaver [4] from CapGemini. Process Weaver was wrapped using Java’s RMI facility to provide an implementation for OPC process components. This shows an example of a logically centralized component whose actual implementation is distributed. 4.1 Process Weaver Process Weaver employs a modified petri net formalism for process modeling. Process models are specified as cooperative procedures, and work is presented to users in work contexts. Process Weaver is a distributed, client-server process support system. Distribution is supported by a message bus running over TCP/IP known as the Broadcast Message Server (BMS). Client and server tool components hook into the message bus to send and receive messages. The clientside also runs a separate BMS to support local communication between client-side tool components and third-party
1. “Logically somewhere” meaning not to imply applets, agents, or any other form of mobile code is mandatory.
applications. The Process Weaver architecture is shown in Figure 4. wcedit Local Storage
user tool
U S E R
cpedit
P
R
O
C
E
S
W
teh
Process Repository cp starter
B M S
aim
S
E
agenda
A
V
E
R
clock
coshell interpreter
CLIENT
cp interpreter
B
M
S
tracer
SERVER
FIGURE 4. Process Weaver architecture
Figure 4 shows the Process Weaver and User BMSs, client and server-side tool components, and repositories on both the client and server-sides. The Process Weaver BMS, CoShell interpreter server-side tool component, and Process Repository are relevant to the OPC wrapping of Process Weaver. The Process Weaver BMS is the primary vehicle for client-server and intra-server communications. The BMS defines asynchronous communication between tools. Process Weaver uses a proprietary scripting language called CoShell (for Cooperative Shell language). Process Weaver provides CoShell functions for USM file manipulation and for hooking into the BMS. USM (Universal Storage Mechanism) is a file format for storing process relevant information, including process models (cooperative procedures) and process instance presentations (work contexts). The OPC Process Weaver wrapper uses a CoShell interpreter process to interact directly with Process Weaver server tools. Process Weaver maintains a repository of process information using the Unix file system. Process information is stored in USM-formatted files under a predefined Unix directory tree. The Process Weaver wrapper makes use of the predefined directory structure to perform repository lookups. 4.2 OPC Wrapping of Process Weaver The OPC to Process Weaver wrapping architecture is shown in Figure 5. The wrapper exposes Process Weaver through an RMI interface, PWService. PWService defines methods for listing cooperative procedure models and instances, creating cooperative procedure instances, changing the process state of a cooperative procedure instance, retrieving a cooperative procedure or work context, and updating a work context. Process components, process component metaviews, and the OPC process component repository all invoke methods on this service.
requests to a PWOPCWrapper object. Requests requiring a CoShell function invocation are in turn delegated to a PWCoShellWrapper object. A PWCoShellWrapper object
The object model of the server-side implementation of PWService is shown in Figure 6. The RMI server implementation object, RMIServiceImpl, delegates service
PW Service
OPC Repository
lis cr ting ea s tio , n
I RM coshell interpreter
m
PW Service
-view
s
imple
ion entat
M
S
meta
B
Process Weaver Repository
USM
USM
USM
SERVER
CLIENT
FIGURE 5. OPC Process Weaver wrapper architecture maintains a Java Process object running a coshell interpreter. The input and output streams of the system process
are used to invoke CoShell routines in the interpreter and receive results.
Remote
Unic as tRemoteObject
< < Interfac e> > PW Se rvice
RM I interface
delegates PW ServiceIm pl
Process p = Runtim e.get Runtime().ex ec ("c os hell");
coshell_calls PW OPCW rapper
1..1
1..1
PW CoShellW rapper 1..1
1..1
FIGURE 6. Process Weaver RMI service object model
1..1
Process 1..1
OPC encapsulates USM files behind object interfaces, and uses these objects for both presentation and process data integration. These interfaces are defined as the Java classes CPObject and WCObject, for cooperative procedures and work contexts respectively. Presentation of cooperative procedures and work contexts is done through CPTool and WCTool objects respectively. A CPTool (WCTool) takes a CPObject (WCObject) in its constructor, and creates a presentation of the cooperative procedure (work context) as a
Performer meta-view tools respectively. Figure 7 shows the object model relationships between CPObject, WCObject, CPTool, WCTool, and the OPC meta-views (the tool interfaces).
Java panel1. CPTool and WCTool serve as the basis for Process Weaver Representation Layer specific Observer and
1. Specifically, a Java Swing JPanel. CPTool and WCTool derive from JPanel in the current implementation.
O P C To ol
OP CP ro c es s P erfo rm erT ool
O P C P ro c e s s O bs e rve rTo ol
O P C P ro c e s s Defin ition To ol
O P C P ro c e s sO wn e rT o ol
P W P e rfo rm e rToo l
P W O bs erverTool
P W De fine rTo ol
P W O wn erToo l
1..1
1..1
s h ows _wc tx
s ho ws_ cp
0..1 W CT o ol
s h ows _c p 0 ..1
us es _U SM _w rapp er 1..1
W C O bjec t
1..1
1 ..1
0 ..1
1..1
s ho ws _cp
0..1
CP To ol
us es _U S M_ wrapp er 1 ..1
CP O bjec t
1..1
FIGURE 7. Process Weaver meta-views object model
The Process Weaver wrapper implementation gets quite involved due to the lack of a high-level API in a widelyused programming language (CoShell does not qualify), the lookup of repository information using predefined (hardcoded) Unix directories, the need to parse and modify USM files, the need to interface with the BMS, and the asynchronous nature of the BMS. The ability to wrap Process Weaver, or any process tool in OPC, is a function of the tool itself, not by the process of componentization. This is because a component must still access an underlying implementation, and that implementation, if provided by a process tool, is accessed by whatever means the tool makes available. Despite the complexity of wrapping Process Weaver, conceptually the important point remains that the component implementations are provided by a distributed service by a COTS process tool, and that the details of these implementations are transparent to the end user through componentization in OPC.
[2.]
[3.]
[4.] [5.]
5. REFERENCES [1.]
Avrilionis, D., Belkhatir, N., and Cunin, P. A Unified Framework for Software Process Enactment and Im-
[6.]
provement. Proceedings of the Fourth International Conference on the Software Process (ICSP4). December 1996. Ben-Shaul, I. and Kaiser, G. An Interoperability Model for Process-Centered Software Engineering Environments and its Implementation in Oz. Technical Report CUCS-034-95, Computer Science Department, Columbia University. 1995. Cai, T., Gloor, P.A. and Nog, S. DartFlow: A Workflow Management System on the Web Using Transportable Agents. Technical Report PCS-TR96-283, Dept. of Computer Science, Dartmouth University. 1996. Cap Gemini Sogeti. Process Weaver Reference Manual, Version 2.1. 1995. Gary, K., Lindquist, T., Sauer, L., and Koehnemann, H., Automated Process Support for Organizational and Personal Processes. Proceedings of the International ACM SIGGROUP Conference on Supporting Group Work (Group97), pp. 221-230. November 1997. Gary, K., Lindquist, T., and Koehnemann, H. Component-based Process Modeling. Proceedings of the
[7.]
13th International Conference on Automated Software Engineering, IEEE Computer Society, Honolulu, Hawaii. November 1998. The Workflow Management Coalition. The Reference Model. WfMC Document Number TC00-1003, January 1995.
