Je použit model architektury klient-server. Architektura klient-server

Klíčovým rozdílem mezi architekturou klient-server a architekturou souborového serveru je abstrakce od vnitřní reprezentace dat (fyzické datové schéma). Klientské programy nyní manipulují s daty na úrovni logického schématu.

Využití architektury klient-server tedy umožnilo vytvořit spolehlivý (z hlediska integrity dat) víceuživatelský IS s centralizovanou databází, nezávislý na hardwarové (a často i softwarové) části databázového serveru a podporující GUI uživatele (GUI) na klientských stanicích připojených lokální sítí. Navíc se výrazně snížily náklady na vývoj aplikací.

Klíčové vlastnosti:

Klientský program pracuje s daty prostřednictvím požadavků na serverový software.

Základní funkce aplikace jsou sdíleny mezi klientem a serverem.

Plná podpora více uživatelů

Záruka integrity dat

Obchodní logika aplikací zůstala v klientském softwaru. Při jakékoli změně v algoritmech je nutné aktualizovat uživatelský software na každém klientovi.

Vysoké požadavky na šířku pásma komunikační kanály se serverem, což zabraňuje použití klientských stanic s výjimkou lokální sítě.

Slabá ochrana dat před hackováním, zejména od bezohledných uživatelů systému.

Vysoká náročnost správy a konfigurace uživatelských pracovních stanic systému.

Potřeba používat výkonná PC na klientských místech.

Vysoká složitost vývoje systému vzhledem k nutnosti implementovat obchodní logiku a poskytovat uživatelské rozhraní v jednom programu.

Je snadné vidět, že většina nedostatků klasické nebo 2vrstvé architektury klient-server pramení z použití klientské stanice jako vykonavatele business logiky IS. Zřejmým krokem v dalším vývoji architektur IS byla proto myšlenka „tenkého klienta“, tedy rozdělení algoritmů zpracování dat do částí souvisejících s výkonem obchodních funkcí a souvisejících se zobrazováním informací v lidsky přívětivé reprezentaci. Na klientském stroji přitom zůstává pouze druhá část, související s prvotní kontrolou a zobrazením informací, přenášejících veškerou skutečnou funkčnost systému na serverovou část.

Přechodná na třívrstvou architekturu (2,5 vrstvy)

Použití uložených procedur a výpočet dat na straně serveru snižuje provoz a zvyšuje bezpečnost. Klient stále implementuje část obchodní logiky.

Jak vidíte, taková organizace systému velmi připomíná organizaci prvních unitárních systémů, jen s tím rozdílem, že uživatelským místem není terminál (s notoricky známou zelenou obrazovkou), ale Osobní počítač, která poskytuje GUI, například v posledních letech se jako klientské programy často používají standardní www prohlížeče. K takovému návratu k téměř unitárním systémům samozřejmě došlo již na jiné technologické úrovni. Používání DBMS se všemi jejich výhodami se stalo povinným. Programy pro serverovou část jsou psány převážně ve specializovaných jazycích s využitím mechanismu uložených procedur databázového serveru. Na úrovni logické organizace je tedy IS v architektuře klient-server s tenkým klientem rozdělen na tři vrstvy - datovou vrstvu, vrstvu obchodních funkcí (uložené procedury) a prezentační vrstvu. Bohužel obvykle v takovém schématu budování IS není možné napsat celou obchodní logiku aplikace ve vestavěných jazycích DBMS, které k tomu nejsou určeny. Velmi často je proto část obchodních funkcí implementována v klientské části systémů, která na tom nevyhnutelně „tloustne“. Částečně z tohoto důvodu a částečně proto, že se tyto IC fyzicky skládají ze dvou komponent, je tato architektura často označována jako 2,5vrstvá architektura klient-server.

Na rozdíl od 2vrstvé architektury 2,5vrstvá architektura obvykle nevyžaduje vysokorychlostní komunikační kanály mezi klientskou a serverovou částí systému, protože hotové výsledky výpočtů jsou přenášeny přes síť - téměř všechny výpočty se provádějí na straně serveru. Výrazně se také zlepšila ochrana informací – uživatelé dostávají práva na přístup k funkcím systému, nikoli na přístup k jeho datům atd. Spolu s výhodami unitárního přístupu však architektura 2.5 přijímá také všechny své nevýhody, jako je: omezená škálovatelnost, závislost na softwarová platforma, omezené využití síťových výpočetních zdrojů. Programy pro serverovou část systému jsou navíc psány v jazycích zabudovaných v DBMS pro popis uložených procedur určených k ověřování dat a vytváření jednoduchých sestav, a vůbec ne pro psaní celopodnikových IS. To vše snižuje rychlost systému, zvyšuje složitost tvorby a úprav IS a tím nejnegativnějším způsobem ovlivňuje náklady na hardware nezbytný pro jeho provoz.

