Point of View

ESB for Hotel System

Table of Contents
Using an enterprise service bus (ESB) for integrating hotel systems 02
Enterprise hotel systems 03
Issues with point-to-point integrations 04
Enterprise service bus 04
Core ESB features 07
The advantages of using an ESB 07
The disadvantages of using an ESB 08
When to use and when not to use? 10
Conclusion 11

Using an enterprise service bus (ESB) for integrating hotel

systems

ENTERPRISE HOTEL SYSTEMS

Enterprise hotel chains, by their very nature, tend to contain many disparate systems and
applications which provide various services. Hotels rely on these systems to run their day-
to-day business. A single hotel chain might use various systems (either developed in-house
or purchased from some vendor) to manage inventory, reservations, guests, property data,
execution, customer relationship, and employee information, among others. The driving force
of quick adaption to changing business needs and using best of technical advancements
make it logical to divide tasks of running business into multiple smaller functionalities.
Hence, such modularization of systems is justified. However, these systems need to work in
conjunction to execute the business successfully.

01
Think what happens when you hit express check-out button on an in-room guest
management system.

1. Your name and room number is displayed

2. Reservation charges are displayed
3. Charges against the items you ordered through concierge system are displayed
4. Charges against the food items you ordered at the restaurant are displayed
5. Loyalty points you earned during your stay are displayed
6. You get an option to send the folio to the email ID of your choice

It’s obvious that all the data listed earlier comes from various discrete systems such as:

1. Property Management System (PMS)

2. Central Reservation System (CRS)
3. Concierge system
4. Loyalty solution
5. Email is sent through some email client

How does in-room guest management system pull data from these systems? What interfaces
does it use? It can be CSV, XML, SOAP, JSON, HTTP, REST, FTP, AMQP, and the list goes on.
Point-to-point integration has been used traditionally wherever communication was needed
between two systems. Use of service layer with adapters or a connector component works
well for such communication. Refer to the diagram 1.1.

ENTERPRISE HOTEL SYSTEM

Agent Concierge
Booking Channel software

Translation
software Communication solution
(email/sms etc)
Guest management
software
Brand site
+
Booking engine
CRS

PMS

CMS Authentication

Loyalty
solution

Diagram 1.1: Enterprise hotel systems

02
ISSUES WITH POINT-TO-POINT INTEGRATIONS

Challenges increase when more than three systems need to integrate with each other.
Maintaining multiple point-to-point connectors becomes unmanageable with increase in the
number of systems.

In diagram 1.1, there are 11 different systems. If it is assumed that each system talks to all the
other systems, we will have 110 interfaces. Diagram displays logical systems. What if we scale
out any of the 11 systems on multiple servers? What if we decide to rewrite any of the 11
systems? Creating and maintaining point-to-point integration is expensive in the long run.

ENTERPRISE SERVICE BUS

An enterprise service bus (ESB) is a software architecture model used for designing and
implementing communication between interacting software applications in a service-oriented
architecture.

An ESB can simplify the aforementioned integration scenario to a great extent. The same
system using an ESB will look something like the following diagram 1.2:

ENTERPRISE HOTEL SYSTEM ON ESB

Brand Sites
Agent
+ Translation
CRS Booking Concierge CMS
Booking Software
Channel
Engine

ESB Adapter ESB Adapter ESB Adapter ESB Adapter ESB Adapter ESB Adapter

Service Bus (JMS / AMQP Server)

ESB Adapter ESB Adapter ESB Adapter ESB Adapter ESB Adapter

Guest
Loyalty Communication
Authentication PMS Management
Solution Software
Software

Diagram 1.2: Enterprise hotel systems on an ESB

03
In diagram 1.2, systems do not exchange information by calling each other directly. Instead,
they route the information through an ESB. Hence, each system needs maximum of two
interfaces (inward and outward) to talk to an ESB. In the aforementioned example, where 11
systems are interacting, maximum of 22 interfaces will be needed instead of 110 in case of
point-to-point integration.

Technically, an ESB is a messaging backbone which does protocol conversion, message

format transformation, routing, and accepts and delivers messages from various services and
applications which are linked to an ESB.

Let us revisit diagram 1.1 to highlight the following points:

• Point-to-point integration is replaced by the ‘bus’ concept. Bus is usually Java Message
Service (JMS) or Advanced Message Queuing Protocol (AMQP) server.
• Data travels on bus in a canonical format. Mostly, the data is formatted as XML. Canonical
format is a kind of contract between systems and is essential for communicating with
other systems on a bus.
• Adapter plays an important role. It marshals data between a bus and the application.
This is the component where an ESB differs from hub-and-spoke model of Enterprise
Application Integration (EAI). Adapters do all the magic of data format transformation,
protocol conversion, security, error handling, and transaction processing, among others.
It does not perform any business logic though.
• An ESB as a product also provides other features such as managing and governing the
ESB from a central dashboard.

