I agree with this 100% Guillaume. I stated it differently, but this is exactly what I was thinking.
-- Chris Custine Sent from my mobile phone On Oct 15, 2010 3:33 AM, "Guillaume Nodet" <gno...@gmail.com> wrote: > Let me reformulate my thoughts about that. > > I think the NMR has some real value, providing this asynchronous bus inside > OSGi, based on endoints registered in the OSGi registry, thus allowing > bundles to communicate with each other in a very nice and scalable way. > What I'm not sure about is if we need to have a custom API for that. Most > of this API has been designed with support for JBI in mind, but if this very > point goes away, there's room for a much cleaner API, maybe reusing parts of > Camel API for exchanges, keeping what the value is (asynchronous bus based > on endpoints registered in the OSGI registry) and making it integrate better > in camel (by avoiding a transformation step which may be unnecessary, > etc...). > > I don't think we should drop the concept of the NMR, just that if we > officially deprecate the JBI layer, a new NMR could have a cleaner API. On > the other hand, having a separate API also allows several version of camels > to inter-operate nicely within the bus, which in itself is a really good > point too. > > Anyway, this discussion is a good way to pin down where the value is and how > we can make things better in the future. > > On Fri, Oct 15, 2010 at 10:48, Chris Custine <chris.cust...@gmail.com >wrote: > >> Johan, its 2:40 AM and I know you are in the same time zone... shouldn't we >> be sleeping :-) >> >> Ade did a great job laying out the case for this in a recent blog post, so >> I >> will just point you to it: >> >> http://trenaman.blogspot.com/2010/08/easy-useful-nmr-monsieur-nodet-vous.html >> >> < >> http://trenaman.blogspot.com/2010/08/easy-useful-nmr-monsieur-nodet-vous.html >> >This >> explains the NMR usage between OSGi bundles quite well. I have talked to >> several people recently who are using this exact architecture. I think >> this >> would be similar to what we have talked about wrt an OpenNMS like event >> bus. >> >> Cheers, and good night ;-) >> >> Chris >> >> -- >> Chris Custine >> FuseSource - Open Source Integration:: http://fusesource.com >> My Blog :: http://blog.organicelement.com >> >> >> >> >> On Fri, Oct 15, 2010 at 02:36, Johan Edstrom <seij...@gmail.com> wrote: >> >> > Chris, >> > >> > Can you elaborate even more on this? >> > I know you've explained it to me - but I think it needs even more >> > clarification? >> > >> > /je >> > >> > On Oct 15, 2010, at 2:31 AM, Chris Custine 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 >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >> >> > >> > 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 >> > >> > >> > >> > >> > >> > >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com
