[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]