Welcome!

ColdFusion Authors: Mike Kavis, Yakov Fain, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: Article

Tagging the Servlet: Part 1

Tagging the Servlet: Part 1

Online stores are the new, next-generation, "revolutionize the world as we see it today" way of doing business. In the context of business transactions, online stores use the global Internet to facilitate the purchase and sale of goods and services. The ability to support online sales is an essential component of the new e-business paradigm for Internet-based businesses today. Putting together an enterprise-level application for an Internet store involves design and integration of various technologies that play specific roles in a distributed computing environment. A distributed topology is a prerequisite for building such Internet applications since the Internet is inherently distributed in nature.

Due to the plethora of technology alternatives available in the computing arena today, designing architectures for an enterprise application involves choosing between technologies based on feasibility, applicability, cost, availability and several other factors. No solution is "the right one." The hard part is to figure out which technology to use to provide a particular functionality. The challenge is to take competing and complementary technologies and make them play nicely together.

This is the first in a series of articles on some of the prominent technologies available to build a simple Internet-based Ticket Store application. This application offers online purchase of airline tickets as well as goods sold in airports. Our discussion focuses on two prominent technologies: ColdFusion and some components of the Java platform, namely Java applets and servlets, RMI and JDBC. The modules implemented using CF will be presented here and in two subsequent issues of ColdFusion Developer's Journal. The modules implemented using Java will be discussed in Volume 4, issues 6, 7, and 9, of Java Developer's Journal.

One of the main objectives of this design is to illustrate how Java servlets can be used as access mechanisms in server modules that serve up data to application modules implemented in ColdFusion. Currently, a majority of services across the Internet are accessed through the use of CGI scripts. Servlets offer an attractive alternative to CGI, especially if you're using Java to provide the server-side functionality. This article will concentrate on why ColdFusion and Java servlets make a great combination for developing Web-based applications and how Java servlets can be accessed from ColdFusion templates. We'll walk through the design of a Custom Tag called CF_Servlet that will allow invocation of Java servlets from ColdFusion templates.

As I'd like to keep this discussion focused on servlet access from ColdFusion, I'll refrain from going into detail on servlets themselves. There are several good books and articles on servlets and I've provided references to a couple of them at the end of the article. While you don't need to be an expert on servlets to benefit from the discussion here, a basic familiarity with CGI, Java, URLs and ColdFusion Custom Tags is assumed.

