On Thu, Oct 14, 2010 at 20: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 think there is some value in the NMR, I'm quite not sure about having to maintain an API which is really similar as the Camel one. i think that slight modifications to Camel could bring it to the same level as the NMR, so I'm wondering if we should try to enhance camel to provide the missing feature we need. AFAIK, there are a few connectors for the NMR, such as the camel one and the CXF one, but CXF has a clean integration in Camel already, so I'm not entirely sure if the cxf/nmr one is needed. Obviously, the camel one would be useless if we switch to Camel. I think another key problem would be the integration of technologies such as Ode (BPEL) which heavily rely on WSDL descriptions. Camel is a bit poor at describing endpoint as WSDL. Camel also does not offer a way to expose endpoints on something that would look like a protocol agnostic bus: endpoints are internal to routes. I guess we'd need to discuss such things with the Camel community, but I think the value of the NMR could be refactored into Camel. The NMR concept is nice, I'm just challenging the need of a different API for it. Not sure though ... > * 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 >>> >>> -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
