I just read an excellent post by Gregor Hohpe talking about the motivation for Event Driven semantics for service communication.

Gregor gives an example of a shipping service listening on order events and address change events to produce shipments.

It is nice to see how architectural approaches transcends business domains so well -  The Naval C4I project Udi Dahan  and myself are working on, we basically try to take the same approach. For example: A Sensors service publishes its status every predefined time - The sensor knows if something is wrong with its state. A sensor, however, doesn't know if the problem is important or  not. We designed an Alerts service that listens in on status messages, based on (changing) business rules a certain status may trigger an alert event (which a UI can then choose to display); a severe alert may result in an SMS alerting a technician to come and have a look.

However, while this approach is very good for inter-service communication -things aren't as rosy when it  comes to interacting with UIs. The point is UIs  are based on interaction so the request-reply idiom (should actually be implemented as request-reaction) is much more prevalent. Users really want to know their request is being taken care of

Another lesson we learnt is that since services make go on-line and off-line independently of each other, it is not enough just to support event listening for event aggregators to be up-to-date. One option is to relay on reliable messaging to any event posted will eventually get to the listener - there are several problems with this approach for example:

•  For one, you need a reliable message transport which might be a problem e.g. you may not be able to use JMS/MSMQ between enterprises and/or the protocols you use don't support it (e.g. WS-RM is not durable see here  and here )
• Even if you have reliable communication,  if one service has been offline for a long period of time (where long is defined by the communication load) - it may be a waste of time (or plainly wrong)  to process old events that are no longer valid

 Another option to handle this situation is to supply in the contract request for current state (the current state can be published using the same message structure used by the matching event). The advantage here is that a server coming on-line can quickly and efficiently get up-to-speed on the current situation.

The event thinking is relatively on par with Take-it-or-leave-it approach for contracts construction, but as I said in the previous post on contracts, I think it is more beneficial to know about your consumer and take their input into account

Apropos EDA,  I also learnt today that the Micro-Services  strategy Udi and me came up with had already been "invented" several years ago. It is called SEDA (Staged Event Driven Architecture) there's a nice presentation explaining it here