ADVANCED macromedia COLDFUSION MX 7 Application Development [Electronic resources] نسخه متنی

How ColdFusion Lives on Top of Java Server

ColdFusion MX 7 includes an embedded Java server based on JRun 4 technology. The infrastructure provides run-time services for ColdFusion Markup Language, Web services, and components. The ColdFusion application server relies upon the underlying JVM in order to serve ColdFusion pages and components. ColdFusion can now be deployed in the middle tiers of your Web site architecture. This leaves the Web server to host HTTP requests only, passing these requests to the application servers (ColdFusion on J2EE, for example) to process dynamic pages and run components. Splitting user-interface and business-logic functions into separate layers adds more stability and scalability to your Web site. Following the J2EE application model, ColdFusion can then run and expose Java components, Web services, JSP pages, and servlets.

See Figures 4.4 and 4.5 for the ColdFusion MX 7 architecture. Figure 4.4 shows ColdFusion MX 7 Server installed as a stand-alone server. ColdFusion MX 7 Server relies upon the embedded J2EE server. Figure 4.5 shows ColdFusion MX 7 for J2EE Application Servers installed on Macromedia JRun, Sun ONE Application Server, IBM WebSphere Application Server, or BEA WebLogic.

One of the advantages of J2EE technology, properly implemented, is the modularity of design in components, servlets, and EJBs. Since ColdFusion MX is based on the Java platform, this is an important relationship. Applications can now be configured to run on tiers, where each tier provides specific functions. Understanding how to write your ColdFusion code in this tiered environment is important. A well-designed application, focusing on modularity, will scale well and improve the stability of the Web site. Some of these issues will be discussed in more detail in the section "Chapter 5, "Managing Session State in Clusters," discusses this topic at length.

When looking for bottlenecks in your applications deployed on multitiered J2EE installations, spend time understanding the layers or tiers that your application is invoking to perform work. Keep in mind that your application is now deployed in various layers, each layer focusing on specific tasks. For example, if the bottleneck is in an EJB, tweaking CFML that calls an EJB may not impact performance, but tweaking the poorly coded EJB will. In a multi-tiered environment, it's best to architect solutions with care before coding. Judicious choice of components to perform work is a prerequisite to gaining performance and scalability in multi-tiered solutions. This adds complexity to application development and precludes the "code and fix" mentality. Thoughtful and thorough planning will pay off when your Web site scales and performs properly. See Figure 4.6 for a sample organization of a multi-tiered Web site architecture.

Coding Implications from the Developer's Perspective

When deploying Web applications, coding implications arise in most any environment. Is the file I want accessible? Is the service or object I want available? Is the database connection available, or is the port I need to get through the firewall open and functioning? These considerations haven't changed in ColdFusion MX 7. There are some things that ColdFusion MX 7 cannot control. It does do an excellent job maintaining user sessions through client and session variables. And connecting to databases has been made easy with the ColdFusion Administrator.

When you introduce ColdFusion applications to a multi-tiered environment, there are several implications that need to be considered, including Java session variables, EJB pooling, JDBC database connections on the Java application server, and user security. The following sections offer some best-practices tips for building Java-enabled applications in ColdFusion.

J2EE Session Management

Even though you may have enabled Java session management in ColdFusion Administrator, you need to be aware of how sessions are managed in the Web site cluster. As mentioned before, Java application servers and Java Web server connector plug-ins offer different options for managing session variables, including

• Persistent, where session state is shared among all clustered servers and may exist after the browser is closed. Users can transfer between application servers without severing session information.

• Sticky, where session state is maintained by keeping the user on the same server throughout the session. The session is terminated when the user closes the browser. This is normally handled by the Web server cluster-managing device.

Chapter 5, "Maintaining Session State in Clusters." If the server fails and the users do not have session data stored on the browser or in a cookie, the session will still be lost.

All Java Web server connector plug-ins for supported J2EE application servers discussed above, offer session-aware load balancing. Session-aware load balancing for ColdFusion is described in Chapter 3, "Scaling with ColdFusion," and is similar to session-aware load balancing in J2EE architecture. This means that the session is "sticky" to the server. The user will remain on the server for the duration of the session. The session is terminated when the user closes the browser.

Both these methods are important for maintaining session state for Web applications such as shopping carts, where user information is stored as the user moves about the site and, hopefully, checks out. Maintaining the user's data is important for enhancing the user experience. Regardless of the method, you, the developer, need to be aware of how the session state is managed by the application server and should always check for its existence with every call to the session.

Scaling with EJBs

To be stateless or stateful, that is the question. Sorry, Shakespeare, for the pun, but it is useful here. EJBs are server-side components for developing business objects and can be highly distributed. This is why they're desirable components for a scalable J2EE architecture. In a multi-tiered J2EE application, the entities, business logic, and database connections can be stored in EJBs. EJBs come in two flavors: entity Beans and session Beans. Entity Beans are used to represent data such as a customer or an order. Session Beans are used to perform tasks or business logic. A good rule of thumb is never to access an entity Bean directly, but rather through a session Bean. Sounds easybut then we realize that session Beans can be either stateless or stateful. We won't go into the details on this topic except where it concerns scaling with EJBs.

• Stateless session Beans do not maintain state and use only data that is passed to them in parameter variables. Stateless Beans are good for writing data to a database. They are highly scalable and can serve many clients.

• Stateful session Beans maintain state with the client, allowing the client to interact with the Bean during the session. These Beans are not shared among clients and they do not participate in instance pooling. Remember that stateful Beans may time out if not used within a specified period. Each instance of a stateful Bean exists only on one application server, and the client must maintain a connection to the instance.

NOTE

Stateful session Beans always explicitly remove stateful session Beans after they are complete, to restore system resources. Stateless session Beans are best used for transactional processing because they are highly scalable.

It is important to be aware of the differences between EJBs and how they are invoked. In a high-transaction Web site, this knowledge is very important to provide scalability and stability.