Messaging SIG - proposal for our notification infrastructure

[Mike Bonnet]

On 08/04/2009 06:20 PM, John Palmieri wrote:
> Hey everyone.  I put up a proposal[1] that describes a publish/subscribe setup for the infrastructure wide notification system.  I haven't quite gotten to the publish side of things because the QMF docs get a little hazy there but the meat of the proposal is there and I wanted to get feedback sooner than later.  An event/notification system is important to the work I need to do going forward.  I specifically avoided method invocation and properties/statistics as they can be added in a later round if we feel we need them.  I do feel statistics might be nice (for instance keeping track of information that is expensive to do via a query but cheap to update based on events) but they are a bonus that we don't need right away.

Thanks for writing this up, I'm glad this is finally gaining some 
momentum, and I'm going to be working on adding support for this to Koji 
soon.

In addition to the event model you outline, I think we should also look 
at how we can support synchronous communication (method calls) via the 
bus.  One of the big advantages of the bus is having a single transport 
and data exchange format, rather than having to teach each application 
how to speak xml-rpc, json, soap, etc.

http://qpid.apache.org/qmf-protocol.html has some interesting notes 
about communication patterns.  The unsolicited-indication looks like our 
event use-case.  Request-response would be a normal method call. 
Query-indication looks like something in-between, and would be useful 
for getting information about a long-running process (koji watch-task 
comes to mind).

To enable two-way communication we'll need some kind of adapter 
framework that sits on the bus and converts method calls on the bus to 
requests to the back-end services.  Ideally this layer will be generic 
enough to be used by many/all of the different services used in the 
infrastructure.  It could even be a single instance which registers 
multiple objects on the bus and proxies their methods to the separate 
backend systems.