2.If my approach is fine, do i need to use a scripting language like JSP or i can submit html forms directly to the rest urls and get the result (using JSON for example)?
Sorry for having many questions , but I am really confused about this.
do you really expect that task_type1 , task_type2 , etc. are going to be very CPU-intensive? Have you tested to confirm that? Are there really going to be a lot of users utilizing the application at the same time? It may be that a single server can handle the load just fine and that distributing the application would just complicate things with no added benefit. 2nd, don't assume you need threads because "tasks need to be executed at the same time". Unless you need to take advantage of multiple CPUs, a single thread pulling tasks off a work queue will probably work just fine.
Commented Jul 4, 2012 at 21:41@AlexD the tasks themselves are not CPU intensive, but if i get many customers with many tasks this might be a problem in the future, I am considering scalability for future. I assume one server would handle for now. But I wanted to know how to make it distributed in case i would need. i.e. I wanted to understand the concepts of distribution.
Commented Jul 4, 2012 at 21:56@AlexD Regarding the threads, I need tasks to be executed on specific times, for example, there might be task_type1 to be executed at 10:00 am for customer1 and another task_type1 for customer2 also at 10:00 am. I need some sort of concurrency in execution. i.e: processing the two tasks in parallel.
Commented Jul 4, 2012 at 21:57 the term "distributed" is generally used in the sense of "running on multiple machines" Commented Jul 4, 2012 at 22:34"should be using other technologies or concepts like Java Beans for example" – if you're not certain what "Java Beans" are for, you probably shouldn't be trying to write a distributed system. This sounds like you're just mashing technology buzzwords together randomly.
Commented Jul 4, 2012 at 22:52I just want to add one point to the already posted answers. Please take my remarks with a grain of salt, since all the web applications I have ever built have run on one server only (aside from applications deployed to Heroku, which may "distribute" your application for you).
If you feel that you may need to distribute your application for scalability, the first thing you should think about is not web services and multithreading and message queues and Enterprise JavaBeans and.
The first thing to think about is your application domain itself and what the application will be doing. Where will the CPU-intensive parts be? What dependencies are there between those parts? Do the parts of the system naturally break down into parallel processes? If not, can you redesign the system to make it so? IMPORTANT: what data needs to be shared between threads/processes (whether they are running on the same or different machines)?
The ideal situation is where each parallel thread/process/server can get its own chunk of data and work on it without any need for sharing. Even better is if certain parts of the system can be made stateless -- stateless code is infinitely parallelizable (easily and naturally). The more frequent and fine-grained data sharing between parallel processes is, the less scalable the application will be. In extreme cases, you may not even get any performance increase from distributing the application. (You can see this with multithreaded code -- if your threads constantly contend for the same lock(s), your program may even be slower with multiple threads+CPUs than with one thread+CPU.)
The conceptual breakdown of the work to be done is more important than what tools or techniques you actually use to distribute the application. If your conceptual breakdown is good, it will be much easier to distribute the application later if you start with just one server.