SpringSource has released a server platform, based on OSGi. Not only do its internals use OSGi, but developers will also be able to make use of it directly. What does that mean? And what are the benefits? What's going on with SpringSource? CEO Rod Johnson tells us all about it in this interview.
Wow. SpringSource is now an application server vendor. How did that happen? And why so secretly?
Firstly, a lot of work has been happening in the Spring Portfolio of open source projects over the last 18 months. Most directly in the area of the Spring Dynamic Modules for OSGi project, but also in delivering Spring 2.5, where we've been working on classloading in the context of OSGi environments. We've also been working on Spring packaged as OSGi bundles with metadata and have been actively engaged with the OSGi alliance in helping move OSGi forward in the enterprise. What we've built above OSGi, in terms of the server, has been done by the team at SpringSource, working for over a year on this project. And the reason that we have not announced anything about this previously is that we think this development is potentially very significant and we didn't want to have people see our ammunition before firing it.
It's been reported as being a new application server without Java EE.
Well, that's probably not the best categorization. It certainly is a server without traditional Java EE. We're not interested in implementing Java EE 5, although it is very likely that we'll implement the Java EE 6 profiles. We're not in opposition to Java EE, but the current version of Java EE does not satisfy the needs of our customers. However, note that we are on the Java EE expert group.
What are the main benefits of your offering in this area?
We provide simplified deployment through giving a better way of packaging applications and their libraries. We consider WAR deployment units becoming a bit long in the tooth. Our dozens of consultants and support engineers have told us about the great deal of duplication going on with web.xml files, Spring configuration file, and so on. Also, the Java EE web-inf folder is unversioned and messy. It has problems with dependencies and potential duplications, on top of which there is no portable way of sharing dependencies at all. These complexities were simply not envisioned by Java EE.
Instead of that, we offer an approach focusing on OSGi bundles for application deployment purposes. Here we see raw OSGi, which is significantly more modular than the traditional WAR model, while offering a much better way of sharing dependencies between applications. It also means that there is no need to deploy part of the server with every application. You can just deploy the bundle that your application requires. The server handles the resolution of particular versions. The use of OSGi provides faster deploy/test cycles because you can redeploy and test those classes that have changed within a bundle, which means that you're redeploying only a part of the application. The server starts quickly because of the modularity of OSGi. On top of that, there's a simpler deployment model because the server understands the components that it sees in the JAR file. For example, if the server sees a Spring configuration file, it understands that and knows what to do with it.
Another benefit is that the user will leverage the Spring programming model, instead of some new programming model. Spring is well established and has been broadly adopted in the enterprise. There is no Java code that is specific to our platform. In short, we're offering the user a deployment model that is compelling, while providing versioning, modularity, and support for concurrent versions of libraries and applications, both at development and production time.
Here is a diagram of how everything fits together:
Very recently GlassFish announced the same thing: they're on OSGi too. Care to comment?
Well, I'm not very familiar with this development since it happened only recently. But, my understanding is that GlassFish does not expose the OSGi model to the end user. The end user's experience is still based around WAR and EAR files. We, though, are providing the full power of OSGi by exposing it to application developers.
What are the benefits of directly exposing users to OSGi?
The benefits are many. For one thing, OSGi manages parts of your application but also the server itself. We are now farther along with modularization that any other server vendor. The current WebSphere is also on Equinox, but using only a very small number of very large bundles. We are providing our server in the form of finer grained bundles, which means we can maintain the server and push out patches very easily, while additional capabilities can be added as bundles.
In addition, there's the support for versioning. If you have two parts of your application depending on different versions of a library or service, we can support that through OSGi's clear separation of modules, with its support for versioning. The OSGi backbone is more dynamic than traditional servers for upgrading and stop/starting without redeploying the entire application, which gives the user a greater degree of control over the division of the application. They'll be able to group classes and resources together and deploy them as a group.
Since the licensing of the server infrastructure is GPLv3, people will be able to create plugins for it and the plugins will need to be open source. The 1.0 version of the server provides the "web personality", while the 2.0 version will extend that with a "batch personality". (The "batch personality" will allow users to deploy batch deployment units and then the server will start up those servers applicable to batch processing.) In turn, partners and the community will be able to add their own plugins that provide additional personalities, such as a "SOA personality" for example. Plugins will be delivered as OSGi bundles and can potentially be shared with other OSGi platforms.
Is this why you are you calling it the SpringSource Application Platform, rather than SpringSource Application Server?
Yes. We didn't want to call it a server because it will be able to be extended and accept different deployment modules, so it will be broader in scope than a typical server.
Where do you see these SpringSource developments in relation to the JCP?
We are very keen to support those JCP technologies that make sense to us, such as the introduction of modularity in JSR-277 and the introduction of profiles coming out of Java EE 6. We are involved in several expert groups, such as those relating to JMX and Servlet 3.0. We are primarily focused on what we believe are the most appropriate technologies. We don't think EJB is an appropriate technology. And the market reflects that: there are now more Spring than EJB jobs and the majority of the development community agrees.
We hope the JCP will move in positive directions. By that we mean a more modular deployment model and a need for more server structures. As SpringSource, we have now put a technology out there that delivers those benefits. We’d like to standardize our deployment model via the OSGi alliance. And we don't want to wait for a more modular approach coming out of the JCP: we believe that the best possible contribution we can make to the shared body of knowledge is to battle test ideas and to get experience out there and prove our model in the process.
In general, though, OSGi and Java EE are not traditionally compatible. But, as as OSGi becomes more important, this is something that Java EE will need to deal with, and not the other way round. We feel that Sun is becoming much more open than before and are very heartened by JCP developments recently. JSR-277 and OSGi will come to a good accommodation that will provide the best possible outcome. We believe that JSR-277 and OSGi will play nicely together, what with Sun getting more serious about openness.
And what about tooling support?
For this we have the SpringSource Tool Suite, which is a comprehensive Eclipse distribution, consisting of Spring IDE, Mylyn, AspectJ, and some in-house work. The application platform can start from the tool suite, making it easier to work with the OSGi concept and deploy just those parts that have changed. The tool suite is available to subscription customers, though we will provide some additional tooling in the open source.
In the process, you've extended several existing technologies. Will you contribute these extensions back?
Good question. We will make contributions back to the projects in the community, because we want to make use of their technologies in a respectful way. We have made some minor changes to Equinox, because we really pushed it to its limits, and are trying to get our changes standardized, for which we are getting a great deal of support from that community. For Tomcat we have worked on classloading to make Tomcat play nicely in an OSGi environment. We are working to contribute those enhancements back. The Apache process requires approval from the community and we are working on that. We're attempting to get all the extensions and modifications back to their respective projects, so that the Tomcat community should end up with a Tomcat that works nicely in the OSGi environment, which wasn't possible before. We also used AspectJ internally in sophisticated ways and our additional constructs were compelling use cases that will also be contributed back.
You also have a Beta program.
Yes. That will last about a month. Our GA version will be available both in the open source version and as a subscription version. The only reason we're not releasing Beta under open source is that we simply didn't have enough resources right now for open sourcing it. Both the programming model and deployment model will be open source. For users, it will work and they'll be able to run their code. The subscription version adds features interesting to manageability for the enterprise, such as an application management suite, which includes a management console to inspect the runtime behavior of applications. Also, the subscription version provides the SpringSource Tool Suite, some specific features relating to Oracle, and more regular updates and patches.
Finally, what factors make you believe that the Spring Application Platform will succeed?
Firstly, the time is right. The Spring programming model is experiencing rapid growth and is the choice of the majority of enterprise Java developers. Analysts, job trends, Gartner group, and so on, agree on this point. It extends the Spring value to the entire platform, which is a major selling point.
Secondly, the time is also right because traditional application servers were conceived when Bill Clinton and Monica Lewinsky were in the White House. Gradually there is an accumulation of momentum behind OSGi. This OSGi stuff is wonderful, users can see its benefit, but not how to use it. They need more around it to make it workable. Look at the rapid growth around OSGi. It provides strong platforms, built on OSGi and Spring.
Thirdly, developers and managers will welcome more competition in the application server market. This has been quite a week: yesterday we launched our platform and the day before BEA was acquired by Oracle. So the strongest independent application server was acquired by a vendor with a full stack. So, the time is absolutely right to bring a new choice into the market.
Finally, because it delivers real benefits: starts quickly, small footprint, gives a solution for versioning, with management of library dependencies... so providing that solution at this time means the product is introduced in the right place at the right time.
Rod Johnson is CEO of SpringSource and the father of Spring and is one
of the world’s leading authorities on Java and J2EE development. Rod’s
best-selling Expert One-on-One J2EE Design and Development (2002) was
one of the most influential books ever published on J2EE. The sequel,
J2EE without EJB (July 2004, with Juergen Hoeller), has proven almost
equally significant, establishing a comprehensive vision for
lightweight, post-EJB J2EE development.
Rod regularly speaks at conferences in the US, Europe and Asia, including JavaOne, JAOO, JavaZone, O’Reilly OSCON and The Server Side Symposium. He was awarded “Rock Star” status at JavaOne in 2005 and 2007, and delivered keynotes at the JavaWorld conference in Tokyo and the JAX conference in Munich.
Rod currently serves in the JCP on the Expert Groups defining the Java EE 6, Servlet 2.4 and JDO 2.0 specifications. His status as a leader in the Java community has been recognized through his invitation to Sun’s Java Champions program. Rod continues to be actively involved in client projects at SpringSource, as well as Spring development, writing and evangelism.