本文目的：

    一开始接触ESB的时候，对mule，servicemix等进行选型，当时考虑到sm对jbi有支持，mule的社区版本砍掉的功能较多等原因，

    选择了sm。在进行sm用做web service代理时，看到网上只有一个sm3.0时代的文章：

    名称：使?用?S?e?r?v?i?c?e?m?i?x?(?E?S?B?)?发?布?一?个?外?部?的?W?e?b?S?e?r?v?i?c?e

    地址：http://wenku.baidu.com/link?url=A9Ava_nYaGHDFBO0mAgykQaZIxnsdg2pqDM1r9vGoePRMChxa-V1umQASfvArZ5qi7ZbyEP13yCA_QT2FZnGAaYYgN5cCVY1ppir6CNL8-W

    随着对sm的深入了解（翻墙等），看到一篇sm的开发者写的blog，大意为JBI已死，Camel作为替代者。

    做一下记录，如果有其他人能够看到这篇blog，省下些寻找的时间，就很好。

本文内容：

    sm1.0是一个轻型的JBI实现；

    sm2.0添加了更丰富的JBI内容；

    sm3.0则从轻型JBI容器，迁移到了一个重型JBI容器，会感受到JBI的强烈限制（JBI 1.0），

             这时候的JBI，从1.0到了2.0，同时从sun公司义无反顾地脱离了出去，

             此时也是Camel兴起，并发展壮大的时候，Camel里的组件与JBI的组件越来越不能兼容。

             经过分析，sm开发者们认为Camel和osgi是未来的标准，JBI不是，于是决定转向Camel。

    sm4.0抛弃JBI，使用Camel。提供了一个可选项插件来支持JBI。

http://gnodet.blogspot.com/2010/12/thoughts-about-servicemix.html

原文内容：

Guillaume Nodet‘s blog
TUESDAY, DECEMBER 21, 2010
Thoughts about ServiceMix
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 seen migration

from the lightweight component to fully fledge JBI components and full JBI compliance.

In doing so, ServiceMix became a container, as required per the JBI spec and over-time

lost a bit of its lightweight-ness. That’s exactly at the same time that

Camel was created as a routing library, based on the experience with ServiceMix.

After the 3.0 was released it became apparent that the JBI spec was way too limited

with respect to the container (classloaders and even the packaging are a real pain in JBI),

so we started experimenting with OSGi at that time and that led the path to ServiceMix 4.x

and the Karaf project, which started as ServiceMix Kernel.

In 2007, the SCA spec came out, backed by IBM and Oracle, and during a few months,

there were a lot of heated debate around JBI versus SCA. It eventually settled a bit when

people started understanding that those specs were not really competing,

as JBI was targeted around components interoperability while SCA target was application

development and could be built on top of JBI. However, JBI was not backed by the

big vendors (only really SUN), and when the spec lead for JBI 2.0 left SUN with no replacement,

it became clear that the JBI spec was dead.

Another point is that over time, Camel grew to become a top level project and

be the very successful project we know, and for some time, we did not really know

what to do with the overlap between Camel components and ServiceMix components.

Since JBI 2.0 doesn‘t appear to be going anywhere we realised we should focus on

Camel for the EIP support and connectivity and that OSGi was a better long term

standard to represent the registry of endpoints, so we‘ve refactored ServiceMix NMRto be more lightweight,

based on the lightweight OSGi container and based around the OSGi registry;

with JBI support an optional legacy connector.

So we now have a simple lightweight approach to providing a middleware agnostic

registry of endpoints with full hot-deploy and supporting powerful class loader versioning schemes via the OSGi registry.

Long live ServiceMix, Camel and OSGi!