Client-server IS-architectuur op twee niveaus

Belangrijk verschil Client-serverarchitectuur van bestandsserverarchitectuur is een abstractie van de interne representatie van gegevens (fysiek gegevensschema). Met deze architectuur manipuleren clientprogramma's gegevens op niveau logisch circuit. Om de client-server-architectuur te implementeren, worden meestal DBMS'en voor meerdere gebruikers gebruikt, bijvoorbeeld Oracle of Microsoft SQL Server.

Client-server informatiesysteem bestaat uit drie hoofdcomponenten: software servers; software eindgebruiker; middleware (Fig. 1.7). De serversoftware biedt naast databasebeheer ook klantenservice.

Dergelijke DBMS'en bieden vergrendelingsmechanismen en toegangscontroles voor meerdere gebruikers die gegevens beschermen tegen de risico's die inherent zijn aan gelijktijdige toegang. Bovendien moet de databaseserver gegevens beschermen tegen ongeautoriseerde toegang, databasequery's optimaliseren, de gegevensintegriteit waarborgen en de voltooiing van transacties controleren. IN client-server organisatie Clients kunnen dun genoeg zijn, maar de server moet dik genoeg zijn om aan de behoeften van alle clients te voldoen. Eindgebruikerssoftware omvat onder meer applicatieontwikkelingstools en rapportgeneratoren spreadsheets En tekstverwerkers Met behulp van deze software brengen gebruikers een verbinding tot stand met de server, formuleren ze queries die automatisch worden gegenereerd in SQL-query's en naar de server worden verzonden. De server accepteert en verwerkt verzoeken en verzendt de resultaten vervolgens naar clients. Middleware is het deel van het client-serversysteem dat de eindgebruikerssoftware met de server verbindt.

Het gebruik van de client-server-architectuur maakte het mogelijk om betrouwbare (in termen van data-integriteit) informatiesystemen voor meerdere gebruikers te creëren met een gecentraliseerde database, onafhankelijk van de hardware (en vaak software) van de databaseserver en ondersteunende GUI gebruiker op aangesloten clientstations lokaal netwerk. Bovendien werden de ontwikkelingskosten van applicaties aanzienlijk verlaagd.

Deze architectuur heeft twee niveaus, karakteristieke eigenschap dat is dat clientprogramma's met gegevens werken via verzoeken aan serversoftware, en basisfuncties applicaties zijn verdeeld tussen client en server (Fig. 1.8).

De voordelen van deze architectuur zijn onder meer:

· volledige ondersteuning werk voor meerdere gebruikers;

· het waarborgen van de gegevensintegriteit.

Het is raadzaam om een ​​tweelaagse architectuur te gebruiken in ondernemingen met enkele tientallen gebruikers, aangezien het serverbesturingssysteem tijdens onderhoud wordt gebruikt grote hoeveelheid Clients zijn overbelast met het beheren van meerdere verbindingen met de server.

De nadelen van een tweelaagse client-serverarchitectuur zijn:

· De bedrijfslogica van de applicaties bleef in de clientsoftware. Bij elke wijziging in algoritmen is het noodzakelijk om de gebruikerssoftware op elke client bij te werken.

· Hoge eisen voor bandbreedte communicatie kanalen met de server, waardoor het gebruik van andere clientstations dan op het lokale netwerk wordt voorkomen.

· Zwakke gegevensbescherming tegen hacking, vooral tegen gewetenloze systeemgebruikers.

· Hoge complexiteit van het beheer en de configuratie van werkstations van systeemgebruikers.

· De noodzaak om krachtige pc's te gebruiken op locaties van klanten.

· Hoge complexiteit van systeemontwikkeling vanwege de noodzaak om bedrijfslogica te implementeren en te bieden gebruikersinterface in één programma.

Client-server-technologie wordt beschouwd als een van de ‘walvissen’ moderne wereld computernetwerken. Maar de problemen waarvoor het is ontwikkeld behoren tot het verleden. Nieuwe taken en technologieën vereisen een heroverweging van de principes van client-server-systemen. Een van deze technologieën Wereld Breed web. Webtechnologie is een ontwikkeling van de client-server-architectuur, d.w.z. Met één client kunt u verbinding maken met veel servers. Een informatiesysteem moet, naast de interface, niveaus van gegevensverwerking en -opslag hebben. Het probleem van internetontwikkelaars is coördinatie Webwerk met andere elementen van het systeem, zoals databases. Een van de veelbelovende manieren om dit probleem op te lossen zijn client-serversystemen met meerdere niveaus.

Klassiek systeem client-server werkt volgens het request-response-schema (architectuur op twee niveaus). De client voert een actieve functie uit (verzoeken), de server reageert er passief op.

Elk informatiesysteem moet ten minste drie functionele delen hebben: modules voor gegevensopslag, gegevensverwerking en gebruikersinterface.

Elk van deze onderdelen kan onafhankelijk van de andere twee worden geïmplementeerd.

Bijvoorbeeld . Zonder de programma's te wijzigen die worden gebruikt om gegevens op te slaan en te verwerken, kunt u de gebruikersinterface wijzigen zodat dezelfde gegevens worden weergegeven in de vorm van tabellen, grafieken of histogrammen. Zonder de gegevenspresentatie- en opslagprogramma's te wijzigen, kunt u de verwerkingsprogramma's wijzigen door het algoritme te wijzigen zoeken in volledige tekst. Zonder de gegevenspresentatie- en verwerkingsprogramma's te wijzigen, kunt u de gegevensopslagsoftware wijzigen door naar een ander bestandssysteem over te schakelen.

