OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bpel4people message

[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
more design points that have lead to the current description in chapter 7
of the WS-HT specification:

- WS-HT application messages (requestMessage and reponseMessage),
WS-HT-specific coordination protocol messages (Skipped, Fault, and Exit),
and general WS-C messages (activation, registration, coordination faults)
are handled separately -- the **normative reference to WS-C** avoids the
need for repeating general coordination concepts here (this is a formal
point -- we would not repeat definitions from e.g. WSDL or XML Schema
either)

- WS-HT coordination protocol messages Skipped, Fault, and Exit must be
standardized for achieving **interoperability** between Task Parent and
Task runtime components -- coordination protocol messages exchanged between
Task Parent and Coordinator **should not** be standardized in order to
allow local optimizations by a single runtime component that implements
both the Task Parent and the Coordinator

- Only the subset of all possible WS-HT human task state transitions that
are **relevant** to a Task Parent (typically those leading to final states)
have been made visible by means of coordination protocol -- as a result,
there are no e.g. "Start", "Stop", etc. coordination protocol messages --
as an example, BPEL4People has a simplified state transition diagram (that
of the peopleActivity) driven by this subset -- however, this might of
course be subject of a new issue and a corresponding resolution proposal
extending the protocol ...

Hope this helps!

Kind Regards

Dieter König

Senior Technical Staff Member, WebSphere Process Server Architect
IBM Software Group, Application and Integration Middleware Software
WSS Business Process Solutions





Phone:            +49-7031-16-3426           IBM Deutschland                      (Embedded 
                                                                                image moved 
                                                                                   to file: 
                                                                              pic09804.gif) 

E-Mail:           dieterkoenig@de.ibm.com    Schönaicher Str. 220                           

                                             71032 Böblingen                                

                                             Germany                                        





IBM Deutschland                                                                             
Research &                                                                                  
Development                                                                                 
GmbH /                                                                                      
Vorsitzender des                                                                            
Aufsichtsrats:                                                                              
Martin Jetter                                                                               
Geschäftsführung:                                                                           
Erich Baier                                                                                 
Sitz der                                                                                    
Gesellschaft:                                                                               
Böblingen /                                                                                 
Registergericht:                                                                            
Amtsgericht                                                                                 
Stuttgart, HRB                                                                              
243294                                                                                      

smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]