Travel and Hospitality
With the volume of information that is available nowadays for travel and leisure services, the need to enable the fairly arcane reservation and scheduling systems in place in the travel and hospitality industries has become more urgent. XML has been provided as a technology capable of meeting these next-generation needs.
Like the manufacturing, health care, and other industries using EDI, the travel industry has been previously dominated by older data formats and mechanisms that have attempted to solve similar problems in data exchange. In the case of the travel industry, the systems that have been widespread are Global Distribution Systems (GDSs). The goal of GDSs is to centralize, consolidate, and deliver travel supplier information for the online booking of reservations. The primary users of GDSs are travel agencies, but in the past few years a number of consumer-focused GDSs have been increasingly available over the Web. GDSs currently present information only on the companies that subscribe to their services and supply data to them, and the format is as arcane and inflexible as EDI is for the manufacturing industry. Therefore, there is movement afoot to replace the GDS systems with an XML-based mechanism to extend the functionality of those systems.
Open Travel Alliance (OTA)
The hospitality and travel industries are undergoing rapid change in this wired era, and XML is helping along the way. While data formats and standards have long been a staple of the airline, hotel, and car-rental organizations, never before have these various compo-nents of the travel industry gotten together and agreed on any one common format. Evolving from the continuing work and effort of the Hospitality Industry Technology Integration Standards (HITIS), the Open Travel Alliance (OTA) aims to solve this critical problem.
The OTA was created in May 1999 as a means for generating a set of standards for the hospitality and travel industries. The OTA organization is a consortium of suppliers in many different sectors of the travel industry, including air, car rental, hotel, travel agen-cies, and tour operators, as well as related companies that provide distribution and tech-nology support to the industry.
OTA’s first deliverable is an XML-based specification that covers the various needs of airline, hotel, car, and entertainment facilities. The OTA effort is an outgrowth of work that has been going on for many years in HITIS. HITIS was mainly focused on the development of standard specifications for internal processes such as Point of Sale (POS), reservation, and Property Management Systems (PMS). However, HITIS was not really focused on standardizing systems to communicate externally with other properties, suppliers, partners, and customers. As such, HITIS focused “inside the property,” and the OTA was created to solve the needs of standardizing “outside the property.” The OTA effort, launched at first independently of HITIS, soon merged with the OTA effort as HITIS began to consider XML as a means for its internal specifications.
The first year of OTA specifications extended the HITIS standards and delivered a hand-ful of transactions that had been partially defined as part of HITIS. However, in the past few months, OTA has been very active in the development of industry-specific vocabu-laries that can give industry players, as well as tools and software vendors, the opportu-nity to create solutions based on the OTA approach.
The OTA is comprised of five working groups focusing on each of the different sectors of the market: air, car, hotel, leisure supplier, and nonsupplier, as well as an interoper-ability committee to ensure consistency. Each industry group is defining transactions that are unique to its industry, and the infrastructure group is trying to define the elements that all these industries share in common. Although they’re all operating under the auspices of OTA, in reality each industry group is working independently and progress-ing at its own rate. In the hotel industry group, most of the major hotels and chains are represented: Cendant, Bass, Marriott, Sheraton, Hilton, and many others. A few of these chains, such as Cendant and Bass, had people assigned to HITIS group prior to their involvement in OTA. Therefore, many of these firms had a vested interest in continued standards development. All the participants in the hotel group are very active, making substantial progress on the development of various hotel industry vocabularies and mes-sages. The group meets face to face at least three or four times per year in addition to numerous conference calls between meetings.
The OTA specification is a message-oriented protocol that specifies requests and responses for various industry-specific actions. The major features in the hotel portion of the OTA specification include the ability to create, modify, and cancel reservations as well as create and pass rate information, detailed and complete rate structures, booking rules, price availability and applicability, room and property availability, and requests for generic availability within a certain geographic area across multiple properties. The latest OTA version, v4.0, is an integration of HITIS into OTA. The end result will be that con-tinued development will be under the watch of OTA, rather than HITIS. Of the two orga-nizations, OTA is most likely to exist in the long run.
There is continual discussion within the group about how OTA can interact with other standards efforts and identify how other standards groups and industries are defining similar vocabularies. However, it seems that getting the various industry groups within OTA to communicate and converge their standards efforts is not easy either. One of the big issues within OTA is getting internal agreement—never mind competing standards— on vocabulary and processes among the air, hotel, car, and related industries. To solve this issue, there are big efforts within OTA to normalize what each of the groups are pro-ducing and to ensure a level of cohesiveness throughout all the specifications. Currently, OTA has not integrated with other standards efforts, but as internal agreement occurs, there is no doubt that the organization will look to other standards groups to integrate, converge, and/or leverage its efforts.
On other fronts, however, OTA is working well with other standards groups. The organi-zation is looking to tie itself more closely with the ebXML specification as a means for transporting industry messages in a standard manner. The infrastructure committee within the OTA is planning to use ebXML as a transport layer, wrapping its OTA mes-sages within MIME wrappers as a means for transporting, routing, and packaging indus-try messages. In the hotel industry, the prevalent vocabularies have been defined by two organizations in particular: the Hotel Electronic Distribution Network Association (HEDNA) and the Hospitality Industry Technology Integration Standards (HITIS).
The HITIS standards leveraged previous efforts of the Windows Hospitality Interface Specifications (WHIS) for its base documents in the development of its standards. The OTA specifications, originally based in part on the WHIS and HEDNA development, have recently merged with HITIS efforts, thus combining many of the best efforts of previous generations.
The latest OTA specification, known as OTA 2001A, is actually divided into two parts: the OTA Infrastructure and the Profile Specification. The OTA Infrastructure section defines how OTA documents are exchanged in a secure and reliable manner between trading partners. The OTA 2001A Infrastructure specifies a request/response mechanism for transmitting messages and can support both synchronous and asynchronous messag-ing capability. The OTA Infrastructure makes use of the ebXML header and a modified version of the manifest part of that header document for transport, routing, and packag-ing. In addition, the OTA Infrastructure supports four basic message types: Create, Read, Update, and Delete. Each of these operations are applied to the profile that is described later in this section. Although Create, Read, and Delete operations apply to a document as a whole, the Update method utilizes XPath to enable partial record updating. In addi-tion to these, the OTA 2001A Infrastructure has well-defined security features, including authentication, encryption, confidentiality, message integrity, and a separated control mechanism for altering these security features. The OTA Infrastructure specification only allows for a connection to one trading partner per message, but it supports multiple pay-loads that may include different operations or batch operations in one message.
The Profile Specification is the content that is transmitted in the OTA Infrastructure and specifies a common customer “profile” that individual travelers and organizations can fill out once and exchange among various travel services over the Internet. A profile is a standard vocabulary that communicates data about the identity of a person or company as well as the person’s or company’s contacts and various “affiliations,” including loyalty programs, forms of payment, travel documents, and detailed travel preferences. Profiles allow users to define collections of travel preferences in terms of specific travel plans and experiences, which can also include preferences for various air, hotel, car, rail, and other travel services. Preferences can be simply defined or contain more complex condition-based choices and dependencies. The profile not only identifies an individual or company but also affiliated persons, such as family members, companions, or business colleagues, as well as affiliated agencies, such as travel agencies, travel clubs, or employers. Profiles are identified by a globally unique identifier, comprised of an identifying string in com-bination with a URL that specifies the location of the identifier.
Due to the sensitivity of travel information, the OTA 2001A specification contains strict privacy requirements that have also been detailed in previous versions of the specification. These privacy preferences allow customers and companies to indicate the data that can be shared with other parties. Various attributes specified with this privacy information indicate whether the data may be shared for the synchronization of system information, such as keeping all copies of the profile on remote sites identical with the original, shared for marketing purposes, or not shared at all.
Prior to any exchange of information, the parties engage in a conversation to determine the capabilities of each other’s systems and their support for different transport protocols, security, and required fields. This is accomplished using nonversioned discovery mes-sages. To deal with the situation of identifying trading partners, the OTA 2001A specifi-cation supports a simple trading partner model, or exclusive trading partner agreement, that involves linking one requestor to one supplier. Although OTA supports the dynamic discovery of trading partners and their capabilities, there is currently no capability to determine whether a proper contract exists or to verify the validity of the trading partner; therefore, the feature remains unsupported. The issue of dynamic partner discovery will no doubt be addressed in future specification releases or in conjunction with other standards efforts.
The Open Travel Alliance is one of the more successful and notable XML-based vertical industry standards currently in existence. Part of its positive publicity is due to the focus of the standard and its acceptance of existing efforts that have attempted to produce spec-ifications relevant to the travel industries. In particular, it has gained the support of other travel and hospitality industry groups such as the Hotel Electronic Distribution Network Association (HEDNA) and the American Hotel & Motel Association (AH&MA), devel-opers of the Hospitality Industry Technology Integration Standards (HITIS). This support has allowed OTA to excel in many capacities as far as standards development and adop-tion. OTA has recruited some of the most notable travel industry organizations, ranging from businesses such as United and Marriott, to industry associations such as AH&MA and HEDNA.
Their recent merger of efforts with HITIS (read the HITIS specification, available on the OTA Web site) continues to bolster its credibility within the industry and possibility for widespread adoption success. The true measure of success will come when the major Global Distribution Systems such as Sabre and Worldspan choose to use OTA as their primary means of communication instead of the more arcane ResTeletype (a 64-character code system) and UN/EDIFACT (an EDI-based protocol) systems. Some of the major GDS providers are part of the OTA effort, which seems to bode well for their future success. A sample OTA XML file excerpt can be found in Listing 22.8.
<PersonName NameType=”Default”> <NameTitle>Mr.</NameTitle> <GivenName>George</GivenName> <MiddleName>A.</MiddleName> <SurName>Smith</SurName>
<TelephoneInfo PhoneTech=”Voice” PhoneUse=”Work”> <Telephone>
<StreetNmbr POBox=”4321-01”>1200 Yakima St</StreetNmbr> <BldgRoom>Suite 800</BldgRoom> <CityName>Seattle</CityName>
<StateProv PostalCode=”98108”>WA</StateProv> <CountryName>USA</CountryName>
<RelatedTraveler Relation=”Child”> <PersonName>
<RelatedTraveler Relation=”Child”> <PersonName>
</RelatedTraveler> <RelatedTraveler Relation=”Child”>