"John Larsen" <jola_at_get2net_dot_dk> skrev i en meddelelse
news:3cd99ba9$0$68572$edfadb0f@dspool01.news.tele.dk...
>
> "Harald" <swobu@kroning.dk> skrev i en meddelelse
> news:3cd9035f$0$58769$edfadb0f@dspool01.news.tele.dk...
> > Kom bare med den lange version, jeg tror jeg ved nok om det til at kunne
> > forstå det. Jeg har rodet en del med databaser og TCP/IP protokoller.
>
>
> OK - Men så starter vi lige med at sige at Client/Server ikke nødvendigvis
> har noget med databaser og TCP/IP at gøre
>
> Client/Server teknologi er i princippet uafhængigt af protokoller, da det
er
> en beskrivelse *ikke* et system, man kan opbygge systemer Client/Server.
>
> Når det er sagt så er netop database et meget godt eksempel på en typisk
> Client/Server opgave.
>
> I virkeligheden er Client/Server en tanke, eller et koncept på nydansk -
> hvor man forestiller sig at een proces forspørger en service fra en anden
> proces der servicerer, Grunden til at man anvender Client/Server er at,
ved
> at opdele processerne kan man uafhængit af hardware og styresystemer lægge
> de processer på den hardware/software konfiguration der er bedst egnet til
> at styre den pågældende proces. For at tage databaser, kan man snilt
> forestille sig en UNIX maskine med en skovlfuld RAM og en passende
> processor, der egner sig godt til FireBird - men måske mangler lidt i GUI,
> tilgengæld har vi så en Windows der ser godt ud på overfladen - men
mangler
> lidt i stabilitet, disse egner sig glimrende til den alm. bruger ved et
> brugervenligt design og flotte farver, at kører klientprogrammet på (dit
> program). Dit program behøver ikke bruge alverdens resourcer på at sende
en
> forespørgsel til FireBird, maskinen med FireBird behøver ikke bruge
alverden
> af resourcer på at give et flot indtryk.
>
> Da en DatabaseServer (FireBird og de servere jeg kender til) kan arbejde i
> adskildte processer (tråde) kan de således besvare forespørgsler fra flere
> klienter af gangen, og skal kun holde rede på transaktionerne for at sikre
> at to (eller flere) brugere *ikke* opdaterer den samme record på samme
> tidspunkt. I Client/Server miljøet er det Serveren der udfører arbejdet,
og
> klienten skal så at sige "bare" vente på et svar.
>
> Samme system gør sig gældende ved en filserver, det behøver også bare være
> en UNIX maskine uden et GUI, men med en skovlfuld GB (eller TB harddisk
> kapacitet), og derudover have en proces der tager sig backup, og en proces
> der tager sig af alm. disk vedligeholdelse, evt. en proces der tager sig
af
> virusdetektering, klienten loader så fra denne maskine og gemmer igen på
> samme maskine.
>
> Eller som det er skrevet, på Internettet er det en WebServer der modtager
en
> forespørgsel og sender siden afsted til Browseren (klienten) på
> modtagermaskinen.
>
> Lidt mere komplekst (Perl og PHP) forespørger klienten et script, serveren
> beder en anden proces interpreteren om at oversætte til noget den forstår,
> evt. beder interpreteren databasen om at hente og bearbejde nogle data,
som
> sendes retur til interpreteren, der sender en fortolket udgave tilbage til
> WebServeren der serverer det hele for Klienten, klientens maskine gør
> *intet* andet end at sende en forespørgsel om scriptet, webserveren virker
> som middelware, databaseserveren ligger højst sandsynligt på en anden
> maskine på netværket.
>
> Så for at summere op :
>
> Er det en kombination af en front-end klient der virker mod brugeren
(oftest
> et GUI nu om dage), og en server der virker som back-end mod de delte
> resourcer (database, filer, printere, modem, scanner o.s.v.). Normalt er
> front-end og back-end konfigureret meget forskelligt, med hensyntagen til
> deres specifikke rolle i samspillet.Ofte er der tale om forskellige
> styresystemer, til forskellige opgaver. OG meget vigtigt når man opbygger
et
> Client/Server "system" vil det velgennemtænkte system kunne skaleres UDEN
> omkostning for systemet som sådan, altså med andre ord det skal være uden
> betydning for systemet om der kommer en, to eller tre nye workstations
> (klienter) på eller ej, og det skal uden at systemet lider voldsomt under
> det være muligt at opgraderer enkelte dele eller hele systemet (her tænkes
> specifikt på back-end, da det oftest vil være her behovet opstår).
>
> OG alt dette sagt, vi har end ikke berørt tree-tier/n-tier, distribuerede
> objekter. Vi har ikke berørt specifikker arkitekturer som IBM, Sun og
Apple
> m.fl. så der er nok at tage fat på
>
> Var lige henne og grave lidt i bogstakken, så her lige et par titler jeg
> selv har brugt :
>
> Patrick Smith
> Client/server computing
> Fra SAMS
>
> og
>
> David Linthicum
> David Linthicum's Guide to Client/Server and Intranet Development
> Fra Wiley
>
> Jeg håber jeg hjalp mere end jeg forvirrede, denne tekst er skrevet over
> mange timer, hvor jeg passede mit arbejde, min familie og en telefon
Så
> bær over med stavefejl og sig endelig til hvis det fremstår som totalt
> sludder (hvilket det nok gør sine steder
Ok, mange tak for den forklaring, så blev man igen lidt klogere :)
Mvh
HK