[DISCUSS] ServiceMix 5.0.0

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] ServiceMix 5.0.0

Jean-Baptiste Onofré
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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Charles Moulliard
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é <[hidden email]> 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
>
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Email: [hidden email]
Twitter : @cmoulliard, @fusenews
Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Jean-Baptiste Onofré
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é<[hidden email]>  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
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Kurt Westerfeld
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é<[hidden email]> 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é<[hidden email]>  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
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Jean-Baptiste Onofré
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é<[hidden email]> 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é<[hidden email]> 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
>  >>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Kurt Westerfeld
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é<[hidden email]> 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é<[hidden email]> 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é<[hidden email]> 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
>  >>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Geert Schuring
In reply to this post by Jean-Baptiste Onofré
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é<[hidden email]> 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é<[hidden email]> 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
>>  >>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Guillaume Nodet
Administrator
In reply to this post by Jean-Baptiste Onofré
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é <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Jean-Baptiste Onofré
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é<[hidden email]>  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
>>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Gert Vanthienen
Administrator
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é <[hidden email]> 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é<[hidden email]>
>>  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
>>>
>>
>>
>>
>
Regards,

Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Jean-Baptiste Onofré
In reply to this post by Jean-Baptiste Onofré
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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Michael Van
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. ;-)
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Jean-Baptiste Onofré
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. ;-)
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Guillaume Nodet
Administrator
I fully agree here.

On Wed, Mar 2, 2011 at 06:41, Jean-Baptiste Onofré <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Charles Moulliard
In reply to this post by Jean-Baptiste Onofré
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é <[hidden email]> 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. ;-)
>>
>
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Email: [hidden email]
Twitter : @cmoulliard, @fusenews
Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Gert Vanthienen
Administrator
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 <[hidden email]> 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é <[hidden email]> 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. ;-)
>>>
>>
>
Regards,

Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Charles Moulliard
+1 good point Gert


On Wed, Mar 2, 2011 at 9:38 AM, Gert Vanthienen
<[hidden email]> 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 <[hidden email]> 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é <[hidden email]> 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. ;-)
>>>>
>>>
>>
>
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Email: [hidden email]
Twitter : @cmoulliard, @fusenews
Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Freeman-2
In reply to this post by Guillaume Nodet
+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é <[hidden email]>  
> 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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Freeman-2
In reply to this post by Charles Moulliard
+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
> <[hidden email]> 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 <[hidden email]
>> > 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é <[hidden email]
>>> 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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] ServiceMix 5.0.0

Fernando Ribeiro
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" <[hidden email]>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...
12