NMR has all sorts of uses when you start looking at systems management and monitoring. For example the entire audit feature could be bolstered to be a high-value addon to any application which is wired to use the NMR. The biggest eyesore to me for using Servicemix from an embedding perspective is the trickiness in using the features-maven-plugin to prepare your application on top of Karaf/SMX. I think great attention should be paid to that part of the build, and I realize you have already called it out. From an end-user perspective, it would be *really great* to separate all of our sub-components features.xml files into plain-old dependencies and have them joined together in an assembly process in a much more straightforward way. The handstands we have to do now with the assembly plugin and features plugin is really a big time soak. I can't also stress enough that tooling is the biggest obstacle to adoption to Servicemix, and if the team focuses there then it will get a big win. I realize that a lot of what Servicemix now relies upon is related to OSGi. But if I could tighten my edit/compile/deploy/debug cycle I would be really happy. In a way, the OSGi world has actually lessened my ability to do everything from maven--at least I don't know how to do the deploy step with OSGi. In the SMX3 JBI world, there was the jbi maven deployment mechanism, and I don't know what the equivalent is on SMX4. I also like the idea of a management console. I really like the concepts around the Felix web console, and if you can simply install a bunch of additional Servicemix plugins to that it would be great. Some things I'd like to see are: Dynamic graphic/vector diagrams of the wires of components and interconnections Graphical depiction of message flow Statistical graphs A *much* better log facility--perhaps with a hierarchy of sorts to show where messages are emanating from I think the Servicemix team needs to become very much an ESB "rails" model. Become very very opinionated about the conventions used to create a fully managed, monitored and audited service deployment container. For example, if I do this X,Y,Z step or use these annotations, then my service plugs right into the management console for the ability to see it with additional metadata, graphs, etc. The big catharsis for me in going to SMX4 was all the crap I don't have to do anymore in building a greenfield application, or even refactoring an existing application. I no longer need to worry about logging, getting all the third party libs to play nice with centralized logs, dealing with configuration files, setup of integration tests, figuring out my packaging model, etc. etc. etc. To me, it was a beautiful thing to not have to worry myself with these things any longer. Now, to make the next leap, I think services must gain the same benefits. Remove away the stuff we have to do in order to diagnose issues in the field, such as where messages are routing visually, understand the service deployment ecology that your service lives in, be able to flip over to a graphical view (ala Visual VM) to watch a graph of messages flow by, understand bottlenecks, squelch down logs to just look at a few inter-related categories, etc. If NMR stays biased enough to WSDL, one can imagine that part of this diagnostic infrastructure would be on-the-fly method testing, similar to the MBeans plugin for Visual VM. Also, while I *hate* WSDL's complexity, it does serve a great purpose in providing descriptive services and a mantle on which some of these diagnostic services can be built. If you rip out that bias and don't replace it with something, then SMX++ is going to lose out on the opportunity to have this metadata drive higher-order services. I think emphasizing Camel is the right direction, especially considering the tooling is on its way, but don't lose sight of the fact that WSDL-based services like ODE are important; leave enough WSDL-based messaging in place that the JBI components such as this can still play nice. Well, that's my $.02 for the day. Hope it helps.
>>> Jean-Baptiste Onofré<[email protected]> 2/17/2011 3:32 AM >>> Totally agree Charles and thanks a lot for your feedback. NMR is too JBI related and not really representative of the NMR futures. For me, NMR is a kind a glue between SMX instances, SMX and Camel, etc. So, it's a kind of gateway between ServiceMix instances and tiers layer (like Camel, or DOSGi glue using CXF, etc). Regarding this, I propose: ServiceMix GL (Gateway Layer) WDYT ? Regards JB On 02/17/2011 09:15 AM, Charles Moulliard wrote: > 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 >>
