Klient-server-arkitektur på flere nivåer. Informasjonssystemarkitektur

Som regel er datamaskiner og programmer som inngår i et informasjonssystem ikke like. Noen av dem eier ressurser (filsystem, prosessor, skriver, database, etc.), andre har muligheten til å få tilgang til disse ressursene. Datamaskinen (eller programmet) som administrerer en ressurs kalles serveren til den ressursen (filserver, databaseserver, dataserver...). Klienten og serveren til en ressurs kan være plassert enten på samme datamaskin eller på forskjellige datamaskiner koblet til et nettverk.

Innenfor en multi-level view datasystemer Tre grupper av funksjoner kan skilles, fokusert på å løse ulike deloppgaver:

  1. datainndata og visningsfunksjoner (gi brukerinteraksjon);
  2. applikasjonsfunksjoner som er spesifikke for dette fagområde;
  3. ressursstyringsfunksjoner (filsystem, database, etc.)

Figur 1. Nettverksapplikasjonskomponenter

Implementeringen av disse funksjonene leveres hovedsakelig av programvare, som kan representeres i form av sammenkoblede komponenter (), der:

  • visningskomponent ansvarlig for brukergrensesnittet;
  • applikasjonskomponent implementerer en algoritme for å løse et spesifikt problem;
  • kontrollkomponent ressurs gir tilgang til nødvendige ressurser.

Et frittstående system (en datamaskin som ikke er koblet til et nettverk) representerer alle disse komponentene som ulike nivåer(OS, verktøy og verktøy, applikasjonsprogramvare), og på applikasjonsnivå (ikke typisk for moderne programmer). Nettverket er det samme - det representerer alle disse komponentene, men generelt fordelt mellom noder. Oppgaven handler om å sikre nettverksinteraksjon mellom disse komponentene.

Klient-server-arkitektur definerer de generelle prinsippene for å organisere samhandling i et nettverk der det er servere, noder som gir noen spesifikke funksjoner (tjenester) og klienter, forbrukere av disse funksjonene.

Praktiske implementeringer av en slik arkitektur kalles klient-server-teknologier. Hver teknologi definerer sine egne eller bruker eksisterende regler for interaksjon mellom klient og server, som kalles utvekslingsprotokoll (interaksjonsprotokoll).

I ethvert nettverk (selv peer-to-peer), bygget på moderne nettverksteknologier, er det elementer av klient-server-interaksjon, oftest basert på to-lags arkitektur. Det kalles to-lags (to-lag, 2-lag) på grunn av behovet for distribusjon tre grunnleggende komponenter mellom to noder(klient og server).

Fig.2. To-lags klient-server-arkitektur

En to-lags arkitektur brukes i klient-server-systemer, der serveren svarer direkte og fullstendig på klientforespørsler, og bruker bare sine egne ressurser. De. serveren kaller ikke tredjeparts nettverksapplikasjoner og har ikke tilgang tredjeparts ressurserå utføre noen del av forespørselen ()

Plasseringen av komponenter på klient- eller serversiden bestemmer følgende grunnleggende modeller for deres interaksjon i en to-lags arkitektur:

  • terminalserver— distribuert datapresentasjon;
  • filserver— tilgang til en ekstern database og filressurser;
  • databaseserver— ekstern datapresentasjon;
  • applikasjonsserver- ekstern applikasjon.

De listede modellene med variasjoner er presentert på.

Fig.3. Klient-server interaksjonsmodeller

Historisk sett var modellen for distribuert datapresentasjon (terminalservermodell) den første som dukket opp. Den ble implementert på en universell datamaskin (stormaskin), som fungerte som en server, med alfanumeriske terminaler koblet til den. Brukere la inn data fra terminaltastaturet, som deretter ble overført til stormaskinen og behandlet der, inkludert dannelsen av et "bilde" av resultatene. Dette "bildet" ble returnert til brukeren på terminalskjermen.

Med bruken av personlige datamaskiner og lokale nettverk ble en filservermodell implementert, som ga tilgang til filressurser, inkludert en ekstern database. I dette tilfellet er den dedikerte nettverksnoden filserver, som er vert for databasefilene. Klienter kjører applikasjoner som kombinerer en presentasjonskomponent og en applikasjonskomponent (DBMS og applikasjonsprogram), ved å bruke den tilkoblede eksterne databasen som en lokal fil. I dette tilfellet representerer utvekslingsprotokoller et sett med lavnivåanrop til filsystemoperasjoner.

Denne modellen har vist seg å være ineffektiv på grunn av at når man aktivt jobber med databasetabeller, er det stor belastning på nettverket. En delvis løsning er å støtte replikering av tabeller og spørringer. I dette tilfellet, for eksempel, når data endres, oppdateres ikke hele tabellen, men bare den modifiserte delen.

Med bruken av spesialiserte DBMS-er ble det mulig å implementere en annen modell for tilgang til en ekstern database - databaseservermodellen. I dette tilfellet opererer DBMS-kjernen på serveren, søknadsprogram på klienten, og kommunikasjonsprotokollen leveres med SQL-språket. Denne tilnærmingen, sammenlignet med en filserver, fører til en reduksjon i nettverksbelastning og forening av klient-server-grensesnittet. Nettverkstrafikken forblir imidlertid ganske høy, og det er fortsatt umulig å administrere applikasjoner på en tilfredsstillende måte, siden ulike funksjoner er kombinert i ett program.

Med utvikling og implementering av den lagrede prosedyremekanismen på databaseservernivå, konseptet med aktiv databaseserver. I dette tilfellet implementeres noen av funksjonene til applikasjonskomponenten i form av lagrede prosedyrer utført på serversiden. Resten av applikasjonslogikken utføres på klientsiden. Interaksjonsprotokollen er den tilsvarende dialekten til SQL-språket.

Fordelene med denne tilnærmingen er åpenbare:

  • sentralisert administrasjon av applikasjonsfunksjoner er mulig;
  • redusere kostnadene for systemeierskap (TOC, totale eierkostnader) ved å leie en server i stedet for å kjøpe den;
  • betydelig reduksjon nettverkstrafikk(siden det ikke er SQL-spørringer som overføres, men kaller til lagrede prosedyrer).

Den største ulempen er de begrensede verktøyene for å utvikle lagrede prosedyrer sammenlignet med språk på høyt nivå.

