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





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