Re: Messaging SIG - proposal for our notification infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list

[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux