HEDNA White Paper: Push and Pull Connectivity Models for Hotel

Hotel Electronic Network Distribution Association ● 750 National Press Building ● 529 14th Street, NW ● Washington, DC 20045 ● www.HEDNA.org ● Tel. 202-204-8400 ● Fax 202-591-2445

HEDNA White Paper: Push and Pull Connectivity Models for Hotel Distribution

BACKGROUND

The HEDNA Connectivity Working Group (CWG) was formed

following HEDNA‟s 2011 winter conference based on a general

agreement by the represented membership that the challenges of

developing and maintaining multiple distribution interfaces in the

absence of any real standardized implementation is a problem that

the industry needs to address. The group is comprised of members

representing suppliers, distributors and intermediaries that are

committed to achieving the goal of simplifying the way in which they

interact with each other to facilitate the distribution of hotel rates,

availability and reservations through automated interfaces.

INTRODUCTION

The terms “push” and “pull” are applied frequently in reference to the

models of connectivity and data exchange that are employed between

hotel distribution systems. This paper provides an analysis of the

models at both technical and business-logic levels in order to

establish a set of commonly held definitions, provide perspectives on

the way the models are used and offer a comparison of their

similarities and differences.

The HEDNA Connectivity Working Group white paper entitled The

Future of Shopping defined the roles of Data Originator, Data

Publisher and Data Consumer in the communication and

representation of hotel rate and availability data and the development

and maintenance of connections between distribution systems. These

roles apply also in the consideration of push and pull models. This

paper examines how each role is involved in the exchange of

availability, rate and inventory (ARI) information, descriptive content,

and reservation details. It also considers the variety of ways in which

the technical process of data transfer may be established between the

participants in an interface.

The paper includes background information and illustrates the

concepts of push and pull. Its purpose is to serve as a reliable

reference document for hospitality suppliers, intermediaries,

distributors, technology providers, and anyone else with an interest in

the specifics of distribution connectivity.

CONTRIBUTORS

Craig Barnby Vice President of Product Development Pegasus Solutions Tom Bruno Director, eDistribution Development & Operations Marriott International Lew Harasymiw Director of Interface Solutions Sabre Hospitality Solutions Cody Kiker Client Manager/Solutions Engineer DerbySoft Rachel Neal Director of Client Implementations DerbySoft TJ Noble Account Manager, Electronic Distribution Hyatt Hotels and Resorts Dave Revelle Senior Director of Global Partnerships DerbySoft Nader Troudi Director of Technology Expedia Tim Unwin Executive Vice President, Hospitality Solutions RateGain

http://www.HEDNA.org

http://c.ymcdn.com/sites/www.hedna.org/resource/resmgr/docs/hedna_future_of_shopping_whi.pdf


2

2 Hotel Electronic Network Distribution Association ● 750 National Press Building ● 529 14th Street, NW ● Washington, DC 20045 ● www.HEDNA.org ● Tel. 202-204-8400 ● Fax 202-591-2445

DEFINITIONS

In the context of the hotel distribution methods considered in this paper, the first step is to define the “who”,

“what” and “how” elements which combine to form the complete picture. Roles and methods are outlined

below.

Roles

Data Originator:

Any system in which hotel data is first created or first appears. In practice, a Data Originator is usually

a PMS or a CRS, or possibly a Channel Manager.

Data Publisher:

Any system that accepts data and then re-publishes or redistributes that data. Typical Data Publishers

include CRSs, Channel Managers, Intermediaries, Switches, GDSs, OTAs, etc.

Data Consumer:

Any system that accepts the data and uses it to enable the search for and/or the sale of hotel rooms,

including booking transactions, traffic referrals, data analysis, etc. Examples of Data Consumers are

OTAs, GDSs, search engines, bed banks, etc.

[For additional examples and background see The Future of Shopping]

The roles outlined above are not fixed in the sense that a particular entity may play more than one role

depending on the nature of the transaction and its participants.

Methods

Push:

The Originator or Publisher initiates or triggers the message flow that sends data to the recipient. In a

Push the Originator/Publisher is the active party and the recipient of the data is passive.

Pull:

The Originator or Publisher maintains the current state of the data and the recipient (either Publisher

or Consumer) initiates an inquiry for the data. In a Pull, the recipient is the active party and the

Originator/Publisher is passive.

Hybrid:

A combination of both push and pull elements either a) within a single data exchange or message

flow, or b) over the course of a transaction sequence which achieves a particular business result.

