Miles to go ...

Arun Gupta is a Technology Evangelist for Web Services and Web 2.0 Apps at Sun. He was the spec lead for APIs in the Java platform, committer in multiple Open Source projects, participated in standard bodies and contributed to Java EE and SE releases.
« Web services in... | Main | Sun understands WS-*... »

http://blogs.sun.com/arungupta/date/20070202 Friday February 02, 2007

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

del.icio.us | furl | simpy | slashdot | technorati | digg
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 09: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 07:07 PM 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 09: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 12:36 PM 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 09: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 10: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 09, 2007 at 05:00 AM 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 04:31 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
« Web services in... | Main | Sun understands WS-*... »

Valid HTML! Valid CSS!

This is a personal weblog, I do not speak for my employer.

--> ajax ajaxworld conf eclipse fitness gem glassfish glassfishday hyderabad india indigo interoperability javaone javaone2008 jax-ws jmaki jpa jruby mac marathon metro microsoft mysql netbeans phobos photography presos railsconf ruby rubyonrails running runninglog runsfm screencast siliconvalleymarathon sun suntechdays swdp tango theserverside totd training traveltips v3 vista wcf web2.0 webservices webtier windows wsaddressing wsit youtube
Locations of visitors to this page

calendar

« August 2008
SunMonTueWedThuFriSat
     
1
9
16
20
21
22
23
24
25
26
27
28
29
30
31
      
Today
www.flickr.com
This is a Flickr badge showing public photos from ArunGupta. Make your own badge here.
Add to Technorati Favorites

Last 50