The OSGi Alliance has a community event in Munich on June 26th - 27th, 2007 that you must attend. The program is turning out to be quite interesting! Many of the key players in the OSGi eco system will be around. This is clearly the place to be if you work with OSGi Technology.
Obviously we will have a lot of attention for Enterprise software. Manfred Hutt, (Siemens), and Nicole Wengatz (Siemens) will demonstrate and talk about their use of OSGi in creating large Enterprise applications for business phone exchanges. BEA will show their microService Architecture based on OSGi and how it benefits their customers. Gunnar Wagenknecht (Truition), and Jochen Hiller (Business Operation Systems) will talk about server side Eclipse. Pierre Dubois (Requea) will talk about how to modularize Web Applications using OSGi Technology. The chief architect of the DB4Objects, Carl Rosenberger, will discuss OSGi Technology and persistence. A crucial subject for Enterprise applications.
One of the most exciting OSGi based developments is JSR-232 and the adoption by Sprint. Brandon Annan, their Lead Chief Java Architect, will explain what the plans are with OSGi. For any OSGi developer, these plans are very interesting, even if you never thought about programming for mobiles. The mobile phone is finally becoming a viable application platform for more than games. Just think what you could do if you could easily integrate mobile phone based solutions in your applications?
In the home automation markets we will have an experience reports from Miguel García Longarón (Telefónica). He shows real applications being used in the field. Andre Bottaro, Software Engineer, France Telecom, Sylvain Marie, Software Engineer, Schneider Electric will show how UPnP+OSGi can be used to finally make the home plug and play dream come true.
Abdallah Bushnaq from Ricoh will give an overview of how OSGi is used in printers. Interestingly, there are several printer manufacturers that have OSGi inside, for example Canon has an OSGi runtime that can be used to download print applications. I am curious how Ricoh will use this technology.
Industrial automation is one of my favorite application areas for OSGi. I think it is an almost perfect fit, especially because this market is less cost sensitive than consumer products. Daniel Grossmann, Research Assistant, Information Technology in Mechanical Engineering, will give a very interesting presentation of how OSGi technology can be used in the automation of very large plants like refineries. Roman Roelofsen (IONA) will discuss how Service Oriented Archictures also fit embedded systems, and OSGi Technology makes this straightforward.
Cross industry, there is the need for remote management. Joachim Ritter, ProSyst Software, will give a presentation how you can use OSGi Technology to manage large number of runtimes. A key component of remote management is the software repository. It is nice to have a framework that resolves bundles, but where do those bundles come from? Richard S. Hall will give a presentation about the OSGi Bundle Repository under the intriguing title: "The Bundle Dilemma."
And of course we have lots of sessions for the people that are busy with the technology itself. First we will give an overview of the state of the OSGi specifications. The chairs of the expert groups will present their progress: BJ Hargrave (IBM), Kai Hackbarth (Prosyst), and Eric Newcomer (IONA). There is lots of progress in the Enterprise group and the Requirements group at the moment. If you plan to use OSGi technology in the future, you better be there.
We have some very interesting lightning talks for OSGi developers. BJ Hargrave will elucidate the changes for v4.1. Maven, the Apache build tool, has been extended with OSGi support. Stuart McCulloch (Jayway Malaysia), will show how these tools can be used to create OSGi bundles. Ales Justin (JBoss) will tell about the work that JBoss is doing adapting their microkernel to support OSGi.
Services, extensions? Neil Bartlett, famous from the popular beginner tutorials. will give a talk comparing the Eclipse Extension Registry (which is a service!) with the OSGi Service Registry. These two concepts are quite close and still wildly different. Puzzled? Neil will make it crystal clear. And if you have decided for services, then you should not miss the talk of Clément Escoffier about iPOJO. He worked with Richard Hall to develop a next generation component model for OSGi. This project can be seen as the successor of Service Binder that was the basis for OSGi Declarative Services. Obviously, if you program for OSGi Technology you should not miss the OSGi best practices talk that BJ Hargrave and I are giving!
The day after the community event, Thursday the 28th, we will have EG meetings. The Enterprise Expert Group meeting will be for members only but there will also be a Remote Management and Automotive requirements gathering meeting presided by Kai Hackbarth. These two meetings are also open for non-members.
Really, if you are involved with OSGi technology you have very little excuse to not show up. There will be plenty of time to talk to the speakers and other participants. I really hope I will meet you there! If you register before the 12th, you still get the early bird discount.
Peter Kriens
Friday, June 8, 2007
Monday, June 4, 2007
OSGi and Hibernate
A long time Dutch friend of mine, Petr van Blokland and me are working on a yet another web framework. I will not go into the reasons for YAWFW, except that his background is graphic design which means aesthetics play a large role in this framework. However, this focus does not exclude us from having to handle mundane details like web requests, models, views, and databases. I am participating because it is a good way to get some enterprise systems experience. Obviously the whole infrastructure is based around OSGi.To get the picture, a short sketch of the architecture. Incoming requests are dispatched to a servlet by the HOST header to a service. This makes it possible to handle multiple sites in the same OSGi framework. We call this servlet the site servlet.The servlet we dispatch to can be anything, but so far we are using a hand made servlet that uses Groovy classes as pages. The first part of the path is the class name, the second part is the method name and the remainder are parameters. That is, a request like http://www.acme.com/home/index is a call to the class index() method in the home class.
The Groovy class is a normal class that does not have to extend or implement anything. When we create it, we assign it a special meta class which we call the Builder. It is a bit different from a Groovy builder, but tries to achieve the same goal: merge code and html. The Builder is setup by the site servlet. Each site can have its own specialized builder. The builder can provide methods to the page class, this makes it easy to provide high level tags to the page. For example, you can make your own tag for a navigation bar.
Builders in Groovy are a marvelous concept, they merge the power of a full blown language with the power of declarative programming à la HTML. The achieve this goals using closures. Closures are blocks of code that have access to their surrounding context but that can be manipulated as objects.
def x = { print "hello $it" }
x() // Call the block
As a Smalltalker, the absence of closures in Java is one of the most painful experiences in my professional life. Anyway, closures allow you to parametrize functions. In Groovy, closures allow you to write code like:
def index() {
def title = "Hello World"
html {
head {
title { title }
}
body {
h1 { title }
}
}
}
This is actually quite an interesting approach but it is not the purpose of this blog. We also needed a database for our web framework ... Groovy provides some very interesting SQL capabilities and I was really tempted. However, Groovy uses some weird trick to recompile the source code in runtime to prevent one from having to write SQL statements (see
findAll). A lofty goal, but in this case not worth the expense. The code generated weird errors when the source code was not available in run time. So the only alternative seemed to be Hibernate.
Hibernate is an Object Relational Mapper (ORM). It allows you to write simple Java objects that are persisted in a database. The objects are free of any markup, required super classes or implemented interfaces. All the mapping information is detailed in xml files that are adjacent to the class files. That is, when hibernate must map a class to a relational database, it uses the class name to create a resource path and loads that resource path as its mapping file. However, such a mapping file must be read before the database connection is created.
Hibernate manipulates the classpath, and programs like that usually do not work well together with OSGi based systems. The reason is that in many systems the class visibility between modules is more or less unrestricted. In OSGi frameworks, the classpath is well defined and restricted. This gives us a lot of good features but it also gives us pain when we want to use a library that has aspirations to become a classloader when it grows up.
We needed a database so in the past few weeks I created a bundle that mediates between bundles with domain objects, connections to the database, and bundles that want to use a database. It was actually quite tricky to get it all to work and I am not sure I found the best solution. Lets take a look what I did and let me know what you think.
To work with Hibernate, you need a Session object. You can get a Session object from a SessionFactory. To get the the SessionFactory, you need to create it with a Configuration object. The Configuration object is created from a configuration XML file. By default, Hibernate loads this from the root of your JAR file, however, you can add classes manually to the configuration if so desired.
This gave us a problem. We had several bundles that needed to use the database but could not a priori decide which bundles would be available at any given moment. They could all have used their own Hibernate Session Factory but that would significantly complicate the configuration management and it would cost performance.
This looked like a clear extender problem. Bundles should be able to declare the classes they contribute to a Hibernate session.
For this model I architected the following manifest header:
Hibernate-Contribution ::= default; \
classes="xierpa.impl.pw.User,xierpa.impl.pw.Role"
The name field in the header (default) is the name of the database contribution. The classes attribute contains a comma separated list of classes. These classes are loaded from the bundle and added to the configuration that uses this contribution. Simple. Any bundle can now provide domain classes to Hibernate by just declaring this header.
However, where does the Session Factory Configuration come from? I decided to use Configuration Admin for this purpose. For each configuration, one can create a factory configuration. The properties for this configuration describe the connection parameters. The configuration was so large, that I had to extend FileInstall to not only install bundles but also handle configuration files. The normal interaction with the command line was too basic.
So, the Hibernate extender receives the configurations and tracks started bundles. With this information it matches up the contributions from any bundles to configurations for Session Factories.
The bundle that wants to get a Hibernate SessionFactory object just gets the HibernateDomain service and requests a session any time it needs a database transaction. This session comes from a factory that is automatically refreshed whenever one of the contribution changes or the configuration parameters changes.
Overall this model turns out to work very well. It is easy for bundles to provide contributions and it is easy for bundles to use a fresh Hibernate Session, without having to track the configuration and contributions.
I of course also had to run into one nasty class loader problem. Hibernate created a proxy using classes from the Hibernate bundle. Unfortunately, it asked the class loader of the domain objects for this Hibernate specific class. "Oh, what tangled webs we weave when first practice to classload ..."
Obviously I always use bnd and bnd only inserts Import-Package statements for the packages that the code really uses. One of the great advantages of Hibernate is that it allows you to use objects not coupled to Hibernate at all. Obviously, bnd can therefore not insert any references.
The short term solution to this problem was Require-Bundle, which is of course not a good solution as readers of this blog can testify. It solves the problem in this case but it creates many other problems in the long run. In the next release of the OSGi specification we must find a solution to this problem. It must be possible to create uncluttered bundles that only import what they need but can still load classes that other bundles make them require. This problem has already been raised in CPEG and it has high attention because the same patterns appears for other libraries as well.
I am very interested in how other people solve the problem of using libraries like Hibernate in an OSGi Service Platform. Please provide feedback.
Peter Kriens