DB ASIAKAS-PALVELINARKKITEHTUURESSA

Luentosuunnitelma

1. Asiakkaat ja palvelimet paikalliset verkot

2. Järjestelmäarkkitehtuuri asiakas-palvelin

3. Työkuormitusmallit asiakas/palvelin-arkkitehtuurissa

4. "Client-server" -arkkitehtuurin tasot ja mallit

T. Connolly. Tietokanta. Suunnittelu, toteutus ja tuki. Teoria ja käytäntö.: Per. englannista. – M.: Toim. talo "Williams", 2006. - 1440 s.

1 LAN-asiakkaat ja -palvelimet

Tietokoneiden lähiverkkojen laajan käytön ytimessä on tunnettu ajatus resurssien jakamisesta. Tämän idean kehittäminen johtaa verkkokomponenttien toiminnalliseen erottamiseen: paikallisverkon työasemat ja palvelimet. Paikallinen verkkopalvelin (palvelin) tarjoaa resursseja (palveluita) työasemille ja/tai muille palvelimille. Työasema (asiakkaat (client)) - tietokoneet, jotka tarjoavat pääsyn palvelimen tarjoamiin verkkoresursseihin.

Lähestymistapaan keskittymisen vuoksi avoimet järjestelmät, on oikeampaa puhua loogisista palvelimista (tarkoittaen joukkoa resursseja ja ohjelmistotyökaluja, jotka tarjoavat palveluita näiden resurssien yli). Esimerkkejä loogisista palvelimista ovat:

tiedostopalvelin, joka ylläpitää yhteistä tiedostomuistia kaikille työasemille ja pyydettäessä tiedosto tai tiedot kopioidaan kokonaisuudessaan pyynnön esittäneelle tietokoneelle;

sovelluspalvelin suorittaa asiakas-palvelin-sovellusten sovellusosat ja sisältää myös asiakkaiden käytettävissä olevia tietoja;

2 Asiakas-palvelin -järjestelmäarkkitehtuuri

"Client-server" -järjestelmäarkkitehtuurin perusperiaatteet ovat seuraavat: IS on jaettu kahteen osaan, jotka voidaan suorittaa eri verkkosolmuissa - asiakas- ja palvelinosissa.

Palvelinpuoli toimii erikoistuneella laitteistokompleksilla, joka sisältää tehokkaat laitteistot, tarvittavat vakioohjelmistot, tietokannan hallintajärjestelmän ja tietokannan.

Sovellusohjelma tai loppukäyttäjä on vuorovaikutuksessa asiakkaan puolella järjestelmä, joka yksinkertaisimmassa tapauksessa tarjoaa vain superverkkorajapinnan. Sovelluksen asiakaspuoli toimii käyttäjän työpaikalla, joka useimmiten on henkilökohtainen tietokone.

Järjestelmän asiakasosa ottaa tarvittaessa yhteyden palvelinosaan verkon kautta (paikallinen tai globaali). Samalla vuorovaikutus tapahtuu asiakkaan ja palvelimen näkökulmasta läpinäkyvästi. verkkokomponentti joka toteuttaa tämän vuorovaikutuksen, sisältää joukon tarpeellisia verkkolaitteet, joukko ohjelmistoteknologioita, jotka tarjoavat tiedonsiirron verkkosolmujen välillä, sekä varsinainen liitäntäohjelmistokerros (protokolla tai protokollat) pyyntöjen ja niiden suorittamisen tulosten vaihtamiseksi. Pääliittymänä asiakkaan ja palvelimen osat SQL on tietokantakieli.

Suurin osa yksinkertainen muoto asiakas-palvelin-arkkitehtuurit ovat laskennallisen kuormituksen jakamista kahden erillisen prosessin kesken: asiakkaan ja palvelimen. Lisäksi standardin interaktiivisen sovelluksen viisi toimintoryhmää on jaettu näiden kahden prosessin kesken:

1) dialogitoiminnot (Presentation Logic, PL) tai visualisointikomponentti. Sovellettavan tehtävän visualisointikomponentti suorittaa käyttäjän syötteitä eri keinoin sekä tietojen näyttämisen näytöllä ja tulostamisen. Asiakas-palvelin-arkkitehtuurin visualisointikomponentti suoritetaan aina käyttäjän työpaikalla (koska hänen on tarkkailtava ohjelman tuloksia). Esityslogiikan järjestämiseen käytetään pääasiassa GUI-mallia (User Interface Graphical) tai web-käyttöliittymää;

2) sovellustoiminnot tai se on osa sovelluskoodia tietojenkäsittelyalgoritmeilla (Business Logic, BL). Sovellettu logiikkakomponentti ratkaisee yhden tai toisen tiedonkäsittelyyn liittyvän tehtävän aihealue ja edustaa sovelluksen reaktioalgoritmeja käyttäjän toimiin tai sisäisiin tapahtumiin, tietojenkäsittelysääntöjä. Tämä komponentti voidaan jakaa asiakas- ja palvelinosien kesken eri tavoin riippuen käytetystä mallista. Yleensä tämä koodi ohjelmoidaan ohjelmointikielillä korkeatasoinen: C, C++, Visual Basic, Object Pascal jne.;

3) sovelluksen tietojenkäsittelytoiminnot (Database Logic, DL) - tämä on osa sovelluskoodia, joka liittyy tietojen valintaan ja käsittelyyn (tietoa hallitsee DBMS itse). Alakieli on SQL.

Tyypillinen asiakas-palvelin-sovelluksen rakenne

4) ohjaustoiminnot tietolähteitä(Database Manager System, DBMS). Tietokannan tallennuskomponentti suorittaa fyysisiä toimintoja, jotka liittyvät tietojen tallentamiseen, tietojen lukemiseen tietokannasta ja kirjoittamiseen siihen liittyen, jotka liittyvät sovelluksen ratkaisemaan sovellettuihin tehtävään. Asiakas-palvelin-arkkitehtuurissa tämä komponentti toimii aina palvelimella;

5) palvelutoiminnot, jotka toimivat linkkinä aikaisempien toimintoryhmien välillä.

3 Asiakas/palvelin työkuormitusmallit

"Asiakas-palvelin" -järjestelmät voivat luottaa usean tyyppiseen tehtävien jakoon asiakkaan ja palvelimen välillä:

· "älykkäät" asiakkaat (paksu asiakas - ohut palvelin);

· "älykäs" palvelin (ohut asiakas - paksu palvelin);

· sekajärjestelmät;

· monitasoiset järjestelmät.

DIV_ADBLOCK80">

"Älykkäät" palvelimet. Siirtämällä kaikki liiketoimintasäännöt SQL Serverille, jossa ne toteutetaan tallennettujen menettelyjen ja tietokantatriggerien muodossa, luodaan "älykäs" palvelin, joka vastaa myös tietokannan tallentamisesta ja toiminnasta. Palvelimen älykkyys ilmenee myös kyvyssä käsitellä tietoja (suorittaa SQL-kyselyitä) ja palauttaa tuloksena oleva tietojoukko asiakkaalle.

Asiakastietokoneessa on toteutettu vain tietojen esityslogiikka.

Edut:

· IS-suorituskyvyn kasvu: liiketoimintalogiikka toimii samassa osoiteavaruudessa kuin tietokannan pääsykoodi, ja lisäksi se on tiiviisti integroitu tiedonhakumekanismiin. Tämä tarkoittaa, että tietoja ei tarvitse siirtää tai kopioida ennen käsittelyä, mikä tarkoittaa verkkoliikennettä on minimoitu;

Tietojen eheys on helpompi varmistaa palvelimella;

· Tarvittaessa liiketoimintalogiikkaa muutetaan keskitetysti asiakasta vaihtamatta.

Virheet:

Lisääntyneet vaatimukset palvelinresursseille, joissa kaikki pyynnöt ja tietojen käsittely suoritetaan.

sekajärjestelmät. Myös sekavaihtoehdot ovat mahdollisia sekä älykkäiden palvelimien että älykkäiden asiakkaiden eduilla. Palvelin yleensä ottaa käyttöön DBMS:n, tiedonkäsittelylogiikan ja sen osan liiketoimintalogiikasta, joka on yhteinen monille asiakkaille. Asiakkaassa otetaan käyttöön tietojen esityslogiikka ja osa tälle asiakkaalle ominaista liiketoimintalogiikkaa.

Sekajärjestelmien edut:

· palvelinkoodi on samanaikaisesti useiden asiakkaiden käytettävissä, mikä vähentää samantyyppisten pyyntöjen suorittamista;

Asiakkaan suorituskyky on vähemmän riippuvainen verkkoliikenteestä.

Virheet:

· Liiketoimintalogiikka on hajautettu asiakkaan ja palvelimen kesken, ja sovellusta päivitettäessä on tarpeen jakaa asiakasosan uusia versioita laajalle yleisölle.

Kerrostettu järjestelmä(kutsutaan joskus kolmitasoiseksi) mahdollistaa erottamisen käyttöliittymä, liiketoimintasäännöt ja tietokanta. Kerrostetussa järjestelmässä liiketoimintasäännöt sijoitetaan sovelluspalvelimelle − ohjelmistokomponentti, joka on sijoitettu tietokantapalvelimen ja asiakkaiden väliin. Asiakas vastaa vain rajapinnasta käyttäjän kanssa, tietokantapalvelin itse tietokannan ylläpidosta ja toiminnasta. Välikerros on palvelin käyttäjälle ja asiakas tietokannan hallintajärjestelmälle. Asiakkaat hakevat tarvittaessa sovelluspalvelimelta, joka puolestaan ​​hakee tietokantapalvelimelta asiakaspyyntöjen toteuttamiseen tarvittavia tietoja.

