OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [wsbpel] Issue 154 - Proposal For Vote


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]