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: Issue 154 - Proposal For Vote


This sounds good.

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Wednesday, March 02, 2005 8:30 AM
To: Satish Thatte
Cc: wsbpeltc
Subject: 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.
>  >  >  >
>  >  >
>  >
> 



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