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

["Yaron Y. Goland" <ygoland@bea.com>]

I'm not sure I follow. Isn't that exactly what the proposal specifies? 
"..specifically data in a message that is not bound to a WSDL message part."

I'm not disagreeing with you. I'm just wondering how I can make the 
language any clearer. Suggestions welcome.

	Thanks,

		Yaron

Ugo Corda wrote:
> 
> 
> As a friendly amendment, I suggest to extend this capability to data in
> a message that are bound to a part that does not belong to the portType
> over which the message is exchanged. This case is explicitly allowed for
> SOAP bindings by WSDL 1.1 (see sec. 3.7, "the referenced message need
> not be the same as the message that defines the SOAP body"), yet this
> information is currently not available to BPEL.
> 
> Ugo
> 
>  > -----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/le
> ave_workgroup.php.
>