avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: [RT] Notification pattern has interesting effects on IoC
Date Thu, 26 Feb 2004 15:18:12 GMT
Niclas Hedhman wrote:

> This is the driving pattern for the OSGi framework.
> 
> In principal I like this a lot, however, there is a "downside" (and a big one 
> that I know someone like Stephen faint over);
> 
> You don't know if the component can fulfill its 'purpose', since it may not be 
> fed required information from "dependent" components, and especially not 
> prior to the components are instantiated.

In some respects, you can code the event classes to enforce or require the
proper information.  It *does* make the stack trace messier, so debugging
these babies is more difficult.  It is always best to keep the types of events
and contracts with the events as simple as possible.  I've been doing this
for about six months now.

> There is a kind-of solution. If the 'router'/'hub' has a registration 
> requirement for the 'publisher' of the events, then the 'subscriber' can 
> query the 'hub' if there is any 'publisher' of the event types of interest.
> 
> Do I think that a centralized 'hub' is better than 'direct events'??
> 
> Not sure. In very 'busy' systems, it becomes a challange to write the 'hub', 
> so that you don't need to synchronize the 'addListener' and 'fireEvent' 
> parts, because otherwise it becomes a bottleneck.

I highly recommend you take a look at GUIApps' EventBus.  It is very simple, and
not a lot to it.  You can subscribe for a particular type of event, as well as
add filters to more fully refine what events you want to be notified of.

You don't need to do addListener() and fireEvent() methods, and it is easier
to wire than directly calling those methods like in a Swing based app.  Any
component that wants to publish events only needs the EventBus.  If they want
to listen for events we have the (un)subscribe methods on the EventBus, and
those events are routed to a Subscriber.  It works very smoothly.

> And then compare it with "direct events", meaning you register yourself at the 
> source.
> The difference is basically;
> 
> The 'hub' pattern uses an EventListener interface and an EventObject class, 
> all in true JavaBean tradition.
> 
> The decoupled 'direct event' pattern also needs a EventProducer interface, and 
> a 'query' service capable of searching for interfaces.

The hub pattern scales much more easily and is simpler to code and understand.
A decoupled "direct event" pattern is much less easy to implement or use.  Not
to mention you can run into issues of double notification if you add a listener
twice (once in two different locations).  KISS.

> In both case, I think that the primary concern for us would be the 
> "Availability Contract", which somehow communicate with the component when 
> other components are available or not. Because once that is defined in 
> framework, both the above patterns, and re-loadable traditional AF4 
> components, can be implemented in the container.

You'd be surprised with this "requirement".  Unless you put your entire
interface on the hub, you only need to notify other components when certain
events happen.  For example, when I save changes to a type of information,
I would send an Update[INFO]Event on the bus, and any component already
loaded that needs to know if that type of info is updated will recheck the
values.  It's pretty handy in that respect.  If you send an event that
requires something else created and ready for you, then you will run into
some problems if things are not started in order.  Its easier to use a
direct method in that case.


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


Mime
View raw message