../oopsla97/OOPSLA'96OOPSLA'98 Business Object Workshop IV

Building Workflow Business Objects

Marc-Thomas Schmidt, IBM Software Group, mts@uk.ibm.com

 


Abstract

OMG is in the final stages of defining the Workflow Management Facility. This facility represents an important building block for the emerging OMG Business Component Framework; it provides a framework for workflow business components which enable realization business processes in a business component environment. Workflow components take care of the overall process logic of a business process, enable monitoring of workflow execution and support flexible combination of reusable business components into workflow applications.

We will describe the key concepts of the Workflow Management Facility specification, discuss implementation options for this facility and explain how to build distributed workflow applications within the framework of such a facility. In addition, we will discuss future extensions to the workflow standard in the areas of resource management and workflow process definition.

Workflow Business Components

A business component can be defined as an entity that realizes a business concept. A lot of progress has been made over the last couple of years in defining (and implementing) frameworks that support definition of business components, interaction of independently developed components, and deployment of these components into different runtime infrastructures ([OMG98c], [OMG97c], [EJB98]). These frameworks focus on the 'generic needs' of business components with respect to persistence, transactions, security, life cycle, concurrency, etc..

Workflows are business components in the sense that they realize a business concept (that of a business process) and as a consequence are long-lived, persistent, transactional entities. However, the nature of the business concept they realize implies some specific requirements on the realization of workflow components. A workflow application implements an abstract business process model which describes the process steps that have to be performed to achieve a specific business goal according to well defined business rules and the respective  responsibilities of process participants (e.g., people involved in the process). The various process steps in a business process can be realized by elemental business components that perform the specific business transactions. These elemental components primarily encapsulate operational business data and support operations that manipulate these data; often their persistent state is provided by a legacy datastore or application. These components are designed to provide a stable set building blocks for more complex components and applications. The primary task of workflow components is the coordination of elemental components to achieve a business goal according to the business rules defined by the underlying process model. In contrast with elemental business objects, the state of a workflow component is defined by the state of the underlying process and rather than manipulating operational business data itself it uses more elemental business components to perform these transactions.

The following is a list of requirements on workflow components that enable realization of business processes (see also [Paul97], [Schulze97]):

Figure 1: Business Process realization by Workflow Components

