Very Computer

can somebody out there explain to me, in plain language and layman's
terms, what do these two subjects mean and how do they work?

thanks in advance!!!

Client/Server is a term for information/resource
retrieval from one station (the server) to another (the client)
on a network.
The server side is anything that serves information to
the requestors (the clients)

Open Architecture is a term that describes computers that
conform to a set standard. Whether it be "de facto" (defined by
standards organizations) or "de jure" (defined by wide usage
within the industry though not defined by a standards org.)

I will give you a case study:

A small business has started up. In the way of information
sharing they are faced with the dilemna of how to access
and share resources. This is important because they are trying
to set up a computing environment that will help them be more
productive.

Lets start with their database. Information on contacts, meetings,
quotes, etc. is being kept within that database. There are two
options. The first is to keep the database in its entirety on each
persons computer, not networked. The second is to network the
computers together and have a dedicated computer that holds all
the database information centrally.

The first option is counter-productive. Especially in larger
organizations. If you are maintaining a database for each
person how will you know what each other is doing. Also it wastes
resources. The database itself will be on everyones disk space.

The second option will allow everyone to share a common database.
This will enable them to share contact information, meeting dates,
reports, form letters, quotes, catalogs, etc. If one person has
done a similar quote or form letter everyone will have access to
it. This eliminates the "double tasking" environment that is
created with the first option. This also facilitates electronic
posting of memos and other documentation. The document is put
on the server and the clients then can retrieve it. The first
option does this via "sneaker net" (copying the info on a floppy and
walking it to peoples computers and loading it)

This brings the company to the next decision. What if the servers
hard drive crashes?

First lets get into their computing environment. They want to use
pc's for the sales desktops and a IBM unix box for the server. They
also have a SPARC workstation that is for internet acces and email
routing. They also have HP workstations for their mechanical
engineering department. They are all on the same network and
use the same server. How? all these machines have different
operating systems and technologies!

This brings up the Open Architecture. They can all connect because
the Hardware, Software, and Networking are all based on open
architecture. These are the three tiers.

