Another angle to all of this is to look at possible competitors. I've recently started looking at Eclipse Virgo + Gemini which I think is worth comparing with. It seems like Gemini is similar to Apache Aries while Virgo is a "modular open source application server based on OSGi". Not sure if the Apache equivalence would be Karaf+Aries or perhaps even ServiceMix. However, on one of the last slides in one of their presentations ( http://archive.eclipse.org/technology/phoenix/webinars/100831_VirgoSlides.pdf) they state that in the future they want to support more "server types" on top of Virgo. On the list of server types is "Integration" which seems related to what is in scope for ServiceMix.
I think it's of great value to be able to use the same platform for both enterprise applications and integration focused applications. It's important for developers to be able to reuse the skills from one application type to the other. A common platform is therefore of great importance - so is tooling. In this area I think that Eclipse will be a fierce competitor to Apache. One of the challenges I have is to find a development (and production) platform that is easy enough to put in the hands of our developers. Keep in mind that OSGi in itself is possibly too complex for many developers. /Bengt 2010/10/16 Bengt Rodehav <be...@rodehav.com> > 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 >> >>> >> > >> >> >