Monitasoisten järjestelmien edut:

käyttöliittymäkomponenttien, liiketoimintasääntöjen ja tietojen tallennuksen erottaminen, mikä lisää tietokantapalvelimen suorituskykyä ja suojaa sen luvattomalta käytöltä;

liiketoimintasääntöjen keskitetty muuttaminen;

Virheet:

verkkoliikenne lisääntyy.

Tällaisia ​​järjestelmiä on paljon vaikeampi kehittää, toteuttaa ja käyttää, ja ne vaativat huomattavia kustannuksia ja korkeasti koulutettua henkilöstöä.

4 Arkkitehtuurin kerrokset ja mallit"asiakas-palvelin"

Määrän suhteen osat asiakas-palvelin järjestelmät jaetaan kaksitasoisiin ja kolmitasoisiin.

Kaksitasoiset järjestelmät koostuvat vain asiakkaasta ja palvelimesta. Asiakas-palvelin-arkkitehtuurin kaksitasoisia malleja ovat:

1) tiedostopalvelimen malli (FS-malli);

2) etäkäyttömalli (RDA-malli);

3) aktiivinen palvelinmalli (DBS-malli).

Kolmiportaista mallia edustaa eräänlainen "asiakas-palvelin" -arkkitehtuuri, joka perustuu "asiakas - sovelluspalvelin" -malliin. Tämä arkkitehtuuri mahdollistaa järjestelmätoimintojen ja kuormituksen joustavamman jakautumisen laitteisto- ja ohjelmistojärjestelmän komponenttien välillä ja voi myös vähentää käyttäjien työasemien resurssivaatimuksia.

Tiedostopalvelimen arkkitehtuuri

Tiedostopalvelinarkkitehtuurissa (File Server, FS-malli) kaikki tietojärjestelmäsovelluksen päätoiminnot (esityslogiikka, liiketoimintalogiikka sekä tietojenkäsittely- ja hallintatoiminnot) sijaitsevat asiakkaalla (kuva 2).

Palvelin sisältää datatiedostoja ja tiedostoihin pääsyä tuetaan.

Tässä mallissa asiakas ottaa yhteyttä palvelimeen ja pyytää tietoja. Asiakkaan pyyntö muotoillaan YMD-komennoilla. DBMS kääntää tämän pyynnön tiedostokomentojen sarjaksi, tiedostonhallintajärjestelmä (FMS) lukee pyydetyt tiedot tietokannasta ja lähettää nämä tiedot lohko lohkolta asiakassovellukselle, minkä jälkeen DBMS analysoi vastaanotetut tiedot asiakassovelluksesta ja jos vastaanotettu lohko ei sisällä vastausta pyyntöön, tehdään päätös seuraavan tietolohkon siirrosta jne. Itse asiassa FS-malli olettaa offline-työtä IC-ohjelmisto päällä erilaisia ​​koneita verkossa. IS-komponentit ovat vuorovaikutuksessa vain läsnäolon vuoksi jaettu tallennustila tiedot. Tietenkin tällaisen tallennustilan tulisi olla hyvin suunniteltu tietokanta, jota hallinnoi FS-mallia tukeva DBMS, esimerkiksi Informix SE DBMS. Tällaista DBMS:ää ei voida pitää "todellisena palvelimena".

Tiedostopalvelimen arkkitehtuurin malli

FS-mallia käytettäessä DBMS-järjestelmästä luodaan kopio jokaista käyttäjän käynnistämää DBMS-istuntoa varten, joka toimii samassa prosessorissa kuin käyttäjäprosessi.

Yleensä tiedostopalvelin IS -arkkitehtuurissa meillä on "paksu" asiakas ja erittäin "ohut" palvelin siinä mielessä, että lähes kaikki työ tehdään asiakaspuolella ja palvelimelta vaaditaan vain riittävästi levytilaa. .

Tiedostopalvelinarkkitehtuurin haittoja ovat:

korkea verkkoliikenne, joka liittyy monien asiakassovellusten tarvitsemien lohkojen ja tiedostojen siirtoon verkon yli;

· rajoitettu joukko tietojen käsittelykomentoja, itse asiassa nämä ovat vain tiedostokomentoja;

heikko suorituskyky (riippuu verkon, palvelimen, asiakkaan suorituskyvystä);

Huono kyky yhdistää uusia asiakkaita;

Kehittyneiden tietosuojatyökalujen puute (vain tiedostojärjestelmätasolla).

Epäilemättömiä etuja ovat mm

Korkea tehokkuus työskennellä pieniä määriä tiedot yhden käyttäjän tilassa.

keskitetyn kulunvalvonnan mukavuus;

· halpa kehitystä;

· suuri nopeus kehitystä;

· Ei korkea hinta ohjelmistopäivitykset ja muutokset.

FS-malli ei täytä nykyaikaisia ​​ajatuksia "client-server" -tekniikasta yleisesti hyväksytyssä mielessä, joten tätä hajautetun laskennan organisointimenetelmää pidetään erillisenä tiedostopalvelinarkkitehtuurina.

Etäkäyttömalli dataan RDA ( Etä Data Pääsy , RDA )

Historiallisesti tämä malli kehitettiin aivan ensimmäisenä. Tässä mallissa palvelinosa tallentaa vain dataa, DBMS-ydin sijaitsee tässä ja tiedonkäsittelylogiikka on toteutettu ja asiakasosa toteuttaa kaiken sovelluslogiikan. Tässä tapauksessa asiakas lähettää palvelimelle pyyntöjä vastaanottaa tietoja, ja palvelin palauttaa tietyt näytteet asiakkaalle. Yleisin viestintäväline asiakkaan ja palvelimen välillä tässä tapauksessa on SQL ( jäsenneltyä kieltä kyselyt) on tavallinen ei-proseduurillinen datasuuntautunut kieli.

Asiakas on selvästi "laihtunut" verrattuna FS-malliin, mutta palvelintoiminnot ovat merkittävästi laajentuneet, verkkoliikenne vähentynyt ja RDA-mallin tärkein etu: SQL-kieli on ilmestynyt laajennetulla datamäärittelyllä ja tiedonkäsittelykomennot, jotka yhtenäisivät asiakas-palvelin-rajapinnan.

RDA-arkkitehtuurimalli

RDA-mallin edut:

· Business Logicin siirto asiakkaalle purkaa tietokantapalvelimen merkittävästi ja minimoi käyttöjärjestelmän prosessien kokonaismäärän;

· tietokantapalvelin vapautetaan sille epätavallisista toiminnoista, mikä tarkoittaa, että prosessori voidaan ladata täyteen pyyntöjen, tietojen ja tapahtumien käsittelytoimilla;

· Verkon kuormitus laskee jyrkästi, koska sen kautta ei välitetä asiakkailta palvelimelle I/O-pyyntöjä, vaan SQL-pyyntöjä, ja niiden määrä on paljon pienempi. Vastauksena pyyntöihin asiakas saa vain tietoja, kyselyyn liittyvää, ei tiedostolohkoja, kuten FS-mallissa.

RDA-mallin haitat:

edelleen korkea verkkoliikenne, varsinkin kun suurissa määrissä asiakkaita ja heidän intensiivistä työtä interaktiivisesti;

Sovelluskoodin tarpeeton päällekkäisyys, kuten liiketoimintalogiikan toistaminen jokaiselle asiakkaalle;

· asiakassovellusten monimutkaisuus tietoresurssien hallinnassa. Palvelimella on passiivinen rooli. Todellakin, jos meidän on esimerkiksi valvottava tavaran vakuutusvarastoa varastossa, niin jokainen sovellus, joka liittyy varaston tilan muutokseen, sen jälkeen, kun on suoritettu tietojen muokkaustoiminnot, jotka simuloivat tavaroiden myyntiä tai poistamista varastosta. varastosta, on tarkistettava saldon määrä, ja jos se on pienempi kuin varmuusvarasto, laadittava asianmukainen pyyntö vaadittujen tavaroiden toimittamiseksi. Tämä monimutkaistaa asiakassovellusta

Tietokantapalvelinmalli (kutsutaan joskus aktiiviseksi palvelimeksi)

Palvelinmalli (Data Base Server, DBS) on konsepti, jonka mukaan sovelluskomponentti (liiketoimintalogiikka) sijaitsee osittain tai kokonaan tietokantapalvelimella (kuva 4). Liiketoimintalogiikka toteutetaan tallennettujen ohjelmayksiköiden (PRE), triggerien ja mukautettujen tietotyyppien muodossa, jotka tallennetaan tietokantaan ja joita palvelin hallitsee. Tietokanta myös kerää tietoa ja muodostaa metatietokannan (MDB). Asiakassovellus osoittaa palvelimelle käynnistyskomennolla PrE ja palvelin tarvittaessa suorittaa sen ja tekee muutokset tietokantaan. Palvelin palauttaa pyynnön tuloksen asiakkaalle joko tulostettavaksi oheislaitteeseen tai suorittamaan osan asiakaskoneessa sijaitsevasta liiketoimintalogiikasta. Tällä tietojenkäsittelyn jakelumenetelmällä verkkoliikenne vähenee huomattavasti.

