Opgemerkt moet worden dat, zoals elke classificatie, onze classificatie van informatiesysteemarchitecturen niet absoluut rigide is. In de architectuur van een bepaald informatiesysteem zijn vaak de invloeden van verschillende algemene architecturale beslissingen terug te vinden. Bij het architectonisch ontwerpen van een systeem lijkt het echter nuttig om op zijn minst een gedeeltelijk orthogonale architecturale basis te hebben. In de volgende delen van de cursus zullen we de kenmerken van elke architectuur in detail bekijken en stilstaan ​​bij de methodologieën en technologische hulpmiddelen die het ontwerp en de ontwikkeling van informatiesystemen in de overeenkomstige architectuur ondersteunen.

2.1. Bestandsservertoepassingen

Blijkbaar is de organisatie van informatiesystemen op basis van het gebruik van speciale bestandsservers nog steeds het meest wijdverbreid vanwege de aanwezigheid van een groot aantal personal computers met verschillende ontwikkelingsniveaus en de relatief goedkope verbinding van pc's met lokale netwerken. Wat trekt zo'n organisatie van informatiesysteemontwikkelaars aan die niet erg ervaren zijn op het gebied van systeemprogrammering? Hoogstwaarschijnlijk blijft de autonomie van de applicatiesoftware (en de meeste systeemsoftware) die op elke pc in het netwerk draait, behouden, hoewel ze vertrouwen op bestandsserver-architecturen. In feite werken de componenten van het informatiesysteem, die op verschillende pc's worden uitgevoerd, alleen met elkaar samen dankzij de aanwezigheid van een gemeenschappelijke bestandsopslag, die is opgeslagen op een bestandsserver. In het klassieke geval dupliceert elke pc niet alleen applicatieprogramma's, maar ook databasebeheertools. De bestandsserver is een uitbreiding van het schijfgeheugen dat door alle pc's van het complex wordt gedeeld (Figuur 2.1).

Zonder in detail stil te staan ​​bij de veelbelovende tools voor de ontwikkeling van file-server-applicaties die vandaag op de markt beschikbaar zijn en zonder een analyse te geven van de ontwikkelingstrends van de corresponderende technologieën (het derde deel van de cursus is hieraan gewijd), zullen we kort noem de belangrijkste voor- en nadelen van bestandsserver-architecturen.

Het belangrijkste voordeel is natuurlijk het gemak van de organisatie. Ontwerpers en ontwikkelaars van het informatiesysteem bevinden zich in de vertrouwde en comfortabele omstandigheden van een IBM-pc in MS-DOS, Windows of een willekeurige lichtgewicht versie van Windows NT. Er zijn handige en geavanceerde ontwikkeltools voor de grafische gebruikersinterface, gebruiksvriendelijke tools voor het ontwikkelen van databasesystemen en/of DBMS. Maar in veel opzichten is deze eenvoud duidelijk. (Zoals het Russische spreekwoord zegt: "Eenvoud is erger dan stelen", en hier hebben we meestal eenvoud gebaseerd op diefstal van pc-software.)

Rijst. 2.1. De klassieke weergave van het informatiesysteem in de "file-server"-architectuur

Ten eerste moet het informatiesysteem met de database werken. Daarom moet deze database worden ontworpen. Om de een of andere reden geloven ontwikkelaars van bestandsservertoepassingen vaak dat vanwege de eenvoud van databasebeheertools, het probleem van databaseontwerp kan worden verwaarloosd. Dit is natuurlijk fout. De databank is een databank. Hoe beter het is ontworpen, hoe meer kans er is om het informatiesysteem later effectief te gebruiken. Uiteraard wordt de complexiteit van het databaseontwerp bepaald door de objectieve complexiteit van het gesimuleerde domein. Maar waaruit zou in feite moeten volgen dat bestandsservertoepassingen alleen geschikt zijn voor eenvoudige vakgebieden?

Ten tweede, zoals we herhaaldelijk hebben benadrukt in het eerste deel van de cursus, zijn de noodzakelijke vereisten voor de informatiesysteemdatabase het behoud van zijn integrale staat en gegarandeerde betrouwbaarheid van informatieopslag. De minimale voorwaarden waaronder aan deze eisen kan worden voldaan zijn:

de aanwezigheid van transactiecontrole, opslag van redundante gegevens (bijvoorbeeld met behulp van logboekmethoden), de mogelijkheid om integriteitsbeperkingen te formuleren en de naleving ervan te verifiëren.

De bestandsserverorganisatie, zoals weergegeven in figuur 2.1, is in principe niet in strijd met het naleven van de genoemde voorwaarden. Een voorbeeld van een systeem dat aan deze voorwaarden voldoet, maar gebaseerd is op een bestandsserverarchitectuur, is de in het verleden populaire Informix SE "databaseserver".

Lange opmerking:
Om de duidelijkheid van de verdere presentatie te behouden, moeten we de terminologie enigszins verduidelijken. Niet voor niets schreven we "databaseserver" tussen aanhalingstekens voor het Informix SE DBMS. Met dit systeem werd een kopie van de DBMS-software bijgehouden voor elke door de gebruiker geïnitieerde DBMS-sessie. Grofweg werd voor elk gebruikersproces dat interactie had met de database, een DBMS-serviceproces gemaakt, dat werd uitgevoerd op dezelfde processor als het gebruikersproces (d.w.z. aan de clientzijde). Elk van deze serviceprocessen gedroeg zich eigenlijk alsof ze de enige vertegenwoordiger van het DBMS waren. Alle synchronisatie van mogelijk parallel werk met de database werd uitgevoerd op het niveau van externe geheugenbestanden die de database bevatten. Laten we voortaan overeenkomen om dergelijke DBMS geen databaseservers te noemen, maar databasebeheersystemen op basis van de bestandsserverarchitectuur (DBMS-FS).

Met een echte databaseserver bedoelen we softwarevorming gekoppeld aan de corresponderende database(s), bestaande, in het algemeen, ongeacht het bestaan ​​van gebruikers (client) processen en uitgevoerd, in het algemeen (hoewel niet noodzakelijk) op dedicated hardware (we hebben bewust we gebruiken niet erg specifieke termen "software-educatie" en "dedicated hardware", omdat hun specifieke implementatie verschilt in verschillende databaseservers).

Echte databaseservers zijn veel complexer qua organisatie dan de DBMS-FS, maar ze bieden fijner en efficiënter databasebeheer. In de rest van deze cursus, wanneer we de term "databaseserver" gebruiken, bedoelen we echte databaseservers.

Maar aan de andere kant wordt in de meeste persoonlijke DBMS niet aan deze voorwaarden voldaan, zelfs niet met behulp van ruwe methoden. In het beste geval is het mogelijk om de tekortkomingen op het niveau van applicatieprogramma's gedeeltelijk te compenseren.

Ten derde is de interface van geavanceerde databaseservers gebaseerd op het gebruik van een SQL-databasetaal op hoog niveau, die het gebruik van netwerkverkeer tussen de client en de databaseserver alleen voor nuttige doeleinden mogelijk maakt (SQL-statements worden voornamelijk verzonden van de client naar de server, van de server naar de client - de resultaten van de uitvoering van operators). In een bestandsserverorganisatie werkt de client met externe bestanden, wat een aanzienlijke overbelasting van het verkeer veroorzaakt (aangezien de DBMS-FS aan de clientzijde werkt, is het in het algemeen noodzakelijk om de volledige bijbehorende bestand aan de clientzijde).

Over het algemeen hebben we in een bestandsserverarchitectuur een "dikke" client en een zeer "dunne" server in die zin dat bijna al het werk aan de clientzijde wordt gedaan en de server alleen voldoende schijfruimte nodig heeft (Figuur 2.2).

Rijst. 2.2. Dikke client en dunne server in bestandsserverarchitectuur

Korte conclusies. Een eenvoudige, kleine bestandsservertoepassing voor één gebruiker kan zeer snel worden ontworpen, ontwikkeld en debuggen. Heel vaak voor een klein bedrijf om bijvoorbeeld personeelsdossiers bij te houden, is het voldoende om een ​​geïsoleerd systeem op een stand-alone pc te hebben. Uiteraard is ook in dit geval grote zorg vereist van eindgebruikers (of beheerders, van wie de aanwezigheid in dit geval twijfelachtig is) om de integriteit van de gegevens veilig op te slaan en te behouden. In al iets complexere gevallen (bijvoorbeeld bij het organiseren van een informatiesysteem ter ondersteuning van een project dat door een groep wordt uitgevoerd), worden fileserver-architecturen echter onvoldoende.

Client-server-applicaties

Met een client-servertoepassing bedoelen we een informatiesysteem gebaseerd op het gebruik van databaseservers (zie de lange noot aan het einde van paragraaf 2.1). Het algemene beeld van het informatiesysteem in de client-server-architectuur is weergegeven in figuur 2.3.

Aan de clientzijde wordt de applicatiecode uitgevoerd, die noodzakelijkerwijs componenten bevat die de interface met de eindgebruiker ondersteunen, rapporten produceren en andere applicatiespecifieke functies uitvoeren (totdat we ons zorgen maken over hoe de applicatiecode is opgebouwd). De clientzijde van de toepassing werkt samen met de clientzijde van de databasebeheersoftware, die in feite een individuele DBMS-vertegenwoordiger is voor de toepassing.

(Dit is waar de terminologie opnieuw gebrekkig is. Meestal, wanneer een bedrijf de release van een nieuwe databaseserver aankondigt, wordt impliciet begrepen dat er ook een clientzijde van dit product is. De combinatie "clientzijde van een databaseserver" lijkt een beetje vreemd, maar dit is wat we de term moeten gebruiken.)

Rijst. 2.3. Algemeen beeld van het informatiesysteem in de client-server-architectuur

Merk op dat de interface tussen de front-end van de applicatie en de front-end van de databaseserver meestal gebaseerd is op SQL. Daarom worden functies zoals bijvoorbeeld het voorbewerken van formulieren die bedoeld zijn voor query's naar de database, of het genereren van de resulterende rapporten uitgevoerd in de applicatiecode.

Ten slotte heeft de clientzijde van de databaseserver, met behulp van netwerktoegangsfaciliteiten, toegang tot de databaseserver en geeft deze de tekst van de SQL-instructie door.

