Your next crucial technology choice: how messages will be sent or received among services and applications. With small-scale SOA implementations, you can often get away with direct, synchronous XML (most often, SOAP) connections that essentially assume services will be available 24/7. As deployments grow larger and more complex, however, asynchronous, reliable messaging may be required -- and because different messaging schemes support this in different ways, the danger of lock-in increases.
ESBs (enterprise service buses), EAI middleware from such stalwarts as Tibco or webMethods, and application servers from BEA, IBM, and Oracle enhanced with integration add-ons all provide asynchronous, reliable messaging functionality. All support a range of messaging protocols, including SOAP, JMS (Java Message Service), and MQ (Message Queuing), and offer application adaptors for legacy systems. Today, however, each solution has its own way of ensuring the arrival of messages, a situation that is unlikely to change even with broad adoption of standards such as WS-ReliableMessaging.
ESBs occupy a particularly confusing area. As Ben Moreland of The Hartford says, "if you get 10 architects together, you're going to get probably 11 different definitions of an ESB. Some are going to say that it's an architecture pattern; others are going to say it's a single product. Others are going to say it's a suite of products." Even among ESB products, the InfoWorld Test Center encountered surprising diversity.
Most people have a natural tendency to stick with what they’ve got. Bob Laird at MCI provides a case in point. “We wound up using WebSphere because we already had IBM MQ installed,” he says. “It just made the most sense. Plus, it allows our developers to be eased into SOA concepts through tools with which they’re already familiar.”
Lockheed’s Vibbert says he encounters this tendency all the time. Although he likes the lightweight, standards-based messaging solution offered by the JMS-based Sonic ESB, he doesn’t try to convince clients to switch if they already have a deep relationship with another vendor providing similar functionality.
But some folks, especially smaller shops, take a dimmer view of the single-vendor default. “To us, flexibility is everything,” says Paul Lindo, a 13-year veteran of development at the Federal Reserve and now CIO of a small New York-based development company. “What you get with a messaging system like MQ is a rehash of older proprietary technology with a new SOA spin. For us, sticking to straight Web services standards makes much more sense.”
MCI’s Laird concedes that relying on IBM may limit his choices in the long term, but he is willing to make that trade in order to start with SOA today, enjoy a low initial platform cost, and grow his SOA as IBM’s product set evolves. “And please don’t think we’re closing our eyes to ragged-edge tools,” he says. Laird indicates that MCI actually encourages its developers to try non-IBM tools as they emerge. Those that become popular are purchased in small quantities first and are integrated into specific projects. If they pass that test, they’re rolled out in larger numbers. “This way, we keep our options open while avoiding large-scale compatibility headaches,” he says.
“Most companies that have a message-oriented middleware system in place are more likely than not to leverage what they already have because it makes little sense not to use the robust messaging topologies that many of these companies have in place,” Flashine’s Stack says. “So unless you don’t have one of those, it seems to me that the MOM [message-oriented middleware] solutions are going to be the reliable messaging service -- and most have announced their intent to support the reliable messaging protocols.”
A technology exec at a major financial conglomerate offers corroboration of this perspective. His company’s asynchronous messaging solution is a well-established EAI product, which among other benefits provides the binary throughput necessary for high-volume transactions. When asked his opinion on ESBs, he replies with a question: “Why should I go for a lightweight JMS solution when I already have a heavy-duty one?”