Section 10.16. Web Services Client

10.16. Web Services Client

We viewed the Web Service's WSDL, so we know that it deployed properly. However, now we need to make sure that the Web Service really works. So, we're going to add an external client application that tests the Web Service. Running a client against our Web Service will flush out any Web Service-related issues like custom data type serialization/de-serialization errors (caused by using data types that aren't compatible with XML Schema data types).

For our client, we'll use a well-known API for invoking the Inventory Web Service methods. Here are some of our choices:

JNDI

We could add <service-ref> elements to our EJB and client deployment descriptors so an external client could use a JNDI name like java:comp/env/service/Inventory to look up our service endpoint and invoke its methods.

JAX-RPC

We could use JAX-RPC calls that look up the service by using its port name from the WSDL, and then specify serializers/deserializers to handle the custom data types.

Apache Axis

We could download the WSDL from http://localhost:8080/jbossatwork-ws/InventoryService?wsdl and use the Apache Axis toolkit to generate proxy and custom data type objects that communicate with the Web Service.

Perl, Python, C#

Clients could have been written in any language that supports Web Services, but since this is a Java book, we decided to stick with Java.

JNDI and JAX-RPC are too Java/J2EE-centric, so these approaches don't provide a good test for the interoperability of our Web Service. Besides, the main reason for using Web Services is to enable clients to seamlessly use a service, regardless of the programming language used on either side. We chose Axis because:

• Axis code generation is based on WSDL, making it platform-neutral.

• The generated proxy and custom data type objects make it much easier to write the client.

Our client is written in Java, but non-Java clients written in other languages like C# could also take our WSDL, generate a proxy using their own language-specific tools, and use our Web Service. WSDL completely decouples a Web Service from its clients because:

• Each client generates a proxy and any associated custom data types from the WSDL into its native language.

• There are no language- or platform-specific dependencies between a Web Service and its clients.

Before we develop a Web Service client, let's explore the new directory structure we'll use for our Web Service client development environment.

10.16.1. Exploring the New Directory Structure

In previous chapters, we had subdirectories for building the Common JAR (common), the database (sql), the web application (webapp), and EJBs (ejb).

If you change to the ch10 directory, you'll see that we've added a client sub-directorythis is our Web Service client development environment. The goal is to keep each portion of the application as autonomous as possible. By providing individual Ant scripts, we have the opportunity to build each portion of the project separately.

10.16.1.1. The client sub-project

Take a moment to explore the client sub-project. There is a single class in itMyAxisClient. Notice that we've created a new package structure for our client codecom.jbossatwork.client.

The Ant build script in the client sub-directory generates Web Service proxy code, compiles the MyAxisClient class, and invokes the MyAxisClient's main( ) method to run the client. Don't run the Ant script just yetwe'll show how the Web Service client build works in the next section. The main build.xml script in the ch10 directory doesn't require any changes because the Web Service and the client are two separate builds.

Now that we've shown the Web Service client development environment, let's implement the client.