SpringSource Gains Momentum in Enterprise Java

 
 
By Darryl K. Taft  |  Posted 2008-11-14 Email Print this article Print
 
 
 
 
 
 
 


title=SpringSource Plans for the Future} 

Enterprise Java will soon be 10 years old, clearly a maturing technology. Put a little more bluntly, why does Spring want to be the next app server if the app server is dying? Moreover, what are you going to be doing to grow beyond this market?

Great question. I agree that the traditional monolithic Java EE application server is a dinosaur. We aren't in the business of building another one, and I don't think our users or customers would want us to.

Dm Server is a different animal from the traditional application server. It doesn't implement the whole grab bag of J2EE APIs-many of which no sane person has used for years-although, it may implement the Java EE Web Profile, depending on whether we feel that output of the Java EE 6 effort is relevant to our customers.

Built on our dm Kernel technology, itself based around OSGi [Open Services Gateway initiative], dm Server is modular from the ground up. It isn't a one-size-fits-all product. It is able to adapt itself to provide exactly what the user requires for a particular purpose. This is radical new technology. A good analogy is the Terminator. The traditional application server is like Arnold Schwarzenegger's T-101. It's big, can usually get the job done, but is a bit clumsy. Dm Server is like the T-1000 in Terminator 2. It can adapt itself as required.

Modular middleware is key to the vision that we have had for years. Darryl, I think the first time we met was when you approached me at a trade show back in 2004, where I was talking about J2EE without EJB. The vision in that book was "a la carte" middleware, and dm Server makes that reality.

The traditional application server may be dying, but there's still a real need for infrastructure. We believe that the combination of Spring and dm Server is tomorrow's infrastructure.

Can you comment on which open-source licenses you use at SpringSource and your reasons for choosing each of them?

We're involved with all the most important open-source communities in enterprise Java. This means that we inevitably work with different licenses.

The key open-source licenses we use are:

Apache License: This is a great license for de facto standard projects such as Spring Framework, which are used by ISVs as well as end users. For example, the Spring Framework is used in the core of Oracle WebLogic, and that's great. It's also the de facto standard programming model for enterprise Java, and we want it to be easy to adopt.

Eclipse Public License: We are involved in a number of Eclipse Foundation projects, including AspectJ, which we lead. Those projects are all EPL.

GPL: GPL [General Public License] is the most popular open-source license, industrywide. GPL doesn't impact end users, but does restrict ISVs in their ability to build closed-source software above open source. That's a pretty fair restriction. We choose GPL for dm Server, because it solves tough problems that large vendors such as Oracle and IBM have been struggling for years to solve. We think our solutions to those problems are well ahead of the curve, and we don't see why we should let large companies compete with us with our own code-probably as part of closed-source products that wouldn't be available to the open-source community.

What are your thoughts regarding cloud computing/SAAS (software as a service)? Cloud computing is about flexibility and simplification, which seems like a natural fit for you guys to go after.

We will be announcing some partnerships in cloud computing at SpringOne Americas in December. Watch this space.

Who do you plan to acquire next?

We don't have any concrete plans, but we are certainly open to making further acquisitions.

What are the most exciting technologies you see coming for Java, and how could Spring tie into those?

We think OSGi is transforming enterprise Java, and we've been heavily involved in bringing it to the server side for years. Spring is becoming the standard component model for OSGi.

We think Grails and Groovy are exciting technologies for the JVM [Java Virtual Machine], hence our acquisition of G2One. Grails is, of course, built on Spring. There's a lot of potential in dynamic languages on the JVM: It's not just about Java.



 
 
 
 
Darryl K. Taft covers the development tools and developer-related issues beat from his office in Baltimore. He has more than 10 years of experience in the business and is always looking for the next scoop. Taft is a member of the Association for Computing Machinery (ACM) and was named 'one of the most active middleware reporters in the world' by The Middleware Co. He also has his own card in the 'Who's Who in Enterprise Java' deck.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...

 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel