Developing a contract-first JAX-WS webservice

In this blog i’ll develop a simple webservice using JAX-WS. I’ll first start with the contract (wsdl and xsd’s). The contract will be used for generating the necessary JAXB artifacts. Getting the webservice up and running will be a piece of cake after that all thanks to Maven and JAX-WS.
First things first, let’s create a new Maven project. I’m using Netbeans as IDE for this.

New Maven Web Application

First Create a new Maven Web Application

and call it hello_person for example

The Contract

The webservice will accept a Person graph with a first and last name and will return a concatenated “Hello first name last name!”. Not very original but good enough for the example.
First we’ll define the xsd called helloPersonService.xsd for the request and response. The request will contain a Person object with a first and last name, the response will contain a Greetings string. We’ll store it in src/main/resources/xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd=""
    <xsd:element name="HelloPersonServiceRequest" type="HelloPersonServiceRequestType"/>
    <xsd:element name="HelloPersonServiceResponse" type="HelloPersonServiceResponseType"/>

    <xsd:complexType name="HelloPersonServiceRequestType">
        <xsd:element name="Person" type="PersonType"/>
    <xsd:complexType name="HelloPersonServiceResponseType">
        <xsd:element name="Greetings" type="xsd:string"/>

    <xsd:complexType name="PersonType">
            <xsd:element name="FirstName" type="xsd:string"/>
            <xsd:element name="LastName" type="xsd:string"/>

Now we’ll define a wsdl called helloPersonService.wsdl and we’ll store it in src/main/resources/wsdl

<?xml version="1.0" encoding="UTF-8"?>
        <xsd:schema targetNamespace="">
            <xsd:import schemaLocation="../xsd/helloPersonService.xsd"
    <wsdl:message name="HelloPersonServiceRequest">
        <wsdl:part name="HelloPersonServiceRequest" element="tns:HelloPersonServiceRequest"/>
    <wsdl:message name="HelloPersonServiceResponse">
        <wsdl:part name="HelloPersonServiceResponse" element="tns:HelloPersonServiceResponse"/>
    <wsdl:portType name="HelloPersonServicePortType">
        <wsdl:operation name="greetPerson">
            <wsdl:input name="HelloPersonServiceRequest" message="tns:HelloPersonServiceRequest"/>
            <wsdl:output name="HelloPersonServiceResponse" message="tns:HelloPersonServiceResponse"/>
    <wsdl:binding name="HelloPersonServiceBinding" type="tns:HelloPersonServicePortType">
        <soap:binding style="document" transport=""/>
        <wsdl:operation name="greetPerson">
            <soap:operation style="document" soapAction=""/>
            <wsdl:input name="HelloPersonServiceRequest">
                <soap:body use="literal"/>
            <wsdl:output name="HelloPersonServiceResponse">
                <soap:body use="literal"/>
    <wsdl:service name="HelloPersonService">
        <wsdl:port name="HelloPersonServicePort" binding="tns:HelloPersonServiceBinding">
            <soap:address location="/service/helloPersonService" />

Getting the pom right

Next up is adding the necessary component to the pom file. We need the jax-ws runtime libraries, the jetty plugin as we use jetty as the servlet container, and the jaxws-maven-plugin for generating the java code from the contract. I’ve highlighted these dependencies in the pom file below.

<project xmlns="" xmlns:xsi=""
    <name>hello_person Java EE 6 Webapp</name>
            <name>Repository hosting the jee6 artifacts</name>
            <name>Repository hosting the jee6 artifacts</name>





                        <connector implementation="org.eclipse.jetty.nio.SelectChannelConnector">



Writing the implementation

First, let’s do a Clean and Build in NetBeans. This will generate the JAXB/JAX-WS artifacts from the contract.
Notice that the jaxws-maven-plugin has generated an interface called nl.example.hello_person.service.generated.HelloPersonServicePortType for the PortType in the wsdl. This is the interface we have to implement. The code for the implementation is pretty straightforward. I’ve added it below for convenience. Notice that the implementation class is called nl.example.hello_person.service.HelloPersonServiceImpl. We’ll need this in one of the next steps. Also notice the necessary @WebService annotation. The endpointInterface atribute points of course to the generated interface.

package nl.example.hello_person.service;

import javax.jws.WebService;
import nl.example.hello_person.service.generated.HelloPersonServiceRequestType;
import nl.example.hello_person.service.generated.HelloPersonServiceResponseType;

public class HelloPersonServiceImpl implements nl.example.hello_person.service.generated.HelloPersonServicePortType {

