> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 30, 2002 12:07 PM
> To: 'Avalon Developers List'
> Subject: [SILK] Refactoring ideas (was RE: Seda)
>
>
> > From: Marc Schier [mailto:[EMAIL PROTECTED]]
> >
> > 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?
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...
Now, how would the stage manager fit into the whole equation? Would it be
an extension to a container or a deployed service itself?
>
> 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...
>
> 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...)
>
> For example, my InfoMover project (in apps) has three processing
> components and one notification dispatcher:
>
> interface Input
> {
> Transaction getTransaction();
> }
>
> interface Output
> {
> Result process(Transaction trans);
> }
>
> interface Manipulator
> {
> Transaction process(Transaction trans);
> }
>
> interface Notifier
> {
> void notify( Result result );
> }
>
>
> In a pure SEDA set up, the Input would be a Source and the Output
> would be a Sink, while the Manipulator is a full fledged Stage.
>
> An external Input EventHandler would receive notification events
> from the JobManager or incomming messages from incomming network
> connections. The Input stage would then convert the information
> into Transaction objects which it sends to the next sink. Since
> the StageManager is in control, that can be remapped at any time.
>
> Anyway, the Transaction moves to the Manipulator EventHandler which
> then calls the process() method. The Transaction received from the
> return method would then be sent on to the next stage in the pipeline.
That sounds great.
>
> 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.
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.
Cheers,
Marc
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
