RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


JAX-RPC Evolves into Simpler, More Powerful JAX-WS 2.0 : Page 3

The new Java Architecture for XML Web Services (JAX-WS) will replace JAX-RPC in the upcoming Java EE 5 and Java 6 (codename: Mustang). Learn all about JAX-WS 2.0 and see how to use it to transform a Java class into a Web service.


The Development Process

To JAX-WS, the development process is a somewhat simplified version of WS development using RPC. Unlike with the JAX-RPC of old, you can use JAX-WS to transform almost any existing Java class into a Web service. The class doesn't need to implement an interface and its methods do not need to declare RMI exceptions. The method, however, does require JAXB 2.0-compatible parameters and return values. Simply add the @WebService annotation to the .java file, add some cookie cutter configuration files, and run an Ant script. Figure 3 diagrams the basic process for the Web service.

Click to enlarge
Figure 3. The Development Process for the Web Service

Notice in Figure 3 that SimpleMethod.java and SimpleMethodResopnse.java are the JavaBeans responsible for marshaling/unmarshaling the invocation and response. Notice also that the developer inputs only three files; the remaining components are generated by apt and the servlet container. The servlet container generates the WSDL and schema at the time of deployment, which is a change from JAX-RPC. These files are therefore not bundled in the WAR.

SimpleJAXWS.java (see Listing 1) is the same as a non-Web service class definition except for the @WebService annotation:

public class SimpleJAXWS { 
public int simpleMethod(int number1, int number2) throws SimpleException { 
if ( number2 == 0 ) {
throw new SimpleException("Cannot divide by zero!",
"Numbers: " + number1 + ", " + number2); 
return number1 / number2; 

The sun-jaxws.xml file (see Listing 2) designates the URL for the service endpoint implementation:


The web.xml (see Listing 3) file assigns the WSServlet to the Web service's URL:


The URL http://localhost:8080/jaxws-simpleexample/simplemethod?wsdl shows the definition for the simpleMethod message:

<definitions targetNamespace="http://server.simpleexample/" name="SimpleJAXWSService">
<message name="simpleMethod">
<part element="tns:simpleMethod" name="parameters"/> 

The URL http://localhost:8080/jaxws-simpleexample/simplemethod?xsd=1 shows the simple method and it's parameters:

<xs:element type="ns1:simpleMethod" name="simpleMethod"/> 
<xs:complexType name="simpleMethod">
<xs:element type="xs:int" name="arg0"/>
<xs:element type="xs:int" name="arg1"/> 

Figure 4 diagrams the basic development process on the client side.

Click to enlarge
Figure 4. The Development Process for the Client

Notice in Figure 4 that the developer inputs only three files; the remaining components are generated by wsimport. The other files required by wsimport are the WSDL and schema generated by the servlet container at time of deployment. This is why it's important to wait for Tomcat to completely deploy the Web service before building the client.

The wsimport-generated files can be found in the build/classes/simpleexample/client directory of the example's home. SimpleMethod.java and SimpleMethodResopnse.java are the JavaBeans that marshal/unmarshal the invocation and response. Because package-level annotations are declared in their own .java file, @XMLSchema is found in package-info.java. The annotation maps the client package name to an XML namespace. ObjectFactory.java uses the class-level annotation @XMLRegistry to indicate it will be an XML registry with the factory methods for the client's JavaBeans and their XML equivalents. Other JavaBeans not shown in Figure 4 are generated for handling the exception used by the service.

SimpleMethodClient.java (Listing 4) has a main method that instantiates the SimpleJAXWS Web service object and calls its method. The SimpleJAXWS object is treated the same as a non-webservice object once it has been instantiated:

SimpleJAXWS port = new SimpleJAXWSService().getSimpleJAXWSPort(); 
double result = port.simpleMethod ( 20, 10 );

The build.properties file (Listing 5) designates the SEI and client class, the client's bindings for its WSDL and schema:

# service endpoint implementation class

# customization files
client.binding=custom-client.xml, custom-schema.xml


The custom-client.xml file (Listing 6) binds the package to the WSDL:

<bindings wsdlLocation="http://localhost:8080/jaxws-simpleexample/simplemethod?wsdl"> 
<bindings node="wsdl:definitions">
<package name="simpleexample.client"/>

The custom-schema.xml file (Listing 7) binds the package to the schema:

<bindings schemaLocation="http://localhost:8080/jaxws-simpleexample/simplemethod?xsd=1 " 
node="/xsd:schema"> <schemaBindings> <package name="simpleexample.client"/> </schemaBindings> </bindings>

Of course, much of this code can be generated by a development tool very simply. As the next section demonstrates, coding all these cookie cutter files by hand can be tedious. As with most JSRs, JAX-WS was designed by Java tool vendors for Java tool vendors. What JAX-WS really does is provide the framework by which the developer's tool of choice can provide one-click generation of a Web service and client skeleton.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date