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: 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]