It will be the Java community that decides how modularity evolves in Java.
JAXenter speaks to Oracle’s Mike Keith on why the OSGi standard is important for the Enterprise.
JAXenter spoke to Oracle’s Mike Keith on the future of OSGi in
the Enterprise and the new OSGi project at Eclipse: Gemini.
JAXenter: Why is the introduction of the OSGi
standard so important for Enterprise applications?
Mike Keith: Enterprise application vendors are
incorporating modularization techiques to produce higher quality
software. Enterprise developers are also thinking about and using
best practices of modularity so they become more skilled at
creating that software. OSGi has succeeded in creating an
environment that encourages both of these outcomes, placing
modularity squarely on the mainstage of enterprise application
development and production.
JAXenter: In your experience, what are the main
obstacles to the adoption of OSGi in the Enterprise?
Mike Keith: Enterprise applications are often
the proverbial combination of “large” and “complex”, so change is
obviously not something that happens quickly. The pre-existing
suite of commonly used enterprise technologies is non-trivial in
number and non-modular by design. Given that few enterprise
applications are written “from scratch”, one of the biggest
challenges introducing modularization of any form into the
enterprise is to maintain reasonable compatibility with what is
already in the field. The usual other challenges of changing the
developer mindset to think in terms of dependencies, providing them
with tools and environments to help them develop, test and manage
their modularized code, convincing management that investing in
modularization up front saves time and resources down the road,
etc, all still apply, of course.
JAXenter: What is Gemini? And how can the
project help to overcome the aforementioned obstacles?
Mike Keith: Gemini is an
Eclipse project that provides modular implementations of
enterprise technologies. It is composed of subprojects, each of
which implements a specific technology. The subprojects are largely
independent of each other and can be downloaded and used together
or separately. They provide a basis for developers and containers
to try out writing modularized enterprise applications using the
technologies they already know and love.
JAXenter: Can you describe the different
components of the project?
Mike Keith: Gemini is composed of 6 different
subprojects, each of which provides a modularized implementation of
a current OSGi enterprise specification.
- Gemini Web solves the problems of deploying a web application
archive (WAR) and running it in an OSGi framework.
- Gemini Blueprint is the new home for what was formerly the
Spring dm project. It implements the OSGi Blueprint component
- Gemini DBAccess provides access to JDBC drivers and databases
as shared modules.
- Gemini JPA implements the OSGi standard for configuring,
deploying and accessing JPA persistence units.
- Gemini Naming is an implementation of the Java Naming and
Directory Interface (JNDI) commonly used in Java, but integrated
with OSGi services.
- Gemini Management provides a standard JMX interface for
managing the core OSGi framework.
All of these subprojects can be used independent of each other.
This is proven by the fact that many of our users consume only one
or two of the subprojects.
JAXenter: Gemini Blueprint is based on the
Spring dm product. What was the motivation for donating the Spring
dm codebase to Eclipse?
Mike Keith: SpringSource was looking to open
source the Spring dm project and offered it as the reference
implementation of the OSGi Blueprint specification. Creating the
Gemini Blueprint project and making Eclipse the new home for its
development allowed the code to continue its lifecycle in the open
and evolve in a way that is both standards-based and
JAXenter: Who is currently participating in the
Mike Keith: Committers and contributors to the
project include developers from Oracle, SpringSource and SAP, as
well as a number of other individuals who have contributed on their
own. It is a very open and friendly project, so anyone who is
interested in using it and/or getting involved is welcome at any
JAXenter: How does Gemini relate to the other
OSGi projects at Eclipse, such as Virgo and the recently proposed
OSGi Enterprise Tools?
Mike Keith: Gemini is a subproject of the
Eclipse Runtime project and an active and integrated member of the
Eclipse runtime community. For example, Gemini JPA builds on the
EclipseLink persistence implementation project and Gemini Web is
consumed by the Virgo container implementation. We’re always on the
lookout for ways to interact with other projects within the
JAXenter: Do you think OSGi should be the
standard when it comes to modularising JDK 8?
Mike Keith: Java is now ubiquitous. It is used
all over the world in all kinds of platforms and systems, and
that’s great. On the other hand, along with so much influence comes
the responsibility to make decisions regarding the JDK with
sobriety and planning. I believe that all modularity options should
be considered and carefully weighed, but that OSGi should be near
the top of the options list. In the end, of course, it will be the
Java community that decides how modularity evolves in Java, and it
will happen in the same way it always does – through the JCP. I’m
confident that OSGi will be a significant input into that process,
and that the end result will reflect contributions from both OSGi
as well as other relevant viewpoints and systems.
JAXenter: What future developments are planned
Mike Keith: We are currently working towards
getting all of the subprojects graduated from incubation and having
production releases available. As of this writing, Gemini Web has
already achieved this milestone and most of the remaining
subprojects are close behind.
We plan on doing more in each of the subprojects, for example,
adding more database support to Gemini DBAccess, etc, as well as
providing additional integration points across the subprojects. The
Gemini community is continuing to grow and mature and we are happy
to let the community decide the direction the project should take
in the future, as long as it is in keeping with the philosophy of
the project — working towards enterprise modularity.