I think there are several benefits to using ServiceMix over Camel, the main one imnsho is that ServiceMix is a JBI container. JBI is often misunderstood but the real value is to be able to plug any JBI component and access it from the bus. This means that if you need a specific feature already implemented by a JBI component not provided by ServiceMix, you'll be able to plug it in and consume it. You can find third party components from Apache Ode, Open JBI Components (https://open-jbi-components.dev.java.net/) and other places.
In addition, ServiceMix is a real container, whereas Camel is a library. You may want to deploy and manage things at runtime and not only rely on launching a camel route directly from the command line. ServiceMix 4 will emphasize these two points: the bus will be able to support multiple specifications including but not limited to JBI 1.0 (think about JBI 1.0, JAX-WS, SCA, EJB3 , Distributed OSGi ...), and non standard things too like Camel routes. The problem is mainly because of the overlap in the components themselves, and on this particular point, use the most appropriate one. Usually camel components are easier to use. Does that help somewhat ? On Jan 24, 2008 3:09 PM, Robert Thullner <[EMAIL PROTECTED]> wrote: > Hi > > I have implemented a few litte projects with ServiceMix and Camel > (included > and not included ServiceMix) now. > For me now following question arises: > I can write to files with SM or Camel, I can write to fpt with SM or > Camel, > I can do message transformation in Camel and SM, ... . Where comes the > benefit for using SM service units to write to any transport type that > Camel > also offers. The only reason advantage I found until now is that when > using > SM I have a standardized container, which I do not have when using Camel. > > What are the main benefits for using SM instead of Camel ? > > Thanks for any suggestions > Robert > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