Implementeringen av en applikasjonskomponent på serversiden representerer følgende modell - en applikasjonsserver. Flytting av apptil serveren reduserer klientkonfigurasjonskrav og forenkler administrasjonen, men stiller økte krav til serverytelse, sikkerhet og pålitelighet.

For tiden er det en tendens til å gå tilbake til der klient-server-arkitekturen begynte - å sentralisere databehandling basert på terminal-server-modellen. I sin moderne reinkarnasjon skiller terminaler seg fra sine alfanumeriske forfedre ved at de, med et minimum av programvare og maskinvare, gir multimediefunksjoner (inkl. grafisk brukergrensesnitt). Driften av terminalene sikres av en høyytelsesserver, hvor alt er plassert, opp til virtuelle drivere enheter, inkludert drivere for undersystem for video.

Fig.4. Tre-lags klient-server-arkitektur

En annen trend innen klient-server-teknologi er relatert til alt stor bruk distribuert databehandling. De implementeres basert på applikasjonsservermodellen, hvor nettverksapplikasjonen er delt inn i to eller flere deler, som hver kan kjøres på en egen datamaskin. Dedikerte deler av applikasjonen kommuniserer med hverandre, og utveksler meldinger i et forhåndsavtalt format. I dette tilfellet blir to-lags klient-server-arkitekturen tre-lags (tre-lag, 3-lag).

Som regel er den tredje lenken i en trelagsarkitektur applikasjonsserveren, dvs. komponentene er fordelt som følger ():

  1. Datapresentasjon er på klientsiden.
  2. Applikasjonskomponent - på en dedikert applikasjonsserver (valgfritt, utfører funksjonene til mellomvare).
  3. Ressursstyring - på databaseserveren, som gir de forespurte dataene.

Fig.5. Flerlags (N-lags) klient-tjener-arkitektur

Trelagsarkitekturen kan utvides til multi-tier (N-tier, Multi-tier) ved å tildele ekstra servere, som hver vil representere egne tjenester og bruke tjenestene til andre servere ulike nivåer. Et abstrakt eksempel på en multi-link modell er gitt på.

Sammenligning av arkitekturer

Tolagsarkitekturen er enklere, siden alle forespørsler betjenes av én server, men nettopp på grunn av dette er den mindre pålitelig og stiller høyere krav til serverytelse.

Trelagsarkitekturen er mer kompleks, men på grunn av det faktum at funksjoner er fordelt mellom servere på andre og tredje nivå, representerer denne arkitekturen:

  1. Høy grad av fleksibilitet og skalerbarhet.
  2. Høy sikkerhet (siden sikkerhet kan defineres for hver tjeneste eller nivå).
  3. Høy ytelse (siden oppgaver er fordelt mellom servere).

Klient-server-teknologier

Klient-server-arkitektur brukes i stort nummer nettverksteknologier som brukes for å få tilgang til ulike nettverkstjenester. La oss kort se på noen typer slike tjenester (og servere).

Webservere Opprinnelig ga de tilgang til hypertekstdokumenter via HTTP (Huper Text Transfer Protocol). Nå støtter de avanserte funksjoner, spesielt arbeid med binære filer(bilder, multimedia osv.). Applikasjonsservere Designet for sentralisert løsning av anvendte problemer i et bestemt fagområde. For å gjøre dette har brukerne rett kjøre serverprogrammer for utførelse. Bruk av applikasjonsservere reduserer kravene til klientkonfigurasjon og forenkler generell ledelse Nettverk. Databaseservere Databaseservere brukes til å behandle brukerforespørsler i SQL-språk. I dette tilfellet er DBMS plassert på serveren som klientapplikasjonene kobles til. Filservere Filserver butikker informasjon i form av filer og gir brukerne tilgang til den. Som regel gir en filserver også et visst nivå av beskyttelse mot uautorisert tilgang. Proxy-server For det første fungerer den som en mellommann, og hjelper brukere med å få informasjon fra Internett samtidig som den beskytter nettverket. For det andre lagrer den ofte tilgang til informasjon i hurtigbufferminnet på lokal disk, raskt levere den til brukere uten å måtte få tilgang til Internett igjen. Brannmurer(brannmurer) Brannmurer, analysere og filtrere passerende nettverkstrafikk for å sikre nettverkssikkerhet. E-postservere Tilby tjenester for å sende og motta elektroniske postmeldinger. Servere fjerntilgang(RAS) Disse systemene gir tilkobling til nettverket over oppringte linjer. En ekstern ansatt kan bruke ressursene til et bedrifts-LAN ved å koble til det ved hjelp av et vanlig modem.

Dette er bare noen få typer fra hele sorten. klient-server-teknologier, brukt i både lokale og globale nettverk.

For å få tilgang til visse nettverkstjenester brukes klienter hvis evner er preget av konseptet "tykkelse". Den definerer maskinvarekonfigurasjonen og programvaren som er tilgjengelig for klienten. La oss vurdere mulige grenseverdier:

"Tynn" klient Dette begrepet definerer en klient hvis dataressurser bare er tilstrekkelige til å kjøre den nødvendige nettverksapplikasjonen gjennom et webgrensesnitt. Brukergrensesnittet til en slik applikasjon dannes ved hjelp av midler statisk HTML ( JavaScript-utførelse ikke oppgitt), kjøres all applikasjonslogikk på serveren.
For at den tynne klienten skal fungere, er det nok bare å gi muligheten til å starte en nettleser, i vinduet der alle handlinger utføres. Av denne grunn kalles en nettleser ofte en "universell klient". "Fet" klient Dette er hva det er arbeidsstasjon eller en personlig datamaskin som kjører sitt eget diskoperativsystem og har det nødvendige settet med programvare. Tykke klienter får tilgang til nettverksservere hovedsakelig for tilleggstjenester(for eksempel tilgang til en webserver eller bedriftsdatabase).
En "tykk" klient betyr også en klientnettverksapplikasjon som kjører under det lokale operativsystemet. En slik applikasjon kombinerer en datapresentasjonskomponent (OS grafisk brukergrensesnitt) og en applikasjonskomponent (datamaskinen til klientdatamaskinen).

