On 01/08/2013 01:41 PM, Jan Provaznik wrote:
Hi folks,
I'd like to discuss a topic which was briefly touched on Aeolus
developer Conference in Brno. Many components of Aeolus project need
to send notifications to other components:
Heat -> Conductor (deployment/instance state changes)
Conductor -> Winged Monkey (deployment/instance state changes)
Imagefactory -> Conductor (notifications about image build&upload state)
DC tracker* -> Heat (notifications about instance state changes)
DC tracker -> Conductor (notifications about other provider resource
changes, realms availability, hw profile changes)
* DC Tracker - this component is actually not agreed yet, it was just
a proposal some time ago, but I believe this will be needed.
As far as I know there is no a unified plan how to deal with
notifications between components. At this point notifications are
implemented only in Imagefactory. This implementation is for now quite
simple - a notification callback is sent back as http PUT request. It
doesn't cover any failure situations (network error, auth error,
Conductor is not running...), so if a request is not successful, no
retry is done.
I think we need more robust notification system between all components
above, this system should support at least:
1) retry on failure
2) keep correct order of notifications
3) support authentication
And here it comes...
Why not use a message bus (an AMQP implementation) for communication
between all involved components?
- it supports all required features out of the box
- clients exists for all languages involved in Aeolus project
- notifications will be solved in the same way between all components
Or is there some other solution how to solve notifications as painless
as possible while keeping required robustness? What is your preferred
solution of this problem?
A message bus can be used currently. An ESB is a prime example of how
you can take what we have now and deploy Aeolus with a messaging
architecture. In my opinion using a message bus should be a deployment
decision. Using ReST and callbacks in the way we do, keeps things
flexible, simple, allows us to easily 'componentize' Aeolus as well as
allowing users to configure a messaging architecture in a production
environment using something like JBossESB or SwitchYard.
We could argue that we should provide a configure parameter that sets up
an ESB and drops in queues/topics, but I think this is beyond the scope
of the project (Maybe if some companies want to offer support for
setting up production environments using messaging, they could offer
this as part of a service ;) )
Another reason for sticking with ReST I think is the fact that we are so
far down the line now, it would be quite an undertaking to add messaging
in all the projects.
Alternatively, how about we write a library that handles ReST callbacks,
this should keep it consistent, and we can reuse it across projects.
Maybe an extension to ActiveResource?
Cheers
Martyn
Jan
