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 <[email protected]> tel. +420777714458