An analogy that can be used to further illustrate the nature of Push and Pull methods is the comparison

between a text message and a phone call. A text message is a push transaction: the source of the message

(or data) is the active party, and the message is delivered to a passive recipient. A phone call, in contrast, is a

pull transaction in that the caller (the recipient of the data) has initiated a request for the data (in this case the

“data” is a conversation) from a passive source.




3


In order to represent the various options and models accurately, consideration of the broad types or

categories of business transactions is also necessary. These categories are defined in detail in the following

section and include: i) transactions related to the maintenance of Availability, Rates and Inventory (ARI), ii)

transactions related to making and confirming bookings, and iii) transactions related to loading, updating and

querying of descriptive content. Note that within a given business transaction or model, each of these

transaction types can be executed by different methods (push or pull) and by different roles (Data Originators,

Publishers and Consumers.)

Transaction types: Availability, Rates and Inventory (ARI)

Non-Cached (Pull and Use): The Data Consumer submits a request to the Data Originator/Publisher‟s system to inquire about

rates and availability for a particular hotel, date, LOS, etc. This response is generated by a consumer

request for use at the time of inquiry. The Data Originator/Publisher responds in turn with the rates

and availability data.

Example: A shopper using a Data Consumer selects a specific hotel, date, and LOS. The request is sent to

the hotel‟s CRS (Data Originator), and an availability response is sent back for the shopper to view and

subsequently make a decision to book or not.

Cached (Push):

The Data Originator or Publisher sends a message containing the change in availability and/or rates

to the pertinent Data Consumer. This updates the data within Data Consumer‟s system so that it

continues to be an accurate reflection of the data within the Originator‟s system.

Example: The hotel CRS (Data Originator) sends an ARI message to the Data Consumer where it is cached.

Any shopping for the hotel will be done on the Data Consumer‟s cache rather than on the hotel‟s system.

Cached (Pull):

The Data Consumer submits a request to the Data Originator/Publisher‟s system to inquire about

rates and availability for a particular hotel, date, LOS, etc. This request is generated by a caching

system, scheduling system, algorithm or shopper‟s search. The Data Originator/Publisher responds

in turn with the rates and availability data that is stored in the Data Consumer‟s cache for further use.

Example: A shopper using a Data Consumer selects a specific hotel, date, and los. The request is sent to

the hotel‟s CRS (Data Originator), and an availability response is sent back for the shopper to view and

subsequently make a decision to book or not. The Data Consumer caches the response for future shoppers

searching the same criteria to avoid redundant transactions being sent to the Data Originator.

Change Discovery Service - CDS (Push / Pull):

Change Discovery is a method of discovering and communicating the existence of change in rates and

availability. Change Discovery allows a Data Publisher or Consumer system to determine whether there has,

or has not been, a change in rates or availability status for a given time frame. With Change Discovery, a

Data Originator, Data Publisher and Data Consumer can communicate with small, efficient messages that

provide a base for building targeted full availability requests for the change detail. This makes each

availability message more useful, meaningful, and efficient, and it effectively eliminates availability requests

for data that has not changed.


4


CDS Push: The Originator or Publisher initiates or triggers the message flow that sends the change notification to the recipient. The Originator/Publisher is the active party as it is responsible for distributing the data, whereas the recipient is passive. CDS Pull: The Originator or Publisher maintains the current state of the data and the recipient (either Publisher or Consumer) initiates an inquiry for the change data. The recipient is the active party in this case, and the Originator/Publisher is passive. More information on CDS can be found in the HEDNA white paper.

Rendered Shopping (Push / Pull):

Rendered shopping allows Originators to provide the rate and availability information in the form of

pre-calculated shopping results, which will be referred to as „rendered shopping data‟, or more

specifically, a „shopping data cube‟. This will contain the rate and availability status information for a

large set of potential room stays, where a room stay is identified by a combination of attributes such

as the property ID, arrival date, length of stay, occupancy, rate plan, room type etc. This means that

shopping requests can be processed by simply using the criteria to look up the rate and availability

status information exactly as it is specified by the supplier in the shopping data cube, without the Data

Consumer having to make any calculations or apply complicated rules. Essentially, this new

approach proposes that the Data Originator communicates explicit shopping data to Data Consumers

whenever a rate or availability status changes, instead of relying on the Data Consumer to calculate

these values based on their interpretation of abbreviated representations of the data.

Rendered Shopping – Push: The data cube is maintained and published by the Data Originator that triggers the message delivery. The Data Consumer is passive.

