- From: Amelia A Lewis <alewis@tibco.com>
- Date: Mon, 7 Feb 2005 14:24:46 -0500
- To: "Liu, Kevin" <kevin.liu@sap.com>
- Cc: www-ws-desc@w3.org, public-ws-async-tf@w3.org
On Mon, 7 Feb 2005 19:42:43 +0100 "Liu, Kevin" <kevin.liu@sap.com> wrote: [several detailed proposals] I'm going to make an alternative suggestion. Parameters: must not require changes to interface, should avoid making deep changes to WSDL, must permit multi-protocol message exchanges. Proposal: Add to the binding or operation a feature^Wcharacteristic: "uses-addressing". This characteristic may be [absent], [required], or [optional]. It has properties: each property represents one supported protocol binding. This characteristic may appear per-operation, or it may apply to the binding as a whole, in which case it applies to each operation (unless overridden within the operation). There are two cases: service-initiated operations and externally-initiated operations (output-first and input-first). Single-message exchanges are not interesting, since we're not doing choreography. For multi-message, or potentially multi-message exchanges, the two cases look like this: 1) output-first: there is no significance to the "required/optional" attribute. The service will include an address/endpoint reference, one for each protocol for which it advertises support (using WS-Addressing). The output message recipient may reply to any one (only one) of these addresses. 2) input-first, optional: the operation initiator MAY include an address/endpoint compatible with one of the protocols advertised. The service will respond using this (single) endpoint/address. If no address/endpoint is included, the service will use the default response address for the protocol binding in use. 3) input-first, required: the operation initiator MUST include an address/endpoint compatible with one of the protocols advertised. The service will respond using this (single) endpoint/address. For exchange patterns containing more than two messages, required/optional semantics continue: additional messages from the service will contain a list of endpoints; additional messages to the service will contain a single endpoint. EXCEPT: the final message in an exchange need not contain any endpoint references/addresses, unless the pattern specifies that faults may be propagated in response to the message. This can be done easily enough with a WS-Addressing Feature containing supported-protocol properties. Amy! -- Amelia A. Lewis Senior Architect TIBCO/Extensibility, Inc. alewis@tibco.com
Received on Monday, 7 February 2005 19:25:10 UTC