Det skal bemerkes at, som enhver klassifisering, er vår klassifisering av informasjonssystemarkitekturer ikke helt stiv. I arkitekturen til et bestemt informasjonssystem kan man ofte finne påvirkningene fra flere generelle arkitektoniske beslutninger. Ved arkitektonisk utforming av et system virker det imidlertid nyttig å ha i det minste et delvis ortogonalisert arkitektonisk grunnlag. I de følgende delene av kurset vil vi vurdere i detalj egenskapene til hver arkitektur og dvele ved metodikkene og teknologiske verktøyene som støtter design og utvikling av informasjonssystemer i den tilsvarende arkitekturen.

2.1. Filserverapplikasjoner

Tilsynelatende er organiseringen av informasjonssystemer basert på bruk av dedikerte filservere fortsatt den mest utbredte på grunn av tilstedeværelsen av et stort antall personlige datamaskiner med forskjellige utviklingsnivåer og den relative billigheten ved å koble PC-er til lokale nettverk. Hva tiltrekker en slik organisasjon av informasjonssystemutviklere som ikke er veldig erfarne innen systemprogrammering? Mest sannsynlig er det faktum at selv om applikasjonen (og det meste av systemet) er avhengig av filserverarkitekturer, er autonomien bevart. Faktisk samhandler komponentene i informasjonssystemet, som kjører på forskjellige PC-er, bare på grunn av tilstedeværelsen av en felles fillagring, som er lagret på en filserver. I det klassiske tilfellet dupliserer hver PC ikke bare applikasjonsprogrammer, men også databaseadministrasjonsverktøy. Filserveren er en utvidelse av diskminne som deles av alle PC-er i komplekset (Figur 2.1).

Uten å dvele i detalj ved de lovende verktøyene for utvikling av filserverapplikasjoner som er tilgjengelige på markedet i dag og uten å gi en analyse av utviklingstrendene til de tilsvarende teknologiene (den tredje delen av kurset er viet til dette), vil vi kort liste opp de viktigste fordelene og ulempene med filserverarkitekturer.

Den største fordelen er selvfølgelig den enkle organisasjonen. Designere og utviklere av informasjonssystemet er i de kjente og komfortable forholdene til en IBM PC i MS-DOS, Windows eller en hvilken som helst lettvektsversjon av Windows NT. Det finnes praktiske og avanserte utviklingsverktøy for grafisk brukergrensesnitt, brukervennlige verktøy for utvikling av databasesystemer og/eller DBMS. Men på mange måter er denne enkelheten tydelig. (Som det russiske ordtaket sier: "Enkelhet er verre enn å stjele," og her har vi vanligvis enkelhet basert på tyveri av PC-programvare.)

Ris. 2.1. Den klassiske representasjonen av informasjonssystemet i "filserver"-arkitekturen

Først må informasjonssystemet fungere med databasen. Derfor må denne databasen utformes. Av en eller annen grunn tror utviklere av filserverapplikasjoner ofte at på grunn av enkelheten til databaseadministrasjonsverktøy, kan problemet med databasedesign neglisjeres. Selvfølgelig er dette feil. Databasen er en database. Jo bedre det er utformet, jo større sjanse er det for å bruke informasjonssystemet effektivt senere. Naturligvis bestemmes kompleksiteten til databasedesign av den objektive kompleksiteten til det simulerte domenet. Men faktisk, av hva skulle det følge at filserverapplikasjoner bare er egnet i enkle fagområder?

For det andre, som vi gjentatte ganger har understreket i første del av kurset, er de nødvendige kravene til informasjonssystemdatabasen å opprettholde sin integrerte tilstand og garantert pålitelighet av informasjonslagring. Minimumsbetingelsene for hvilke disse kravene kan oppfylles er:

tilstedeværelsen av transaksjonskontroll, lagring av redundante data (for eksempel ved bruk av loggmetoder), evnen til å formulere integritetsbegrensninger og verifisere overholdelse av dem.

I prinsippet motsier ikke filserverorganisasjonen, som vist i figur 2.1, overholdelsen av de angitte forholdene. Et eksempel på et system som oppfyller disse betingelsene, men som er basert på en filserverarkitektur, er den populære Informix SE "databaseserveren" tidligere.

Lang merknad:
For å bevare klarheten i den videre fremstillingen må vi tydeliggjøre terminologien noe. Det er ikke for ingenting at vi skrev "databaseserver" i anførselstegn for Informix SE DBMS. Med dette systemet ble en kopi av DBMS-programvaren opprettholdt for hver brukerinitierte DBMS-økt. Grovt sett, for hver brukerprosess som samhandler med databasen, ble det opprettet en DBMS-tjenesteprosess, som ble utført på samme prosessor som brukerprosessen (dvs. på klientsiden). Hver av disse tjenesteprosessene oppførte seg faktisk som om de var den eneste representanten for DBMS. All synkronisering av mulig parallelt arbeid med databasen ble utført på nivå med eksterne minnefiler som inneholder databasen. La oss nå bli enige om å kalle slike DBMS ikke databaseservere, men databasestyringssystemer basert på filserverarkitekturen (DBMS-FS).

Med en ekte databaseserver mener vi programvaredannelse knyttet til den(e) tilsvarende databasen(e), eksisterende, generelt sett, uavhengig av eksistensen av bruker(klient)prosesser og utført, generelt sett (men ikke nødvendigvis) på dedikert maskinvare (vi bevisst vi bruker ikke veldig spesifikke termer "programvareopplæring" og "dedikert maskinvare", fordi deres spesifikke implementering er forskjellig på forskjellige databaseservere).

Ekte databaseservere er mye mer komplekse i organisasjonen enn DBMS-FS, men de gir finere og mer effektiv databaseadministrasjon. Gjennom resten av dette kurset, når vi bruker begrepet "databaseserver", vil vi mene ekte databaseservere.

Men på den annen side, i de fleste personlige DBMS er disse betingelsene ikke oppfylt selv ved hjelp av grove metoder. I beste fall er det mulig å delvis kompensere for manglene på programnivå.

For det tredje er grensesnittet til avanserte databaseservere basert på bruk av et SQL-databasespråk på høyt nivå, som tillater bruk av nettverkstrafikk mellom klienten og databaseserveren kun for nyttige formål (SQL-setninger sendes hovedsakelig fra klienten til serveren, fra serveren til klienten - resultatutførelsen av operatører). I en filserverorganisasjon jobber klienten med eksterne filer, noe som forårsaker en betydelig trafikkoverbelastning (siden DBMS-FS fungerer på klientsiden, for å hente nyttelasten, generelt, er det nødvendig å se hele den tilsvarende fil på klientsiden).

Generelt har vi i en filserverarkitektur en "tykk" klient og en veldig "tynn" server i den forstand at nesten alt arbeid gjøres på klientsiden, og serveren trenger kun tilstrekkelig diskplass (Figur 2.2).

Ris. 2.2. Tykk klient og tynn server i filserverarkitektur

Korte konklusjoner. En enkel, lavvolum, enkeltbruker filserverapplikasjon kan designes, utvikles og feilsøkes veldig raskt. Svært ofte for et lite selskap å føre for eksempel personaljournaler, er det nok å ha et isolert system som kjører på en frittstående PC. Selvfølgelig, også i dette tilfellet, kreves det stor forsiktighet fra sluttbrukere (eller administratorer, hvis tilstedeværelse i dette tilfellet er tvilsomt) for å sikkert lagre og opprettholde integriteten til dataene. Imidlertid, i allerede litt mer komplekse tilfeller (for eksempel når du organiserer et informasjonssystem for å støtte et prosjekt utført av en gruppe), blir filserverarkitekturen utilstrekkelig.

Klient-server-applikasjoner

Med en klient-server-applikasjon mener vi et informasjonssystem basert på bruk av databaseservere (se det lange notatet på slutten av avsnitt 2.1). Den generelle oversikten over informasjonssystemet i klient-server-arkitekturen er vist i figur 2.3.

På klientsiden kjøres applikasjonskoden, som nødvendigvis inkluderer komponenter som støtter grensesnittet mot sluttbrukeren, produserer rapporter, utfører andre applikasjonsspesifikke funksjoner (inntil vi er bekymret for hvordan applikasjonskoden er bygget opp). Klientsiden av applikasjonen samhandler med klientsiden av databasebehandlingsprogramvaren, som faktisk er en individuell DBMS-representant for applikasjonen.

(Det er her terminologien er feil igjen. Vanligvis, når et selskap kunngjør utgivelsen av en ny databaseserver, er det implisitt forstått at det også er en klientside av dette produktet. Kombinasjonen av "klientsiden av en databaseserver" virker litt rart, men det er dette vi må bruke begrepet.)

Ris. 2.3. Generell oversikt over informasjonssystemet i klient-server-arkitekturen

Merk at grensesnittet mellom front-end av applikasjonen og front-end av databaseserveren vanligvis er SQL-basert. Derfor utføres slike funksjoner som for eksempel forhåndsbehandling av skjemaer beregnet for spørringer til databasen, eller generering av de resulterende rapportene i applikasjonskoden.

Til slutt får klientsiden av databaseserveren, ved hjelp av nettverkstilgangsfasiliteter, tilgang til databaseserveren, og sender den teksten til SQL-setningen.

Det er to poeng til her.

