• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why are clients so thin?

 
Frank Silbermann
Ranch Hand
Posts: 1408
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the old days of two-tier client-server systems, database-oriented applications would download a mass of data, let the user hack on it, and then submit the changes. (This sort of implies optimistic locking, I guess.) Business logic was all on the client.

These two-tier systems had a few weaknesses:

(1) The effort of installing new versions of client software.
(2) Limited scalability.
(3) Difficulty imposed by firewalls standing between the client and server.
(4) Unnecessary network traffic when a single user interaction produced a small value after examining a large amount of data.

In response, we seem to have gone to ultra-thin web clients, and strive to move business logic as close to the database as possible. But is this not an over-reaction? It seems to me that a which minimizes network traffic will most likely divide business logic between the client and the server.

Java WebStart eliminates problem the client software installation problem (1). Placing appropriate (but not necessarily all) business logic on the back end would eliminate problems (2) and (4).

Firewall issues (3) may mandate a web front end, but we can still think of the web tier as being a fat client to the EJB tier. And it seems still appropriate to me to strive to minimize the network traffic between the webserver and the EJB server -- therefore splitting business logic between them. I admit, I don't like to see business logic in servlets and JSPs, but these web components are certainly able to reference web tier POJOs (plain old Java objects) that contain the business logic and communicate with the EBJ tier.

Since the FBN problem is performance sensitive, it seems to me that maybe we should consider splitting business logic between the EJB tier versus POJOs referenced by both web components and the fat client. Communication between the two sets of business logic could be done via Java serialization of objects (as an alternative to the more common record-oriented data transfer object).

But I am afraid to take this approach, as I cannot recall any appropriate patterns to cite or guide me. Can anyone please comment on these ideas, and maybe suggest a few patterns that are appropriate for the partitioning of business logic in this way?
 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Frank,

You phrased your question eloquently!


> In response, we seem to have gone to ultra-thin web clients, and strive to move
> business logic as close to the database as possible. But is this not an over-reaction?

I don't think it is on over-reaction. I think it dramatically simplifies the life of practically millions of human end-users. I can't imagine any valid counter-argument for that. These ultra-thin web clients also open the door for all kinds of hand-held devices. Without the ultra-thin clients they just can't exist.

Regards,
Dan
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic