Specification of Workflows with Heterogeneous Tasks in ... - Kno.e.sis

Specication of Workows with Heterogeneous Tasks in
METEOR
Narayanan Krishnakumar
Bellcore, MRE 2B324
445 South St., Morristown, NJ 07960
nkk@bellcore.com
Amit Sheth
Bellcore, RRC 1J210
444 Hoes Lane, Piscataway, NJ 08854
amit@ctt.bellcore.com
Abstract
Many enterprise applications require performing
dierent tasks on dierent systems (or
processing entities). Both the types of tasks
and processing entities can be very heterogeneous.
Such enterprise applications can be
supported by workow automation. In this
paper, we discuss specication of workows
that involve heterogeneous tasks that execute
on old main-frame based (legacy) application
systems as well as new workstation-based distributed
computing systems.
The workow specication involves two highlevel
languages for specifying a workow at
dierent levels of abstraction: the Work-
ow Specication Language (WFSL) to express
the application-level interactions between
multiple tasks, while the Task Speci-
cation Language (TSL) focuses on the issues
related to individual tasks. These languages
support denition of dierent types of tasks,
state-based and value-based intertask dependencies
and data management, as well as failure
and exception handling.
1 Introduction
In most computing environments in industry and government,
application systems were developed one at
a time. Earlier application systems typically automated
one organizational function, were developed independently
of others and usually each had their own
database. The need to improve productivity and cut
Copyright c 1994 by Bell Communications Research,
Inc.
costs has resulted in the need to signicantly reengineer
and automate enterprise applications. The objective
of the METEOR (Managing End-To-End OpeRations)
project at Bellcore is to support and enable exible
automated solutions for enterprise applications.
A workow supported in METEOR involves the
critical aspect of an enterprise application involving
coordinated execution of multiple, related tasks. The
tasks can be heterogeneous and performed on or by
heterogeneous processing entities. Many tasks cannot
be modied or easily migrated to more modern environments
due to the size and complexity of existing
processing entities . Thus, in METEOR, our approach
to automating workows is necessarily a bottom-up
one: we need to support the current execution environments
as well as evolving ones. While signicant
reuse of existing specications of individual tasks is
desirable, some changes, mostly additions, may be necessary
to support increased functionality and automation.
Other approaches in the literature to workow
automation have taken one of distributed transaction
processing, oce (document or e-mail workow) automation,
or multidatabase transaction perspectives.
We wish to support an amalgamation of all of these -
both in modeling/specication and implementation.
A practical workow management system that can
enable multi-system applications must deal with the
specication and execution support related to:
dierent types of (preexisting and new) tasks, the
processing entities that execute or perform the
tasks, and the interfaces through which the tasks
are submitted to the processing entities,
the coordination requirements between tasks, that
are dependent on the execution states of individual
tasks and the workow as a whole as well as
the data manipulated by these tasks,
the data exchange between tasks, that might also
Page 1

involve dealing with dierent data formats for different
tasks, and
interfacing with existing software systems (e.g.,
script interpreter/processors, abstract data management
and manipulation, data format translators,
etc.) that add value to workow processing
and the associated computation.
METEOR deals with all of the above aspects and oers
the following features:
awell-dened model and high-level languages for
specifying the workows and the tasks,
a compiler/interpreter for the workow language
(ancillary support may include syntax directed
editors and/or graphical user interfaces that support
workow specication, and support for testing
the correctness and executability ofthede-
ned workows), and
run-time components, such as a workow controller
that supervises the progress of the work-
ow, enforces intertask dependencies and interfaces
with existing systems, and task managers
that have the responsibility for individual tasks.
In this paper, we discuss a workow model and the
high-level languages that support it. The language
design is consistent with the need to support appropriate
levels of abstractions for dierent classes of persons
who might specify a workow. At Bellcore, for example,
one group of persons (called systems engineers)
focus on the enterprise-level (end-user and applicationcentric)
requirements that the workows should support,
while another group of persons (called developers)
better understand the systems implementation aspects
of the workows. This dichotomy aswell as the
considerations for modular design and implementation
has led us to have two languages: workow specication
(sub-)language (WFSL) and task specication
(sub-)language (TSL).
The paper is organized as follows. Section 2 discusses
in more detail the requirements for workow
support in METEOR based on our interactions with
real multi-system applications. A high-level description
of the operational environment is also discussed
since it has inuenced the model and the language.
Section 3 discusses the approach and rationale in the
language design. Sections 4 and 5 discuss details of
WFSL and TSL, respectively. The related work is discussed
in Section 6. Section 7 gives our conclusions.
Additional details of this work is available from authors
[21]. It discusses further details of the languages,
the architecture of METEOR's workow management
systems, correctness issues related to workow management,
and additional examples.
2 The Environment and Application
Requirements
Atypical large telecommunications company has several
thousand applications. Around two hundred of
these are large application systems, called Operation
Support Systems (OSSs), each with several hundreds
of thousands of lines of code and a very large database.
Historically, end users performed operations on these
OSSs using screens. To provide easier access, application
programs and scripts have been written to perform
operations using terminal emulation or through
\contracts" that provide well-dened logical interfaces.
Many new applications also access DBMSs directly for
auxiliary inventory management, monitoring of work-
ow or task status, statistics maintenance, or error
processing. Applications could also involve humans
processing some tasks (currently this is often needed
for error resolution when OSSs issue Requests for Manual
Assists- RMAs). To adequately model such realworld
environments, we classify the relevant components
of our applications into tasks, processing entities
and their physical interfaces, and then discuss how
they can be tied together into a workow.
2.1 Tasks, Interfaces, and Processing Entities
Tasks are operations or a sequence of operations that
are submitted for execution at the processing entities
using their interfaces. The types of tasks we currently
consider include user tasks that involvehumans in processing
the tasks, scripts or application programs that
may involve terminal emulations to remote systems,
client programs or servers invoking application servers,
database transactions, and contracts. For the purpose
of this paper, the contract tasks can be viewed as predened
sets of operations at the OSSs and behave as
stored procedures from the invoker's perspective. We
refer to all types of tasks that do not involve humans
(i.e., tasks other than the user tasks) as application
tasks.
The processing entities for the application tasks include
application systems (OSSs, legacy and modern
application systems) servers supported by client-server
and/or transaction processing systems (e.g., atop DCE
and Encina TM ), DBMSs (for processing transactions),
and script interpreters and compilers (for processing
scripts and application programs). Furthermore, with
user tasks, humans are the processing entities, who in
turn may use other software (typically business and
oce automation software such as spread sheets and
document/image processing systems).
The physical interfaces or distributed execution
support mechanisms include remote procedure call
Encina is a trademark of Transarc Corp.
Page 2