vývoj iOS,

Vývoj mobilních aplikací

Okamžitě udělám rezervaci, že jsem mobilní vývojář a článek je určen hlavně vývojářům na druhé straně cloudu – mobilní lidé už o tom všem vědí. Poslední webová aplikace, kterou jsem napsal, byla před mnoha lety a možná se mýlím ve webové terminologii, neznám některé z nejnovějších trendů ve webových službách .NET, PHP nebo Java, takže nesuďte příliš přísně.

Jako každý front-end vývojář se téměř v každém projektu musím vypořádat s protokoly klient-server – bez nich se neobejdu. A velmi, velmi často musíte pracovat se špatně promyšlenou architekturou.

Také vývoj protokolu a architektury velmi často padá na bedra webového vývojáře, což není vždy pravda – ve většině případů by měl být vyvíjen pouze ve spojení s těmi, kteří se této architektuře přizpůsobí. Bohužel při práci na několika desítkách projektů za poslední tři roky jsem se na plánování tohoto úseku architektury podílel pouze 3x nebo 4x - ve všech ostatních případech již byl v různé míře připraven ze strany zákazníka. O kolik lepší může být svět!

Chyba při zpracování

Nejčastěji jsem narazil na něco takového:

HTTP kód 200 (OK) Nepravdivé Uživatelské jméno nebo heslo je nesprávné. Prosím zkuste to znovu.
Tito. výsledek zpracování požadavku je obsažen v samotném XML, návratový kód HTTP je 200, tzn. normálně jsou data prezentována ve formě běžného RPC. Například podobným způsobem je v 90 % případů implementováno zpracování chyb v protokolu SOAP.

Ve zvláště opomíjených případech, zvláště typických pro hinduistický kód, se false může nacházet na různých místech v XML, což značně komplikuje parsování, vede k překomplikovaným a znuděného programátora to nesmírně potěší.

Podívejme se ale na nedostatky tohoto přístupu v zásadě.

Nejprve musíte analyzovat XML. Jedná se o další data přenášená po síti, extra čas CPU strávený analýzou XML, navíc RAM pro ukládání textových dat. To vše není na moderních zařízeních ve Wi-fi zóně tak děsivé, ale i takové excesy mohou v metru mezi stanicemi udělat rozdíl v aplikaci, která odesílá desítky požadavků současně (a s tímto přístupem by v každém požadavku, i úspěšném, měly být prázdné bloky pro zpracování chyb).
Za druhé, webový vývojář musí sám vymýšlet chybové texty. Velmi často jsou pro uživatele zcela nesrozumitelné, protože přesnost formulace je to poslední, na co webový vývojář při psaní služby myslí. Text chyby v 90 % případů nesouhlasí s rodilými mluvčími a v neposlední řadě obrovské množství mobilních aplikací potřebuje lokalizaci. Zatímco text chyby je s největší pravděpodobností vždy napsán pouze v angličtině, pro front-endového programátora je tedy naprosto k ničemu - nemůže jej jen tak vzít a vytisknout.

Čas potřebný k tomu, aby webový programátor vymyslel text zprávy, je však promarněný a dokonce i kanál je zahlcen zbytečnými informacemi.

Jak vyřešit problém?

V HTTP protokol po mnoho let je možné přidávat vlastní chybové kódy, proto musí patřit do rozsahu od 512 do 597. Jsem si jistý, že tento počet chyb bude stačit na pokrytí všech možné chyby ve středně velké aplikaci. Je zřejmé, jaké výhody to přináší, ale přesto si to shrňme:

Neexistuje žádná redundance. Předává se pouze HTTP kód v hlavičce, prostě neexistuje tělo požadavku.
Na straně klienta existují pouze dvě větve kódu zpracování požadavku - úspěšné provedení nebo chyba při provádění (obě zpětná volání jsou již implementována z krabice v libovolné knihovně požadavků). Neexistují žádné větve „požadavek úspěšně dokončen, ale v těle odpovědi může být logická chyba“.

5xx Chyba serveru
Serveru se nepodařilo splnit zjevně platný požadavek.
Stavové kódy odezvy začínající číslicí "5" označují případy, kdy si server je vědom toho, že narazil na chybu nebo je jinak neschopný provést požadavek. S výjimkou odpovědi na požadavek HEAD by server měl obsahovat entitu obsahující vysvětlení chybové situace a uvést, zda se jedná o dočasný nebo trvalý stav. Podobně by měli uživatelští agenti zobrazit uživateli jakoukoli zahrnutou entitu. Tyto kódy odezvy jsou použitelné pro jakoukoli metodu požadavku.

