Multitier Model for Architecting Distributed Applications²

Before discussing the challenges of building a J2EE application, it is important to understand the model provided by the J2EE platform for architecting distributed applications.  This multitier model is like a client server model because the application components either reside on a client or on a server. However, the multitier model differs from the client server model because more than one tier can exist on the server side.

J2EE applications are typically implemented in three or more tiers. The client tier contains the presentation logic that renders the graphical user interface (GUI) on the client. The middle tier (which may contain sub-tiers) contains the business logic in the Enterprise JavaBeans^TM (EJB^TM) tier, and the client services in the web tier. The middle tier, with its business logic and client services, resides on a server. The back-end tier, or Enterprise Information Systems (EIS) tier, provides interfaces to enterprise information systems, such as database management systems. Like the middle tier, the back-end tier also resides on a server.

This multitier architecture allows different parts of the distributed application to run on different machines. Even different server components can reside on different servers.

With an understanding of the multitier model supported by the J2EE platform, we can now briefly examine how a J2EE application is constructed. The key concept to understand here is that of a component. A component is the basic building block of a J2EE application. Stated concisely in Designing Enterprise Applications with the J2EE^TM Platform, Second Edition, "a component is an application-level software unit."³

Now let's discuss the different types of J2EE components. The J2EE standard defines the following component types: application clients, applets, web components, and Enterprise JavaBeans components called enterprise beans.⁴ Application clients are GUI programs that execute on a client (typically a desktop computer) and interact with the EJB tier.⁵ Applets are GUI programs that execute in a web browser on a client.⁶ Web components, which consist of servlets and JavaServer Pages^TM (JSP^TM), provide dynamic content from a server. A servlet is a compiled Java class that extends a J2EE-compatible web server by generating dynamic content.⁷ A JSP page is a web document that contains both fixed template text, like an HTML page, and special markup that is used to specify dynamic content.⁸ Enterprise beans are components that allow a developer to write business objects that use the services of the J2EE platform.⁹  Like web components, enterprise beans also execute on a server.

¹ Shannon, Bill. April 11, 2003. Java^TM 2 Platform Enterprise Edition Specification, v1.4, page 5. Sun Microsystems. 

² Singh, Inderjeet, Beth Stearns, Mark Johnson, and the Enterprise Team. 2002. Designing Enterprise Applications with the J2EE^TM Platform, Second Edition, pages 6-7. Addison-Wesley.

³ Singh, Inderjeet, Beth Stearns, Mark Johnson, and the Enterprise Team. 2002. Designing Enterprise Applications with the J2EE^TM Platform, Second Edition, page 25. Addison-Wesley.

⁴ Shannon, Bill. April 11, 2003. Java^TM 2 Platform Enterprise Edition Specification, v1.4, pages 6-7. Sun Microsystems.

⁵ Shannon, Bill. April 11, 2003. Java^TM 2 Platform Enterprise Edition Specification, v1.4, page 6. Sun Microsystems.

⁶ Shannon, Bill. April 11, 2003. Java^TM 2 Platform Enterprise Edition Specification, v1.4, page 6. Sun Microsystems.

Now that we know about components, the basic building blocks of a J2EE application, we can look at how these building blocks are assembled. The manner in which a J2EE application is built and deployed stems from the type of deployment unit used. The J2EE standard defines three types of deployment units: stand-alone J2EE modules, J2EE applications consisting of J2EE modules, and class libraries packaged as JAR files.¹⁰ 

Building a J2EE application consists of building the modules that make up the application. J2EE components of the same type are combined with module-level deployment descriptors to form J2EE modules. J2EE modules can be deployed as stand-alone units or they can be combined with J2EE application deployment descriptors to form a J2EE application.¹¹ Deployment descriptors are XML files that specify component and container behavior.¹²

The modules that comprise a J2EE application are packaged into a file called an enterprise archive or EAR file. The EAR file consists of one or more J2EE components along with a J2EE application deployment descriptor. 

When a J2EE application is built, an EAR file is constructed with J2EE modules packaged as JAR, EJB JAR, WAR, and RAR files. Client components, typically Java class files, are packaged in a Java archive (JAR) file. Enterprise Java Beans (EJBs), the Java class files that comprise the middle tier business logic, are packaged as EJB JAR files. An EJB JAR file differs from a JAR file because it also includes a deployment descriptor that contains meta-information about enterprise beans.¹³ Web content is packaged in a web archive (WAR) file. The WAR file is a JAR format file that contains web resources, such as static HTML files, JSP pages, and Java JAR and class files. The components that implement a Java Connector are packaged in a JAR format file called a resource adapter archive (RAR) file.

Now that we know how J2EE is structured, we can focus on issues surrounding build and deployment. One of the major challenges faced in building and deploying a J2EE application involves constructing the EAR file. While the process of building the EAR file is relatively straightforward, the decision about what to include in the EAR file may not be clear-cut.

⁷ Singh, Inderjeet, Beth Stearns, Mark Johnson, and the Enterprise Team. 2002. Designing Enterprise Applications with the J2EE^TM Platform, Second Edition, page 79. Addison-Wesley.

⁸ Singh, Inderjeet, Beth Stearns, Mark Johnson, and the Enterprise Team. 2002. Designing Enterprise Applications with the J2EE^TM Platform, Second Edition, page 80. Addison-Wesley.

⁹ Singh, Inderjeet, Beth Stearns, Mark Johnson, and the Enterprise Team. 2002. Designing Enterprise Applications with the J2EE^TM Platform, Second Edition, page 135. Addison-Wesley.

¹⁰ Shannon, Bill. April 11, 2003. Java^TM 2 Platform Enterprise Edition Specification, v1.4, page 127. Sun Microsystems.

¹¹ Singh, Inderjeet, Beth Stearns, Mark Johnson, and the Enterprise Team. 2002. Designing Enterprise Applications with the J2EE^TM Platform, Second Edition, page 118. Addison-Wesley.

¹² Singh, Inderjeet, Beth Stearns, Mark Johnson, and the Enterprise Team. 2002. Designing Enterprise Applications with the J2EE^TM Platform, Second Edition, pages 223-224. Addison-Wesley.

¹³ Singh, Inderjeet, Beth Stearns, Mark Johnson, and the Enterprise Team. 2002. Designing Enterprise Applications with the J2EE^TM Platform, Second Edition, page 210. Addison-Wesley.

The J2EE specifications dictate the use of an EAR file to deploy one or more web applications to an application server. Unfortunately, J2EE development environments offer little support for important enterprise activities, such as integration builds and deployment. Organizations that develop J2EE applications, typically want to build the application for a project's development integration environment then promote the built application through various test environments, such as system integration test (SIT) and user acceptance test (UAT). To ensure that the fully tested application is deployed to the production environment, the J2EE application that was built initially for the project's system or user acceptance test environment should eventually be promoted to production.

The EAR file is nothing more than a file that contains other files. It is much like a Windows zip or UNIX tar file.  The EAR file format is the same as the Java JAR file format. However, the J2EE standard specifies that the file and folder structure embedded in the EAR file contain certain files and maintain a certain directory or folder structure.  At runtime, the EAR is exploded and its contents are provided in the native operating system file and folder structure.  The file contents and folder structure are critical to the success of J2EE, but the EAR file itself is primarily a delivery vehicle for the application server.  The EAR file is well-suited for small application environments. Its problems appear more with increasing application scale in terms of total number of files.  

The use of an EAR file for building and deploying J2EE applications can prevent an application from being built once and promoted through a series of test environments to a production environment. The reason for this problem is the requirement to construct EAR files with different contents - one per environment. For example, for testing, the J2EE modules are usually required to connect to a test instance of database while for production, the same modules must reference a production database. Java developers often prefer to provide this information in the form of a properties file (the Java equivalent to an ini file).  If this file is bundled into the EAR, the EAR becomes tied to a specific environment and loses its portability. This is a significant departure from native executable and even pre-J2EE Java deployment because a different EAR file needs to be constructed to support each environment. Unfortunately, the burden for satisfying the deployment requirement of having a different EAR for each environment falls squarely onto build management.  Where in the past, a single build would be used for all late-stage test and production environments, now multiple, distinct builds must be created.

