One year since receiving 10M in VC funding, SpringSource (the company behind Spring framework) today became an application server vendor, challenging the existing Java EE server establishment with the SpringSource Application Platform (editor's note - SpringSource's Rob Harrop has released further technical details on his blog), an application server built on Spring, OSGi, and Apache Tomcat. The new appserver departs from the Java EE standards, exposing the Spring programming model natively, along with a new deployment and packaging system, built over an OSGi core. Today marks the beta release under the SpringSource Evaluation license. A GA version will be released with open source (under GPLv3) and subscription versions in one month.
SpringSource Application Platform is not a Java EE application server. While it does support WAR deployment, EAR deployment is not supported nor are some other EE specs such as EJB. The SpringSource Application Platform has been designed from the ground up to instead focus directly on supporting the widely used Spring Portfolio of open source projects. Specifically, the application server builds on the Spring Portfolio programming model leveraging Spring Dynamic Modules for OSGi-based deployment. SpringSource has created a "kernel" of logging, tracing, bootstrap, classloading, management and other features on top of the Eclipse Foundation's Equinox OSGi runtime environment. Tomcat is included as an OSGi bundle to support web functionality.
InfoQ spoke to Spring framework co-founder and SpringSource CEO Rod Johnson to discuss the new application server. Explaining the need for thew new platform, Rod pointed to a number of pain points with today's current development/production environments such as the duplication of meta data across configuration files, the fact it is common for projects to in essence deploy a server on top of a server (deploying your application along with many tools and frameworks in the same deployable unit), meanwhile they were mostly using only the web container portion of their appserver. SpringSource as a result wanted to provide a simpler platform based on today's development needs.
On the benefits of the new application server, Johnson emphasized modularity: both for the server itself but also for the packaging and deployment model offered to developers. By leveraging OSGi and the interworking nature of dependencies among OSGi bundles, a running application server only has active the features needed for the applications running in it, cutting down on the server's footprint and startup time. This dependency support also allows multiple versions of dependent libraries to coexist for different applications. Parts of the application server can easily be updated and restarted without restarting the entire system. From a development standpoint the server's modularity allows for extremely fine grained redeployments to be quickly performed as code changes.
On OSGi and SpringSource's use of Eclipse Equinox OSGi, Johnson praised the foundation that that the OSGi specification and runtimes implementing provide but noted that OSGi can be a bit too low level for every day application development use. Johnson explained that SpringSource wants to enable developers to easily gain value from OSGi in an enterprise context. The new application server abstracts a lot of the complexity of OSGi behind new programming model constructs. He went on to mention that the application server will support a new PAR deployable unit simplifying the use of OSGi for enterprise applications (more on this below)
Asked about legacy support of libraries not natively supporting OSGi, Johnson replied that significant work had been performed so that the application server environment and classloading would behave in a manner compatible with legacy libraries. SpringSource will also be submitting patches back to projects such as Tomcat for any changes they have made to enable a library to be OSGi bundle compatible.
Johnson explained that the majority of application server code would be release under GPLv3 license. Everything that a developer has to commit to in terms of the server, programming model and deployment unit will be available in an open source manner. SpringSource will also provide a commercial version of the application server that includes support, indemnification, management, and monitoring capabilities.
On Java EE and how the announcement of the Spring Application Platform would effect the Spring Portfolio's continued support of Java EE. Johnson responded:
...What we are fundamentally trying to do is NOT push the Spring user community in any direction. We are simply giving them this choice. The Spring philosophy is that the user is always right. They are smart enough to figure out what they want. Regardless of if they take this choice, we think they will be glad to have the option to consider...
Johnson affirmed that SpringSource is committed to ensuring that the Spring Portfolio and other SpringSource products are compatible with other application platforms. Johnson then commented on upcoming Java EE 6 specification:
Java EE 6 is about modularity and is moving [Java EE] in the right direction. It is highly likely that the SpringSource Application server will become Java EE 6 Compliant in some form. There are three profiles A, B, and C. I can very confidently say that we're not going to implement the Entity Beans 1.1 model or several legacy technologies that constitute option 'C'. It is extremely likely we'll implement profiles A and B. I can't say it with 100% certainty however since the specs are not final.
Finally, InfoQ and Johnson talked about the big picture of the SpringSource Application Platform. In terms of the shift to OSGi he commented:
The traditional application server model is becoming obsolete. BEA and IBM are redoing their application servers incrementally using OSGi. SpringSource is providing OSGi support now. You look at the numbers and most people don't deploy to a full blown platform. They deploy to Tomcat. They write their code to the Spring programming model rather than Java EE. The market has already made its choice, the question is how long will developers have to fight their servers.
Johnson explained that he was confident the SpringSource Application Platform would succeed for three reasons:
- It is the first product that built on a modern technology basis. Java EE compliance is no longer the be all and end all. We've got a competitive advantage because we have a clean new code base. We have designed and delivered to meet the requirements of today and not those from the last 10 years.
- POJO programming is where the industry is. In the past POJO programming was grafted onto other products kicking and screaming. In our case, POJO programming is the design assumption around what we've built.
- The OSGi technology used is a fundamental next generation technology.
In addition to Rod Johnson, InfoQ also followed up with SpringSource's Rob Harrop for some of the technical details of the new application server. In terms of what is in/out of stack compared to the traditional Java EE application server he commented:
...JPA and JMS are both supported, but we don't include any particular implementation. In the case of JPA we support Hibernate, OpenJPA and Toplink. We've added support for load-time weaving into the OSGi environment that honours boundaries between applications and doesn't accidentally pollute shared libraries. JNDI is not included, the OSGi Service Registry is used in preference. Servlets are supported via the embedded Tomcat. Things in JEE but not in the SpringSource Application Platform include things such as Entity Beans.
InfoQ next asked about Spring Dynamic Modules. Spring-DM has been a public project for quite a while. From a modular deployment standpoint, Harrop was asked if anything was added to Spring-DM:
The Platform introduces the notion of applications, formed from one or more bundles. The bundles in these applications are explicitly scoped to prevent applications colliding with each other. This is particularly important when you have applications that start publishing services in the OSGi service registry - you don't want those services conflicting with each other.Harrop went on to describe the new PAR format:The introduction of Import-Library has made it much easier to use third-party libraries in your applications. Rather than having to code a lot of Import-Package statements, some of which might not be entirely intuitive, you can use Import-Library to pull in all the necessary packages for a logical library. Libraries such as Hibernate JPA can also span multiple bundles, so using Import-Library really makes a difference.
In terms of extending Spring DM to support running in the Platform, very little was added to the code base.
Spring DM powered bundles are normal OSGi bundles that include META-INF/spring/*.xml files that are automatically made into an ApplicationContext for that bundle when it starts. Spring DM provides a mechanism for different bundles to import and export services using a Spring NamespaceHandler.A PAR (Platform ARchive) is essentially a collection of OSGi bundles, some of which will typically be Spring DM powered. Together these bundles form a logical application. The programming is simply raw OSGi, Spring and Spring DM - the PAR does not change this.
On how the team addressed legacy/non-OSGi libraries in comparison to techniques that have typically been used in the past such as Buddy Classloaders, Rob replied:
It is easier to say what we avoided doing. Buddy class loading, dynamic import and require-bundle are all explicitly avoided due to the difficulties in maintaining consistent class spaces. We also avoided providing any proprietary alternative mechanisms.Finally Harrop highlighted the benefits of the application server's modularity revealing that it allows the application server to maintain a minimal footprint. The platform provisions dependencies on the fly so a running instance only has installed exactly what it needs.Instead, we added some low-level hooks into Equinox to make resource loading work in the typical cases, we extended class loading to support load-time weaving and throw away loading semantics and we manage the context classloader to allow third-parties to see classes as expected. The PAR is a central part of this since it defines the scope of visibility for context class loading and load-time weaving.
In the worst cases, we created patched versions of libraries to make them work in OSGi, and we are making these available via the SpringSource Enterprise Bundle Repository as well as submitting all patches back to the relevant projects.
The last couple of years have seen many discussions about whether the Java EE standard is dead, today we have seen the launch of what may potentially be the next major appserver, without Java EE support. How do you see this changing our space going forward?