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.
Mike Keith has been an object-oriented programming, distributed systems and persistence expert for over 20 years. He co-lead the expert group that produced the first release of the Java Persistence API (JPA) and co-authored the premier JPA reference book, Pro EJB 3: Java Persistence API, followed up with Pro JPA 2: Mastering the Java Persistence API. He works at Oracle as a Java architect and has represented Oracle on numerous Java and platform expert groups and specifications. He is the project lead of the Eclipse Gemini project that produces reusable enterprise modules supporting Java EE-based applications and also participates in the OSGi Enterprise Expert Group.
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 specification.
- 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 community-driven.
JAXenter: Who is currently participating in the Gemini project?
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 time.
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 ecosystem.
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 for Gemini?
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.