Home arrow Web Services arrow Page 3 - Deploying an EJB Application

Deploying an EJB Application

This article shows you how to deploy an EJB application, and more. Picking up where the previous article left off, it is the third of three parts. It is excerpted from chapter 7 of the book Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418).

Author Info:
By: Sams Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 10
June 01, 2006
  1. · Deploying an EJB Application
  2. · Configuring Axis to Invoke the SkatesService Session Bean
  3. · EJB Wrap-Up
  4. · JSR109 Client Code

print this article

Deploying an EJB Application - EJB Wrap-Up
(Page 3 of 4 )

This section has been long and a little complicated. The overheads of using EJBs aren't completely clear in such a small example, and we've also done many steps by hand that would usually be done by a specialized J2EE tool—and also by the JSR109 support we're about to look at. The main aspect that's complicated is the packaging of applications into EAR files. The imposed discipline is excellent in situations where careful control, versioning of applications, and staging are required—usually in enterprise Web systems. For our smaller scenario, this is probably overkill. The other complexity is understanding the code structure and the linkages and references. These have a great benefit in separating the application from the infrastructure, but at the cost of complexity.

Finally, you can avoid much of the hard work described here by using a well- integrated J2EE development environment. However, because this book isn't designed to be tied to any given system, we've shown you the basic steps using command-line tools and kept the vendor-specific aspects to a minimum.

Using JSR109: Implementing Enterprise Web Services

