Guillaume Nodet's blog

ServiceMix 4 NMR on Equinox

2008-05-15T17:02:00.002+02:00

I've done some experiments today to check that ServiceMix 4 NMR can be easily deployed on Equinox instead of Felix. Have a look at this wiki page.

Apache ServiceMix Kernel 1.0-m3

2008-05-13T21:53:00.003+02:00

We've just released the third milestone of ServiceMix Kernel 1.0-m3. This small OSGi based container is really nice, if you haven't had a look at it yet, go and grab it.

It adds a bunch of cool new features. For example you can run:


osgi list | utils grep ServiceMix


log d | utils grep WARN

If you want to have a quick run at it, go and look at the quick start guide.

Spring App Server

2008-04-30T11:31:00.002+02:00

I've just seen the annoucement that SpringSource has launched a new App Server based on OSGi (Spring-DM).
I find it a bit weird that they tend to rewrite existing stuff: the JMS JCA layer in Spring 2.x is somehow derived from the Jencks project, Spring Integration looks a lot like Camel, and now this app server which looks very similar to ServiceMix Kernel with WAR support (which we already had in ServiceMix 4 from the Pax Web project).

Ziphone

2008-04-25T14:47:00.003+02:00

A friend of mine has cracked an iPhone a few months ago (shame on him...) but was quite reluctant to upgrade to a newer version in case the phone would be bricked.
Fortunately, I gave him a link to ZiPhone, which is the best way to unlock your iPhone I've found so far: just upgrade your phone using iTunes, launch the application and click. 5 minutes later, you have a jailbroken and unlocked iPhone with the latest firmware :-)

Dan has also blogged about Fring, a very nice application to to VoIP over the iPhone.

If you like to twitter, have a look at Twinkle too.

ApacheCon EU 2008

2008-04-04T17:27:00.003+02:00

Bruce and I will be both at ApacheCon Europe in Amsterdam next week to talk about ServiceMix and Camel, so if you want to meet with us, send us a mail.
There will be a BOF about ServiceMix on Wednesday, so it will be a good opportunity to meet too.

JBI and SCA (again)

2008-04-04T15:50:00.001+02:00

I've just seen this post saying:

One of the major motivations for doing so is that currently, the Java community is still split between SCA and JBI.

Well, this is somewhat true, I can't really deny it, but it should not be that way. JBI and SCA are not really competitors, even if they are usually seen that way. The JBI specification explains how to create an ESB that allows pluggable components to be wired easily thus allowing vendor independant components to be created. SCA defines a way to write composite applications in a clearly defined way that can be applied to different languages (though you can't really mix those, so you end up with one runtime per language you support).

As a standard, SCA offers value, but I really think both could be supported in a single runtime like FUSE ESB. We've discussed several times about supporting SCA on top of JBI in ServiceMix, but I haven't heard much needs on that. We are currently working hard on ServiceMix 4, based on OSGi and allowing lots of technologies to be plugged onto a single bus, including JBI, Camel, JAX-WS, EJB3, etc... Supporting SCA would only be another profile.

ServiceMix / Fuse ESB press release

2007-12-06T16:52:00.000+01:00

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.

Apache ServiceMix 3.1.2

2007-09-25T09:21:00.000+02:00

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 http://repo1.maven.org/maven2/org/apache/servicemix/).

ServiceMix has graduated

2007-09-19T20:08:00.000+02:00

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 http://servicemix.apache.org/ and the svn repo to https://svn.apache.org/repos/asf/servicemix/.

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

FUSE ESB

2007-08-30T14:39:00.000+02:00

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

Switching to Mac

2007-08-13T23:04:00.000+02:00

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

ServiceMix 3.1.1 released

2007-07-04T14:06:00.000+02:00

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

Accessing databases in servicemix-drools

2007-06-28T14:00:00.000+02:00

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);
      this.jdbcTemplate.afterPropertiesSet();
    }

    public String getSurname(String name) {
        String surname = (String) this.jdbcTemplate
          .queryForObject(
              "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
    when
        $me : Exchange()
    then
        String t = $me.getIn().getContent().getTextContent();
        jbi.answer("<surname>"
            + helper.getSurname(t)
            + "</surname>");
end

And the xbean.xml would look like:

<drools:endpoint  service="test:service"
                  endpoint="endpoint"
                  ruleBaseResource="classpath:router.drl"
                  globals="#globals" />
<util:map id="globals">
  <entry key="helper" value-ref="helper" />
</util:map>
<bean id="helper" class="DbHelper">
  <property name="dataSource">
    <bean class="org.springframework.jndi.JndiObjectFactoryBean">
      <property name="jndiName" value="java:myDataBase" /> 
    </bean>
  </property>
</bean>

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

Happy hacking !

Loose coupling in JBI

2007-06-22T08:54:00.000+02:00

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.

Father for the fifth time

2007-06-02T14:47:00.000+02:00

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

Performances of ServiceMix WSDL-First example

2007-03-08T01:46:00.000+01:00

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 !

Using maven to switch runtime properties

2007-03-07T09:33:00.000+01:00

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"
               endpoint="myConsumer"
               role="consumer" 
               locationURI="http://0.0.0.0:8192/Service/"
               soap="true"
               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:


  root
    |- 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:


<properties>
  <deployment-port>8192</deployment-port>
  <deployment-soap-version>1.2</deployment-soap-version>
</properties>

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


<build>
  <resources>
    <resource>
      <directory>src/main/resources
      <filtering>true
    </resource>
  </resources>
</build>

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


<http:endpoint service="test:MyConsumerService"
               endpoint="myConsumer"
               role="consumer" 
               locationURI="http://0.0.0.0:${deployment-port}/Service/"
               soap="true"
               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 ...

ServiceMix dependencies

2007-03-05T14:58:00.000+01:00

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="http://servicemix.apache.org/config/1.0"
     xmlns:test="urn:test">
  <sm:container id="jbi" embedded="true">                 
    <sm:activationSpecs>
      <sm:activationSpec service="test:echo">
        <sm:component>
          <bean class="org.apache.servicemix.components.util.EchoComponent" />
        </sm:component>
      </sm:activationSpec>
    </sm:activationSpecs>
  </sm:container>
  <sm:client id="client" container="#jbi" />
</beans>

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"));
       client.sendSync(me);
       System.err.println(me);
   }
}

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

