Capgemini India Private Limited
Next-Generation
Enterprise Application Development
with SpringSource™ Application Platform
Aditya Jha
Page 1 of 7

Capgemini India Private Limited
Introduction
The Java, Enterprise Edition (formerly, J2EE) landscape has always been dynamic;
constantly updating itself to cater to requirements driven by the Java community. Just like
other worthy open-source ventures, it has maintained its status-quo as largely a
community-driven endeavor.
Most of the changes to this landscape have been called for by developers worldwide, for
whom not only the Java EE is the very bread and butter, but also a means of expressing
their creativity. It’s no surprise that with the latest version of Java EE, the platform has
taken an entirely new shape, whereby features like Dependency-Injection and
Annotation-driven drop-and-play components have become standard practice. However,
the changes remain largely in the area of construction of enterprise software.
An area equally important, if not more, is that of Application Packaging & Deployment.
Unfortunately, not much progress has been recorded in terms of packaging formats,
deployment techniques, administrator’s ease-of-use and standard ways of software
versioning. Let’s face it – We might start writing POJO-based EJBs and Web-Services
without a single XML descriptor, but we will still use the old method of WARing and
EARing our application in order to deploy it to a container of our choice. And I’m not even
counting any container-specific tasks that may be required to carry out as part of the
process.
Have the authorities been too busy to listen to the growing resentment in community?
Not really. There is JSR 277 in pipeline (anticipated in JDK 7), which might prove to have
the answers to some of the questions below. However, as explained further in the
document, it is sort-of reinventing the wheel due to the fact that a proven, reliable
technique is already there, and the folks in community have been using it for ages; only,
not knowing that it could be the very answer they are looking for.
Issues with current state of Java/JavaEE Application Packaging &
Deployment
Consider the following cases, and try to reason plausible solutions:
 Is hot-deployment a reality? How confident are you as a developer with regards to
memory footprint and resource loading of server in cases of hot-deployment?
 Module ‘A’ of your application has a critical flaw in its configuration files. Would it
be possible to redeploy a single module without bringing down the whole system?
Consider advantages this could provide in a scenario where the target server is on
the other side of the globe, and it takes 30+ minutes to transfer your complete
application-archive.
Page 2 of 7

Capgemini India Private Limited
 Is there a standard way of versioning your application? Is it possible from the
server console to query/manage the version-number of your application?
 How about versioning individual modules (for ex., Domain, Services, Web etc.) of
your application?
 Module ‘A’ of your system depends on version 1.1 of library ‘L’. Module ‘B’
depends on version 1.2 of the same library. Is it possible to satisfy such a
requirement within the same application? Consider that module ‘A’ might be
incompatible with version 1.2 of library ‘L’.
 You have two web-applications in two different EARs. Both require 15 third-party
JARs? Is there a standard way to share the dependencies, such that each WAR
need not be bloated with libraries? To take the idea further, is it possible to use
some kind of a global/organization-level repository of libraries, with only the
declarative dependencies mentioned in application/module meta-data?
 Is it possible to expose your POJO services without requiring consumer of these
services requiring to ‘approach’ or ‘obtain’ them (WSDL, JNDI)? How about
Dependency-Injection on a Library-level, or even Service-level?
 You have package ‘com.acme.myapp.service’ in your Service module,
defining façade interfaces for services. Corresponding implementations are in the
same module JAR in a package titled ‘com.acme.myapp.serviceimpl’. You
want to expose only the interfaces to other modules of the system. Is this possible
in the current scheme of packaging formats? Consider that the implementation
classes might need to be ‘public’ because of framework reasons (Spring-beans, EJB
etc.).
 How clearly can you represent the boundaries and interfaces of individual
modules in your application? Is there standard tooling possible which can read the
meta-data of the application and present a module-level interaction report?
There have been attempts by individual server vendors to address some of these
problems. However, there remains a need of standard, proven ways to provide a generic
meta-data facility in Java/JavaEE modules along with generic standards for packaging and
easy deployment, thereby resolving the above mentioned issues.
The resolution of above mentioned issues can be classified into two major groups – A
robust packaging and versioning technique, and an infrastructure to support, manage and
take advantage of such packaged modules/applications.
Page 3 of 7

