I think raw CXF if quite important... The speed on large streams for example is not yet up to par compared to "native" cxf. Not to mention I don't think we should "Enforce" anything :)
On Oct 15, 2010, at 1:18 AM, Jean-Baptiste Onofré wrote: > Guillaume has greatly summarize our discussion. > > Our discussion starts from some facts: > 1/ JBI is dead. The JBI 2.0 specification will never be released. It's not > due to technical leaks but, as Guillaume said, mainly due to politic reasons. > 2/ All that we can do with JBI could be achieved by Camel: if Camel could > manage most of message format (stream, binary, etc), of course it can manage > XML payload like JBI does. JBI imposes the XML message format whereas Camel > supports it and the developers just need to use it (eventually using a > Normalizer pattern). The MEP is defined in the Camel route itself (depending > of the from(), to(), etc statements). > 3/ The maintenance cycle on the ServiceMix components is lower than the Camel > components. As it's more simple to write Camel components, the Camel > components scope is larger than the ServiceMix components one. There are only > one component present in ServiceMix which is not available in Camel: > servicemix-smpp. I'm gonna submit a patch to Camel proposing a camel-smpp > component. > 4/ in the past, I had in mind to add WSDL publication in all ServiceMix > components to be able to use WS-BPEL in ODE. To be honest, after thinking > about that, I'm not sure if the best way to add BPM in ServiceMix (see later > :)). > > As Guillaume, ServiceMix is really a great brand in OpenSource ESB. We didn't > speak about deleting ServiceMix project, but more adopt a clear position. > > My vision is the following: > - ServiceMix 3 should be marked as deprecated and unmaintained release. > - ServiceMix 4 should stay as it is currently: based on Karaf, adding > ActiveMQ, Camel, CXF and NMR/JBI > - I propose to preparate ServiceMix 5. ServiceMix 5 is clearly an ESB, > In ServiceMix 5, the JBI layer should be set as deprecated. It means that we > always provide the JBI features but not installed by default. The users could > installed it for backward compatibility if required. > ServiceMix 5 is a complete ESB, based on OSGi, gathering: > - Apache Felix + Apache Karaf > - Apache ActiveMQ: more than a message broker, ActiveMQ could be the cluster > and fail-over player > - Apache Camel: the integration and mediation layer, providing the components > and routing bases > - Apache CXF: I think that CXF directly ServiceMix will not make sense. CXF > will be provided by Camel CXF components, that is enough. > - BPM: ServiceMix 5 should embed a BPM engine. ODE requires the usage of XML > as it's based on WS-BPEL. I think that Activiti could be more interesting as > it's based on BPMN2. > - Tooling: ServiceMix 5 should provide more friendly tooling. Especially, > starting to the fact that we use Camel, we can provide a web tool to see, > design and monitor the Camel components and routes. > - Extensions: why not thinking about integrating (as optional or not) others > technologies. For example, I'm thinking about extending the Aries usage, > providing DOSGI using CXF, or supporting EJB3 using OpenEJB/Geronimo. We have > no limit to provide extra features to give a full scoped ESB (I don't see any > others ESBs that is able to cover or extend as ServiceMix). > > So, ServiceMix is not dead at all !!! More over, I think that, with a clear > position, providing and gathering differents technologies, ServiceMix will an > awesome platform, ESB oriented but very extensible. > > So welcome to the new area of ServiceMix 5 :) > > Regards > JB > > On 10/14/2010 04:35 PM, Guillaume Nodet wrote: >> 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. >> >> 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
