Model klient/server
Potřeba sdílení souborů v prostředí vzájemně propojených osobních počítačů se postarala o velké rozšíření a velkou popularitu lokálních počítačových sítí. Časem vznikly velmi výkonné platformy pro file servery, které nabízely i možnost sdílení dalších periferií, zejména tiskáren. Pro mnohé aplikace a potřeby uživatelů i provozovatelů a správců sítí to stačilo. Postupně se ale objevovaly i takové požadavky, pro které nebylo provozování aplikací v režimu file server/pracovní stanice příliš vhodné. Díky nim se pak prosadil další výpočetní model, model klient/server.
Zkusme si nejprve naznačit, v čem spočívala ona „nepříliš velká vhodnost" modelu file server /pracovní stanice pro některé aplikace. Představme si jako příklad databázovou aplikaci, napsanou v některém běžném databázovém prostředí pro osobní počítače standardu IBM PC (například FoxPro, FoxBase, dBase apod.). Na konkrétním databázovém produktu přitom až tak nezáleží, důležité je naopak to, aby šlo o databázi vyvinutou především pro prostředí samostatných a vzájemně nepropojených osobních počítačů. Takovéto databáze se samozřejmě časem přizpůsobily existenci lokálních sítí a možnosti sdílení centrálně umístěných souborů (tj. umístěných na file serverech), dokázaly tuto možnost využít, ale jejich samotná podstata se již nezměnila: tato podstata spočívá v tom, že veškeré zpracování dat v databázi se provádí jediným programem, který běží přímo na počítači (pracovní stanici) uživatele. Rozdíl je vlastně jen v tom, kde jsou umístěna vlastní data tvořící „náplň" databáze: zda v souboru, který se nachází také na uživatelově počítači (a ten pak vůbec nemusí být zapojen do sítě), nebo v souboru umístěném centrálně na file serveru. Z pohledu samotné databázové aplikace přitom nemusí být rozdíl mezi oběma případy zase až tak patrný - díky snaze lokálních sítí učinit mechanismus sdílení souborů na file serveru co možná nejméně viditelný si tato aplikace může myslet, že zpracovává lokální soubory, přesněji data umístěna v lokálních souborech. V praxi ovšem musí databázová aplikace přeci jen brát do úvahy některé čistě technické aspekty - například to, že k obsahu sdíleného souboru může chtít přistupovat více zájemců současně, a musí být tudíž aplikovány vhodné strategie a mechanismy, řešící takovéto situace (např. formou uzamykání celých souborů nebo jejich částí).
Nyní si ale uvědomme, jak bude naše databázová aplikace skutečně fungovat: představme si, že má něco najít v datovém souboru velikosti kupř. 10 megabytů, který musí celý prohledat. K tomuto prohledání přitom musí dojít tam, kde samotná databázová aplikace běží, tj. na uživatelově počítači. Je-li ale datový soubor sdílený, tj. nachází-li se ve skutečnosti na centrálním file serveru, musí být nejprve přenesen po síti na uživatelův počítač. No a to představuje nemalou zátěž pro přenosové cesty, zajišťující propojení mezi file serverem a jednotlivými pracovními stanicemi. Zátěž takového rozměru, která dokáže velmi snadno přerůst možnosti a přenosové schopnosti dané sítě, a stát se výrazným úzkým místem, které téměř znemožní praktické využívání databázových aplikací výše popsaného typu - a obecně pak všech druhů aplikací, které zpracovávají velké objemy dat jinde, než se tato data nachází. Podstata problému je přitom právě v tom, že ke zpracování dochází na jiném místě, než kde jsou data skutečně uložena, a v důsledku toho jsou nutné obrovské přenosy dat po síti. Přenosy, které již na první pohled musí vzbuzovat pochybnosti o své opodstatněnosti - proč někam přenášet celý desetimegabytový soubor, když nás z něj zajímá například jen jeden jediný byte?
Myšlenka rozdělit zpracování
Výpočetní model klient/server je založen na myšlence, že data by se měla zpracovávat především tam, kde jsou k dispozici. Nejsou-li k dispozici místně, tj. přímo u uživatele, ale jsou umístěna centrálně, pak nechť se také zpracovávají na onom centrálním místě, kde se skutečně nachází. Jestliže ale s těmito daty chce pracovat uživatel ze své pracovní stanice, a chce tedy být v přímém kontaktu s aplikací, která mu tato data zpřístupňuje a zpracovává, pak je nevyhnutná jistá dělba práce - původně jednolitá aplikace se musí rozdělit na dvě části. Jedna z nich, zajišťující vlastní zpracovávání dat, se přestěhuje na místo výskytu dat, zatímco druhá část zůstane u uživatele a bude zajišťovat kontakt s ním. Pokud se „řez" původní jediné aplikace na dvě části provede rozumně a šikovně, je možné dosáhnout toho, že objem přenášených dat mezi oběma částmi bude velmi malý, až prakticky zanedbatelný. Vrátíme-li se zpět k příkladu desetimegabytového souboru, ze kterého nás zajímá jen jediný byte, nyní již lze věci zařídit mnohem efektivněji: část aplikace, běžící přímo u uživatele, zformuluje na jeho popud konkrétní dotaz, který odešle druhé části aplikace. Ta jej přijme a zodpoví, tj. provede požadované zpracování dat (ze svého pohledu místních), a výsledek - námi požadovaný byte - odešle zpět směrem k uživateli. Dovedeno ad absurdum, nyní po síti místo celého desetimegabytového soboru cestuje pouze jediný byte!
V praxi se samozřejmě přenáší po síti přeci jen o něco více dat, protože obě části aplikace se musí nějak dorozumívat a dávat si najevo, co vlastně po sobě chtějí a co si posílají. Nicméně pořád půjde o velmi malé objemy dat, a jejich konkrétní velikost je navíc plně v moci tvůrců příslušné aplikace, rozdělené do dvou částí.
Server a jeho klient
Myšlenka rozdělit jednu aplikaci na dvě části může přinášet i další výhody, než jen pouhou minimalizaci objemu přenášených dat. Jednou z velkých výhod vhodné „dělby práce" může být i to, že centrálně umístěná část aplikace může existovat v jediném exempláři, ale přitom může spolupracovat s více „uživatelskými" částmi více či méně najednou.