WSIF - Multiple bindings can be used in flexible ways

Imagine that you have successfully deployed an application that uses a Web service which offers multiple bindings. For example, imagine that you have a SOAP binding for the service and a local Java binding that lets you treat the local service implementation (a Java class) as a Web service.

The local Java binding for the service can only be used if the client is deployed in the same environment as the service. In this case, it is more efficient to communicate with the service by making direct Java calls than by using the SOAP binding.

If your clients could switch the actual binding used based on run-time information, they could choose the most efficient available binding for each situation. To take advantage of Web services that offer multiple bindings, you need a service invocation mechanism that can switch between the available service bindings at run-time, without having to generate or recompile a stub.

 

See Also

Goals of WSIF
WSIF - Web services are more than just SOAP services
WSIF - Tying client code to a particular protocol implementation is restricting
WSIF - Incorporating new bindings into client code is hard
WSIF - Enabling a freer Web services environment promotes intermediaries

 

---