Thursday, December 06, 2007

ServiceMix / Fuse ESB press release

A press release has been published recently on the use of Fuse ESB for the Belgium Government. For french speaking people, you may find lots of informations on the project by browsing Lilian DuchĂȘne's blog.
Together with Anne Noseda, we have presented this projet at the BeJUG SOA conference. You can view the slides or download them.

Tuesday, September 25, 2007

Apache ServiceMix 3.1.2

Apache ServiceMix 3.1.2 has been released. Release notes are available here.

This is our first official release since graduation: this means that the artifacts are available from the public repositories now (see

Wednesday, September 19, 2007

ServiceMix has graduated

I'm really pleased to announce that the ASF Board has approved Apache ServiceMix graduation :-) This means that ServiceMix now becomes a full Apache Top Level Project. So we will soon make our first official release of ServiceMix 3.1.2 and 3.2 coming later. This also means that the resource will be moved to their final location: the website will be moved to and the svn repo to

In addition, I'm honored to have been voted as the Apache ServiceMix PMC Chair. The PMC (Project Management Commitee) is the group of people responsible for the project oversight, and its Chair is the interface between the Board and the project.

I just want to remind people the purpose of the Apache Incubator: its main responsibility is to watch new projects at the ASF to make sure that no IP problems remains and that there is a vibrant, diverse and sustainable community around the project that goes the "Apache Way". This is in no case about the quality or maturity of the software itself, as incubating projects greatly vary in these areas (from brand new projects to very mature projects joining the ASF).

Thursday, August 30, 2007


My company IONA provides support on Apache ServiceMix via a distribution called FUSE ESB available from the Open Source IONA site.

What's in FUSE ESB right now? Well, it's roughly a distribution of ServiceMix trunk. This implies that FUSE ESB is released ahead of the Apache ServiceMix distribution (the latest release is 3.1.1, whereas FUSE ESB is based on 3.2).

Why are you using the latest trunk instead of the most stable branch? Well, mostly because our customers needs some of the latest features available. We take great care of what is in our Fuse branch: we do not necessarily backport all new stuff from trunk. We may also add some specific customer needs inside our own distribution, features that are not present in the trunk version.

So is that a fork? Certainly not :-) We have always supported Apache ServiceMix and we will continue to do so. But our customers have specific needs, so we may need to do custom development or have custom branches for them to fullfill these needs. Over time, we put the features that we consider generic enough back to the community. But this level of support can not be provided in a community driven environment such as the Apache Software Foundation. Let alone the fact that our customers often require privacy regarding their issues or their specific needs, environments and projects, so that it becomes difficult to use the open mailing lists of the community.

So is that a closed source version? No. The Apache License would allow that (quite the opposite of the GPL), but this is not what we aim for. Our process is quite open: as an example, I've recently developed an AsyncBridge EIP pattern for FUSE ESB (see the issue) that will certainly be contributed back to the community...

Hopefully, this blog entry will clarify a bit the IONA policy with respect to the Apache projects it supports and the relationship between FUSE ESB and ServiceMix. Feel free to download it and give it a try...

Monday, August 13, 2007

Switching to Mac

My ThinkPad has some serious cooling problems (it keeps shutting down when I really use it, which is kinda annoying, because this is when you really use it that you want it up and running of course) so I decided to go for a MacBook Pro. Why? Well, I'm a long time users of Windows, but for developing, I usually use cygwin for command line and all the unix good stuff. Additionally, all my team mates are Mac users, so I was quite sure I would not loose much. Now, I must admit I don't regret. Thanks to James for having pointed a few useful softwares...

Wednesday, July 04, 2007

ServiceMix 3.1.1 released

Apache ServiceMix 3.1.1 release is finally out! This release is a bug fix version with a few minor improvements.

Thursday, June 28, 2007

Accessing databases in servicemix-drools

ServiceMix provides a Service Engine for Drools, the famous Rules Engine.

People often want to retrieve data from the rules and such data is usually stored in a database. Previously there was no easy way to configure a DataSource and inject it in the rules definitions. This is a small enhancement that I've just written and that will be included in next major release.

