FuseByExample

A few weeks ago, our first Red Hat JBoss Fuse release was completed. As with previous releases, this comes with a few examples that show you how to build e.g. a content-based routers or a JAX-RS web service. These examples are all very simple and focused on single technology.

In real life however, things often get quite a bit more complicated than what these examples are showing you. Based on their experience with customers, people like Charles Mouillard, Scott Cranton, Jakub Korab and Scott England-Sullivan have been creating a set of more elaborate example projects on GitHub.

FuseByExample is the name of the GitHub organisation where all these projects live. If you go there, you'll find a dozen examples that show you how to implement things like transactions using Aries' JTA support,using JPA for database access, using web sockets to build more dynamic web front-ends, ...

All of these examples have been updated to work with the new Red Hat JBoss Fuse 6.0 release so if you're taking a look at this new release, be sure to check out the stuff in FuseByExample as well to get a better idea of what is possible with this technology. And also, these are GitHub projects so feel free to create pull requests for improvements, bug fixes, ... We love contributions ;)

Apache ServiceMix 4.4.0

After a few weeks of testing builds, ironing out the final issues, doing the release builds and running the actual release votes, I'm very glad to be able to send the announcement mails for two new Apache ServiceMix releases to our mailing lists today.

Highlights in the new Apache ServiceMix 4.4.0 release include:

• new packaging options (cfr. my previous blog post)
• upgrade to Apache ActiveMQ 5.5.1
• upgrade to Apache Camel 2.8.3
• upgrade to Apache CXF 2.4.4
• upgrade to Apache Karaf 2.2.4

As part of this release cycle, we also did a new Apache ServiceMix 3.4.0 release, which delivers the same dependency upgrades to our existing 3.x user base

Together with this release, we also switched to using Scalate for the main website as well as the documentation pages. With these new pages, we aim to make it easier for people to get started with Apache ServiceMix and all the other projects we embed.

New packaging options for ServiceMix

A while ago, Ioannis Canellos added a few new packaging options to the upcoming Apache ServiceMix 4.4.0 release to better reflect these recommendations. Our upcoming Apache ServiceMix 4.4.0 release will have 4 different assembly types ...

Our default assembly (called apache-servicemix) no longer has the NMR or the JBI support preinstalled. You can still install those as optional features, but the focus is on ActiveMQ, Camel and CXF instead. This is the set of technologies we recommend new users to start with, so it makes sense to have our default assembly reflect these recommendations.

With this default assembly, installing the optional features will download the additional bundles required for that feature. If you're running Apache ServiceMix on a server that does not have direct access to the internet, this is not very convenient. That's why we also have a full distribution now (called apache-servicemix-full) that has all the bundles sitting ready in the system folder for quick and offline installation.

If you're an existing NMR or JBI user, the apache-servicemix-jbi distribution builds on top of the default assembly and adds JBI and NMR support. It also comes with all the existing JBI components from earlier versions of Apache ServiceMix.

And finally, the apache-servicemix-minimal contains all the configuration and features definitions that come with Apache ServiceMix, but with none of the features preinstalled. This allows you to install just those features that your project requires.

P.S. We now have all the dependencies for Apache ServiceMix 4.4.0 available and are just fixing a few last things so expect one of my next blog posts to be about this new release

It's been a while...

It's been quite a while since I have been blogging and, now that the school year is well underway and things are getting a bit more quiet around the house, I intend to start posting a bit more regularly again. Just some random picks out of what I have been doing the past year instead of blogging...

• In January, I was really honored by the invitation to become an Apache Software Foundation Member.


• In March, there was a talk about Scalate for BeJUG. We also released Apache ServiceMix 4.3.0 that month.


• Over the summer, we did some redecorating in the house - what was supposed to be a simple change to the electrical wiring, quickly ended up being almost two weeks of hacking walls, adding and removing outlets, plastering, painting, …


• A few weeks ago, we went on a weekend vacation with the kids at the seaside and it just happened to be the warmest October weekend in decades

