Re: Web Services Description: Requirements

Jeff

I'd like to add the following requirements to the list.


1) A clearer separation of transport and binding in the spec. The current spec builds bindings that are tied to the transport, and therefore a hard link between the port and binding information. There are obviously cases where formatting information is specific to the transport, so it would be good to see the ability to define multiple bindings and to define bindings that are independent of transport, and also perhaps independent of the exact porttype. So an example would be --- define a porttype, then a binding for "soap-encoded rpc style", then a binding for SOAP/HTTP, then a port for HTTP, which points to both bindings. 

2) Context. WebServices requests often have an associated context --- such as the identity of the caller. This context has a logical component - typically a set of name-value pairs - and a binding into the particular format or transport. So for example, a userid and password may be bound into the HTTP transport using Basic Auth, or may be encoded in the SOAP header, and the Service implementation may be expecting that. Furthermore, there are some context items that the service may require, and there are others that are not required but may be understood. It is also possible that there are context items that are not required or understood, but the service may have a policy of passing on non-understood context items to other service it calls, or returning them to the client --- which may use them for correlation. 

3) WSDL is typically used to capture the server requirements on the client. For example, the server will expect to see certain SOAP headers. When WSDL is used in higher protocols, such as an orchestration language, each side of the exchange may wish to publish their requirements, and the "client" may have a requirement on the "server". For example, the client may require the server to set a particular header on the response. In WSDL today, there is an option to try to map this into the "Out-In" or "Out" interactions, by treating them as the "conjugates" of the corresponding "In-Out" or "In-only" operations. However, this is unsatisfactory, as these interactions are not well defined, and there is no way to specify that an Out-In is actually the conjugate of an In-Out, or simply another operation that has the same messages in the opposite order. It would be more satisfactory if the concept of "conjugates" was exposed directly so that the "client" side of an interaction could publish their requirements. This could be used by proposal such as flow or orchestration languages.

Regards

Paul Fremantle
WebServices Architect 
IBM Hursley Lab