Re: [bpel4people] Groups - New Action Item #0018 This is the sketch of the HT Arc...

[Yoichi Takayama <takayama.yoichi@gmail.com>]

Dear Frank,

This is a good document that explains very well as to the architecture  
and where the interfaces fit.

I thank you for this valuable document and it should be very helpful  
when it is included in the current specification as non-normative  
information, as it has been decided by the TC earlier.

This is NOT different from what I thought what architecture the  
members of the TC were thinking about.

This proves my point that the Task Client mentioned in the document  
was called as Task List Client in BPEL4People White Paper (and I think  
that it was so defined in BPEL4People 1.0 and HumanTask 1.0). The  
specifications mention that the Task Client functionality may be a  
part of the ability of the Task List Client or it may choose to use  
some separate modules (it is out of scope). Nevertheless, there was a  
distinction between so-called Task List Client and the so-called Task  
Client. Task List Client shows all available Tasks that the end user  
may potentially claim or preassigned and may do or skip etc. This is  
different from showing a given individual Task instance (Case) itself  
after the selection was done.

The second point is that, in the paragraph after Figure 6, the  
document states "WS-HumanTask does not specify such rendering but  
provides a container to pass rendering information to Task Clients".  
Although it is out of scope, I cannot see any such container or  
passing of the information defined or mentioned in the current  
specification. It is probably necessary to mention this clearly as a  
separate interface or entity, as I have been trying to point out of  
its importance.

The last is that the document concludes that "... Again, the use of  
such business applications is out of scope of WS-HumanTask but such  
applications and their use are important ingredients of the overall  
architecture shown in Figure 7.".

This was exactly my point. This should be the heart of the  
specification, and without it we would never have interoperable Tasks  
provided by different vendors working with different WKMS and  
different Task Processors. If the Tasks provided by one vendor is  
always to work with a Task Processor provided by the same vendor only  
and if the proprietary interfaces existing between them are to handle  
the actual Tasks' human interfaces, this is not the case. However, I  
envisage that different Task "services" are implemented by many  
different players and they work interpretably with any Task  
Processors. Also my point was that mentioning the outline of how it  
can be done is a trivial matter without defining actual specifics  
(since you have deemed that this is out of scope unfortunately).

As I said that the problem was that these important information was  
totally lacking from the current specification, i.e. what are in, what  
are out and the whole picture.

Therefore, I strongly support the inclusion of this important document  
to the specification. I also hope that the TC should at least outline  
or mention (as out-of-scope) the lacking mechanisms in the main parts  
of the documents somewhere in a well-thought-of manner, since the  
whole architecture won't work unless these are all in places.

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 06/05/2009, at 3:53 PM, Frank.Leymann@informatik.uni-stuttgart.de  
wrote:

>
> OASIS WS-BPEL Extension for People (BPEL4People)  TC member,
>
> Dr Frank Leymann has created a new action item.
>
> Number: #0018
> Description: This is the sketch of the HT Arc...
> Owner: Dr Frank Leymann
> Due: 13 May 2009
>
> Comments:
> Dr Frank Leymann  2009-05-06 05:53 GMT
> This is in response of B4P issue 64
>
> View Details:
> http://www.oasis-open.org/apps/org/workgroup/bpel4people/members/action_item.php?action_item_id=2678
>
> Referenced Items
> Date            Name                             Type
> ----            ----                             ----
> 2009-04-15      cd-03.zip                        Reference Document
> 2009-05-06      Sketch of HT Architecture.docx   Reference Document
>
>
> PLEASE NOTE:  If the above links do not work for you, your email  
> application
> may be breaking the link into two pieces.  You may be able to copy  
> and paste
> the entire link address into the address field of your web browser.
>
> - OASIS Open Administration

smime.p7s