avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Schier <MSch...@bsquare.com>
Subject RE: [SILK] Refactoring ideas (was RE: Seda)
Date Fri, 30 Aug 2002 21:49:26 GMT

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Friday, August 30, 2002 2:23 PM
> To: 'Avalon Developers List'
> Subject: RE: [SILK] Refactoring ideas (was RE: Seda)
> > 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...
> > > 
> 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
> rules.

I think the ideal way to look at a SEDA system is to not look at it from an
event / signal / queue element perspective, but rather from the stage as a
business performing service. The good thing about SEDA in this scenario is
that it performes business gradually and queued instead of all at once like
in the current server architectures.  

Let's say I have a component A with method processB(B b) and processC(C c),
then a staged system should allow me to configure whether those methods are
fed from one or two distinct sources, so as if they were the same or two
distinct event handlers. The benfit of this approach is that it guarantees
type safety and eliminates these nasty switch statements. The drawback is
that it only allows atomic methods in the service interface.  The methods
itself would know where to route the processed object by using the service
manager to get the next stage's/service's sink in the process chain, similar
to how a componentized process chain would work in an unstaged server.


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