![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Remote deployment is an important feature for any J2EE-certified application server. Mission-critical applications need to run on dedicated systems. Security is also a must for such systems, thus limiting access to the systems. Limited access means that an application cannot be built and packaged on the same system on which it's going to be deployed and run.
The Java community recognized the importance of remote deployment. Java Specification Request 88: Java Application Deployment (JSR 88) was introduced in October 2000 to address it. The Java Community Process (JCP) has standardized many aspects of applications through the JSRs. One example of this standardization is the packaging of applications. A Web application has a standardized layout and is packaged as a Web application archive (WAR). This allows an application developer to develop a Web application without having to worry too much about what kind of environment that application will be deployed to. It's the classic Java motto of write once, run anywhere applied to enterprise development.
Like other JSRs created through the JCP, JSR 88 was the product of collaboration between representatives from many industry leaders, such as IBM®, Sun Microsystems, BEA, and Oracle. The specification introduces a standardized way for any J2EE application to be deployed to any J2EE application server. It provides details on (and thus standardization of) many important aspects of deployment in general and remote deployment in particular. It establishes how a remote application server should be identified and located and determines a basic security model for accessing an application server. It also selects several core deployment phases an application server should support, such as deployment, undeployment, and redeployment.
A lot of time and effort went into JSR 88. The draft of the specification was released to the JCP in October 2001. Of course by then, all of the major application server vendors already had some kind of support for remote deployment built into their products. Not surprisingly, different vendors had different approaches, and thus there was a lot of debate on how to standardize deployment. The JCP settled on a draft that was released to the public in January 2002. JSR 88 was finalized and approved in June 2002. Since then, it was updated in 2003 and is due to be updated again this year with the release of Java Platform, Enterprise Edition (Java EE) 5. (See Resources later in this article for more details and history on JSR 88.)
JSR 88 allows independent software vendors to produce J2EE applications that can be deployed to any J2EE-certified application server. Of course, developers of each application server can add extra deployment capabilities while still supporting JSR 88. For example, Apache Geronimo provides many advanced deployment features via its Geronimo deployment plans. The deployment plan tells Geronimo important metadata about your application. For Web applications, one of the important things that it does is set the context root of your application. This makes it easy to have your application appear at http://<host>, for example, with no additional path on the URL. This article includes a simple Web application that includes a Geronimo deployment plan (see Resources for more about deployment plans).
To see how remote deployment works on Geronimo, it's useful to have an application to deploy. Figure 1 shows the layout of a simple Web application, remoteApp, which is used in this article.
Figure 1. File structure of a simple Web application called remoteApp
This application contains just a single Web page called index.jsp. Listing 1 shows the Web page displaying Hello World along with the current time.
Listing 1. index.jsp for remoteApp
<?xml version="1.0" encoding="ISO-8859-1" ?>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1" session="false"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<title>My Remote Web Application</title>
</head>
<body>
Hello Remote World! The current time is: <%= new
java.util.Date().toString() %>
</body>
</html>
|
The application uses Ant to build and package the application. Listing 2 shows the build script. All it really does is call the Java jar function to package the application into a .war file. To build and package the application you simply run ant buildwar.
Listing 2. Simple Ant Build File
<project name="remoteApp" basedir="." default="usage">
<property name="src.dir" value="src"/>
<property name="web.dir" value="war"/>
<property name="build.dir" value="${web.dir}/WEB-INF/classes"/>
<property name="name" value="remoteApp"/>
<target name="build" description="Compile main source
tree java files">
<mkdir dir="${build.dir}"/>
<javac destdir="${build.dir}" debug="true"
deprecation="false" optimize="false" failonerror="true">
<src path="${src.dir}"/>
<classpath refid="master-classpath"/>
</javac>
<copy todir="${build.dir}" preservelastmodified="true">
<fileset dir="${src.dir}">
<include name="**/*.hbm.xml"/>
</fileset>
</copy>
</target>
<target name="buildwar" depends="build"
description="Builds application as a WAR file">
<war destfile="${name}.war"
webxml="${web.dir}/WEB-INF/web.xml">
<fileset dir="${web.dir}">
<include name="**/*.*"/>
</fileset>
</war>
</target>
</project>
|
Last, but not least, the application contains a Geronimo deployment plan. Geronimo finds the deployment plan when it unpacks the .war file. The deployment plan specifies that the context root will be /helloRemote (see Listing 3). Thus, you'll be able to access your running Web application at http://<host>:<port>/helloRemote. The plan also gives the application an ID of HelloRemote.
Listing 3. The Geronimo deployment plan for remoteApp
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
configId="HelloRemote">
<context-root>/helloRemote</context-root>
<context-priority-classloader>false</context-priority-classloader>
</web-app>
|
With a simple application in hand, you can now use Geronimo's remote deployment features to deploy the application to a remote instance of Geronimo. There are several different ways to do this; the next section takes a look at the different options and how they work.
The specification laid out in JSR 88 is a requirement for any J2EE 1.4 application server, and Apache Geronimo fully implements it. Geronimo provides several ways to deploy your applications to both local and remote systems. Out of the box, it provides the Geronimo deployment tool, a command-line utility. This tool provides full JSR 88 support and can even be used with other application servers.
Geronimo also provides deployment via the Geronimo Administration Console, a Web application for Geronimo administrators. Finally, by providing JSR 88 support, other third-party tools can be used with Geronimo, such as the popular Eclipse Web Tools Platform (see Resources for more information). This article shows how to deploy the sample application using the Geronimo deployment tool and how to verify its deployment using the Geronimo Administration Console. First, take a look at the Geronimo deployment tool.
The Geronimo deployment tool can be found in $GERONIMO_HOME/bin/deployer.jar. It provides all the options specified by JSR 88 as well as additional Geronimo-specific options, such as specifying external Geronimo deployment plans. This tool is a natural choice for system administrators used to working from the command line and can be used for both local and remote deployment. It has a straightforward syntax:
java -jar deployer.jar <general_options> <command>
<command_options>
There are several general options that enable remote deployment. The --uri option allows a remote server to be identified using the URI syntax defined in JSR 88. Thus, the URI would look something like this:
deployer:geronimo:jmx:rmi:///jndi/rmi:[//host[:port]]/JMXConnector
This allows you to specify the remote server (host) and, optionally, the port that the host is listening on. If you don't specify host and port, the defaults are localhost and 1099, respectively. Alternatively, you can specify a host and port using the --host and --port options.
Of course, deployment must be secured. Thus, you'll need to use a username and password as credentials with the deployment tool. The username is specified using --user option, and similarly the --password option can be used to specify the password. If no password is given, the deployment tool will prompt the user for a password.
The deployment tool can be used for starting/stopping applications as well as un-deploying an application. It can even be used with other J2EE application servers. To do this, you will need the --driver option to specify a JSR 88 compliant driver JAR. You can also combine the various options into a deployment script (a simple XML file), and then pass in the deployment script to the deployment tool.
The deployment tool also has a few requirements that you should be aware of. The local machine needs to have its Remote Method Invocation (RMI) port open. This is 1099 by default. It must also share its file system with the remote server. This allows the remote server to read the application archive file (usually an EAR or a WAR). The remote server must also have its RMI port open and its HTTP port open, which is 8080 by default. Finally, it must be running the remote-deploy Web application, which is included and running by default on Geronimo.
Later in this article, you will see the remoteApp deployed to a remote instance of Geronimo using the Geronimo deployment tool. Before getting to that, let's take a look at another option for deployment, the Geronimo Administration Console.
Remote deployment using the Geronimo Administration Console
The remote-deploy Web application allows for deployment to be done using the Geronimo Administration Console (see Figure 2). This can be accessed at http://<host>:<port>/console.
Figure 2. The Geronimo Administration Console: welcome page
Click the Deploy New link under the Applications folder on the left navigation bar, as shown in Figure 3.
Figure 3. The Geronimo Administration Console: Deploy new application screen
This lets you upload your application's .ear or .war file and a deployment plan. You can include your Geronimo deployment plan as part of your EAR or WAR, such as in the sample Web application remoteApp. Alternatively, you can specify it separately. This is useful for applications that have been developed for other application servers. For example, maybe you have a Web application that you currently run on JBoss and you want to migrate it to Geronimo. Using this option, you can write any special Geronimo metadata in a deployment plan that is external to your Web application's .war file, and just deploy the existing WAR.
The Geronimo Administration Console is a simple and graphical alternative to the Geronimo deployment tool. The console is a Web application, so it must be deployed (which it is by default), and a Web container (Tomcat or Jetty) must be installed. In some production systems, you may not want its Web application deployed, since it uses some resources and it exposes administrative capabilities that are already exposed through command-line features. It's also possible that the application you're running on Geronimo doesn't need a Web container at all. In that case, you can take advantage of Geronimo's modularity and strip it down by removing the Web container. This can free up more resources and help you squeeze even more performance out of Geronimo. It's still a nice tool for developers. Another nice option during development is using the Eclipse Web Tools platform with the Geronimo plug-in (see Resources for a link to a developerWorks article explaining this option).
Deployment using the Eclipse Web Tools platform
The standardization of J2EE application deployment allows for other tools to build in this functionality and support a variety of application servers. You can also use Eclipse's Web Tools Platform to deploy applications to both local and remote instances of Geronimo. In the remainder of this section, you'll see an example of Eclipse being used to deploy to a remote instance of Geronimo. You'll need the Geronimo plug-in for Eclipse installed (see Resources for a link to the download). From there it's just a matter of creating a new server instance in Eclipse, typically using the New Server wizard, and then specifying your application to be deployed on this server.
The wizard will default the server's host name to localhost, so you'll want to change this to the name of your remote host, as shown in Figure 4. Note that you'll need Geronimo on your local machine as well, since you need its deployment tool. In Figure 4, a Geronimo run time has already been installed locally; otherwise you would need to set that up using the Installed Runtimes... button.
Figure 4. Step 1: You can choose what type of J2EE server to use
Figure 5 shows the usual information for connecting to any Geronimo instance -- such as what Web, RMI, and Enterprise JavaBeans (EJB) ports Geronimo is using -- and the security credentials for connecting to Geronimo.
Figure 5. Step 2: Specify parameters for connecting to Geronimo
The last step is to select your application to deploy to the server (see Figure 6). Of course, you can always select other applications for deployment to any configured server in Eclipse. (See Resources for more detailed instructions on setting up Eclipse, WTP, and the Geronimo plug-in, and then deploying applications to Geronimo using Eclipse.)
Figure 6. Step 3: Specifying what applications to deploy
Now that you've seen some of the different options for remote deployment, let's deploy the sample application using the Geronimo Deployment Tool.
Deployment example: deploying remoteApp
This example uses the Apache Geronimo Deployment Tool. However, it would be just as easy to use the Administration Console or Eclipse to deploy the application. During development it may be a simple matter of preference, although a production system might require the deployment tool to be used.
To use the deployment tool, you'll have to make sure that the remote environment has access to the local file system. In a Microsoft® Windows® environment, you can do this by mapping a network drive. In this example, the remote system has a mapped network drive of Y: that maps to the local system's %GERONIMO_HOME%/deploy directory. This is a logical choice since you would probably test your application locally first; thus your application could already be sitting in this directory. The command for deployment now is simple:
java -jar %GERONIMO_HOME%/bin/deployer.jar --user system
--password manager --host aristotle deploy remoteApp.war
Here, aristotle is the name of the remote server. The --host option was used to specify the remote host instead of using the URI for it. The --port option was not used; thus Geronimo will use the default RMI port of 1099. You should see output similar to what is shown in Listing 4.
Listing 4. Remote deployment of sample application using Deployment Tool
C:\dev\geronimo-1.0\deploy>java -jar %GERONIMO_HOME%/bin/deployer.jar
--host aristotle --user system --password manager deploy remoteApp.war
Uploading 1 file(s) to server
File upload complete (Server: OK)
1 file(s) transferred to server. Resuming deployment operation.
Deployed HelloRemote @ http://aristotle:8080/helloRemote
|
After you've deployed the application, you can log in to the remote admin console and, as Figure 7 shows, see that the application is there.
Figure 7. The Geronimo Administration Console: installed Web applications
To get to the list of installed Web applications, click the Web App WARs link in the left menu under the Applications folder. You should see HelloRemote (that was the ID used for the application in the Geronimo deployment plan) at the top of the list. Notice that the Administration Console shows that HelloRemote is running and gives you the ability to stop it and even uninstall it. It also shows other Web applications running on Geronimo. The list shown in Figure 7, above, shows all the standard Web applications that are running on a default installation of Geronimo with Jetty. It includes the JavaServer Pages (JSP) and servlet examples. Remember the remote-deploy Web application mentioned earlier? You should see it in the list, too.
Of course, the easiest way to make sure your Web application is running is to access it directly through your Web browser. When you deployed the sample application using the Geronimo Deployment Tool, it gave you the URL of your Web application. Enter that address into your browser, and you should see something like the display shown in Figure 8.
Figure 8. remoteApp deployed to a remote server
The results displayed in Figure 8 show that your application has been deployed to the remote server and is up and running there.
Remote deployment is an essential feature for any J2EE application server. It's one of the reasons Java technology is so well suited to the enterprise. Geronimo provides remote deployment in a standardized way by fully implementing JSR 88. It also provides additional deployment methods to make it easier to develop, deploy, and test applications.
Learn
- Read "Create, deploy, and debug Apache Geronimo applications" (developerWorks, May 2005) to learn how to use Eclipse to deploy your application to a remote instance of Geronimo.
- Check out "Building a better J2EE server, the open source way" (developerWorks, May 2005) for a great read on the development process behind Geronimo, including its JSR 88 support.
- Learn about Geronimo's support for the full J2EE 1.4 specification in "Geronimo! Part 1: The J2EE 1.4 engine that could" (developerWorks, May 2005).
- Read the JCP specification for JSR 88.
- Read "Understand Geronimo's deployment architecture" (developerWorks, August 2005) for a detailed description of Geronimo deployment plans and how Geronimo uses them.
- Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
- Check out the developerWorks Apache Geronimo project area for articles, tutorials, and other resources to help you get started developing with Geronimo today.
- Check out the IBM Support for Apache Geronimo offering, which lets you develop Geronimo applications backed by world-class IBM support.
- Find helpful resources for beginners and experienced users at the Get started now with Apache Geronimo section of developerWorks.
- Read The Geronimo renegade column for the latest info on the Apache Geronimo project.
- Get more information on the Eclipse Web Tools Platform.
- Browse all the Apache articles and free Apache tutorials available in the developerWorks Open source zone.
- Browse for books on these and other technical topics at the Safari bookstore.
Get products and technologies
- Download the latest release of Apache Geronimo.
- Innovate your next open source development project with IBM trial software, available for download or on DVD.
- Download your free copy of IBM WebSphere® Application Server Community Edition V1.0 -- a lightweight J2EE application server built on Apache Geronimo open source technology that is designed to help you accelerate your development and deployment efforts.
Discuss
- Participate in the discussion forum.
- Stay up to date on Geronimo developments at the Apache Geronimo blog.
- Get involved in the developerWorks community by participating in developerWorks blogs.
Table of contents
Next steps from IBM
Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).
- Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
- Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
- Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
- Demo: This demo shows how to use the new Java EE 5 Java Persistence API (JPA) framework.
- Buy: Rational Application Developer
