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-comment] HumanTask Comittee draft 1.1

This comment was recently sent to bpel4people-comment@lists.oasis-open.org and I've been informed by OASIS staff that TC Chairs are auto-subscribed to the comment distribution lists (anybody else on our TC subscribed?)

Either way, here's a comment for the TCs consideration. I'll allocate some discussion time on the 9/3 agenda.

Regards, Dave Ings,
Emerging Software Standards
Email: ings@ca.ibm.com
Yahoo Messenger: dave_ings
----- Forwarded by Dave Ings/Toronto/IBM on 2008/08/20 03:54 PM -----


Yoichi Takayama <yoichi@melcoe.mq.edu.au>




James Dalziel <james@melcoe.mq.edu.au>


2008/08/11 03:28 AM


[bpel4people-comment] HumanTask Comittee draft 1.1


The WS-HumanTask specification 1.0 and 1.1 (draft) both are not clear  
on how the Task Application (a local or remote Service) can pass  the  
Task human interface back to the Task Parent Application (Process  
host) via the service interface connection they both establish.

Different from the human free BPEL Process, which sends and receives  
data, the Human Task service must pass back the Task human interface  
for human to complete the Task on the system which is hosting the  
Process. (This is not the case for a remote service which is executed  
on the service side by humans).

Judging from the document, this must occur between the Steps 3 and 4a  
(or 4b) of the Figure 1 in Section 7.

It simply says:

1975 Now the instance of the human task is activated, so the assigned  
person can perform the task
1976 (e.g. the risk assessment). Once the human task was successfully  
completed, a response
1977 message is passed back to the parent application (step (4a) in  
Figure 1).

I think that this description is too simple. You may need to expand  
more to include precise mechanism used in that part.

In other parts of the document, it says that the human interface of a  
Task could be e.g. Web Application, Flex client, .Net client (Windows  
remote application), Forms client, Portlet client, Email clients.  
Although in one part it says that it assumes a simple one-page form in  
most cases, handling all these types of UIs is not that simple.

When the information about the human interfaces (e.g. UI definition in  
XML form, URL of an Web Application, or RPC call definition, etc.) is  
passed back to the Task Parent Application (Task Engine, I presume), I  
presume that you expect it to come inside some standardized SOAP  
message, which indicates to the Task Parent application what is  
returned and how the Task instance should be "activated" (cf. line  

Then, the Task Engine may be able to handle it properly and pass it  
onto an appropriate Task Client. A Task client may simply render UI or  
it may have to connect with its own protocol to the service as a  
server, such as Flex Communication Protocol via the Web Service  
interface (i.e. HTTP/SOAP tunneled) or on some other port without  
HTTP /SOAP tunneling.

Or, is such a thing a part of the WS-Coordination standard (which is  
not explained explicitly in the document) and am I missing something  


Yoichi Takayama, PhD
Senior Research Fellow
RAMP Project
MELCOE (Macquarie E-Learning Centre of Excellence)

Phone: +61 (0)2 9850 9073
Fax: +61 (0)2 9850 6527

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.

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