I think what possibly is missing as well in the general context is how much work / thought is behind servicemix-specs.... \
I've heard out on gigs "Well, it is only felix and some command line tools" to which I'll start snickering, because getting EE / JSR services going under Osgi is no easy feat. Karaf as a management console and deployment environment is pretty darn savvy. Not to mention that Yes, you can use it as an EE container. But it isn't forcing you to do that :) Things like being able to deploy webapps. Working with some snoracle buddies - I can also say that the builds we have are pretty "stellar".... It is a pretty magnificent deployment/cloud/maven integrated "device" as in - Nice for sysadmins I think what really would be neat is a focus on extremely fast DOSGI - i.e wire protocol fast. I know I want that. In a way I think SMX4 is "hard to wrap your head around" as it can be... OSGi, EE, JBI, WebContainer or all of the above. - You pick! /je On Oct 15, 2010, at 12:52 AM, Chris Custine wrote: > Adrian's comments mirror my thoughts almost exactly. Over time, I would > like to see increasingly tighter integration with Camel such that Camel is > more of a first class citizen in ServiceMix alongside the NMR. This is > already progressing nicely, but if we continue to pursue tight knit > integration with Camel and selectively de-emphasize aging technologies like > JBI over time, the confusion about how to use ServiceMix, Camel, and the NMR > together will have more clarity. I think the benefits of using the runtime > services of ServiceMix and NMR as a deployment container and router for > Camel routes is still often overlooked. > > Obviously Karaf should continue to be the core container for runtime > services and OSGi. In lieu of an integration specific standard such as JBI, > OSGi provides a generic model to build internal services and components so > that code is not tied 100% to the integration use case. I see this bringing > comfort to those projects worried about writing a lot of code against a task > specific API or vendor specific product API. > > In general, I am all for streamlining the project over time, so that we do > not have 2 or more generations of the project to divide our attention. With > the current JBI interoperability and shared components releases, I > definitely think we can begin recommending the move to ServiceMix 4 for > existing ServiceMix 3 users. Moving forward with new features and tools > will be much easier if we establish a roadmap for this kind of transition > and we can begin looking forward to these new things without worrying about > limitations of supporting them in legacy code. > > My 2 cents. > > -- > Chris Custine > FuseSource - Open Source Integration:: http://fusesource.com > My Blog :: http://blog.organicelement.com > > > > > On Thu, Oct 14, 2010 at 12: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 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 >>>> >>>> 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
