WSIF - Web services are more than just SOAP services
You 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 J2EE environment, then the application is available over multiple transports and protocols.
For example, you 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 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, 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.
See Also
Goals of WSIF
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