Tito. klienti by měli uživateli ukázat zprávu odeslanou serverem. Hned je jasné, co Američané napsali. Rusové mimochodem hloupě přeložili.

I když nebudeme paušalizovat – myšlenku používat HTTP kódy mi před pár lety navrhl jeden Američan.

Obecně je ideologie taková - klient vždy lépe ví, jak nahlásit chybu. A server musí informovat klienta o chybě nejrychlejším a nejhospodárnějším způsobem.

Vazba na relaci nebo soubor cookie.

K takové vazbě nejspíše dojde, pokud byl web nejprve vytvořen a teprve poté se zákazník rozhodl vytvořit mobilní frontend. Přestože je možné pracovat s proměnnými relace z mobilní strany, není to dobrá praxe, protože často neexistuje žádná běžná sada nástrojů pro práci s těmito nástroji.

Druhou, globální nevýhodou je, že Safari (nebo jakýkoli prohlížeč na Androidu) nesdílí s aplikací své cookies a proměnné relace, což je samozřejmě z hlediska bezpečnosti správné, ale vede to k řadě problémů a berliček.

Řekněme, že vaše mobilní aplikace implementuje pouze 70 % funkcí webu. Zbývajících 30 % funkcí je dostupných pouze na webu a vaše aplikace obsahuje pouze odkazy na příslušné webové stránky.

Je také možné, že tyto stránky jsou dostupné pouze oprávněným uživatelům. Výsledkem je, že uživatel, který je již přihlášen mobilního klienta, budete vyzváni k opětovnému přihlášení - nyní v nepohodlném webovém formuláři a bude štěstí, pokud bude uživatel po přihlášení přesměrován na požadovanou sekci webu.

Závěr – pokud navrhujete obecný protokol, zapomeňte na věci jako proměnné relace a soubory cookie. Mnohem lepší způsob by bylo předat nějaký jedinečný token získaný během autorizace explicitně v těle každého požadavku. A webové stránky a webové aplikace – přizpůsobit se použití jediného API. Jsem si jistý, že všichni mobilní vývojáři často viděli dvě verze API – jednu pro webové aplikace, druhou pro mobily. Ale to je duplikace funkčnosti, která je vždy dražší jak ve fázi vývoje, tak ve fázi ladění. Vždy je lepší oddělit webové služby od samého začátku do samostatné vrstvy systému, než je vkládat do jiných částí blízkých webovým technologiím.

HTML návrat

To má kořeny již v designu samotných webových serverů, které byly původně určeny pouze pro prohlížeč. Chyby 403, 404 a někdy i složitější jsou velmi často vráceny jako HTML stránka, která často jednoduše nemá prostředky k zobrazení mobilní aplikace. Přesněji řečeno, existují fondy, ale když uvidíte stránku „404 nenalezeno“ s mohutným černým Arial Black na bílém pozadí uvnitř webového zobrazení se mobilní uživatel zblázní a zavře aplikaci.

Pamatujte, že server musí vrátit XML (nebo JSON) pro jakýkoli požadavek na webové služby a pouze ve formátu, který byl původně dohodnut. Mobilní vývojář nemůže s HTML, které pochází ze serveru, udělat nic, co by stálo za to.

Použijte WSDL

Na technologiích společnosti Microsoft je situace stále nic - většina z nich moderní technologie podporuje WSDL ihned po vybalení. To samé se o PHP a Javě říci nedá – zejména PHP vývojáři mají velmi rádi ruční vytváření obyčejných stránek, které jsou v podstatě webovými službami. K integraci s webovou službou kompatibilní s WSDL však stačí, aby mobilní vývojář použil nástroj pro generování kódu, zatímco ručně zkompilované odpovědi webové služby musí také analyzovat ručně.

Pravda, i zde jsou drobnosti – standardní implementace WSDL od společností MS a Sun (Oracle) stále mají nekompatibilitu, ale stále je rychlejší tyto nekompatibility opravit souborem, než vše zapisovat ručně.

Závěr

Dotkl jsem se pouze těch nejbolestivějších designových chyb, se kterými se musí mobilní vývojáři každý den potýkat. Pokud bude článek žádaný, určitě napíšu o desítce dalších klient-server jemností, které bych velmi rád viděl v API webových služeb, se kterými každý den pracujete.

Architektura klient-server(architektura klient-server) je koncept informační síť, ve které je převážná část jejích zdrojů soustředěna na servery obsluhující jejich zákazníky. Dotyčná architektura definuje dva typy komponent: servery a klienty.

Server - je objekt, který poskytuje servis jiné síťové objekty na jejich žádost. Servis je proces zákaznického servisu.

Obrázek Architektura klient-server

Server pracuje na pokyn klientů a řídí provádění jejich úkolů. Po provedení každé úlohy server odešle výsledky klientovi, který úlohu odeslal.

Obslužná funkce v architektuře klient-server je popsána sadou aplikačních programů, podle kterých se provádějí různé aplikační procesy.

Proces, který volá servisní funkce prostřednictvím určitých operací se nazývá klienta. Může to být program nebo uživatel. klienti jsou pracovní stanice, které využívají serverové prostředky a poskytují pohodlné uživatelská rozhraní. Uživatelská rozhraní Toto jsou postupy pro interakci uživatele se systémem nebo sítí.

Obrázek Model klient-server

Klient je iniciátorem a používá e-mailem nebo jiné služby serveru. V tomto procesu klient požaduje službu, naváže relaci, získá požadované výsledky a ohlásí, když je hotovo.

V sítě s vyhrazeným souborovým serverem na vyhrazeném samostatném PC je nainstalován síťový serverový operační systém. Tento PC se stává server. Software ( PODLE), nainstalováno na pracovní stanice, umožňuje komunikaci se serverem. Nejběžnější síťové operační systémy jsou:

K využití výhod sítě jsou kromě síťového operačního systému potřeba síťové aplikace.

Serverové sítě mají nejlepší výkon a zvýšenou spolehlivostí. Server vlastní hlavní síťové zdroje, do používané jinými pracovními stanicemi.

V moderní architektuře klient-server se rozlišují čtyři skupiny objektů: klienti, servery, data a síťové služby. Klienti jsou umístěni v systémech na uživatelských pracovních stanicích. Data jsou většinou uložena na serverech. Síťové služby jsou sdílené servery a data. Služby navíc řídí postupy zpracování dat.

Sítě s architekturou klient-server mají následující výhody:

Umožňuje práci v síti velké množství pracovní stanice;

Poskytujte centralizovanou správu uživatelských účtů, zabezpečení a přístupu, která zjednodušuje správu sítě;

Efektivní přístup k síťovým zdrojům;

Uživatel potřebuje jedno heslo pro přihlášení do sítě a pro získání přístupu ke všem zdrojům, které podléhají uživatelským právům.

Kromě výhod sítě mají architektury klient-server také řadu nevýhod:

Selhání serveru může způsobit, že síť bude nepoužitelná, přinejmenším ztráta síťových zdrojů;

Vyžadovat kvalifikovaný personál pro administraci;

Mají vyšší náklady na síť a síťová zařízení.

systémy "klient-server". Část 2

Architektura klient-server: definice, předpoklady pro aplikaci, klady a zápory

Co je architektura klient-server? Možnosti tvorby aplikací

Pojďme si tedy konečně promluvit

co je vlastně klient-server? . Přísně vzato by se mělo rozlišovat mezi technologií klient-server v širokém smyslu, kterou lze použít v jakékoli počítačové systémy od skutečné architektury klient-server ve vztahu k informačním aplikacím obecně a automatizovaným systémům řízení podniku zvláště.

Podle online slovníku počítačové termíny, klient-server je druh distribuovaný systém, ve kterém je server, který provádí požadavky klientů, a server a klient spolu komunikují pomocí jednoho nebo druhého protokolu.

Klient je program, který využívá prostředky, a server (v angličtině - sluha) je program, který obsluhuje požadavky klientů na zdroje určitého typu. Taková široká definice zahrnuje téměř jakoukoli softwarovou technologii, která zahrnuje více než jeden program, funkce mezi nimiž jsou distribuovány asymetricky. V souladu s tím hovoří o CS technologii ve vztahu k operační systémy, místní a globální sítě atd.

Tato široká definice vytváří určitý zmatek. Systém souborového serveru tedy také využívá technologii klient-server, ale z hlediska architektury aplikačního programu je důležité, jaké zdroje server klientům poskytuje.

Koncept architektury klient-server v systémech podnikového řízení je spojen s rozdělením libovolného aplikačního programu do tří hlavních komponent nebo vrstev. Tyto tři složky jsou

komponenta prezentace (vizualizace) dat;

aplikovaná logická složka;

komponent pro správu databáze.

Ve skutečnosti jakýkoli program, který počítačově provádí provádění jednoho nebo druhého aplikovaný úkol, by si měl vyměňovat informace s uživatelem, provádět vlastní zpracování těchto informací v rámci automatizace konkrétního obchodního procesu a nakonec ukládat data používaná v programu na jedno či druhé trvalé médium.

