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: 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]