Application Development Meanderings

Typically, GUI applications have the issue that the UI itself runs in its own thread and  follows some type of event-driven design. Multi-threaded GUI’s are hard to write. The event dispatching model will typically have a way to run tasks on its  thread that works with (versus against) the UI system. In swing, the EDT is the event-dispatch-thread and performs this function for java swing. If we are running a system that is suppose to handle publishing and consuming by handlers that are typically tied to the EDT, how do we arrange for all of the channel activities to be on the right thread? One way, not so safe, is to ensure that the channel and entire infrastructure is created an runs on the EDT. We can do this by wrapping the entire program in a SwingUtilities.invokeLater(…) method to launch the program. If you look at the demo code, this is what we do. So we seem safe, at least, until we are publishing and consuming in a side thread because of a long running task or some other scenar

If you look at different event broker implementation, such as that in OSGi, contemplated for e4 and eventbus.org, they all talk about subscribing to events based on a topic string. The topic string is like a URI that denotes topics of interest and typically relate to some type of hierarchy of objects, actions, services or some combination of these. We saw in the last blog that is fairly easy to implement a subscriber type mechanism that selects on an event type and an arbitrary SpEL expression (AND’d together). Combined together with spring integration’s method injection, we can also have a flexible method signature. How would we implement event topics specified as URI-like strings? You can also think of these strings similar to RESTful URIs that denote traversing a container hierarchy. Seems useful. In addition to topics, we also may want to filter events that we process based on the source in some way. While we do not want to go back to the tight coupling associated with the classic

In Part 1, we saw that loosely coupled integration with legacy components is alot of work mostly because of the need to create scaffolding around error handling, method invocation, publishing and channel management (routing, filtering, bridging). In this blog, we want to assume that a loosely coupled model is the implementation approach and that spring integration will be used to implement it. Essentially, we are saying that the application context message publishing model is a good one and we want to put the simple event publishing mechanism that is provided in the application context today, with framework provided by spring integration. Because we can assume that the components, where appropriate, will be loosely coupled and that spring integration is the implementation machinery, we can program interfaces, create subscription annotations and do many things that are one step closer to the application specific nature of the integration. Spring integration cannot make many assumptions

At some point, your RCP application may be to complex to manage because of volume or complexity of managing observers when using the standard java swing observer pattern or java beans observer pattern with property change listeners or highly coupled listener lists. Event.org has shown that it is possible to provide a looser coupling between components. The eventbus project is a good project and has a lightweight library that has a good following. In essence, it implements a queue internally to hold events that are distributed to event listeners. This is the same as what spring integration does although spring integration is designed to rely on the application context for configuration and creation as well as handles a fully general set of message bus functionality that is robust for many general application integration tasks. The event bus is conceived to help swing applications but is not as general. Two questions arise: Does spring integration really help decouple components and