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]