SOAP bindings for Web services are part of the WSDL specification. When most developers think of using a Web service, they immediately think of assembling a SOAP message and sending it across the network to the service endpoint, using some SOAP client API. For example: with Apache SOAP the client creates and populates a Call object which encapsulates the service endpoint, the identification of the SOAP operation to be invoked, the parameters that have to be sent, and so on.
Although this works for SOAP, it is limited in its use as a general model for invoking Web services for these reasons:
You can deploy as a Web service any program with a WSDL description of its functional aspects and access protocols; and in the J2EE environment, the same component is available over multiple transports and protocols.
For example, you can have a database stored procedure, which is then exposed as a stateless session bean, and then deployed into a SOAP router to become a SOAP service. At each stage, the fundamental service is the same. All that changes is the access mechanism: from JDBC to RMI-IIOP and then to SOAP.
The WSDL specification defines a SOAP binding for Web services, but you can add binding extensions to the WSDL so that, for example, you can offer an enterprise bean as a Web service using RMI/IIOP as the access protocol. You can even treat a single Java class as a Web service, with in-thread Java method invocations as the access protocol. With this broader definition of a Web service, you need a binding-independent mechanism for service invocation.
If your client code is tightly bound to a client library for a particular protocol implementation, it can become hard to maintain. For example if you move from Apache SOAP to a different SOAP implementation, the process can take a lot of time and effort. To avoid these problems, you need a protocol implementation-independent mechanism for service invocation.
If you want to make an application that uses a custom protocol work as a Web service, you can add extensibility elements to WSDL to define the new bindings. But in practice, achieving this is hard. For example you have to design the client APIs for using this protocol; and if your application uses just the abstract interface of the Web service, you have to write tools to generate the stubs that enable an abstraction layer. These are tasks that can take a lot of time and effort. What you need is a service invocation mechanism that allows bindings to be updated or new bindings to be plugged in easily.
Imagine that you have successfully deployed an application that uses a Web service offering multiple bindings. For example, imagine that you have a SOAP binding for the service and a local Java binding that lets you to 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 itself, and if this is the case it is far more efficient to communicate with the service by making direct Java calls than 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. In order to take advantage of Web services that offer multiple bindings, you need a service invocation mechanism that allows you to switch between the available service bindings at runtime, without having to generate or recompile a stub.
Web services offer application integrators a loosely-coupled paradigm. In such environments, intermediaries can be very powerful. Intermediaries can add value to the service invocation without specific programming. Facilities such as logging, high-availability and transformation can be provided by a intermediary. WSIF is designed to make building intermediaries both possible and simple.
The goals of WSIF are therefore: