You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2007/10/04 21:25:02 UTC
ServiceMix 4.0 modularity
I'd like to make ServiceMix 4.0 as modular as possible. This would
mean that ServiceMix 4.0 main distribution would come with the minimal
set, while additional features could be provisioned and configured
using OBR, the Deployment Admin or our provisioning system.
Such features could include:
* an activemq broker
* an apache ds server
* jbi 1.0 compatibility layer
* jaxws support
* ...
Although from a project perspective, if we could split these features
in different projects, that would make things easier to release: i.e.
release a single "feature" at a time, rather than releasing everything
each time. Kinda like maven does with its plugins.
Thoughts ?
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4.0 modularity
Posted by Guillaume Nodet <gn...@gmail.com>.
I guess the idea of a self-provisionning application is somewhat
unrelated to the release cycle of the different bits of the
application. It seems people are a bit scared to split the lifecycle
soon. So let's work on a monolithic release cycle and see how it
goes. i think things should be easier once the API is finished.
As for an example, the components in ServiceMix are mostly independant
of each other, and mostly independant of the core container (they are
closely tied to servicemix-common though), and imho it should be easy
to split these lifecycles... (though I don't want to do that now, I'd
rather work on the 4.0 branch).
On 10/5/07, Chris Custine <cc...@apache.org> wrote:
> I agree that eventually you will have certain components that have their own
> release cycles seperate from the core components. I think it will take
> several releases of all components as an entire system before you will be
> comfortable splitting things into seperate sub-projects, but as the core
> components mature and stabilize I think it will be a natural desire to have
> more frequent releases of the optional components.
>
> The dependency management issues mentioned by Bruce and Kit are valid, but
> don't forget that the bundles are able to specify required version
> information for their own dependencies. So the dependency management issue
> is more about shipping a properly working default configuration with the
> main ServiceMix distribution than about the seperate releases of components.
>
> I like Guillaume's idea of offering a basic image that is capable of
> provisioning itself from a managed OBR repository. This could also allow a
> user to configure their own customized provisioning configuration similar to
> kickstart files for Linux distributions. I think you will also want to
> offer a fully loaded and self contained image that already has all of the
> components available, but the auto-provisioned basic image will be very
> useful for a lot of users I would think.
>
> Thanks,
> Chris
>
>
> On 10/4/07, Kit Plummer <ki...@gmail.com> wrote:
> >
> > Yes you are crazy.
> >
> > I have to agree - dependency hell is not something I'd like to have to
> > overcome. Eclipse's deal is a nice example.
> >
> > Kit
> >
> > Sent from my iPhone
> >
> > On Oct 4, 2007, at 4:31 PM, "Bruce Snyder" <br...@gmail.com>
> > wrote:
> >
> > > On 10/4/07, Guillaume Nodet <gn...@gmail.com> wrote:
> > >> I'd like to make ServiceMix 4.0 as modular as possible. This would
> > >> mean that ServiceMix 4.0 main distribution would come with the
> > >> minimal
> > >> set, while additional features could be provisioned and configured
> > >> using OBR, the Deployment Admin or our provisioning system.
> > >> Such features could include:
> > >> * an activemq broker
> > >> * an apache ds server
> > >> * jbi 1.0 compatibility layer
> > >> * jaxws support
> > >> * ...
> > >>
> > >> Although from a project perspective, if we could split these features
> > >> in different projects, that would make things easier to release: i.e.
> > >> release a single "feature" at a time, rather than releasing
> > >> everything
> > >> each time. Kinda like maven does with its plugins.
> > >
> > > I've always thought the idea of separate release cycles for different
> > > components/features was a good one. This allows for individual
> > > components to be released as they're ready. However, I've begun to
> > > reconsider this recently. Independent component releases seem like a
> > > good idea until the developer has trouble and then begins to upgrade
> > > components independently resulting in a mish-mash of versions which
> > > can cause a laundry list of other problems.
> > >
> > > It seems to me that we should not push this responsibility onto the
> > > developer because it causes them more trouble than its worth. Not
> > > unlike recent Eclipse releases, ServiceMix is a container with many
> > > modules and I think *we* should bear the burden of making each module
> > > work together to provide an overall ServiceMix release.
> > >
> > > An alternative approach would be to mix independent component releases
> > > with overall ServiceMix releases. This would give us the ability to
> > > release components independently while still providing a major release
> > > of all components packaged together as ServiceMix, say, four times a
> > > year.
> > >
> > > Am I crazy?
> > >
> > > Bruce
> > > --
> > > perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!
> > > G;6%I;\"YC;VT*"
> > > );'
> > >
> > > Apache ActiveMQ - http://activemq.org/
> > > Apache ServiceMix - http://servicemix.org/
> > > Apache Geronimo - http://geronimo.apache.org/
> > > Castor - http://castor.org/
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4.0 modularity
Posted by Guillaume Nodet <gn...@gmail.com>.
Yeah, that's what I have been working on for ServiceMix 4.0.
The core module contains the implementation of the api module. Both
are not tied to OSGi at all. The OSGi bits and wiring bits are all
done using spring-osgi in the nmr nodule.
That way, ServiceMix core container is independant of both OSGi and
Spring and can be easily enbedded. This works because I have
introduced internal registries in ServiceMix api, which are
automatically populated from the OSGi registry using spring service
trackers.
So using it in a non OSGi environment basically means that you have to
register the services using ServiceMix api instead of registering them
in the OSGi registry, but everything else should work the same.
On 10/5/07, Chris Custine <cc...@apache.org> wrote:
> On 10/4/07, Bruce Snyder <br...@gmail.com> wrote:
> >
> > On 10/4/07, Chris Custine <cc...@apache.org> wrote:
> > > I agree that eventually you will have certain components that have their
> > own
> > > release cycles seperate from the core components. I think it will take
> > > several releases of all components as an entire system before you will
> > be
> > > comfortable splitting things into seperate sub-projects, but as the core
> > > components mature and stabilize I think it will be a natural desire to
> > have
> > > more frequent releases of the optional components.
> >
> > Agreed.
> >
> > > The dependency management issues mentioned by Bruce and Kit are valid,
> > but
> > > don't forget that the bundles are able to specify required version
> > > information for their own dependencies. So the dependency management
> > issue
> > > is more about shipping a properly working default configuration with the
> > > main ServiceMix distribution than about the seperate releases of
> > components.
> >
> > That's a good point and something I forgot about. I guess we'll need
> > to relax any static version requirements once the core stablizes so
> > that we can allow a wider range of acceptable versions of various
> > components.
> >
> > > I like Guillaume's idea of offering a basic image that is capable of
> > > provisioning itself from a managed OBR repository. This could also
> > allow a
> > > user to configure their own customized provisioning configuration
> > similar to
> > > kickstart files for Linux distributions. I think you will also want to
> > > offer a fully loaded and self contained image that already has all of
> > the
> > > components available, but the auto-provisioned basic image will be very
> > > useful for a lot of users I would think.
> >
> > I think this is a good paradigm as well. However, a question arose
> > today about continuing to allow ServiceMix to be embedded in any old
> > Java app. Some folks may want an OSGi container to be started when
> > embedding ServiceMix, and some may not. All I'm saying is that we need
> > to keep this in mind as a requirement because there are a fair amount
> > of users who are embedding ServiceMix today.
>
>
> I have had to think about this same issue with Apache Directory Server.
> ApacheDS has many users that embed as well as many users of the standalone
> server and this will be an issue for us as we move the server to an OSGi
> container as well. It may be different for ServiceMix, but for ApacheDS I
> want to be able to offer the ability to embed without using OSGi or Spring
> at all.
>
> I haven't worked out all the details yet, but I am thinking about a
> component that contains all of the OSGi specific code and manages the server
> components which are just library bundles with OSGi Manifest headers so that
> they can also be used as simple jar files outside of OSGi. If you wanted to
> embed, then the OSGi component is not used, and instead you could have a
> facade that basically does what the standalone server does today (use Spring
> to load app context and wire components), or just wire the components up
> directly in the user's own code (ADS has people doing this as well). So
> this basically exposes 3 distinct use cases with progressively lower levels
> of integration. Now the trick is to accomplish this without introducing a
> maintenance nightmare. :-)
>
> Thanks,
> Chris
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4.0 modularity
Posted by Chris Custine <cc...@apache.org>.
On 10/4/07, Bruce Snyder <br...@gmail.com> wrote:
>
> On 10/4/07, Chris Custine <cc...@apache.org> wrote:
> > I agree that eventually you will have certain components that have their
> own
> > release cycles seperate from the core components. I think it will take
> > several releases of all components as an entire system before you will
> be
> > comfortable splitting things into seperate sub-projects, but as the core
> > components mature and stabilize I think it will be a natural desire to
> have
> > more frequent releases of the optional components.
>
> Agreed.
>
> > The dependency management issues mentioned by Bruce and Kit are valid,
> but
> > don't forget that the bundles are able to specify required version
> > information for their own dependencies. So the dependency management
> issue
> > is more about shipping a properly working default configuration with the
> > main ServiceMix distribution than about the seperate releases of
> components.
>
> That's a good point and something I forgot about. I guess we'll need
> to relax any static version requirements once the core stablizes so
> that we can allow a wider range of acceptable versions of various
> components.
>
> > I like Guillaume's idea of offering a basic image that is capable of
> > provisioning itself from a managed OBR repository. This could also
> allow a
> > user to configure their own customized provisioning configuration
> similar to
> > kickstart files for Linux distributions. I think you will also want to
> > offer a fully loaded and self contained image that already has all of
> the
> > components available, but the auto-provisioned basic image will be very
> > useful for a lot of users I would think.
>
> I think this is a good paradigm as well. However, a question arose
> today about continuing to allow ServiceMix to be embedded in any old
> Java app. Some folks may want an OSGi container to be started when
> embedding ServiceMix, and some may not. All I'm saying is that we need
> to keep this in mind as a requirement because there are a fair amount
> of users who are embedding ServiceMix today.
I have had to think about this same issue with Apache Directory Server.
ApacheDS has many users that embed as well as many users of the standalone
server and this will be an issue for us as we move the server to an OSGi
container as well. It may be different for ServiceMix, but for ApacheDS I
want to be able to offer the ability to embed without using OSGi or Spring
at all.
I haven't worked out all the details yet, but I am thinking about a
component that contains all of the OSGi specific code and manages the server
components which are just library bundles with OSGi Manifest headers so that
they can also be used as simple jar files outside of OSGi. If you wanted to
embed, then the OSGi component is not used, and instead you could have a
facade that basically does what the standalone server does today (use Spring
to load app context and wire components), or just wire the components up
directly in the user's own code (ADS has people doing this as well). So
this basically exposes 3 distinct use cases with progressively lower levels
of integration. Now the trick is to accomplish this without introducing a
maintenance nightmare. :-)
Thanks,
Chris
Re: ServiceMix 4.0 modularity
Posted by Bruce Snyder <br...@gmail.com>.
On 10/4/07, Chris Custine <cc...@apache.org> wrote:
> I agree that eventually you will have certain components that have their own
> release cycles seperate from the core components. I think it will take
> several releases of all components as an entire system before you will be
> comfortable splitting things into seperate sub-projects, but as the core
> components mature and stabilize I think it will be a natural desire to have
> more frequent releases of the optional components.
Agreed.
> The dependency management issues mentioned by Bruce and Kit are valid, but
> don't forget that the bundles are able to specify required version
> information for their own dependencies. So the dependency management issue
> is more about shipping a properly working default configuration with the
> main ServiceMix distribution than about the seperate releases of components.
That's a good point and something I forgot about. I guess we'll need
to relax any static version requirements once the core stablizes so
that we can allow a wider range of acceptable versions of various
components.
> I like Guillaume's idea of offering a basic image that is capable of
> provisioning itself from a managed OBR repository. This could also allow a
> user to configure their own customized provisioning configuration similar to
> kickstart files for Linux distributions. I think you will also want to
> offer a fully loaded and self contained image that already has all of the
> components available, but the auto-provisioned basic image will be very
> useful for a lot of users I would think.
I think this is a good paradigm as well. However, a question arose
today about continuing to allow ServiceMix to be embedded in any old
Java app. Some folks may want an OSGi container to be started when
embedding ServiceMix, and some may not. All I'm saying is that we need
to keep this in mind as a requirement because there are a fair amount
of users who are embedding ServiceMix today.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: ServiceMix 4.0 modularity
Posted by Chris Custine <cc...@apache.org>.
I agree that eventually you will have certain components that have their own
release cycles seperate from the core components. I think it will take
several releases of all components as an entire system before you will be
comfortable splitting things into seperate sub-projects, but as the core
components mature and stabilize I think it will be a natural desire to have
more frequent releases of the optional components.
The dependency management issues mentioned by Bruce and Kit are valid, but
don't forget that the bundles are able to specify required version
information for their own dependencies. So the dependency management issue
is more about shipping a properly working default configuration with the
main ServiceMix distribution than about the seperate releases of components.
I like Guillaume's idea of offering a basic image that is capable of
provisioning itself from a managed OBR repository. This could also allow a
user to configure their own customized provisioning configuration similar to
kickstart files for Linux distributions. I think you will also want to
offer a fully loaded and self contained image that already has all of the
components available, but the auto-provisioned basic image will be very
useful for a lot of users I would think.
Thanks,
Chris
On 10/4/07, Kit Plummer <ki...@gmail.com> wrote:
>
> Yes you are crazy.
>
> I have to agree - dependency hell is not something I'd like to have to
> overcome. Eclipse's deal is a nice example.
>
> Kit
>
> Sent from my iPhone
>
> On Oct 4, 2007, at 4:31 PM, "Bruce Snyder" <br...@gmail.com>
> wrote:
>
> > On 10/4/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >> I'd like to make ServiceMix 4.0 as modular as possible. This would
> >> mean that ServiceMix 4.0 main distribution would come with the
> >> minimal
> >> set, while additional features could be provisioned and configured
> >> using OBR, the Deployment Admin or our provisioning system.
> >> Such features could include:
> >> * an activemq broker
> >> * an apache ds server
> >> * jbi 1.0 compatibility layer
> >> * jaxws support
> >> * ...
> >>
> >> Although from a project perspective, if we could split these features
> >> in different projects, that would make things easier to release: i.e.
> >> release a single "feature" at a time, rather than releasing
> >> everything
> >> each time. Kinda like maven does with its plugins.
> >
> > I've always thought the idea of separate release cycles for different
> > components/features was a good one. This allows for individual
> > components to be released as they're ready. However, I've begun to
> > reconsider this recently. Independent component releases seem like a
> > good idea until the developer has trouble and then begins to upgrade
> > components independently resulting in a mish-mash of versions which
> > can cause a laundry list of other problems.
> >
> > It seems to me that we should not push this responsibility onto the
> > developer because it causes them more trouble than its worth. Not
> > unlike recent Eclipse releases, ServiceMix is a container with many
> > modules and I think *we* should bear the burden of making each module
> > work together to provide an overall ServiceMix release.
> >
> > An alternative approach would be to mix independent component releases
> > with overall ServiceMix releases. This would give us the ability to
> > release components independently while still providing a major release
> > of all components packaged together as ServiceMix, say, four times a
> > year.
> >
> > Am I crazy?
> >
> > Bruce
> > --
> > perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!
> > G;6%I;\"YC;VT*"
> > );'
> >
> > Apache ActiveMQ - http://activemq.org/
> > Apache ServiceMix - http://servicemix.org/
> > Apache Geronimo - http://geronimo.apache.org/
> > Castor - http://castor.org/
>
Re: ServiceMix 4.0 modularity
Posted by Kit Plummer <ki...@gmail.com>.
Yes you are crazy.
I have to agree - dependency hell is not something I'd like to have to
overcome. Eclipse's deal is a nice example.
Kit
Sent from my iPhone
On Oct 4, 2007, at 4:31 PM, "Bruce Snyder" <br...@gmail.com>
wrote:
> On 10/4/07, Guillaume Nodet <gn...@gmail.com> wrote:
>> I'd like to make ServiceMix 4.0 as modular as possible. This would
>> mean that ServiceMix 4.0 main distribution would come with the
>> minimal
>> set, while additional features could be provisioned and configured
>> using OBR, the Deployment Admin or our provisioning system.
>> Such features could include:
>> * an activemq broker
>> * an apache ds server
>> * jbi 1.0 compatibility layer
>> * jaxws support
>> * ...
>>
>> Although from a project perspective, if we could split these features
>> in different projects, that would make things easier to release: i.e.
>> release a single "feature" at a time, rather than releasing
>> everything
>> each time. Kinda like maven does with its plugins.
>
> I've always thought the idea of separate release cycles for different
> components/features was a good one. This allows for individual
> components to be released as they're ready. However, I've begun to
> reconsider this recently. Independent component releases seem like a
> good idea until the developer has trouble and then begins to upgrade
> components independently resulting in a mish-mash of versions which
> can cause a laundry list of other problems.
>
> It seems to me that we should not push this responsibility onto the
> developer because it causes them more trouble than its worth. Not
> unlike recent Eclipse releases, ServiceMix is a container with many
> modules and I think *we* should bear the burden of making each module
> work together to provide an overall ServiceMix release.
>
> An alternative approach would be to mix independent component releases
> with overall ServiceMix releases. This would give us the ability to
> release components independently while still providing a major release
> of all components packaged together as ServiceMix, say, four times a
> year.
>
> Am I crazy?
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!
> G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
> Castor - http://castor.org/
Re: ServiceMix 4.0 modularity
Posted by Bruce Snyder <br...@gmail.com>.
On 10/4/07, Guillaume Nodet <gn...@gmail.com> wrote:
> I'd like to make ServiceMix 4.0 as modular as possible. This would
> mean that ServiceMix 4.0 main distribution would come with the minimal
> set, while additional features could be provisioned and configured
> using OBR, the Deployment Admin or our provisioning system.
> Such features could include:
> * an activemq broker
> * an apache ds server
> * jbi 1.0 compatibility layer
> * jaxws support
> * ...
>
> Although from a project perspective, if we could split these features
> in different projects, that would make things easier to release: i.e.
> release a single "feature" at a time, rather than releasing everything
> each time. Kinda like maven does with its plugins.
I've always thought the idea of separate release cycles for different
components/features was a good one. This allows for individual
components to be released as they're ready. However, I've begun to
reconsider this recently. Independent component releases seem like a
good idea until the developer has trouble and then begins to upgrade
components independently resulting in a mish-mash of versions which
can cause a laundry list of other problems.
It seems to me that we should not push this responsibility onto the
developer because it causes them more trouble than its worth. Not
unlike recent Eclipse releases, ServiceMix is a container with many
modules and I think *we* should bear the burden of making each module
work together to provide an overall ServiceMix release.
An alternative approach would be to mix independent component releases
with overall ServiceMix releases. This would give us the ability to
release components independently while still providing a major release
of all components packaged together as ServiceMix, say, four times a
year.
Am I crazy?
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/