Technology weblog

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 ;)
Carsten started his talk by motivating OSGi, which was best summarized by the slogan "embrace change - embrace OSGi". By packaging everything as a module, called bundle in OSGi speak, where only the classes to be exposed are made visible, and assigning each module its own class loader, many shortcomings of traditional Java are elegantly circumvented or resolved. The bundle is realized as the well known jar file, accompanied with some additional meta data (in the META-INF directory), such as the bundle ID, version, imports and exports (i.e. Java packages).

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

  • Try to centralize interaction with the OSGi API so that other components remain POJOs
  • Think about dynamics: late binding and loose coupling
  • Think about modularity. Unfortunately, there is no one size fits all strategy that successfully applies to the following decisions that OSGi forces you to think of
    • creation of clean packages,
    • the granularity of your bundles and
    • the separation between API and implementation bundles
    However, separating out stable code versus changing code and identification of the optional bundles and services are a useful start.
  • Check out the spec and other projects
  • Use your preferred logging library (the LogManager takes care of the rest)
  • Use the available tooling

Concluding, I was very happy to hear that Maven was complementary to OSGi and I realized that the crawler program of 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:

  • Read/write
  • Search with XPath and SQL. Note that you are dealing with a subset of these languages here, e.g. you can access all properties of the node you are querying, but you cannot access the child nodes.
  • XML import/export (in JCR specific XML format or document view format)
  • Observations, comparable to triggers in a relational database, but are asynchronous
  • Versioning (store snapshots elsewhere)
  • Node types (see above)
  • Locking
  • Access control (i.e. authentication)
  • Atomic and XA changes

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.

Summarizing, I think this was a very nice a good introduction into Java content repositories in general and Apache Jackrabbit in particular.

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.
  • Each bundle can provide services to other bundles
  • Services are simply Java objects that implement a given interface
  • Ther is a service registry wher you can find a serice implementation
  • Services should be only links between components
  • OSGi is the best known way to decouple components from each other
  • The OSGi component model is a dynamic model
  • Bundles can be installed, started, stopped, updated and uninstalled without shutting down the whole system.
Thereafter their solution WSO2 Carbon was introduced, a framework based on OSGi with Equinox as implementation. WSO2 Carbon is a well-defined component model for Enterprise middleware, closely based on Apache technologies such as Apache Axis 2, Apache Synapse, Apache ODE, Apache Tomcat and Apache Axiom.

WSO2 Carbon
WSO2 Carbon

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:

  1. First create a big OSGi bundle including all your project code and dependent JARs
  2. Use a BundleActivator to call the main class
  3. Get your project working
  4. Gradually break down the big bundle into manageable bundles
    • Remove all the dependent JARs and use their OSGified versions
    • If possible, break down your project into reusable components (bundles)
  5. Be prepared for many issues along the way, but solve themand make sure the software keeps working.
  6. Use the Maven bundle plugin to create the bundles.
  7. Import all the packages your bundle needs
  8. Use versioning when importing packages
    • This avoids version conflicts
    • Use fixes versions as opposed to version ranges
  9. Use Import-Package instead of Require-Bundle
    • Import-Package can have many providers
    • Require-Bundle can only have a single provider
  10. Avoid using Class.forName
    • A lot of ClassNotFoundExceptions
    • Use OSGi services to handle these dynamic collaborations between bundles
    • As a workaround for Class.forName, use DynamicImport-Package, although this is not the recommended approach
  11. Avoid ordering dependencies
    • Starting order of bundles may differ from framework to framework
    • Use ServiceTracker utility or declarative services


Post a Comment:
Comments are closed for this entry.

Hire us