[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [bpel4people] Action Item 10 - comments on WS-HT section 7/8
Thanks, Dieter, for the explanation. I fully understand all those. I agree that we would not go into too much details of WS-C. WS-C, however, does not define what WS-HT protocol messages are to be sent. WS-HT defines what they are and that is what WS-HT document should describe. Also, I agree that they have to be standardized. So do the requestMessage and the responseMessage (except for the input/output parameters - they are service dependent). In that, however, I disagree that Start, Stop and Suspend must be conveyed to the Task Application, because it affects the session management of the Task Application. BPEL4People lists examples of Task Applications, such as, a simple Form (HTML Form or XForm or a UI page in some protocol, presumably an XML), Web Application, Java, Web Dynpro, Flex, .Net, etc. I think that the list probably should include even an XUL application, or existing Desktop applications, such as Excel or MS Word, under a control of WS-C. For a single form-based "application", "Start", "Stop" and "Suspend (only while it is in InProgress, not other Suspends)" probably do not have to be conveyed. I, however, strongly believe that this is not the case for more complex "applications" that expect multiple messages exchanged between the UI clients and the Task Applications before the completion, and require some sort of session control of their own. Please note that the WS-C or BPEL4People do not have to handle the sessions, since the UIs themselves are capable of doing session management. They, however, need to be told of these Task life-cycle events that affect their behaviours and must take necessary measures to respond. Of those Task life-cycle events shown, the user assignment/claiming related events do not have to be conveyed to the Task applications, since the Task applications have not started at that time and these events are only needed for maintaining some states of Task proxies (Task entries on Task List) between the end users and the Task Manager. They are not the states of actual Task executables, but they overlap once the Task applications started. Incidentally, I have architected a workfow system where these human interface "applications" are all Web applications or use Web application adaptors, and we need those states to control the behaviours of the Web applications according to the end user requests to Start, Stop, or Suspend once they were started. Also, you have to remember that the WS-C does not describe at all what the requestMessage and responseMesaage should be for WS-HT although WS-HT 1.0 has very scanty descriptions of them. Of course, an alternative is not to include WS-HT specific things in the resuqestMessage and responseMessage, but to include such in "Start" or "Activate" and WS-C "Completed" (which should not trigger responseMessages in this case), i.e. WS-C's WS-HT protocol messages. However, this is not what WS-HT describes did. It includes the Task Context, input parameters, output parameters, attachments, etc. in the requestMessage and responseMessage. As Alex pointed out, they are not clearly described in WS-HT specification, so they should be elaborated (i.e. SOAP binding), although I can decipher to some extent what they are and how they may be expressed as SOAP in these messages. WS-C documentation does not help us much in this and it takes a fair bit of efforts to see that the WS-C has nothing to do with this. This is because the WS-C must be read just to make sure that this is not defined in WS-C or anything else such as WSDL 2.0 as some common profiles. This is all because WS-HT does not elaborate on them although it should state these matters. Does this make sense? Thanks, 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 -------------------------------------------------------------------------- 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 02/12/2008, at 9:21 PM, Dieter Koenig1 wrote: Yoichi, Alex, before we get too deep into the details, let me add a few |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]