U lokálních aplikací, které běží výhradně na PC (jako je Word nebo Excel), jsou všechny tyto součásti spojeny dohromady a nelze je distribuovat mezi různé počítače. Takový program je monolitický a využívá pouze prostředky počítače, na kterém je spouštěn.

V aplikacích souborového serveru je část komponenty úložiště přenesena souborový server, ovšem veškeré manipulace s datovými strukturami se provádějí na klientském stroji a kód uživatelského programu také funguje pouze na něm.

Kritérium, které umožňuje klasifikovat aplikační program jako a architektura klient-server je, že alespoň jedna z jeho tří komponent je kompletně spuštěna na jiném počítači a interakce mezi komponentami je zapnutá různé počítače se provádí prostřednictvím určitého síťového média zasíláním požadavků na získání určitého zdroje.

Protože architektura klient-server je speciálním případem technologie klient-server, má nutně klienta a server. Podle toho se rozlišuje klientská a serverová strana aplikace. klientská strana Aplikace fungují na pracovišti uživatele, kterým je v naprosté většině případů osobní počítač. Strana serveru funguje na specializovaném komplexu, který zahrnuje výkonný hardware, požadovanou sadu standardního softwaru, systém správy databází a vlastní datové struktury.

Interakce mezi klientskou a serverovou částí aplikace se provádí prostřednictvím sítě – lokální nebo globální. Zároveň z pohledu klienta a serveru probíhá interakce transparentně, respektive síťová součást zde zahrnuje sadu nezbytných síťových zařízení, sadu softwarových technologií, které zajišťují přenos dat mezi uzly sítě a také vlastní protokol nebo protokoly pro výměnu požadavků a výsledky jejich provádění.

Vizualizační složka aplikované úlohy provádí uživatelský vstup pomocí různých prostředků, stejně jako zobrazování informací na obrazovce a tisk. Vizualizační komponenta pro architekturu klient-server se vždy spouští na pracovišti uživatele (protože ten musí sledovat případné výsledky programu).

Použitá logická komponenta řeší jeden nebo druhý úkol související se zpracováním dat v jednom nebo druhém předmětová oblast. Tato komponenta může být distribuována mezi klientskou a serverovou částí různými způsoby v závislosti na použitém modelu.

Komponenta úložiště databáze provádí fyzické operace spojené s ukládáním dat, čtením informací z databáze a zápisem do ní. V architektuře klient-server tato komponenta vždy běží na serveru.

Z hlediska množství základní části systémy klient-server se dělí na dvouvrstvé a třívrstvé

. Dvouúrovňové systémy se skládají pouze z klienta a serveru. V tříúrovňový mezi klientem uživatele a serverem, který ukládá a zpracovává databázi, se objeví třetí, mezivrstva, což je server pro uživatele a klient pro systém správy databází. Tato architektura umožňuje flexibilnější rozdělení systémových funkcí a zátěže mezi komponenty hardwarového a softwarového systému a může také snížit požadavky na zdroje pro uživatelské pracovní stanice. Nezbytnou cenou za to je, že takové systémy jsou mnohem obtížnější na vývoj, implementaci a provoz a vyžadují značné náklady a vysoce kvalifikovaný personál.

Ve třetí části je zvažován příklad třívrstvé struktury Server Bajkonur.

V architektuře klient-server existuje několik různých aplikační modely v závislosti na distribuci komponent aplikace mezi klientskou a serverovou částí. Historicky byl vyvinut úplně první model serveru pro vzdálený přístup k datům. V tomto modelu serverová část pouze ukládá data a klientská část implementuje veškerou aplikační logiku. V tomto případě klient odešle serveru požadavky na příjem dat a server vrátí určité vzorky klientovi. Nejběžnějším prostředkem komunikace mezi klientem a serverem je v tomto případě SQL ( strukturovaný jazyk dotazy) je standardní neprocedurální datově orientovaný jazyk.

V modelu serveru vzdáleného přístupu k datům se na straně serveru nespouští žádná aplikační část systému, což může vést k podtížení serveru a přetížení klienta. Proto byl následně navržen a následně realizován architektura databázového serveru. V něm je část aplikační logiky implementována na serveru pomocí speciálního programovacího jazyka a část - na klientovi. To bylo možné díky zvýšenému výkonu moderních serverů DBMS. Ve srovnání s možností serveru pro vzdálený přístup k datům, in tento případ trochu menší zátěž

na straně klienta je intenzita síťové výměny dat a v některých případech zjednodušena struktura aplikace. V současné době je tato možnost pro stavební systémy nejběžnější.

