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(a)redhat.com>
tel. +420777714458