Guillaume Nodet's blog

The Remote Services OSGi specification describes how services registered in an OSGi framework can be transparently accessed from another OSGi framework. This is in essence a remoting capability for OSGi services. Fabric has a very fast implementation of this specification, leveraging ZooKeeper for the discovery of services. From the user point of view, registering a service with a property service.exported.interfaces (with a value of ‘*’ or a list of classes to expose) is the only thing to do to make a service available from the outside. The Fabric DOSGi implementation will automatically detect which services have to be imported and will automatically create a proxy in the OSGi registry for those needed. This services to be imported are found through the use of Service Hooks which enable the implementation to be aware of which services are required by existing bundles. For example, if a bundle registers a ServiceListener (directly or indirectly by using Blueprint for example)...

Already, one month since my last blog entry, but time as been flying with the birth of my son Arthur a few weeks ago. I'd like to talk about the provisioning mechanism of Fabric a bit. In my last post, I explained how configuration was done through the use of ZooKeeper as the repository for configurations and profiles, propagated to various bundles using the OSGi ConfigurationAdmin service. The provisioning mechanism in Fabric is based on this mechanism: the fabric-agent bundle receives its configuration through the org.fusesource.fabric.agent pid and will automatically update bundles as needed. The nice thing is that the configurations are computed using an overlay mechanism which means that the list of bundles or features to deploy will come from the various profiles a give node has been assigned. The agent itself supports several kinds of informations: bundles that need to be installed karaf features that need to be installed repositories for karaf features a url poi...