Vanligvis streber selskaper som produserer avanserte databaseservere for å sikre at produktene deres kan brukes ikke bare i dagens standard TCP / IP-baserte nettverk, men i nettverk basert på andre protokoller (for eksempel SNA eller IPX / SPX) ... Derfor, når du organiserer nettverksinteraksjoner mellom klient- og serverdelene av DBMS, brukes ofte ikke standard verktøy på høyt nivå (for eksempel programvaresockets eller eksterne prosedyrekall), men deres egne funksjonelt lignende verktøy som er mindre avhengige av funksjonene av nettverkstransportprotokoller. Når vi snakker om et grensesnitt basert på SQL-språket, må vi være klar over at til tross for den titaniske innsatsen for å standardisere dette språket, er det ingen implementering der standardfunksjonene til språket ikke har blitt utvidet. Hensynsløs bruk av språkutvidelser fører til fullstendig avhengighet av applikasjonen av den spesifikke produsenten av databaseserveren.

La oss nå se hva som skjer på databaseserversiden. I produktene til nesten alle selskaper mottar serveren fra klienten teksten til setningen i SQL.

Serveren kompilerer den mottatte operatøren. Vi skal ikke dvele her ved hvilket målspråk som brukes av en bestemt kompilator; ulike implementeringer bruker ulike tilnærminger (se del 4 for eksempler). Hovedsaken er at i alle fall, basert på informasjonen i databasekatalogtabellene, konverteres den ikke-prosedyremessige representasjonen av operatøren til en bestemt prosedyre for utførelse. Videre (hvis kompileringen ble fullført) blir setningen utført. Igjen, vi vil ikke diskutere tekniske detaljer da de er forskjellige i implementering. La oss vurdere de mulige handlingene til SQL-setningene.
En operatør kan tilhøre klassen av operatører for å bestemme (eller lage) databaseobjekter (det ville vært mer nøyaktig og mer korrekt å snakke om elementer i et databaseskjema eller om metabaseobjekter). Spesielt kan domener, tabeller, integritetsbegrensninger, utløsere, brukerrettigheter, lagrede prosedyrer defineres. I alle fall, når setningen for å lage et databaseskjemaelement utføres, blir den tilsvarende informasjonen plassert i databasekatalogtabellene (i metabasetabellene). Integritetsbegrensninger lagres vanligvis i metabasen direkte i tekstrepresentasjon. For handlinger definert i utløsere og lagrede prosedyrer, genereres prosedyremessig kjørbar kode og lagres i katalogtabeller. Merk at integritetsbegrensninger, utløsere og lagrede prosedyrer på en måte er representative for en applikasjon i en serverstøttet database; de utgjør ryggraden i søknaden (se nedenfor). Når du utfører datavalgsetninger basert på innholdet i tabellene som påvirkes av spørringen og, muligens, ved bruk av indeksene som støttes i databasen, dannes det resulterende datasettet (vi bruker bevisst ikke begrepet "resultattabell" her, siden avhengig av på den spesifikke typen operatør kan resultatet sorteres, og tabeller, det vil si relasjoner er uordnet per definisjon). Serversiden av DBMS sender resultatet til klientsiden, og den endelige behandlingen gjøres på klientsiden av applikasjonen. Når du kjører operatører for å endre innholdet i databasen (INSERT, UPDATE, DELETE), kontrolleres det at integritetsbegrensningene definert på det tidspunktet (de som tilhører klassen av umiddelbart kontrollerbare) ikke vil bli brutt, hvoretter den passende handlingen er tatt (akkompagnert av endring av alle relevante indekser og logging endringer). Deretter sjekker serveren om denne endringen påvirker utløsertilstanden til en utløser, og hvis en slik utløser blir funnet, utfører den handlingsprosedyren. Denne prosedyren kan inkludere flere databasemodifikasjonssetninger som kan utløse andre utløsere osv. Du kan anta at handlingene som utføres på databaseserveren når du sjekker at integritetsbegrensninger er oppfylt og når utløsere utløses, er handlingene til applikasjonens backend. . .. Når du utfører setninger for endring av databaseskjemaer (legger til eller fjerner kolonner i eksisterende tabeller, endrer datatypen til en eksisterende kolonne i en eksisterende tabell, etc.) utløsere kan også utløses, det vil si at serversiden av applikasjonen kan kjøres med andre ord. På samme måte kan utløsere utløses når objekter i databaseskjemaet (domener, tabeller, integritetsbegrensninger osv.) blir ødelagt. En spesiell klasse av SQL-operatører består av operatører som kaller tidligere definerte lagrede prosedyrer lagret i databasen. Hvis en lagret prosedyre er definert ved bruk av et tilstrekkelig utviklet språk som inkluderer både ikke-prosedyremessige SQL-setninger og rene prosedyrekonstruksjoner (for eksempel Oracles PL / SQL-språk), kan en slik prosedyre inneholde en betydelig del av applikasjonen, som når prosedyrekall-setningen blir utført, vil bli utført på serversiden, ikke klientsiden. Når du utfører transaksjonsfullføringserklæringen, må serveren kontrollere samsvar med alle de såkalte utsatte integritetsbegrensningene (slike begrensninger inkluderer begrensninger pålagt innholdet i databasetabellen som helhet eller på flere tabeller samtidig; f.eks. totallønnen til avdelingsansatte 999 bør ikke overstige 150 millioner rubler .). Igjen kan det å se etter utsatte integritetsbegrensninger betraktes som å kjøre baksiden av applikasjonen.

Som du kan se, i en klient-server-organisasjon kan klienter være tynne nok, og serveren må være tykk nok til å kunne møte behovene til alle klienter (Figur 2.4).

Ris. 2.4. Tynn klient og fet server i klient-server-arkitektur

På den annen side er utviklere og brukere av informasjonssystemer basert på klient-server-arkitekturen ofte misfornøyde med de vedvarende nettverksoverheadkostnadene som følger av behovet for å gå fra klienten til serveren med hver påfølgende forespørsel. I praksis er situasjonen utbredt når det for effektiv drift av en separat klientkomponent i et informasjonssystem i realiteten bare kreves en liten del av den totale databasen. Dette fører til ideen om å opprettholde en lokal delt databasebuffer på klientsiden.

Faktisk er konseptet med lokal databasebufring et spesielt tilfelle av konseptet med replikerte (eller, som de noen ganger kalles i den russiskspråklige litteraturen, replikerte) databaser. Som i det generelle tilfellet, for å støtte den lokale databasebufferen, må arbeidsstasjonsprogramvaren inneholde en databasebehandlingskomponent - en forenklet versjon av databaseserveren som for eksempel ikke gir tilgang til flere brukere. Et eget problem er å sikre konsistensen (sammenhengen) av cacher og den felles databasen. Ulike løsninger er mulige her - fra automatisk vedlikehold av konsistens ved hjelp av grunnleggende datil fullstendig overføring av denne oppgaven til applikasjonslaget. Uansett blir klientene tykkere uten å gjøre serveren tynnere (Figur 2.5).

Ris. 2.5. Fet klient og fet server i klient-server-arkitektur med lokal cache-støtte på klientsiden

La oss formulere noen foreløpige konklusjoner. Klient-server-arkitekturen ser ved første øyekast ut til å være mye dyrere enn fil-server-arkitekturen. Kraftigere maskinvare kreves (i det minste for serveren) og mye mer avanserte databaseadministrasjonsverktøy. Dette er imidlertid bare delvis sant. En stor fordel med klient-server-arkitekturen er dens skalerbarhet og, generelt, evnen til å utvikle seg.

Når du utformer et informasjonssystem basert på denne arkitekturen, bør mer oppmerksomhet rettes mot leseferdigheten til generelle beslutninger. De tekniske midlene til pilotversjonen kan være minimale (for eksempel kan en av arbeidsstasjonene brukes som maskinvaregrunnlag for databaseserveren). Etter at piloten er opprettet, må det gjøres ytterligere forskning for å identifisere flaskehalser i systemet. Først etter det er det nødvendig å ta en beslutning om valg av servermaskinvare som skal brukes i praksis.

Økningen i omfanget av informasjonssystemet gir ikke opphav til grunnleggende problemer. Den vanlige løsningen er å erstatte servermaskinvaren (og kanskje arbeidsstasjonsmaskinvaren hvis en overgang til lokal databasebufring er nødvendig). Uansett er den anvendte delen av informasjonssystemet praktisk talt ikke berørt. Ideelt sett, som selvfølgelig ikke eksisterer, fortsetter informasjonssystemet å fungere normalt etter bytte av utstyr.

Hensikten med forelesningen: å vise hvordan de generelle prinsippene for klient-server-teknologier implementeres i webteknologier. Undersøk nøkkelelementene i den underliggende HTTP-protokollen.

Emnet for dette kurset er teknologiene til det globale nettverket World Wide Web (forkortet til WWW eller ganske enkelt Internett). På russisk er en vanlig variant navnet "Web".

Spesielt vil kurset dekke slike spørsmål som: grunnleggende standarder og protokoller for nettet, markup- og programmeringsspråk for nettsider, verktøy for å utvikle og administrere webinnhold og applikasjoner for nettet, verktøy for å integrere webinnhold og applikasjoner i nettet.

Nettverk Web er et globalt informasjonsrom basert på den fysiske infrastrukturen til Internett og HTTP-dataoverføringsprotokollen. Når vi snakker om Internett, mener de ofte nettverket. Web.