Since the EAR file is used primarily as a vehicle for deploying files to an application server, J2EE applications can be built by simply building the modules that make up the EAR file. These modules are packaged as JAR, EJB JAR, and WAR files. Ideally, these modules would be built a minimal number of times (for each planned deployment) using either an open source scripting language or a commercial build automation tool. Once built, these modules would then be promoted through a series of environments from testing, typically system or user acceptance, through to production.

Two important issues arise when using an EAR file to build and deploy a J2EE application. The first issue involves the loss of audit if you build a different EAR file for each environment, e.g., SIT, UAT, and production. The second issue involves the increased overhead of installing an EAR file each time a new build is deployed.

A common rule of thumb when developing distributed applications is to deploy what is tested. Unfortunately, this practice cannot be followed if the content of the EAR file depends on the environment in which it will be deployed. Since a different EAR file must be built for each environment, there is no guarantee that the application that was built and tested in one environment is equivalent to the application that is built and tested in the next environment.

If an EAR file is built every time a new version of the J2EE application is to be deployed, the existing EAR file may need to be completely uninstalled before a new one can be deployed. (The application server used dictates whether an existing EAR file must be uninstalled before a new one can be installed.) Given the frequency of changes to web content in J2EE applications, an organization may need to uninstall then reinstall the EAR file one or more times each day. Consider the resource overhead of removing a thousand files and then replacing most of those files with identical versions when only a few dozen files may actually have changed.

This problem is particular costly for JSP files that have not changed, but have been redeployed because the EAR file contains a complete copy of the application.  Java's expansion of any JAR-family type file (JAR, EAR, WAR, and RAR) updates the timestamp of every file extracted, and the application server is now unable to detect which files have changed from the previous installation and recompiles every JSP file whether it needed to or not.  Now, not only is unnecessary compilation taking place, but it is happening in the production environment too.

Given the issues that may arise when building and deploying an EAR file, there are two strategies presented here that an organization can follow for building and deploying J2EE applications. The first strategy is to deploy only stand-alone J2EE modules or individual files, rather than a J2EE application consisting of J2EE modules. The second strategy is to build a reference EAR file once, and then apply a process to create the actual environment-specific EAR files from the reference EAR file.

Assuming that the appropriate directory structure is initially created on all target servers, the deployment process need only consist of replacing the JAR and WAR files on the server that were modified from the previous deployment. This alleviates the need to deploy and expand an entire EAR file. However, server specific content would still need to be deployed to each target server.

To create the appropriate directory structure on the target servers, the necessary EAR files could be created at the start of the project and expanded on these servers. This is analogous to creating the appropriate directory structure by initially extracting the contents of a Windows zip or UNIX tar to a top level target directory.

In the case of over-compiling JSP files, deploying the WAR file stand-alone will not solve the problem because the WAR expansion itself updates the JSP timestamps.  Some users have resorted to deploying individual JSP files directly into the modules' runtime file system.  Others have resorted to using a third-party JAR expansion tool in lieu of the application server's default module installation.  Tools such as WinZip do not update file timestamps when expanding JAR-type files.

One strategy that has been successfully implemented is to build a reference (environment-independent) EAR file. This EAR file does not have environment-specific information such as which database to connect to, and so is not viable for controlled testing or production runtime environments.  This Reference EAR file is then used as the source for creating a set of environment-specific EAR files each containing the respective properties file for the target environment in addition to the contents of the Reference EAR file.  It is best if the Reference and environment-specific EAR files are built in a single pass, build-once-and-bundle-many approach to ensure they are built from a single source configuration.  There are a number of advantages to this approach: 

• The Reference EAR file can be deployed directly to development testing environments where pre-existing properties files exist.
• The age-old practice of using file sizes and timestamp comparisons can be used by developers to make quick assessments of J2EE application versions by comparing two different Reference EAR files.
• Advantage can be taken of sophisticated CM and build tools to reproducibly control, create and identify (audit) the environment specific EAR files without placing additional burden on developers.

The J2EE platform provides superb logical container organization, however, the use of an EAR file to preserve this organization can create build and deployment challenges if the EAR file content differs for each target environment. To avoid building a unique EAR file for, and deploying this EAR file to, each environment, the build engineer can elect to build and deploy only the components of the EAR file. Alternatively, the build engineer can build a Reference EAR file to use as a template for creating the EAR file for each target environment.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment