FuseSource acquired by RedHat

Yesterday, an important announcement was made: RedHat is acquiring FuseSource.  This news is following Progress announce a few weeks ago about FuseSource being divested as not being part of their new product strategy.

This is truly exciting. RedHat looks like a fantastic company, pure Open Source players as we are too.  We will be integrated into the JBoss Enterprise Middleware Group and even if there is some overlap on the products, I don't have any doubts that we'll be able to find the best way to leverage our respective strengths to build new awesome products for our users and customers.

This is definitely a good fit for both RedHat and FuseSource, and I'm definitely thrilled about it.

Camel Webinar

Je présente la semaine prochaine un webinar sur Camel en français intitulé "Introduction à Apache Camel".
Inscrivez-vous !

JLine 2.6

I've released JLine 2.6 which should be available in central soon. The main change is that JLine is almost completely conform ant with GNU readline. This means that JLine will read the ~/.inputrc by default and now supports VI editing mode, macro recording and all the goodness you can find in your standard unix shell.
It will be used in Karaf 3.0 and in the next Fuse ESB.

Unit testing Camel Blueprint routes

Last week, while in Vegas, I discussed with my colleague Scott Cranton and he told me that something that was really making our users tend to stick with Spring-DM when using Camel Blueprint routes was that unit testing those routes was not possible.

So I hacked a small support library for Camel, leveraging PojoSR which provides a service registry without using a fully compliant OSGi container. This allows defining real unit tests (as opposed to integration tests using Pax Exam.

See the below example.

public class DebugBlueprintTest extends CamelBlueprintTestSupport {

    @Override
    protected Collection<URL> getBlueprintDescriptors() {
        return Collections.singleton(getClass().getResource("camelContext.xml"));
    }

    @Test
    public void testRoute() throws Exception {
        // set mock expectations
        getMockEndpoint("mock:a").expectedMessageCount(1);

        // send a message
        template.sendBody("direct:start", "World");

        // assert mocks
        assertMockEndpointsSatisfied();
    }

}

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

 <camelcontext autostartup="true" id="camelContext" trace="true" xmlns="http://camel.apache.org/schema/blueprint">

  <route>
   <from uri="direct:start"/>
   <transform>
    <simple>Hello ${body}</simple>
   </transform>
   <to uri="mock:a"/>
  </route>
 </camelcontext>

</blueprint>

Back from Las Vegas

I'm back from Las Vegas where we had a fantastic FuseSource KickOff meeting.

As you can see below, a real camel had been brought from the west coast and James even had a short ride on it! On the technical side, we expect a bunch of exciting stuff this year, so you'll certainly hear from us soon.

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 ...

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.