Trigger - mekanismi tietokannan tilaan liittyvien erityistapahtumien seurantaan. Tietokannan laukaisu on kuin jonkinlainen vaihtokytkin, joka toimii, kun tietokannassa tapahtuu tietty tapahtuma. DBMS-ydin tarkkailee kaikkia tapahtumia, jotka aiheuttavat luodut ja kuvatut triggerit tietokannassa, ja kun vastaava tapahtuma tapahtuu, palvelin käynnistää vastaavan triggerin => triggeri on ohjelma, joka toimii tietokannassa ja kutsuu tallennettuja proseduureja.

Tämä palvelinmalli on aktiivinen, koska ei vain asiakas, vaan palvelin itse käyttää laukaisumekanismia.
Edut:

DBS-malli tukee useimpia moderni DBMS: Oracle, Sybase, Ingres, Informix, MS SQL Server kuitenkin toiminnallisuutta heillä on erilaisia.

DBS-mallin edut:

Mahdollisuus soveltavien toimintojen keskitettyyn hallintaan;

· verkkoliikenteen vähentäminen mahdollisten etämenettelypuheluiden vuoksi;

· kyky erottaa menettelyt useiden sovellusten mukaan ja säästää tietokoneen resursseja käyttämällä kerran luotua SQL-kyselyn suoritussuunnitelmaa. (koska tallennetut proseduurit ja triggerit on tallennettu tietokantasanakirjaan ja niitä voivat käyttää useat asiakkaat => tietojenkäsittelyalgoritmien päällekkäisyys eri asiakassovelluksissa vähenee).

Virheet:

Palvelimen ominaisuudet:

1. Valvoo kuvattuihin laukaisimiin liittyviä tapahtumia;

2. Tarjoaa laukaisujen automaattisen laukaisun, kun asiaan liittyviä tapahtumia tapahtuu;

3. Varmistaa kunkin liipaisimen sisäisen ohjelman suorittamisen;

4. Suorittaa tallennettuja proseduureja käyttäjien pyynnöstä;

5. Käynnistää tallennetut proseduurit laukaisuista;

6. Palauttaa vaaditut tiedot asiakkaalle;

7. Tarjoaa kaikki DBMS:n toiminnot: pääsy tietoihin, tietokannan tietojen eheyden valvonta ja tuki, kulunvalvonta, kaikkien käyttäjien oikean toiminnan varmistaminen yhdestä tietokannasta.

Itse asiassa palvelin suorittaa suuren joukon toimintoja ja palvelee monia asiakkaita. Palvelimen purkamiseen on kehitetty monitasoisia malleja ja erityisesti kolmitasoinen malli.

Sovelluspalvelin

Sovelluspalvelin (Sovellus palvelin, KUTEN) - eräänlainen monitasoinen arkkitehtuuri "client-server", joka perustuu "asiakas - sovelluspalvelin" -malliin.

Tämä malli tuo ylimääräisen välikerroksen asiakkaan ja palvelimen välille. Tämä välikerros sisältää yhden tai useamman sovelluspalvelimen. Tästä syystä identtinen nimi - "sovelluspalvelinmalli" AS (sovelluspalvelin).

Tässä mallissa kaikki IS-komponentit on jaettu kolmen esiintyjän kesken.

Asiakas toteuttaa käyttöliittymän, tarjoaa sovelluksen esityslogiikan, käynnistää lokalisoidun asiakaskone asiakassovelluskoodi, joka suorittaa viestintätoiminnot pääsyn paikalliseen tai maailmanlaajuinen verkosto, valtuutusrajapinta, salausalgoritmit, syötearvojen oikeellisuuden ja muodon noudattamisen tarkistaminen, yksinkertaiset toiminnot (lajittelu, ryhmittely, arvojen laskeminen) tiedoilla, jotka on jo ladattu käyttöliittymän (yleensä graafiseen) komponenttiin, eli varsinaiseen sovellukseen loppukäyttäjä. Asiakas ja sovelluspalvelin kommunikoivat API:n kautta ja sovelluspalvelin ja tietokantapalvelin SQL-kyselykielen kautta.

Sovelluspalvelimen malli

Sovelluspalvelimet suorittavat yleisimmät liiketoimintasäännöt, tukevat toimialueympäristöä ja tarjoavat viestintää sovelluskomponenttien välillä. Sovelluspalvelimen sovellustoiminnot on suunniteltu erillisiksi palveluiksi tai palveluiksi (Palvelu). Palvelu tarjoaa joitain palveluita kaikille ohjelmille, jotka haluavat ja pystyvät käyttämään niitä. IS-arkkitehtuurissa voi olla useita sovelluspalvelimia, ja jokainen niistä tarjoaa tietyn joukon palveluita. Kaikkia niitä käyttäviä ohjelmia käsitellään AC (Application Client) -sovelluspalvelinasiakkaana. Sovelluspalvelimen sovellustoimintojen toteutustiedot ovat täysin piilossa sovellusasiakkaalta. AS tekee pyynnön tietylle palvelulle, ei AS:lle. Pyynnöt asetetaan jonoon AS-prosessille, joka välittää ne käsiteltäviksi tietylle palvelulle asetettujen prioriteettien mukaisesti.

Tämän mallin tietokantapalvelimet käsittelevät yksinomaan DBMS:n toimintoja.

Yksinkertaisimmassa kokoonpanossa sovelluspalvelin voidaan yhdistää fyysisesti tietokantapalvelimeen yhdellä tietokoneella, johon yksi tai useampi asiakas muodostaa yhteyden verkon kautta.

"Oikeassa" (turvallisuuden, luotettavuuden, skaalauksen näkökulmasta) kokoonpanossa tietokantapalvelin sijaitsee dedikoidulla tietokoneella (tai klusterilla), johon verkon kautta on kytketty yksi tai useampi sovelluspalvelin, johon puolestaan ​​asiakkaat muodostavat yhteyden verkon kautta.

AS-mallin edut:

Parempi suorituskyky purkamalla palvelin;

IS-toiminnan kustannusten vähentäminen;

Mahdollisuus monimutkaistaa liiketoimintalogiikkaa suorituskyvyn menettämättä;

IS:n siirrettävyyden ja skaalautuvuuden ominaisuuksien parantaminen käyttämällä vakiokieliä ohjelmointi, kuten C, C++, Borland Pascal, Small Talk, Java, suurimman osan liiketoimintalogiikasta toteuttamiseksi.

· asiakasohjelmisto ei vaadi hallintaa;

konfiguroitavuus - tasojen eristäminen toisistaan ​​mahdollistaa järjestelmän nopean ja helpon konfiguroinnin uudelleen vikatilanteissa tai kun määräaikaishuolto jollakin tasosta

korkea turvallisuus;

korkea luotettavuus;

alhaiset vaatimukset asiakkaiden ja sovelluspalvelimen välisen kanavan (verkon) nopeudelle;

alhaiset suorituskykyvaatimukset ja tekniset tiedot asiakkaita, mikä johtaa heidän arvon alenemiseen.

Virheet:

palvelinosan monimutkaisuus ja sen seurauksena hallinnon ja ylläpidon kustannukset kasvavat;

sovellusten luomisen monimutkaisuus;

vaikeampi ottaa käyttöön ja hallinnoida;

· korkeat vaatimukset sovelluspalvelimien ja tietokantapalvelimen suorituskykyyn ja siten korkeisiin kustannuksiin palvelinlaitteisto;

· korkeat vaatimukset tietokantapalvelimen ja sovelluspalvelimien välisen kanavan (verkon) nopeudelle.

Tällä hetkellä suosittu Web-järjestelmien arkkitehtuuri voidaan esittää kolmiportaisena versiona.

Tietojärjestelmään kuuluvat tietokoneet ja ohjelmat eivät yleensä ole tasa-arvoisia. Jotkut niistä ovat omia resursseja (tiedostojärjestelmä, prosessori, tulostin, tietokanta jne.), toisilla on mahdollisuus käyttää näitä resursseja. Resurssia hallitsevaa tietokonetta (tai ohjelmaa) kutsutaan tämän resurssin palvelimeksi (tiedostopalvelin, tietokantapalvelin, laskentapalvelin...). Minkä tahansa resurssin asiakas ja palvelin voivat sijaita sekä samassa tietokoneessa että päällä erilaisia ​​tietokoneita yhdistetty verkkoon.

Tietojenkäsittelyjärjestelmien monitasoisen esityksen puitteissa voidaan erottaa kolme funktioryhmää, jotka keskittyvät erilaisten osatehtävien ratkaisemiseen:

1. tietojen syöttö- ja näyttötoiminnot (tarjoavat vuorovaikutusta käyttäjän kanssa);
2. tietylle aihealueelle ominaiset sovellustoiminnot;
3. resurssienhallintatoiminnot ( tiedostojärjestelmä, tietokanta jne.)

Kuva 1. Verkkosovelluskomponentit

Näiden toimintojen toteutuksen tarjoavat pääasiassa ohjelmistotyökalut, jotka voidaan esittää toisiinsa liittyvinä komponentteina (), joissa:

• Näytä komponentti vastaa käyttöliittymästä;
• sovelluskomponentti toteuttaa algoritmin tietyn ongelman ratkaisemiseksi;
• ohjauskomponentti resurssi tarjoaa pääsyn tarvittaviin resursseihin.

Autonominen järjestelmä (tietokone, joka ei ole kytketty verkkoon) edustaa kaikkia näitä komponentteja sekä eri tasoilla (käyttöjärjestelmä, apuohjelmat ja apuohjelmat, sovellusohjelmistot) että sovellustasolla (ei tyypillistä nykyaikaiset ohjelmat). Samoin verkko - se edustaa kaikkia näitä komponentteja, mutta yleensä jaettuna solmujen välillä. Tehtävänä on tarjota verkottumista näiden komponenttien välillä.

