Notifications between Aeolus components

Martyn Taylor mtaylor at redhat.com
Thu Jan 10 10:11:24 UTC 2013


On 01/09/2013 09:52 PM, Matt Wagner wrote:
> On Wed, Jan 09, 2013 at 10:53:58AM +0000, Martyn Taylor wrote:
> <enormous snipping>
>> 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.
> I'm not sure I follow what you mean here. Do you mean that it currently
> works as a drop-in replacement?
Yes you can create interceptors that catch messages and stick them on a 
queue.
>
>> In my opinion using a message bus should be a
>> deployment decision.
> +1
>
>> 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.
> Yes! This is what I was going to reply with, but you stated it more
> eloquently.
>
> If I write $small_component that I want to interface with Aeolus, but
> might have utility outside of Aeolus too (and this is exactly what we're
> trying to do with our components!), I might have no use for an AMQP
> client. Even if it's something easy to add in, I'd be annoyed adding the
> dependency just for Aeolus.
>
> In fairness, there's a possibility that $small_component wouldn't have
> reason to speak HTTP outside of Aeolus, either. But that strikes me as a
> bit less likely, because it's what all (?) the cloud providers are using
> for their APIs, and what all the Aeolus components are using to interact
> already.
>
>> 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.
> +1, it would be a lot of work and I'm not sure how much it would gain
> us.
>
>> 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?
> +10k. (If one doesn't already exist.)
>
> The other thing that would be nice is if it supported a queuing system,
> to handle retries and whatnot. Some components might not be using one,
> but where we did have a queuing system in place it would be nice if
> there was a way to use it. (Both in the case that you need to retry, but
> also in the case that you just don't want to be doing this stuff in the
> foreground from a web app...)
>
> -- Matt



More information about the aeolus-devel mailing list