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