Asiakas-palvelin-arkkitehtuuri määrittelee yleiset periaatteet vuorovaikutuksen järjestäminen verkostossa, missä niitä on palvelimia, joidenkin tiettyjen toimintojen (palvelujen) solmut-tarjoajat ja asiakkaita, näiden toimintojen kuluttajat.

Tällaisen arkkitehtuurin käytännön toteutuksia kutsutaan asiakas-palvelin teknologiat. Jokainen tekniikka määrittelee omat tai käyttää olemassa olevia sääntöjä asiakkaan ja palvelimen väliseen vuorovaikutukseen, joita kutsutaan vaihtoprotokolla (vuorovaikutusprotokolla).

Kaikissa nykyaikaisille verkkotekniikoille rakennetussa verkossa (jopa vertaisverkossa) on elementtejä asiakas-palvelin vuorovaikutus, useimmiten perustuu kaksikerroksinen arkkitehtuuri. Kaksitasoinen (kaksitasoinen, 2-tasoinen) sitä kutsutaan jakelutarpeen vuoksi kolme perus komponentit välillä kaksi solmua(asiakas ja palvelin).

Kuva 2. Kaksitasoinen asiakas-palvelin-arkkitehtuuri

Kaksitasoista arkkitehtuuria käytetään asiakas-palvelin-järjestelmissä, joissa palvelin vastaa asiakkaan pyyntöihin suoraan ja täysimääräisesti, mutta käyttää vain omia resurssejaan. Nuo. palvelin ei kutsu kolmannen osapuolen verkkosovelluksia eikä käytä kolmannen osapuolen resurssit suorittaa jonkin osan pyynnöstä ()

Komponenttien sijainti asiakas- tai palvelinpuolella määrittää seuraavat päämallit niiden vuorovaikutuksesta kaksitasoisessa arkkitehtuurissa:

• päätepalvelin— tietojen hajautettu esittäminen;
• tiedosto palvelin— pääsy etätietokantaan ja tiedostoresursseihin;
• tietokantapalvelin— tietojen etäesitys;
• sovelluspalvelin- etäsovellus.

Listatut mallit variaatioineen on esitetty.

Kuva 3. Asiakas-palvelin vuorovaikutuksen mallit

Historiallisesti hajautetun tiedon esitysmalli (päätepalvelinmalli) ilmestyi ensimmäisenä. Se toteutettiin yleistietokoneella (mainframe), joka toimi palvelimena, johon oli liitetty aakkosnumeerisia päätteitä. Käyttäjät syöttivät dataa päätteen näppäimistöltä, joka sitten siirrettiin keskuskoneeseen ja käsiteltiin siellä, mukaan lukien "kuvan" muodostaminen tuloksista. Tämä "kuva" palautettiin käyttäjälle päätteen näytöllä.

Henkilökohtaisten tietokoneiden ja paikallisten verkkojen myötä otettiin käyttöön tiedostopalvelinmalli, joka tarjosi pääsyn tiedostoresursseihin, mukaan lukien etätietokanta. Tässä tapauksessa omistettu isäntä on tiedostopalvelin, joka isännöi tietokantatiedostoja. Asiakkaat käyttävät sovelluksia, joissa yhdistyvät esityskomponentti ja sovelluskomponentti (DBMS ja sovellusohjelma), jotka käyttävät yhdistettyä etätietokantaa paikallisena tiedostona. Tässä tapauksessa vaihtoprotokollat ​​edustavat joukkoa matalan tason kutsuja tiedostojärjestelmän toimintoihin.

Tämä malli on osoittanut tehottomuutensa johtuen siitä, että kun työskentelet aktiivisesti tietokantataulukoiden kanssa, valtava paine verkkoon. Osittainen ratkaisu on tukea taulukoiden ja kyselyiden replikointia (replikointia). Tässä tapauksessa esimerkiksi kun tietoja muutetaan, koko taulukkoa ei päivitetä, vaan vain sen muokattu osa.

Erikoistuneen DBMS:n myötä tuli mahdolliseksi ottaa käyttöön toinen malli etätietokantaan pääsyä varten - tietokantapalvelinmalli. Tässä tapauksessa DBMS-moottori toimii palvelimella, sovellusohjelma asiakkaalla, ja vaihtoprotokolla tarjotaan SQL-kielellä. Tämä lähestymistapa verrattuna tiedostopalvelimeen johtaa verkon kuormituksen vähenemiseen ja asiakas-palvelin-rajapinnan yhtenäistämiseen. Verkkoliikenne on kuitenkin edelleen melko korkea, ja sovellusten tyydyttävä hallinta on edelleen mahdotonta, koska eri toiminnot yhdistetään yhteen ohjelmaan.

Kun kehitetään ja toteutetaan tallennettu menettely mekanismi tasolla tietokantapalvelimia, käsite aktiivinen tietokantapalvelin. Tässä tapauksessa jotkin sovelluskomponenttitoiminnot toteutetaan tallennettuina proseduureina, jotka suoritetaan palvelinpuolella. Loput sovelluslogiikasta suoritetaan asiakaspuolella. Vuorovaikutusprotokolla on SQL-kielen vastaava murre.

Tämän lähestymistavan edut ovat ilmeiset:

• sovellustoimintojen keskitetty hallinta on mahdollista;
• alentaa järjestelmän omistuskustannuksia (TOC, kokonaiskustannukset) vuokraamalla palvelin sen ostamisen sijaan;
• verkkoliikenteen merkittävä väheneminen (koska SQL-kyselyitä ei lähetetä, vaan kutsuja tallennettuihin proseduureihin).

Suurin haittapuoli on tallennettujen menettelyjen rajalliset kehitystyökalut korkean tason kieliin verrattuna.

Sovelluskomponentin toteutus palvelinpuolella edustaa seuraavaa mallia - sovelluspalvelin. Sovelluskomponenttien toiminnallisuuden siirtäminen palvelimelle vähentää asiakkaan kokoonpanovaatimuksia ja yksinkertaistaa hallintaa, mutta asettaa palvelimen suorituskyvylle, turvallisuudelle ja luotettavuudelle enemmän vaatimuksia.

Tällä hetkellä on taipumus palata siihen, mistä asiakas-palvelin-arkkitehtuuri sai alkunsa - pääte-palvelin-malliin perustuvan laskennan keskittämiseen. Nykyaikaisessa reinkarnaatiossa päätteet eroavat aakkosnumeerisista esivanhemmistaan ​​siinä, että niillä on vähintään ohjelmistoja ja laitteistoja, ne edustavat multimediaominaisuudet(sis. graafinen käyttöliittymä). Päätteiden toiminnasta huolehtii korkean suorituskyvyn palvelin, jonne sijoitetaan kaikki virtuaalisiin laiteajureihin asti, mukaan lukien videoalijärjestelmän ajurit.

Kuva 4. Kolmikerroksinen asiakas-palvelin-arkkitehtuuri

Toinen asiakas-palvelin-tekniikoiden trendi liittyy hajautetun tietojenkäsittelyn lisääntyvään käyttöön. Ne toteutetaan sovelluspalvelinmallin perusteella, jossa verkkosovellus on jaettu kahteen tai useampaan osaan, joista kukin voidaan suorittaa erillinen tietokone. Sovelluksen omistetut osat ovat vuorovaikutuksessa keskenään vaihtamalla viestejä ennalta sovitussa muodossa. Tässä tapauksessa kaksitasoinen asiakas-palvelin-arkkitehtuuri tulee kolmikerroksinen (kolmitasoinen, 3-tasoinen).

Sovelluspalvelimesta tulee pääsääntöisesti kolmas linkki kolmikerroksisessa arkkitehtuurissa, ts. komponentit jakautuvat seuraavasti ():

1. Datan esittäminen on asiakkaan puolella.
2. Sovelluskomponentti - erillisellä sovelluspalvelimella (lisävarusteena, joka suorittaa väliohjelmiston toimintoja).
3. Resurssienhallinta - tietokantapalvelimella, joka edustaa pyydettyä dataa.

Kuva 5. Monitasoinen (N-taso) asiakas-palvelin-arkkitehtuuri

Kolmikerroksinen arkkitehtuuri voidaan laajentaa monitasoinen (N-taso, monitasoinen) allokoimalla lisäpalvelimia, joista jokainen tarjoaa omia palvelujaan ja käyttää muiden palvelimien palveluita eri tasoilla. Abstrakti esimerkki usean linkin mallista on esitetty kohdassa .

Arkkitehtuurin vertailu

Kaksitasoinen arkkitehtuuri on yksinkertaisempi, koska kaikki pyynnöt palvelee yksi palvelin, mutta juuri tästä syystä se on vähemmän luotettava ja asettaa palvelimen suorituskyvylle enemmän vaatimuksia.

Kolmikerroksinen arkkitehtuuri on monimutkaisempi, mutta koska toiminnot on jaettu toisen ja kolmannen tason palvelimien välillä, tämä arkkitehtuuri edustaa:

1. Korkea joustavuus ja skaalautuvuus.
2. Korkea turvallisuus(koska tietoturva voidaan määrittää jokaiselle palvelulle tai tasolle).
3. Korkea suorituskyky(koska tehtävät on jaettu palvelimien kesken).

Asiakas-palvelin teknologiat

Asiakas-palvelin-arkkitehtuuria käytetään suuret numerot verkkotekniikoita, joita käytetään pääsyyn erilaisiin verkkopalvelut. Tarkastellaanpa nopeasti joitakin tällaisia ​​palveluja (ja palvelimia).

Web-palvelimet Aluksi tarjosi pääsyn hypertekstiasiakirjoihin HTTP-protokolla(Huper Text Transfer Protocol). Nyt ne tukevat edistyneitä ominaisuuksia, erityisesti toimivat binääritiedostot(kuvat, multimedia jne.). Sovelluspalvelimet Suunniteltu sovellettavien ongelmien keskitettyyn ratkaisuun tietyllä aihealueella. Käyttäjillä on tähän oikeus juosta palvelinohjelmat teloitusta varten. Sovelluspalvelimien käyttö vähentää asiakkaan kokoonpanovaatimuksia ja yksinkertaistaa verkon yleistä hallintaa. Tietokantapalvelimet Tietokantapalvelimia käytetään käsittelemään käyttäjien pyyntöjä SQL-kieli. Tässä tapauksessa DBMS sijaitsee palvelimella, johon asiakassovellukset muodostavat yhteyden. Tiedostopalvelimet Tiedosto palvelin myymälöissä tietoja tiedostojen muodossa ja tarjoaa käyttäjille pääsyn niihin. Pääsääntöisesti tiedostopalvelin tarjoaa myös tietyn tason suojan luvatonta käyttöä vastaan. Välityspalvelin Ensinnäkin se toimii välittäjänä, joka auttaa käyttäjiä saamaan tietoa Internetistä ja turvaamaan verkon. Toiseksi se tallentaa usein pyydetyt tiedot välimuistiin paikallinen levy, toimittaa sen nopeasti käyttäjille ilman Internet-yhteyttä. Palomuurit(palomuurit) Palomuurit, analysoimalla ja suodattamalla kulkevaa verkkoliikennettä verkon turvallisuuden varmistamiseksi. Postipalvelimet Ne tarjoavat palveluita sähköpostiviestien lähettämiseen ja vastaanottamiseen. Remote Access Servers (RAS) Nämä järjestelmät tarjoavat yhteyden verkkoon puhelinverkkoyhteyksien kautta. etätyöntekijä voi käyttää yrityksen LAN-resursseja muodostamalla yhteyden siihen tavallisella modeemilla.

Nämä ovat vain muutamia erilaisia ​​asiakas-palvelintekniikoita, joita käytetään sekä paikallisissa että globaaleissa verkoissa.

Tiettyihin verkkopalveluihin pääsemiseksi käytetään asiakkaita, joiden ominaisuuksille on ominaista "paksuuden" käsite. Se määrittelee asiakkaan laitteiston ja ohjelmiston. Harkitse mahdollisia raja-arvoja:

"Ohut" asiakas Tämä termi määrittelee asiakkaan, jonka laskentaresurssit riittävät vain tarvittavan verkkosovelluksen suorittamiseen web-rajapinnan kautta. Tällaisen sovelluksen käyttöliittymä muodostetaan käyttämällä staattinen HTML (JavaScript-suoritusta ei tarjota), kaikki sovelluslogiikka suoritetaan palvelimella.
Jotta ohut asiakas toimisi, riittää, kun tarjotaan mahdollisuus käynnistää verkkoselain, jonka ikkunassa kaikki toiminnot suoritetaan. Tästä syystä web-selainta kutsutaan usein "yleisasiakkaaksi". "Paksu" asiakas Tämä on työasema tai henkilökohtainen tietokone, jossa on oma levyasema. käyttöjärjestelmä ja joilla on tarvittava setti ohjelmisto. TO verkkopalvelimia"lihavat" asiakkaat hakevat pääasiassa lisäpalvelut(esimerkiksi pääsy verkkopalvelimeen tai yrityksen tietokantaan).
"Paksu" asiakas tarkoittaa myös asiakasverkkosovellusta, joka toimii paikallisessa käyttöjärjestelmässä. Tällainen sovellus yhdistää tiedonesityskomponentin (käyttöjärjestelmän graafinen käyttöliittymä) ja sovelluskomponentin (asiakastietokoneen laskentateho).

SISÄÄN Viime aikoina toista termiä käytetään yhä enemmän: "rikas"-asiakas . "Rikas"-asiakas on eräänlainen kompromissi "paksun" ja "ohuen" asiakkaan välillä. Kuten "ohut" asiakas, "rikas" asiakas myös tarjoaa GUI jo kuvattu XML-työkalut ja sisältää joitain monipuolisia asiakastoimintoja (esim. vedä ja pudota -käyttöliittymä, välilehdet, useita ikkunoita, avattavat valikot jne.)

Myös "rikkaan" asiakkaan sovelluslogiikka on toteutettu palvelimella. Tiedot lähetetään osoitteeseen vakiomuoto Exchange, joka perustuu samaan XML:ään ( SOAP-protokollat, XML-RPC) ja asiakas tulkitsee ne.

Jotkut tärkeimmistä XML-pohjaisista rich-asiakasprotokollista on lueteltu alla:

• XAML (eXtensible Application Markup Language) - Microsoftin kehittämä, käytetään .NET-alustan sovelluksissa;
• XUL (XML User Interface Language) on standardin sisällä kehitetty standardi Mozilla projekti, käytetään esim sähköpostiohjelma Mozilla Thunderbird tai Mozilla Firefox -selain;
• Flex- multimediatekniikkaa päällä XML-pohjainen, jonka on kehittänyt Macromedia/Adobe.

Johtopäätös

Niin, Asiakas-palvelin-arkkitehtuurin pääideana on jakaa verkkosovellus useisiin komponentteihin, joista jokainen toteuttaa tietyn palvelujoukon. Tällaisen sovelluksen komponentit voivat toimia erilaisia ​​tietokoneita, joka suorittaa palvelin- ja/tai asiakastoimintoja. Tämä parantaa luotettavuutta, turvallisuutta ja suorituskykyä. verkkosovelluksia ja verkko yleensä.

Kontrollikysymykset

1. Mikä on tärkein idea K-S vuorovaikutuksia?
2. Mitä eroa on "asiakas-palvelin-arkkitehtuurin" ja "asiakas-palvelin-tekniikan" välillä?
3. Listaa K-S-vuorovaikutuksen komponentit.
4. Mitä tehtäviä näkymäkomponentti suorittaa CS-arkkitehtuurissa?
5. Mikä on tietokannan käyttömahdollisuuksien tarkoitus erillisenä komponenttina CS-arkkitehtuurissa?
6. Miksi bisneslogiikka erotetaan K-S-arkkitehtuurissa erillisenä komponenttina?
7. Listaa asiakas-palvelin-vuorovaikutuksen mallit.
8. Kuvaile tiedostopalvelimen mallia.
9. Kuvaa tietokantapalvelimen malli.
10. Kuvaile "sovelluspalvelin" -mallia
11. Kuvaile "päätepalvelimen" mallia
12. Luettele tärkeimmät palvelintyypit.

Tämän sivun pysyvä osoite:

Näiden ongelmien ratkaisemiseksi käytetään monitasoisia (kolme tai useampia tasoisia) asiakas-palvelin-arkkitehtuureja.

Tällaiset arkkitehtuurit allokoivat älykkäämmin tietojenkäsittelymoduuleja, jotka tässä tapaus suoritetaan yhdelle tai useammalle erilliset palvelimet. Nämä ohjelmistomoduulit toimii käyttöliittymien palvelimena ja tietokantapalvelimien asiakkaana. Lisäksi eri sovelluspalvelimet voivat olla vuorovaikutuksessa toistensa kanssa jakaakseen järjestelmän tarkemmin tiettyjä rooleja suorittaviin toiminnallisiin lohkoihin.

Voit esimerkiksi valita henkilöstöjohtamisen palvelimen, joka suorittaa kaikki henkilöstöjohtamiseen tarvittavat toiminnot. Yhdistämällä siihen erillisen tietokannan voit piilottaa kaikki tämän palvelimen toteutustiedot käyttäjiltä, ​​jolloin he voivat käyttää vain sen julkisia toimintoja. Lisäksi tällainen järjestelmä on erittäin helppo mukauttaa verkkoon, koska on helpompi kehittää html-lomakkeita käyttäjien pääsyä varten tiettyihin tietokantatoimintoihin kuin kaikkiin tietoihin.

Kolmiportaisessa arkkitehtuurissa asiakas ei ole ylikuormitettu tietojenkäsittelytoiminnoilla, vaan se suorittaa päärooliaan sovelluspalvelimelta tulevan tiedon esittämisjärjestelmänä. Tämä käyttöliittymä voidaan toteuttaa käyttämällä standardi tarkoittaa Verkkoteknologiat - selain, CGI ja Java. Tämä vähentää asiakkaan ja sovelluspalvelimen välillä siirrettävien tietojen määrää, mikä mahdollistaa yhteyden muodostamisen asiakastietokoneet jopa hitaiden linjojen, kuten puhelinkanavien, yli. Lisäksi asiakaspuoli voi olla niin yksinkertainen, että useimmissa tapauksissa se toteutetaan käyttämällä universaali selain. Mutta jos sinun on silti muutettava se, tämä toimenpide voidaan suorittaa nopeasti ja kivuttomasti. Kolmikerroksinen asiakas-palvelin-arkkitehtuuri mahdollistaa käyttäjien oikeuksien määrittämisen tarkemmin, koska he eivät saa käyttöoikeuksia itse tietokantaan, vaan tiettyihin sovelluspalvelimen toimintoihin. Tämä lisää järjestelmän turvallisuutta (verrattuna tavanomaiseen arkkitehtuuriin) ei vain tahallisesta hyökkäyksestä, vaan myös henkilöstön virheellisistä toimista.

