Guillaume Nodet's blog

I’ve been involved in ServiceMix, the Open Source ESB, nearly since its inception. ServiceMix was started by James Strachan and Rob Davies in May 2005 and the 1.0 version was released in August 2005. I joined LogicBlaze in October 2005 (leaving Mule behind, as I was a committer on Mule) to work on the 2.x releases (2.0 was released in November 2005) and then on the 3.x after the move from Codehaus to the Apache Software Foundation (3.0 was released in May 2007) and the 4.x versions based on OSGi (4.0 was released in March 2009). Even though I’m now focusing more on the OSGi side now (being the VP of Karaf), I’ve done my share of work on ServiceMix (I’m still the first committer in terms of number of commits according to http://svnsearch.org/svnsearch/repos/ASF/search?path=/servicemix) and I’ve been the VP of ServiceMix at the ASF for a few years. ServiceMix started as a very lightweight implementation of JBI spec. The 2.x version brought much more JBI compliance and the 3.x has se...

Ross Mason, the CTO of MuleSource, recently started a discussion about JBI. His first point is that JBI is no TCP/IP, meaning somehow that JBI is targeted at vendors and not at developers. Well, I'm not sure about the TCP/IP thingy, but he's a bit right about JBI being targeted at vendors and not developers. Why? If you have some knowledge about JBI, you know that there are multiple JBI components (bindings that handle a particular protocol such as HTML, JMS, etc... and engines that provides business logic such as a rules engine, a BPEL engine and so on). The developer will mostly see those components, not the JBI APIs: if you work with a BPEL engine and write a process, you won't see the JBI APIs surface in the BPEL at all. If you write a WSDL to define a SOAP/HTTP service, you won't really see JBI there either. So, yes, at some point, he is right that JBI 1.0 hasn't focused on the developer, or I should say, the user. Because if you need a custom componen...

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

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