AsyncMessageProcessorRoute

[alechenninger]

This can be used to asynchronously process messages which have business logic completely independent of each other.

For example, incoming document messages can be parsed and as part of processing, update (or insert) entities in a data store (such as lightblue). The handling of any incoming document doesn't need to know about any other. Perhaps you could argue that it could benefit from this, such as if two documents referred to the same entity, then they could coordinate and do one update instead of two, but this is something we should talk about later.

It could also be used to handle incoming messages were are more like "requests" or "command messages" which as a result of processing do something else.

It's generic enough that I think eventually maybe our other types of events could be brought together under this kind of model but, for now those differ in that, in least for document events, processing involves coordinating many document events together and optimizing them, so it is not natural to implement with this additional abstraction just yet.

On the other hand, Notifications as currently implemented could be handled in this model actually. But this is for another conversation, and another PR :).

[kahowell]

Looks good overall. I had a couple minor comments, but nothing big. Merge when ready.

[alechenninger]

Thanks!