Další možností pro architekturu klient-server je aplikační server. V tomto případě klient provádí pouze operace vizualizace a zadávání dat a server implementuje veškerou aplikační logiku. Výměna mezi klientem a serverem v takových systémech probíhá na úrovni příkazů pro zobrazení dat na obrazovce a výsledků uživatelského vstupu. Nejvýraznějším příkladem této architektury je známá webový prohlížeč. Nejčastěji jsou v modelu aplikačního serveru aplikační logika a komponenty správy dat implementovány samostatně.

Architektura aplikačního serveru je často označována jako tzv „tenký“ klient, Na rozdíl od tradiční "tlustý" klient implementovaný v architektuře databázového serveru."Tenký" klient je možnost, kterou lze použít, když zdroje dostupné na pracovních stanicích uživatelů nestačí k provedení aplikační logiky. Tato technologie navíc umožňuje snížit náklady na provoz klientských komponent systému díky jejich výraznému zjednodušení.

Předpoklady pro vznik architektury klient-server v podniku

Elektronizace průmyslového podniku může v rámci dříve popsaných místních pracovních míst nebo architektury trvat dlouho. souborový server. Dříve nebo později však může přijít chvíle, kdy je jedinou možností pro další vývoj automatizované systémy řízení podniku se stanou architekturou klient-server. Zkusme vyjmenovat hlavní důvody pro které se to stává nezbytným.

Za prvé, architektura klient-server se stává životně důležitou, když počet uživatelů aktivně využívajících stejná data ve stejnou dobu přesáhne 10-15 lidí. Kvůli zásadním omezením, která jsou vlastní aplikacím souborového serveru, je 15 souběžných uživatelů takových systémů obtížné přenést a 20 uživatelů se často rozpadne. Stojí-li tedy podnik před úkolem vybudovat systém, ve kterém počet míst aktivně pracujících s daty současně přesáhne 20, je pro něj klient-server prakticky jedinou možností.

Pro spravedlnost je třeba poznamenat, že sálové počítače si také dokážou poradit s desítkami nebo dokonce stovkami uživatelů. Vzhledem k vysokým nákladům na hardware, vysokým nákladům na vývoj, a co je důležité, k nemalým nákladům na provoz takových zařízení a programů pro ně, se však o možnosti využití centralizované architektury při zavádění nových systémů u nás téměř vůbec neuvažuje.

Dalším kritickým momentem pro přechod na architekturu klient-server je přechod na celopodnikové řešení problémů a řízení podniku jako celku. Automatizaci jednotlivých pracovišť lze úspěšně provádět i bez použití síťových technologií, souborový server zvládne úkoly na úrovni oddělení, ale sestavení integrovaného automatizovaného systému pokrývajícího celý podnik nebo alespoň kterýkoli ze subsystémů správy je možné pouze pomocí technologií klient-server.

Další situací, kdy je klient-server jediným způsobem, jak vybudovat systém, je přítomnost v automatizovaném systému vzdálení uživatelé se kterými je nutné vyměňovat si informace v reálném čase. Skutečným časem zde máme na mysli sekundy-minuty. V tomto případě není výměna dat na disketách zásadně vhodná a architektura souborového serveru bude vyžadovat velmi vysoké rychlosti výměna, a to může být buď zásadně nemožné, nebo velmi drahé. Jednotlivé příklady bohatých organizací, které vybudovaly systémy souborových serverů v městském měřítku (například ruská „Inkombank“), jsou výjimky potvrzující pravidlo.

A konečně, když je potřeba architektura klient-server úkol zajistit integritu informací se stává kritickým. Kritickým zde rozumíme situaci, kdy náklady na datovou chybu mohou být srovnatelné s náklady na vytvoření systému klient-server. Především je to relevantní pro finanční služby podniků.

Pokus o řešení některého z výše uvedených problémů v rámci elektronizace průmyslového podniku nutně povede ke vzniku systému klient-server. Navíc se tato architektura může objevit v průběhu přirozeného vývoje automatizovaných systémů řízení výroby, i když omezení předchozích architektur v daném podniku ještě nejsou kritická. Tato možnost je nejvýhodnější, protože implementace na jedné straně dostává podporu zevnitř a na druhé straně je čas připravit se na hladkou změnu architektury informačních aplikací.

Architektura klient-server: Ano, ale...

O výhodách architektury klient-server jsme již hovořili. Může vyvstat přirozená otázka, pokud je to tak dobré, proč se na to ještě nepřešlo Všechno velkých uživatelů informační systémy. Ve skutečnosti není vše tak jednoduché.

Za prvé, pro domácí průmyslové podniky je to rozhodující nákladový faktor. Na rozdíl od západních podniků, kde jde zpravidla o výměnu poměrně drahých centralizovaných systémů za klient-server, jejichž přímé náklady jsou nižší, tuzemské podniky téměř nikdy neměly dostatek prostředků na implementaci velkých centralizovaných systémů. Informační systémy dostupné v podniku jsou velmi často postaveny na zastaralém hardwaru, který vyžaduje kompletní výměna při přechodu na architekturu klient-server.