Rendered Shopping - Pull: The data cube is maintained and published by the Data Originator and the Data Consumer/Publisher triggers the message delivery. The Data Originator is passive.

More information on Rendered Shopping can be found in the HEDNA white paper.

Transaction Types: Reservations

Reservation processing is commonly divided into two categories referred to as Reservation Notification and

Reservation Request. Either push or pull mechanisms may apply to Reservation Notification; Reservation

Request is typically a pull transaction.

Reservation Request (Pull):

In a Reservation Request the Data Consumer/Publisher sends booking details to the Data Originator

and waits for confirmation before confirming back to the guest that the process is complete. It is

literally a request for a reservation.

Reservation Notification (Push):

In a Reservation Notification the Data Consumer/Publisher sends details of a booking that is already

confirmed to the Data Originator. The booking will typically have been confirmed to the guest before

the notification process starts. Literally, the Data Consumer/Publisher is notifying the Data Originator

of a confirmed booking.


http://c.ymcdn.com/sites/www.hedna.org/resource/resmgr/docs/hedna_change_discovery_servi.pdf


5


Reservation Notification (Pull)

In the pull version of Reservation Notification, the Data Originator initiates the process by sending a retrieval

request to the Data Consumer/Publisher. Once again, the booking will typically have been confirmed to the

guest before the notification process starts.

Transaction Types: Content

Static Content:

Static content consists of descriptive information that changes infrequently. This includes property address,

amenities, latitude/longitude, directions, etc. This type of data can be communicated via a push or a pull

transaction set just as with rates and availability data. The frequency of the delivery of such messages is

much less than that of the rate and availability messages because this data changes much less frequently.

Semi-static Content:

Semi-static content consists of data that is necessary to transact an availability message or a

reservation but is not part of the rates or availability. Taxes, guarantee policies, cancellation policies,

rate plan codes, occupancy restrictions, etc. typically comprise semi-static content. This type of data

can be communicated via a push or a pull transaction set just as with rates and availability data. The

comparative frequency of the delivery of such messages corresponds with the frequency of changes

in the data contained within, i.e. semi-static data changes less frequently than rates and availability,

but more frequently than static (descriptive) data.

IMPLEMENTATION MODELS

1. Acquiring ARI Information Using Pull Hotel availability, rates, and inventory may be acquired via any of several Pull models. As noted above, the

primary feature of the pull model is that information is being requested from the Data Originator or Publisher.

Pull (Direct Connect and non-Cached)

This is the simplest model. A Data Consumer requests (i.e. pulls) ARI data by sending availability request

messages to the Data Originator. The Data Originator replies synchronously by sending availability response

messages to the Data Consumer:


6


Pull (Direct Connect and Cached)

This is similar to the previous model except that the Data Consumer caches the ARI data locally after pulling

it. The cache population mechanism may include some form of Change Discovery and/or Rendered

Shopping as described earlier in this document:

Pull (with Publisher and non-Cached)

In this model the Data Consumer does not interact directly with the Data Originator but instead gets the ARI

data from a Data Publisher. The Data Publisher serves as a communication hub in this case, receiving data

from the Data Originator and providing it to the Data Consumer:


7


Pull (with Publisher and Cached)

In this model the Data Consumer does not interact directly with the Data Originator but instead gets the

availability data from a Data Publisher. The Data Publisher serves not only as a communication hub but also

provides a caching mechanism:

2. Distributing ARI Information Using Push

Just as there are several Pull models, any of several Push models may be used for the transfer of ARI data.

In these cases, the Data Originator or Publisher initiates the distribution of information.

Push (Cached)

The Data Originator distributes ARI directly to the Data Consumer. The Originator initiates the flow of data

that is received and cached by the Consumer and used when responding to hotel shopping enquiries. Either

the Originator or Consumer may dictate the format and layout of the data:


8


Push (with Publisher and Cached)

The Data Originator distributes ARI to a Data Publisher who subsequently redistributes it to the Data Con-

sumer. The information flow is initiated by the source in each case. The format and layout of the data may be

dictated by any of the parties in the communication. Note also that the format and layout might be adjusted or

altered by the Publisher mid-flow. Data may be cached by the Consumer or by both the Consumer and the

Publisher, depending on the implementation model:

3. Hybrid Models for Availability

In situations where a Data Publisher is involved in the communication of ARI, the mechanism used by the

Publisher to communicate with the Originator can be different from the mechanism used by the Consumer to

