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


I am with Paco on this.  I see no reason to even mention binding in the
BPEL spec since we cannot say anything useful, only make empty noises
about not being responsible for any problems regarding something that we
never mention.

Some of the other WSDL issues having to do with overloading etc were
more directly of concern in disambiguating BPEL runtime behavior.

-----Original Message-----
From: Francisco Curbera [mailto:curbera@us.ibm.com] 
Sent: Tuesday, February 08, 2005 1:01 PM
To: ygoland@bea.com
Cc: wsbpeltc
Subject: Re: [wsbpel] Issue 154 - Proposal For Vote

Just to be clear: this is not a failure of BPEL, in fact this problem is
shared by WSDL 1.1 users as a whole. So using this issue for suggesting
again that the BPEL spec is broken is just nonsense. The fact is that
there
are holes in the WS stack, but that doesn't mean that BPEL needs to take
on
the job of patching them all to succeed.

Anyhow, I think enough has been said on such a minor issue. I would
suggest
we take a vote and get on with it.

Paco




 

                      "Yaron Y. Goland"

                      <ygoland@bea.com>        To:       Francisco
Curbera/Watson/IBM@IBMUS                                             
                                               cc:       wsbpeltc
<wsbpel@lists.oasis-open.org>                                         
                      02/04/2005 01:53         Subject:  Re: [wsbpel]
Issue 154 - Proposal For Vote                                     
                      PM

                      Please respond to

                      ygoland

 





One of the qualities of a good specification is that it doesn't make any
implicit assumptions. Currently the BPEL specification fails to meet
this bar as it implicitly assumes that 'somehow' the binding layer will
be able to produce a value that can be placed in a messageType variable
but it never makes this assumption clear in the spec.

The result is that there are circumstances in WSDL where a legal WSDL
cannot necessarily be unambiguously decomposed from a binding layer
message to a messageType. Because of the BPEL spec's failure to be clear
the implementer is left confused as to who bears the responsibility of
fixing the situation, the binding layer or the BPEL processor.

My proposal is that we make explicit what until now has been implicit -
if there are any issues translating between the binding layer and the
messageType then the responsibility for resolving matters belongs to the
binding layer and not BPEL.

                         Yaron

Francisco Curbera wrote:
> The text is certainly a little better but I still think we are not
doing
> anyone a favor by sprinkling the BPEL spec with WSDL issues and
warnings
-
> there are way too many of those! My preference is not to address this
issue
> in the BPEL spec.
>
> Paco
>
>
>
>

>
>
>                       "Yaron Y.
> Goland"

>
>
>                       <ygoland@bea.com>        To:       Francisco
> Curbera/Watson/IBM@IBMUS
>
>                                                cc:       wsbpeltc
> <wsbpel@lists.oasis-open.org>
>
>                       01/14/2005 06:26         Subject:  Re: [wsbpel]
Issue 154
> - Proposal For Vote
>
>
> PM

>
>
>                       Please respond
> to

>
>
>
> ygoland

>
>
>

>
>
>
>
>
> I agree with your statement that "In BPEL we need to assume that WSDL
> and SOAP processing have taken place and provide us with the right
> messages, properly processed.", what the issue is asking for is that
the
> assumption be made explicit.
>
> Perhaps a warning of the form "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."
>
>                          Yaron
>
> Francisco Curbera wrote:
>  > I personally prefer to leave this type of  WSDL or SOAP
recommendations
> to
>  > the appropriate 'authorities' (WS-I and the like). In BPEL we need
to
>  > assume that WSDL and SOAP processing have taken place and provide
us
with
>  > the right messages, properly processed. The use case mentioned here
might
>  > make sense for example when a non-SOAP serialization is
encountered.
So
> my
>  > preference is to close w/o change.
>  >
>  > If (against this advice) the TC persists in addressing this issue
in
the
>  > BPEL spec, I would suggest that the last sentence ("implementations
>  > reject...") be changed to a recommendation to authors to ensure
that
the
>  > message definitions they use don't lead to processing difficulties
under
>  > certain bindings. Based on BPEL's binding-independence aims this
seems
> like
>  > a more reasonable piece of advice to me.
>  >
>  > Paco
>  >
>  >
>  >
>  > |---------+---------------------------->
>  > |         |           "Yaron Y. Goland"|
>  > |         |           <ygoland@bea.com>|
>  > |         |                            |
>  > |         |           01/13/2005 08:47 |
>  > |         |           PM               |
>  > |         |           Please respond to|
>  > |         |           ygoland          |
>  > |---------+---------------------------->
>  >
>  >
>
>-----------------------------------------------------------------------
--------------------------------------------------------------|

>
>  >
>  >
>  > |
>
>  > |
>  >
>  >   |       To:       wsbpeltc
>  > <wsbpel@lists.oasis-open.org>
>
>  > |
>  >
>  >   |
>  > cc:
>
>  > |
>  >
>  >   |       Subject:  [wsbpel] Issue 154 - Proposal For
>  > Vote
> |
>  >
>  >
>  >
>
>-----------------------------------------------------------------------
--------------------------------------------------------------|

>
>  >
>  >
>  >
>  >
>  > Issue 154 - doc/lit & multiple body parts
>  >
>  > Proposal: Put in an implementer's note on the problem of multi-part
>  > messages defined using complexTypes that are encoded using doc/lit
>  >
>  > Rationale: It is possible to create message definitions using
doc/lit
>  > and complex types where it is impossible to decompose the messages
into
>  > parts. But this problem doesn't exist with rpc/encoded, just with
>  > doc/lit. Since BPEL doesn't operate at that level we can't
officially
>  > ban the practice. But we can at least warn people.
>  >
>  > 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..."
>  >
>  > WS-BPEL only operates at the WSDL portType layer and so
intentionally
>  > does not address WSDL binding issues. But there is one particular
WSDL
>  > binding issue that implementers should be aware of. If a WSDL
message
is
>  > defined with multiple parts at least one of which is defined using
a
>  > complex type and the resulting message is bound using doc/lit then
it
is
>  > at least theoretically possible to create a situation where it is
>  > impossible to determine for a message instance where one part of
the
>  > message ends and another begins. WS-BPEL only requires that
messages
be
>  > broken into their required parts, it does not specify how,
therefore
>  > this issue is out of scope for WS-BPEL. But in general it is
recommended
>  > that implementations reject message definitions where this
ambiguity
>  > exists. Note that WS-I's Basic Profile explicitly forbids WSDL
messages
>  > constructed as described above.
>  >
>  > 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 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 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 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]