[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
SWAP Working Group                              Surendra Reddy(Oracle)
Internet Draft                                          August 6, 1998
draft-sreddy-swap-requirements-01.txt              Expires Feb 6, 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 <swap-
   wg@netscape.com>, which may be joined by sending a message with
   subject "subscribe" to <swap-wg-request@netscape.com>.

   Discussions of the SWAP working group are archived at
   <URL:http://www.ics.uci.edu/pub/ietf/swap>.


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
   growth of internet and web technologies has changed our computational



Surendra Reddy                                                  [Page 1]


draft-sreddy-swap-requirements-01.txt                        Feb 6, 1999


   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.

    Basic units of any organization are the work processes performed
    within it. Process refers to a business process and its correspond-
    ing information process. Workflow management involves everything
    from defining and modeling processes up to synchronizing the activi-
    ties of performers (information systems or humans) that perform the
    processes.

    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



Surendra Reddy                                                  [Page 2]


draft-sreddy-swap-requirements-01.txt                        Feb 6, 1999


    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 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 performed 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 Work Item is a special kind of process instance that instead of
    performing something, simply represents that activity being per-
    formed by a person. The work items hold the references to the
    activities for the people.

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
    the protocol to schedule, execute, control and monitor workflow
    tasks as defined by work flow specification. The SWAP interprets the
    workflow specifications and controls the instantiation of processes
    and sequencing of activities, adding work items to the users "todo"
    lists. SWAP also provides data formats to exchange workflow specifi-
    cations across different workflow systems.  SWAP will not define
    methods to define workflow specifications.






Surendra Reddy                                                  [Page 3]


draft-sreddy-swap-requirements-01.txt                        Feb 6, 1999


3.1.  Data Format Requirements
    This protocol MUST define data formats for interchanging process
    descriptions, and process coordination rules defined as workflow
    specifications.

3.2.  Specification of Process Instances
    The idea of workflow can be traced to Job Control Language of batch
    operating systems which allowed user to specify a job as a collec-
    tion of steps. Each step was an invocation of a program and the
    steps are executed in sequence. Some steps could be executed condi-
    tionally.

    From the view point of a workflow, all details of the Process
    Instance that describe its sequential processing are unnecessary.
    SWAP protocol SHALL 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 conditions that enable these transitions.

    Transitions between various states of a Process Instance may be
    affected by various scheduling events. Some of these transitions are
    controlled by the SWAP responsible for inter Process Instance depen-
    dencies. For example,
     Process Instance can be submitted for execution thus resulting in a
    state transition from "Initial" to "Running". It SHOULD be possible
    to query on various states of the Process Instance and SHOULD be
    able to suspend and resume Process Instances by the requestor.

    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
    An output or partial output of a Process Instance may be made avail-
    able to other process instance. SWAP SHOULD be able to provide
    methods to query and retrieve Process Instance generated data, state
    variables and error messages.

3.4.  Process Instance Co-ordination Requirements
    Once the process instances constituting a workflow are defined, the
    control flow of the workflow is driven by the process instance co-
    ordination. How each process instance is started or stopped. It
    SHOULD be possible for the SWAP protocol to determine the process
    instance state or control the process instances.

3.5.  Failure Atomicity Requirements
    Workflow consists of process instances and process co-ordination
    rules. Failure atomicity requires that failure of any process



Surendra Reddy                                                  [Page 4]


draft-sreddy-swap-requirements-01.txt                        Feb 6, 1999


    instance would result in a failure of a workflow. SWAP MUST provide
    methods to guarantee the failure atomicity.

3.6.  Execution Automicity Requirements
    In a distributed environment, Process instances may use data span
    across multiple systems. To ensure the integrity of the data would
    require that a whole workflow constitute an execution atomic unit.
    Therefore, an interleaved execution of workflows should have the
    same effects as of they were executed serially. For example, con-
    sider a workflow that transfer money between two accounts in two
    different banks. To avoid inconsistent access of the databases of
    those banks, all processes that operate on those data should consti-
    tute an execution-atomic unit with respect to other concurrent tran-
    sactions.  SWAP MUST provide methods to guarantee the execution
    automicity.

3.7.  Dynamic Monitoring and Control of Process Instances
    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.8.  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.9.  System Behavior
    SWAP MAY provide methods to query on run-time information of the
    process instances to understand the system or process instance
    behavior.

3.10.  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 partners SHOULD be relieved from being continuously
    present and watch the process. Awareness information should be visi-
    ble 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 aware-
    ness information MAY be required.




Surendra Reddy                                                  [Page 5]


draft-sreddy-swap-requirements-01.txt                        Feb 6, 1999


    It SHOULD also provides methods to query or retrieve this informa-
    tion or register for delivering this data to the Observer through
    notifications.

3.11.  Monitoring of Processes Instances

    Since many processes are likely to be underway at any given time,
    the system facilitates 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.

3.12.  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.13.  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.14.  Scalability and Availability
    Some of the goals of the workflow systems are to achieve better per-
    formance of business processes, better quality, enhanced



Surendra Reddy                                                  [Page 6]


draft-sreddy-swap-requirements-01.txt                        Feb 6, 1999


    effectiveness, enterprise- wide coordination and monitoring. Given
    its goals, workflow systems must be able to deal with local and com-
    munication 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.

    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).


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.

5.  Open Issues
    (1). Correctness of Process Scheduling:  The SWAP cannot violate any
    of the dependencies provided in the specification while instantiat-
    ing process instances. SHOULD SWAP be aware of how it can interpret
    these inter-process dependencies and state-transition criteria for
    workflows?

    (2). SHOULD  SWAP need to guarantee the correctness of schedules --
    validating pre and post execution requirements defined as task co-
    ordination requirements in the workflow definitions?

    (3). SHOULD SWAP include Event - Condition - Action Rules for defin-
    ing inter-process dependencies?

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.



Surendra Reddy                                                  [Page 7]


draft-sreddy-swap-requirements-01.txt                        Feb 6, 1999


    [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-00.txt,
    April, 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

    Expires February 6, 1999































Surendra Reddy                                                  [Page 8]