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