Interview: BEA CTO details SOA platform

Interview: BEA CTO details SOA platform. Check it out:
(InfoWorld Daily Via Thomson Dialog NewsEdge) BEA Systems at the BEAWorld 2006 San Francisco conference this week stressed SOA as a core technology and unveiled its SOA 360 platform. Comprising multiple BEA products, some of which have yet to be released, the ambitious SOA 360 strategy features multiple role-based offerings for IT as well as a services architecture and modularization of existing BEA products. InfoWorld Editor at Large Paul Krill spoke with Rob Levy, BEA executive vice president and chief technology officer, at the conference about SOA 360 and BEA's growth as a middleware company.



InfoWorld: Would you explain the concepts of SOA 360 WorkSpace 360, WorkSpace Central and microService Architecture?

Levy: Sure. Lets start with the highest level, which is SOA 360. SOA 360 is a governing approach to modeling, creating, developing and deploying a full lifecycle SOA application. It is a unifying methodology between all the product lines we have, as well as connecting it to other products. In that respect, think of it as a governing approach that is supported by a set of products, by a common architecture and by a set of standards that govern the lifecycle. So if you drop [down] from that, either to the bottom or the top, depending on how you want to look at that, on the bottom youre going to need a common architecture that allows you to build those SOA applications across this lifecycle. [This is] mSA, microService Architecture. Think of mSA as using the SOA practices to componentize our platform and our product line. You take the basic services that exist inside each one of our product lines and you componentize them so they can be reused with all of our products, not just in single products.... To do the SOA lifecycle correctly, the common architecture will also have to have a common repository, [a] catalog of services, where basically each one of the roles contributes a different portion of the knowledge and expertise that is necessary to move forward in the SOA lifecycle. Now lets leave that for a second, and again Ill jump back out now this time to the roles. Its a multiple view of the same problem, its all starting from the SOA lifecycle domain. Take WorkSpace 360, and WorkSpace 360 is the tool, or the set of tools, that allow each one of the roles to participate in the SOA lifecycle. The business analysts, the LOB [line of business], have a very specific set of things that they are concerned about. From the application -- from the business process to maybe ROI (return on investment) metrics that they need to measure to the definition of the business requirements. All of these artifacts need to be stored somewhere, and theyll now be stored in the central repository.

InfoWorld: Which is what product?

Levy: Its using the Flashline product we just acquired, what is now called AquaLogic Enterprise Repository. You move forward in this workspace, which is again following the lifecycle, then the next level will be an architect, right? Because you [wrote] the business requirements then you go to the architects. Architects translate business requirements into global architecture. They will have issues like architecture diagrams and flow diagrams, things the developers can use. They would also need access to, again, some sort of a central repository where they can look up to see if some of the services that are being required to build a new application already exist. If they find that they [do not], then we can define the parameters for definition of the new services. All that is done on our side though the AquaLogic product. And as you go into development, developers if they choose to develop in Java, then theyll go into Workspace 360 for Developer, which will be the tooling sets required to physically build products on either WebLogic or on Tuxedo. With Tuxedo also we made an announcement of something called SALT (Services Architecture Leveraging Tuxedo), which basically allows you to take Tuxedo services and expose them as Web services. So youll be either using Tuxedo services or build brand new ones on top of a J2EE platform, WebLogic. Those would have the specific parameters, again, that define [where] they are. So now youre talking policy artifacts (etc.). Those will again be put in the central repository. When youre going to the deployment cycle, when people start worrying about things like SLAs, the network definition underneath, which services to deploy on, what provisioning parameters are necessary, levels of operating systems. Thats where the Workspace 360 for IT will come in. And people will do two things. One, theyll control the deployment cycle, moving it from test to production. And the other one, once its in production, will control the manageability, so finding things like -- is it up, it is running, whats the response time? Whats the availability? Is it meeting the SLAs that were defined originally by the business users? And thats how you create a closed-loop lifecycle. [We have] a set of tools that allow each one of the roles to participate. SOA 360 is an approach that governs how you do it. And underneath is an architecture of product components, mSA, that allows you to build those products from scratch. Each one of the customers will compose their own pieces of mSA that they need to provide a complete solution.

InfoWorld: Weve covered WorkSpace 360. WorkSpace Central, have we covered that one yet?

Levy: Workspace is the role-based set of tooling. SOA 360 is the governing approach. MSA is the underlying architecture. And those three together are all in support of the SOA lifecycle.

InfoWorld: So with WorkSpace 360 and the WorkSpace Central, whats the difference?

Levy: WorkSpace Central is central to WorkSpace 360. All of the four components of WorkSpace, for business analysts, for architects, for developer, for IT, will all store and read the artifacts from the same WorkSpace Central. Its kind of the hub.

InfoWorld: Does BEA really think this simplifies things? It seems pretty complex.

Levy: Im not sure I agree. Again, I think the issue we always faced in the lifecycle is that each one of the pieces was done, but done in a separate manner. Business people dealt with business issues with one set of tools, and architects dealt with another set of tools, and developers dealt with another. We believe that in order to make SOA simple, we have to put all of them in that cycle, and what connects that cycle is WorkSpace. You sort of think of reusability as the work before you.

