RealTime IT News

Mark Carges, Chief Technology Officer, BEA Systems

Jeff HawkinsBEA Systems is adrift on an ocean of information these days.

One of the top middleware providers in the world, the company has set sail on a course for "enterprise liquidity," where bits and bytes of data are exchanged seamlessly between applications with no regard to the technology.

Just a year after flirting with the Liquid Computing brand and code-names like QuickSilver and Alchemy, the San Jose, Calif., company has settled on another water-oriented brand and product family: Think Liquid and AquaLogic.

The idea of computing being liquid, BEA executives explained during a press event in New York earlier this month, is that information flows seamlessly from one network to the next, buoyed by a complex model called a services infrastructure.

Service infrastructure is simply BEA rendering of a service-oriented architecture (SOA) , a distributed computing model in which Web services are often shuttled from network to network as a form of communication among software.

Armed with Think Liquid and AquaLogic, BEA hopes to saturate the market and soak up market share from rivals IBM, Oracle and Microsoft. BEA CTO Mark Carges recently discussed internetnews.com the plotting of BEA course. .

Q: What is the essence of AquaLogic?

We recognized a need for infrastructure to support service networks, or what we call service infrastructure, after seeing customers work with our product over the last couple of years to build out service-oriented architectures. We observed their services portfolio and saw some things that needed to happen.

Services need to be extremely heterogeneous, not constrained by any particular technology. The existing services are in mainframes, packaged applications -- new and old -- and so on.

That heterogeneity needs to be tied together in a neutral fashion. XML and Web services certainly meet that need. But the way to tie these together requires a set of technologies that are independent and neutral from those different endpoints.

We asked: Would J2EE-based, developer-oriented technology be what you're going to need to tie together your service backbone and service networks? Or would a particular type developer model or would writing code be a way to solve these problems?

We said it's not about writing code or buying code and endpoints. What's important in the service network is the ability to bring everything together and manage it, compose it and see the policy.

The realization behind AquaLogic is that we wanted to provide a set of technologies for a service network that was independent of the technology of the endpoints, but that could integrate with heterogeneous endpoints. That's AquaLogic.

Q: Where does the WebLogic platform and brand fit into this mix?

The important point is: Who is it aimed at? Who uses it? WebLogic is aimed at developers writing code.

They see the Java, they write to J2EE standards. With AquaLogic, the users of those tools will be interfacing with policy tools, configuration tools, management tools -- not development tools. There won't be a WebLogic Workshop-type tool for developers in AquaLogic.

We talked about Composer at our launch. That is a type of tool that will allow you to compose your enterprise business process, or to put portals together via federation. But you're not going to be writing code. If all the tech and products are part of a WebLogic developer-centric brand, what we're advocating to the world that only way to do SOA is to write code. We recognize there is a time and place for writing code and a time and place to leverage metadata and to enunciate separately from code.

Q: The heterogeneity factor seems to be one major hallmark of the SOA as we know it. Can you elaborate on that?

I tell customers we need to look at how to service-enable the applications you have regardless of where they live. The minute you do that you'll realize there's going to be the 30-year-old mainframe that does its provisioning thing from the last two or three decades, as well as a new Siebel app, and Web-based apps built on .NET or BEA.

All of them will ultimately become part of what you're going to service-enable and consume. One, you have to have a tech-neutral way of looking at it, and two, you have to separate where you write code from where you're building and managing the code that someone's already written. I'm a firm believer that if you actually get to SOA and you're reusing services, at some point in time someone has to put their pencils down and stop writing code. You have to reuse and have tools to reuse what you already have.

Q: Gartner latest application and middleware market stats list IBM at 37.2 percent while BEA tallied only 7.2 percent. Is AquaLogic the answer to regaining market share?

On market share, I don't believe for a second we're No. 2. The reason I can say that so boldly is that our rev numbers speak to the license rev of our products.

There is no other company in the planet that has rev numbers broken out, let alone what is shelf ware versus what is deployed. A lot of IBM and Oracle sales are wrapped into other deals but never deployed. In many, many accounts we're in, supposedly all of the stuff that other competitors have sold and sits on shelves is counted as market share. Meanwhile they're writing checks to BEA.

It's not like in the database days where you can look at Oracle, Informix and Sybase revenues and say, "Well they all do DB so here it is." I would contend that in deployment we're the No. 1-deployed app server on the planet.

As far as what AquaLogic does from a growth standpoint, it puts us into new opportunities that would not have been addressable before with WebLogic. We will continue to grow and invest in the WebLogic brand for developers, work around Eclipse in Workshop, WebLogic 9 [Diablo].

And as enterprises move to SOA, WebLogic will be a great platform for creating and consuming these services. AquaLogic will be a good complement when you're looking to tie this all together whether it's WebLogic or J2EE. We see that as being a competitive message.