[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 154 - Proposal For Vote
Works for me. Dieter Koenig1 wrote: > W.r.t. the discussion in the call about reducing the statement to just > saying BPEL is not fixing any binding bugs, I propose this one: > > Section 3: > > Insert new paragraph after the paragraph that begins "While WS-BPEL > attempts to provide as much compatibility with WSDL 1.1 as possible...": > > BPEL does not make any assumptions about the WSDL binding. > Constraints, > ambiguities, provided or missing capabilities of WSDL bindings are > out > of scope of this specification. > > Kind Regards > DK > > ----- Forwarded by Dieter Koenig1/Germany/IBM on 02.03.2005 18:30 ----- > > "Yaron Y. Goland" > <ygoland@bea.com> > To > 02.03.2005 17:29 Satish Thatte > <satisht@microsoft.com> > cc > Please respond to wsbpeltc > ygoland <wsbpel@lists.oasis-open.org> > Subject > [wsbpel] Issue 154 - Proposal For > Vote > > > > > > > > > > > Section 3: > > Insert new paragraph after the paragraph that begins "While WS-BPEL > attempts to provide as much compatibility with WSDL 1.1 as possible..." > > BPEL assumes that the WSDL binding layer is able to decompose incoming > messages into the parts specified by the WSDL message definition. It is > at least theoretically possible in some cases for the translation > between the WSDL binding layer and the WSDL message definition to be > ambiguous. The BPEL specification assumes that these > ambiguities will be dealt with at the binding layer, perhaps by > forbidding ambiguous message definitions, and are therefore out of scope > of BPEL. > > > Satish Thatte wrote: > > That works for me. > > > > -----Original Message----- > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > Sent: Monday, February 28, 2005 10:57 AM > > To: Satish Thatte > > Cc: wsbpeltc > > Subject: Re: [wsbpel] Issue 154 - Proposal For Vote > > > > Fine, then let us state that. Let us make it clear in the spec that BPEL > > > > will not deal with a message until it has been successfully translated > > into an abstract message and how that happens is out of scope for the > > spec. Even a statement like that would resolve the issue. > > > > Yaron > > > > Satish Thatte wrote: > > > The question is: implementer of what? We are only addressing the > > > implementer of BPEL who is not even required to be aware of the SOAP > > > binding. There are clearly bindings that would make this unambiguous > > > but those again are out of scope for the metadata the BPEL implementer > > > is concerned with. > > > > > > This is the essence of my objection: addressing binding issues in the > > > spec *unnecessarily* expands the scope of what we are concerned with. > > > It is clearly possible to implement BPEL in such a way that the > > binding > > > layer is cleanly separated and the "BPEL engine" is not even invoked > > > until an abstract message has been constructed successfully. > > > > > > Satish > > > > > > -----Original Message----- > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > Sent: Monday, February 14, 2005 2:30 PM > > > To: Satish Thatte > > > Cc: wsbpeltc > > > Subject: Re: [wsbpel] Issue 154 - Proposal For Vote > > > > > > An implementer creates a test message involving two complex types, > > both > > > of which are unbounded sequences of the same element type. When > > encoded > > > in a SOAP message there is no binding level definition that lets the > > > engine figure out which parts of the SOAP message should go into one > > > part versus another. > > > > > > The implementer, looking at this completely legal WSDL case then has > > to > > > ask themselves 'how should I handle this'? > > > > > > The answer is - by rejecting the binding, it's ambiguous. > > > > > > But where in the spec can they find that ever stated? The answer is - > > > they can't. > > > > > > So the implementer is left to wonder if: > > > A) There is some part of the spec that addresses the situation but > > they > > > can't find it > > > B) The spec has a bug and meant to provide a way to handle the > > situation > > > > > > but forgot > > > C) BPEL intentionally doesn't address the situation because it is out > > of > > > > > > scope > > > > > > There is nothing in the spec which I can find that would lead a common > > > implementer to know which of the three above options to choose. > > > > > > By adding in a simple paragraph we resolve the situation nicely and > > make > > > > > > it absolutely clear that this type of scenario is not something BPEL > > > deals with. > > > > > > BTW, I get this kind of question from my testing team all the time and > > > is where a number of the clarification issues I have raised have come > > > from. > > > > > > Yaron > > > > > > Satish Thatte wrote: > > > > Can you give me an example where a BPEL engine implementer would > > get > > > > confused about what the BPEL engine's responsibilities are based on > > > > today's spec? > > > > > > > > -----Original Message----- > > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > > Sent: Monday, February 14, 2005 12:35 PM > > > > To: Satish Thatte > > > > Cc: wsbpeltc > > > > Subject: Re: [wsbpel] Issue 154 - Proposal For Vote > > > > > > > > I'm unclear how you can be so sure that an implementer will come to > > > the > > > > same conclusion that as reached in the second paragraph of your > > mail. > > > > After all, there are a number of techniques we could have chosen to > > > use > > > > at the abstract layer that would have dealt with some of the > > > ambiguities > > > > > > > > at the binding layer. But we wisely choose not to try and > > disambiguate > > > > things at the abstract layer because it would be a nasty mess. But > > > that > > > > decision is not recorded anywhere in the spec. By explicitly > > stating > > > > that we will not try to disambiguate things at the abstract layer > > we > > > > create a clearer specification. > > > > > > > > Put another way, what may be clear in your mind will most certainly > > > not > > > > be clear in the minds of implementers who will not have your > > > background > > > > in the spec. > > > > > > > > Yaron > > > > > > > > Satish Thatte wrote: > > > > > -1 > > > > > > > > > > I think this additional language adds no useful content to the > > > > > specification. All it says is: WSDL has binding problems and > > they > > > are > > > > > WSDL's problems not ours. > > > > > > > > > > > > > > > Since we only deal with abstract port types and abstract message > > > > types, > > > > > it is absolutely clear already that it is someone else's > > > > responsibility > > > > > to "make things right" from the wire layer to the abstract > > layer. > > > > > > > > > > Satish > > > > > > > > > > -----Original Message----- > > > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > > > Sent: Friday, February 11, 2005 12:47 PM > > > > > To: wsbpeltc > > > > > Subject: [wsbpel] Issue 154 - Proposal For Vote > > > > > > > > > > Issue 154 - doc/lit & multiple body parts > > > > > > > > > > Proposal: To put in language that makes explicit what is > > currently > > > > > implicit in the BPEL spec, that it is the binding layer's job to > > > > > decompose the physical message into the portType definition. > > > > > > > > > > Rationale: One of the more basic flaws in spec writing is to > > make > > > > > implicit assumptions. By doing so spec implementers are always > > left > > > in > > > > > the dark because they may not share the same implicit > > assumptions > > > as > > > > the > > > > > > > > > > spec authors. The fix is to make the implicit assumption > > explicit > > > > which > > > > > is what this proposal does. Note, however, that this proposal > > > causes > > > > no > > > > > normative changes to BPEL's current behavior, it just makes what > > > was > > > > > implicit, explicit. > > > > > > > > > > Changes Required: > > > > > > > > > > Section 3 - > > > > > > > > > > Insert new paragraph after the paragraph that begins "While > > WS-BPEL > > > > > attempts to provide as much compatibility with WSDL 1.1 as > > > > possible..." > > > > > > > > > > BPEL assumes that the WSDL binding layer is able to decompose > > > incoming > > > > > messages into the parts specified by the WSDL message > > definition. > > > > > However it is know that certain combinations of message > > definitions > > > > and > > > > > bindings, including ones defined in the WSDL standard itself, > > > cannot > > > > be > > > > > decomposed in any standard way. For example, a multi-part WSDL > > > message > > > > > where one of the parts is a complexType and a doc/lit SOAP > > > transport > > > > can > > > > > > > > > > create ambiguous situations. The BPEL specification assumes that > > > these > > > > > ambiguities will be dealt with at the binding layer, perhaps by > > > > > forbidding ambiguous message definitions, and are therefore out > > of > > > > scope > > > > > > > > > > of BPEL. > > > > > > > > > > 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, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]