[DISCUSS] ServiceMix 5.0.0

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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

Re: [DISCUSS] ServiceMix 5.0.0

[Gert Vanthienen <ge...@gmail.com>]

L.S.,

I've summarized the basic ideas for these two versions in
https://cwiki.apache.org/confluence/display/SM/Roadmap -- we probably
want to elaborate the NMR and tooling ideas for 5.0.0 a bit more
before we go ahead and change SVN layouts/names of projects/..., but
at least this gives us something to go by.

I think it would be wise to schedule the 4.4.0 release somewhere close
after the Camel 2.7.0 release - we usually get people asking on the
mailing list about upgrading to the next version of Camel as soon as
it's available and this would also force us to do a new release
sooner.  We really want to get rid of these long release cycles and
release things more often.  However, we also want to do something
about the release process itself imho ...

For the next release, I'd like to try an all-in-one release instead of
doing the submodule releases one after the other.  The latter approach
has caused the current 4.3.0 release chain to run for almost 3 months
now, with the initial utils release being done in November so it got
outdated and everything needed to be started over again a month ago.
Doing it all in one go might be a better way - I don't mind
volunteering for the next release round to give that a go myself (just
in case it ends up to be a bad idea while I'm doing it ;)).  If
something is wrong with the release during the vote using this
approach, we can always re-cut the faulty bits and just reuse the
existing tags for the release:perform of the other bits) so I don't
think it will cause a lot of extra work even if the vote gets canceled
a few times).

Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Fri, Feb 18, 2011 at 10:12 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Thanks Guillaume for your answer.
> It's exactly in the following way as the discussion we had in October during
> Fuse Community Day.
>
> I'm totally agree regarding the survey, it's a good idea to get feedback
> from the community and the end-users.
>
> For ServiceMix GL (ex-NMR), we can start to write down and discuss the
> features coverage (QoS, remoting/farming capability including instances
> sync, ServiceLocator, BPM extension and registry (WSDL for ODE, Activiti
> registry, etc), custom registries (ETL jobs definition, MDM data storage,
> etc), etc.
> It will show to the crowd that ServiceMix spaceship IS NOT JBI, it's largely
> more than that :)
> I'm sure that some users could think that these features could be part of
> others projects (like CXF, ActiveMQ or Camel), but I think that ServiceMix
> GL is more transverse and could be glue between these projects.
>
> I'm working on SMX 3.3.3 and 4.3.0 today, I will create the wiki page
> tomorrow (I would like to work on SMX documentation and web site too).
>
> Thanks
> Regards
> JB
>
> On 02/17/2011 04:22 PM, Guillaume Nodet wrote:
>>
>> I agree with your description of 4.4, I would maybe add drop support
>> for jdk 1.5 and maven 2.x too though.
>>
>> For ServiceMix 5, I think things are still a bit blurry.  We discussed
>> a while back about a survey for ServiceMix users.  I think before
>> making any firm plans / roadmap, we should start by asking our users
>> some feedback.  I think FuseSource would happily pay for it and
>> reusing the same host than the CXF and Camel communities did sounds
>> like a good idea to me.  This would give us a good idea or where we
>> should focus -- but I fear documentation will be the first and most
>> important point ;-)   I'll start another thread about that as I really
>> think now is a good time to do it (or at least just after 4.3 is out).
>>
>> That said, I think ServiceMix 5 should definitely be more modular, so
>> leveraging whatever comes from Karaf 3 for features / kar / and ease
>> of building custom distributions would definitely be welcomed.  We
>> need to be able to provide very easily tailored distributions for
>> simple integration, web services, bpel, without being this big thing
>> that some people think servicemix is.
>>
>> On the NMR point, we discussed that back a few months ago too, and I
>> think you're right.  We definitely need to enhance the NMR layer (or
>> whatever we will call it) to provide built-in support for clustering.
>> In addition this remoting capatiblity, the NMR is currently the best
>> way to integrate WSDL based tools such as ODE (as Kurt pointed), so
>> the registry part could play a big role here, especially in a
>> clustered environment.  Though we need to be very careful here as we
>> already tried twice (with flows in smx3 and the clustering engine in
>> smx4) and both have severe limitations that we need to overcome.
>>
>> On Wed, Feb 16, 2011 at 22:25, 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
>>>
>>
>>
>>
>

Re: [DISCUSS] ServiceMix 5.0.0

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Thanks Guillaume for your answer.
It's exactly in the following way as the discussion we had in October 
during Fuse Community Day.

I'm totally agree regarding the survey, it's a good idea to get feedback 
from the community and the end-users.

For ServiceMix GL (ex-NMR), we can start to write down and discuss the 
features coverage (QoS, remoting/farming capability including instances 
sync, ServiceLocator, BPM extension and registry (WSDL for ODE, Activiti 
registry, etc), custom registries (ETL jobs definition, MDM data 
storage, etc), etc.
It will show to the crowd that ServiceMix spaceship IS NOT JBI, it's 
largely more than that :)
I'm sure that some users could think that these features could be part 
of others projects (like CXF, ActiveMQ or Camel), but I think that 
ServiceMix GL is more transverse and could be glue between these projects.

I'm working on SMX 3.3.3 and 4.3.0 today, I will create the wiki page 
tomorrow (I would like to work on SMX documentation and web site too).

Thanks
Regards
JB

