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 08:32:30 GMT
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