idnits 2.17.1 draft-sreddy-swap-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 303 has weird spacing: '...orkflow inter...' == Line 304 has weird spacing: '...orkflow inter...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: SWAP MAY NOT provide any facilities for defining or modifying the process definitions or rules associated with these process instances. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feb 6, 1999) is 9210 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Bradner' is defined on line 333, but no explicit reference was found in the text == Unused Reference: '1997' is defined on line 325, but no explicit reference was found in the text == Unused Reference: '1996' is defined on line 333, but no explicit reference was found in the text -- Duplicate reference: RFC2026, mentioned in '1996', was also mentioned in 'Bradner'. Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SWAP Working Group Surendra Reddy(Oracle) 3 Internet Draft August 6, 1998 4 draft-sreddy-swap-requirements-01.txt Expires Feb 6, 1999 6 Requirements for Simple Workflow Access Protocol 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or made obsolete by other documents at 17 any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress". 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 23 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 24 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 Distribution of this document is unlimited. Please send comments to 27 the Simple Workflow Access Protocol (SWAP) working group at , which may be joined by sending a message with 29 subject "subscribe" to . 31 Discussions of the SWAP working group are archived at 32 . 34 Abstract 36 Workflow is intuitive and powerful paradigm for capturing business 37 processes, reasoning about them, and process specifications to 38 produce corresponding implementations that are supported by the 39 information systems. There has been a growing acceptance of workflow 40 technology in numerous application domains such as 41 telecommunications, software engineering, manufacturing, production, 42 finance and banking, laboratory sciences, healthcare, shipping and 43 office automation. 45 In the last few years, pervasive network connectivity, exploded 46 growth of internet and web technologies has changed our computational 47 landscape to distributed, heterogeneous and network centric computing 48 model from centralized, desktop-oriented, and homogenous computing. 49 This has raised challenging requirements for workflow technologies in 50 terms being required to support heterogeneous, distributed computing 51 infrastructures, interoperability, scalability and availability. 53 The main objective of this document is to identify various business 54 requirements for internet based Workflow Access Protocol to 55 instantiate, control and monitor the workflow process instances. 56 Definition and administration of process specifications are not 57 discussed in this requirements. 59 1. Introduction 61 Workflow is intuitive and powerful paradigm for capturing business 62 processes, reasoning about them, and process specifications to pro- 63 duce corresponding implementations that are supported by the infor- 64 mation systems. There has been a growing acceptance of workflow 65 technology in numerous application domains such as telecommunica- 66 tions, software engineering, manufacturing, production, finance and 67 banking, laboratory sciences, healthcare, shipping and office auto- 68 mation. 70 In the last few years, pervasive network connectivity, exploded 71 growth of internet and web technologies has changed our computa- 72 tional landscape to distributed, heterogeneous and network centric 73 computing model from centralized, desktop-oriented, and homogenous 74 computing. This has raised challenging requirements for workflow 75 technologies in terms being required to support heterogeneous, dis- 76 tributed computing infrastructures, interoperability, scalability 77 and availability. 79 Basic units of any organization are the work processes performed 80 within it. Process refers to a business process and its correspond- 81 ing information process. Workflow management involves everything 82 from defining and modeling processes up to synchronizing the activi- 83 ties of performers (information systems or humans) that perform the 84 processes. 86 The main objective of this document is to identify various business 87 requirements for internet based Workflow Access Protocol to instan- 88 tiate, control and monitor the workflow process instances. Defini- 89 tion and administration of process specifications are not discussed 90 in this requirements. 92 2. Terminology 94 Workflow 95 Workflow is an activity in involving the coordinated execution of 96 multiple tasks performed by different processing entities. Workflow 97 is structured around the domain of information processes and define 98 as a sequence of actions to be performed on information properties. 99 The primary organizing structure is the routing of information 100 objects among users or actors, specification of automatic actions to 101 be performed in the routing. 103 Workflow Process Instance 104 The Process Instance is the actual performer of the service. Simple 105 Process instances are self contained, not relying on any external 106 Observer. 108 Notifications 109 Notifications are defined as psuedo action-items in that they are 110 sent by process performers in response to a call from application. 112 Observer 113 Process Observer monitors the Process Instances. The Process 114 Instance knows very little about who or what invoked it. However, 115 Process Instance communicate is state to the Process Observer. 117 Work Item 118 A Work Item is a special kind of process instance that instead of 119 performing something, simply represents that activity being per- 120 formed by a person. The work items hold the references to the 121 activities for the people. 123 Workflow Management 124 Workflow management is the automated coordination, control and com- 125 munication of work as is required to satisfy workflow processes. 126 Workflow Management is process focused - coordinating activities of 127 people working in a common task or project. Workflow Management 128 makes sure that activities occur in proper sequence, and that users 129 are informed so they can complete tasks on time. 131 3. Simple Workflow Access Protocol 132 The objective of Simple Workflow Access Protocol(SWAP) is to define 133 the protocol to schedule, execute, control and monitor workflow 134 tasks as defined by work flow specification. The SWAP interprets the 135 workflow specifications and controls the instantiation of processes 136 and sequencing of activities, adding work items to the users "todo" 137 lists. SWAP also provides data formats to exchange workflow specifi- 138 cations across different workflow systems. SWAP will not define 139 methods to define workflow specifications. 141 3.1. Data Format Requirements 142 This protocol MUST define data formats for interchanging process 143 descriptions, and process coordination rules defined as workflow 144 specifications. 146 3.2. Specification of Process Instances 147 The idea of workflow can be traced to Job Control Language of batch 148 operating systems which allowed user to specify a job as a collec- 149 tion of steps. Each step was an invocation of a program and the 150 steps are executed in sequence. Some steps could be executed condi- 151 tionally. 153 From the view point of a workflow, all details of the Process 154 Instance that describe its sequential processing are unnecessary. 155 SWAP protocol SHALL deal with those aspects that are externally 156 visible like (1) a set of externally visible execution states of the 157 process instance, (2). a set of valid transitions between these 158 states, and (3). the conditions that enable these transitions. 160 Transitions between various states of a Process Instance may be 161 affected by various scheduling events. Some of these transitions are 162 controlled by the SWAP responsible for inter Process Instance depen- 163 dencies. For example, 164 Process Instance can be submitted for execution thus resulting in a 165 state transition from "Initial" to "Running". It SHOULD be possible 166 to query on various states of the Process Instance and SHOULD be 167 able to suspend and resume Process Instances by the requestor. 169 SWAP MAY NOT provide any facilities for defining or modifying the 170 process definitions or rules associated with these process 171 instances. 173 3.3. Communication between Process Instances 174 An output or partial output of a Process Instance may be made avail- 175 able to other process instance. SWAP SHOULD be able to provide 176 methods to query and retrieve Process Instance generated data, state 177 variables and error messages. 179 3.4. Process Instance Co-ordination Requirements 180 Once the process instances constituting a workflow are defined, the 181 control flow of the workflow is driven by the process instance co- 182 ordination. How each process instance is started or stopped. It 183 SHOULD be possible for the SWAP protocol to determine the process 184 instance state or control the process instances. 186 3.5. Failure Atomicity Requirements 187 Workflow consists of process instances and process co-ordination 188 rules. Failure atomicity requires that failure of any process 189 instance would result in a failure of a workflow. SWAP MUST provide 190 methods to guarantee the failure atomicity. 192 3.6. Execution Automicity Requirements 193 In a distributed environment, Process instances may use data span 194 across multiple systems. To ensure the integrity of the data would 195 require that a whole workflow constitute an execution atomic unit. 196 Therefore, an interleaved execution of workflows should have the 197 same effects as of they were executed serially. For example, con- 198 sider a workflow that transfer money between two accounts in two 199 different banks. To avoid inconsistent access of the databases of 200 those banks, all processes that operate on those data should consti- 201 tute an execution-atomic unit with respect to other concurrent tran- 202 sactions. SWAP MUST provide methods to guarantee the execution 203 automicity. 205 3.7. Dynamic Monitoring and Control of Process Instances 206 SWAP SHOULD provide the ability to suspend, resume, cancel or ter- 207 minate any executing process instances. It SHOULD also provide 208 methods to monitor long running activities and access intermediate 209 data of these process instances. 211 3.8. Event Notification 212 SWAP SHOULD be able to accept requests for monitoring and notifying 213 specific states of the process instance. For example, user can 214 register with SWAP to notify an Observer when the process instance 215 is completed or when the process instance state matches with the 216 registered state. 218 3.9. System Behavior 219 SWAP MAY provide methods to query on run-time information of the 220 process instances to understand the system or process instance 221 behavior. 223 3.10. Coordination of Process Instances 224 In order to continue the co-operation process, awareness information 225 about completed actions is required. It must be required to record 226 awareness information about actions and process instance state tran- 227 sitions along with the process generated data. In a time deferred 228 processes, the partners SHOULD be relieved from being continuously 229 present and watch the process. Awareness information should be visi- 230 ble if relevant for the current action, it SHOULD be available after 231 a while of absence to inform about the intermediate progress, or on 232 request to give more details, or to inform about the history of 233 actions performs. Awareness information needs to persist as long as 234 it may be necessary in the process. Process specific aging of aware- 235 ness information MAY be required. 237 It SHOULD also provides methods to query or retrieve this informa- 238 tion or register for delivering this data to the Observer through 239 notifications. 241 3.11. Monitoring of Processes Instances 243 Since many processes are likely to be underway at any given time, 244 the system facilitates inquires into the status of certain processes 245 as they are being executed. The user may also want to know why a 246 particular process has not yet been completed, and will be able to 247 identify the task and its associated responsible user that are hold- 248 ing up the process. 250 After each process is completed, all information relating to that 251 process and all tasks that were carried out to complete that process 252 need to be recorded. These process histories MUST be queriable as 253 find out how many times a particular process has run, who initiated 254 this process, how long it took on average to complete. This histori- 255 cal reporting provides valuable feedback for process engineering. 257 3.12. Exception Handling and Recovery 258 A workflow represents a very complex computational activity which 259 consists of many tasks whose execution needs to be coordinated. 260 Therefore, SWAP should provide comprehensive error handling and 261 recovery procedures. 263 SWAP should be able to reach an acceptable termination state even in 264 the case of a failure. For example, the SWAP could continue process- 265 ing after a failure and recovery as if nothing happend, thus provid- 266 ing a forward recoverability. 268 3.13. Transactional support 269 Workflow systems require the participation of multiple application 270 systems and databases. It is desirable that workflow systems main- 271 tain at least some of the safeguards of traditional transactions 272 related to the correctness of computations and data integrity. In a 273 multi-system workflow main problem is the need to preserve the 274 autonomy of participating systems. Since many systems used in 275 multi-system workflows were designed for standalone operation, they 276 normally do not provide the information and services that would be 277 necessary to execute the distributed transactions while supporting 278 the required transaction semantics. Providing transactional support 279 for distributed process instances is not within the scope of the 280 SWAP. 282 3.14. Scalability and Availability 283 Some of the goals of the workflow systems are to achieve better per- 284 formance of business processes, better quality, enhanced 285 effectiveness, enterprise- wide coordination and monitoring. Given 286 its goals, workflow systems must be able to deal with local and com- 287 munication failures, and the system must be continuously available 288 as its relevance in the control of the business processes. 290 High availability is a key requirement of workflow systems and 291 failures should be transparent to the users and should have minimal 292 impact on the normal functioning of the organization. 294 It is also necessary to deal with other issues which are dominant in 295 the current workflow systems, such as dynamic configuration, addi- 296 tion of new services without reconfiguring the whole system, message 297 replication and recovery facilities. These requirements are not 298 critical, but good to address as lot of relevant work is underway in 299 IETF(e.g. wide area service location protocol, LDAP replication 300 mechanisms are best examples to consider in this protocol). 302 4. Security Considerations 303 Since workflow interoperability may involve the exchange of sensi- 304 tive information, any workflow interoperability mechanism must pro- 305 vide for encryption and authentication. Several techniques such as 306 SSL and HTTP Access Authorization are available for use in Internet 307 protocols. Without such techniques, SWAP clients and servers are 308 wide open to forged or snooped workflow proposals or authorizations. 310 5. Open Issues 311 (1). Correctness of Process Scheduling: The SWAP cannot violate any 312 of the dependencies provided in the specification while instantiat- 313 ing process instances. SHOULD SWAP be aware of how it can interpret 314 these inter-process dependencies and state-transition criteria for 315 workflows? 317 (2). SHOULD SWAP need to guarantee the correctness of schedules -- 318 validating pre and post execution requirements defined as task co- 319 ordination requirements in the workflow definitions? 321 (3). SHOULD SWAP include Event - Condition - Action Rules for defin- 322 ing inter-process dependencies? 324 6. References 325 [Bradner, 1997] S. Bradner, "Key words for use in RFCs to Indicate 326 Requirement Levels." RFC 2119, BCP 14. Harvard University. March, 327 1997. 329 [Fielding et al., 1997] R. Fielding, J. Gettys, J. Mogul, H. 330 Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." 331 RFC 2068. U.C. Irvine, DEC, MIT/LCS. January, 1997. 333 [Bradner, 1996] S. Bradner, "The Internet Standards Process - 334 Revision 3." RFC 2026, BCP 9. Harvard University. October, 1996. 336 [S.Reddy,1998] Surendra Reddy, "Requirements for Event Notification 337 Protocol", 338 ftp://ftp.ietf.org/internet-drafts/draft-ietf-webdav-enpreq-00.txt, 339 April, 1998. 341 7. Author's Address 342 Surendra Reddy 343 Oracle Corporation 344 500 Oracle Parkway 345 M/S 4op12 346 Redwoodshores, CA 94065 348 Phone: +1(650) 506 5441 349 Email: skreddy@us.oracle.com 351 Expires February 6, 1999