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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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


Subject: RE: [wsbpel] A Topic for the F2F?


Personally I am not in favor of standardizing on any one particular representation. Instead I was thinking more of the location of objects on the page and the location and route followed by lines to connect objects together. I was not thinking of the visual representation of ICONs as depending on your preference, you might want to use different ones.
 
Other things to think about is the idea of pages that contain subsets of perhaps a large process so that you have multi-page documents.
 
My thoughts on what needs doing is nowhere neare complete so the idea is that there is a sub-committee that thinks about the issues, make recommendations and then determines how to move forward if agreed.
 
David
-----Original Message-----
From: Rajesh Pradhan [mailto:rajesh@iopsis.com]
Sent: Thursday, May 22, 2003 5:09 PM
To: 'Burdett, David'
Cc: 'WS BPEL (E-mail)'
Subject: RE: [wsbpel] A Topic for the F2F?

Hi David,
 
Good thoughts ! I assume that by Visual Extensions you mean the visual representations ( icons and such like ) to depict the BPEL constructs.
 
I wonder if this should be a part of the specification though ?  For instance, we have created an internal POC that uses a UML Profile to model the constructs - seems to work I guess.
 
My feeling is that tool vendors will prefer to create their own visual interpretations of the BPEL artifacts. On the flip side, I feel, if we do insist on standardization, then UML seems to be the best bet.
 
Regards,
 
Rajesh.
-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Thursday, May 22, 2003 4:47 PM
To: 'Tony Andrews'; Burdett, David; WS BPEL (E-mail)
Subject: RE: [wsbpel] A Topic for the F2F?

Tony
 
Thanks for the comments, I agree, that "Business Process Execution Language" is a bit of a misnomer and perhaps it should be simply called a "Process Execution Language" ... but let's not go there ...
 
As far as including the Visual Binding extensions in BPEL natively is concerned I think we can actually separate the work into two parts:
1. Identify WHAT additional information needs to be held to identify the graphical information, and
2. Design HOW to represent that information. At this point we can choose to include it within the BPEL language or have a separate language. We can also decide whether it goes in the same spec e.g. in an Appendix or in a separate spec.
 
The point is that we do not have to decide immediately HOW to specify it.
 
David
-----Original Message-----
From: Tony Andrews [mailto:tandrews@microsoft.com]
Sent: Thursday, May 22, 2003 4:33 PM
To: Burdett, David; WS BPEL (E-mail)
Subject: RE: [wsbpel] A Topic for the F2F?

I just wanted to comment on your first assumption below. The "business protocol" extensions in BPEL are very much about describing behavior, as opposed to execution. A BPEL abstract process definition is a useful description of behavior regardless of how the service is implemented. I would even argue that "business protocol" may be an unfortunate name for this given that we're really talking about services in a more general sense. The two usage styles - "executable processes" and "business protocols" can each be used independently or together as appropriate.
 
Regarding your real point, I wonder if a set of standard annotations and extensions within the BPEL document itself would be sufficient. Separating these into different documents seems troubling to me.
 
Tony


From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Thursday, May 22, 2003 3:45 PM
To: WS BPEL (E-mail)
Subject: [wsbpel] A Topic for the F2F?

Here's a topic I would like to suggest for discussion at the F2F.
 
THE PROBLEM
The problem arises because of three assumptions that I believe are valid:
1. BPEL is an "execution only" language, i.e. it is desgined to be something that can be input into software and run, e.g. using some "BPEL Run Time" software
2. BPEL will often be defined and maintained with the aid of some GUI based "BPEL Design Time" software that allows the process to be visualised.
3. The BPEL Design Time software will contain additional positional and graphical information about the visual representation of the BPEL design that not contained in the BPEL XML definitions.
 
The problem is that this means that exporting a BPEL definition from one BPEL Design Time for input into another will result in a BPEL definition that will not be easily editable as all the graphical information would be lost.
 
In the extreme, for a complex design, it could mean that designer of business processes using BPEL is effectively locked into the BPEL Design Time software provider that they initially choose. This I don't think is a good idea.
 
THE SOLUTION ?
To solve this problem I would like to suggest the setting up of a sub-committe of the TC that has responsibilty for developing a "BPEL Visual Binding" specification which would contain the relevant visual information from the BPEL Design Time. The idea would be that the Visual Binding specification is a separate document to the main BPEL specification. Also BPEL Design Time Implementations could export either:
1. The BPEL XML Definition alone, or
2. The BPEL XML Definition PLUS the BPEL Visual Binding
 
The former could be used for input to a BPEL Run Time and the latter could be input into some other BPEL Design Time.
 
By creating a separate, but related, specification, it should be possible to carry out the work on the BPEL Visual Binding specifcation in parallel, without hindering any work on the main BPEL specification.
 
Regards
 
David
 
 
Director, Product Management, Web Services
Commerce One
4440 Rosewood Drive, Pleasanton, CA 94588, USA
Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
 


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