The specifications in the release address a number of important Enterprise use-cases and greatly enhance the OSGi programming model. Besides bringing a number of JEE technologies to OSGi, there are also a number of specs that nicely enhance the OSGi programming model.
Here's a high-level overview of the specs developed by the EEG in this release:
- The Blueprint specification is a standard based on Spring-DM. It provides an IOC container for OSGi and really makes developing with OSGi services very easy. Spring has many fans and the Spring-DM project has shown that integrating Spring with OSGi is a very elegant combination. The Blueprint standard helps developers by not binding their code to a single implementation. There are already a number of Blueprint implementations available.
- Remote Services and Remote Services Admin. These specifications started out under the name Distributed OSGi and bring Distributed Computing to the OSGi Service model. The Remote Services spec is for bundle developers. It describes how the OSGi Services Programming model is enhanced with a number of properties that turn your services into Remote Services. It's a very simple spec with big possibilities.
Remote Service Admin standardizes on a high level the internal components that a typical Remote Services implementation consists of. It defines the API for the Distribution Provider (the thing that makes the remote invocation), a distributed Discovery System (that can make your OSGi framework aware of suitable remote services) and a component called a Topology Manager that provides the decision policy over what services to export and import. RSA provides users with the capability to mix and match these components from various implementations. A user might use the Distribution Provider from CXF while taking the SCA-enabled Topology Manager from Tuscany combining that with maybe a yet another implementation of Discovery that might use a UDDI server.
- Web Applications - while deploying .war files in an OSGi Framework was already possible with technologies such as PAX-Web the Webapps spec describes a standard way to do this. Besides providing some new standard Manifest headers (like one to describe what context path your webapp lives on) it also describes a standard way for the Web Application to interact with the other bundles in the OSGi Framework. The Servlet Context will contain a new attribute 'osgi-bundlecontext' that gives your Servlet access to other OSGi Bundles and Services and allows the servlet to register OSGi Services of its own. Other OSGi bundles can interact with Servlets as the Servlet Context(s) of a successfully started Web Application is registered in OSGi Service Registry.
- The JDBC specification nicely solves problems that database users previously had while using OSGi. Obtaining a database driver was typically ugly and most of the time required exporting and importing private database packages. With the new specification JDBC Database drivers simply register themselves under a standardized DataSourceFactory class in the OSGi Service Registry. It has APIs to create a DataSource (variants for Pooled and XA are also provided) or obtain the underlying java.sql.Driver object. No exposure of internal classes any more.
- JPA is a highly popular Database Persistence framework and the OSGi-JPA specification describes how to use it from within OSGi. While there is a 'traditional' mode of using JPA in OSGi which is identical to using it in JSE, the recommendation is to obtain a JPA EntityManagerFactory from the OSGi Service Registry. This provides additional lifecycle support (you can update your JPA implementation without restarting the container) and it also allows the existence of multiple JPA providers in the system. OSGi-JPA implementations normally work well with the OSGi-JDBC providers described above.
- The JNDI spec provides a bridge between JNDI and the OSGi service registry. It enables the lookup of an OSGi Service or BundleContext through JNDI. It also describes how you to obtain a JNDI Initial Context from the OSGi Service registry in case your bundle needs to do a JNDI lookup or bind.
- Like the OSGi-JDBC spec, the OSGi-JTA spec provides access to JTA APIs such as javax.transaction.UserTransaction and javax.transaction.TransactionManager through the OSGi Service Registry. If you have a JTA implementation in your framework they will simply appear there.
- Finally, the JMX specification provides JMX access to the OSGi Framework. It enables controlling the Bundle Lifecycle (like installing, uninstalling, starting, stopping a bundle) from JMX and also provides Bundle and Service information through JMX. Additionally JMX APIs are defined for a number of standard OSGi Services such as Package Admin and Configuration Admin.
Oh, and as a side node, I don't expect Enterprise OSGi Frameworks to deploy all of these specs at the same time. Take only what you need, keep your framework nice and lean :)
Implementations for all of the above are available. Good places to look for them are the Apache Aries and Eclipse Gemini projects. And, of course, Apache CXF provides Remote Services and Remote Services Admin implementations in the CXF Distributed OSGi project.
Scott Lewis said: Hey David. For future, you might want to include the EclipseRT/ECF in your list of remote services impls.ReplyDelete
Maybe I should create a wiki page somewhere that lists all known implementations of all the specs, because there are more...ReplyDelete
"Implementations for all of the above are available"ReplyDelete
You're sure? Gemini is still in its legal phase before commiting modules and Aries looks quite empty as well in terms of releases :)
I'd be glad to have some reference implementation, specially for JTA.
So far I've been playing with Jencks and dealing with all dependencies is quite though.
Thanks for your commitment in the OSGi EE specs !
You are correct that most of these projects are not released yet. However, the source and binaries are generally available (albeit from trunk). It should however be enough to get you started with. The expectation is that most of these projects will do a release over the coming few months.
Aries is not empty. I have used Blueprint, JDBC, JPA, JNDI implementation for our current project. And Pax Web is good implementation of Web Applications specifications. Aries have a blog and AriesTrader examples gluing up all the pieces.
I created a page on wikipedia that lists all know OSGi spec implementations. http://en.wikipedia.org/wiki/OSGi_Specification_Implementations
Feel free to add anything that I missed there.
Can I ask if there is any way to retro-fit a non OSGi 4.2 JDBC driver to work with the new JDBC API in 4.2? Does this mechanism only work for drivers that have been repackaged or is there actual coding that is required within the driver to be able to use the JDBC Service registry?
It should be pretty easy to fit an existing non-OSGi JDBC driver into the OSGi model. What you would do is wrap the driver jar as-is in an OSGi bundle and add a bundle activator in the wrapper that registers the driver with the OSGi Service Registry. See here for an example of how we do this at JBoss: http://github.com/jbosgi/jbosgi-hsqldb/tree/master/bundle/src/main/java/org/jboss/osgi/jdbc/hsqldb/
You can also have a peek at our pom.xml to get an idea what the maven/bnd instructions to wrap a jar are...
It totally depends on your architecture and your application needs. What I would do first is come up with an architecture of your system. For this architecture you can pick from all OSGi Technologies (and anything else) that you like :)
Then once you made the choice that's right for you, only deploy those pieces of infrastructure that you need. So for example if you only need a web layer then don't deploy JPA support, etc...