WebLogic man goes full circle with SpringSource
Second wind for Java application servers
We had an interesting conversation with Peter Cooper-Ellis, the guy who ran product management at BEA Systems from the time it acquired WebLogic and who's now taking on a similar role with SpringSource. Obviously, in the wake of the Oracle acquisition, it's not surprising that Cooper-Ellis jumped ship.
But in making the jump to SpringSource, Cooper-Ellis has come full circle. As BEA was digesting its WebLogic acquisition, Cooper-Ellis was there when the Java stack was being built. Now at SpringSource, with its Eclipse Equinox OSGi-based server container, he's now part of an open-source company that's helping deconstruct it. So we explored some history with him and compared notes.
To summarize, Cooper-Ellis sees a bit of history repeating again today: a decade ago, the drive was for a unified middle-tier stack to make the web interactive, and today, it's the goal of having a dynamic lightweight stack that uses simpler constructs. In other words, a technology framework that actually delivers on the old promise of "internet time" - where things move fast on the internet.
Let's rewind the tape a bit. In the 90s, BEA (originally called Independence Technology) was formed to make a business in middleware. It thought its business would come from transaction monitors, but that only addressed a tiny portion of the market with transaction loads huge enough to justify buying another layer of software.
Instead, the killer app for middleware occurred with the application server. When the web caught on, there was demand to add the kind of data-driven interactivity that became real with client/server. BEA bought WebLogic, a company that gambled (and won) a bet that Enterprise Java Beans (EJBs) would become the standard (which it did with Java 2 Enterprise Edition in 1999).
Rise of the rebels
The good news was that J2EE (later joined by rival .NET) provided the standard middle tier that made e-commerce bloom (if you're going to sell something, you need a database behind your online ordering system). The bad news was that J2EE was obese, proving overkill for anybody who wasn't an Amazon, eBay, online banking, or travel reservations site - it was engineered for transaction-intensive, highly distributed, data-centric websites.
Not surprisingly, the complexity of J2EE subsequently spawned a backlash for Plain Old Java Objects (POJOs), supported by a growing array of open-source frameworks made famous by then Burton Group analyst Richard Monson-Haefel in 2004 as the Rebel Frameworks. More recently, there has been surging interest in dynamic scripting languages that let you manipulate data using higher-level constructs.
But so far, all these technologies were about development, not run time. That's where Eclipse Equinox comes in. Leveraging the OSGi component model that Eclipse embraced for the IDE, Equinox extends the idea to run time. Like Java, OSGi was conceived for different purposes (Java was for set-top boxes, while OSGi was the framework for provisioning services in the smart, networked home). You could consider both as fraternal twins reunited at adolescence.
Eclipse reincarnated OSGi as the dynamic service bundle, first for its IDE (where developers could swap different vendor plug-ins at will), and more recently as a new run time.
That's where Cooper-Ellis views OSGi as giving Java application servers a second wind. In place of installing the entire Java Enterprise Edition stack, OSGi lets you provision only the features you need at run time. So if you add distributed nodes, you can take the Java Message Service (JMS) plug-in if traffic spikes, hot deploy clustering support, and so on. The advantage is that if you don't need these or other bundles, you could run the server on a very tiny footprint of code, which reduces overhead and potentially makes it blazingly fast.
That was what BEA was trying to do with the micro-Service Architecture (mSA) that it announced roughly 18 months before Oracle swooped in, and how it built WebLogic Event Server, its complex event streaming engine. The product only used Java Enterprise Edition features such as managing availability, security and user management, it dispensed with much of the rest of the stack, and supported development with POJOs, which included support of the Spring framework.
OSGi/Eclipse Equinox is part of the same return to simplicity that originally spawned POJOs and the rebel frameworks. Beyond the Java space, it's the same trend that has driven the popularity of dynamic scripting languages as a faster means to developing the relatively straightforward data-driven apps that are the mainstream of the web, and it's also the driving force behind AJAX (which is easy enough that casual developers, business analysts, or web designers can grow dangerous).
Each of these has catches and limitations but they are evidence that - for the rest of us - the 80/20 rule lives when it comes to developing for the web.
This article originally appeared in onStrategies.
Copyright (c) 2008, onStrategies.com
Tony Baer is the principal with analyst onStrategies. With 15 years in enterprise systems and manufacturing, Tony specialises in application development, data warehousing and business applications, and is the author of several books on Java and .NET.