OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bpel4people message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [bpel4people] BP-20 Revised Proposal



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: dieterkoenig@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

2008-11-21 - BP-20 - Extensibility.ppt

Task State Transitions.xls

State Diagram HT.vsd



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]