Re(2): "Thin Client" Paradigm

Re(2): "Thin Client" Paradigm

Post by John Ma » Wed, 27 Dec 1995 04:00:00



IM.HO, there are complicated issues re: C/S design.  I think important
distinctions are sometimes left out (for brevity, perhaps), and when that
happens the arguments can go on and on without resolution.   My rule would be
to place OFF the client any and all application code that implements business
rules.  That is, I would try to make sure that the world's best hacker could
alter any client code and alter any traffic from client to server all s/he
wanted, and it would not affect the operation of the application (other than
issuing unusual error messages) or affect the content of the database.  To me,
this means "thin client" in many cases.  But if the application is helping a
user - say, doing chip design or composing a memo or putting together a
compound document (with some spreadsheet calculations on the side), then you
might call that a "fat client".  But it also could be considered thin in that
there is only user-helping code out there on the client.  I'm all for
empowering the end user - for certain things and certain things only.  

I wouldn't even let the client do input data validation.  Well, I'd let the
client do nice, friendly user input validation, but I would do it all over
again (as efficiently as possible, no need to be friendly) on a secure server.
  The server written today for a single application may someday be drafted
into service to answer requests from multiple client applications in 1999 or
so.  If that happens, we'll want that server to be self-sufficient, reliable,
robust, to "know who s/he is" and not be dependent on some  client-spouse.  If
I may use a wild metaphor.

 
 
 

Re(2): "Thin Client" Paradigm

Post by Jonathan Euni » Sat, 30 Dec 1995 04:00:00



Quote:> [...] My rule would be to place OFF the client any and all application
> code that implements business rules.  That is, I would try to make sure
> that the world's best hacker could alter any client code and alter any
> traffic from client to server all s/he wanted, and it would not affect the
> operation of the application (other than issuing unusual error messages)
> or affect the content of the database.  To me, this means "thin client" in
> many cases.
> But if the application is helping a user - say, doing chip design or
> composing a memo or putting together a compound document (with some
> spreadsheet calculations on the side), then you might call that a "fat
> client".  But it also could be considered thin in that there is only
> user-helping code out there on the client.  [...]
> I wouldn't even let the client do input data validation.  Well, I'd let
> the client do nice, friendly user input validation, but I would do it all
> over again (as efficiently as possible, no need to be friendly) on a
> secure server. The server written today for a single application may
> someday be drafted into service to answer requests from multiple client
> applications in 1999 or so.  If that happens, we'll want that server to be
> self-sufficient, reliable, robust, to "know who s/he is" and not be
> dependent on some  client-spouse.  [...]

And I heartily agree with each of them!

--
Jonathan Eunice                       Director, client/SERVER Companion


 
 
 

Re(2): "Thin Client" Paradigm

Post by w.. » Thu, 04 Jan 1996 04:00:00


***I seem to have a different perspective than John Mann

    Issue in the evolution of Client/Server computing in business.    


Quote:> [...] My rule would be to place OFF the client any and all application
> code that implements business rules. . . .

***Before computers, and still today, PEOPLE "implement business rules".
   The 'client' in client/server is a computer program that is intended
   to assist the PERSON using it (aka User).  The best possible assistance
   can happen when there is maximum 'bandwidth' between the User and the
   business rule code in execution.  If this code is executing in the
   'client' computer, the available 'bandwidth' between it and the User
   is huge, zero latency, and essentially free.  If the code is executing
   in a distant shared 'server' then bandwidth is likely to be low, with
   latency measured in seconds (not milliseconds), and often expensive.

   I'm a strong believer in the merits of local execution of code,
   including code that 'implements business rules'. (Local to the User)
   I think those advocating 'remote execution' are fighting a battle that
   is already lost.  No User wants time sharing after they've seen a PC!!
    (Paraphrase of: "How can you get em back on the farm after they've seen
     Parieee.)
   Heck, local execution is at the heart of the PC revolution.

