[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 154 - Proposal For Vote
+1 assaf 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 > > > >
begin:vcard fn:Assaf Arkin n:Arkin;Assaf org:Intalio adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065 email;internet:arkin@intalio.com title:Chief Architect tel;work:(650) 596-1800 x-mozilla-html:TRUE url:http://www.intalio.com version:2.1 end:vcard
S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]