RE: [wsbpel] Issue - 87 - Proposal for Vote

[Frank Leymann <LEY1@de.ibm.com>]

+1 on any binding specifics being out of scope of BPEL

Regards,
Frank






To:    <ygoland@bea.com>, "wsbpeltc" <wsbpel@lists.oasis-open.org>
cc:
Subject:    RE: [wsbpel] Issue - 87 - Proposal for Vote


Yaron,

I am not aware of any binding dependency we have put into BPEL so far
and I am not sure about the interop and portability stories around this
proposal to add such a semantic dependency, unless the intention is to
go far deeper into defining rules relative to specific bindings, which
in my view would almost certainly end up being out-of-scope.

Satish

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Wednesday, September 15, 2004 6:14 PM
To: wsbpeltc
Subject: [wsbpel] Issue - 87 - Proposal for Vote

14.9 Application Data

Application data is data transmitted in a message outside of the normal
message channel, specifically data in a message that is not bound to a
WSDL message part.

To enable BPEL processes to access application data the from-spec is
extended to include:

<from appDataForMessage="ncname"/>

The value of the appDataForMessage attribute MUST be the name of a WSDL
message type variable. The output of this from-spec will always follow
the schema:

<element name="applicationData" type="bpws:tApplicationData">

<complexType name="tApplicationData">
    <sequence>
       <any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    <anyAttribute processContents="lax"/>
</complexType>

The application data will be recorded inside of the applicationData XML
element.

To enable BPEL processes to set application data the to-spec is extended

to include:

<to appDataForMessage="ncname"/>

The schema of the data assigned using this to-spec MUST follow the
previously defined schema or a bpws:mismatchedAssignmentFailure MUST be
thrown.

When a message is received by the BPEL process any application data
associated with the message MUST be made available via the application
data from-spec. The exact means by which application data is retrieved
from a message is binding specific and the binding definition has final
say as to what data will appear as application data but in general any
parts of the incoming message that do not have bindings to specific WSDL

message parts are considered application data. Similarly when a message
is sent if any application data has been associated with the message
then the application data MUST be sent with the outgoing message using
the rules defined for the particular binding in use.

In the specific case of a message received via a SOAP based binding the
applicationData value associated with the received BPEL WSDL message
type variable MUST contain any SOAP headers that do not have bindings to

message parts in the WSDL used to receive the message. Each SOAP header
not otherwise bound to a WSDL message part MUST be copied into the
application data structure in the relative document order the headers
appeared in the SOAP message.

Similarly if a message is sent via a SOAP based binding then any values
in the applicationData MUST be copied into the SOAP message's header
block in document order. The exact place where the headers will be
inserted into the header block is application specific but SHOULD
generally be after the SOAP headers defined via a binding in the
outgoing message's WSDL message definition.

Any application data associated with a WSDL message type variable is
replaced with application data from the incoming message, if any,
whenever that variable is used to receive a new message.

Schema Changes:

Add to tFrom:

<attribute name="appDataForMessage" type="NCName"/>

Add to to:

<attribute name="appDataForMessage" type="NCName"/>

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