[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [bpel4people] Action Item 10 - comments on WS-HT section 7/8
Hey, sorry for the delay in responding – I’ll follow up with some comments on the smaller issues below. The main topic I think would be worth discussing today is Dieter’s comment below that “coordination protocol messages exchanged between Task Parent and Coordinator <alex: task processor?> **should not** be standardized in order to allow local optimizations by a single runtime component that implements both the Task Parent and the Coordinator". If this is the design of WS-HT, I have a hard time understanding how one could support interop in constellation 4, i.e. where the processor and parent are from different vendors. Thanks, alex -----Original Message----- From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] Sent: Tuesday, December 02, 2008 2:21 AM To: Yoichi Takayama; Alex Malek Cc: bpel4people@lists.oasis-open.org; James Dalziel Subject: Re: [bpel4people] Action Item 10 - comments on WS-HT section 7/8 Yoichi, Alex, before we get too deep into the details, let me add a few more design points that have lead to the current description in chapter 7 of the WS-HT specification: - WS-HT application messages (requestMessage and reponseMessage), WS-HT-specific coordination protocol messages (Skipped, Fault, and Exit), and general WS-C messages (activation, registration, coordination faults) are handled separately -- the **normative reference to WS-C** avoids the need for repeating general coordination concepts here (this is a formal point -- we would not repeat definitions from e.g. WSDL or XML Schema either) - WS-HT coordination protocol messages Skipped, Fault, and Exit must be standardized for achieving **interoperability** between Task Parent and Task runtime components -- coordination protocol messages exchanged between Task Parent and Coordinator **should not** be standardized in order to allow local optimizations by a single runtime component that implements both the Task Parent and the Coordinator - Only the subset of all possible WS-HT human task state transitions that are **relevant** to a Task Parent (typically those leading to final states) have been made visible by means of coordination protocol -- as a result, there are no e.g. "Start", "Stop", etc. coordination protocol messages -- as an example, BPEL4People has a simplified state transition diagram (that of the peopleActivity) driven by this subset -- however, this might of course be subject of a new issue and a corresponding resolution proposal extending the protocol ... Hope this helps! 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 (Embedded image moved to file: pic09804.gif) 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 From: Yoichi Takayama <yoichi@melcoe.mq.edu.au> To: Yoichi Takayama <yoichi@melcoe.mq.edu.au> Cc: Alex Malek <alexma@exchange.microsoft.com>, bpel4people@lists.oasis-open.org, Dieter Koenig1/Germany/IBM@IBMDE, James Dalziel <james@melcoe.mq.edu.au> Date: 01.12.2008 02:08 Subject: Re: [bpel4people] Action Item 10 - comments on WS-HT section 7/8 Correction. d. Call back EPR of the Task Parent (to return the asynchronous results). I have not investigated the responseMessage (4a) in detail. Thanks, 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 www.mq.edu.au www.melcoe.mq.edu.au/projects/RAMP/ -------------------------------------------------------------------------- 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 01/12/2008, at 11:45 AM, Yoichi Takayama wrote: 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 www.mq.edu.au www.melcoe.mq.edu.au/projects/RAMP/ -------------------------------------------------------------------------- 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: 1. 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? 2. Where is the spec for the requestMessage and responseMessage of the coordination prototcol? Are the details supposed to be vendor specific? 3. At the top of section seven, it mentions “A simplified protocol applies to notifications”, but I don’t see where that is fleshed out. 4. 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” 5. 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]