On 02/17/2011 04:22 PM, Guillaume Nodet wrote:
> I agree with your description of 4.4, I would maybe add drop support
> for jdk 1.5 and maven 2.x too though.
>
> For ServiceMix 5, I think things are still a bit blurry.  We discussed
> a while back about a survey for ServiceMix users.  I think before
> making any firm plans / roadmap, we should start by asking our users
> some feedback.  I think FuseSource would happily pay for it and
> reusing the same host than the CXF and Camel communities did sounds
> like a good idea to me.  This would give us a good idea or where we
> should focus -- but I fear documentation will be the first and most
> important point ;-)   I'll start another thread about that as I really
> think now is a good time to do it (or at least just after 4.3 is out).
>
> That said, I think ServiceMix 5 should definitely be more modular, so
> leveraging whatever comes from Karaf 3 for features / kar / and ease
> of building custom distributions would definitely be welcomed.  We
> need to be able to provide very easily tailored distributions for
> simple integration, web services, bpel, without being this big thing
> that some people think servicemix is.
>
> On the NMR point, we discussed that back a few months ago too, and I
> think you're right.  We definitely need to enhance the NMR layer (or
> whatever we will call it) to provide built-in support for clustering.
> In addition this remoting capatiblity, the NMR is currently the best
> way to integrate WSDL based tools such as ODE (as Kurt pointed), so
> the registry part could play a big role here, especially in a
> clustered environment.  Though we need to be very careful here as we
> already tried twice (with flows in smx3 and the clustering engine in
> smx4) and both have severe limitations that we need to overcome.
>
> On Wed, Feb 16, 2011 at 22:25, 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
>>
>
>
>

Re: [DISCUSS] ServiceMix 5.0.0

[Guillaume Nodet <gn...@gmail.com>]

I agree with your description of 4.4, I would maybe add drop support
for jdk 1.5 and maven 2.x too though.

For ServiceMix 5, I think things are still a bit blurry.  We discussed
a while back about a survey for ServiceMix users.  I think before
making any firm plans / roadmap, we should start by asking our users
some feedback.  I think FuseSource would happily pay for it and
reusing the same host than the CXF and Camel communities did sounds
like a good idea to me.  This would give us a good idea or where we
should focus -- but I fear documentation will be the first and most
important point ;-)   I'll start another thread about that as I really
think now is a good time to do it (or at least just after 4.3 is out).

That said, I think ServiceMix 5 should definitely be more modular, so
leveraging whatever comes from Karaf 3 for features / kar / and ease
of building custom distributions would definitely be welcomed.  We
need to be able to provide very easily tailored distributions for
simple integration, web services, bpel, without being this big thing
that some people think servicemix is.

On the NMR point, we discussed that back a few months ago too, and I
think you're right.  We definitely need to enhance the NMR layer (or
whatever we will call it) to provide built-in support for clustering.
In addition this remoting capatiblity, the NMR is currently the best
way to integrate WSDL based tools such as ODE (as Kurt pointed), so
the registry part could play a big role here, especially in a
clustered environment.  Though we need to be very careful here as we
already tried twice (with flows in smx3 and the clustering engine in
smx4) and both have severe limitations that we need to overcome.

On Wed, Feb 16, 2011 at 22:25, 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
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: [DISCUSS] ServiceMix 5.0.0

[Charles Moulliard <cm...@gmail.com>]

Good points James !!!

On Thu, Mar 3, 2011 at 10:01 AM, James Strachan <ja...@fusesource.com> wrote:
> On 2 March 2011 07:58, Charles Moulliard <cm...@gmail.com> wrote:
>> Hi,
>>
>> Regarding to the new name of NMR, we could use another acronym --> SML
>> = ServiceMix Messaging Layer or EML = Endpoints Messaging Layer as the
>> main goal of this component will be to deliver messages to endpoints
>> exposed in bundles or in another SMX instances, will also handle
>> transaction between transactional endpoints, audit messages, provide a
>> registry to locate endpoints registered and least but not least
>> provide clustering or clouding
>
> The term NMR has always been a bit confusing as it talks about Routing
> (which then makes folks compare it directly to Camel and then get
> confused as the NMR doesn't really do that much routing - it does as
> much routing as blueprint does with the dynamic proxies to 0....n
> service implementations in the OSGi registry for example).
>
> So how about calling it ServiceMix Registry? For me the big win and
> value of the NMR is its a universal (cross-classloader & bundle)
> registry of logical messaging endpoints that can use any technology
> underneath (ActiveMQ / Camel / CXF / ODE / OpenEJB etc). It then more
> clearly defines the value add ServiceMix brings above and beyond
> Camel; particularly as ServiceMix Registry could easily be a
> distributed (rather than purely in-VM only) registry of endpoints.
>
> --
> James
> -------
> FuseSource
> Email: james@fusesource.com
> Web: http://fusesource.com
> Twitter: jstrachan
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration
>

Re: [DISCUSS] ServiceMix 5.0.0

[James Strachan <ja...@fusesource.com>]

On 2 March 2011 07:58, Charles Moulliard <cm...@gmail.com> wrote:
> Hi,
>
> Regarding to the new name of NMR, we could use another acronym --> SML
> = ServiceMix Messaging Layer or EML = Endpoints Messaging Layer as the
> main goal of this component will be to deliver messages to endpoints
> exposed in bundles or in another SMX instances, will also handle
> transaction between transactional endpoints, audit messages, provide a
> registry to locate endpoints registered and least but not least
> provide clustering or clouding

The term NMR has always been a bit confusing as it talks about Routing
(which then makes folks compare it directly to Camel and then get
confused as the NMR doesn't really do that much routing - it does as
much routing as blueprint does with the dynamic proxies to 0....n
service implementations in the OSGi registry for example).

So how about calling it ServiceMix Registry? For me the big win and
value of the NMR is its a universal (cross-classloader & bundle)
registry of logical messaging endpoints that can use any technology
underneath (ActiveMQ / Camel / CXF / ODE / OpenEJB etc). It then more
clearly defines the value add ServiceMix brings above and beyond
Camel; particularly as ServiceMix Registry could easily be a
distributed (rather than purely in-VM only) registry of endpoints.

-- 
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

Re: [DISCUSS] ServiceMix 5.0.0

[Fernando Ribeiro <we...@fernandoribeiro.eti.br>]

I like the fact that we are changing that name, sounds like yet another step
away from JBI, which has been stale (not to say dead) for a long time now.