The company will run tcp/ip (a networking protocol) to have all
the computers talk to each other. They choose this because the unix
operating systems base their networking on this open architecture.
(that covers two tiers. The hardware supports the o/s (software)

They choose ethernet for their network. Ethernet is a networking
standard (defined by an org. (IEEE)) It defines the speed and physical
connections of the networking equipment. (cabling and network adapters)
(this covers the last tier) They chose this because it is supported
by most computers. It is based on open architecture.

Basically the Open Architecture means that you can communicate between
unlike computers based on standard formats of software, hardware, and
networking. Remember that all computers are talking digitally. When
you break it all down they are all translating binary information.
(0's and 1's in a certain order ie. 01101001 would translate the same
on all computers)

Now back to the disk crashing dilemna. They have chosen a back-up
software that is based on an open architecture. Meaning it will
back-up all their sytems from one computer. Their back-up will
be performed on a standalone pc that has mirrored hard drives.
(both hard drives have the same information on them) This can be
considered their back-up server and all the other computers back-up
clients. The software can pull data from the clients, even though they
are differnet types of systems, because it is utilizing the 3 standards
that I spoke of earlier. ethernet for network, operating systems that
support tcp/ip, and hardware that supports those operating systems and
ethernet adapters.

To sum it up. This company is on the right path to information
sharing and restoring based on its decision to go with a client/server
model with an Open Architecture design. The initial cost is more
than their first option but in the long run it is much cheaper. This
is based on the time saved. They can now also share printers, modems,
etc. All they have to do is connect them to their network.

I hope that explains it!

Bill N.

In a traditional client-server application, the client side focuses on
user interface while the server side handles business-specific methods  
(business practices, decisions, etc) as well as databases.

In a 3-tier application, the server side is typically decomposed into
a middle tier that supports the business methods and a lower tier that
handles databases. The middle tier servers act as servers to the
traditional clients, and as clients to the database servera and perhaps
to each other.

I'll try and cut through to the real world, which may skirt the
defintions, so anyone who wants to flame me can save themselves the
trouble - I won't respond!

Real world client/server entails systems using a Relational Database
Management system (RDBMS) like Oracle, Sybase, Informix or DB2.  These
systems and the way they work are derived from the research of IBM
fellow Dr. E.F Codd and are based on his rules.  One of these rules
is that the database must be accessible via Structured Query Language
(SQL).  SQL commands are sent by a client application to the RDBMS and

the RDBMS returns a result set of rows to the client.

In essence, what this means is that Clients need know nothing about
how the database works or how data is manipulated and retrieved.
These issues are handled by the server!

Most RDBMS now include the ability to run programs, usually called
stored procedures, on the server.  Usually this code is limited to a
subset of the SQL language itself.

3 Tier architecture extends this idea by allowing executable code to
be seperated and moved in a modular way from the client and server to
a 3rd location, which might be an application server.   3 tier
architecture is a specialized area that is usually necessitated by
tricky performance issues in high transaction, engineering or
manufacturing applications, and is not the norm in the client server
world.

BTW, this "don't bother flaming me" rhetoric which has become so
popular on netnews is all too often used as shorthand for "I don't
care to be careful about the opinions and purported facts I'm
relaying".  Either people want to engage in discussion -- and so need
to accept ownership of their statements -- or they should be content
to lurk.

Quote:>Real world client/server entails systems using a Relational Database
>Management system (RDBMS) like Oracle, Sybase, Informix or DB2.  These
>systems and the way they work are derived from the research of IBM
>fellow Dr. E.F Codd and are based on his rules.  One of these rules
>is that the database must be accessible via Structured Query Language
>(SQL).  SQL commands are sent by a client application to the RDBMS and
>the RDBMS returns a result set of rows to the client.

Distributed RDBMS access is a major c/s area.  It is not all of c/s,
even in the "real world".

Client/server -- in or out of the real world, however we want to
define that -- means distributing parts of an "application" into
multiple "programs".  An application is a collection of tightly-
integrated software that makes a computer do something useful with
the user's data.  A program is a piece of software that a computer's
operating system views as a single entity.

In simpler terms:

Client/server means getting two or more programs, on one or more
computers, working together to make a single application.  Often
an RDBMS is part of that.  Not always.  If we restrict c/s to only
mean RDBMSes, we'll need to invent a new term for a programming
concept that a lot of software is based on.

Three-tier is a particular case -- the application is broken up
into three chunks, usually a user-interface chunk, a business-
logic chunk, and a database chunk.

AAI Development, Micro Focus Inc.
Department of English, Miami University

Quote:

>>Real world client/server entails systems using a Relational Database
>>Management system (RDBMS) like Oracle, Sybase, Informix or DB2.  These
>>systems and the way they work are derived from the research of IBM
>>fellow Dr. E.F Codd and are based on his rules.  One of these rules
>>is that the database must be accessible via Structured Query Language
>>(SQL).  SQL commands are sent by a client application to the RDBMS and
>>the RDBMS returns a result set of rows to the client.

>This is certainly true of many, possibly most, real (in use in
>production environments) client/server systems.  However, much of the
>client/server code and traffic in use today has nothing to do with
>RDBMS access.  The WWW is client/server.  X Windows, and even to a
>lesser extent Microsoft Windows, is a client/server architecture.
>We've sold plenty of middleware to customers who use it to build
>enterprise mission-critical c/s applications that don't involve
>an RDBMS.

>Distributed RDBMS access is a major c/s area.  It is not all of c/s,
>even in the "real world".

Quote:

>Client/server -- in or out of the real world, however we want to
>define that -- means distributing parts of an "application" into
>multiple "programs".  An application is a collection of tightly-
>integrated software that makes a computer do something useful with
>the user's data.  A program is a piece of software that a computer's
>operating system views as a single entity.

>In simpler terms:

>Client/server means getting two or more programs, on one or more
>computers, working together to make a single application.  Often
>an RDBMS is part of that.  Not always.  If we restrict c/s to only
>mean RDBMSes, we'll need to invent a new term for a programming
>concept that a lot of software is based on.

The question is how often your suspicion is true -- that "when some-
one is asking 'what is this C/S all about'" they mean (or should
be answered with, since the question suggests that they don't know
what they mean) only RDBMS-related c/s.  (I won't debate whether this
is "the general use of the term"; the speech community that owns
the "general use" of a technical term that's migrated into the
mainstream is almost impossible to identify.  It's not the way I or
the customers I deal with use the term, but there's no way to prove
that my usage patterns are more or less general than yours.)

If the questioner's IS world begins and ends with RDBMS access --
as many do -- then this is a good assumption to make.  If not, it
isn't; a reply based on that assumption will be misleading.

Unfortunately, we don't know enough about the questioner in this
(or many other cases here) to decide what the context of the question
is.  You're leaning toward a more restrictive context that favors
simplicity and brevity of explanation; I'm favoring a wider and
more flexible one at the cost of simplicity.  I don't know of any
evidence that suggests that one approach is more likely than the
other to be the more appropriate one.  I've never seen a survey
of newbie questioners on comp.client-server, and that's what it would
take to demonstrate that a majority of them are in fact looking for
the simpler or the more complex answer.

There's an essential problem here with hopping on a technical
newsgroup and asking what its topic means.  It's rather like someone
jumping on sci.crypt and asking "What's all this cryptography and
cryptanalysis stuff about?".  The equivalent to your answer in that
case might be something like "using PGP to make sure that no one
else can read your email" -- the pop application of a complex
technical area.

Which is why, of course, M Chui's original question was a violation
of generally-accepted netiquette.  Newbies are supposed to lurk in
a group and read the FAQ before asking questions, to eliminate
precisely this sort of discussion -- the whether-to-simplify-the-
topic debate -- because it interferes with the BoF-style exchange
among knowledgable parties that newsgroups are designed for.  That's
the whole point of dividing them by topic.

