servicemix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [DISCUSS] ServiceMix 5.0.0
Date Thu, 17 Feb 2011 14:05:49 GMT
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é<jb@nanthrax.net> 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é<jb@nanthrax.net> 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
>  >>

Mime
View raw message