[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Clarification to my previous comments
Dear BPEL4People TC, This is to clarify what contents I think should be added. (1) Task Application life-cycle and how to get it. The standard draft at present contains an interface for a service for a Remote Human Task. It defines it as a dual interface, i.e. with a normal WS Service request/response (this cannot be asynchronous at this level since there is no responsePortType in your specification defined). However, since it must also manage the life-cycle of Task application implementation's UI, it should be quadruple interface. Task Application UI life-cycle interface and Task application UI interface are required. We want the latter to be opaque, i.e. the BPMS or the service should not be concerned. It only matters between the Task Application UI client and the Task Application implementation. If it is possible, the Task Parent or WS-C should not be involved once the connection is made between them. To demonstrate it, consider what happens after the "start" event occurs as indicated in the 6. Programming Interface. By this time, we expect that the WS-C EPRs have been exchanged for this Task and a Task instance (represents the People Activity's Task request, knows the Task Information and Task service EPR and Task life- cccle state) has been created on the BPMS side. The Task is in "Ready" or "Claimed" state. The event will presumably generate: (this is not specifically said) <xsd:element name="start" type="spe:ProtocolMsgType" /> <wsdl:message name="start"> <wsdl:part name="parameters" element="htdp:start" /> </wsdl:message> and send it over the WS-C EPR that is registered for the service's WS- C Protocol Service. What's then? The specification does not define the following actions. This presumably receives a response. What is the nature of the response? Is it enough to start the connection and processing between the user agent and the task service's Task Application interface? We can presume some default behavior and default response here (I am not going to incline to it or suggest one), but only if we can presume e.g. what is returned is only a simple Form based UI (i.e. a single page) and there is no complex interactions between the Task Client and the Task Application taking place. This also leaves the UI handling to BPMS, not the service itself handles it. BPMS must provide the UI codes. This would not suite for the examples listed such as Web Dynpro, Flex client and so on. It must first know that the protocol is HTTP/HTML and client can be on the User Agent (Web browser + Flash Player) and then to ask the BPMS to pass on the URL of the HTML page for the Web application (which has e.g. a Flex client on it) to the User Agent to download the Task Client application on to the user agent which is pointed to the Task Application on the service. This is 3 degrees of indirection until the Task Application can operate. What I think is that there has to be first an information passed back as to the UI details e.g Task UI protocol requirements that indicates what Task Client would be needed and what BPMS should do to establish the connection. Unless this is defined as a standard, there is no interoperability. (2) An Application serviced by a service interface (which is not just an XML UI) Web Services normally provide operations that can be used by whatever the using application side logics benefit from the operations. For this, normally the applications are built outside the services and those must know all details of the operations. An application served by a service interface on the other hand should provide only the entry point and end point and it should provide all UIs and necessary navigation logics embedded inside those UIs. Since the application may be embedded in a variety of ways and how it achieves a desired outcome should be not a concern of Process or BPMS, the UIs of the applications embedded in the services should deliver their UIs to the end user direct. This means some standards that just provide XML-based UIs on SOAP or RESTful Web services binding just for that Web Service operation (not navigational) is not sufficient. The service must have some application logics built inside it, not just providing operations. By the way, OASIS produced http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec.html . Although this can be the case of having a Web application on a Web Services interface, it defines many SOAP operations. Maybe because it requires additional Portlet behaviours that should be controlled at the SOAP level. Although we would not use this for human activities in Processes, is there some useful standard regarding a Web application as a Web Service? (3) Java or .Net application The draft standard indicates that these can be delivered over Web Services interface. What does this mean? Previously, we saw a Web application over Web Service as an example. It must have a Web Server inside the service implementation. What does it provide? Different from a normal Client-Server, this provides an ability for the Client code (corresponding to a particular Server application) to be delivered to the Web browser (user agent) on the client side and to talk to the Web application on the Web Service. So, unless Java or .Net mean an "off-line" task, the Client Application tailored for the Server application on the service must be downloaded. Here, "office-line task" means: the task itself is done off-line by some applications or manually. BPMS does not concern with how it is done, but the results are entered back to the system when they are finished. What should BPMS do? a. It must find out first that it is a Java application (or .Net) that requires a Java client application download b. Must download a Java client application from the service (must know where and how to get it). c. Must automatically launch the client for the target user. d. Must tell it what the Server address is (the Task application embedded on the service). e. Preset the UI of the client application to the user. f. The user starts using the UI. g. Allow the transaction communications h. When the Task is completed, the service must tell the BPMS to dispose the Client (How?) All these (except for a. and g.) automatically happen with Web applications but not with a Java application, although we may be able to use Java Web Start. Still it is not embedded inside BPMS interface. (A Java Applet can be categorized as a Web application, so not as a Java application). Something similar applies to .Net. (4) Task completion Let's consider how a Task can complete. Only the Task Application can tell whether the Task is completed or not, since what qualifies the "Completion" is up to it to judge. For example, the end user may press "Complete" or "Submit" button. However, this does not necessarily constitute "Task Completed". E.g. the form may not have been completely filled or wrong or the Task Application may allow the user to still add another entry or even let the user correct the submitted entry etc. The Task Application may come back and say that the user must fix these things and must submit again, or "Entry accepted. You can enter another or you can finish the Task" etc. The point is that the finish may not be always automatic or obvious in case of human task. Since in most cases the Task Application must judge the "completion", it seems that the end user must tell it to close only when the Task Application permits it. This means that the first "Complete" action takes place from user -> Task UI -> Task Application. Then, Task Application may respond with "OK to complete" back to the WS-C, it may then tell the Task Parent that it is over. Since at this stage, the Task UI is still Open, how does it close it? Probably the Task UI must be composite of Task Parent UI, for example. In that case, the Task Parent may be able to tell the Task UI to close. Or, do we assume some "PUSH" control over the user agent from the BPMS? When the Task UI is closed, the WS-C can tell the EPR or Web Service that the Task state is now "Completed". (5) Task Information for Remote Human Task RemoteTask does not allow any definition of Task on the Process side. Presumably, this is a WS-HT compliant task and all are defined on the Service side. BPMS is not privy to the information before it is calling. Where and how it is defined and the BPEL4People definition file is supposed to be returned upon calling it? When the WS-C returns the EPR, the standard does not define any Presentation Elements or Rendering Elements returned. A Task instance is supposed to be created on BPMS at this point as "Created". Unless the Task Information is retrieved, it has nothing to show on the Task List. Also, the the standard Overriding Elements are sent to the Remote Human Task, but this seems to be never used on the service side. The Task information is the only one which should combine the returned Task Information and the Overriding Elements. (6) Chaining successive Tasks BPEL4People White paper described the desirability of a user not having going back to the Task List after each Task if the following Tasks are meant for the user. Although this requires a mechanism to assign successive Tasks to a single user or the user to choose successive Tasks before starting the run of Tasks, it is not mentioned in the draft 1.0 or 1.1. (7) Voting example Although the example BPEL4People XML is shown, this cannot be done with the BPEL4People, because it can offer a Task to multiple people, but it has no syntax to specify multiple people to claim and to start the Task. The syntax is the same as a single user claiming the Task. As a consequence, the Voting Task may be chosen by a single person, then that's is the end of the story. This also requires the cooperation from the service to recognize the claims to create sub-Tasks and "correlate" the sub-Task instances with the same ID number. There is no such mechanism hinted. Also, BPEL4People does not allow any correlation in People Activity or Remote Task, although BPEL: Invoke Activity has it. However, I think that the BPEL correlation is also not meat for multiple user Use Case. Being an automated Processes, BPEL or BPEL4People had not syntactical provision for multiple-user Use Cases, I think. (8) If I am misunderstanding something and some of my comments are invalid, please correct me. That would be appreciated. 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]