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 that 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, 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.