Well, I don't understand the part about "ServiceMix GL", and while I can spell OBR I haven't grokked it's value yet. But it does sound like I spurred some thinking so that is all good. :)
>>> Jean-Baptiste Onofré<[email protected]> 2/17/2011 9:05 AM >>> 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 > >>
