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

SIDEBAR

Tivoli Access Manager
The production security configuration followed the recommendations for Tivoli implementations published by IBM. The setup consisted of two WebSEAL servers, two Web/application servers, one policy server, and a master/replica LDAP configuration. The application servers hosted all of the applications with WebSEAL tying to each application through an IP/Port specific junction (a "junction" is a resource mapping and defines the true location of a URI). This necessitates multiple network cards in the WebSEAL machines in order to support multiple host addresses that are on the standard Web port.

Each production WebSEAL instance had numerous junctions configured to the multiple applications. The configuration was also set up for failover by ensuring that the server UUID configured in the junctions matched on each machine; therefore cookies for session fail-over could be picked up by either WebSEAL instance.

Choosing to install the Authorization Server on each application server created policy server redundancy. The authorization servers act as a replica of Policy server information. As a default, when the authorization server is installed, the application server does not hit the policy server directly in most cases because it obtains authorization information directly from the authorization server. The only time the policy server is reached is for any account updates. All these settings can be found in a configuration file (webseald.conf). Choosing to follow the authorization server route ensures application availability in case the policy server is down - it's a more economical method for fail-over than a master/replica policy server configuration.

Sidebar 2

Configuring Ant for Deployments Between Different Application Servers
We used Ant (Ant 1.6+) to manage configuration, builds, and deployments from local development environments to the integration server, from there to the staging server, and finally to production. The ant scripts needed to handle two main server differences:

  1. The WEB-INF/lib directory had to be populated with any JARs not provided by the application server. Specifically, our Tomcat environment required the optional JDBC 2.0 Package while WebSphere already came with the necessary classes installed.
  2. The security-* elements of the Web deployment descriptor (web.xml) needed to include security-role definitions for deployments to Tomcat. In WebSphere, the security roles were defined at the enterprise application level (application.xml). The solution was to treat any environment dependencies through parameters and to create configuration files that contained all settings for a server type. We laid the groundwork by explicitly providing a value for the server.type Ant property:

    <!-- Server Type property-override customizations (if any) -->
    <property name="server.type.config.file"
    location="${build.modules.home}/deployment/servertypes/${server.type}.properties"/>
    <echo message="server.type.config.file=${server.type.config.file}"/>
    <property file="${server.type.config.file}"/>

    Having a separate properties-file for each server type was helpful, because it made the deployment process agnostic of the type of server that we deployed to. The main property set in each of these files was deploy.tomcat or deploy.websphere (essentially deploy.server-type). Having these properties allowed us to configure the build-war macro according to the server type to handle the inclusion/exclusion of the JDBC 2.0 optional package (see Listing 1).

    Only one of the war-* targets is being called depending upon whether the deploy.websphere property is defined or not. This results in a macro definition of build-war, which has been configured for the target server.

    Similarly simply, the appropriate definitions for the security-* elements of the web.xml are handled according to the value of server.type.

    <!-- Copy the environment-specific version of the web-security.xml XDoclet merge file -->
    <target name="web-security-websphere" if="deploy.websphere">
    <copy file="${web.merge.dir}/was-web-security.xml"
    tofile="${web.merge.dir}/web-security.xml" overwrite="yes"/>
    </target>
    <target name="web-security-tomcat" unless="deploy.websphere">
    <copy file="${web.merge.dir}/tomcat-web-security.xml"
    tofile="${web.merge.dir}/web-security.xml" overwrite="yes"/>
    </target>

    The targets web-security-tomcat and web-security-websphere are then named as dependencies in other targets that use the XDoclet webdoclet task (which uses the web-security.xml deployment descriptor snippet).

    Listing 1: Ant macro for building a WAR file


    <!-- Call the build-war macro that is defined by the dependencies -->
    <target name="package-web"
    depends="webdoclet,war-tomcat,war-websphere">
    <build-war/>
    </target>

    <!-- Setup the build-war macro for a tomcat deploy -->
    <target name="war-tomcat" depends="" unless="deploy.websphere">
    <macrodef name="build-war">
    <sequential>
    <war destfile="${web.dist.dir}/${web.war}"
    webxml="${web.build.dir}/WEB-INF/web.xml"
    compress="true">
    <fileset dir="${web.build.dir}" excludes="**/web.xml" />
    <webinf dir="${struts.dir}" includes="validator.xml,*.dtd" />
    <lib dir="${cfmx.dir}" includes="*.jar" />
    <lib dir="${commons-lang.dir}" includes="*.jar" />
    <lib dir="${dist.dir}" includes="${dist.name}" />
    <lib dir="${jstl.lib.dir}" includes="*.jar" />
    <lib dir="${struts.dir}" includes="*.jar" />
    <lib file="${commons-dbcp.jar}"/>
    <lib file="${commons-pool.jar}"/>
    <lib file="${log4j.jar}" />
    <lib file="${spring.jar}" />
    <lib file="${jdbc.jar}"/>
    <lib file="${jtds.jar}"/>
    </war>
    </sequential>
    </macrodef>
    </target>

    <!-- Setup the build-war macro for a WebSphere deploy -->
    <target name="war-websphere" depends="" if="deploy.websphere">
    <macrodef name="build-war">
    <sequential>
    <war destfile="${web.dist.dir}/${web.war}"
    webxml="${web.build.dir}/WEB-INF/web.xml"
    compress="true">
    <fileset dir="${web.build.dir}" excludes="**/web.xml" />
    <webinf dir="${struts.dir}" includes="validator.xml, *.dtd" />
    <lib dir="${commons-lang.dir}" includes="*.jar" />
    <lib dir="${dist.dir}" includes="${dist.name}"/>
    <lib dir="${jstl.lib.dir}" includes="*.jar" />
    <lib dir="${struts.dir}" includes="*.jar" />
    <lib file="${commons-dbcp.jar}"/>
    <lib file="${commons-pool.jar}"/>
    <lib file="${log4j.jar}" />
    <lib file="${spring.jar}" />
    <lib file="${jtds.jar}"/>
    </war>
    </sequential>
    </macrodef>
    </target>

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.