Often, in a multi layered, structured application it is sometimes required to notify several services on a system state change. Such change could be of some user interaction with our application, exception thrown from a specific layer or new client registered with our publishing service. These operations can be handled in a variety of paradigms, but for today's lesson: Event Driven Programming.
Recently I faced a problem with our ever growing application of knowing of a network topology change and notify several modules. The initial approach we took was to send important events to a centralize service, which knows almost the entire application structure, that can modify modules state based on the called method. Over time this service got larger and larger, complexity level rose and the maintainability efforts went to the roof. Searching for a suitable solution I broke the behavior to small strategy methods to which I could call from the original method. These strategies are actually event handlers for the state change. Looking around for event handling framework that will suite my needs I came across GWT's HandlerManager, Java's beans implementation, EventBus, ELF and even SpringSource event multi caster. Most, if not all of the above frameworks follow the same guidelines and principals with their provided solution, some are a lot easier to configure than other but what most of them lack is the (poor) support of configuration by annotations.
That's where my github.com account went in handy - I decided to write an event handling framework of my own. Named the project - Event Roaster. The framework is fully annotation configured and if you're working with IoC container like Spring it even provides you with EventServiceFactoryBean. So, here's what you need to know before you can start working with it:
The snippet above demonstrates how simple the configuration really is and layout for event publishing and handling. Objects you wish to pass around as events are annotated with @Event (no need to implement anything, any object will do) and handler methods are annotated with @EventHandler, each method declaring which event it handles. Handlers can set their priority when called and (future versions will include the ability to) block further event processing. Publishing (a.k.a Firing) an event is as simple as calling the fire event in a matching event service. The event broadcasting is done asynchronous using a multi-threaded executor service. That's all there is to it, implement your handling methods and you're good to go.
Event Roaster is an open source project and as such it requires some attention and assistance by its users and contributers. Future versions are waiting release to Maven's Central repository using Sonatype OSS repository (project can't go to Central unless one of its dependency will move to Central as well). Feedback, feature requests and any general assistance will be appreciated.
Recently I faced a problem with our ever growing application of knowing of a network topology change and notify several modules. The initial approach we took was to send important events to a centralize service, which knows almost the entire application structure, that can modify modules state based on the called method. Over time this service got larger and larger, complexity level rose and the maintainability efforts went to the roof. Searching for a suitable solution I broke the behavior to small strategy methods to which I could call from the original method. These strategies are actually event handlers for the state change. Looking around for event handling framework that will suite my needs I came across GWT's HandlerManager, Java's beans implementation, EventBus, ELF and even SpringSource event multi caster. Most, if not all of the above frameworks follow the same guidelines and principals with their provided solution, some are a lot easier to configure than other but what most of them lack is the (poor) support of configuration by annotations.
That's where my github.com account went in handy - I decided to write an event handling framework of my own. Named the project - Event Roaster. The framework is fully annotation configured and if you're working with IoC container like Spring it even provides you with EventServiceFactoryBean. So, here's what you need to know before you can start working with it:
The snippet above demonstrates how simple the configuration really is and layout for event publishing and handling. Objects you wish to pass around as events are annotated with @Event (no need to implement anything, any object will do) and handler methods are annotated with @EventHandler, each method declaring which event it handles. Handlers can set their priority when called and (future versions will include the ability to) block further event processing. Publishing (a.k.a Firing) an event is as simple as calling the fire event in a matching event service. The event broadcasting is done asynchronous using a multi-threaded executor service. That's all there is to it, implement your handling methods and you're good to go.
Event Roaster is an open source project and as such it requires some attention and assistance by its users and contributers. Future versions are waiting release to Maven's Central repository using Sonatype OSS repository (project can't go to Central unless one of its dependency will move to Central as well). Feedback, feature requests and any general assistance will be appreciated.
