for a student project i am evaluating certain frameworks like Droplets or Ultra Light Client for a Thin Client over
Internet. A Thin Client means that the presentation layer runs on the client while the application logic remains on the server. The project is for a company that has a B2B protal and wants to integrate a Clientapplication with maximum userbility and a GUI. The Clientapplication must fit into the J2EE structure of the B2B and have the "Look and Feel" of a Desktop Application. One solution could be the thin client solution like Droplets etc. Another solutionen could be a Fat Client where the presentation and application logic is on the client and the whole application is distributed via Java WebStart or a DeployDirector, Marimba Castanet etc.
I would like to know arguments, opinions which solution you would preferred in certain situations. Maybe you hav pro?s or contra?s, so please let me know.
A good solution that I have had positive results with is to make a Swing client, distributed via WebStart that uses EJB for business logic. While it's hard to think of Swing as "thin", you can have a desktop app that looks like others (assuming this is Windows, but obviously it works for everything else with a JVM), but you have all your business logic on the server and you can tweak that w/out having to redistribute.
WebStart is the easiest installation mechanism I've seen that can keep you up to date. You just deliver your jars, with a jndi.properties that points to your server and you are ready to go. After 2 executions of the program, Webstart even puts an icon on the user's desktop.
The only thing you need a website for is to provide the webstart link.
The advantages is that Swing is way more established and standard than many of the other technologies you list, and it is free; all you need is a JRE on the client.
Disadvantages is that swing apps tend to be less responsive than real native apps (though this is getting better all the time!).
I would say that you should use Webstart/Swing/J2EE unless you have a strong reason not to because they are standard and in widespread use and very flexible.
another aspect ist the problem of communication with the business logic in an application logic behind an firewall.
You cannot use RMI or IIOP - one way is to represent every EJB with a servlet. Exist there any frameworks that solve the problem? Which protocol did you use for communication with the business logic?
The stuff I have done was on an intranet, so there were no firewall issues. It may be possible to run RMI or IIOP over port 80 to get around it, but your idea with the servlets would work. You would want something like Web Services where requests and responses are in XML and exposed over port 80. Even if you can't/dont' want to use web services, you should still consider XML as your communication format, as it's standard and there's freelyi available parsers, so you don't have to make up your own format.
Of course, whoever's asking you to write this should want to help you out and maybe open up a port in the firewall if you can't do EJB over port 80. You can make the RMI communication encrypted via SSL, so you can make it secure even if you open up another port on the firewall...
I am not sure if this answers your question. However, you may also want to look at a Flash (Macromedia) Client going against J2EE.
Why not use Thinlet over JProxy? You'll get all of J2EE API accessible over the Internet and a nice looking XUL based UI with client runtime less than 150KB.http://www.thinlet.comhttp://jproxy.com/thinlet/demo.html