Nylig har et annet begrep blitt brukt i økende grad: "rik"-klient. Den "rike" klienten er et slags kompromiss mellom de "tykke" og "tynne" klientene. I likhet med den tynne klienten, representerer også den rike klienten GUI, allerede beskrevet ved hjelp av XML og inkludert noen rik klientfunksjonalitet (f.eks. dra-og-slipp-grensesnitt, faner, flere vinduer, rullegardinmenyer osv.)

Applikasjonslogikken til den "rike" klienten er også implementert på serveren. Data sendes til standard format utveksling, basert på samme XML (SOAP, XML-RPC-protokoller) og tolket av klienten.

Noen grunnleggende XML-baserte rike klientprotokoller er gitt nedenfor:

  • XAML (eXtensible Application Markup Language) - utviklet av Microsoft, brukt i applikasjoner på .NET-plattformen;
  • XUL (XML User Interface Language) er en standard utviklet av Mozilla-prosjektet, brukt for eksempel i e-postklient Mozilla Thunderbird eller Mozilla Firefox nettleser;
  • Flex - multimedieteknologiXML-basert, utviklet av Macromedia/Adobe.

Konklusjon

Så, Hovedideen med klient-server-arkitekturen er å dele nettverksapplikasjonen i flere komponenter, som hver implementerer et spesifikt sett med tjenester. Komponentene til en slik applikasjon kan kjøres på forskjellige datamaskiner, utføre server- og/eller klientfunksjoner. Dette forbedrer påliteligheten, sikkerheten og ytelsen til nettverksapplikasjoner og nettverket som helhet.

Kontrollspørsmål

  1. Hva er hovedideen med C-S-interaksjon?
  2. Hva er forskjellen mellom konseptene "klient-server-arkitektur" og "klient-server-teknologi"?
  3. Liste komponenter K-S interaksjoner.
  4. Hvilke oppgaver utfører presentasjonskomponenten i KS-arkitekturen?
  5. Til hvilket formål presenteres databasetilgangsverktøy som en egen komponent i KS-arkitekturen?
  6. Hvorfor fremheves forretningslogikk som en egen komponent i KS-arkitekturen?
  7. List opp modellene for klient-tjener-interaksjon.
  8. Beskriv filservermodellen.
  9. Beskriv databaseservermodellen.
  10. Beskriv "applikasjonsserver"-modellen
  11. Beskriv terminalservermodellen
  12. Liste hovedtyper av servere.

Permanent adresse til denne siden:

Brukerforberedelse

Beskyttelse

Serverkrav

Delte ressurser

I et node-til-node-nettverk må hver datamaskin:

· skaffe de fleste dataressursene dine lokal bruker(til personen som sitter ved denne datamaskinen);

· For å støtte tilgang til ressurser til en ekstern bruker (som får tilgang til serveren over nettverket), koble til ytterligere dataressurser.

Serverbasert nettverk krever kraftigere servere da de må håndtere forespørsler fra alle klienter på nettverket.

Grunnleggende beskyttelse innebærer å angi et passord for en delt ressurs, for eksempel en katalog. Det er svært vanskelig å sentralt administrere sikkerhet i et peer-to-peer-nettverk, siden hver bruker installerer det uavhengig, og "delte" ressurser kan lokaliseres på alle datamaskiner, og ikke bare på den sentrale serveren. Denne situasjonen utgjør en alvorlig trussel for hele nettverket, og noen brukere kan ikke installere beskyttelse i det hele tatt. Hvis personvernspørsmål er av grunnleggende betydning for deg, anbefaler vi å velge et serverbasert nettverk.

Fordi i et peer-to-peer-nettverk fungerer hver datamaskin som både en klient og en server, må brukerne ha tilstrekkelig kunnskap til å fungere som både brukere og administratorer av datamaskinen.

Tema 5.2. Nettverk OS. Klient server

Klient server(Client-server) - en databehandlings- eller nettverksarkitektur der oppgaver eller nettverksbelastning er fordelt mellom tjenesteleverandører, kalt servere, og tjenestekunder, kalt klienter. Ofte kommuniserer klienter og servere over et datanettverk og kan enten være forskjellige fysiske enheter eller programvare.

Flernivå klient-server-arkitektur er en type klient-server-arkitektur der databehandlingsfunksjonen utføres på en eller flere separate servere. Dette lar deg separere funksjonene for å lagre, behandle og presentere data for mer effektiv bruk egenskapene til servere og klienter.

Spesielle tilfeller av flernivåarkitektur:

· Tre-lags arkitektur

· Dedikert servernettverk

· Et nettverk med en dedikert server (engelsk klient/server-nettverk) er et lokalt datanettverk(LAN), der nettverksenheter sentralisert og administrert av en eller flere servere. Individuelle arbeidsstasjoner eller klienter (som PCer) må få tilgang til nettverksressurser via server(e).

Nettverksoperativsystem- et operativsystem med innebygde muligheter for arbeid i datanettverk. Slike muligheter inkluderer:

· Brukerstøtte nettverksutstyr

· Brukerstøtte nettverksprotokoller

· støtte for rutingprotokoller

· støtte for filtrering av nettverkstrafikk

· støtte for tilgang til eksterne ressurser som skrivere, disker osv. over et nettverk

Tilgjengelighet i systemet nettverkstjenester lar eksterne brukere bruke datamaskinressurser

Eksempler på nettverksoperativsystemer:

Novell NetWare

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

· Ulike UNIX-systemer, slik som Solaris, FreeBSD

· Ulike GNU/Linux-systemer

ZyNOS fra ZyXEL

Moderne nettverksoperativsystemer (UNIX, WIN2000, NOWELL NW) implementerer hele protokollstabelen til OSI-modellen, og UNIX støtter derfor en protokollstack (TCP/IP, NW LINK, NET BIOS). Nowell NW støtter IPX/SPX-protokollstabelen Apple Mac bruker sitt eget sett med protokoller.

Uavhengig av produsent, utfører alle nettverksoperativsystemer følgende funksjoner:

1. Fordeling av funksjoner mellom nettverksnoder (klienter og servere);

2. Støtte for kommunikasjonsprotokoller;

3. Støtte for nettverksfilsystem;

4. Databeskyttelse.

Alle nettverksoperativsystemer kan deles inn i 2 typer:

1. Peer-to-peer eller peer-to-peer-nettverk (hvert av hvert). Eksempel Windows 9x;

2. Nettverk basert på en dedikert server.