Er zijn hier nog twee opmerkingen.

Bedrijven die geavanceerde databaseservers produceren, streven er doorgaans naar om ervoor te zorgen dat hun producten niet alleen kunnen worden gebruikt in de huidige standaard op TCP / IP gebaseerde netwerken, maar ook in netwerken die zijn gebaseerd op andere protocollen (bijvoorbeeld SNA of IPX / SPX) ... Daarom worden bij het organiseren van netwerkinteracties tussen de client- en servergedeelten van het DBMS vaak geen standaard tools op hoog niveau (bijvoorbeeld software-sockets of externe procedureaanroepen) gebruikt, maar hun eigen functioneel vergelijkbare tools die minder afhankelijk zijn van de functies van netwerktransportprotocollen. Als we het hebben over een interface gebaseerd op de SQL-taal, moeten we ons ervan bewust zijn dat ondanks de enorme inspanningen om deze taal te standaardiseren, er geen implementatie is waarin de standaardfuncties van de taal niet zijn uitgebreid. Roekeloos gebruik van taalextensies leidt tot volledige afhankelijkheid van de applicatie van de specifieke fabrikant van de databaseserver.

Laten we nu eens kijken wat er gebeurt aan de kant van de databaseserver. In de producten van bijna alle bedrijven ontvangt de server van de klant de tekst van het statement in SQL.

De server compileert de ontvangen operator. We zullen hier niet uitweiden over welke doeltaal door een bepaalde compiler wordt gebruikt; verschillende implementaties gebruiken verschillende benaderingen (zie deel 4 voor voorbeelden). Het belangrijkste is dat in ieder geval, op basis van de informatie in de databasecatalogustabellen, de niet-procedurele weergave van de operator wordt omgezet in een bepaalde procedure voor de uitvoering ervan. Verder (als de compilatie met succes is voltooid) wordt de instructie uitgevoerd. Nogmaals, we zullen geen technische details bespreken omdat ze verschillen in implementatie. Laten we eens kijken naar de mogelijke acties van de SQL-instructies.
Een operator kan behoren tot de klasse van operators voor het bepalen (of maken) van database-objecten (het zou nauwkeuriger en correcter zijn om te praten over elementen van een databaseschema of over metabase-objecten). In het bijzonder kunnen domeinen, tabellen, integriteitsbeperkingen, triggers, gebruikersrechten en opgeslagen procedures worden gedefinieerd. In ieder geval, wanneer de instructie om een ​​databaseschema-element te maken wordt uitgevoerd, wordt de bijbehorende informatie in de databasecatalogustabellen (in de metabasetabellen) geplaatst. Integriteitsbeperkingen worden meestal direct in de tekstweergave in de metabase opgeslagen. Voor acties die zijn gedefinieerd in triggers en opgeslagen procedures, wordt procedurele uitvoerbare code gegenereerd en opgeslagen in catalogustabellen. Merk op dat integriteitsbeperkingen, triggers en opgeslagen procedures in zekere zin representatief zijn voor een toepassing in een door een server ondersteunde database; ze vormen de ruggengraat van de applicatie (zie hieronder). Bij het uitvoeren van gegevensselectie-instructies op basis van de inhoud van de tabellen waarop de query betrekking heeft en, mogelijk, met behulp van de indexen die in de database worden ondersteund, wordt de resulterende dataset gevormd (we gebruiken hier bewust niet de term "resultatentabel", omdat afhankelijk op het specifieke type operator kan het resultaat worden geordend, en tabellen, dat wil zeggen, relaties zijn per definitie ongeordend). De serverzijde van het DBMS stuurt het resultaat naar de clientzijde en de uiteindelijke verwerking vindt plaats aan de clientzijde van de toepassing. Bij het uitvoeren van operators voor het wijzigen van de inhoud van de database (INSERT, UPDATE, DELETE), wordt gecontroleerd of de integriteitsbeperkingen die op dat moment zijn gedefinieerd (die behoren tot de klasse van direct controleerbaar) niet worden geschonden, waarna de juiste actie wordt ondernomen wordt genomen (vergezeld van de wijziging van alle relevante indexen en logboekwijzigingen). Vervolgens controleert de server of deze wijziging de triggervoorwaarde van een trigger beïnvloedt, en als een dergelijke trigger wordt gevonden, voert deze zijn actieprocedure uit. Deze procedure kan aanvullende instructies voor het wijzigen van de database bevatten die andere triggers kunnen activeren, enz. U kunt ervan uitgaan dat de acties die op de databaseserver worden uitgevoerd bij het controleren of aan integriteitsbeperkingen is voldaan en wanneer triggers worden geactiveerd, de acties zijn van de backend van de toepassing. .. Bij het uitvoeren van instructies voor het wijzigen van databaseschema's (toevoegen of verwijderen van kolommen van bestaande tabellen, wijzigen van het gegevenstype van een bestaande kolom van een bestaande tabel, enz.) triggers kunnen ook worden geactiveerd, d.w.z. met andere woorden, de serverkant van de applicatie kan worden uitgevoerd. Evenzo kunnen triggers worden geactiveerd wanneer objecten in het databaseschema (domeinen, tabellen, integriteitsbeperkingen, enz.) worden vernietigd. Een speciale klasse van SQL-operators bestaat uit operators die eerder gedefinieerde opgeslagen procedures aanroepen die in de database zijn opgeslagen. Als een opgeslagen procedure is gedefinieerd met behulp van een voldoende ontwikkelde taal die zowel niet-procedurele SQL-instructies als puur procedurele constructies bevat (bijvoorbeeld de PL / SQL-taal van Oracle), dan kan een dergelijke procedure een aanzienlijk deel van de applicatie bevatten, die, wanneer de procedure-aanroepinstructie wordt uitgevoerd, wordt uitgevoerd aan de serverzijde en niet aan de clientzijde. Bij het uitvoeren van de transactievoltooiingsverklaring moet de server de naleving van alle zogenaamde uitgestelde integriteitsbeperkingen controleren (dergelijke beperkingen omvatten beperkingen die worden opgelegd aan de inhoud van de databasetabel als geheel of aan meerdere tabellen tegelijk; bijvoorbeeld de het totale salaris van de afdelingsmedewerkers 999 mag niet hoger zijn dan 150 miljoen roebel.). Nogmaals, het controleren op uitgestelde integriteitsbeperkingen kan worden gezien als het uitvoeren van de achterkant van de toepassing.

Zoals u kunt zien, kunnen clients in een client-serverorganisatie dun genoeg zijn en moet de server dik genoeg zijn om aan de behoeften van alle clients te kunnen voldoen (Figuur 2.4).

Rijst. 2.4. Thin client en fat server in client-server-architectuur

Aan de andere kant zijn ontwikkelaars en gebruikers van informatiesystemen gebaseerd op de client-server-architectuur vaak ontevreden over de aanhoudende netwerkoverheadkosten die het gevolg zijn van de noodzaak om bij elk volgend verzoek van de client naar de server te gaan. In de praktijk is de situatie wijdverbreid dat voor de effectieve werking van een afzonderlijk klantonderdeel van een informatiesysteem in werkelijkheid slechts een klein deel van de totale database nodig is. Dit leidt tot het idee om een ​​lokale gedeelde databasecache aan de clientzijde te onderhouden.

In feite is het concept van lokale databasecaching een speciaal geval van het concept van gerepliceerde (of, zoals ze in de Russischtalige literatuur soms worden genoemd, gerepliceerde) databases. Zoals in het algemene geval, moet de werkstationsoftware, om de lokale databasecache te ondersteunen, een databasebeheercomponent bevatten - een vereenvoudigde versie van de databaseserver die bijvoorbeeld geen toegang voor meerdere gebruikers mag bieden. Een apart punt is het zorgen voor de consistentie (samenhang) van caches en de gemeenschappelijke database. Hierbij zijn verschillende oplossingen mogelijk - van het automatisch behouden van de consistentie door middel van basis databasebeheersoftware tot het volledig overdragen van deze taak aan de applicatielaag. In ieder geval worden de clients dikker zonder de server dunner te maken (Figuur 2.5).

Rijst. 2.5. Fat client en fat server in client-server-architectuur met lokale cache-ondersteuning aan de clientzijde

Laten we enkele voorlopige conclusies formuleren. De client-server-architectuur lijkt op het eerste gezicht veel duurder dan de file-server-architectuur. Er is krachtigere hardware nodig (in ieder geval voor de server) en veel geavanceerdere hulpprogramma's voor databasebeheer. Dit is echter slechts gedeeltelijk waar. Een enorm voordeel van de client-server-architectuur is de schaalbaarheid en, in het algemeen, de mogelijkheid om te ontwikkelen.

Bij het ontwerpen van een informatiesysteem op basis van deze architectuur moet meer aandacht worden besteed aan de geletterdheid van algemene beslissingen. De technische middelen van de pilotversie kunnen minimaal zijn (een van de werkstations kan bijvoorbeeld worden gebruikt als hardwarebasis van de databaseserver). Na totstandkoming van de pilot moet aanvullend onderzoek worden gedaan om knelpunten in het systeem te identificeren. Pas daarna is het nodig om een ​​beslissing te nemen over de keuze van de serverhardware die in de praktijk zal worden gebruikt.

De schaalvergroting van het informatiesysteem levert geen fundamentele problemen op. De gebruikelijke oplossing is om de serverhardware te vervangen (en misschien de hardware van het werkstation als een overstap naar lokale databasecaching vereist is). In ieder geval wordt het toegepaste deel van het informatiesysteem praktisch niet aangetast. Idealiter, wat natuurlijk niet bestaat, blijft het informatiesysteem normaal functioneren na het wisselen van apparatuur.

Het doel van de lezing: laten zien hoe de algemene principes van client-servertechnologieën worden geïmplementeerd in webtechnologieën. Onderzoek de belangrijkste elementen van het onderliggende HTTP-protocol.

Het onderwerp van deze cursus zijn de technologieën van het wereldwijde netwerk World Wide Web (afgekort als WWW of simpelweg het Web). In het Russisch is een veel voorkomende variant de naam "Web".

In het bijzonder zal de cursus onderwerpen behandelen als: basisstandaarden en protocollen van het web, opmaaktalen en programmeertalen voor webpagina's, tools voor het ontwikkelen en beheren van webcontent en applicaties voor het web, tools voor het integreren van webcontent en applicaties in het web.

