RE: SEDA

[Marc Schier <MS...@bsquare.com>]

Hi everybody, 

I have made several improvements regarding the SEDA stage manager
implementation. The current manager has several nice new features including
the following:

The stage manager interface has changed to give access to a service manager.
The service manager can be used to lookup sinks based on a stage name or
services. If a method on the service is declared as an asynchronous handler
the invocation to the service is proxied, intercepted and the argument is
enqueued to the associated stage's queue. This makes it very easy to work in
the Avalon world but still keep a stage driven architecture. All non-handler
methods are passed through.

Event Handlers can now be very easily declared in the configuration as being
either a handler interface (class name) or specific methods on a service
component (described by signature and event type class name). In the first
case all atomic methods on the interface are used in the second of course
only those declared. In addition a return and exception sink can be declared
where return values and invocation exceptions are enqueued to.

I also added three example applications which show how the stage manager and
the tcp and http connectors work. They depend on Fortress and on either Jdk
NIO (1.4.1) or NBIO. I will continue working on the http connector and maybe
make request and response to implement the servlet spec interfaces.

I am now thinking about moving the code from my cvs server to some public
server and maybe opening a sourceforge project and have more people working
on it (if doomed important enough). Besides, my thinking is, that the world
needs a central avalon component repository anyway, where developers can
have their own developed components hosted that comply to the Avalon
framework and use excalibur or phoenix, but have nothing to do with the
apache projects and therefore do not fit in the jakarta cvs. This could
spread the adoption of Avalon even further...

OK, let me know what you think.

Marc


> -----Original Message-----
> From: Marc Schier 
> Sent: Friday, September 13, 2002 3:38 PM
> To: 'Avalon Developers List'
> Subject: RE: SEDA
> 
> 
> Hi everybody,
> 
> I was finally able to spend some more time on the SEDA stuff. 
> Attached is
> another intermediary release. I've changed the following 
> things from my
> initial cut:
> 
> * Switched back to the event package's implementations and interfaces 
> =========================================
> Basically reversing my fork and therefore giving credit to 
> the right authors
> of the code again :->. Also Changed the package names, so 
> they show in which
> area they belong to. All event package extensions that are 
> not yet reflected
> in the original event package such as predicates and 
> multicaster sinks are
> now in the 'ext' sub package.
> 
> * EventHandler is now a legacy interface 
> =========================================
> Event Handler should not be needed anymore in a seda 
> implementation. The
> stage interface has now become a lifecycle interface which 
> does not extend
> from EventHandler anymore and shows that the implemnting 
> component wants to
> know about sinks in its reach to enqueue data to. 
> Event Handler is replaced by a dynamic scheme, going away from the one
> component == one stage paradigm. In the current 
> implementation a stage can
> conceptually have a 'one to many' relationship with handler 
> methods. A queue
> can therefore be mapped to more than one method on a 
> component and a each
> method on a service interface can in return be mapped to a 
> single queue
> representing a stage in its own right.
> 
> * Added examples
> =========================================
> I added a working example under 
> org.apache.excalibur.event.seda.test, which
> uses fortress to deploy the stages and stage manager. I 
> tested it with the
> latest fortress CVS and it works.
> 
> The process of writing a stage implementation has become much simpler,
> object oriented and type safe, since the dispatching is not 
> done in a event
> handler internal if/else statement, but in the manager 
> component itself.
> It's now as simple as defining the component interface and 
> exposing the
> atomic methods in the stage manager's configuration as 
> handlers. The stage
> manager takes care of routing the information to the right 
> method on the
> interface (actually component class, for now). Arrays as 
> parameters are also
> supported similar to the handleEvents(Object[]) method on 
> Event Handler.
> Therefore the method can sort the events and process them by priority.
> 
> Future enhancements:
> =========================================
> * Handling of exceptions in the way Berin suggested by 
> putting them into a
> signal handler queue. Another possible way is to change the 
> sink interface
> to allow for the provision of a completion queue in which 
> error message
> would be routed back to a specified handling stage. Currently 
> exceptions are
> not even logged but only printStackTrace'd.
> * Cleanup and removal of deprecated Classes and Interfaces.
> * Redo the nio socket implementations, make them compliant 
> with the current
> scheme.
> * Make th design more extensible, for example by allowing to 
> provide special
> event handler implementations for specific purposes to the 
> stage pipeline.
> Currently the three needed event handler implementations are 
> inner classes
> to the pipeline.
> * Add ant build files.
> 
> Let me know what you think of it so far or if you think something is
> missing. I will be posting updates soon, probably in one or 
> two weeks...
> 
> Marc
> 
> 
> 
>