Wednesday Mar 25, 2009
First day at ApacheCon Europe 2009
From the 7 talks I attended today, I'll discuss two in some more detail. Some of the other presentations were either too advanced for me (I discovered only halfway during the conference that on the schedule all talks were provided with tokens indicating the required experience), or consisted of a series of case studies, that are both impossible and useless to summarize in a weblog.
Embracing change - embracing OSGi
The OSGi presentation was a good and very crowded quickstart on OSGi. In fact, so many people attended, that this track got a bigger room after the presentation: many people were forced to either get extra chairs or stand during the whole session.
The presentation was very inspiring and informative at the same time. I heard many things on OSGi before, but this time I got the picture, or at least I think I did
Bundles are created using Eclipse or ... good old Maven! During this talk it became clear that Maven is not replaced nor made redundant by OSGi, but that it may very well be used to create bundles (luckily I forgot who told me that Maven would become obsolete!). The Maven bundle plug-in provides a bundle with the correct meta data based on information in the POM file. This typically includes you exports, private packages and embedded libraries, if any. Bundles can be started, updated and removed dynamically within one and the same VM.
Although it is possible to use modules without a registry, OSGi also introduces a service registry which offers the obligatory publish/find/bind functionality. This quickly leads to applications based on a so-called service oriented component model, a typical application then consisting of bundles that interact via interfaces. Key in OSGi is that services can easily be started, removed and updated. Even multiple versions of the same service running simultaneously works fine. Stated differently, an OSGi application may be considered as a dynamic version of a Spring application, where all dependencies can be (re)wired at run-time.
Bearing in mind that OSGI is a merely specification, various implementations exist, such as Eclipse's Equinox and Knoplerfish. Apache Felix is the reference implementation of OSGi R4.1, which includes the aforementioned Maven plug-ins (maven-bundle-plugin and maven-scr-plugin), a web console and iPojo. Of course, since we happened to be at an Apache conference, some advertisment and arguments in favour of Felix were inevitable.
Carsten's talk also comprised a few best practices and recommendations, such as
Concluding, I was very happy to hear that Maven was complementary to OSGi and I realized that the crawler program of www.contract-crawler.nl could immediately benefit from such an approach by transforming the SAX handlers for the various sites that are being visited to OSGi modules, thereby easing the process of updating/replacing/adding an additional site with contract data. Last but not least, OSGi concepts promote good design practice.
Content storage with Jackrabbit
The company Hyppo was very well represented at the ApacheCon. Apparently their business model of delivering support on their own open source CMS (content management system) based on Apache Jackrabbit is quite profitable. Since I was curious what the content store Jackrabbit was all about, I decided to attend the introductory level presentation
For the implementation of applications that are rich in content, such as weblogs, wikis, image galleries and discussion fora, one is typically looking for an optimal mix of features traditionally offered by a database (queries, transaction) and a (hierarchical) file system. A content store unites those features. Version 1.0 of the JCR (Java Content Repository) API was specified by the Java Specification Request 170 (JSR 170) and work on the JCR version 2.0 has begun in JSR 283. Apache Jackrabbit is the reference implementation of these specifications.
In a content repository, everything is represented by a document, consisting of one or generally more nodes. Each node has a name, which is namespaced. Referenceable nodes have UUIDs, so they can uniquely be referenced. Each node inherits from zero ore more node types, which define the (data) structure of the node. The case of zero is especially interesting here, and is generally referred to as unstructured node. In such a node, basically anything can be stored, and allows for a maximum flexibility during the development phase of your application. Only when your application has matured, it may be handy to standardize and enforce a data structure on your nodes.This is best summarized by the slogan "data first, structure later, maybe".
Features of Jackrabbit include:
When configuring Jackrabbit, the persistence manager is one of the first things to consider. The persistency manager is an internal Jackrabbit component that handles the persistent storage of content nodes and properties. Various persistence managers and combinations are possible, as can be read here.
Jackrabbit is very lean and fast, and can also be run in-core, which comes in very handy during development.
Finally, the presentation underscored some guidelines and best practices that contribute to a sound a proper way to do your content modelling. Workspaces apparently play an important role here, but the introduction escaped me during the presentation.
OSGi as Framework for Building a Product Line: Experience and Best Practices
According to the speakers from WSO2, traditional SOA platforms suffer from quite some drawbacks, such as being overly complex, heavyweight, hard to learn and not internally consistent. This often leads to a centralized monolithic ESB and SOA platform, where considerable time is spent in integrating vendor's products instead of integration of real applicaitons. The solution they presented is a componentized SOA platform based on OSGi.
First the choice for OSGi as an in-VM collaborative SOA model was motivated:
Schematic representation of OSGi, taken from the slides.
At the base one finds the core Carbon framework, based on the (Equinox) OSGi kernel enhanced with some standaard extensions such as dedicated bundles for Spring support, clustering, security, transports, administration, provisioning, deployment and logging.
The ESB can then be constructed and extended in a flexibel and dynamic way by adding additional hexagons to this core as needed. As use case was taken a database administrator who uses the WSO2 dat services to expose his data as secure web service across the enterprise. By adding the mediation component and using XSLT, for example, he can now easily convert this corporate schema to any existing (legacy) service interface.
They also reported some challenges that they face during the development of their solution, such as the tuning of OSGi to fit into the server runtime and the transformation of existing code into OSGi bundles: legacy JARs use class loaders heavily, hence are most likely to fail in an OSGi environment.
This led to a very interesting slide with a recipe for transforming legacy JARs to bundles in an OSGi environment: