The vm:// can't abstract endpoints over several installations.
On Oct 15, 2010, at 1:50 AM, Moulliard, Charles 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
