ColdFusion Article

ColdFusion MX standalone and previous versions, you had to purchase multiple servers to benefit from isolation and clustering. Purchasing additional servers was not just a monetary cost—you also had to configure and maintain a lot of hardware. With a single license of ColdFusion MX for J2EE, developers and administrators can deploy an unlimited number of ColdFusion instances directly to J2EE application servers, such as Macromedia JRun, BEA WebLogic Server, IBM WebSphere, and more.

By deploying directly to an enterprise application server, ColdFusion MX takes advantage of the underlying infrastructure that provides multiple instances on a single machine.

Why twice is nice
There are several advantages to running ColdFusion in multiple instances instead of a single instance on a single machine:

• Isolate applications to ensure high availability. Under high user loads, an improperly coded application, CFX tag, JVM bug, or ColdFusion bug can cause a ColdFusion instance to fail or hang. When you run multiple instances, however, errors in the ColdFusion application, the ColdFusion server, or the JRun server levels do not affect other instances of ColdFusion.
  
  In some cases, when you change or configure your server, you may have to restart ColdFusion server. If you run multiple instances, restarting the server restarts the current instance without affecting all other instances.
  
  
• Scale your configuration with clustering. Scalability improves when you use multiple instances. For instance, if you currently have 10 or 20 ColdFusion applications in a single instance, you will find that they scale better if you distribute them across multiple instances. This is especially true with machines that have multiple CPUs. Administrators can extend the idea of multiple instances across multiple machines, taking advantage of each application server's underlying ability to cluster.
  
  
• Isolate applications for security. In ColdFusion MX standalone and previous versions of ColdFusion, you could use sandbox security to isolate applications and limit access to specific ColdFusion resources. Hosting many applications on a single server caused administrators a significant amount of overhead, however. By using multiple instances on a single machine, administrators can distinctly separate all server resources.
  
  A single instance of ColdFusion shares several variable scopes across applications (Server, Application, and Session scopes). By isolating each application within its own instance, you guarantee the security of these shared scopes. Multiple instances can also isolate resources such as custom tags, ColdFusion components, Java classes, and data sources without configuring sandbox security.
  
  
• Fine-tune each website with its ColdFusion server instance. In cases where you have many different departments within a company hosting their applications on a single machine, your ColdFusion Administrator settings may conflict. With multiple instances on a single machine, however, each instance or department has its own ColdFusion Administrator. This allows each department to fine-tune ColdFusion settings, such as simultaneous requests, mappings, data sources, verity collections, debugging, JVM heap size, and classpaths.
  
  With ColdFusion 5 or ColdFusion MX standalone servers, the web-to-application server configuration has limits (see Figure 1).

ColdFusion MX for J2EE breaks these limitations. It allows administrators the flexibility to configure each web server and application server individually (see Figure 2). Here each website has its own instance of ColdFusion MX. This allows you to isolate each application completely.

Consider several websites sharing an instance of ColdFusion MX, while one website has its own instance (see Figure 3). This example demonstrates how an Internet service provider can leverage ColdFusion MX for J2EE: The ISP could allow many sites to share a single ColdFusion MX instance, while giving a high-profile site a single instance because it has more traffic.

In a corporate environment, you may have a single customer-facing website that contains many different applications that could benefit from each application running in its own instance (see Figure 4). This technique does have some limitations, though. Each ColdFusion application server must have a unique context root that is not the top level. For example, if you have separate ColdFusion application servers for the HR and technical support departments, you cannot have www.mycompany.com/HR.cfm and www.mycompany.com/techsupport.cfm. Instead, you must use separate context roots for the two ColdFusion application servers, and the web page addresses should be at the directory levels, such as www.mycompany.com/HR/ and www.mycompany.com/techsupp/.

Note: Context root is a J2EE term for the application mapping of a particular application. When you install ColdFusion MX for J2EE, it asks you to specify a context root, or the URL that will answer requests. For example, if you specify a context root of cfmx, the URL would be http://server/cfmx/page.cfm. The /cfmx in the URL is not a physical directory; it's a virtual URL that directs the request to the J2EE application server. Defining unique context roots only becomes necessary when you have multiple J2EE application servers connected to a single web server. Each application server must have a unique context roots to avoid conflicts.

Deploying ColdFusion MX for J2EE to an application server
To deploy ColdFusion MX to multiple instances of your application server, you must first create the instances that you will deploy to. Refer to the documentation for each J2EE application server vendor to learn how to create additional instances. After creating and configuring the new instance on the J2EE application server, you will deploy ColdFusion MX for J2EE to the server. This procedure varies based on the version of CFMX for J2EE you are using. There are two different installations: Phase I and II.

The initial release of ColdFusion MX for J2EE (also called Phase I), released in September 2002, featured specific installers for J2EE application servers (such as Macromedia JRun 4, IBM WebSphere Application Server 4, and Sun ONE Web Server 6) that automatically installed and deployed the ColdFusion web application. If you use Phase I and choose to configure multiple instances, you will need to run the installer for each new instance that you want to create. The installer packages and deploys CFMX to the instance chosen during installation.

The Phase II installation version of ColdFusion MX for J2EE, available in early 2003, benefits from the portability in the J2EE standard and supports a wider variety of application servers through a standardized installation process. Regardless of application server, the installation creates either an enterprise application archive (EAR) file or two web application archive (WAR) files. You then use application server–specific deployment facilities to deploy the ColdFusion web application and perform additional configuration steps to enable graphing, COM, CFX, ODBC, and Verity support. Because the installer produces either an EAR or WAR file, you only need to run it once. The administrator only needs to deploy CFMX from the EAR or WAR file to each new instance that you wish to create. Phase II has several advantages over Phase I: for instance, it supports ColdFusion sandbox security and serializable ColdFusion session data, which session failover in clustered servers requires.

For more detailed instructions, see "Macromedia ColdFusion MX for JRun: Using Multiple JRun Application Servers to Isolate ColdFusion Applications on Single and Multihomed Web Servers" (TechNote 23407).

ColdFusion MX for J2EE licensing is based on the number of CPUs per server machine. With a single license, administrators can deploy an unlimited amount of ColdFusion MX instances on a single server machine. Administrators are only limited by the amount of RAM and CPU resources available on their servers. This is a much more cost effective model than buying multiple servers and deploying the ColdFusion MX standalone version to each server machine.

Beyond multiple instances
By extending ColdFusion applications across multiple servers, administrators can leverage the clustering capability of their J2EE application server as well (see Figure 5). Enterprise-level J2EE application servers can provide load balancing and failover from the web server to the application server, including replicating session data between servers in-memory.

Note: You must use the Phase II release of CFMX for J2EE for this feature.

ColdFusion MX for J2EE offers several advantages over the standalone version of ColdFusion MX or ColdFusion 5. From multiple instances on a single machine to ColdFusion MX clusters spanning multiple machines, the configuration options are unlimited.

About the author
Brandon Purcell is a senior product support engineer at Macromedia with over seven years of experience with developing, maintaining, and supporting web-based applications. Brandon has been working with ColdFusion for over six years and has over two years of experience with J2EE and Macromedia JRun.