Thanks Guillaume for your answer.
It's exactly in the following way as the discussion we had in October
during Fuse Community Day.
I'm totally agree regarding the survey, it's a good idea to get feedback
from the community and the end-users.
For ServiceMix GL (ex-NMR), we can start to write down and discuss the
features coverage (QoS, remoting/farming capability including instances
sync, ServiceLocator, BPM extension and registry (WSDL for ODE, Activiti
registry, etc), custom registries (ETL jobs definition, MDM data
storage, etc), etc.
It will show to the crowd that ServiceMix spaceship IS NOT JBI, it's
largely more than that :)
I'm sure that some users could think that these features could be part
of others projects (like CXF, ActiveMQ or Camel), but I think that
ServiceMix GL is more transverse and could be glue between these projects.
I'm working on SMX 3.3.3 and 4.3.0 today, I will create the wiki page
tomorrow (I would like to work on SMX documentation and web site too).
Thanks
Regards
JB
On 02/17/2011 04:22 PM, Guillaume Nodet wrote:
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é<[email protected]> 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