Ajatellaan esimerkiksi järjestelmää, jonka eri osat toimivat usealla etäinen ystävä muilta palvelimilta. Oletetaan, että kehittäjältä on saatu uusi versio järjestelmästä, jonka asentamiseen kaksikerroksinen arkkitehtuuri kaikki järjestelmämoduulit on vaihdettava samanaikaisesti. Jos näin ei tehdä, vanhojen asiakkaiden vuorovaikutus uusien palvelimien kanssa voi johtaa arvaamattomiin seurauksiin, koska kehittäjät eivät yleensä luota tällaiseen järjestelmän käyttöön. Kolmikerroksisessa arkkitehtuurissa tilanne on yksinkertaistettu. Tosiasia on, että vaihtamalla sovelluspalvelinta ja tiedontallennuspalvelinta (tämä on helppo tehdä samanaikaisesti, koska molemmat ovat yleensä lähellä), muutamme joukon välittömästi saatavilla olevat palvelut. Siten palvelimen ja asiakkaan osien välisestä versioerosta johtuvan virheen todennäköisyys pienenee huomattavasti. Jos sisään uusi versio Jos palvelu on kadonnut, sitä vanhassa järjestelmässä palvelleet käyttöliittymäelementit eivät yksinkertaisesti toimi. Jos palvelun algoritmi on muuttunut, se toimii oikein myös vanhalla käyttöliittymällä.

Monitasoiset asiakaspalvelinjärjestelmät voidaan varsin helposti muuntaa Web-teknologiaksi - tähän riittää, että asiakasosa korvataan yleisellä tai erikoisselaimella ja täydennetään sovelluspalvelinta web-palvelimella jamilla. Näiden ohjelmien kehittämiseen voit käyttää molempia Yhteinen yhdyskäytävä Käyttöliittymä (CGI) tai enemmän moderni teknologia Java.

On myös huomattava, että kolmitasoisessa järjestelmässä sovelluspalvelimen ja tietokannan välisen viestintäkanavan kautta siirretään paljon tietoa. Tämä ei kuitenkaan hidasta laskelmia, koska yhteyden osalta määritellyt elementit voit käyttää nopeampia linjoja. Tämä vaatii vain vähän vaivaa, koska molemmat palvelimet sijaitsevat yleensä samassa huoneessa. Siten järjestelmän yleinen suorituskyky paranee - kaksi tehtävää työskentelee nyt yhden parissa erilaisia ​​palvelimia, ja niiden välinen viestintä voidaan suorittaa kaikkein nopeimmilla linjoilla pienin kustannuksin. On totta, että yhteisten laskelmien johdonmukaisuus on ongelma, joka on suunniteltu ratkaisemaan tapahtumanhallinnat - monitasoisten järjestelmien uusia elementtejä.

Asiakas-palvelintekniikkaa pidetään perustellusti yhtenä "pilareista", jolla moderni maailma Tietokoneverkot. Mutta tehtävät, joita varten se on suunniteltu, ovat vähitellen jäämässä menneisyyteen, ja näyttämölle nousee uusia tehtäviä ja teknologioita, jotka edellyttävät asiakas-palvelin-järjestelmien periaatteiden uudelleen miettimistä. Yksi tällainen tekniikka on World Wide Web.

Tekniikan käyttö hypertekstiasiakirjoja rakentamaan sisäistä tietoinfrastruktuuri Yritystä vauhditti erilaisten asiakas-palvelinjärjestelmien nopea kehitys. Jotkut ihmiset yrittävät verrata verkkoteknologiaa asiakas-palvelin-arkkitehtuuriin, mutta tämä on harhaanjohtavaa, koska itse asiassa verkko on tämän arkkitehtuurin evoluutio. Voidaan sanoa, että Web-järjestelmässä on asiakas-palvelin-arkkitehtuuri, eli yhden asiakkaan avulla voit muodostaa yhteyden useisiin palvelimiin. Web-selain, joka tarjoaa käyttäjäystävällinen käyttöliittymä Käyttäjän pääsy tietoihin on vain jäävuoren huippu huipputaso web-järjestelmät. Rajapinnan lisäksi kaikissa tietojärjestelmissä tulee olla tietojen käsittely- ja tallennustasot. Intranet-kehittäjät kohtaavat usein oikean kohdistuksen ongelman verkkotyötä järjestelmän muiden osien, kuten tietokantojen, kanssa. Yksi lupaavista tavoista ratkaista tämä ongelma on monitasoinen asiakas-palvelin-arkkitehtuuri. Ymmärtääksemme niiden edut, katsotaanpa tarkemmin tyypillistä asiakas-palvelinjärjestelmää.

Klassinen asiakas-palvelin-arkkitehtuuri

Termi "asiakas-palvelin" tarkoittaa sellaista ohjelmistokompleksin arkkitehtuuria, jossa sen toiminnalliset osat ovat vuorovaikutuksessa "pyyntö-vastaus"-järjestelmän mukaisesti. Jos tarkastellaan tämän kompleksin kahta vuorovaikutuksessa olevaa osaa, niin toinen niistä (asiakas) suorittaa aktiivisen toiminnon, eli aloittaa pyynnöt ja toinen (palvelin) vastaa niihin passiivisesti. Järjestelmän kehittyessä roolit voivat vaihtua esimerkiksi joitain ohjelmalohko toimii samanaikaisesti palvelimena suhteessa yhteen lohkoon ja asiakkaana suhteessa toiseen.

Huomaa, että kaikissa tietojärjestelmissä tulee olla vähintään kolme päätoiminnallista osaa - tiedon tallennus-, käsittely- ja käyttöliittymämoduulit. Jokainen näistä osista voidaan toteuttaa kahdesta muusta riippumatta. Esimerkiksi muuttamatta tietojen tallentamiseen ja käsittelyyn käytettyjä ohjelmia, voit muuttaa käyttöliittymää niin, että samat tiedot näytetään taulukoiden, kaavioiden tai histogrammien muodossa. Muuttamatta tietojen esitys- ja tallennusohjelmia, voit muuttaa käsittelyohjelmia esimerkiksi vaihtamalla algoritmia koko tekstihaku. Ja lopuksi, muuttamatta tietojen esitys- ja käsittelyohjelmia, voit vaihtaa tietojen tallennusohjelmiston vaihtamalla esimerkiksi toiseen tiedostojärjestelmään.

Klassisessa asiakas-palvelin-arkkitehtuurissa sinun on jaettava sovelluksen kolme pääosaa kahteen fyysiseen moduuliin. Tyypillisesti tiedontallennusohjelmisto sijaitsee palvelimella (esim. tietokantapalvelin), käyttöliittymä on asiakaspuolella, mutta tietojenkäsittely on hajautettava asiakas- ja palvelinosien kesken. Tämä on kaksitasoisen arkkitehtuurin suurin haitta, josta useat epämiellyttäviä piirteitä, jotka vaikeuttavat suuresti asiakas-palvelinjärjestelmien kehitystä.

Tietojenkäsittelyalgoritmeja jaettaessa on tarpeen synkronoida järjestelmän molempien osien käyttäytyminen. Kaikilla kehittäjillä on oltava täydelliset tiedot viimeaikaiset muutokset tehdä järjestelmään ja ymmärtää muutokset. Tämä aiheuttaa suuria vaikeuksia asiakas-palvelin-järjestelmien kehittämisessä, niiden asennuksessa ja ylläpidossa, koska toimintojen koordinointiin on panostettava huomattavasti. eri ryhmiä asiantuntijoita. Kehittäjien toiminnassa syntyy usein ristiriitoja, mikä hidastaa järjestelmän kehitystä ja pakottaa muuttamaan valmiita ja hyväksi havaittuja elementtejä.

