Wattle Software - producers of XMLwriter XML editor
 Home | Site Map 
 About Latest Version
 Awards & Reviews
 User Comments
 Download XMLwriter
 Download Plug-ins
 Download Help Manual
 Downloading FAQ
 Buy XMLwriter
 Sales Support
 Sales FAQ
 Sales Support
 Technical Support
 Submit a Bug Report
 Feedback & Requests
 Technical FAQ
 XML Links
 XML Training
 XMLwriter User Tools
 The XML Guide
 XML Book Samples
Wattle Software
 About Us
 Contact Details
Professional XML Design and Implementation

Buy this book



Introducing the Centaur Case Study


In this chapter, we will take a more detailed tour of the Centaur system that is the subject of the application case study. By the end of the chapter, you will:


q       understand something about the market that Centaur is addressing

q       understand the aims of the system

q       understand some ways in which it differs from a commercially viable system

q       know the basic structure and functions of the system

q       know where XML is used within the system

Capturing Requirements

Some years ago, I heard of a software house developing a large and complex system for a customer. This was the biggest system they had ever undertaken, and they delivered it to the specification, on time and on budget. At the end of the year, they celebrated this as the best project they had undertaken all year. And what happened to the system? The customer decided that the system performance (which had been excluded from the specification to save time in negotiations) was inadequate, threw it away and started again with an in-house development team.

On another occasion, a joint venture was established to develop a new industry-wide system. The project ran for a year, then there were rumours of problems. The consortium comprised industry suppliers and the developers of their technology, but the industry traditionally sold through agents, and the agents had not been involved. When they were asked, the views of the major agents ranged from indifference to the project to antipathy since the system did not meet their needs, and would be more expensive and harder to use than the supposedly outdated technology they already had.


Why do such projects fail? In nearly twenty years of running development teams, I have never known a project to fail because of the incompetence of the developers. Instead, they fail because of poor management, poor requirements, or failure to involve all parties affected by the system.


Why am I telling you this? I have consulted various interested parties while designing and developing Centaur, but since this is not a book about project management or development methodologies, you will only see the results in the product itself, not as documentation in this book. The design method I used is typical of iterative rapid application development, but too many people see this as an excuse not to collect proper requirements and not to define their system. By all means keep your methodology light, but don’t ignore it altogether. So I would like to make it clear, that although the case study in this book lacks some features that would be needed in a full commercial implementation, which I will indicate, it nonetheless fulfils a defined set of initial requirements, as we shall see soon.


The diagram below shows the traditional model for buying vacations in the UK:



In recent years, this model has been changing, with tour operators buying up travel agents and charter airlines to provide a vertically integrated market. Up until now, these vertically integrated companies have sold seats on their airlines to other tour operators, and provided shelf space for their competitors’ brochures in their travel agencies.

Now the market is changing. Investigations by the UK government and consumer organisations have shown that the major companies are starting to use their power to push their own products through their agencies. The smaller tour operators are starting to worry about their seat allocations on the charter airlines. The 1998 survey[1] shown below indicated that twice as many agents think that independent tour operators will be squeezed out by the major tour operator groups as think they won’t.



The trend seems set to continue, to the point that the vertically integrated travel agencies are likely to be re-branded under the tour operator name and cease all pretence of being independent. This will divide the market into two — the major tour operators with strong branding and a good high street presence and the smaller, independent, tour operators selling through independent travel agents.


At the same time, we have new distribution channels. Although the complexity of travel products means it has taken some time, the large tour operators are starting to sell through the Internet. Then the likes of Microsoft Expedia (http://expedia.msn.com/daily/home/default.hts) are expanding from the scheduled market to packaged vacations. Who will they be talking to — the top few operators or Mom and Pop Tours? You guess. It goes on, with portal sites seeing travel as a major market area.


Oh dear, who would be an independent tour operator? Then it gets worse. In the diagram earlier, there is clearly an intermediary too many in the loop. Why have both a tour operator and a travel agent in the supply chain when selling through the Internet? While the tour operator can sell direct, the independent agents could start putting bespoke tours together using bookable sites available on the Internet. Currently, the commercial model, where tour operators use their buying power to get good discounts, may make this uncompetitive, but I would not want to base my future on this situation lasting.


Once the top few tour operators are selling through the Internet, what chance have the rest got of people even visiting their sites? Unable to compete on advertising expenditure, they will be relying on word of mouth for future business.


But wait! Isn’t the Internet meant to make it easy  for the small guys to look as impressive as the majors? Well, maybe on static sites, but providing facilities for booking complex products is expensive, and anyway, why should someone visit a site only covering vacations in Corfu when they can go to one covering the world?

Enter Centaur. Centaur works on a model where the tour operator stays in the loop, and addresses the issues of cost and visibility by operating with a wide range of tour operators. Whether the vacations are booked directly by the public or through travel agents is a political question which I can conveniently ignore for the sake of this demonstration system. Another major part of the business model is that many of these tour operators are specialists and so are not competing directly with each

other. While a Corfu specialist and a Caribbean specialist may both be after the same traveler's wallet, they are likely to see the benefit of co-operating as outweighing the disadvantages.


Let’s come back for a moment to the direct vs. travel agent question. When we are talking about the Internet, aren’t we meant to be talking about new paradigms? How about a "vacation café" on the model of the Internet café? Or supermarkets building coffee lounges with terminals connected to Centaur and a few experts around to help people book their vacations? Here I am, making a couple of dollars from your buying this book (you did buy it, didn’t you?), and giving you ideas for making millions. I hope you remember me in your will.


So Centaur allows many tour operators to share a single system while maintaining their own branding. Centaur will cover vacations all over the world for all seasons of the year. Because it will have so many companies using it, it can afford to advertise and will be big enough to compete with the major tour operators’ web-based systems. It will provide integrated searching, allowing the traveler or agent to find the perfect vacation, regardless of the tour operator, then book on-line. It will be available from the home, and possibly through a new model for travel booking through supermarkets, cafés, banks and wherever. Suddenly Mom and Pop are competing on equal terms.

Centaur Description

This diagram shows how Centaur fits into the booking environment to allow booking of tour operators.


In principle, the system can be used for either direct sales or sales through agents. For direct sales, the system can be financed through a booking fee taken from the revenue that would normally be paid to the agent as commission. For sales through agents, it is less obvious where the funding comes from. The only direct payment saved is the fee paid to the value added networks that currently connect agents to tour operators. In practice, agents may still want the security of such a network. So the revenue for Centaur has to be generated by savings elsewhere or the ability to charge more to the client.


In operation, Centaur collects brochure descriptions of vacations from the tour operators and stores and indexes these. The traveler then conducts a search of this database, and gets a list of vacations meeting his or her needs. It is then possible to refine the search or get more information on selected vacations. Searching is branded as Centaur, but individual vacation descriptions carry the tour operator’s branding.


Once a vacation has been selected, Centaur collects information about the number of travelers and opens a conversation with the tour operator system to allow quotation, availability checking and booking. The booking appears as "direct" with the tour operator, Centaur operating as an intelligent gateway rather than a travel agent:



This diagram shows the opportunity for selling additional services, either directly or by linking into other sites. These services would include insurance, guides, maps and other travel accessories. These additional services, along with advertising, would generate additional revenue for a commercial system, but are not relevant to the use of XML and so will not be included in the demonstration system.

The Aims of Centaur

Centaur is being developed for a variety of purposes. Firstly, it is clear from the above that a system like this is needed in the travel industry. The threat from major tour operators is to small companies, and these are often so heads down that they do not address the threat, or they are so unaware of what technology could do for them that they cannot see the solution. As a demonstration system, Centaur is designed to increase awareness of the possibilities for this group by showing them a real working prototype.


Secondly, it is being developed as a prototype for a production system. Most systems users and purchasers cannot easily express what they want until they see something different. In other words, it is easier to say what is wrong with something you can see than it is to specify requirements on a blank sheet of paper. Centaur provides the initial writing on the paper, and, as such, is a system waiting to be shot down as "not what we need".


As a consultant in XML, I spend time developing little prototype systems to help people become aware of the possibilities of the technology. With a new technology that many of those who could benefit have never heard of, this is essential to business development. Centaur is such a system, but on a bigger scale.


The fourth aim is a bit of a personal one. As a contributor to the discussions within the United Nations on using XML as a mechanism for electronic data interchange (EDI), I have come across people who are very good at playing devil’s advocate. One point I have heard made is that it is impossible to use XML as a trading language without being a Java programmer. Some books on XML support this view by leaping straight into Java code even to display information. If such programming is necessary, XML becomes unavailable to web site developers and others who do not have a programming background, but have become familiar with scripting languages. The aim of Centaur is to demonstrate that powerful web-based applications can be developed in XML using only standard scripting languages.


And the fifth aim is to provide a case study for this book.


These aims conflict to some degree. The requirement for the book is to maximise the variety of ways in which XML is used, while minimising any parts of the system that do not require XML. Hence the elimination of payment mechanisms, which are complex, well catered for with existing products and would contribute little to this book. I am also restricting myself to scripting languages, which could result in a commercial system hitting performance problems in some areas. Of course, this is one of the benefits of a prototype — Centaur will indicate those areas where a commercial system needs some performance enhancements.

Differences from a Commercial System

I have already said that the case study differs from a commercial system by excluding a payment mechanism. There are other areas where there is little benefit in implementing complex business logic when trying to demonstrate the use of XML.

The first is in the direct sell versus travel agent model. Requirements here are different. A travel agent would need to log in and be recognised so that commission can be paid. The tour operator system itself would track commissions due and make payments, so adding this functionality is purely a matter of one or two additional screens and additional messages between Centaur and the tour operator system.


Centaur will include a search capability as that is a key part of the requirement. However, this can be kept simple, since complex searches merely require more complex logic. For this reason, the range of vacation types is also limited (for example, no account is taken of ferry travel or multi-centre vacations). Most commercial travel systems on the Internet use a keyword search mechanism. I would like to see this supplemented with the sort of free format "I want to go somewhere hot near a golf course in August" searches that are familiar to Microsoft Office users.


The other major area of complexity is when the user wants to cancel or change a vacation booking. In practice, tour operators have different ways of handling these events, and would almost certainly prefer to do this over the phone rather than over the Internet so they can explain the cancellation charges that will be applied and discuss whether insurance covers these.


A commercial system would include not only vacations, but also the travel ancillaries such as the insurance, guide books and maps that I mentioned before. In the UK, tour operators insist that the traveler has adequate insurance taken out at the time of booking. The user will therefore either have to take out a policy through the tour operator, or provide details of existing insurance. This would be an opportunity for the Centaur operator to earn commission by linking through to a preferred insurance supplier.


And finally, remember the system is simplified. There are no queuing mechanisms and no transactional controls — familiar areas of commercial systems and well catered for with existing products. The aim is to expose the XML, not teach you the details of complex transactional systems. Similarly, there are no pretty graphics to get you into the vacation mood. Just one logo and boring text and grey buttons as this simplifies the appearance of the scripts, all of which are included in the downloadable files, and much of which is discussed in more detail in later chapters. Doubtless you will spot some of the other areas where there is a need for more error checking or other enhancements.


Well actually, that wasn't "finally" at all. By far the most important difference is that Centaur relies on the facilities of Microsoft Internet Explorer version 5 — a browser that has only just been released at the time of publication. This would probably limit the system to less that 5% of its available market in the short term. Unfortunately, a real commercial system at the moment would have much of the client-side XML stripped out. It would be replaced by a combination of server-side processing (for example where XSL is used to display vacation details) and more conventional mechanisms in other areas.


Up until now, I have used the term Centaur for both the demonstration and commercial systems. From here on, I am discussing the demonstration system unless I need to point out how a commercial system would differ.

So What Does Centaur Do?

I have already described Centaur as the middle tier of a three tier system for booking package vacations. What is a three tier system? It is usually described as a system that incorporates display logic in one system (the browser), business logic in another (the middle tier) and database services in a third tier (the server tier):



As was shown in the diagram earlier, Centaur uses a slightly different model, combining business logic with a simple database in the middle (Centaur) tier, and using existing tour operator systems, which include both databases and business logic, as the server tier. There are two reasons for this approach. The first is that a vendor-independent search is simpler, quicker, more reliable and uses less network bandwidth if it is conducted on a single server. It's simpler because all the information is held locally in a consistent format, quicker and lower bandwidth because there is no need to interrogate other servers. And it's also more reliable since everything is held on a single server, which could have any degree of fault tolerance required, rather than on multiple remote servers, the failure of any one of which, or the network in between, would limit the value of the search.


The second reason is that, when we look at the functionality of the tour operator systems, they generally do not have the facilities for supplying vacation details. They tend to be old systems that manage only the transactional elements. This is why most multi-vendor on-line booking systems currently operating don't show any detailed information about the vacations. Typically, the information found in the brochure is held in a variety of word processor documents, spreadsheets and databases and only comes together at the publisher. So for Centaur, we will have to collect this information once only and hold it in the local database. This will ease implementation for the tour operator at the expense of increasing the size and complexity of the Centaur database.


So Centaur itself holds a database with information about the tour operators, their vacation destinations and individual vacations. The user can search for a vacation based on information about both the destination and the hotels (or villas or whatever) there. In general, we will use the terms "tour" and "vacation" and there is no reason why Centaur should not be used for cruises and other sorts of vacation as well.

A Brief Tour of Centaur

The diagram that follows shows typical navigation round the system. Of course, being an internet-based system, the user can go backwards and forwards as he or she pleases:



Let's now walk through the process that the diagram illustrates.

Welcome to Centaur!

When you log into the system (remember that you can build a copy of Centaur on your own machine – see Appendix A) you should see this screen:


As you can see, this welcome page tells you a little about the system and this book. In a commercial venture, I would expect all pages to make far more use of graphics (especially to get rid of those horrible grey buttons, which are used all over the application simply because using something better would not add anything to the XML aspects). This screen could also include advertising and links to other travel-related products such as insurance and books.

Finding and Displaying the Vacations

Suppose you click on the button to open a new brochure. This will take you to the main search screen, from which you can select vacations based on the type of vacation you want, where you want to go and the facilities you would like either on site or close by. If you select some criteria and submit the search, you will get one of three results. You could get no matches at all, which is quite likely as there are only fifteen vacations in the system database. You could get so many vacations that the search results would be confusing. In this case, you will get a message and the opportunity to see the results anyway or refine your search criteria. Of course, with fifteen vacations, this is not going to be the case, so the limit of the number of vacations to display before sending this message has been set artificially low at ten. You will get this result if you do not set any criteria before searching, or if you search for all Mediterranean vacations.


Of course, the result we want is a limited number of vacations as shown here:



Clicking on either of the vacations listed in the left frame will show its details in the right frame.

The information displayed is similar to that available in a tour operator's brochure. However, a brochure gives much more freedom to vary the layout from page to page. I have limited the tour operator to one photo of the resort and one for the individual vacation. If they want more, they have to create a montage. Here is the page for a vacation in Hammamet, Tunisia:




As I have it all resorts will be shown in the same format, but in the real world each tour operator will have a corporate image. One option would be to use my page layout as a standard, but develop individual styles for different companies as an extra-cost option. We will explore the ways that we might achieve this in Chapters 4 and 5.

Using the Brochure

What if you are at home viewing these vacations during the day and you see several you like that you would like to show the rest of your family later? Rather than write them down and search for them again, it would be good if you could save them in your own electronic brochure. Obviously, the brochure needs be saved and restored, so that you do not have to start from scratch if you come back to the system later. In the demonstration, the brochure is saved as a cookie on the client system, which will be wiped after 30 days (so make sure you have cookies enabled when you access the system!). We will see how to do this in Chapter 6.


There are advantages and disadvantages of this approach that will be discussed when we look at the brochure in more detail.


An advantage of the electronic brochure is that you can conduct further searches with different criteria and add more vacations to the brochure. This saves having to provide complex Boolean searching such as looking for a vacation in either Majorca or Cyprus, but nowhere else in the Mediterranean. The user should be able to view this brochure at any time and see the same details of the vacations as they did for the original search.



Care has been taken in the design of Centaur to ensure that the brochure is also accessible off-line. If you switch your browser to off-line mode (File | Work Offline), you will still be able to retrieve the brochure. This is particularly valuable where you are paying for online charges, either through your telecomms company or Internet Service Provider, as it allows you to browse at your leisure without incurring costs. This is more the atmosphere a tour operator would want while you are choosing your vacation.

Getting a Quotation

Once you have found a vacation you are interested in, the next step is to get a quotation. Centaur has a screen that will allow you to complete a form showing the start date and duration of your vacation and the number of adults, children and infants that you are booking for. From here, you can go back to the vacation details, but you are more likely to want to submit the information and get the quotation.


A fully commercial Centaur would, at this point, submit this information to the tour operator system to check availability and get an up to date price. It would be possible to calculate the price from the price tables, but tour operators may change prices without updating Centaur, so it is better to get the information directly from a system that we know will be kept up to date. This gives us both access to current availability and protects us from the situation that an airline got into in the early days of the Internet when it was prosecuted and fined for having out of date prices on its web site.


In the demonstration system, the tour operator system is simulated using a random number generator within Centaur, so the price you get will bear no relation to the brochure price.


Once you have submitted the form, you will see your quotation:



You can see that you have three options from here. Well, actually two, as we are not going to let the user book the vacation until they have accepted the supplier's terms and conditions.


So, assuming you want to go ahead and book, you can click to view the terms, then accept these. This will return you to the screen above, as well as enabling the booking option.

Making the Booking

The booking form is pre-populated with the details of the vacation chosen. There are also fields that can be filled in to specify a contact traveler, and for any others travelling with you.


After submitting the form, the user will get a confirmation screen for the booking:


And that is it. At the bottom of the screen (out of shot) is an Exit button. Clicking on this will take the user to an exit screen, from which they can get back into the main Centaur search screen using the startup option (new or existing brochure) used initially.

The Use of XML in Centaur

The two main uses of XML are for data interchange and for separating content from style when rendering pages for display. As a case study, it is clearly important that Centaur demonstrates both. The diagram shows where this is done:



The interface between Centaur and the tour operator system is clearly a messaging interface, and so can benefit from the use of XML as a data interchange technology. As such, it will require a DTD so the parser can be used to validate messages. This is a design decision that has an alternative. By enforcing a standard XML interface on all tour operators, I am forcing them to develop new front-ends to their systems. In a commercial environment, issues such as this generate power plays, with the possibility of some tour operators being able to say that their presence is necessary to the commercial viability of Centaur, and so I should interface to their proprietary interface. Should a particular tour operator wish to stick with their own proprietary DTD if necessary we can accommodate this by converting it using the transformations possible with XSL.


The user interface, on the other hand, is largely a display-based system that could be built quite adequately using HTML. However, XML has some real benefits in this environment, which I shall indicate as I build the interface. There are places where I use XSL to display pages, and places where I use the DOM and JScript. All these techniques are described in subsequent chapters.


The brochure is also stored as an XML text string in a cookie.

The Vacations

Centaur is designed to search for and display vacations from multiple tour operators. It would obviously make the system more realistic if we were to use real vacations rather than make them up. So, many thanks to two UK tour operators — Panorama Holidays and Argo Holidays — that have allowed me to use material from their Winter 1998/99 and Summer 1999 vacation brochures. These tour operators fit the Centaur profile well — Argo specialises in vacations to a single location — Cyprus, while Panorama has a few brochures, both to specific locations such as Tunisia and for specialist vacations such as golfing vacations. So, thanks to them, we can look at real vacations in Centaur.


This chapter has been very much about the background to the case study, and the process of user interaction with the system. You should now understand:


q       some of my views on software development

q       a bit about recent changes in the UK leisure travel industry

q       the aims of Centaur and the conflicts between those aims

q       some of the changes that would be necessary to turn Centaur into a commercial system

q       what Centaur does and how it uses XML


We also now have a list of the basic functional requirements for our application. It must:


q       be able to interface with, and retrieve up-to-date data from, tour operator information databases based on search criteria the user specifies

q       be able to collate that data into an integrated, sorted data set

q       allow the user to select a subset of the vacations information from the data set, and persist that on the off-line client machine as a personalized brochure

q       allow the user to select a vacation from the brochure, get a quotation, and if they want to, book it


In the next chapter we will take a look at XML and why it provides the means to satisfy these requirements in a comparatively straightforward manner, without the need for complex format conversion components.


[1] Survey by The Network, published in the Travel Trade Gazette 9/9/98.

©1999 Wrox Press Limited, US and UK.

Buy this book

Select a Book

Beginning XML
Beginning XHTML
Professional XML
Professional ASP XML
Professional XML Design...
Professional XSLT...
Professional VB6 XML
Designing Distributed...
Professional Java XML...
Professional WAP

© Wattle Software 1998-2019. All rights reserved.