Uansett hvordan konseptet "klient-server"-arkitektur er definert (og det er mange slike definisjoner i litteraturen), er dette konseptet basert på en distribuert databehandlingsmodell. I det mest generelle tilfellet, under klient og server to samvirkende prosesser er forstått, hvorav den ene er en leverandør av en tjeneste for den andre.

Begrepet "klient-server" betyr en programvarepakkearkitektur der funksjonsdelene samhandler i henhold til et "forespørsel-svar"-skjema. Hvis vi vurderer to samvirkende deler av dette komplekset, utfører en av dem (klienten) en aktiv funksjon, det vil si initierer forespørsler, og den andre (serveren) reagerer passivt på dem. Etter hvert som systemet utvikler seg, kan rollene endres, for eksempel vil en bestemt programvareenhet samtidig utføre funksjonene til en server i forhold til en enhet og en klient i forhold til en annen.

Server - en eller flere flerbrukerprosessorer med et enkelt minnefelt, som, i samsvar med brukerens behov, gir dem funksjonene databehandling, kommunikasjon og tilgang til databaser. Server du kan ringe et program som gir noen tjenester til andre programmer. Eksempler på servere er Apache webserver, databaseservere er MySQL, ORACLE, nettverksfilsystemer og Windows-skrivere.

Klient er en arbeidsstasjon for én bruker, som gir registreringsmodus og andre funksjoner for beregning, kommunikasjon, tilgang til databaser etc. nødvendig på hans arbeidsplass.En klient kan kalles et program som bruker tjenesten som serverprogrammet gir. Eksempler på klienter - MSIE (MS Internet Explorer), ICQ-klient.

Ofte refererer folk ganske enkelt til datamaskinen som kjører et av disse programmene som en klient eller server.

I hovedsak er klienten og serveren roller som programmer spiller. Klienter og servere kan være fysisk plassert på samme datamaskin. Ett og samme program kan være både en klient og en server samtidig, osv ... dette er bare roller.

Hvis vi trekker en analogi med samfunnet - en bank eller en butikk - "servere". De yter en slags service til sine kunder. Men en bank kan samtidig være kunde i et annet firma osv.

Client - Server Processing - Et miljø der applikasjonsbehandling er fordelt mellom klient og server. Ofte er maskiner av forskjellige typer involvert i behandlingen, og klienten og serveren kommuniserer med hverandre ved hjelp av et fast sett med standard utvekslingsprotokoller og prosedyrer for tilgang til eksterne plattformer.

