Hi Guillaume, This is definitively the way to go for SMX5, integrate NMR as the communication layer within SMX and providing features with added value like you propose. BTW, it should also be great if we can externalize the Tx behavior and define it when we will register the Camel Tx endpoints in SMX5 (like jms, jdbc, jpa, ....). That will simplify the development, .... The debate regarding Tomcat <-> SMX5 <--> OSGI will continue in another threads/emails/... but I don t think that packaging SMX5 + Tomcat will help clients/projects as they already have Tomcat, JBoss, WebSphere but require to deploy SMX5 (with or without OSGI) + Camel for Tx purpose, Auditing, Security, Tracing, .... into their container. Do you know a lot of client using TomEE of OpenEJB (http://openejb.apache.org/3.0/apache-tomee.html). No and that will be the case if we promote a TomEE for SMX5.
Just my 2 cents opinion ;-) Regards, Charles On Mon, Jun 27, 2011 at 5:54 PM, Guillaume Nodet <[email protected]> wrote: > 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 >
