The Wannabe Java Rockstar

Janek's weblog where all posts go to Eleven

• Home
• About me
• Archive
• Blogroll
• Experiences
• Software
• Janeks Logbuch
• Email Janek

All views and documentation expressed here are mine and not necessarily those of my employer.

EDI solutions

• EDI-Outsourcing
• EDI-Konverter
• WebEDI
• EDIINT AS2
• EDI adaptor for SAP R/3
• EDI addin for Sage Office Line
• EDI with Microsoft Dynamics NAV
• EANCOM
• EDITEC

InfoBus - An API for event-driven Swing programming

David has an interesting article on event-driven GUI programming. He describes two patterns, but usually it comes down this:

The user issues a long-running command and the GUI sends it to the command queue. Other threads receive the command from the queue, compute the result and update the GUI through calls to SwingUtilities.invokeLater().

So far so good. For me, the surprising part is his choice for a message bus. David uses Somnifugi, a single-JVM JMS implementation. The obvious choice for me has always been the standard extension API InfoBus. Despite it's relative obscureness, it's the best tool for event-driven programming inside a JVM that I know.

Of course, with InfoBus producers produce data items and consumers process them. But there are APIs that make InfoBus special:

Producers can revoke data items.

Great when the data becomes invalid. 

Consumers can act.

That means, instead of only waiting for event arrival they can request a data item. This can prevent race conditions when the consumer is constructed later than the producer and misses the initial event.

An InfoBus can be guarded.

Whenever a data item is published the a guard can decide what to do with it. This could be used, for instance, to enforce execution order.

All in all, it is a complete API for loosly-coupled component interaction in a one JVM. I believe stock JMS does not address all of it. But then, I might have missed something when skimming over the specification.