This samples will not work; it needs a code change to WSIFServiceFactory; once that is done this sample will work as described. This note will be removed once the code change has been made.
This sample aims to demonstrate a simple customization of WSIF. One of the central pieces of code in the WSIF runtime is the WSIFService. This interface is responsible for (amongst other things) returning the instance of the WSIFPort object that will be used for invocation, through one of the available getPort methods. WSIFService objects themselves are created using a factory, the WSIFServiceFactory. This is an abstract factory whose implementation we can customise.
This sample employs a customised service factory, which behaves no different from the default service factory other than the fact that it returns a customised implementation of the WSIFService interface. This customised service implementation differs from the default one that comes with WSIF in one respect only. The getPort() method has been changed to return a port that uses a java binding, if there is one, in preference to any other port. The rationale is that if the same service is available as a local java binding, it's probably a lot faster to use that than to attempt to make a SOAP invocation, use an EJB, etc. Of course this is very simplistic, but the sample demonstrates how you can use your own customised algorithm for choosing between bindings at runtime. All you need to do is add the following line to your wsif.properties file:
wsif.servicefactory=customfactory.client.CustomServiceFactoryImpl
You can change the class name to point to your customised factory if you like, or just omit this property for the default factory to be used.
The service used to demonstrate the flexibility is the familiar stock quote example. The WSDL in this directory offers two bindings: a SOAP binding and a java binding. Through the use of trace you will be able to detect which binding is actually used. You will see that when the custom factory is used, the java binding is always picked. Try removing the custom factory by commenting out the wsif.servicefactory property from your wsif.properties file. Now the default factory will be used; its algorithm for picking a suitable port/binding is very simple: it just picks the first one. So now when you run your clients you may see the SOAP binding being picked (the actual one picked is the first port in the list of ports, and since the list is not ordered it is impossible to predict exactly which one it will be, but if it happens to be the java port, it isn't because the default service implementation did that purposefully, it just happened to be first on the list!).
The WSDL file is in this sample directory.
The SOAP implementation is hosted by the good folks at XMethods. The service URL, where you can find details on the service implementation, etc. is here.
Here's how the local java class that implements the service functionality.
Here's how to invoke this service dynamically using WSIF's dynamic invocation interface (DII).
Here's how to invoke this service by first generating the stub interface and using this directly through WSIF's dynamic proxy, thus hiding all WSIF specifics from the client code. Note that the stub interface used is the the service interface as defined by the JAX-RPC specification.
Here's the customised factory implementation that create our customised service, and here's the customised service class. Note the implementation of the getPort() method in the latter class.