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] Issue - 72 - Some proposals


Those weren't intended as alternatives - the D2 to D5 set were. Looking
at it again they are similar if not identical. D1 was supposed to mean
that a conformant engine need not do more than BP 1.0; D2 to mean that a
conformant engine shall do *at least* BP 1.0.   An implementation that
did BPEL only with (say) java rmi and soap rpc encoding would be ok with
D.1 but fail D.2.  

(It's a separate, and possibly academic, question whether such an
implementation would be useful and if useful whether it is desirable to
class it as conformant.  Peter's doctrine: implementations based on some
spec A can be distinguished as to whether they are useful (=someone will
pay for it and use it because it does what they need) and whether they
are conformant (=align with the conformance requirements of spec A.)
The writers of conformance requirements must recognise that it is
impossible to have a definition that makes all useful implementations
conformant and all non-conformant implementations useless - the writers
must choose whether some non-conformant implementations are useful or
some useless implementations are conformant. (It may not be possible to
avoid both))

On those grounds, if we accept D.2, we are making possibly useful
implementations (since the rmi:rpc encoding implementation might be a
useful bridging tool) non-conformant.


Peter

> -----Original Message-----
> From: Danny van der Rijn [mailto:dannyv@tibco.com] 
> Sent: 09 October 2003 21:47
> To: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 72 - Some proposals
> 
> 
> i agree with all of this, but i'm confused as to what the 
> difference between these D1 and D2 is.
> 
> <snip>
> 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 </snip>
> 
> ----- Original Message ----- 
> From: "Furniss, Peter" <Peter.Furniss@choreology.com>
> To: <wsbpel@lists.oasis-open.org>
> Sent: Thursday, October 09, 2003 4:58 AM
> 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.ht
ml
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/leave_workgr
oup.php.



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/leave_workgr
oup.php.



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