• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

thin vs. fat client concept

 
Ranch Hand
Posts: 150
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 150
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 150
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... 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
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's not fat, it's big bones! - for other South Park lovers
 
She said she got a brazillian. I think owning people is wrong. That is how I learned ... tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic