Clustering
Load balancing is not usually "application aware." Its job is simply to route incoming requests. The point at which your cluster becomes application aware, and not just a simple load balancer, is when you configure your cluster to replicate session data. The ColdFusion Enterprise Manager's Cluster Manager takes care of copying session data to each node in the cluster so clients of your application will not experience any change in the event of a server failure. Sessions can move freely among members of the cluster or be configured to be "sticky" where each particular client will be routed to the same node for the duration of the session. With either sticky sessions or not, replicated data will always be up to date on every node at the moment it is requested in your app. Another thing to note is that there are no changes in the way you use the session object in your CFML code to take advantage of session replication. The Cluster Manager works under the covers and is entirely invisible to your application. An important aspect of session replication to keep in mind, however, is that since this feature is not part of the J2EE spec the behavior of session replication is not consistent across the range of app servers that support it. Some, like WebSphere, explicitly document the fact that they will only replicate instances of classes found in the JDK. This means that if you are developing a ColdFusion application using the session object that may at some point be deployed on an app server other than ColdFusion's underlying JRun, you should be conservative about the type of objects you store in session.

WARs, EARs and Sourceless Deployment
A ColdFusion Application contains an application's resources, such as ColdFusion Markup Language files (CFM), ColdFusion Components (CFC), and static resources such as HTML pages and image files. The application may also require configuration information such as details about data sources. Managing and deploying an application with all of those resources and settings, for instance moving an application from a development environment to production, can be difficult. The J2EE specification has a solution; a WebARchive (WAR) file. This is a single file used to package an application for easy deployment and it is the standard way to deploy applications in J2EE environments. The archive contains all of the application's logic, resources, and the ColdFusion runtime required to run it.

ColdFusion MX 7 automates the task of creating these J2EE archives. All versions of ColdFusion allow you - from the ColdFusion Administrator - to create a WAR or EAR file from a specified set of application directories. You can configure data sources to be included in the archive, chose to include or exclude the ColdFusion Administrator in the packaged application, include or exclude external components (such as COM support), and more. And just like the Enterprise Manager, the J2EE packaging feature of ColdFusion is as simple as creating a datasource.

ColdFusion MX 7 also supports packaging and deploying ColdFusion applications as Enterprise Archives (EAR files) - another Java 2 Enterprise Edition (J2EE) application archive format. Whether your choose EAR or WAR is entirely driven by the deployment environment (i.e. Tomcat is a servlet engine and only accepts WARs).

It's important to point out that you can create a J2EE package of an application with any version of ColdFusion (Developer, Standard, or Enterprise), but they must be deployed onto a server running ColdFusion Enterprise edition. When you create the package, you will need to enter a valid licensed Enterprise serial number for the server on which the application will be deployed. If you leave the serial number out, the application will be deployed in Developer mode (IP restricted).

Another new option we developed for ColdFusion MX 7 is the ability to write a ColdFusion application and deploy it without distributing the unencrypted, human-readable source code. This is presented as an option when you are creating your EAR or WAR file. If this box is checked, the CFML that makes up your ColdFusion application will not be included in the archive, but your application will still run. This gives your intellectual property more protection than was ever possible before in ColdFusion. The Java byte code is not human readable. Even if the byte code were decompiled, it would still only result in Java source code, which is still very far from CFML.

This is achieved by compiling the ColdFusion files to Java byte code. If you expand the archive you will still see your applications directory structure and even all of the files that make up your application - images, style sheets, etc. However, if you open any of the CFML templates you will see that they do not contain CFML, but instead contain Java byte code. Give it a try; you'll see byte code completely obscures your application logic.

Summary
ColdFusion has had features for many years that allowed you to create and deploy high performance scalable web applications in even the most demanding environments. However, with ColdFusion MX 7, we've made many of the high availability, scalability, and management features more powerful and much easier to use. If you aren't familiar with J2EE, you can still take advantage of many of its HA strengths by using the new ColdFusion Enterprise Manager. If you are in a standardized J2EE organization, you can use the new J2EE package and deployment features to make ColdFusion fit more easily alongside any other Java application. And, in either case, the job of managing and deploying these important applications is done in the kind of intuitive and highly productive ways that you've come to expect only from ColdFusion.