Rod Johnson, the creator of the Spring Framework that has become so popular among Java developers, is attempting to raise the profile of the company he founded to help bring Spring to market: Interface21.
Johnson created Spring as a byproduct of a 2001 Java book project. Since then it has become one of the leading alternatives to Enterprise Java Beans (EJBs). But now Johnson has turned his attention to growing his company Interface21, while coping with the fact that its primary product, Spring, is better-known to most Java developers than the company itself.
Speaking to Computer Business Review in a recent interview, Johnson explained how the development of Spring came about. He had been writing a sample application that would be used in his book Expert One-on-One J2EE Design and Development, for WebLogic Server 6.1. The application used one of the key elements of the EJB spec, container managed persistence (CMP). That’s the feature where the Java Bean itself manages the connection and the mapping of objects to relational data structures. It also happened to be one of the most challenging pieces of EJB components to write.
I discovered that even writing a simple app was ridiculously complex, said Johnson, echoing a conclusion that was becoming more and more apparent to Java developers. We succeeded by working around the specs.
When J2EE emerged during the height of the dot-com boom in 1999, it was aimed at providing the necessary, well-rounded framework that the complex, highly distributed Internet applications of tomorrow would require.
This was the period where the Internet was supposed to be changing everything, including the way apps were deployed. EJBs, which formed the heart of the spec, were supposed to provide a way for developing components that could be deployed in such widely distributed, high traffic environments.
But EJBs proved too complex. While they were supposed to abstract all the middleware plumbing, according to Johnson, it forced you to write Java apps around the plumbing. Nonetheless, as complex as J2EE was, Johnson characterized it as simpler than CORBA, the middleware community’s previous attempt at a distributed component standard.
Not surprisingly, EJB versions 1 and 2 found scant uptake. For instance, at a Java developer conference back in 2001, we polled a room full of developers and asked if any of them actually used EJBs. Only a couple of hands went up.
The problem with EJBs is that they went from vaporware to legacy without the intervening step of being real, said Johnson. He noted that the vendor community’s strategy for cutting through the complexity was to automate the process. The Java industry had faith on tools. The CMP 2.0 specification writers knew that no mortal could write all the code. They knew that tools would generate it all.
By 2005, the Java Community Process (JCP) got the message and responded by simplifying J2EE 1.4’s successor: Java EE 5. But by then, the damage was done. Several rebel frameworks had already emerged: Struts, TomCat, Hibernate, Spring, and others. The common thread of these new, so-called rebel frameworks is that they relied on relatively basic Java classes, also known as Plain Old Java Objects, or POJOs.
The original Spring framework was about 30,000 lines of code, published as a sample application in conjunction with Johnson’s book. It was open sourced in 2003, with Johnson’s newly formed company, Interface21, employing the project leaders.
Spring’s key innovation was a concept called Inversion of Control, which meant that you didn’t have to write all the plumbing in your code. Instead, the framework would handle all dependencies (for proving the right artifacts to the interfaces) with whatever server target or framework you were writing the object to interact or execute against.
For instance, it abstracted the need to write interfaces to Java standards like JDBC and JMS, or other objects such as Spring’s own Model-View-Controller (MVC, a design pattern for GUIs that isolates presentation from the underlying data access and business logic).
According to Johnson, those 30,000 lines of code were only meant for prototyping, and not intended for applications that would go into production. But by the time that version 1.0 was published the following year, developers had other ideas. Spring was gathering momentum.
For instance, when BEA surveyed its installed base, it found a large proportion was interested in putting Spring into production. In the meantime, BEA developed its blended source strategy, symbolizing that many leading Java brand owners were now looking to join, rather than fight the so-called rebel frameworks.
As an open source project, it’s difficult to gauge the extent of Spring adoption in the Java community. But according to Johnson, there have been roughly a million downloads to date, and Interface21 itself has trained over 1,800 developers.
That brings Interface21 to an interesting crossroads. Its primary product has become far better known than the company itself. And until this point, the company has been known as a training and services company that has helped promote adoption of its open-sourced product.
But, as Johnson wants to make clear, this is not a charity operation, and it won’t be just a professional services firm either. In the long run, he intends Interface21 to become a product company, and that may be harder that it sounds.