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

Spring
The Spring Framework was very useful in allowing us to develop our application in a container-agnostic fashion. We took advantage of several of the many features of Spring.

  1. Service Location: We used Spring application contexts for the integration with Struts, for deployments to Tomcat and WebSphere, in standalone utility applications, and even in JUnit tests. Spring allowed us to standardize how our service objects were found and initialized across all uses of those objects in a compelling way.
  2. Bean Life Cycle and Dependency Management: By using Spring's application contexts, we successfully avoided stateless session beans that would have caused deployment issues across containers (not to mention the fact that Tomcat would not have readily supported EJBs).
  3. JDBC Template Code: The Spring JDBC APIs allowed for facile database coding - much cleaner code and standardization along the lines of connection management and exception handling.
  4. Flexible Data Sources: The Spring model of using beans to wire together dependent objects allowed us to use extra-container data sources. This came with the benefit of standardized usage of data sources across our runtime scenarios - no fiddling around with container-specific data source configuration.
Jakarta Commons Logging API
We used the Jakarta Commons Logging API from the beginning. It provides a very useful abstraction of typical logging needs while supplying useful hooks for plugging in various logging services such as Log4j, the Java Logging API, etc. WebSphere even provides a gateway to its own tracing facility. The ws-commons-logging.jar in the lib directory off the WebSphere installation root directory allows for logging of classes to be controlled via the WebSphere Administrative Console - as long as those classes were coded to use the Jakarta Commons Logging API.

Commons Logging allowed us to configure which plugin to use (e.g., Log4J in a Tomcat environment, WebSphere logging in that environment) and - via its default implementation that simply writes to the console - to trace unit test code without the need to configure or enable a logging service. In addition, we were able to completely turn off logging via configuration files. (This is done by placing a file called commons-logging.properties on the classpath with the line org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog in it). In fact, this was the standard configuration for running our unit tests, which were run as part of every build. Of course, if a unit test failed, logging could be turned on again as a diagnostic tactic by setting org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog.

What About the Risks?
After a year of real-life experience of developing several applications and performing multiple production deployments with this configuration, we feel that developing on Tomcat and deploying to WebSphere is a low-risk strategy. Once the environments were set up and the deployment process automated, there were very few problems. Spring provided the necessary container capabilities that we needed in a portable way. We were able to take advantage of Spring's bean management, service locator, data source, and JDBC abstractions.

Differences in the security infrastructure were overcome by using Tomcat's built-in features and by providing stub code in the service layer of the development envi-ronment that simulated the presence of TAM. We were able to use the same LDAP server in development (with Tomcat security) and in QA (with Tivoli Access Manager security).

Over time, the cost-saving aspect of cross-platform development became less important in favor of other advantages that were initially not anticipated. The lightweight development environment turned out to be a great advantage, and being forced to layer the application architecture to achieve isolation from the container produced cleaner and better maintainable application code - something that reduced the overall project risks, not increased them.

Summary
It takes a good amount of planning to develop on Tomcat and successfully deploy to a WebSphere environment. Open source frameworks, such as Spring and Struts, can be used to shield an application from platform-dependent implementation details. Ant is a handy tool that facilitates cross-platform deployments. Special consideration is required to handle application security across different platforms. Coding guidelines designed to avoid platform-dependencies must be followed rigorously.

With all these things in mind, cross-platform Java development is a rewarding goal, because your resulting application will be cleaner, easier to maintain, and can provide a real cost advantage.

Resources and Links

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.