Enterprise JavaBeans and the era of the application server
On September 28, 1998, BEA Systems paid $192 million in stock for a three-year-old startup called WebLogic, Inc., whose entire product was a Java server and a protocol the founders had named T3. The name T3 stood for three-tier: web client, application server, database. BEA was not buying source code. It was buying a conviction about where enterprise software was headed.
That conviction had been building since the mid-1990s, as client-server applications — fat desktop clients talking directly to databases — buckled under the weight of internet-scale traffic. The web demanded stateless HTTP sessions, thousands of concurrent users, and coordinated transactions across systems that had never been designed to cooperate. Something needed to sit in the middle: pooling database connections, enforcing transactional integrity, applying security policy, and translating between HTTP and the business logic underneath. WebLogic, Inc. had founded itself in September 1995 in San Francisco precisely to build that middle tier, and had shipped its Tengah server in 1997 — two years before Sun would bundle EJB into the broader J2EE 1.2 platform in December 1999.
The specification itself arrived at JavaOne in San Francisco, March 24–27, 1998, when Sun Microsystems announced Enterprise JavaBeans 1.0, co-authored with IBM, Oracle, and Hewlett-Packard. EJB was a component model for the application server: write a bean, declare its transactional and security requirements in metadata, and the server’s container would supply everything else. Session beans held business logic. Entity beans mapped to database rows and managed their own persistence. The container provided transactions, connection pooling, and remote access — none of which the developer had to write. The architectural promise was clean: business logic portable across any certified server; plumbing was the container’s problem.
The plumbing turned out to be everyone’s problem. EJB 2.x, released in 2001, required each business object to be declared across a remote interface, a home interface, a local interface, a local home interface, the bean class itself, and an XML deployment descriptor. Remote calls ran over CORBA, which imposed serialization overhead even when client and server shared the same JVM, because the specification had been written for a distributed-everywhere future that had not arrived on schedule.
By October 2002, a British developer named Rod Johnson had grown tired enough of the overhead to write a 900-page book, Expert One-on-One J2EE Design and Development, arguing that most of what EJB promised could be had with plain Java objects and a lightweight container of his own design. The code he released alongside the book became the Spring Framework. When EJB 3.0 arrived in 2006, it had dropped the home interfaces, adopted annotation-based configuration, and incorporated a persistence API whose design tracked Spring’s closely enough to read as a concession.
What the application server era established, beneath the XML and the CORBA overhead, was the architectural grammar that enterprise software still speaks: a runtime handles transactions, pooling, and security as first-class services; business logic is declarative and environment-agnostic. The specific answer got lighter. The question did not.
The name “container” outlasted the technology. Something that began as a JVM managing bean lifecycles became a Linux namespace managing microservices. The object changed; the enclosure did not.
Sources
- Jakarta Enterprise Beans — Wikipedia — EJB 1.0 (March 1998), JavaOne announcement, bean types, EJB 2.x complexity, evolution through 3.0.
- WebLogic, Inc. — Wikipedia — Company founded September 1995 in San Francisco; T3Server / Tengah shipped 1997; BEA acquisition for $192 million, September 28, 1998.
- Celebrating 20 years of enterprise Java — Red Hat — J2EE 1.2 (December 1999), the portability challenge across application servers, JBoss origins.
- Rod Johnson — Wikipedia — “Expert One-on-One J2EE Design and Development” (October 2002), Spring Framework (June 2003), EJB complexity critique.