Client-Side Presentation Logic
595
Getting XML Data to the Client Side: Three Techniques
In order for processing to occur on the client, data must be transferred between the server and the
client. We have already established that XML can be used to our advantage for the exchange of
structured datasets between client and server. The next question that comes to mind is how the data
should be transferred. There are at least three very common techniques:
q
One shot: Deliver the XML data encapsulated in-line with the HTML document
The limitation of this technique is that the data is essentially static, and cannot be changed
without a complete reload of the URL essentially resetting the processing logic. Updating
the data must be done as a reload, and the complete dataset must be transferred all over again.
q
Client pull: Have the client make a connection back to the server
This is considerably more flexible, and the client has great latitude in optimizing the actual
data transferred. However, doing this ad hoc can be problematic because the client needs to
make a connection back to the server and there is no telling whether the connection can in
fact be made, due to security restrictions, routing problems, etc.
q
In-band client pull: Have the client request data through a proven HTTP channel
This is commonly known as HTTP tunneling, and is the preferred way of implementing a
client pull. It is sure to work because it uses the same channel that the original HTML page
and applet were downloaded through to make a request back to the server for data transfer.
In this chapter, we will be deploying the in-band client pull technique, creating an HTTP tunnel that we
can make arbitrary data requests through. We will also be working with several examples where the
one-shot technique is used.
Case Study for a Specialized Travel Agency Chain
Our hypothetical customer is a large chain of travel agencies. Each of the travel agents in the chain
specializes in his/her own areas. There are agents that specialize in Asia, others that are specialists in
Africa, and still others specialize in trips to tropical destinations.
While there are hundreds of agencies in the chain, there is only a single headquarters. Each travel agent
has access to a computer that is tied in to the network at the headquarters. Some computers are
connected via existing packet switched networks, while others dial in using analog modems to access
points provided by the headquarters.
The entire chain of travel agencies is located in a major market. In this market, there is a constant flow
of last minute vacancies from tour operators, wholesalers, and distributors that are being sold off (on
almost a daily basis) at a fraction of their original cost. These trips may be cancellations, seats that are
blocked but unsold, or low season excess. The rationale from the operators and wholesalers is that
"getting something for these packages/seats is better than getting nothing at all".
These last minute specials are commonly known as "sell-offs". The headquarters of the travel agency
chain receives notification of these sell-offs from the major distributors and operators daily. These
notifications used to come in the form of faxes, but with the new e-business system that is installed, they
now come into the headquarters in the format of transmitted XML documents.
The agency chain decides to enter the sell-off market. The trick of the trade is to notify the agencies as
soon as possible upon the discovery of availability. Since many other independent travel agencies and
chains also receive this sell-off information, and are essentially in competition for these sales, timeliness
and efficiency are of the essence here.