Klient-server-teknologier Web

Den grunnleggende protokollen til nettverket av hypertekstressurser Web er HTTP-protokollen. Det er basert på interaksjon " klient server", det vil si at det antas at:

Forbruker- kunde etter å ha startet en forbindelse med serverleverandøren, sender den en forespørsel til den;

Forsørger- server Etter å ha mottatt forespørselen, utfører den de nødvendige handlingene og returnerer et svar med resultatet tilbake til klienten.

I dette tilfellet er det to mulige måter å organisere arbeidet til klientdatamaskinen på:

Tynn klient er en klientdatamaskin som overfører alle informasjonsbehandlingsoppgaver til serveren. Et eksempel på en tynnklient er en datamaskin med en nettleser som brukes til å kjøre nettapplikasjoner.

Fet klient tvert imot behandler den informasjon uavhengig av serveren, og bruker sistnevnte hovedsakelig for lagring av data.

Før vi går videre til spesifikke klient-/serverwebteknologier, la oss se på det grunnleggende og strukturen til den underliggende HTTP-protokollen.

Http-protokoll

HTTP(HyperText Transfer Protocol - RFC 1945, RFC 2616) er en applikasjonslagsprotokoll for overføring av hypertekst.

Sentralt i HTTP er ressurs pekt på av URI i klientens forespørsel. Vanligvis er disse ressursene filer som er lagret på serveren. En funksjon ved HTTP-protokollen er muligheten til å spesifisere i en forespørsel og et svar en måte å representere den samme ressursen ved forskjellige parametere: format, koding, språk osv. Det er takket være muligheten til å spesifisere metoden for koding av en melding at klienten og serveren kan utveksle binære data, men i utgangspunktet er denne protokollen beregnet på å overføre symbolsk informasjon. Ved første øyekast kan dette virke som sløsing med ressurser. Faktisk tar data i symbolsk form mer minne, meldinger skaper en ekstra belastning på kommunikasjonskanaler, men dette formatet har mange fordeler. Meldingene som sendes over nettverket er lesbare, og ved å analysere de mottatte dataene kan systemadministratoren enkelt finne feilen og fikse den. Om nødvendig kan rollen til en av de interagerende applikasjonene utføres av en person, manuelt legge inn meldinger i det nødvendige formatet.

I motsetning til mange andre protokoller, er HTTP en minneløs protokoll. Dette betyr at protokollen ikke lagrer informasjon om tidligere klientforespørsler og serversvar. Komponenter som bruker HTTP kan uavhengig opprettholde tilstandsinformasjon knyttet til de siste forespørslene og svarene. For eksempel kan en nettklientapplikasjon som sender forespørsler spore svarforsinkelser, og en webserver kan lagre IP-adressene og forespørselshodene til nylige klienter.

All programvare for arbeid med HTTP-protokollen faller inn i tre hovedkategorier:

Servere- tilbydere av tjenester for lagring og behandling av informasjon (behandling av forespørsler).

Kunder- sluttforbrukere av servertjenester (sende forespørsler).

Proxy-servereå støtte arbeidet med transporttjenestene.

Det "klassiske" HTTP-øktskjemaet ser slik ut.

Etablere en TCP-tilkobling.

Kundeforespørsel.

Serverrespons.

Ødelagt TCP-tilkobling.

Dermed sender klienten en forespørsel til serveren, mottar et svar fra den, hvoretter interaksjonen avsluttes. Vanligvis er en klientforespørsel en forespørsel om å sende et HTML-dokument eller en annen ressurs, og serverens svar inneholder koden for den ressursen.

HTTP-forespørselen sendt fra en klient til en server inkluderer følgende komponenter.

Statuslinje (noen ganger brukes begrepene statuslinje eller spørringsstreng også for å betegne det).

Overskriftsfelt.

Tom linje.

Brødteksten i forespørselen.

Statuslinjen sammen med overskriftsfelt noen ganger også kalt forespørselsoverskrift.

Ris. 1.1. Struktur for klientforespørsel.

Statuslinjen har følgende format:

request_method url_pecypca nttp_protocol_version

La oss ta en titt på komponentene i statuslinjen, med fokus på spørringsmetoder.

Metode, spesifisert i statuslinjen, bestemmer hvordan ressursen skal påvirkes, hvis URL er spesifisert på samme linje. Metoden kan ta verdiene GET, POST, HEAD, PUT, DELETE, etc. Til tross for overfloden av metoder, er bare to av dem virkelig viktige for en webprogrammerer: GET og POST.

FÅ. I følge den formelle definisjonen er GET-metoden ment å få en ressurs med den angitte URL-en. Når serveren mottar en GET-forespørsel, må den lese den spesifiserte ressursen og inkludere ressurs-IDen i svaret til klienten. Ressursen hvis URL sendes som en del av forespørselen, trenger ikke å være en HTML-side, bildefil eller andre data. Ressurs-URLen kan peke til den kjørbare koden til programmet, som, hvis visse betingelser er oppfylt, må kjøres på serveren. I dette tilfellet er det ikke programkoden som returneres til klienten, men dataene som genereres under kjøringen. Mens GET-metoden per definisjon er ment for å hente informasjon, kan den også brukes til andre formål. GET-metoden er ganske egnet for å overføre små biter av data til serveren.

POST. I følge den samme formelle definisjonen er hovedformålet med POST-metoden å overføre data til serveren. I likhet med GET-metoden kan imidlertid POST-metoden brukes på forskjellige måter og brukes ofte til å hente informasjon fra en server. Som med GET-metoden, peker URL-en som er angitt i statuslinjen til en spesifikk ressurs. POST-metoden kan også brukes til å starte en prosess.

HEAD- og PUT-metodene er modifikasjoner av GET- og POST-metodene.

HTTP-protokollversjon er vanligvis gitt i følgende format:

Http / versjon.modifikasjon

Overskriftsfelt ved å følge statuslinjen kan du avgrense søket ditt, dvs. sende tilleggsinformasjon til serveren. Overskriftsfeltet har følgende format:

Feltnavn: Verdi

Formålet med et felt bestemmes av navnet, som er atskilt fra verdien med et kolon.

Navnene på noen av de vanligste overskriftsfeltene i en klientforespørsel og deres formål er oppgitt fanen. 1.1.

I mange tilfeller, når du arbeider på nettet, mangler forespørselsteksten. Når CGI-skript kjøres, kan dataene som sendes til dem i forespørselen, plasseres i forespørselens brødtekst.

Nedenfor er et eksempel på en HTML-forespørsel generert av nettleseren

FÅ http://oak.oakland.edu/ HTTP / 1.0

Tilkobling: Keep-Alive

Brukeragent: Mozilla / 4.04 (Win95; I)

Vert: oak.oakland.edu

Godta: bilde / gif, bilde / x-xbitmap, bilde / jpeg, bilde / pjpeg, bilde / png, * / *

Accept-Language: en

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

Etter å ha mottatt en forespørsel fra klienten, må serveren svare på den. Kunnskap om strukturen til serverresponsen er nødvendig for utvikleren av webapplikasjoner, siden programmene som kjører på serveren uavhengig må danne svaret til klienten.

I likhet med klientens forespørsel har serverens svar også de fire komponentene som er oppført nedenfor.

Statuslinjen.

Overskriftsfelt.

Tom linje.

Responsorgan.

Serverens svar til klienten begynner med en statuslinje, som har følgende format:

Protocol_version Response_code Explanatory_message

Protocol_version er spesifisert i samme format som i klientforespørselen og har samme betydning.

Response_code er et tresifret desimaltall som kodet resultatet av å betjene forespørselen av serveren.

Forklarende_melding dupliserer svarkoden i symbolsk form. Dette er en tegnstreng som ikke behandles av klienten. Den er beregnet på systemadministratoren eller operatøren som vedlikeholder systemet, og er en dekryptering av svarkoden.

Av de tre sifrene som utgjør svarkoden, definerer den første (høyeste) svarklassen, de to andre representerer svarnummeret i klassen. Så, for eksempel, hvis forespørselen ble behandlet vellykket, mottar klienten følgende melding:

HTTP / 1.0 200 OK

Som du kan se, er versjonen av HTTP 1.0-protokollen etterfulgt av en kode 200. I denne koden betyr tegn 2 vellykket behandling av klientens forespørsel, og de resterende to sifrene (00) er nummeret til denne meldingen.

I for øyeblikket brukte HTTP-protokollimplementeringer kan ikke det første sifferet være større enn 5 og definerer følgende responsklasser.

1 - en spesiell klasse meldinger kalt informative. En svarkode som starter med 1 betyr at serveren fortsetter å behandle forespørselen. Når du utveksler data mellom en HTTP-klient og en HTTP-server, brukes sjelden meldinger av denne klassen.

2 - vellykket behandling av kundens forespørsel.

3 - be om omdirigering. Ytterligere skritt må tas for å betjene forespørselen.

4 - klientfeil. Vanligvis returneres en svarkode som starter med tallet 4 hvis det oppstår en syntaksfeil i klientens forespørsel.

5 - serverfeil. Av en eller annen grunn kan ikke serveren oppfylle forespørselen.

Eksempler på svarkoder som klienten kan motta fra serveren, og forklarende meldinger er gitt i tabell. 1.2.

