[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 72 - Some proposals
Yes, the proposed resolution for issue 46 would fall within the A.1 category. > -----Original Message----- > From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] > Sent: Thursday, October 09, 2003 9:34 AM > To: Ugo Corda; wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 72 - Some proposals > > > Ugo, > > Thanks - I had hoped there were no known limitations imposed > by BP 1.0, > which would indeed make my A options collapse. However, it > was partly a > question of giving ourselves guidance for our own future, if we find > that there is such. But since we don't think it can happen, crossing > that bridge when we come to it would be fine. Your A.1 states things > well. > > I take it the proposed resolution of issue 46 (which you mentioned in > some of the 47/72 discussion) follows your A.1 rule. > > Peter > > > > > -----Original Message----- > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > > Sent: 09 October 2003 17:23 > > To: Furniss, Peter; wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Issue - 72 - Some proposals > > > > > > 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. > > > > > > 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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]