Em 02/03/2011 06:28, "Freeman Fang" <fr...@gmail.com>escreveu:

+1

Freeman


On 2011-3-2, at 下午5:23, Charles Moulliard wrote:

> +1 good point Gert
>
>
> On Wed, Mar 2, 2011 at...

-- 
Freeman Fang

------------------------

FuseSource: http://fusesource.com
blog: http://freemanfa...

Re: [DISCUSS] ServiceMix 5.0.0

[Freeman Fang <fr...@gmail.com>]

+1

Freeman
On 2011-3-2, at 下午5:23, Charles Moulliard wrote:

> +1 good point Gert
>
>
> On Wed, Mar 2, 2011 at 9:38 AM, Gert Vanthienen
> <ge...@gmail.com> wrote:
>> L.S.,
>>
>> How about I split out the ideas about the NMR into a separate page
>> linked from the roadmap?  It looks like we first have to get a grip  
>> on
>> what exactly are the requirements and use cases we want to handle  
>> with
>> our new NMR implementation...
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>>
>>
>> On Wed, Mar 2, 2011 at 8:58 AM, Charles Moulliard <cmoulliard@gmail.com 
>> > wrote:
>>> Hi,
>>>
>>> Regarding to the new name of NMR, we could use another acronym -->  
>>> SML
>>> = ServiceMix Messaging Layer or EML = Endpoints Messaging Layer as  
>>> the
>>> main goal of this component will be to deliver messages to endpoints
>>> exposed in bundles or in another SMX instances, will also handle
>>> transaction between transactional endpoints, audit messages,  
>>> provide a
>>> registry to locate endpoints registered and least but not least
>>> provide clustering or clouding
>>>
>>> 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, Mar 2, 2011 at 6:41 AM, Jean-Baptiste Onofré <jb@nanthrax.ne 
>>> t> wrote:
>>>> Hi,
>>>>
>>>> I don't want to split NMR. NMR (or the new proposed name,  
>>>> ServiceMix GL) IS
>>>> ServiceMix 4 :).
>>>> In fact ServiceMix 4 is a premium integration platform for other  
>>>> projects
>>>> (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR.
>>>>
>>>> So basically my answer is no, I prefer to keep NMR as the main  
>>>> ServiceMix
>>>> project.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 03/01/2011 09:42 PM, Michael Van wrote:
>>>>>
>>>>> I was a proponent of splitting NMR off of SMX and making it its  
>>>>> very own
>>>>> TLP.
>>>>> But, if you guys are going to integrate it deeper into SMX, I  
>>>>> can see
>>>>> where
>>>>> that wouldnt' work. ;-)
>>>>>
>>>>
>>>
>>


-- 
Freeman Fang

------------------------

FuseSource: http://fusesource.com
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org

Re: [DISCUSS] ServiceMix 5.0.0

[Charles Moulliard <cm...@gmail.com>]

+1 good point Gert


On Wed, Mar 2, 2011 at 9:38 AM, Gert Vanthienen
<ge...@gmail.com> wrote:
> L.S.,
>
> How about I split out the ideas about the NMR into a separate page
> linked from the roadmap?  It looks like we first have to get a grip on
> what exactly are the requirements and use cases we want to handle with
> our new NMR implementation...
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> On Wed, Mar 2, 2011 at 8:58 AM, Charles Moulliard <cm...@gmail.com> wrote:
>> Hi,
>>
>> Regarding to the new name of NMR, we could use another acronym --> SML
>> = ServiceMix Messaging Layer or EML = Endpoints Messaging Layer as the
>> main goal of this component will be to deliver messages to endpoints
>> exposed in bundles or in another SMX instances, will also handle
>> transaction between transactional endpoints, audit messages, provide a
>> registry to locate endpoints registered and least but not least
>> provide clustering or clouding
>>
>> 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, Mar 2, 2011 at 6:41 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>> Hi,
>>>
>>> I don't want to split NMR. NMR (or the new proposed name, ServiceMix GL) IS
>>> ServiceMix 4 :).
>>> In fact ServiceMix 4 is a premium integration platform for other projects
>>> (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR.
>>>
>>> So basically my answer is no, I prefer to keep NMR as the main ServiceMix
>>> project.
>>>
>>> Regards
>>> JB
>>>
>>> On 03/01/2011 09:42 PM, Michael Van wrote:
>>>>
>>>> I was a proponent of splitting NMR off of SMX and making it its very own
>>>> TLP.
>>>> But, if you guys are going to integrate it deeper into SMX, I can see
>>>> where
>>>> that wouldnt' work. ;-)
>>>>
>>>
>>
>

Re: [DISCUSS] ServiceMix 5.0.0

[Charles Moulliard <cm...@gmail.com>]

Hi,

I think that we should provide a plugin strategy when registering the
endpoint within the transport layer to allow to :
- Register it with new NMR, JBI, JMS, Camel, ... or any other transport layer,
- Define if the endpoint is available localy, remotely,
- If transaction support must be use,
- Idem but for audit,
- Exchange format to be used,
...

example

<endpoint id="uniqueRefKeyId"
registerName="userRegisteringEndpointName" access="local/remote"
transportLayer="EML/jms/camel" transaction="true/false"
audit="true/false" format="text/object/byte"/>

Regards,

Charles

On Thu, Mar 3, 2011 at 9:32 AM, Gert Vanthienen
<ge...@gmail.com> wrote:
> Johan,
>
> Yeah, well the good thing about these use cases is that it gets us
> talking about what we want to achieve in a bit more detail...
>
> For use case 2, I didn't mean to imply using STOMP, it was just about
> using the next version of ActiveMQ for conveying exchanges (at some
> point, Apollo is supposed to be supporting OpenWire again as well).  I
> have altered the description to avoid the confusion though.
>
> I'm actually expecting us to handle use case 1 with some internal seda
> queues or something, similar to what we have now in the NMR.  This
> means that when migrating a route to a remote node, something has to
> trigger the NMR implementation on the first node to start sending the
> same exchanges over the wire instead.  We now have something like this
> for JBI, but that involves altering the route that is sending the
> exchange and adding a cluster registration to it.
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> On Thu, Mar 3, 2011 at 8:16 AM, Johan Edstrom
> <jo...@acj-consulting.com> wrote:
>> Hey!
>>
>> I love the use-cases, I think the name actually should contain bus or esb, since we rightfully can argue that there is no ESB nor BUS without an NMR.
>> UseCase1 :
>>
>> Technically it means the same JVM/Same container, we pick a streaming scenario.
>>
>> Use case 2:
>>
>> I don't see why stomp would help here, an XML payload is a good idea.
>>
>> Use case 3
>>
>> This has more to do with consumer setup than anything else.
>>
>>
>> On Mar 3, 2011, at 12:06 AM, Charles Moulliard wrote:
>>
>>> Thx. Great job.
>>>
>>> Charles
>>>
>>> On Wed, Mar 2, 2011 at 11:09 PM, Gert Vanthienen
>>> <ge...@gmail.com> wrote:
>>>> L.S.,
>>>>
>>>> I created https://cwiki.apache.org/confluence/display/SM/ServiceMix+5+-+NMR+Improvements
>>>> as an initial stab at capturing what we need from our NMR layer.  The
>>>> requirements section list the high-level goals we want to achieve, but
>>>> I think the main thing to work out is the use cases section: what are
>>>> the things we want to be able to do with our new NMR layer
>>>> implementation.  I've added a few obvious use cases but feel to append
>>>> to that list, so we can get a clearer picture of what is covered by
>>>> the buzzwords we listed in the requirements section.
>>>>
>>>> (By the way, I wrote these first few scenario using Camel routes as an
>>>> example, but those obviously cover CXF endpoints and anything else we
>>>> plan to integrate with the NMR as well.)
>>>>
>>>> Regards,
>>>>
>>>> Gert Vanthienen
>>>> ------------------------
>>>> FuseSource
>>>> Web: http://fusesource.com
>>>> Blog: http://gertvanthienen.blogspot.com/
>>>>
>>>>
>>>>
>>>> On Wed, Mar 2, 2011 at 9:38 AM, Gert Vanthienen
>>>> <ge...@gmail.com> wrote:
>>>>> L.S.,
>>>>>
>>>>> How about I split out the ideas about the NMR into a separate page
>>>>> linked from the roadmap?  It looks like we first have to get a grip on
>>>>> what exactly are the requirements and use cases we want to handle with
>>>>> our new NMR implementation...
>>>>>
>>>>> Regards,
>>>>>
>>>>> Gert Vanthienen
>>>>> ------------------------
>>>>> FuseSource
>>>>> Web: http://fusesource.com
>>>>> Blog: http://gertvanthienen.blogspot.com/
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 2, 2011 at 8:58 AM, Charles Moulliard <cm...@gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Regarding to the new name of NMR, we could use another acronym --> SML
>>>>>> = ServiceMix Messaging Layer or EML = Endpoints Messaging Layer as the
>>>>>> main goal of this component will be to deliver messages to endpoints
>>>>>> exposed in bundles or in another SMX instances, will also handle
>>>>>> transaction between transactional endpoints, audit messages, provide a
>>>>>> registry to locate endpoints registered and least but not least
>>>>>> provide clustering or clouding
>>>>>>
>>>>>> 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, Mar 2, 2011 at 6:41 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I don't want to split NMR. NMR (or the new proposed name, ServiceMix GL) IS
>>>>>>> ServiceMix 4 :).
>>>>>>> In fact ServiceMix 4 is a premium integration platform for other projects
>>>>>>> (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR.
>>>>>>>
>>>>>>> So basically my answer is no, I prefer to keep NMR as the main ServiceMix
>>>>>>> project.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 03/01/2011 09:42 PM, Michael Van wrote:
>>>>>>>>
>>>>>>>> I was a proponent of splitting NMR off of SMX and making it its very own
>>>>>>>> TLP.
>>>>>>>> But, if you guys are going to integrate it deeper into SMX, I can see
>>>>>>>> where
>>>>>>>> that wouldnt' work. ;-)
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
>

Re: [DISCUSS] ServiceMix 5.0.0

[Gert Vanthienen <ge...@gmail.com>]

Johan,

Yeah, well the good thing about these use cases is that it gets us
talking about what we want to achieve in a bit more detail...

For use case 2, I didn't mean to imply using STOMP, it was just about
using the next version of ActiveMQ for conveying exchanges (at some
point, Apollo is supposed to be supporting OpenWire again as well).  I
have altered the description to avoid the confusion though.

I'm actually expecting us to handle use case 1 with some internal seda
queues or something, similar to what we have now in the NMR.  This
means that when migrating a route to a remote node, something has to
trigger the NMR implementation on the first node to start sending the
same exchanges over the wire instead.  We now have something like this
for JBI, but that involves altering the route that is sending the
exchange and adding a cluster registration to it.

Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Thu, Mar 3, 2011 at 8:16 AM, Johan Edstrom
<jo...@acj-consulting.com> wrote:
> Hey!
>
> I love the use-cases, I think the name actually should contain bus or esb, since we rightfully can argue that there is no ESB nor BUS without an NMR.
> UseCase1 :
>
> Technically it means the same JVM/Same container, we pick a streaming scenario.
>
> Use case 2:
>
> I don't see why stomp would help here, an XML payload is a good idea.
>
> Use case 3
>
> This has more to do with consumer setup than anything else.
>
>
> On Mar 3, 2011, at 12:06 AM, Charles Moulliard wrote:
>
>> Thx. Great job.
>>
>> Charles
>>
>> On Wed, Mar 2, 2011 at 11:09 PM, Gert Vanthienen
>> <ge...@gmail.com> wrote:
>>> L.S.,
>>>
>>> I created https://cwiki.apache.org/confluence/display/SM/ServiceMix+5+-+NMR+Improvements
>>> as an initial stab at capturing what we need from our NMR layer.  The
>>> requirements section list the high-level goals we want to achieve, but
>>> I think the main thing to work out is the use cases section: what are
>>> the things we want to be able to do with our new NMR layer
>>> implementation.  I've added a few obvious use cases but feel to append
>>> to that list, so we can get a clearer picture of what is covered by
>>> the buzzwords we listed in the requirements section.
>>>
>>> (By the way, I wrote these first few scenario using Camel routes as an
>>> example, but those obviously cover CXF endpoints and anything else we
>>> plan to integrate with the NMR as well.)
>>>
>>> Regards,
>>>
>>> Gert Vanthienen
>>> ------------------------
>>> FuseSource
>>> Web: http://fusesource.com
>>> Blog: http://gertvanthienen.blogspot.com/
>>>
>>>
>>>
>>> On Wed, Mar 2, 2011 at 9:38 AM, Gert Vanthienen
>>> <ge...@gmail.com> wrote:
>>>> L.S.,
>>>>
>>>> How about I split out the ideas about the NMR into a separate page
>>>> linked from the roadmap?  It looks like we first have to get a grip on
>>>> what exactly are the requirements and use cases we want to handle with
>>>> our new NMR implementation...
>>>>
>>>> Regards,
>>>>
>>>> Gert Vanthienen
>>>> ------------------------
>>>> FuseSource
>>>> Web: http://fusesource.com
>>>> Blog: http://gertvanthienen.blogspot.com/
>>>>
>>>>
>>>>
>>>> On Wed, Mar 2, 2011 at 8:58 AM, Charles Moulliard <cm...@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> Regarding to the new name of NMR, we could use another acronym --> SML
>>>>> = ServiceMix Messaging Layer or EML = Endpoints Messaging Layer as the
>>>>> main goal of this component will be to deliver messages to endpoints
>>>>> exposed in bundles or in another SMX instances, will also handle
>>>>> transaction between transactional endpoints, audit messages, provide a
>>>>> registry to locate endpoints registered and least but not least
>>>>> provide clustering or clouding
>>>>>
>>>>> 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, Mar 2, 2011 at 6:41 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I don't want to split NMR. NMR (or the new proposed name, ServiceMix GL) IS
>>>>>> ServiceMix 4 :).
>>>>>> In fact ServiceMix 4 is a premium integration platform for other projects
>>>>>> (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR.
>>>>>>
>>>>>> So basically my answer is no, I prefer to keep NMR as the main ServiceMix
>>>>>> project.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 03/01/2011 09:42 PM, Michael Van wrote:
>>>>>>>
>>>>>>> I was a proponent of splitting NMR off of SMX and making it its very own
>>>>>>> TLP.
>>>>>>> But, if you guys are going to integrate it deeper into SMX, I can see
>>>>>>> where
>>>>>>> that wouldnt' work. ;-)
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
>

Re: [DISCUSS] ServiceMix 5.0.0

[Johan Edstrom <jo...@acj-consulting.com>]

Hey!

I love the use-cases, I think the name actually should contain bus or esb, since we rightfully can argue that there is no ESB nor BUS without an NMR.
UseCase1 :

Technically it means the same JVM/Same container, we pick a streaming scenario.

Use case 2:

I don't see why stomp would help here, an XML payload is a good idea.

Use case 3

This has more to do with consumer setup than anything else.


On Mar 3, 2011, at 12:06 AM, Charles Moulliard wrote:

> Thx. Great job.
> 
> Charles
> 
> On Wed, Mar 2, 2011 at 11:09 PM, Gert Vanthienen
> <ge...@gmail.com> wrote:
>> L.S.,
>> 
>> I created https://cwiki.apache.org/confluence/display/SM/ServiceMix+5+-+NMR+Improvements
>> as an initial stab at capturing what we need from our NMR layer.  The
>> requirements section list the high-level goals we want to achieve, but
>> I think the main thing to work out is the use cases section: what are
>> the things we want to be able to do with our new NMR layer
>> implementation.  I've added a few obvious use cases but feel to append
>> to that list, so we can get a clearer picture of what is covered by
>> the buzzwords we listed in the requirements section.
>> 
>> (By the way, I wrote these first few scenario using Camel routes as an
>> example, but those obviously cover CXF endpoints and anything else we
>> plan to integrate with the NMR as well.)
>> 
>> Regards,
>> 
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>> 
>> 
>> 
>> On Wed, Mar 2, 2011 at 9:38 AM, Gert Vanthienen
>> <ge...@gmail.com> wrote:
>>> L.S.,
>>> 
>>> How about I split out the ideas about the NMR into a separate page
>>> linked from the roadmap?  It looks like we first have to get a grip on
>>> what exactly are the requirements and use cases we want to handle with
>>> our new NMR implementation...
>>> 
>>> Regards,
>>> 
>>> Gert Vanthienen
>>> ------------------------
>>> FuseSource
>>> Web: http://fusesource.com
>>> Blog: http://gertvanthienen.blogspot.com/
>>> 
>>> 
>>> 
>>> On Wed, Mar 2, 2011 at 8:58 AM, Charles Moulliard <cm...@gmail.com> wrote:
>>>> Hi,
>>>> 
>>>> Regarding to the new name of NMR, we could use another acronym --> SML
>>>> = ServiceMix Messaging Layer or EML = Endpoints Messaging Layer as the
>>>> main goal of this component will be to deliver messages to endpoints
>>>> exposed in bundles or in another SMX instances, will also handle
>>>> transaction between transactional endpoints, audit messages, provide a
>>>> registry to locate endpoints registered and least but not least
>>>> provide clustering or clouding
>>>> 
>>>> 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, Mar 2, 2011 at 6:41 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>>>> Hi,
>>>>> 
>>>>> I don't want to split NMR. NMR (or the new proposed name, ServiceMix GL) IS
>>>>> ServiceMix 4 :).
>>>>> In fact ServiceMix 4 is a premium integration platform for other projects
>>>>> (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR.
>>>>> 
>>>>> So basically my answer is no, I prefer to keep NMR as the main ServiceMix
>>>>> project.
>>>>> 
>>>>> Regards
>>>>> JB
>>>>> 
>>>>> On 03/01/2011 09:42 PM, Michael Van wrote:
>>>>>> 
>>>>>> I was a proponent of splitting NMR off of SMX and making it its very own
>>>>>> TLP.
>>>>>> But, if you guys are going to integrate it deeper into SMX, I can see
>>>>>> where
>>>>>> that wouldnt' work. ;-)
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Re: [DISCUSS] ServiceMix 5.0.0

[Charles Moulliard <cm...@gmail.com>]

Thx. Great job.

Charles

On Wed, Mar 2, 2011 at 11:09 PM, Gert Vanthienen
<ge...@gmail.com> wrote:
> L.S.,
>
> I created https://cwiki.apache.org/confluence/display/SM/ServiceMix+5+-+NMR+Improvements
> as an initial stab at capturing what we need from our NMR layer.  The
> requirements section list the high-level goals we want to achieve, but
> I think the main thing to work out is the use cases section: what are
> the things we want to be able to do with our new NMR layer
> implementation.  I've added a few obvious use cases but feel to append
> to that list, so we can get a clearer picture of what is covered by
> the buzzwords we listed in the requirements section.
>
> (By the way, I wrote these first few scenario using Camel routes as an
> example, but those obviously cover CXF endpoints and anything else we
> plan to integrate with the NMR as well.)
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> On Wed, Mar 2, 2011 at 9:38 AM, Gert Vanthienen
> <ge...@gmail.com> wrote:
>> L.S.,
>>
>> How about I split out the ideas about the NMR into a separate page
>> linked from the roadmap?  It looks like we first have to get a grip on
>> what exactly are the requirements and use cases we want to handle with
>> our new NMR implementation...
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>>
>>
>> On Wed, Mar 2, 2011 at 8:58 AM, Charles Moulliard <cm...@gmail.com> wrote:
>>> Hi,
>>>
>>> Regarding to the new name of NMR, we could use another acronym --> SML
>>> = ServiceMix Messaging Layer or EML = Endpoints Messaging Layer as the
>>> main goal of this component will be to deliver messages to endpoints
>>> exposed in bundles or in another SMX instances, will also handle
>>> transaction between transactional endpoints, audit messages, provide a
>>> registry to locate endpoints registered and least but not least
>>> provide clustering or clouding
>>>
>>> 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, Mar 2, 2011 at 6:41 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>>> Hi,
>>>>
>>>> I don't want to split NMR. NMR (or the new proposed name, ServiceMix GL) IS
>>>> ServiceMix 4 :).
>>>> In fact ServiceMix 4 is a premium integration platform for other projects
>>>> (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR.
>>>>
>>>> So basically my answer is no, I prefer to keep NMR as the main ServiceMix
>>>> project.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 03/01/2011 09:42 PM, Michael Van wrote:
>>>>>
>>>>> I was a proponent of splitting NMR off of SMX and making it its very own
>>>>> TLP.
>>>>> But, if you guys are going to integrate it deeper into SMX, I can see
>>>>> where
>>>>> that wouldnt' work. ;-)
>>>>>
>>>>
>>>
>>
>

Re: [DISCUSS] ServiceMix 5.0.0

[Gert Vanthienen <ge...@gmail.com>]

L.S.,

I created https://cwiki.apache.org/confluence/display/SM/ServiceMix+5+-+NMR+Improvements
as an initial stab at capturing what we need from our NMR layer.  The
requirements section list the high-level goals we want to achieve, but
I think the main thing to work out is the use cases section: what are
the things we want to be able to do with our new NMR layer
implementation.  I've added a few obvious use cases but feel to append
to that list, so we can get a clearer picture of what is covered by
the buzzwords we listed in the requirements section.

(By the way, I wrote these first few scenario using Camel routes as an
example, but those obviously cover CXF endpoints and anything else we
plan to integrate with the NMR as well.)

Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Wed, Mar 2, 2011 at 9:38 AM, Gert Vanthienen
<ge...@gmail.com> wrote:
> L.S.,
>
> How about I split out the ideas about the NMR into a separate page
> linked from the roadmap?  It looks like we first have to get a grip on
> what exactly are the requirements and use cases we want to handle with
> our new NMR implementation...
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> On Wed, Mar 2, 2011 at 8:58 AM, Charles Moulliard <cm...@gmail.com> wrote:
>> Hi,
>>
>> Regarding to the new name of NMR, we could use another acronym --> SML
>> = ServiceMix Messaging Layer or EML = Endpoints Messaging Layer as the
>> main goal of this component will be to deliver messages to endpoints
>> exposed in bundles or in another SMX instances, will also handle
>> transaction between transactional endpoints, audit messages, provide a
>> registry to locate endpoints registered and least but not least
>> provide clustering or clouding
>>
>> 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, Mar 2, 2011 at 6:41 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>> Hi,
>>>
>>> I don't want to split NMR. NMR (or the new proposed name, ServiceMix GL) IS
>>> ServiceMix 4 :).
>>> In fact ServiceMix 4 is a premium integration platform for other projects
>>> (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR.
>>>
>>> So basically my answer is no, I prefer to keep NMR as the main ServiceMix
>>> project.
>>>
>>> Regards
>>> JB
>>>
>>> On 03/01/2011 09:42 PM, Michael Van wrote:
>>>>
>>>> I was a proponent of splitting NMR off of SMX and making it its very own
>>>> TLP.
>>>> But, if you guys are going to integrate it deeper into SMX, I can see
>>>> where
>>>> that wouldnt' work. ;-)
>>>>
>>>
>>
>

Re: [DISCUSS] ServiceMix 5.0.0

[Gert Vanthienen <ge...@gmail.com>]

L.S.,

How about I split out the ideas about the NMR into a separate page
linked from the roadmap?  It looks like we first have to get a grip on
what exactly are the requirements and use cases we want to handle with
our new NMR implementation...

Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Wed, Mar 2, 2011 at 8:58 AM, Charles Moulliard <cm...@gmail.com> wrote:
> Hi,
>
> Regarding to the new name of NMR, we could use another acronym --> SML
> = ServiceMix Messaging Layer or EML = Endpoints Messaging Layer as the
> main goal of this component will be to deliver messages to endpoints
> exposed in bundles or in another SMX instances, will also handle
> transaction between transactional endpoints, audit messages, provide a
> registry to locate endpoints registered and least but not least
> provide clustering or clouding
>
> 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, Mar 2, 2011 at 6:41 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi,
>>
>> I don't want to split NMR. NMR (or the new proposed name, ServiceMix GL) IS
>> ServiceMix 4 :).
>> In fact ServiceMix 4 is a premium integration platform for other projects
>> (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR.
>>
>> So basically my answer is no, I prefer to keep NMR as the main ServiceMix
>> project.
>>
>> Regards
>> JB
>>
>> On 03/01/2011 09:42 PM, Michael Van wrote:
>>>
>>> I was a proponent of splitting NMR off of SMX and making it its very own
>>> TLP.
>>> But, if you guys are going to integrate it deeper into SMX, I can see
>>> where
>>> that wouldnt' work. ;-)
>>>
>>
>

Re: [DISCUSS] ServiceMix 5.0.0

[Charles Moulliard <cm...@gmail.com>]

Hi,

Regarding to the new name of NMR, we could use another acronym --> SML
= ServiceMix Messaging Layer or EML = Endpoints Messaging Layer as the
main goal of this component will be to deliver messages to endpoints
exposed in bundles or in another SMX instances, will also handle
transaction between transactional endpoints, audit messages, provide a
registry to locate endpoints registered and least but not least
provide clustering or clouding

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, Mar 2, 2011 at 6:41 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi,
>
> I don't want to split NMR. NMR (or the new proposed name, ServiceMix GL) IS
> ServiceMix 4 :).
> In fact ServiceMix 4 is a premium integration platform for other projects
> (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR.
>
> So basically my answer is no, I prefer to keep NMR as the main ServiceMix
> project.
>
> Regards
> JB
>
> On 03/01/2011 09:42 PM, Michael Van wrote:
>>
>> I was a proponent of splitting NMR off of SMX and making it its very own
>> TLP.
>> But, if you guys are going to integrate it deeper into SMX, I can see
>> where
>> that wouldnt' work. ;-)
>>
>

Re: [DISCUSS] ServiceMix 5.0.0

[Freeman Fang <fr...@gmail.com>]

+1

Freeman
On 2011-3-2, at 下午3:13, Guillaume Nodet wrote:

> I fully agree here.
>
> On Wed, Mar 2, 2011 at 06:41, Jean-Baptiste Onofré <jb...@nanthrax.net>  
> wrote:
>> Hi,
>>
>> I don't want to split NMR. NMR (or the new proposed name,  
>> ServiceMix GL) IS
>> ServiceMix 4 :).
>> In fact ServiceMix 4 is a premium integration platform for other  
>> projects
>> (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR.
>>
>> So basically my answer is no, I prefer to keep NMR as the main  
>> ServiceMix
>> project.
>>
>> Regards
>> JB
>>
>> On 03/01/2011 09:42 PM, Michael Van wrote:
>>>
>>> I was a proponent of splitting NMR off of SMX and making it its  
>>> very own
>>> TLP.
>>> But, if you guys are going to integrate it deeper into SMX, I can  
>>> see
>>> where
>>> that wouldnt' work. ;-)
>>>
>>
>
>
>
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com


-- 
Freeman Fang

------------------------

FuseSource: http://fusesource.com
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org

Re: [DISCUSS] ServiceMix 5.0.0

[Guillaume Nodet <gn...@gmail.com>]

I fully agree here.

On Wed, Mar 2, 2011 at 06:41, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi,
>
> I don't want to split NMR. NMR (or the new proposed name, ServiceMix GL) IS
> ServiceMix 4 :).
> In fact ServiceMix 4 is a premium integration platform for other projects
> (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR.
>
> So basically my answer is no, I prefer to keep NMR as the main ServiceMix
> project.
>
> Regards
> JB
>
> On 03/01/2011 09:42 PM, Michael Van wrote:
>>
>> I was a proponent of splitting NMR off of SMX and making it its very own
>> TLP.
>> But, if you guys are going to integrate it deeper into SMX, I can see
>> where
>> that wouldnt' work. ;-)
>>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: [DISCUSS] ServiceMix 5.0.0

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi,

I don't want to split NMR. NMR (or the new proposed name, ServiceMix GL) 
IS ServiceMix 4 :).
In fact ServiceMix 4 is a premium integration platform for other 
projects (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR.

So basically my answer is no, I prefer to keep NMR as the main 
ServiceMix project.

Regards
JB

On 03/01/2011 09:42 PM, Michael Van wrote:
> I was a proponent of splitting NMR off of SMX and making it its very own TLP.
> But, if you guys are going to integrate it deeper into SMX, I can see where
> that wouldnt' work. ;-)
>

Re: [DISCUSS] ServiceMix 5.0.0

[Michael Van <mv...@comcast.net>]

I was a proponent of splitting NMR off of SMX and making it its very own TLP. 
But, if you guys are going to integrate it deeper into SMX, I can see where
that wouldnt' work. ;-)

-- 
View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-ServiceMix-5-0-0-tp3388430p3405676.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

Re: [DISCUSS] ServiceMix 5.0.0

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi all,

FYI

1/ I've updated the roadmap wiki page to write down some discussed ideas:
http://servicemix.apache.org/roadmap.html

2/ Chris made a very professional and beautiful website mock some weeks 
ago. I've sent an e-mail to Chris to get the sources, add more content 
and check how to promote it to http://servicemix.apache.org (we will 
still have a link to the confluence wiki).

