LibGo Travel, one of the largest privately held travel companies in the U.S., provides vacation packages through its retail stores and wholesale distribution channels to consumers, partners, travel agents, and stores. The company wanted to expand its offerings by adding dynamic, branded, and personalized packages. To help execute this idea, LibGo had to bring together our travel partners, including airlines, hotels, and travel aggregators, as well as LibGo Travel's existing heterogeneous systems environment. As a result, LibGo's Next-Generation Travel System (NGTS) is among the most sophisticated booking systems that are currently being implemented. Instead of building one-off interfaces for each partner - a time-consuming, expensive, and brittle solution -- LibGo adopted a modern SOA with shared business services and Web services: data interchange would be XML-based, and WSDL would be the single interface definition standard.

This report from the trenches focuses on our experience of architecting NGTS as a large-scale composite application that is able to deliver more than a million transactions per day. In the process we mastered performance, transactional semantics, and the security challenges that are unique to an SOA environment, which is the focus of this article. The software architecture is shown in Figure 1.

Tracing a Customer Order
The heart of LibGo's booking system, which sits behind the portal, is NGTS, a J2EE-based composite application that ties together a plethora of local back-end systems and remote partner systems, all based on different technologies but accessed through service interfaces. A single sign-on framework integrated into the booking portal provides agents' security and enables the logging of the agents' activities. Each time a customer quote is generated by the agent, NGTS creates a lead in the Oracle E-Business Suite sales online application. To generate a personalized vacation package for a customer, the agent works through each component of the vacation package, such as airline, hotel, and car. A J2EE-based packaging and promotion engine (based on a rules engine) within NGTS gathers the appropriate schedule and pricing information from partners and internal systems, applies appropriate discounts, and delivers the information to the agent through the portal. When the sale is made, the booking is published to the ESB infrastructure where it's propagated to the CRM, Financials, and Project Accounting modules. The process is shown in Figure 2.

Airlines, hotels, and other partners may change customers' travel schedules. To handle this scenario, LibGo created a callback service within NGTS that the partner systems call via Web services. NGTS processes this information and publishes it to the ESB so it can be matched against a customer booking, thus triggering notification - either by e-mail or by agents calling customers.

Now, the reality-check: not all vendors use HTTP-based communication to send information to LibGo. Pricing and availability information can come in multiple formats from FTP, flat files, message queues, e-mails, and fax. Also, each of our internal and external systems has a slightly different data representation, even for the same entities. In keeping with LibGo's design principles, a service adapter layer encapsulates capabilities that are implemented in both internal and external partner systems, and abstracts the business logic for access through an XML-based interface defined in WSDL. The enterprise service bus (ESB) infrastructure facilitates communications and provides services such as data transformation and enrichment. NGTS also provides key foundational services on its own, such as common security services, utility services such as fax and e-mail, a shopping cart-like service, and an elaborate rules engine. All front-end systems (including the .NET-based Web presence) use the common services and business logic provided through NGTS and the ESB infrastructure.

The rules engine is a truly foundational service used to do all manner of things ranging from implementing the decision logic for alerting (call a customer immediately in case of a same-day flight change), to implementing the result caching policies (refreshes price information for air travel on some routes more often than others), to enabling dynamic pricing and packaging of travel services (mid-week travel and minimum night stays).

Now let's discuss LibGo's experiences with caching, transactions, and security.

Caching Is a Necessity for Real-Time Distributed SOAs
Four key factors drove us to consider implementing caching within the SOA:

1. Each time a customer searches for a flight or holiday package, tens of concurrent queries are fired across LibGo's internal systems and across the Internet to partners, which produces result sets that can regularly be larger than 1MB.
2. There are transaction fees involved in performing searches across air and hotel partner systems, whether or not the itinerary is purchased.
3. To meet immediate business needs and future plans, performance must withstand at least 50 interactions per second or 1 million per day, and response times must not exceed 10 seconds.
4. LibGo's system must take orders when back-end systems or partner systems are momentarily unavailable and must process them later.

Web-only travel vendors must cache heavily to avoid partner fees that are levied each time a search is carried out. Often enough, such "over-caching" results in bad data being served, and customers end up being disappointed when offers turn out to be unavailable, or at least not at the promised price, when they press the Buy button. For LibGo, the bottom line was that we needed capabilities to define sophisticated and configurable caching rules to deal with price volatility. For example, prices on flights to Hawaii are less volatile than those on Las Vegas flights. Therefore, it might make sense to not cache flights to a particular Las Vegas flight. Cache invalidation rules based on destination location and heuristics helped LibGo optimize the caching strategy. Figure 3 shows the type of data that is cached.

Caching at the UI level. This applies to HTML pages and fragments. Using Oracle Application Server's WebCache, information items such as destination, airline, and hotel information can be easily cached. Since the WebCache capability is closely integrated with Oracle Portal, it can cache output from both .NET-based Web systems and the J2EE system that supports live agents. We used events to manage this content cache; for example, triggers on changes within the content management system invalidate the cache in WebCache and force updates. This avoids serving up bad data.

Caching of reference data within the composite application (NGTS). This applies to reference data such as state, country, and destination names or different types of attributes that make up 50MB of data located in different data stores that is sourced from remote systems. Using the Java Object Cache in Oracle Application Server's J2EE container, LibGo cached this data at the mid-tier and avoided the overhead of remote system calls.

Caching of transactional data within the composite application (NGTS). This applies to the most perishable information, such as pricing information that relates to airline tickets and hotels. Each time a search is performed for a travel itinerary, the composite application draws upon the data cached in the Java Object Cache. If pricing information isn't available for part of the itinerary that is directly out of the cache, NGTS pulls the information in from the partner system. The result set is then stored in the cache for subsequent queries for both the same customer (in case the customer decides to change the hotel but keep the air ticket), as well as for other customers.