Similarly, Sabre Inc. (www.sabre.com) provides customers access to its Web services by supplying a module that runs on its partners' Web sites. The XML Travel Toolkit module is designed to let partner companies build Websites to allow their customers to book travel. For instance, a brick-and-mortar travel agent would build a Web site, and then, to allow its customers to make last-minute changes to an itinerary, the travel agentwould connect itsWeb site to the Sabre system using the XML Travel Toolkit. "The travel agent can extend loyalty for a customer who might otherwise sneak over to a travel dot-com," said Cheryl Hutchinson, product managerthe XML Travel Toolkit. The reason Sabre chose to distribute software, ratherthan run it all locally at Sabre, is that Sabre communicates with its module using its own lightweight, structured communications language, rather than XML, which requires more bandwidth. [SD Times]via[.netWire] Hmm. So Sabre has services available, which require proprietary software on the client end, use a proprietary transport protocol, and a proprietary data format (the XML mentioned is only used between the client and the proprietary client library). Does this have anything to do with web services? Galileo has had a similar product availablefor several years, called XML Select. This is nothing new! However, Galileo also has "real" webservices,using industry standard protocols and data formats (you know, SOAP and HTTP). They even have hugecustomers (like AAA) using them. Good stuff. [Greg Reinacker] If the intelligence I have is correct, all the GDSes have "Web Services". It's just a matter of how you define it. From what I've heard, it breaks down about like this: - Amadeus has a simple approach to this - basically an HTTP POST of an XML document that returns an XML document. The documents are basically direct translations from Amadeus' structured data into XML (much like XML Select),which means that the messages aren't abstracted very much from the process that the mainframe implements. Note that this is not a REST implementation.
- Sabre - As described, they're using a proprietary protocol, i.e. Sabre Structured Data. I think that the acronym for this was GDS, but not sure what it stood for. My understanding is that this "XML Toolkit" simply wraps an element tag around the data you get from Sabre, so it's XML in that the messages are (presumably) well formed XML documents, but not necessarily well - structured documents.
- Worldspan - has something, but I don't recall what.
- Galileo - Exposes messages to and from the Galileo core systems as XMLoverSOAP. Also offers "higher level" services such as the Booking Service, which packages the entire process of creating a travel reservation into one SOAP message.
Generally, my impression is that Amadeus and Galileo provide the best "WebService" solutions, and Sabre's solution is a terrible hack. The problem with Amadeus' solution, and Galileo's low level solution (i.e. Xml Select) is that there's not enough abstraction from the underlying data stream the mainframe understands; document structure reflects the the structure of the mainframe's data stream. Given that the data streams to the mainframe are smaller, the primary benefit is that the customer doesn't have to write a proprietary parser and the data can be described with DTD, Schema, RELAX-NG,etc. - not bad benefits, but not earthshaking ones either. The problem with Galileo's higher level solutions has been that the request documents are pretty complicated, and the best documentation is the XSD Schema. However,the tools for navigating XSD schemas and creating documents from schema are pretty poor, so we've had to create a great deal of supporting documentation to make these services usable for our customers. The other issue has been the general resistance by our customers to understanding SOAP; we've had to provide proxy stubs for the major toolkits because proxy creation has been a big stumbling block for our customers. I expect that Amadeus hasan easier time with adoption because the HTTP POST interface would be pretty simple, though I don't have direct experience to confirm this. Unfortunately, the travel industry isn't generally driven to make decisions based on sound technical principles. More often, the GDS customers choose solutions based on the financial incentives offered by the GDS. Sabre hasbeen quite successful in winning customers via a combination of good marketing and financial incentives. Disclaimer: regular readers know that I'm employed by Galileo, so everything I've just written should be read with that in mind. |
|
