J2EE applications are becoming the norm rather than the exception in today's distributed computing environment. But organizations are still facing the same issues with this technology set that they did withapplication models of yesteryear - how to ensure that they can scalequickly, respond dynamically, and maintain flexibility as their businessenvironment changes.
These challenges have never been more pressing than they are in today's environment, where business models are changing rapidly as organizations cope with the realities of a cyclical economy.
This article focuses on some of the application characteristics of large-scale J2EE applications and is prescriptive in terms of what we have seen work and not work with large-scale Web applications. In particular, this article considers Web applications designed to support thousands of concurrent users. Areas covered include the importance and impact of up-front architectural decisions, development steps to help ensure smooth deployments, performance tuning, and production deployment planning and design.
Considering Architectural Approaches
Because of the popularity of both Java and J2EE, organizations have an unprecedented variety of portable software to draw on in the formation of their architectural standards. Since J2EE currently focuses more on application portability and less on the underlying implementation and operational characteristics of an application server, it's important for organizations to look beyond the J2EE programming model and concentrate on how key decisions will impact the operational characteristics of the deployed systems. Apart from decisions related to the underlying hardware and operating systems, the following architectural considerations will weigh most heavily on the performance of the operational environment.
- Select application server: To an extent not seen with other Web and enterprise component platforms, the J2EE platform enables an organization to base the bulk of its development investment on the portable base platform and layered frameworks rather than on vendor-specific APIs and features. The adoption of J2EE has allowed organizations to worry less about comparing application development environments, but they still need to perform a comprehensive evaluation of the available J2EE-compliant application server products to ensure that the products meet the organization's operational requirements. Switching application servers midway through development of a J2EE-based application effort will moderately impact the delivery schedule. However, given the investment necessary to train operational teams on the product-specific processes and features, switching application server products near or during the deployment phase will result in significant additional costs and extended deployment delays.
- Examine Web presentation layer frameworks: Almost any Web application will benefit greatly from the use of a prebuilt Web presentation layer framework. For example, the Apache Jakarta project's Cocoon and Struts Web presentation layer frameworks have become very popular with many J2EE developers. Although some teams will be hesitant to build the Web presentation layer on a third-party framework, most organizations end up developing a generic infrastructure that sits between the base J2EE Web container services and business presentation logic - whether or not they call it a framework. In addition to the time savings they generate, such frameworks are portable across almost any J2EE Web container implementation. Although the popular frameworks evolved with JSPs and servlets prior to the formal J2EE specification, the relative newness of the frameworks warrants caution when considering them for production use. It's advisable to thoroughly test any adopted framework in a production-like environment to ensure that stability and performance requirements are met.
