You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Alex Blewitt <Al...@ioshq.com> on 2003/08/08 19:55:16 UTC
[JNDI] [Config] Thought
Why can't/shouldn't all configuration be stored in JNDI, presumably as
subdirectory (sorry, subcontext) specific to geronimo?
(java:comp/env/genronimo, or other such domain).
JNDI supports pretty much everything you need -- contexts (one per
server/node/app/ejb/servlet/whatever) and an unlimited amount of
configuration entries (poolsize, max thread, min thread).
And if the JNDI is going to be backed by Technology X, then that
provides a way for users to administer the data directly. But a app
configurator can just be based on reading/writing JNDI values.
JNDI also not only supports tree-like structures, but also references
to other parts of the tree as well which would be ideal (for instance)
to represent relationships like 'App Y is in node Z'
And lastly, XML extraction of a JNDI source would be a doddle, or even
be backed by the JNDI-XML server (though IMHO a JNDI-DB server will be
more scalable for read-write data synchronised across multiple nodes
for clustering).
Can anyone think of a good reason why JNDI cannot/should not be used as
/the/ place to store config information? That way, the server will only
need one start-up parameter -- the JNDI server to connect to.
Alex.
PS Isn't this what Windows 2000 uses for its registry, and what Windows
XP uses to mount its Active Directory? Certainly, Mac OS X is moving
more towards a directory-managed approach (be it backed by LDAP or
whatever) -- so why don't we do the same for Geronimo?
Re: [JNDI] [Config] Thought
Posted by Alex Blewitt <Al...@ioshq.com>.
On Friday, Aug 8, 2003, at 22:39 Europe/London, Gareth Bryan wrote:
> I understand what you're saying, but it does sound quite network
> chatty.
>
> As cautionary note: I have known customers of commercial app servers
> really bitch about the chattiness /between/ nodes in a cluster. This
> should be kept to an absolute minimum
I agree. The less communication overhead between nodes, the better.
However, a replicated service doesn't necessarily imply that all
requests go over the network. Instead, I'd envisage a local JNDI server
on each machine that only communicates deltas in the naming setup to
other nodes, so it wouldn't be hit consistently with a bunch of read
requests.
This is already possible using a cacheing LDAP server to provide
transparent cacheing to a primary LDAP server on the network, for
example.
Alex.
Re: [JNDI] [Config] Thought
Posted by Gareth Bryan <ga...@fastmail.fm>.
I understand what you're saying, but it does sound quite network chatty.
As cautionary note: I have known customers of commercial app servers
really bitch about the chattiness /between/ nodes in a cluster. This
should be kept to an absolute minimum
On Fri, 8 Aug 2003 21:52:27 +0100, "Alex Blewitt"
<Al...@ioshq.com> said:
> It would be a single service, but could easily be adapted for
> distributed systems. For example, each Geronimo app server is likely to
> have a server VM running server services, which could include the JNDI
> server. Then, each other node has a JNDI server which synchronizes its
> state with the others.
>
> With a backend DB, it's very likely that the DB could be used to
> provide the synchronization. Files may be more problematic, unless they
> are on a network device.
>
> So, doesn't necessarily need to be a single point of failure although
> it would be a single service.
>
> Alex.
>
> On Friday, Aug 8, 2003, at 20:31 Europe/London, Gareth Bryan wrote:
>
> > I like this idea:- but wouldn't it introduce a single point of failure?
> >
> > (I guess the same problem will hold for any config node in a cluster)
> >
> > On Fri, 8 Aug 2003 19:28:26 +0100, "Philip Dodds"
> > <ph...@unity-financials.com> said:
> >> I certainly agree. The idea of holding all configuration information
> >> in
> >> a
> >> repository such as LDAP would certainly be useful within clustered and
> >> grid
> >> style environments.
> >>
> >> Philip
> >>
> >> -----Original Message-----
> >> From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
> >> Sent: Friday, August 08, 2003 6:55 PM
> >> To: geronimo-dev@incubator.apache.org
> >> Subject: [JNDI] [Config] Thought
> >>
> >> Why can't/shouldn't all configuration be stored in JNDI, presumably as
> >> subdirectory (sorry, subcontext) specific to geronimo?
> >> (java:comp/env/genronimo, or other such domain).
> >>
> >> JNDI supports pretty much everything you need -- contexts (one per
> >> server/node/app/ejb/servlet/whatever) and an unlimited amount of
> >> configuration entries (poolsize, max thread, min thread).
> >>
> >> And if the JNDI is going to be backed by Technology X, then that
> >> provides a way for users to administer the data directly. But a app
> >> configurator can just be based on reading/writing JNDI values.
> >>
> >> JNDI also not only supports tree-like structures, but also references
> >> to other parts of the tree as well which would be ideal (for instance)
> >> to represent relationships like 'App Y is in node Z'
> >>
> >> And lastly, XML extraction of a JNDI source would be a doddle, or even
> >> be backed by the JNDI-XML server (though IMHO a JNDI-DB server will be
> >> more scalable for read-write data synchronised across multiple nodes
> >> for clustering).
> >>
> >> Can anyone think of a good reason why JNDI cannot/should not be used
> >> as
> >> /the/ place to store config information? That way, the server will
> >> only
> >> need one start-up parameter -- the JNDI server to connect to.
> >>
> >> Alex.
> >>
> >> PS Isn't this what Windows 2000 uses for its registry, and what
> >> Windows
> >> XP uses to mount its Active Directory? Certainly, Mac OS X is moving
> >> more towards a directory-managed approach (be it backed by LDAP or
> >> whatever) -- so why don't we do the same for Geronimo?
> >>
> >>
> >>
> >>
> > --
> > Gareth Bryan
> > garethbryan@fastmail.fm
> >
> > --
> > http://www.fastmail.fm - mmm... Fastmail...
>
--
Gareth Bryan
garethbryan@fastmail.fm
--
http://www.fastmail.fm - Does exactly what it says on the tin
Re: [JNDI] [Config] Thought
Posted by Alex Blewitt <Al...@ioshq.com>.
It would be a single service, but could easily be adapted for
distributed systems. For example, each Geronimo app server is likely to
have a server VM running server services, which could include the JNDI
server. Then, each other node has a JNDI server which synchronizes its
state with the others.
With a backend DB, it's very likely that the DB could be used to
provide the synchronization. Files may be more problematic, unless they
are on a network device.
So, doesn't necessarily need to be a single point of failure although
it would be a single service.
Alex.
On Friday, Aug 8, 2003, at 20:31 Europe/London, Gareth Bryan wrote:
> I like this idea:- but wouldn't it introduce a single point of failure?
>
> (I guess the same problem will hold for any config node in a cluster)
>
> On Fri, 8 Aug 2003 19:28:26 +0100, "Philip Dodds"
> <ph...@unity-financials.com> said:
>> I certainly agree. The idea of holding all configuration information
>> in
>> a
>> repository such as LDAP would certainly be useful within clustered and
>> grid
>> style environments.
>>
>> Philip
>>
>> -----Original Message-----
>> From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
>> Sent: Friday, August 08, 2003 6:55 PM
>> To: geronimo-dev@incubator.apache.org
>> Subject: [JNDI] [Config] Thought
>>
>> Why can't/shouldn't all configuration be stored in JNDI, presumably as
>> subdirectory (sorry, subcontext) specific to geronimo?
>> (java:comp/env/genronimo, or other such domain).
>>
>> JNDI supports pretty much everything you need -- contexts (one per
>> server/node/app/ejb/servlet/whatever) and an unlimited amount of
>> configuration entries (poolsize, max thread, min thread).
>>
>> And if the JNDI is going to be backed by Technology X, then that
>> provides a way for users to administer the data directly. But a app
>> configurator can just be based on reading/writing JNDI values.
>>
>> JNDI also not only supports tree-like structures, but also references
>> to other parts of the tree as well which would be ideal (for instance)
>> to represent relationships like 'App Y is in node Z'
>>
>> And lastly, XML extraction of a JNDI source would be a doddle, or even
>> be backed by the JNDI-XML server (though IMHO a JNDI-DB server will be
>> more scalable for read-write data synchronised across multiple nodes
>> for clustering).
>>
>> Can anyone think of a good reason why JNDI cannot/should not be used
>> as
>> /the/ place to store config information? That way, the server will
>> only
>> need one start-up parameter -- the JNDI server to connect to.
>>
>> Alex.
>>
>> PS Isn't this what Windows 2000 uses for its registry, and what
>> Windows
>> XP uses to mount its Active Directory? Certainly, Mac OS X is moving
>> more towards a directory-managed approach (be it backed by LDAP or
>> whatever) -- so why don't we do the same for Geronimo?
>>
>>
>>
>>
> --
> Gareth Bryan
> garethbryan@fastmail.fm
>
> --
> http://www.fastmail.fm - mmm... Fastmail...
RE: [JNDI] [Config] Thought
Posted by Gareth Bryan <ga...@fastmail.fm>.
I like this idea:- but wouldn't it introduce a single point of failure?
(I guess the same problem will hold for any config node in a cluster)
On Fri, 8 Aug 2003 19:28:26 +0100, "Philip Dodds"
<ph...@unity-financials.com> said:
> I certainly agree. The idea of holding all configuration information in
> a
> repository such as LDAP would certainly be useful within clustered and
> grid
> style environments.
>
> Philip
>
> -----Original Message-----
> From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
> Sent: Friday, August 08, 2003 6:55 PM
> To: geronimo-dev@incubator.apache.org
> Subject: [JNDI] [Config] Thought
>
> Why can't/shouldn't all configuration be stored in JNDI, presumably as
> subdirectory (sorry, subcontext) specific to geronimo?
> (java:comp/env/genronimo, or other such domain).
>
> JNDI supports pretty much everything you need -- contexts (one per
> server/node/app/ejb/servlet/whatever) and an unlimited amount of
> configuration entries (poolsize, max thread, min thread).
>
> And if the JNDI is going to be backed by Technology X, then that
> provides a way for users to administer the data directly. But a app
> configurator can just be based on reading/writing JNDI values.
>
> JNDI also not only supports tree-like structures, but also references
> to other parts of the tree as well which would be ideal (for instance)
> to represent relationships like 'App Y is in node Z'
>
> And lastly, XML extraction of a JNDI source would be a doddle, or even
> be backed by the JNDI-XML server (though IMHO a JNDI-DB server will be
> more scalable for read-write data synchronised across multiple nodes
> for clustering).
>
> Can anyone think of a good reason why JNDI cannot/should not be used as
> /the/ place to store config information? That way, the server will only
> need one start-up parameter -- the JNDI server to connect to.
>
> Alex.
>
> PS Isn't this what Windows 2000 uses for its registry, and what Windows
> XP uses to mount its Active Directory? Certainly, Mac OS X is moving
> more towards a directory-managed approach (be it backed by LDAP or
> whatever) -- so why don't we do the same for Geronimo?
>
>
>
>
--
Gareth Bryan
garethbryan@fastmail.fm
--
http://www.fastmail.fm - mmm... Fastmail...
RE: [JNDI] [Config] Thought
Posted by Philip Dodds <ph...@unity-financials.com>.
I certainly agree. The idea of holding all configuration information in a
repository such as LDAP would certainly be useful within clustered and grid
style environments.
Philip
-----Original Message-----
From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
Sent: Friday, August 08, 2003 6:55 PM
To: geronimo-dev@incubator.apache.org
Subject: [JNDI] [Config] Thought
Why can't/shouldn't all configuration be stored in JNDI, presumably as
subdirectory (sorry, subcontext) specific to geronimo?
(java:comp/env/genronimo, or other such domain).
JNDI supports pretty much everything you need -- contexts (one per
server/node/app/ejb/servlet/whatever) and an unlimited amount of
configuration entries (poolsize, max thread, min thread).
And if the JNDI is going to be backed by Technology X, then that
provides a way for users to administer the data directly. But a app
configurator can just be based on reading/writing JNDI values.
JNDI also not only supports tree-like structures, but also references
to other parts of the tree as well which would be ideal (for instance)
to represent relationships like 'App Y is in node Z'
And lastly, XML extraction of a JNDI source would be a doddle, or even
be backed by the JNDI-XML server (though IMHO a JNDI-DB server will be
more scalable for read-write data synchronised across multiple nodes
for clustering).
Can anyone think of a good reason why JNDI cannot/should not be used as
/the/ place to store config information? That way, the server will only
need one start-up parameter -- the JNDI server to connect to.
Alex.
PS Isn't this what Windows 2000 uses for its registry, and what Windows
XP uses to mount its Active Directory? Certainly, Mac OS X is moving
more towards a directory-managed approach (be it backed by LDAP or
whatever) -- so why don't we do the same for Geronimo?