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.
<Profile>
<Customer>
<PersonName
NameType=”Default”> <NameTitle>Mr.</NameTitle>
<GivenName>George</GivenName>
<MiddleName>A.</MiddleName> <SurName>Smith</SurName>
</PersonName>
<TelephoneInfo
PhoneTech=”Voice” PhoneUse=”Work”> <Telephone>
<AreaCityCode>253</AreaCityCode>
<PhoneNumber>813-8698</PhoneNumber>
</Telephone>
</TelephoneInfo>
<PaymentForm>
...
</PaymentForm>
<Address>
<StreetNmbr POBox=”4321-01”>1200 Yakima
St</StreetNmbr> <BldgRoom>Suite 800</BldgRoom>
<CityName>Seattle</CityName>
<StateProv
PostalCode=”98108”>WA</StateProv>
<CountryName>USA</CountryName>
</Address>
<RelatedTraveler
Relation=”Child”> <PersonName>
<GivenName>Devin</GivenName>
<MiddleName>R.</MiddleName>
<SurName>Smith</SurName>
</PersonName>
</RelatedTraveler>
<RelatedTraveler
Relation=”Child”> <PersonName>
<GivenName>Amy</GivenName>
<MiddleName>E.</MiddleName>
<SurName>Smith</SurName>
</PersonName>
</RelatedTraveler> <RelatedTraveler
Relation=”Child”>
<PersonName>
<GivenName>Alfred</GivenName>
<MiddleName>E.</MiddleName>
<SurName>Newman</SurName>
</PersonName>
</RelatedTraveler>
</Customer>
</Profile>
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.