Netto Web is een wereldwijde informatieruimte gebaseerd op de fysieke infrastructuur van internet en het HTTP-protocol voor gegevensoverdracht. Als we het over internet hebben, bedoelen ze vaak het netwerk. Web.

Client-servertechnologieën Web

Het basisprotocol van het netwerk van hypertextbronnen Web is het HTTP-protocol. Het is gebaseerd op interactie" client server", dat wil zeggen, er wordt aangenomen dat:

Klant- klant na het initiëren van een verbinding met de serverprovider, stuurt deze een verzoek naar hem;

De leverancier- server Na het verzoek te hebben ontvangen, voert het de nodige acties uit en stuurt het een antwoord met het resultaat terug naar de klant.

In dit geval zijn er twee mogelijke manieren om het werk van de clientcomputer te organiseren:

Thin client is een clientcomputer die alle informatieverwerkingstaken naar de server overdraagt. Een voorbeeld van een thin client is een computer met een browser die wordt gebruikt om webapplicaties uit te voeren.

Dikke klant integendeel, het verwerkt informatie onafhankelijk van de server en gebruikt deze voornamelijk voor het opslaan van gegevens.

Laten we, voordat we verder gaan met specifieke client/server-webtechnologieën, eens kijken naar de fundamenten en structuur van het onderliggende HTTP-protocol.

HTTP-protocol

HTTP(HyperText Transfer Protocol - RFC 1945, RFC 2616) is een applicatielaagprotocol voor het overbrengen van hypertext.

Centraal in HTTP is hulpbron gewezen door URI op verzoek van de klant. Meestal zijn deze bronnen bestanden die op de server zijn opgeslagen. Een kenmerk van het HTTP-protocol is de mogelijkheid om in een verzoek en een antwoord een manier te specificeren om dezelfde bron door verschillende parameters weer te geven: formaat, codering, taal, enz. Het is dankzij de mogelijkheid om de methode voor het coderen van een bericht te specificeren dat de client en de server binaire gegevens kunnen uitwisselen, hoewel dit protocol in eerste instantie bedoeld was voor het overdragen van symbolische informatie. Op het eerste gezicht lijkt dit misschien een verspilling van middelen. Gegevens in symbolische vorm nemen inderdaad meer geheugen in beslag, berichten zorgen voor een extra belasting van communicatiekanalen, maar dit formaat heeft veel voordelen. De berichten die via het netwerk worden verzonden, zijn leesbaar en door de ontvangen gegevens te analyseren, kan de systeembeheerder de fout gemakkelijk vinden en oplossen. Indien nodig kan de rol van een van de interactieve applicaties worden vervuld door een persoon, waarbij handmatig berichten in het vereiste formaat worden ingevoerd.

In tegenstelling tot veel andere protocollen is HTTP een geheugenloos protocol. Dit betekent dat het protocol geen informatie opslaat over eerdere clientverzoeken en serverreacties. Componenten die HTTP gebruiken, kunnen onafhankelijk statusinformatie bijhouden die is gekoppeld aan de meest recente verzoeken en antwoorden. Een webclienttoepassing die verzoeken verzendt, kan bijvoorbeeld responsvertragingen bijhouden en een webserver kan de IP-adressen en verzoekheaders van recente clients opslaan.

Alle software voor het werken met het HTTP-protocol valt in drie hoofdcategorieën:

Servers- aanbieders van diensten voor het opslaan en verwerken van informatie (verwerkingsverzoeken).

Klanten- eindgebruikers van serverdiensten (verzenden van verzoeken).

Proxyservers om het werk van vervoersdiensten te ondersteunen.

Het "klassieke" HTTP-sessieschema ziet er als volgt uit.

Een TCP-verbinding tot stand brengen.

Klant verzoek.

Serverreactie.

Gebroken TCP-verbinding.

De client stuurt dus een verzoek naar de server, ontvangt er een reactie van, waarna de interactie wordt beëindigd. Gewoonlijk is een clientverzoek een verzoek om een ​​HTML-document of een andere bron te verzenden, en het antwoord van de server bevat de code voor die bron.

Het HTTP-verzoek dat van een client naar een server wordt verzonden, omvat de volgende componenten.

Statusbalk (soms worden de termen statusbalk of querystring ook gebruikt om het aan te duiden).

Koptekst velden.

Lege regel.

De hoofdtekst van het verzoek.

Statusbalk samen met koptekstvelden soms ook genoemd verzoek header.

Rijst. 1.1. Vraagstructuur van de klant.

Statusbalk heeft het volgende formaat:

request_method url_pecypca nttp_protocol_version

Laten we eens kijken naar de componenten van de statusbalk, met de nadruk op querymethoden.

Methode, gespecificeerd in de statusbalk, bepaalt hoe de bron kan worden beïnvloed, waarvan de URL in dezelfde regel wordt gespecificeerd. De methode kan de waarden GET, POST, HEAD, PUT, DELETE, etc. aannemen. Ondanks de overvloed aan methoden, zijn er slechts twee echt belangrijk voor een webprogrammeur: GET en POST.

KRIJGEN. Volgens de formele definitie is de GET-methode bedoeld om een ​​bron met de opgegeven URL te krijgen. Bij ontvangst van een GET-verzoek moet de server de gespecificeerde bron lezen en de bron-ID opnemen in het antwoord aan de client. De bron waarvan de URL wordt doorgegeven als onderdeel van het verzoek, hoeft geen HTML-pagina, afbeeldingsbestand of andere gegevens te zijn. De bron-URL kan verwijzen naar de uitvoerbare code van het programma, die, als aan bepaalde voorwaarden is voldaan, op de server moet worden uitgevoerd. In dit geval is het niet de programmacode die naar de client wordt teruggestuurd, maar de gegevens die tijdens de uitvoering worden gegenereerd. De GET-methode is per definitie bedoeld om informatie op te halen, maar kan ook voor andere doeleinden worden gebruikt. De GET-methode is heel geschikt voor het overbrengen van kleine stukjes gegevens naar de server.

NA. Volgens dezelfde formele definitie is het belangrijkste doel van de POST-methode het overbrengen van gegevens naar de server. De POST-methode kan echter, net als de GET-methode, op verschillende manieren worden gebruikt en wordt vaak gebruikt om informatie van een server op te halen. Net als bij de GET-methode verwijst de URL die is opgegeven in de statusbalk naar een specifieke bron. De POST-methode kan ook worden gebruikt om een ​​proces te starten.

De HEAD- en PUT-methoden zijn modificaties van de GET- en POST-methoden.

HTTP-protocolversie wordt meestal gegeven in het volgende formaat:

Http / versie.modificatie

Koptekstvelden door de statusbalk te volgen, kunt u uw zoekopdracht verfijnen, d.w.z. aanvullende informatie naar de server sturen. Het kopveld heeft het volgende formaat:

Veldnaam: Waarde

Het doel van een veld wordt bepaald door de naam, die door een dubbele punt van de waarde wordt gescheiden.

De namen van enkele van de meest voorkomende kopvelden in een klantverzoek en hun doel worden gegeven in: tabblad. 1.1.

In veel gevallen ontbreekt bij het werken op het web de hoofdtekst van het verzoek. Wanneer CGI-scripts worden uitgevoerd, kunnen de gegevens die in het verzoek aan hen worden doorgegeven, in de hoofdtekst van het verzoek worden geplaatst.

Hieronder ziet u een voorbeeld van een HTML-verzoek dat door de browser is gegenereerd:

GET http://oak.oakland.edu/ HTTP / 1.0

Verbinding: Keep-Alive

Gebruikersagent: Mozilla/4.04 (Win95; I)

Gastheer: eiken.oakland.edu

Accepteren: afbeelding / gif, afbeelding / x-xbitmap, afbeelding / jpeg, afbeelding / pjpeg, afbeelding / png, * / *

Accepteer-taal: en

Accept-tekenset: iso-8859-l, *, utf-8

Na een verzoek van de client te hebben ontvangen, moet de server hierop reageren. Voor de ontwikkelaar van webapplicaties is kennis van de structuur van de serverrespons noodzakelijk, aangezien de programma's die op de server draaien zelfstandig de respons naar de client moeten vormen.

Net als het verzoek van de client, bevat het antwoord van de server ook de vier onderstaande componenten.

Statusbalk.

Koptekst velden.

Lege regel.

Reactie lichaam.

De reactie van de server op de client begint met een statusregel, die de volgende indeling heeft:

Protocol_version Response_code Explanatory_message

Protocol_versie wordt gespecificeerd in hetzelfde formaat als in het verzoek van de klant en heeft dezelfde betekenis.

Reactiecode is een decimaal getal van drie cijfers dat het resultaat van het verwerken van het verzoek door de server heeft gecodeerd.

Explanatory_message dupliceert de antwoordcode in symbolische vorm. Dit is een tekenreeks die niet door de client wordt verwerkt. Het is bedoeld voor de systeembeheerder of operator die het systeem onderhoudt en is een decodering van de responscode.

Van de drie cijfers waaruit de responscode bestaat, definieert de eerste (hoogste) de responsklasse, de andere twee vertegenwoordigen het responsnummer binnen de klasse. Dus als het verzoek bijvoorbeeld met succes is verwerkt, ontvangt de klant het volgende bericht:

HTTP / 1.0 200 OK

Zoals u kunt zien, wordt de versie van het HTTP 1.0-protocol gevolgd door een code 200. In deze code betekent teken 2 een succesvolle verwerking van het verzoek van de klant, en de resterende twee cijfers (00) zijn het nummer van dit bericht.

In momenteel gebruikte HTTP-protocolimplementaties kan het eerste cijfer niet groter zijn dan 5 en definieert het de volgende responsklassen.

1 - een speciale klasse van berichten die informatief wordt genoemd. Een responscode die begint met 1 betekent dat de server het verzoek blijft verwerken. Bij het uitwisselen van gegevens tussen een HTTP-client en een HTTP-server worden berichten van deze klasse zelden gebruikt.

2 - succesvolle verwerking van de aanvraag van de klant.

3 - omleiding aanvragen. Er moeten aanvullende stappen worden ondernomen om aan het verzoek te voldoen.

