I forgot to add, that particularly in the case of clustering/DOSGI/grid/large scale environments, etc., having too much routing functionality tied up down at the camel level just doesn't make much sense. Having the NMR and other generic requirements as a container supplied services will allow centralized administration and configuration and make much more sense in this case. So this is another reason I don't like the idea of shifting NMR like responsibilities up to a higher level in the stack.
Chris -- Chris Custine FuseSource - Open Source Integration:: http://fusesource.com My Blog :: http://blog.organicelement.com On Fri, Oct 15, 2010 at 02:31, Chris Custine <chris.cust...@gmail.com>wrote: > I would never want to hide the NMR inside of Camel and take away the > ability to wire up endpoints via OSGi services. Some of the statements > people are making here don't seem to take this into consideration, so I just > want to point this out. It is true that you can reproduce much of the async > message flow by various means using Camel without the NMR, but now you are > integrating non Camel components only via external bindings and protocols. > I think the value is in integrating these things more closely and as first > class citizens inside the ESB, and do that using the NMR. To force everyone > into using Camel just to utilize the NMR seems rather short sighted to me > considering how many people use (and very much like) the NMR and OSGi > combination. > > So the added value of NMR in this case is very poor/limited. I don't think >> that we need anymore NMR in the future except if we have features present >> in NMR that camel cannot implement. > > > You are assuming that everyone who uses ServiceMix must also want to use > Camel, and I am reasonably certain that this is not always the case. I may > be misinterpreting some of this, but I think we should be careful not go > overboard here. > > Chris > > -- > Chris Custine > FuseSource - Open Source Integration:: http://fusesource.com > My Blog :: http://blog.organicelement.com > > > > > On Fri, Oct 15, 2010 at 01:50, Moulliard, Charles < > cmoulli...@fusesource.com> wrote: > >> Hi, >> >> The vm:// component of camel plays the same role as NMR to interconnect >> camel routes deployed in different bundles. So the added value of NMR in >> this case is very poor/limited. I don't think that we need anymore NMR in >> the future except if we have features present in NMR that camel cannot >> implement. >> >> Charles >> >> On Fri, Oct 15, 2010 at 9:25 AM, Johan Edstrom <seij...@gmail.com> wrote: >> >> > +1 >> > >> > I'm often accused of being an NMR lover, the concept is great. >> > It is also something that sets it apart from say the hump. >> > >> > /je >> > >> > On Oct 15, 2010, at 1:14 AM, Guillaume Nodet wrote: >> > >> > > 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 >> > >> > Johan Edstrom >> > >> > j...@opennms.org >> > >> > They that can give up essential liberty to purchase a little temporary >> > safety, deserve neither liberty nor safety. >> > >> > Benjamin Franklin, Historical Review of Pennsylvania, 1759 >> > >> > >> > >> > >> > >> > >> > >