ServiceMix 3.1 released

2007-02-12T12:48:00.000+01:00

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

JMS Soap Binding

2007-01-14T01:03:00.000+01:00

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

Jencks 2.0

2007-01-09T10:22:00.000+01:00

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.

ActiveMQ Pooling

2006-12-20T02:35:00.000+01:00

Over the past weeks, I spend some times load testing ServiceMix and ActiveMQ.
I discovered two things:
* ActiveMQ broker is currently single threaded for a given JMS connection. The main effect is that if you send messages from several threads on the same connection, all threads will be processing sequentially (well, not exactly, but they will all be processed by a single thread on the broker side).
* ActiveMQ Resource Adapter does not pool sessions and producers: this means that sending a single message with Jencks using the JMS best practices in a J2EE environment (create a connection, create a session, create a producer, send, close all) will take three consecutive roundtrips to the JMS broker and is very CPU intensive for the broker (at least, when using JMX).

The first problem is mainly apparent when using persistent messages and there are a few things than can be used to speed up things (see the LogicBlaze tuning guide for ActiveMQ). However these tuning tweaks are not always desirable, and there was an easy solution: as the broker use a single thread for given JMS connection, we just have to use multiple connections. Hence, I enhanced the org.apache.activemq.pool package so that the PooledConnectionFactory can reuse more than one connection.

The second point was more difficult to solve, as I did not had time to rewrite the ActiveMQ Resource Adapter -- and I'm still not sure of the downside of pooling sessions and consumers inside a full J2EE environment (security for example). But my needs were only to be able to have XA support and session pooling at the same time. Once again, the solution was to enhance the existing PooledConnectionFactory to support XA resource enlistment. This was quite easy, as the jencks project already contained some code written by a contributor. Unfortunately, I could not reuse it, as it uses the XA JMS api, and in such a case, ActiveMQ force the use of an XA transaction, and I wanted the same connection to be reused with and without transactions. So I rewrite it.

Last, but not least, I needed this ConnectionPool to be correctly used with the Jencks inbound JCA support. It sounds easy (and I thought it was), but at first, the two JMS session were enlisted in the transaction, but they were not recognized as using the same Resource Manager. It was inefficient, but worse, the transaction did not complete successfully. Back to the drawing board ...

Well, the good news is that it now works !
So jencks now features a new module called jencks-amqpool which defines three different factory beans:

PooledConnectionFactory: the standard JMS pooled connection factory
XaPooledConnectionFactory: this one supports XA transaction auto enlistement
JcaPooledConnectionFactory: to be used with jencks JCA inbound support

Note that the three connection factories inherit from each other, so that it is completely safe to use the JCA connection factory in all cases.

Code is available at http://fisheye.codehaus.org/browse/jencks/trunk/jencks-amqpool/src/main/java/org/jencks/amqpool/ and will be include in the upcoming 2.0 release of Jencks.

Here are some simple performance tests. The test spawns 10 threads, each sending 100 messages through the same JMS connection factory.
Using a single connection for the factory:

without transactions: 38 msgs/sec
with a transaction for each message: 41 msgs/sec
with a transaction for 10 messages: 283 msgs/sec

Using 10 connections in the factory:

without transactions: 150 msgs/sec
with a transaction for each message: 173 msgs/sec
with a transaction for 10 messages: 353 msgs/sec

As you can see, the performance boost over the previous pooled connection factory is quite important: 4 times faster ! (unless you use transaction batching).

For the JCA outbound part, the tests are launched with 10 threads, 100 messages per thread.

JCA managed connection factory: 11 msgs/sec
Pooled connection factory: 31 msgs/sec
Pooled connection factory with 10 connections: 143 msgs/sec

The pooled connection factory is three times faster and 12 times faster when using 10 connections ! In addition, the tests were using 10% of my CPU with the pooled connection factory, but 100% with JCA managed connection factory.

GWT

2006-12-12T22:50:00.000+01:00

I have just viewed Bruce Johnson tech talk on GWT (Google Web Toolkit).
It sounds really powerful, especially the fact that your code is statically checked and the hosted mode.
I really need to try it. Maybe a new console for ServiceMix which would allow the management of a ServiceMix cluster ...