4 - klantfout. Meestal wordt een responscode die begint met het cijfer 4 geretourneerd als er een syntaxisfout wordt aangetroffen in het verzoek van de client.

5 - Serverfout. Om de een of andere reden kan de server niet aan het verzoek voldoen.

Voorbeelden van responscodes die de client van de server kan ontvangen, en verklarende berichten worden gegeven in de tabel. 1.2.

Het antwoord gebruikt dezelfde kopveldstructuur als het clientverzoek. Headervelden zijn bedoeld om de reactie van de server op de client te verduidelijken. Een beschrijving van enkele van de velden die in de serverresponsheader kunnen worden gevonden, wordt gegeven in de tabel. 1.3.

De hoofdtekst van het antwoord bevat de code van de bron die als reactie op het verzoek aan de client is doorgegeven. Het hoeft niet de HTML-tekst van de webpagina te zijn. Als onderdeel van het antwoord kan een afbeelding, een audiobestand, een stukje video-informatie, evenals elk ander type gegevens dat door de klant wordt ondersteund, worden verzonden. De inhoud van het koptekstveld van het type Inhoud vertelt de klant hoe de ontvangen bron moet worden afgehandeld.

Hieronder ziet u een voorbeeld van een serverreactie op het verzoek dat in de vorige sectie is gegeven. De hoofdtekst van het antwoord bevat de originele tekst van het HTML-document.

Server: Microsoft-IIS / 5.1

X-aangedreven door: ASP.NET

Inhoudstype: tekst / html

Accept-bereiken: bytes

ETag: "b66a667f948c92: 8a5"

Inhoudslengte: 426

operand1:

operand2:

Operatie:

+

-

*

/

De kop- en hoofdtekstvelden van het bericht kunnen ontbreken, maar de statusbalk is vereist omdat deze het type verzoek/antwoord aangeeft.

Een veld met de naam Inhoudstype kan zowel in een clientverzoek als in een serverreactie voorkomen. De waarde van dit veld is opgegeven MIME-type van de inhoud van het verzoek of antwoord. MIME-type wordt ook doorgegeven in het veld Accept header dat aanwezig is in de aanvraag.

Specificatie MIME(Multipurpose Internet Mail Extension) is oorspronkelijk ontwikkeld om de overdracht van verschillende gegevensformaten als onderdeel van e-mails mogelijk te maken. Het gebruik van MIME is echter niet beperkt tot e-mail. MIME-tools worden met succes gebruikt op het WWW en zijn in feite een integraal onderdeel van dit systeem geworden.

Standaard MIME is ontworpen als een uitbreidbare specificatie, wat inhoudt dat het aantal gegevenstypen zal groeien naarmate de vormen van gegevenspresentatie evolueren. Elk nieuw type moet worden geregistreerd in de IANA(Internet Toegewezen Nummers Autoriteit).

voor de opkomst MIME computers die via het HTTP-protocol communiceren, wisselden uitsluitend tekstinformatie uit. Om afbeeldingen over te zetten, zoals bij elk ander binair bestand, moest je het FTP-protocol gebruiken.

Volgens specificatie: MIME, om het gegevensformaat te beschrijven, worden gebruikt een type en subtype. Een type bepaalt tot welke klasse het inhoudsformaat van een HTTP-verzoek of HTTP-antwoord behoort. Subtype geeft het formaat aan. Het type en subtype worden gescheiden door een schuine streep:

type / subtype

Aangezien in de overgrote meerderheid van de gevallen, in antwoord op het verzoek van een klant, de server de originele tekst van het HTML-document retourneert, bevat het veld Inhoudstype van het antwoord meestal de waarde text / html. Hier beschrijft de tekstidentificatie het type, wat aangeeft dat karakterinformatie aan de client wordt doorgegeven, en de html-identificatie beschrijft het subtype, d.w.z. geeft aan dat de tekenreeks in de antwoordtekst een HTML-documentbeschrijving is.

Lijst met typen en subtypen MIME groot genoeg. Tafel 1.4 zijn voorbeelden MIME-types, meestal te vinden in de headers van HTML-verzoeken en antwoorden.

Tabel 1.4. MIME-gegevenstypen.
Type / subtype	Bestandsextensie	Beschrijving
		Document te verwerken door Acrobat Reader
applicatie / msexcel		Microsoft Excel-document
toepassing / naschrift		PostScript-document
applicatie / x-tex		Document in TeX-formaat
applicatie / msword		Microsoft Word-document
		RTF-document weergegeven met Microsoft Word
		GIF-afbeelding
		JPEG-afbeelding
		TIFF-afbeelding
		XBitmap-afbeelding
		ASCII-tekst
		HTML-document
		Audiobestand in MIDI-formaat
		Audiobestand in WAV-formaat
		Mail bericht
		Posten in nieuwsgroepen
	Mpeg, .mpg, .mpe	Videofragment in MPEG-indeling
		Videofragment in AVI-indeling

Unieke URL-ID's worden gebruikt om bronnen op het web op unieke wijze te identificeren.

Een Uniform Resource Identifier (URI) is een korte reeks tekens die een abstracte of fysieke bron identificeert. De URI geeft niet aan hoe de bron kan worden verkregen, maar identificeert deze alleen. Dit maakt het mogelijk om met behulp van RDF (Resource Description Framework) bronnen te beschrijven die niet via internet kunnen worden verkregen (namen, titels, etc.). De bekendste voorbeelden van URI's zijn URL en URN.

URL(Uniform Resource Locator) is een URI die niet alleen een bron identificeert, maar ook informatie geeft over de locatie van die bron.

URN(Uniform Resource Name) is een URI die een resource in een specifieke naamruimte identificeert, maar in tegenstelling tot een URL geeft een URN niet de locatie van die resource aan.

De URL heeft de volgende structuur:

<схема>://<логин>:<пароль>@<хост>:<порт>/

schema- schema voor toegang tot een bron (meestal een netwerkprotocol);

Log in- gebruikersnaam die wordt gebruikt om toegang te krijgen tot de bron;

wachtwoord- het wachtwoord dat bij de opgegeven gebruikersnaam hoort;

gastheer- volledig geregistreerde domeinnaam van de host in het DNS-systeem of IP-adres van de host;

haven- hostpoort voor verbinding;

URL-pad- verduidelijking van informatie over de locatie van de bron.

Gebruik van client-servertechnologie

In de loop van de tijd werd het niet erg functionele model van de bestandsserver voor lokale netwerken (FS) vervangen door het steeds meer opkomende model van de "Client Server"-structuur (RDA, DBS en AS).

De client-servertechnologie, die helemaal onderaan de database stond, is de belangrijkste technologie van het wereldwijde internet geworden. Verder ontstond de intranettechnologie als gevolg van de overdracht van de ideeën van internet naar de sfeer van bedrijfssystemen. In tegenstelling tot de "Client-Server"-technologie is deze technologie gericht op informatie in zijn uiteindelijke vorm voor consumptie, en niet op gegevens. Computersystemen, die zijn gebouwd op basis van het intranet, bevatten centrale informatieservers en bepaalde componenten voor het presenteren van informatie aan de laatste gebruiker (browsers of navigators). De actie tussen de server en de client in het intranet gebeurt met behulp van webtechnologieën.

In moderne tijden is de Client-Server-technologie zeer wijdverbreid geworden, maar deze technologie zelf heeft geen universele recepten. Het geeft slechts een algemeen oordeel over hoe het huidige distributie-informatiesysteem tot stand moet komen. Ook de implementatie van deze technologie in bepaalde softwareproducten en zelfs in soorten software wordt zeer sterk erkend.

Klassieke two-tier client-server-architectuur

Netwerkcomponenten hebben in de regel geen gelijke rechten: sommige hebben toegang tot bronnen (bijvoorbeeld: databasebeheersysteem, processor, printer, bestandssysteem, enz.), andere hebben toegang tot deze bronnen. besturingssysteem servertechnologie

"Client-server"-technologie is een architectuur van een softwarepakket dat een toepassingsprogramma verdeelt in twee logisch verschillende delen (server en client), die op elkaar inwerken volgens het "request-response"-schema en hun eigen specifieke taken oplossen.

Het programma (of computer) dat een bron beheert en/of bezit, wordt de server van deze bron genoemd.

Een programma (computer of) dat een bron aanvraagt ​​en gebruikt, wordt een client van die bron genoemd.

In dit geval kunnen dergelijke omstandigheden ook optreden wanneer een programma-eenheid gelijktijdig de functies van de server zal implementeren met betrekking tot één eenheid en de client met betrekking tot een andere eenheid.

Het belangrijkste principe van de Client-Server-technologie is om de applicatiefuncties in ten minste drie links te verdelen:

Gebruikersinterfacemodules;

Deze groep wordt ook wel presentatielogica genoemd. Met zijn hulp kunnen gebruikers communiceren met applicaties. Ongeacht de specifieke kenmerken van de presentatielogica (opdrachtregelinterface, intermediaire interfaces, complexe grafische gebruikersinterfaces), is het doel ervan een middel te bieden voor een efficiëntere informatie-uitwisseling tussen het informatiesysteem en de gebruiker.

Gegevensopslagmodules;

Deze groep wordt ook wel bedrijfslogica genoemd. Bedrijfslogica vindt waar een applicatie precies voor nodig is (bijvoorbeeld applicatiefuncties die inherent zijn aan het opgegeven domein). Het scheiden van een applicatie langs programmagrenzen biedt een natuurlijke basis voor het distribueren van een applicatie over twee of meer computers.

Gegevensverwerkingsmodules (resourcebeheerfuncties);

Deze groep wordt ook wel logische datatoegangsalgoritmen of simpelweg datatoegang genoemd. Algoritmen voor het invoeren van gegevens worden beschouwd als een specifieke interface voor een specifieke toepassing naar een apparaat voor stabiele gegevensopslag zoals een DBMS of een bestandssysteem. Met behulp van dataverwerkingsmodules wordt een specifieke interface voor een DBMS-applicatie georganiseerd. Met behulp van de interface kan een toepassing databaseverbindingen en -query's beheren (toepassingsspecifieke query's vertalen naar SQL, resultaten ophalen en die resultaten weer vertalen naar toepassingsspecifieke gegevensstructuren). Elk van de vermelde koppelingen kan onafhankelijk van verschillende andere worden gerealiseerd. Zonder de programma's te wijzigen die worden gebruikt om gegevens te verwerken en op te slaan, kunt u bijvoorbeeld de gebruikersinterface wijzigen zodat dezelfde gegevens worden weergegeven in de vorm van tabellen, histogrammen of grafieken. De eenvoudigste toepassingen zijn vaak in staat om alle drie de koppelingen in een enkel programma samen te voegen, en deze scheiding volgt functionele grenzen.

In overeenstemming met de functiescheiding worden in elke toepassing de volgende componenten onderscheiden:

• - datapresentatiecomponent;
• - applicatiecomponent;
• - component voor resourcebeheer.

De client-server in de klassieke architectuur moet de drie hoofdonderdelen van de applicatie verdelen in 2 fysieke modules. Gewoonlijk bevindt de toepassingscomponent zich op de server (bijvoorbeeld op de databaseserver), bevindt de gegevenspresentatiecomponent zich aan de clientzijde en wordt de resourcebeheercomponent verdeeld tussen de server- en clientgedeelten. Dit is het grootste nadeel van de klassieke two-tier architectuur.

In een tweeledige architectuur moeten ontwikkelaars, bij het scheiden van gegevensverwerkingsalgoritmen, volledige informatie hebben over de laatste wijzigingen die in het systeem zijn aangebracht en deze wijzigingen begrijpen, wat niet geringe problemen veroorzaakt bij de ontwikkeling van client-serversystemen, hun onderhoud en installatie, aangezien het nodig is om grote inspanningen te leveren om de acties van verschillende groepen specialisten te coördineren. In de acties van ontwikkelaars ontstaan ​​​​vaak tegenstrijdigheden, en dit vertraagt ​​​​de ontwikkeling van het systeem en dwingt je om reeds kant-en-klare en bewezen elementen te veranderen.

Om de inconsistentie van verschillende elementen van de architectuur te vermijden, hebben we twee wijzigingen aangebracht in de tweeledige architectuur "Client-Server": "Fat Client" ("Thin Server") en "Thin Client" ("Fat Server").

In deze architectuur probeerden de ontwikkelaars gegevensverwerking uit te voeren op een van de twee fysieke onderdelen - ofwel aan de clientzijde ("Thick client") of op de server ("Thin client").

Elke benadering heeft belangrijke nadelen. In de eerste situatie is het netwerk onterecht overbelast, omdat er onverwerkte, dat wil zeggen redundante gegevens over worden verzonden. Bovendien wordt de systeemondersteuning en de wijziging ervan gecompliceerder, omdat het oplossen van een fout of het vervangen van het berekeningsalgoritme de gelijktijdige volledige vervanging van alle interfaceprogramma's vereist. Als een volledige vervanging niet wordt uitgevoerd, kunnen er inconsistenties in de gegevens of fouten optreden. Als alle informatieverwerking op de server wordt uitgevoerd, ontstaat het probleem van het beschrijven van de ingebouwde procedures en hun foutopsporing. Een systeem met informatieverwerking op een server is absoluut onmogelijk over te zetten naar een ander platform (OS), dit is een serieus nadeel.

Als u een klassieke architectuur met twee niveaus "Client-Server" maakt, moet u de volgende feiten weten:

Thick Server-architectuur is vergelijkbaar met Thin Client-architectuur

Het verzenden van een verzoek van de client naar de server, het verwerken van het verzoek door de server en het doorgeven van het resultaat aan de client. De architecturen hebben echter de volgende nadelen:

• - de implementatie wordt ingewikkelder, aangezien talen zoals SQL niet zijn aangepast voor de ontwikkeling van dergelijke software en er geen goede debugging-tools zijn;
• - de prestaties van programma's die zijn geschreven in talen zoals SQL zijn erg laag dan die in andere talen, wat het belangrijkst is voor complexe systemen;
• - programma's die in DBMS-talen zijn geschreven, functioneren in de regel gedeeltelijk niet erg betrouwbaar; een fout daarin kan leiden tot het uitvallen van de hele databaseserver;
• - de resulterende programma's zijn volledig niet-overdraagbaar naar andere platforms en systemen.
• - architectuur "Thick client" is vergelijkbaar met architectuur "Thin server"

De verwerking van verzoeken vindt plaats aan de clientzijde, dat wil zeggen dat alle onbewerkte gegevens van de server naar de client worden overgedragen. In dit geval hebben de architecturen negatieve kanten:

• - de software-update wordt ingewikkelder, omdat deze door het hele systeem tegelijk moet worden vervangen;
• - de bevoegdheidsverdeling wordt ingewikkelder, omdat de differentiatie van toegang niet gebeurt volgens handelingen, maar volgens tabellen;
• - het netwerk is overbelast door de overdracht van ruwe data erover;
• - zwakke gegevensbescherming, aangezien het moeilijk is om bevoegdheden goed te verdelen.

Om de genoemde problemen op te lossen, is het noodzakelijk om een ​​client-server-architectuur op meerdere niveaus (drie of meer niveaus) te gebruiken.

Model met drie niveaus .

Sinds het midden van de jaren 90 van de vorige eeuw is de populariteit van specialisten toegenomen door de drieledige client-server-architectuur, die het informatiesysteem op functionaliteit in drie secties verdeelde: datatoegangslogica, presentatielogica en bedrijfslogica. In tegenstelling tot de architectuur met twee lagen, heeft de architectuur met drie lagen een extra laag: een applicatieserver die is ontworpen om bedrijfslogica te implementeren, terwijl de client die verzoeken naar middleware verzendt, volledig wordt ontlast en alle mogelijkheden van de servers worden gemaximaliseerd.

In een drieledige architectuur wordt de client in de regel niet overladen met gegevensverwerkingsfuncties, maar vervult hij zijn hoofdrol als systeem voor het presenteren van informatie van de applicatieserver. Een dergelijke interface kan worden afgedwongen met behulp van standaard webtechnologietools - browser, CGI en Java. Dit vermindert de hoeveelheid gegevens die tussen de client en de toepassingsserver wordt geleverd, waardoor clientcomputers zelfs via langzame lijnen, zoals telefoonlijnen, kunnen worden aangesloten. Als zodanig kan de clientzijde zo eenvoudig zijn dat het in de meeste gevallen wordt gedaan met behulp van een generieke browser. Als u het echter nog moet wijzigen, kan deze procedure snel en pijnloos worden uitgevoerd.

Een applicatieserver is software die een tussenlaag vormt tussen de server en de client.

• - Bericht georiënteerd - heldere vertegenwoordigers van MQseries en JMS;
• - Object Broker - slimme vertegenwoordigers van CORBA en DCOM;
• - Component gebaseerd - heldere vertegenwoordigers van .NET en EJB.

Het gebruik van een applicatieserver brengt veel meer functies met zich mee, zo wordt de belasting van clientcomputers verminderd, omdat de applicatieserver de belasting verdeelt en bescherming biedt tegen storingen. Aangezien de bedrijfslogica is opgeslagen op de applicatieserver, hebben eventuele wijzigingen in rapportage of berekeningen op geen enkele manier invloed op de clientprogramma's.

Er zijn maar weinig applicatieservers van bekende bedrijven als Sun, Oracle Microsystem, IBM, Borland, en elk van hen verschilt in de reeks geleverde services (in dit geval zal ik geen rekening houden met de prestaties). Deze services maken het gemakkelijk om bedrijfsbrede applicaties te programmeren en te implementeren. Doorgaans biedt de toepassingsserver de volgende services:

• - WEB Server - bevat meestal de meest krachtige en populaire Apache;
• - WEB Container - hiermee kunt u JSP en servlets uitvoeren. Voor Apache is dit Tomcat;
• - CORBA-agent - kan een gedistribueerde map bieden voor het opslaan van CORBA-objecten;
• - Berichtenservice - berichtenmakelaar;
• - Transactieservice - al uit de naam is duidelijk dat dit een transactieservice is;
• - JDBC - stuurprogramma's voor verbinding met databases, omdat het de applicatieserver is die met de databases moet communiceren en verbinding moet kunnen maken met de database die in uw bedrijf wordt gebruikt;
• - Java Mail - deze service kan service verlenen aan SMTP;
• - JMS (Java Messaging Service) - verwerking van synchrone en asynchrone berichten;
• - RMI (Remote Method Invocation) - bel procedures op afstand.

Multi-tier client/server-systemen kunnen eenvoudig worden vertaald naar webtechnologie - hiervoor moet u het clientgedeelte vervangen door een gespecialiseerde of universele browser en de applicatieserver aanvullen met een webserver en kleine serverprocedure-aanroepprogramma's. Voor

Deze programma's kunnen worden ontwikkeld met zowel de Common Gateway Interface (CGI) als de modernere Java-technologie.

In een systeem met drie niveaus kunnen de snelste lijnen die minimale kosten vereisen, worden gebruikt als communicatiekanalen tussen de applicatieserver en het DBMS, aangezien de servers zich meestal in dezelfde ruimte (serverruimte) bevinden en het netwerk niet overbelasten door de overdracht van een grote hoeveelheid informatie.

Uit al het bovenstaande volgt dat de two-tier-architectuur erg inferieur is aan de multi-tier-architectuur. In dit opzicht wordt vandaag alleen de multi-tier client-server-architectuur gebruikt, die drie wijzigingen herkent: RDA, DBS en ALS.

Verschillende modellen van "Client-server"-technologie

De allereerste fundamentele onderliggende technologie voor lokale netwerken was: bestandsservermodel (FS)... In die tijd was deze technologie heel gebruikelijk bij binnenlandse ontwikkelaars die systemen gebruikten zoals FoxPro, Clipper, Clarion, Paradox, enzovoort.

In het FS-model zijn de functies van alle 3 componenten (presentatiecomponent, applicatiecomponent en resourcetoegangscomponent) gecombineerd in één code, die wordt uitgevoerd op de servercomputer (host). Er is helemaal geen clientcomputer in deze architectuur en de weergave en presentatie van gegevens wordt uitgevoerd met behulp van een computercomputer of een terminal in de volgorde van terminalemulatie. Applicaties zijn meestal geschreven in de vierde generatie taal (4GL). Een van de computers op het netwerk wordt beschouwd als een bestandsserver en biedt andere computers bestandsverwerkingsservices. Het werkt onder de controle van een netwerkbesturingssysteem en speelt een belangrijke rol als onderdeel van de toegang tot informatiebronnen. Op andere pc's in het netwerk draait een applicatie, in de codes waarvan de applicatiecomponent en de presentatiecomponent zijn verbonden.

