| From | Sent On | Attachments |
|---|---|---|
| Dieter Koenig1 | Nov 24, 2008 4:26 am | .ppt, .xls, .vsd |
| Subject: | [bpel4people] BP-20 Revised Proposal | |
|---|---|---|
| From: | Dieter Koenig1 (diet...@de.ibm.com) | |
| Date: | Nov 24, 2008 4:26:09 am | |
| List: | org.oasis-open.lists.bpel4people | |
| Attachments: | ![]() 2008-11-21 - BP-20 - Extensibility.ppt - 582k - 8 pages ![]() Task State Transitions.xls - 54k - 15 pages ![]() State Diagram HT.vsd - 262k | |
Revised proposal for issue BP-20 (Extensibility of Task Status).
The original proposal mandated that the task must be in a pre-defined state in order to allow an API operation to be performed. This is now relaxed in the proposed change for section 6.1.1, which only specifies the behavior for the standardized task states.
For an overview, please see the attached document "2008-11-21 - BP-20 - Extensibility.ppt".
Changes in WS-HT types XML Schema ("ws-humantask-types.xsd") ============================================================
Replace simple type definition of task status (lines 157-170): <xsd:simpleType name="tStatus"> <xsd:restriction base="xsd:string"/> </xsd:simpleType>
Add documentation of predefined task status values (definition only, not referenced anywhere): <xsd:simpleType name="tPredefinedStatus"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="CREATED" /> <xsd:enumeration value="READY" /> <xsd:enumeration value="RESERVED" /> <xsd:enumeration value="IN_PROGRESS" /> <xsd:enumeration value="SUSPENDED" /> <xsd:enumeration value="COMPLETED" /> <xsd:enumeration value="FAILED" /> <xsd:enumeration value="ERROR" /> <xsd:enumeration value="EXITED" /> <xsd:enumeration value="OBSOLETE" /> </xsd:restriction> </xsd:simpleType>
Changes in WS-HT Specification ==============================
Section 6.1.1 ? participant operations - add definition of all pre and post states (lines 1793):
See attached document "Task State Transitions.xls".
Add normative language about task pre and post states (lines 1794): - If the task is in a predefined state listed as valid pre-state before the operation is invoked then, upon successful completion, the task MUST be in the post state defined for the operation. - If the task is in a predefined state that is not listed as valid pre-state before the operation is invoked then the operation MUST be rejected and MUST NOT cause a task state transition.
Section 4.7 ? update state diagram (line 1581) - fix some state transitions: - Change "activate" (Created -> Ready/Reserved) to "activation" - Change "revoke" (Reserved/InProgress -> Ready) to "release"
See attached document "State Diagram HT.vsd".
Kind Regards
Dieter König
Senior Technical Staff Member, WebSphere Process Server Architect IBM Software Group, Application and Integration Middleware Software WSS Business Process Solutions
Phone: +49-7031-16-3426 IBM Deutschland
E-Mail: diet...@de.ibm.com Schönaicher Str. 220
71032 Böblingen
Germany
IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Erich Baier Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php






.ppt, .xls, .vsd