servicemix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Westerfeld" <>
Subject Re: [DISCUSS] ServiceMix 5.0.0
Date Thu, 17 Feb 2011 13:37:49 GMT
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é<> 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)



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 :
> Twitter :
> Linkedin :
> Skype: cmoulliard
> On Wed, Feb 16, 2011 at 10:25 PM, Jean-Baptiste Onofré<>  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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message