The release of ColdFusion MX 7 provides developers with several options for deploying their CFML applications. While the current option of using ColdFusion Archives (CAR files) has worked to this point, a fundamental problem still remains that the source code needed to be included.

However, the two new options available in this release, sourceless and EAR/WAR file deployment, truly give developers the flexibility to deploy their code while optionally preserving their valuable intellectual property. (It is important to note that New Atlanta's BlueDragon Server line has supported sourceless deployment of CFML source code since the introduction of their 6.1 product line in June 2004. All references to sourceless and EAR/WAR deployments as "new features" apply solely to Macromedia ColdFusion MX 7.) Coupled with the streamlined ability to add new ColdFusion instances to an environment via the ColdFusion MX Administrator (Enterprise edition only), much of the manual work associated with application deployment has been automated, allowing the developer to focus on development instead.

Pre-compiled and Sourceless Deployment
Before ColdFusion MX 7, the only option for companies to protect their commercial CFML code distribution was the cfencode utility. However, anybody who has worked with ColdFusion for any reasonable amount of time knows that a simple Internet search will turn up a utility for decompiling the templates, which essentially rendered cfencode pointless. So for many years, all a developer could realistically do was release their code to the public and simply hope that the end user would abide by the license agreement. Further, many companies, not just those selling commercial applications, simply weren't comfortable running production applications without some sort of source code protection.

ColdFusion MX 7 ships with a new cfcompile utility that has two main uses. First, it can be used to simply compile your ColdFusion source code into the resulting Java class files so that the initial load time is quicker. Second, it allows for pre-compiling CFML code (CFM, CFC, and CFR templates) to Java byte code, which can then be deployed without the source templates. This utility, which can be found in the cfroot/bin (for the server configuration) and in the cf_webapp_root/WEB-INF/cfusion/bin (for the multi-server and J2EE configuration) directory, can be run on one template (i.e., a custom tag) or an entire directory structure containing a complete CFML application (i.e, a blogging application).

In both cases, its usage is incredibly simple. To pre-compile CFM, CFC, and CFR templates (note that this is not for sourceless deployment, which will be covered shortly), the general usage is

cfcompile webroot [directory-to-compile]

where webroot is the absolute path to the site's web root and the directory-to-compile is an optional parameter specifying the directory to compile (Note: all sub-directories are automatically compiled as well). If no directory is specified, the utility will compile all CFM, CFC, and CFR templates from the web root, recursively. This usage of cfcompile is the same process that the ColdFusion runtime uses when first loading a page: it parses the file, compiles it, and stores the appropriate class files in the cfclasses directory under your ColdFusion installation. For a small set of files, this might not seem very useful due to the massive compiler optimizations that the ColdFusion MX runtime has received since its first release. However, for large sites, this initial overhead savings could prove valuable.

As an example, the Mach-II framework files are used as the directory structure (the freely available code is located at www.mach-ii.com/code.cfm). Assuming that the web root is C:\Inetpub\wwwroot, the following command-line statement would pre-compile all the templates in the framework:

cfcompile C:/Inetpub/wwwroot C:/Inetpub/wwwroot/MachII

As seen in Figure 1, the forty templates comprising the base framework were compiled in 5.36 seconds. Figure 2 shows the resulting class files in Windows Explorer. A count of the number of resulting class files output shows that 345 files were generated for a total directory size of just over 1 MB (remember, the number of compiled class files is not one-to-one with the number of ColdFusion templates. ColdFusion Components, for example, have their methods broken out into individual class files). Running this utility has just saved the ColdFusion runtime from having to generate over 300 files when they are first loaded!

The second use of this utility lies in its ability to pre-compile templates for sourceless deployment. What this means is that applications can now be distributed without the underlying source code and without the fear that a vendor's intellectual property will be compromised. The general usage is

cfcompile -deploy webroot directory-to-compile output-directory

Once again using the Mach-II core file distribution, the sourceless deployment syntax is

cfcompile -deploy C:/Inetpub/wwwroot C:/Inetpub/wwwroot/MachII
C:/Inetpub/wwwroot/MachII_Sourceless

The major usage difference is the presence of the "-deploy" switch that tells the cfcompile utility to compile the CFML source code to Java byte code. Further, the output-directory is required since the resulting files will still have the same name and file extension as the source files. Once this process is done, it is simply a matter of backing up the original CFML source code and copying the generated byte code templates into the original directory. That's it! You now have a copy of the Mach-II framework that can be run without the original source code!

EAR/WAR Deployment
While the cfcompile utility satisfies the long-standing enhancement request for protection of source code, it does not answer the other request that applications be easier to deploy. ColdFusion MX has been a pure J2EE application since its initial release. A traditional J2EE application is bundled as a EAR (Enterprise Application Archive) or a WAR (Web Application Archive) file. At companies that run a pure J2EE environment, system administrators simply take the EAR/WAR file and drop it into the J2EE instance. However, traditional ColdFusion deployments meant that a server first had to be installed (the ColdFusion runtime) and then the CFML source code installed separately. This did not sit well with system administrators, who felt this two-step process was awkward, and hence limited ColdFusion's adoption in those environments.

To solve this disconnect, ColdFusion MX 7 introduces the option of packaging CFML applications as a EAR or WAR file so that one file can be handed off to the system administrator for deployment. This option means that deployment and management is easier for the system administrator while subsequently allowing ColdFusion to be a viable development alternative when building J2EE applications. Found under the "Packaging & Deployment" section in the ColdFusion MX Administrator (Enterprise version only), the "J2EE Archives (.ear/.war)" option provides a variety of options such as whether or not to include the source code or whether or not to include the ColdFusion Administrator. Figure 3 shows an example of bundling the Mach-II framework into a WAR file (MachII.war).

Having created your EAR or WAR file, it is now literally as easy as sending the resulting file to your system administrator for deployment - no separate server installation is needed!

J2EE Instance Management
Running ColdFusion on multiple instances has many benefits such as application isolation, greater stability, and greater scalability (for more information on the benefits of multiple J2EE instances, see Ben Forta's July 2003 CFDJ article entitled "When One ColdFusion Is Not Enough" at http://sys-con.com/story/?storyid=42050&de=1). Before the release of ColdFusion MX 7, the creation of new J2EE instances in which ColdFusion server would be deployed (remember, ColdFusion MX is simply a standard Java application deployed into a J2EE server) left a lot of additional setup work for administrators. From a separate interface for actually creating the instance (i.e., the JRun Admin console) to the manual editing of the underlying XML configuration files (to get features such as session replication properly working), creating a new instance was too tedious of a process, and one that caused many administrators to forgo the feature.

Recognizing this barrier to multiple instance deployment adoption, Macromedia has included a new feature in the ColdFusion Administrator for creating new J2EE servers with no more than a couple of mouse clicks (Note: this feature is only available if the integrated JRun + ColdFusion option was selected while running the installer. Macromedia did not back-port this option for existing JRun installations.) Found in the ColdFusion MX Administrator under the "Enterprise Manager" navigation bar heading, setting up a new J2EE instance really could not be any easier. From the main screen, simply click the "Add New Instance" button. As seen in Figure 4, only a few pieces of information are needed for ColdFusion to create the new instance.

The "Server Name" field is required, as this is the name of the J2EE instance. The next two fields are optional. The "Server Directory" field (which is automatically filled in based on the "Server Name" value filled in) is where the instance will reside on the file system. The "Create From EAR/WAR" option is where the EAR/WAR packaging feature mentioned previously really shines. Remember the MachII.war file created earlier that had the ColdFusion runtime bundled with it? Well, if it needs to de deployed to a separate instance, point to the WAR file created and the Manager will deploy the ColdFusion runtime from the bundled archive. If the JRun installation is on a Windows server, there are also options to create the new instance as a Windows service and to define the service with an auto restart recovery option. Clicking the "Submit" button will start the process of installing the new instance, deploying the ColdFusion server within it, optionally deploying the application to run within it, and starting the instance. When everything is complete, the screen will look similar to Figure 5 below:

It is important to realize that the setup of a J2EE instance and the subsequent deployment of ColdFusion MX within it require a lot of files to be laid down. Therefore, it might be tempting to think that the process is not responding. Rest assured that the process is indeed running under the hood and simply take several minutes to complete.

Licensing and Other Restrictions
The pre-compile and sourceless deployment licensing and restrictions are pretty straightforward. The ability to run applications without the source code is only compatible with ColdFusion MX 7 installations - it is not backwards compatible with ColdFusion MX 6.1 and earlier. That being said, the ability to both compile and run applications without the source code is available across all editions of the ColdFusion MX 7 product line - Developer, Standard, and Enterprise. This means that you do not have to have an Enterprise license to compile your application for Enterprise customers.

The EAR/WAR deployment option is a little trickier. First off, the ability to create the package is available in any edition of ColdFusion MX 7. However, because EAR/WAR files can only be deployed to J2EE servers, ColdFusion MX 7 Enterprise is the only edition that supports the deployment of these packages. (This deployment restriction is consistent with New Atlanta's BlueDragon product line, as seen at www.newatlanta.com/products/bluedragon/product_info/features.cfm#FCMatrix) Further, deploying an EAR or WAR package requires the purchase of ColdFusion MX 7 Enterprise licenses to match the number of CPUs on the deployment server. For example, if the package is being deployed to a 4-CPU server, then a 4-CPU Enterprise license of ColdFusion MX is required. (Note that Macromedia has changed its server licensing policy with the release of ColdFusion MX 7 such that a 2-CPU license can no longer be split across two 1-CPU machines. Each physical server now requires a separate license. Further, the licensing is based on the number of physical processors in the server only.) If a serial number is not applied when the EAR/WAR package is first created, then either the ColdFusion Administrator must be included with the package, or the Administrator API must be used so that the user can apply their license upon deployment (See the Macromedia LiveDocs for more information on the Administrator API). If the Administrator is not included and no serial number is applied via the Administrator API, the application is deployed as a 30-day trial that reverts to the Developer version upon expiration (which is restricted to localhost access plus 2 client machines).

While seemingly a hassle on the surface, the EAR/WAR deployment option is still much easier than previous versions' deployment experience. As an example, if a company wanted to purchase a bug tracking system with ColdFusion, that company would have to do the following using pre-MX 7:

1. Buy the bug tracking system application itself
2. Purchase ColdFusion and the appropriate number of licenses
3. Install ColdFusion server
4. Deploy the bug tracking system to the new server

1. Buy the bug tracking system with the ColdFusion runtime bundled as one cost
2. Purchase and apply the appropriate number of ColdFusion licenses

The Enterprise Manager feature for creating new J2EE instances is limited to the Enterprise edition. However, because the licensing is a "per CPU" agreement, there is no limit to the number of instances that can be created. Further, the Instance Manager can only create instances on the same server from which the ColdFusion MX Administrator is installed as opposed to across a network to another installation.

Summary
After years of developer demand, Macromedia has come through with an intelligent, straightforward way to confidently deploy CFML applications. The cfcompile utility improves initial template load time and gives a developer confidence that the innovation and hard work that they have put into a product will not be compromised while the ability for ColdFusion to be packaged up into one clean installation step opens it up to an increased number of companies who previously would have shunned the idea because of the fragmented install process. The J2EE Instance Manager vastly simplifies this process because system administrators now simply have to click a few buttons as opposed to running several installers.