United has long invested in its EDA, using IBM’s WebSphere as its messaging bus for seven years. In the past year, it’s begun an SOA effort to handle the modern Web services used at its United.com Web site. But those two environments are fairly distinct, Cidambi notes, so they could exist in parallel. However, that’s beginning to change, as the company begins adding transaction services within its internal operations, such as notifying customer service reps by text message (using Web services) what their schedules are for the day, using the HR system to see who’s scheduled, who’s called in sick, and so on to assign individuals to various gates at each airport. That puts Web services into the same environment as event-driven processes, Cidambi says, causing the airline to begin an SOA effort beyond the United.com program.
United’s challenge is figuring out how to architect and deploy services in a business that has, and needs, two architectures. Although the airline’s internal operations have two architectures, it cannot treat them as completely separate. After all, a cancelled flight (an event) also has implications for transaction systems (such as rescheduling passenger flights, updating Web-based flight-status lookup tools, or issuing credit vouchers). Many processes have both an event and a transaction component: while customer service reps get their schedules for the day from the transaction system, changes in plane status due to cancellations, weather delays, and so on quickly render that schedule moot. The event-driven system tracks the plane status, and the scheduling transaction system then updates the staff’s assignments by polling that status periodically. (The flight display monitors use the same process.)
The biggest challenge has been figuring out the messaging system. “ESBs don’t use standards outside of Web services standards,” Cidambi notes, so how to deal with event-driven services is unclear and inconsistent from product to product and tool to tool. Yet Cidambi is drawn to using ESBs for both SOA and EDA purposes because they handle messaging, data transformations, and other critical data routing tasks well.
Today, United Airlines has two ESBs: one for EDA services and one for SOA services. It uses an IBM WebSphere integration broker as a publish-and-subscribe-oriented messaging platform for its event-driven services, propagating events as needed and handling any transformations among services – essentially acting as an EDA ESB. For the transport, its existing J2EE applications are very messaging-oriented, so all use JMS (Java Message Service) as the messaging standard rather than Web services.
United is adopting the BEA AquaLogic ESB for its SOA services, because it is a newer platform that Cidambi expects will be more oriented to the newer SOA concept, and a better fit with the WebLogic server environment and Eclipse development environment in use at United. “AquaLogic basically runs on top of WebLogic,” Cidambi says, so there’s no integration effort.
Avoiding unnecessary effort is also why Cidambi isn’t moving the EDA services to AquaLogic; WebSphere does the job quite well, he notes, and moving to a new ESB would inevitably cause disruptions and surprises: United has had seven years to optimize its WebSphere platform and work out operational kinks; moving to a new ESB such as AquaLogic would take effort now and undoubtedly expose new kinks.
Another issue Cidambi faces is the lack of standard XML schemas for EDA, making the messaging effort between EDA and SOA services more complex and labor intensive.