InfoWorld: Where does WSRP [Web Services for Remote Portlets] enter into this? It was mentioned in passing like we all would have already known that. There just seems like too many elements here to grasp.

Levy: WSRP is just a standard. [It is] one of the standards that govern the behavior of SOA. I dont believe people need to know the standard, they just need to know that the products that theyre combining are all maintaining the same standard. Think of cars. Theres only two standards [for] cars -- metric and inch If you need tooling for cars, you can buy tools for cars. The only thing you need to know is whether the car is following a metric system or inch system? Everything else is provided. Our goal is to do the exact same thing. [We] provide you with a set of tools that supports those standards without you needing to actually think through which standards does which and which standard does what. So in that respect we greatly simplify SOA implementation, because all you really need to know from a user perspective -- this is now not from my side, the architecture that comes from underneath -- but how a user sees it. All the user needs to know is based on the role in the cycle - which tool they need to use. And the interface, by the way, all of them would be identical in behavior, different in function, because obviously theyre different functions. So as you move in the cycle, all you have to worry about is picking up, logging into your tool You shouldnt care about the fact that theres something called a repository or WorkSpace Central. Its just there so you wouldnt have to repeatedly ask for information from before.

InfoWorld: I understand there is going to be a modularization of some of the products that are out there now, like WebLogic Server?

Levy: Correct.

InfoWorld: How does that play into this?

Levy: Think about the deployment today of SOA on top of WebLogic. You get the full container regardless if you need all the functions of the container or not. [With modularization, you] only pick the pieces that are really necessary for the solution that we provided.

InfoWorld: Can you give an example of how somebody might pick a module of the app server as opposed to the whole product?

Levy: Well, sure. A lot of the products, the ESB (enterprise service bus), require some of the Java container services but dos not require a full JVM (Java Virtual Machine).... If youre really building full-scale applications on Java, you need [the] full WebLogic Server. But if you only need the Java container, but not the JVM thats run underneath that, then why not just take that and package that with the ESB?

InfoWorld: So when will that happen?

Levy: Its happening now.

InfoWorld: Can you give an example?

Levy: Sure. I mean tomorrow Mark [Carges, executive vice president of the BEA Business Interaction Division] is going to basically show a WebLogic server and this. Its a slimmed-down version of the execution engine.

InfoWorld: What are you going to do with that?

Levy: You can execute Java without having the development environment or the creation environment, [where] the full WebLogic server is. That is exactly what the AquaLogic product set is going to be [using].

InfoWorld: Whats the benefit of doing that?

Levy: Simplicity of installations, simplicity of administration, and of course, it allows us to spend less time trying to create a [big] environment and be more agile in our response to the marketplace. So its good for us and its good for our customers.

InfoWorld: BEAs still about $1 billion in revenue a year, correct?

Levy: $1.2 billion.

InfoWorld: It doesnt seem like BEAs been able to grow that in the past couple years. What is it going to do to finally get off the mark there at $1 billion, or maybe it has gone up a little bit?

Levy: We grow both organically and through expansion. If you look at what weve done in the last year and a half, weve expanded the reach of Java to areas where traditionally before we were not. One area, in addition to the RFID field, [is] to the communication field, so people that are developing either RFID applications or communication applications to serve in VOIP, are now developing under the same Java container that we supported before. We created WebLogic Real Time, which [extended the] standard Java reach into places where Java didnt exist before, so where traditionally people used C/C++ for real-time applications, now they can use Java. So thats another growth factor. And obviously, the whole AquaLogic product line, and the now SOA 360. We believe that SOA is going to create a large wave that obviously allows significant growth.

InfoWorld: Where BEA headed? Obviously, SOA is the big push for you.

Levy: SOA is a huge push for us, as well as completely we agree with the statements made by Shaygan [Kheradpir, CIO of Verizon] this morning. I think what were going to see Web 2.0 fully in the enterprise and SOA pushing out into the consumer. And when that happens its going to be just like in the beginning age of the Internet, when in order to make Internet successful, you really needed the technology and the infrastructure for this new world of sort of consumer-based development. Youre going to need an infrastructure that will allow you to push out the execution or the composition of the applications into this peer-to-peer world. And thats where were going.

InfoWorld: Why do see SOA in the consumer world?

Levy: You look at SOA-based applications, theyre about composition. People are looking to be able to compose the application at runtime, not at design time. So what did [Kheradpir] call it? At the speed of need That would require a new type of infrastructure.

Related ArticlesInterview: BEA CTO details SOA platform

Copyright 2006 InfoWorld Media Group, Inc.
The opinions and views expressed in comments, blogs, etc. are those of the authors alone and not necessarily those of TMC, TMCnet, or its editors. TMCnet reserves the right to edit, delete, or otherwise make changes to the content that appears on these pages at its own discretion and as it deems necessary.

Listed below are links to sites that reference Interview: BEA CTO details SOA platform:

Around TMCnet Blogs

Latest Whitepapers

TMCnet Videos