This is mostly management waffle and making things complicated for the sake of it. The subtitle is how SOA Enables the Real-Time enterprise yet the emphasis is hardly on SOA.and certainly there is no information on the practical implementation of SOA in a real-time, event-driven environment. The approach of the entire book is to extol the virtues of an Event Driven Architect EDA - over and over again without really getting down to anything concrete. There are lots of diagram that mostly serve to abstract the situation to the point where it is difficult to make  any connection with the real world.

The book begins with an introduction to EDA for idiots - if you need this level of explanation you have no chance of designing anything sophisticated. Even so it fails miserably to make clear the distinction between EDA and a standard SOA approach. Because of this it is possible for the book to continue to baffle and mystify the reader with its discussion of abstract ideas. Nothing in programming or architecture has to be this abstract unless it is trying to cover up the fact that there is nothing to the idea.

Then Part I goes into the theory of EDA - this is mostly evangelism and obvious definitions.We are treated to a description of SOAP at a level that no application programmer cares about any longer. Why is it that the rest of the book attempts to work at a high level but feels the need to descend into the details of the SOAP protocol when the whole point is that in building and designing an application you can more or less forget this detail?

More definitions of SOA and EDA and more justification of why it's important. The final chapter in the section promises to show how SOA and EDA fit together but it fails to do this convincingly. Basically all it says is that some web services generate "events" and others consume them - events are transferred using message passing implemented using an Enterprise Service Bus.

The second section of the book is on EDA in practice. After some more waffle we get to some case studies that are quite interesting. They don't really help enlighten the reader about EDA in particular, but they are interesting case studies in their own right - particularly the Airline Flight Control system.

The big problem with this particular book is that it never actually explains the idea of EDA in a way that makes it clear what is going on. In the usual SOA paradigm a client web service calls a server web service for some action to be performed. In an EDA approach the roles are reversed - the server now generates an event which the client responds to. This is just a relabeling of the roles with a few extra requirements for a timely response and perhaps the need to pass the event on to multiple clients, i.e. a one-many connection.

So we have a whole book which simply points out, or rather fails to point out, that EDA is just an inversion of roles with possibly a broadcast architecture. Sometimes I think that software architects should write more code.

Unless you are short of something to occupy your time, steer clear of this particular book.