mechanisms such as DCE RPC to directly make calls
to application servers, transactional RPCs to application
servers under the control of a transaction monitor
(such transaction monitors include ACMS TM ,
Tuxedo TM , and Encina), queue managers that deliver
requests to application servers (proprietary or
vendor product supported, e.g., Tuxedo/Q, Encina's
RQS or DEC's MessageQ), workstation-to-mainframe
interfaces to allow aworkstation-based client program
to access a mainframe-based OSS, and interfaces that
support user tasks and provide access to graphical
user interfaces (such as those associated with document/image
processing systems). The last two types
of interfaces behave as queue managers, where the task
submitted may ormay not block foraresponse.
2.2 Task Coordination and Data Management
Tasks, processing entities and their interfaces are the
basic components in a multi-system workow application.
Two additional components are inter-task dependencies
and data management (including formatting,
manipulation and exchange).
Inter-task dependencies specify how the execution
of a task is related to that of others (based on the execution
state of other tasks and their outputs) and external
variables (e.g., time of day). As in the literature
on multidatabase transactions, there can be complex
dependencies between the states of tasks, depending
on transactional aspects such as concurrency control,
commitment, etc. However, most of the telecommunications
applications we considered dealt with several
autonomous \closed" systems (i.e., whose internal
mechanisms are not made available to the external
world). There was therefore not much scope for intricate
dependencies involving the states of tasks other
than ordering dependencies among tasks. On the other
hand, dependencies based on data values and external
variables can often be complex.
Data management inmulti-system workow applications
can be very demanding. This involves support
for dierent data formats, transport and storage of this
data and complex manipulation of data by auxiliary
systems. Auxiliary systems are existing application
programs (including applications that can invoke subworkows)
or scripts, that can parse and manipulate
complex data.
2.3 Additional Requirements for Workow
Management
We now discuss some of the key additional requirements
of workow management in our environment
ACMS is a trademark of Digital Equipment Corp.
Tuxedo is a trademark of AT & T Corp.
that inuence the language design and the system architecture.
Typically, one set of people dene the workows at
the conceptual level - they do not concern themselves
with the exact details of any task, but do describe
its functionality and what inputs and outputs it may
have. Another set of people write the code for the tasks
associated with the workow. The workow management
system should enable these two sets of people to
work together and also permit code-reuse.
As new telecommunications services are oered or
newer systems get incorporated into the business process,
there is a need to exibly and easily modify the
workows. Given that each new workow most likely
incorporates pre-existing tasks, only the conceptual
workow specication has to be written anew. This
is yet another reason to separate the workow specication
from the details of the individual tasks.
Errors occur routinely in the system. The work-
ow management system should be able to recognize
and handle errors. We subdivide the errors into logical
errors and system errors. Logical errors arise at the
level of the application, i.e., for instance, if a particular
item is required from the inventory and the item is
not in stock. The task that attempts to procure this
item from inventory runs to completion but with a
logical failure. Alternative tasks can be dispatched to
deal with this logical error. However, suppose the task
was not able to complete since the inventory database
could not be accessed. This is a system failure, where
alternative means can be used to try to rectify the
failure. This demarcation between logical and system
errors and the dierenttechniques used to handle them
is important in building a modular system. The task
programmer and the workow management infrastructure
handle system errors rst, for instance by retrying
the same task (see Section 5). A workow specication
deals only with logical errors.
Workows can be dynamic, i.e., the entire workow
cannot be determined beforehand. For instance, if a
customer requires a digital link between three of his
locations, a special routing task determines possible
trunk routes between these locations, and new tasks
will have to be generated to do appropriate inventory
assignment. The workow management system will
have toallowsuch incremental changes in the work-
ow specication, where additional tasks and associated
dependencies can be included at run-time.
3 Approach
Any solution involving interoperability intheabove
environment would require a careful trade-o between
the exibility of the system, the functionality itcan
provide, and performance. In this section, we discuss
Page 3

