The security aspect is true. I don't see a problem in the worker threads yet, however you might be right.
We might try a Wicket example to see how we can integrate all our existing code into it. Thanks! Sebastian 2012/8/26 Martin Grigorov <[email protected]>: > Hi Sebastian, > > I see a little problem in your architecture - the jQuery client will > make a request to the Velocity servlet, then if you use > the REST API you'll need to make another http request. If both the > servlet app and the REST app are deployed on the same > web container instance/node then you will face thread starvation > problem for http worker threads, possible deadlock too. So you may > need to deploy the different parts on different nodes. > > Also think early how you will implement the security part of the application. > > Sometimes classics are much easier ;-) > > On Sun, Aug 26, 2012 at 5:36 PM, [email protected] > <[email protected]> wrote: >> Thanks for the detailed answer Martin! >> >> You are right in my description I missed one part, for generating the >> HTML my plan was to use Apache Velocity. The REST interface will only >> generate data to fill that HTML. >> >> I've created a MockUp of the architecture proposal that should cover it all: >> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal >> >> Wicket seems to be more likely to be a classic >> web-application-framework. From my point of view we are more looking >> for a UI framework. >> >> Thanks! >> Sebastian >> >> 2012/8/26 Martin Grigorov <[email protected]>: >>> Hi, >>> >>> You didn't say what your web service response's type is. >>> By referring to jQuery's #load() method it seems like your WS returns >>> ready to render HTML, but later you say that you will create the >>> content with pure JavaScript (JQuery) which makes me think that the >>> returned response is plain data (JSON, XML, ...) which you will use to >>> generate the HTML. >>> >>> Wicket is (mostly) server side framework, i.e. it generates the HTML >>> at the server and sends it to the browser for rendering. For single >>> page applications (SPA) you start with rendering a whole Page and then >>> by using Wicket Ajax components just need to update your components' >>> models (pure Java code executed at the server) and Wicket will >>> generate the HTML and send it to the browser to update the part(s) of >>> the page. Wicket 6.0 also provides integrations with Atmosphere >>> framework and Native WebSocket so you can use newer (HTML5) >>> technologies for updating the view at the client side. Again you'll >>> have to write mostly Java code to implement this. >>> The benefit is that you can test all this very easily with >>> unit/functional tests written in Java. >>> >>> If you want to use JavaScript to render the returned plain data from >>> your web service then there is no need to include Wicket in the >>> technology stack. But in this case you will need to use some >>> JavaScript testing library. The JS testing libs became better last >>> year but still not that good as Java ones. >>> >>> In both cases using Selenium for more complicated test scenaria will be >>> needed. >>> >>> HTH >>> martin-g >>> >>> On Sun, Aug 26, 2012 at 2:24 PM, [email protected] >>> <[email protected]> wrote: >>>> Hi, >>>> >>>> we are developers from the Apache project "Apache OpenMeetings", we >>>> provide a Web-Conferencing application that is currently Flash-based >>>> on the client side. >>>> We already have a server side stack with Spring + openJPA + Axis2 that >>>> provides us with a SOAP/REST API and ORM. >>>> >>>> We are currently discussing an HTML5 alternative for our Flash based >>>> client and have to decide some basic framework questions. >>>> Apache Wicket is one option. >>>> >>>> Our HTML client is likely to be a single HTML page that loads content >>>> / components dynamically into the website. >>>> My idea was first to use http://api.jquery.com/load/ to load >>>> components dynamically, however maybe Wicket has a similar mechanism? >>>> It seems like the combination of jQuery + Wicket is the most widespreaded. >>>> But if we create our content with pure jQuery, why adding Wicket to it? >>>> I was told that Wicket's strength is to provide a Non-JavaScript >>>> version of the website if JavaScript is not available. However as our >>>> basic features will be collaboration tools that really make no sense >>>> without JavaScript, we don't need a Non-JavaScript version. >>>> And we have already a REST interface, we don't need to duplicate one >>>> with Wicket that provides yet another API. >>>> >>>> Maybe there are other arguments positive for using Wicket that I have >>>> overseen? >>>> >>>> Thanks for sharing! >>>> Sebastian >>>> -- >>>> Sebastian Wagner >>>> https://twitter.com/#!/dead_lock >>>> http://www.webbase-design.de >>>> http://www.wagner-sebastian.com >>>> [email protected] >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> >>> -- >>> Martin Grigorov >>> jWeekend >>> Training, Consulting, Development >>> http://jWeekend.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