De technologie van actie tussen de client en de server is als volgt: het verzoek wordt verzonden naar de bestandsserver, die het vereiste gegevensblok verzendt naar het DBMS dat zich op de clientcomputer bevindt. Alle verwerking gebeurt op de terminal.

Een uitwisselingsprotocol is een reeks aanroepen die een toepassing toegang geven tot het bestandssysteem op een bestandsserver.

De positieve aspecten van deze technologie zijn:

• - gemak van applicatie-ontwikkeling;
• - gemak van beheer en software-updates
• - lage kosten voor het uitrusten van werkplekken (terminals of goedkope computers met lage kenmerken in terminalemulatiemodus zijn altijd goedkoper dan volwaardige pc's).

Maar de voordelen van het FS-model overtreffen de nadelen:

Ondanks de grote hoeveelheid gegevens die via het netwerk wordt verzonden, is de responstijd van cruciaal belang, omdat elk teken dat door de client op de terminal wordt ingevoerd, naar de server moet worden verzonden, door de toepassing moet worden verwerkt en moet worden teruggestuurd om op het scherm van de terminal te worden weergegeven . Daarnaast is er het probleem van het verdelen van de belasting over meerdere computers.

• - dure serverhardware aangezien alle gebruikers zijn bronnen delen;
• - gebrek aan een grafische interface .

Dankzij de oplossing van de problemen die inherent zijn aan de "File - Server"-technologie, is er een meer vooruitstrevende technologie verschenen, genaamd "Client - Server".

Voor moderne DBMS is de client-server-architectuur de de facto standaard geworden. Als wordt aangenomen dat de geprojecteerde netwerktechnologie een "client-server"-architectuur zal hebben, betekent dit dat de toepassingsprogramma's die binnen het kader ervan worden geïmplementeerd, een gedistribueerd karakter zullen hebben, dat wil zeggen dat sommige van de toepassingsfuncties in de client zullen worden geïmplementeerd programma, de andere in de programma-server.

Verschillen in de implementatie van applicaties binnen de Client-Server technologie worden bepaald door vier factoren:

• - welke soorten software in logische componenten;
• - welke softwaremechanismen worden gebruikt om de functies van logische componenten te implementeren;
• - hoe logische componenten worden gedistribueerd door computers op het netwerk;
• - welke mechanismen worden gebruikt om de componenten aan elkaar te koppelen.

Op basis hiervan worden drie benaderingen onderscheiden, die elk worden geïmplementeerd in het bijbehorende model van de Client-Server-technologie:

• - model van toegang tot gegevens op afstand (Remote Date Access - RDA);
• - databaseservermodel (DateBase Server - DBS);
• - het model van de applicatieserver (Application Server - AS).

Een belangrijk voordeel van het RDA-model is het brede scala aan applicatie-ontwikkeltools die zorgen voor de snelle vorming van desktopapplicaties die werken met SQL-georiënteerde DBMS'en. Doorgaans ondersteunen de tools een grafische gebruikersinterface met een besturingssysteem, evenals automatische codegeneratie, waarbij presentatie- en applicatiefuncties worden gemengd.

Ondanks de brede verspreiding maakt het RDA-model plaats voor het technologisch meest geavanceerde DBS-model.

Databaseservermodel (DBS) - netwerkarchitectuur van de "Client - Server"-technologie, die is gebaseerd op het mechanisme van opgeslagen procedures die toepassingsfuncties implementeren. In het DBS-model wordt het concept van een informatiebron gecomprimeerd tot een database vanwege hetzelfde mechanisme van opgeslagen procedures, geïmplementeerd in het DBMS, en zelfs dan niet in alle.

De voordelen van het DBS-model ten opzichte van het RDA-model liggen voor de hand: het is zowel de mogelijkheid van gecentraliseerd beheer van verschillende functies als de vermindering van netwerkverkeer omdat in plaats van SQL-query's, aanroepen van opgeslagen procedures over het netwerk worden verzonden, en de mogelijkheid van het splitsen van een procedure tussen twee toepassingen en het besparen van computerbronnen voor het gebruik van het eenmaal gemaakte plan voor de uitvoering van de procedure.

Toepassingsserver (AS)-model is een netwerkarchitectuur van de Client-Server-technologie, een proces dat wordt uitgevoerd op een clientcomputer en verantwoordelijk is voor de gebruikersinterface (gegevensinvoer en -weergave). Het belangrijkste element van een dergelijk model is de applicatiecomponent, de applicatieserver genoemd, die op een externe computer (of twee computers) werkt. De applicatieserver is geïmplementeerd als een groep applicatiefuncties, ontworpen in de vorm van services (services). Elke dienst levert een aantal diensten aan alle programma's die ze willen en kunnen gebruiken.

Nadat we alle modellen van de Client-Server-technologie hebben geleerd, kunnen we de volgende conclusie trekken: RDA- en DBS-modellen, deze twee modellen zijn gebaseerd op een systeem voor het delen van functies op twee niveaus. In het RDA-model worden applicatiefuncties overgedragen aan de client; in het DBS-model wordt hun uitvoering geïmplementeerd via de DBMS-kernel. In het RDA-model is de applicatiecomponent samengevoegd met de presentatiecomponent, in het DBS-model is deze geïntegreerd in de resourcetoegangscomponent.

Het AS-model implementeert een schema met drie niveaus van scheiding van functies, waarbij de applicatiecomponent is geïsoleerd als het belangrijkste geïsoleerde element van de applicatie, die gestandaardiseerde interfaces heeft met twee andere componenten.

De resultaten van de analyse van de modellen van technologieën "File Server" en "Client - Server" worden weergegeven in tabel 1.

Ondanks zijn naam is de Client-Server-technologie ook een gedistribueerd computersysteem. In dit geval gedistribueerd computergebruik wordt opgevat als een client-server-architectuur met de deelname van sommige servers. In de context van gedistribueerde verwerking betekent de term "server" eenvoudig een programma dat reageert op verzoeken en de nodige acties uitvoert op verzoek van de klant. Omdat Grid Computing een soort client-serversysteem is, ervaren gebruikers dezelfde voordelen, zoals een grotere totale bandbreedte en de mogelijkheid om te multitasken. Ook het integreren van discrete netwerkcomponenten en deze als één geheel laten werken, draagt ​​bij aan verhoogde efficiëntie en verminderde besparingen.

Omdat verwerking overal op het netwerk plaatsvindt, zorgt gedistribueerd computergebruik in een client-server-architectuur voor efficiënte schaalbaarheid. Om een ​​balans tussen server en client te bereiken, mag een applicatiecomponent alleen op de server plaatsvinden als centrale verwerking efficiënter is. Als de logica van het programma dat in wisselwerking staat met de gecentraliseerde gegevens geconcentreerd is op dezelfde machine als de gegevens, hoeft het niet via het netwerk te worden verzonden, zodat de vereisten voor de netwerkomgeving kunnen worden verminderd.

Als resultaat kan de volgende conclusie worden getrokken: als u met kleine informatiesystemen moet werken die geen grafische gebruikersinterface nodig hebben, kunt u het FS-model gebruiken. De kwestie van de GUI kan vrij worden opgelost met behulp van het RDA-model. DBS-model is een zeer goede optie voor databasebeheersystemen (DBMS). Het AS-model is de beste optie voor het maken van grote informatiesystemen, maar ook voor het gebruik van communicatiekanalen met een lage snelheid.

Ministerie van Algemeen en Beroepsonderwijs van de regio Bryansk

Staatsonderwijsinstelling

Textielcollege Klintsovsky

GEAUTOMATISEERDE INFORMATIESYSTEMEN SOFTWARE

Client-servertechnologie

Student gr. A-90 ______________________ (Petrochenko AO)

Leraar _______________________ (Shirokova A.L.)

Klintsy - 2011

1. Servers. Basisconcepten voor servers

2. Client-servermodel

3. Classificatie van standaardservers

4. Gevolgtrekking

1. Servers. Basisconcepten voor servers

Server (van de Engelse server, serveren). Afhankelijk van het doel zijn er verschillende definities van het begrip server.

1. Server (netwerk) - een logisch of fysiek netwerkknooppunt dat verzoeken aan één adres en/of domeinnaam (aangrenzende domeinnamen) verstuurt, bestaande uit één of een systeem van hardwareservers waarop één of een systeem van serverprogramma's draait

2. Server (software) - software die verzoeken van clients ontvangt (in client-server-architectuur).

3. Server (hardware) - een computer (of speciale computerapparatuur) die speciaal en/of gespecialiseerd is om bepaalde servicefuncties uit te voeren.

3. Server in informatietechnologie - een softwarecomponent van een computersysteem dat op verzoek van een klant servicefuncties uitvoert en hem toegang geeft tot bepaalde bronnen.

Interrelatie van concepten. Een servertoepassing (server) draait op een computer, ook wel een "server" genoemd, terwijl gezien de netwerktopologie een dergelijk knooppunt een "server" wordt genoemd. In het algemeen kan het zijn dat een servertoepassing op een normaal werkstation draait, of dat een servertoepassing die in het kader van de beschouwde topologie op een servercomputer draait, als client optreedt (dwz geen server is in termen van netwerk topologie).

2. Het client-servermodel

Een client-serversysteem wordt gekenmerkt door de aanwezigheid van twee met elkaar samenwerkende onafhankelijke processen - een client en een server, die in het algemeen op verschillende computers kunnen worden uitgevoerd en gegevens via het netwerk kunnen uitwisselen.

Processen die een service implementeren, zoals een bestandssysteem of databaseservice, worden genoemd servers(servers). Processen die services van servers aanvragen door een aanvraag te verzenden en vervolgens te wachten op een reactie van de server, worden aangeroepen klanten(klanten).

Volgens dit schema kunnen op DBMS gebaseerde gegevensverwerkingssystemen, post- en andere systemen worden gebouwd. We zullen het hebben over databases en systemen die daarop zijn gebaseerd. En hier is het handiger om niet alleen de client-server-architectuur te beschouwen, maar deze ook te vergelijken met een andere - file-server-architectuur.

In een bestandsserversysteem worden gegevens opgeslagen op een bestandsserver (bijvoorbeeld Novell NetWare of Windows NT Server) en wordt de verwerking uitgevoerd op werkstations, die in de regel een van de zogenaamde "desktop-DBMS " - Toegang, FoxPro, Paradox, enz.

Een applicatie op een werkstation is "verantwoordelijk voor alles" - voor de vorming van de gebruikersinterface, logische verwerking van gegevens en voor de directe manipulatie van gegevens. De bestandsserver biedt alleen services op het laagste niveau - bestanden openen, sluiten en wijzigen. Let op: bestanden, geen databases. Het databasebeheersysteem bevindt zich op het werkstation.

Er zijn dus verschillende onafhankelijke en inconsistente processen betrokken bij directe gegevensmanipulatie. Bovendien moeten voor elke verwerking (zoeken, wijzigen, optellen, enz.) alle gegevens via het netwerk van de server naar het werkstation worden verzonden ( zie afb. Vergelijking van file-server en client-server modellen)

Rijst. Vergelijking van bestandsserver- en client-servermodellen

In een client-serversysteem zijn er (minstens) twee applicaties - een client en een server, die onderling de functies delen die een applicatie op een werkstation volledig in de file-server-architectuur uitvoert. De opslag en directe manipulatie van gegevens wordt afgehandeld door een databaseserver, die Microsoft SQL Server, Oracle, Sybase, enz. kan zijn.

De gebruikersinterface wordt gevormd door de client, waarvoor u een aantal speciale tools kunt gebruiken, evenals de meeste desktop-DBMS. De logica voor gegevensverwerking kan zowel op de client als op de server worden uitgevoerd. De client stuurt queries naar de server, meestal geformuleerd in SQL. De server verwerkt deze verzoeken en stuurt het resultaat naar de client (er kunnen natuurlijk veel clients zijn).

Er is dus één proces betrokken bij directe gegevensmanipulatie. Tegelijkertijd vindt de gegevensverwerking plaats op dezelfde plaats waar de gegevens zijn opgeslagen - op de server, waardoor er geen grote hoeveelheden gegevens via het netwerk hoeven te worden verzonden.

Wat levert de client-server-architectuur op?

Laten we deze architectuur eens bekijken vanuit het oogpunt van zakelijke behoeften. Welke kwaliteiten voegt de client-server toe aan het informatiesysteem?

Betrouwbaarheid

De databaseserver voert gegevenswijzigingen uit op basis van het transactiemechanisme, dat elke reeks bewerkingen die als transactie zijn gedeclareerd, de volgende eigenschappen geeft:

• atomiciteit- onder alle omstandigheden zullen ofwel alle operaties van de transactie worden uitgevoerd, ofwel geen enkele; gegevensintegriteit aan het einde van een transactie;
• onafhankelijkheid- transacties geïnitieerd door verschillende gebruikers interfereren niet met elkaars zaken;
• fouttolerantie:- na de voltooiing van de transactie gaan de resultaten ervan niet verloren.

Het transactiemechanisme dat door de databaseserver wordt ondersteund, is veel efficiënter dan zijn tegenhanger in desktop-DBMS'en omdat het: de server regelt centraal de werking van transacties. Bovendien kan in het file-serversysteem een ​​storing op een van de werkstations leiden tot gegevensverlies en hun ontoegankelijkheid voor andere werkstations, terwijl in het client-serversysteem een ​​storing op de client praktisch nooit de gegevensintegriteit en hun beschikbaarheid voor andere klanten.

schaalbaarheid

Schaalbaarheid - het vermogen van het systeem om zich aan te passen aan de groei van het aantal gebruikers en het volume van de database met een adequate toename van de prestaties van het hardwareplatform, zonder de software te vervangen.

Het is bekend dat de mogelijkheden van desktop-DBMS ernstig beperkt zijn - dit zijn respectievelijk vijf tot zeven gebruikers en 30-50 MB. De getallen vertegenwoordigen natuurlijk enkele gemiddelde waarden; in specifieke gevallen kunnen ze zowel in de ene als in de andere richting afwijken. Het belangrijkste is dat deze barrières niet kunnen worden overwonnen door hardwaremogelijkheden op te bouwen.

Databaseserversystemen kunnen duizenden gebruikers en honderden GB's aan informatie ondersteunen - geef ze gewoon het juiste hardwareplatform.

Veiligheid

De databaseserver biedt krachtige gegevensbescherming tegen onbevoegde toegang die niet mogelijk is met desktop-DBMS. Tegelijkertijd worden toegangsrechten zeer flexibel beheerd - tot op het niveau van tabelvelden. Bovendien kunt u in het algemeen directe toegang tot tabellen verbieden door gebruikersinteractie met gegevens uit te voeren via tussenliggende objecten - weergaven en opgeslagen procedures. De beheerder kan er dus zeker van zijn dat geen al te slimme gebruiker zal lezen wat hij niet zou moeten lezen.

Flexibiliteit

Er zijn drie logische lagen in een datatoepassing:

• gebruikersomgeving ;
• logische verwerkingsregels(bedrijfsregels);
• gegevensbeheer(Verwar logische lagen niet met fysieke lagen, die hieronder worden besproken).

Zoals eerder vermeld, worden in een bestandsserverarchitectuur alle drie de lagen geïmplementeerd in een enkele monolithische toepassing die op een werkstation draait. Daarom leiden wijzigingen in een van de lagen ondubbelzinnig tot de wijziging van de applicatie en de daaropvolgende update van de versies op werkstations.

In de tweeledige client-servertoepassing die in de bovenstaande afbeelding wordt getoond, worden in de regel alle functies voor het vormen van de gebruikersinterface op de client geïmplementeerd, zijn alle gegevensbeheerfuncties op de server, maar bedrijfsregels kunnen worden geïmplementeerd zoals op de server met behulp van de serverprogrammeermechanismen (opgeslagen procedures, triggers, views, enz.) en op de client.

In een applicatie met drie niveaus verschijnt een derde, tussenniveau dat bedrijfsregels implementeert, de meest gewijzigde applicatiecomponenten ( zie afb. Drielaags client-server-toepassingsmodel)

Rijst. Drielaags client-server-toepassingsmodel

De aanwezigheid van niet één, maar meerdere niveaus stelt u in staat om de applicatie flexibel en kosteneffectief aan te passen aan veranderende zakelijke vereisten.

Laten we proberen al het bovenstaande te illustreren met een klein voorbeeld. Stel dat een organisatie haar salarisregels (bedrijfsregels) heeft gewijzigd en haar software moet updaten.

1) In een bestandsserversysteem brengen we "gewoon" wijzigingen aan in de applicatie en werken de versies bij op werkstations. Maar dit brengt "slechts" maximale arbeidskosten met zich mee.