So let's say you write your database access code in a simple helper object:
import javax.sql.DataSource;
import org.springframework.jdbc.core.JdbcTemplate;

public class DbHelper {
private DataSource dataSource;
private JdbcTemplate jdbcTemplate;

public void setDataSource(DataSource dataSource) {
this.dataSource = dataSource;
this.jdbcTemplate = new JdbcTemplate(dataSource);

public String getSurname(String name) {
String surname = (String) this.jdbcTemplate
"select surname from t_actor where name = ?",
new Object[]{name}, String.class);

Now, let's use it in our rule definition:
import org.apache.servicemix.drools.model.Exchange;
global org.apache.servicemix.drools.model.JbiHelper jbi;
global DbHelper helper;

rule Init
$me : Exchange()
String t = $me.getIn().getContent().getTextContent();
+ helper.getSurname(t)
+ "</surname>");

And the xbean.xml would look like:
<drools:endpoint  service="test:service"
globals="#globals" />
<util:map id="globals">
<entry key="helper" value-ref="helper" />
<bean id="helper" class="DbHelper">
<property name="dataSource">
<bean class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:myDataBase" />

This will make available the helper bean to the rules while initializing it with a DataSource looked up from JNDI.

Happy hacking !

Friday, June 22, 2007

Loose coupling in JBI

Loose coupling is a feature that can be easily achieved in JBI but which is sometimes not well understood by newbies in the JBI world.

In JBI, services are exposed inside the bus by JBI components when you deploy a given service onto it. These components can be Service Engines (contain business logic) or Binding Components (handling a specific protocol). The distinction is the key for loose coupling: the service itself it decoupled from the protocols used to access it. This is true for all services accessed from inside the JBI bus, be it internal to the bus or external to it.

Let's take an example. You need to write a BPEL process and expose it over SOAP/HTTP, and this process will consume several other services. These services can be inside the JBI bus, accessible via SOAP/HTTP or plain JMS. The important point is that the BPEL process has no knowledge of the protocol and location of these services. How does it work ?

The key is the WSDL. A WSDL can be split into two parts: the abstract and the concrete model. The abstract model contains the interface (Port) definition along with the messages and xml structures definition. The concrete part contains the binding (tying the service to a particular protocol) and service definition (location and binding for a given service). When JBI components talk together, they only use the abstract WSDL definition which does not contain any protocol or location information. The NMR will select a JBI endpoint based on some informations (name of the interface, name of the service) and will send the JBI exchange to the selected endpoint. If the endpoint has been activated by a Service Engine, it means that the service is hosted inside the JBI bus, and not protocol transformation will be performed. However, if the endpoint is activated from a Binding Component, the endpoint will act as a proxy for an external service provider: the binding component will send a request to the service in the protocol it handles to the known location, but the consumer (the BPEL process) has no knowledge of the exact protocol and location: the only things it needs is the contract (the abstract WSDL).

Take a look at ServiceMix and it's User's Guide.

Saturday, June 02, 2007

Father for the fifth time

Welcome to this world, Alexandre! My new son was born on May the 30th, weights 3.8 kg and his height is 52 cm.
Posted by Picasa

Thursday, March 08, 2007

Performances of ServiceMix WSDL-First example

I have spent some time profiling ServiceMix a bit, and particularly the WSDL-First example from the distribution. Here are the results while running a SOAP UI load tests on the example from the 3.1 distribution and the upcoming 3.1.1 distribution:

Version, min, max, avg, last, cnt, tps, bytes, bps, err
SMX 3.1, 9, 234, 20.64, 14, 57724, 484.43, 19106644, 159450, 0
SMX 3.1.1, 5, 204, 16.75, 14, 71065, 596.99, 23522515, 196095, 0

The most interesting number is the tps (transaction per seconds) absolute number: roughly 600 transactions per seconds sounds like a reasonable number (this small tests were running on my laptop without any particular tuning on the JVM or ServiceMix configuration) !

The other one is the tpc increase between 3.1 and 3.1.1:

595.99 / 484.43 = 1.2324

which means this sample performances for this sample has been boosted by 23 percents !

Wednesday, March 07, 2007

Using maven to switch runtime properties

For those who don't know all of Maven's features, I will show how to leverage maven at built-time to easily share run-time properties between service units in ServiceMix.

Let's say that you expose a few services over HTTP/SOAP using servicemix-http. If you are building several service assemblies, you will end up having several files containing:

<http:endpoint service="test:MyConsumerService"
soapVersion="1.1" />

You will certainly want all your services to be exposed on the same port, so it can become a bit tedious if you need to change them all, or if you need to change between different work environments (test, production, etc...).

When working with several service assemblies at the same time, I would recommend to use a hierachical organization for your maven projects:

|- module1
| |- module1-http-su
| |- module1-jsr181-su
| \- module1-sa
|- module2
| |- module2-http-su
| |- module2-jsr181-su
| \- module2-sa

This has several advantages: aside from organizing your code logically, you can use mvn jbi:projectDeploy at the root level, or at a sub-level.

So, now, how can we use maven for our properties ? Well, we just have to create them in the root pom:


Then, we need to enable maven resource filtering in our root pom:


And of course, we need to use them. So instead of the previous xbean.xml, we can now use:

<http:endpoint service="test:MyConsumerService"
soapVersion="${deployment-soap-version}" />

So now, if you want to switch your port, just change the root pom property and rebuild :-)