Arkkitehtuurin eri elementtien välisten epäjohdonmukaisuuksien välttämiseksi yritetään suorittaa tietojenkäsittely jommallakummalla kahdesta fyysisestä osasta - joko asiakaspuolella ("paksu" asiakas) tai palvelimella ("ohut" asiakas tai "2.5"-niminen arkkitehtuuri -kerroksen asiakas-palvelin"). Jokaisella lähestymistavalla on haittapuolensa. Ensimmäisessä tapauksessa verkko on tarpeettomasti ylikuormitettu, koska sen yli siirretään raakadataa ja siten redundanttia dataa. Lisäksi järjestelmän ylläpito ja muuttaminen vaikeutuu, koska laskenta-algoritmin vaihtaminen tai virheen korjaaminen edellyttää kaikkien liitäntäohjelmien samanaikaista täydellistä vaihtoa, muuten saattaa ilmetä virheitä tai tietojen epäjohdonmukaisuuksia. Jos kaikki tiedonkäsittely suoritetaan palvelimella (kun sellainen on ylipäätään mahdollista), syntyy sisäänrakennettujen toimintojen kuvauksen ja niiden virheenkorjauksen ongelma. Tosiasia on, että sisäänrakennettujen menettelyjen kuvauksen kieli on yleensä deklaratiivinen, eikä siksi periaatteessa salli askelvirheenkorjaus. Lisäksi järjestelmää, jossa on tietojenkäsittely palvelimella, on täysin mahdotonta siirtää toiselle alustalle, mikä on vakava haitta.

Useimmat nykyaikaiset nopean sovelluskehityksen (RAD) työkalut, jotka toimivat erilaisia ​​perustuksia data, toteuttaa ensimmäisen strategian, eli "paksu" asiakas tarjoaa rajapinnan tietokantapalvelimelle sulautetun SQL:n kautta. Tällainen järjestelmän toteuttaminen "paksulla" asiakkaalla tarjoaa yllä lueteltujen haittojen lisäksi yleensä liian alhaisen turvallisuustason. Esimerkiksi pankkijärjestelmissä kaikille laskuttajille on annettava kirjoitusoikeus kirjanpitojärjestelmän päätaulukkoon. Lisäksi tätä järjestelmää on lähes mahdotonta siirtää Web-teknologiaan, koska tietokantapalvelimeen pääsyyn käytetään erikoistunutta asiakasohjelmistoa.

Joten yllä olevilla malleilla on seuraavat haitat.

1. "Lihava" asiakas:

hallinnon monimutkaisuus;

ohjelmistopäivityksestä tulee monimutkaisempi, koska sen vaihtaminen on suoritettava samanaikaisesti koko järjestelmässä;

valtuuksien jakamisesta tulee monimutkaisempi, koska pääsyä ei rajoita toimet, vaan taulukot;

verkko on ylikuormitettu, koska sen kautta siirretään raakadataa;

heikko tietosuoja, koska valtuuksia on vaikea jakaa oikein.

2. "Lihava" palvelin:

toteutuksesta tulee monimutkaisempi, koska kielet, kuten PL / SQL, eivät sovellu tällaisten ohjelmistojen kehittämiseen, eikä niitä ole hyvä raha virheenkorjaus;

PL/SQL:n kaltaisilla kielillä kirjoitettujen ohjelmien suorituskyky on huomattavasti alhaisempi kuin muilla kielillä luotujen, mikä on tärkeää monimutkaisille järjestelmille;

DBMS-kielillä kirjoitetut ohjelmat eivät yleensä toimi tarpeeksi luotettavasti; virhe niissä voi johtaa koko tietokantapalvelimen epäonnistumiseen;

tuloksena olevat ohjelmat eivät ole täysin siirrettävissä muihin järjestelmiin ja alustoihin.

Näiden ongelmien ratkaisemiseksi käytetään monitasoisia (kolme tai useampia tasoisia) asiakas-palvelin-arkkitehtuureja.

Kerrostetut asiakas-palvelin-arkkitehtuurit

Tällaiset arkkitehtuurit jakavat älykkäämmin tietojenkäsittelymoduuleja, jotka tässä tapauksessa toimivat yhdellä tai useammalla erillisellä palvelimella. Nämä ohjelmistomoduulit toimivat käyttöliittymien palvelimena ja tietokantapalvelimien asiakkaana. Lisäksi eri sovelluspalvelimet voivat olla vuorovaikutuksessa toistensa kanssa jakaakseen järjestelmän tarkemmin tiettyjä rooleja suorittaviin toiminnallisiin lohkoihin. Voit esimerkiksi valita henkilöstöjohtamisen palvelimen, joka suorittaa kaikki henkilöstöjohtamiseen tarvittavat toiminnot. Yhdistämällä siihen erillisen tietokannan voit piilottaa kaikki tämän palvelimen toteutustiedot käyttäjiltä, ​​jolloin he voivat käyttää vain sen julkisia toimintoja. Lisäksi tällainen järjestelmä on erittäin helppo mukauttaa verkkoon, koska on helpompi kehittää html-lomakkeita käyttäjien pääsyä varten tiettyihin tietokantatoimintoihin kuin kaikkiin tietoihin.

Kolmikerroksisessa arkkitehtuurissa "ohut" asiakas ei ole ylikuormitettu tietojenkäsittelytoiminnoilla, vaan se suorittaa päärooliaan sovelluspalvelimelta tulevan tiedon esittämisjärjestelmänä. Tällainen käyttöliittymä voidaan toteuttaa tavallisilla Web-teknologian työkaluilla - selaimella, CGI:llä ja Javalla. Tämä vähentää asiakkaan ja sovelluspalvelimen välillä siirrettävän tiedon määrää, jolloin asiakastietokoneet voivat muodostaa yhteyden jopa hitaiden linjojen, kuten puhelinlinjojen, yli. Lisäksi asiakaspuoli voi olla niin yksinkertainen, että useimmissa tapauksissa se toteutetaan yleisellä selaimella. Mutta jos sinun on silti muutettava se, tämä toimenpide voidaan suorittaa nopeasti ja kivuttomasti. Kolmikerroksinen asiakas-palvelin-arkkitehtuuri mahdollistaa käyttäjien oikeuksien määrittämisen tarkemmin, koska he eivät saa käyttöoikeuksia itse tietokantaan, vaan tiettyihin sovelluspalvelimen toimintoihin. Tämä lisää järjestelmän turvallisuutta (verrattuna tavanomaiseen arkkitehtuuriin) ei vain tahallisesta hyökkäyksestä, vaan myös henkilöstön virheellisistä toimista.

Ajatellaan esimerkiksi järjestelmää, jonka eri osat toimivat useilla etäpalvelimilla. Oletetaan, että kehittäjältä on saatu uusi versio järjestelmästä, ja sen asentamiseksi kaksitasoiseen arkkitehtuuriin on tarpeen vaihtaa samanaikaisesti kaikkia järjestelmämoduuleja. Jos näin ei tehdä, vanhojen asiakkaiden vuorovaikutus uusien palvelimien kanssa voi johtaa arvaamattomiin seurauksiin, koska kehittäjät eivät yleensä luota tällaiseen järjestelmän käyttöön. Kolmikerroksisessa arkkitehtuurissa tilanne on yksinkertaistettu. Tosiasia on, että vaihtamalla sovelluspalvelinta ja tiedontallennuspalvelinta (tämä on helppo tehdä samanaikaisesti, koska molemmat ovat yleensä lähellä), muutamme heti saatavilla olevien palveluiden joukkoa. Siten palvelimen ja asiakkaan osien välisestä versioerosta johtuvan virheen todennäköisyys pienenee huomattavasti. Jos palvelu on kadonnut uudesta versiosta, vanhassa järjestelmässä sitä palvelleet käyttöliittymäelementit eivät yksinkertaisesti toimi. Jos palvelun algoritmi on muuttunut, se toimii oikein myös vanhalla käyttöliittymällä.

Monitasoiset asiakaspalvelinjärjestelmät voidaan varsin helposti muuntaa Web-teknologiaksi - tähän riittää, että asiakasosa korvataan yleisellä tai erikoisselaimella ja täydennetään sovelluspalvelinta web-palvelimella jamilla. Voit käyttää joko Common Gateway Interfacea (CGI) tai uudempaa Java-tekniikkaa näiden ohjelmien kehittämiseen.

On myös huomattava, että kolmitasoisessa järjestelmässä sovelluspalvelimen ja tietokannan välisen viestintäkanavan kautta siirretään paljon tietoa. Tämä ei kuitenkaan hidasta laskelmia, koska näiden elementtien yhdistämiseen voidaan käyttää nopeampia linjoja. Tämä vaatii vain vähän vaivaa, koska molemmat palvelimet sijaitsevat yleensä samassa huoneessa. Siten järjestelmän kokonaissuorituskyky paranee - kaksi eri palvelinta työskentelee nyt yhden tehtävän parissa, ja niiden välinen viestintä voidaan suorittaa nopeimpien linjojen kautta. minimaaliset kustannukset varoja. On totta, että yhteisten laskelmien johdonmukaisuus on ongelma, joka on suunniteltu ratkaisemaan tapahtumanhallinnat - monitasoisten järjestelmien uusia elementtejä.

Tapahtumapäälliköt

Monitasoisissa arkkitehtuureissa käytetään transaktioiden hallintaohjelmia (MT), joiden avulla yksi sovelluspalvelin voi vaihtaa tietoja samanaikaisesti useiden tietokantapalvelimien kanssa. Siitä huolimatta Oracle-palvelimet on mekanismi hajautettujen tapahtumien suorittamiseen, mutta jos käyttäjä tallentaa osan tiedoista Oracle-tietokantaan, osan Informix-tietokantaan ja osan tekstitiedostoihin, tapahtumanhallinta on välttämätön. MT:tä käytetään hajautettujen heterogeenisten toimintojen hallintaan ja toimien koordinointiin erilaisia ​​komponentteja tietojärjestelmä. On huomattava, että lähes kaikki monimutkaiset ohjelmistot edellyttävät tapahtumanhallintaohjelman käyttöä. Esimerkiksi pankkijärjestelmien on suoritettava erilaisia ​​dokumenttiesitysten muunnoksia, eli työskenneltävä samanaikaisesti sekä tietokantoihin että tavallisiin tiedostoihin tallennettujen tietojen kanssa - nämä ovat toimintoja, joita MT auttaa suorittamaan.

Tapahtumanhallinta on ohjelma tai ohjelmasarja, jonka avulla voidaan koordinoida tietojärjestelmän eri osien työtä. Loogisesti MT on jaettu useisiin osiin:

Communication Manager (Communication Manager) ohjaa viestien vaihtoa tietojärjestelmän komponenttien välillä;

käyttöoikeuksien hallinta (Authorization Manager) tarjoaa käyttäjien todennuksen ja heidän käyttöoikeuksiensa varmistuksen;

tapahtumanhallinta (Transaction Manager) hallitsee hajautettuja toimintoja;

lokinhallinta (Log Manager) valvoo hajautettujen toimintojen palautusta ja palautusta;

Lock Manager varmistaa oikean pääsyn jaettuun tietoon.

Tyypillisesti viestintähallinta yhdistetään valtuutushallintaan, ja tapahtumanhallinta toimii yhdessä lukon ja järjestelmän tietueita. Lisäksi tällainen johtaja sisältyy harvoin toimituspakettiin, koska sen toiminnot (kirjanpito, resurssien allokointi ja toimintojen ohjaus) suorittaa pääsääntöisesti tietokanta itse (esimerkiksi Oracle).

Ensimmäiset tapahtumapäälliköt ilmestyivät 70-luvun alussa. (esimerkiksi CICS); Siitä lähtien ne ovat muuttuneet hieman ideologisesti, mutta melko merkittävästi - teknisesti. Suurimmat ideologiset muutokset ovat tapahtuneet viestintäpäällikössä, kun tälle alueelle on ilmestynyt uusia oliotekniikoita (CORBA, DCOM jne.). Tulevaisuudessa viestintämedian nopean kehityksen vuoksi meidän pitäisi odottaa yleiseen käyttöön erilaisia ​​tapahtumien johtajia.

Siten monitasoinen asiakas-palvelin-arkkitehtuuri voi yksinkertaistaa merkittävästi hajautettua tietojenkäsittelyä, mikä tekee siitä paitsi luotettavamman, myös helpommin saavutettavissa olevan. Javan kaltaisten työkalujen tulo helpottaa sovelluspalvelimen kommunikointia asiakkaiden kanssa, ja oliopohjaiset tapahtumanhallintaohjelmat varmistavat, että sovelluspalvelin toimii sopusoinnussa tietokantojen kanssa. Tämän seurauksena luodaan kaikki edellytykset monimutkaisten hajautettujen tietojärjestelmien luomiselle, jotka hyödyntävät tehokkaasti kaikkia modernin teknologian etuja.

Artikkelin materiaalin toimitti ASoft; puh. 261-5724. Valeri Koržoviin voi ottaa yhteyttä osoitteessa .

]. Näin voit erottaa tietojen tallennus-, käsittely- ja esittämistoiminnot enemmän tehokas käyttö palvelimien ja asiakkaiden ominaisuudet.