Další velké "ale" je velké množství skutečných technologických změn které vznikají při pokusu o implementaci architektury klient-server. Systém klient-server vyžaduje odlišnou úroveň technické gramotnosti jak ze strany pracovníků informačních služeb, tak i ze strany pracovníků informačních služeb koneční uživatelé. Náklady na rekvalifikaci uživatelů a provozního personálu a restrukturalizaci automatizace závodu jsou spíše ledovcem než jasně viditelné přímé náklady na upgrade hardwaru, pořízení a/nebo vývoj požadovaného softwaru.

A nakonec ten největší past na cestě k vytvoření CS systému v podniku je potřeba změnit strukturu řízení a související organizační náklady

Pokus zavádět nová technologická řešení, aniž by se cokoli změnilo na podstatě automatizovaných obchodních procesů, může skončit marně. Podnik zároveň utrpí přímé materiální ztráty v důsledku velkého množství drahého hardwaru a softwaru, které leží mrtvou vahou, a také v důsledku odvádění pozornosti zaměstnanců od jejich hlavních povinností. V nejlepší případ bude představen samostatné sekce klient-server systém, i když ve skutečnosti nový software budou použity na staré ideologické úrovni.

Pokud se podnik po zvážení všech pro a proti rozhodl vytvořit systém klient-server, pak stojí před úkolem výběr komponentů vybudovat tento systém. Tak jako tak potřebná součást je jedno nebo druhé databázový server firemní úrovni. Zbývající komponenty závisí na cestě, kterou podnik zvolí pro další rozvoj automatizovaný systémřízení.

Pokud se společnost rozhodne vyvinout systém, pak stojí především před úkolem vybrat vývojové nástroje. Pokud firma umístí za účelem vytvoření systému od konkrétní developerské společnosti, pak před ním stojí podobný úkol.

V případě, že se rozhodneme nevyvíjet systém sami, ale použít některé z řešení dostupných na trhu, pak je hlavní složkou volby hotový (v té či oné míře) podnikový automatizační systém. Ve skutečnosti by se slovo „z regálu“ mělo používat s velkou opatrností, protože je obtížné stanovit jasnou hranici mezi přizpůsobením pro konkrétní použití a přizpůsobením systému, které často zahrnuje úpravu modulů systému nebo dokonce vývoj dodatečného softwaru podle potřeb zákazníka.

DB, na strukturální Jazyk SQL dotazy (Structured Query Language), což je průmyslový standard ve světě relačních databází. Vzdálený server přijme požadavek a přesměruje jej na databázový server SQL. SQL Server - speciální program Ten spravuje vzdálenou databázi. SQL server zajišťuje interpretaci dotazu, jeho provedení v databázi, vytvoření výsledku dotazu a jeho vystavení klientské aplikaci. V tomto případě se prostředky klientského počítače neúčastní fyzického provedení požadavku; klientský počítač pouze odešle požadavek do databáze serveru a obdrží výsledek, poté jej potřebným způsobem interpretuje a předloží uživateli. Protože je výsledek požadavku odeslán do klientské aplikace, po síti „putují“ pouze data, která klient potřebuje. V důsledku toho se sníží zatížení sítě. Protože se dotaz provádí na stejném místě, kde jsou data uložena (na serveru), není potřeba posílat velké datové pakety. Kromě toho SQL server, pokud je to možné, optimalizuje přijatý dotaz tak, aby byl proveden v minimálním čase s co nejmenší režií [ [ 3.2 ] , [ 3.3 ] ]. systém je znázorněn na Obr. 3.3.

To vše zvyšuje výkon systému a zkracuje dobu čekání na výsledek dotazu. Když jsou dotazy prováděny serverem, stupeň zabezpečení dat se výrazně zvyšuje, protože pravidla integrity dat jsou definována v databázi na serveru a jsou stejná pro všechny aplikace využívající tuto databázi. Tím je vyloučena možnost definování konfliktních pravidel pro zachování integrity. Výkonný transakční aparát podporovaný servery SQL umožňuje vyloučit současné změny stejných dat různými uživateli a poskytuje možnost vrátit se k původním hodnotám při provádění změn v databázi, které skončily v nouzi [ [ 3.2 ] , [ 3.3 ] ].

Rýže. 3.3. Architektura klient-server

