OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Issue - 87 - Language tweaking


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: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]