[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 87 - Proposal for Vote - Part 1
Yaron, There is the problem of several headers (or "application data" units as you call them) being typed by the same WSDL message type. I don't recall any limitation as to the uniqueness of the message type used to type a header. Since WSDL does not let you identify a "message type instance" except when used for input and output of the WSDL operation the problem you try to address seems inherently ambiguous to me. Moreover, I don't think there is an easy solution to this problem that does not involve fixing WSDL 1.1 in one way or another. While I understand (but not share, as we have discussed in the past) your concern for bringing this issue up, I am very uneasy about using BPEL to make up for the shortcomings of other specifications. Paco "Yaron Y. Goland" <ygoland@bea.com> To: wsbpeltc <wsbpel@lists.oasis-open.org> cc: 09/28/2004 02:35 Subject: [wsbpel] Issue - 87 - Proposal for Vote - Part 1 PM Please respond to ygoland The original proposal for vote contained two parts, one that defined the generic mechanism and another that specified language for specific bindings. In order to allow us to make forward progress I am removing the section on specific bindings for this vote and instead just focusing on the mechanism. This vote will not close issue 87 as, if it is passed, we will still need to decide if we wish to address any binding specific issues. 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 referenced in the portType/operation definition that applies to the sent or received message. 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. 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/leave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]