Java Tutorial: Java Tutorial - Java Scipt : Deploying EJBs as Web Services

Java Tutorial - Java Scipt :

Deploying EJBs as Web Services

An example WSDD for an EJB might look like this:

<?xml version=”1.0” encoding=”UTF-8”?>

<deployment xmlns=”http://xml.apache.org/axis/wsdd/”

xmlns:java=”http://xml.apache.org/axis/wsdd/providers/java”>

<parameter name=”homeInterfaceName”

value=”test.interfaces.GreeterHome” />

<parameter name=”remoteInterfaceName”

value=”test.interfaces.Greeter” />

<parameter name=”jndiContextClass”

value=”com.sun.jndi.rmi.registry.RegistryContextFactory”/>

</service>

</deployment>

Be sure that the Axis Web application is deployed in JBoss. You can do so by copying the axis folder into JBoss’s deployment directory. You’ll also need to make sure that Axis can load the class files for the Greeter EJB. The easiest way to do that is to add a copy of the greeter-ejb.jar to the axis\lib directory. Thus, there will be two copies of greeter-ejb.jar, one in the deploy directory for JBoss and one in the lib directory for Axis.

In Windows, use the following command:

xcopy %AXIS_HOME%\webapps\axis %JBOSS_HOME%\server\default\deploy\axis.war\ /s

In Linux, use this command instead:

cp -r $AXIS_HOME/webapps/axis $JBOSS_HOME/server/default/deploy/axis.war

You must change the folder name to axis.war in order for JBoss to recognize it as a Web application.

We need to use the Axis AdminClient once again to deploy our Web service.

On Windows, the command is as follows:

java -classpath .;%TOMCAT_HOME%\webapps\axis\WEBINF\

lib\axis.jar;%TOMCAT_HOME%\webapps\axis\WEBINF\

lib\jaxrpc.jar;%TOMCAT_HOME%\webapps\axis\WEB-INF\lib\commons-logging.jar;%T

OMCAT_HOME%\webapps\axis\WEB-INF\lib\commonsdiscovery.

jar;%TOMCAT_HOME%\webapps\axis\WEB-INF\lib\saaj.jar

org.apache.axis.client.AdminClient Greeter.wsdd

On Linux, the command is as follows:

java -classpath .:$TOMCAT_HOME/webapps/axis/WEBINF/

lib/axis.jar:$TOMCAT_HOME/webapps/axis/WEBINF/

lib/jaxrpc.jar:$TOMCAT_HOME/webapps/axis/WEB-INF/lib/commons-logging.jar:$TO

MCAT_HOME/webapps/axis/WEB-INF/lib/commonsdiscovery.

jar:$TOMCAT_HOME/webapps/axis/WEB-INF/lib/saaj.jar

org.apache.axis.client.AdminClient Greeter.wsdd

You can test to see if it works by calling the Web service via HTTP GET:

http://localhost:8080/axis/services/Greeter?method=sayHello&name=World

You should get an XML response with a sayHelloResponse. This is a useful approach to deploying EJBs as Web services, but with JBoss things are even more interesting. JBoss has a module called JBoss.NET, which is an integrated Axis implementation with some value-added features such as additional handlers for authentication, transaction management, and much more. What we’re going to do is deploy the Greeter stateless session bean from as a JBoss.NET Web service.

First, we need to add the JBoss.NET module into the default server configuration. Copy the server\all\deploy\jboss-net.sar directory to server\default\deploy.

Let’s check to see if JBoss.NET is working. The following URL should list the services:

http://localhost:8080/jboss-net/servlet/AxisServlet

Okay, that’s done. Now, JBoss.NET is basically Axis repackaged and integrated with JBoss. Deployment relies on a .wsr file, which is basically a packaged up version of the Axis’s WSDD. The .wsr file is a standard .jar file with a

single XML Web services descriptor under META-INF\web-service.xml.

Following is the web-service.xml file for creating a JBoss.NET Web service using the Greeter EJB.

Here are the contents of web-service.xml:

<?xml version=”1.0” encoding=”UTF-8”?>

<deployment

name=”Greeter”

xmlns=”http://xml.apache.org/axis/wsdd/”

xmlns:java=”http://xml.apache.org/axis/wsdd/providers/java”

<parameter name=”handlerClass”

value=”org.jboss.net.axis.server.EJBProvider” />

</requestFlow>

<handler

type=”java:org.jboss.net.axis.server.SerialisationResponseHandler”/>

<handler

type=”java:org.jboss.net.axis.server.TransactionResponseHandler”/>

</responseFlow>

</service>

</deployment>

You can also use XDoclet to generate the JBoss.NET Web services deployment descriptor. The XDoclet module for that can be retrieved from JBoss’s CVS repository. There’s an excellent summary online at http://

www.nsdev.org/jboss/stories/jboss-net.html, with information about using XDoclet with JBoss.NET.

Although it is very similar to the WSDD file, you’ll note that JBoss uses different classes to handle the calls. Let’s package up the greeter.wsr file and use JBoss’s hot deploy to try out the service.

On Windows, the commands are:

jar cvf greeter.wsr META-INF\web-service.xml

copy greeter.wsr %JBOSS_HOME%\server\default\deploy

On Linux, the commands are:

jar cvf greeter.wsr META-INF/web-service.xml

copy greeter.wsr $JBOSS_HOME/server/default/deploy

JBoss will detect this file and deploy it. When used this way, the .wsr file is loosely deployed. We will find it deployed under the following URL:

http://localhost:8080/jboss-net/services/Greeter?wsdl

A handy option for debugging is to use -Daxis.enableListQuery=true when starting JBoss. This exposes the JBoss.NET configuration at http://localhost:8080/jboss-net/services/Administration?list. It’s very useful for development, but a potential security issue when running in a production environment.

A better-organized method, recommended for production, is to have the .wsr file residing inside your application’s .ear file. The .wsr file should be at the same level as an EJB .jar file within the .ear file. You’ll also need to add a reference to the .wsr in the <module> tag within the .ear’s METAINF\ application.xml file. Following are the additions you’ll need to make to the .ear’s META-INF\application.xml file:

<java>greeter.wsr</java>

</module>

As you can see, JBoss.NET is a powerful mechanism for deploying Java Web services. The toolset is a bit rough, and there are still some issues with reloading a Web service at times, necessitating a restart of the server to detect new changes. The option to use a vanilla installation of Apache’s Axis is still available, so you can choose the method that works best for your application. It has some quirks, but JBoss.NET is shaping up to be a great distinguishing feature in favor of JBoss