| QUESTION & ANSWER |
BEA CTO Rob Levy on what's ahead for SOA |
 |
By Rich Seeley, News Writer
22 Sep 2006 | SearchWebServices.com |
|
|
Rob Levy, executive vice president and CTO of BEA Systems Inc. took time out of his busy schedule at this week's BEA World conference in San Francisco this week to talk with SearchWebServices about future development in SOA. In part two of the interview he talks about the growing roles for open source, the maturing of the enterprise service bus (ESB) and the importance of governance.Read part one.
Where do you see BPM fitting in with SOA?
Levy:
I don't want to be facetious but [BEA's new SOA 360 initiative] answers that question, too. SOA 360 is all about the business process. If you think about it, in the future an application would not be an application the way we see it today. It will be the usage of business process and policy rules against the container of available services.
So would you say BPM is becoming built into the overall service oriented approach?
Levy: Absolutely. BPM is about workflow, modeling, and execution. From the modeling side it's how you define what needs to happen and what the logic of it is. It will then create processes and has an execution engine that makes those things happen. I believe in the next generation of SOA applications two things are going to control everything: BPM and metadata. You know what the metadata means and you have ways to control your business process management. You now have the way to make business applications happen.
BEA's made no secret of its "blended strategy." What open source initiatives in the SOA/Web services arena would you like to see take off in the next year so that you do more blending with them?
Levy: Obviously what we've done so far in terms of blended, which is things like allowing certain containers to run on WebLogic. We're supporting Spring and Beehive and those things. Those are activities that are coming from the developer side of things and are continuing. What we're looking at is we're making mSA an open approach. We're making the concepts, the principles and the APIs of mSA available to everybody. Blending is a natural reaction of mSA. SOA is built on the premise of tightly-integrated, loosely-coupled components. Those components could come from us, could come from third party vendors, could come from the open source community. They should come from whoever produces the best component for the specific customer need at the time that they need it. So blending now takes not just the approach that we work with open source tools, or we certify against open source tools, which is what we've done so far. This is really being inclusive of the developer community regardless of whether it's inside our organization, inside our competitors or cooperators organizations, or whether it's coming from the open source community. If we all comply with the same basic set of rules and regulations and standards, we should all interoperate.
What sort of future do you see for the ESB? Commoditized service bus or something far more robust? If the latter please describe what that greater robustness entails.
Levy: I don't think the ESB is commoditized because there are a lot of people who still need a transport layer, translation and transformation, which is what ESB does. I think ESB will grow retaining probably its title, meaning service bus, but growing just like communication channels were SNA and then grew to be transport layers and then grew to be middleware and then grew to ESB. ESB will grow, become more federated, more cooperative, more inclusive. You'll see multiple ESBs talking to each other regardless of whether they're from the same company or not. You're going to start seeing things like semantics get involved, so multiple ESBs can negotiate between them and [determine] "what does this really mean?" I believe ESB is part of the fabric.
Give us your definition of SOA governance and describe what tools will be needed to achieve it? Also where does management/monitoring software fit in and does BEA need to start think about adding that to the AquaLogic stack?
Levy: We see SOA governance as the ability to understand why you're doing it and who is allowed to do what, and then adding traceability and management view into the SOA stack. It's about how it's done, why it's done, who did it and where did it happen, more than what it is that did happen. So the first thing you need for governance is the ability to put all the artifacts somewhere so you can actually see them in a cohesive manner. That's where AquaLogic enterprise repository came from Flashline. You need to physically put all those artifacts in that place and make some sense of it. So you're going to see all of our products -- AquaLogic and WebLogic and Tuxedo -- putting their artifacts in that centralized repository. Once you have information in the repository, you can really start looking at it in a more holistic way, and say: "Okay why did it change? Who changed it? What does it mean that they did this? Was it done under an agreed upon workflow and policy?"
That's where BPM on top of that and dashboards on top of that will fit in. So you'll see more dashboards coming out of the AquaLogic brand. You'll see more "business intelligence" types of views on top of the central repository andnd you'll see policy definition against that. There's no difference between policy against change management policy and policy against security access. One is an IT policy, the other is a governance policy, but the concept of policy applying to the artifact did not really change. Going back to the fractal view, at the lower level elements require policy to say: "If that app goes down, it goes. It can't go 'I can access it. I can't access it.'" You bring it up one level the same policy says: "Did John approve this before it came into production?" That's no more than a workflow element with an approval process. So we see this as a process on top of process. Actually what we believe is happening is the processes are becoming exposed services on their own. So governing the processes is also governance. You see some of that already in AquaLogic BPM and AquaLogic User Interaction. And because we just added Flashline and the common repository, you'll see a lot more coming out because we now have access to all of these artifacts together.
|
|
|
|