communicate with the Publisher. For example, the Publisher might deploy a cache that is populated using

Pull transactions but then distribute the availability information to Consumers using Push transactions:


9


4. Reservation Requests and Notifications

Reservation processing is commonly divided into two categories referred to as Reservation Request

(generally a pull transaction) and Reservation Notification (for which either push or pull mechanisms may be

employed).

Reservation Request (Pull)

In a Reservation Request, the Data Consumer/Publisher sends booking details to the Data Originator and

waits for confirmation before confirming back to the guest that the process is complete:

Two-phased Reservation Request (Pull)

In some situations there may be two phases to the Reservation Request process:


10


Reservation Notification (Push)

In a Push Reservation Notification, the Data Consumer/Publisher initiates the process by sending details of a

booking that is already confirmed to the Data Originator. The booking will typically have been confirmed to

the guest before the notification process starts:

Reservation Notification (Pull)

In the pull version of Reservation Notification, the Data Originator initiates the process by sending a retrieval

request to the Data Consumer/Publisher. Once again, the booking will typically have been confirmed to the

guest before the notification process starts:


11


USE CASES AND ADDITIONAL CONSIDERATIONS

Data Consumers generally fall into one of two main categories, depending on their mode of operation:

“Seamless” processing, as employed by GDSs and some OTAs, in which pull transactions predominate;

Extranet and cache configurations, used by the majority of web-based Data Consumers, in which ARI

updates and reservations are typically processed using a mixture of push and pull transactions.

Some Data Consumers may be in both categories at different times. One of the key differences between the

categories is that, in the case of ARI and descriptive content, seamless processing tends to involve a

centralized or “single source” view of information, whereas the use of extranets and caches leads to the

replication of information in multiple locations.

For Data Originators, especially those with large portfolios of hotels and substantial volumes of data to

maintain, the use of the pull model for ARI and descriptive content is considered preferable because it

generally allows more granular control over factors such as last room availability or the application of yield

management restrictions. However, because the configuration of many Data Publishers and Data Consumers

is more compatible with push transactions, the decision for Originators between Push and Pull is not simple.

Channel management products evolved as a method of automating the maintenance of information on

multiple Data Consumer extranets. The first channel managers were built to push ARI to a number of

destination sites, each of which had its own representation of rates and room types to be sold. As a result,

the primary function of early channel managers was to provide the mapping between the Data Originator‟s

data structure and that of the Data Consumer.

Over time, the role of channel managers has evolved in sophistication to include, for example, the delivery of

reservation notifications from Data Consumer to Data Originator. This in turn has led to more elaborate

deployment models and allowed channel managers to offer another layer of control in the distribution

process.

In today‟s environment, the range of Data Publishers has expanded to include a variety of intermediary

technologies that are able to extract and deliver data to and from Originator and Consumer systems (using

both push and pull transactions). These technologies can also store, manipulate, and translate the data

according to the business processes being performed, and then redistribute the data in a format appropriate

to the recipient. These functions of collection, translation and delivery facilitate the communication between

Originators and Consumers and reduce the need for one party to adapt technology and processes to match

the other.

The entire process of managing ARI, content, and reservations has become increasingly complex and

inefficient for Data Originators, Data Publishers, and Data Consumers. The volume of shopping requests

continues to grow at a rate that would be unmanageable for most of the systems that originate the data to

answer directly without the buffer provided by the databases and caches of the systems that consume it. At

the same time, the volatility of the data is also increasing, which magnifies for Data Originators the task of

keeping all of the data they distribute current.

The challenge presented by increasing volumes of both shopping requests and changes in ARI data is further

complicated by the lack of adoption of a standardized representation of rates and availability. This results in


12


both Data Originators and Data Consumers needing to manage these volumes across multiple different

message formats. Yet another complication is that not all Data Consumers can easily support or replicate the

variety of restrictions and business rules required by increasingly sophisticated Data Originators.

This lack of consistency in functionality and business logic across various systems leads to price and

availability disparity as products that appear on one site may be priced differently on another or may be

missing altogether. These disparities disadvantage both the Data Consumers and Data Originators, and they

can be exacerbated if a Data Publisher is involved as this adds an additional layer of complexity and another

party‟s system, the potential limitations of which may negatively impact the distribution flow.

For more information about HEDNA, visit HEDNA.org, email [email protected] or call 202-204-8400.


Documents

HEDNA White Paper: Push and Pull Connectivity Models for Hotel