Web-based clients vs thick/rich clients?
- by rudolfv
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 in 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?
