avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [SILK] Refactoring ideas (was RE: Seda)
Date Fri, 30 Aug 2002 21:23:14 GMT
> From: Marc Schier [mailto:MSchier@bsquare.com] 
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > 
> > > From: Marc Schier [mailto:MSchier@bsquare.com]
> > > 
> > > Let me know how you intend to achieve it and I could do it...
> > 
> > I'd rather get payed to do it, but since no-one jumped on the 
> > opportunity.... ;P
> > 
> > The idea came about when I was spending time trying to clean up 
> > Fortress.  Currently, Fortress binds a lot of stuff in the 
> container's 
> > context.  The idea being that any container can ask for that 
> > information, and expect to see it.  Unfortunately, we can't define 
> > really solid contracts to make it enforceable. Another issue is the 
> > fact that we have *services* bound to the Context--not the 
> > ServiceManager.
> > 
> > The idea is to move the services out of the context, and into the 
> > ServiceManager where it belongs.  That includes the CommandManager 
> > (which is part of the Event package).
> > 
> > We are still with the Stage == Component metaphor, but the 
> twist is to 
> > expose the Sinks through the ServiceManager.  We would ask for a 
> > "Command Queue", and we would get the sink that the 
> StageManager knows 
> > belongs to the CommandManger.  That would allow other 
> components that 
> > know what the Sink interface is to put new events on the 
> pipeline as 
> > well as let the Stages access the traditional components 
> through the 
> > same mechanism.
> Do you mean that the service manager is proxying the method 
> invocation into a service/ stage's sink?  Basically providing 
> the service interface through lookup, but instead of invoking 
> the method will put the object into a stage specific sink?  

Essentially yes.  What is happening is that we expose an EventHandler
that is specific to the Stage.  For example, with the Manipulator
component I showed the interface for, the EventHandler might look like

abstract class AbstractEventHandler implements EventHandler
    public void handleEvents( Object[] events )
        for( int i=0; i < events.length; i++ )
            handleEvent( events[i] );

class ManipulatorEventHandler extends AbstractEventHandler
    private Manipulator m_manipulator;

    // skip all logic to get the Manipulator and SinkManager in

    public void handleEvent( Object event )
        Object newEvent = m_manipulator.process( (Transaction) event );

        m_manager.getDefaultSink().enqueue( newEvent );

What is happening is that the "Stage" becomes a wrapper around
the existing component.

> That would IMO be ideal, because you push the stage and 
> threading down into the container and the developer does not 
> have to deal with it at all. It is most important when 
> implementing a seda based server to get the stages to be 
> highly reusable and to be able to assemble them (and the 
> threading and event multicasting/merging logic) from a 
> configuration file. With the implementations that are 
> currently out there this is impossible because they mix 
> stages with the thread handling mechanism, but if the service 
> lookup and invocation were transparent to a service the 
> developer can concentrate on writing thread safe components 
> that are executed in a stage-based container...

Right.  I think this is where Matt wanted to go, but I am not
sure he knew how to make it happen with his current model.

> Now, how would the stage manager fit into the whole equation? 
>  Would it be an extension to a container or a deployed service itself?

It might become like the ServiceManager--i.e. a lookup device that
returns a Sink.  But then that is kind of what I wanted for the

My original view of the StageManager was that it was a container
in its own right.

> > The only trouble spot is the EventHandler for the Stage.  Currently 
> > Stages are required to implement EventHandler.  In reality, 
> it can be 
> > a helper class.  The important thing is to specify the proper meta 
> > info.  By separating out the EventHandler into a helper 
> class, we can 
> > also turn traditional component interfaces into Stages.
> I was thinking using simple reflection for method invocation 
> and maybe later BCEL, or something similar to create the 
> helper class dynamically from a stage manager configuration, 
> but if we used a proxy dispatching mechanism as described 
> above using BCEL would not add a lot of performance after all...


A dynamic proxy would definitely work.  The big thing is determing
what event type gets mapped to which method on a component.

Let's say a component has three atomic methods on its interface.
How are you going to automatically generate something?  You have
to know how to route event types to the right location and everything.

However if the developer wants to expose one EventHandler/Stage
for the Service (which is all we would really need), then the
StageManager would be able to map things nicely.  Using a multiplexing
Sink/Queue, we would be able to route events using simple

The thing is we can effectively move everything into the realm of
SILK, except how to use a component.  That has to be done with one
EventHandler per user interface--unless the interface was EventHandler.

> > If we make the "Stage" a conceptual thing instead of a 
> component, we 
> > can convert any component with Atomic methods to work in a 
> SEDA like 
> > environment.
> The stage interface could become a lifecycle interface that 
> is served by some manager and would look like the 
> SinkMappable interface. Implementing stage would give the 
> service access to additional seda information or allow the 
> stage to expose its own sink implementation instead of one 
> attached by the stage manager (Just brainstorming here...)

Yep.  That is where I was going with this.

> > The same type of thing happens with the Output, which gives back a 
> > Result.  The Result is then sent to the notifier.
> > 
> > There are more things to deal with, but that is the general gist of 
> > it.
> > 
> > In the mean time, I am going to look at what you did with
> > your silk.jar.
> This code is by far not finished and was more meant to be a 
> feasability test in the beginning. I planned to propose it 
> when done, but then I saw the posting about moving SEDA to 
> avalon, and I thought I submit it before there is work 
> underway on another front. Anyways, the stagemanager code 
> does work, since it is based on already working code from 
> excalibur and sandstorm, but the nio stuff still has some problems.  

:)  Understood.

> In this implementation the stagemanager is a service itself 
> so that it is container independent.  When you look at the 
> event handler and queue interfaces you see that they are 
> dealing with Objects instead of queue elements, but the rest 
> is pretty much the event package melted with SEDA. The sink 
> map has sink arrays. I thought that might be a way to do load 
> balancing and multiplexing, but a better way would be to use 
> specific sink implementations for these tasks.  

Right--which is something I was going to change about the Event

About the SinkMap comments.  The biggest thing that I wanted to
enable was to allow the Stage to make a decision whether the
events go to the default Sink, or to a more specific one like a
Cache.  The idea is that we have something like a FileResolver
front, that backed up to a cache.  If there was a cache hit, we
pull from the cache and then pass the File on.  If there is a
miss, we have to ask the system to create the File for us.  When
we have the requested File, we pass it on.

Something like that can't really be automated directly in a
Queue unless we have a special QueueElement that had a target
hint.  That way all Stages would have one way in, one way out,
and the StageManager would have an easy way of automatically
dispersing the events to a particular location.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message