Hi, Great idea to spend time and effort to define SMX 5.x roadmap JB.
Regarding to NMR 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 --> Yep, NMR should become the missing layer to allow communication between camel routes deployed in separate bundles or SMX instances. Name should be changed to something less JBI minded because in the perspective you propose, the routing will be made by camel, normalization does not longer exist but nMr wil continue to exchange messages and play a bigger role in transaction handling, clustering with ActiveMQ, ... So I propose that you find a new name for this component. Regards, Charles Moulliard Sr. Principal Solution Architect - FuseSource Apache Committer Blog : http://cmoulliard.blogspot.com Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard Skype: cmoulliard On Wed, Feb 16, 2011 at 10:25 PM, 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 >
