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. 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.
Would you explain the concepts of SOA 360 WorkSpace 360, WorkSpace Central and microService Architecture?
Sure. Let's 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 you're 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 let's leave that for a second, and again I'll jump back out now this time to the roles. It's a multiple view of the same problem, it's 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 they'll now be stored in the central repository.
Which is what product?
It's 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 they'll 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 you'll 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 you're talking policy artifacts (etc.)... Those will again be put in the central repository. When you're 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...
That's where the Workspace 360 for IT will come in. And people will do two things. One, they'll control the deployment cycle, moving it from test to production. And the other one, once it's in production, will control the manageability, so finding things like -- is it up, it is running, what's the response time? What's the availability? Is it meeting the SLAs that were defined originally by the business users? And that's 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.