avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [RT] Notification pattern has interesting effects on IoC
Date Wed, 18 Feb 2004 07:06:15 GMT

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.

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.

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.


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.


Cheers
Niclas


On Wednesday 18 February 2004 12:44, Alex Karasulu wrote:
> Hi all,
>
> While looking at the frontend of the Eve server I began to realize a trend
> emerging after I introduced a central publish and subscribe facility. The
> pattern decouples components by enabling communication using events and the
> notifier pattern. This also lead to the disappearence of methods on service
> interfaces.
>
> So the dependency graph turns into a star with all components depending on
> the event router, hub, bus or whatever you call it in the center. Event
> types and interfaces essentially become the dependency as opposed to the
> service interfaces. This way you can introduce new subscribers and
> publishers. Also the dynamic rerouting of events is possible at runtime.
> What this means is that the dependencies between components can change on
> the fly! Wow not a bad thang.
>
> What does this mean for service interfaces? Well they start looking bleak
> because the Subscriber interface replaces them. Basically methods are
> called internally by the Subscriber handling code on the component itself
> rather than exposing them on the service interface for direct calls by what
> are now publishers. This is crazy my service interfaces are all empty now!
>
> Alex
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org


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


Mime
View raw message