How does a technology-driven company with massive performance and scalability requirements -- and incredibly varied customer and supplier bases -- transition to SOA? For Sabre Holdings, the answer was a lot of in-house development and a complex interweaving of the old and new.
Sabre's three companies include the Travelocity online travel service; the Sabre Travel Network, whose GDS (Global Distribution System) connects travel agents and suppliers with travelers; and Sabre Airline Solutions, which supplies reservations and other services to major airlines.
Sabre launched its SOA initiative in 2002, largely in response to requests from its larger customers. "We were pushing Web services to lower our costs, but [customers] were major drivers on what functions would be first on the list and how we'd work out security and business issues," says Todd Richmond, Sabre's vice president of strategic architecture.
Some of those customers became beta testers, migrating from Sabre's desktop products or their own screen-scraping desktop applications to products that could consume Web services. Meanwhile, Sabre started analyzing its customer usage metrics.
"We have a lot of data that helped us determine what might be interesting as a Web service. Then, we'd go out and validate our ideas in customer meetings and take their feedback," Richmond says.
As it turns out, Sabre's customers were divided into major camps. "Some said, 'Just expose each individual host command as a Web service, and I'll build the apps to aggregate them.' Others said, 'I don't want to know about the host and the back end. Just show me the flights, select the flight, price it, sell it, and ticket it in high-level Web services,' " Richmond explains.
So Sabre had to build both capabilities. According to Richmond, the company's first release had 30 or 40 Web services at the low level and another 30 or 40 at the high level. "Now all those who asked for the low level are losing interest as they see what the high level can do," he says.
The architecture is complex. Richmond's team defined very terse XML descriptions that are passed to services over an IBM MQSeries message queue or within a CORBA message. Sitting on top of the system are a set of services that manage session, state, and transaction flow as data moves from Sabre's IBM TPF (Transaction Processing Facility) mainframes to open systems and then back out to the customer.
So far, Sabre has done most of its back-end integration in-house, although it is looking to transition to tools from SeeBeyond -- now a division of Sun Microsystems. Sabre engineers have also developed an aggregator that takes an incoming request, parcels it out to the appropriate servers and applications, and uses a rules engine to tailor a response based on the particular customer's contractual agreement.
Many customers receive messages from Sabre as standard XML based on the Open Travel Alliance (OTA) standard. Others still connect over the same private links they used in the past, including teletype, X.25 connections, and an old UN/EDIFACT (United Nations Electronic Data Interchange for Administration, Commerce, and Transport) standard. This mix of new technologies and legacy systems has proved challenging in many ways.
"We sent our TPF and assembly language programmers to C++ school because we thought that object-oriented methodologies wouldn't be difficult for people so experienced in the application," Richmond says. "The result is that we made some of the common errors that novice object-oriented programmers make and did some other stupid things. Now, we've had to go back over it all and do a better job."
Richmond says Sabre also learned over time that someone has to have an end-to-end view of transactions in order to ensure that infrastructure and application developers will work together to troubleshoot customer problems. Still, many challenges still lie ahead in Sabre's ongoing SOA efforts.
"We have substantial transactions through our Web services gateway," Richmond says. "Do we push all the way off TPF or continue investing in TPF for the parts that run effectively there? What we do with SOA is very much tied to that decision. We also have a lot of mom-and-pop travel agencies that are not necessarily interested in Web services and airlines with international locations [that are] still using 386 systems over 2400-baud lines. Our strategic vision is there, but the rate at which we get there is in flux based on these business realities."