If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

J2EE-based RIA design

I'm new to web development, planing to develop my first J2EE-based Rich Internet Application, and have some fundamental questions to application architecture.

The back-end will run on a Linux machine, serving multiple (5 to 25) Windows PCs via Intranet.

Front-end will be an interactive UI for executing work flows that run on the server; for viewing scalable diagrams and data tables of the results, for requesting data as Excel and Word files, for uploading data from Excel files. The UI will be realised in the web browser using HTML(5) with CSS and JavaScript.

- Will these technologies be sufficient for complex and interactive UI, since I want to avoid Browser plug-ins and Applets? (OK, this is not directly a back-end question)

- How can I "tame" JavaScript (e.g. automated generation of HTML, CSS and JavaScript by J2EE back-end), as it feels confusing to create a mix of three different front-end syntaxes besides Java on the back-end.

Back-End: communication with multiple clients, central application logic (including a computational-expensive comparison algorithm as part of user-requested work flows), hosting and access to data in DB

- My first thought was to use J2EE with Tomcat for realising the whole back-end - but will this be sufficient to communicate with the clients, i.e. take care of all the session administration and HTML/CSS/JavaScript-generation? Or do I add another layer of complexity, e.g., PHP?

- As performance (up to 25 clients might simultaneously request computational-expensive sub-routines), platform-independence (might run on Windows servers in future) and extensibility are important issues, I decided for Java. But would DJANGO or Ruby-on-Rails or PHP or something else be a sufficiently fast alternative to?

- How can I find out about the minimal hardware requirements of the server?

Will these technologies be sufficient for complex and interactive UI, since I want to avoid Browser plug-ins and Applets? (OK, this is not directly a back-end question)

Javascript and JavaEE play very well together, but you have to architect your app in a way that allows them to communicate. What you ideally need is a restful API which allows you to communicate with your backend, and a front end that allows you to solely handle client interactions. Your web interface is created using HTML/CSS/Javscript like you mentioned, and the javascript provides any data needed from your server via your REST endpoints.

How can I "tame" JavaScript (e.g. automated generation of HTML, CSS and JavaScript by J2EE back-end), as it feels confusing to create a mix of three different front-end syntaxes besides Java on the back-end.

Javascript needs somewhere to live. It organically gets mixed in to your architecture, with each of these serving a very specific purpose. HTML provides a means to display data via a web browser. CSS allows you to format that data in whatever way you wish. Javascript allows you to fetch and manipulate that data from your server (in addition to any fancy UI interactions you can't achieve with the first two).

My first thought was to use J2EE with Tomcat for realising the whole back-end - but will this be sufficient to communicate with the clients, i.e. take care of all the session administration and HTML/CSS/JavaScript-generation? Or do I add another layer of complexity, e.g., PHP?

You should think of these layers of your app as separate. You have your backend, which does all the heavy lifting, and provides data and services when you query it. This can be created in JavaEE. Now, your front end will have to display data, and allow users to perform actions which invoke these backend services, i.e., you might click an 'Add User' button on a form, and this tells the backend that you want to add a new user to your database. Your front end can be created for this purpose using HTML/CSS/and a javascript framework of your choice (some favorites are Angular.js, Backbone.js, Ember.js). There is no reason for another layer of complexity here, unless you wanted to introduce PHP instead of javascript as a mechanism to talk to your backend, but I would only worry about this if you have an existing PHP based application.

As performance (up to 25 clients might simultaneously request computational-expensive sub-routines), platform-independence (might run on Windows servers in future) and extensibility are important issues, I decided for Java. But would DJANGO or Ruby-on-Rails or PHP or something else be a sufficiently fast alternative to?

Using JavaEE, it is very easy to make extensible applications. You might want to do some reading on methods to handle this in the future, but for right now, I've always been told to worry about scalability when, and only when, scaling becomes a problem. Switching to another technology will provide you different solutions to your problem, but there are ways to solve this issue in any language you choose. If you go with the architectural choice to provide data via RESTful API on your backend, you can program an interface on any platform you wish, using whatever technology you'd like (web browser, iPhone, Android, command line, etc). If you are concerned about calculation speed on the back end, Java is going to give you an edge over PHP or Ruby.