You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Robert Thullner <rt...@gmx.at> on 2008/01/24 15:09:19 UTC

Best Practice Question

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

AW: Best Practice Question

Posted by Robert Thullner <rt...@gmx.at>.
 
Thanks for you explanation it helps me a lot. 
The container is definitely an advantage that I did not think about too
much. 

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


> 
> 
> 
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> 


Re: Best Practice Question

Posted by Guillaume Nodet <gn...@gmail.com>.
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 <rt...@gmx.at> 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/