The static EventBus

[drscn]

Firstly, congratulations on the v1.0 release!

I've been reading through the docs (which are great by the way) and have a couple of questions.

Regarding the EventBus ( http://www.springactionscript.org/do..._eventbus.html ): why is it static? Surely that completely flies in the face of DI/IoC? Global, shared state, global access etc. How would two instances of the same application be able to exist in the AVM at the same time?

Just curious as to the reason for this design decision.

[666shooter]

Hey Shaun,

The EventBus is basically a port from the Java EventBus. Its initial goal was to be a central conduit through which any application can send messages, and on the other end have any process listening for these messages. With that in mind I guess the singleton made sense here, it would enable separate modules, components or processes to communicate with each other in a decoupled way. Having two identical applications in the same AVM would only become a problem if they're both running in the same application domain, as far as I understand application domains correctly. But please correct me if I'm mistaken.

It has been bugging me from the start though that indeed there is no way of controlling who can receive certain events coming out of the EventBus. The EventBus is very tolerant and will let anyone add listeners as they please. Should an application want to restrict certain events to certain listeners then currently we offer no solution for this yet.

I've been scratching my head about this for a while now. I think it might be an idea to let every ApplicationContext instance also receive its own IEventBus implementation, one that will receive and redispatch all the events coming out of the EventBus singleton but the context itself can decide who will receive a reference to its own IEventBus.
After that the context can dispatch events either through the EventBus singleton,or through its own IEventBus instance. ApplicationContexts with a parent could optionally have the ability to connext their own IEventBus to its parent IEventBus, thus creating a private conduit between modules.

On top of that we could implement some kind of interception mechanism which can decide on a 'per event' basis whether an event will be dispatched to a certain listener. I think the Parsley framework has something similar in its messaging framework, but I'm not familiar with its exact implementation.

Thoughts? Does this sound viable, or am I talking out of my ass? I'd love to hear some ideas or feedback on this.

thanks for bringing the issue up

cheers,

Roland

P.S. Also thanks for raising the issue of standardization of IoC metadata, we're in the process of complying our codebase to the metadata tags that you suggest in your survey. i.e. [Inject], [PreDestroy],[PostConstruct], etc

[cherreman]

Hi Shaun,

Thanks for the compliments. They are much appreciated.

I'll also throw in my 2 cents here.

Apart from its current implementation, the EventBus class with static methods should really be seen as a facade on top of an underlying structure of event dispatchers. When I started implementing the EventBus (based on the Java EventBus by Michael Busche) I originally had that in mind but opted for a direct implementation in the EventBus class itself because this made things much easier for the needs that we had at that point in time.

That being said, I agree with you that the current implementation does not provide a lot of flexibility and does not fit into the IoC way of thinking, which we obviously promote as much as possible. At least the (facade) interface is there and we can change the internals without breaking existing applications. On top of that, the RouteEvents and EventHandler annotations already provide an extra layer of abstraction on the current API.

For future updates we'll implement more of the Java EventBus API. I'm especially thinking about the notion of topics. This will allow modules to create their own space in the event bus, where they can communicate with eachother without interfering with events from other components.

Roland already pointed out some extra ideas. I actually think that we could give each application context its own topic inside the eventbus and provide an event publishing API inside the application contexts (as Java Spring has).

Taking this a step further, the EventBus could actually be an AS3Commons project as it has no dependencies on Spring ActionScript at all and other frameworks and projects could easily use it without needing to use Spring ActionScript. As we have shown in the past with AS3Commons Lang, Reflect and Logging, we are open to sharing and collaborating with other frameworks as much as possible and if we can make an extra in the AS3Commons portfolio then I would be glad to do so.

Thanks for taking the time to comment on this. All feedback is welcome.

best regards,
Christophe

[666shooter]

Some more cents from me then

If we remove the EventBus from the spring actionscript core and isolate it in an as3commons project, it might even be a good plan to fully abstract the use of the EventBus inside Spring AS. That way someone could potentially choose to use AS3 Signals for messaging instead of the EventBus. I'm not too familiar with S3 Signals, but I'm guessing it has enough functionality to do the same tasks. I'll have to look into this though.

Cheers,

Roland

[drscn]

Thanks for the responses guys!

"..would only become a problem if they're both running in the same application domain.."

Granted, separate Application Domains would keep the statics from colliding, but modules aren't always loaded into separate app domains. Of the 4 ApplicationDomain configurations, 3 will result in static collisions.

"The EventBus is basically a port from the Java EventBus. Its initial goal was to be a central conduit through which any application can send messages, and on the other end have any process listening for these messages."

I understand that, but that's just so at odds with DI. Any class that uses the EventBus is now hiding that dependency by using the static accessors.

"..the notion of topics. This will allow modules to create their own space in the event bus, where they can communicate with eachother without interfering with events from other components."

But we already have a mechanism for partitioning messaging in such a fashion: object instances!

The messiest, most unreliable, hardest-to-test system I can think of is one that provides static access to a single object instance that internally partitions and manages messaging, routing and value look-ups. It's just so unnecessary in an object oriented language. Especially when using a DI/IoC container!

Surely the EventBus could just be a normal class, and you could put an instance of that class into your container? Any class that wants to use it would just declare a dependency on an IEventBus.

It would then be trivial to build a utility that forwards (re-dispatches) events between IEventBusses in a given heirachy.

[666shooter]

Hey Shaun,

interesting points, I agree with most of them. There's just one use case where I don't see how you'd be able to get it to work without a singleton.
What if there are two applications that know absolutely *nothing* about each others existence, but still through events they need to be notified.
How would this be accomplished without both of them having some sort of access to a shared state? I kind of liken this to the systemManager in Flex, it actually has a sharedEvents property to achieve just that, I believe.
In Spring Actionscript there is already a class called EventBusFacade, which is a non-singleton, this implements the IEventBus interface and can be used for DI. (http://www.springactionscript.org/as...BusFacade.html). Internally this class accesses the EventBus singleton, so eventually we could safely refactor this, should be decide to get rid of the singleton.
But first I'd like to hear your thoughts on my use case

cheers,

Roland

[drscn]

Hey Roland,

"What if there are two applications that know absolutely *nothing* about each others existence, but still through events they need to be notified."

In my opinion, if two apps know absolutely nothing about each other then they certainly shouldn't be wired together behind one's back. It should be the shell application's responsibility to facilitate communication between them. If the two apps need to share state, then inject a single stateful object into both of them. The point of DI is to be able to configure this kind of thing from the outside, not from the inside.

Perhaps I'm misunderstanding you however. Do you have a more concrete example?

[666shooter]

Hey,

I was actually thinking in a host application with plugins kind of situation. Where individual plugins might need to be notified of some kind of state.
But you're right, in that case the host application should be the one responsible for injecting them with the right instances.
I think you've made your point

So, in a Spring Actionscript scenario, an application context would create an EventBus instance for itself and inject this into any object that needs it. If a child context is created, the parent context might decide to share its eventbus with the child eventbus, thus enabling it to route its events (or some of them, in that case the topics functionality can offer help) to any modules or sub applications.

I think I like the sound of that. I don't think we'll be able to get this done for version 1.1 (probably released by the end of the month), but for version 1.2 this is a very nice item for the TODO list. Refactoring it out of Spring Actionscript into its own as3commons-eventbus project can be combined in this effort.
Unless of course Christophe will chime in later and is able to come up with a scenario where the singleton is absolutely necessary

thanks a lot for your thoughts!

cheers,

Roland

[drscn]

"an application context would create an EventBus instance for itself and inject this into any object that needs it. If a child context is created, the parent context might decide to share its eventbus with the child eventbus"

Bingo!

By the way, regarding my DI/IoC metadata standardization document: I wasn't sure if you guys had seen it; it's supposed to be a collaborative document, hopefully receiving input from any/all the library/framework authors. Feel free to oppose any of the suggestions or add new ones. There is also quite a bit missing: like how to annotate optional or named constructor arguments, and factories. Fork it here: http://github.com/darscan/AS3-DI-Metadata

[666shooter]

Hey Shaun,

ticket has been created : https://jira.springframework.org/bro...ONSCRIPTAS-116

Thanks for your help and comments!

cheers,

ROland