Capgemini India Private Limited
Resolution of Packaging and Versioning Issues
For quite some time in past, Java community has been using a sophisticated, proven and
extensible technique of managing meta-data at module-level. This technique not only
solves the existing problems, but also enables us to future-proof our packaging strategies.
Think about it – we have been installing/creating several plugins in our Eclipse™
environment. Plugin ‘A’ might require version 1.0 of plugin ‘B’. Plugin ‘C’ might require
version 1.1 of plugin ‘B’ itself. These requirements (and others) have been successfully,
reliably and extensibly fulfilled by adopting a common format for packaging and meta-
data specification. This format is called Open-Source Gateway initiative (OSGi).
The OSGi format is a standard, open format specified by the OSGi Alliance Group. As per
the OSGi website (http://www.osgi.org/), “The OSGi technology provides the standardized
primitives that allow applications to be constructed from small, reusable and collaborative
components. These components can be composed into an application and deployed”.
OSGi format uses standard JAR format to define components of an application. These
components are termed as ‘bundles’ and each bundle has its meta-data in a standard
format in file META-INF/manifest.mf.
Thus, the manifest file of each bundle (JAR) will provide the following:
 Name and version of the module
 Type of module
 Dependencies required for the module
 Public interface (exposure) of the module
The component of Spring portfolio which helps in working with OSGi bundles is named as
Spring-DM (Dynamic Modules). This is a separate framework, independent of other
frameworks in the portfolio.
The OSGi technology resolves the following problems:
 It gives a standard way of versioning individual modules of an application.
 Dependencies (package/library/service) can be defined in a clear, unambiguous
and consistent manner.
 It provides greater control over the public interface of individual modules, by
providing a layer of encapsulation. Packages needed to be exposed can be
explicitly specified. The boundary and interfaces of a module are cleanly defined.
Page 4 of 7

Capgemini India Private Limited
Resolution of Infrastructure Issues
Having a common, stable and extensible packaging format is good, but it’s not the end of
the story. If we still have to do all the version-resolution and dependency management
tasks ourselves, it won’t do much of a benefit, would it?
This is where SpringSource™ Application Platform (S2AP) comes into picture. The S2AP is a
completely module-based Java application server that is designed to run enterprise Java
applications and Spring-powered applications with a new degree of flexibility and
reliability. It not only manages the lifecycle and dependency management for OSGi
modules, but also supports the standard Java EE WAR (Web ARchive) format as a first-
class citizen.
There’s more to it – The S2AP is not really a new server (which has to prove its worth),
rather it’s actually a Spring-DM kernel/runtime over Apache Tomcat, the leading Java EE
web-server in industry. Thus, you get all the reliability, community support and robustness
of a proven server infrastructure underneath the S2AP.
OSGi standard + Spring-DM + Apache Tomcat = SpringSource™ Application Platform
The SpringSource Application Platform is based on the new SpringSource Dynamic Module
Kernel™ (dm-Kernel). The dm-Kernel provides a module-based backbone for the server,
which also harnesses the power of Spring, Apache Tomcat and OSGi-based technologies.
Reference to SpringSource™ Application Platform can be found at the official website -
http://www.springsource.com/products/suite/applicationplatform.
S2AP helps in resolving the following issues:
 Hot deployment (even on production) becomes a reality. It provides complete
control over an application and its constituent modules. Individual modules or
even the application as a whole can be deployed at runtime. Even the so-called
‘pre-deployed’ applications are actually sensed and deployed in the truest sense at
runtime only.
 Provides out-of-the-box support for OSGi bundles. S2AP is fully aware of
corresponding standards and is able to read, manage and use the application
meta-data specified in manifest files.
 Provides dependency-injection at three levels – package level, library level and
service level. Respects and validates cleanly separated boundaries of individual
modules as per their meta-data.
 Supports the notion of centralized repository for bundles/libraries.
 Coupled with SpringSource™ Tool Suite (STS), provides an integrated,
comprehensive development environment with easy-to-use tools.
Page 5 of 7

Capgemini India Private Limited
Migration from standard WAR format to OSGi format
S2AP supports deployment of an application packaged in the following formats. These
formats or different ways of packaging an application are also known as ‘Personalities’:
 Standard WAR format
 OSGi Bundle (Web-module or Standard-module)
o Shared Libraries format
o Shared Services format
 PAR (Platform Archive) format
OSGi bundles are classified into two types – Web and Standard. Web bundles are having
the UI code, such as JSPs, MVC artifacts etc. (akin to a WAR), whereas Standard bundles
are either services or utility bundles (akin to normal JARs in an enterprise application).
The WAR (Web ARchive) Format
As mentioned previously, a standard Java EE WAR format is directly deployable in S2AP.
Naturally, if the application depends upon server-specific arrangements (connection-pool,
security-settings), the same have to be configured on S2AP as well. To make the
application completely portable, Spring encourages usage of Spring Security framework
and open-source, reliable connection-pooling frameworks (such as C3P0 or Apache
Commons DBCP). These not only make the application package completely portable
(drop-n-deploy), but also provide some new features, all in the familiar Spring-bean style
of configuration.
Shared-Library Format
The first step towards standardization is to pull out all the JARs from WEB-INF/lib, thereby
solving the library-bloat problems commonly found in web-applications. Instead,
dependency markers are put in manifest file to indicate which JARs are needed at
runtime.
Please note that you do not have to put markers for transitive dependencies, if your direct
dependencies are in OSGi format themselves. To facilitate this better, equivalent OSGi
bundles for various commonly used APIs have been provided in an Enterprise Repository
hosted by SpringSource™ (http://www.springsource.com/repository).
Compatible tooling provided by STS ensures that these markers are understood at
development time as well in order to resolve compilation issues. Thus, the effective
memory-footprint of web-application reduces to a great extent. This format is called the
‘Shared-library’ format.
Page 6 of 7

Capgemini India Private Limited
Shared-Services Format
The next step is to structure the application by dividing it into parts with clear, defined
and explicit boundaries. An application may be divided into parts either by aspects
(Domain, Services, Web etc.) or use-cases (InsertData, UpdateData etc.), or both. In both
cases, a valid division is not expected to have cyclic dependencies among its constituent
parts (or modules).
Each of these modules is an OSGi bundle, having its own meta-data and can be
deployed/redeployed independently (provided dependency among modules is taken care
of).
Thus, the services module can be reused in different modules, across applications. This is
possible because an OSGi bundle in itself is a deployable and hence, exposable unit for
S2AP. The original web-application’s footprint becomes even smaller. This format is called
‘Shared-Services’ format.
PAR (Platform Archive) Format
The final step towards PAR format is to identify related modules of an application and
pack them as a single unit of deployment, known as Platform Archive, or PAR format. The
PAR is simply a JAR file containing its constituent modules (OSGi bundles).
The PAR not only provides a packaging layer for the whole application for the purpose of
atomic deployment/undeployment, but also provides a synthetic scope for the whole
application. In other words, it provides a layer of encapsulation, so that two similar
modules (residing in different PARs) do not collide with each other.
Summary
SpringSource™ Application Platform brings the much-needed changes in enterprise-
application development, packaging, versioning and deployment processes. It presents a
refreshing, new and powerful way of merging OSGi standard with the mainstream
development and deployment processes. It further enhances reuse by promoting reusable
services and centralized repository of libraries.
SpringSource™ Application Platform has reached ‘Release Candidate’ beta version and is
about to be available for production very soon. In my humble opinion, this will be a
deserving force to reckon with for standard Java EE application-servers. All in all, definitely
a good news for Java community.
Page 7 of 7