This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Is there something wrong with �fatter� clients? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Is there something wrong with �fatter� clients?" Watch "Is there something wrong with �fatter� clients?" New topic
Author

Is there something wrong with �fatter� clients?

Michal Harezlak
Ranch Hand

Joined: Jul 06, 2000
Posts: 185
Ok, I am not entirely sure if that is a right forum to post my question. It has many aspects (I think), it is rather a question of architectonic nature. Please correct me if I am mistaken posting it here.
I am trying to decide on architecture of a solution that has rather complex UI in the back office component. This app will be hosted in one place and accessible by clients from all over the world. It will have to be accessible trough firewalls with not or minimal configuration at clients firewall settings (port 80 using https). I am trying to figure out if it is feasible to use applet swing client. I have not seen many projects using this approach as a mater of fact just one. It was rather complex time tracking/accounting system. I was not very impressing with speed of the interface at times (dual processor). I could not see any prohibiting risk when I thought about this yesterday. I am starting to suspect that this whole HTML interface (APS/JSP) thing is web designers conspiracy .
Risk:
-Java Swing performance (I am not sure it that is still the case),
-Maintainability (client code will be on client workstation how to manage updates and version control WebStart?),
-Proprietary protocol over HTTPS and in case of use of XML considerable stress on client�s workstation resources ergo performance drawback,
Benefits:
-Sending just data not interfaces over the network therefore lower traffic (not sure if that is very important when using proxies on client side),
-Event driven interface with well defined and proven components therefore more intuitive, consistent and maintainable,
-Productivity tools available,
Any thought ideas, pointing out my faulty logic or misinformation will be greatly appreciate!
Best!
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Fat clients are appealing because you can do a genuine stateful business object model and some very sophisticated things with the user experience. And as you said, you can keep data in the client and work with it all day without calling the server.
The big negatives are all those deployment and configuration problems. Avoiding conflicts with other apps on the desktop, pushing releases, etc. I see people using more and more thin client even in the corporate setting where we own and control the user's desktop machine. Total Cost of Ownership is a big deal.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
If you are going to do fat clients then you are going to want to look at something like Java Web Start.


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Michal Harezlak
Ranch Hand

Joined: Jul 06, 2000
Posts: 185
Guys,
Thanks a lot for your valid suggestions. It seems that WebStart mentioned by Thomas takes care of problems with deployment aspect of maintainability (run time environment and versions) therefore TCO should not be affected here. I intentionally used �fatter� instead of fat client. That might be a crazy idea, but I intend [not sure exactly how yet] to use it as a stateless client just for sake of benefits [is that proper English sentence ] that Swing gives in GUI development over HTML derivatives.
Thanks again.
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4340
    
    2

just an aside really. i like doing everything on the server when i can. the app looks the same to everyone, and no browser problems. of course, as you mentioned, you have an intensive interface and many simultanious clients. in some ways its nice to have a record daily user rate of 20. :roll:


SCJP
Visit my download page
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
And don't forget that there are a whole range of options between a wholly-client application and a wholly-server application.
For example, I've seen a few fairly impressive applet clients where most of the processing, and even the UI configuration, is on the server. A generic UI applet recieves instructions from the server about which swing UI components to lay out, where to put them, and what to do with the events generated. The advantage of this is that it's easy to use regular HTTP as the client/server transport.
I recently saw a demo of a pre-built RAD framework like this from Mart Technology, but it's also possible to "roll your own".


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Michal Harezlak
Ranch Hand

Joined: Jul 06, 2000
Posts: 185
Thanks!
Specially thanks to Frank for Mart Tech link, must check it out ASAP.
I see three aspects to this decision.
Maintainability
I will need to have HTML base interface no matter what. This app has front and back office. Front office is traffic intensive but with simple interface. So using load balancer and web container + sending messages to (MDB) search and submitting loads of data should work like a charm on front office side.
While back office is transactions, processes and basically used by a user throughout his entire day of work.
Deployment seems o be not a problem when employing WebStart although it adds to complexity and managing complexity, specialty the more complex ones is not easy.
Keeping it simple
Introducing two different sets of tools for developing UI is not wise. Needs more resources and discipline and in result is costly.
Productivity :
I need productivity TOOL that kicks [Three character word]. I can much easier get it done with Swing applet then designing HTML with GUI artists and such. Their designs needs to be redone with JSP/Struts/Sofia guys. It takes time and is tricky but looks prettier and my users are used to HTML interface, I still suspect they would love Swing, this must be validated with prototype.
I cannot make up my mind!
Thanks again!
Tonny Tssagovic
Ranch Hand

Joined: Dec 30, 2003
Posts: 226
Originally posted by Frank Carver:
A generic UI applet receives instructions from the server about which swing UI components to lay out, where to put them, and what to do with the events generated.

Well this is what I thought I should do to have a cool dynamic client GUI, but it was for a Midlet (j2me) so I though this is infeasible, because of the constraints imposed by the mobile device (memory and CPU speed), and I will end up having an �interpreter� of my own language running in a mobile device on top of KVM which is interpreted to the underlying OS all running on a slow CPU
Is this feasible, or it would not even run?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Have you considered WAP (WML is kind of like HTML for mobile devices)?


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Michal Harezlak
Ranch Hand

Joined: Jul 06, 2000
Posts: 185
MIDP vs. WML. I had this dilemma on my last project it went down to MIDP not being easily deployable and maintainable on all kinds of phones (it could be anything but my app was for phones). WML is totally client independent but lacks well defined interface. Exactly same problem with swing and HTML. MIDP is of course the choice for all off line capabilities.
Ok. Lets get back to my problem! I cannot put my finger on it put there is some problem with Swing Web based clients, perhaps it is this proprietary protocol that needs to be developed for communication with the server. BTW I remember seeing something in the vision document [or somewhere else] about enabling my users doing work off line. Is it really necessary and good idea to spend money all this hassle with keeping data up in sync. IMHO if you are at a place that dose not have net hookup you should not be working anyway.
Best and thanks again for all your help.
BTW I came across this little thing called WebCream http://www.creamtec.com/webcream [no it is not a porn outfit] it lets you port Swing apps interface to web with no effort and there is something called XUL (XML UI Language). I must investigate.
Best!
[ February 21, 2004: Message edited by: Michal Harezlak ]
Tonny Tssagovic
Ranch Hand

Joined: Dec 30, 2003
Posts: 226
Thought about xHtml, Symbian OS Epoc, windows CE, Brew , wap and chose J2me.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Is there something wrong with �fatter� clients?
 
Similar Threads
Design review
Session state management
Thin Client/Fat Client?
Why Swing client at all?
keeping http clients up to date