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
>>
