Both of you are right and wrong at the same time. It mostly comes down to
semantics.
The traditional definition of client-server is the processing being shared
between the requester (client) and the backend (server). For instance, the
client sends a request to a server to extract records from a database. The
server pulls them from the database and sends them to the client. The
client then displays them, and the user can make changes. When the client
is finished doing its thing, it sends the changes back to the server, which
then persists the changes to the database.
Along came n-tier architecture. This is essentially an expanded
implementation of c-s, where tasks like enforcing data consistency and
business rules can be divvied-up among multiple processes on the back end,
where the "server" could be one or more physical computers or applications.
The line between client and server also can get rather blurred in the
business logic layer, where some components can be both consumers of data,
as well as originators. All in all, this cleans-up deployment considerably,
as you don't have to maintain the validation and processing logic across all
of the clients, and can rewrite or reconfigure the business logic layer with
little or no alteration of the client.
Web applications are basically a combination of both of these. They are
inherently c-s, in that they are useless without some backend to initially
push HTML and other data down to them and respond to the user's directives.
Their transmission medium is primarily Internet technology (namely HTTP).
However, clients these days can have varying degrees of "smarts" that enable
them to be active participants in the processing stream as well. For
example, a common design these days allows for offline use where an entire
database can be pulled to a laptop, the user goes on his or her merry way in
the field, and syncs-up their changes with the "source" at random points.
Another hallmark of a 'web application' is that it can have a "rich" UI that
maintains a level of realtime interactivity with the backend that approaches
that of a desktop application, without resorting to the contortions required
in "dumb" clients.
I'm only summarizing and over-simplyfing the concepts here. There are
considerably more subtle (and some rather arcane) elements to the
distinctions, but this should give you enough of a basic understanding.
Alan
"Matt" <ma*******@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
I think this is the basic concept in ASP server-side development.
My boss told me web application is NOT client-server application. I argued
with him because browser is the client, and the server code put in server.
Then web application should be a client-server application. My
understanding is that a web application is an application that runs on a browser. But
client-server application is not necessary a web application.
Please advise. Thanks!!
