Page 1 of 2   next page »

Enterprise Application aRchive (EAR) files are a standard and portable manner for packaging applications to be deployed on J2EE application servers, such as Adobe JRun, BEA WebLogic, and IBM WebSphere. An EAR file is, in essence, just a big ZIP file with a special layout of the directory tree inside that contains a full application, see the following code. EAR files have a well-defined format and make Java bytecode truly portable. The same EAR file that we compile and build on our i386 Windows laptop can also run on a 64-CPU mainframe running commercial Unix.

Directory Structure of an EAR file application.ear

• META-INF
• application.xml
• contextroot.war
• CFML source
• HTML sources
• CSS
• images
• WEB-INF
• web.xml
• ColdFusion runtime

In this article you will learn why it is beneficial to deliver your ColdFusion applications using EAR files. We will also explain what to watch out for when you design applications that you are planning to deliver in an EAR file.

Requirements
ColdFusion MX 7 Enterprise
To try, go to http://www.adobe.com/go/devcenter_cf_try, and to buy, go to: www.adobe.com/go/devcenter_cf_buy.

Note: You will need to install the ColdFusion multiserver installation. This option is available in the licensed Enterprise Edition, the Developer Edition, or in the 30-day trial edition of ColdFusion MX 7. This requires that you download the trial or purchase the Enterprise, Evaluation, or Developer Edition. You must select "multiserver configuration" during the installation process.

Apache Ant
Download Apache Ant from http://ant.apache.org/.

Prerequisite Knowledge

• Basic understanding of ColdFusion
• Basic J2EE knowledge

On the business side, J2EE is a standard technology that has a lot of traction. If your customers already have a J2EE environment, ColdFusion will fit in without changes to their infrastructure. If you want, you can even position ColdFusion as a 4GL language for rapid application development. All that the server administrator sees is an EAR file; it may be big but an EAR file is like any other EAR file. This advantage can open a whole new market that was previously the exclusive domain of Java shops.

On the technical side, EAR files can provide more than just a format for delivering your code. Because EAR files can include the complete ColdFusion runtime, you can also package additional components like database drivers and preconfigured ColdFusion runtime settings. This means you can deliver your application to your customer with far fewer instructions for installation and configuration - greatly reducing the risk of a deployment error.

Combined with the J2EE underpinnings, using EAR files makes it easier to deploy your application in more than one instance on one or more servers. You also have the option to combine these instances into a cluster that provides fault-tolerance and increases the scalability of the application you are deploying.

From a support standpoint, we have all been there: a customer reports that the latest patch doesn't work. After several hours of frantic debugging, you discover that the issue is that the customer never installed a previous patch. However, if you deliver your application as an EAR file, you can ensure that the customer has installed the latest version of every file because each EAR file you deliver contains the entire application.

Challenges to Deploying Applications as EAR Files
There are challenges to delivering your application as an EAR file. Some of the aforementioned advantages can, in other contexts, become disadvantages. For instance, because all the code is compiled and packaged in the EAR file, the customer cannot tinker with it. This also means that you cannot tinker with it after preparing it. If you frequently have to add last-minute, one-line adjustments to your code during deployment, you might find yourself at a disadvantage.

Likewise, creating EAR files requires that you own the ColdFusion Enterprise Edition. You can still develop and build your application using ColdFusion Developer Edition on your local host, but for deployment you must own an Enterprise Edition license for every two CPUs on which you deploy your application. EAR deployments will not work on ColdFusion Standard Edition.

The biggest challenge is how your application interacts with its environment. Because you are delivering a self-contained application, you must be sure to put everything in the EAR file - code, HTML, CSS, additional components, and so forth. Deploying the application should require as little configuration as possible, both to make it easier for your customer and to reduce the chance of something going wrong.

For interaction with the Web server, the most important issue is that you pick the right context-root. The context-root is the subdirectory under which the application is located. By selecting different context-roots, you can deploy multiple applications on one Website. Putting your application in a subdirectory also enables you to handle uploaded user content gracefully (such as avatars on a forum): you can upload them to a sibling directory of the application so the Web server can process them directly. Don't be greedy and use / as the context-root. Because you don't know if the person who deploys your application is going to use an empty J2EE server instance or not, you should develop your application to always run inside a context-root. All paths in your application should be relative to this context-root. When you create your application, choose a context-root so that the name is unique on the deployment server; don't use any common names, such as "admin."

Some of the challenges require you to think about your application in a whole new way. When you package your application as an EAR file, the J2EE server has to expand the application before it can run it. Some J2EE servers, like JRun, do so automatically, which adds some overhead the first time it starts. Others, like WebSphere, require the server administrator to expand the EAR file manually when deploying on it. J2EE servers that expand the EAR file automatically do so to a temporary directory and start the application from there.

One side-effect of this is that the application no longer knows where the EAR file is located; the application knows only the temporary directory to which it was extracted. As a result, when you change something using the ColdFusion Administrator, it ends up in the temporary directory and not in the EAR file. Therefore, if the server administrator moves the EAR file from one server to another, the application will lose any changes that you have made using the ColdFusion Administrator. Even worse, if the operating system deletes all temporary files upon reboot, you will lose all your changes to the ColdFusion Administrator just by rebooting the system. Luckily, this is largely a theoretical problem. Still, if possible, deploy your application as an expanded EAR file. Be mindful of this issue, because even when deploying an expanded EAR file, it will affect your settings when the server administrator moves the EAR or you release a new version.

Another way this becomes a problem is in the use of ColdFusion mappings. When ColdFusion starts from the temporary directory, it automatically updates its internal mapping to CFIDE to point to the temporary directory from which it is executed. All the other mappings will not be updated, however.

Page 1 of 2   next page »