|Luc Clément||Jan 20, 2009 7:48 am|
|Subject:||[bpel4people] [BP-67] Clarify the words, Requesting Application, Task Parent, the Application Logic and the Task in Section 7.|
|From:||Luc Clément (luc....@activevos.com)|
|Date:||Jan 20, 2009 7:48:13 am|
[BP-67] Clarify the words, Requesting Application, Task Parent, the Application
Logic and the Task in Section 7.<http://www.osoa.org/jira/browse/BP-67> Created: 20/Jan/09 Updated: 20/Jan/09
Raised By: Yoichi Takayama
Target: V 1.1, CD02, Jan 6 2009
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
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.
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
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.