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

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

In the spirit of 10 and 103 why don't we split the proposal into two 
votes. One on the generic mechanism and another on the binding issue?

	Yaron

Frank Leymann wrote:
> 
> 
> 
> 
> +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 
> 
> .
> 
> 
> 
> 
> 
> 
> 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. 
> 
>