3/ I'm working on ServiceMix documentation to include NMR part, etc and 
especially a ServiceMix architecture, present and future section.

4/ I like the Guillaume's idea about the survey. How can we make 
progress around that ? As CXF and Camel did it before, we can request 
help to the CXF/Camel communities to prepare the survey. @Dan, @Claus, 
could you help us around the survey ?

5/ ServiceMix 4.3.0 release vote is in progress. I would like to release 
ServiceMix 3.4.0 as a maintenance release. I propose the following 
release policy:
* We maintain one release "active". Currently it's ServiceMix 4.x, but 
it will become ServiceMix 5.x as soon as a first RC is out.
* We maintain one maintenance release. Currently it's ServiceMix 3.x, 
but it will become ServiceMix 4.x as soon as a first ServiceMix 5 RC is out.
* We deprecate the previous releases. Currently, it's ServiceMix 3.2, 
3.1, 3.0. When ServiceMix 5 RC is out, ServiceMix 3.x will be deprecated.

WDYT ?

Thanks
Regards
JB

On 02/16/2011 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

Re: [DISCUSS] ServiceMix 5.0.0

[Geert Schuring <ge...@schuring.eu>]

Hey all,

A small comment about the NMR: Currently the NMR requires endpoints to
explicitly declare that they want to participate in the cluster. That
means I can't create 3 bundles that use the NMR for communication, and
then after deploying the bundles to the repository decide on which cluster
nodes I want to deploy them, because once an endpoint is cluster targeted,
local endpoints are ignored. Maybe I want to start with all three on the
same node, and then spread them over multiple machines while the
application is running.

