I think the general direction should still be to use Camel instead of servicemix components. If possible, it's far better to improve Camel where features are lacking or not good enough than providing them as a separate track outside of Camel. Otherwise I think we'll just add to the confusion instead of providing clear directions for ServiceMix.
Still not entirely convinced that ServiceMix should "just" be an ESB although that is of course the primary purpose. Especially when integrating technology like Aries, I think the scope of ServiceMix could be extended to a OSGi based platform for enterprise applications. /Bengt 2010/10/15 Lars Heinemann <lh...@apache.org> > I think it is a good idea to move to a new major version to do all those > changes. But I would then > deprecate both SMX3 and SMX4 to start something really new. And I wouldn't > even advertise those old > versions on the new homepage but simply go only for the new one. > Otherwise we will end up maintaining 3 different versions of smx in code > and documentation. > > I agree that Camel has all components SMX has but the question is if they > are as good as their > smx pendants. For camel-mail <-> servicemix-mail I would say that the smx > one has more functionality. > So I would not blindly thre away our components without checking that > first. > > Regards > Lars > > > Am 14.10.2010 um 16:35 schrieb Guillaume Nodet: > > > I've had an interesting discussion today with jbonofre about ServiceMix > > future so I think we should get that on the dev list, hence this mail to > > start the discussion. I've heard more and more people wondering about > the > > value in ServiceMix compared to Karaf + Camel for example. I wonder what > > your feedback is, how you feel about the future of ServiceMix and what we > > should do as a community. > > > > As for my personal opinion, I think ServiceMix has a very strong brand as > an > > open source ESB, but since ServiceMix 4.x, people tend to be confused > about > > it. I think there are several path forward. > > The first thing to state is that the JBI spec did not fulfill its > promises. > > For various reasons (mostly political I think), the specs has not been > > backed by enough big vendors. JBI 2.0 will never happen so the JBI spec > is > > kinda dead. The second fact is that more and more users tend to start > new > > projects directly with Camel for a lot of valid reasons, mainly its ease > of > > use and tons of connectors. That does not mean they don't use ServiceMix > as > > the runtime, just that they tend to let aside some features such as the > JBI > > or NMR layer. > > Given those facts, I think one possible future would be to officially > > deprecate the JBI layer and components (i.e. maintaining those for > > compatibility, but not necessarily add new features) and focus on more > value > > added such as better integration with third party projects (Ode, Hise, > > etc...) and maybe more tooling (monitoring, etc...). > > > > Anyway, it's just my personal opinion and feedback, but i'd like to here > > what other think about that, so that we can move forward. I'm sure there > > are a lot of different ways for ServiceMix' future, but the most > important > > thing to me is to come up with a clear position that we all agree on and > be > > in a better position to move forward and bring ServiceMix to the next > level. > > > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > >
