This built-in webserver, also known as a Java Web Server or JWS, is not intended to be used in production but only in development since it is not tested or maintained to be as robust and secure as production-quality webserver. So, if your career is resting on this decision, use ColdFusion with Apache or IIS. It turns out, however, that the Macromedia website (macromedia.com) receives incoming traffic on clusters of Apache webservers and Apache then proxies the request to CF/JWS in turn using mod_proxy. The web architect found that configuration better than using Apache alone for their particular environment.
The way ColdFusion works with Apache or any other external webserver is ColdFusion will install what is known as a stub or connector, built in C++, and that connector will be loaded into the webserver process. In Apache, the connector runs as dynamic module called mod_jrun20.so. Apache is built from a core server and dynamically loads modules at runtime that extend Apache's functionality.
When a HTTP Request is sent from a browser to a website, a webserver like Apache receives the Request. The Request is filtered by the modules loaded into Apache. The ColdFusion connector module will have a chance to review the Request information and if the Request matches certain patterns that are to be associated with the ColdFusion server, then the connector will handle the request by passing it on the ColdFusion server. Certain file extensions are handled by the connector including *.cfm, *.cfc, and more as well as servlet mappings such as /flashservices/gateway.
The way the connector hands off the Request to ColdFusion is that it opens a TCP connection to the ColdFusion server and sends the associated Request information such as the HTTP Headers and Data. ColdFusion receives the request and attaches it a thread responsible for executing that Request. Part of the Request is the page name such as /some/path/to/hello.cfm along with Cookies, Form or URL data such as ?action=dosomething &dosomething=update ¶m1=1 ¶m2=2 for example as a list of name value pairs that have semantic meaning to the ColdFusion application code.
ColdFusion is both a server and a language. The language is CFML and CFML is parsed, compiled, and executed by ColdFusion the server. In fact, ColdFusion *IS* Java actually. The ColdFusion server itself runs on an underlying J2EE (Java 2 Enterprise Edition) server, which in most cases is an embedded version of Macromedia JRun. Other well known J2EE servers include WebSphere, WebLogic, and Tomcat.
When ColdFusion receives this HTTP Request it will look in a corresponding location on the file system for the file hello.cfm in this case and read the source CFML code. The source CFML is actually converted to Java much in the same way JSP code is converted to Java, and then compiled to a Java class file. The resultant Java class file is most often written to disk and stored (optional) and is in turn compiled to bytecode that is held in memory.
In that last paragraph, I fibbed a little bit to make the process clearer. That is how ColdFusion MX 6.0 worked. In ColdFusion MX 6.1 and 7 the CFML source code is converted directly into bytecode in memory, skipping the whole Java source and Java class file process using a bytecode emitter that's wicked fast, without ever having to write the Java source file or class file to disk.
That bytecode in memory is executed as a program that takes into consideration all the information about the Request including HTTP Headers, Data, and URL/FORM data. The code executes the CFML that you the developer have written, including your queries and everything else. Most often the result of running a CFML code page is that HTML will be generated and is intended to be sent back to the browser (although its sometimes the case for no data to be returned because the page may have performed some task which requires no response to the browser). So while the program is running, the generated HTML is collected in a buffer, and at the end of program execution the HTML result is returned via TCP back to the connector stub.
The connector stub then hands the data back to Apache, and Apache sends an officious HTTP Response back to the browser.
Since the communication between the connector/Apache and ColdFusion is over TCP, then ColdFusion server can reside either on the same machine or possibly on a remote machine somewhere inside your DMZ or intranet.
Its quite common that a company will use firewalls not only between their DMZ and the public internet, but will use them within their intranet as well. Linux in particular usually runs its own firewall iptables and will filter requests on localhost. This is usually what troubles administrators that attempt to connect Apache to ColdFusion, that a firewall is running on the system and is interefering with the TCP communication required during the installation of the connector and the running of the connector.
Hopefully this helps to clear up the mystery behind what goes on inside ColdFusion.
I hope your classmates realize just how lucky they are to have someone like you in in their class. This has been an excellent series of posts so far. Please keep them up!