Issue - 72 - Some proposals

["Furniss, Peter" <Peter.Furniss@choreology.com>]

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