Using XFire as a Client for WebSphere Application Server

XFire has great easy-to-use client API,
which makes it an ideal candidate for developing unit tests for Web services.
The best part is that it can interoperate with Web services implemented in other
containers and application servers. I recently started using it with IBM WebSphere Application Server (WAS) 6.1.

So what are the benefits of using XFire as opposed to a “native” Web services client
created using tools provided with your application server?

• Many application servers/Web service containers use code generation to
  generate a client’s “proxy”. You have to remember to re-gen the client
  every time you change interface of your service.
• Code generation has a number of issues. For example, a client generator
  will generate Java classes for parameters of a Web service. Oftentimes,
  it is desirable to use an existing class instead, so then the generated code must
  be changed.
• Using “native” client does not test interoperability. When client and server
  are implemented using the same product, interoperability is almost guaranteed.
  Using a different client library potentially allows you to discover
  interoperability problems early on.
• Finally, since XFire is open source, it can be packaged and distributed to
  customers and partners without requiring a license.

Invoking a Web service running in WebSphere does not require anything special:

public void testHelloService() throws Exception {
    
    Service serviceModel = new ObjectServiceFactory()
        .create(HelloService_SEI.class);
    XFireProxyFactory serviceFactory = new XFireProxyFactory();
    HelloService_SEI service = (HelloService_SEI) serviceFactory
        .create( serviceModel, 
        "http://localhost:9090/helloWS/services/HelloService");
    
    Person person = new Person();
    person.setFirstName("John");
    person.setLastName("Doe");
    String s = service.helloPerson(person); 
    assertEquals("Hello John Doe", s);
}

It must be noted though that I have not tried using any advanced features. It
would be interesting to see if, for example, XFire WS-Addressing implementation can
interoperate with WAS.

By the way, if you’re only going to use XFire client, you only a need few jars from
its distribution. Here is the list that I use (it could probably be trimmed down even more):

activation-1.1.jar
commons-codec-1.3.jar
commons-httpclient-3.0.jar
jdom-1.0.jar
jsr173_api-1.0.jar
mail-1.4.jar
saaj-api-1.3.jar
saaj-impl-1.3.jar
stax-api-1.0.1.jar
stax-utils-20040917.jar
wsdl4j-1.5.2.jar
wss4j-1.5.0.jar
wstx-asl-2.9.3.jar
xbean-2.1.0.jar
xfire-all-1.2.jar

Also, from my expreience SAAJ API only works with Sun JDK as opposed to JDKs provided by IBM as part of Rational development tools.