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: BP-64 PPT


Hi Yoichi,

While I have a personal opinion :-) in my role as TC chair I am officially neutral and it's up to the TC members, not me per se to determine if this is in or out of scope.

Regards, Dave Ings,
Emerging Software Standards
Email: ings@ca.ibm.com
Yahoo Messenger: dave_ings

Inactive hide details for Yoichi Takayama ---2009/04/14 09:36:54 PM---Hi Dave, Thanks for reviewing it.Yoichi Takayama ---2009/04/14 09:36:54 PM---Hi Dave, Thanks for reviewing it.


From:

Yoichi Takayama <yoichi@melcoe.mq.edu.au>

To:

Dave Ings/Toronto/IBM@IBMCA

Cc:

bpel4people@lists.oasis-open.org

Date:

2009/04/14 09:36 PM

Subject:

Re: BP-64 PPT





Hi Dave,

Thanks for reviewing it.

I don't see any change you might have made to the slides, except probably for the font-size change you have made.

I have corrected the last slide (Proposal) to make it simpler and clearer. Please have a look.

I will distribute this corrected version as below in the older MS PPT format.
[attachment "OASIS BP-64 v.2.ppt" deleted by Dave Ings/Toronto/IBM]

I must appreciate your comment on the original one that you disagree, because then I know that I have to defend my position.

I disagree with the view that this issue is not necessary or out of scope, but please check the new Proposal first.


My point:

At least the Task service must indicate what UI the Task wants the caller to be able to handle (FORM, Web Application, etc. It makes a difference how it can be called and what User Agent it may require), and how the UI can be obtained (e.g. EPR or URL). This is because the Task Service just stalls after the initial request and the WS-C exchange. There has to be another call to the Task.

How does it do it? There is no indication of this. At least there should be an indication of how this can be done. Can anyone show me actually how this is done and where it is described on the documents? As I read them, I can not find any hint on how this is done and how the "start Task" action (in the life cycle management) may cause the UI to be obtained and the end user start doing the Task.

For this to happen, the system must know at least how to obtain the UI, and additionally what the UI is.

Unless this is clarified, as an implementer, I have to say I cannot implement the remoteTask at all at this stage.

This actually may apply to the "proprietary" inline- and local Tasks, too. Although the specification do not define them saying out-of-scope, an implementor must still devise how this can be implemented. I assume that there would be implicit UITypes and calling information for the UIs used by the inline- and local Tasks, too.

Why?

This is because the inline- or local Task will probably use the same Task Processor, Task List Client, and Task Client, who use the same UIType and the calling information. Therefore, there is no other way than unifying them. I don't see any other description how the inline- or local Task are done.

If the inline- or local Task uses different Task Processor, Task List Client and Task Client, this is not the case, but who would use two separate sets, one for internal Tasks and another for external Tasks???

Details:

For example, let's say that the UI is a single HTTP Form. It has to be obtained from the Task implementation (the caller has no information what the Form is like) and the Task Client must present it to the end user. The Task Client must also return the filled-in Form to the Task. In the current specification, there is no indication (not a specific details but just a guide) of how the UI can be obtained or how the implementer can work it out in an interoperable way.

Also, many UIs will require multiple communications, not just a single request to get a single HTTP Form as the above example. We don't want such a mechanism to be fixed on the HTTP Form alone. We want some flexible and generic way that will fit all UIs.

You are correct in that the Web Service interface is just HTTP protocol port on a server that will listen to whatever the request coming in and it may or may not supply UI. It can be used whatever the way, i.e. to supply HTTP Form, Web application, XML UI, XForm, XML Application, etc. However, my point is that the caller must be informed of the nature of the UI required. What I mean is that the "normal" (meaning typical) use of Web Services do not supply UI or require separate user interactions other than the original "request" calls. I presume that the UI calls are other than what Task WSDL defines as portTypes and operations.

This (UI information) can be done in many ways, implicitly (i.e. there is some agreement or assumption between them) or explicitly, or automatically (e.g. both parties exchange information and find it out at runtime) or manually (i.e. the B4P may use WSDL or some other external definition for it).

However, there are other possibilities. The Web Service interface is just a Task Service instance registration. It may issue an instance ID for the session. By using this session, the caller may call yet another URL to start doing Task application, which may be hosted by the Task Web Service or something else on the same saver (Web application) or some other server, or even to tell the caller that the end user must do some off-line manual task or application and enter or upload the results. How can this be described between the caller and the Task?

Of course, the B4P documents should not concern any of the fine details. It should only define minimum information to assure the interoperability and the rest should be handled automatically.

In my opinion, the information simply must be the part of Task instantiation handled by the Task Processor (probably requires an additional call via WS-C) and the information must be used to instantiate the UI with the Task Processor and it must be passed to the Task Client to allow the UI session to take pace.

If the caller cannot handle the UI request, it can simply decline to handle the Task. If this is done by WSDL or some definition that is included in B4P, for example, the system can detect incompatible Task Services when such Process is deployed onto it. This way, we do not have to define some fine details of some unusual UIs.

For the Task UI info, for interoperability, we can define elements (UIType, parameters and how to call it, e.g. EPR or URL) and the agreed formats of the UI information for commonly used UIs, maybe only the HTTP Form and Web application at this time, and leave the others as extensible type.

With such generic arrangement, it is up to the Task Web Service and the Task Processor (or Task List Client) and Task Client to work out the details. B4P or WS-HT does not have to handle actual UI details.

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
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.

On 15/04/2009, at 1:38 AM, Dave Ings wrote:




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