K1. I et peer-to-peer-nettverk har alle PC-er like rettigheter, men det er også klienter og servere i nettverket. Vanligvis kan hver PC byttes til servermodus hvis brukeren ønsker det (en delt ressurs er tildelt).

Peer-to-peer-nettverk OS mangler pålitelig ytelse og sikkerhet. Brukes på nettverket når det er 10-15 stk. Et eksempel på et node-til-node-nettverk er Win94/98/OS/2/LANtastic

K2. I dette nettverket er det alltid en hoved-PC - en server, som er spesielt optimalisert for rask behandling av forespørsler fra mange klienter (ca. -100) og for å administrere beskyttelsen av filer og kataloger. I store nettverk skille seg ut separate servere Til individuelle søknader(WEB – server, Fil – server, Print – server, DB server og e-postserver)

Serverprogramvaren er svært sofistikert, pålitelig og ytende. Den kan fungere på forskjellige plattformer.

Ulike operativsystemer – Unix, Win 2000Server, NovellNetWare

Klientprogramvare for et hvilket som helst operativsystem lar deg omdirigere brukerens forespørsel fra et lokalt sted. PC til server med nødvendige ressurser. Dette gjøres ved hjelp av en spesiell redirector (interceptor), som fanger opp forespørselen og bestemmer om den skal kjøres på den lokale PC-en eller på serveren.

Re-director struktur:

DB, om strukturell Språk SQL-spørringer (Structured Query Language), som er industristandard i en verden av relasjonsdatabaser. Den eksterne serveren mottar forespørselen og videresender den til SQL-databasetjeneren. SQL server – spesialprogram, som administrerer den eksterne databasen. SQL-serveren gir tolkning av forespørselen, dens utførelse i databasen, generering av resultatet av forespørselen og levering av den til klientapplikasjonen. I dette tilfellet er ikke ressursene til klientdatamaskinen involvert i den fysiske utførelsen av forespørselen; klientdatamaskinen sender kun en forespørsel til serverdatabasen og mottar resultatet, hvoretter den tolker det som nødvendig og presenterer det for brukeren. Siden resultatet av forespørselen sendes til klientapplikasjonen, "reiser" bare dataene som klienten trenger gjennom nettverket. Som et resultat reduseres belastningen på nettverket. Siden forespørselen utføres der dataene er lagret (serveren), er det ikke nødvendig å sende store mengder data. I tillegg optimaliserer SQL-serveren, hvis mulig, den mottatte spørringen slik at den utføres på minimum tid med minst mulig overhead [[3.2], [3.3]]. systemet er vist i fig. 3.3.

Alt dette øker systemytelsen og reduserer tiden det tar å vente på et forespørselsresultat. Når spørringer utføres av serveren, økes graden av datasikkerhet betydelig, siden dataintegritetsregler er definert i databasen på serveren og er de samme for alle applikasjoner som bruker denne databasen. Dette eliminerer muligheten for å definere motstridende regler for å opprettholde integritet. Den kraftige transaksjonsmotoren som støttes av SQL-servere gjør det mulig å forhindre samtidige endringer av samme data av forskjellige brukere og gir muligheten til å rulle tilbake til de opprinnelige verdiene når du gjør endringer i databasen som endte unormalt [[3.2], [ 3.3]].


Ris. 3.3. Klient-server-arkitektur

  • Finnes det lokale nettverket, bestående av klientdatamaskiner, som hver har klientapplikasjon for å jobbe med databasen.
  • På hver av klientdatamaskinene har brukerne muligheten til å kjøre applikasjonen. Ved å bruke brukergrensesnittet fra applikasjonen, starter den et anrop til DBMS som ligger på serveren for å hente/oppdatere informasjon. For kommunikasjon brukes et spesielt spørrespråk SQL, dvs. Bare forespørselsteksten overføres over nettverket fra klienten til serveren.
  • DBMS initierer anrop til data som ligger på serveren, som et resultat av at all databehandling utføres på serveren og kun resultatet av forespørselen kopieres til klientdatamaskinen. Dermed returnerer DBMS resultatet til applikasjonen.

La oss se på hvordan separasjonen av funksjoner mellom serveren og klienten ser ut.

  • Klientapplikasjonsfunksjoner:
    • Sender forespørsler til serveren.
    • Tolkning av søkeresultater mottatt fra serveren.
    • Presentere resultatene for brukeren i en eller annen form (brukergrensesnitt).
  • Funksjoner på serversiden:
    • Motta forespørsler fra klientapplikasjoner.
    • Tolking av forespørsler.
    • Optimalisering og utførelse av databasespørringer.
    • Sender resultater til klientapplikasjonen.
    • Sikre et sikkerhetssystem og tilgangskontroll.
    • Databaseintegritetsstyring.
    • Implementering av stabilitet av flerbrukerdriftsmodus.

Såkalte "industrielle" DBMS-er opererer i klient-server-arkitekturen. De kalles industrielle fordi det er DBMS i denne klassen som kan gi arbeidet informasjonssystemer omfanget av en mellomstor og stor bedrift, organisasjon, bank. Kategorien industriell DBMS inkluderer MS SQL Server, Oracle, Gupta, Informix, Sybase, DB2, InterBase og en rekke andre [[3.2]].

Som regel vedlikeholdes en SQL-server av en enkelt ansatt eller en gruppe ansatte (SQL-serveradministratorer). De styrer fysiske egenskaper databaser, optimalisere, konfigurere og omdefinering ulike komponenter databaser, opprette nye databaser, endre eksisterende osv., og også utstede privilegier (tillatelser til et visst nivå av tilgang til spesifikke databaser, SQL-server) til ulike brukere [[3.2]].

La oss se på hovedfordelene med denne arkitekturen sammenlignet med filserverarkitekturen:

  • Nettverkstrafikken er betydelig redusert.
  • Kompleksiteten til klientapplikasjoner reduseres (mesteparten av belastningen faller på serverdelen), og følgelig reduseres kravene til maskinvarekapasiteten til klientdatamaskiner.
  • Tilgjengelighet av spesielle programvareverktøy– SQL server – fører til at en betydelig del av design- og programmeringsoppgavene allerede er løst.
  • Integriteten og sikkerheten til databasen er betydelig økt.

