Notifications between Aeolus components

Jan Provaznik jprovazn at redhat.com
Thu Jan 10 12:58:10 UTC 2013


On 01/09/2013 10: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?
>
>> 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
>

Hi,
thanks all for feedback (going to reply only on this one place). There 
are valid points/arguments in all yours replies.

Interesting is Martyn's proposal to leave message bus usage on 
deployment decision. This sounds good to me, but it also means that 
simple non-robust callback support is sufficient for default deployment 
(w/o ESB). I don't think this is true - I can't imagine there are many 
situations where the simple callback system is sufficient.

Do you guys know about any Aeolus use case where you could use simple 
(no-robust) callback system? I don't, but I'd love to know some examples.

I'm fine with going the REST callbacks way if all 3 requirements I 
mentioned in orig mail (retry, order, authentication) are supported by 
each Aeolus component which provides callback support.

Honestly, I thought that add message bus support into each component is 
simpler than implement robust callback system (which sounds like 
reinventing message bus wheel to me to some extent, but there are 
probably some existing solutions already). But based on your feedbacks 
where bus+pain is mentioned too often, I admit that it might be not so easy.

Jan


More information about the aeolus-devel mailing list