Talk to Adam Bosworth, BEA's chief architect and senior vice president of advanced development, and he will tell you reliable messaging is at least as important as security when it comes to Web services. To that end, BEA is working on message management and message brokering in an upcoming release of its WebLogic platform. InfoWorld Executive News Editor Mark Jones, Test Center Lead Analyst Jon Udell, and Editor at Large Paul Krill met with Bosworth to discuss BEA's strategy and the company's role in the standards development process.
InfoWorld: Services Oriented Architectures are evolving around monikers such as the Enterprise Service Bus or message broker. Which one will stick?
Bosworth: The message broker is the same thing as what Gartner calls the Enterprise Service Bus. It is a core part of our plans and our architecture. We are in this process of changing what mainstream applications take into account the services-oriented architecture. Key parts of that are building a smart bus and building a smart repository. We're quite far along on that. There's an argument internally what to call this. I don't know what moniker will stick here. Maybe it will be Gartner's service-oriented architecture stuff, and I think it's a good enough name. Whether it's active intermediary, or enterprise service bus, or message broker, I really don't care. But I care everyone understands we're on track to make it a core part of our architecture.
InfoWorld: How distributed do you think message broker will be? Will it become an appliance-level technology that's in routers and big enterprise servers?
Bosworth: There are some places where you want the routers to be involved, [for example] where a local directory doesn't do the job that you want and so [the router] starts to move XML messages to a system. But a message broker's a little more simple [to run]. In comes a message and the first thing we want to do is make sure, is it okay? If not, bounce it. So part of the description [has to do with] do you bounce this thing or not. Access control authorization [has happened], it's already been authorized. Then there's the business of essentially getting straight that the recipient was expecting it, because maybe the person who sent it didn't send it according to the contract, [didn't send a] normalizing message, or whatever your recipient is expecting. Lastly, there are really two different people. One, there is some primary recipient. For example, [with a] purchase order the business processes is going to pick up the purchase order and handle it and do the processing. But there may also be a compliance system and a budgeting system and three other systems that want to know every time one of these messages flows through. That's a subscription model. Right now the world thinks of these as very different, but in the message [broker] protocol they're not going to. They are going to think this is the routing mechanism [to the primary recipient] and also the routing mechanism [to] any other interested parties.
InfoWorld: Does that function as part of a routing model?
Sign up to receive Architecture Resource Alerts
Recommend This
