This is a very slick REST based sample that leverages ATOM feeds to publish event notifications. Hats off to Ian and the guys behind the sample. Nothing can beat the good old polling consumer.
With an ATOM implementation the guaranteed delivery responsibility is in the hands of the consumer. This opens up the possibility for the consumer to further optimize the communication by only processing those categories where it is interested in. Categories are basically entry meta data (properties of the entry) and they are set by the ATOM server. For example 'product' and 'updated' for a product related notification.
In this Restbucks sample there are 2 different feed implementations: 1 where the ATOM entry represents a lightweight notification and another where the notification holds a xml representations of the 'domain' resource' state or part of the state at the time of the event. Let's call the later 'rich' notification. This way an ATOM feed can be used (or abused) for message queue based integration.
The principal idea behind asynchronous message queue based integration is to represent a resource state change from state A to state Z as an ordered collection of messages describing the intermediate state changes. Most often all messages need to be processed for a connected system (at its own pace etc) to become 'in-sync'. The extra latency required for processing this ABC of historical state changes, makes that the connected systems to become in-sync only after a delay, even if the expected message count is expected to be low. The longer an integrated system is not connected, the more messages that will be aggregated and the more time it will take for the integrated system to be synced.
Sometimes there is another way to optimize communication that is overlooked:
A consumer is, in a lot of cases, only interested in the most 'recent state' of a resource. They don't necessarily need to know the exact and complete path a resource traversed (its 'lifecycle') while being offline.
In this case we need to leverage the 'connected' and open nature of ATOM based integration (where queues rather imply asynchronous communication between conflicting technology stacks). This is exactly where the 'lightweight' ATOM implementation shines:
A client can get the list of resources that have changed since the last poll in a standardized way and get the latest version of only those resources that are affected. This speeds up syncing tremendously. Combined with an idempotent and atomic message design this is more like 'consumer delegated delivery'. Notice we got rid of the 'guaranteed' there. This is definitely the the way to go for syncing an iPhone or Android app and to save on bandwidth over sloppy on/off connections.
So wrapping up: Ian, thumbs up for the lightweight feeds, and thanks for the presentation!