Ulemper inkluderer høyere Finansielle utgifter for maskinvare og programvare, og også det faktum at et stort antall klientdatamaskiner plassert på forskjellige steder forårsaker visse vanskeligheter med rettidig oppdatering av klientapplikasjoner på alle klientdatamaskiner. Imidlertid har klient-server-arkitekturen vist seg i praksis, i for tiden Det er et stort antall databaser bygget i samsvar med denne arkitekturen.

3.4. Tre-lags (flerlags) klient-tjener-arkitektur.

Tre-link (i noen tilfeller multi-link) arkitektur(N-tier eller multi- tre-lags arkitektur? Nå, når forretningslogikken endres, er det ikke lenger behov for å endre klientapplikasjoner og oppdatere dem for alle brukere. I tillegg reduseres kravene til brukerutstyr mest mulig.

Så, som et resultat, er arbeidet strukturert som følger:

  • Databasen i form av et sett med filer ligger på harddisken til en spesielt dedikert datamaskin (nettverksserver).
  • DBMS er også plassert på nettverksserveren.
  • Det er en spesielt dedikert applikasjonsserver som forretningsanalyseprogramvaren (forretningslogikk) er plassert på [[3.1]].
  • Det er mange klientdatamaskiner, som hver har en såkalt "tynn klient" installert - en klientapplikasjon som implementerer brukergrensesnittet.
  • På hver av klientdatamaskinene har brukerne mulighet til å kjøre en applikasjon – en tynnklient. Ved å bruke brukergrensesnittet fra applikasjonen, starter den et anrop til Business Intelligence-programvaren som ligger på applikasjonsserveren.
  • Applikasjonsserveren analyserer brukerkrav og genererer spørringer til databasen. For kommunikasjon brukes et spesielt spørrespråk SQL, dvs. Bare forespørselsteksten overføres over nettverket fra applikasjonsserveren til databaseserveren.
  • DBMS kapsler inn i seg all informasjon om den fysiske strukturen til databasen som ligger på serveren.
  • DBMS initierer anrop til data som ligger på serveren, som et resultat av at resultatet av spørringen blir kopiert til applikasjonsserveren.
  • Applikasjonsserveren returnerer resultatet til klientapplikasjonen (brukeren).
  • Applikasjonen, ved hjelp av brukergrensesnittet, viser resultatet av spørringene.

Klient-server-teknologi regnes som en av "hvalene" moderne verden datanettverk. Men problemene den ble utviklet for, er i ferd med å bli en saga blott. Nye oppgaver og teknologier krever en nytenkning av prinsippene for klient-server-systemer. En av disse teknologiene World Wide Web. Webteknologi er en utvikling av klient-server-arkitekturen, dvs. Med én klient kan du koble til mange servere. Et informasjonssystem, i tillegg til grensesnittet, må ha nivåer av databehandling og lagring. Problemet med internettutviklere er koordinering Webarbeid med andre elementer i systemet, for eksempel databaser. En av de lovende måtene å løse dette problemet på er klient-serversystemer på flere nivåer.

Klassisk system klient-server fungerer i henhold til forespørsel-svar-skjemaet (to-nivå arkitektur). Klienten utfører en aktiv funksjon (forespørsler), serveren svarer passivt på dem.


Ethvert informasjonssystem skal ha minst tre funksjonsdeler - moduler for datalagring, databehandling og brukergrensesnitt.

Hver av disse delene kan implementeres uavhengig av de to andre.

For eksempel . Uten å endre programmene som brukes til å lagre og behandle dataene, kan du endre brukergrensesnittet slik at de samme dataene vises i form av tabeller, grafer eller histogrammer. Uten å endre datapresentasjonen og lagringsprogrammene kan du endre behandlingsprogrammene ved å endre algoritmen fulltekstsøk. Uten å endre programmene for å presentere og behandle data, kan du endre programvaren for lagring av data ved å bytte til et annet filsystem.

I klassisk arkitektur klient-server tre hoveddeler av applikasjonen er fordelt på to fysiske moduler. Vanligvis er datalagringsprogramvaren plassert på serveren (/: databaseserver), brukergrensesnittet er på klientsiden, men databehandlingen må distribueres mellom klient- og serverdelen. Dette er den største ulempen med denne arkitekturen. Partisjonering av databehandlingsalgoritmer krever synkronisering av handlingene til begge deler av systemet. For å unngå inkonsekvens ulike elementer arkitekturer forsøker å utføre databehandling på en av to deler - enten på klientsiden (tykk klient) eller på serveren (tynn klient eller 2,5-lags klient-server). Hver tilnærming har sine ulemper: I det første tilfellet nettverket er urettmessig overbelastet, fordi den overfører rå (redundante) data, noe som gjør det vanskeligere å støtte og endre systemet, siden erstatning av en beregningsalgoritme eller korrigering av en feil krever en samtidig fullstendig utskifting av alle grensesnittprogrammer, ellers vil datainkonsekvens følge; i det andre tilfellet, når all informasjonsbehandling utføres på serveren, oppstår problemet med å beskrive innebygde prosedyrer og deres feilsøking (beskrivelsen er deklarativ og tillater ikke trinnvis feilsøking). I tillegg er et system med informasjonsbehandling på en server helt umulig å overføre til en annen plattform.

Flertall moderne virkemidler rask applikasjonsutvikling (RAD), som fungerer med ulike databaser, implementerer den første modellen ("tykk" klient), og gir et grensesnitt med databaseserveren via SQL-språk.. Dette alternativet, i tillegg til ulempene som er oppført ovenfor, har lavt nivå sikkerhet.

For eksempel. I banksystemer har alle operatøroperatører rett til å skrive til hovedtabellen i regnskapssystemet. I tillegg, dette systemet Det er nesten umulig å overføre til webteknologi, siden spesialisert klientprogramvare brukes for å få tilgang til databaseserveren.

Ulemper med modellene diskutert ovenfor:

1. "Fet" klient

F kompleksiteten i administrasjonen;

F problemer med å oppdatere programvare, fordi dens utskifting må utføres samtidig gjennom hele systemet;

F kompleksitet i maktfordelingen, siden tilgang er begrenset ikke av handlinger, men av tabeller;

F nettverksoverbelastning på grunn av overføring av ubehandlede data;

F svak databeskyttelse.

2. "Fet" server

ð implementeringen blir mer komplisert, siden PL/SQL-språkene ikke er egnet for utvikling av slik programvare og det er ingen feilsøkingsverktøy;

ð ytelsen til programmer på PL/SQL-språk er lavere enn på andre språk, noe som er viktig for komplekse systemer;

ð programmer skrevet på DBMS-språk fungerer ikke pålitelig, noe som kan føre til feil på hele databaseserveren;

ð programmer som er opprettet på denne måten er fullstendig uportable til andre systemer og plattformer.



For å løse disse problemene brukes multi-level (tre eller flere) klient-server-modeller.

Flerlags klient-server-arkitekturer - distribuerer databehandlingsmoduler som kjører på en eller flere separate servere på en mer intelligent måte.

Disse programvaremoduler utføre funksjoner servere for grensesnitt med brukere og klient- for databaseservere. I tillegg kan forskjellige applikasjonsservere kommunisere med hverandre for å partisjonere systemet mer nøyaktig funksjonsblokker utføre spesifikke roller.

For eksempel. Du kan velge en personaladministrasjonsserver som skal utføre alle funksjonene som er nødvendige for personaladministrasjon. Ved å knytte en egen database til den, kan du skjule alle implementeringsdetaljene til denne serveren for brukere, og bare gi tilgang til dens offentlig tilgjengelige funksjoner. Et slikt system er lettere å tilpasse til nettet, fordi Det er lettere å utvikle HTML-skjemaer for brukertilgang til visse databasefunksjoner enn til alle data.

I trelagsmodellen er ikke tynnklienten overbelastet med databehandlingsfunksjoner, men spiller hovedrollen som et system for å presentere informasjon som kommer fra applikasjonsserveren. (Dette grensesnittet er implementert ved hjelp av standard betyr Nettteknologi – nettleser, CGI og Java). Dette reduserer mengden data som overføres mellom klienten og applikasjonsserveren, slik at klienter med trege telefonlinjer kan koble seg til.

Klient-servermodellen med tre nivåer lar deg tildele brukertillatelser mer nøyaktig, siden de mottar rettigheter ikke til selve databasen, men til visse funksjoner på applikasjonsserveren, noe som øker sikkerheten til systemet.

Multi-level client-server-systemer kan enkelt overføres til webteknologi - for å gjøre dette er det nok å erstatte klientdelen med en universell nettleser, og supplere applikasjonsserveren med en webserver og små serverprosedyrekalleprogrammer. I et tre-nivå system overføres mye informasjon gjennom kommunikasjonskanalen mellom applikasjonsserveren og databasen, men beregningene går ikke langsommere, siden kommunikasjonen spesifiserte elementer raskere linjer brukes. Dette krever lavere kostnader siden begge serverne er plassert i samme lokaler. Men dette reiser problemet med konsistens i felles beregninger, som transaksjonsledere - nye elementer i flernivåsystemer - blir bedt om å løse.

Transaksjonsledere

MT - tillate én applikasjonsserver å kommunisere med flere databaseservere samtidig. Selv om Oracle-servere har en mekanisme for å utføre distribuerte transaksjoner, men hvis brukeren lagrer en del av informasjonen i Oracle-databasen, en del i Informix-databasen, og en del i tekstfiler, da kan du ikke klare deg uten MT. MT brukes til å administrere distribuerte heterogene operasjoner og koordinere handlingene til ulike komponenter i et informasjonssystem. All kompleks programvare krever bruk av MT.

For eksempel. Banksystemer må gjennomføre ulike transformasjoner innleveringer av dokumenter, dvs. arbeide samtidig med data lagret både i databasen og i vanlige filer,- dette er funksjonene MT hjelper til med å utføre.

MT er et program eller sett med programmer som kan brukes til å koordinere driften av ulike komponenter i et informasjonssystem.

Logisk sett er MT delt inn i flere deler:

· kommunikasjonsansvarlig (kontrollerer utvekslingen av meldinger mellom komponenter i informasjonssystemet;

· transaksjonsansvarlig (styrer distribuerte operasjoner);

· loggbehandler (overvåker gjenoppretting og tilbakeføring av distribuerte operasjoner);

· låsebehandler (sikrer korrekt tilgang til delte data).

Typisk kombineres M-kommunikasjon med M-autorisasjon, og M-transaksjoner kombineres med M-låser og systemposter. Dessuten er en slik M sjelden inkludert i leveringspakken, siden dens funksjoner (holde journaler, distribuere ressurser og kontrollere operasjoner) vanligvis utføres av selve databasen (for eksempel Oracle).

Største endringer skjedde i M-kommunikasjon, ettersom nye objektorienterte teknologier (CORBA, DCOM, etc.) dukket opp i dette området. Klient-servermodellen med flere nivåer kan forenkle distribuert databehandling betydelig, noe som gjør den ikke bare mer pålitelig, men også mer tilgjengelig.

4.4. Behandle postsystemer­ -

det er en garantert levering av informasjon og et middel for applikasjonsintegrasjon

Utformingen av informasjonssystemer konfronterer systemanalytikere med løsninger på følgende problemer:

ð distribuert system;

ð integrasjon ulike applikasjoner;

ð enkel administrasjon.

Moderne datamaskiner er stort sett distribuert, så problemet oppstår med å velge en metode for interaksjon mellom de enkelte delene av slike systemer. Sammenslåing av flere informasjonssystemer krever en integrasjonsløsning stor kvantitet heterogene applikasjoner. Et slikt (integrert) system må ha all funksjonaliteten til de kombinerte delsystemene og opprettholde enkelhet og brukervennlighet. Dette problemet kan løses ved hjelp av teknologiske postsystemer(STP).

Begrepet "teknologisk post" brukes for å betegne interaksjonen mellom applikasjoner ("elektronisk post" er interaksjonen mellom mennesker), informasjonen som overføres er teknologisk; dens dannelse og overføring kan utføres uten/eller med minimal menneskelig medvirkning.

Det teknologiske postsystemet inkluderer to forskjellige måter interaksjoner brukt i moderne distribuerte systemer.

En av dem er basert på konseptet tilkobling (fig. 1), og den andre er basert på ideen om meldinger.

1


Figur 1. Tilkoblingsorientert interaksjonsmekanisme

Prosessen med interaksjon mellom applikasjoner og bruk av tilkoblingsetablering kan deles inn i tre faser:

1. forbindelsesetablering;

2. overføring av informasjon;

3. lukke forbindelsen.

Slik interaksjon krever tilkobling av alle tre fasene og samtidig drift av applikasjoner, noe som ikke alltid er mulig.

Systemer bygget på meldingsprinsippet bruker meldingskøteknologi under interaksjon (fig. 2).



Fig.2. Applikasjonskommunikasjon ved hjelp av meldingskøteknologi

Applikasjoner som utveksler informasjon adresserer det ikke direkte til hverandre, men til meldingskøer knyttet til applikasjonene. Forbindelsen mellom applikasjonen og køen skjer som regel i online-modus, noe som unngår tiden brukt på å etablere forbindelsen. Kontrollprogramvaren kan enten være plassert på samme maskin med applikasjonene eller på en dedikert server. Systemer som bruker meldingskøteknologi, i motsetning til systemer for etablering av tilkoblinger, krever ingen permanent tilkobling i prosessen med interaksjon, og heller ikke samtidig drift av interagerende applikasjoner. Disse egenskapene gir dem fleksibilitet og akseptabilitet i ulike områder applikasjoner.

Allsidigheten til teknologiske postsystemer gjør at de kan jobbe videre heterogen (en rekke programvare- og maskinvareplattformer de jobber på individuelle komponenter STP, samt en rekke tilkoblingsmetoder og interaksjonsprotokoller som brukes i systemstrukturer. Heterogenitet oppnås ved å skille server- og klientdelene av STP. Klientdelene har liten funksjonalitet og kan porteres til ulike plattformer. Dermed krever driften av STP ikke kostnadene for tilleggsutstyr - systemet tilpasser seg eksisterende midler (både maskinvare og programvare, samt eksisterende dataoverføringskanaler) og krever ikke utskifting.

Fordeler med å bruke STP:

Ø Garantert meldingslevering. Message Queuing-servere

De bestemmer selv hvordan de skal sikre levering ved svikt i individuelle deler av systemet: sende på nytt, finne en alternativ rute eller bruke andre metoder. Siden STP-er gir informasjonsutveksling mellom applikasjoner, må det faktum at en melding ikke ble levert spores og behandles (i motsetning til E-post, der brukeren må ta eventuelle korrigerende handlinger i tilfelle av manglende levering av en melding);

Ø Ingen blokkering av applikasjonen under overføring av informasjon, pga Teknologien for meldingskøer er på plass, og serverdelen av TP-systemet er allokert, som er ansvarlig for meldingslevering. Mangel på blokkering reduserer nedetid for programmet;

Ø Evne til å angi meldingsprioriteter og alternativer ved sending. Prioriteringer lar deg implementere flere parallelle systemer meldingsoverføring. Meldinger med lavere prioritet vil imidlertid ikke ha noen innvirkning på leveringen av meldinger med høyere prioritet. Dette har en positiv effekt ved design og konfigurering av store systemer, samt ved administrasjon av systemer;

Ø Mulighet for informasjonsutveksling i et heterogent miljø, hvor modernisering av både maskinvare og programvare er mulig.

Oversettelse fra engelsk: Chernobay Yu. A.

Utvikling av klient-server systemer

Arkitekturen til et datasystem har utviklet seg sammen med maskinvarens evne til å bruke applikasjonene den kjører. Den enkleste (og tidligste) av alle var "Mainframe Architecture", der alle operasjoner og funksjoner utføres på server- (eller "verts") datamaskin. Brukere samhandlet med serveren gjennom "dum" terminaler, som overførte instruksjoner ved å fange tastetrykk til serveren og viste resultatene av instruksjonene til brukeren. Slike applikasjoner var av typisk karakter, og til tross for den relativt store datakraften til serverdatamaskiner, var de generelt relativt trege og upraktiske å bruke, på grunn av behovet for å overføre hvert tastetrykk til serveren.

Introduksjon og utbredt bruk av PC-en, med sin egen datakraft og grafisk brukergrensesnitt tillot applikasjoner å bli mer komplekse og utvidelse nettverkssystemer førte til den andre hovedtypen systemarkitektur, "Filpartisjonering". I denne arkitekturen laster PC-en (eller "arbeidsstasjonen") ned filer fra en spesialisert "filserver" og administrerer deretter applikasjonen (inkludert data) lokalt. Dette fungerer bra når den delte databruken, dataoppdateringen og mengden data som skal overføres er liten. Imidlertid ble det snart klart at fildeling i økende grad tettet nettverket, og applikasjoner ble mer komplekse og krever at mer og mer data overføres i begge retninger.

Problemene knyttet til applikasjoner som behandler data over en fil som ble delt over et nettverk førte til utviklingen av klient-server-arkitektur på begynnelsen av 1980-tallet. I denne tilnærmingen erstattes filserveren av en databaseserver, som, i stedet for bare å overføre og lagre filer til tilkoblede arbeidsstasjoner (klienter), mottar og faktisk utfører forespørsler om data, og returnerer kun resultatet som klienten ber om. Ved å overføre bare dataene som klienten ber om i stedet for hele filen, reduserer denne arkitekturen nettverksbelastningen betydelig. Dette gjorde det mulig å lage et system der flere brukere kunne oppdatere data gjennom GUI-grensesnitt knyttet til en enkelt delt database.

Vanligvis brukes enten Structured Query Language (SQL) eller Remote Procedure Call (RPC) for å utveksle data mellom klienten og serveren. Flere grunnleggende alternativer for å organisere en klient-server-arkitektur er beskrevet nedenfor.

I en tolagsarkitektur deles belastningen mellom serveren (som huser databasen) og klienten (som huser brukergrensesnittet). Vanligvis er de plassert på forskjellige fysiske maskiner, men dette er ikke et krav. Forutsatt at lagene er logisk atskilt, kan de plasseres (for eksempel for utvikling og testing) på samme datamaskin (fig. 1).

Figur 1: Tolagsarkitektur

Fordelingen av applikasjonslogikk og databehandling i denne modellen var og er fortsatt problematisk. Hvis klienten er "smart" og utfører hovedbehandlingen av dataene, oppstår det problemer knyttet til distribusjon, installasjon og vedlikehold av applikasjonen, siden hver klient trenger sin egen lokale kopi av programvaren. Hvis klienten "dum" må applikasjonslogikken og behandlingen implementeres i databasen, og derfor blir den helt avhengig av den spesifikke DBMS som brukes. Uansett må hver klient registrere seg og, avhengig av tilgangsrettighetene han får, utføre visse funksjoner. Imidlertid var den to-lags klient-server-arkitekturen Bra valg, da antallet brukere var relativt lite (opptil ca. 100 samtidige brukere), men med veksten av brukere fulgte en rekke restriksjoner på bruken av denne arkitekturen.

Ytelse: Etter hvert som antall brukere øker, begynner ytelsen å bli dårligere. Ytelsesforringelsen er direkte proporsjonal med antall brukere, som hver har sin egen tilkobling til serveren, noe som betyr at serveren må opprettholde alle disse tilkoblingene (ved å bruke "Keep-Alive"-meldinger) selv når databasen ikke brukes .

Sikkerhet: Hver bruker må ha sin egen individuelle tilgang til databasen, og ha rettighetene til å betjene applikasjonen. For å gjøre dette er det nødvendig å lagre tilgangsrettighetene for hver bruker i databasen. Når du trenger å legge til funksjonalitet til en applikasjon og du må oppdatere brukerrettigheter.

Funksjonalitet: Uavhengig av hvilken type klient som brukes, må mesteparten av databehandlingen ligge i databasen, noe som betyr at den er helt avhengig av egenskapene som tilbys i databasen av produsenten. Dette kan sterkt begrense funksjonaliteten til applikasjonen siden forskjellige databaser støtter forskjellige funksjoner, bruk ulike språk programmere og til og med implementere grunnleggende funksjoner som triggere på forskjellige måter.

Portabilitet: Tolagsarkitektur er så avhengig av den spesifikke databaseimplementeringen som portabilitet eksisterende applikasjoner for ulike DBMS-er, blir et alvorlig problem. Dette gjelder spesielt for applikasjoner i vertikale markeder der valget av DBMS ikke bestemmes av leverandøren.

Men til tross for dette har tolagsarkitektur funnet nytt liv i Internett-æraen. Det kan fungere godt i et frakoblet miljø der brukergrensesnittet er dumt (f.eks. en nettleser). Imidlertid representerer denne implementeringen på mange måter en tilbakevending til den opprinnelige stormaskinarkitekturen.

I et forsøk på å overvinne begrensningene til den beskrevne tolagsarkitekturen generell disposisjon ovenfor ble et tilleggsnivå introdusert. Denne arkitekturen er en standard klient-server-modell med en tre-lags arkitektur. Formålet med det ekstra laget (ofte kalt "midt" eller "regler" laget) er å administrere applikasjonskjøring og databaseadministrasjon. Som med modellen med to nivåer, kan nivåene være plassert enten på forskjellige datamaskiner (Figur 2), eller på én datamaskin i testmodus.

Figur 2: Tre-lags arkitektur

Ved å introdusere den midterste raden ble begrensningene til tolagsarkitekturen i stor grad eliminert, noe som resulterte i et mye mer fleksibelt og skalerbart system. Siden klienter nå bare kobler til applikasjonsserveren og ikke direkte til dataserveren, fjernes byrden med å opprettholde tilkoblinger, og det samme gjelder behovet for å implementere applikasjonslogikk i databasen. Databasen kan nå kun utføre funksjonene med å lagre og hente data, og oppgaven med å motta og behandle søknader kan utføres av gjennomsnittlig nivå tre-lags arkitektur. Utviklingen av operativsystemer, som inkluderte elementer som tilkoblingspooling, køer og distribuert transaksjonsbehandling, styrket (og forenklet) utviklingen av mellomlaget.

Merk at i denne modellen kontrollerer ikke applikasjonsserveren brukergrensesnittet, og brukeren spør heller ikke direkte i databasen. I stedet lar det flere kunder dele forretningslogikk, beregninger og tilgang til datasøkemotorer. Hovedfordelen er at klienten krever mindre programvare og ikke lenger trenger en direkte tilkobling til databasen, noe som forbedrer sikkerheten. Følgelig er applikasjonen mer skalerbar, kostnadene for støtte og installasjon på én server er mye lavere enn for å vedlikeholde applikasjoner direkte på klientens datamaskin eller til og med på en to-lags arkitektur.

Det er mange varianter av de grunnleggende tre-nivå modellene designet for å yte ulike funksjoner. Disse inkluderer distribuert transaksjonsbehandling (hvor flere DBMS-er oppdateres i samme protokoll), meldingsbaserte applikasjoner (der applikasjoner ikke kommuniserer i sanntid) og kompatibilitet på tvers av plattformer (Object Request Broker eller "ORB"-applikasjoner).

Flerlagsarkitektur eller N-lagsarkitektur

Med utviklingen av Internett-applikasjoner på bakgrunn av en generell økning i antall brukere, ble den grunnleggende tre-nivå klient-server-modellen utvidet ved å introdusere flere nivåer. Slike arkitekturer kalles "multi-tier" og består typisk av fire lag (Figur 3), hvor en server i nettverket er ansvarlig for å håndtere forbindelsen mellom nettleserklienten og applikasjonsserveren.Fordelen er at flere webservere kan koble seg sammen til en enkelt applikasjonsserver, og dermed øke behandlingen av et større antall samtidig tilkoblede brukere.

Figur 3: N-tier arkitektur

Nivåer vs. lag

Disse begrepene blir (dessverre) ofte forvekslet. Det er imidlertid stor forskjell mellom dem og de har en viss betydning. Hovedforskjellen er at lagene er i det fysiske laget og lagene er i det logiske laget. Med andre ord, laget, teoretisk, kan distribueres uavhengig på en separat datamaskin, og laget er en logisk inndeling i laget (Figur 4). Den typiske trelagsmodellen beskrevet ovenfor inneholder vanligvis minst syv lag, atskilt på tvers av alle tre nivåene.

Det viktigste å huske på med en lagdelt arkitektur er at forespørsler og svar fra hver tråd i én retning går gjennom alle lag, og at lag aldri kan hoppes over. Således, i modellen vist i figur 4, er det eneste laget som kan få tilgang til lag "E" (datatilgangslaget) lag "D" (regellaget). På samme måte kan lag "C" (applikasjonsvalideringslaget) bare svare på forespørsler fra lag "B" (feilhåndteringslaget).

Figur 4: Rader delt inn i logiske lag