X

Deployment Descriptor-free Web services in GlassFish

Guest Author
One of the big benefits of JAX-WS 2.0 is that deployment descriptors are
optional. By optional, it means no deployment descriptors are required if you
can live with the reasonable defaults defined by the JAX-WS specification. So if
you develop a trivial Web service, starting from POJO (Plain Old Java Object),
as:

@javax.jws.WebService(targetNamespace="http://example.org")

public class Hello {

  public String sayHello(String name) {

    return "Hello " + name;

  }

}

compile it and drop the class in $AS_HOME/domains/domain/autodeploy
directory, where AS_HOME is the directory location for GlassFish,
then you have deployed a Web service at http://localhost:8080/Hello/HelloService?wsdl.
With GlassFish v2
M4
, the WSDL looks like (default values are highlighted in bold):

<?xml version="1.0" ?>

<definitions 

  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

  xmlns:tns="http://example.org"

  xmlns:xsd="http://www.w3.org/2001/XMLSchema"

  xmlns="http://schemas.xmlsoap.org/wsdl/"

  targetNamespace="http://example.org"

  name="HelloService">

  <types>

    <xsd:schema>

      <xsd:import namespace="foobar"
schemaLocation="http://localhost:8080/Hello/HelloService?xsd=1">

      </xsd:import>

    </xsd:schema>

  </types>

  <message name="sayHello">

    <part name="parameters" element="tns:sayHello">

    </part>

  </message>

  <message name="sayHelloResponse">

    <part name="parameters" element="tns:sayHelloResponse">

    </part>

  </message>

  <portType name="Hello">

    <operation name="sayHello">

      <input message="tns:sayHello">

      </input>

      <output message="tns:sayHelloResponse">

      </output>

    </operation>

  </portType>

  <binding name="HelloPortBinding" type="tns:Hello">

    <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document">

    </soap:binding>

    <operation name="sayHello">

      <soap:operation soapAction="">

      </soap:operation>

      <input>

        <soap:body use="literal">

        </soap:body>

      </input>

      <output>

        <soap:body use="literal">

        </soap:body>

      </output>

    </operation>

  </binding>

  <service name="HelloService">

    <port name="HelloPort" binding="tns:HelloPortBinding">

      <soap:address location="http://localhost:8080/Hello/HelloService">

      </soap:address>

    </port>

  </service>

</definitions>

The wsdl:service/@name, wsdl:port/@name, wsdl:portType/@name
and other similar elements use a default value, defined by the JAX-WS
specification, derived from the class name and method name. All these values can
be easily configured using @WebService
and @WebMethod.

This class is in default package and that's why @WebService/targetNamespace
attribute is required. Otherwise targetNamespace is derived from
the package name and in which case the Web service implementation looks like:

package hello;

public class Hello 

  public String sayHello(String name) {

    return "Hello " + name;

  }

}

There is a similar sample in GlassFish
samples
as well. A much broader collection of JAX-WS samples is available here.

This Deployment Descriptor-free concept also work if you really like to
bundle up your classes together in a WAR. Basically just package your classes in
WEB-INF/classes directory and that's it. No web.xml, sun-web.xml
or any proprietary descriptors are required.

As shown above, converting your POJO to a Web service is really simple, does
not require any deployment descriptors, improves readability of code and is
backed by the production-quality JAX-WS runtime in GlassFish.

And if you are using NetBeans,
then you don't need to worry about any of these details.

Technorati: Web
service
GlassFish JAX-WS
JAXWS Samples
Ease of Use

Join the discussion

Comments ( 14 )
  • Arun Gupta's Blog Monday, February 5, 2007
    [Trackback] In this third and last part of a blog series (part 1 and part 2), I plan to explore the steps to develop/deploy/invoke a Web service on GlassFish using Eclipse IDE. Eclipse does not offer GlassFish as a a bundled...
  • David Dossot Tuesday, February 6, 2007
    If you add on top of this DD-free WS the <a heref="http://blogs.sun.com/theaquarium/entry/spring_support_in_glassfish_s">support for Spring in Glassfish, man this is sweet!
  • Arun Friday, February 9, 2007
    The JAX-WS RI available in GlassFish already supports Spring. Please read the following entry for more detail:
    http://weblogs.java.net/blog/kohsuke/archive/2007/01/spring_support.html
  • Johan Eltes Tuesday, February 20, 2007
    Is it possible to use annotations to produce an xsd:any extensibility element? I.e.
    <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" />
  • Kohsuke Kawaguchi Wednesday, February 21, 2007
    Johan, questions like that should be posted to the forum (http://forums.java.net/jive/forum.jspa?forumID=46)
  • Arun Gupta's Blog Friday, March 23, 2007
    [Trackback] In the opening keynote of Day 2 (Day 1), Joe Ottinger, Editor-in-chief of TheServerSide, asked the following questions, to an audience of approx 500 Java developers, receiving instant feedback using little handy devices on each attendees table. As with...
  • Richard Livingstone Tuesday, October 9, 2007

    In the example above, I can see

    <part name="parameters" element="tns:sayHelloResponse">

    and similarly for the request, for a param which could be a complex type. How could the WSDL generated be forced into being a proper type ? This is particularly the case where the parameters are also classes.

    I have some Java-first web services like this deployed fine on OAS but when I deploy on Glassfish I get WSDL like the above, which is not ideal as I would like to the fact I run on 2 app servers to be transparent (for various reasons too dull to go into the services may end up being deployed on both).

    Is the answer explicit JAXB bindings ? It seems that OAS can generate these without the annotations on the classes I'm using as a parameter but why not Glassfish?


  • Vivek Pandey Tuesday, November 13, 2007

    That is correct, as required by the JAX-WS 2.0 spec, a java class (that follows a bean pattern)is mapped to an XML type based on the Java to XML binding rules defined by JAXB 2.0 specification.

    So for any JAX-WS 2.0 compliant implementation if you deploy this class the generated XML type in the WSDL would be the same.

    As a general guideline, if you have requirement to deploy your service on different containers, you should consider WSDL first approach.

    Please bring your further questions to the forum: http://forums.java.net/jive/forum.jspa?forumID=46.


  • laptop batteries Wednesday, November 26, 2008

    So for any JAX-WS 2.0 compliant implementation if you deploy this class the generated XML type in the WSDL would be the same.

    As a general guideline, if you have requirement to deploy your service on different containers, you should consider WSDL first approach.


  • guest Monday, August 8, 2011

    If you add on top of this DD-free WS the support for Spring in Glassfish, man this is sweet!


  • guest Monday, August 8, 2011

    Is it possible to use annotations to produce an xsd:any extensibility element?


  • soryea squanta Monday, August 8, 2011

    As a general guideline, if you have requirement to deploy your service on different containers, you should consider WSDL first approach.


  • Lithium-ion Battery Saturday, November 12, 2011

    As a general guideline, if you have requirement to deploy your service on different containers, you should consider WSDL first approach.


  • guest Saturday, November 12, 2011

    Is the answer explicit JAXB bindings ? It seems that OAS can generate these without the annotations on the classes I'm using as a parameter but why not Glassfish?


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha