On 10/11/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>
> On 10/11/07, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> > On 10/11/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > > I was thinking that ldap may be handy for the registry, but hopefully
> > > Chris will join the discussion at this point... Though camel does
> > > not support ldap (yet).
> >
> > This was exactly the road I started going down in order to solve a
> > couple of problems:
> >
> > 1) Distributing a consistent configuration across groups of nodes
> > 2) Providing for a central registry that is replicated to other
> > directory server instances
What I am trying to get my head around, is if this configuration data can be
abstracted up to the OSGi level or if it is specific to ServiceMix? I see
the specific requirement for this data within ServiceMix itself, but with
OSGi there is also the configuration admin service which is a standardized
way to provide data to instances of services. I have been thinking about
implementing a distributed version of these kinds of OSGi services for a
long time so this could be another option. If nothing else, we could
support a pluggable registry that could have different implementations
depending on the deployment scenario. Just a thought.
>
> > This would optionally require a master directory server with other
> > backup or slave servers in order to replicate the registry data. The
> > size of the network and the criticality of the data would determine if
> > you need to run slave servers or not.
> >
> > The other thing I began thinking about was using the AMQ master/slave
> > functionality and just embedding the directory server in the master
> > and the slaves. This would mean less moving parts and we could make
> > any LDAP replications take place via AMQ transports.
>
> Doesn't apacheds comes with a clustering / replication solution already ?
Yes, and I can look into modifying this to use ActiveMQ to do the
replication so that we can keep things consistent (current replication is
direct TCP with Mina on each node). ApacheDS also allows replication
without exposing the actual LDAP server... so it can be embedded and expose
a direct JNDIContext without exposing a listener externally yet still
achieve replication, which is a common use case for embedded users.
>
> > > So your snippet would actually solve the heartbeat problem. But I'm
> > > not sure we can send the whole data at each heartbeat. I guess it
> > > depends how bit this data is, but if we have lots of services in the
> > > OSGi registry, it may not be very scalable. So we would have to
> > > default to send only updates or find another mechanism to send the
> > > data (the heartbeat could just contain the url of our container, and
> > > the data would be retrieved by another mechanism).
> >
> > How about just sending the URL and a flag stating that there is an
> > update? If one of the other servers wants the update, then they can
> > poll that server's URL and a known topic for the actual data updates.
>
> Yeah. However, for performance reasons, it may be interesting to be
> able to only publish the delta in addition to provide an easy access
> to the whole data.
I think ApacheDS does this now, but I am sure that it could be optimized to
fit our needs if it doesn't already.
We could also expose the registry as a REST interface, but it may not
> be the most efficient way.
>
> >
> > Bruce
> > --
> > perl -e 'print
> unpack("u30","D0G)[EMAIL PROTECTED]&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/
>
I certainly think that ApacheDS could be of some use here, but I don't want
to be pushy or biased ;-) There will certainly be some customizations for
this use case, but ApacheDS is extensible via interceptors and other similar
means. In addition, it might not be well known that ApacheDS is going to
start moving to an OSGi container based deployment as well, so that might be
useful too. I think these discussions are great and will help expose the
requirements as we toss around these ideas and we can keep fine tuning the
solution.
Chris