Svaret bruker samme overskriftsfeltstruktur som klientforespørselen. Overskriftsfelt er ment å tydeliggjøre serverens svar til klienten. En beskrivelse av noen av feltene som finnes i serversvarhodet er gitt i tabellen. 1.3.

Brødteksten i svaret inneholder koden til ressursen som ble sendt til klienten som svar på forespørselen. Det trenger ikke å være HTML-teksten til nettsiden. Som en del av svaret kan et bilde, en lydfil, et stykke videoinformasjon, samt alle andre typer data som støttes av klienten, overføres. Innholdet i feltet Innholdstype-overskrift forteller klienten hvordan den mottatte ressursen skal håndteres.

Nedenfor er et eksempel på et serversvar på forespørselen gitt i forrige seksjon. Brødteksten i svaret inneholder den originale teksten til HTML-dokumentet.

Server: Microsoft-IIS / 5.1

X-Powered-By: ASP.NET

Innholdstype: tekst / html

Godta-områder: bytes

ETag: "b66a667f948c92: 8a5"

Innhold-lengde: 426

Operand1:

Operand2:

Operasjon:

+

-

*

/

Overskrifts- og brødtekstfeltene til meldingen kan mangle, men statuslinjen er påkrevd da den angir typen forespørsel/svar.

Et felt kalt Content-type kan vises både i en klientforespørsel og i et serversvar. Verdien av dette feltet er spesifisert MIME-type innholdet i forespørselen eller svaret. MIME-type sendes også i Accept header-feltet i forespørselen.

Spesifikasjon MIME(Multipurpose Internet Mail Extension) ble opprinnelig utviklet for å tillate overføring av ulike dataformater som en del av e-post. Bruken av MIME er imidlertid ikke begrenset til e-post. MIME-verktøy brukes med hell på WWW og har faktisk blitt en integrert del av dette systemet.

Standard MIME er utformet som en utvidbar spesifikasjon, noe som innebærer at antallet datatyper vil vokse etter hvert som formene for datapresentasjon utvikler seg. Hver ny type må registreres i IANA(Internet Assigned Numbers Authority).

Før fremveksten MIME datamaskiner som kommuniserte over HTTP-protokollen utvekslet utelukkende tekstinformasjon. For å overføre bilder, som med alle andre binære filer, måtte du bruke FTP-protokollen.

I henhold til spesifikasjonen MIME, for å beskrive dataformatet brukes type og undertype. Type av bestemmer hvilken klasse innholdsformatet til en HTTP-forespørsel eller HTTP-svar tilhører. Undertype spesifiserer formatet. Typen og undertypen er atskilt med en skråstrek:

type / undertype

Siden serveren i de aller fleste tilfeller, som svar på en klients forespørsel, returnerer den opprinnelige teksten til HTML-dokumentet, inneholder innholdstype-feltet i svaret vanligvis verdien tekst / html. Her beskriver tekstidentifikatoren typen, som indikerer at tegninformasjon sendes til klienten, og html-identifikatoren beskriver undertypen, dvs. indikerer at tegnsekvensen i svarteksten er en HTML-dokumentbeskrivelse.

Liste over typer og undertyper MIME stor nok. Bord 1.4 er eksempler MIME-typer, som oftest finnes i overskriftene til HTML-forespørsler og svar.

Tabell 1.4. MIME-datatyper.
Type / undertype	Filutvidelse	Beskrivelse
		Dokumentet skal behandles av Acrobat Reader
applikasjon / msexcel		Microsoft Excel-dokument
søknad / etterskrift		PostScript-dokument
applikasjon / x-tex		Dokument i TeX-format
applikasjon / msword		Microsoft Word-dokument
		RTF-dokument vises med Microsoft Word
		GIF-bilde
		JPEG-bilde
		TIFF-bilde
		XBitmap-bilde
		ASCII-tekst
		HTML-dokument
		Lydfil i MIDI-format
		Lydfil i WAV-format
		E-postmelding
		Legg ut i nyhetsgrupper
	Mpeg, .mpg, .mpe	Videosnutt i MPEG-format
		Videosnutt i AVI-format

Unike URL-identifikatorer brukes til å identifisere ressurser på nettet unikt.

En Uniform Resource Identifier (URI) er en kort sekvens av tegn som identifiserer en abstrakt eller fysisk ressurs. URI-en indikerer ikke hvordan ressursen skal skaffes, men identifiserer den bare. Dette gjør det mulig å beskrive bruk av RDF-ressurser (Resource Description Framework) som ikke kan skaffes over Internett (navn, titler osv.). De mest kjente eksemplene på URIer er URL og URN.

URL(Uniform Resource Locator) er en URI som, i tillegg til å identifisere en ressurs, også gir informasjon om plasseringen til den ressursen.

URNE(Uniform Resource Name) er en URI som identifiserer en ressurs i et spesifikt navneområde, men i motsetning til en URL, indikerer ikke en URN plasseringen til den ressursen.

URL-en har følgende struktur:

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

ordningen- skjema for tilgang til en ressurs (vanligvis en nettverksprotokoll);

Logg Inn- brukernavn som brukes for å få tilgang til ressursen;

passord- passordet knyttet til det angitte brukernavnet;

vert- fullt registrert domenenavn til verten i DNS-systemet eller IP-adressen til verten;

havn- vertsport for tilkobling;

URL-bane- avklare informasjon om plassering av ressursen.

Bruk av klient-server-teknologi

Over tid ble den lite funksjonelle modellen av filserveren for lokalnettverk (FS) erstattet av den nye modellen etter en av "Client Server"-strukturen (RDA, DBS og AS).

Klient-server-teknologien, som okkuperte bunnen av databasen, har blitt hovedteknologien på det globale Internett. Videre, som et resultat av overføringen av ideene til Internett til sfæren av bedriftssystemer, oppsto intranettteknologien. I motsetning til "Client-Server"-teknologien, er denne teknologien rettet mot informasjon i sin endelige form for forbruk, og ikke til data. Datasystemer, som er bygget på grunnlag av intranettet, inkluderer sentrale informasjonsservere og visse komponenter for å presentere informasjon til siste bruker (nettlesere eller navigatorer). Handlingen mellom serveren og klienten i intranettet gjøres ved hjelp av nettteknologi.

I moderne tid har Client-Server-teknologien blitt svært utbredt, men denne teknologien i seg selv har ikke universelle oppskrifter. Den gir kun en generell vurdering av hvordan dagens distribusjonsinformasjonssystem skal lages. Implementeringen av denne teknologien i visse programvareprodukter og til og med i typer programvare er anerkjent svært betydelig.

Klassisk to-lags klient-server-arkitektur

Nettverkskomponenter har som regel ikke like rettigheter: noen har tilgang til ressurser (for eksempel: databasestyringssystem, prosessor, skriver, filsystem osv.), andre har tilgang til disse ressursene. operativsystemserverteknologi

"Client - server"-teknologi er en arkitektur av en programvarepakke som distribuerer et applikasjonsprogram i to logisk forskjellige deler (server og klient), som samhandler i henhold til "request - response"-skjemaet og løser sine egne spesifikke oppgaver.

Programmet (eller datamaskinen) som kontrollerer og/eller eier en eller annen ressurs kalles serveren til denne ressursen.

Et program (datamaskin eller) som ber om og bruker en ressurs kalles en klient for den ressursen.

I dette tilfellet kan slike forhold også oppstå når en programenhet samtidig vil implementere funksjonene til serveren i forhold til en enhet og klienten i forhold til en annen enhet.

Hovedprinsippet for Client-Server-teknologien er å dele applikasjonsfunksjonene inn i minst tre lenker:

Brukergrensesnittmoduler;

Denne gruppen kalles også presentasjonslogikk. Med dens hjelp kan brukere samhandle med applikasjoner. Uavhengig av de spesifikke egenskapene til presentasjonslogikken (kommandolinjegrensesnitt, mellomliggende grensesnitt, komplekse grafiske brukergrensesnitt), er formålet å gi et middel for mer effektiv informasjonsutveksling mellom informasjonssystemet og brukeren.

Datalagringsmoduler;

Denne gruppen kalles også forretningslogikk. Forretningslogikk finner nøyaktig hva en applikasjon er nødvendig for (for eksempel applikasjonsfunksjoner som er iboende i det angitte domenet). Å skille en applikasjon langs programgrenser gir et naturlig grunnlag for å distribuere en applikasjon på to eller flere datamaskiner.

Databehandlingsmoduler (ressursstyringsfunksjoner);

Denne gruppen kalles også logiske datatilgangsalgoritmer eller ganske enkelt datatilgang. Algoritmer for å legge inn data betraktes som et spesifikt grensesnitt for en spesifikk applikasjon til en enhet for stabil datalagring som et DBMS eller et filsystem. Ved hjelp av databehandlingsmoduler organiseres et spesifikt grensesnitt for en DBMS-applikasjon. Ved å bruke grensesnittet kan en applikasjon administrere databasetilkoblinger og spørringer (oversette applikasjonsspesifikke søk til SQL, hente resultater og oversette disse resultatene tilbake til applikasjonsspesifikke datastrukturer). Hver av de oppførte koblingene kan realiseres uavhengig av flere andre. For eksempel, uten å endre programmene som brukes til å behandle og lagre data, kan du endre brukergrensesnittet slik at de samme dataene vises i form av tabeller, histogrammer eller grafer. De enkleste applikasjonene er ofte i stand til å sette sammen alle tre koblingene til et enkelt program, og denne separasjonen følger funksjonelle grenser.

