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
Posted by Arun Gupta in webservices | Comments[8]
|
|
|
|
Posted by Arun Gupta's Blog on February 05, 2007 at 09:18 AM PST #
Posted by David Dossot on February 06, 2007 at 07:07 PM PST #
Posted by Arun on February 09, 2007 at 09:43 PM PST #
Posted by Johan Eltes on February 20, 2007 at 12:36 PM PST #
Posted by Kohsuke Kawaguchi on February 21, 2007 at 09:41 AM PST #
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 #