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.

This entry was posted on Saturday, September 9th, 2006 at 9:51 pm and is filed under Web services. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.