I was actually surprised to find that the NMR ignored remote endpoints by
default. I my opinion the NMR should consider both local and remote
endpoints and then route the request to the most suitable endpoint. That
would enable the scenario mentioned above.

If I missed something and what I'm describing is already possible then I
would be delighted if someone could share that knowledge :)

Geert Schuring.

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

Re: [DISCUSS] ServiceMix 5.0.0

[Kurt Westerfeld <kw...@novell.com>]

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é<jb...@nanthrax.net> 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é<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
>  >>

Re: [DISCUSS] ServiceMix 5.0.0

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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

Re: [DISCUSS] ServiceMix 5.0.0

[Kurt Westerfeld <kw...@novell.com>]

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

Re: [DISCUSS] ServiceMix 5.0.0

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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

Re: [DISCUSS] ServiceMix 5.0.0

[Charles Moulliard <cm...@gmail.com>]

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
>

Re: [DISCUSS] ServiceMix 5.0.0

[Gert Vanthienen <ge...@gmail.com>]

L.S.,


Yeah, I do agree that now that the 4.3.0 release is out, we probably
want to focus on the documentation again.  We can merge the ideas
page, but I'd really love to try and get a shorter release cycle next
time around, so let's try not to get ahead of ourselves with picking
up new features.  A good, clean 4.4.0 build with new version of CXF,
Camel and ActiveMQ is worth a lot in itself to many users, especially
if we can get that done together with a nice set of docs.  We can
obviously add new stuff too if we like, but I would suggest we aim at
those two goals in the first place.

