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.

Thomson Financial automates service compliance

Many companies like the SOA concept because it promises faster development times. But some SOA developers have discovered that a key part of service governance can actually slow down development, stealing that promised speed. Financial publisher and information services firm Thomson Financial discovered this unpleasant surprise early in its SOA journey, recalls Vladimir Mitevski, vice president of product management core services.

"To call it an enterprise production asset, a service needs to comply with several methodologies and policies," Mitevski notes. Many are very exacting: The names of XML elements can't be abbreviations and must be real dictionary words, for example, and some items, such as user names and passwords, cannot be hard-coded. When you have just a few services, the enterprise architecture team can usually keep up and also catch any issues, he says. But soon enough, the reviewers become a bottleneck and even begin missing problems due to the workload.

Thomas Financial has thousands of services -- fine-grained, coarse-grained, and everything in between -- and a small architecture staff, so it quickly felt the pain. "No matter what the granularity, each service goes through this process," Mitevski says. Only then is it entered in the service registry. Likewise, changed services need to be evaluated for compliance before the new version is registered and thus available for production use. "But the architecture office was a bottleneck due to the scale," Mitevski says.

Reducing the compliance requirements was not an option, given the critical nature of the applications involved, such as single sign-on services, Web services that deliver financial markets information to analysts and traders, and Web-based financial analysis and charting services accessed through Microsoft Office.

Thomson's solution to the compliance workload issue was to turn to automation, using policy evaluation tools from WebLayers. "The tools are more efficient and don't miss violations," Mitevski says. It did take some time to create the policies that the tools gauge compliance against, and it's critical that architects review the tools' analyses to see if certain issues arise repeatedly that might indicate lack of understanding of key policies by developers or ambiguity in the architecture, he notes. "It helps show us what to do better, and some policies do need to be adjusted" Mitevski says, though he has found that most violations are due to developers taking shortcuts. Architects also decide when developers are granted exceptions for any compliance violations, something that happens only rarely, he notes,and the exceptions are noted in the registry for other users to be made aware of.