I samsvar med separasjonen av funksjoner skilles følgende komponenter i hver applikasjon:

• - datapresentasjonskomponent;
• - applikasjonskomponent;
• - ressursstyringskomponent.

Klientserveren i den klassiske arkitekturen må distribuere de tre hoveddelene av applikasjonen i 2 fysiske moduler. Vanligvis er applikasjonskomponenten plassert på serveren (for eksempel på databaseserveren), datapresentasjonskomponenten er på klientsiden, og ressursstyringskomponenten er fordelt mellom server- og klientdelene. Dette er den største ulempen med den klassiske tolagsarkitekturen.

I en to-lags arkitektur, når man skiller databehandlingsalgoritmer, må utviklere ha fullstendig informasjon om de siste endringene som er gjort i systemet, og forstå disse endringene, noe som skaper ikke små vanskeligheter i utviklingen av klient-server-systemer, deres vedlikehold og installasjon, siden det er nødvendig å bruke store anstrengelser for å koordinere handlingene til forskjellige grupper av spesialister. I handlingene til utviklere oppstår ofte motsetninger, og dette bremser utviklingen av systemet og tvinger deg til å endre allerede ferdiglagde og utprøvde elementer.

For å unngå inkonsekvensen av forskjellige elementer i arkitekturen, laget vi to modifikasjoner av to-lags arkitekturen "Client-Server": "Fat Client" ("Thin Server") og "Thin Client" ("Fat Server").

I denne arkitekturen prøvde utviklerne å utføre databehandling på en av to fysiske deler – enten på klientsiden ("Thick client") eller på serveren ("Thin client").

Hver tilnærming har betydelige ulemper. I den første situasjonen er nettverket uberettiget overbelastet, fordi ubehandlet, det vil si redundante data, overføres over det. I tillegg blir systemstøtten og dens endring mer komplisert, fordi å fikse en feil eller erstatte beregningsalgoritmen krever en samtidig fullstendig utskifting av alle grensesnittprogrammer, hvis en fullstendig utskifting ikke gjøres, kan datainkonsekvens eller feil oppstå. Hvis all informasjonsbehandling utføres på serveren, oppstår problemet med å beskrive de innebygde prosedyrene og deres feilsøking. Et system med informasjonsbehandling på en server er absolutt umulig å overføre til en annen plattform (OS), dette er en alvorlig ulempe.

Hvis du lager en to-lags klassisk arkitektur "Client-Server", må du vite følgende fakta:

Thick Server-arkitektur ligner på Thin Client-arkitektur

Sende en forespørsel fra klienten til serveren, behandle forespørselen av serveren og sende resultatet til klienten. Imidlertid har arkitekturene følgende ulemper:

• - implementeringen blir mer komplisert, siden språk som SQL ikke er tilpasset utviklingen av slik programvare, og det er ingen gode feilsøkingsverktøy;
• - ytelsen til programmer skrevet på språk som SQL er svært lav enn de som er opprettet på andre språk, noe som er viktigst for komplekse systemer;
• - programmer som er skrevet på DBMS-språk, fungerer som regel delvis ikke veldig pålitelig; en feil i dem kan føre til feil på hele databaseserveren;
• - de resulterende programmene er fullstendig ikke-bærbare til andre plattformer og systemer.
• - arkitektur "Thick client" ligner på arkitektur "Thin server"

Forespørselsbehandling gjøres på klientsiden, det vil si at all rådata fra serveren overføres til klienten. I dette tilfellet har arkitekturene negative sider:

• - programvareoppdateringen blir mer komplisert, fordi den må byttes ut samtidig gjennom hele systemet;
• - maktfordelingen blir mer komplisert, fordi differensieringen av tilgang skjer ikke 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.

For å løse de oppførte problemene, er det nødvendig å bruke en klient-server-arkitektur på flere nivåer (tre eller flere nivåer).

Tre-lags modell .

Siden midten av 90-tallet av forrige århundre har populariteten til spesialister blitt oppnådd av trelags klient-server-arkitekturen, som delte informasjonssystemet etter funksjonalitet i tre seksjoner: datatilgangslogikk, presentasjonslogikk og forretningslogikk. I motsetning til tolagsarkitekturen har trelagsarkitekturen et tilleggsnivå - en applikasjonsserver designet for å implementere forretningslogikk, mens den fullstendig avlaster klienten som sender forespørsler til mellomvare, og maksimerer alle egenskapene til serverne.

I en trelagsarkitektur er klienten som regel ikke overbelastet med databehandlingsfunksjoner, men utfører sin hovedrolle som et system for å presentere informasjon fra applikasjonsserveren. Et slikt grensesnitt kan håndheves ved å bruke standard webteknologiverktøy – nettleser, CGI og Java. Dette reduserer datavolumet mellom klienten og applikasjonsserveren, slik at klientdatamaskiner kan kobles til selv over langsomme linjer som telefonlinjer. Som sådan kan klientsiden være så enkel at den i de fleste tilfeller gjøres ved hjelp av en generisk nettleser. Men hvis du fortsatt må endre det, kan denne prosedyren implementeres raskt og smertefritt.

En applikasjonsserver er programvare som er et mellomlag mellom serveren og klienten.

• - Meldingsorientert - lyse representanter for MQseries og JMS;
• - Object Broker - lyse representanter for CORBA og DCOM;
• - Komponentbasert - lyse representanter for .NET og EJB.

Bruken av en applikasjonsserver gir mange flere funksjoner, for eksempel reduseres belastningen på klientdatamaskiner, siden applikasjonsserveren balanserer belastningen og gir beskyttelse mot feil. Siden forretningslogikken er lagret på applikasjonsserveren, vil ikke endringer i rapportering eller beregninger påvirke klientprogrammene på noen måte.

Det er få applikasjonsservere fra så kjente selskaper som Sun, Oracle Microsystem, IBM, Borland, og hver av dem er forskjellige i settet med tjenester som tilbys (jeg vil ikke ta hensyn til ytelsen i dette tilfellet). Disse tjenestene gjør det enkelt å programmere og distribuere bedriftsomfattende applikasjoner. Vanligvis tilbyr applikasjonsserveren følgende tjenester:

• - WEB Server - inkluderer oftest den kraftigste og mest populære Apache;
• - WEB Container - lar deg kjøre JSP og servlets. For Apache er dette Tomcat;
• - CORBA Agent - kan gi en distribuert katalog for lagring av CORBA-objekter;
• - Meldingstjeneste - meldingsmegler;
• - Transaksjonstjeneste - allerede fra navnet er det tydelig at dette er en transaksjonstjeneste;
• - JDBC - drivere for tilkobling til databaser, fordi det er applikasjonsserveren som skal kommunisere med databasene og den må kunne kobles til databasen som brukes i din bedrift;
• - Java Mail - denne tjenesten kan tilby tjenester til SMTP;
• - JMS (Java Messaging Service) - behandling av synkrone og asynkrone meldinger;
• - RMI (Remote Method Invocation) - anrop eksterne prosedyrer.

Flerlags klient-/serversystemer kan enkelt oversettes til nettteknologi - for å gjøre dette må du erstatte klientdelen med en spesialisert eller universell nettleser, og supplere applikasjonsserveren med en webserver og små serverprosedyreanropsprogrammer. Til

Disse programmene kan utvikles ved hjelp av både Common Gateway Interface (CGI) og den mer moderne Java-teknologien.

I et trelagssystem kan de raskeste linjene som krever minimale kostnader brukes som kommunikasjonskanaler mellom applikasjonsserveren og DBMS, siden serverne vanligvis er plassert i samme rom (serverrom) og ikke vil overbelaste nettverket pga. overføring av store mengder informasjon.

Av alt det ovennevnte følger det at tolagsarkitekturen er veldig dårligere enn flerlagsarkitekturen, i denne forbindelse brukes i dag bare flerlags klient-serverarkitekturen, som gjenkjenner tre modifikasjoner - RDA, DBS og SOM.

Ulike modeller av "Client-server" teknologi

Den aller første grunnleggende underliggende teknologien for lokale nettverk var filservermodell (FS)... På den tiden var denne teknologien veldig vanlig blant innenlandske utviklere som brukte systemer som FoxPro, Clipper, Clarion, Paradox og så videre.

I FS-modellen er funksjonene til alle 3 komponentene (presentasjonskomponent, applikasjonskomponent og ressurstilgangskomponent) kombinert i én kode, som kjøres på serverdatamaskinen (verten). Det er ingen klientdatamaskin i denne arkitekturen, og visning og presentasjon av data utføres ved hjelp av en datamaskin eller en terminal i rekkefølgen til terminalemulering. Søknader skrives vanligvis på fjerde generasjons språk (4GL). En av datamaskinene på nettverket regnes som en filserver og gir andre datamaskiner filbehandlingstjenester. Den opererer under kontroll av et nettverksoperativsystem og spiller en viktig rolle som en komponent i tilgang til informasjonsressurser. På andre PC-er i nettverket kjører en applikasjon, i kodene som applikasjonskomponenten og presentasjonskomponenten er koblet til.

