With AquaLogic, BEA Talks Up Last-Gen Paradigm Shift

Some analysts say the AquaLogic data service platform BEA Systems announced last week is the last, best hope of a one-time J2EE market leader.

BEA officials, not surprisingly, offer a different spin. They put AquaLogic on the leading edge of an incipient paradigm shift, one that’s less focused on discrete applications and data and more centered on services.

As paradigm shifts go, this doesn’t sound all that revolutionary; after all, most everyone is talking up service-enablement these days. But there’s more to it than that, officials protest: With AquaLogic, BEA also hopes to reinvent itself—in this case, by positioning its WebLogic application server platform less as a next-generation application architecture, and more after the model of a last-generation application architecture, with next-gen trappings, of course.

“The [AquaLogic] vision is something beyond the application infrastructure. In addition to what we’re doing with Java, in addition to what we’re doing with WebLogic, there’s fundamental changes going on at BEA, and our rebranding reflects that,” says Bill Roth, VP of marketing with BEA. “It’s a new vision about how we can take IT assets that are essentially frozen and make them more liquid, if you’ll pardon the plug.”

To sell this paradigm shift, BEA is trying to reach a new and different audience–C-level executives. The company has traditionally been most popular among J2EE application developers, but as part of its “enterprise liquid assets” pitch, BEA now hopes to secure top-down support, too. According to Roth, C-level executives and other corporate suits are more receptive to the AquaLogic idea of service-enablement and “legacy” asset liberation than are most rank-and-file developers. “We did a survey where we looked at the pervasiveness of the idea of the service-oriented architecture, and it turns out by a substantial margin that C-level and line-of-business executives get SOA and are more comfortable with the idea of SOA than developers are,” he comments.

Most rank-and-file developers know more about the nuts and bolts of the technology that’s designed to enable SOA than do their C-level counterparts. Because of this, some WebLogic developers who’ve looked at (and in some cases worked on) service-enabling applications think it’s an idea that makes sense, but–as far as large scale transformations go—is still largely horizontal. The same goes for the AquaLogic vision of “composite” applications (itself not exactly revolutionary), which describes a scenario where applications are pieced together, often by non-developers, from existing services.

“[Executives] hope that business process execution language…will enable business analysts to ‘orchestrate’ business processes directly. I describe BPEL as a scripting language. It has an XML representation, but people often view and write it in a graphical flowchart-like form,” says J2EE veteran and independent programming consultant Jeff Grigg. “It all seems like a good idea, but people will have to make their services available as WSDL-described SOAP services first. Until businesses make a big investment in SOAP-enabling their business applications, there won't be much to drive with BPEL.”

Roth concedes this might be the case. At the same time, he argues, change of the type that’s needed to facilitate a transition to SOA won’t come without a top-down push from C-level backers. And although AquaLogic does promise to put service orchestration in the hands of non-developers, Roth says it’s a bit too optimistic to expect business analysts to perform this task.

“I won’t go as far as saying that we’re servicing the business analyst. To me, a business analyst is someone who works on a spreadsheet, and we aren’t there yet,” he says. “We’re going after the people who spend most of their time configuring applications. If you’ve service-enabled things the right way, it should be merely a matter of configuration and not coding, and one look at our AquaLogic service bus product will tell you how that’s possible.”

About the Author

Stephen Swoyer is a contributing editor. He can be reached at [email protected].