RE: [wsbpel] Issue - 72 - Some proposals

["Ugo Corda" <UCorda@SeeBeyond.com>]

Peter,

I pretty much agree with your description of options for B-E, but I think case A options are incorrectly stated.

As we have already preliminarily assessed, there are no features currently required by BPEL (within its scope, i.e. WSDL abstract interface) that are not provided by BP 1.0. So right now options 1, 2 and 3 of A are indistinguishable as far as their practical effects are concerned.

What BP 1.0 addresses within the scope of the BPEL language is clarifications in the use of WSDL 1.1 features that are underspecified or contradictory/erroneous. It would be more appropriate to state A as:

A : of the language
	1 shall not interpret underspecified/erroneous WSDL 1.1 features in a way that is contradictory with BP 1.0 interpretation
	2 should merely encourage (use of word "SHOULD" ?) such consistency with BP 1.0

Ugo

> -----Original Message-----
> From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
> Sent: Thursday, October 09, 2003 4:58 AM
> To: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Issue - 72 - Some proposals
> 
> 
> In some kind of mental aberration, I talked myself into being Champion
> for issue 72 on BPEL and BP 1.0 during the issues group session last
> night. I've been through the emails and, though there isn't a clear
> consensus, there is some emerging agreement. Perhaps.
> 
> I believe it will help to separate the target of the 
> alignment - what is
> affected by aligning BPEL with BP 1.0. Some of the apparent 
> disagreement
> is because people were addressing different targts. Thus there are
> 
> 	- implications on the language - essentially policy decisions
> that will affect our own work in producing the first committee draft
> BPEL (BPEL CD 1.0 ?)
> 	- implications on the use-cases artifacts
> 	- implications on the use-cases themselves
> 	- implications on bpel engines
> 	- implications on deployed bpel processes
> 
> For each of these, I put forward the following alternative assertions.
> Some of these I'm pretty sure are generally rejected, but by stating
> them we can be sure. For D, D.1 could be accepted with one of 
> the other
> D's (or some of them). All other groups are, I think, strict
> alternatives.
> 
> A : of the language
> 	1 shall have no support for features that could not be used with
> BP 1.0 services
> 	2 need have no support for features that could not be used with
> BP 1.0 services
> 	3 should merely encourage (use of word "SHOULD" ?) BP 1.0 use
> 
> B: of the use-case artifacts 
> 	1 all shall be BP 1.0 compliant
> 	2 all shall be BP 1.0 compliant or out of BP 1.0 scope
> 	3 shall be either BP 1.0 compliant or have a necessary and
> explained reason to be otherwise
> 		
> C: of use-cases themselves
> 	1 shall be capable of implementatin with exclusively BP 1.0
> services
> 	2 shall be so capable or have a necessary and explained reason
> to be otherwise
> 			
> D: of bpel engines
> 	1 need not implement features that could not be used with BP 1.0
> services (assuming A.1 is rejected)
> 	
> 	2 shall be able to offer and use BP 1.0 services, but is free to
> implement other bindings and encodings even with soap/http
> 	3 shall be able to offer and use *only* BP 1.0 services
> 	4 shall only be able to offer BP 1.0 ports but use other
> 	5 for bindings in scope for BP 1.0, shall only be able to offer
> BP 1.0 ports (no restriction on other bindings)
> 
> E: of deployed bpel processes
> 	1 shall offer at least one BP 1.0 port
> 	2 no limitation; it is just a binding issue and so no concern of
> ours
> 
> Bit of explanation of A.1, A.2 : if A.1 or A.2 are accepted, then in
> considering of issue XYZ, if BP 1.0 answers the question, then the BP
> 1.0 can be (shall be if A.1) applied without further concern. (Ugo
> mentioned that Issue 46 may be answerable on this basis).  If A.1 is
> accepted, then we are agreeing that if, for issue PQR, "you can't
> exploit that feature with BP 1.0" is true, then the feature is
> rejected/removed from BPEL. If both are rejected, then the 
> capability of
> the language can be deliberately exceed BP 1.0-possible (and a
> requirement from a non BP 1.0 case would be acceptable). 
> 
> The above are of course open to clarification (which may 
> split them). As
> a first stab, I think the discussion was leaning towards accepting:
> 
> A.3, B.3, C.2, D.1, D.2, E.2
> 
> but I'm liable to be biased.
> 
> Bernd's text in
> http://lists.oasis-open.org/archives/wsbpel/200310/msg00085.html
> expresses A.3, D.1 and D.2. B and C are more "policy" matters for the
> use-cases group.
> 
> Peter
> 
> ------------------------------------------
> Peter Furniss
> Chief Scientist, Choreology Ltd
> 
>    Cohesions 1.0 (TM)
>    Business transaction management software for application 
> coordination
> 
> web: http://www.choreology.com
> email:  peter.furniss@choreology.com
> phone:  +44 870 739 0066  <-- new, from 4 August 2003
> mobile: +44 7951 536168
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
ave_workgroup.php.