Handlingsteknologien mellom klienten og serveren er som følger: forespørselen sendes til filserveren, som overfører den nødvendige datablokken til DBMS som ligger på klientdatamaskinen. All behandling gjøres på terminalen.

En utvekslingsprotokoll er et sett med samtaler som gir en applikasjon tilgang til filsystemet på en filserver.

De positive sidene ved denne teknologien er:

• - enkel applikasjonsutvikling;
• - enkel administrasjon og programvareoppdateringer
• - lave kostnader for å utstyre arbeidsplasser (terminaler eller billige datamaskiner med lave egenskaper i terminalemuleringsmodus er alltid billigere enn fullverdige PC-er).

Men fordelene med FS - modellen overgår ulempene:

Til tross for den store mengden data som sendes over nettverket, er responstiden kritisk, fordi hvert tegn som legges inn av klienten på terminalen må overføres til serveren, behandles av applikasjonen og returneres tilbake for å vises på terminalskjermen . I tillegg kommer problemet med å fordele belastningen mellom flere datamaskiner.

• - dyr servermaskinvare siden alle brukere deler ressursene sine;
• - mangel på et grafisk grensesnitt .

Takket være løsningen av problemene som ligger i "File - Server"-teknologien, har det dukket opp en mer progressiv teknologi, kalt "Client - Server".

For moderne DBMS har klient-server-arkitekturen blitt de facto-standarden. Hvis det antas at den prosjekterte nettverksteknologien vil ha en "klient-server"-arkitektur, betyr dette at applikasjonsprogrammene implementert innenfor rammen vil ha en distribuert natur, det vil si at noen av applikasjonsfunksjonene vil bli implementert i klienten. program, den andre i program-serveren.

Forskjeller i implementeringen av applikasjoner innenfor Client-Server-teknologien bestemmes av fire faktorer:

• - hvilke typer programvare i logiske komponenter;
• - hvilke programvaremekanismer som brukes for å implementere funksjonene til logiske komponenter;
• - hvordan logiske komponenter distribueres av datamaskiner på nettverket;
• - hvilke mekanismer som brukes for å koble komponentene sammen.

Basert på dette skilles tre tilnærminger ut, som hver er implementert i den tilsvarende modellen av Client-Server-teknologien:

• - modell for tilgang til eksterne data (Remote Date Access - RDA);
• - databaseservermodell (DateBase Server - DBS);
• - modellen til applikasjonsserveren (Application Server - AS).

En betydelig fordel med RDA-modellen er det brede utvalget av applikasjonsutviklingsverktøy som gir rask dannelse av skrivebordsapplikasjoner som fungerer med SQL-orienterte DBMS-er. Vanligvis støtter verktøyene et grafisk brukergrensesnitt med et OS, samt automatisk kodegenerering, hvor presentasjons- og applikasjonsfunksjoner blandes.

Til tross for sin brede distribusjon, viker RDA-modellen for den mest teknologisk avanserte DBS-modellen.

Databaseservermodell (DBS) - nettverksarkitektur for "Client - Server"-teknologien, som er basert på mekanismen for lagrede prosedyrer som implementerer applikasjonsfunksjoner. I DBS-modellen er konseptet med en informasjonsressurs komprimert til en database på grunn av den samme mekanismen for lagrede prosedyrer, implementert i DBMS, og selv da ikke i alle.

Fordelene med DBS-modellen fremfor RDA-modellen er åpenbare: det er både muligheten for sentralisert administrasjon av ulike funksjoner, og reduksjon av nettverkstrafikk fordi i stedet for SQL-spørringer, blir anrop av lagrede prosedyrer overført over nettverket, og muligheten å dele en prosedyre mellom to applikasjoner, og lagre dataressurser for å bruke den en gang opprettede planen for utførelse av prosedyren.

Application Server (AS) modell er en nettverksarkitektur av Client-Server-teknologien, som er en prosess som kjører på en klientdatamaskin og er ansvarlig for brukergrensesnittet (datainndata og visning). Det viktigste elementet i en slik modell er applikasjonskomponenten, som kalles applikasjonsserveren; den opererer på en ekstern datamaskin (eller to datamaskiner). Applikasjonsserveren er implementert som en gruppe applikasjonsfunksjoner, utformet i form av tjenester (tjenester). Hver tjeneste gir noen tjenester til alle programmer som ønsker og kan bruke dem.

Etter å ha lært alle modellene av Client-Server-teknologien, kan vi trekke følgende konklusjon: RDA- og DBS-modeller, disse to modellene er basert på et to-lags funksjonsdelingsskjema. I RDA-modellen overføres applikasjonsfunksjoner til klienten, i DBS-modellen implementeres kjøringen gjennom DBMS-kjernen. I RDA-modellen er applikasjonskomponenten slått sammen med presentasjonskomponenten, i DBS-modellen er den integrert i ressurstilgangskomponenten.

AS-modellen implementerer en tre-lags separasjon av funksjoner, der applikasjonskomponenten er isolert som hovedisolert element i applikasjonen, som har standardiserte grensesnitt med to andre komponenter.

Resultatene av analysen av modellene for teknologiene "Filserver" og "Klient - Server" er presentert i tabell 1.

Til tross for navnet er Client-Server-teknologien også et distribuert datasystem. I dette tilfellet distribuert databehandling forstås som en klient-server-arkitektur med deltagelse av noen servere. I sammenheng med distribuert behandling betyr begrepet "server" ganske enkelt et program som svarer på forespørsler og utfører de nødvendige handlingene på forespørsel fra klienten. Fordi Grid Computing er en type klient-server-system, opplever brukerne de samme fordelene, som økt total båndbredde og muligheten til å multitaske. Dessuten bidrar det til økt effektivitet og reduserte besparelser å integrere diskrete nettverkskomponenter og få dem til å fungere som en helhet.

Fordi prosessering foregår hvor som helst på nettverket, sikrer distribuert databehandling i en klient-server-arkitektur effektiv skalerbarhet. For å oppnå en balanse mellom server og klient bør en applikasjonskomponent kun foregå på serveren dersom sentralisert behandling er mer effektiv. Hvis logikken til programmet som samhandler med de sentraliserte dataene er konsentrert på samme maskin som dataene, trenger de ikke å overføres over nettverket, så kravene til nettverksmiljøet kan reduseres.

Som et resultat kan følgende konklusjon trekkes: hvis du trenger å jobbe med små informasjonssystemer som ikke krever et grafisk brukergrensesnitt, kan du bruke FS - modellen. Spørsmålet om GUI kan løses fritt ved å bruke RDA-modellen. DBS-modellen er et veldig godt alternativ for databasestyringssystemer (DBMS). AS-modellen er det beste alternativet for å lage store informasjonssystemer, så vel som ved bruk av lavhastighets kommunikasjonskanaler.

Avdeling for generell og yrkesrettet utdanning i Bryansk-regionen

Statens utdanningsinstitusjon

Klintsovsky Textile College

PROGRAMVARE FOR AUTOMATISERT INFORMASJONSSYSTEM

Klient-server-teknologi

Student gr. A-90 __________________________ (Petrochenko A.O.)

Lærer ____________________ (Shirokova A.L.)

Klintsy - 2011

1. Servere. Server grunnleggende konsepter

2. Klient-server-modell

3. Klassifisering av standard servere

4. Produksjon

1. Servere. Server grunnleggende konsepter

Server (fra den engelske serveren, servering). Avhengig av formålet er det flere definisjoner av begrepet server.

1. Server (nettverk) - en logisk eller fysisk nettverksnode som betjener forespørsler til én adresse og/eller domenenavn (tilstøtende domenenavn), som består av en eller et system med maskinvareservere som kjører ett eller et system med serverprogrammer

2. Server (programvare) - programvare som mottar forespørsler fra klienter (i klient-server-arkitektur).

3. Server (maskinvare) - en datamaskin (eller spesielt datautstyr) dedikert og/eller spesialisert til å utføre visse tjenestefunksjoner.

3. Server i informasjonsteknologi - en programvarekomponent i et datasystem som utfører tjenestefunksjoner på forespørsel fra en klient, og gir ham tilgang til visse ressurser.

Sammenheng mellom begreper. En serverapplikasjon (server) kjører på en datamaskin, også kalt en "server", mens med tanke på nettverkstopologien, kalles en slik node en "server". I det generelle tilfellet kan det være at en serverapplikasjon kjører på en vanlig arbeidsstasjon, eller en serverapplikasjon som kjører på en serverdatamaskin innenfor rammen av den betraktede topologien fungerer som en klient (dvs. ikke er en server når det gjelder nettverk topologi).

2. Klient-server-modellen

Et klient-server-system er preget av tilstedeværelsen av to interagerende uavhengige prosesser - en klient og en server, som i det generelle tilfellet kan kjøres på forskjellige datamaskiner og utveksle data over nettverket.

Prosesser som implementerer en tjeneste, for eksempel et filsystem eller databasetjeneste, kalles servere(servere). Prosesser som ber om tjenester fra servere ved å sende en forespørsel og deretter vente på svar fra serveren kalles klienter(klienter).

I henhold til denne ordningen kan databehandlingssystemer basert på DBMS, post og andre systemer bygges. Vi skal snakke om databaser og systemer basert på dem. Og her vil det være mer praktisk ikke bare å vurdere klient-server-arkitekturen, men å sammenligne den med en annen - fil-server-arkitektur.

