[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]