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. 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. 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. 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. 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>