I et filserversystem lagres data på en filserver (for eksempel Novell NetWare eller Windows NT Server), og behandlingen av dem utføres på arbeidsstasjoner, som som regel kjører en av de såkalte "desktop DBMS "- Access, FoxPro, Paradox, etc.

En applikasjon på en arbeidsstasjon er "ansvarlig for alt" - for dannelsen av brukergrensesnittet, logisk behandling av data og for direkte manipulering av data. Filserveren tilbyr kun tjenestene på laveste nivå - åpning, lukking og endring av filer. Vennligst merk - filer, ikke databaser. Databasebehandlingssystemet er plassert på arbeidsstasjonen.

Dermed er flere uavhengige og inkonsekvente prosesser involvert i direkte datamanipulering. I tillegg, for å utføre enhver behandling (søk, modifikasjon, summering, etc.), må alle data overføres over nettverket fra serveren til arbeidsstasjonen ( se fig. Sammenligning av fil-server- og klient-server-modeller)

Ris. Sammenligning av fil-server- og klient-server-modeller

I et klient-serversystem er det (minst) to applikasjoner - en klient og en server, som deler funksjonene som en applikasjon på en arbeidsstasjon utfører i sin filserverarkitektur. Lagring og direkte manipulering av data håndteres av en databaseserver, som kan være Microsoft SQL Server, Oracle, Sybase, etc.

Brukergrensesnittet dannes av klienten, som du kan bruke en rekke spesialverktøy for, samt de fleste desktop DBMS. Databehandlingslogikken kan utføres både på klienten og på serveren. Klienten sender spørringer til serveren, vanligvis formulert i SQL. Serveren behandler disse forespørslene og sender resultatet til klienten (selvfølgelig kan det være mange klienter).

Dermed er én prosess involvert i direkte datamanipulering. Samtidig foregår databehandlingen på samme sted som dataene lagres – på serveren, noe som eliminerer behovet for å overføre store datamengder over nettverket.

Hva gir klient-server-arkitekturen?

La oss se på denne arkitekturen fra synspunktet til forretningsbehov. Hvilke kvaliteter tilfører klient-serveren informasjonssystemet?

Pålitelighet

Databaseserveren utfører datamodifisering basert på transaksjonsmekanismen, som gir ethvert sett med operasjoner som er erklært som en transaksjon, følgende egenskaper:

• atomitet- under noen omstendigheter vil enten alle operasjoner av transaksjonen bli utført, eller ingen vil bli utført; dataintegritet ved slutten av en transaksjon;
• uavhengighet- transaksjoner initiert av forskjellige brukere forstyrrer ikke hverandres saker;
• feiltoleranse- etter at transaksjonen er fullført, vil resultatene ikke gå tapt.

Transaksjonsmekanismen som støttes av databasetjeneren er mye mer effektiv enn motparten i stasjonære DBMS-er fordi den er det serveren kontrollerer sentralt driften av transaksjoner. I tillegg, i filserversystemet kan en feil på en av arbeidsstasjonene føre til tap av data og utilgjengelighet til andre arbeidsstasjoner, mens en feil på klienten i klient-serversystemet praktisk talt aldri påvirker dataintegriteten og deres tilgjengelighet for andre kunder.

Skalerbarhet

Skalerbarhet - systemets evne til å tilpasse seg veksten av antall brukere og volumet av databasen med en tilstrekkelig økning i ytelsen til maskinvareplattformen, uten å erstatte programvaren.

Det er velkjent at mulighetene til desktop DBMS er alvorlig begrenset - disse er henholdsvis fem til syv brukere og 30-50 MB. Tallene representerer selvfølgelig noen gjennomsnittsverdier, i spesifikke tilfeller kan de avvike både i en retning og i den andre retningen. Det viktigste er at disse barrierene ikke kan overvinnes ved å bygge opp maskinvarefunksjoner.

Databaseserversystemer kan støtte tusenvis av brukere og hundrevis av GB med informasjon - bare gi dem riktig maskinvareplattform.

Sikkerhet

Databaseserveren gir kraftig databeskyttelse mot uautorisert tilgang som ikke er mulig med desktop DBMS. Samtidig administreres tilgangsrettigheter svært fleksibelt – opp til nivå med tabellfelt. I tillegg kan du generelt forby direkte tilgang til tabeller ved å utføre brukerinteraksjon med data gjennom mellomobjekter - visninger og lagrede prosedyrer. Så administratoren kan være sikker på at ingen altfor smarte brukere vil lese det han ikke skal lese.

Fleksibilitet

Det er tre logiske lag i en dataapplikasjon:

• brukergrensesnitt ;
• logiske behandlingsregler(forretningsregler);
• Dataledelse(Ikke forveksle logiske lag med fysiske lag, som vil bli diskutert nedenfor).

Som nevnt tidligere, i en filserverarkitektur er alle tre lagene implementert i en enkelt monolittisk applikasjon som kjører på en arbeidsstasjon. Derfor fører endringer i noen av lagene utvetydig til endring av applikasjonen og den påfølgende oppdateringen av versjonene på arbeidsstasjoner.

I to-lags klient-server-applikasjonen vist i figuren ovenfor, er som regel alle funksjonene for å danne brukergrensesnittet implementert på klienten, alle databehandlingsfunksjoner er på serveren, men forretningsregler kan implementeres som på serveren som bruker serverprogrammeringsmekanismene (lagrede prosedyrer, triggere, visninger osv.) og på klienten.

I en applikasjon med tre nivåer vises et tredje mellomnivå som implementerer forretningsregler, som er de hyppigst endrede applikasjonskomponentene ( se fig. Tre-lags klient-server applikasjonsmodell)

Ris. Tre-lags klient-server applikasjonsmodell

Tilstedeværelsen av ikke ett, men flere nivåer lar deg fleksibelt og kostnadseffektivt tilpasse applikasjonen til endrede forretningskrav.

La oss prøve å illustrere alt ovenfor med et lite eksempel. Anta at en organisasjon har endret sine lønnsregler (forretningsregler) og må oppdatere programvaren.

1) I et filserversystem gjør vi "bare" endringer i applikasjonen og oppdaterer dens versjoner på arbeidsstasjoner. Men dette medfører «bare» maksimale arbeidskostnader.

2) I et to-lags klient-serversystem, hvis lønnsalgoritmen er implementert på serveren i form av en lønnsregel, utføres den av forretningsregelserveren, utført for eksempel i form av en OLE-server , og vi vil oppdatere ett av objektene uten å endre noe verken i klientapplikasjonen eller på databaseserveren.

Klient-server-teknologier

Nesten alle modeller for organisering av brukerinteraksjon med en database er basert på klient-server-teknologi. Det antas at hver slik applikasjon er forskjellig når det gjelder distribusjon av funksjoner: klientdelen er ansvarlig for målrettet behandling av data og organisering av interaksjon med brukeren, serverdelen gir datalagring - behandler forespørsler og sender resultatene til klienten for spesialbehandling. En typisk arkitektur for klient-server-teknologi er vist i fig. 4.1:

Ris. 4.1. Typisk arkitektur for klient-server-teknologi

Noen av funksjonene til de sentrale datamaskinene ble overtatt av lokale datamaskiner. I dette tilfellet er enhver programvareapplikasjon representert av tre komponenter: en presentasjonskomponent som implementerer et grensesnitt med brukeren; en applikasjonskomponent som gir implementering av applikasjonsfunksjoner; komponent av tilgang til informasjonsressurser (ressursansvarlig), utføre informasjonsakkumulering og datahåndtering.

Basert på fordelingen av disse komponentene mellom en arbeidsstasjon og en nettverksserver, skilles følgende modeller av "klient-server"-arkitekturen:

· Modell for tilgang til eksterne data (fig. 4.2). Serveren inneholder kun data:

Ris. 4.2. Modell for ekstern datatilgang

Denne modellen er preget av lav ytelse, siden all informasjon behandles på arbeidsstasjoner; i tillegg støttes en lav valutakurs ved overføring av store mengder informasjon fra en server til arbeidsstasjoner;

Databehandlingsservermodell (fig. 4.3):

Ris. 4.3. Data Management Server Modell

Funksjoner ved denne modellen: reduksjon av mengden informasjon som overføres over nettverket, siden valget av nødvendige informasjonselementer utføres på serveren, og ikke på arbeidsstasjoner; forening og et bredt spekter av verktøy for å lage applikasjoner; mangelen på et klart skille mellom presentasjonskomponenten og applikasjonskomponenten, noe som gjør det vanskelig å forbedre datasystemet. Det er tilrådelig å bruke ved behandling av moderate mengder informasjon, mens kompleksiteten til den anvendte komponenten bør være lav,

· Modell av en kompleks server (fig. 4.4):

Ris. 4.4. Kompleks servermodell

Fordeler med modellen: høy ytelse, sentralisert administrasjon, sparer nettverksressurser. En slik server er optimal for store nettverk fokusert på å behandle store og økende informasjonsmengder over tid;

· Tre-lags arkitektur "klient-server" (fig. 4.5). Den brukes når du kompliserer og øker ressursintensiteten til applikasjonskomponenten.

Ris. 4.5. Tre-lags arkitektur

Flere applikasjonsfunksjoner kan implementeres i applikasjonsserveren, som hver er utformet som en egen tjeneste som gir noen tjenester til alle programmer. Det kan være flere slike servere, hver av dem er fokusert på å tilby et visst sett med tjenester. Denne arkitekturen er basert på ytterligere spesialisering av arkitekturkomponenter: klienten er kun opptatt av å organisere grensesnittet med brukeren, databaseserveren utfører kun standard databehandling, for å implementere databehandlingslogikken, arkitekturen gir et eget lag - et lag med forretningslogikk, kan det enten være en dedikert server (applikasjonsserver ), eller vert på klienten som et bibliotek.

Innenfor klient-server-arkitekturen er det to grunnleggende konsepter:

· "Tynn klient. En kraftig databaseserver og et bibliotek med lagrede prosedyrer brukes til å gjøre beregninger som implementerer hovedlogikken til databehandling direkte på serveren. Klientapplikasjonen stiller derfor lave krav til maskinvaren til arbeidsstasjonen;

· En "feit" klient implementerer hovedprosesseringslogikken på klienten, og serveren er en ren databaseserver, som sikrer kjøring av kun standardforespørsler for datamanipulering (som regel lesing, skriving, modifisering av data i relasjonsdatabasetabeller) .

Nettverksbasert IT

E-post... Den aller første, denne formen for elektroniske meldinger (e-post), demonstrerte selve muligheten for nesten umiddelbar kommunikasjon gjennom datanettverk. Arkitektonisk ment for utveksling av meldinger mellom to abonnenter, tillot det grupper av mennesker å utveksle informasjon. Grupper eller e-postlister ble en slik modifikasjon. Med e-postprogramvare kan du opprette og legge ved e-postmeldinger. Vedleggsfunksjonen brukes til å sende dokumenter av enhver type med post, for eksempel tekstdokumenter, regneark, multimediefiler, databasefiler, etc. Senere utviklet tekstfiltreringsprogramvare utvidet mulighetene til e-post for å hjelpe brukeren med å strukturere, dirigere og filtrere meldinger. Behovet for disse tjenestene skyldes at mengden post, som nesten eller ikke er nødvendig for brukeren (Spam), stadig øker. Filtreringsprogramvaren kan sørge for at kun personlige meldinger som inneholder nyheter som er viktige for dem, leveres til brukerne, og hjelper også med å finne informasjon som brukerne trenger i beslutningsprosessen.

Nyhetsgrupper eller nyhetsgrupper... Telekonferanser er neste trinn i utviklingen av kommunikasjonssystemer. Funksjonene deres var for det første å lagre meldinger og gi interesserte parter tilgang til hele utvekslingshistorien, og for det andre ulike metoder for tematisk gruppering av meldinger. Slike konferansesystemer gir en mulighet for en gruppe fellesarbeidende, men geografisk adskilte mennesker til å utveksle meninger, ideer eller informasjon på nettet når de diskuterer ethvert problem, og overvinne tidsmessige og romlige barrierer. I dag finnes det mange typer konferansesystemer, inkludert datakonferanser (møter som holdes på e-post), konferansesamtaler med mulighet for å koble til mobile innringere, konferanser ved hjelp av stasjonære PC-er, multimedia, telekonferanser og videokonferanser.

Interaktiv kommunikasjon(chatter). Med utviklingen av telekommunikasjon begynner et økende antall brukere å jobbe på Internett i en permanent tilstedeværelsesmodus, derfor har en sanntidskommunikasjonstjeneste dukket opp når en abonnent mottar en melding innen kort tid etter at den ble sendt av en samtalepartner.

De vanligste moderne måtene for interaktiv kommunikasjon er nettapplikasjoner som støtter følgende former for organisering av kommunikasjon:

o Gjestebøker. Den første og enkleste formen. Den enkleste gjesteboken er en liste over meldinger vist fra den siste til den første, og hver av dem ble lagt igjen i den av en besøkende.

o Forum... De første forumene dukket opp som en forbedring av gjestebøker og organiserte innlegg i grener - omtrent som nyhetsgrupper. Brukerinnlegg i forum er gruppert etter emner, som vanligvis settes av de første innleggene. Alle besøkende kan se emnet og legge ut budskapet sitt – som svar på de som allerede er skrevet. Emner er gruppert i tematiske fora, systemet administreres av uformelle administratorer og moderatorer. De mest utviklede foraene begynner å ha de første tegnene på sosiale nettverk - langsiktige sosiale bånd av interesse kan etableres mellom deltakerne.

o Blogger(Web-logg - Web-logg, Web-protokoll). I disse tjenestene fører hver deltaker sin egen journal - legger igjen journaler i kronologisk rekkefølge. Innleggsemner kan være hva som helst, den vanligste tilnærmingen er blogging som din egen dagbok. Andre besøkende kan legge igjen kommentarer på disse innleggene. I dette tilfellet får brukeren, i tillegg til å kunne føre sin egen journal, muligheten til å organisere en listevisning - en liste over oppføringer fra "venner"-journaler, regulere tilgangen til oppføringer, og lete etter samtalepartnere etter interesser. På grunnlag av slike systemer skapes interessefellesskap – journaler som føres samlet. I et slikt fellesskap kan medlemmene fritt legge ut en melding om retningen for fellesskapets aktiviteter.

Generelt har alle moderne systemer for å sikre arbeidet til nettverkssamfunn flere fellestrekk:

· De aller fleste fellesskap sørger for brukerregistrering, d.v.s. det må opprettes en konto for hver deltaker. Ved registrering oppgir brukeren noe informasjon om seg selv for identifikasjon. Nesten alle systemer krever at du oppgir en e-postadresse og sjekker funksjonaliteten ved å sende en e-post med en kontoaktiveringskode. Hvis adressen er feil, kan bare systemadministratoren aktivere oppføringen. Denne tilnærmingen garanterer til en viss grad deltakerens unike karakter og identifiserbarhet.

· Arbeid i miljøet utføres i økter. Hver økt begynner med at brukeren skriver inn navnet sitt og bekrefter identiteten sin ved å skrive inn et passord. For enkelhets skyld er deltakelsesøkten vanligvis skjult for brukeren med tekniske midler, men ikke desto mindre skjer identifiseringen av brukeren konstant.

I tillegg til legitimasjon, konfigurerer brukeren miljøet - utseende, tilleggsdata om seg selv, indikerer hans interesser, ønskede kontakter, emner for kommunikasjon, etc.

· Sosiale nettverk og tjenestene som støtter dem har vist seg å være en ekstremt effektiv metode for å sikre nettstedtrafikk, tilbakemeldinger, de ble gradvis et av virkemidlene for å fylle nettstedets innhold med innhold som har reell kommersiell og sosial verdi.

Basert på den sistnevnte tilnærmingen dukket det opp et ganske stort antall sosiale netttjenester og ble raskt populære, samlet kalt Web 2.0-tjenester. Noen av disse ressursene kan spesifiseres:

o Sosiale bokmerker... Noen nettsteder lar brukere dele en liste over bokmerker eller populære nettsteder med andre. Slike nettsteder kan også brukes til å finne brukere med en felles interesse. Eksempel: Deilig.

o Sosiale kataloger minner om sosiale bokmerker, men fokuserte på akademisk bruk, slik at brukerne kan jobbe med en database med sitater fra vitenskapelige artikler. Eksempler: Academic Search Premier, LexisNexis Academic University, CiteULike, Connotea.

o Sosiale biblioteker er applikasjoner som lar besøkende legge igjen lenker til sine samlinger, bøker, lydopptak tilgjengelig for andre. Støtte for et system med anbefalinger og rangeringer er gitt. Eksempler: discogs.com, IMDb.com.

o Multiplayer online spill simuler virtuelle verdener med forskjellige poengsystemer, nivåer, konkurranse, vinnere og tapere. Eksempel: World of Warcraft.

o Flerspråklige sosiale nettverk lar deg etablere sosiale bånd mellom mennesker som snakker forskjellige språk. Samtidig brukes spesiell programvare som lar deg oversette fraser fra ett språk til et annet i sanntid. Eksempler: Dudu.

o Geososiale nettverk danne sosiale forbindelser basert på brukerens geografiske plassering. Samtidig brukes ulike geolokaliseringsverktøy (for eksempel GPS eller hybridsystemer som AlterGeo-teknologi), som gjør det mulig å bestemme gjeldende plassering av en bestemt bruker og korrelere hans posisjon i rommet med plasseringen til ulike steder og folk rundt.

o Profesjonelle sosiale nettverk er laget for kommunikasjon om faglige temaer, erfarings- og informasjonsutveksling, søk og tilbud om ledige stillinger, utvikling av forretningsmessige bånd. Eksempler: Doctor at work, Professionals.ru, MyStarWay.com, LinkedIn, MarketingPeople, Viadeo.

o Tjeneste sosiale nettverk tillate brukere å forene seg på nettet rundt sine felles interesser, hobbyer eller av ulike grunner. Noen nettsteder tilbyr for eksempel tjenester der brukere kan dele personlig informasjon som er nødvendig for å finne partnere. Eksempler: LinkedIn, VKontakte.

o Kommersielle sosiale medier fokusert på å støtte forretningstransaksjoner og bygge folks tillit til merkevarer basert på å ta hensyn til deres meninger om produktet, og dermed la forbrukere delta i å markedsføre produktet og øke deres bevissthet.