    public HelloPersonServiceResponseType greetPerson(HelloPersonServiceRequestType helloPersonServiceRequest) {
        HelloPersonServiceResponseType helloPersonServiceResponse = new HelloPersonServiceResponseType();
        helloPersonServiceResponse.setGreetings("Hello " + helloPersonServiceRequest.getPerson().getFirstName() + " " + helloPersonServiceRequest.getPerson().getLastName() + "!");
        return helloPersonServiceResponse;


The web.xml file

Now, add a web.xml file to the project (you can do this via New File > Web > Standard Deployment Descriptor (web.xml)) and add the proper configuration for the jax-ws servlet to it:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns=""
        <description>JAX-WS endpoint</description>
        <display-name>The JAX-WS servlet</display-name>

The sun-jaxws.xml file

The last step is adding the sun-jaxws.xml file to the WEB-INF directory of the project. This is the content of the file:

<?xml version="1.0" encoding="UTF-8"?>
        url-pattern='/helloPersonService' />

Notice that the implementation attribute is pointing to our implementation class.

Running the service

Add jetty:run as custom action (via Run > Set Project Configuration > Customize > Actions) and run it.
Now open a browser and check the following url http://localhost:8083/hello_person/helloPersonService. If you see the following screen, the webservice is up and running!

Testing the service

For testing I’m using the soapUI plugin for Netbeans.
After you’ve installed the plugin, you can create a new Web Service Testing Project (New Project > SOA > Web Service Testing Project)

Point the initial WSDL property to the url you’ve seen on the Web Services page: http://localhost:8083/hello_person/helloPersonService?wsdl.

The testsuite now contains a greetPerson Test Step. You can now test if the service works. If all goes well, you should see something similar to the picture below.


17 thoughts on “Developing a contract-first JAX-WS webservice

  1. Nice example. Very clear and simple.

    Any ideas on the pom file configuration when the wsdl and xsd’s are somewhere out there on the internet, and you are behind a proxy?


    • Thanks Enno. I guess you could still get a hold on the wsdl and xsd’s and add them to the project locally. But that’s a bit like the other way around isn’t it? This example assumes that you’re building a new webservice from scratch and first build the contract. In your case the contract is already out there, so i’m guessing the service also is. Or are you implying some sort of central repository where you keep all your wsdl and xsd files?

      • Hi Roger,

        Maybe my question is/was out of scope for your example.

        I’m more thinking of building a/the client when the service is indeed already build and available. This should be possible by configuring the pom so it checks online for the wsdl and the xsd’s (whithout copying them to a local repository) and generating the needed classes. I thought there was a difference when trying this with or without a proxy server in between. Hence my question.



      • Hi Enno,

        Check. I haven’t tried it myself, but according to the jaxws-maven plugin documentation there is a parameter called httpproxy available for setting a proxy. The wsimport goal also generates a client class. So if the httpproxy parameter works, you can point the wsdlUrls parameter to the external wsdl and i’m guessing you’re all set to go.

        Regards, Roger.

    • Hello Chris,
      No it doesn’t. You have to run a mvn clean install or mvn clean package before firing up the jetty server via mvn jetty:run. Running jetty before packaging or installing the web service will amount to nothing. It will fire up Jetty but the web service won’t be deployed, hence won’t be available.
      Furthermore, the configuration in the example is pretty basic and it will not give you hot deployment on jetty. When you make a change to the web service, you’ll have to stop jetty first, then do a package or install and finally startup jetty again.
      For hot deployment you could check out Cargo. Apart from hot deployment features it’s also a good way to standardize JEE container management.

  2. Hi,

    This is really a good example to quickly grasp the concept of web services using JAX-WS. I have tried to run this example in both net beans and cmd but got the below error. Not sure how to solve this since am new to moven. If you could help on this issue, it would be great.

    Thanks in advance

    Sree Hari

    [ERROR] Failed to execute goal on project hello_person: Could not resolve dependencies for project Failure to find com.sun.istack:istack-commons-runtime:jar:1.1 in was cached in the local repository, resolution will not be reattempted until the update interval of has elapsed or updates are forced -> [Help 1]
    org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project hello_person: Could not resolve dependencies for project Failure to find com.sun.istack:istack-commons-runtime:jar:1.1 in was cached in the local repository, resolution will not be reattempted until the update interval of has elapsed or updates are forced
    at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(
    at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(
    at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(
    at org.apache.maven.DefaultMaven.doExecute(
    at org.apache.maven.DefaultMaven.execute(
    at org.apache.maven.cli.MavenCli.execute(
    at org.apache.maven.cli.MavenCli.doMain(
    at org.apache.maven.cli.MavenCli.main(
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(
    at java.lang.reflect.Method.invoke(
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(
    Caused by: org.apache.maven.project.DependencyResolutionException: Could not resolve dependencies for project Failure to find com.sun.istack:istack-commons-runtime:jar:1.1 in was cached in the local repository, resolution will not be reattempted until the update interval of has elapsed or updates are forced
    at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(
    at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(
    … 22 more
    Caused by: org.sonatype.aether.resolution.DependencyResolutionException: Failure to find com.sun.istack:istack-commons-runtime:jar:1.1 in was cached in the local repository, resolution will not be reattempted until the update interval of has elapsed or updates are forced
    at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveDependencies(
    at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(
    … 23 more
    Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Failure to find com.sun.istack:istack-commons-runtime:jar:1.1 in was cached in the local repository, resolution will not be reattempted until the update interval of has elapsed or updates are forced
    at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(
    at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(
    at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveDependencies(
    … 24 more
    Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Failure to find com.sun.istack:istack-commons-runtime:jar:1.1 in was cached in the local repository, resolution will not be reattempted until the update interval of has elapsed or updates are forced
    at org.sonatype.aether.impl.internal.DefaultUpdateCheckManager.checkArtifact(
    at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(
    … 26 more
    [ERROR] For more information about the errors and possible solutions, please read the following articles:
    [ERROR] [Help 1]

    • Hi Sree,

      If I had to guess, i’d think you’re pom file is not entirely correct. Look for the repositories element. It should have a repository in it with an url pointing to
      Looks like your pom file is looking in the repository located at This repository doesn’t have the necessary jars needed for the example. To be more specific, it lacks the javaee-web-api and jaxws-rt dependency graphs. Look at the pom in the example for more details. Hope this helps.

      Regards, Roger.

    • I know this is old, just just posting for posterity.

      I ran into the same issue with istack-commons-runtime. I just had to explicitly add it as a dependency:


      hope this helps someone!

  3. Need some help on handling xsd:any .
    The xsd:any type is an XMLSchema element that defines elements that can
    contain undefined XML data.The application
    deals directly with XML data and do not want the overhead of
    converting the XML data into a Java object and then converting back into
    XML in to be inserted into a SOAP message.

    Need help on the implementation and also on handling the element. Also how to handling the xml data avaialble as String in the application to transfer its contents into a
    SOAPElement instance

    Pramod Kumar

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s