Quote:> That is, I would try to make sure
> that the world's best hacker could alter any client code and alter any
> traffic from client to server all s/he wanted, and it would not affect the
> operation of the application (other than issuing unusual error messages)
> or affect the content of the database.  To me, this means "thin client" in
> many cases.

***Security from "the world's best hacker" is needed, but why is "thin client"
   seen as a security solution?  I don't follow the logic.  I think
   the Automatic Teller Machine (ATM) is good evidence for the security
   that can be delivered by a "thick client" implementation.  ATMs are
   in public areas, hold about $50,000 cash each, and execute 'client
   business rule code' that IF HACKED could easily dump cash by the
   bucketful.  There could not be a better incentive for "the world's best
   hacker" to "alter ... client code".  It does not happen for ATMs and
   need not happen for other thick clients if systems are prudently engineered.

   I believe the typical "thin client" is likely to be less secure against
   hacking.  Thick or thin, if client code is altered, (or a real client
   spoofed by a hacker), then the objective stated above to "not affect
   the operation of the application . . .or the contents of the database"
   is just plain impossible anyway.  Thickness or thinness seems to me
   to have little to do with security.  

Quote:> But if the application is helping a user - say, doing chip design or
> composing a memo or putting together a compound document (with some
> spreadsheet calculations on the side), then you might call that a "fat
> client".  But it also could be considered thin in that there is only
> user-helping code out there on the client.  [...]

***I'm opposed to any code that is not 'user-helping code'.  If code is
    not helpful in some direct or indirect way, then dump it. :-)
   I sense some kind of 'hierarchy of importance' is behind the reasoning
    presented above.  "My 'business rule code' is more important than your
    "spreadsheet calculations on the side".  Actually the reverse is more
    likely to be true.  The 'spreadsheet calculations' may be the basis
    for a corporate business decision to terminate the in house IP
    department (and all their 'business rule code') in favor of outsourcing. :-)  

Quote:> I wouldn't even let the client do input data validation.  Well, I'd let
> the client do nice, friendly user input validation, but I would do it all
> over again (as efficiently as possible, no need to be friendly) on a
> secure server. The server written today for a single application may
> someday be drafted into service to answer requests from multiple client
> applications in 1999 or so.  If that happens, we'll want that server to be
> self-sufficient, reliable, robust, to "know who s/he is" and not be
> dependent on some  client-spouse.  [...]

***This touches tangentially on the really big problem with Client Server
   that is not talked about.  The problem is implied by the "do it all
   over again" notion and the 'future different and multiple clients'
   'same server' notion.  

   The really big problem is: in accepted C/S practice today the
   Client and Server parts of an application are vastly different:
     (Different programming languages, different developers, different
      development/test environments, different schedules, different deployment...)
   This duality just has to be a lot harder to build and harder to keep
   working than the singleness of a centralized traditional application.  

   Those advocating 'thin client' are correctly minimizing complexity
   by shrinking one side of the duality.      

   Instead, postulate a 'Unified' development environment where Client and
   Server partitioning is just a deployment issue.  In this brave new 'unified'
   world all computers (clients and servers) run the same code; developed/tested
   at the same time by the same group of developers.  In this world there
   is no development cost to "do it all over" since once developed, the code
   to 'do it' (whatever it is) can be deployed and executed at Server, Client,
   and New Client(s).  Application Evolution in this Unified world is thus
   no harder (and no easier) than it used to be before C/S.  

   I've seen the benifits of the "Unified" C/S approach pay off in production
   since 1987 with large scale misson critical systems.  A company I co-founded
   (and am still an investor in) built the required "Unified C/S toolkit"
   and 4GL way back then, and have continued developing the toolkit since.      

   The problem until recently was that "Unified C/S" required all computers,
   both Clients and Servers to be from the same cpu and OS 'family'.
   Thus the natural choice of PCs as Clients dictate PCs as Servers too -
   a somewhat closed approach.  

   Personally I'm e*d by the potential of new languages such as Java
   for "Unification" of C/S code across diverse platforms.  I hope the company
   I mentioned above decides to 'port' its Unified C/S 4GL toolkit to take
   advantage of the cross platform capability of Java.