About the survey, I'm open to the idea and it would be great to learn
what our users have to say.  I just wonder if we shouldn't try to get
our act together first before we do the survey.  Right now, doing the
survey would no doubt yield a lot of ideas and remarks we're already
aware of: the lack of good documentation, the length of the release
cycles, the website, ...  If we can address those concerns in our next
release, we might get more relevant ideas from a survey afterwards.


Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Tue, Mar 8, 2011 at 9:44 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi all,
>
> I guess that you've already seen that Gert and I updated the ServiceMix
> website:
> http://servicemix.apache.org
>
> We're still working on the website and documentation, so we will have
> updated soon.
>
> Related to this thread, we created a roadmap wiki page to write down our
> discussions:
> http://servicemix.apache.org/roadmap.html
> Feel free to edit the wiki page to append some ideas/thoughts.
> I think that I will merge the idea wiki page:
> http://servicemix.apache.org/ideas.html
> into the roadmap. After we will be able to prioritize in the releases
> schedule.
>
> Anyway, I like the Guillaume's idea about a ServiceMix survey to get a
> feedback from the community.
> I would like to make progress around this topic. Could we have some help
> around that ?
>
> Thanks
> Regards
> JB
>
> On 02/16/2011 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
>

Re: [DISCUSS] ServiceMix 5.0.0

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi all,

I guess that you've already seen that Gert and I updated the ServiceMix 
website:
http://servicemix.apache.org

We're still working on the website and documentation, so we will have 
updated soon.

Related to this thread, we created a roadmap wiki page to write down our 
discussions:
http://servicemix.apache.org/roadmap.html
Feel free to edit the wiki page to append some ideas/thoughts.
I think that I will merge the idea wiki page:
http://servicemix.apache.org/ideas.html
into the roadmap. After we will be able to prioritize in the releases 
schedule.

Anyway, I like the Guillaume's idea about a ServiceMix survey to get a 
feedback from the community.
I would like to make progress around this topic. Could we have some help 
around that ?

Thanks
Regards
JB

On 02/16/2011 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

Re: [DISCUSS] ServiceMix 5.0.0

[qhoster <qh...@yahoo.com>]

Going to try the software tomorrow so will have a feedback shortly.

Thanks,

-----
Hosting  and domains .
--
View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-ServiceMix-5-0-0-tp3388430p3624594.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.