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]