Deployment Descriptor-free Web services in GlassFish

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

Comments:

[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...

Posted by Arun Gupta's Blog on February 05, 2007 at 01:18 AM PST #

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!

Posted by David Dossot on February 06, 2007 at 11:07 AM PST #

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

Posted by Arun on February 09, 2007 at 01:43 PM PST #

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" />

Posted by Johan Eltes on February 20, 2007 at 04:36 AM PST #

Johan, questions like that should be posted to the forum (http://forums.java.net/jive/forum.jspa?forumID=46)

Posted by Kohsuke Kawaguchi on February 21, 2007 at 01:41 AM PST #

[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...

Posted by Arun Gupta's Blog on March 23, 2007 at 03:45 AM PDT #

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?

Posted by Richard Livingstone on October 08, 2007 at 10:00 PM PDT #

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.

Posted by Vivek Pandey on November 13, 2007 at 08:31 AM PST #

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.

Posted by laptop batteries on November 26, 2008 at 01:54 PM PST #

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

Posted by guest on August 07, 2011 at 05:26 PM PDT #

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

Posted by guest on August 08, 2011 at 11:51 AM PDT #

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

Posted by soryea squanta on August 08, 2011 at 11:54 AM PDT #

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

Posted by Lithium-ion Battery on November 11, 2011 at 04:48 PM PST #

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?

Posted by guest on November 11, 2011 at 04:50 PM PST #

Post a Comment:
Comments are closed for this entry.
About

profile image
Arun Gupta is a technology enthusiast, a passionate runner, author, and a community guy who works for Oracle Corp.


Java EE 7 Samples

Stay Connected

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today