Apache Camel did a survey less than two weeks ago. You could always ask them if it was useful or not...
/Bengt 2010/10/16 Lars Heinemann <lh...@apache.org> > Or maybe we should join the hype and go for a ServiceMix Survey ;) > > Lars > > > Am 16.10.2010 um 18:23 schrieb Charles Moulliard: > > > It could be interesting that we create a wiki page to discuss ServiceMix > 5 content ;-) > > > > On 16/10/10 16:35, Bengt Rodehav wrote: > >> I agree with Guillaume 100%. > >> > >> I'm sure there are lots of things in ServiceMix that provides a lot of > value > >> - scalability seems to be one of them. However, being a ServieMix user > >> myself (that lately favours Karaf+Camel instead), I know for sure that > the > >> vision and purpose with ServiceMix is not crystal clear. A clear vision > for > >> ServiceMix - that differentiate it from other projects like Karaf and > Camel > >> - is essential. Otherwise, I think ServiceMix will loose a large portion > of > >> its installed base. > >> > >> What Camel does well (and Camel does a lot of things really well) should > not > >> be duplicated in ServiceMix. It's a real waste with competent resources. > >> Instead ServiceMix should find its unique value proposition. I think > that > >> value proposition really needs to be discussed. > >> > >> Some of the value I see in ServiceMix (some now and some possible in the > >> future) are: > >> > >> - Umbrella project. It can be of great value if ServiceMix coordinates > >> versions of other projects and get them to work together. You would then > >> have a working ESB and/or a platform for developing enterprise > applications > >> depending on what other projects are embraced. > >> > >> - OSGi glue. Like the specifications and bundles that ServiceMix > provides > >> today. This could be part of ServiceMix or it could be moved to an > >> independent project (like suggested by Ioannis). Either way, there is a > need > >> for this glue. > >> > >> - Scalability. > >> > >> - Improve on "production readiness". Among other things, this includes > >> tooling of different sorts. For deploying, monitoring, measuring and > >> managing. I think this is important when customers compare OSS products > with > >> commercial products. Although many OSS products have both functionality > and > >> quality in par with the commercial products, the "finishing touch" is > often > >> lacking. This is often in the area of tooling but also concerns > >> documentation. The umbrella project view is also important here. > Commercial > >> products often include "everything" and you can turn to one vendor to > get > >> the new release. With OSS you have to coordinate everything your self > which > >> is a risk for a company. If ServiceMix could decrease that risk than it > >> would be able to compete better with commercial software than if the > >> alternative would be Karaf+Camel+ActiveMQ+....that the customers would > have > >> to handle on their own. > >> > >> Isn't it time to perform a survey to really find out what the installed > user > >> base thinks? Some questions could be: > >> > >> - What type of applications do you target with ServiceMix? Integration, > >> enterprise applications or other (please specify)? > >> > >> - Is your use of ServiceMix increasing, decreasing or unchanged? > >> > >> - What are ServiceMix most valuable features? > >> > >> - What other options does ServiceMix compete with? > >> > >> - ... and so on.... > >> > >> /Bengt > >> > >> > >> > >> 2010/10/16 Guillaume Nodet<gno...@gmail.com> > >> > >>> On Sat, Oct 16, 2010 at 13:39, Ioannis Canellos<ioca...@gmail.com> > wrote: > >>> > >>>> Hi all, > >>>> > >>>> Service Mix is one thing and Camel is an other. > >>>> > >>>> The fact that JBI failed to become widely accepted, does not mean that > it > >>>> should be deprecated. It could become optional but I don't see why > >>>> deprecated. > >>>> I agree with Adrian the deprecated sounds really strong. For all > existing > >>>> professional JBI users, the word deprecation means replacement. I > really > >>>> can't see a production infrastructure built on "deprecated" software. > So > >>>> deprecating JBI is like punishing all those who chose to invest on it. > >>>> > >>> Deprecation may be a bit strong, but the point is for our users to be > aware > >>> of what they should try to use in the future, because that's where we > will > >>> focus our efforts. If we plan on continuing adding new JBI > components, or > >>> new improvements to the existing components and all, then that clearly > mean > >>> that the JBI layer is not deprecated. If we don't really plan to do > much > >>> on > >>> those but bug fixing, that means they should be put officially in > >>> maintenance mode (if the term is preferred over the stronger > deprecation). > >>> Which ever term we choose, we should let our users know. > >>> > >>> > >>>> As a ServiceMix/Camel user I don't like the fact that binding > components > >>>> have been discontinued, that serivcemix-eip is deprecated in favor of > >>> camel > >>>> etc, since camel can't give me 100% of the functionality I want (yet). > >>> Can > >>>> camel provide me with alternatives for all the existing > servicemix-eips? > >>>> No. > >>>> Can camel provide me with alternatives for all existing service mix > >>>> binding > >>>> components? No. Is Camel as scalable as ServiceMix? No. > >>>> > >>> Servicemix-eip is deprecated since a long time, but we still ship it. > The > >>> point is that no-one has ever submitted a new feature on it and the > code > >>> hasn't changed at all since monthes. Is the component still used and > >>> usable ? Of course. Is that where we're focusing our efforts to make > things > >>> even better? Not really. > >>> > >>> For Camel scalability, I think since camel reintroduced the > asynchronous > >>> processing, there's no huge gap between camel and servicemix. My > opinion > >>> however, is that it would be easier to make Camel as scalable as > ServiceMix > >>> rather than make the jBI/NMR layer and components as easy to use as > Camel. > >>> > >>> I also do think, a non marginal portion of our users are switching to > Camel > >>> instead of the using JBI components and I don't see this tendency to > >>> decrease. I also don't think ServiceMix should try to compete against > >>> camel. Which means the camel components will get better and better > while > >>> the ServiceMix components will have a much lower improvement in the > same > >>> time. We should be honest with our users if that's the way it works > and > >>> pushing them where we think it's best for them. And I think the > benefits > >>> from using Camel over the JBI components exceeds the possible > drawbacks. > >>> > >>> It is totally understandable that Karaf / Camel combo is very strong > and > >>>> easy to use, but that doesn't mean anything. Karaf is a really strong > >>>> runtime and it could be used as a base for any infrastructure. Does it > >>> mean > >>>> that since I can use Karaf/Aries/OpenEJB/ActiveMQ/Jetty, Geronimo > should > >>>> change focus or get deprecated? No. > >>>> > >>> Not sure how this is related. Geronimo's purpose is to provide a JEE > >>> server. And if you look at the version 3.x in developement, it is > actually > >>> based on exactly those products. But dropping those products inside > Karaf > >>> certainly does not make a JEE server, and certainly not Geronimo. > >>> > >>>> Things I would love to see in Service Mix 5 are: > >>>> > >>>> 1) Improved management. > >>>> i) Full life cycle control of endpoints (servicemix or camel) via > command > >>>> prompt, web console, jmx. > >>>> ii) Endpoint Life cycle bindings to certain events inside the BUS > >>> (example: > >>>> on accept connection activate route X, on connection lost deactivate > >>> route > >>>> X). > >>>> iii) Advanced endpoint (servicemix or camel) publishing via > >>> command-prompt, > >>>> web console, jmx. > >>>> iv) A web based integration designer, where the user could draw EIPs > and > >>>> ServiceMix would create the Endpoints, Camel Routes etc. > >>>> v) Advanced monitoring. (Example I want to know any given time even > that > >>>> state of Jetty's connection pool). > >>>> > >>>> 2) Integration with third party software > >>>> i) Spring Batch would be interesting. > >>>> ii) The Apache Hadoop stack. > >>>> > >>>> 3) Cloud deployments. > >>>> i) Maybe it would be a good idea Cloud Mix to merge with Service Mix. > >>>> ii) Other similar cloud related things. > >>>> > >>>> 4) The Apache Bundle Repository > >>>> i) Make ServiceMix bundles an independent project, in a conjoined > effort > >>>> with the rest of ASF projects that use OSGi, for faster bundle > coverage > >>>> which would aid point 2 and also save resources. > >>>> > >>>> > >>> Those ideas are indeed interesting. The problem is that when > "servicemix > >>> or > >>> camel" for endpoints, there is necessarily a duplication of efforts, or > we > >>> need to chose one or the other. I don't really think we should start > a > >>> detailed roadmap discussion without agreeing about the vision of > ServiceMix > >>> first. > >>> > >>> I really think a lot of people are confused. People were already > confused > >>> when we had only the servicemix-http compoennts (with the 2 sets of > >>> endpoints) and servicemix-cxf components. Now, with camel-http, > >>> camel-cxf, > >>> cxf-nmr, things are even more confusing. I'd like to reduce our users > >>> options (or at least better guide them) when it comes to implementing a > new > >>> project to make their life easier... > >>> > >>> > >>>> > >>>> On Fri, Oct 15, 2010 at 2:21 PM, Charles Moulliard< > cmoulli...@gmail.com > >>>>> wrote: > >>>>> If you think that keeping NMR (or at least a part of the API) is a > >>> great > >>>>> value, I would like to suggest that we think about the name of the > >>>> component > >>>>> that we will propose to our users / customers > >>>>> > >>>>> Does it make sense to keep the name NMR if the exchange is not longer > >>> of > >>>>> type XML = normalized, the routing made by Camel ? > >>>>> We should investigate the pro/con to have NMR vs VM with Camel to > >>> propose > >>>> a > >>>>> clear way to interconnect components over OSGI Bundles and not two > >>>> endpoints > >>>>> doing the same ? > >>>>> This component could be improved to allow clustering beween SMX4 > boxes > >>>> and > >>>>> could be an alternative of using JMS for that purpose > >>>>> > >>>>> CM > >>>>> > >>>>> > >>>>> > >>>>> On 15/10/10 12:54, Jean-Baptiste Onofré wrote: > >>>>> > >>>>>> Agree Rob: MEP is an important value as I said in my previous > e-mail. > >>>>>> > >>>>>> I think that the most important limitation in JBI is the XML based > >>>>>> messages. > >>>>>> > >>>>>> The NMR could provide quite the same features than JBI (async > >>> behavior, > >>>>>> MEP, etc) without the requirement of the XML messaging. > >>>>>> > >>>>>> My purpose was most to flag JBI as deprecated (because it's the > case). > >>>>>> ServiceMix NMR is a good place to provide the MEP and async support > >>> (as > >>>> it > >>>>>> does currently). > >>>>>> > >>>>>> Regards > >>>>>> JB > >>>>>> > >>>>>> On 10/15/2010 12:38 PM, Rob Davies wrote: > >>>>>> > >>>>>>> I'm still of the opinion that there is a lot of value in JBI - the > >>>>>>> message exchange part at least It would be interesting to do a > clean > >>>> API > >>>>>>> for the NMR without any JBI considerations, and then see if we > could > >>>> retro > >>>>>>> fit JBI message exchanges over it - I'd be happy to volunteer to > try > >>> do > >>>> the > >>>>>>> JBI retro fit ;) > >>>>>>> > >>>>>>> On 15 Oct 2010, at 10:27, Guillaume Nodet 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 > >>>>>>>> > >>>>>>> > >>>> > >>>> -- > >>>> *Ioannis Canellos* > >>>> http://iocanel.blogspot.com > >>>> > >>>> Integration Engineer @ Upstream S.A.<http://www.upstreamsystems.com> > >>>> > >>> > >>> > >>> -- > >>> Cheers, > >>> Guillaume Nodet > >>> ------------------------ > >>> Blog: http://gnodet.blogspot.com/ > >>> ------------------------ > >>> Open Source SOA > >>> http://fusesource.com > >>> > > > >
