Talk to Adam Bosworth, BEA Systems'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.
Q: 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.
Q: 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.
Q: Does that function as part of a routing model?
Bosworth: For a router, this is all going to be meta data. Everything that describes what happens in here is meta data. It's going to be meta data that you can dynamically change once the system is up and running because that's how you're going to handle change and control. The simplest and most obvious case is security policy -- you change that all the time without wanting to bring down (your) code. So for a router to do this, you'd have to have very, very formal (agreement) on the description of the meta data for the pipeline, should it work. I don't think that's going to happen fast. There's just this (incredible) complexity here. It's my guess that we're at least five years away from seeing this sort of thing being done.
Q: Is what you call a message broker the same as what others call an active intermediary?
Bosworth: We've been wrestling with (terminology). In either case, this is the next logical step in the evolution of the (Web services) ecosystem. If you look at the Web service management companies, (the) little ones, they have (simple) forms of this.
Q: Is this going to evolve from the startups who wrestle with meta data to make it more flexible?
Bosworth: I don't know if that's how it's going to evolve. It's how it has evolved. But historically, once you get standards, the stacks very quickly adopt those standards. And at that point, that turns out to not be a good startup business. I don't think, to be honest with you, that this is a very good startup business (to be in) because we clearly have this in our sights.
Q: What do you see as the clear role of messaging and BEA's Web services architectural vision?
Bosworth: Even today it's clearly part of our stuff. The Web services stuff we share (in WebLogic) 7.0 uses any messaging system as a transport. And the road (ahead) is very simple -- It's (all about) delivery. So we will let you use MQ, (or use) JMS, (or whatever) company to send and route (messages), to send and receive Web services right now. We do that because there is no reliable delivery model, but also because there are cases (for) scale. You want the kind of technologies that the messaging experts have developed. The dirty secret, though, is you don't need it for most applications. …Messaging, at the end of the day, is about reliable delivery. And as soon as Web services has as part of its standards reliable delivery (asynchrony), you're pretty much done. You've now opened up what has been a closed architecture. Once you've opened it up, the only value to (customers) is that it can deliver better management or better (scalability).
Q: Doesn't Web services have the asynchrony and reliable services now?
Bosworth: Well it does -- we do it. But it's not saying that we can actually get the interoperability we want with other vendors. What we've been working with the WS-I vendors on is getting published the WS-Addressing and WS-Reliable Messaging (specs). WS-Addressing is a standard that's been proposed by a bunch of us, the same thing with WS-Reliable Messaging. When IBM and Microsoft (support) that standard, that gives it a fair amount of critical mass.
Q: BPEL does business processes, but does it do business contracts reliably?
Bosworth: BPEL is a language for describing a business process model. So it says "Oh, I've got a message coming in. Here I'm going to invoke a service, I'm going to wait for a response to come back, I'm then going to go out and make a decision based on that response. Based on that, I might invoke two services, and wait for both their responses to come back and so on." And (it) can describe all that in a nice XML grammar that everyone can understand. Each one of those components can be a Web service. And that's fine. We like that part. The issue is, could you by looking at that description of the language if you were a business partner who is receiving this message and sending back this (response)? If you receive this message (would you know to) send this one back? Could you infer that? Could you figure out what your contract was as a partner, entirely from the description of this language plus the WSDL? And the answer is maybe yes, maybe no. The idea behind WSCI (Web Services Choreography Interface) was to have a (formal leg) of this practice, separate from the business process. WSDL will tell you that your job, if you get one of these guys, is to send back one of these. And your job, if you get one of these, is to send back one of those. And that's fine. But it won't tell you "Expect to have this to happen before this." WSDL doesn't say that.
Q: So WSCI is for the business contracts?
Bosworth: That was the original intent, that WSCI (would be) used for that purpose.