[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 72 - Some proposals
BP compliance is not limited to WSDL bindings. (My point A, for example, can relate to non-binding parts of BP). I don't think we have identified any controversial issues related to non-binding parts so far. Nevertheless it still makes sense voting on BP compliance within the scope of BPEL. For example, I strongly believe in choosing option 1 for my version of point A. Ugo > -----Original Message----- > From: Yaron Goland [mailto:ygoland@bea.com] > Sent: Monday, October 20, 2003 2:48 PM > To: 'Liu, Kevin'; 'Furniss, Peter'; Ugo Corda; > wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 72 - Some proposals > > > One is forced to wonder if it is appropriate for the BPEL standard to > discuss WSDL bindings at all. If it is not then the BP issue > would only be > relevant to the implementation and use case sub-groups. > Since, to the best > of my understanding, neither of those sub-groups work > products are normative > is any vote required for how they choose to handle the issue? > > > -----Original Message----- > > From: Liu, Kevin [mailto:kevin.liu@sap.com] > > Sent: Wednesday, October 15, 2003 4:37 PM > > To: 'Furniss, Peter'; 'Ugo Corda'; 'wsbpel@lists.oasis-open.org' > > Subject: RE: [wsbpel] Issue - 72 - Some proposals > > > > > > Thanks Peter for putting together a good summary. It really > > helps sort out confusions around this issue. > > > > Below is my take on the stated options: > > > > A (with Ugo's amendment) - 1. > > B - 3 > > C - 2 > > D - Since there is no option like E2, I am inclined to 2. The > > Basic Profile has the strong potential to become the > > industry's common denominator for application > > interoperability through Web services. It's basically just > > XSD+SOAP+HTTP, I don't see it a common case that a bpel > > engine doesn't support such a minimum functionality. > > E - 2 > > > > Best Regards, > > Kevin > > > > > > -----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. > > > > > > 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/leave_workgroup. php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]