Section 2.1. The New ColdFusion Architecture

   

2.1 The New ColdFusion Architecture

The release of ColdFusion MX in the summer of 2002 comes less than a year after its predecessor, ColdFusion 5. In fact, work on MX was begun long before ColdFusion 5 was released. There has been a good deal of excitement surrounding Macromedia's MX technology platform, which includes not only ColdFusion, but Flash and Dreamweaver.

Note

There has been much speculation about the origins of the "MX" moniker. Guesses about its significance include the following: It is an abbreviation of The Matrix, which featured a character named Neo (Neo was also the code name of the ColdFusion MX project); it is the ICANN domain abbreviation for the country of Mexico; it stands for Macromedia eXperience or Macro-media's eXperiment. Public speculation about the meaning of MX soon led to the suggestion that it stood for "Macromedia X," where X is the Roman numeral for 10 and 2002 marks the 10th anniversary of Macromedia.


2.1.1 ColdFusion Prior to MX

Prior to ColdFusion MX, the code base for ColdFusion Server was written in C++, which had several ramifications for the product. To begin with, it made it expensive and time consuming to offer ColdFusion on platforms other than Windows. Though ColdFusion 5 was offered for Linux, Solaris, and HP-UX, the code had to be specifically written for each of these platforms.

For the users of ColdFusion, this meant a limitation in the choice of platforms on which they could run ColdFusion. This fact contributed to a sense in the development community that ColdFusion was only for Windows users ”a perception that Macromedia has worked to put to rest in recent years . It might have been hard, for instance, for a hosting company running FreeBSD to look seriously at incorporating ColdFusion into its offerings.

Note

Three of the biggest limitations with CF prior to MX were lack of support for industry standard languages and APIs like the Java servlet and EJB APIs, difficulty of supporting localization/internationalization in CF applications, and general interoperability with Java. Since about 1998, there has been building pressure to make CF interoperate better with Java objects, and then JRun, EJBs, and other J2EE servers like Weblogic and Websphere. CFX and CFOBJECT with Java required Macromedia to use JNI from the ColdFusion process to load the JVM (like how the browers do it), which was very buggy and hard to support across platforms and various JVM versions. Calls to servlets only worked with JRun and CFSERVLET; since it was an out-of-process call, the integration between CF and JRun at that point was just too disconnected to provide the benefits users wanted, like in-process integration and fully shared session objects between CFM pages and Java servlets.


ColdFusion 5 was built with four major subsystems: a p-code just-in-time compiler responsible for preprocessing CFML templates, runtime services for CFML language, support for application services (such as searching and graphing engines), and infrastructure services.

When a . cfm template is called for the first time in ColdFusion 5, the JIT compiler converts the template to p-code. It is then cached for further requests , and the cached copy remains valid until the template is modified or the server is restarted. The CFML runtime service then executes the resulting p-code; that is, it does the work specified in the code, such as querying a database, executing a loop, and so on. At this time the infrastructure services may be called upon to perform their supporting role, which includes such functions as opening database connections, interacting with the operating system, or interoperating with various protocols. The results of the template execution are then formatted and sent back to the Web server.

2.1.2 ColdFusion MX Architecture

As you likely know, ColdFusion MX sees the second fundamental rewrite of the core ColdFusion code base in the product's history. ColdFusion MX is written entirely in Java. While you as a ColdFusion developer can continue to write ColdFusion applications without learning Java, there are, as we will see, many benefits to the new opportunities the migration to Java affords.

Note

ColdFusion was first written in 1995 as a CGI executable. As the product grew, it became clear that this model, which spawned a new process for every request, was not only too slow, but also would not scale. It was rewritten in C++ to integrate with IIS and other Web servers via their proprietary APIs (ISAPI for IIS, NSAPI for Netscape, DSO for Apache), which provided better speed and scalability than the generic CGI.


The manner in which the old architecture incorporated its infrastructure services meant complexity for Macromedia, as well as slight differences among the same product on different platforms. It also meant complexity for ColdFusion users. Increasingly, organizations are moving toward a standard infrastructure not only for their Web environment, but also for a wide range of IT systems. In a world where open , flexible standards and system interoperability are increasingly important, rewriting the ColdFusion Server code base in Java made sense. Benefits to IT departments with a standardized model include reduced complexity of management, reduced costs, and easier integration.

The most fundamental change to the underlying architecture is that its infrastructure services are implemented by an embedded version of JRun 4, Macromedia's J2EE (Java 2 Enterprise Edition) server. Note that this is not a full version of the JRun product.

Here is an overview of how the MX architecture works. Just like Cold-Fusion 5, ColdFusion MX has four major subsystems. There is a translation engine that parses CFM pages and generates Java code from them. These Java files are compiled by a Java compiler and loaded by the core CF engine, which is implemented on top of the Java servlet API. When a requested template is processed , the compiled code is cached in memory and on disk. Subsequent requests for the same template execute the bytecode that has already been compiled.


   
Top


Java for ColdFusion Developers
Java for ColdFusion Developers
ISBN: 0130461806
EAN: 2147483647
Year: 2005
Pages: 206
Authors: Eben Hewitt

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net