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 17:15:35 GMT
Niclas Hedhman wrote:

> On Thursday 26 February 2004 23:18, Berin Loritsch wrote:
> 
>>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.
> 
> 
> Debugging; :o)  Once the Event infrastructure in place, the intimidating stack 
> traces is less so, just look at the first couple of entries, and ignore the 
> rest. (I have been in this boat since 96/97).

:) I know, but when you are convincing people to adopt the event based
architecture the eyes glaze over when they see a 40+ line stack trace.
Anyhoo, its academic.  THe biggest issue I had to overcome (and it did not
take me long to develop some guidelines to avoid it completely) is the
icky circular event logic.  You know, when one event triggers another event,
which triggers the first one again.  Clicking on a menu item in that situation
will cause the application to feel like it locked up until the stack limits
have been reached.

> 
> My point; Stephen is very much of the opinion that the container should 
> validate that the deployment requirements are fulfilled, so called rigid.
> The EventDriven architecture is very much the opposite, and allow you to plug 
> in stuff later, even to fulfill dependencies of other components that have 
> been "starved".

:/ It all comes back to the problem at hand.  Until you can prove it is really
a problem, it is merely a case of misunderstanding the system.  Too rigid a
spec makes the software bloated and slow, while too loose a spec makes things
prone to breaking unexpectedly.

I am still out on my verdict which one is preferable to err towards.  One might
argue that you are "safer" with the over designed system, but I wonder if that
is really the case.  I might throw together another of my essays on that subject
soon.  No promises though.

>>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.
> 
> URL?

http://cvs.sourceforge.net/viewcvs.py/d-haven/guiapp/guiapp-core/src/java/org/d_haven/guiapp/eventbus/

>>Not to mention you can run into issues of double
>>notification if you add a listener twice (once in two different locations).
>> KISS.
> 
> 
> Double notification is unresolved at a semantic level. IMVHO, if I do double 
> registration I should get double notification, as well as have to do double 
> de-registration.
> But this is not the place for this discussion.

Yep.  I was speaking more for accidental double registration due to more
complex set ups.

>>>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.
> 
> I think you missed my argument.
> If we allow services to come and go asynchronously, we should provide a 
> mechanism for the component to know that a service is/becomes or is not/"no 
> longer" available.
> This is somewhat orthogonal with the EventBus discussion.
> Components that are "AvailabilityAware" can have multiple strategies in place 
> to fulfill the service, depending on available services. Having spontaneous 
> events every now and then doesn't help for this.

I may have missed it.  I am just saying that in many cases, you won't need
the availability requirement.  In fact, I haven't run accross something I
needed that guarantee for yet.  I know we work on very different types of
projects, so you may have.  Esp. if you are dealing with hardware integration.
Usually in these cases, I have seen an XXXAvailable event and corresponding
XXXUnavailable event.  The thing is, if you miss either one of these, you
may be operating on the wrong assumption.  That brings up the synchronous
requirement and a QueryXXXAvailable event.

There are ways around everything, but in the end it boils down to what makes
sense for your proejct.  I tend to use concrete components and introduce
events sparingly.  That approach works for me, and it really works well
(IMNSHO).  Granted, I haven't done the same amount of pure event based
programming that you have either.


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


Mime
View raw message