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.
