[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: BP-64: A need for a "GetUI" or "StartTask" request/message fora Task
|
Yoichi / TC Members: The following issues have been created. Separate emails will
follow to create separate thread of discussions for each. ·
BP-65: Add a clear proposed system component architecture
dictated by the BPEL4People and WS-HumanTask ·
BP-66: Delete or modify the mention/usage of the TaskProcessor
in Section 7 and Appendix A of WS-HumanTask ·
BP-67: Clarify the words, Requesting Application, Task Parent,
the Application Logic and the Task in Section 7. ·
BP-68: htd:remoteTask - a possible error? Luc Clément Active Endpoints, Inc +1.978.793.2162 | luc.clement@activevos.com From: Yoichi Takayama
[mailto:yoichi@melcoe.mq.edu.au] Thanks, Luc. After reading through CD02, it seems that there is a
confusion about what the standard tries to achieve. In my previous reading of the BPEL 1.1 initial documents (v
1.0, 2007 June and V 1.1), I thought that the standard gave
the guidelines for what the Task Life Cycle management should be like
and to support such operations what operational commands there should be,
separate from what and how the Task are implemented as Web Services and
communicated with the Task Life Cycle management structure - i.e. Task Manager. In the CD02, the Task Manager is expressed as Task Parent
and Task Processor (newly introduced). In fact, the previous document submitted to OASIS was
clearer on this point. It needed Task List manager and Task List application
(and its client) and Task Application (and its client) in addition to the Task
implementation, which may be in-line, local or remote. All these Tasks were supposed to be able to have either WSDL
(standard Web Service interface) only interface or composite interface as WSDL
+ WS-C, as Appendix A. Portability and Interoperability Considerations, in the
WS-HumanTask v 1.1 (original document). That talked about the WS-HT protocol, a definition of a
protocol that operates over the WS-C architecture. The messages in that WS-HT protocol were defined in Section
7.1 of the WS-HumanTask document (original v 1.1) and it had noting to do with
the TaskProcessor (that is introduced on CD02) on the Task
implementation side. The WS-HT messages do not do any life cycle management.
These messages are separate from the messages that the Task Life Cycle
management API that is defined in Section 6. Reading the most workings of the proposed TaskProcessor in
Section 6, it rather belongs to the "Application" side on the figure
on the Appendix A. Therefore, as though the TaskProcessor on the Task
implementation receives the WS-HT messages is incorrect in CD02. The TaskProcessor may receive those Task Life Cycle
management API messages from the "application" but in the original
document there was nothing to indicate that they may be received via the WS-C
channel or need for it whatsoever. Accordingly, I am raising the flowing issues. -------------------------------------------------------------------------------------------------------------------------------------- Title: Add a clear proposed system component architecture
dictated by the BPEL4Peoppe and WS-HumanTask Raised By: Yoichi Takayama Target: V 1.1, CD02, Jan 6 2009 document_id=30552 Description: The Task life cycle management API and the Task Web Service
interface must be clearly distinguished as V 1.0. In CD02, however,
there seems to be a confusion about the demarcation and the role of
each element. Proposal: Add a prospective system component architecture dictated by
this standard and attach the relevant interface used to each part. -------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------- Title: Delete or modify the mention/usage of the
TaskProcessor in Section 7 and Appendix A of WS-HumanTask Raised By: Yoichi Takayama Target: V 1.1, CD02, Jan 6 2009 document_id=30552 Description: The TaskProcessor does not receive the messages over WS-C.
The mention and the usage of TaskProcessor in conjunction with Task
implemented as Web Service are completely wrong. Proposal: Move the TaskProcessor to the Application side of the
diagram. The TaskProcessor must communicate with the WS-HT
Protocol Service on the Web Service that implemented the Task. Also,
the (WS-C) WS-HT Protocol Service is the proper term used in WS-C,
that handles the Register events to exchange the EPRs for the WS-C interface. -------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------- Title: Clarify the words, Requesting Application, Task
Parent, the Application Logic and the Task in Section 7. Raised By: Yoichi Takayama Target: V 1.1, CD02, Jan 6 2009 document_id=30552 Description: The "Task" talked about in this section seems to
indicate that it is a Task Implementation, i.e. a Task application or a Web
Service that implements it, not a Task representation on the
BPEL4People application. The latter is subject to the life cycle
management and e.g. involved on who claims it etc., but the former, the
Task application as a Web Service implementation, does
not need to know anything but who uses the Web Service to run a
Task application. The former is associated with the Task List Client, and the
latter, with Task Client. Assuming that the Coordinator indicated in Figure 1 is the
WS-C Coordinator, the meaning of the Requesting Application, Task Parent,
the Application Logic and the Task must be all clarified. Proposal: Task is the Web Service that may be invoked as a Human Task
implementation. This is defined in <htd:task> or <b4p:remoteTask>.
When the TaskProcessor requires the Task application instance, it
invokes it to create the Task application instance. When the TaskProcessor
needs to pass the UI of the Task application to a corresponding Task
Client, it uses WS-C to send a "StartTask" message. Coordinator: This is a WS-C Coordinator that sits between
the Task Parent and the Task. The Task is implemented as WS-C-enabled Web
Service. The Coordinator is the registration service of WS-C Protocol Service
EPRs of two parties which wish to communicate during a single Web Service
invocation (i.e. a session). Each Task instance creates a separate EPR exchange
with a unique instance ID. Requesting Application: In this case, it is a Task Life
Cycle management application. In case of CD02, this seems to be designated
as Task Processor. However, from Task point of view, this is a combination of
BPEL engine and Task List application (the Task Processor does all
the leg work for the Task List application). Task Parent: This word is ambiguous. Each Task instance
(application implementation on the Service side) may have a
corresponding Task Client to work with on the BPEL4System. This may be called a
Task Parent. It is a separate concept from the Requesting Application. Maybe
Task Parent should be included inside the Application Logic (or behind it).
Probably Task List Application is more appropriate, although I prefer Task
Engine or Task Manager. Application Logic: In this case, the Application logic is
the hard-wired logic of the Task Processor, dictating what WS-C messages are to
be sent to the Task. In a larger picture, however, this is all the hard/soft
logics of Process, Process engine, Task List application and the Task
Processor. In a narrow sense, however, Application Logic regarding
the communication can be actually dissected to 3 parts. Web
Service communication, WS-C communication and Task application communication.
In this diagram, the Application Logic is the combination of all these and may
be the diagram should be refined with different components involved. For
example, the Coordinator does not really handle the messages (1) and (4a or
4b). What is left out of Figure 1 is another application
layer. That is, the Task Client, that receives the
Task application from the Web Service and runs it for the end user,
if it is a, inline or a local Task. For a remoteTask, there is no human interface needed and no
Task Client gets involved. All human users are expected on the other side of
the Service. This is a black box in terms of the human operation. For a
remoteTask, the WS-C still must operate to deal with
the asynchronous nature of the human task request. -------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------- Title: htd:remoteTask - a possible error? Raised By: Yoichi Takayama Target: WS-HumanTask, V 1.1, CD02, Jan 6 2009 document_id=30552 Description: Line 2397 states htd:remoteTask/@responseOperation
attribute. As far as I know, the remoteTask is a b4p element. Is this an error? Proposal: Change htd to b4p. -------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------- 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]