Why Servlets?
So why would the developers of a full-fledged application server like ColdFusion be interested in using Java servlets? There is certainly an overlap in functionality. Some of the common reasons for opting to use Java servlets and ColdFusion templates are:

  • To access relational databases from the next tier of the distributed system. ColdFusion achieves this through a rich library of SQL-based tags and ODBC. Servlets achieve this via the use of JDBC.
  • To extend the capabilities of the Web server that serves up the data.
  • To add dynamism to the Web applications by enabling client-to-server interactivity.

    ColdFusion's most powerful feature is its capability to connect to data sources that are maintained in other applications. It allows the building of dynamic queries on the fly to retrieve data from such applications. This makes it the ideal tool for creating dynamic Web application components such as shopping carts, account management modules, purchasing modules and customer profiles.

    Servlets on the other hand excel at making server-side services available to the client in a dynamic and interactive fashion. They can be used to efficiently access a variety of services offered across different tiers of a distributed architecture. Basically, servlets serve HTML to the client. They also bring access control and enhanced security into the equation. They are closely tied to the Web server they run on and thus help extend the server's capabilities to the client. One thing servlets are not designed for is building sophisticated GUIs. They are primarily HTML servers.

    The focus in Java technologies is shifting toward server-side Java, and that makes servlets a prominent player in developing Web applications. Typically, ColdFusion-based applications would use servlets:
    1. To access server-side services offered by Java applications
    2. To gain access to RMI/CORBA services
    3. To perform sophisticated computation-intensive tasks on the server as opposed to burdening the client with this responsibility

    Accessing Servlets
    Clients can access servlets in the following ways:

  • Via a URL: This is the same as connecting to any site via a browser. The query string parameters at the end of the URL are picked up by servlets in the same manner as CGI programs.

  • Via Server-Side Includes (SSI): These are used to embed servlets within HTML pages. This is achieved through the use of tags in .html files. Files containing the ... tags are named with an .shtml extension. They can be accessed via any Web browser via a URL, similar to regular .html files.

    The remainder of this article focuses primarily on creating the CF_Servlet Custom Tag. This tag allows the ColdFusion templates to access servlets using either of the mechanisms listed above. It also allows the information needed to invoke the desired servlet to be specified from an Access database. Figure 1 shows the database with the names of three example servlets that can be invoked via the CF_Servlet tag.

    Before getting into the details of the tag, let's go over the pieces required to invoke the servlet on a Web server:

    For a URL invocation we'll need:

  • The name of the servlet class
  • The URL for the Web server that houses the servlet
  • Any query parameters that the servlet expects in the query string

    For an SSI invocation we'll need:

  • The name of the .shtml file
  • The URL for the Web server that houses the servlet

    I've written the following two sample servlets that can be used to test the CF_Servlet tag. You can download these (and the corresponding SSI [.shtml] files) from www.sys-con.com/coldfusion/sourcec.cfm:

    - HelloColdFusionServlet, HelloColdFusionServlet.shtml
    - TicketServlet, TicketServlet.shtml

    These servlets are clearly simplistic and exist only to demonstrate the use of the CF_Servlet tag.

    The servletURL.cfm template
    Before developing the CF_Servlet tag, we'll walk through the development of a template for invoking the servlets from a URL string. This is available in the file servletURL.cfm and is shown in Listing 1. The first part of the code is the usual HTML tags and the specification of the title for the browser. After this, the first statement in the of the document initializes the variable url. It is initialized to "http://" since all URLs will begin with the HTTP protocol (at least for our purposes). Basically, the purpose of this template is to build up this variable based on the input from the browser.

    The first thing we check is whether a trace parameter has been passed in. If it has, it will print out the final URL for invoking the servlet. If it hasn't, only the output from the servlet will be printed. The trace parameter can be used for debugging.

    Next, the variable database is initialized to "cfservlets." This is the name of the table illustrated in Figure 1. The idea is that if the servlet has an entry there, the data for invoking it doesn't need to be supplied with each invocation. If the servletdatabase parameter is supplied, the template will pick up the data from the database name supplied as the value for that parameter. The variable database is initialized with this value.

    The servletclass is a required parameter. Hence it is specified in the tag. None of the tags have any default values in this template because this template is meant for the generic invocation of servlets. In the absence of a parameter, it's better for it to fail than to invoke a default servlet.

    The next section is the CFQUERY tag that retrieves the fields for invoking the servlet. The key used is the servletclass, which is also the primary key in the database. Once the records are obtained from the table, the next step is to build the URL. The URL is built as follows:



    The URL is built up of four segments - the string "http://", the URL for the server, the directory for the servlet plug-ins on the server and the name of the servlet. The standard directory for servlets is the directory "servlet" under the Web server's root directory. A typical URL at this point would be:

    http://myURL.com/servlet/MyServlet

    If we were picking up all the data from the database, at this stage our URL would be complete. The program would skip the section and go on to check whether any queryString parameter was supplied in the URL that was used to invoke the servletURL template. If so, it's appended to the end of the URL (demarcated with a "?" character).

    Next, the trace variable is checked to see whether the URL needs to be printed out. This is followed by a check for the method parameter, which is used to specify "GET" or "POST" for the servlet. The servletURL template doesn't support "POST" yet. If the method parameter isn't supplied, the default service() method of the servlet is called.

    The actual invocation is made in the CFHTTP tag. If the "GET" method was specified, it is passed to the servlet and the doGet() method of the servlet is called. If not, no method is explicitly specified. This causes the servlet's service() method to be invoked (which in turn calls doGet(); hence the end result is the same).

    The last part of the template is the only significant piece as far as the browser user is concerned. The file content is output using the CFHTTP.FileContent variable.

    This template can be used to invoke servlets from the URL. Figure 2 illustrates two such invocations. The first one causes the servlet to be invoked using data from the database. The second supplies the data in the URL and also turns on the Trace flag to print out the URL being invoked. The URLs used in the screens are:

    http://localhost/Test/servletURL.cfm?serv-letdatabase=
    cfservlets&servletclass=HelloColdFusionServlet

    and

    http://localhost/Test/servletURL.cfm?serv-erurl=
    localhost&servletclass=HelloColdFusionServlet&Trace=ON

    The CF_Servlet Custom Tag
    Listing 2 shows the CF_Servlet tag, which is available in the file servlet.cfm. The changes from the template to the Custom Tag are trivial. Basically, instead of reading the parameters from the URL, they are obtained from the ATTRIBUTES supplied by the calling template. The values of the corresponding ATTRIBUTE fields are copied into appropriate variables in the tag.

    Listing 3 illustrates how the CF_Servlet tag is used. The file invokeHelloColdFusionServlet.cfm contains the code to invoke the HelloColdFusionServlet in three different ways to demonstrate the CF_Servlet tag's flexibility. The first one uses the "database invocation." It also supplies three NAME=VALUE style parameters (although they're not used by the servlet). The second invocation supplies the server URL and other data in the parameters passed to the tag. The third invocation uses the SSI file to invoke the servlet. The output of all three invocations is displayed on the same page. This is illustrated in Figure 3.

    Listing 4 shows an invocation of the TicketServlet via its SSI file. The TicketServlet simply sends back a hard-coded response for the flight query. However, it illustrates some key points in this design. The output of this invocation is displayed in two separate sections of the resultant page. The first half (Flight request Parameters) shows the parameters passed into the servlet; the second half, the output from the servlet that comes back to the ColdFusion Custom Tag.

    Listing 4 represents the basis for the interaction between a ColdFusion application and the service exposed by the TicketServlet. In a real application this query could have gone across to another server, done some comparison shopping for airline tickets, and so on. The key thing is that the ColdFusion application is abstracted from all this. It basically submits a query and gets a price quote back.

    So What's the Big Deal?
    There's nothing that the CF_Servlet tag provides you that you couldn't have gotten by just typing the URL in the browser. However, what it does allow you to do is set up a basic communication between a ColdFusion template and a servlet residing in, perhaps, another tier of the application. The output from the servlet is going to be available in your template and can feed the front-end application.

    The protocol for communication between ColdFusion and Java servlets as demonstrated in this article is simple and string based. But let's stop and think for a minute. The server side of this equation is in Java. One of Java's primary features is dynamic class loading. What if object names were supplied to the servlet by ColdFusion templates? These objects could be instantiated on the fly, used and then discarded. Well-known and published services (such as CORBA/RMI services) could be accessed via this simple means of communication.

    Development Environment
    The code shown in this article was developed on NT 4.0. The servlets were tested in JRun Pro 2.2. The version of ColdFusion used was 4.0. The JDK version for the Java classes was 1.17B, and JSDK 2.0 (Java Servlet Development Kit) was used for the servlets.

    The following files are available at www. ColdFusionJournal.com. The ".java" files will need to be installed in JRun in order to run the ColdFusion templates:
    Listing 1: ServletURL.cfm
    Listing 2: Servlet.cfm
    Listing 3: invokeHelloColdFusionServlet.cfm
    Listing 4:invokeTicketServlet.cfm
    Listing 5: HelloColdFusionServlet.java
    Listing 6: HelloColdFusionServlet.shtml
    Listing 7: TicketServlet.java
    Listing 8: TicketServlet.shtml

    A Microsoft Access database file is also available for the reader to download: cfservlets.mdb.

    The Online Airline Ticket Store
    In subsequent articles in this series we'll use the foundation built here to develop an example e-business store. The Online Ticket Store is an Internet-based application that allows an Internet user to log in and purchase tickets via a browser. It also offers an online store to purchase items normally offered in duty-free shops in the regular international airports. In the next article we'll build some of the basic components of the store such as a shopping cart and a profile manager. We'll also add some intelligence to our queries for purchasing tickets and getting some meaningful quotes.

    References
    Servlets: Hunter, J., and Crawford, W. (1999). Java Servlet Programming. O'Reilly and Associates.
    ColdFusion Custom Tags: Forta, B., et al. (1999). Advanced ColdFusion 4.0 Application Development, pp. 114-132.

  • More Stories By Ajit Sagar

    Ajit Sagar is Associate VP, Digital Transformation Practice at Infosys Limited. A seasoned IT executive with 20+ years experience across various facts of the industry including consulting, business development, architecture and design he is architecture consulting and delivery lead for Infosys's Digital Transformation practice. He was also the Founding Editor of XML Journal and Chief Editor of Java Developer's Journal.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.