Pros And Cons Of Thick Client/Thin Client

[Reza Rahman]

Hi All:

I think there is little doubt that all of the Sun assignments can be solved successfully through either a thin or thick client approach (people have been successful using both and thank goodness for that - where would we be if there was a single silver bullet to the project?).

However, I'd like to get everyone's help to catalog the pros and cons of both the thin and thick client approaches in turn (I'll collect as much as I can from previous posts). I'll keep a running list at the bottom of this message and will keep editing it as points are added.

Again, my goal is not to "prove" that one approach is "better" than the other, it is to better understand both solutions and hopefully make an educated guess that suits me and hopefully some other people the best (not to mention write a killer choices.txt to boot ).

As always, please be mindful of the rules of the forum in not discussing too many details of a specific implementation (I think that is in everybody's best interest)...

Note:
Please do not be shy about asking anyone to document any claims made about any aspect of the JVM pertinent to this issue. Sockets/RMI seem to be a frequent subject of (mostly unintentional) unsubstantiated claims on various posts that could potentially mislead hundreds of fellow forum members. Fortunately, there are many good sources of documentation on virtually any aspect of the JVM, including books, Sun, JavaWorld, JDJ and Usenet postings.

In the least, producing general purpose code that can be run on a specified platform to prove your point should be easy enough to do.

Please be very courteous while asking for substatiation. Feel free to refer to this section if it makes things easier. This is a standard practice in scientific and logical discourse and nothing to be ashamed about.

Thin Client:
    Pros:
     
    Cons:
 
Thick Client:
    Pros:
 
    Cons:

Thanks in advance for your kind participation.

Reza
[ June 07, 2005: Message edited by: Reza Rahman ]

[Andrew Monkhouse]

Hi Reza,

Have you looked at the pros and cons listed in the topic "Should lock methods be callable by the client"?

Regards, Andrew

[Reza Rahman]

Andrew:

The thread you linked to is a great starting point in this discussion. However, I think the general consensus of the thread was that both are valid approaches, would you not agree (or did you want to mention it for background)?

Reza

[Lara McCarver]

Can you clarify your question a little more? Where I work, when people talk about "thick clients" they are talking about traditional native applications (like Java with Swing or VC++ with MFC). And when they talk about "thin clients", they are talking about web applets running under Tomcat or maybe under an App Server, with either HTML or an applet on the client side. I have actually worked with both types of applications, but I didn't think that a web application using Tomcat would work given the design requirements.

So now I am thinking... maybe you are talking about something else. Maybe you are talking about whether the client uses the exact methods that are exposed through the Data interface, or uses something a bit more business-oriented. I am not sure which would be considered "Thin" and which would be "Thick".. I guess if you have a layer on top of Data which the client actually uses, that is "Thick"?

[Reza Rahman]

Lara:

You are absolutely right, what you mentioned is the popularized usages for the terms, but isn't really their original meanings (If you have ever used a cable settop - the interface you deal with on your TV screen is called a "thin client" even though there is no HTML involved; this is becuase these interfaces do little more than communinate over the cable network to the remote servers that do the actual video/image streaming). Just to clarify:

What I meant by "thin client" is that the GUI part only deals with presentation (minimally Swing with a server "proxy" - kind of what the role of JSP/HTML/CSS/XML in the J2EE world). This means that business logic is handled on the server on a pseudo "business layer" (the equivant of an app server/EJB layer) and the "low level" data access object methods are abstracted behind a server facade. Here is a useful definition: http://www.webopedia.com/TERM/T/thin_client.html

On the other hand, by "thick client" I mean the case in which the client application handles both the business logic and the presentation and makes "low level" data access object calls across the network.

The Applet-to-Server communication scenario (I'm assuming this is what you had in mind) is actually a borderline case. As context, early Applet marketing heavily favored a thick client approach (on top of a thin-client platform).

Note, clearly there is a lot of J2EE bias in the terms I just used to describe both cases. However, hopefully the critical eye will filter that factor out...

Reza
[ June 08, 2005: Message edited by: Reza Rahman ]

[Andrew Monkhouse]

Hi Reza,

The thread you linked to is a great starting point in this discussion. However, I think the general consensus of the thread was that both are valid approaches, would you not agree (or did you want to mention it for background)?

I was more thinking that there were a lot of Pros and Cons for both scenarios listed in that thread. I thought that might give you a starting point.

I do agree that either approach can lead to a passing score, and neither approach appears to be favoured by the assessors at this time.

Regards, Andrew

[Frans Janssen]

I do agree that either approach can lead to a passing score, and neither approach appears to be favoured by the assessors at this time.

FWIW, I fully agree with Andrew's statement here. I think I also share Andrew's opinion that - bases upon the instructions - the assessors ought to favour the fat client approach. But somehow they don't, so Andrew and me might just be plain wrong

Frans.

[Andrew Monkhouse]

.. so Andrew and me might just be plain wrong