|
Home > Archive > Apache Directory Project > October 2005 > [naming] Enable Remote JNDI Access
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[naming] Enable Remote JNDI Access
|
|
| Jeremy Whitlock 2005-10-25, 5:45 pm |
| Hey all,
I would like to use directory-naming in my application but I need to enable
remote access to the in-memory JNDI provided by directory-naming. It would
be great to have a user have a PROVIDER_URL of jndi://host:port and get a
reference to the JNDI provided on the server by directory-naming. Can
someone assist me with this?
Take care,
Jeremy
| |
| Phil Steitz 2005-10-28, 5:45 pm |
| Jeremy Whitlock wrote:
> Hey all,
> I would like to use directory-naming in my application but I need
> to enable remote access to the in-memory JNDI provided by
> directory-naming. It would be great to have a user have a PROVIDER_URL
> of jndi://host:port and get a reference to the JNDI provided on the
> server by directory-naming. Can someone assist me with this?
Why not use ldap into ADS directly? If the problem is that [naming]
supports some things not provided by ADS (resource factories?) then it
would make sense to do what Noel suggested some time ago, i.e., to
integrate naming into ADS and use ldap to provide the remote access.
Otherwise, we end up needing to invent another remote binding and
transport protocol, which may not be the best idea.
If what you are after is the resources, a practical issue is that these
are mostly returned by [naming] and other JNDI providers as *references*
to locally generated resource instances - e.g., database connection
pools. Making use of these resources remotely requires a change in
their programming model. Not impossible, but requires that the resource
providers and interface specs currently supported by [naming] be
redesigned. For things like database connection pools, manageability
and security would be problematic.
What is your application trying to do?
Phil
| |
| Jeremy Whitlock 2005-10-28, 5:45 pm |
| Phil,
I want to use ApacheDS but it does not store binary data right now due to a
bug and its not scheduled to be fixed for a few weeks. Basically, I want to
have a lightweight directory for storing MBean/References in the directory
so that I can use JNDI to get to them easily. This approach is similar to
what Geronimo does with it's MBeans and what Weblogic does with it's MBeans..
That being said, I do know that ApacheDS is the directory used in Geronimo
so I don't know why it would work for them but not for me but that is the
information I got from #directory-dev on freenode, the same people that told
me to contact you. Ideally, I would like to have the lightweight provider in
[naming] but have it networkable. It would be nice not to have the overhead
of LDAP but I can go that route if needed. Thanks for getting back to me and
for sharing your ideas.
Take care,
Jeremy
On 10/27/05, Phil Steitz <phil-FeSXfS1/0IzQT0dZR+AlfA@public.gmane.org> wrote:
>
> Jeremy Whitlock wrote:
>
> Why not use ldap into ADS directly? If the problem is that [naming]
> supports some things not provided by ADS (resource factories?) then it
> would make sense to do what Noel suggested some time ago, i.e., to
> integrate naming into ADS and use ldap to provide the remote access.
> Otherwise, we end up needing to invent another remote binding and
> transport protocol, which may not be the best idea.
>
> If what you are after is the resources, a practical issue is that these
> are mostly returned by [naming] and other JNDI providers as *references*
> to locally generated resource instances - e.g., database connection
> pools. Making use of these resources remotely requires a change in
> their programming model. Not impossible, but requires that the resource
> providers and interface specs currently supported by [naming] be
> redesigned. For things like database connection pools, manageability
> and security would be problematic.
>
> What is your application trying to do?
>
> Phil
>
>
| |
| Stephane Bailliez 2005-10-28, 5:45 pm |
| Jeremy Whitlock wrote:
> Phil,
> I want to use ApacheDS but it does not store binary data right now due
> to a bug and its not scheduled to be fixed for a few weeks. Basically,
> I want to have a lightweight directory for storing MBean/References in
> the directory so that I can use JNDI to get to them easily. This
> approach is similar to what Geronimo does with it's MBeans and what
> Weblogic does with it's MBeans. That being said, I do know that
> ApacheDS is the directory used in Geronimo so I don't know why it
> would work for them but not for me but that is the information I got
> from #directory-dev on freenode, the same people that told me to
> contact you. Ideally, I would like to have the lightweight provider in
> [naming] but have it networkable. It would be nice not to have the
> overhead of LDAP but I can go that route if needed. Thanks for getting
> back to me and for sharing your ideas.
Jeremy,
I think there is a confusion, Directory is embedded into Geronimo only
for authentication matters as a service.
AFAIK it does nothing else but implements the server lifecycle
start/stop and access to it is done via the ldap login module
The jndi provider used in Geronimo to bind objects (just like tomcat,
the famous environment context java:comp/env ) is a different beast.
It is the 'naming' module (in Geronimo, not in Directory) and uses RMI
for remote access.
It might not be a good option for you to take this code as well because
it depends on a couple of classes on the Geronimo Kernel and Service
modules.
my 0.02€
Stephane
| |
| Phil Steitz 2005-10-28, 5:45 pm |
| I understand and am intrigued by the idea, just stuck on the protocol invention bit. Any ideas on how to do this using another more lightweight standard protocol?
-----Original Message-----
From: Jeremy Whitlock [mailto:jcscoobyrs@gmail.com]
Sent: Thu 10/27/2005 10:30 AM
To: Apache Directory Developers List
Cc:
Subject: Re: [naming] Enable Remote JNDI Access
Phil,
I want to use ApacheDS but it does not store binary data right now due to a bug and its not scheduled to be fixed for a few weeks. Basically, I want to have a lightweight directory for storing MBean/References in the directory so that I can use JNDI to get to them easily. This approach is similar to what Geronimo does with it's MBeans and what Weblogic does with it's MBeans. That being said, I do know that ApacheDS is the directory used in Geronimo so I don't know why it would work for them but not for me but that is the information I got from #directory-dev on freenode, the same people that told me to contact you. Ideally, I would like to have the lightweight provider in [naming] but have it networkable. It would be nice not to have the overhead of LDAP but I can go that route if needed. Thanks for getting back to me and for sharing your ideas.
Take care,
Jeremy
On 10/27/05, Phil Steitz <phil@steitz.com> wrote:
Jeremy Whitlock wrote:
> Hey all,
> I would like to use directory-naming in my application but I need
> to enable remote access to the in-memory JNDI provided by
> directory-naming. It would be great to have a user have a PROVIDER_URL
> of jndi://host:port and get a reference to the JNDI provided on the
> server by directory-naming. Can someone assist me with this?
Why not use ldap into ADS directly? If the problem is that [naming]
supports some things not provided by ADS (resource factories?) then it
would make sense to do what Noel suggested some time ago, i.e., to
integrate naming into ADS and use ldap to provide the remote access.
Otherwise, we end up needing to invent another remote binding and
transport protocol, which may not be the best idea.
If what you are after is the resources, a practical issue is that these
are mostly returned by [naming] and other JNDI providers as *references*
to locally generated resource instances - e.g., database connection
pools. Making use of these resources remotely requires a change in
their programming model. Not impossible, but requires that the resource
providers and interface specs currently supported by [naming] be
redesigned. For things like database connection pools, manageability
and security would be problematic.
What is your application trying to do?
Phil
| |
| Jeremy Whitlock 2005-10-28, 5:45 pm |
| Phil,
Not without rewriting a JNDI SPI. I thought of doing that anyways though. I
like the in-memory directory provided by Naming so that would replace the
need for the RMI/LDAP backend. I just need to figure out the proper
communication/protocol to use for accessing the in-memory directory. That is
where I thought you might be able to help. I've never written a JNDI SPI so
it's new to me. I guess some sort of Socket-based daemon to handle the
request/response to/from the client/server would be an approach. Daemon
listens for connections and based on the request, sends a serialized object
to the client. Client deserializes and uses. LocalContext wouldn't use the
daemon obviously because it would have direct access to the in-memory
directory while the RemoteContext would use this client/server approach for
storing/serving objects stored in the in-memory directory on the server.
Does this make sense?
Take care,
Jeremy
On 10/27/05, Phil Steitz <phil-FeSXfS1/0IzQT0dZR+AlfA@public.gmane.org> wrote:
>
> I understand and am intrigued by the idea, just stuck on the protocol
> invention bit. Any ideas on how to do this using another more lightweight
> standard protocol?
>
> -----Original Message-----
> From: Jeremy Whitlock [mailto:jcscoobyrs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
> Sent: Thu 10/27/2005 10:30 AM
> To: Apache Directory Developers List
> Cc:
> Subject: Re: [naming] Enable Remote JNDI Access
>
>
> Phil,
> I want to use ApacheDS but it does not store binary data right now due to
> a bug and its not scheduled to be fixed for a few weeks. Basically, I want
> to have a lightweight directory for storing MBean/References in the
> directory so that I can use JNDI to get to them easily. This approach is
> similar to what Geronimo does with it's MBeans and what Weblogic does with
> it's MBeans. That being said, I do know that ApacheDS is the directory used
> in Geronimo so I don't know why it would work for them but not for me but
> that is the information I got from #directory-dev on freenode, the same
> people that told me to contact you. Ideally, I would like to have the
> lightweight provider in [naming] but have it networkable. It would be nice
> not to have the overhead of LDAP but I can go that route if needed. Thanks
> for getting back to me and for sharing your ideas.
>
> Take care,
> Jeremy
>
>
> On 10/27/05, Phil Steitz <phil-FeSXfS1/0IzQT0dZR+AlfA@public.gmane.org> wrote:
>
> Jeremy Whitlock wrote:
>
> Why not use ldap into ADS directly? If the problem is that [naming]
> supports some things not provided by ADS (resource factories?) then it
> would make sense to do what Noel suggested some time ago, i.e., to
> integrate naming into ADS and use ldap to provide the remote access.
> Otherwise, we end up needing to invent another remote binding and
> transport protocol, which may not be the best idea.
>
> If what you are after is the resources, a practical issue is that these
> are mostly returned by [naming] and other JNDI providers as *references*
> to locally generated resource instances - e.g., database connection
> pools. Making use of these resources remotely requires a change in
> their programming model. Not impossible, but requires that the resource
> providers and interface specs currently supported by [naming] be
> redesigned. For things like database connection pools, manageability
> and security would be problematic.
>
> What is your application trying to do?
>
> Phil
>
>
>
>
>
>
| |
| Phil Steitz 2005-10-29, 8:45 pm |
| Jeremy Whitlock wrote:
> Phil, Not without rewriting a JNDI SPI. I thought of doing that
> anyways though. I like the in-memory directory provided by Naming so
> that would replace the need for the RMI/LDAP backend. I just need to
> figure out the proper communication/protocol to use for accessing the
> in-memory directory. That is where I thought you might be able to
> help. I've never written a JNDI SPI so it's new to me. I guess some
> sort of Socket-based daemon to handle the request/response to/from
> the client/server would be an approach. Daemon listens for
> connections and based on the request, sends a serialized object to
> the client. Client deserializes and uses. LocalContext wouldn't use
> the daemon obviously because it would have direct access to the
> in-memory directory while the RemoteContext would use this
> client/server approach for storing/serving objects stored in the
> in-memory directory on the server. Does this make sense?
Sorry for the response latency. Yes, the use case makes sense as long
as the entries that you want to access remotely are all serializable. I
am still resisting the idea of inventing our own protocol, though, given
that either LDAP and RMI could be used. I understand that the goal
would be to use the federation stuff already in [naming] to hide the
protocol from the client, which is the kind of thing that federation was
designed for, so I could get over this. Under the covers, we would have
to handle both the server infrastructure (which we could use [mina] for,
as sort of a compromise to bringing in ads) and the protocol itself. It
might be a good idea to start by playing with a simple mina server that
passes "jndi urls" from client to server and returns serialized objects.
I will think some more about how to represent the remote contexts and
operations, but my immediate reaction is just follow the ldap url spec.
Patches / better ideas welcome ...
Phil
|
|
|
|
|