Ilia Papas

Subscribe to Ilia Papas: eMailAlertsEmail Alerts
Get Ilia Papas: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Apache Web Server Journal, Open Web Magazine

Apache Web Server: Article

Benefiting from Open Source Development

Saving on software licenses can mean the difference between financial failure and success

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>
When the application is packaged, it looks in (among other places) ${web.build.dir} for files to include in the Web application archive (WAR). There, it will find the generated runtime resources with environment-specific values.

More Stories By Christian Donner

Christian Donner has 20 years of experience in project delivery and consulting. His professional focus includes EAI, BI, CRM, supporting business strategy through the development, implementation, and maintenance of mission critical systems. He is a senior technical architect at Molecular, a Web consulting firm located in the Boston area, and has written for both Java Developer's Journal and .NET Developer's Journal. He can be reached at pubs2005@cdonner.com.

More Stories By Sumitra Chary

Sumitra Chary is a senior software engineer at Molecular. Her career has spanned both academic and commercial worlds. These have included software systems for X-ray observatory missions, network management, marketing automation, and enterprise Web applications.

More Stories By Jim Lamoureaux

Jim Lamoureaux is a senior consultant and software architect at Molecular. His interests include object-oriented design and implementation, programming languages, and software process. Jim is a Sun Certified Programmer for the Java 2 Platform. He currently lives in Southern New Hampshire.

More Stories By Ilia Papas

Ilia Papas is a software engineer at Molecular. He has been working with web applications for five years and has interests in the design and implementation of enterprise applications using a variety of technologies. He currently lives in the Boston area.

More Stories By Dita Vyslouzil

Dita Vyslouzil is a Consultant and Technical Architect in the Engineering group at Molecular in Watertown. She has been in software development for 7 years, concentrating in transactional web applications.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
SYS-CON Italy News Desk 02/05/06 01:37:22 PM EST

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.