The next step is to use maven profiles to define environment and easily switch between those. This is maybe not useful for changing the HTTP port use, but if you configure some database access, you can easily switch between your production database and an embedded one for testing ...

Monday, March 05, 2007

ServiceMix dependencies

I have just fixed a small bug in ServiceMix (SM-865) and this makes ServiceMix a *very* lightweight ESB. The bare minimum dependencies to run the following example are:
  • servicemix-core
  • servicemix-jbi
  • servicemix-services
  • backport-util-concurrent
  • spring
  • xbean-spring

The example I ran is very simple, and of course dependencies need to be added depending on the JBI components you use. Anyway, here is the servicemix.xml file:

<beans xmlns:sm=""
<sm:container id="jbi" embedded="true">
<sm:activationSpec service="test:echo">
<bean class="org.apache.servicemix.components.util.EchoComponent" />
<sm:client id="client" container="#jbi" />

And here is the java code used:

import javax.jbi.messaging.InOut;
import javax.xml.namespace.QName;
import org.apache.servicemix.client.ServiceMixClient;
import org.apache.servicemix.jbi.jaxp.StringSource;
import org.apache.xbean.spring.context.ClassPathXmlApplicationContext;
import org.springframework.context.ApplicationContext;

public class Main {
public static void main(String[] args) throws Exception {
ApplicationContext context = new ClassPathXmlApplicationContext("servicemix.xml");
ServiceMixClient client = (ServiceMixClient) context.getBean("client");
InOut me = client.createInOutExchange();
me.setService(new QName("urn:test", "echo"));
me.getInMessage().setContent(new StringSource("world"));

This is the results of the work that has been done for the 3.1 release. The next step is to use the standard JBI components from ServiceMix ...

Monday, February 12, 2007

ServiceMix 3.1 released

Woohooo ! ServiceMix 3.1 has just been released officially.
This is a very important version with tons of new features, enhancements and bug fixes.

Sunday, January 14, 2007

JMS Soap Binding

Dan Diephouse just blogged about the announcement of a public review of a JMS SOAP binding and IRI scheme from BEA, IBM, Sonic and Tibco. This is a great news for JMS/SOAP interoperability !

He mentioned that the content-type header has a limited value because of the lack of support for very large messages in JMS. While this may be true for some providers, ActiveMQ provides such a feature.

Also, I'd like to mention I would have been very happy to have a JMS Binding for non-SOAP WSDLs, like the WSDL2 HTTP Binding. I think it would be even more useful !
Anyway, hopefully ServiceMix will have support for the spec soon ...

Tuesday, January 09, 2007

Jencks 2.0

Jencks 2.0 has been released.
This is a major release because there are lots of incompatibilities, but the main point has been to upgrade to Geronimo 1.2 Transaction Manager, which leads to a much simpler configuration.
The release also includes the ActiveMQ Pool from my previous blog entry.