Goals of WSIF
WSIF aims to extend the flexibility provided by SOAP services into a general model for invoking web services, irrespective of the underlying binding or access protocols.
SOAP bindings for web services are part of the Web Services Description Language (WSDL) specification, therefore 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 a SOAP client API. For example: using Apache SOAP the client creates and populates a Call object that encapsulates the service endpoint, the identification of the SOAP operation to invoke, the parameters to send, and so on.
Although this process works for SOAP, it is limited in its use as a general model for invoking web services for the following reasons:
- Web services are more than just SOAP services.
- Tying client code to a particular protocol implementation is restricting.
- Incorporating new bindings into client code is hard.
- Multiple bindings can be used in flexible ways.
- A freer web services environment enables intermediaries.
The goals of the Web Services Invocation Framework (WSIF) are therefore:
- To give a binding-independent mechanism for web service invocation.
- To free client code from the complexities of any particular protocol used to access a web service.
- To enable dynamic selection between multiple bindings to a Web service.
- To help the development of web service intermediaries.
Web services are more than just SOAP services
We can deploy as a web service any application that has a WSDL-based description of its functional aspects and access protocols. If we are using the Java EE environment, then the application is available over multiple transports and protocols.
For example, we can take a database-stored procedure, expose it as a stateless session bean, then deploy it into a SOAP router as a SOAP service. At each stage, the fundamental service is the same. All that changes is the access mechanism: from Java DataBase Connectivity (JDBC) to Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) and then to SOAP.
The WSDL specification defines a SOAP binding for web services, but we can add binding extensions to the WSDL so that, for example, we can offer an enterprise bean as a web service that uses RMI-IIOP as the access protocol. We 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, we need a binding-independent mechanism for service invocation.
Tying client code to a particular protocol implementation is restricting
If our 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 Java Message Service (JMS) or enterprise bean, the process can take a lot of time and effort. To avoid these problems, we need a protocol implementation-independent mechanism for service invocation.
Incorporating new bindings into client code is hard
To make an application that uses a custom protocol work as a web service, we can add extensibility elements to WSDL to define the new bindings. But achieving this capability is complex.
For example we must design the client APIs to use this protocol. If the application uses just the abstract interface of the web service, write tools to generate the stubs that enable an abstraction layer. These tasks can take a lot of time and effort. What we need is a service invocation mechanism that we can use to update existing bindings, and to add new bindings.
Multiple bindings can be used in flexible ways
To take advantage of web services that offer multiple bindings, we need a service invocation mechanism that can switch between the available service bindings at run time, without having to generate or recompile a stub.
Imagine that we have successfully deployed an application that uses a web service that offers multiple bindings. For example, imagine that we 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 using the SOAP binding.
If our clients can switch the binding used based on runtime information, they can choose the most efficient available binding for each situation.
A freer web services environment enables intermediaries
Web services offer application integrators a loosely-coupled paradigm. In such environments, intermediaries can be very powerful.
Intermediaries are applications that intercept the messages that flow between a service requester and a target web service, and undertake some mediating task (for example logging, high-availability or transformation) before passing on the message. The Web Services Invocation Framework (WSIF) is designed to make building intermediaries both possible and simple. Using WSIF, intermediaries can add value to the service invocation without needing transport-specific programming.
Related:
WSIF Overview WSIF and WSDL Use WSIF to invoke web services Invoking a WSDL-based web service through the WSIF API