2) In een client-serversysteem met twee niveaus, als het salarisalgoritme op de server is geïmplementeerd in de vorm van een salarisregel, wordt het uitgevoerd door de bedrijfsregelsserver, bijvoorbeeld uitgevoerd in de vorm van een OLE-server , en we zullen een van zijn objecten bijwerken zonder iets te veranderen, noch in de clienttoepassing, noch op de databaseserver.

Client-servertechnologieën

Vrijwel alle modellen voor het organiseren van gebruikersinteractie met een database zijn gebaseerd op client-servertechnologie. Aangenomen wordt dat elk van deze toepassingen verschilt in de manier waarop functies worden verdeeld: het clientgedeelte is verantwoordelijk voor de gerichte verwerking van gegevens en de organisatie van de interactie met de gebruiker, het servergedeelte zorgt voor gegevensopslag - verwerkt verzoeken en stuurt de resultaten naar de klant voor speciale verwerking. Een typische architectuur van client-servertechnologie wordt getoond in Fig. 4.1:

Rijst. 4.1. Typische architectuur van client-servertechnologie

Een deel van de functies van de centrale computers werd overgenomen door lokale computers. In dit geval wordt elke softwaretoepassing vertegenwoordigd door drie componenten: een presentatiecomponent die een interface met de gebruiker implementeert; een applicatiecomponent die voorziet in de implementatie van applicatiefuncties; onderdeel van toegang tot informatiebronnen (resourcemanager), het uitvoeren van informatieaccumulatie en gegevensbeheer.

Op basis van de verdeling van deze componenten tussen een werkstation en een netwerkserver worden de volgende modellen van de "client-server"-architectuur onderscheiden:

· Model van toegang tot gegevens op afstand (Fig. 4.2). De server bevat alleen gegevens:

Rijst. 4.2. Model voor gegevenstoegang op afstand

Dit model wordt gekenmerkt door lage prestaties, aangezien alle informatie op werkstations wordt verwerkt; daarnaast wordt een lage wisselkoers ondersteund bij het overbrengen van grote hoeveelheden informatie van een server naar werkstations;

Model databeheerserver (fig. 4.3):

Rijst. 4.3. Model gegevensbeheerserver

Kenmerken van dit model: vermindering van de hoeveelheid informatie die via het netwerk wordt verzonden, aangezien de selectie van de benodigde informatie-elementen op de server wordt uitgevoerd en niet op werkstations; unificatie en een breed scala aan tools voor het maken van applicaties; het ontbreken van een duidelijk onderscheid tussen de presentatiecomponent en de applicatiecomponent, waardoor het moeilijk is om het computersysteem te verbeteren. Het is raadzaam om bij het verwerken van matige hoeveelheden informatie te werken, terwijl de complexiteit van de toegepaste component laag moet zijn,

· Model van een complexe server (fig. 4.4):

Rijst. 4.4. Complex servermodel

Voordelen van het model: hoge prestaties, gecentraliseerd beheer, besparing van netwerkbronnen. Zo'n server is optimaal voor grote netwerken die gericht zijn op het verwerken van grote en toenemende hoeveelheden informatie in de loop van de tijd;

· Drielaagse architectuur "client-server" (Fig. 4.5). Het wordt gebruikt bij het compliceren en verhogen van de resource-intensiteit van de applicatiecomponent.

Rijst. 4.5. Architectuur met drie niveaus

