Re : [DISCUSS] Rebooting ServiceMix 5

["jb@nanthrax.net" <jb...@nanthrax.net>]

Hi Guillaume,

as already discussed, I'm fully agree about all points.

I will add one point:  we have to work on the website and doc. I propose to use the Karaf approach using scalate. Gert and I worked on a new style/css. We can leave the wiki as it is and start from scratch for the new doc and website.

I will populate the roadmap page.

Regards
JB

----- Reply message -----
De : "Guillaume Nodet" <gn...@gmail.com>
Pour : "dev" <de...@servicemix.apache.org>
Objet : [DISCUSS] Rebooting ServiceMix 5
Date : lun., juin 27, 2011 17:54


Last week, I've been discussing with a few committers about the
ServiceMix roadmap.
So I'd like to communicate those thoughts to a wider audience.

We've been discussing already that the value of ServiceMix (which was
the JBI layer in ServiceMix 3
and the container side in ServiceMix 4) has moved mostly to Camel and
Karaf respectively.  The remainining
bits are mostly the NMR.  However, the value of the NMR is not in the
NMR itself, but rather the NMR was
supposed to enable various container-level features.  However, we
haven't really built those features so
that the *real* value of the NMR is not that high currently.

So, what we've been discussing is to focus on that added value in a
more transparent way by tweaking
Camel a bit to support global interceptors, so that one could deploy
the real routes without having to
force the use of a specific transport such as the current NMR.  This
way, a user could test / develop
the Camel routes or take existing Camel routes and deploy them in
ServiceMix, thereby transparently
enabling a bunch of useful features.  We've been thinking about adding
message tracing / timing / auditing,
sending test messages, security checks, viewing flows, persistent
modification of camel
routes, camel route versioning, etc...  That need to be coupled with a
web console similar to the
Camel / ActiveMQ web consoles, to actually display all the data to
provide useful information for monitoring
Camel routes and help diagnosing problems in production for example.
There's really nothing magically new
here and some of those features were actually part of ServiceMix 3,
but without much focus on those and
they have always kept a bit on the side.  The idea is really to make
ServiceMix the best possible container
for deploying Camel based integration.

Additional things that could be pushed inside ServiceMix 5 would be a
Tomcat based container deployment
option (for those that don't need OSGi), a new manual similar to what
we have in Karaf (maybe reusing
parts of it).  We'd also need a new website (without the technical
doc, as we have for Karaf I think).

On the maintenance of the JBI components and NMR/JBI layer, I think we
should keep them in smx4.
People wanting to deploy those could easily add a pointer to the
servicemix 4 features descriptors and
deploy the needed features.  So we could officially deprecate those
and tell users they won't be
available in smx5.    This also means that there's really not much to
reuse from smx4, so smx5 would
have its own new and dedicated svn area.

FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
coming months, so those are not
faithful wishes, but really something I want to start implementing asap.

Feedback welcomed!

-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: Re : [DISCUSS] Rebooting ServiceMix 5

[Claus Ibsen <cl...@gmail.com>]

Hi

This is great news. I think this is a big step in the right direction.
As Camel will have a more proficient role in SMX5, and JBI is
deprecated, then SMX5 looks much more appealing to me.
Finding the time I would like to help out as well.

I especially like that the docs will be in svn, so SMX have a chance
to kick-start again with good documentation, so new people can
actually get started with SMX. The current docs is poor at best.

I can foresee that SMX5 may impose some changes in camel-core to be
moved forward. For example I think we should get started to better
support dynamic discovery of interceptors so you can install global
interceptors in SMX5 container, and have those interceptors kick-in
existing running Camel applications. And likewise you should be able
to uninstall those interceptors as well.

That should help with most of ideas from Guillaume so we can do
monitoring, tracing, auditing, etc.

We have some of those thoughts in the Camel 3.0 roadmap
http://camel.apache.org/camel-30-roadmap.html



On Mon, Jun 27, 2011 at 6:46 PM, jb@nanthrax.net <jb...@nanthrax.net> wrote:
> Hi Guillaume,
>
> as already discussed, I'm fully agree about all points.
>
> I will add one point:  we have to work on the website and doc. I propose to use the Karaf approach using scalate. Gert and I worked on a new style/css. We can leave the wiki as it is and start from scratch for the new doc and website.
>
> I will populate the roadmap page.
>
> Regards
> JB
>
> ----- Reply message -----
> De : "Guillaume Nodet" <gn...@gmail.com>
> Pour : "dev" <de...@servicemix.apache.org>
> Objet : [DISCUSS] Rebooting ServiceMix 5
> Date : lun., juin 27, 2011 17:54
>
>
> Last week, I've been discussing with a few committers about the
> ServiceMix roadmap.
> So I'd like to communicate those thoughts to a wider audience.
>
> We've been discussing already that the value of ServiceMix (which was
> the JBI layer in ServiceMix 3
> and the container side in ServiceMix 4) has moved mostly to Camel and
> Karaf respectively.  The remainining
> bits are mostly the NMR.  However, the value of the NMR is not in the
> NMR itself, but rather the NMR was
> supposed to enable various container-level features.  However, we
> haven't really built those features so
> that the *real* value of the NMR is not that high currently.
>
> So, what we've been discussing is to focus on that added value in a
> more transparent way by tweaking
> Camel a bit to support global interceptors, so that one could deploy
> the real routes without having to
> force the use of a specific transport such as the current NMR.  This
> way, a user could test / develop
> the Camel routes or take existing Camel routes and deploy them in
> ServiceMix, thereby transparently
> enabling a bunch of useful features.  We've been thinking about adding
> message tracing / timing / auditing,
> sending test messages, security checks, viewing flows, persistent
> modification of camel
> routes, camel route versioning, etc...  That need to be coupled with a
> web console similar to the
> Camel / ActiveMQ web consoles, to actually display all the data to
> provide useful information for monitoring
> Camel routes and help diagnosing problems in production for example.
> There's really nothing magically new
> here and some of those features were actually part of ServiceMix 3,
> but without much focus on those and
> they have always kept a bit on the side.  The idea is really to make
> ServiceMix the best possible container
> for deploying Camel based integration.
>
> Additional things that could be pushed inside ServiceMix 5 would be a
> Tomcat based container deployment
> option (for those that don't need OSGi), a new manual similar to what
> we have in Karaf (maybe reusing
> parts of it).  We'd also need a new website (without the technical
> doc, as we have for Karaf I think).
>
> On the maintenance of the JBI components and NMR/JBI layer, I think we
> should keep them in smx4.
> People wanting to deploy those could easily add a pointer to the
> servicemix 4 features descriptors and
> deploy the needed features.  So we could officially deprecate those
> and tell users they won't be
> available in smx5.    This also means that there's really not much to
> reuse from smx4, so smx5 would
> have its own new and dedicated svn area.
>
> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
> coming months, so those are not
> faithful wishes, but really something I want to start implementing asap.
>
> Feedback welcomed!
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/