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.