the model, and the basic design decisions behind two
languages for specifying multi-system workow applications.
Scope of TSL
I1
T1
PE1
f
AUX1
T2
T3
I2
PE2
Scope of WFSL
Figure 1: Schematic of a workow
Tasks in a workow can have dierent functionality,
and can further be dierentiated on the basis of the interface
and/or the processing entity they are executed
on. We discussed in the last section the requirement of
separating the conceptual workow specication from
the detail of how and where an individual task is executed.
The METEOR workow model in Section 3.1
provides the basis for the former and is an adaptation
and extension of the model outlined in [28, 27].
WFSL is based on the features of the workow model.
The detailed specication of each task and its interaction
with the interfaces/processing entities is done
using TSL (see Figure 1). At anarchitectural level,
the WFSL specication would be executed by awork-
ow controller, whereas each task specication would
be executed by a task manager.
3.1 The Workow Model
Failed
fail
Initial
start
Executing
done
Done
A non-transactional task structure
abort
Aborted
Initial
start
Executing
commit
Committed
A transactional task structure
I3
abort
Figure 2: Task Structures
abort
Aborted
T4
PE3
start
Initial
Executing
done
Done
prepare
Prepared
abort
commit
Committed
An open 2PC transaction structure
Aworkow comprises multiple tasks. The workow
specication might not be concerned with the details
of the tasks, however, it would have to at least deal
with the (externally visible) starting and completion
events of tasks, the inputs and outputs of tasks and
how they relate to other tasks. In general, we represent
the execution behavior of each task using task
structures. This specication is important in dealing
with the co-ordination aspects of heterogeneous task
executions. Generally, dierent types of tasks can have
dierent task structures. Three frequently occurring
task structures in our environment are shown in Figure
2. Each task structure has an initial state, and on
the start transition moves into the executing state.
There could be one or more transitions after this, and
the task eventually enters a terminating state (such
as done, failed, committed, aborted). The controllable
transitions in these tasks are underlined, i.e.,
these transitions can be activated by an external entity.
Whether a transition is controllable might depend
upon the properties of the interface or the processing
entity.
A user task or script can be characterized by a nontransactional
task structure. Such a task reaches a
failed state if a system error is encountered during
its execution. A completed task reects normal execution
of a task from the system (as opposed to the
application) perspective. A completed task can further
be determined to be successful or unsuccessful,
based on application-specic criteria (see value dependency
in Section 4). The task structure of a contract
(stored procedure) is typically a transactional
task (with ACID properties), which has an aborted or
committed nal state. The third type of task structure
shown is that of a transaction supported by DBMSs
that provide an open two-phase commit (2PC) feature.
Notice the transitions from prepared to aborted
or from prepared to committed are controllable. Furthermore,
there are two kinds of abort transitions from
the executing state: one that is controllable (used
when there is a deadlock), and another that is not
controllable and initiated by the processing entity.
The task structure does not determine the means of
execution nor the functionality of the task, but only a
high-level description of the (visible) state transitions.
Two tasks might have the same structure, but have
dierent functionality or can be executed atop dierent
interfaces and/or processing entities. Usually, the
task structure is determined by the states that are observable
while the task executes at the processing entity.
Sometimes it is possible that the interface does
not support the same view: suppose a database transaction
is submitted through a persistent queue. The
queue might only oer a non-transactional view of the
task, i.e., the task has been submitted, and the task
has either failed or has been done (and not that the
task committed or aborted). This issue is discussed
further in Section 5.
Tasks are not the only executable entities in a work-
ow. Often the data transferred between tasks has to
Page 4

e formatted appropriately using lters. Filters are
repeatable (and side eect free) functions that need
not be recoverable and need not be characterized by a
task structure. Such functions can either be executed
locally as part of the workow management system or
remotely from shared libraries on auxiliary systems.
Thus a workow specication primarily contains:
the task structure of each task in the workow,
the typed inputs and outputs of each task/lter
types, and how they are related to the outputs
and inputs of other task types, and
the preconditions for each controllable transition
in each task.
3.2 Language design and rationale
WFSL has been designed based on the model described
in the previous section. WFSL is a declarative rulebased
language. Each WFSL rule has two components:
a control part and an optional data transfer part. The
control part denotes the preconditions for a single controllable
task transition. Whenever a task makes a
state transition, we saythatanevent occurs. The
preconditions can include references to events and/or
data outputs of other tasks, as well as program variables.
The data transfer part indicates which outputs
of other tasks or variables (possibly passing through
lters) are input to that task, i.e., for instance, the
output o1 of task T 1 is fed through a lter f for reformatting
and then fed into the input i1 of task T 2.
The data transfer specication in WFSL is very exible.
For instance, the data outputs of several tasks
that become available at dierent times can be fed
into one task. In a language that is procedure-calloriented,
one would have to use variables to temporarily
store the data as it becomes available, and then
call the task at one point with all these variables. The
METEOR workow management system handles this
temporary storage instead. We can also specify alternative
inputs to tasks, i.e., it is possible that under
one circumstance, the output of task T 1 feeds into the
input of a second task T 2, but under some other circumstance,
the output of a third task T 3 feeds into
the input of T 2.
A unique feature of WFSL is that task specications
can be nested, which allows complex workowlike
tasks with their own task structures to be specied
as composed of smaller task units. To support
specication re-use, task types and task classes can be
dened. The rule-based nature of WFSL is consistent
with the requirement offorward recovery. Every next
step of the workow is determined by anevaluation of
relevant rules when an event occurs, and a rule which
has all its preconditions satised res. Note that by
this declarative approach, we have removed the need
for a program counter. If all inputs, outputs and task
states were made persistent, then during recovery, the
workow controller can start up with its state intact
and resume evaluating rules. (In an imperative program
implementing the workow, the memory image
of the program will have tobecheckpointed instead.
The logical checkpointing in the declarative approach
is usually more ecient than the memory image checkpointing.)
Furthermore, if the workow is dynamic,
the declarative nature of WFSL allows it to be incrementally
interpreted during run-time.
We nowgive a high-level description of TSL. One
of the key objectives in TSL is the minimal rewriting
of existing tasks. TSL provides a wrapper for code describing
interaction with an interface to a processing
entity and comprises a set of macros that can be embedded
in a host language like C or C++. The main
functionality of the TSL macros is to indicate points in
the task execution at whichtheworkowcontroller can
be informed about the current logical state of the task
(and thereby points where the state of the task can be
made persistent). The remainder of the task is written
in the host language and embedded sub-languages
supported by the processing entities. As part of TSL,
we also prescribe how new task programs should be
written. The interface is made explicit in the task
specication, and this allows the task programmer to
specify error handling for interface or processing entity
(system) errors. For instance, the task submission
to the interface might time out, or might needto
be re-submitted for up to n retries, or a dierent interface
might bechosen, and so on. (A system error
can eventually develop into an application error at the
workow level. For instance, a task program can try
to re-submit a task several times with repeated system
errors before it gives up. The workow specication in
WFSL would then have to handle the error by possibly
submitting an alternate task.)
In summary, WFSL deals with the enterprise or application
issues. It is used to specify the workows, including
all task types and classes in a workow, all intertask
dependencies, lter calls, and application level
failure recovery and error handling issues. TSL is used
to homogeneously specify individual tasks including
task level failure recovery and error handling that are
interface and/or processing entity specic.
4 WFSL
We describe this language by using some representative
examples. Many syntactic details and the full
BNF for WFSL are not included for brevity. Task
structures can be dened and named by thework-
ow designer in WFSL, but we do not give the syntax
Page 5