At the FuseSource side, we did several FUSE ESB releases this year (starting with FUSE ESB 4.3.1-fuse and just did FUSE ESB 4.4.1-fuse a few weeks ago) so I spent quite a bit of time doing release work and even now I'm again working on getting the Apache codebase ready for an Apache ServiceMix 4.4.0 release. Anyway, I'm hoping to be able to tell you a bit more about that in one of the next blog posts.

Traits in the Camel Scala DSL

When using the Java DSL for Camel, you can create a custom RouteBuilder class which defines common elements for all your routes (e.g. standardized error handling). Since you're only able to inherit from a single class, great care must be taken in which common route elements are being added to the parent class.

The Scala DSL allows you to extract those common route elements into traits, which can be mixed into the RouteBuilder in more flexible ways. Consider the scenario where we have two ways we do our error handling: we either want to write a message to the error log or we want to send the message into an error queue.

We can model this by writing two Scala traits, defining the org.apache.camel.scala.dsl.RouteBuilder class as the trait's self type:

trait ErrorQueue { self: RouteBuilder =>
  handle[Exception] {
    log("Sending ${id} to error queue")
    to("seda:errors")
  }
}

and

trait ErrorLog { self: RouteBuilder =>

  handle[Exception] {
    log("Sending ${id} to error log")
    to("log:errors")
  }

}

Afterwards, we can just add the implementation we want in our own RouteBuilder using a simple with clause.

class MyRouteBuilder extends RouteBuilder
                     with ErrorLog {

  //rest of the route goes here

}

Just replace the with ErrorLog by with ErrorQueue to pick another error handler implementation. And because you can add multiple traits to the same class, this approach allows you to define lots of common route elements and just mix and match those that you need.

Happy Camel riding with the Scala DSL!!

Camel async routing in ServiceMix

Until recently, servicemix-camel did not allow asynchronous interaction with the NMR. Every MessageExchange was being sent using sendSync(), causing the calling thread to wait for the MessageExchange to finish.

Let's take a look at this set of Camel routes:

from("jbi:endpoint:urn:test:service:endpoint1")
.to(""jbi:endpoint:urn:test:service:endpoint2");
from("jbi:endpoint:urn:test:service:endpoint2")
.to(""jbi:endpoint:urn:test:service:endpoint3");
from("jbi:endpoint:urn:test:service:endpoint3")
.to(""jbi:endpoint:urn:test:another_service:endpoint");


When sending an exchange to endpoint 1, the diagram below shows how this invocation will cause three threads to be waiting until the entire flow ends.


For the upcoming Camel 2.4.0 release, Claus Ibsen has been working hard to add fully async routing to Camel again. The servicemix-camel and camel-nmr components have already been upgraded to leverage his hard work, because this improvement completely changes the picture for JBI and NMR integration.

As you can see below, the threads are now no longer waiting, but are available to pick up new work while the initial flow of MessageExchanges is still ongoing.


If you're using Camel inside ServiceMix, make sure you pick up the next version of Apache ServiceMix or FUSE ESB to benefit from these scalability improvements.

When JBI meets OSGi, part 1

In ServiceMix 4.2.0, you'll be able to deploy your existing JBI artifacts alongside OSGi bundles.

In a mixed environment like that, you might run into the situation where you want to access a class defined in an OSGi bundle from within your existing JBI SU. To allow you to that without having to add the JAR to your SU (effectively adding a second definition of the same class to the container), you can now reference an OSGi bundle as a shared library directly from your SU xbean.xml file using osgi:<bundle symbolic name>.

An example: you have a nice Camel InterceptStrategy implementation in an OSGi bundle and you're using that in a lot of your OSGi based Camel routes. You can now reuse the same code in a JBI SU for servicemix-camel by adding this snippet to your xbean.xml or camelContext.xml


  <classpath>
    <library>osgi:my.intercept.bundle.symbolic.name</library>
  </classpath>