Monitasoisesta asiakas-palvelin-arkkitehtuurista yleisin on kolmikerroksinen arkkitehtuuri ( kolmikerroksinen arkkitehtuuri, kolmikerroksinen), jossa oletetaan, että seuraavat sovelluskomponentit ovat läsnä: asiakassovellus (yleensä sanotaan "ohut asiakas" tai pääte), joka on yhdistetty sovelluspalvelin, joka puolestaan ​​on yhteydessä tietokantapalvelin [ , ].

riisi. 5.4.

Riisi. 5.4. Kerrostetun asiakas-palvelin-arkkitehtuurin esitys

• Pääte on käyttöliittymä (yleensä graafinen) komponentti, joka edustaa ensimmäistä tasoa, varsinaista sovellusta loppukäyttäjälle. Ensimmäisellä tasolla ei saa olla suoria yhteyksiä tietokantaan (turvallisuusvaatimusten vuoksi), se on ladattu pääliiketoimintalogiikalla (skaalautuvuusvaatimusten vuoksi) ja tallentaa sovelluksen tilaa (luotettavuusvaatimusten vuoksi). Yksinkertaisin liiketoimintalogiikka voidaan ja yleensä viedään ensimmäiselle tasolle: valtuutusrajapinta, salausalgoritmit, syöttöarvojen oikeellisuuden ja muodon noudattamisen tarkistaminen, yksinkertaiset toiminnot (lajittelu, ryhmittely, laskenta) päätelaitteelle jo ladatuilla tiedoilla .
• Sovelluspalvelin sijaitsee toisessa kerroksessa. Toiselle tasolle suurin osa liiketoimintalogiikasta on keskittynyt. Sen ulkopuolelle jää terminaaleihin vietyjä fragmentteja sekä tallennettuja toimenpiteitä ja kolmanteen tasoon upotettuja laukaisuja.
• Tietokantapalvelin tarjoaa tietojen tallennustilaa ja on sijoitettu kolmannelle tasolle. Tämä on yleensä tavallinen relaatio- tai oliopohjainen DBMS. Jos kolmas taso on tietokanta sekä tallennettuja proseduureja, triggereitä ja skeema, joka kuvaa sovellusta relaatiomalli, sitten toinen taso rakennetaan muodossa ohjelmiston käyttöliittymä A, joka yhdistää asiakaspavut tietokantasovelluslogiikkaan.

Yksinkertaisimmassa kokoonpanossa, fyysisesti sovelluspalvelin voidaan yhdistää tietokantapalvelin yhdellä tietokoneella, johon yksi tai useampi pääte on kytketty verkon kautta.

"Oikeassa" (turvallisuuden, luotettavuuden, skaalauksen) kokoonpanossa tietokantapalvelin sijaitsee erillisessä tietokoneessa (tai klusterissa), johon yksi tai useampi sovelluspalvelimia, johon puolestaan ​​päätelaitteet on kytketty verkon kautta.

Tämän arkkitehtuurin edut ovat [ , , , ]:

• asiakasohjelmisto ei vaadi hallintaa;
• skaalautuvuus;
• konfiguroitavuus - tasojen eristäminen toisistaan ​​mahdollistaa järjestelmän nopean ja helpon konfiguroinnin uudelleen vikojen sattuessa tai määräaikaishuoltojen aikana jollakin tasosta;
• korkea turvallisuus;
• korkea luotettavuus;
• alhaiset vaatimukset kanavan (verkon) nopeudelle päätteiden välillä ja sovelluspalvelin;
• alhaiset vaatimukset päätteiden suorituskyvylle ja teknisille ominaisuuksille, mikä johtaa niiden kustannusten laskuun.

• palvelinosan monimutkaisuus kasvaa ja sen seurauksena hallinnon ja ylläpidon kustannukset;
• sovellusten luomisen monimutkaisuus;
• vaikeampi ottaa käyttöön ja hallinnoida;
• korkeat suorituskykyvaatimukset sovelluspalvelimia Ja tietokantapalvelin ja siten palvelinlaitteiston korkeat kustannukset;
• välisen kanavan (verkon) nopeudelle korkeat vaatimukset tietokantapalvelin Ja sovelluspalvelimia.

1. Esitys;
2. esitys kerros;
3. logiikka taso;
4. Tietokerros;
5. Data.

Riisi. 5.5. Viisi kerrosta monitasoista arkkitehtuuria "asiakas-palvelin"

Näkymä sisältää kaiken suoraan käyttäjälle näytettävän tiedon: luodut html-sivut, tyylisivut, kuvat.

Esityskerros kattaa kaiken, mikä liittyy käyttäjän ja järjestelmän väliseen vuorovaikutukseen. Esityskerroksen päätoimintoihin kuuluu tietojen näyttäminen ja käyttäjän antamien komentojen tulkitseminen ja niiden muuntaminen tarkoituksenmukaisiksi toiminnoiksi logiikan ja datan kontekstissa.

Logiikkataso sisältää järjestelmän päätoiminnot, jotka on suunniteltu sen tavoitteen saavuttamiseksi. Näihin toimintoihin kuuluvat syötettyyn ja tallennettuun dataan perustuvat laskelmat, kaikkien tietoelementtien ja esityskerroksen käsittelykomentojen tarkistaminen sekä tiedon välittäminen tietokerrokseen.

Tietojen käyttökerros on osa funktioita, jotka tarjoavat vuorovaikutusta kolmannen osapuolen järjestelmät, jotka suorittavat tehtäviä sovelluksen hyödyksi.

Järjestelmätiedot tallennetaan yleensä tietokantaan.

5.1.6. Hajautettu järjestelmäarkkitehtuuri

Tämäntyyppinen järjestelmä on monimutkaisempi järjestelmän organisoinnin kannalta. olemus hajautettu järjestelmät on säilyttää paikallisia kopioita tärkeistä tiedoista.

Kaavamaisesti tällainen arkkitehtuuri voidaan esittää kuvan 1 mukaisesti. 5.6.

Riisi. 5.6.

Yli 95 % yrityksen johtamisessa käytetystä tiedosta voidaan sijoittaa yhteen henkilökohtainen tietokone, joka tarjoaa mahdollisuuden itsenäiseen työskentelyyn . Tämän tietokoneen luoma korjaus- ja lisäysvirta on pieni verrattuna sen käyttämään tietomäärään. Siksi, jos tallennat jatkuvasti käytettyä dataa itse tietokoneisiin ja järjestät niiden välisen korjausten ja lisäysten vaihdon tallennettuihin tietoihin, siirretty kokonaisliikenne laskee jyrkästi. Tämän avulla voit vähentää tietokoneiden välisten viestintäkanavien vaatimuksia ja käyttää asynkronista viestintää useammin, ja tämän ansiosta luoda luotettavasti toimivia hajautettuja tietojärjestelmiä, jotka käyttävät epävakaata viestintää, kuten Internetiä, matkaviestintää, kaupallisia verkkoja yksittäisten elementtien yhdistämiseen. satelliittikanavat. Ja liikenteen minimoiminen elementtien välillä tekee tällaisen yhteyden käyttökustannuksista varsin edullisia. Tällaisen järjestelmän käyttöönotto ei tietenkään ole alkeellista ja vaatii useiden ongelmien ratkaisemista, joista yksi on oikea-aikainen tietojen synkronointi.

Jokainen työasema on itsenäinen, sisältää vain ne tiedot, joiden kanssa sen tulee toimia, ja tiedon relevanssi koko järjestelmässä varmistetaan jatkuvalla viestien vaihdolla muiden työasemien kanssa. Viestintä työasemien välillä voidaan toteuttaa eri tavoilla, tietojen lähettämisestä kohteeseen sähköposti ennen tiedon siirtämistä verkkojen kautta.