here. We use the names SIMPLE NON TRANSACTIONAL,
SIMPLE TRANSACTIONAL and TRANSACTIONAL OPEN2PC
to refer to the task structures in Figure 2.
4.1 Task type and instance declarations
The following example declares a simple task type with
name OSS CONTRACT that has the structure of a transaction,
has one input of type FCIF 1 and one output of
type FCIF (for simplicity, we assume that data types
are dened as in C.)
simple_task_type OSS_CONTRACT
SIMPLE_TRANSACTIONAL
(input FCIF input1 output FCIF output1)
A task class declaration is used to name one or
more classes of the same type. The following example
species two task classes, Loop Assignment and
Circuit Facility Check of type OSS CONTRACT.
task_class OSS_CONTRACT Loop_Assignment,
Circuit_Facility_Check
Several instances of the same task class can be used
within a workow, as follows, where L1 and L2 are two
instances of Loop Assignment:
Loop_Assignment L1, L2
Compound tasks are composed of several simple
or compound tasks. The denition of a compound
task is given entirely within WFSL (unlike a simple
task, whose code is written in another language and
compiled/interpreted independently). An entire work-
ow can be represented as a compound task. Unlike
simple tasks, all the transitions of a compound
task are controllable - the transition from executing
to done or executing to failed is inuenced by the
states and outputs of its sub-tasks. In our environment,
the compound task associated with a workow
has a non-transactional task structure. We refer to
this task structure by COMPOUND NON TRANSACTIONAL.
Compound tasks are specied as follows:
compound_task_type WORKFLOW1_TYPE
COMPOUND_NON_TRANSACTIONAL
(input FCIF input1 output FCIF output1 )
As with simple task types, compound task classes
and their instances can be specied. Compound
tasks can also have a transactional task structure provided
all tasks within them are transactional with
open two-phase commit. For instance, within a
large workow, there might betwo tasks to be executed
as a transactional unit. Then the two can be
grouped together into a transactional compound task
(COMPOUND TRANSACTIONAL).
1 FCIF (Flexible Computer Interface Format) is a de facto
standard for data transfer between OSSs in Bellcore. Messages
in the FCIF format have a tree structure, where the non-leaf
nodes have tags and the leaf nodes hold the data.
4.2 Intertask Dependencies
Intertask dependencies determine how the tasks (instances
of task classes) in the workow are coordinated
for execution. Other coordination aspects, such
as concurrency control among concurrent workows,
will be ignored for now for lack ofspace. Two general
types of dependencies are of interest: state dependencies
and value dependencies.
A state dependency species how a controllable
transition of a task depends on the current observable
states of other tasks. A state dependency is
specied as a rule consisting of < left hand side >
evaluator < right hand side >. Several complex
dependencies have been dened in the literature [2, 20,
6], but given our environment in which related tasks
in a workow execute on autonomously developed
and often \closed" systems, we nd that the BEGINdependency,
SERIAL-dependency, BEGIN-ON-COMMITdependency
and BEGIN-ON-ABORT dependency [6] are
the most relevant. We express these dependencies using
the evaluator ENABLES 2 : the event(s) leading to
the state(s) identied by the left hand side must have
occurred before the (controllable) transition(s) identi-
ed on the right hand side can be allowed tooccur.
Other evaluators can be incorporated into WFSL easily
as the need arises (the main impact would be on the
scheduling algorithms within the workow controller
which is not addressed here). The following state dependency
species that L2 can make the start transition
only after L1 has entered the done state.
[L1,done] ENABLES [L2, start]
Avalue dependency may optionally be associated
with a state dependency to further constrain the latter.
The data that are referred to in the value dependency
can be data items that are the output of some
task, program variables that keep track of some data
items in the workow, constants, or the results of lter
evaluations. When used in a value dependency, alter
can be used to determine the logical success or failure
of a previously terminated task (typically a done nontransactional
task or a committed transactional task).
For example, the above state dependency can be further
constrained using a program variable outvalL4
and by using a lter function called "success" which
determines whether L1 has logically (i.e., at the application
level) completed successfully:
[L1,done] & (success(L1.output1) = TRUE) &
(outvalL4 > 5) ENABLES [L2, start]
The usual boolean and arithmetic operators can be
used in value dependencies.
2 ENABLES is a combination of the \!" and\