Existuje místní síti, skládající se z klientských počítačů, z nichž každý má klientská aplikace pracovat s databází.
Na každém z klientských počítačů mají uživatelé možnost spouštět aplikaci. Pomocí uživatelského rozhraní poskytovaného aplikací zahájí volání do DBMS umístěného na serveru za účelem načtení/aktualizace informací. Používá se pro komunikaci speciální jazyk SQL dotazy, tzn. pouze text požadavku je přenášen přes síť z klienta na server.
DBMS iniciuje volání dat umístěných na serveru, v důsledku čehož veškeré zpracování dat probíhá na serveru a pouze výsledek dotazu je zkopírován do klientského počítače. DBMS tedy vrátí výsledek aplikaci.

Pojďme se podívat, jak vypadá oddělení funkcí mezi serverem a klientem.

Vlastnosti aplikačního klienta:
- Odesílání požadavků na server.
- Interpretace výsledků dotazů přijatých ze serveru.
- Prezentace výsledků uživateli v nějaké formě (uživatelské rozhraní).
Funkce serverové části:
- Příjem požadavků z klientských aplikací.
- Interpretace požadavků.
- Optimalizace a provádění dotazů do databáze.
- Odeslání výsledků do klientské aplikace.
- Zajištění bezpečnostního systému a kontroly vstupu.
- Správa integrity databáze.
- Implementace stability víceuživatelského režimu provozu.

Takzvané "průmyslové" DBMS pracují v architektuře "klient-server". Průmyslové se jim říká proto, že právě DBMS této třídy dokážou zajistit provoz informačních systémů měřítka středního a velkého podniku, organizace, banky. MS SQL Server , Oracle , Gupta , Informix , Sybase , DB2 , InterBase a řada dalších patří do kategorie průmyslových DBMS [ [ 3.2 ] ].

O správu SQL serveru se zpravidla stará jednotlivý zaměstnanec nebo skupina zaměstnanců (administrátoři SQL serveru). Spravují fyzikální vlastnosti databází, provádějí optimalizaci, ladění a redefinice různé součásti databáze, vytvářet nové databáze, upravovat stávající atd. a také udělovat oprávnění (oprávnění pro přístup určité úrovně ke konkrétní databázi, SQL serveru) různým uživatelům [ [ 3.2 ] ].

Zvažte hlavní výhody této architektury ve srovnání s architekturou "souborový server":

Výrazné snížení síťového provozu.
Snižuje se složitost klientských aplikací (většina zátěže připadá na serverovou část) a následně se snižují požadavky na hardwarové kapacity klientských počítačů.
Dostupnost speciálu softwarový nástroj- SQL-server - vede k tomu, že značná část návrhových a programovacích úloh již byla vyřešena.
Výrazně zlepšuje integritu a bezpečnost databáze.

Mezi nevýhody patří vyšší finanční náklady na hardware a software, a také to velký počet klientské počítače umístěné v různá místa, způsobuje určité potíže s včasnou aktualizací klientských aplikací na všech klientských počítačích. Architektura klient-server se však v praxi osvědčila, v současné době existuje a provozuje velké množství databází postavených v souladu s touto architekturou.

3.4. Třívrstvá (vícevrstvá) architektura „klient-server“.

Tři odkazy (v některých případech více odkazů) architektura(N-tier nebo více- třívrstvá architektura? Nyní, při změně obchodní logiky, již není potřeba měnit klientské aplikace a aktualizovat je pro všechny uživatele. Navíc jsou maximálně sníženy požadavky na uživatelské vybavení.

V důsledku toho je práce strukturována takto:

Databáze ve formě sady souborů je umístěna na pevném disku vyhrazeného počítače (síťový server).
DBMS je také umístěn na síťovém serveru.
Existuje vyhrazený aplikační server, který hostí software pro obchodní analýzu (obchodní logiku) [ [ 3.1 ] ].
Existuje mnoho klientských počítačů, z nichž každý má takzvaného „tenkého klienta“ – klientskou aplikaci, která implementuje uživatelské rozhraní.
Na každém z klientských počítačů mají uživatelé možnost spustit aplikaci – tenkého klienta. Pomocí uživatelského rozhraní poskytovaného aplikací zahájí volání softwaru business intelligence umístěného na aplikačním serveru.
Aplikační server analyzuje požadavky uživatele a generuje dotazy do databáze. Pro komunikaci se používá speciální dotazovací jazyk SQL, tzn. přes síť se z aplikačního serveru do databázového serveru přenáší pouze text požadavku.
DBMS v sobě zapouzdřuje veškeré informace o fyzické struktuře databáze umístěné na serveru.
DBMS iniciuje volání dat umístěných na serveru, v důsledku čehož je výsledek dotazu zkopírován na aplikační server.
Aplikační server vrátí výsledek klientské aplikaci (uživateli).
Aplikace pomocí uživatelského rozhraní zobrazí výsledek provádění dotazu.