Web clients versus fat / rich clients?
My company is a software solutions provider for a large telecommunications company. Currently, the IBM WebSphere environment is based on the IBM Portal front-end servers communicating with a cluster of WebSphere Application Servers back-end that provide EJB services. Some of the portlets use our own home MVC pattern, and some are written in JSF.
We recently made a rich / fat client proof-of-concept application that communicates directly with EJBs on back-end servers. It was written using the NetBeans Platform and uses the WebSphere Application Client Library to communicate with the EJB.
The really painful bit was that the client was using a secure JAAS / SSL communication. But after this was resolved, we found that the rich client has a number of advantages over the web client applications we are used to:
- Huge performance advantage (CORBA vs HTTP, cut out the middle Portal Server)
- Development is simplified and accelerated through the use of the NetBeans visual designer and robust Swing architecture.
- The debug cycle is shortened if you don't need to deploy the client application to the test server.
- No problem with technologies like web development (Struts, JSF, JQuery, HTML, JSTL, etc.).
After much pain of web development (even JSF) for a while, I came to the following conclusion: rich clients are not suitable for every situation, but when you develop your own intranet based solution, then you would be crazy not to consider NetBeans Platform or Eclipse RCP ...
Any comments / experiences with rich clients and web clients?
a source to share
One advantage is that many calculations / validations can be performed on the client side, allowing each client to share the processing load of the entire application.
Another advantage of the fat client is that you keep your fortune in the client. This makes your servers stateless and they can scale much better and also make fault tolerance easy.
In our case, we have interfaces to hardware in our application, scanners are on serial ports on workstations. We also implemented a JNI layer for printers so that we can manage Print Jobs applications from our application. (Print invoice)
To launch and distribute new software, we have an updated jar that we run that checks the file on the local system on the 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 required and then launch the application. This prevents users from going to the web page.
I also recommend this book for Server Side Templates as they relate to new Java EE stuff.
a source to share