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]):
-
Support changes of the underlying process model. Business processes
are subject to frequent changes triggered by changing business needs, e.g.,
reorganizations, process optimization efforts, outsourcing. The realization
of a business process by a set of workflow components must be done in a
way that makes it easy to reflect those changes.
-
Enable composition of reusable business components. A business process
defines the flow of work and relies on existing application components
to perform the actual work. Workflow components must interact with other
application components and support changes of the overall process without
affecting these components.
-
Allow for monitoring of process execution. Business process models
are often developed as the result of a business process re-engineering
effort with the objective to optimize business performance; as a result,
an important requirement on the implementation of business process process
models is the capability to monitor performance of process execution in
terms of the underlying process model.
-
Enable distribution of a process across business domains. Business
processes can span multiple business domains or enterprise boundaries.
For example, in a supply chain scenario, an order process initiated by
company A might require parts of the order to be processed by another company
B; in addition, the distribution of the process might change, e.g., due
to an outsourcing decision. A realization of a business process must allow
for the flexible distribution of process components and support the interaction
of these components.
-
Support assignment of process steps to workflow participants. An
important aspect of business process automation is the capability to manage
assignment of work to the resources required to perform the work. Process
steps can, for example, be assigned to people (or other units in an organization
model) that contribute to the execution of that process step; other examples
of resources include machines or documents required to perform a business
task. The realization of a business process must support association of
entities in a resource model to process steps.
|
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:
-
The current state of a workflow process can be obtained from status attributes
of the WfProcess and its associated WfActivities navigating the relationships
between process and its activities. The notification mechanism can be used
to observe updates of the process status via consumers of structured events
(StructuredEventPushConsumers or StructuredEventPullConsumers) as defined
by the Notification Service.
-
The execution history of a particular workflow process can be explored
by navigating the relations between a process manager and its associated
workflow processes or between a process and its associated activities to
obtain history information about the various entities involved in process
execution.
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:
-
Central Process Control: In this scenario (see scenario B in Figure
4) the process coordination logic is implemented by the WfProcess which
creates WfActivities as required and determines when to activate them.
The workflow activities maintain their own state, create event audit entities
as required and are responsible for execution of a process step; this may
involve interaction with another workflow process that implements the process
step. However, activities have no knowledge about other process steps.
When an activity is activated, the workflow process initializes its context
and waits for the activity to come back with a notification that it is
completed; it uses the result of the activity to determine follow-on activities.
-
Distributed Process Control: In this scenario (see scenario C in
Figure 4), the process logic is 'pushed down' to the activities in a workflow
process: the workflow process and its activities publish information about
their status changes, e.g., their completion and the results produced.
Other activities are prepared to receive status updates; an activation
condition of an activity could determine whether or not to activate the
activity when it receives information about completion of another activity.
Status changes of the process would be propagated to activities and might
trigger status changes, too. The workflow process would use status updates
from activities to determine when the process is completed.
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:
-
Find an appropriate workflow component that realizes the process step
-
Initialize the remote workflow process using context data of the main process
and start it
-
While the remote process is active, propagate changes of activity execution
state to the remote process and observe status changes of the remote process
-
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:
-
Activity diagrams currently are associated with an operation on a class,
basically providing a means to specify the details of a (complex) operation
of one component rather than coordination of the interaction of
several
components.
-
There is no association between an activity and other components that provide
a realization of the activity. It should be possible to define the association
of other business components with an activity and to link a description
of their interaction (e.g., in the form of a collaboration diagram) to
the activity.
-
Swim lanes basically provide a categorization of activities in an activity
diagram rather than a potential link into a resource model.
-
The semantics of activity diagrams is derived from UML state diagrams and
needs to be extended/specialized to be applicable to workflow processes;
for example, activities play a more active role in a workflow than states
do in a state diagram and it should be possible to define conditions in
terms of the results produced by an activity.
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:
-
The RM Facility must provide a means to describe resource selection criteria
in a way that can be used in a workflow process model; the description
should allow references to workflow process data.
-
An RM Facility might consider using workflow processes to describe complex
resource selection tasks;
-
An RM Facility should be capable of using workflow context data as input
for resource selection and the WfM Facility must enable retrieval of such
process data by an RM Facility.
-
The RM Facility might deduce information on potential future use of resources
from workflow process models, enabling it to 'plan ahead' for future resource
requests of a workflow to avoid having a process waiting for resources.
The workflow may play an active role in this scenario, informing the RM
about future resource requirements.
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
-
[EJB98]: Sun Microsystems, "Enterprise JavaBeans (TM)", Version 1.0, March
21, 1998
-
[Ley95]: Leymann F., 'Workflows Make Objects Really Useful", Sixth International
Workshop on High Performance Transaction Systems (HPTS), Asilomar, CA,
September 1995
-
[OMG97a]: Object Management Group, "Workflow Management Facility RFP",
May 9, 1997, OMG Document cf/97-05-06
-
[OMG97b]: Object Management Group, "UML Notation Guide", Version 1.1, September
1, 1997, OMG Document ad/97-08-05
-
[OMG97c]: Object Management Group, "CORBA Component Model RFP", July, 1997,
OMG Document orbos/97-06-12
-
[OMG98a]: Object Management Group, "Workflow Management Facility", Joint
Revised Submission, July 4, 1998, OMG Document bom/98-06-07
-
[OMG98b]: Object Management Group, "Errata relative to Workflow Management
Facility Revised Submission", July 30, 1998, OMG Document bom/98-07-15
-
[OMG98c]: Object Management Group, "Combined Business Object Facility Interoperability
Specification", May 18, 1998, OMG Document bom/98-05-03
-
[OMG98e]: Object Management Group, "Notification Service", Joint Revised
Submission, June 15, 1998, OMG Document telecom/98-06-15
-
[OMG98f]: Object Management Group, "Suggested Revisions to Activity Models
for Business Process Modeling", June 11, 1998, OMG Document ad/98-06-13
-
[Paul97]: Paul S., Park E. and Chaar J., "Essential Requirements for a
Workflow Standard", Workshop on Business Object Design and Implementation
III, OOPSLA, 1997
-
[Schulze97]: Schulze W., "Fitting the Workflow Management Facility into
the Object Management Architecture", Workshop on Business Object Design
and Implementation III, OOPSLA, 1997
-
[WfMC96a]: Workflow Management Coalition, "Interoperability Abstract Specification",
Version 1.0, October 20, 1996, WfMC Document WfMC-TC-1012
-
[WfMC96b]: Workflow Management Coalition, "Audit Data Specification", Version
1.0, November 1, 1996, WfMC Document WfMC-TC-1015
-
[WfMC95]: Workflow Management Coalition, "The Workflow Reference Model",
November, 1994, WfMC Document TC00-1003
-
[WfMC98a]: Workflow Management Coalition, "Workflow Client API", Version
2.0, July, 1998, WfMC Document WfMC-TC-1009
-
[WfMC98b]: Workflow Management Coalition, "Process Definition Interchange",
Version 1.0 Beta, August, 1998, WfMC Document WfMC-TC-1016-P
OOPSLA'98
Business Object Workshop IV