Web Services is by far the most ubiquitous technology used for integration purposes. You always come across it in a B2B discussion, with either business or technical stakeholders. In Travel industry, web services account for +40% of total integrations. This technology has a broad history and many branches that make it suitable to meet a broad range of solutions. In this article, we explain the basics on web services technology, detail some of the most common extensions, such as SOAP, and provide interesting Travel industry examples on how this technology is used to solve real challenges.
What is a Web Service?
If you usually deal with computer science and IT people, you might have come across that feeling of “what language are they talking?” HTML, IP stack, SOAP, REST, synchronization, timeout, delayed response, and many other terms that are common to any company dealing with integration needs, such as those intermediating between clients and providers. Essentially, the concepts behind the jergon are not so complex, and in this article we are uncovering the basics of one of the most ubiquitous Internet technologies used for integration purposes, that is Web Service technology.
The web service definition found at W3C (the parents of Internet) is not understandable. The Wikipedia definition doesn’t help much, either. To understand a web service, let’s first understand what is the challenge behind.
There are multiple programs that control the accounting, HR, logistics, web, call center, or any other internal or customer-facing activity. The more complex a company is the more integrations between these information systems that are needed. When the business complexity increases, companies are no longer self-sufficient and rely on other companies to meet their business purpose. For example, tour operators not only showcase their own products but also 3rd party products that are sold with a margin on top of the price. In this case, an integration between the tour operator and 3rd parties information systems is needed, so that both systems “talk” the same language.
Integration was invented just after computing. First computers running complex calculations soon created the need to “consult” and “receive feedback” from other computers and calculations. The first integration system, still very popular, was based on file exchange between computers, called Electronic Data Exchange (EDI). Even the humble File Transport Protocol (FTP) does a good job for integrating data files nowadays. When the Internet became preeminent and electronic commerce started to ramp up, faster integration methods were needed. Technologies like CORBA never gained wide adoption due to its complexity to integrate heterogeneous systems, that is, systems programmed in different languages. Electronic commerce is collaborative in essence, you need integration with several providers to fulfill an order - so web service technology was designed.
This solves the integration challenge, because it decouples the complexity of the different systems that interact in a conversation, abstracting from the computer, operating system, and programming language used in a certain company. In essence, a web service is a contract that clearly states the functionality being provided, the data to be sent in a request, and the data you might expect in the response, together with some additional description on what to do in case of errors, limitations of usage, etc.
The beauty of web service technology is that once the contract is clear between the parties, each party will use its preferred technology to build the computer program used to the actual integration. On one hand you might have a company using IBM AS/400 and RPG language, and the counterpart is using Linux and Java.
Web Service Technologies
Here comes the tricky part. A Web Service is easy from a conceptual point of view. However, there are a bunch of extra technologies used to create the artifacts needed for the web service programs, and also many additional specifications that cope with advanced features on security, data formats, or transactions.
Let’s briefly describe some of the most common terms and technologies to avoid getting lost and perform like a pro in any integration discussion.
HTTP is a network protocol, the same protocol used in Internet for World Wide Web, and by far the most used communication method leveraged in a web service interaction. A web service interaction is usually made up of one request and one response data exchange, but there are more complex interactions.
Extensible Markup Language, aka XML, is an format for exchanging electronic documents in text mode. It is intended to be understood by computer programs, not humans, and contains labels (called tags) that verbosely delimit the document in semantic sections. This example represents a note from a person called Tove to another called Jani.
<body>Don't forget me this weekend!</body>
"body": "Don’t forget me this weekend!",
Simple Access Protocol, aka SOAP, it’s a web services protocol. The web services contract is generic and supports different protocols for actual implementation and communication details, and SOAP is the most common one. It’s based on XML, and the main concept is the SOAP envelope, a digital “envelope” around the real message that wants to be transmitted back and forth. This is an example of a SOAP envelope in XML format that represents a request for a web service aimed at providing the price of a stock.
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:m="http://www.datumize.com/stock/Foo">
Just for the sake of curiosity, Web Services Description Language (WSDL) is the technology used to describe the electronic contract of a web service. It describes the different operations available, and also the surrounding conditions such as security.
A more modern web service protocol is REST (compared to SOAP). It simplifies web services by creating a standard notation for the operations and actions allowed. It’s far easier to use in modern programming and even at the operating system level using basic commands such as wget.
A Service Oriented Architecture (SOA) is a conceptual approach for solving enterprise challenges in information systems. A SOA architecture leverages the concept of service in its core definition to provide better interoperability and lots of other benefits.
An Enterprise Service Bus (ESB) is a software specially designed to contain interoperability services, a key component of a service-oriented architecture. Most of the times, an ESB acts as a proxy for internal and external web services.
Travel Industry Examples
Within Travel industry, the Open Travel Alliance (OTA) is an organization aimed at defining interoperable XML standards to facilitate the integration between parties. The OTA XML format is widely used to represent the semantics of different operations such as product search, product description, availability and price, and bookings.
Typically, a company operating in travel industry provides products and services that consider not only internal offering but also external providers. The OTA format is becoming more popular, but still, there are many cases where proprietary formats are needed to integrate with a party.
Quoting services are especially interesting in travel. In a context of adjusted margins and increased competition, companies need to quote a huge number of products to achieve the right sales figures. Figure 2 represents conceptual sales funnel in the travel industry - in reality, however, conversion rates are below 8%. A quote usually consists of an availability and price for a specific product and comes right after extensive product search and refinement.
Let’s look into a sample service for availability and price. The format is based on OTA standard, and represents a simple hotel lookup for a range of dates (2018-01-19 to 2018-01-23), in a certain hotel (131416), and 2 adults aged 30. The technology used is a SOAP web service over HTTP.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<soapenv:Envelope xmlns:ns0="http://www.opentravel.org/OTA/2003/05" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<ns0:StayDateRange End="2018-01-23" Start="2018-01-19"/>
<ns0:GuestCount Age="30" Count="2"/>
The system responds with a XML document that contains detailed information on availability and price. There is availability for requested criteria, otherwise the response would contain no product, or an error would be raised to indicate the caller that the desired product is not available. For the sake of simplicity, just one rate has been represented, but usually these responses contain a full fledge of rates, each one applies to different room types and policies.
<?xml version="1.0" encoding="UTF-8"?>
<ns:OTA_HotelAvailRS Token="5106759488755527645" xmlns:ns="http://www.opentravel.org/OTA/2003/05">
<ns:RoomDescription Name="Standard Room NON REFUNDABLE"/>
<ns:RatePlan RatePlanCode="NR_SA" RatePlanName="GENERAL">
<ns:MealsIncluded MealPlanCodes="SA-SÓLO ALOJAMIENTO"/>
<ns:RatePlan RatePlanCode="NR_AD" RatePlanName="GENERAL">
<ns:MealsIncluded MealPlanCodes="AD-ALOJAMIENTO Y DESAYUNO"/>
<ns:RoomRate AvailabilityStatus="AvailableForSale" InvBlockCode="1" RatePlanCode="NR_SA" RoomTypeCode="DBLE">
<ns:Total AmountAfterTax="104.55" AmountBeforeTax="88.11" CurrencyCode="EUR">
<ns:Tax Code="AGE" Percent="13.0"/>
<ns:Tax Code="VAT" Percent="21.0"/>
<ns:RoomRateDescription Name="ADDITIONAL#NOREEM#NO REEMBOLSABLE"/>
<ns:GuestCount Age="30" Count="2"/>
<ns:TimeSpan End="2018-01-23+01:00" Start="2018-01-19+01:00"/>
<ns:BasicPropertyInfo HotelCode="131416" HotelName="EXCELSIOR"/>
<ns:CategoryUngroupedCode Code="3 EST"/>
<ns:CategoryName Name="3 *"/>
Integrations based on web services and XML format are the de facto standard in travel industry. All key players provide a B2B API for automating the interaction with clients and providers. Industry standards such as OTA have gained wide adoption and facilitated quite a lot a rich functionality for a number of players. The simple case just depicted has a huge technical complexity because retrieving an immediate availability and price needs to be completed fast enough and usually encompasses retrieving external data (through a call to another web service) and an internal calculation (to add margins and reformat data).
Datumize knows the challenges in Travel industry. Much of the burdens comes from the fact that the industry is very demanding and competitive, and integration with multiple clients and providers increases the cost and complexity of every new functionality to be offered. Web Service technology plays a significant role in travel because most interoperability between parties leverages services for basic operations such as product searches, product description, quotes, and bookings. Besides this fact, modern companies operate over a wide number of channels, such a mobile, public web, intranet webs for agents, call center, or B2B API. The dispersion and specific features of each channel add complexity to information systems and create information silos.
For every web service call, Datumize is able to capture the full request and the full response, and transform the data into structured information, in real time. In order to avoid additional cost to companies, Datumize does not need to modify the applications or change any infrastructure.
When it comes to web services in travel, most clients record (at most) a minimal part of the exchanged data - for example, you will be storing lot of data about the booking (for obvious reasons), but it’s very likely that you only know the number of calls per day for the availability and pricing service. However, if you could analyze the gap between the real destinations being requested and your responses in terms of availability and price, you could understand if some product is missing in your portfolio, or if a price in your system is not well configured because a product is not converting enough. This kind of insights can only be achieved in companies that are able to capture and consolidate the right data across systems.
Some additional references you might be interested: