I use servlets because of their ease of use with GWT RPC. Maybe GWT RPC integrates with python nicely now (without needing to use JSON)? I really don't know, I haven't tried it.
As for servlets, just like everything else in java, it's only as complicated as you make it. If you don't need struts and spring then why include it? Just create servlets and package a war file and deploy and be done with it. On Mar 22, 3:30 am, Uemit <[email protected]> wrote: > Hi everyone. > > I have to re-design an existing application which uses Pylons (Python) on > the backend and GWT on the frontend. > In the course of this re-design I can also change the backend system. > I tried to read up on the advantages and disadvantages of various backend > systems (Java, Python, etc) but I would be thankful for some feedback from > the community. > > *Existing application:* > The existing application was developed with GWT 1.5 (runs now on 2.1) and is > a multi-host-page setup. > The Pylons MVC framework defines a set of controllers/host pages in which > GWT widgets are embedded (classical website). > Data is stored in a MySQL database and accessed by the backend with > SQLAlchemy/Elixir. Server/client communication is done with the > RequestBuilder (JSON). > > The application is not a typical business like application with complex CRUD > functionality (transactions, locking, etc) or sophisticated permission > system (tough a simple ACL is required). > The application is used for visualization (charts, tables) of scientific > data. The client interface is primarily used to display data in read-only > mode. There might be some CRUD functionality but it's not the main aspect of > the app. > Only a subset of the scientific data is going to be transfered to the client > interface but this subset is generated out of large datasets. The existing > backend uses numpy/scipy to read data from db/files, create matrices and > filter them. > The numbers of users accessing or using the app is relatively small, but the > burden on the backend for each user/request is pretty high because it has to > read and filter large datasets. > The analysis of the existing backend (python) showed that because of > python's GIL, concurrent heavy requests don't scale that well (cherrypy uses > workers/processed for concurrent requests). > Numpy/Scipy libraries however work well with matrices and arrays (filtering, > sorting, etc). > > *Requirements on the new system:* > I want to move away from the multi-host-page setup to the MVP architecture > (one single host page). So the backend only serves one host page and acts as > data source for AJAX calls. > Data will be still stored in a relational database (PostgreSQL instead of > MySQL). There will be a simple ACL (defines who can see what kind of data) > and maybe some CRUD functionality (but it's not a priority). The size of the > datasets is going to increase so the burden on the backend is probably going > to be higher. There won't be many concurrent requests but the few ones have > to be handled by the backend quickly. Hardware (RAM and CPU) for the backend > server is not an issue. > > *Possible backend solutions:* > > *Python (SQLAlchemy, Pylons or Django):* > > *Advantages: * > > - Rapid prototyping. > - Re-Use of parts of the existing application > - Numpy/Scipy for handling large datasets. > > *Disadvantages:* > > - Weakly typed language -> debugging can be painful > - Server/Client communication (JSON parsing or using 3rd party > libraries). > - Python GIL -> scaling with concurrent requests > - Server language (python) <> client language (java) > > *Java (Hibernate/JPA, Spring, etc)* > > *Advantages: * > > - One language for both client and server (Java) > - Easier to debug. > - Server/Client communication (RequestFactory, RPC) easer to implement. > - Performance, multi-threading, etc > - Object graph can be transfered (RequestFactory). > - CRUD "easy" to implement > - Multitear architecture (features) > > *Disadvantages: * > > - Multitear architecture (complexity,requires a lot of configuration) > - Handling of arrays/matrices (not sure if there is a pendant to > numpy/scipy in java). > - Not all features of the Java web application layers/frameworks used > (overkill?). > > I didn't mention any other backend systems (RoR, etc) because I think these > two systems are the most viable ones for my use case. > To be honest I am not new to Java but relatively new to Java web application > frameworks. I know my way around Pylons though in the new setup not much of > the Pylons features (MVC, templates) will be used because it probably only > serves as AJAX backend. > If I go with a Java backend I have to decide whether to do a RESTful service > (and clearly separate client from server) or use RequestFactory (tighter > coupling). There is no specific requirement for "RESTfulness". In case of a > Python backend I would probably go with a RESTful backend (as I have to take > care of client/server communication anyways). > Although mainly scientific data is going to be displayed (not part of any > Domain Object Graph) also related metadata is going to be displayed on the > client (this would favor RequestFactory). If I use python I can re-use code > which was used for generated the subset of the scientific data that should > be transfered to the client. In case of Java I would have to re-implement > this part. > > As you can see both backend-systems have its advantages and disadvantages. > I would be thankful for any further feedback. Maybe somebody has experience > with both backend or with that use case. > > thanks in advance > > Uemit -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
