Scope of Work
The TC will accept as input Version 1.0 of the BPEL4People specification, and Version 1.0 of the WS-HumanTask specification as published by Adobe, Active Endpoints, BEA, IBM, Oracle and SAP AG (see section References).
Other contributions and changes to the input documents will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit in so far as they conform to this charter. OASIS members with extensive experience and knowledge in related areas are particularly invited to participate.
This work will focus on:
-
Defining the specification of a WS-BPEL extension enabling the definition of human interactions ("human tasks") as part of a WS-BPEL process.
-
Defining the specification of a model enabling the definition of human tasks that are exposed as Web services.
-
Defining a programming interface enabling human task client applications to work with human tasks.
WS-BPEL Extension (BPEL4People Specification)
The WS-BPEL Extension Specification will define the following:
-
Concept of people activity
-
Composition model for human tasks and processes supporting at least the following:
-
Inline human tasks in one people activity of a WS-BPEL process, without re-use
-
Inline human tasks in a WS-BPEL process for re-use in multiple people activities
-
Standalone human tasks for re-use in multiple WS-BPEL processes. The life-cycle of processes and human tasks is tightly coupled using the coordination protocol implemented in a vendor specific manner
-
Standalone human tasks for re-use in multiple WS-BPEL processes. The life-cycle of processes and human tasks is tightly coupled using the coordination protocol and protocol service standardized by WS-HumanTask
-
Standalone human tasks, without using a particular coordination protocol, callable using plain Web services means, for re-use between WS-BPEL processes (invokes) and other Web services clients
-
Concept of inline human tasks within a people activity and within a WS-BPEL process. Inline human tasks within a WS-BPEL process can be reused by different people activities within that process
-
Allow people activity to reference a standalone human task (introduced in WS-HumanTask)
-
Concept of people activity context and mechanism to access the context from the people activity definition and from elsewhere in the enclosing scope
-
Semantics of people activity states and lifecycle
-
States and basic operations for people activities aligned with the corresponding states and operations of standalone human tasks
-
Concept of generic human roles for processes
-
Definition of process specific people assignments
-
Mechanism to use logical people groups in WS-BPEL assignments
-
Support for time-based conditions on people activities, e.g. deferred activation of a human task
-
Support of specific interaction patterns
-
Four-eyes principle (a.k.a. separation of duties)
-
Enablement of human tasks to access context information from the surrounding process including previous people activities and the corresponding human tasks.
-
Extension mechanism
-
Ad-hoc Attachments
Human Task Enablement (WS-HumanTask Specification)
The WS-Human Task Specification will define the following:
-
Concept of human tasks (i.e. tasks and notifications) as an explicit entity independent from any process definition
-
Concept of human task context and mechanism to access the context from the task definition
-
Concept of generic human roles for human tasks
-
Concept of logical people groups as an abstraction for assigned people used to hide access to organizational directories
-
Definition of people assignments
-
Data types representing individuals associated with human tasks
-
Semantics of task states and task lifecycle
-
Basic operations (API) for client application interactions with human tasks
-
Coordination protocol for processes (or other applications) interacting with human tasks
-
Handling of deadlines including escalation
-
Support of specific interaction patterns
-
Nomination
-
Delegation
-
Escalation
-
Extension mechanism
Potential additional features
In addition to the specification features described above, the TC may explore the inclusion of the following features and topics, providing that the technical approach chosen does not contradict the scope described above:
-
Single user screen flow (chained execution)
-
Workflow patterns commonly encountered in document-centric and people-centric workflows including:
-
Sequential approval through a management chain
-
Parallel approval and voting
-
Approval management, group vote
-
Pushback
-
RequestInfo
-
Basic operations (API) for client application interactions with WS-BPEL processes (e.g. adding or deleting attachments)
Out of Scope
The following is a non-exhaustive list. It is provided only for the sake of clarity. If some function, mechanism or feature is not mentioned here, and is not mentioned in the Scope of Work section either, then it will be deemed to be out of scope.
The following items are specifically out of scope of the work of the TC:
-
Authorization definitions
-
Deployment
-
Monitoring
-
Organizational directories (e.g., Human Resources)
-
Definition of such directories
-
Specific mechanisms (including protocols) to query such directories
-
Task execution rendering and definition of user interface elements
Deliverables
The TC has the following set of deliverables:
-
A revised BPEL4People specification and associated schema. A Committee Specification is targeted for completion within 18 months of the first TC meeting.
-
A revised WS-HumanTask specification with associated schema. A Committee Specification is targeted for completion within 18 months of the first TC meeting.
These specifications will reflect refinements, corrections or material technological improvements with respect to the input documents and in accordance with this charter.
Maintenance
Once the TC has completed work on a deliverable and it has become an OASIS Standard, the TC will enter "maintenance mode" for the deliverable.
The purpose of maintenance mode is to provide minor revisions to previously adopted deliverables to clarify ambiguities, inconsistencies and obvious errors. Maintenance mode is not intended to enhance a deliverable or to extend its functionality.
The TC will collect issues raised against the deliverables and periodically process those issues. Issues that request or require new or enhanced functionality shall be marked as enhancement requests and set aside. Issues that result in the clarification or correction of the deliverables shall be processed. The TC shall maintain a list of these adopted clarifications and shall periodically create a new minor revision of the deliverables including these updates. Periodically, but at least once a year, the TC shall produce and vote upon a new minor revision of the deliverables.