CORE ESB FEATURES

As per Wikipedia, the following capabilities are considered as core features of an ESB:

Category Functions
Invocation Support for synchronous and asynchronous transport protocols and service mapping
(locating and binding)
Routing Addressability, static or deterministic routing, content-based routing, rules-based routing, and
policy-based routing
Mediation Adapters, protocol transformation, and service-mapping
Messaging Message-processing, message transformation, and message enhancement
Process choreography Implementation of complex business processes
Service orchestration Coordination of multiple implementation services exposed as a single, aggregate service
Complex event processing Event-interpretation, correlation, and pattern-matching
Other quality of service Security (encryption and signing), reliable delivery, and transaction management
Management Monitoring, audit, logging, metering, and admin console
Agnosticism General agnosticism to operating-systems and programming-languages; for example, it
should enable interoperability between Java and .NET applications
Protocol conversion Comprehensive support for topical communication protocols service standards
Message exchange patterns Support for various Message Exchange Patterns (MEPs). For example, synchronous request /
response, asynchronous request/response, send-and-forget, and publish/subscribe)

04
 Category Functions
Adapters Adapters for supporting integration with legacy systems possibly based on standards such as
Java EE Connector Architecture (JCA).
Security A standardized security-model to authorize, authenticate, and audit use of the ESB.
Transformation Facilitation of the transformation of data formats and values, including transformation services
(often via XSLT or XQuery) between the formats of the sending application and the receiving
application
Validation Validation against schemas for sending and receiving messages
Governance The ability to apply business rules uniformly
Enrichment Enriching messages from other sources
Split and merge The splitting and combining of multiple messages, and handling of exceptions
Abstraction The provision of a unified abstraction across multiple layers
Routing and transformation Routing or transforming messages conditionally, based on a non-centralized policy (without
the need for a central rules-engine)
Queuing and staging Queuing, holding messages if applications become temporarily unavailable or work at
different speeds.
Commodity services Provisioning of commonly used functionality as shared services depending on context.

THE ADVANTAGES OF USING AN ESB

• ESB is made up of many interoperating services rather than a point-to-point or single

hub component. Hence, it is lightweight. It can be made as heavy or as light as per the
requirement of an organization.
• ESB makes the architecture easy to adopt changes, additions or removals. To make a new
system ready to work, all that one needs is to hook it on the bus.
• Unlike point-to-point or hub-and-spoke approach, ESB can be scaled out easily. It can
also be dispersed across geographical network, if required. As individual components are
used to implement unique feature, it is simpler to achieve high availability and scalability.
• For an organization, where a lot of legacy systems coexist, one of the important benefits
ESB offers is incremental adoption. The only systems which are integration ready can be
moved on ESB independently.

THE DISADVANTAGES OF USING AN ESB

• Increased overhead
• Slower communication speed, especially for services which are already compatible

WHEN TO USE AND WHEN NOT TO USE?

It is a fairly common problem with the enterprise application space that the technology is not
chosen for valid reasons and with adequate logical data points. And, mostly the technology
gets blamed if the project struggles. It happens with big hotel chains as well because criteria
and complexity of the problem is often not understood until later in the development
process.

05
 If the number of applications that need to talk to each other are less than three, point-to-
point integration can be a better choice, otherwise, an ESB can be a good candidate. If HTTP,
REST, SOAP, or JMS is the only protocol involved in communication, an ESB can be an overkill.
Simpler options must be sought. If systems in question operate on multiple protocols, an ESB
is a good option. The future integration need to be carefully checked. Future proof or YNNI
(You’ll Never Need It) approaches need to be avoided. Re-architecting can be simpler than
opting for an ESB sighting too many future requirements.

CONCLUSION

Hotel chains use distinct packaged software, legacy systems, and heterogeneous
environments to accomplish technology needs for running a business. Such systems are
routinely connected by point-to-point integrations. For a small number of systems, such
integration may work. When more than three systems need to be integrated on multiple
protocols, a better integration methodology needs to be followed. Among other EAI
techniques such as hub-and-spoke model, ESB scores more for various reasons. An optimal
implementation of an ESB can result into scalable, flexible architecture. In hotel industry,
ever-evolving multi-channel UI technologies need to work alongside of many legacy backend
systems. In such cases, an ESB as an integration platform can be an ideal fit.

Cybage Software Pvt. Ltd.

[An SEI-CMMI Level 5 & ISO 27001 Company]

HQ: Cybage Towers, Survey No 13A/ 1+2+3/1, Vadgaon Sheri, Pune 411014 |
Tel: 91 20 6604 4700 | Fax: 91 20 6604 1701
Pune | Hyderabad | Gandhinagar | Seattle | New Jersey | San Francisco |
Atlanta | Austin | London | Frankfurt | Amsterdam | Sydney
www.cybage.com

© 2014. Cybage Software Ltd. All rights reserved. 06