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

["Ugo Corda" <UCorda@SeeBeyond.com>]

In the case I mentioned below, data IS bound to a WSDL message part, but
the WSDL message itself is not part of the portType definition used by
BPEL for the corresponding activity. 
For example in WSDL:

message A
message B
portType P
    operation
        input message A

but the message sent to the receive on portType P includes, besides data
from message A, data defined as a part in message B. Right now BPEL can
only see data defined in message A, because message B is not part of
portType P.

So it's a different situation than what you mention, but it should, in
my view, be treated the same way.

I would just rephrase your statement as:

"specifically data in a message that is not bound to a WSDL message part
included in the corresponding portType"

Ugo

> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com] 
> Sent: Friday, September 17, 2004 9:40 AM
> To: Ugo Corda
> Cc: wsbpeltc
> Subject: Re: [wsbpel] Issue - 87 - Proposal for Vote
> 
> 
> 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.
> > 
>