Event-driven architecture isn't new, but they do require developers to rethink their designs. Most traditional business apps have the "one transaction" mindset, where everything must either save to the DB or roll-back together. Unfortunately, the "all-or-nothing" mentality means a lot of work at the same time, which isn't very scalable. Event-driven architectures compose multiple small transactions that are more easily manageable into a single multi-hop business transaction.
As you may have guessed from its name, it is heavily influenced by the Reactor design pattern. However, it supports several different styles of event-driven programming. Starting with the traditional callback-oriented Consumer interface, Reactor has an interpretation of the Promises/A+ spec that simplifies working on deferred values.
And (my favorite part) you can use Groovy to describe your config. Jon Brisbin provided this example in the announcement:
// Assign a Closure as a Consumer reactor.on($('hello')) { Event<String> ev -> if(ev.headers['specialHeader']) { // Events can have metadata doSomethingWith(ev.data) } } // Use Groovy helpers for notify reactor.notify for: 'hello', data: 'Hello World!', specialHeader: 'specialValue'
Read about it on the SpringSource blog.