JAX-WS simplifies the development model for a web service endpoint a great deal. In short, an endpoint implementation bean is annotated with JAX-WS annotations and deployed to the server. The server automatically generates and publishes the abstract contract (i.e. wsdl+schema) for client consumption. All marshalling/unmarshalling is delegated to JAXB.
Setting up your environment
This sample has been tested with JBoss-5.0.0.CR2 and JBoss WS native 3.0.4
To get started you need to download jbossws and install JBossWS on your preferred target container.
Follow the installing instructions from the binary distribution. I'd suggest you as well to take a look at the JBoss Sample suite which allows you to test all the Web Service Stack both with Ant scripts and with the Eclipse IDE. Here's a link for it:
EJB 3.0 web services
Let’s first see a straightforward example: here you expose an EJB 3.0 as a web service. After we'll dive into the details of some commonly used annotations that can make defining web services even easier.
In this sample we have used the @javax.jws.WebService annotation to expose HelloWorld Bean as a web service.
The @WebService annotation can also specify the name of the web service. If you don’t specify the name element, the name of the bean class or interface will be used by default.
You can use the targetNamespace element to specify the target namespace for the WSDL elements generated by the web service. If you don’t specify this element, the EJB container will use the Java package name to generate a default XML namespace.
You can use the serviceName element to specify the service name. Specifying the serviceName is only allowed when you annotate the bean class. The name specified using serviceName is used for generating the name attribute in the service element in the WSDL. If you don’t specify the serviceName element, the server will generate it using the default, which is the bean class name appended with Service.
We specified that the web service is a document-style web service by using the @javax.jws.SOAPBinding annotation.
We used the @javax.jws.WebMethod annotation to expose the echo method in the web service. If you use the @WebService annotation on the interface, then all public methods on the web service endpoint will be exposed in the web service.
A client for our web service can be as simple as this:
Packaging the WebService:
It's just a matter of putting the Bean and the Interface in a jar file. Once you have packed these files put them in the deploy directory of jboss.
verify that JBoss has correclty deployed the web service:
Running the client should echo your "Hello World" back to the client.
Deploying a POJO as web service:
Deploying your ejb as webservice is not your only option: you can deploy a POJO as web service as well. In this case you just need to tag @WebService in a plain java class.
Package your WebService in a Web Application Archive. Take care to map the WebService as a Servlet in your web.xml
Once deployed the war you should see it in your webservice console (JBoss 5-6)
The client logic doesn't change compared with the previous example.
So when you choose EJB over a POJO for a web service?
JAX-WS 2.0 allows both regular Java classes and stateless EJBs to be exposed as web services. If you
were using J2EE 1.4, you’re probably wondering why you’d use a stateless EJB as a web service. A
look at the code for a POJO and for EJB 3 web services reveals that there are hardly any differences,
with the exception that the EJB 3 web service will have a few extra annotations. A Java class web
service is packaged in a web module whereas an EJB web service is packaged in an EJB-JAR.
Both a Java web service and an EJB web service support dependency injection and lifecycle
methods such as @PostConstruct and @PreDestroy, but you get a few extra benefits from
using EJB 3 web services.
First, you automatically get the benefits of declarative transaction and security available only to
EJB 3 components. You can use interceptors and the timer service if your applications need them,
without depending on extra layering.
Second, a web service that uses EJB 3 can easily expose your business applications using
additional protocols, such as RMI, by adding a remote interface. As you saw in the previous section,
exposing an EJB 3 stateless session bean is easy and can be done by simply adding the