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).
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
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:
Create a WSDL file.
Create the DDs for the service.
Assemble the EJB JAR and EAR files.
Enable the EAR file for Web services (doing so automatically adds a generated Web application to support the Web service endpoint).
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>\bindirectory to your path.
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:
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 .xmifiles are additional bindings files, which contain additional information that WebSphere needs to use the EJB as a service.
SkatesProducts_mapping.xmlis 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:
To test it, we can modify the URL in the test client we wrote earlier:
SkatesProductsService sps =
SkatesProducts sp = sps.getSkatesService(
Then run it. This time, we get a failure on the addProduct:
Fault in adding product
Product code =
The latest inlines from Supertastix—these are worth
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.