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