IMO, when people violate this protocol (usually through ignorance,
not maliciously), it's best not to try to strip the response of
its technical complexity.  Let them know that the newsgroup exists
because the answers aren't simple, and people who already know a
lot about the subject still need to exchange ideas on it.  Then they
can learn a bit and begin to refine their questions, at which point
we can begin to restrict our answers to their particular situations.

This all certainly sounds like an academic debate.  It has real
consequences, though.  An undergraduate student in the humanities
taking an introductory computer-science course, fishing around for
research directions for a term paper, will be better served by the
more technically precise and encompassing answer than the "how
many people use the technology answer".  A mid-level manager told
to find out if this new IS buzzword is applicable to the department's
processing needs might well also need the broader answer.

There are simply too many cases where the stripped-down answer isn't
sufficient to justify using it when we don't know what the context
is, IMO.

Quote:>I certainly am not going to disagree with you here, but again, I feel
>that leaving out the RDBMS/SQL component, while "technically more
>correct", fails to tell the real story for must of us who call
>ourselves "Client/Server developers".

AAI Development, Micro Focus Inc.
Department of English, Miami University

(...other very helpful text deleted...)
: 3 Tier architecture extends this idea by allowing executable code to
: be seperated and moved in a modular way from the client and server to
: a 3rd location, which might be an application server.   3 tier
: architecture is a specialized area that is usually necessitated by
: tricky performance issues in high transaction, engineering or
: manufacturing applications, and is not the norm in the client server
: world.

What the norm is depends on what you are doing I suppose.
I've kept awfully busy over the past 5 or 6 years doing 90%
3-tier architecture work.  In businesses dealing with large
customer databases, 3 tier architectures have been the norm
for a long time.  Satisfactory performance in a client/server
application is nearly impossible without going the 3-tier route
when you have to deal with large amounts of data.  It's not just
a performance issue either.  A 3-tier architecture is also very
beneficial when your application requires control, reliability,
scalability, flexibility, connectivity and the need to avoid a
proprietary solution.  Gary Long occasionally posts a paper
to comp.client-server discussing these aspects.  The last email

--

Scot Cunningham

  URL: http://www.seidata.com/~scunning

Opinions expressed are mine and not my employer's.

Quote:>>Well, I guess this is exactly my point.  Taken to the abstract, any
>>system which involves communication can be considered client/server,
>>but I suspect that when someone is asking "what is this C/S all about"
>>I take that to mean the general use of the term, which I would hold
>>does entail the use of the an RDBMS and SQL.
>I think there's a problem of pragmatics (in the linguistic sense)
>here.  I certainly see your point -- for many people in the industry,
>at many levels (technical, managerial, user), c/s means distributed
>database access and only that.
>The question is how often your suspicion is true -- that "when some-
>one is asking 'what is this C/S all about'" they mean (or should
>be answered with, since the question suggests that they don't know
>what they mean) only RDBMS-related c/s.  (I won't debate whether this
>is "the general use of the term"; the speech community that owns
>the "general use" of a technical term that's migrated into the
>mainstream is almost impossible to identify.  It's not the way I or
>the customers I deal with use the term, but there's no way to prove
>that my usage patterns are more or less general than yours.)

I can only hope that our discussion has served the purpose in
exploring this issue in such a way that if anyone was interested in
what the C/S industry is about they would certainly have a good idea
at this point, both in terms of the theoretical, and the pragmatic.  I
suppose I approached the original question from the point of view that
the poster might be someone who was interested in exploring the field
with an eye on seeking employment.  

Now in terms of the "flame" issue, sure enough I have received a flame
mail, which perhaps was also posted publicly on this forum,  from one
seriously angry and impatient individual, accusing me of being rude,
shortsighted, and ignorant of what C/S is really all about.  It
included a nice lecture about XWindows being an example of the true
client server model of which I am apparently so woefully ignorant.

I suppose this is my fault for predicting such an event, as it will
almost certainly be a self-fulfilling prophecy.  Nonetheless, I would
hope that those of us who make a living implementing C/S based
technology would be excused the excess in the client-server usenet
group of being "allowed" by the netcops among us to describe to others
what we do in context of the term.

I also don't agree with your assessment that adding in 3 tier to the
mix is going to intrinsicly add reliability, since in my experience
the more moving parts, the more potential failure points.

Nonetheless I do see the potential of 3 tier and would appreciate a
substantive discussion of its application at the mainstream level.  I
believe what would be helpful both to myself and others here would be
if people like yourself, who work with the technology on a frequent
basis were to explain the advantages and pitfalls of using it, what
products you've had success with and in what situations it proved to
be useful.  I think this would get us all a lot farther down the road,
than by refering to a white paper which gets posted here once and
awhile.