4.3 Input and Output Assignments
In a workow, each task has to get data input(s) from
either the output of some other task, constants, program
variables or the input to the entire workow
(compound task). Thus, the workow specication includes
the association of inputs and outputs of each
task to those of some other tasks. As an example,
output1 of task L1 fed to input1 of task L2 is speci-
ed as:
L1.output1 -> L2.input1
Similarly, the assignment to a program variable
outvalL1 is done as follows:
L1.output1 -> outvalL1
Program variables in a WFSL program can be
global or local. For the purpose of simplicity of semantics,
we assume each program variable can be assigned
to at most once during run-time.
The input and output assignments of a task are
given in conjunction with the intertask dependencies:
it is crucial to determine when the outputs referred
to in these assignments are made available. It is assumed
that the outputs are made available when the
associated tasks are in one of the terminating states
(done/failed/committed/aborted). (For open 2PC
transactions, the output can sometimes be made available
in the done or prepared state, although this has
implication on transactional properties.) The value of
a program variable is undened before it is assigned
to. The following rule indicates that L2 starts when
L1 completes successfully and the value of outvalL4
is more than 5, and that the input for L2 is available
when L1 transitions to done.
[L1,done] & (success(L1. output1) = TRUE) &
(outvalL4 > 5) ENABLES [L2, start] %
L1.output1 -> L2.input1
An Example: We discuss a simple example to
demonstrate some of the workow specication features.
The example (Figure 3) shows how the repeated
occurrence of an error can be handled. There are three
non-transactional tasks, A, B, and C When A is done,
C is started. If A encounters a system error, then B is
started. When B is done, then A is started up again.
Notice that the relationship between A and B is similar
to that between a contract and the corresponding failure
handling procedure - when the contract fails, the
failure handling procedure takes over, and once the
latter completes, the contract is retried. The workow
fails if A completes and C fails, or if B fails.
The workow specication in Figure 4 denes the
control and data ow between tasks A, B and C (the
line numbers are just for reference and are not part
of the syntax). Note the use of a lter to massage
the input to the workow. Line 5 indicates that the
typedef ... FCIF
typedef struct {
int field_one
char field_two
...
} SPECIAL_REC
simple_task_type A_type
SIMPLE_NON_TRANSACTIONAL
(input FCIF input1
output SPECIAL_REC output1)
simple_task_type B_type
SIMPLE_NON_TRANSACTIONAL
(input SPECIAL_REC input1
output FCIF output1)
simple_task_type C_type
SIMPLE_NON_TRANSACTIONAL
(input SPECIAL_REC input1
output SPECIAL_REC output1)
task_class A_type A_class
task_class B_type B_class
task_class C_type C_class
Filter FCIF f1(FCIF)
compound_task_type WORKFLOW1
COMPOUND_NON_TRANSACTIONAL
(input FCIF input1
output SPECIAL_REC output1 )
{
A_class A B_class B C_class C
SPECIAL_REC var1
1 [WORKFLOW1,executing] ENABLES [A,start] %
f1(WORKFLOW1.input1) -> A.input1
2 [A,failed] ENABLES [B,start] %
A.output1 -> B.input1
3 [B,done] ENABLES [A,start] %
B.output1 -> A.input1
4 [A,done] ENABLES [C,start] %
A.output1 -> C.input1
5 [C,done] ENABLES [WORKFLOW1,done] %
C.output1 -> WORKFLOW1.output1
6 ([A,done] & [C,failed]) | [B,failed]
ENABLES [WORKFLOW1,fail] %
A.output1 -> WORKFLOW1.output1
}
task_class WORKFLOW1 WF1_CLASS
WF1_CLASS WF1
Figure 4: Workow Specication Example
Page 7

