[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Issue - 87 - Language tweaking
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:ygoland@bea.com]
> 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:ygoland@bea.com]
> > > 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: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.
> > > > > >
> > > > >
> > > >
> > >
> >
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]