ServiceMix -- jbi dead-replaced by camel

Purpose:

When I first came into contact with ESB, I selected mule, ServiceMix, and so on. At that time, considering SM's support for jbi and many other reasons such as the mule Community version's cut-off functions,

Select SM. When SM is used as a Web Service proxy, we can see that there is only one article in the era of sm3.0 on the Internet:

Name: make? Use? S? E? R? V? I? C? E? M? I? X? (? E? S? B ?)? ? Bu? I? ? ? Department? ? W? E? B? S? E? R? V? I? C? E

Http://wenku.baidu.com/link? Url = A9Ava_nYaGHDFBO0mAgykQaZIxnsdg2pqDM1r9vGoePRMChxa-V1umQASfvArZ5qi7ZbyEP13yCA_QT2FZnGAaYYgN5cCVY1ppir6CNL8-W

With an in-depth understanding of SM, I can see a blog written by an SM developer, which means that jbi is dead and camel is used as a replacement.

Make a record. If someone else can see this blog, it will be nice to save some time for searching.

 

Content:

Sm1.0 is a lightweight jbi implementation;

More abundant jbi content is added to sm2.0;

If sm3.0 is migrated from a light jbi container to a heavy jbi container, it will feel the strong jbi restrictions (jbi 1.0 ),

At this time, the jbi, from 1.0 to 2.0, and Sun Company left the company with no hesitation,

At this time, when camel emerged and grew stronger, components in camel became increasingly incompatible with jbi components.

After analysis, SM developers thought that camel and osgi were the future standards, and jbi was not, so they decided to switch to camel.

Sm4.0 discards jbi and uses camel. An optional plug-in is provided to support jbi.

 

Original article address:

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

 

Original article content:

Guillaume nodet's blog
Tuesday, December 21,201 0
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 logicblze 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

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 cocould be built on top of jbi. However, jbi was not backed by

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 realized we shoshould 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!