The importance of workflow technology in a business component environment as a means for 'coarse grained scripting' of business components is a well known fact (see for example ([Ley95]). In this paper we describe a framework for realizing this concept in a business component infrastructure.

The jointFlow specification

The jointFlow specification ([OMG98a], [OMG98b]) is a submission by 19 companies in response to OMG's Workflow Management Facility RFP ([OMG97a]); the specification is based on the work of the Workflow Management Coalition (see [WfMC95], [WfMC98a], [WfMC96a], [WfMC96b]). The submission was recommended for adoption by the Business Object DTF and the Architecture Board at the OMG meeting in July 1998.

The specification defines interfaces that support runtime interaction with workflow components, enable interoperability of workflow components across business domains and allow for monitoring and auditing of workflow processes (see Figure 2).
 

Figure 2: jointFlow Interfaces

Workflow Composition

A WfProcessManager serves as a factory for instances of a particular workflow process type (e.g., ProcessCreditRequest); the interface provides operations to create instances of the particular process type and access to meta information on process attributes (context and result).

Since jointFlow primarily addresses interoperability and monitoring of workflow components, the specification does not deal with definition of workflow process models; as a consequence, there are no capabilities to explore the structure of a workflow process model associated with a process type managed by a WfProcessManager. It is assumed, however, that a process model is made up from a set of process steps that are activated according to the process logic defined by a workflow process model. The process steps are visible as workflow activities associated with a process instance; the process logic that coordinates interaction of the process steps is realized in an implementation specific way (see the section on 'Building Workflow Applications' for a discussion of implementation options).

The WfRequester interface is implemented by entities that request execution of a business task (i.e., a workflow process); it provides operations to report status changes of a workflow instance back to its requester. This allows the workflow initiator to observe progress of process execution and to receive an indication of completion of a process.

A WfProcess represents an instance of a workflow process type and is implemented by all workflow entities which perform a business task. The interface provides operations to control process execution (e.g., start, suspend, abort) and to access process attributes (state, context and result). The state attribute describes the current state of execution of the process (e.g., running, suspended, completed). When a process is created it is associated with a workflow requester and its context attributes are initialized with information describing the concrete business situation it is applied to (e.g., customerName and creditAmount for a ProcessCreditRequest process); the context can be updated at a later point in time  if necessary. While it is active, a process collects process results that describe progress of the process and can be retrieved when it is completed (e.g., creditApprovalStatus). Whenever the status of a process is changed, an event audit record is created that records information about the nature of the change (see discussion of the WfEventAudit interface below) and the requester associated with the process is informed; status change event can also be published as structured events using the OMG Notification Service ([OMG98e]) to other observers of the workflow process. A workflow process contains a set of workflow activities which represent the process steps of the corresponding process type; this set may be empty. If an entity implementing the WfProcess interface does not contain workflow activities this basically means that the internal structure of the process is not exposed and that the entity performs the business task without delegating sub tasks to other components (see the discussion on 'workflow fakers' below).

A WfActivity represents a process step in a workflow process or a request for execution of a business task in the context of a workflow process; for example, a ProcessCreditRequest process might have activities EvaluateRequest, ApproveRequest and SendMoney. The interface provides operations to control execution of a process step (suspend, abort) and to access activity attributes (state, context and result). The state attribute describes the current state of execution of the activity (e.g., running, suspended, completed); an activity is activated according to the process logic of the in the underlying process model; status changes of the owning workflow process can effect the state of an activity (e.g., it is suspended when the process is). The context attributes define the process context the activity is operating in (e.g., creditHistory and creditAmount for the ApproveRequest activity); the context is initialized using process attributes when the activity is activated. The result attributes describe the results produced by an activity (e.g., approvalStatus for the ApproveRequest activity).

A workflow activity has several facets: it serves as an adapter that enables composition of workflows from other workflow components and (as a representation of a process step in the underlying process model) it is an 'atomic unit' from a monitoring and resource assignment perspective.

From an interoperability perspective, a workflow activity represent an adapter for a workflow component that implements the activity; the WfActivity interface specializes the WfRequester interface and can be registered with a workflow process which performs the work requested by the activity. The context of the activity defines the context of that process, the result produced by the process defines the result of the activity, and the activity is completed when it receives a completion notification from the associated process. Activity adapters can be used to realize distribution of complex workflow across business domain boundaries; the main process delegates execution of parts of the overall process model to sub-processes that interact with the main process using activity adapters. The '(activity) requester-process' pattern is very useful to decouple elemental requests for work in a process from their implementation; it allows for replacement of an activity implementation without affecting the main process (see the section on 'Implementing Process Steps' for a more detailed discussion).

It is important to note that not all activities must be associated with a workflow process implementation. The requester-process pattern is used when there is a need for explicit delegation of the execution of the task represented by an activity to an entity that is potentially outside of the scope of the workflow process owning the activity. Alternatively, an activity can be implemented by an application that uses explicit operations on the WfActivity interface to set activity results and to complete the activity (see the discussion activity implementations in the section on 'Building Workflow Applications').

Workflow activities can be associated with resources that are required to perform the work request represented by the activity. This can be used, e.g.,  to assign an entity in an organization model that is responsible for execution of a process step.

From a workflow monitoring perspective, workflow activities describe the internals of a workflow process (as far as these internals are exposed by jointFlow); for each process step in the underlying workflow process model there is one workflow activity representing that step. The full status of a workflow process is given by the overall state of the WfProcess and the states of all of its WfActivities.  An activity is the smallest observable entity in a workflow process. Status changes and changes in the resource assignment of an activity are reported via event audit records; status change event can also be published as structured events using the OMG Notification Service to other process observers.
 

Figure 3: Workflow Composition and Resource Assignment

Resource Assignment

A WfAssignment represents the association of an activity with a workflow resource; several resources can be assigned to an activity and the same resource can be assigned to several activities. The status attribute of an assignment can be used to indicate the specific nature of the assignment. The set of WfAssignments associated with an activity basically defines the resources the activity needs to perform its task; these resources are used by the implementation of the activity. Resources may include people that provide input for the process step (e.g., a clerk providing a credit assessment for an EvaluateCredit process step), IT resources (e.g., a server needed to execute an application), or information resources (e.g., a CAD document that needs to be made available to perform a task).

Workflow assignments can be used to realize various collaboration patterns of workflow participants; for example, different participants could contribute to the overall result of an activity or an activity might be offered  to potential contributors assuming that one of them will take responsibility for execution of the work request. Coordination of the resources associated with an activity is left to the implementation of the activity or its owning process. Workflow assignments can also be used to realize work lists for people involved in workflow process execution; the work list of a person would show a list of all WfAssignment associated with the resource representing that person.

The WfResource interface is implemented by resources involved in processing of workflow processes; it serves as a generic place holder for an entity in a resource model and is expected to be specialized by implementations of the Workflow Management Facility (potentially using a Resource Management Facility). Specification of a resource model as well as definition of resource assignment rules is outside of the scope of the jointFlow specification (see the section on 'Building Workflow Applications' for a discussion on resource selection).

Process Monitoring and Auditing

The WfEventAudit interface defines the information to be recorded when a workflow process or an activity changes its state (e.g., 'activity ApproveRequest completed'); subtypes of the interface are defined for specific types of status changes (execution state, context or result attributes, resource assignment). A mapping of event audits to structured events as defined by the OMG Notification Service is defined to allow publication of workflow events (workflow processes and activities are StructuredEventPushSuppliers); WfEventAudit entities represent persistent versions of these structured events that can be retrieved for analysis later. Event audit entities are associated with the source of the event; the set of events produced by a process or activity constitutes the execution history of the workflow entity. The lifetime of an workflow audit entity is not limited by that of its source; this allows for analysis of workflow process performance history. Workflow events can be used for monitoring and auditing of workflow performance:

Building Workflow Applications

The jointFlow specification defines interfaces of a framework for realization of workflow process models. It defines the interfaces necessary to enable interoperability of workflow process components, workflow monitoring and for linking workflow components to resources involved in a workflow process. It does not define details of interaction of the workflow entities that are irrelevant in support of these goals; this allows for a broad spectrum of implementation of the WfM Facility and enables, e.g., workflow processes realized in a 'classical' Workflow Management System to interoperate with workflow process components developed as autonomous business components.

The following discusses options for the implementation of this framework and exploitation of the framework for realization of workflow applications.

Workflow Business Objects

As discussed in the introduction, workflow components are business objects. jointFlow intentionally does not address the general aspects of business component management and focusses on the specifics of workflow business components. Since the work in OMG on the definition of a base framework for business components has not been finished yet, jointFlow uses a very simple 'business component model' that serves as a place holder for a future OMG Business Component Framework specification; basically, all jointFlow entities are transactional, identifiable, life cycle objects and relationships between entities are realized using a generic pattern for enabling relationship navigation.

The basic assumption is that workflow components will be deployed in a business component infrastructure which provides mechanisms for efficient management of persistent, secure, transactional entities and enables interaction between independently developed business components. We refrain from speculating about the shape of this infrastructure here, but will discuss potential applications of some of the concepts defined in the Business Object Interoperability Framework proposal {[OMG98c]) and in the Enterprise Java Beans specification ([EJB98]) in the following sections.

In an EJB infrastructure, for example, the entities defined by jointFlow would be entity beans that are deployed into EJB containers; containers could take care of the persistent state of workflow processes, activities, assignments and event audit entities, providing different back ends for these entities. The container model basically enables deployment of the realization of a workflow process model into different runtime environments (see also the discussion on workflow process implementation in the next section), enabling reuse of workflow processes in different installations. EJB homes would enable applications to create and locate workflow entities; this could be used, for example to realize process history analysis applications using specialized 'find' operations on the home of workflow event audit entities.

The concepts for enabling interaction of business components defined in the Interoperability Framework could be used for integration between workflow components and other business components. Workflow components could be used as building blocks for business applications, e.g., to delegate execution of a complex operation in an application to a workflow process; and, of course, business components can be used to implement process steps in a workflow process (see the discussion of process step implementations below).

Implementing Workflow Process Models

From a jointFlow perspective, an instance of a process model is represented by a workflow process and its associated workflow activities; it is assumed that these entities cooperate to realize the process goal according to the business rules defined in the underlying process model. The jointFlow specification does not define details of interaction between workflow process and activities since this is not relevant for workflow interoperability; the realization of this interaction is left to implementations of the Workflow Management Facility. The following discusses several options for the representation of workflow process models in the jointFlow framework.

Workflow Engine Backends

A Workflow Management Facility can be realized based on existing workflow management systems (WfMS). Execution of a workflow process by a WfMS is driven by a generic workflow engine that interprets the workflow process model at runtime in order to create and enact workflow instances.
In this scenario the WfMS takes care of the persistent state of the workflow components. The workflow engine interprets the workflow process model and coordinates status changes of the associated workflow process and its activities (see scenario A in Figure 4). In this model, the workflow entities have no knowledge about the underlying process model; they pass on status change requests to the backend engine which determines the resulting status changes and updates the corresponding entities. A process start request, for example, would be received by a WfProcess, passed on to the backend which decides which activities should be activated, initializes their context, changes their status, potentially requests instantiation of other workflow processes that implement activities and waits for future status change reports from these activities.
Event Audit records and publication of status changes via notification can be handled by the WfMS backend or can be left to individual workflow components since this requires only 'local' knowledge about the specific entity. A WfMS often provides capabilities to maintain process history information; this facility can be used to hold the persistent state of WfEventAudit entities.
Figure 4: Workflow Component Interaction Models

Distributed Workflow Components

Workflow processes and activities can be implemented as business objects that encapsulate the process logic of the underlying workflow process model. Code generators might be used to translate the process model into a set of templates for workflow components. There are various options for distribution of processing logic between the workflow process component and its workflow activity components and for realization of information exchange between these components.

Information exchange between the workflow entities can be realized via a 'private' interface extending the WfProcess and WfActivity interfaces interface with operation to signal status changes; alternatively, the Notification Service can be used for this communication by specializing the WfProcess and WfActivity interfaces into StructuredEventPushConsumers that register their interest in status changes change events published by related workflow entities (WfProcess and WfActivity are StructuredEventPushSuppliers).  Another option would be to use the 'managed relationships' mechanism proposed in [OMG98c] where business components on the two ends of a relationship exchange information about their respective status changes.

There are several potential models for distribution of the process logic defined in the underlying workflow process model; we discuss two variants in more detail:

Implementing Process Steps

The jointFlow specification basically provides two ways for realization of a workflow activity: if there is a need for 'loose coupling' between the activity and its implementation, the activity would be implemented by another, 'remote' workflow process; otherwise, it can be implemented by a 'local' component. In both cases, the underlying workflow process model can provide information to be used to identify the components to be used to implement the activity. The following discusses details of interactions of a 'request for work to be done within the context of a workflow process' with components that do the work.

Workflow Process implementation

The activity adapter enables composition of independently developed, autonomous workflow components. The 'requester - process' pattern defines the interaction between the components, the activity specialization of a requester serves as a process context specific mediator between the main process and other workflow components. The decoupling of main process and its workflow components makes it easy to change one side of the interaction equation with out affecting the other one: the realization of the process step can be modified as long as it still provides the service requested by the activity; changes in the main process can be hidden from the process step implementation by changing the activity adapter accordingly. The role of the activity in this interaction is to:
  1. Find an appropriate workflow component that realizes the process step
  2. Initialize the remote workflow process using context data of the main process and start it
  3. While the remote process is active, propagate changes of activity execution state to the remote process and observe status changes of the remote process
  4. When the remote process to signals its completion, translate the results of the remote process into process attributes of the main process and signal completion of the process step
The underlying workflow process model will provide information on how to find an appropriate workflow process manager for realization of the process step. Often this will simply be the identifier of a particular workflow process type represented by a WfProcessManager; in this case the activity would locate the process manager using, e.g., the CORBA Naming Service or an EJB process manager home (using the identifier of the home and that of the particular process manager). If greater flexibility in selecting a process manager is required, advanced locator facilities such as the OMG Trading Service could be applied, using selection criteria defined by the underlying process model. The activity adapter can use the meta information about the context and result attributes of the remote process to translate between the context of the main process and the requirements of the remote process.

It is important to note that any business component implementing the WfProcess interface can be used as an activity implementation; this basically means that it must provide operations to initialize and start it and it must signal its completion back to the requester. The component might, for example, represent a wrapper for a legacy application; in this case it would not contain any activities and would have a very simple state model (running and completed). In an EJB environment, the home of the component could realize the process manager interface. The jointFlow specification allows realization of this kind of 'workflow process faker' to enable integration of a broad range of 'process components' into workflow applications.

Business Component implementation

The 'requester-process' pattern is used for interactions between an activity and components outside of the scope of the main workflow process. In many cases, a process step can be realized by an application within the scope of the workflow process. In this case there is no need to associate a WfProcess with the corresponding activity; instead, the implementation of the process step uses operations of the WfActivity interface to obtain the activity context, perform its task, set the result of the activity and signal completion of the process step.

Often, the work requested by an activity can be performed by an operation on an existing business component; in this case, the implementation of the activity can be derived from information provided in the underlying process model. The pattern would be the following: The process model contains information on how to find the appropriate component and which operation to invoke; in the case of an EJB entity bean the identifier might be the identifier of the home of the bean and the bean's primary key relative to that home. The process step implementation would locate the component, set the input parameters of the appropriate operation, invoke the operation and update the activity results according to the result returned by the operation.

In a more complex situation, several elemental business components might be required to perform the task represented by an activity. The business logic enabling the cooperation of these components can be 'scripted' in a variety of ways. One option would be to realize it as another component (eventually a 'light-weight' one, such as an EJB session bean); in this case the pattern described above can be applied. Note that even though the realization of an activity might involve a set of components, the activity represents an 'atomic unit' from the perspective of a workflow.

It is expected that emerging OMG Business Component Facility will provide additional capabilities for realizing business component interaction; it is a future work item for the WfM Facility to define exploitation of these capabilities in a workflow context.

Resource Assignment

jointFlow supports the concept of assigning resources to an activity; however, the details of identifying the resources to be assigned are not defined. It is assumed that the workflow process model provides information that can be used by the workflow components to determine the appropriate resources to be assigned to workflow activities. A workflow process model could, for example, define criteria for the selection of a person responsible for an activity depending on the role of the person, the position of that person in an organization hierarchy or depending on the actual context data of the activity. When the process is executed these rules would be applied to find persons in an organization model that match the criteria; additional selection criteria might be applied, such as current workload of eligible persons, etc..

Resource selection could be performed by another workflow process that takes the activity context as input and returns a set of resources as a result. The process could realize a specific resource selection procedure and activities in that process would interact with a resource management system to identify resources that 'willing and able' to participate in execution of the business task. The process would identify resources that meet the selection criteria and check their availability (e.g., in terms of workload); in addition, it may realize 'negotiations' with a specific resource on whether or not it accepts the assignment.

Future Work

The jointFlow specification focusses on defining a set of core interfaces that enable interoperability of workflow components, support process monitoring and resource assignment. Some areas that are important for the overall functionality of a Workflow Management Facility where not addressed by this first stage of the specification. The following discusses potential work areas for future extensions of the specification.

Workflow Processes Definition

The coordination of activities in order to achieve a business goal can be described in a variety of ways; most commercial WfMS use variants of directed graphs or Petri nets to represent process models, other approaches use, e.g., production rules to describe the potential flow of work. Arguably there is no single meta model that could potentially unify all of these approaches; one can only hope to obtain models that cover certain classes of workflow process models. The Workflow Management Coalition recently published a draft of a 'Workflow Process Definition Language' ([WfMC98b]) that attempts to unify the different modeling approaches of the WfMS and BPR tools represented in the coalition.

From a workflow business component perspective, the most interesting activity is the ongoing work on UML ([OMG97b]) extensions to describe workflow process models. UML activity diagrams provide several ingredients necessary to describe workflow processes: an activity network can be used to represent the potential flow of work, between activities conditions can be specified to determine the actual flow and 'swim lanes' can be used to associate resources with activities. However, the model must be extended in several areas to enable description of all aspects of a workflow process:

The UML Revision Task Force is in the process of defining extensions to activity diagrams to address these problems ([UML98f]). When this work is finished, UML workflow models could become a base for generation of workflow components and the integration of other business components into workflows as described in the section on 'Building Workflow Applications'.

Resource Management

The jointFlow specification enables association of resources with activities, e.g., to represent responsibility of a person for a process step. The WfResource interface simply provides a place holder for 'some entity in a resource model' and definition of a Resource Management Facility is outside of the scope of a WfM Facility. However, a couple of requirements can be defined for an RM Facility from a workflow perspective to enable interaction between both facilities:

Summary

We have shown how the jointFlow specification can be used to realize distributed workflow applications. A workflow process model is represented by a set of workflow components, maintaining the essential structure of the underlying model and thereby allowing for monitoring of execution of the process model. Complex workflows can be composed from independently developed workflow components which allows for the distribution of workflows in a heterogeneous environment such as a virtual enterprise. Process control is separated from actual business operations; business components can be integrated with workflow processes enabling reuse of  a base set of components in multiple workflows.

More work is needed in the area of workflow process definition; the work on workflow extensions to UML could provide a solution in this area. We also discussed requirements for a Resource Management Facility from a workflow perspective and implications for future work on the WfM Facility. Another future work area would be the exploitation of the emerging OMG specification of a Business Component Facility.

References

../oopsla97/OOPSLA'96OOPSLA'98 Business Object Workshop IV