[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Issue - 87 - Language tweaking
The new wording sounds good to me. Ugo > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Monday, September 27, 2004 10:13 AM > To: Ugo Corda > Cc: wsbpel@lists.oasis-open.org > 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]