RE: [wsbpel] Issue 154 - Proposal For Vote

["Satish Thatte" <satisht@microsoft.com>]

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.
>  >
>