Yup, that explained it! Thank you for providing the example.
I think the proposed change will fix the problem -
Original Language in Proposal: 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.
New Language: 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 referenced in the portType/operation
definition that applies to the sent or received message.
What do you think?
Yaron
Ugo Corda wrote:
>
>
> Here is a complete example:
>
> <message name="In">
> <part name="InPart" element="InElement"/>
> </message>
>
> <message name="Header">
> <part name="HeaderPart" element="HeaderElement"/>
> </message>
>
> <portType name="myPortType">
> <operation name="op1">
> <input message="In"/>
> </operation>
> </portType>
>
> <binding type="myPortType" ... >
> <soap:binding ..../>
> <operation name="op1">
> <input>
> <soap:body parts="InPart" ...>
> <soap:header message="Header" part="HeaderPart" .../>
> </input>
> </operation>
> </binding>
>
> As you can see, the actual message being sent, as described in the
> binding, includes the part HeaderPart, which is currently not accessible
> to BPEL because it is declared outside myPortType.
> I think this case is pretty similar to what you address in your proposal
> as Application Data, i.e. "data transmitted in a message outside of the
> normal message channel".
>
> Ugo
>
> > -----Original Message-----
> > From: Yaron Y. Goland [mailto:]
> > Sent: Friday, September 17, 2004 3:10 PM
> > To: Ugo Corda
> > Cc: wsbpeltc
> > Subject: Issue - 87 - Language tweaking
> >
> >
> > I'm sorry Ugo, I honestly don't understand. Can you please provide a
> > portType, a sample SOAP message, a BPEL variable and an
> > explanation for
> > how the data gets lost between the SOAP message, the portType and the
> > BPEL variable?
> >
> > Sorry to be so thick but I just don't get it.
> >
> > Yaron
> >
> > Ugo Corda wrote:
> > >
> > >
> > > The case I have in mind is the SOAP binding where the part from
> > > message B is transmitted via a SOAP header (and schema
> > validation for
> > > that header would be performed based on message B, not message A).
> > >
> > > Again, see WSDL 1.1, sec. 3.7, where it says "the
> > referenced message
> > > need not be the same as the message that defines the SOAP body".
> > >
> > > Ugo
> > >
> > > > -----Original Message-----
> > > > From: Yaron Y. Goland [mailto:]
> > > > Sent: Friday, September 17, 2004 2:36 PM
> > > > To: Ugo Corda
> > > > Cc: wsbpeltc
> > > > Subject: Re: [wsbpel] Issue - 87 - Proposal for Vote
> > > >
> > > >
> > > > 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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