In een klassieke client-serverarchitectuur zijn de drie hoofdonderdelen van een applicatie verdeeld over twee fysieke modules. Normaal gesproken bevindt software voor gegevensopslag zich op de server (/: databaseserver), de gebruikersinterface bevindt zich aan de clientzijde, maar de gegevensverwerking moet worden verdeeld tussen de client en serveronderdelen. Dit is het belangrijkste nadeel van deze architectuur. Het partitioneren van algoritmen voor gegevensverwerking vereist het synchroniseren van de acties van beide delen van het systeem. Om inconsistentie te voorkomen verschillende elementen architecturen proberen gegevensverwerking op een van de twee delen uit te voeren: aan de clientzijde (thick client) of op de server (thin client of 2,5-tier client-server). Elke aanpak heeft zijn nadelen: in het eerste geval het netwerk is onterecht overbelast, omdat er worden ruwe (redundante) gegevens doorheen verzonden, ondersteuning en aanpassing van het systeem wordt ingewikkelder, omdat het vervangen van een rekenalgoritme of het corrigeren van een fout gelijktijdige volledige vervanging alle interfaceprogramma's, anders zal er inconsistentie in de gegevens optreden; in het tweede geval Wanneer alle informatieverwerking op de server wordt uitgevoerd, ontstaat het probleem van het beschrijven van ingebouwde procedures en het debuggen ervan (de beschrijving is declaratief en staat niet toe stap voor stap debuggen). Bovendien is een systeem met informatieverwerking op een server absoluut niet over te zetten naar een ander platform.

Meerderheid moderne middelen rapid application development (RAD), die met verschillende databases werkt, implementeert het eerste model ("thick" client), dat een interface biedt met de databaseserver via de SQL-taal. Deze optie heeft, naast de hierboven genoemde nadelen laag niveau beveiliging.

Bijvoorbeeld. IN banksystemen alle operators hebben schrijfrechten voor de hoofdtabel boekhoudsysteem. Daarnaast, dit systeem Het is bijna onmogelijk om over te stappen op webtechnologieën, omdat gespecialiseerde clientsoftware wordt gebruikt om toegang te krijgen tot de databaseserver.

Nadelen van de hierboven besproken modellen:

1. "Dikke" klant

F complexiteit van de administratie;

F problemen bij het updaten van software, omdat de vervanging ervan moet gelijktijdig door het hele systeem worden uitgevoerd;

F complexiteit bij de verdeling van bevoegdheden, aangezien de toegang niet wordt beperkt door acties, maar door tabellen;

F netwerkcongestie als gevolg van de overdracht van onverwerkte gegevens;

F zwakke gegevensbescherming.

2. "Vette" server

ð de implementatie wordt ingewikkelder, omdat de PL/SQL-talen niet geschikt zijn voor het ontwikkelen van dergelijke software en er geen debugging-tools zijn;

ð de prestaties van programma’s in PL/SQL-talen zijn lager dan in andere talen, wat belangrijk is complexe systemen;

ð programma’s geschreven in DBMS-talen werken niet betrouwbaar, wat kan leiden tot uitval van de gehele databaseserver;

ð programma's die op deze manier zijn gemaakt, zijn volledig niet overdraagbaar naar andere systemen en platforms.

Om deze problemen op te lossen, worden client-servermodellen met meerdere niveaus (drie of meer) gebruikt.

Multi-tier client-server-architecturen - distribueer op intelligentere wijze gegevensverwerkingsmodules die op een of meer afzonderlijke servers draaien.

Deze softwaremodules functies uitvoeren servers voor interfaces met gebruikers en cliënt- voor databaseservers. Bovendien kunnen verschillende applicatieservers met elkaar communiceren om het systeem nauwkeuriger te verdelen in functionele eenheden die specifieke rollen vervullen.

Bijvoorbeeld. U kunt een personeelsbeheerserver selecteren die alle functies uitvoert die nodig zijn voor personeelsbeheer. Door er een aparte database aan te koppelen, kunt u alle implementatiedetails van deze server voor gebruikers verbergen, waardoor u alleen toegang krijgt tot de openbaar toegankelijke functies. Een dergelijk systeem is gemakkelijker aan te passen aan het internet, omdat Het is gemakkelijker om HTML-formulieren te ontwikkelen voor gebruikerstoegang tot bepaalde databasefuncties dan tot alle gegevens.

In het drielagenmodel wordt de thin client niet overbelast met gegevensverwerkingsfuncties, maar speelt hij de hoofdrol van een systeem voor het presenteren van informatie afkomstig van de applicatieserver. (Deze interface is geïmplementeerd met behulp van standaard middelen Webtechnologieën - browser, CGI en Java). Hierdoor wordt de hoeveelheid gegevens die tussen de client en de applicatieserver wordt overgedragen verminderd, waardoor clients met langzame telefoonlijnen verbinding kunnen maken.

Met het client-servermodel op drie niveaus kunt u gebruikersrechten nauwkeuriger toewijzen, omdat zij geen rechten krijgen op de database zelf, maar op bepaalde functies van de applicatieserver, wat de veiligheid van het systeem vergroot.

Meerdere niveaus client-server systemen kan eenvoudig worden overgedragen naar webtechnologie - om dit te doen, hoeft u alleen maar te vervangen cliënt deel een universele browser, en vul de applicatieserver aan met een webserver en kleine serverprocedureaanroepprogramma's. In een systeem met drie niveaus wordt veel informatie verzonden via het communicatiekanaal tussen de applicatieserver en de database, maar de berekeningen vertragen niet omdat de communicatie gespecificeerde elementen Er worden snellere lijnen gebruikt. Dit vereist lagere kosten omdat beide servers zich in hetzelfde pand bevinden. Maar tegelijkertijd ontstaat het probleem van de consistentie van gezamenlijke berekeningen, dat transactiemanagers – nieuwe elementen van systemen met meerdere niveaus – moeten oplossen.

