CAB question of event broker

Topics: CAB & Smart Client Software Factory
May 6, 2006 at 9:33 AM
originally posted by: CABFollower

We are in early stage of adopting CAB. I have performance concerns with the event broker model (pub-sub). It is the only way to communicate with other smart parts in the application. (Within and across screens) It will add over-head when many modules with many screens are loaded.

Please let me know, if any body aware of how the event-wiring is accomplished by CAB. Is it a run time activity, when an event is thrown it goes thru the list of subscribers to figure out recipients;
OR when loading the modules CAB determines who are the publishers and subscribers and internally create necessary wiring to decrease the overhead.
May 8, 2006 at 7:46 PM
originally posted by: askew

We have been told that this architecture scales very well.
I don't know the details on performance, have you any experimental results?
May 9, 2006 at 2:50 AM
originally posted by: DLorenz

Performance with Event Publication/Subscription isn't that bad, but debugging errors that occur during an event is not the greatest. You can replace the use of some of these events with CAB Services, which makes the errors much easier to trace. Though, if you are going across modules or across views in the same workitem, then you really have no choice but to use it.
Jun 3, 2007 at 3:14 PM
This is an old question, but having come across it in search of another topic I thought I'd go ahead and respond for others searching for information about this.

The CAB's event brokering mechanism works by keeping track of all the subscribers by event topic. These get registered at the time each object is created by the ObjectBuilder, so there is no runtime determination of who should receive the event notification aside from determining the category of recipient (i.e. workitem, descendants, or global). When an object raises an event which has been registered with the event broker, a single delegate registered to the event retrieves a collection of handlers registered for the event based on the recipient category and the handler delegate is called for each. The only real overhead is the building of the collection of handlers, but from looking at the code this is fairly minimal.

So in summary, the determination of the wiring isn't at runtime as there is no hard wiring of events aside from a single delegate maintained for each event publication, but the determination of the category is performed each time which is fairly minimal.