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