To simplify the scenario lets imagine that messages A and B contain
exactly one part.
For the scenario you describe to be possible then message B's syntax
MUST be legal under the message A definition. If it wasn't then the
incoming message would be rejected by schema validation.
The only way then that message B could be different than message A and
still be legal under message A's definition is if message A contains
extension points (e.g. xs:any). But any data in those extension points
would be available to the BPEL.
So I don't see how the scenario you describe would, in practice, ever
result in the BPEL not having access to the data, independent of issue 87.
Thanks,
Yaron
Ugo Corda wrote:
>
>
> 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:]
> > 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:]
> > > > 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.
> > >
> >
>
