|
Raised By: Yoichi
Takayama
Target: V 1.1, CD02, Jan 6 2009
http://www.oasis-open.org/apps/org/workgroup/bpel4people/document.php?
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.
|