I agree a messaging queue is a nice scalable system. But I also think pragmatic approaches are best. You don't have "messages" that need to be sent right now (data sent between disparate apps). You have a single command that needs to be invoked. That happens to be what HTTP is *really* good at. And, you're already writing a web app. That said, I'd choose Serban's recommendation. Create a Wicket bookmarkable page that takes a pre-shared key or some other method of authentication and call that from the app. If it's just an encrypted URL param that gives authorization you don't even need to call it from the other app - just give the user a link to click that goes straight to the "flush cache" page on the frontend. Open that in a new window, have your page print out "all your strings are belong to us" and you're done :)
-- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Sat, Feb 4, 2012 at 6:47 AM, Bas Gooren <[email protected]> wrote: > François, > > Thanks for your response. > > Playing around with messaging has been on my wishlist for a while now. > I really like the features of JBoss HornetQ, in the context of my question > especially the "no dependencies, can be embedded through guice, handles > persistence itself without external db and ... in-vm transport". > > I didn't know about this project, so thanks for pointing it out. > > Sebastian > > Op 4-2-2012 12:39, schreef Francois Meillet: > > Hi Sebastian, >> >> >> 1) crossContext : >> Tomcat 7 - javadocs: >> >> Set to true if you want calls within this application to >> ServletContext.getContext() >> to successfully return a request dispatcher for other web applications >> running on >> this virtual host. >> >> But if you want something secure : >> Set to false (the default) in security conscious environments, to make >> getContext() always return null. >> Easy, not scalable, unsecure >> >> >> 2) socket : >> Write a server and a listener using Socket and ServerSocket. >> Inexpensive, not-scalable, .... must manage new threads >> >> >> 3) jmx / mxbean >> If you want to write a lot of lines of code .... >> >> >> 4) Memory-mapped file with NIO >> Easy, not scalable >> >> >> 5) messaging >> It may be overkill at first glance. Only at first glance, >> >> If you want something scalable and secure, go for a messaging bus: >> For example, why not using JBoss HornetQ messaging system ? >> It's scalable, multi-protocol, embeddable. >> >> Your components will be loosely-coupled, scalable and secure, and your >> unit tests much easier. >> Especially if you deploy your web app to a cluster.... >> >> >> François Meillet >> >> >> >> >> Le 4 févr. 2012 à 12:17, Bas Gooren a écrit : >> >> Yeah, I was thinking the same thing. >>> >>> The only thing I need to take care of then is access control, normal >>> users should not be able to invoke a cache clear by calling the url. But >>> since the call made from the admin to the frontend will not go over a >>> public network I can simply use a pre-shared key for that. >>> >>> Thanks to all who replied for their input! >>> >>> Op 4-2-2012 11:02, schreef Martin Grigorov: >>> >>>> On Fri, Feb 3, 2012 at 10:17 PM, Serban.Balamaci<thespamtrapp@** >>>> gmail.com <[email protected]>> wrote: >>>> >>>>> Some REST interface to be called through Httpclient from the admin >>>>> application I'd say it's the simplest approach. >>>>> >>>> I also think this is better than JMX, JMS/RabbitMQ/0mq, ... because >>>> these require different ports to be open and sometimes this is >>>> problematic. >>>> >>>> -- >>>>> View this message in context: http://apache-wicket.1842946.** >>>>> n4.nabble.com/Communication-**in-vm-between-webapps-** >>>>> tp4355616p4355667.html<http://apache-wicket.1842946.n4.nabble.com/Communication-in-vm-between-webapps-tp4355616p4355667.html> >>>>> Sent from the Users forum mailing list archive at Nabble.com. >>>>> >>>>> ------------------------------**------------------------------** >>>>> --------- >>>>> To unsubscribe, e-mail: >>>>> users-unsubscribe@wicket.**apache.org<[email protected]> >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> users-unsubscribe@wicket.**apache.org<[email protected]> >> For additional commands, e-mail: [email protected] >> >>
