Page 1 of 3   next page »

In a market that is defined by today's tight IT budgets, saving on software licenses can mean the difference between financial failure and success for a software development project. While our corporate clients use commercial-grade application servers, we sometimes find ourselves in a situation where there are no funds for developer licenses of these commercial application servers. Out of necessity, we developed and implemented a process that allows for development on top of an open source stack, while production delivery relies on a commercial application server.

Initial concerns that implementation differences and the different runtime environments would lead to issue-prone deployments turned out to be unjustified. While different application servers do indeed show incompatibilities, we found that we were able to avoid common pitfalls through preparation and disciplined coding. In this article, we will explain what it takes to develop complex Web applications with Eclipse and Tomcat and to deploy these applications to a WebSphere-based production environment.

Introduction
It all started when a client requested a solution for the WebSphere application server platform, but did not want to cover the cost of WebSphere Studio licenses for the development team. We looked for alternatives and found one in Eclipse and Tomcat.

The team initially feared that the different implementation of core functionalities provided by application server containers would create application portability issues. The main areas of concern included transaction management, security, and application deployment.

Because we used IBM's Tivoli Access Manager and WebSEAL Reverse Proxy in production, but relied on Tomcat's built-in authentication in development, there was concern that having only a subset of the target security infrastructure available in development would limit our ability to build a security service layer for Tivoli.

These risks had to be addressed and dealt with. At that time it seemed that the cost of doing so would outweigh the potential savings from software licenses. However strong this concern was, it was difficult to convey it to a client who was eager to start the project, and so we embarked on the open source endeavor.

Developing with Eclipse and Tomcat
Once properly configured, Eclipse can be a powerful hub for developing your application. It can automatically generate content and code such as class header comments, implementations of functions from interfaces, variable getters and setters, and more. These time-saving tools, along with the multitude of available plug-ins (e.g., for Tomcat, VSS, and Struts) allowed us to spend less time performing repetitive tasks and more time actually developing.

We created a project in Eclipse with its root reflecting the root of our Web application, which would later be packaged into a WAR (Web Application Archive), then an EAR (Enterprise Archive), along with the required application configuration files, for deployment to WebSphere. This root directory was located within the "webapps" directory of our Tomcat installation, which is the default directory that Tomcat allocates for Web applications.

Although the Tomcat plug-in for Eclipse does not add any new functionality to either product, it greatly eases the integration of the two and saves time by consolidating common tasks in one place and reducing the need for multitasking. Debugging in Eclipse is fairly robust, allowing the user to step through code and to evaluate expressions on the fly. The JDK we were using (IBM 1.3.1) does not support hot-replacing of classes, but new code is loaded on an application server restart, which does not take much time.

It should be mentioned that Tomcat does not support Enterprise beans. We decided against Enterprise beans because the Spring framework provides similar features without the platform dependencies.

The Microsoft Visual SourceSafe plug-in integrates well into the Eclipse interface, allowing for comments on both checkout and check-in. It also provides a report of all files checked out within the project, the owner, and what actions are being performed on them. The only gripe is that when checking-in files, it does not remember the checkout comment, so it must be reentered manually.

There are a few aspects to take into consideration when bridging the gap between the development and production environments. User authentication, handled by Tivoli Acess Manager in production, was handled by the tomcat-users.xml file located in the config directory. Roles, users, and passwords are recorded in this file. Through the use of configuration files and Ant, we were able to easily change server locations and credentials, as well as any other variables that may need to change when code is moved between environments. Tomcat tends to be much more forgiving when it comes to parsing configuration files such as the web.xml and tag library definitions, whereas WebSphere will either load the application in a crippled state or not at all. The dtds must be adhered to in order to avoid this issue.

Production Environment
The production environment was a load-balanced configuration of two application servers and several other servers hosting the security environment (Tivoli Access Manager) and the database (see Tables 1 and 2 and Figure 1).

Multiple Environments
In most software development projects, to support the life cycle of the application, there are multiple environments into which the code must be deployed (see Figure 2).

When the application is deployed from one environment to another, various things need to change, such as database data source information and LDAP server information. We used Ant's property filtering capability to generate runtime resource files, such as properties files and Spring application context files, with the correct information appropriate to each environment.

We recommend the following steps to make this work:

1. Define a deploy.host property and assign a value according to the hostname of the target deployment environment
2. Create a separate properties file for each host with environment-specific values. For example, JDBC property definitions for serverA might be defined in serverA.properties as follows:

   #
   # Database overrides
   #
   jdbc.driver.classname = net.sourceforge.jtds.jdbc.Driver
   jdbc.driver.type = jtds
   jdbc.server.type = sqlserver
   jdbc.server.port = 1433
   jdbc.server.host = db01
   jdbc.username = db01-user
   jdbc.password = db01-pwd

3. Create Ant filter token definitions that use the environment-specific properties:

   <filterset id="project.filter.tokens">
      <!-- DB Service(s) -->
      <filter token="JDBC.DRIVER.CLASSNAME" value="${jdbc.driver.classname}"/>
      <filter token="JDBC.DRIVER.TYPE" value="${jdbc.driver.type}"/>
      <filter token="JDBC.SERVER.TYPE" value="${jdbc.server.type}"/>
      <filter token="JDBC.SERVER.HOST" value="${jdbc.server.host}"/>
      <filter token="JDBC.SERVER.PORT" value="${jdbc.server.port}"/>
      <filter token="JDBC.USERNAME" value="${jdbc.username}"/>
      <filter token="JDBC.PASSWORD" value="${jdbc.password}"/>
   </filterset>

4. Create a properties file containing the filter tokens. Ant will substitute actual values for the tokens:

   jdbc.driverClassName = @JDBC.DRIVER.CLASSNAME@
   jdbc.url = jdbc:@JDBC.DRIVER.TYPE@:@JDBC.SERVER.TYPE@:
   //@JDBC.SERVER.HOST@:@JDBC.SERVER.PORT@
   jdbc.username = @JDBC.USERNAME@
   jdbc.password = @JDBC.PASSWORD@

5. Place a copy task in some target that invokes the filter token substitution (<filterset>):

   
   <target name="copy-files" depends="">
     <!-- Copy, with overwrite, properties and xml files
       -  so that configuration changes via Ant build properties
       -  will always be picked up.
     -->
     <copy todir="${web.build.dir}" overwrite="yes">
       <fileset dir="${web.src.dir}">
         <include name="**/*.properties" />
         <include name="**/*.xml" />
       </fileset>
       <filterset refid="project.filter.tokens" />
     </copy>
   </target>
   

Page 1 of 3   next page »