Verschillende applicatiefuncties kunnen in de applicatieserver worden geïmplementeerd, die elk zijn ontworpen als een afzonderlijke service die bepaalde services aan alle programma's levert. Er kunnen meerdere van dergelijke servers zijn, elk van hen is gericht op het leveren van een bepaalde reeks services. Deze architectuur is gebaseerd op verdere specialisatie van architectuurcomponenten: de klant houdt zich alleen bezig met het organiseren van de interface met de gebruiker, de databaseserver voert alleen standaard gegevensverwerking uit, om de gegevensverwerkingslogica te implementeren, de architectuur biedt een aparte laag - een laag van bedrijfslogica, het kan een dedicated server zijn (toepassingsserver) of op de client worden gehost als een bibliotheek.

Binnen de client-server-architectuur zijn er twee basisconcepten:

· "dunne" cliënt. Een krachtige databaseserver en een bibliotheek met opgeslagen procedures worden gebruikt om berekeningen te maken die de hoofdlogica van gegevensverwerking direct op de server implementeren. De client-applicatie stelt dan ook weinig eisen aan de hardware van het werkstation;

· Een "dikke" client implementeert de belangrijkste verwerkingslogica op de client en de server is een pure databaseserver die alleen standaardverzoeken voor gegevensmanipulatie uitvoert (in de regel lezen, schrijven, wijzigen van gegevens in relationele databasetabellen).

Netwerk IT

E-mail... De allereerste, deze vorm van elektronisch berichtenverkeer (e-mail) demonstreerde de mogelijkheid van bijna onmiddellijke communicatie via computernetwerken. Architectonisch bedoeld voor de uitwisseling van berichten tussen twee abonnees, stelde het groepen mensen in staat om informatie uit te wisselen. Groepen of mailinglijsten werden zo'n wijziging. Met e-mailsoftware kunt u e-mailberichten maken en bijvoegen. De bijlagefunctie wordt gebruikt om documenten van elk type per post te verzenden, zoals tekstdocumenten, spreadsheets, multimediabestanden, databasebestanden, enz. Later ontwikkelde tekstfiltersoftware breidde de mogelijkheden van e-mail uit om de gebruiker te helpen bij het structureren, sturen en filteren van berichten. De behoefte aan deze diensten is te wijten aan het feit dat de hoeveelheid post, die de gebruiker bijna of niet nodig heeft (Spam), voortdurend groeit. De filtersoftware kan ervoor zorgen dat alleen persoonlijke berichten met nieuws dat voor hen belangrijk is, aan gebruikers worden bezorgd en helpt ook om informatie te vinden die gebruikers nodig hebben in het besluitvormingsproces.

Nieuwsgroepen of nieuwsgroepen... Teleconferenties zijn de volgende fase in de ontwikkeling van communicatiesystemen. Hun kenmerken waren ten eerste het opslaan van berichten en het verschaffen van toegang aan geïnteresseerden tot de volledige uitwisselingsgeschiedenis, en ten tweede verschillende methoden voor het thematisch groeperen van berichten. Dergelijke conferentiesystemen bieden een groep van gezamenlijk werkende, maar geografisch gescheiden mensen de mogelijkheid om online meningen, ideeën of informatie uit te wisselen bij het bespreken van een kwestie, waarbij tijdelijke en ruimtelijke barrières worden overwonnen. Tegenwoordig zijn er veel soorten vergadersystemen, waaronder computerconferenties (vergaderingen die via e-mail worden gehouden), conferentiegesprekken met de mogelijkheid om mobiele bellers met elkaar te verbinden, conferenties met desktop-pc's, multimedia, teleconferenties en videoconferenties.

Interactieve communicatie(chatten). Met de ontwikkeling van telecommunicatie begint een toenemend aantal gebruikers op internet te werken in een permanente aanwezigheidsmodus, daarom is er een realtime communicatieservice verschenen, wanneer een abonnee een bericht ontvangt binnen een korte tijd nadat het is verzonden door een gesprekspartner.

De meest voorkomende moderne vormen van interactieve communicatie zijn webapplicaties die de volgende vormen van communicatie organiseren:

O Gasten boeken. De eerste en eenvoudigste vorm. Het eenvoudigste gastenboek is een lijst met berichten die van de laatste tot de eerste worden weergegeven en die elk door een bezoeker erin zijn achtergelaten.

O Forums... De eerste forums kwamen naar voren als een verbetering van gastenboeken en organiseerden berichten in branches - net als nieuwsgroepen. Gebruikersberichten in forums zijn gegroepeerd op onderwerpen, die meestal worden ingesteld door de eerste berichten. Alle bezoekers kunnen het onderwerp zien en hun bericht plaatsen - als reactie op de reeds geschreven berichten. Onderwerpen zijn gegroepeerd in thematische forums, het systeem wordt beheerd door informele beheerders en moderators. De meest ontwikkelde forums beginnen de eerste tekenen van sociale netwerken te vertonen - er kunnen op lange termijn interessante sociale banden tussen de deelnemers tot stand worden gebracht.

O Blogs(Weblog - Weblog, Web-protocol). In deze diensten houdt elke deelnemer zijn eigen dagboek bij - laat records in chronologische volgorde achter. Postonderwerpen kunnen van alles zijn, de meest gebruikelijke aanpak is bloggen als je eigen dagboek. Andere bezoekers kunnen reacties achterlaten op deze berichten. In dit geval krijgt de gebruiker niet alleen de mogelijkheid om zijn eigen dagboek bij te houden, maar ook de mogelijkheid om een ​​lijstweergave te organiseren - een lijst met vermeldingen uit de "vrienden" -tijdschriften, de toegang tot de vermeldingen te regelen en gesprekspartners op interesses te zoeken . Op basis van dergelijke systemen worden communities of interest gecreëerd, tijdschriften die gezamenlijk worden bijgehouden. In een dergelijke gemeenschap kan het lid vrijelijk elk bericht plaatsen over de richting van de activiteiten van de gemeenschap.

Over het algemeen hebben alle moderne systemen voor het waarborgen van het werk van netwerkgemeenschappen verschillende gemeenschappelijke kenmerken:

· De overgrote meerderheid van gemeenschappen voorziet in gebruikersregistratie, d.w.z. Voor elke deelnemer moet een account worden aangemaakt. Bij het registreren geeft de gebruiker ter identificatie enige informatie over zichzelf op. Bijna alle systemen vereisen dat u een e-mailadres invoert en de functionaliteit ervan controleert door een e-mail te sturen met een accountactiveringscode. Als het adres onjuist is, kan alleen de systeembeheerder de invoer activeren. Deze aanpak garandeert tot op zekere hoogte de uniciteit van de deelnemer en zijn herkenbaarheid.

· Werkzaamheden in de omgeving worden in sessies uitgevoerd. Elke sessie begint met de gebruiker die zijn naam invoert en zijn identiteit bevestigt door een wachtwoord in te voeren. Voor het gemak wordt de deelnamesessie meestal met technische middelen voor de gebruiker verborgen, maar niettemin vindt de identificatie van de gebruiker constant plaats.

Naast inloggegevens configureert de gebruiker de omgeving - uiterlijk, aanvullende gegevens over zichzelf, geeft zijn interesses, gewenste contacten, onderwerpen voor communicatie, enz.

· Sociale netwerken en de diensten die ze ondersteunen zijn een uiterst effectieve methode gebleken om siteverkeer en feedback te verzekeren, ze werden geleidelijk een van de middelen om de inhoud van de site te vullen met inhoud die echte commerciële en sociale waarde heeft.

Op basis van de laatste benadering ontstond een vrij groot aantal sociale webservices die snel aan populariteit wonnen, gezamenlijk Web 2.0-services genoemd. Sommige van deze bronnen kunnen worden gespecificeerd:

O Sociale bladwijzers... Op sommige websites kunnen gebruikers een lijst met bladwijzers of populaire websites met anderen delen. Dergelijke sites kunnen ook worden gebruikt om gebruikers met een gemeenschappelijk belang te vinden. Voorbeeld: heerlijk.

O Sociale mappen doet denken aan sociale bladwijzers, maar gericht op academisch gebruik, waardoor gebruikers kunnen werken met een database met citaten uit wetenschappelijke artikelen. Voorbeelden: Academic Search Premier, LexisNexis Academic University, CiteULike, Connotea.

O Sociale bibliotheken zijn applicaties waarmee bezoekers links naar hun collecties, boeken, audio-opnamen beschikbaar kunnen stellen aan anderen. Er wordt ondersteuning geboden voor een systeem van aanbevelingen en beoordelingen. Voorbeelden: discogs.com, IMDb.com.

O Online spellen voor meerdere spelers simuleer virtuele werelden met verschillende scoresystemen, niveaus, competitie, winnaars en verliezers. Voorbeeld: World of Warcraft.

O Meertalige sociale netwerken kunt u sociale banden aanknopen tussen mensen die verschillende talen spreken. Tegelijkertijd wordt speciale software gebruikt waarmee u zinnen in realtime van de ene taal naar de andere kunt vertalen. Voorbeelden: Dudu.

O Geosociale netwerken sociale connecties vormen op basis van de geografische locatie van de gebruiker. Tegelijkertijd worden verschillende geolocatietools gebruikt (bijvoorbeeld GPS of hybride systemen zoals AlterGeo-technologie), die het mogelijk maken om de huidige locatie van een bepaalde gebruiker te bepalen en zijn positie in de ruimte te correleren met de locatie van verschillende plaatsen en mensen in de buurt.

O Professionele sociale netwerken zijn gemaakt voor communicatie over professionele onderwerpen, uitwisseling van ervaring en informatie, zoeken en aanbieden van vacatures, ontwikkeling van zakelijke banden. Voorbeelden: Dokter op het werk, Professionals.ru, MyStarWay.com, LinkedIn, MarketingPeople, Viadeo.

O Dienst sociale netwerken gebruikers in staat stellen zich online te verenigen rond hun gemeenschappelijke interesses, hobby's of om verschillende redenen. Sommige sites bieden bijvoorbeeld services waarmee gebruikers persoonlijke informatie kunnen delen die nodig is om partners te vinden. Voorbeelden: LinkedIn, VKontakte.

O Commerciële sociale media gericht op het ondersteunen van zakelijke transacties en het opbouwen van vertrouwen van mensen in merken door rekening te houden met hun mening over het product, waardoor consumenten kunnen deelnemen aan de promotie van het product en hun bekendheid kunnen vergroten.