Hey all, A small comment about the NMR: Currently the NMR requires endpoints to explicitly declare that they want to participate in the cluster. That means I can't create 3 bundles that use the NMR for communication, and then after deploying the bundles to the repository decide on which cluster nodes I want to deploy them, because once an endpoint is cluster targeted, local endpoints are ignored. Maybe I want to start with all three on the same node, and then spread them over multiple machines while the application is running.
I was actually surprised to find that the NMR ignored remote endpoints by default. I my opinion the NMR should consider both local and remote endpoints and then route the request to the most suitable endpoint. That would enable the scenario mentioned above. If I missed something and what I'm describing is already possible then I would be delighted if someone could share that knowledge :) Geert Schuring. > Kurt, > > thanks a lot for your feedback, I will populate the roadmap wiki with > your very interesting comments. > Reading your feedback, I got a new idea around features provisioning: > maybe a kind of auto provisioning. ServiceMix GL could be able to > "resolve" dependencies using a OBR or gather remote services via a kind > of ServiceLocator/ServiceGateway. > Really, I have to write it down :) > > Regards > JB > > On 02/17/2011 02:37 PM, Kurt Westerfeld wrote: >> 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 >> >> > > >
