***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
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.