HELIA 1 (19) Luento 10 Sovelluksen hajauttamisesta 2 Mitä kaikkea voi hajauttaa / keskittää? 2 Miksi hajauttaa / keskittää? 2 Hajautuksen edellytys: modulaarisuus 3 Hajautuksen mahdollisia toteutustapoja 4 Tietokannan hajautus / keskitys 5 Tapahtumaeheys 6 Commit & Rollback 7 Käsittelyn hajautus / keskitys 9 Päätepohjainen rakenne 9 Itsenäinen työasemasovellus 10 Tiedostopalvelinpohjainen rakenne 11 Tietokantapalvelinpohjainen rakenne 12 Selainpohjainen rakenne 14 Yhteistoiminnallinen rakenne 15 Middleware 16 Middleware luokittelu 17
HELIA 2 (19) Sovelluksen hajauttamisesta Mitä kaikkea voi hajauttaa / keskittää? 1. Laitteistoa 1 vai useampi (palvelin)kone? 2. Tietoja / Tietokantaa 1 vai useampi palvelin vaiko tietokanta työasemassa? replikointi vai tosiaikainen yhteys tietokantainstanssien välillä 3. Käsittelyä 1 vai useampi paikka ohjelmakomponenteille? Miksi hajauttaa / keskittää? Prosessointikapasiteetin tehokas hyväksikäyttö Tietoliikennekustannusten minimointi Ohjelmistojen tehokkaampi ylläpito Tietovarastojen yhteiskäyttö Tietojen luotettavuudesta (eheydestä) huolehtiminen Ä Tavoitteet aina suhteessa sovellusalueen toimintavaatimuksiin: Jos esim. tosiaikaisuus on tärkeää ko. sovellusalueelle, se sanelee hajautusvaihtoehtoja
HELIA 3 (19) Hajautuksen edellytys: modulaarisuus Sovellus on rakenteeltaan modulaarinen! Käyttöliittymälogiikka, sovelluslogiikka ja tietokantalogiikka (käyttöliittymäpalvelut, sovelluspalvelut ja tietokantapalvelut) perustuvat erillisiin komponentteihin Prosessit kommunikoivat toistensa kanssa määriteltyjen rajapintojen (palvelujen) kautta Käyttöliittymä Sovelluslogiikka Tietoliikenne Käyttöliittymä Tiedonhallinta Tiedonhallinta
HELIA 4 (19) Hajautuksen mahdollisia toteutustapoja Keskuskonepainotteisuus Työasemapainotteisuus Työasema Palvelin Käyttöliittymä Sovelluslogiikka Tiedonhallinta Sovelluslogiikka Tiedonhallinta Sovelluslogiikka Tiedonhallinta Tiedonhallinta Tiedonhallinta Käyttöliittymä Käyttöliittymä Sovelluslogiikka Käyttöliittymä Sovelluslogiikka Käyttöliittymä Sovelluslogiikka Tiedonhallinta Käyttöliittymä Sovelluslogiikka Tiedonhallinta 1 kjän sovellus Raportointijärjestelmät, toimistojärjestelmät Kevyet tapahtumankäsittelyjärjestelmät Raskaat tapahtumankäsittelyjärjestelmät
HELIA 5 (19) Tietokannan hajautus / keskitys Vaihtoehtoja Koko tietokanta sijaitsee työasemassa Osa tietokannasta sijaitsee työasemassa, osa palvelimella Koko tietokanta sijaitsee yhdellä palvelimella Osa tietokannasta sijaitsee toisella palvelimella Osa tietokannasta kopioidaan määräajoin toiselle palvelimelle (replikointi) Tietokannan hajautuksen ikuisuusongelma on transaktioeheyden säilyttäminen:
HELIA 6 (19) Tapahtumaeheys On oltava varmuus siitä, että tietokantaan kohdistuva päivitystoimenpide menee joko a) läpi kokonaisuudessaan tai b) peruuntuu kokonaisuudessaan niin että tietyllä ajanhetkellä tietokannan kuva todellisuudesta on yhtenäinen ja ristiriidaton Ä Jos vain osa päivitystoimenpiteestä menee läpi, olisi tietokannassa oleva tieto epätäydellistä ja epäluotettavaa, ts. tieto menettäisi arvonsa Tapahtumankäsittelyn voi katkaista esim. Palvelimen käyttöjärjestelmän kaatuminen, Työaseman käyttöjärjestelmän kaatuminen, Sovelluksen kaatuminen, Tiedonhallintajärjestelmän kaatuminen, Tietoliikenneyhteyden katkeaminen, Ohjelmavirhe Tietokantaan määriteltyjen eheys- ym. sääntöjen vastainen toimenpide Samaan ongelmatiikkaan viitataan myös termeillä Tapahtumakäsittely Transaktionkäsittely Transaktioeheys OLTP (On Line Transaction Processing)
HELIA 7 (19) Commit & Rollback Tapahtumaeheyden säilyttämiseksi tietokantaan tehtävät muutokset tallennetaan tietokantaan vasta erillisellä COMMIT -toimenpiteellä Vastaavasti tehdyt muutokset voidaan perua ROLLBACK toimenpiteellä Tehdyt muutokset eivät näy muille käyttäjille ennen kuin COMMIT -toimenpide on tehty. Päivityksen ajaksi muutetut rivit lukitaan muiden käyttäjien tekemiltä muutoksilta Lukitus tehdään, kun rivin tietoja on muutettu Lukitus vapautuu COMMIT / ROLLBACK toimenpiteillä
HELIA 8 (19) Jos päivitystoimenpide kohdistuu vain yhteen fyysiseen tietokantaan, pystyvät nykyiset tiedonhallintajärjestelmät huolehtimaan tapahtumaeheydestä Jos päivitystoimenpide kohdistuu useampaan fyysiseen tietokantaan, mikään nykyisistä tiedonhallintajärjestelmistä ei pysty 100 % turvaamaan tapahtumaeheyden säilymistä! Monet nykyisistä tiedonhallintajärjestelmätoimittajista ovat kehittäneet menetelmiä, joilla tapahtumaeheyden säilymistä pyritään parantamaan varautumalla etukäteen em. virhemahdollisuuksiin, mutta täydellistä ratkaisua ei ole Å Älä siis hajauta tietokantaa ellei sille ole erityisiä perusteita, tai elleivät päivitystoimenpiteet kohdistu kerrallaan vain yhden instanssien tietoihin On-line hajautuksen sijasta nykyään kaupallisen mielenkiinnon kohteena on replikointi, eli osa tietokannasta kopioidaan määräajoin toiselle palvelimille. Teknisenä tavoitteena on tällöin tyypillisesti tietoliikennekulujen optimointi
HELIA 9 (19) Käsittelyn hajautus / keskitys Päätepohjainen rakenne Pääte tai työasema varustettuna pääteemulointiohjelmalla Keskustietokoneessa koko sovellus (käyttöliittymä, sovelluslogiikka ja tietokanta Käyttöliittymän mahdollisuudet riippuvat käytettävästä päätetyypistä (merkkipohjainen / graafinen) Hyvää Sovellukset helppo ylläpitää Ei rajapintaongelmia Pääteyhteys riittää Huonoa Graafiset päätteet / pääte-emulointi eivät yleistyneet, joten ratkaisut ovat yleensä merkkipohjaisia ja näyttävät vanhanaikaisilta Pääteyhteys on päällä palvelimeen jatkuvasti, jolloin yhteydenpito saattaa käydä kalliiksi
HELIA 10 (19) Itsenäinen työasemasovellus Koko sovellus (data, sovelluslogiikka ja käyttöliittymä) on yhdessä työasemassa Tyypillisesti jopa samassa tiedostossa Käyttöliittymän mahdollisuudet riippuvat käytettävästä työasemasta Hyvää Kompakti kokonaisuus Ei rajapintaongelmia Ei tietoliikenneongelmia Huonoa Tiedot vain yhden henkilön käytettävissä
HELIA 11 (19) Tiedostopalvelinpohjainen rakenne Työasemilla on käytettävissä 1 tai useampi tiedostopalvelin Työasema käsittelee tiedostopalvelimen levyä kuten paikallista levyä Hyvää Yksinkertainen rakenne Huonoa Kehittymättömät suojauskäytännöt yhtäaikaista käyttöä ajatellen Ei tiedon eheyden valvontaa Vaatii lähiverkkoyhteydet
HELIA 12 (19) Tietokantapalvelinpohjainen rakenne Palvelinkoneessa tiedonhallintajärjestelmä (tyypillisesti relaatiopohjainen) Työasemassa toimiva sovellus kommunikoi tietokannan kanssa (tyypillisesti SQL-kieltä käyttäen) Sanomat välitetään tietokannalle ns. CLI-kutsurakenteen mukaisesti (Call Level Interface) Sovelluksen ja tiedonhallinnan välisen rajapinnan toteutus on joko Microsoftin ODBC (Open Database Connectivity) tai tietokantatoimittajan oma rajapinta Hyvää Riippumattomuus käytettävästä tiedonhallintajärjestelmästä (jos käytetään yleistä yhteyskäytäntöä ja sitoudutaan standardin mukaisiin SQL-lauseisiin) Mahdollisesti tietoriippumattomuus, eli tietokantapalvelin voidaan vaihtaa pelkällä uudelleenmäärittelyllä ts. ilman muutoksia varsinaiseen ohjelmakoodiin Huonoa Työasemiin installoitu sovellus rajapintaohjelmistoineen on työläs ylläpidettävä Vaatii lähiverkkoyhteydet ODBC on yhden yrityksen (Microsoftin) isännöimä, ei oikea standardi SQL-standardin mukaiset yhteyskäytännöt eivät ole saavuttaneet laajempaa kannatusta
HELIA 13 (19) Esimerkki tietokantapalvelin rakenteesta: VB-sovellus + Oracle-tietokanta Työasema Sovellus *.exe Palvelin ODBC driver manager DBMS specific driver DBMS specific network driver Tietoliikenneohjelmisto Tietoliikenneohjelmisto DBMS specific network driver DBMS Oracle DB Odbc.dll Sqora.dll ora7win.dll Sqltcp.dll
HELIA 14 (19) Selainpohjainen rakenne Selain vastaa käyttöliittymän esittämisestä Sovelluslogiikka palvelimella Usein tietokanta ja sovelluslogiikka eri palvelimilla Mahdollisesti sovelluspalvelin www-palvelin Käyttöliittymä selaimen ehdoilla Hyvää Tehokas keskitetty ohjelmiston ylläpito Graafinen käyttöliittymä Huonoa Ei vielä paljon kokemuksia tuotantokäyttöympäristöistä
HELIA 15 (19) Yhteistoiminnallinen rakenne Sovelluslogiikkaa sekä työasema- että palvelinpäässä Tyypillisesti eri sovelluskehitysvälineet työasemassa ja palvelimella Uusi suunnittelukohde: kommunikaatio sovellusosien välillä Å Middleware tuotteet Hyvää Skaalautuvuus (tapahtuma-, data- ja käyttäjämääriin nähden) Huonoa Toistaiseksi osaamista niukasti
HELIA 16 (19) Middleware Perinteinen ohjelmistojako 1. Varusohjelmat 2. Sovellusohjelmat Varusohjelmat vastaavat tietokonejärjestelmän toiminnasta (keskusyksikkö ja oheislaitteet) Sovellusohjelmat palvelevat ihmisen tietojenkäsittelytarpeita 1. Yleiskäyttöiset valmisohjelmat / toimisto-ohjelmat 2. Erityiskäyttöön räätälöidyt ohjelmistot Ä Tietoliikenne? Middleware ~ huonosti määritelty termi helpottaa varusohjelmiston ja sovellusohjelmiston rajaaluetta Tyypillinen tehtävä prosessien välinen kommunikointi Peittää sovelluksilta teknisiä mm. tietoverkkoihin ja tietoliikenteeseen liittyviä yksityiskohtia Vähentää sovellusohjelmointitarvetta Pakottaa suunnittelemaan ohjelmiston palvelupohjaisesti (oliopohjaisesti)
HELIA 17 (19) Middleware luokittelu Tietokantamiddleware Olio-brokerit (ORB) ODBC JDBC CORBA DCOM Middleware TP-monitorit (DTP) Sanomatekniikat (MOM) Etäkutsut (RPC)
HELIA 18 (19) Etäkutsut - Remote Procedure Call (RPC) Tekniikka, jossa sovellukset voivat kutsua funktioita tai aliohjelmia, jotka todellisuudessa sijaitsevat jossain muussa koneessa Sovelluksen ei tarvitse tietää, missä palvelu sijaitsee Sovelluksen linkityksessä koodiin sijoitetaan pieni ohjelmanpala (stub), jonka tehtävä on etsiä verkosta kyseinen palvelu ja aktivoida se kuten aliohjelmakutsu, eli sovellus jää odottamaan, kunnes palvelu on suoritettu Sanomajonot Message Oriented Middleware (MOM) Sovellukset siirtävät sanomia erityisen sanomajonon kautta Ratkaisusta riippuen jonoon voi kirjoittaa 1 tai useampia sovelluksia ja sieltä voi poimia yksi tai useampia palvelimia Ratkaisu takaa, että jonoon kirjoitettu sanoma tullaan jossakin vaiheessa käsittelemään Sovellus ei jää odottamaan vastausta Erityisesti asynkroniseen käsittelyyn ja eräajoihin mutta tarvittaessa myös ajantasakäsittelyyn
HELIA 19 (19) Oliobrokerit Object Request Broker (ORB) Oliopohjaisen sovelluksen hajautusmalli Hajautus piilotetaan sovellusohjelmoijalta CORBA (Common Object Request Broker Architecture) COM / DCOM (Distributed) Component Object Model CORBA ja Microsoftin OLE ActiveX (COM, DCOM) ovat perusratkaisuiltaan samantyyppisiä, mutta CORBA toimii heterogeenisissä ympäristöissä ja DCOM ainoastaan Windows ympäristössä Tapahtumamonitorit Transaction Processing Monitor Huolehtivat tapahtumien eheydestä hajautetussa ympäristössä, tavoitteena yhtä luotettava tapahtumankäsittely kuin keskuskoneympäristöissä Sovellukset kutsuvat palveluja TP-monitorin kautta, joka reitittää kutsut palvelimille Tärkeimpiä tuotteita BEA Systemsin TUXEDO, MS:n Transaction Server, IBM:n CICS Tietokanta -middleware Tietokantapalvelinpohjaisissa järjestelmissä Usein tietokantatoimittajakohtaisia ratkaisuja, esim. ODBC vaatii alleen tietokantatoimittajakohtaisen rajapinnan työasemaan Sovellukset kutsuvat tietokantapalveluja SQL:n tai ODBC:n kautta Perustason tekniikkana yleensä RPC-kutsut