directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes McKean <>
Subject Re: Frontend redesign
Date Thu, 04 Dec 2003 16:06:03 GMT
> 1). Service Decoupling Using an EventManager
> ============================================

I really like the idea of decoupling the services by making everything event 
driven.  There are quite a few modules lying around that have circular 
dependencies.  By doing this, we basically have one dependancy, the 
EventManager, and everything else is event driven.


> However I think its best to hid this and not expose it as a
> service interface.  It is best to use explicit listener interfaces
> to flag a stage as recieving certain events rather than exposing
> a generic stage enqueue() method.

Exactly!  Take a lesson from the JMS folks and write a lean mean internal 
message driven system.  Would not a more appropriate term for this module be 
QueueManager, rather than EventManager :-)  Seems like we are going to be 
creating and providing access to a number of queues, and modules can register 
with each queue to listen for events.  I assume that each queue would be 
running in its own thread and distributing events to the appropriate 
registered/concerned parties.

Question:  If we are distributing events to registered listeners, is the Event 
consumed after all listeners have been notified?  I think so.

> 2). The SEDA stages, events and processing pathway
> ==================================================
> This is now really simple.  A SEDA event is just like any other
> simple vanilla event.  Except the difference is the nature of the
> sink makes the event handling semantics asynchronous yet the order
> of event processing is preserved by the stage's queue.
> The processing pathway was already covered above so there is not
> much that's left to be said here.

A SEDA event is just a different type of event...

> 3). Session handling, identity and synchronization
> ==================================================


> Now keep in mind that for nonblocking IO the getChannel() call on
> a socket returns a non-null channel.  For blocking IO or sockets
> created using methods other than through channel construction, the
> returned channel is null.  So we can just give a stage that needs to
> work on a socket channel the socket.  This means stages can detect
> the nature of events and determine if they will handle it or not.

When using a non-blocking server side socket, you get back a SocketChannel, 
and from there you can get to the socket.  The process is reversed if given 
the socket, and it is non-blocking, then you can get access to the 
SocketChannel associated with the socket as you say.

> So a NonBlockingInputManager (input stage) is an implementation that
> handles channel based non-blocking IO.  Other implementations of the
> InputManager can just handle blocking IO.  We can have both residing
> within the same server.  For the time being SSL connections can
> leverage the blocking IO stages rather than the NIO based ones until
> SUN adds SSL support to the nio stuff.

Having both blocking and non-blocking io implementations is going to be 
difficult until we solve the issues with the SNACC stuff, which only supports 
blocking InputStreams.

> So to summarize we need to determine if we keep the ClientKey
> concept, how we manage protecting the socket when the code is
> not trusted.  Should we hide the socket or just carry it in a
> event.  Or is it best to have a service that enables access to
> the socket based on the (old implementation) and we protect the
> access to the service rather than the key.

I don't see any reason any reason to protect the client socket.  There are 
about a half dozen ways to get to it if you really want to, including hacking 
the code :-)  By routing the Socket or SocketChannel through the process, you 
will avoid having to look it up later, and in my opinion keeps everything 

> 4). Interactions with server side JNDI provider
> ===============================================

I agree this stuff is cool :-)  Need to learn more about it.


View raw message