The software components that make up the Online Ticket Store, their functions and the technologies used for their implementation are illustrated in Table 1.

Only the modules used for ticket transactions are listed. The modules used for building the virtual store will be discussed in a future article. We're not too concerned about the airline's back offices. Our focus on the back office will be limited to the access mechanisms used for the services offered by the back office. For example, how an airline prices and reserves tickets is beyond the scope of this article. However, the format in which a back office accepts a reservation request and the format of the response will be defined here and in subsequent articles. The transport mechanism (RMI/CORBA/other) will also be discussed and implemented, although security issues involved in transporting the data will not. The application modules are illustrated in Figure 1.Application Framework
The framework for this application is distributed among the following tiers:

Java Servlets and ColdFusion
The Merchant Server interacts primarily with the Service Access tier via a URL connection and is implemented using the ColdFusion 4.0 application server. For the purposes of this application I developed a custom tag called CF_Servlet (see CFDJ Vol. 1, issue 4). While details of the custom tag aren't relevant to the JDJ articles, they will be discussed in CFDJ.

Before describing the access mechanism, I'll elucidate why specific modules are implemented in ColdFusion while others are implemented using different Java technologies. ColdFusion is an application server whose most important feature is its ability to connect to data created and maintained in other applications. It allows the building of dynamic queries on the fly to retrieve data from such applications. It achieves this through the use of a very flexible tag-based markup language. This makes it an ideal tool for creating dynamic Web application components such as shopping carts, account management modules, purchasing modules, customer profiles, etc.

Servlets, on the other hand, excel at making server-side services available to the client in a dynamic and interactive fashion. Servlets can be used to efficiently access a variety of services offered across different tiers of a distributed architecture. Servlets basically 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 in and thus help extend the server's capabilities to the client. One thing they're NOT designed for is building sophisticated GUIs. They are primarily "HTML servers."

Typically, ColdFusion-based applications and Java Servlets can be used in conjunction if the division of functionality leverages these strengths. In our application, all data pertaining to the customer should reside in the ColdFusion components and be presented to the customer in a snazzy and sophisticated user interface. However, when back-office services like ticket price/availability quotes need to be dynamically accessed (e.g., for submitting a request for a ticket quote), Java Servlets provide an ideal access mechanism to these services. The Merchant Server tier uses the Service Access tier:
1. To access server-side Java services. Non-Java (C++) services could be accessed using JNI.
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.

This is based on the premise that the airline back-office services are publicly published as RMI/CORBA services. The Service Access tier dynamically queries the various airlines for the ticket price/availability and returns a quote based on some predetermined selection rules. The Service Access tier also maintains a database that captures each interaction with the Application Service tier. This database can be used for statistical analysis in the future, after the data has been accumulated over a period of time. The data would be valuable to the airline agencies. For example, if most customers have been rejecting an airline's quotes because the price is too high, the carrier would probably want to be aware of this fact.

Implementation
The rest of this article discusses the implementation of a test scenario for the application. Basically, it shows the interaction between a Java Servlet and an RMI server for getting a quote for a ticket. The servlet should be accessible from the ColdFusion template described in the corresponding CFDJ issue. However, you can also run it from a regular browser by invoking the corresponding URL.

Before we define the protocol for communication between the Merchant Server and the Service Access tiers, let's examine the information we'd like to pass between the two. A typical end-to-end transaction in this system would have the following steps. Please note that for this transaction we're not making use of the Customer Profile Manager, Travel Profile Manager, Shopping Cart and other components that are a part of the application implemented in ColdFusion:
1. The user feeds in his or her input for a flight quote request via the Client UI (Web browser). This actually invokes the ColdFusion template on the Merchant Server.
2. The request goes to the Merchant Server. A ColdFusion template passes the data to the Service Access layer by invoking a servlet. Let us call this the TicketServlet.
3. The TicketServlet packages the data into a TicketQuery object.
4. The TicketServlet sends the TicketQuery object to the different airline carriers as a request for a price and availability quote.
5. The TicketServlet receives the quote from the different carriers in the form of TicketQuote objects.
6. The TicketServlet chooses the price quote/quotes based on some predefined selection rules.
7. The TicketServlet packages the response into HTML and passes it back to the Merchant Server.
8. The corresponding ColdFusion template at the Merchant Server converts the response into a Web page that it serves back to the Client UI. For this article the UI is in the form of a browser at the client site.

Here, we'll just look at the classes that will implement this scenario.

The logic in these example classes is hard-coded. The actual implementation will be developed in subsequent articles. The classes used for the basic scenario are:

The flight quote requested from the client is simple and doesn't contain all the fields necessary to process the actual flight request that will be used in our application. In fact, the TicketQuote only contains a single field, which is the price for the flight. The refined classes for the application will be discussed in the next part of this article series.

Environment
The code for this article was developed using JDK 1.1.7B on an NT 4.0 workstation. The TicketServlet is accessed using Jrun Pro 2.2. The code listings may be obtained from the JDJ Web site.