WebServices dot org

Enterprise services buses (ESBs) are enterprises’ greatest hope for overcoming, rationalizing, and turning point-to-point Web services, or spaghetti architectures, into bona fide service-oriented architectures, Paul Patrick pointed out in a recent discussion with Webservices.Org editors. First, the industry has been pitching the concept of a componentized architecture for well over a decade, and never quite got it right. “As an old CORBA, DCOM and COM person, I look at SOA and think, ‘What’s different here?’” he asked. “To get some of the abstractions, and agility, we have to think about the problem differently than we have in the past.”

Namely, enterprises need to have some type of intermediary middleware to manage changes that may move up and down the network stack. “I’ve seen a lot of companies go out and just grab Web services as a WSDL and do a point-to-point connection; then they make a change to the service, and it’s all busted,” he said. “I don’t think people have fully understood the power of intermediaries like service buses, and how they can create nice evolution points in an enterprise.”

Of course, ESBs tend to be defined – and misunderstood – in many ways. Some industry watchers, for example, consider the ESB to be another piece of proprietary middleware that often doesn’t fit into a best-of-breed architecture. “Right now, we need to develop a good crisp definition of enterprise service bus,” Patrick observed. “Depending on whom you’re talking to, ESBs could be messaging systems; they could be everything and anything. I even saw someone talking about having adapters as their ESBs,” he said. “I also keep seeing a lot of people doing their own home-grown ESBs. Messaging systems have been the classic approach. You hear a lot of people say ‘I put a Web service interface on my messaging system. But I don’t necessarily see the value anymore.’”

The key to long-term success in intermediary middleware such as ESB, Patrick said, is the ability to integrate with any and all key systems across the enterprise. “An intermediary in the network needs to be transparent, and needs to be interoperable, or else you are building a spoke-and-hub type scenario,” he explained. “Often, there are proprietary protocols and custom APIs you have to bridge to. One of the architectural questions we face is whether we do that in the bus, or do that in a proxy. That will depend quite heavily on risk mitigation, performance requirements, distribution, and security. We need some best practices to help people understand these tradeoffs, and that’s what’s missing in the industry right now.”

There are alternatives to ESBs, but Patrick said some might represent a step backward for enterprise architectures. For example, emerging standards such as WS-Addressing help virtualize services through a gateway approach, which may reduce the requirement for an ESB. However, Patrick fears reliance on a gateway strategy may move too much processing to the client. “The age-old problem is if we put all knowledge back in the clients – about where things physically are, how to get there, and how to do retries and handle exceptions – then we’re repeating two-tier client/server computing again. I shudder when I think about gateways a little bit, because I picture spoke-and-hub scenarios. The reality is, as time goes by, we won’t have one ESB, but a federation of ESBs from which we build a virtual bus.”

In our next installment of Interview with a Purpose with BEA’s Paul Patrick, Paul will discuss the emerging role of Service Component Architecture.

For detailed Webservices.Org coverage on BEA’s AquaLogic Service Bus offering, click here .

You can read the second installment of this interview here .