servicemix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [DISCUSS] ServiceMix 5.0.0
Date Thu, 17 Feb 2011 15:22:30 GMT
I agree with your description of 4.4, I would maybe add drop support
for jdk 1.5 and maven 2.x too though.

For ServiceMix 5, I think things are still a bit blurry.  We discussed
a while back about a survey for ServiceMix users.  I think before
making any firm plans / roadmap, we should start by asking our users
some feedback.  I think FuseSource would happily pay for it and
reusing the same host than the CXF and Camel communities did sounds
like a good idea to me.  This would give us a good idea or where we
should focus -- but I fear documentation will be the first and most
important point ;-)   I'll start another thread about that as I really
think now is a good time to do it (or at least just after 4.3 is out).

That said, I think ServiceMix 5 should definitely be more modular, so
leveraging whatever comes from Karaf 3 for features / kar / and ease
of building custom distributions would definitely be welcomed.  We
need to be able to provide very easily tailored distributions for
simple integration, web services, bpel, without being this big thing
that some people think servicemix is.

On the NMR point, we discussed that back a few months ago too, and I
think you're right.  We definitely need to enhance the NMR layer (or
whatever we will call it) to provide built-in support for clustering.
In addition this remoting capatiblity, the NMR is currently the best
way to integrate WSDL based tools such as ODE (as Kurt pointed), so
the registry part could play a big role here, especially in a
clustered environment.  Though we need to be very careful here as we
already tried twice (with flows in smx3 and the clustering engine in
smx4) and both have severe limitations that we need to overcome.

On Wed, Feb 16, 2011 at 22:25, Jean-Baptiste Onofré <> wrote:
> Hi all,
> As you know, ServiceMix 4.3.0 release has been submitted to VOTE. If it's
> fine, the release will be available before the end of this week.
> In the mean time, I'm testing ServiceMix 3 (especially around Components) to
> be able to submit ServiceMix 3.3.3 release to vote tonight or tomorrow
> morning.
> It's time to deal with the ServiceMix roadmap :)
> I think it makes sense to prepare ServiceMix 4.4.0 with the following
> enhancements:
> - powered by Karaf 2.2.0
> - dependencies upgrade: Aries 0.3, Camel 2.7 (depending of the timing), CXF
> 2.3.3, etc
> - bug fixing in ServiceMix modules: components, utils, specs, NMR.
> - features improving (avoid to override tiers features such as the Camel
> one)
> - build improving (especially around the add-features-to-repo goal and
> dependency set).
> - documentation and website. It's known issue. Before releasing ServiceMix
> 4.4.0, the documentation should be improved. Some of us are already involved
> (especially Gert), but we need to be in commando mode for this important
> task.
> To summarize, ServiceMix 4.4.0 will be a maintenance release, mainly
> containing bug fixed and dependencies update.

> Anyway, I think that we need to prepare the next major ServiceMix release:
> ServiceMix 5.0.0.
> I would like to split the discussion in three parts:
> 1/ Architecture/Design update
> As discussed before, JBI support should set as deprecated but only available
> as optional feature.
> Regarding this, I deeply think that NMR is a really plus value module.
> Too much people are thinking that ServiceMix 4 NMR is only the JBI
> implementation support in ServiceMix. It's too restrictive.
> NMR could have a key role in ServiceMix. I've some ideas in mind:
> - better relationship between NMR and Camel
> - generic clustering/farming/clouding support
> - transaction/distributed transaction
> - service registry and service locator
> - etc
> I'm quite sure that lot of us have others ideas :)
> I propose to create a roadmap page in the ServiceMix wiki to discuss of that
> and draft the future architecture of the NMR and ServiceMix 5.
> 2/ Tooling
> We're all agree that our integrated modules are rock solid: karaf, nmr,
> camel, cxf, etc.
> Of course, we have to provide new features, improve some parts, etc. There's
> no discuss around that.
> However, I think that we need to provide some tooling. I don't talk about
> killer tool to do every thing, but at least, some tool to increase the
> adoption of ServiceMix for the production administrator.
> For instance, just a clean console for monitoring and simple management of
> ServiceMix will provide a good start for administrator.
> Maybe I'm wrong, but I think that ServiceMix is really great for a developer
> and an integration team. However, I'm quite sure that the administrator (the
> same guy who uses the WebSphere or Weblogic console) is expecting a simple
> console for monitoring a production running environment.
> 3/ Infra update
> The current svn repo organization is not very flexible.
> The smx4 repo module should be rename in smx.
> In this module the features module should be renamed as runtime.
> It means that we will have:
> - smx3 for ServiceMix 3 (maintenance reason)
> - smx (moved from smx4)
> -- bundles
> -- specs
> -- nmr
> -- obr
> -- runtime
> WDYT ?
> Thanks all
> Regards
> JB

Guillaume Nodet
Open Source SOA

View raw message