RE: [wsbpel-abstract] where is the dividing line?

["Rossomando, Philip" <Philip.Rossomando@unisys.com>]

Ok Martin, I assume that your definition is a single language 
And we leave it up to the customer as to how to simplify it.
I don't think there is a single dividing line. To look for one
Is to search for a Holly Grail. I would like to see from you and
Others within the TC their definition of what abstract BPL is
And the requirements for use. As was said in last week's meeting
A hopeful consensus definition and requirements list will be 
Put together. Hopefully by the f2f. Some of our group definitely
See a place for abstract BPEL (e.g., SAP, et. al.).

Phil

PS. Your input is definitely appreciated. 

Phil Rossomando
 
Research Director, Technology & Architecture
Unisys Corporation
Unisys Way, B-330
Blue Bell, PA 19424 USA
Philip.rossomando@unisys.com
215-986-3998
FAX 413-0215-2043
 

-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com] 
Sent: Monday, June 14, 2004 10:07 AM
To: wsbpel-abstract@lists.oasis-open.org
Subject: [wsbpel-abstract] where is the dividing line?



I've been listening with great interest to the discussions on abstract
BPEL as contracts, abstract BPEL as templates, and 
abstract BPEL as an intermediate language, and I agree each use case is
valid. What I am having trouble with is how we can define a single
language to meet all these goals; where is the single dividing line
between abstract and executable BPEL?

When a company exposes a definition to another company surely it is up
to the company to decide
 how much detail it wants to expose.
If a company chooses to expose an executable BPEL definition who are we
to stop them?
In fact there is no way of stopping them.
Internally, a company may want to expose more detail between analyst and
programmer then they would to external parties, and different companies
will have different rules about what can be exposed and where.
Some people may want to make extensive use of <opaque> to inform others
that something internal will happen, others may stick to plain old
extensibility.

My point is that all these use cases are valid, yet they appear to have
different exclusion requirements on the language, and that different
companies may have different polices as to what gets exposed (or not).
Is it really possible to define a single syntax under the abstract BPEL
umbrella, which all vendors support and which precisely matches a
variety of customer usage policies. Sounds more than a single language
to me; it sound like a family of syntaxes. Wouldn't it be better just to
define a single language (BPEL) and let tool vendors support
customisation that allows each *Customer*  to  decide what features are
in and out?

Look forward to your feedback,
   Martin.



_________________________________________________________________
Martin Chapman                                 
Consulting Member of Technical Staff           
Oracle                                        
P: +353 87 687 6654                           
e: martin.chapman@oracle.com