Tuesday, October 11, 2011

WS-Notification implementation

Since the early days, Apache ServiceMix has had an implementation of the Oasis WS-Notification specifications. This implementation was built on top of Apache ActiveMQ and available inside the JBI bus as a service. Now that JBI is being put aside in ServiceMix, some questions arose about the future of this component.

So last week, I took a stab at rewriting the component using pure JAX-WS services. For those that are not familiar with WS-Notification, this specification, unlike most other WS-* specifications defines a service described by a WSDL, so there's no low level protocol implementation to write. I took most of the code from ServiceMix implementation and just rewrote the JBI specific bits to leverage JAX-WS instead.

The results have been committed into Apache CXF and should be part of the upcoming 2.5 release. Note that the implementation itself does not require CXF, though it can very well use it as the JAXWS provider.

If you want to give it a try, you need to build CXF trunk locally and then run the following commands in Karaf:
karaf> features:addurl mvn:org.apache.cxf.karaf/apache-cxf/2.5.0-SNAPSHOT/xml/features
karaf> features:install wsn 


To check that the WS-Notification broker is correctly started, you can try the following command:
karaf> cat http://0.0.0.0:8182/wsn/NotificationBroker?wsdl
...


The services are also exposed as OSGi services, so that they can be directly accessed if needed. If you use the awesome Fabric DOSGi implementation, it can be very interesting.

Some areas could still be enhanced, as the codebase is mostly the same as the old ServiceMix component. I'm thinking to complex topic expressions or persistence of subscriptions. If you have any real need for something, send an email to the CXF mailing lists ...

Thursday, June 16, 2011

Distributed OSGi in Fabric

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), the Fabric DOSGi implementation will check if there is a local service satisfying the listener and if there’s none, it will look into the ZooKeeper registry and import a matching service.

The Fabric implementation is based on the insanely fast HawtDispatch library which has a very nice support for NIO. The result is a very fast remoting mechanism for OSGi with more than 25.000 requests per second on my laptop. This remoting mechanism is actually not dependant on OSGi and external clients can also connect to a remote OSGi service provided they can find the service identifier from ZooKeeper or some other place.

A complete example can be found in the Fabric source tree at on github.

Tuesday, June 14, 2011

Provisionning with Fabric

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 pointing to the osgi framework to use
  • system properties
  • osgi framework properties

An example of defining such profiles can be found in the fabric example.

The agent will use those informations and delegate to an internal OSGi resolver to compute the actual list of bundles to deploy. It will then compare this list to the list of bundles already installed and resolve the differences by installing / updating / uninstalling bundles. The agent is able to upgrade all bundles, including core Karaf bundles and even the OSGi framework itself and framework properties.

The profile notion I explained in my previous blog entry allow the use of profiles for provisioning and configuration. For example, a profile can be defined for deploying ActiveM or Camel. And remember one can override profiles, so you can define a profile for your application and change the IP of the ActiveMQ broker in overridden profiles based on the geographic location to connect to the nearest broker.

Due to the configuration bridge between the OSGi Configuration Admin and ZooKeeper, any change made into the zookeeper tree will be reflected to the provisionning agent and the bundles updated immediately. This may or may not be a desired behavior and that's one of the reason why the ZooKeeper tree used by Fabric has a notion of versions. But that'll be explained in a follow up entry.

Saturday, May 07, 2011

Configuration with FuseSource Fabric

From a high level, ZooKeeper can be seen as a replicated tree, and Fabric uses this tree to store the configuration of the various agents (we call Agent, any Karaf instance connected to the same Fabric cluster).

Fabric defines a notion of profile, which is a "kind" of agent. We can define different profiles for various applications we want to deploy in Karaf, for example an ActiveMQ broker or a web server. A given agent can be assigned multiple profiles, allowing a single Karaf instance to serve multiple purposes.

To configure a Karaf instance, Fabric uses the ConfigAdmin OSGi service which is the standard way to push configurations to OSGi applications. An agent will have a bundle deployed which will monitor the ZooKeeper tree and update the configurations according to the profiles it has been assigned. Each bundle will then automatically be notified of the changes through the ConfigAdmin service.

It is often the case that configurations are mostly the same between several nodes, but to one or two parameters that may change. In order to increase sharing between profiles, profiles can inherit other profiles. The actual configurations are computed using an overlay mechanism so that the parent's configurations are overriden by the children ones.

The zookeeper layout for the configurations is setup using the following nodes in the zookeeper tree:
/fabric/configs/agents/{agent}
/fabric/configs/versions/{version}/agents/{agent}
/fabric/configs/versions/{version}/profiles/{profile}


The first node contains the {version} used for a given agent. I'll explain more about versions in a later post. Once we have the version, we can go the the second node which will give the list of profiles assigned to that node. The computation is done by going to the list of parents and retrieving the configurations maps which are organized as following:
 /.../{profile}/{pid}/{key}

A profile can contain any number of such nodes, which gives a map (indexed by the {pid}) of maps (indexed by the {key}) and which values are the content of the node. A special value #deleted# can be used to flag a {pid} or {key} as deleted so that it won't appear in the overlaid configuration. The {pid} will be used as the OSGi configuration pid and the contents will be the various {key}s defined. Note that a {pid}containing a dash will be identified as a factory pid.

After creating creating the ZooKeeper server in Fabric using the fabric:zk-cluster root command, you can experiment with the zookeeper commands and see the changes reflected on agents.

Provisioning is done through this very mechanism. My next post will explain in details how this is done. Stay tuned!

Wednesday, May 04, 2011

Introducing FuseSource Fabric

I'm very pleased to introduce FuseSource Fabric, a distributed configuration, management and provisioning system for the products supported by FuseSource: Apache ServiceMix, Apache Camel, Apache ActiveMQ and Apache CXF.

The user's guide contains lots of informations, so I won't rewrite it all again, but I instead invite you to have a quick look at it. The core Fabric is deployed on top of Apache Karaf and heavily reuses the very mature Apache ZooKeeper project.

I'm really excited about Fabric. I've been working on it since Apache Karaf 2.2.0 has been released and I'm glad to share this work. I won't add much more for now, but stay tuned as I plan to write a number of posts explaining the various parts of Fabric.

Tuesday, May 03, 2011

CamelOne conference


I just want to point out the great conference FuseSource is sponsoring around open source integration and especially Apache Camel. Unfortunately, I won't be able to attend the event as my wife is expecting our sixth child in the coming weeks :-). That would have been a great opportunity to have my copy of the EIP book signed by Gregor though.

You should definitely go there and listen to all the great speakers. Click on the image below for more informations.


CamelOne