Hi Alex,
1. I had to read through the WS-C specification to understand what exactly the BPEL4People needed from the WS-C. So, I agree that explaining minimum workings of WS-C (that are relevant to BPEL4People) here would be helpful.
2. I presume that the requestMessage (1) for Task creation, the final responseMessage (4a) and messages for the WS-C must be standardized, or we won't have interoperability. Except that some input/output message parameters must be Task-dependent and that may be determined by the Task service's WSDL? Did you mean this?
As Dieter explained, the WS-C messages are mentioned in the WS-HumanTask 1.0. Although requestMessage (1) and responseMessage (4a) were also explained, their exact formats are not shown, as you pointed out.
Also, I think that it may have to include "Start", "Stop" and "InProgress:Suspend" to communicate with WS-C. I think that the latter two may be necessary, since they occur after the Task (Task Application) has been started. They are different from Skip or Exit. The "Start" may have to be communicated with WS-C to Task Service, because the Coor Register request (2) in Figure 1 does not include anything to do with how to instantiate the Task Application instance itself.
I presume that the specification expects some kind of Process engine that creates a Task when it encounters it in the running Process. Although BPEL4People can leave it out such a detail, I imagine that it sends the Task to some sort of "Task Manager" to handle it. This handles the Task List, Task List Client and so on. Also, I presume that the Task Manager acts as WS-C's Task Coordinator and deals with a Task Parent and a Task Application as a service (which consists of the Task Service and the Task Application implementation).
From the BPEL4People 1.0, I presume that the Task sent from the Process engine to the Task Manager on BPMS starts the Task life-cycle. This is the "Create Task" event for the Task Engine on BPMS, which sends the requestMessage to the Task Service. At that stage it may be necessary for the Task Manager to reach the Task Service to pass on Task instance information (overriding information for this instance, etc.) and to get some information about the Task back from the Service.
The Figure 1 in Section 7 states that the requestMessage consists of:
a. HT coordination context (defined in 7.4.1. The SOAP Binding is defined in 7.4.2)
b. Overriding Task attributes (defined with WS-HT. It seems no SOAP-binding has been defined for Task Service)
c. Attachments (3.4.3.1, but no SOAP-binding. Using a standard SOAP format defined in WSDL 2.0?)
d. Call back EPR of the WS-C handler of the Task Parent (defined in 7.3.1. SOAP-binding is defined in WS-C)
What is missing from this explanation in WS-HumanTask is the mention of the input and output data (SOAP details are missing from Task Operational Data 3.4.3 and 3.4.4). They are presumably inherited from the definitions in the encasing People Activity but not mentioned with the Task that must relay these information to the Task service. Presumably they are defined with the services WSDL and reflected in the People Activity and the Human Task definition at the Process at design time (maybe by means of WSDL the Process Design tool will reveal them). They, however, must revert to the WSDL defined form when they are sent to or received from the Service. Did you mean, "service dependent" in this sense?
Also, some of the the Task context 7.4.1 is meaningful for the Task Manager on the BPMS but not to the Task service. For example, the Task cares only who is doing it, but not who else may have claimed it. The Figure 1 does not elaborate on this and probably we need to define a subset of it for this interaction, or need to mention that any superfluous information will be ignored.
WS-C details how to distinguish instances by including unique instance IDs in the WS-C response message and the exact form of EPR for the WS-C Protocol Service of the Task Service (called Coor task protocol handler in Figure 1 but WS-C calls it as Protocol Service) for later communication between the Coordinator and the Web Service. However, the requestMessage may have to include a unique instance ID (or correlation IDs) for identifying unique instance for its own purposes and that may have to be returned back with Coor Register message (2). Alternatively, WS-C may handle all these instance IDs but BPEL4People does not take this option. Each Task instance issues requestMessage with unique ID if it needs to identify the instance. Additionally, I can see the need for a Correlation ID in my own Use Cases, but BPEL4People People Activity does not have this provision.
The WS-C "messages" defined with BPEL4People has the Task life-cycle messages but Figure 1 is lacking the WS-C messages between (3) and (4a). We probably need to renumber these and insert WS-C messages (4) and responses (5), responseMessage (6a) and Skipped (or Failed etc.) as (6b).
Overall, the BPEL4People details on Task life-cycle but it lacks an easy description (high level view) of a section as to the life-cycle of a Task Service with a Task Application implementation and the Task Application instance management before it directly dives into Section 7 to describe much more technical details??? They are intimately related but different.
3. I think that Dieter is right but it would help to insert a reference for that.
4. You are probably right. Consistency may be good.
5. As I said in 3, I think that the Figure 1 should be improved.
It seems Dieter is expert in this section and I hope that he would correct me if these are incorrect.
Regards,
Yoichi
--------------------------------------------------------------------------
Yoichi Takayama, PhD
Senior Research Fellow
RAMP Project
MELCOE (Macquarie E-Learning Centre of Excellence)
MACQUARIE UNIVERSITY
Phone: +61 (0)2 9850 9073
Fax: +61 (0)2 9850 6527
--------------------------------------------------------------------------
MACQUARIE UNIVERSITY: CRICOS Provider No 00002J
This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of Macquarie E-Learning Centre Of Excellence (MELCOE) or Macquarie University.
On 27/11/2008, at 11:52 AM, Alex Malek wrote:
At the last F2F, I mentioned that I found section 7 of the WS-HT spec hard to understand. I spent a bit of time since then trying to crystallize that feeling into actual constructive feedback. I came up with five high-level comments for sections 7 and 8:
- It seems hard to understand section 7 without a deep understanding of WS-Coordination. Do we assume that readers of the spec have to fully understand WS-Coordination before reading WS-HT?
- Where is the spec for the requestMessage and responseMessage of the coordination prototcol? Are the details supposed to be vendor specific?
- At the top of section seven, it mentions “A simplified protocol applies to notifications”, but I don’t see where that is fleshed out.
- Sections 7 and 8 don’t use the conformance targets, which makes them hard to read, e.g. using the term “Caller” instead of “Task Parent”
- I like the diagram at the top of the section that outlines the messaging lifecycle. It would be nice if the text in that section walked through the same lifecycle.
Thanks,
Alex Malek
Microsoft Corp.