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?
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