COMPOUND TASK
WORKFLOW1
TASK A
start
Initial
TASK B
Initial
Initial
Executing
start
start
Executing
fail
Executing
done
Failed
Done
Failed
Done
TASK C
Initial
start
Failed
Done
Executing
Failed
Done
workow can make a transition to the done state when
C reaches the done state. From line 6, the workow
enters the failed state if task A is done and task C has
failed, or if B has failed. There is also a semantic detail
in the specication of the rules above. The following
scenario can occur : task A moves to failed, task B
is started and then completes, then task A is started,
and so on (the assumption is that this terminates).
Thus there could be several dynamic instances of task
A which might be started up as the workow unfolds.
However, at most one instance of A can be \active"
(i.e., not in the initial or a terminating state). When
we refer to a state of task A on the left hand side of
any of the rules (say as in line 4), the reference is to the
currently active instance when the rule is evaluated.
Advanced Features :To accommodate complex applications,
WFSL includes features that are not discussed
here to allow the dynamic additions of tasks
and dependencies, and concurrent invocations of task
instances of the same class. Dealing with the former
involves including a WFSL interpreter as part of the
workow and using \control lters" that produce new
WFSL rules to augment theoldworkow using macro
substitution. The latter involves allowing arrays of
tasks, conditions over subsets of such arrays of tasks,
and array inputs/outputs of tasks.
5 TSL
In this section we describe how a task program is written.
A task programmer includes the following kinds
of statements in his/her task program:
(a) Interface specic statements : This includes statements
to identify the interface and to handle errors at
the interface or processing entity.
(b) Processing entity specic task statements : This
would include all statements of the task that need
Figure 3: Control Flow
Database_task (Sp_rec)
SPECIAL_REC Sp_rec
{
EXEC SQL INCLUDE SQLCA
EXEC SQL BEGIN DECLARE SECTION
int info
EXEC SQL END DECLARE SECTION
EXEC SQL WHENEVER SQLERROR goto Failed
TASK_EXECUTING()
info = extract_info_from_rec(Sp_rec)
EXEC SQL INSERT INTO INFO_table
VALUES (:info)
EXEC SQL COMMIT
TASK_COMMIT()
Failed :
EXEC SQL ROLLBACK
TASK_ABORT()
}
Figure 5: Database SQL task
to be executed against the processing entity. For instance,
these might beembedded SQL statements for
databases, or contract specications for OSSs.
(c) Statements for revealing the task (structure) state
to the workow controlling entity : The task programmer
explicitly includes macros within the program
such asTASK EXECUTING() and TASK DONE() to
indicate to the workow controller that the task has
reached a particular state.
We illustrate the above usingtwo examples. The
rst example deals with an SQL-based task written
in C (Figure 5). This transactional task receives as
input a record structure SPECIAL REC, extracts some
information out of it, and inserts the result into a
database using Embedded SQL. The statements that
Page 8

Contract (FCIF_id1,FCIF_id2)
FCIF FCIF_id1,FCIF_id2
{ int temp_qms_stat, iter
TASK_EXECUTING()
iter = MAX_TRIES /* Try QMS call up to
MAX_TRIES times
if system failure*/
repeat
{
EXEC QMS
send_and_recv (FCIF_id1, FCIF_id2)
temp_qms_stat = qms_status
iter++
}
until (temp_qms_stat != ( QMS_FAILURE ||
QMS_OSS_DOWN_FAILURE ) || iter >= 10)
if (iter >=10)
TASK_FAILED()
else
TASK_DONE(FCIF_id2)
}
Figure 6: Contract task - I
are specic to the processing entity are the Embedded
SQL statements. The program is annotated with
TSL macros, i.e., TASK EXECUTING(), TASK COMMIT()
and TASK ABORT(). These are used to communicate
the current logical state of the task to the workow
controller. (There is no detail in the program regarding
which database the \interface" is connected to: it
is assumed that the connection of the Embedded SQL
interface to the database has been done elsewhere.)
The only additions the task programmer makes to
the program s/he normally writes are the appropriate
TASK ... macro calls.
We now consider another example task program
that submits a contract to an OSS through a queued
message system called QMS (Figure 6). QMS is accessed
by a transactional RPC call from a client. We
assume that the access to QMS is made partially transparent
using Embedded QMS calls (like Embedded
SQL calls). We use the send and recv construct in
Embedded QMS to send a contract to QMS and block
until the reply comes back or there is a system failure.
It is assumed that the contract information is
input as FCIF id1, anFCIF structure, and the result
is FCIF id2. We also illustrate in this example how
the task structure of Contract assumed by thework-
ow specication is consistent with the task structure
reported by the task program. Contract is assumed
to be non-transactional, so only the failure or successful
completion of the task is reported to the workow
controller. Notice how the task takes into account the
system errors of the interface and the processing entity.
Contract (FCIF_id1,FCIF_id2)
FCIF FCIF_id1,FCIF_id2
{ int temp_qms_stat, iter
extern int did_commit() /* Function to
determine if contract committed */
TASK_EXECUTING()
iter = MAX_TRIES /* Try QMS call up to
MAX_TRIES times if system failure*/
repeat
{
EXEC QMS
send_and_recv (FCIF_id1, FCIF_id2)
temp_qms_stat = qms_status
iter++
}
until (temp_qms_stat != ( QMS_FAILURE ||
QMS_OSS_DOWN_FAILURE ) || iter >= 10)
if (iter >=10)
TASK_ABORTED() /* System failure */
else if (did_commit(FCIF_id2) = TRUE)
TASK_COMMITTED(FCIF_id2)
else TASK_ABORTED() /* Abort due to
actual abort of contract at OSS */
}
Figure 7: Contract Task - II
In the second instance of this example (Figure 7),
suppose the workow designer assumed Contract to
be transactional, and the contract execution at the
processing entity is also transactional. However, since
the submission of the contract is through the interface,
it is possible that the task completes successfully as far
as the interface is concerned (i.e., without a system error),
but the task could have committed or aborted.
Then the task program is modied to return a commit
or abort status to the workow controller. Furthermore,
if the task does return successfully, the function
did commit() in the task program is used to determine
whether the contract committed or aborted.
6 Related Work
We rst discuss work in the literature related to
workow/activity models [10]. These include active
database and rule-based approaches [7, 8], multidatabase
and relaxed/extended transaction model
based approaches [14, 1, 15], and oce and process
automation based approaches [17, 23,24]. Somewhat
less relevant are the many proposals for multi-level
and nested transaction models [30]. A perspective
on combining workow and transaction management
was given in [4]. Unlike many of these models, we
do not view the entire application or the activities in
transactional terms, since several tasks can be non-
Page 9

transactional. Thus our approach is based on a detailed
description of the task structure, and then building
up a workow using intertask data and control dependencies.
When using a multidatabase oriented approach,
issues related to intertask dependencies have
been discussed in detail in [6, 20, 2, 16, 15]. For instance,
both ACTA [6] and the DOM project [15] support
complex intra- and inter-transaction state dependencies,
and correctness dependencies such as serialization,
visibility, co-operation and temporal dependencies.
Our model can support all these dependencies,
but for simplicitywehave restricted WFSL. This
is because in several telecommunications applications,
many tasks are not transactional and task transitions
of autonomous processing entities are not controllable.
On the other hand, with operations supported by auxiliary
systems, lters and logical operators, we allow
a comprehensive set of data dependencies (the intertask
dependencies that involve datavalues and external
variables). The applications we have studied do
involve such complex value-based intertask dependencies.
We share the view of [9] regarding the set of properties
that a workow (called operation owin[9]) model
and specication language should support. These include
(with the approximately corresponding terms
used by [9] in parantheses), denition of individual
tasks (basic operation denition), a variety of tasks
including user tasks (transactions and nonelectronic
operations), state-based and value-based intertask dependencies
and data management (control and data
ow denition), and failure and exception handling
(same terms). Currently, no separate or direct support
for business rules and constraints, and security
and role resolution identied in [9] is provided. These
can partly or indirectly be supported by intertask dependencies
and by individual interfaces (e.g., security
features of DCE) and processing entities.
The relevant eorts on specication languages are
as follows. In [14], a language is proposed for describing
(possibly nested) multi-transaction activities,
and how the ow of data between dierent modules
can be specied. However, the specication of intertask
control dependencies is limited, and it is assumed
that all the leaf-level tasks are transactional.
We have adopted a similar data transfer specication
in WFSL, but have extended the model to include different
task structures and more complex control dependencies.
In [7, 8], the ATM extended nested transaction
model and language is presented for describing
long running activities. Such a description includes a
procedural static specication of the high-level work-
ow, and rules (triggers) for the dynamic evolution of
the workow. The WFSL language, is however, based
on a unique more general workow model, and allows
heterogeneous tasks to be incorporated exibly into
the workow. By modeling the task structures of compound
tasks and by using rules throughout a WFSL
specication, we have allowed the arbitrary nesting of
tasks and specify how the controllable transitions of
each task is inuenced. WFSL is less expressive than
a common procedural language, but we believe that
this is compensated for by having TSL incorporate a
procedural host language. In the ConTract model[25],
a long running activity is modeled as a combination of
scripts and steps, where scripts are at the level of the
conceptual workow specication and steps are at the
level of individual tasks. By using rules and the notion
of compound tasks, we allow dynamic nested work-
ows. In contrast to having data transferred through
variables and their contexts, we makeintertask data
ow explicit, have variables one-time assignable only,
and use lter functions. The IPL language from the
InterBase project at Purdue [5] isyet another highlevel
language that shares some of our objectives. IPL
does separate workow-level details from task-level details
and allows dependency rules, but nested work-
ows are not allowed. Furthermore, error handling
(system or logical) using the dependencies is limited.
WFSL also supports more types of tasks and interfaces
and a exible data transfer specication. Other,
albeit less relevant, specication and language eorts
are the script-based workow specication in Carnot
[29], and the extensions to MSQL to support some
features of workows [27]. For transaction processing
environments, the STDL language [3] supports several
features we consider to be important, including, support
for tasks that are transactions, RPC-based tasks,
and queued tasks, as well as recoverable presentation
services, recoverable variables, and structured exception
handling. The ideas behind TSL have been borrowed
from several predecessors with which it shares
its objectives and functionality. These include, among
others, DOL [26], and the interfaces that support executions
of heterogeneous tasks against dierent processing
entities (e.g., LAM in Narada [18], RSI in Interbase
[12], and ESS in Carnot [29]).
7 Conclusions
Reengineering and automation of enterprise applications
can be supported using workow management
that support coordinated execution of heterogeneous
tasks on heterogeneous processing systems. We have
discussed a workow model and languages for specifying
the workows to support enterprise applications.
The high-level language WFSL supports specication
of the application-level issues of workows. Task type
declarations capture the observable behavior of the
task using task structures and data inputs and outputs.
Page 10