Transactiemanagers

MT- toestaan ​​dat één applicatieserver gelijktijdig communiceert met meerdere databaseservers. Hoewel Oracle-servers hebben een mechanisme voor het uitvoeren van gedistribueerde transacties, maar als de gebruiker een deel van de informatie opslaat in de Oracle-database, een deel in de Informix-database en een deel in tekstbestanden, dan kun je niet zonder MT. MT wordt gebruikt om gedistribueerde heterogene operaties te beheren en acties te coördineren diverse componenten informatiesysteem. Elke complexe software vereist het gebruik van MT.

Bijvoorbeeld. Banksystemen moeten verschillende transformaties van documentrepresentaties implementeren, d.w.z. werken gelijktijdig met gegevens die zowel in de database als in de database zijn opgeslagen reguliere bestanden,- dit zijn de functies die MT helpt vervullen.

MT is een programma of een reeks programma's die kunnen worden gebruikt om de werking van verschillende componenten van een informatiesysteem te coördineren.

Logischerwijs is MT verdeeld in verschillende delen:

· communicatiemanager (controleert de uitwisseling van berichten tussen componenten van het informatiesysteem;

· transactiemanager (beheert gedistribueerde operaties);

· logmanager (bewaakt het herstel en terugdraaien van gedistribueerde bewerkingen);

· sluismanager (biedt juiste toegang naar gedeelde gegevens).

Typisch wordt M-communicatie gecombineerd met M-autorisatie, en M-transacties worden gecombineerd met M-locking en systeemrecords. Bovendien wordt zo'n M zelden opgenomen in het leveringspakket, omdat de functies ervan (het bijhouden van gegevens, het distribueren van bronnen en het controleren van bewerkingen) meestal worden uitgevoerd door de database zelf (bijvoorbeeld Oracle).

Grootste veranderingen vond plaats in M-communicatie, toen nieuwe objectgeoriënteerde technologieën (CORBA, DCOM, enz.) op dit gebied verschenen. Model met meerdere niveaus Met client-server kunt u gedistribueerd computergebruik aanzienlijk vereenvoudigen, waardoor het niet alleen betrouwbaarder, maar ook toegankelijker wordt.

4.4. Systemen technologische post ­ -

het is een gegarandeerde informatievoorziening en een middel voor applicatie-integratie

Het ontwerp van informatiesystemen confronteert systeemanalisten met beslissingen volgende problemen:

ð gedistribueerd systeem;

ð integratie diverse toepassingen;

ð administratiegemak.

Moderne computers zijn meestal gedistribueerd, dus het probleem doet zich voor bij het kiezen van een methode voor interactie tussen de afzonderlijke delen van dergelijke systemen. De fusie van verschillende informatiesystemen vereist de oplossing van het integreren van een groot aantal heterogene applicaties. Een dergelijk (geïntegreerd) systeem moet alle functionaliteit van de gecombineerde subsystemen hebben en eenvoud en gebruiksgemak behouden. Dit probleem kan worden opgelost met behulp van technologische postsystemen(STP).

De term “technologische post” wordt gebruikt om de interactie tussen applicaties aan te duiden (“elektronische post” is de interactie tussen mensen), de overgedragen informatie is technologisch; de vorming en verzending ervan kan worden uitgevoerd zonder/of met minimale menselijke deelname.

Het technologische postsysteem omvat er twee verschillende manieren interacties die worden gebruikt in moderne gedistribueerde systemen.

Een daarvan is gebaseerd op het concept van verbinding (Fig. 1), en de andere is gebaseerd op het idee van berichtenuitwisseling.

1

Afb.1. Verbindingsgericht interactiemechanisme

Het proces van interactie tussen applicaties en het gebruik van verbindingsopbouw kan in drie fasen worden verdeeld:

1. tot stand brengen van de verbinding;

2. overdracht van informatie;

3. het sluiten van de verbinding.

Een dergelijke interactie vereist de aanwezigheid van een verbinding tussen alle drie de fasen gelijktijdig werken toepassingen, wat niet altijd mogelijk is.

Systemen die zijn gebouwd op het principe van berichtenuitwisseling, maken tijdens interactie gebruik van berichtenwachtrijtechnologie (Fig. 2).

Afb.2. Applicatiecommunicatie met behulp van message queuing-technologie

Applicaties die informatie uitwisselen, adresseren deze niet rechtstreeks aan elkaar, maar aan de berichtenwachtrijen die bij de applicaties horen. De verbinding tussen de applicatie en de wachtrij vindt in de regel plaats in de onlinemodus, waardoor de tijd die besteed wordt aan het tot stand brengen van de verbinding wordt vermeden. De besturingssoftware kan zich op dezelfde machine bevinden als de applicaties of op een speciale server. Systemen die gebruik maken van message queuing-technologie vereisen, in tegenstelling tot systemen voor het tot stand brengen van verbindingen, geen permanente verbinding tijdens het interactieproces of de gelijktijdige werking van op elkaar inwerkende applicaties. Deze eigenschappen maken ze flexibel en geschikt voor uiteenlopende toepassingen.

De veelzijdigheid van technologische postsystemen stelt hen in staat om aan te werken heterogeen (verscheidenheid aan software- en hardwareplatforms waarop ze werken individuele componenten STP, evenals een verscheidenheid aan verbindingsmethoden en interactieprotocollen die in systeemstructuren worden gebruikt. Heterogeniteit wordt bereikt door de server- en clientdelen van het STP te scheiden. De clientonderdelen hebben weinig functionaliteit en kunnen worden verplaatst verschillende platforms. Voor de exploitatie van de RWZI zijn dus geen kosten verbonden extra uitrusting- het systeem past zich aan bestaande middelen(zowel hardware als software, en op bestaande datatransmissiekanalen) en hoeft niet te worden vervangen.

Voordelen van het gebruik van STP:

Ø Gegarandeerde bezorging van berichten. Message Queuing-servers

bepalen hoe de levering kan worden gegarandeerd in geval van een storing afzonderlijke onderdelen systemen: opnieuw verzenden, een alternatieve route zoeken of andere methoden gebruiken. Omdat STP's zorgen voor informatie-uitwisseling tussen applicaties, moet het feit dat berichten niet worden afgeleverd, worden gevolgd en verwerkt (in tegenstelling tot e-mail, waarbij de gebruiker in geval van niet-bezorging van een bericht corrigerende maatregelen moet nemen);

Ø Geen blokkering van de applicatie tijdens de overdracht van informatie, omdat De technologie van berichtenwachtrijen is aanwezig en het servergedeelte van het TP-systeem is toegewezen, dat verantwoordelijk is voor de bezorging van berichten. Gebrek aan blokkering vermindert de downtime van applicaties;

Ø Mogelijkheid om berichtprioriteiten en opties in te stellen bij het verzenden. Met prioriteiten kunt u er meerdere implementeren parallelle systemen berichtoverdracht. In dit geval hebben berichten met een lagere prioriteit geen enkele invloed op de bezorging van berichten met een hogere prioriteit. hoge prioriteit. Dit heeft een positief effect bij het ontwerpen en configureren grote systemen, evenals in systeembeheer;

Ø Mogelijkheid tot informatie-uitwisseling in een heterogene omgeving, waar modernisering van zowel hardware als software mogelijk is.

Klassieke client-serverarchitectuur

De term "client-server" verwijst naar deze architectuur softwarepakket, waarin de functionele delen ervan samenwerken volgens het verzoek-antwoordschema. Als we twee op elkaar inwerkende delen van dit complex beschouwen, dan vervult een van hen (de client) een actieve functie, dat wil zeggen, het initieert verzoeken, en de andere (de server) reageert er passief op. Naarmate het systeem zich ontwikkelt, kunnen rollen bijvoorbeeld veranderen programma blok zal tegelijkertijd de functies van een server uitvoeren in relatie tot het ene blok en een client in relatie tot een ander blok.

Houd er rekening mee dat elk informatiesysteem ten minste drie functionele hoofdonderdelen moet hebben: modules voor gegevensopslag, gegevensverwerking en gebruikersinterface. Elk van deze onderdelen kan onafhankelijk van de andere twee worden geïmplementeerd. Zonder de programma's te wijzigen die worden gebruikt om gegevens op te slaan en te verwerken, kunt u bijvoorbeeld de gebruikersinterface wijzigen zodat dezelfde gegevens worden weergegeven in de vorm van tabellen, grafieken of histogrammen. Zonder de gegevenspresentatie- en opslagprogramma's te wijzigen, kunt u de verwerkingsprogramma's wijzigen, bijvoorbeeld door het zoekalgoritme voor de volledige tekst te wijzigen. Ten slotte kunt u, zonder de programma's voor het presenteren en verwerken van gegevens te wijzigen, de software voor het opslaan van gegevens wijzigen, bijvoorbeeld door naar een ander bestandssysteem te verhuizen.

In een klassieke client-serverarchitectuur moeten de drie hoofdonderdelen van de applicatie over twee fysieke modules worden verdeeld. Doorgaans bevindt software voor gegevensopslag zich op een server (bijvoorbeeld een databaseserver), de gebruikersinterface bevindt zich aan de clientzijde, maar de gegevensverwerking moet worden verdeeld tussen de client- en serveronderdelen. Dit is het grootste nadeel architectuur met twee lagen, waaruit er meerdere volgen onaangename kenmerken, wat de ontwikkeling van client-serversystemen enorm bemoeilijkt.

Bij het splitsen van algoritmen voor gegevensverwerking is het noodzakelijk om het gedrag van beide delen van het systeem te synchroniseren. Alle ontwikkelaars moeten dit hebben volledige informatie O laatste wijzigingen wijzigingen die in het systeem zijn aangebracht en deze wijzigingen begrijpen. Dit schept grote moeilijkheden bij de ontwikkeling van client-serversystemen, de installatie en het onderhoud ervan, aangezien het noodzakelijk is aanzienlijke inspanningen te besteden aan het coördineren van acties verschillende groepen specialisten. Er ontstaan ​​​​vaak tegenstrijdigheden in de acties van ontwikkelaars, en dit vertraagt ​​​​de ontwikkeling van het systeem en dwingt hen om kant-en-klare en beproefde elementen te veranderen.

Om inconsistentie tussen verschillende elementen van de architectuur te voorkomen, proberen ze gegevensverwerking uit te voeren op een van de twee fysieke delen: aan de clientzijde (thick client) of aan de serverzijde (thin client, of een architectuur genaamd 2,5-tier client) .server"). Elke benadering heeft zijn nadelen. In het eerste geval wordt het netwerk ten onrechte overbelast, omdat er onverwerkte en dus redundante gegevens doorheen worden verzonden. Bovendien wordt het ondersteunen en wijzigen van het systeem moeilijker, omdat het vervangen van een rekenalgoritme of het corrigeren van een fout een gelijktijdige volledige vervanging van alle interfaceprogramma's vereist, anders kunnen er fouten of inconsistenties in de gegevens optreden. Als alle informatieverwerking op de server wordt uitgevoerd (als dit zelfs maar mogelijk is), ontstaat het probleem van het beschrijven van ingebouwde procedures en het debuggen ervan. Feit is dat de taal voor het beschrijven van ingebouwde procedures meestal declaratief is en daarom in principe geen stapsgewijze foutopsporing mogelijk maakt. Bovendien is een systeem met informatieverwerking op een server absoluut niet over te dragen naar een ander platform, wat een ernstig nadeel is.

De meeste moderne tools voor snelle applicatieontwikkeling (RAD) die met verschillende databases werken, implementeren de eerste strategie, dat wil zeggen dat de dikke client een interface biedt met de databaseserver via ingebedde SQL. Deze optie voor het implementeren van een systeem met een “thick” client biedt, naast de hierboven genoemde nadelen, doorgaans een onaanvaardbaar laag beveiligingsniveau. In banksystemen moeten bijvoorbeeld alle transactieoperatoren het recht krijgen om naar de hoofdtabel van het boekhoudsysteem te schrijven. Bovendien is het vrijwel onmogelijk om dit systeem over te zetten naar webtechnologie, omdat gespecialiseerde clientsoftware wordt gebruikt om toegang te krijgen tot de databaseserver.

De hierboven besproken modellen hebben dus de volgende nadelen.

1. "Dikke" klant:
# complexiteit van de administratie;
# het updaten van de software wordt moeilijker, omdat deze over het hele systeem gelijktijdig vervangen moet worden;
# de verdeling van bevoegdheden wordt ingewikkelder, omdat de toegang niet wordt beperkt door acties, maar door tabellen;
# het netwerk is overbelast door de overdracht van onverwerkte gegevens;
# zwakke gegevensbescherming, omdat het moeilijk is om de bevoegdheden correct te verdelen.

2. "Vette" server:
# implementatie wordt ingewikkelder, omdat talen als PL/SQL niet geschikt zijn om dergelijke software te ontwikkelen en dat is er ook niet goede fondsen debuggen;
# de prestaties van programma's die in talen als PL/SQL zijn geschreven, zijn aanzienlijk lager dan die van programma's die in andere talen zijn gemaakt belangrijk voor complexe systemen;
# programma's geschreven in DBMS-talen werken meestal niet betrouwbaar; een fout daarin kan leiden tot het falen van de gehele databaseserver;
# De resulterende programma's zijn volledig niet overdraagbaar naar andere systemen en platforms.

Om deze problemen op te lossen, worden client-server-architecturen met meerdere niveaus (drie of meer niveaus) gebruikt.

Client-server-architecturen met meerdere lagen

Dergelijke architecturen distribueren op intelligentere wijze gegevensverwerkingsmodules, die in dit geval op een of meer afzonderlijke servers draaien. Deze softwaremodules vervullen de functies van een server voor gebruikersinterfaces en een client voor databaseservers. Bovendien kunnen verschillende applicatieservers met elkaar communiceren om het systeem nauwkeuriger te verdelen in functionele eenheden die specifieke rollen vervullen. U kunt bijvoorbeeld een personeelsbeheerserver selecteren die alle functies uitvoert die nodig zijn voor personeelsbeheer. Door er een aparte database aan te koppelen, kunt u alle implementatiedetails van deze server voor gebruikers verbergen, waardoor ze alleen toegang hebben tot de openbare functies. Bovendien is een dergelijk systeem heel gemakkelijk aan te passen aan het web, omdat het gemakkelijker is om HTML-formulieren te ontwikkelen voor gebruikerstoegang tot specifieke databasefuncties dan tot alle gegevens.

In een architectuur met drie lagen wordt de thin client niet overbelast met gegevensverwerkingsfuncties, maar vervult hij zijn belangrijkste rol als systeem voor het presenteren van informatie die afkomstig is van de applicatieserver. Een dergelijke interface kan worden geïmplementeerd met behulp van standaard webtechnologietools: een browser, CGI en Java. Dit vermindert de hoeveelheid gegevens die wordt overgedragen tussen de client en de applicatieserver, waardoor u verbinding kunt maken clientcomputers zelfs over langzame lijnen zoals telefoonlijnen. Bovendien kan de clientzijde zo eenvoudig zijn dat deze in de meeste gevallen wordt geïmplementeerd met behulp van universele browser. Maar als u het toch moet veranderen, kan deze procedure snel en pijnloos worden uitgevoerd. De drielaagse client-server-architectuur maakt een nauwkeurigere toewijzing van gebruikersrechten mogelijk, omdat zij geen toegangsrechten krijgen tot de database zelf, maar tot bepaalde functies van de applicatieserver. Dit verhoogt de veiligheid van het systeem (vergeleken met conventionele architectuur), niet alleen tegen opzettelijke aanvallen, maar ook tegen foutieve acties van personeel.

Beschouw als voorbeeld een systeem waarvan de verschillende onderdelen op meerdere onderdelen werken verre vriend van andere servers. Laten we aannemen dat de ontwikkelaar een nieuwe versie van het systeem heeft ontvangen, voor de installatie waarvan het in een architectuur op twee niveaus noodzakelijk is om tegelijkertijd alle instellingen te wijzigen systeemmodules. Als dit niet gebeurt, kan de interactie van oude clients met nieuwe servers tot onvoorspelbare gevolgen leiden, omdat ontwikkelaars meestal niet op een dergelijk gebruik van het systeem rekenen. In een architectuur met drie niveaus is de situatie vereenvoudigd. Het feit is dat door het veranderen van de applicatieserver en de gegevensopslagserver (dit is gemakkelijk tegelijkertijd te doen, aangezien ze zich meestal allebei in de buurt bevinden), we de set onmiddellijk veranderen beschikbare diensten. De kans op een fout als gevolg van een mismatch tussen de versies van de server- en clientonderdelen wordt dus sterk verminderd. Als binnen nieuwe versie Als een dienst is verdwenen, dan zijn dat de interface-elementen waarin deze dienst heeft gedaan oud systeem, ze zullen gewoon niet werken. Als het algoritme van de service is gewijzigd, werkt deze zelfs met de oude interface correct.

Client-serversystemen met meerdere niveaus kunnen vrij eenvoudig worden overgedragen naar webtechnologie. Om dit te doen, volstaat het om het clientgedeelte te vervangen door een universele of gespecialiseerde browser en de applicatieserver aan te vullen met een webserver en kleine serverprocedureaanroepprogramma's . Om deze programma's te ontwikkelen, kunt u beide gebruiken Gemeenschappelijke toegangspoort Interface (CGI) en meer moderne technologie Java.

Er moet ook worden opgemerkt dat in een systeem met drie niveaus nogal wat informatie wordt verzonden via het communicatiekanaal tussen de applicatieserver en de database. Dit vertraagt ​​de berekeningen echter niet, omdat er snellere lijnen kunnen worden gebruikt om deze elementen met elkaar te verbinden. Dit vereist minimale inspanning, aangezien beide servers zich meestal in hetzelfde pand bevinden. Zo nemen de totale prestaties van het systeem toe: twee mensen werken nu aan één taak. verschillende servers, en de communicatie tussen hen kan via de snelste lijnen worden uitgevoerd minimale kosten fondsen. Het is waar dat er een probleem is van de consistentie van gezamenlijke berekeningen, dat transactiemanagers – nieuwe elementen van systemen met meerdere niveaus – moeten oplossen.

Vertaling uit het Engels: Chernobay Yu A.

Ontwikkeling van client-serversystemen

Architectuur computersysteem is geëvolueerd samen met het vermogen van de hardware om de applicaties die erop draaien te gebruiken. De eenvoudigste (en vroegste) van allemaal was de "Mainframe Architecture", waarin alle bewerkingen en functies worden uitgevoerd binnen de server- (of "host")-computer. Gebruikers hadden interactie met de server via "domme" terminals, die instructies doorgaven door toetsaanslagen naar de server vast te leggen en de resultaten van de instructies aan de gebruiker lieten zien. Dergelijke toepassingen waren typisch van aard en waren, ondanks de relatief grote rekenkracht van servercomputers, over het algemeen relatief traag en onhandig in gebruik, vanwege de noodzaak om elke toetsaanslag naar de server te verzenden.

Introductie en wijdverbreide acceptatie van de pc, met zijn eigen pc rekenkracht en grafische gebruikersinterface zorgden ervoor dat applicaties complexer en uitgebreider werden netwerk systemen leidde tot het tweede belangrijke type systeemarchitectuur, "Bestandspartitionering". In deze pc-architectuur (of " werkstation") downloadt bestanden van een gespecialiseerde "bestandsserver" en beheert vervolgens de applicatie (inclusief de data) lokaal. Dit werkt goed wanneer het gedeelde datagebruik, de data-updates en de hoeveelheid over te dragen data klein zijn. Het zal echter al snel Het werd duidelijk dat het delen van bestanden het netwerk nog meer verstopte, en dat applicaties complexer werden en dat iedereen dat nodig had meer gegevens werden in beide richtingen verzonden.

De problemen die gepaard gaan met het verwerken van gegevens via een bestand dat via een netwerk wordt gedeeld, leidden begin jaren tachtig tot de ontwikkeling van de client-server-architectuur. Bij deze aanpak wordt de bestandsserver vervangen door een databaseserver, die, in plaats van eenvoudigweg bestanden te verzenden en op te slaan naar aangesloten werkstations (clients), verzoeken om gegevens ontvangt en daadwerkelijk uitvoert, waarbij alleen het door de client gevraagde resultaat wordt geretourneerd. Door alleen de door de klant gevraagde gegevens te verzenden in plaats van het hele bestand, vermindert deze architectuur de netwerkbelasting aanzienlijk. Dit maakte het mogelijk een systeem te creëren waarin meerdere gebruikers gegevens konden bijwerken via GUI-interfaces die waren gekoppeld aan één gedeelde database.

Normaal gesproken worden Structured Query Language (SQL) of Remote Procedure Call (RPC's) gebruikt om gegevens uit te wisselen tussen de client en de server. Hieronder worden verschillende basisopties voor het organiseren van een client-serverarchitectuur beschreven.

In een architectuur met twee lagen wordt de belasting verdeeld tussen de server (die de database huisvest) en de client (die de gebruikersinterface huisvest). In de regel bevinden ze zich op verschillende locaties fysieke machines, maar dit is geen verplichte vereiste. Mits de lagen logisch gescheiden zijn, kunnen ze (bijvoorbeeld voor ontwikkelen en testen) op dezelfde computer worden geplaatst (Fig. 1).

Figuur 1: Architectuur met twee lagen

De verdeling van applicatielogica en dataverwerking in dit model was en blijft problematisch. Als de klant “slim” is en de hoofdverwerking van de gegevens uitvoert, ontstaan ​​er problemen in verband met de distributie, installatie en onderhoud van de applicatie, aangezien elke klant zijn eigen lokale kopie van de software nodig heeft. Als de klant "dom" is, moeten de applicatielogica en -verwerking in de database worden geïmplementeerd, en daarom wordt deze volledig afhankelijk van het specifieke DBMS dat wordt gebruikt. In ieder geval moet elke klant zich registreren en, afhankelijk van de toegangsrechten die hij krijgt, bepaalde functies uitvoeren. De client-server-architectuur met twee lagen was dat echter wel goede beslissing, toen het aantal gebruikers relatief klein was (tot ongeveer 100 gelijktijdige gebruikers), maar met de groei van het aantal gebruikers kwamen er een aantal beperkingen aan het gebruik van deze architectuur.

Prestaties: Naarmate het aantal gebruikers toeneemt, beginnen de prestaties te verslechteren. De achteruitgang van de prestaties is recht evenredig met het aantal gebruikers dat elk heeft eigen aansluiting met de server, wat betekent dat de server al deze verbindingen moet onderhouden (met behulp van een "Keep-Alive"-bericht), zelfs als er geen toegang tot de database is.

Beveiliging: elke gebruiker moet zijn eigen hebben individuele toegang toe te voegen aan de database en de rechten te krijgen om de applicatie te gebruiken. Om dit te doen, is het noodzakelijk om de toegangsrechten voor elke gebruiker in de database op te slaan. Wanneer u functionaliteit aan een applicatie moet toevoegen en de gebruikersrechten moet bijwerken.

Functionaliteit: Ongeacht het type client dat wordt gebruikt, moet het grootste deel van de gegevensverwerking in de database plaatsvinden, wat betekent dat deze volledig afhankelijk is van de mogelijkheden die de fabrikant in de database biedt. Dit kan de functionaliteit van de applicatie ernstig beperken, omdat verschillende bases gegevensverwerkers ondersteunen verschillende functies, gebruiken verschillende programmeertalen en implementeren zelfs basisfuncties zoals triggers op verschillende manieren.

Portabiliteit: Tweelaagsarchitectuur is zo afhankelijk van de specifieke database-implementatie dat portabiliteit mogelijk is bestaande applicaties voor verschillende DBMS'en wordt dit een serieus probleem. Dit geldt vooral voor toepassingen in verticale markten waar de keuze voor DBMS niet door de leverancier wordt bepaald.

Maar desondanks werd er architectuur op twee niveaus gevonden nieuw leven in het internettijdperk. Het kan goed werken als de verbinding is verbroken omgeving, waarbij de gebruikersinterface "dom" is (bijvoorbeeld browser). In veel opzichten vertegenwoordigt deze implementatie echter een terugkeer naar de oorspronkelijke mainframe-architectuur.

In een poging om de beperkingen van de beschreven tweeledige architectuur te overwinnen algemene schets hierboven werd een extra niveau geïntroduceerd. Deze architectuur is standaard model client-server met drielaagse architectuur. Het doel van de extra laag (gewoonlijk de "middelste" of "regels"-laag genoemd) is het beheren van de uitvoering van applicaties en het databasebeheer. Net als bij het model met twee niveaus kunnen de niveaus zich op beide niveaus bevinden diverse computers(Figuur 2), of op één computer in testmodus.

Figuur 2: Architectuur met drie lagen

Door binnen te komen middelste rij zijn de beperkingen van de tweelaagse architectuur grotendeels geëlimineerd, wat resulteert in een veel flexibeler en schaalbaarder systeem. Omdat clients nu alleen verbinding maken met de applicatieserver en niet rechtstreeks met de dataserver, wordt de last van het onderhouden van verbindingen weggenomen, evenals de noodzaak om applicatielogica in de database te implementeren. De database kan nu alleen de functies uitvoeren van het opslaan en ophalen van gegevens, en de taak van het ontvangen en verwerken van applicaties kan worden uitgevoerd door gemiddeld niveau architectuur met drie niveaus. Ontwikkeling besturingssystemen, dat elementen omvatte zoals het poolen van verbindingen, wachtrijen en gedistribueerde transactieverwerking, versterkte (en vereenvoudigde) de ontwikkeling van de middenlaag.

Houd er rekening mee dat bij dit model applicatieserver heeft geen controle over de gebruikersinterface, en de gebruiker bevraagt ​​ook niet rechtstreeks de database. In plaats daarvan kunnen meerdere klanten bedrijfslogica, berekeningen en toegang delen zoekmachine gegevens. Het grote voordeel is dat de klant minder software nodig heeft en niet meer nodig heeft directe verbinding naar de database, wat de veiligheid verhoogt. Bijgevolg is de applicatie schaalbaarder, de kosten voor ondersteuning en installatie op één server zijn veel lager dan voor het onderhouden van applicaties rechtstreeks op de computer van de klant of zelfs op een tweelaagse architectuur.

Er zijn veel variaties op de basismodellen met drie niveaus die zijn ontworpen om te presteren verschillende functies. Deze omvatten gedistribueerde transactieverwerking (waarbij meerdere DBMS'en worden bijgewerkt in hetzelfde protocol), op berichten gebaseerde toepassingen (waarbij toepassingen niet in realtime communiceren) en platformonafhankelijke compatibiliteit (Object Aanvraag makelaar of "ORB"-applicatie).

Architectuur met meerdere lagen of architectuur met N-lagen

Met de ontwikkeling van internettoepassingen tegen de achtergrond van een algemene toename van het aantal gebruikers, werd het basiscliënt-servermodel met drie niveaus uitgebreid door de introductie van extra niveaus. Dergelijke architecturen worden 'multi-tier' genoemd en bestaan ​​doorgaans uit vier lagen (Afbeelding 3), waarbij een server in het netwerk verantwoordelijk is voor het afhandelen van de verbinding tussen de browserclient en de applicatieserver. Het voordeel is dat meerdere webservers verbinding kunnen maken naar één enkele applicatieserver, waardoor de verwerking toeneemt meer gelijktijdig verbonden gebruikers.

Figuur 3: N-tier-architectuur

Niveaus versus lagen

Deze termen worden (helaas) vaak met elkaar verward. Er is echter een groot verschil tussen hen en ze hebben een bepaalde betekenis. Het belangrijkste verschil is dat de niveaus dat zijn fysiek niveau en de lagen staan ​​op logisch. Met andere woorden: het niveau kan in theorie zelfstandig worden ingezet aparte computer en de laag logische scheiding binnen het niveau (Figuur 4). Het typische hierboven beschreven drielagenmodel bevat doorgaans ten minste zeven lagen, verdeeld over alle drie niveaus.

Het belangrijkste om te onthouden over een gelaagde architectuur is dat verzoeken en antwoorden van elke thread in dezelfde richting alle lagen doorkruisen, en dat lagen nooit kunnen worden overgeslagen. In het in figuur 4 getoonde model is dus de enige laag die toegang heeft tot laag "E" (de laag voor gegevenstoegang) laag "D" (de laag met regels). Op dezelfde manier kan laag "C" (de applicatievalidatielaag) alleen reageren op verzoeken van laag "B" (de foutafhandelingslaag).

Figuur 4: Rijen verdeeld in logische lagen

Multi-tier client-server-architectuur

Multi-level client-server-architectuur is een type client-server-architectuur waarbij de gegevensverwerkingsfunctie wordt uitgevoerd op een of meer afzonderlijke servers. Hierdoor kunt u de functies van het opslaan, verwerken en presenteren van gegevens nog meer scheiden effectief gebruik mogelijkheden van servers en clients.

Speciale gevallen van architectuur op meerdere niveaus:

· Drielaagse architectuur

· Speciaal servernetwerk

· Een netwerk met een speciale server (Engels Client/Server-netwerk) is een lokaal netwerk computernetwerk(LAN), waarin netwerk apparaten gecentraliseerd en beheerd door een of meer servers. Individuele werkstations of clients (zoals pc's) moeten via server(s) toegang krijgen tot netwerkbronnen.

Netwerkbesturingssysteem- een besturingssysteem met ingebouwde mogelijkheden om in te werken computernetwerken. Dergelijke mogelijkheden zijn onder meer:

· steun netwerkapparatuur

· steun netwerkprotocollen

· ondersteuning voor routeringsprotocollen

· filterondersteuning netwerk verkeer

· ondersteuning voor toegang tot externe bronnen zoals printers, schijven, enz. via het netwerk

Beschikbaarheid in het systeem netwerkdiensten toestaan gebruikers op afstand gebruik computerbronnen

Voorbeelden van netwerkbesturingssystemen:

Novell NetWare

· Microsoft Windows(95, NT, XP, Vista, Zeven)

· Verscheidene UNIX-systemen, zoals Solaris, FreeBSD

· Diverse GNU/Linux-systemen

ZyNOS van ZyXEL

Moderne netwerkbesturingssystemen (UNIX, WIN2000, NOWELL NW) implementeren de volledige protocolstack van het OSI-model. UNIX ondersteunt dus een protocolstack (TCP/IP, NW LINK, NET BIOS). Nowell NW ondersteunt de IPX/SPX-protocolstack. Apple Mac gebruikt zijn eigen set protocollen.

Ongeacht de fabrikant worden alle netwerkbesturingssystemen geïmplementeerd volgende functies:

1. Verdeling van functies tussen netwerkknooppunten (clients en servers);

2. Ondersteuning communicatie protocollen;

3. Ondersteuning voor netwerkbestandssysteem;

4. Gegevensbescherming.

Alle netwerkbesturingssystemen kunnen in 2 typen worden verdeeld:

1. Peer-to-peer- of peer-to-peer-netwerken (elk van elk). Windows-voorbeeld 9x;

2. Netwerk gebaseerd op een dedicated server.

K1. In een peer-to-peer netwerk hebben alle pc’s gelijke rechten, maar er bevinden zich ook clients en servers in het netwerk. Normaal gesproken kan elke pc naar de servermodus worden geschakeld als de gebruiker dat wil (er wordt een gedeelde bron toegewezen).

Het peer-to-peer netwerkbesturingssysteem mist betrouwbare prestaties en beveiliging. Gebruikt op het netwerk als er 10-15 stuks zijn. Een voorbeeld van een peer-to-peer-netwerk is Win94/98/OS/2/LANtastic

K2. In dit netwerk bevindt zich altijd een hoofd-PC: een server, die speciaal is geoptimaliseerd snelle verwerking verzoeken van veel klanten (ongeveer -100) en om de bescherming van bestanden en mappen te beheren. IN grote netwerken opvallen aparte servers Voor individuele toepassingen(WEB – server, Bestand – server, Afdrukken – server, DB-server en mailserver)

Serversoftware is zeer geavanceerd, betrouwbaar en performant. Het kan op verschillende platforms functioneren.