DBMS fra personlige datamaskiner (som Clipper, DBase, FoxPro, Paradox, Clarion har nettverksversjoner som ganske enkelt deler databasefiler med de samme formatene for en PC, mens de implementerer nettverkslåser for å avgrense tilgang til tabeller og poster. arbeidet gjøres på en PC, serveren brukes rett og slett som en delt fjernstasjon med stor kapasitet, og denne måten å gjøre ting på risikerer å miste data ved maskinvarefeil.

Sammenlignet med slike systemer har systemer bygget i Client-Server-arkitekturen følgende fordeler:

lar deg øke størrelsen og kompleksiteten til programmer som kjører på en arbeidsstasjon;


gir overføring av de mest tidkrevende operasjonene til serveren, som er en maskin med større datakraft;


reduserer til et minimum muligheten for å miste informasjon i databasen ved å bruke interne databeskyttelsesmekanismer tilgjengelig på serveren, som for eksempel transaksjonssporingssystemer, tilbakeføring etter en feil, midler for å sikre dataintegritet;


flere ganger reduserer mengden informasjon som overføres over nettverket.


I en klient-server-arkitektur gir databaseserveren ikke bare tilgang til de delte dataene, men tar seg også av all behandlingen av disse dataene. Klienten sender forespørsler til serveren om å lese eller endre data, som er formulert i SQL-språket. Serveren selv gjør alle nødvendige endringer eller valg, mens den kontrollerer integriteten og konsistensen til dataene, og sender resultatene i form av et sett med poster eller en returkode til klientens datamaskin.


Den lar deg fordele databelastningen optimalt mellom klienten og serveren, noe som også påvirker mange egenskaper ved systemet: kostnad, ytelse, støtte.


1.2. Historie…


Arkitekturen og begrepet "klient-server" ble først brukt på begynnelsen av 1980-tallet. De første klient-server-applikasjonene var databaser.


Før det var det ingen klar separasjon - programmet gjorde som regel alt av seg selv - inkludert å jobbe med data i filsystemet, presentere data for brukeren osv. Over tid vokste volumet og kritikaliteten til data for virksomheten, og dette over tiden begynte å gi opphav til problemer (ytelse, sikkerhet annet).


Så fant de ut at det ville være praktisk å legge databasen på en kraftig separat datamaskin (server) og la denne databasen brukes av mange små databrukere (klienter) gjennom nettverket, noe som ble gjort.


I hovedsak ble eksplosjonen i klient-server-teknologi drevet av IBMs oppfinnelse av et enkelt spørrespråk for relasjonsdatabaser, SQL. SQL er den universelle standarden for arbeid med databaser i dag. Nylig fortsetter denne "eksplosjonen" oppfinnelsen av Internett, der bokstavelig talt hver interaksjon finner sted på en klient-server-arkitektur.


1.3. Protokoller


Serveren og klienten i nettverket «snakker» til hverandre på et «språk» (i ordenes videste betydning) som er forståelig for begge parter. Dette "språket" kalles en protokoll.


Når det gjelder en bank, kan protokollen kalles skjemaene som klienten fyller ut.


I vårt tilfelle, eksempler på protokoller:


FTP (File Transfer Protocol)


HTTP (Hyper Text Transfer Protocol)


SMTP (Simple Mail Transfer Protocol)


IP (Internettprotokoll)


MySQL Client / Server Protocol


Merk at protokollene kan være på forskjellige nivåer. Klassifiseringssystemer for nivåer kan være forskjellige, men en av de mest kjente linjene er OSI (Open Systems Interconnection), der det er 7 nivåer.


For eksempel er HTTP applikasjonen (syvende - høyeste) lagprotokoll, og IP er nettverksprotokollen (tredje) lag.


1.4. Distribusjon av funksjoner i klient-server-arkitekturen


I den klassiske klient-server-arkitekturen må du fordele de tre hoveddelene av applikasjonen i to fysiske moduler. Vanligvis er datalagringsprogramvare plassert på en server (for eksempel en databaseserver), brukergrensesnittet er på klientsiden, men databehandlingen må distribueres mellom klient- og serverdelen. Dette er hovedulempen med tolagsarkitekturen, hvorfra flere ubehagelige funksjoner følger, som i stor grad kompliserer utviklingen av klient-serversystemer.


Utviklingsprosessen av slike systemer er ganske komplisert og en av de viktigste oppgavene er beslutningen om hvordan applikasjonsfunksjonaliteten skal fordeles mellom klient- og serverdelen. Ved å prøve å løse dette problemet får utviklere tolags-, trelags- og flerlagsarkitekturer. Alt avhenger av hvor mange mellomkoblinger som er inkludert mellom klienten og serveren.


Hovedoppgaven som klientapplikasjonen løser er å gi et grensesnitt med brukeren, det vil si å legge inn data og presentere resultatene i en brukervennlig form, og å administrere applikasjonsscenarioene.


Hovedfunksjonene til en server-DBMS er å sikre pålitelighet, konsistens og sikkerhet for data, administrere klientforespørsler og raskt behandle SQL-spørringer.


All logikken til applikasjonen - applikasjonsoppgaver, forretningsregler - i en tolagsarkitektur fordeles av utvikleren mellom to prosesser: klienten og serveren (fig. 1).


Til å begynne med ble de fleste av applikasjonens funksjoner håndtert av klienten; serveren var kun opptatt av å behandle SQL-spørringer. Denne arkitekturen kalles "tykk klient - tynn server".


Fremveksten av muligheten til å lage lagrede prosedyrer på serveren, det vil si kompilerte programmer med intern arbeidslogikk, førte til en tendens til å overføre flere og flere funksjoner til serveren. Serveren ble tykkere og klienten ble tynnere.


Denne løsningen har åpenbare fordeler, for eksempel er den lettere å vedlikeholde, siden alle endringer bare må gjøres på ett sted - på serveren.


modellene diskutert ovenfor har følgende ulemper.


1. "Tykk" klient:


- kompleksiteten i administrasjonen;


- programvareoppdateringen blir mer komplisert, siden den må byttes ut samtidig i hele systemet;


- maktfordelingen blir mer komplisert, siden differensieringen av tilgang ikke skjer i henhold til handlinger, men i henhold til tabeller;


- nettverket er overbelastet på grunn av overføring av rådata over det;


- svak databeskyttelse, siden det er vanskelig å fordele fullmakter på riktig måte.


2. "Tykk" server:


- implementeringen blir mer komplisert, siden språk som PL / SQL ikke er tilpasset utviklingen av slik programvare, og det er ingen gode feilsøkingsverktøy;


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


- programmer skrevet på DBMS-språk fungerer vanligvis ikke pålitelig nok; en feil i dem kan føre til feil på hele databaseserveren;


- de resulterende programmene er fullstendig ikke-bærbare til andre systemer og plattformer.


For å løse problemene ovenfor, brukes en klient-server-arkitektur på flere nivåer (tre eller flere nivåer). flerlags klient-server-arkitektur kan betydelig forenkle distribuert databehandling, noe som gjør dem ikke bare mer pålitelige, men også rimeligere.


Språket som lagrede prosedyrer er skrevet på er imidlertid ikke kraftig og fleksibelt nok til å enkelt implementere kompleks applikasjonslogikk.


Så var det en tendens til å overlate utførelsen av anvendte oppgaver og forretningsregler til en separat komponent av applikasjonen (eller flere komponenter), som kan kjøres både på en dedikert datamaskin - applikasjonsserveren, og på samme datamaskin som databaseserveren løper. Dette er hvordan de tre-lags og multi-lag klient-server-arkitekturene oppsto.





Ris. 1. Fordeling av funksjoner mellom klient og server


Det har dukket opp spesiell programvare (programvare) av mellomlaget, som skal sikre felles funksjon av mange komponenter i en slik flerkomponentapplikasjon. Slike applikasjoner er fleksible, skalerbare, men vanskelige å utvikle.



BIBLIOGRAFI

1. Informatikk / Ed. N.V. Makarova. –M .: Finans og statistikk, 1998.
   

   V.V. Evdokimov og annen økonomisk informatikk. SPb .: Peter, 2004.
   

   S. I. Kazakov Grunnleggende om nettverksteknologier - M .: Radio og kommunikasjon, 2004.
   

   Kogalovsky M.R., Teknologi for databaser på personlige datamaskiner, - M .: Finans og statistikk, 2003.
   

   Popov V.V. Grunnleggende om datateknologi. –M .: Finans og statistikk, 2001.
   

   Figurnov V.E. IBM PC for brukeren. M., 2000.
   

OPERATIVSYSTEM MS-DOS. GRUNNLEGGENDE KONSEPT OG KOMMANDOER GRUNNLEGGENDE KONSEPT: DATABASE, DBMS, ESSENS, ATRIBUTE, KOMMUNIKASJON (EN-TIL-EN, EN-TIL-MANGE, MANGE-TIL-MANGE), RELASJON, PRIMÆR NØKKEL

Oversatt fra engelsk: Chernobay Yu.A.

Utvikling av klient-server systemer

Arkitekturen til datasystemet har utviklet seg sammen med maskinvarens evne til å bruke kjørbare applikasjoner. 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 dumme terminaler, som overførte instruksjoner, fanget opp tastetrykket, til serveren og viste resultatene av å utføre instruksjonene til brukeren. Slike applikasjoner var typiske, og til tross for den relativt store prosessorkraften til serverdatamaskiner, var de generelt relativt trege og upraktiske å bruke, på grunn av behovet for å overføre hvert tastetrykk til serveren.

Introduksjonen og utbredt bruk av PC-en, med sin egen prosessorkraft og grafiske brukergrensesnitt, gjorde at applikasjoner ble mer komplekse, og utvidelsen av nettverkssystemer førte til den andre hovedtypen systemarkitektur, "Filpartisjonering". I denne arkitekturen laster PC-en (eller "arbeidsstasjonen") ned filer fra en dedikert "filserver" og administrerer deretter applikasjonen (inkludert data) lokalt. Dette fungerer bra når det er lite bruk av delte data, dataoppdatering og mengden data som skal overføres. Imidlertid ble det snart klart at fildeling i økende grad tettet opp nettverket, og applikasjoner ble mer komplekse og krevde at mer og mer data ble overført i begge retninger.

Problemene knyttet til behandling av data av applikasjoner gjennom 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 databaseserveren, som, i stedet for bare å overføre og lagre filer til de tilkoblede arbeidsstasjonene (klientene), mottar og faktisk utfører forespørsler om data, og returnerer kun resultatet som klienten ber om. Ved å overføre kun data som klienten ber om og ikke hele filen, reduserer denne arkitekturen belastningen på nettverket betydelig. Dette tillot opprettelsen av 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 å kommunisere mellom klient og server. Flere grunnleggende alternativer for å organisere en klient-server-arkitektur er beskrevet nedenfor.

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

Figur 1: To-lags arkitektur

Fordelingen av applikasjonslogikk og databehandling i denne modellen har vært og er fortsatt problematisk. Hvis klienten er "smart" og utfører hovedbehandlingen av dataene, er det problemer knyttet til distribusjon, installasjon og vedlikehold av applikasjonen, siden hver klient trenger sin egen lokale kopi av programvaren. Hvis klienten er "dum" må applikasjonen av logikk og prosessering implementeres i databasen, og derfor blir den helt avhengig av den spesifikke DBMS som brukes. I alle fall må hver klient registrere seg og, avhengig av tilgangsrettighetene han mottar, utføre visse funksjoner. Ikke desto mindre var tolags klient-server-arkitekturen en god løsning når antallet brukere var relativt lite (opptil ca. 100 samtidige brukere), men etter hvert som brukerne vokste, dukket det opp en rekke restriksjoner på bruken av denne arkitekturen.

Ytelse: Etter hvert som antallet brukere vokser, begynner ytelsen å bli dårligere. Nedgangen i ytelse 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"-meldingen) selv når databasen er ikke blir tilgjengelig.

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

Funksjonalitet: Uansett hvilken type klient som brukes, må mesteparten av databehandlingen være i databasen, noe som betyr at den avhenger helt av mulighetene som tilbys i databasen av produsenten. Dette kan sterkt begrense funksjonaliteten til applikasjonen, siden forskjellige databaser støtter forskjellig funksjonalitet, bruker forskjellige programmeringsspråk og til og med implementerer grunnleggende verktøy som triggere annerledes.

Mobilitet: Tolagsarkitekturen er så avhengig av den spesifikke databaseimplementeringen at portering av eksisterende applikasjoner til forskjellige DBMS-er blir en stor utfordring. Dette gjelder spesielt for applikasjoner i vertikale markeder der valget av DBMS ikke bestemmes av leverandøren.

Men til tross for dette fant tolagsarkitekturen nytt liv i internettalderen. Det kan fungere godt i frakoblede miljøer der brukergrensesnittet er "dumt" (f.eks. en nettleser). Imidlertid representerer denne implementeringen på mange måter en retur til den opprinnelige stormaskinarkitekturen.

I et forsøk på å overvinne begrensningene til tolagsarkitekturen som er skissert ovenfor, har et ekstra lag blitt introdusert. Denne arkitekturen er standard klient-server-modell med en tre-lags arkitektur. Formålet med det ekstra laget (ofte referert til som "midt"- eller "regler"-laget) er å kontrollere applikasjonskjøring og databaseadministrasjon. Som med to-nivåmodellen, kan nivåene være plassert enten på forskjellige datamaskiner (Figur 2), eller på samme datamaskin i testmodus.

Figur 2: Tre-lags arkitektur

Med introduksjonen av den midterste raden har begrensningene i tolagsarkitekturen i stor grad blitt fjernet, noe som har resultert 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 er behovet for å implementere applikasjonslogikk i databasen. Databasen kan nå kun utføre funksjonene med å lagre og hente data, og oppgaven med å motta og behandle forespørsler kan utføres av den midterste nivået i trelagsarkitekturen. Utviklingen av operativsystemer, inkludert elementer som pooling av tilkoblinger, kø og distribuert transaksjonsbehandling, har styrket (og forenklet) utvikling på mellomnivå.

Merk at i denne modellen kontrollerer ikke applikasjonsserveren brukergrensesnittet, og brukeren foretar heller ikke spørsmål direkte til 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 øker sikkerheten. Følgelig er applikasjonen mer skalerbar, støtte- og installasjonskostnadene på en enkelt server er betydelig lavere enn for å vedlikeholde applikasjoner direkte på klientens datamaskin eller til og med på en to-lags arkitektur.

Det er mange variasjoner på de grunnleggende tre-lags modellene, designet for å tjene forskjellige funksjoner. Disse inkluderer distribuert transaksjonsbehandling (der 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).

Lagdelt arkitektur eller N-lags arkitektur

Med utviklingen av Internett-applikasjoner på bakgrunn av en generell økning i antall brukere, har den grunnleggende tre-lags klient-server-modellen blitt utvidet ved å introdusere flere lag. Disse arkitekturene omtales som «tiered» arkitekturer, og de har vanligvis fire lag (Figur 3) hvor på nettverket serveren er ansvarlig for å håndtere forbindelsen mellom klientnettleseren og applikasjonsserveren. Fordelen er at flere webservere kan koble seg til til samme applikasjonsserver og dermed øke håndteringen av flere samtidig tilkoblede brukere.

Figur 3: N-Tier-arkitektur

Lag kontra lag

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

Det viktigste å huske om lagdelt arkitektur er at forespørsler og svar fra hver flyt i samme 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 referere til lag "E" (datatilgangslag) lag "D" (lag av regler). På samme måte kan lag "C" (applikasjonsvalideringslag) bare svare på forespørsler fra lag "B" (feilhåndteringslag).

Figur 4: Rader delt inn i logiske lag

Klient-server to-lags IC-arkitektur

Den viktigste forskjellen mellom klient-server-arkitekturen og fil-server-arkitekturen er abstraksjonen fra den interne representasjonen av data (fysisk dataskjema). Med denne arkitekturen manipulerer klientprogrammer data på logisk nivå. For å implementere klient-server-arkitekturen brukes vanligvis flerbruker-DBMS-er, for eksempel Oracle eller Microsoft SQL Server.

Klient-server informasjonssystemet består av tre hovedkomponenter: serverprogramvare; sluttbrukerprogramvare; mellomvare (Figur 1.7). Serverprogramvaren, i tillegg til databaseadministrasjon, gir kundeservice.

Disse DBMS-ene har låsemekanismer og tilgangskontroller for flere brukere som beskytter data mot den iboende risikoen ved samtidig tilgang. I tillegg må databaseserveren beskytte data mot uautorisert tilgang, optimalisere databasespørringer, sikre dataintegritet og kontrollere gjennomføringen av transaksjoner. I en klient-server-organisasjon kan klienter være tynne nok, og serveren må være tykk nok til å møte behovene til alle klienter Sluttbrukerprogramvare inkluderer applikasjonsutviklingsverktøy og rapportgeneratorer, inkludert regneark og tekstbehandlere Med denne programvaren kan brukere etablere en forbindelse med serveren, danne spørringer som automatisk genereres til SQL-spørringer og sendes til serveren. Serveren godtar og behandler forespørsler, og sender deretter resultatene til klientene. Mellomvare er den delen av klient-server-systemet som kobler sluttbrukerens programvare til serveren.

Bruken av klient-server-arkitekturen gjorde det mulig å skape pålitelig (med tanke på dataintegritet) multi-user IS med en sentralisert database, uavhengig av maskinvare- (og ofte programvare) delen av databaseserveren og støttet et grafisk brukergrensesnitt på klientstasjoner koblet til et lokalt nettverk. Dessuten har kostnadene ved å utvikle applikasjoner blitt betydelig redusert.

Denne arkitekturen har to nivåer, hvor det karakteristiske trekk er at klientprogrammene arbeider med data gjennom forespørsler til serverprogramvaren, og de grunnleggende funksjonene til applikasjonen er delt mellom klienten og serveren (Figur 1.8).

Fordelene med denne arkitekturen inkluderer:

· Full støtte for flerbrukerarbeid;

· Sikre dataintegritet.

Det er tilrådelig å bruke en tolagsarkitektur i bedrifter med flere dusin brukere, siden serveroperativsystemet, når det betjener et stort antall klienter, er for overbelastet med å administrere flere tilkoblinger til serveren.

Ulempene med en to-lags klient-server-arkitektur er:

· Forretningslogikken til applikasjonene forble i klientprogramvaren. Hver gang algoritmene endres, må brukerprogramvaren oppdateres på hver klient.

· Høye krav til båndbredden til kommunikasjonskanaler med serveren, noe som hindrer bruk av klientstasjoner annet enn i lokalnettet.

· Svak beskyttelse av data mot hacking, spesielt fra skruppelløse brukere av systemet.

· Høy kompleksitet av administrasjon og konfigurasjon av arbeidsstasjoner til systembrukere.

· Behovet for å bruke kraftige PC-er på klientsteder.

· Høy kompleksitet av systemutvikling på grunn av behovet for å utføre forretningslogikk og gi et brukergrensesnitt i ett program.

DB, om strukturell SQL spørringsspråk(Structured Query Language), som er industristandarden i verden av relasjonsdatabaser. Den eksterne serveren mottar forespørselen og videresender den til SQL-databasetjeneren. SQL Server er et spesielt program som administrerer en ekstern database. SQL - serveren gir tolkning av spørringen, dens utførelse i databasen, dannelsen av spørringens utførelsesresultat og utstedelsen 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 trengs av klienten over nettverket. Som et resultat reduseres belastningen på nettverket. Siden forespørselen utføres på samme sted som dataene er lagret (på serveren), er det ikke nødvendig å sende store datapakker. I tillegg optimaliserer SQL-serveren, hvis mulig, den mottatte spørringen slik at den utføres på kortest mulig tid med minst mulig overhead [[3.2], [3.3]]. systemet er vist i fig. 3.3.

Alt dette øker systemytelsen og reduserer ventetiden på søkeresultatet. Når serveren utfører spørringer, økes graden av datasikkerhet betydelig, siden dataintegritetsreglene er definert i databasen på serveren og er enhetlige for alle applikasjoner som bruker denne databasen. Dette eliminerer muligheten for å definere motstridende regler for å opprettholde integritet. Kraftig transaksjonsapparat, støttet av SQL-servere, gjør det mulig å ekskludere samtidige endringer av samme data fra 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

• Det er et lokalt nettverk som består av klientdatamaskiner, som hver har en klientapplikasjon installert for å fungere med databasen.
• På hver av klientdatamaskinene kan brukere kjøre applikasjonen. Ved å bruke brukergrensesnittet fra applikasjonen, starter den et kall 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 dataene som ligger på serveren, som et resultat av at all databehandling utføres på serveren og bare resultatet av spørringen kopieres til klientdatamaskinen. Dermed returnerer DBMS resultatet til applikasjonen.

La oss se hvordan differensieringen av funksjoner mellom serveren og klienten ser ut.

• Klientapplikasjonsfunksjoner:
  • Sender forespørsler til serveren.
  • Tolke resultatene av forespørsler 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 spørringer til databasen.
  • Sender resultater til klientapplikasjonen.
  • Tilveiebringelse av et sikkerhetssystem og adgangskontroll.
  • Databaseintegritetsstyring.
  • Implementering av stabiliteten til flerbrukermodusen.

Den såkalte "industrielle" DBMS fungerer i klient-server-arkitekturen. De kalles industrielle fordi det er DBMS i denne klassen som kan sikre driften av informasjonssystemer i skalaen til 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 SQL-serveren av en enkelt ansatt eller en gruppe ansatte (SQL-serveradministratorer). De administrerer de fysiske egenskapene til databaser, utfører optimalisering, tuning og omdefinering ulike databasekomponenter, opprette nye databaser, modifisere eksisterende osv., og også gi privilegier (tillatelser til å få tilgang til et visst nivå til spesifikke databaser, SQL-server) til ulike brukere [[3.2]].

La oss vurdere hovedfordelene med denne arkitekturen sammenlignet med "filserver"-arkitekturen:

• Nettverkstrafikken er betydelig redusert.
• Kompleksiteten til klientapplikasjoner reduseres (mesteparten av belastningen faller på serversiden), og følgelig reduseres maskinvarekravene til klientdatamaskiner.
• Tilstedeværelsen av et spesielt programvareverktøy - en SQL-server - fører til at en betydelig del av design- og programmeringsoppgavene allerede er løst.
• Integriteten og sikkerheten til databasen er betydelig forbedret.

Ulempene inkluderer høyere økonomiske kostnader for maskinvare og programvare og det faktum at et stort antall klientdatamaskiner plassert på forskjellige steder forårsaker visse vanskeligheter med rettidig oppdatering av klientapplikasjoner på alle klientdatamaskiner. Likevel har "klient-server"-arkitekturen vist seg godt i praksis, for øyeblikket er det og fungerer 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-lag eller multi- tre-lags arkitektur? Nå, når du endrer forretningslogikk, trenger du ikke lenger å endre klientapplikasjoner og oppdatere dem for alle brukere. I tillegg er kravene til brukerutstyr minimert.

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

• Databasen i form av et sett med filer ligger på harddisken til en dedikert datamaskin (nettverksserver).
• DBMS er også plassert på nettverksserveren.
• Det er en dedikert applikasjonsserver som er vert for forretningsanalyseprogramvaren (forretningslogikk) [[3.1]].
• Det er mange klientdatamaskiner, som hver har en såkalt «tynn klient» – en klientapplikasjon som implementerer brukergrensesnittet.
• På hver av klientdatamaskinene kan brukere kjøre en tynnklientapplikasjon. Ved å bruke brukergrensesnittet fra applikasjonen, starter den et anrop til forretningsanalyseprogramvaren som ligger på applikasjonsserveren.
• Applikasjonsserveren analyserer brukerens krav 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 dataene på serveren, som et resultat av at resultatet av spørringen blir kopiert til applikasjonsserveren.
• Applikasjonsserveren returnerer resultatet til klientapplikasjonen (til brukeren).
• Applikasjonen, ved hjelp av brukergrensesnittet, viser resultatet av spørringene.

Klient-server-teknologi regnes som en av "hvalene" i den moderne verden av datanettverk. Men oppgavene den ble designet for er i ferd med å bli en saga blott. Nye oppgaver og teknologier krever en nytenkning av prinsippene for klient-server-systemer. En slik teknologi er World Wide Web. Webteknologi er en utvikling av klient-server-arkitekturen, dvs. én klient kan koble til mange servere. Informasjonssystemet må i tillegg til grensesnittet ha nivåer av databehandling og lagring. Utfordringen for Internett-designere er å justere nettet 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.

Det klassiske klient-serversystemet fungerer i henhold til "request-response"-skjemaet (to-lags arkitektur). Klienten utfører en aktiv funksjon (forespørsler), serveren reagerer passivt på dem.

Ethvert informasjonssystem må ha minst tre funksjonelle deler - datalagringsmoduler, 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 data, kan du endre brukergrensesnittet på en slik måte at de samme dataene vises i form av tabeller, grafer eller histogrammer. Uten å endre datapresentasjons- og lagringsprogrammene kan du endre behandlingsprogrammene ved å endre fulltekstsøkealgoritmen. Uten å endre datapresentasjons- og behandlingsprogrammene kan du endre datalagringsprogramvaren ved å bytte til et annet filsystem.

I den klassiske klient-server-arkitekturen er de tre hoveddelene av applikasjonen fordelt over to fysiske moduler. Vanligvis er lagringsprogramvaren 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. Å dele databehandlingsalgoritmer krever synkronisering av handlingene til begge deler av systemet. For å unngå inkonsistens mellom de ulike elementene i arkitekturen, forsøkes det å utføre databehandling på en av to deler – enten på klientsiden ("tykk" klient), eller på serveren ("tynn" klient, eller "2.5") -tier klient-server"). Hver tilnærming har en ulempe: I det første tilfellet nettverket er urettmessig overbelastet; rå (redundante) data overføres gjennom det, støtten og endringen av systemet blir mer komplisert, siden utskifting av beregningsalgoritmen eller korrigering av en feil krever 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 systemet med behandlingsinformasjon på serveren helt umulig å overføre til en annen plattform.

De fleste moderne Rapid Application Development (RAD) verktøy, som fungerer med ulike databaser, implementerer den første modellen ("tykke" klienten), som gir et grensesnitt til databaseserveren gjennom SQL-språket. Dette alternativet, i tillegg til de ovennevnte ulempene, har lavt sikkerhetsnivå.

For eksempel. I banksystemer har alle tellere rett til å skrive til hovedtabellen i regnskapssystemet. I tillegg er dette systemet nesten umulig å oversette til webteknologi, siden spesialisert klientprogramvare brukes for å få tilgang til databaseserveren.

Ulemper med modellene diskutert ovenfor:

1. "Tykk" klient

F kompleksiteten i administrasjonen;

F Vanskeligheter med å oppdatere programvaren, pga den må skiftes ut samtidig i hele systemet;

F kompleksitet i maktfordelingen, siden differensieringen av tilgang ikke skjer i henhold til handlinger, men i henhold til tabeller;

F nettverksoverbelastning på grunn av overføring av rådata over det;

F svak databeskyttelse.

2. "Tykk" server

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

ð ytelsen til programmer i 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;

ð Programmene opprettet på denne måten er fullstendig ikke-bærbare til andre systemer og plattformer.

For å løse problemene ovenfor, brukes multilevel (tre eller flere) klient-server-modeller.

Klient-tjener-arkitekturer i lag – distribuerer databehandlingsmoduler mer intelligent som kjører på én eller flere separate servere.

Disse programvaremodulene utfører funksjonene server for brukergrensesnitt og klient- for databaseservere. I tillegg kan ulike applikasjonsservere samhandle med hverandre for mer nøyaktig å dele systemet inn i funksjonelle blokker som utfører spesifikke roller.

For eksempel. Du kan velge en personaladministrasjonsserver som skal utføre alle funksjonene som er nødvendige for personaladministrasjon. Ved å knytte en separat database til den, kan du skjule alle implementeringsdetaljene til denne serveren for brukere, slik at du kun får tilgang til dens offentlige funksjoner. Et slikt system er lettere å tilpasse til nettet, fordi det er lettere å designe html-skjemaer for brukertilgang til spesifikke databasefunksjoner enn til alle data.

I trelagsmodellen er ikke den "tynne" klienten overbelastet med databehandlingsfunksjoner, men spiller hovedrollen som et system for å presentere informasjon fra applikasjonsserveren. (Dette grensesnittet er implementert ved hjelp av standard webteknologiverktøy – 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.

Den tre-lags klient-server-modellen lar deg mer nøyaktig tildele brukertillatelser, siden de mottar rettigheter ikke til selve databasen, men til visse funksjoner på applikasjonsserveren, noe som øker sikkerheten til systemet.

Flerlags klient-server-systemer kan enkelt konverteres til webteknologi – alt du trenger å gjøre er å erstatte klientsiden med en universell nettleser, og supplere applikasjonsserveren med en webserver og smår. I et trelagssystem overføres mye informasjon over kommunikasjonskanalen mellom applikasjonsserveren og databasen, mens beregningene ikke går langsommere, siden det brukes raskere linjer for å koble sammen disse elementene. Dette er rimeligere siden begge serverne er plassert i samme rom. Men samtidig oppstår problemet med konsistensen av felles databehandling, som blir bedt om å løse transaksjonslederne - nye elementer i flerlagssystemer.

Transaksjonsledere

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

For eksempel. Banksystemer skal gjennomføre ulike transformasjoner av dokumentrepresentasjoner, d.v.s. jobbe samtidig med data som er lagret både i databasen og i vanlige filer - dette er funksjonene MT hjelper til med å utføre.

MT er et program eller et sett med programmer ved hjelp av hvilke det er mulig å koordinere arbeidet til ulike komponenter i et informasjonssystem.

Logisk sett er MT delt inn i flere deler:

· Kommunikasjonsleder (kontrollerer utvekslingen av meldinger mellom komponentene i informasjonssystemet;

· Transaksjonsleder (styrer distribuert drift);

· Leder for vedlikehold av loggoppføringer (overvåker gjenoppretting og tilbakeføring av distribuerte operasjoner);

· Låsebehandler (gir riktig tilgang til delte data).

Vanligvis kombineres M-kommunikasjon med M-autorisasjon, og M-transaksjoner med M-låser og systemposter. Dessuten er en slik M sjelden inkludert i leveringssettet, siden funksjonene (journalføring, ressursallokering og kontroll av operasjoner), som regel, utføres av selve databasen (for eksempel Oracle).

De største endringene har skjedd innen M-kommunikasjon, ettersom nye objektorienterte teknologier (CORBA, DCOM, etc.) har dukket opp på dette området. Multi-tier klient-server-modellen kan betydelig forenkle distribuert databehandling, noe som gjør dem ikke bare mer pålitelige, men også rimeligere.

4.4. Teknologiske postsystemer­ -

det er en garantert levering av informasjon og et verktøy for å integrere applikasjoner

Informasjonssystemdesign gir løsninger på følgende problemer for systemanalytikere:

ð distribusjon av systemet;

ð integrering av ulike applikasjoner;

ð enkel administrasjon.

Moderne fly er hovedsakelig distribuert, så problemet oppstår med å velge en metode for interaksjon mellom individuelle deler av slike systemer. Sammenslåing av flere informasjonssystemer krever en løsning for å integrere et stort antall heterogene applikasjoner. Et slikt (integrert) system bør ha all funksjonaliteten til de kombinerte delsystemene og opprettholde enkelhet og brukervennlighet. Løsningen på dette problemet kan utføres ved hjelp av teknologiske postsystemer(STP).

Begrepet "teknologisk post" brukes for å betegne interaksjonen mellom applikasjoner ("e-post" - interaksjon mellom mennesker), den overførte informasjonen er teknologisk, dens dannelse og overføring kan utføres uten / eller med minimal menneskelig deltakelse.

Det teknologiske postsystemet inkluderer to ulike kommunikasjonsmetoder som brukes i moderne distribuerte systemer.

Den ene er basert på konseptet tilkobling (figur 1) og den andre er basert på ideen om meldinger.

1

Figur 1. Tilkoblingsorientert kommunikasjonsmekanisme

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

1. etablere en forbindelse;

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 teknologien for meldingskøer for interaksjon (fig. 2).

Fig. 2. Applikasjonsinteroperabilitet ved hjelp av meldingskøteknologi

Applikasjoner som utveksler informasjon adresserer det ikke direkte til hverandre, men til meldingskøene knyttet til applikasjonene. Forbindelsen mellom applikasjonen og køen skjer som regel online, noe som unngår den tidkrevende prosessen med å etablere en forbindelse. Kontrollprogramvaren kan enten være plassert på samme maskin med applikasjonene eller på en dedikert server. Systemer som bruker meldingskøteknologi, i motsetning til tilkoblingsetableringssystemer, krever verken en konstant tilkobling under interaksjon, eller samtidig drift av interagerende applikasjoner. Disse egenskapene gir dem fleksibilitet og aksepterbarhet i en rekke bruksområder.

Allsidigheten til teknologiske postsystemer gjør at de kan jobbe videre heterogen (en rekke programvare- og maskinvareplattformer som individuelle STP-komponenter opererer på, samt en rekke tilkoblingsmetoder og interaksjonsprotokoller som brukes i systemet) strukturer. Heterogenitet oppnås ved å skille server- og klientdelene av STP. Klientdelene har liten funksjonalitet og kan porteres til ulike plattformer. For funksjonen til STP er det derfor ikke behov for ekstra utstyrskostnader - systemet tilpasser seg de eksisterende midlene (både maskinvare og programvare, så vel som til eksisterende dataoverføringskanaler) og krever ikke utskifting.

Fordeler med å bruke STP:

Ø Meldingsleveringsgaranti. Message Queuing-servere

de bestemmer selv hvordan de skal sikre leveringssikkerhet i tilfelle feil i enkelte deler av systemet: å sende på nytt, finne en alternativ rute eller bruke andre metoder. Siden STP-er gir utveksling av informasjon mellom applikasjoner, må faktumet om manglende levering av en melding spores og behandles (i motsetning til e-post, hvor brukeren må ta noen korrigeringer i tilfelle av manglende levering av en melding handling);

Ø Ingen blokkering av applikasjonen under overføring av informasjon, pga teknologien for meldingskøer er på plass, og allokeringen av serverdelen av TP-systemet, som er ansvarlig for meldingslevering. Fraværet av blokkering lar deg redusere nedetiden for applikasjoner;

Ø Evne til å angi meldingsprioriteter og alternativer ved sending. Prioriteringer gjør at flere parallelle meldingssystemer kan implementeres. I dette tilfellet vil ikke meldinger med lavere prioritet ha noen innvirkning på leveringen av meldinger med høyere prioritet. Dette har en positiv egenskap ved design og konfigurering av store systemer, samt ved administrasjon av systemer;

Ø Evnen til å utveksle informasjon i et heterogent miljø, hvor modernisering av både maskinvare og programvare er mulig.