Loosen Up!

Service-oriented architecture holds great promise for reducing the cost and complexity of integrating business systems. But without an enterprise service bus, SOAs may not stretch to meet scalability requirements and could hamper IT with the kind of coding and confusion that plagued early point-to-point Web services implementations. ESB also is critical to how SOAs support business process management and the whole chain of strategic objectives that endeavor to make business change less difficult

Java Messaging Service (JMS), part of the J2EE specification, is the essential standard applied by EAI, messaging and application server providers. However, vendors such as Cape Clear Software and Microsoft counter that the standard does not protect organizations from proprietary software shackles that some believe will be an impediment to reaching the fully distributed, loosely coupled SOA vision. Cape Clear and iWay Software are examples of vendors that do not have their own messaging component, viewing that layer as either commodity or part of its customers' existing infrastructure. Cape Clear, iWay, Software AG and even the ESB providers that have their own messaging systems are sensing that their customers' attention is more focused on the potential business value of mediation and XML data transformation above the messaging layer.

Microsoft shops, of course, are most concerned about the world outside of Java. Microsoft does not as yet market an ESB product; instead, it offers BizTalk Server and other elements of the Windows platform for messaging and related functions. Microsoft is a major backer of OASIS Web Services (WS) standards, which could supplant (or at least counterbalance) JMS for critical messaging duties. The biggest task is ensuring reliability so systems can detect, recover from and ultimately avoid failures, without compromising the SOA's loosely coupled, plug-and-play objectives. WS-Reliable Messaging and WS-Reliability build on the SOAP processing model to give asynchronous SOA the same level of transaction quality as synchronous, RPC-style computing.

Reliability is also a key issue in how ESBs manage transaction state in SOAs. ESB vendors use routing and concepts such as itineraries or circuits to pass state from one node to the next. XML lets messages carry a great deal of information as metadata, which describes the endpoints that must receive the messages. Through smart routing and state passing, the system can begin to manage itself through reusable integration patterns. These techniques also let humans or process management systems make changes in midstream if necessary. Metadata-rich messages hold potential as an important integration point for business activity monitoring and BI systems.

Is the growing ESB workload going to turn SOA back into the hub-and-spoke architecture that typified EAI? This might please conventional EAI vendors, who are "having a hard time with SOA," says Ronald Schmelzer, senior analyst with ZapThink, an IT advisory and analysis firm. "They are afraid customers will say, 'Wait a minute, if I take my services and interfaces and just do SOA composition, I might not need this expensive integration middleware.'" Schmelzer doesn't see EAI as a good starting point for ESB. Because EAI is focused around a hub, he feels it's contrary to SOA's goal of decentralized services. "EAI systems pour concrete on business processes, since they tend to solidify existing processes rather than enable an IT environment that allows companies to deal easily with change," he says.

Not all analysts share Schmelzer's view. "The weaknesses of hub and spoke are no longer a big deal," says Ken Vollmer, principal analyst with Forrester Research. "Even the 'single point of failure' criticism is not true anymore, because integrated middleware platforms are clustered and the products take advantage of all kinds of backup and recovery." Forrester's November 2005 ESB report gave high ratings to EAI players that have ESB as part of their comprehensive suites.

Processes and Business Integration

BPEL, which is defined in WSDL (and thus, XML), has become the primary connection between business process management (BPM) and SOA. However, BPEL is likely only the beginning of a growing synergy. As they grow in number and sequence complexity, Web services need the orchestration that process management can provide. Messages and services, which must organize and mediate their interaction, have a lot in common with business processes. And as organizations use BPM to increase efficiency and reusability, they will execute processes and monitor performance through SOA.

Business processes are "acts of communication," according to Robin Milner's pi-calculus theory, which is foundational to BPM. Process engines are good at taking business rules and determining who or what does which activities and tasks to accomplish the process objective. SOA easily becomes the standards-based integration platform that BPM needs.

BPEL's popularity is spurring the Java community to step up its move from code and objects to process development. The Java standards community now has Java Specification Request (JSR) 208 for Java Business Integration (JBI), which is slated to become for services what J2EE has been for applications. JBI also will provide an easier way for existing J2EE systems to expose components as services. Finally, JBI helps BPM by opening up the SOA "pluggable platform" to more than just BPEL.

Gartner defines ESB as a platform that "combines features from several previous types of middleware into one package," including "message validation, transformation, content-based routing, security, services discovery for SOA, load balancing, failover and logging." Functioning as the linchpin of SOA, organizations hope that a heavyweight ESB can lift integration and mediation up to a higher, more strategic level, where the language of communication is business models, rules and processes, not arcane IT concepts like objects.

With SOA, ESB and BPM in sync, when the organization needs to move and change, IT can move and change. Custom development will never entirely go away, but it can focus more on uniquely competitive enhancements and less on routine integration. And contortion? Hopefully, it will go back to being a circus act.