The JSR109 specification (http://www.jcp.org/en/jsr/detail?id=109) is the way that J2EE embraces Web services much more closely. JSR109 addresses the following aspects of Web services and J2EE:

  • Implementation and deployment of Web services using J2EE

  • Client access to Web services from a J2EE application

  • Service publication

  • Security for Web services and mapping to J2EE security

But for SkatesTown, it means something even more useful. The steps to create and deploy a Web service into an application server are reduced. There are still a number of steps, but because the entire Axis part of this model is effectively included into the application server, the result is less work.

The steps required are as follows:

  1. Create a WSDL file.

  2. Create the DDs for the service.

  3. Assemble the EJB JAR and EAR files.

  4. Enable the EAR file for Web services (doing so automatically adds a generated Web application to support the Web service endpoint).

  5. Deploy the application.

We'll guide you through each of these steps in the following sections. First, create a new working directory, J109, to contain the updated code. Copy the skatesejb.jar file into the directory, and unjar it:

>jar xvf skatesejb.jar

You'll use the WebSphere tools, which will replace the Axis WSDL2Java and Java2WSDL. To do this, add the <websphere>\bin directory to your path.

Step 1: Creating the WSDL File

Run Java2WSDL on the SkatesProduct interface:

>set classpath=skatesejb.jar
-implClass com.skatestown.ejb.SkatesProductsBean 

The –implClass is optional; it uses the implementation class to find the names of the arguments to create nicer-looking WSDL. Axis supports this as well, so we could have used it in the previous part of the chapter. (This only works if you compile the code with the –g option, which adds debug information to the class files).

Now, create the WSDL file. For this project, we need to move it to META-INF\WSDL:

>mkdir META-INF
>mkdir META-INF\wsdl
>move SkatesProducts.wsdl META-INF\WSDL\

Step 2: Creating the Deployment Descriptors

The extended options for the WebSphere Java2WSDL command are as follows:

> WSDL2Java \
-verbose \ 
-role develop-server \
-container ejb \
-genJava no 
WSWS3185I: Info: Parsing XML file: META-INF\WSDL\
SkatesProducts.wsdl WSWS3282I: Info: Generating META-INF\
webservices.xml. WSWS3282I: Info: Generating META-INF\
ibm-webservices-bnd.xmi. WSWS3282I: Info: Generating META-INF\
ibm-webservices-ext.xmi. WSWS3282I: Info: Generating META-INF\

The options disable the generation of any Java classes, say that you're using an EJB as the implementation of the service (JSR109 also allows servlets), and say that you're developing the server-side artifacts.

When this command is run, it creates four new files:

  • The webservices.xml file is the overall DD that configures the application server to use this bean as the service.

  • Two .xmi files are additional bindings files, which contain additional information that WebSphere needs to use the EJB as a service.

  • SkatesProducts_mapping.xml is a JAX-RPC mapping file that contains the mapping between XML Schema types and Java types that is used in this instance.

We now need to edit webservices.xml and set the ejb-name of the session bean to SkatesProduct:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE webservices 
PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web
services 1.0//EN" "http://www.ibm.com/webservices/dtd/
j2ee_web_services_1_0.dtd"> <webservices> <webservice-description> <webservice-description-name> SkatesProductsService </webservice-description-name> <wsdl-file>META-INF/wsdl/SkatesProducts.
wsdl</wsdl-file> <jaxrpc-mapping-file>META-INF/
SkatesProducts_mapping.xml</jaxrpc-mapping-file> <port-component> <port-component-name>SkatesProducts</port-
component-name> <wsdl-port> <namespaceURI>http://ejb.skatestown.
com</namespaceURI> <localpart>SkatesProducts</localpart> </wsdl-port> <service-endpoint-interface> com.skatestown.ejb.SkatesProducts </service-endpoint-interface> <service-impl-bean> <ejb-link>SkatesProduct</ejb-link> </service-impl-bean> </port-component> </webservice-description> </webservices>

As you can see, this is much more like an Axis WSDD file than a WSDL file, in that it configures the server to expose this service.

The descriptor does a number of things. For each service, it defines the following:

  • The service description name

  • The WSDL file associated with the service

  • A JAX-RPC type-mapping file that associates Java types with XML Schema types

    One or more port components, each defining a QName, a service endpoint (business) interface, the EJB which implements the interface, and (optionally) any JAX-RPC handlers to run for that port

The JAX-RPC mapping file is pointless in this instance because we didn't specify any mapping! It's pretty much mechanical. It's a big file, so we'll just show a snippet:

?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE java-wsdl-mapping 
PUBLIC "-//IBM Corporation, Inc.//DTD J2EE JAX-RPC
mapping 1.0//EN" "http://www.ibm.com/webservices/dtd/
j2ee_jaxrpc_mapping_1_0.dtd"> <java-wsdl-mapping
id="JavaWSDLMapping_1075832345810"> <package-mapping
id="PackageMapping_1075832345820"> <package-type>com.skatestown.ejb</package-type> <namespaceURI>http://ejb.skatestown.
com</namespaceURI> </package-mapping> <java-xml-type-mapping id="JavaXMLTypeMapping_1075832345820"> <class-type>double</class-type> <root-type-qname id="RootTypeQname_1075832345820"> <namespaceURI>http://www.w3.org/2001/
XMLSchema</namespaceURI> <localpart>double</localpart> </root-type-qname> <qname-scope>simpleType</qname-scope> </java-xml-type-mapping> </java-wsdl-mapping>

We've now created the required files for the EJB JAR.

Step 3: Assembling the Application Files

Let's create the EJB JAR file:

>jar cvf skates109.jar META-INF\* com\skatestown\

Now we need a new application.xml file to create the EAR file. It's shown here:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application 
PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE
Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd"> <application id="SkatesTown109"> <display-name>Skates109</display-name> <module id="EjbModule_skates"> <ejb>skates109.jar</ejb> </module> </application>

This is just like the last one, except we only need the EJB JAR—the tooling is about to add the Web router for us. The tool that does this is called the endpoint enabler (endptEnabler).

Step 4: Enabling the EAR File for Web Services

We run the endpoint enabler tool as follows:

>endptEnabler skates109.ear
WSWS2004I: IBM WebSphere Application Server Release
5 WSWS2005I: Web services Enterprise Archive Endpoint
Enabler Tool. WSWS2007I: (C) COPYRIGHT International Business
Machines Corp. 1997, 2003. WSWS2003I: Backing up EAR file to: skates109.ear~ WSWS2016I: Loading EAR file: skates109.ear WSWS2017I: Found EJB Module: skates109.jar WSWS2024I: Adding http router for EJB Module skates
109.jar. WSWS2036I: Saving EAR file skates109.ear... WSWS2037I: Finished saving the EAR file. WSWS2018I: Finished processing EAR file skates109.

It automatically adds a new Web application into the EAR file.

Step 5: Deploying the Application

This process is just as before, except we'll choose different JNDI names so the application doesn't clash with the other one. Follow these steps:

  1. From the console, choose Applications and then Install New Application.

  2. Browse to the Skates.ear file.

  3. The wizard will take you through a number of steps, and in most of them you can accept the default values. The ones you need to change are as follows:

    • In Deploy EJBs Option, the Database Type is CLOUDSCAPE_V5 and the Database Schema is SKATES.

    • In JNDI Names For Beans, the value for SkatesEntity is ejb/skates109/SkatesEntityHome and the value for SkatesProduct is ejb/skates109/SkatesProductHome.

    • In Provide Default Datasource Mapping For Modules Containing 2.0 Entity Beans, the value for Skatesejb.jar is jdbc/SkatesDataSource.

    • In Map EJB References To Beans, the value for SkatesProduct and SkatesEntity is ejb/skates109/SkatesEntityHome.

  4. Click Finish.

Start the application, and then browse the WSDL file to see if it's working:


To test it, we can modify the URL in the test client we wrote earlier:

SkatesProductsService sps =
new SkatesProductsServiceLocator(); SkatesProducts sp = sps.getSkatesService( new URL( "http://localhost:9080/skates109/services/
SkatesProducts")); ....

Then run it. This time, we get a failure on the addProduct:

C:\book\axis>java com.skatestown.ejb.SkatesTest
Fault in adding product
Product code =
Price =
Description =
The latest inlines from Supertastix—these are worth
every penny!

This, with a little thought, should be expected. The product entry Supertastix58s is already in the database table—we used the same datasource, and therefore the same database, as the original installation. Since we ran this client before, it created the entry, and the code in the EJB fails with an exception if there is an existing entry with the same product code. This isn't actually a bug! Enterprising readers may wish to modify the sample application to offer a choice between adding or viewing products.

blog comments powered by Disqus

- Dealing with Loose Coupling in a Service-Ori...
- Loose Coupling in a Service-Oriented Archite...
- Safety, Idempotence, and the Resource-Orient...
- The Resource-Oriented Architecture in Action
- Features of the Resource-Oriented Architectu...
- The Resource-Oriented Architecture
- Getting Started with Flex
- Automated Billing and Faxing for the Web
- An Introduction to Web Services
- The Foundations of Web Services: From Novice...
- Web Services Reengineering: Finishing Touches
- Fault Handling with Web Services
- Flow and Web Services
- Process Lifecycles and Web Services
- Business Processes and Web Services

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials