SWAP Working Group Surendra Reddy(Oracle)
Internet Draft Matthew Pryor(Verve)
draft-sreddy-swap-requirements-02.txt November 17, 1998
Expires May 17, 1999
Requirements for Simple Workflow Access Protocol
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments to
the Simple Workflow Access Protocol (SWAP) working group at , which may be joined by sending a message with subject
"subscribe" to .
Discussions of the SWAP working group are archived at
.
Abstract
Workflow is intuitive and powerful paradigm for capturing business
processes, reasoning about them, and process specifications to
produce corresponding implementations that are supported by the
information systems. There has been a growing acceptance of workflow
technology in numerous application domains such as
telecommunications, software engineering, manufacturing, production,
finance and banking, laboratory sciences, healthcare, shipping and
office automation.
In the last few years, pervasive network connectivity, exploded
Surendra Reddy, Matthew Pryor [Page 1]
draft-sreddy-swap-requirements-02.txt Feb 6, 1999
growth of Internet and web technologies has changed our computational
landscape to distributed, heterogeneous and network centric computing
model from centralized, desktop-oriented, and homogenous computing.
This has raised challenging requirements for workflow technologies in
terms being required to support heterogeneous, distributed computing
infrastructures, interoperability, scalability and availability.
The main objective of this document is to identify various business
requirements for Internet based Workflow Access Protocol to
instantiate, control and monitor the workflow process instances.
Definition and administration of process specifications are not
discussed in this requirements.
1. Introduction
Workflow is intuitive and powerful paradigm for capturing business
processes, reasoning about them, and process specifications to pro-
duce corresponding implementations that are supported by the infor-
mation systems. There has been a growing acceptance of workflow
technology in numerous application domains such as telecommunica-
tions, software engineering, manufacturing, production, finance and
banking, laboratory sciences, healthcare, shipping and office auto-
mation.
In the last few years, pervasive network connectivity, exploded
growth of Internet and web technologies has changed our computa-
tional landscape to distributed, heterogeneous and network centric
computing model from centralized, desktop-oriented, and homogenous
computing. This has raised challenging requirements for workflow
technologies in terms being required to support heterogeneous, dis-
tributed computing infrastructures, interoperability, scalability
and availability.
The main objective of this document is to identify various business
requirements for Internet based Workflow Access Protocol to instan-
tiate, control and monitor the workflow process instances. Defini-
tion and administration of process specifications are not discussed
in this requirements.
2. Terminology
Workflow
The automation of a business process, in whole or part, during which
documents, information or tasks are passed from one participant to
another for action, according to a set of procedural rules. Workflow
is an activity in involving the coordinated execution of multiple
tasks performed by different processing entities. Workflow is
structured around the domain of information processes and define as
Surendra Reddy, Matthew Pryor [Page 2]
draft-sreddy-swap-requirements-02.txt Feb 6, 1999
a sequence of actions to be performed on information properties. The
primary organizing structure is the routing of information objects
among users or actors, specification of automatic actions to be per-
formed in the routing.
Workflow Process Instance
The Process Instance is the actual performer of the service. Simple
Process instances are self contained, not relying on any external
Observer.
Notifications
Notifications are defined as psuedo action-items in that they are
sent by process performers in response to a call from application.
Observer
Process Observer monitors the Process Instances. The Process
Instance knows very little about who or what invoked it. However,
Process Instance communicate is state to the Process Observer.
Work Item
A runtime instance of an activity that requires work to be done by a
participant. The work items hold the references to the activities
for the people.
Worklist
A list of all outstanding workitems for a particular participant.
Participant
An object which represents either a user or entity which can actu-
ally perform work.
Workflow Management
Workflow management is the automated coordination, control and com-
munication of work as is required to satisfy workflow processes.
Workflow Management is process focused - coordinating activities of
people working in a common task or project. Workflow Management
makes sure that activities occur in proper sequence, and that users
are informed so they can complete tasks on time.
3. Simple Workflow Access Protocol
The objective of Simple Workflow Access Protocol(SWAP) is to define
mechanisms to schedule, execute, control and monitor workflow pro-
cess instances as defined by work flow definitions to provide
interoperability between different workflow engines. The SWAP com-
pliant service interprets the workflow specifications and controls
the instantiation of processes and sequencing of activities, adding
work items to the users "todo" lists. SWAP will not define methods
for creating and managing workflow definitions.
Surendra Reddy, Matthew Pryor [Page 3]
draft-sreddy-swap-requirements-02.txt Feb 6, 1999
3.1. Data Format Requirements
This protocol MAY define data formats for interchanging process
descriptions, and process coordination rules defined as workflow
specifications.
3.2. Specification of Process Instances
From the view point of SWAP, all details of the process specifica-
tions that describe its sequential or conditional processing, pro-
cess activiation rules are unnecessary. All transitions between
various states of process instance are controlled by the workflow
engines as per the workflow specifications. SWAP SHALL only deal
with those aspects that are externally visible like (1) a set of
externally visible execution states of the process instance, (2) a
set of valid transitions between these states, and (3) the condi-
tions that enable these transitions. The details of how workflow
process works can be hidden from SWAP and isolated inside the work-
flow engine.
SWAP MAY NOT provide any facilities for defining or modifying the
process definitions or rules associated with these process
instances.
3.3. Communication between Process Instances
Process instances can share intermediate results with other process
instances; that also implies that SWAP should aware of dependencies
between process instances . SWAP SHOULD be able to provide methods
to query and retrieve Process Instance generated data, state vari-
ables and error messages. SWAP SHOULD also provide mechanisms to
define and manage the dependencies between the process instances.
3.4. Coordination of Process Instances
In order to continue the co-operation process, awareness information
about completed actions is required. It must be required to record
awareness information about actions and process instance state tran-
sitions along with the process generated data. In a time deferred
processes, the participants SHOULD be relieved from being continu-
ously present and watch the process. Awareness information should be
visible if relevant for the current action, it SHOULD be available
after a while of absence to inform about the intermediate progress,
or on request to give more details, or to inform about the history
of actions performs. Awareness information needs to persist as long
as it may be necessary in the process. Process specific aging of
awareness information MAY be required.
It SHOULD also provides methods to query or retrieve this informa-
tion or register for delivering this data to the Observer through
notifications.
Surendra Reddy, Matthew Pryor [Page 4]
draft-sreddy-swap-requirements-02.txt Feb 6, 1999
SWAP should be constructed in such a way that if a given exchange
completes successfully, meaning that an OK result was received, then
the client system can have high certainty that this action has hap-
pened on the server. SWAP interchanges should be designed so that
each interaction takes the server from one well defined state to
another well defined state. Another way to say this is that the
server does not have to maintain any temporary information from
requests to request.
3.5. Monitoring of Processes Instances
Since many processes are likely to be underway at any given time,
SWAP MUST facilitate inquires into the status of certain processes
as they are being executed. The user may also want to know why a
particular process has not yet been completed, and will be able to
identify the task and its associated responsible user that are hold-
ing up the process.
After each process is completed, all information relating to that
process and all tasks that were carried out to complete that process
need to be recorded. These process histories MUST be queriable as
find out how many times a particular process has run, who initiated
this process, how long it took on average to complete. This histori-
cal reporting provides valuable feedback for process engineering.
SWAP SHOULD provide the ability to suspend, resume, cancel or ter-
minate any executing process instances. It SHOULD also provide
methods to monitor long running activities and access intermediate
data of these process instances.
3.6. Event Notification
SWAP SHOULD be able to accept requests for monitoring and notifying
specific states of the process instance. For example, user can
register with SWAP to notify an Observer when the process instance
is completed or when the process instance state matches with the
registered state.
3.6.1. Defined States
SWAP MUST define a minimal set of states with meanings such that a
generic service can be monitored and controlled through a set of
defined states.
3.6.2. Sub-state Extension
SWAP MUST define an extension mechanism for the state values such
that sub-states, within a known state can be defined, so that more
information can be communicated to clients that know about the
extensions, while clients without any knowledge of the extensions
can still understand the state value at least to the extent of the
minimal set of states.
Surendra Reddy, Matthew Pryor [Page 5]
draft-sreddy-swap-requirements-02.txt Feb 6, 1999
3.7. Process Instance Lifecycle
SWAP MAY provide methods to query on run-time information of the
process instances to understand the system or process instance
behavior. SWAP MUST provide a way to get information about a given
instance as long as it is around. But at some point the completed
process instance will be removed from the server and it is no longer
accessible by SWAP. In such case, SWAP MUST specify a proper error
response that accurately indicate this situation.
3.8. Exception Handling and Recovery
A workflow represents a very complex computational activity which
consists of many tasks whose execution needs to be coordinated.
Therefore, SWAP should provide comprehensive error handling and
recovery procedures.
SWAP should be able to reach an acceptable termination state even in
the case of a failure. For example, the SWAP could continue process-
ing after a failure and recovery as if nothing happend, thus provid-
ing a forward recoverability.
3.9. Transactional support
Workflow systems require the participation of multiple application
systems and databases. It is desirable that workflow systems main-
tain at least some of the safeguards of traditional transactions
related to the correctness of computations and data integrity. In a
multi-system workflow main problem is the need to preserve the
autonomy of participating systems. Since many systems used in
multi-system workflows were designed for standalone operation, they
normally do not provide the information and services that would be
necessary to execute the distributed transactions while supporting
the required transaction semantics. Providing transactional support
for distributed process instances is not within the scope of the
SWAP.
3.10. Scalability and Availability
Some of the goals of the workflow systems are to achieve better per-
formance of business processes, better quality, enhanced effective-
ness, enterprise- wide coordination and monitoring. Given its goals,
workflow systems must be able to deal with local and communication
failures, and the system must be continuously available as its
relevance in the control of the business processes.
High availability is a key requirement of workflow systems and
failures should be transparent to the users and should have minimal
impact on the normal functioning of the organization.
Surendra Reddy, Matthew Pryor [Page 6]
draft-sreddy-swap-requirements-02.txt Feb 6, 1999
3.11. Integration with other protocols
It is also necessary to deal with other issues which are dominant in
the current workflow systems, such as dynamic configuration, addi-
tion of new services without reconfiguring the whole system, message
replication and recovery facilities. These requirements are not
critical, but good to address as lot of relevant work is underway in
IETF(e.g. wide area service location protocol, LDAP replication
mechanisms are best examples to consider in this protocol).
3.12. Simplicity and Ease of Implementation
The protocol SHOULD be lightweight and easy to implement, so that a
variety of devices and situations can be covered. The service can be
considered to be a "black box" which has been pre-configured to do a
particular process. SWAP does not provide a way to discover the
internal details of the service.
3.13. Quality of Service
SWAP SHOULD be designed to work in an environment where quality of
service is quite variable. This means that we should consider the
effect of being cut off, and what has to be done in order to deter-
mine whether or not your request was successful. We have to consider
the fact that a notification for completion of a process instance
may get lost, and therefore we need a way to poll and get all the
information that the notification would have been delivered.
4. Security Considerations
Since workflow interoperability may involve the exchange of sensi-
tive information, any workflow interoperability mechanism must pro-
vide for encryption and authentication. Several techniques such as
SSL and HTTP Access Authorization are available for use in Internet
protocols. Without such techniques, SWAP clients and servers are
wide open to forged or snooped workflow proposals or authorizations.
4.1. Client Security
SWAP MUST provide for the fact that some clients will need a high
security connection between client-server session.
4.2. Client Identity
SWAP MUST provide a way for the server to know with high certainty
who the client is, in order to use that information for access con-
trol. In this configuration it should not be possible (or at least
astronomically difficult) for a user to masquerade as another user,
and retrieve information or take actions that normally only that user
would be able to do.
4.3. Simple Security
SWAP MUST allow low-security implementation where a relatively sim-
ple and lightweight mechanism is used for authentication that does
Surendra Reddy, Matthew Pryor [Page 7]
draft-sreddy-swap-requirements-02.txt Feb 6, 1999
not require a large maintenance overhead, still gives the server a
moderate amount of confidence that a client is who the client claims
to be.
4.4. Access Control
SWAP MUST not proscribe how user access is controlled. The workflow
system is fully responsibe for determining, by whatever means at
it's disposal, what users can have access to what. This access is
controlled on the server, and server does not have to trust that the
client will obey any security policies. When the user can access
part of the information which a command might normally return, then
that part of the information should be able to be communicated
without ambiguity to the client. If none of the information is
accessible to that user, and error response should be provided that
does not indicate any details about the inner workings of the access
control rules.
5. Acknowledgments
This draft has benefited from thoughtful discussion by Keith Swen-
son, Larry Masinter, George Buzsaki, and Michael Oliver.
6. References
[Bradner, 1997] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels." RFC 2119, BCP 14. Harvard University. March,
1997.
[Fielding et al., 1997] R. Fielding, J. Gettys, J. Mogul, H.
Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1."
RFC 2068. U.C. Irvine, DEC, MIT/LCS. January, 1997.
[Bradner, 1996] S. Bradner, "The Internet Standards Process -
Revision 3." RFC 2026, BCP 9. Harvard University. October, 1996.
[S.Reddy,1998] Surendra Reddy, "Requirements for Event Notification
Protocol",ftp://ftp.ietf.org/internet-drafts/draft-ietf-webdav-enpreq-01.txt,
May, 1998.
7. Author's Address
Surendra Reddy
Oracle Corporation
500 Oracle Parkway
M/S 4op12
Redwoodshores, CA 94065
Phone: +1(650) 506 5441
Email: skreddy@us.oracle.com
Surendra Reddy, Matthew Pryor [Page 8]
draft-sreddy-swap-requirements-02.txt Feb 6, 1999
Matthew Pryor
Verve, Inc
81 Clementina St,
2nd Floor,
San Francisco, CA 94114
(888) 327 8085 x102
Expires May 17, 1999
Surendra Reddy, Matthew Pryor [Page 9]