WSIF - 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 you are using the Java 2 platform, Enterprise Edition (J2EE) environment, then the application is available over multiple transports and protocols.
For example, one 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 you can add binding extensions to the WSDL so that, for example, one can offer an enterprise bean as a Web service using 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.
See Also
WSIF - Tying client code to a particular protocol implementation is restricting
WSIF - Incorporating new bindings into client code is hard
WSIF - Multiple bindings can be used in flexible ways
WSIF - Enabling a freer Web services environment promotes intermediaries