Notifications between Aeolus components

Martin Povolny mpovolny at redhat.com
Mon Jan 14 13:28:59 UTC 2013


On Thu, Jan 10, 2013 at 01:58:10PM +0100, Jan Provaznik wrote:
> 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

Gentleman, before jumping into this discussion I'd like to ask you not
to hurry much with a decision.

I have recently read a book that is very relevant to our discussion:

http://martinfowler.com/books/sdp.html

I was very interesting reading for me, especially since I am not a big
fan of the "do everything REST" idea that seems to be so popular these
days.

I gently suggest that you take a look at this book, there are situations
described and considerations explained that closely resemble our
concerns and problems.

Wish all a productive week!

-- 
Martin Povolny <mpovolny at redhat.com>
tel. +420777714458


More information about the aeolus-devel mailing list