Network Working Group Surendra Reddy Internet Draft Oracle Corporation draft-sreddy-swap-requirements-00.txt May 2, 1998 Expires November 2, 1998 Requirements for Simple Workflow Access Protocol - SWAP 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 docu- ments 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 swap-wg@netscape.com, which may be joined by sending a message with subject "subscribe" to swap-wg-request@netscape.com. 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 landscape to distributed, heterogenous and network centric computing model from centralized, desktop-oritented, and homogenous computing. This has raised challenging requirements for Surendra Reddy [Page 1]
draft-sreddy-swap-requirements-00.txt April 1998 workflow technologies in terms being required to support heterogenous, distributed computing infrastructures, interoperability, scalability and availability. The main objective of this document is to identify various business scenarios, requirements for internet based Workflow Access Protocol. 1. Introduction 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 landscape to distributed, heterogenous and network centric computing model from centralized, desktop-oritented, and homogenous computing. This has raised challenging requirements for workflow technologies in terms being required to support heterogenous, distributed 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 corresponding information process.Workflow management involves everything from defining and modelling processes up to synchronizing the activities of performers (information systems or humans) that perform the processes. 2. Terminology Workflow Workflow is an activity in involving the coordinated execution of multiple tasks performed by different processing entities[KS95]. 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 A workflow process is an automated organizational process involving both manual and automated tasks.A Work process is a communicative Surendra Reddy [Page 2]
draft-sreddy-swap-requirements-00.txt April 1998 relation between a customer and a performer within which both assume responsibilties and consume time and resources. Moreover, it is a cycle; the relation between the customer and the performer does not restart at any new request for action the former proposes to the later or any re-negotiation of the current request. From a Work process we can abstract its work flow, taking into account only the performed input-output transformation. Workflow Management Workflow management is the automated coordination, control and communication 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. Notifications Notifications are defined as psuedo action-items in that they are sent by process performers in response to a call from application. 3. Workflow Management Requirements Workflow Management involves everything from modeling business proceses as workflow specifications upto coordinating workflow processes, monitoring, and notifying these interactions among the various workflow processes and users. In particular, Workflow Management involves: a. processing modeling as workflow specifications b. workflow enactment services to implement, schedule, execute, monitor coordinate workflow processes by interpreting workflow specifications. Following sections describe each of these requirements in detail. 3.1. Workflow specification Workflow specification defines workflow models and methodologies for capturing a process specification. The execution structure of each is each task is defined by providing a set of externally observable execution states and a set of transitions between these states. Specification of workflow invloves describes tasks and processing entitites that are relevant to controlling and coordinating their execution.It also requires specification of relationships among tasks and their execution environment as task coordination rules or constraints. Task coordination expresses as intertask execution dependencies and Surendra Reddy [Page 3]
draft-sreddy-swap-requirements-00.txt April 1998 data-flow dependencies, as well as the termination conditions of the workflow. Task Description describes individual tasks within a process are documented. A Process engineer authors these documents when defining the process. User SHOULD be able to checkout, revide, edit all these process documents. This protocol MUST support mechanisms or data formats for representing task descriptions, and task coordination rules as workflow specifications. It MUST also support metadata to describe application specific workflow data and workflow process metadata. 3.2. Roles and Delegation Roles and Delegation facilitates an ability to associate or delegate users and processes to roles and management of these associations. Workflow specification may refer to an Organization/Role model which contains information concerning organizational structure and roles within organizational model. This enables workflow specification in terms of organizational entities and role functions. 3.3. Workflow enactment Defines methodologies/protocols to schedule, execute, control and notify workflow tasks as defined by work flow specification. The workflow enactment interprets the workflow specifications and controls the instantiation of processes and sequencing of activities, adding work items to the users "todo" lists. 3.4. Dynamic modification of workflow the ability to change task sequencing or introduce new tasks into an existing workflow 3.5. Event notification Define ability to raise events in one task and have another task notice that event and take action on it.This section identifies the motivating factors for the need for Notification mechanisms within the Workflow environment. 3.5.1. Pure sharing allows access to material of collaboration, but in order to coordinate the actions of the material, it is necessary to inform and be informed about the past and current actions performed by the other users of the shared material. Surendra Reddy [Page 4]
draft-sreddy-swap-requirements-00.txt April 1998 3.5.2. Understanding the system behavior for understanding of the behavior of a collaborative workspace it is necessary to recognize the causes for changes. 3.5.3. Coordination of actions In order to continue the co-operation process, awareness information about completed actions is required. 3.5.4. Awareness It must be required to record awareness information about actios and disseminates them across time and space to the participants. In a time deferred processes, the partners SHOULD be relieved from being continuously present and watch the process. This implies, awareness information cannot be volatile but needs to have some persistency. 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 will be required. 3.5.5. Scope of the awareness information Awareness information needs to occur, before the participant initiates the next action in the effected context. 3.5.6. Distance and provision of awareness The provision modes should range from drawing attention, via displaying when relevant, to presenting on request only. The members of the "Collborative" workspace need to be provided with awareness information which allows them to watch the ongoing process. It should allow to understand the current process, recognize the traces of changes, and to re-construct modifications of materials and their authors. 3.5.7. Monitoring of Workflow Processes: 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 holding 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 Surendra Reddy [Page 5]
draft-sreddy-swap-requirements-00.txt April 1998 this process, how long it took on average to complete. This historical reporting provides valuable feedback for process engineering. 3.6. Exception handling and revovery A workflow represents a very complex computational activity which consists of many tasks whose execution needs to be coordinated. 3.7. Transactional support Workflow systems require the participation of multiple application systems and databases. It is desirable that workflow systems maintain at least some of the safeguards of traditional transactions related to the correctness of computations and data interity. 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 donot provide the information and services thaat would be necessary to execute the distributed transactions while supporting the required transaction semantics. 3.7.1. Security Sophisticated mechanisms for security, authentication and access control MUST be supported. 3.8. Scalability and availability Some of the goals of the workflow systems are to achieve better performance of business processes, better quality, enhanced effectiveness, 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. It is also necessary to deal with other issues which are dominant in the current workflow systems, such as dynamic configuration, addition 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 locaton procotocl, LDAP replication mechanims are best examples to consider in this protocol). Surendra Reddy [Page 6]
draft-sreddy-swap-requirements-00.txt April 1998 3.9. Workflow Use Case (1). Define terms to be used in expressing progress of the Work being executed. (2). Create new processes and define their pre and post conditions a. each process consists of one or more actions. b. each process may also have an arbitrary number of operand on which the process operates c. Terminal conditions - stating what states must hold to declare the process itself completed. d. Creating instances of these processes e. Setting initiatives in motions. When an initiative is started each of its steps having no precondition is automatically activated. (3). Notifying users about actions that need completion (4). Managing reminders, alerts, follow-ups to keep processes moving along (5). Giving users an overview of where their tasks fit into the overall processes, both dynamically and through maintaing records of workflow history and providing structured access to them. Simple workflow structure is both general and universal. It is general in that it occurs whenever there is co-ordination among people, regardless of what they are doing. 3.10. Workflow Scenarios (1). The New Service Provision workflow captures the process of telephone service provisioning for a new customer. The workflow starts when when a customer requests for a new telephone connection. Objective of this workflow is to construct circuit from a customer location to the appropriate telephone switch and allocate equipment to connect the circuit. a. Operator collects information from the customer b. Check if all required information is collected from the customer c. Verify if the information provided by the customer is accurate Surendra Reddy [Page 7]
draft-sreddy-swap-requirements-00.txt April 1998 d. Create a service order for the customer e. check if customer can be connected using existing facilities f. Check the best alternate paths can be used to connect the customer g. Provide installation instructions to techinicans h. Technican installs the equipment, updates the service order i. Update the telephone directory j. Updates to telephone switch to activates the service k. Generates the bill Process dependencies Step 1: (a) starts (b) starts (c) starts (d) Step 2: (d) starts (e) ( (if (e) is successful, starts (g)) else starts (f) starts (g) ) Step 3: (g) starts (h) starts (i) starts (j) starts (k) (2). Distributed Authoring workflow captures the process of authoring, distributing, reviewing. a. create document(s) b. select reviewers c. distribute document(s) to reviewers d. reviewers collaborate and produce a joint review document e. forward review document to authors (3). Insurance Claims Process Workflow. Following steps describe various tasks involved in this workflow: (a). capture the claim form (b). check if the claim can ve paid (c). if the claim is accepted, trigger the payment workflow (d). if the claim is rejected, claim representative calls the customer, either agrees to make some payment or reject the cliam. In this workflow, it is (1). the interaction of information systems with business process (2). need to automated task performers Surendra Reddy [Page 8]
draft-sreddy-swap-requirements-00.txt April 1998 4. Security Considerations Since workflow interoperability may involve the exchange of sensitive information, any workflow interoperability mechanism must provide 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. 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-00.txt, April, 1998. [KS95] N.Krishnakumar and A.Sheth, "Managing Heterogeneous Multi-system Tasks to Support Enterprise-wide Operations", Distributed and Parallel Databases, (3):155-186, April 1995. [Kamath et al., 1996] Mohan U. Kamath and Krithi Ramamritham, "Correctness Issues in Workflow Management", Distributed Systems Engineering (DSE) Journal : Special Issue on Workflow Management Systems, Volume 3, Number 4, December 1996. [Bre93] Breitbart, Y., Deacon, A., Schek, H.J., Sheth,A., and Weikum. G. Merging Application-centric and Data-centric Approaches to Support Transaction-Oriented Multi-system Workflows. In ACM SIGMOD Record, 22(3), September 1993. [Elm92] A. Elmagarmid, editor. Database Transaction Models for Advanced Applications Morgan-Kaufmann, 1992. [Geo95] Georgakopoulos D., Hornick M., and Sheth A. An Overview of Workflow Management: From Process Modelling to Workflow Automation Infrastructure., In Distributed and Parallel Databases, 3(2):119-152, Surendra Reddy [Page 9]
draft-sreddy-swap-requirements-00.txt April 1998 1995. [Hsu95] M. Hsu. Special Issue on Workflow Systems. Bulletin of the Technical Committee on Data Engineering, IEEE, 18(1), 1995. [She93] A. Sheth and M. Rusinkiewicz. On transactional workflows. Bulletin of the Technical Committee on Data Engineering, 16(2), June 1993. IEEE Computer Society. 6. Author's Address Surendra Reddy Oracle Corporation 500 Oracle Parkway M/S 6op3 Redwoodshores, CA 94065 Phone: +1(650) 506 5441 Fax: +1(650) 654 6205 Email: skreddy@us.oracle.com Expires November 2, 1998 Surendra Reddy [Page 10]