Alex Karasulu wrote: <snip/>
that's cool - sounds complex to me
actually, your average J2EE app is orders of magnitude more complex than what I'm doing. The difference is that with something like a J2EE stack you have many layers, and I'm trying to take the "call stack" through all those layers, then make that simpler :D
Perhaps I'm just slow.
no its probably me! I tried to explain how I'm currently trying to decompose these issues. I think you've done that already and have moved on to thinking about implementation issues. I'm not there yet.
What this means is that the dependencies between components can change on the fly! Wow not a bad thang.
well, its less rigid. Have you gone through the introduction of lots of rigidity by introducing a strict model for lots of things (declaring loads of metadata and creating facilities to read/write/store it), only to build a layer on top of it that takes all the rigidity away again?
So basically that's what this pattern does? You had the rigidity with
the IoC stuff meta data and all that then the notification pattern/event bus
comes along and takes all the dependency based rigidity away? Is that what you mean above?
yep. It's one of the things that it does. Event-based systems seem to me to be inherently more flexible.
Note I think that rigidity is not a defining quality of IoC stuff. I wouldn't come up with a slogin "IoC Component Glue" if I did. But rigidity is one of the *big* benefits of using avalon, especially merlin.
I think you want to introduce a layer between your event-based system that maps events to-and-from method calls. Your services don't change (good thing), but you still get all the benefit of the event-based approach.
in other words, exactly this sample you wrote:
> inform( InputEvent a_event )
> {
> byte[] l_buf = a_event.getBuffer() ;
> decode( l_buf ) ;
> }the inform() method for your decoder is doing the transformation of event into method call on the 'actual' work interface.
It might make sense to extract this functionality from all classes that do this kind of thing and put it in some common place. I haven't figured out how to do that nicely, but it 'feels' smart.
Why there are no method calls anymore? The pattern uses a standard inform(EventObject) method for Subscribers. Sure u can make this type
safe and specific by having a Subscriber heirarchy by haveing specialized
subinterfaces supporting signatures like inform(XYZEvent) or in on example
in Eve we have a ConnectSubscriber for ConnectEvents that has a type specific
inform(ConnectEvent).
I think a subscriber hierarchy will be messy. It seems like you will end up with a parallel class hierarchy.
Otherwise, what's the benefit of using avalon at all?
Good question. I have not answered that just yet. But I'm thinking this way. Not every aspect of the system is best suited for pub/sub model. The IoC based dependency approach based on service interfaces is still valid. You can mix these patterns to suit the need best.
good answer! We are looking, of course, for another kind of pattern that shows what kind of mix works :D
interface Decoder
{
Message decode( byte[] buf ) ;
inform( InputEvent a_event ) { byte[] l_buf = a_event.getBuffer() ; decode( l_buf ) ; }
There is no need to expose decode anymore is there? Perhaps you might
want to expose it for non-pipeline processing. Meaning your not responding
to an event but just using the decode functionality. So then you could leave it there. See where i'm goin here?
yep. I think you do want to expose it.
I split things out somewhat like this in jicarilla atm, but its otherwise very similar. I have something like
interface Decoder
{
Message decode( byte[] buf );
}
class DecoderStage extends AbstractStage
{
private Decoder m_decoder; public void DecoderSink( Decoder decoder )
{
m_decoder = decoder;
} Object process( Object event )
{
EventAssert.assertOfType( event, InputEvent.class );
InputEvent a_event = (InputEvent)event;
byte[] l_buf = a_event.getBuffer() ;
return m_decoder.decode( l_buf ) ;
}
}so the event handling and the services is decoupled. The disadvantage is probably in that you'll likely want a stage, source or sink for each service work interface. But OTOH you should be able to use the same stage for different service implementations.
WDYT?
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
