Web-based clients vs thick/rich clients?

Question

My company is a software solutions provider to a major telecommunications company. The environment is currently IBM WebSphere-based with front-end IBM Portal servers talking to a cluster of back-end WebSphere Application Servers providing EJB services. Some of the portlets use our own home-grown MVC-pattern and some are written in JSF.

Recently we did a proof-of-concept rich/thick-client application that communicates directly with the EJB's on the back-end servers. It was written using NetBeans Platform and uses the WebSphere application client library to establish communication with the EJB's.

The really painful bit, was getting the client to use secure JAAS/SSL communications. But, after that was resolved, we've found that the rich client has a number of advantages over the web-based portal client applications we've become accustomed to:

• Enormous performance advantage (CORBA vs. HTTP, cut out the Portal Server middle man)
• Development is simplified and faster due to use of NetBeans' visual designer and Swing's generally robust architecture
• The debug cycle is shortened by not having to deploy your client application to a test server
• No mishmash of technologies as with web-based development (Struts, JSF, JQuery, HTML, JSTL etc., etc.)

After enduring the pain of web-based development (even JSF) for a while now, I've come to the following conclusion: Rich clients aren't right for every situation, but when you're developing an in-house intranet-based solution, then you'd be crazy not to consider NetBeans Platform or Eclipse RCP.

Any comments/experiences with rich clients vs. web clients?

Answer 1

As long as you're using Java Web Start for deployment, I don't necessarily disagree. The point of web applications in IT is to avoid the remote deployment mess of trying to update everyone to version Y when version X is no longer supported.

You get that for free with webapps.

Answer 2

One benefit is that a lot of calculations/validations can be done on the client side, this allows each client to share in the processing load of the overall application.

Another benefit of a thick client is that you hold your state in the client. This makes your servers stateless and they can scale a lot better as well as making fault tolerance a breeze.

In our case we have interfaces to hardware in our app, scanners are on serial ports to the workstations, We have also implemented a JNI layer to the printers so that we can have application control of Print Jobs from our application. (Invoice Printing)

For startup and distribution of new software we have an update jar that we run that checks a file on the local system against a deployed date on the server to see if the local system is up to date. If the System is out of date we download the jar files needed and then launch the app. This avoids the users from needing to go to a web page.

I also recommend this book for server side patterns as they relate to the new J2EE/JEE stuff.