For example, Ciurana did not want to force developers to all use the same transport. "The transport doesn't matter," he says. He chose to use the open source Mule ESB as a messaging backbone, relying on it to deal with transport interfaces. That way, "developers could focus as little as possible on the implementation of services," he explains. Instead, their focus is on the functionality they are trying to achieve. The result is that developers tend to use HTTP as their transport mechanism, but some use REST (Representational State Transfer) and SOAP -- "whatever works best or they're most comfortable in," he says. With the Mule ESB's approach, "they don't need to worry about what's in a specific SOAP stack or what IDE they're using." Ciurana had previously used Mule at Walmart.com, so he was convinced it was the right basis for Leapfrog's "clean slate" efforts.

Leapfrog could take this approach because its focus is on integrating applications, Ciurana notes. "Most of the integration is happening at the app level, with apps talking to apps. So apps just do inputs and outputs," he says. Developers write services as POJOs (plain old Java objects) and let the Mule ESB "wire" the POJOs to the messaging network, handling any transformation within the ESB. "Normally, when you're working with SOAP and REST, you tend to think about how to connect to the outside world. With POJOs, you don't need to do that," he says.

Ciurana also likes the simplicity of the Mule ESB because it has no agenda other than to manage the messaging. "All the commercial vendors wanted to sell us a whole suite of products. Yet the whole point of SOA is to move from one locked-in system to another," Ciurana adds. With the Mule ESB, Leapfrog has to assemble the various layers of the SOA stack, but Ciurana is happy to pay that price to have the flexibility to use whatever works best at the time.

Leapfrog uses two ESBs, one for managing data flow and application handoffs throughout internal systems such as ERP, ActiveDirectory, and data warehousing, and the other ESB for customer-facing Web-based applications, such as its customer account self-management application and the online games it offers consumers. Not only does this bring in a natural boundary for security and access management, it also provides a mutual backup capability, as each ESB can take over for the other if needed.

Leapfrog did have to create a common service-naming scheme so services could run on either ESB, Ciurana notes. The exacting names "help us keep all the services straight" he adds. It's a small price to pay for ESB freedom.

United Airlines merges SOA with event-driven architecture

As sensible as the SOA concept is -- decomposing business processes into their constituent elements and then developing stand-alone software services that let you mix and match the components as needed for a variety of business demands -- it assumes that you're dealing with discrete transactional functions. The basic SOA premise requires that function be building blocks that can be combined in nearly unlimited ways.

But many business tasks are not so decomposable, instead relying on specific sequences of events. Airlines are a classic example of an event-driven set of processes, and so they typically have an EDA (event-driven architecture) in place to handle events. "EDA is very flow-oriented, while SOA is about discrete black boxes," says Ramnath Cidambi, middleware engineering manager at United Airlines. Both have their place; after all, airlines also have transaction systems such as booking fares and assigning seats, not just event-driven ones such as dispatching fuel trucks when a plane lands or updating the status board for flight arrivals, he notes.

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, etc.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.)