directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [naming] Enable Remote JNDI Access
Date Sat, 29 Oct 2005 23:36:08 GMT
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

Mime
View raw message