File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes thin vs. fat client concept Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "thin vs. fat client concept " Watch "thin vs. fat client concept " New topic
Author

thin vs. fat client concept

Andy Jung
Ranch Hand

Joined: Feb 07, 2010
Posts: 150
Hi all,

What actually makes up a thin and a fat client in the special context of this assignment?
I think there's some confusion about this in this forum (me either ).

Regards,
Andy


SCJP, SCJD
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5398
    
  13

Hi Andy,

It's easy: if your business logic resides on the server, you have a thin client. Otherwise a fat one.

Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
Hi,
I also expressed my doubts in the other thread.
Why do you call locking a record on the client 'business logic on the client'? I don't understand this. All locking is done on the server, these are just 2 methods that the client can call.
Can you clarify?

Wujek
Andy Jung
Ranch Hand

Joined: Feb 07, 2010
Posts: 150
Roel De Nijs wrote:
It's easy: if your business logic resides on the server, you have a thin client. Otherwise a fat one.


If I rely on this definition (and this is the commonly used definition) I would have a thin client too, because all my business logic is on the server.
My client just initiates locking / unlocking but does not implement this.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5398
    
  13

If you expose lock, unlock, update,... methods to the client you have a fat client. If you expose only a book-method to your client you have a thin client.

In a thin-client to book a room:
And in this method you'll have (simplified):

In a fat client to book a room:

When you have to change the logic of the booking process (for example add a check to see if it was already booked) and you only have to change code server-side you have a thin client. If you have to redistribute all your clients, you have a fat client.

Kind regards,
Roel
Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
I date to have second thoughts on this.
If you have a steady API which exposes the locking API (as you do for the assignment), and only the implementation changes on the server side - you don't have to redistribute the clients.
If you change your server by changing the book() method signature (which locks - books - unlocks), you also have to redistribute all your 'thin' clients. The 'thin' vs 'thick' in this case is simply 2 methods more and more fine grained functionality. Nothing special happens on the client actually - I still call to the remote service, I just use more methods.
For me it is just a matter of finer vs. coarser granularity of the service.

Just a question copied from the other thread:

- when 2 users (that work for B&S, they are called CSRs in my specs, that serve clients booking contractors for them) use this app and both have a certain record displayed and want to book it - what you get is more or less what is called a 'lost update' in databases - CSR A locks the record - atomically; CSR B sees at this point an outdated record information and thinks the record is free, so books it (again, atomically), and all goes well, except that CSR A thinks he owns the lock, tells the client of B&S that the booked contractor will come on Monday at noon, but actually the contractor will go to whomever CSR B was serving - this is a great bug in the application IMHO; the client of CSR A would also be very disappointed with the service and I would say it means death for B&S in the real world
- on the other hand, when you expose locking, and make the policy among CSRs that they should never ever touch booked records - you can enforce correctness; OK, the policy might seem flimsy but this is the most I can take out of my requirements, normally I would impose much stricter rules, like remembering who booked a record and only allow that CSR to unbook it, with ability to take down old lingering locks on the server side by some superuser

I would dare to say that such a 'thin' client is unusable and error prone (see first hyphen and its use case). It is not real world, fair enough, but it is pretending to be...

Roel said:
When you have to change the logic of the booking process (for example add a check to see if it was already booked) and you only have to change code server-side you have a thin client. If you have to redistribute all your clients, you have a fat client.

No, I don't - the signature of the lock method is still the same, the check is the new thing that is done on the server anyways.

Regards,
Raf
Andy Jung
Ranch Hand

Joined: Feb 07, 2010
Posts: 150
... so I have a thick client, because I expose lock and unlock to the client to prevent lost updates?
For me the workflow (client side)

is just basic business logic on a very high level.

Actually I like Rafs definition "finer vs. coarser granularity of the service" much better than thin vs. thick client.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5398
    
  13

if your lock method is callable from the client, you have a thick/fat client. Otherwise you have a thin client. Should lock methods be callable by the client is an interesting discussion
Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
It's not fat, it's big bones! - for other South Park lovers
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: thin vs. fat client concept