Task class and instance declarations support specication
reuse. Inter-task dependencies and data exchange
statements that express task coordination and data
ow requirements, and lters can be used for data
manipulation. TSL is used to specify individual tasks
while accommodating the heterogeneities related to interfaces
and processing entities. TSL supports macros
that allow the tasks to reveal their task structure to
the workow management system. The language design
consider the issues of system and application-level
error handling. They also enable logging for forward
recovery (this issue is not discussed in this paper).
A partial prototype of the METEOR workow management
system was completed last year, and used
to demonstrate some of the basic functionality to
prospective clients by prototyping a real multi-system
application, and to get further requirements. One approach
to the workow controller part of the system
was discussed in [2] and later implemented at MCC,
while another was completed at Bellcore. A more
detailed prototype system is currently being implemented.
We are also studying the issues of developing
a graphical environment for specifying, testing, simulating
and maintaining the workows.
Acknowledgements : The METEOR technical team
at Bellcore, Henri Weinberg and Chris Wood, and our long
time collaborator Prof. Marek Rusinkiewicz have had signicant
inuence on our thinking and this work. Our special
thanks to all application experts and developers at
Bellcore to whom this work has been directed, for their
participations in a task force, for sharing their future application
requirements, and for informally reviewing our
work.
References
[1] M. Ansari, L. Ness, M. Rusinkiewicz, and A. Sheth.
Using Flexible Transactions to Support Multi-System
Telecommunication Applications. In Proc. of the 18th
VLDB Conference, August 1992.
[2] P. Attie, M. Singh, A. Sheth, and M. Rusinkiewicz.
Specifying and Enforcing Intertask Dependencies. In
Proc. of the 19th VLDB Conference, 1993.
[3] P. Bernstein, P. Gyllstorm and T. Wimberg. STDL -
APortable Language for Transaction Processing. In
Proc. of the 19th VLDB Conference, 1993.
[4] Y. Breitbart, A. Deacon, H.-J. Schek, A.Sheth,
and G. Weikum Merging Application-centric and
Data-Centric Approaches to Support Transactionoriented
Multi-system Workows. In SIGMOD
Record, September 1993
[5] J. Chen, O. Bukhres, and A. Elmagarmid. IPL:
A Multidatabase Transaction Specication Language.
In Proc. of the 13th Intl. Conf. on Distributed Computing
Systems, Pittsburgh, PA, May 1993.
[6] P. Chrysanthis and K. Ramamritham. A Formalism
for Extended Transaction Models. In Proc. of the 17th
VLDB Conference, 1991.
[7] U. Dayal, M. Hsu, and R. Ladin. Organizing Long-
Running Activities with Triggers and Transactions.
In Proc. of ACM SIGMOD Conf. on Management of
Data, 1990.
[8] U. Dayal, M. Hsu, and R. Ladin. ATransactional
Model for Long-Running Activities. In Proc. of the
17th VLDB Conference, September 1991.
[9] U. Dayal and M. Shan. Issues in Operation Flow Management
for Long Running Activities. In [10].
[10] M. Hsu, editor. Special Issue on workow and Extended
Transaction Systems, 16 (2), June 1993.
[11] A. Elmagarmid, editor. Transaction Models for Advanced
Database Applications. Morgan-Kaufmann,
February 1992.
[12] A. Elmagarmid, J. Chen, and O. Bukhres. Remote
System Interfaces : An Approach toOvercome Heterogeneous
Barriers and Retain Local Autonomy in
the Integration of Heterogeneous Systems. the Intl.
Journal on Intelligent and Cooperative Information
Systems, 1993. (to appear).
[13] A.K. Elmagarmid, Y. Leu, W. Litwin, and
M. Rusinkiewicz. A Multidatabase Transaction Model
for InterBase. In Proc. of the 16th VLDB Conference,
1990.
[14] H. Garcia-Molina, D. Gawlick, J. Klein, K. Kleissner,
and K. Salem. Coordinating Multi-transaction Activities.
Technical Report CS-TR-247-90, Princeton
University, February 1990.
[15] D. Georgakopoulos, M. Hornick, P.Krychniak, and F.
Manola. Specication and Management of Extended
Transactions in a Programmable Transaction Environment.
In Proc. of the Intl. Conf. on Data Engineering,
February 1994.
[16] R. Gunthor. Extended Transaction Processing Based
on Dependency Rules. In Proc. of the RIDE-IMS '93:
Intl. Workshop on Multidatabase Systems, April 1993.
[17] M. Hsu, R. Obermarch, and R. Vuurboom. Integration
and Interoperability of a Multimedia Workow
Model and Execution. In [10].
[18] Y. Halabi et. al. Narada: An Environment for Speci-
cation and Execution of Multi-System Applications.
In Proc. of the 2nd Intl. Conf. on Systems Integration,
1992.
[19] W. Jin, L. Ness, M. Rusinkiewicz, A. Sheth. Concurrency
Control and Recovery of Multidatabase Work
Flows in Telecommunication Applications. In Proc. of
ACM SIGMOD Conf. on Management of Data, May
1993.
Page 11

[20] J. Klein. Advanced Rule Driven Transaction Management.
In Proc. of the IEEE COMPCON, 1991.
[21] N. Krishnakumar and A. Sheth. Specifying Multisystem
Workow Applications in METEOR. Bellcore
Technical Memorandum TM-24198, May 1994.
[22] P. Krychniak, M. Rusinkiewicz, A. Sheth, and
G. Thomas. Bounding the Eects of Compensation
under Relaxed Multi-level Serializability. Technical
Report UH-CS-92-06, Dept. of Computer Science,
University of Houston, March 1992.
[23] D. McCarthy and S. Sarin. Workow and Transaction
in InConcert. In [10].
[24] R. Medina-Mora,
H. Wong, and P. Flores. ActionWorkow TM as the
Enterprise Integration Technology. In [10].
[25] H. Wachter and A. Reuter. The ConTract Model.
Chapter 7, In [11], 1992.
[26] M. Rusinkiewicz, S. Osterman, A. Elmagarmid, and
K. Loa. The Distributed Operational Language for
Specifying Multisystem Applications. In Proc. of the
1st Intl. Conf. on Systems Integration, 1990.
[27] M. Rusinkiewicz and A. Sheth. Specication and
Execution of Transactional Workows. In Modern
Database Systems: The Object Model, Interoperability,
and beyond, W. Kim, Ed., Addison-Wesley/ ACM
Press, 1994.
[28] A. Sheth and M. Rusinkiewicz. On Transactional
Workows, In [10].
[29] C. Tomlinson et. al. Workow Support in Carnot. In
[10].
[30] G. Weikum and H.-J. Schek. Concepts and applications
of multilevel transactions and open nested transactions.
Chapter 13, In [11].
ActionWorkow is a trademark of Action Technologies, Inc.
Page 12