Oh, and opennms is about 80% osgi now. I just have been swamped.
On Oct 15, 2010, at 2:48 AM, Chris Custine 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 >> >> >> >> >> >> 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
