I agree with lots of comments here, particularly Guillaume, Adrian & Chris's points resonate most strongly with me.
I understand that if you look at the pieces, say just Camel or Camel + Karaf, folks might not need the full ServiceMix. Its worth stepping back to realise that all those pieces kinda came from ServiceMix in the first place! Rather than being one big honking project which was app server + ESB + routing engine, we kinda decoupled pieces into their own smaller projects with their own life. This is a good thing! The container, integration library, NMR, JBI layers are all now optional pieces. We shouldn't beat ourselves or ServiceMix up too much because its done the great thing of modularising itself so folks can use as much or as little as they like. When I think of ServiceMix I still think of it as the box with all the pieces; like any vendors ESB diagram does. To me ServiceMix is Karaf + Camel + CXF + ActiveMQ + OSGi + NMR + JBI + loads of other stuff. It doesn't really matter to me how much code lives *just* in ServiceMix or whether the code is in Karaf or Camel or ActiveMQ or CXF or whatever; to me ServiceMix is the ESB - the "Enterprise Service Bus" or "Services Grid" or what have you; its the packaging, integration, documentation and tooling of all these technologies in a single place - where you can eat as much or as little as you like. ServiceMix has a great brand too :) For me personally I think ServiceMix should start to look higher up the stack & focus more on the bigger picture of the end user consuming all these different technologies across a number of machines. e.g. providing consistent security, transactions, monitoring, auditing across routes and containers. Maybe providing load balancing of non JMS endpoints using a registry. Maybe integrating tooling like this... http://www.slideshare.net/rguigsaad/activebam-5583589 If nothing else though, to me ServiceMix is the ESB; its the place where we figure out how to integrate all these projects together and create samples, documentation, recipe's and tooling. It doesn't matter to me really how much implementation detail code lives inside CXF or Camel or Karaf etc; ServiceMix has a clear focus on being the ESB and preferred deployment container for all this integration stuff. On 14 October 2010 19:14, Adrian Trenaman <trena...@progress.com> wrote: > Bengt is spot on, and has beaten me to the post on this. > > Here's my take: > > * By definition, Karaf is a pure, generic container for OSGi goodness. Lets > keep it that way: clean and simple, and applicable in many settings. > > * ServiceMix, as Guillaume points out, has a great reputation in the area of > ESB and 'enterprise integration in general'. It should evolve to provide all > the smarts that pull in Camel, CXF, ActiveMQ and other great integration > kits over Karaf into one deployment runtime that is absolutely focused on > solving the problem of enterprise integration. > > * While JBI adoption is on the decline, the ServiceMix NMR is a great device > for high-perf, in-memory, inter-bundle asynchronous communication. We should > continue to bring this goodness forward. > > * While I feel 'deprecate' may be too strong a word for the classic JBI > stuff, I do think we need to promote Camel wherever we can and void user > distraction into difficult areas of JBI. So, if deprecation is what is > called for, then let's make it so. > > Best, > Ade. > > On 14/10/2010 19:09, Bengt Rodehav wrote: >> >> Very interesting post Guillaume, >> >> I have the exact same experience that you describe. A few years ago we >> started using ServiceMix as an ESB. The JBI support (and the hope that it >> would become a "standard") was one of the important reasons for this. >> >> JBI in itself turned out to be unnecessary complex and since JBI hasn't >> caught on at all it is not a compelling reason for us anymore. I started >> to >> look at ServiceMix 4 as a good, OSGi based, deployment container. As an >> integration platform we turned to Camel - exactly as you described. Camel >> is >> much easier to use and has many more supported components. A pretty good >> combination I thought. Then Karaf came along which was a much better fit >> for >> us since we merely used ServiceMix 4 as a deployment container. The >> combination of Karaf and Camel is a very compelling platform and I like it >> a >> lot. >> >> I still follow the development of ServiceMix (we still have a ServiceMix 3 >> application in production) but I'm not at all sure what is being targeted. >> Is it an integration platform? A deployment container? >> >> I think Karaf is better suited for pure deployment and Camel is better >> suited for integration purposes. However, I think there is a need for >> something more complete than Karaf in terms of integrating other open >> source >> projects (like Camel, Karaf, Aries, OpenJPA...). I think many use >> ServiceMix >> (and Karaf+Camel) as an ESB or integration platform. But, I have a hunch >> (since I'm exploring it myself) that it could also be an option for >> "normal" >> enterprise applications (kind of like an application server). >> >> One of the problems I encounter is to integrate various versions of all >> the >> open source projects I use. Currently I'm waiting for Camel 2.5 and iPOJO >> 1.8. Prior to that I needed a Karaf 2.x version. But all of these projects >> are not always coordinated and it's quite a big job to find your own >> working >> "version mix". ServiceMix could take that on. It would mean creating a >> larger stack (larger than only Karaf) of enterprise/integration software >> components that would be tested together. >> >> Just a thought.. >> >> /Bengt >> >> >> 2010/10/14 Guillaume Nodet<gno...@gmail.com> >> >>> 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 >>> > -- James ------- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan Blog: http://macstrac.blogspot.com/ Open Source Integration
