WSIF stands for the Web Services Invocation Framework. It supports a simple Java API for invoking Web services, no matter how or where the services are provided. The framework allows maximum flexibility for the invocation of any WSDL-described service.
In the WSDL specification, Web service binding descriptions are extensions to the specification. So the SOAP binding, for example, is one way to expose the abstract functionality (and there could be others). Since WSIF mirrors WSDL very closely, it also views SOAP as just one of several ways you might wish to expose your software's functionality. WSDL thus becomes a normalized description of software, and WSIF is the natural client programming model.
The WSIF API allows clients to invoke services focusing on the abstract service description - the portion of WSDL that covers the port types, operations and message exchanges without referring to real protocols. The abstract invocations work because they are backed up by protocol-specific pieces of code called providers. A provider is what conducts the actual message exchanges according to the specifics of a particular protocol - for example, the SOAP provider that is packaged with WSIF uses a specific SOAP engine like Axis to do the real work.
The decoupling of the abstract invocation from the real provider that does the work results in a flexible programming model that allows dynamic invocation, late binding, clients being unaware of large scale changes to services - such as service migration, change of protocols, etc. WSIF also allows new providers to be registered dynamically, so you could enhance your client's capability without ever having to recompile its code or redeploy it.
Using WSIF, WSDL can become the centerpiece of an integration framework for accessing software running on diverse platforms and using widely varying protocols. The only precondition is that you need to describe your software using WSDL, and include in its description a binding that your client's WSIF framework has a provider for. WSIF defines and comes packaged with providers for local java, EJB, JMS, and JCA protocols. That means you can define an EJB or a JMS-accessible service directly as a WSDL binding and access it transparently using WSIF, using the same API you would for a SOAP service or even a local java class.
TODO: Put a picture showing WSIF client with pluggable providers to access service using different protocols.
Quick start: If you have downloaded binary package then you are ready to use WSIF: the very first thing to do is to check provided samples. However before you start please read WSIF FAQ. Then read about how to run the samples. Otherwise if you downloaded source code or accessed it from CVS you will need to build WSIF. First check that all prerequisites are available. Then proceed with building.
After you have successfully downloaded and installed WSIF, you can test your installation by running the samples. If you are able to run all the samples successfully you should have a very good idea of what you can do with WSIF. Essentially once you have a WSDL file with a binding that WSIF understands (such as SOAP, EJB, Java, JMS, JCA, etc.) you can write a client that uses WSIF's APIs - the dynamic invocation API or the stub-based invocation - to use this service.
Traditionally, the burden of dealing with new protocols has been a carried by the server-side. Software has to morph itself (through the addition of wrappers) to look like something the client expects to see. With WSIF, the software remains exactly the same - we just get the client to use WSIF's binding independent API, and through the addition of providers, we can mix and match protocols as we please.
Service is a very liberal term for WSIF! Anything that can be described in WSDL qualifies as a service and is something you can access using the WSIF API. Moreover, since WSDL is extensible, potentially everything can be described using WSDL. The next section describes how you can define your own bindings and write your own WSIF providers.
This part of documentation is meant to help developers who want to modify WSIF by adding or changing its providers and implementing new protocols.
There are many points within the WSIF API that allow for customization. An advanced WSIF sample demonstrates how to write your own WSIF service factory so that dynamic binding selection follows your own customized algorithm. The user can discover other customization points by examining WSIF's core API.
Larger scale customization involves finding ways to expose software that uses your proprietary protocols through WSDL, so that you can then access this software using WSIF's APIs. To do this, you need to take care of the following:
You may find also useful read WSIF documentation is with descriptions of the WSIF Java and EJB bindings.
You may find also useful to read about using Soap
Attachments using WSIF and always important when debugging on
how to use tracing in WSIF.
More documentation is available in doc/ subdirectory and includes:
WSIF shares the Apache AXIS mailing lists axis-user and axis-dev. To aid identifying posts about WSIF, the prefix [wsif] should be added to each posts subject line.
You can contribute to WSIF by participating in discussions on the axis-user and axis-dev mailing lists. Be sure to prefix the subject of your WSIF-related emails with [wsif]. If you find something that outstanding issue or bug that interests you, feel free to download WSIF's source code and work on it. Below you will find instructions for accessing the source code.
You can find a list of outstanding bugs from Bugzilla.