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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
