Hajautettujen transaktioiden käsittelyjärjestelmät M. Kifer, A. Bernstein & P. M. Lewis: Database Systems. An Application-Oriented Approach. Complete Version. Pearson Addison Wesley, 2006; sivut 947 1004, luku 23 (architecture of transaction processing systems); sivut 793 795, luvun 19 (models of transactions) kohta 19.3.3 (declarative transaction demarcation). A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Sixth Edition. McGraw-Hill, 2010; sivut 1091 1096, luvun 26 (advanced transaction processing) kohta 26.1 (transactionprocessing monitors). A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Fifth Edition. McGraw-Hill, 2006; sivut 933 938, luvun 25 (advanced transaction processing) kohta 25.1 (transaction-processing monitors). 281
Yksi- ja kaksikerrosmallit, s. 283. Tallennetut proseduurit, s. 286. Kolmikerrosmalli, s. 289. Istunnot ja konteksti, s. 296. Jonotettu transaktionkäsittely, s. 305. Transaktiomonitori, s. 308. Transaktiomonitorin tarjoamat palvelut, s. 312. Etäproseduurikutsu, s. 315. Transaktionaalinen etäproseduurikutsu, s. 320. Transaktioiden käsittely Internetissä, s. 326. Www-sovelluspalvelimet: J2EE, s. 336. Java-pavun rakenne, s. 345. Papujen pysyvyydenhallinta, s. 350. Papujen transaktionhallinta, s. 356. 282
Yksi- ja kaksikerrosmallit Hajautettujen transaktioiden käsittelyjärjestelmä on kehittynyt perinteisestä keskitetystä monen käyttäjän järjestelmästä (centralized multiuser system), jossa voidaan erottaa seuraavat ohjelmisto- ja laitteistokomponentit: 1a. Keskuskoneessa omina prosesseinaan toimivat sovellusohjelmat, joiden kanssa käyttäjä kommunikoi koneeseen kiinteästi tai puhelinyhteyden välityksellä kytkettyjen tyhmien päätteiden välityksellä. 1b. Keskuskoneessa toimiva tietokannan hallintajärjestelmä, joka sisältää tietokantapalvelut (database servives), so. transaktioiden hallinnan (transaction management) ja keskuskoneen levyillä sijaitsevan tiedon saannin (data access) hallinnan. 283
Sovellusohjelma sisältää sekä esitys- ja sovelluspalvelut. Esityspalvelut (presentation services) huolehtivat tiedon näyttämisestä päätteen kuvaruudulla ja tiedon syöttämisestä sovellukseen. Sovelluspalvelut (application services) kommunikoivat tietokantapalvelimen kanssa. Kutakin sovellusprosessia palvelee jokin palvelinprosessi tai sen säie. Palvelin toimii kyselypalvelimena: sovellusprosessit lähettävät palvelimelle transaktion aloitus-, sitoutumis- ja peruutuspyyntöjä sekä SQL-operaatioita, ja palvelinprosessi palauttaa sovellusprosessille tiedon operaation onnistumisesta ja operaation tuloksen. Koska esitys-, sovellus- ja tietokantapalvelut sijaitsevat kaikki yhdessä ja samassa koneessa, tätä järjestelmämallia kutsutaan yksikerrosmalliksi (single-tiered model). 284
Kehityksen ensimmäisenä askeleena oli päätteiden korvaaminen asiakastyöasemilla, joissa sovellusohjelmat toimivat ja jotka kommunikoivat tietokantapalvelimen kanssa verkon välityksellä: 1. Eri asiakaskoneissa (client machine) toimivat sovellusohjelmat, jotka sisältävät esitys- ja sovelluspalvelut. 2. Tietokantapalvelinkoneessa (database server machine) toimiva tietokantapalvelin (kuten edellä). Tätä mallia kutsutaan kaksikerrosmalliksi (two-tiered model). Palvelin toimii kysely- eli transaktiopalvelimena sovelluksille kuten keskitetyssä tietokannassa, mutta erona on sovelluksen palvelupyyntöjen ja palvelimen niihin antamien vastausten välittyminen verkon yli. Palvelinkoneita on keskitetyn tietokannan tapauksessa yksi (mahdollisesti rinnakkaiskone) ja hajautetun tietokannan tapauksessa useita. 285
Tallennetut proseduurit Turvallisuussyistä sekä verkkoliikenteen vähentämiseksi sovellukset käynnistävät palvelupyyntöjään yksittäisten SQL-lauseiden sijasta useimmiten tallennettujen proseduurien kautta. Tallennettu proseduuri (stored procedure) on tietokantaan tallennettu SQL-aliohjelma, jonka voivat käynnistää siihen oikeutetut sovellukset. Esim. pankin tietokantapalvelin voi tarjota sovellusohjelmien käyttöön tallennetut proseduurit deposit() ja withdraw(), jotka suorittavat tilille panon ja tililtä oton. 286
Tallennettujen proseduurien käytöstä on merkittäviä etuja: Tallennetun proseduurin oletetaan olevan oikeellinen; oikeellisuutta ylläpidetään tietokantapalvelimessa. Kun asiakaskoneessa toimiva sovellus voi operoida tietokantaan ainoastaan tallennettujen proseduurien välityksellä, voidaan paremmin taata tietokantaan kohdistuvien transaktioiden oikeellisuus ja siis tietokannan eheyden säilyminen. Kun sovellukset operoivat tietokantaan ainoastaan tallennettujen proseduurien kautta, sovellusohjelman suunnittelijan ei edes tarvitse olla tietoinen tietokannan kaaviosta. Tietokannan kaavion myöhemmin muuttuessa on joitakin tallennettuja proseduureja todennäköisesti ohjelmoitava uudestaan, mutta sovellusohjelmiin ei välttämättä aiheudu mitään muutoksia. Tallennetun proseduurin sisältämät SQL-lauseet voidaan etukäteen kääntää ja valmistella suoritusta varten, jolloin niiden suoritus on tehokkaampaa kuin joka kerta uudestaan käännettävien ja tulkittavien SQL-lauseiden. 287
Palvelun tarjoaja voi helpommin antaa käyttäjälle oikeuksia suorittaa tiettyjä sovelluskohtaisia toimintoja. Esimerkiksi ainoastaan pankkivirkailija, eikä suinkaan asiakas, voi kirjoittaa varmennetun shekin. Käyttöoikeuksien valvonta SQL-lauseiden tasolla on vaikeampaa. Käyttäjän tililtäottotransaktio voi hyvinkin käyttää samoja SQLlauseita ja operoida samoihin tauluihin kuin varmennetun shekin tuottava transaktio. Ongelma ratkaistaan kieltämällä asiakkaalta suora pääsy tietokantaan ja sallimmalla asiakkaalle sen sijaan oikeus suorittaa tallennettu proseduuri withdraw() muttei tallennettua proseduuria issue-certified-check(). Yksittäisiä SQL-lauseita abstraktimman palvelun tarjoaminen vähentää verkon kautta välitettävän tiedon määrää. Sen sijaan, että kuljetettaisiin yksittäisten SQL-lauseiden tuottamia välituloksia palvelinkoneelta asiakaskoneelle, kaikki välitulokset voidaan käsitellä palvelimessa, niin että ainoastaan tallennetun proseduurin syöteparametrit välitetään asiakkaalta palvelimelle ja proseduurin tuottama lopullinen tulos palvelimelta asiakkaalle. 288
Kolmikerrosmalli Ajatusta korkeamman abstraktiotason palvelujen tarjoamisesta asiakaskoneelle voidaan viedä askelta pidemmälle. Transaktioiden käsittelyjärjestelmän kolmikerrosmallissa (threetiered model) sovellusmoduulin sisältämät esitys- ja sovelluspalvelut on sijoitettu eri koneisiin: 1. Asiakaskoneissa (client machine) toimivat esityspalvelut. 2. Sovelluspalvelinkoneessa (application server machine) toimiva sovelluspalvelin (application server), joka sisältää sovelluspalvelut. 3. Tietokantapalvelinkoneessa (database server machine) toimiva tietokantapalvelin (kuten edellä). Esityspalvelut vastaanottavat käyttäjän antamat syötteet, tekevät niille yksinkertaisia tyyppitarkistuksia ja lähettävät palvelupyynnön sovelluspalvelimelle. 289
Asiakaskoneiden erottamisesta sovelluspalvelinkoneista seuraa mm. seuraavia hyötyjä: (1) Asiakaskoneet voivat olla pienempiä (ja siten halvempia). Tämä on erityisen tärkeää sovelluksissa, joilla on satoja tai tuhansia samanaikaisia asiakkaita. (2) Järjestelmää on helpompi ylläpitää, koska yrityksen liiketoimintasääntöjen muutokset voidaan paikallistaa sovelluspalvelinkoneeseen eikä kaikkiin asiakaskoneisiin. (3) Järjestelmän turvallisuus paranee, koska yksittäinen käyttäjä ei voi päästä fyysisesti sovelluspalvelinkoneelle eikä niin muodoin voi helposti muuttaa sovellusohjelmia. 290
Sovelluspalvelin suorittaa pyydettyä palvelua vastaavan sovellusohjelman. Kuten ennenkin, tämä ohjelma toteuttaa yrityksen liiketoimintasäännöt, mihin kuuluu pyynnön toteuttamiseen oikeuttavien ehtojen tarkistus, asianomaisten tallennettujen proseduurien suorituspyyntöjen lähetys tietokantapalvelimeen, pyyntöjen vastausten käsittely ja vastausten palautus esityspalveluille. Sovellusohjelman näkökulmasta käyttäjän pyynnön palvelu on jono tehtäviä (task), joista sovellusohjelma muodostaa yhden transaktion sulkemalla tehtävät begin transaction- ja commit-kutsujen väliin. Tehtävä voi vaatia monimutkaisen ohjelman suorituksen, joka sisältää tietokantaan tallennettujen proseduurien kutsuja. Yleisemmin käyttökelpoinen tehtävä voidaan sijoittaa omaksi tallennetuksi proseduurikseen, jolloin se voidaan käynnistää useamman eri sovellusohjelman komponenttina. Menettely siis edistää ohjelmistokomponenttien uudelleenkäyttöä. 291
Asiakkaan pyynnön palvelu voi viedä sovelluspalvelimelta paljon aikaa. Eri asiakkaiden pyyntöjä voi olla useita odottamassa käsittelyä. Sovelluspalvelimen pitääkin pystyä käsittelemään pyyntöjä samanaikaisesti: kutakin palveltavaa käyttäjää varten on osoitettava erillinen sovelluspalvelimen prosessi tai sellaisen säie. Uuden prosessin tai säikeen käynnistämisen välttämiseksi sovelluspalvelimessa pidetään yllä vapaiden säikeiden allasta, josta osoitetaan tarvittaessa säie käyttäjää palvelemaan. Sovelluspalvelimesta voi olla olemassa useampia ilmentymiä, varsinkin kun asiakkaita on paljon. Sovelluspalvelimen jokainen ilmentymä voi toimia eri koneessa, joista kukin on kytketty tiettyyn osajoukkoon asiakaskoneita. Yksittäinen sovelluspalvelinkone ja sen palvelemat asiakaskoneet voivat olla maantieteellisesti lähellä toisiaan. 292
Joissakin kolmitasomallin toteutuksissa sovellusohjelmien käynnistämät tehtävät toteuttavat tallennetut proseduurit on sijoitettu tietokantapalvelimen sijasta erilliseen transaktiopalvelimeen: 1. Asiakaskoneissa toimivat esityspalvelut (kuten edellä). 2a. Sovelluspalvelinkoneissa toimivat sovelluspalvelimet, jotka lähettävät tallennettujen proseduurien suorituspyyntöjä transaktiopalvelimelle. 2b. Transaktiopalvelinkoneessa (transaction server machine) toimiva transaktiopalvelin (transaction server), joka suorittaa tallentamiaan proseduureja lähettämällä niiden sisältämiä SQL-lauseita suoritettavaksi tietokantapalvelimeen ja käsittelemällä SQL-lauseiden tuottamat tulokset. 3. Tietokantapalvelinkoneessa toimiva tietokantapalvelin (kuten edellä, muttei sisällä sovellusten tallennettuja proseduureja). Transaktiopalvelin sijaitsee yleensä lähellä tietokantapalvelinta, kun taas sovelluspalvelimet sijaitsevat lähellä asiakkaita. 293
Transaktiopalvelimestakin voi olla olemassa useampia ilmentymiä, jos on odotettavissa, että palvelin kuormittuu raskaasti. Transaktiopalvelimen ilmentymät muodostavat silloin palvelinluokan (server class). Työkuorman edelleen tasaamiseksi palvelinluokan ilmentymät voivat toimia eri koneissa, joista kukin on kytketty tietokantapalvelimeen. Yleisimmässä tapauksessa järjestelmässä on useita tietokantapalvelimia ja useita transaktiopalvelimia, missä kukin transaktiopalvelinkone on kytketty osaan tietokantapalvelinkoneita. Silloin yksittäinen transaktiopalvelin (palvelinluokan ilmentymä) tallentaa ja pystyy suorittamaan vain osan kaikista tallennetuista proseduureista. Sovelluspalvelimen on tiedettävä, missä transaktiopalvelimessa sijaitsee minkäkin tehtävän toteuttava proseduuri. 294
Transaktiopalvelimen erottaminen tietokantapalvelimesta on hyödyllistä seuraavissa tilanteissa: (1) Yrityksen eri yksiköt käyttävät eri proseduurijoukkoja operoidessaan yhteiseen tietokantaan. Näiden proseduurijoukkojen sijoittelu eri transaktiopalvelimille antaa yksikölle paremman mahdollisuuden valvoa omia proseduurejaan. Suuryrityksen kirjanpito- ja henkilöstöjärjestelmät operoivat samaan tietokantaan, mutta täysin eri proseduurein. (2) Yksittäisen proseduurin pitää operoida eri palvelinkoneilla sijaitseviin tietokantoihin. (3) Tietokantapalvelimen pitää käsitellä palvelupyyntöjä suurelta käyttäjäjoukolta, minkä vuoksi palvelimesta voi tulla järjestelmän suorituskyvyn pullonkaula. Tallennettujen proseduurien siirto pois tietokantapalvelimelta keventää työkuormaa. 295
Istunnot ja konteksti Kussakin edellä esitetyssä järjestelmämallissa esiintyy asiakkaiden ja palvelinten välisiä istuntoja (session). Kahden yksilön välillä on istuntoja, kun yksilöt kommunikoivat toistensa kanssa suorittaakseen jonkin tehtävän ja kumpikin ylläpitää tilainformaatiota eli kontekstia (context) roolistaan tehtävässä. Transaktionkäsittelyjärjestelmissä erityisen tärkeitä ovat yhteys- ja asiakaspalveluistunnot. Yhteysistuntoja (communication sessions) esiintyy kaksikerrosmallissa esitys- ja sovelluspalveluiden ja tietokantapalvelimen välillä ja kolmikerrosmallissa sekä esityspalveluiden ja sovelluspalvelimien välillä että sovelluspalvelimien ja tietokanta- tai transaktiopalvelimien välillä. Yhteysistunnon kukin osapuoli pitää yllä kontekstitietoa, kuten kumpaankin suuntaan lähetettyjen viestien järjestysnumeroita, osoitetietoa, salausavaimia ja yhteyden nykyistä suuntaa. Kontekstitietoa säilytetään kontekstilohkoksi (context block) kutsutussa tietorakenteessa. 296
Yhteysistunnon luominen ja lopettaminen edellyttävät viestien vaihtoa ja tilanvarauksia kontekstilohkoille. Tästä koituvan kustannuksen vähentämiseksi ei jokaista palvelupyyntöä varten luoda omaa istuntoa, vaan kerran luotu istunto pidetään pitkäkestoisena. Niinpä sovelluspalvelin ei luo uutta istuntoa joka kerta, kun on tarpeen saada palvelu tietokantapalvelimelta, vaan kerran näiden välille luotua istuntoa käytetään kaikkien sovelluspalvelimen lähettämien SQL-lauseiden suorituspyyntöjen palveluun siitä riippumatta, minkä asiakkaan palveluun SQL-lause liittyy. Kolmikerrosmallin eräs etu kaksikerrosmalliin on ylläpidettävien yhteysistuntojen pienempi lukumäärä. Tällä voi olla huomattava merkitys tuhansia asiakaskoneita ja useita tietokantapalvelimia käsittävässä järjestelmässä. 297
Olkoon järjestelmässä n 1 asiakaskonetta ja n 3 tietokantapalvelinta. Kaksikerrosmallin mukaisessa järjestelmässä on silloin pahimmassa tapauksessa käynnissä n 1 n 3 asiakkaiden ja tietokantapalvelinten välistä istuntoa. Kolmikerrosmallin mukaisessa järjestelmässä, jossa on n 2 sovelluspalvelinta, asiakkaan riittää perustaa vain yksi yhteys sovelluspalvelimeen. Pahimmassa tapauksessa istuntoja on yhteensä n 1 + n 2 n 3 kpl, mikä on huomattavasti pienempi kuin n 1 n 3, koska n 2 on paljon pienempi kuin n 1. 298
Asiakaspalveluistuntoa (client/server session) varten palvelimen on tarpeen pitää yllä kontekstitietoa jokaista palvelemaansa asiakasta kohti. Tietokantapalvelimen palveltavana voi olla esimerkiksi asiakas, joka käy läpi taulua SQL:n kohdistimen (cursor) välityksellä. Asiakas suorittaa sarjan SQL-lauseita (open, fetch). Palvelimen on ylläpidettävä kontekstia, josta ilmenee, minkä rivin palvelin on viimeksi palauttanut. Kaupan verkkopistettä hallitseva palvelin ylläpitää ostoskorikontekstia jokaiselle asiakkaalle. Käyttäjän vuorovaikutuksesta syntyvä pyyntösarja päivittää ostoskorin tilaa. Palvelin ei halua joka pyynnön kohdalla uudestaan todentaa asiakasta ja tarkistaa, mitä tämä on oikeutettu tekemään. Sen vuoksi todennusja käyttöoikeusinformaatio tallennetaan istunnon kontekstiin. 299
Asiakaspalveluistunnon kontekstia voidaan ylläpitää eri tavoin: Palvelin voi ylläpitää asiakaskontekstiaan paikallisesti palvelimen ilmentymässä. Joka kerta, kun asiakas lähettää palvelupyynnön, palvelin noutaa asiakkaan kontekstin ja tulkitsee pyynnön suhteessa kontekstiin. Menettely toimii, jos asiakas aina kutsuu samaa palvelimen ilmentymää. Pyydetyn palvelun voi kuitenkin tarjota palvelinluokan mielivaltainen ilmentymä, jolloin yhden ilmentymän tallentama konteksti ei ole muiden käytettävissä. Jos asiakkaita on hyvin monta ja istunnot pitkiä, samanaikaisesti ylläpidettävät paikalliset kontekstit voivat merkitä palvelimelle huomattavaa taakkaa. Palvelin voi säilyttää kunkin asiakkaan kontekstia tietokannassa. Menettelyllä vältetään palvelinluokkien ongelma, mikäli luokan kaikki ilmentymät voivat operoida samaan tietokantaan. 300
Kun kontekstitieto säilytetään palvelimella tai tietokannassa, palvelimen täytyy paikallistaa asiakkaan konteksti pyynnön saapuessa. Paikallistamisongelma ratkaistaan ylläpitämällä kontekstikahvaa (context handle), joka on osoitin paikkaan, johon palvelin on tallentanut asiakkaan kontekstin. Palvelin välittää kontekstikahvan asiakkaalle palvelupyynnön vastauksen yhteydessä, ja asiakas palauttaa kahvan palvelimelle seuraavan pyynnön yhteydessä. Kahvaa tulkitsee vain palvelin; asiakas ei saa muuttaa sitä mitenkään. Esimerkkinä kontekstikahvoista mainittakoon Internetin asiakaspalvelusovelluksissa käytetyt piparit (cookie). Pipari voi toisinaan sisältää kahvan lisäksi myös itse kontekstitietoa. 301
Asiakkaan konteksti voidaan säilyttää asiakkaalla ja kuljettaa tarvittaessa edestakaisin palvelimen ja asiakkaan välillä. Palvelin palauttaa luomansa kontekstin asiakkaalle pyynnön palveltuaan. Asiakas ei pyri tulkitsemaan kontekstia, vaan yksinkertaisesti tallentaa sen ja välittää sen takaisin palvelimelle uuden pyynnön yhteydessä. Menettelyllä palvelin vapautuu tallentamasta kontekstia pitkäkestoisesti. Samoin vältetään palvelinluokkien ongelma. Arkaluontoinen kontekstitieto pitää salata, jottei asiakas voi päästä siihen käsiksi. 302
Kontekstia täytyy pitää yllä myös transaktiokohtaisesti, ei ainoastaan yhden asiakkaan ja yhden palvelimen välisestä palvelupyyntösarjasta. Transaktio voi sisältää useita pyyntöjä eri palvelimelle ja siis käsittää useita istuntoja. Tarkastellaan tilannetta, jossa asiakas c on perustanut istunnot palvelimiin s 1 ja s 2. Sekä s 1 että s 2 on tyydyttänyt c:n pyyntöjä käyttämällä tietokantapalvelinta s 3. Asiakaspalveluistuntoja on siis neljä: c s 1, s 1 s 3, c s 2, s 2 s 3. Oletetaan, että s 3 on s 1 :ltä vastaanottamansa pyynnön palvelemiseksi varannut lukkoja transaktiolle T tietokannan tietoalkioihin ja kirjannut päivityksiä lokiin T :n nimiin. Kun s 3 sitten palvelee s 2 :lta vastaanottamaansa pyyntöä, jota varten se suorittaa tietokantaoperaatioita transaktion T nimissä, täytyy s 3 :n käyttää transaktiokontekstia sen havaitsemiseksi, että kysymyksessä on sama transaktio. 303
Kun käyttäjä kirjoittautuu asiakaskoneeseen, käynnistetyn asiakasprosessin ja sille osoitetun (monisäikeisen) sovelluspalvelinprosessin säikeen välille perustetaan asiakaspalveluistunto. Asiakaskonteksti voidaan tallentaa sovelluspalvelinprosessin säikeen yksityiseen pinoon. Sovelluspalvelinprosessin globaaleissa tietorakenteissa, jotka ovat yhteistä kaikille säikeille, voidaan säilyttää yhteiset resurssit, joita palvelin ylläpitää kaikkien asiakkaiden tarpeisiin. Esimerkkeinä sellaisista yhteisistä resursseista ovat sovelluspalvelimen ja tietokantapalvelimen (tai transaktiopalvelimen) väliset yhteysistunnot. 304
Jonotettu transaktionkäsittely Transaktionkäsittelyjärjestelmän kaksikerrosmallia voidaan pitää tietokeskeisenä (data-centered), kun taas kolmikerrosmallia voidaan pitää palvelukeskeisenä (service-centered). Kummassakin mallissa asiakas ja palvelin ottavat osaa välittömään transaktionkäsittelyyn (direct transaction processing): Asiakas käynnistää palvelupyynnön ja sitten odottaa tulosta. Palvelin käsittelee pyynnön mahdollisimman nopeasti ja palauttaa vastauksen. Asiakas ja palvelin toimivat siis tahdistetusti. Jonotetussa transaktionkäsittelyssä (queued transaction processing) asiakas laittaa pyynnön palvelua odottavien pyyntöjen jonoon ja suorittaa sitten muita tehtäviä. Pyyntö otetaan jonosta, kun sen vuoro tulee tai kun palvelin on valmis tarjoamaan palvelun. Pyynnön palveltuaan palvelin laittaa vastauksen erilliseen tulosjonoon, josta asiakas ottaa sen aikanaan. Asiakas ja palvelin toimivat siis tahdistamatta. 305
Elpyvien eli pysyvien jonoja (recoverable queue, persistent queue) käytettäessä jonotusoperaatiot ovat transaktionaalisia. Pyynnön käsittely voi koostua kolmesta transaktiosta: 1. Asiakas suorittaa transaktion T 1, joka käsittää palvelupyynnön viemisen pyyntöjonoon. 2. Palvelin suorittaa transaktion T 2, joka ottaa pyynnön jonosta, palvelee pyynnön ja vie tuloksen tulosjonoon. 3. Asiakas suorittaa transaktion T 3, joka ottaa tuloksen tulosjonosta. 306
Jonotettu transaktionkäsittely tarjoaa erinäisiä etuja. Asiakas voi syöttää palvelupyynnön silloinkin, kun palvelin on kiireinen tai poissa toiminnasta, ja palvelin voi vuorostaan palauttaa tuloksia vaikkei asiakas olisi valmis niitä vastaanottamaan. Jos palvelin romahtaa kesken pyynnön palvelun, palvelutransaktio (T 2 ) keskeytyy ja palauttaa peruutusvaiheessaan pyynnön pyyntöjonoon. Pyyntö palvellaan palvelimen elvyttyä, ilman että pyynnön tehneen asiakkaan tarvitsee tehdä mitään. Pyyntö- ja tulosjono voivat olla yhteisiä usealle palvelimelle (palvelinluokan ilmentymälle), jolloin palvelinten työkuormaa voidaan tasata sopivalla jononkäsittelyalgoritmilla. 307
Transaktiomonitori Transaktioiden käsittelyn valvoja (transaction-processing monitor, TP monitor) transaktiomonitori on ohjelmistomoduulikokoelma, joka täydentää käyttöjärjestelmän tarjoamia palveluita transaktioilla. Käyttöjärjestelmä luo abstraktion samanaikaisesti toimivista prosesseista, jotka kommunikoivat toistensa kanssa viestinvälitysmekanismia käyttäen, sekä tarjoaa prosesseille valvotun pääsyn tietokonejärjestelmän yhteisiin fyysisiin resursseihin. Transaktiomonitori laajentaa tätä abstraktiota transaktioilla, jotka ovat suorituksessa samanaikaisesti hajautetussa järjestelmässä. Järjestelmähierarkiassa transaktiomonitori sijoittuu sovellustason ja käyttöjärjestelmätason väliin: 1. Sovellustaso. 2. Transaktiomonitori. 3. Käyttöjärjestelmä. 4. Fyysinen tietokonejärjestelmä. 308
Tyypillisiä transaktiomonitorin tarjoamia palveluita ovat mm. erilaiset yhteyskäytännöt, hajautettujen sovellusten turvallisuuspalvelut (käyttäjän todentaminen ja viestien salakirjoitus) sekä hajautettujen transaktioiden atomisuus, eristyvyys ja pysyvyys (kaksivaiheinen sitoutumiskäytäntö). Nämä palvelut voidaan tarjota sovelluksesta riippumattomalla tavalla; palvelut ovat yleiskäyttöisiä ja niitä voidaan käyttää monissa hajautetuissa sovelluksissa. Tunnettuja transaktiomonitoreita ovat mm. Tuxedo, Encina, Microsoft Transaction Server (MTS) ja Java Transaction Service (JTS). Kaikki tarjoavat joukon sovelluksesta riippumattomia palveluita, joita tarvitaan transaktioiden käsittelyssä mutta joita ei kuulu tavanomaiseen käyttöjärjestelmään. 309
Varhaiset transaktionkäsittelyjärjestelmät olivat homogeenisia (homogeneous, TP-lite) järjestelmiä, joissa sekä laitteisto että ohjelmisto olivat samalta toimittajalta ja jotka käyttivät toimittajan omia ohjelmistorajapintoja. Monet nykyiset transaktionkäsittelyjärjestelmät ovat heterogeenisiä (heterogeneous, TP-heavy), niin että ne toimivat yhteen monien eri laite- ja ohjelmistotoimittajien tuotteiden kanssa: eri laitealustoilla, eri käyttöjärjestelmissä ja eri yhteyskäytännöillä. Uudet sovellukset edellyttävät usein yhteentoimivuutta vanhojen, eri toimittajien tuottamien ja aiemmin itsenäisesti toimineiden perinnejärjestelmien (legacy systems) kanssa. Esim. yrityksen eri osastot ovat aikojen kuluessa kehittäneet omat ostojärjestelmänsä, mutta nyt halutaan koko yrityksen kattava ostojärjestelmä, joka kytkee yhteen kaikki paikalliset järjestelmät. Laitteisto- ja ohjelmistokomponentteja on saatavilla yhä useammilta toimittajilta, ja käyttäjät vaativat mahdollisuutta sisällyttää järjestelmään parhaat saatavilla olevat komponentit. 310
Heterogeenisen järjestelmän toteuttaminen edellyttää, että laiteja ohjelmistotoimittajat sopivat (1) standardoiduista, patentoimattomista liittymistä eli avoimista liittymistä (open interfaces), jotka määrittelevät järjestelmäkomponenttien vuorovaikutuksessa välitettävän tiedon sisällön ja muodon, sekä (2) ohjelmistoista, jotka välittävät tätä tietoa. Kun järjestelmään sisällytetään epästandardia patentoitua liittymää käyttävä perinnejärjestelmä, liittymien väliseksi sillaksi voidaan kirjoittaa kääreohjelma (wrapper program). Avoimien hajautettujen järjestelmien kehittämisen edistämiseksi on kehitetty monia ohjelmistotuotteita, joita kutsutaan väliohjelmistoiksi (middleware). Monet transaktiomonitorin sisältämät ohjelmistomoduulit ovat väliohjelmistoja. Ohjelmointikielten tietokantaliittymien JDBC ja ODBC toteutukset ovat esimerkkejä väliohjelmistoista, jotka mahdollistavat sovelluksen vuorovaikutuksen eri toimittajien tietokantapalvelimien kanssa. 311
Transaktiomonitorin tarjoamat palvelut Transaktiomonitori tarjoaa yleensä seuraavat palvelut: (1) Yhteyskäytännöt, joilla sovellusohjelmamoduulit kommunikoivat toistensa kanssa. Yhteyskäytännöt näkyvät sovellukselle ohjelmointirajapintana, jonka funktiot on transaktiomonitorissa toteutettu käyttöjärjestelmään kuuluvalla alemman tason viestinvälitysmekanismilla. Useimmiten käytettyjä yhteyskäytäntöjä ovat etäproseduurikutsut, vertaiskommunikaatio ja tapahtumakommunikaatio. (2) Transaktioiden koordinointi hajautettujen transaktioiden globaalin atomisuuden takaamiseksi; perustuu yleensä kaksivaiheseen sitoutumiskäytäntöön. Homogeenisessa järjestelmässä koordinointi voi olla integroitu järjestelmätoimittajan resurssinhallitsimiin (tietokannan hallitsimiin), mutta heterogeenisessa järjestelmässä koordinoinnista vastaa yleensä erillinen, kaupan hyllyltä valmiina saatava moduuli, transaktionhallitsin, joka sisältää sovelluksen kutsujen tx begin(), tx commit() ja tx rollback() toteutuksen. 312
(3) Lokinhallitsin ja lukkojenhallitsin sellaisia resurssinhallitsimia (kuten tavallista tiedostojärjestelmää) varten, jotka eivät itsessään sisällä mekanismia niihin operoivien paikallisten transaktioiden atomisuuden tai eristyvyyden takaamiseksi. Lokinhallitsin sisältää kutsut, joilla esim. tavallista tiedostoa päivittävä hajautettu transaktio voi kirjata eksplisiittisesti pysyvät lokikirjaukset tiedostoon tekemistään päivityksistä. Lukonhallitsin sisältää kutsut, joilla transaktio voi manuaalisesti lukita lukemansa tai kirjoittamansa tiedoston tai sen osan. (4) Kuormantasaus ja reititys (load balancing and routing) palvelinluokkia käyttäviä suuria transaktioiden käsittelyjärjestelmiä varten. Luokan palvelimet voidaan hajauttaa verkkoon tiedon saatavuuden parantamiseksi ja käsittelyn rinnakkaisuusasteen lisäämiseksi. Kun asiakas käynnistää palvelinluokan tarjoaman palvelun, transaktiomonitori voi reitittää kutsun mille tahansa luokan palvelimelle. Jotkin transaktiomonitorit käyttävät kuormantasausta tämän valinnan kriteerinä. Työkuormaa voidaan tasata palvelimille kiertovuorotai satunnaisalgoritmilla ja pitämällä kirjaa kunkin palvelimen käsittelemien istuntojen lukumäärästä ja valitsemalla palvelin, jonka kuorma on pienin. 313
(5) Elpyvät jonot; käytetään jonotetun transaktionkäsittelyn lisäksi myös yleisemmin tapauksissa, joissa sovellusmoduulien välisen kommunikoinnin halutaan olevan tahdistamatonta. (6) Turvallisuuspalvelut, kuten salakirjoitus, käyttäjien todentaminen ja käyttöoikeudet. (7) Transaktiomonitorissa toteutettu säikeistys (threading) sellaisia käyttöjärjestelmiä varten, joissa prosessit eivät ole säikeistettyjä. (8) Erilaiset tukipalvelimet, kuten ajoituspalvelin (eri koneiden kellojen tahdistamiseksi) ja yleiskäyttöinen tiedostopalvelin. (9) Jotkin transaktiomonitorit mahdollistavat tavanomaisten litteiden transaktioiden (flat transaction) ohella monitasoiset sisäkkäiset transaktiot (nested transaction). 314
Etäproseduurikutsu Asiakaspalvelujärjestelmässä asiakkaat yleensä keskustelevat palvelinten kanssa etäproseduurikutsuilla (remote procedure call, RPC): asiakas käynnistää proseduurikutsun, joka oikeastaan suoritetaankin palvelimessa, joka sitten palauttaa kutsun tuloksen asiakkaalle. Etäproseduurikutsun käynnistävä asiakkaan ohjelmakoodi näyttää paikalliselta proseduurikutsulta:...; p(x);... Asiakkaan ohjelmaan linkitetty proseduuri p on ns. asiakastynkä (client stub), joka muuntaa kutsun argumentit x palvelimen odottamaan muotoon, kokoaa ne yhdessä kutsuttavan proseduurin nimen kanssa osaksi palvelimelle lähetettävää viestiä ja lähettää viestin käyttäen käyttöjärjestelmän viestinvälitysmekanismia: proc p(x) { parametrien x muuntaminen; palvelupyyntöviestin kokoaminen ja viestin lähetys; vastauksen odotus; vastauksen muuntaminen ja palautus; }. 315
Palvelimen ohjelmakoodiin linkitetty palvelintynkä (server stub) vastaanottaa asiakkailta saapuvia viestejä, eristää parametrit, käynnistää tavallisen paikallisen proseduurin ja palauttaa tuloksen asiakastyngälle. while (saapuvia viestejä riittää) { viestin vastaanottaminen; proseduurin nimen p ja argumenttien x eristäminen viestistä; p(x); kutsun tuloksen muunto vastausviestiksi ja viestin lähetys; }. Sekä asiakkaan että palvelimen puolella käyttöjärjestelmän viestinvälitysrutiinien kutsut on piilotettu tynkiin. Paikallisen palvelimen ja etäpalvelimen kutsuminen asiakkaasta näyttävät samalta: kummassakin tapauksessa se näyttää asiakkaan koodiin linkitetyn paikallisen proseduurin kutsulta. Asiakkaan koodin ei siis tarvitse olla tietoinen palvelimen fyysisestä sijainnista. Näin toteutuu sijainnin tuntumattomuus. 316
Asiakkaat tuntevat palvelimen tämän julkisen liittymän avulla, joka sisältää asiakkaan tarvitsemat tiedot palvelimen proseduurin käynnistämiseksi: proseduurin nimen ja parametrien kuvaukset. Liittymä kuvataan liittymänmäärittelykielellä (interface definition language, IDL). IDL-kääntäjä kääntää liittymäkuvauksen otsikkotiedostoksi ja palvelinkohtaisiksi asiakas- ja palvelintyngiksi. Otsikkotiedosto sisällytetään sovellusohjelmaan käännösvaiheessa, ja asiakastynkä linkitetään asiakaskoodiin. IDL-tiedoston käyttö palvelimen liittymän kuvaamiseen rohkaisee avoimien järjestelmien kehittämistä. Asiakas ja palvelin voivat olla eri ohjelmistotoimittajilta, kunhan nämä sopivat liittymästä. 317
Palvelimen liittymä ei kuitenkaan määritä sen palvelinprosessin identiteettiä tai sijaintia, joka todellisudessa suorittaa kutsuttavan proseduurin. Sijainti ei välttämättä ole tiedossa käännösaikana tai se voi muuttua dynaamisesti. Palvelin saattaa olla toteutettu palvelinluokkana, jonka ilmentymät toimivat verkon eri pisteissä. Järjestelmässä täytyy olla ajonaikainen mekanismi asiakkaan sitomiseksi palvelinprosessiin dynaamisesti. Dynaamisen sitomisen mahdollistamiseksi jokaisen palvelimen S, joka on valmis palvelemaan asiakkaita, on rekisteröidyttävä johonkin keskitettyyn nimipalvelimeen (name server) tai hakemistopalvelimeen (directory server), joka on kaikkien asiakkaiden saatavilla. Rekisteröityessään S toimittaa hakemistopalvelimelle globaalisti yksilöivän nimensä (kaikkien asiakkaiden käyttämä merkkijono), verkko-osoitteensa, tarjoamansa liittymät sekä asiakkaiden kanssa käytävässä viestien vaihdossa soveltamansa yhteyskäytännöt. 318
Asiakastynkä lähettää hakemistopalvelimelle palvelimen nimen tai tietyn liittymän tunnisteen ja pyytää verkko-osoitetta ja yhteyskäytäntöä käytettäväksi kommunikointiin sennimisen palvelimen tai sillä tunnisteella varustetun liittymän tarjoavan palvelimen kanssa. Kun tarvittavat tiedot on saatu, asiakastynkä voi kommunikoida suoraan palvelimen kanssa. Hakemistopalvelin sijaitsee kaikkien asiakkaiden tuntemassa verkko-osoitteessa, joka on määrättävissä käyttämättä mitään toista nimipalvelua. Hakemistopalvelimella on keskeinen rooli hajautetussa tiedonkäsittelyssä. Jos hakemistopalvelin romahtaa, asiakkaat eivät enää pysty paikantamaan palvelimia, joten uusia hajautettuja transaktioita ei voida käynnistää. Järjestelmän toimintavarmuuden lisäämiseksi hakemistopalvelu voi itsessään olla hajautettu ja/tai toisinnettu verkon ylin. Tämä taas synnyttää tuttuja ongelmia, kuten toisinteiden ajantasaisuuden varmistaminen. 319
Transaktionaalinen etäproseduurikutsu Usemmat transaktiomonitorit tarjoavat transaktionaalisen etäproseduurikutsuliittymän (transactional RPC interface) palveluihinsa. Liittymä sisältää kutsuja, joita voidaan käyttää määrittelemään etäproseduurikutsujen sarja yhdeksi transaktioksi. X/Open-standardin mukainen transaktionaalinen etäproseduurikutsuliittymä sisältää jo aiemmin esillä olleet kutsut: (1) tx begin(), tx commit() ja tx rollback(), joilla sovellus kutsuu transaktionhallitsinta, (2) xa reg(), jolla resurssinhallitsin ilmoittaa transaktionhallitsimelle liittyneensä transaktioon, sekä (3) xa prepare(), xa commit() ja xa abort(), joilla transaktionhallitsin käskyttää resurssinhallitsimia transaktion kaksivaiheisen sitoutumiskäytännön suorituksessa. 320
Transaktion aloittaminen: 1. Asiakasohjelma kutsuu tx begin(). 2. Asiakastynkä lähettää transaktionhallitsimelle uuden transaktion aloituspyynnön ja jää odottamaan vastausta. 3. Transaktionhallitsin tuottaa uuden transaktiotunnisteen T, säilyttää sen ja palauttaa sen asiakastyngälle. 4. Asiakastynkä vastaanottaa T :n, säilyttää sen ja palauttaa sovellukselle onnistuneen kutsun paluukoodin. 5. Asiakasohjelma jatkaa suoritustaan tx begin()-kutsua seuraavasta lauseesta. 321
Tietokantapalvelimen (tai yleisemmin resurssinhallitsimen) kutsuminen: 1. Asiakasohjelma pyytää SQL-lauseen suoritusta. 2. Asiakastynkä lähettää SQL-lauseen yhdessä transaktiotunnisteen T kanssa tietokantapalvelimelle S ja jää odottamaan vastausta. 3. Mikäli kysymyksessä on transaktion T ensimmäinen palvelupyyntö palvelimelle S, niin S kutsuu xa reg(t). Kutsu toteutuu S:n palvelintyngän sisältämän kommunikaatiomekanismin avulla. 4. Palvelin S palvelee SQL-lauseen suorituspyynnön suorittamalla erinäisiä paikallisia kutsuja ja palauttaa tuloksen asiakkaalle. 5. Asiakasohjelma jatkaa suoritustaan. 322
Transaktion sitoutuminen: 1. Asiakasohjelma kutsuu tx commit(). 2. Asiakastynkä lähettää transaktionhallitsimelle transaktion T sitoutumispyynnön ja jää odottamaan vastausta. 3. Transaktionhallitsin aloittaa T :n kaksivaiheisen sitoutumisen käskyttämällä kutsulla xa prepare() kaikkia T :hen osallisia resurssinhallitsimia S. 4. T :n kunkin osallisen S palvelintynkä vastaa transaktionhallitsimen lähettämään valmistautumisviestiin. 5. Transaktionhallitsin päättää sitouttaa T :n käskyttämällä T :n osallisia S kutsulla xa commit() tai päättää keskeyttää T :n käskyttämällä T :n osallisia S kutsulla xa abort(). 6. T :n kunkin osallisen S palvelintynkä vastaanottaa transaktionhallitsimen käskyn sitouttaa tai keskeyttää T, ja sen mukaisesti S joko sitouttaa tai keskeyttää T :n S:ssä toimivan alitransaktion. 323
Tynkien tehtäviin kuuluu käsitellä asiakkaiden ja palvelinten yhteyksissä esiintyvät häiriöt. Jos tynkä on odottanut vastausta viestiinsä yli määräajan, sen pitää mahdollisesti lähettää viesti uudestaan samalle palvelimelle tai jollekin toiselle saman palvelinluokan palvelimelle tai sitten keskeyttää asiakas. Vastausviestin saapumatta jäämiselle tai viivästymiselle voi olla eri syitä, kuten viestin menetys tai palvelimen romahtaminen, ja yhdessä tilanteessa sopiva korjaustoimenpide ei välttämättä ole sopiva toisessa. Jos tynkä lähettää palvelimelle S palvelun aloituspyynnön toistamiseen, palvelu saattaa tulla toteutetuksi kahdesti. Jos taas palvelupyyntöä ei toisteta, tynkä ei voi olettaa, ettei palvelua olisi suoritettu, sillä palvelupyyntö on voinut mennä perille ja tulla käsitellyksi, mutta vastausviesti on kadonnut. 324
Tyngän täytyy taata joko (1) pyydetyn palvelun suoritus täsmälleen kerran palvelimessa S, jolloin transaktio saa jatkaa suoritustaan, tai (2) että pyydettyä palvelua ei suoriteta lainkaan ja (jos palvelua ei voi tarjota muukaan palvelin) että transaktio keskeytetään. Vaadittua ominaisuutta kutsutaan täsmälleen kerran semantiikaksi (exactly-once semantics). Tilanne mutkistuu entisestään, jos palvelin S on pyydettyä palvelua suorittaessaan käynnistänyt toisen palvelimen S. Jos S:n piste romahtaa ja S toimii muualla verkossa, S jää orvoksi (orphan): S :n tehtävällä ei enää ole vanhempiprosessia, jolle raportoisi. Täsmälleen kerran semantiikan takaaminen tällaisissa tapauksissa ei ole triviaalia. 325
Transaktioiden käsittely Internetissä Moniin Internet-palveluihin liittyy hajautettuja transaktioita ja heterogeenisiä järjestelmiä. Palveluita tarjoavat www-palvelimet (web server), jotka pystyvät kommunikoimaan www:n yli. Usein wwwpalvelimelta vaaditaan kykyä käsitellä jopa tuhansia transaktioita sekunnissa. Järjestelmät voidaan karkeasti erotella kahteen luokkaan: (1) asiakkaan ja yrityksen välisiin ja (2) yritysten välisiin. Asiakkaan ja yrityksen väliset (customer-to-business, C2B) järjestelmät ovat tuttuja kaikille Internetin käyttäjille. Esimerkiksi Amazon.com-verkkokirjakaupan välityksellä kuka tahansa asiakas voi tilata ja maksaa kirjoja. Ostotransaktioon liittyy käyttäjän vuorovaikutusta, jossa haluttuja sivuja haetaan ja näytetään asiakaspisteen selaimella ja syötekenttiin kirjoitetaan tietoa ja toimintoja käynnistetään napsauttamalla linkkejä ja painikkeita. 326
Yritysten väliset (business-to-business, B2B) järjestelmät ovat monimutkaisempia, sillä ne ovat täysin automatisoituja. Yhden yrityksen www-pisteessä toimiva ohjelma kommunikoi toisen yrityksen www-pisteessä toimivan ohjelman kanssa ilman ihmisen vuorovaikutusta tai www-selainta. Järjestelmä voi sisältää monimutkaisia sopimuskäytäntöjä ja merkittäviä kaupallisia transaktioita. Internet-palvelujärjestelmä voidaan jaotella edustaan ja taustaan. Edusta (front end) käsittelee liittymää, jonka järjestelmä tarjoaa asiakkaille ja yrityksille, ts. kuinka järjestelmä kuvaillaan käyttäjille ja kuinka järjestelmä käynnistetään. Tausta (back end) sisältää sovelluksen varsinaisen toteutuksen, joka palvelun lopulta tarjoaa. Seuraavassa käsitellään lyhyesti asiakkaan ja yrityksen välisiä järjestelmiä, joissa edusta toteutetaan www-selaimen ja tausta hajautettujen transaktioiden käsittelyjärjestelmän avulla. 327
Www:n transaktionkäsittelyjärjestelmä hyödyntää usein kahta Javakielen konstruktiota: sovelmaa ja palvelinsovelmaa. Kun asiakkaan ja yrityksen välistä vuorovaikutusta toteuttava wwwpalvelin lähettää www-sivun asiakkaan selaimelle, se voi sisällyttää sivuun Java-kielisiä ohjelmia, sovelmia (applet), jotka suoritetaan suoritetaan selaimen ohjelmointiympäristössä. Selain näyttää vastaanottamansa www-sivun ja suorittaa siihen liittyvät sovelmat. Www-sivuun sisältyy käyttäjältä yleensä kätkettynä (1) sen www-palvelimen verkko-osoite (URL), johon käyttäjän antama tieto lähetetään, sekä (2) sen kyseisessä palvelimessa toimivan sovelluksen nimi, jolla käyttäjän antama tietoja on tarkoitus käsitellä. Sovelmat ovat siis asiakkaanpuolisia sovelluksia. 328
Palvelinsovelma (servlet) on palvelimella sijaitseva Java-ohjelma. Se käyttää standardia Java servlet -sovellusohjelmointirajapintaa, joka sisältää monia palvelimenpuolisten sovellusten totetuksessa tarvittavia toimintoja. Rajapinta sisältää esimerkiksi Java-metodeja HTML-sivujen sisältämän tiedon lukemista ja kirjoittamista varten. Palvelinsovelman elinaika ulottuu yksittäisen käyttäjän vuorovaikutuksia pitemmälle. Kun palvelinsovelma käynnistetään, se luo joukon säikeitä, joita osoitetaan dynaamisesti palvelemaan saapuvia palvelupyyntöjä. Palvelupyynnöt noudattavat yleensä HTTP-käytäntöä, ja niitä voi lähettää selain tai toinen sovellus. 329
Tarkastellaan kolmea mahdollista tapaa organisoida asiakkaan ja yrityksen välisiä paveluita Internetissä tarjoava transaktionkäsittelyjärjestelmä: kaksi-, kolmi- ja nelikerrosmallit. Kaksikerrosmallissa (two-tiered model) selain toimii sekä esitysettä sovelluspalvelimena, ja tietokantapalvelin sijaitsee www-palvelimen Internet-pisteessä: 1. Asiakaskoneessa toimiva www-selain, joka sovelmien avulla toteuttaa esitys- ja sovelluspalvelut. 2. Palvelinkoneessa toimivat www-palvelin ja tietokantapalvelin. Www-palvelimen palvelinsovelmasäie vastaa asiakkaan selaimen pyyntöön HTML-sivulla ja siihen sisältyvällä, liiketoimintasäännöt toteuttavalla sovelmalla. Käyttäjän täytettyä asianmukaiset sivun kentät sovelma suoritetaan selaajasta. 330
Sovelma saattaa aloittaa transaktion ja lähettää sitten SQL-lauseita tai tallennettujen proseduurien kutsuja suoritettaviksi tietokantapalvelimella. Sovelma kommunikoi tietokantapalvelimen kanssa JDBC-liittymän kautta. JDBC-ajuri saatetaan toimittaa sovelman kanssa www-palvelimelta, jolloin se luo verkkoyhteyden asiakaskoneesta tietokantapalvelimeen, tai sitten JDBC-ajuri sijaitsee www-palvelimella ja vastaanottaa komentoja selaajalta palvelinsovelmasäikeen kautta. 331
Kolmikerrosmallissa (three-tiered model) selain toimii esityspalvelimena ja www-palvelimen palvelinsovelmasäie toimii sovelluspalvelimena: 1. Asiakaskoneessa toimiva www-selain, joka toteuttaa esityspalvelut. 2. Www-palvelinkoneessa toimiva www-palvelin, joka toteuttaa sovelluspalvelut. 3. Tietokantapalvelinkoneessa toimiva tietokantapalvelin. Kun asiakas ottaa yhteyden www-palvelimeen, palvelinsovelmasäie lähettää HTML-sivun käyttäjän vuorovaikutusta varten. Käyttäjän täytettyä sivun kentät ja lähetettyä sivun palvelimelle vuorovaikutusta varten osoitetaan liiketoimintasäännöt toteuttava palvelinsovelmasäie. Nyt palvelinsovelmasäie, eikä sovelma, saattaa aloittaa transaktion tietokantapalvelimella. Saatuaan tehtävän suoritetuksi palvelinsovelma palauttaa HTML-sivun selaimelle. 332
Useimmat korkean suoritustehon sovellukset perustuvat nelikerrosmalliin (four-tiered model), jossa on kolme kerrosta palvelimen puolella (mahdollisesti eri verkkopisteissä) ja yksi kerros asiakkaan puolella: 1. Asiakaskoneessa toimiva www-selain, joka toteuttaa osan esityspalveluista. 2. Www-palvelinkoneessa toimiva www-palvelin, joka osoittaa asiakkaan palvelupyynnön sopivalle sovelluspalvelimelle ja toteuttaa osan esityspalveluista. 3. Sovelluspalvelinkoneessa toimiva sovelluspalvelin, joka toteuttaa sovelluspalvelut. 4. Tietokantapalvelinkoneessa toimiva tietokantapalvelin. 333
Asiakas on yhteydessä www-palvelimella toimivaan palvelinsovelmasäikeeseen, joka käsittelee selaajan palauttaman tiedon. Wwwpalvelin saattaa vastata käyttäjän pyyntöön toimittamalla selaimelle uuden HTML-sivun tai käynnistämällä sopivan ohjelman sovelluspalvelimella. Sovelluspalvelin toimii eri koneella, joka saattaa olla erotettu www-palvelinkoneesta palomuurilla muista lähteistä saapuvien ylimääräisten viestien torjumiseksi. Sovelluspalvelimella toimiva sovellusohjelma voi käynnistää tietokantapalvelimen tietoon operoivia transaktioita. Tietokantapalvelinkone voi olla erotettu sovelluspalvelinkoneesta eri palomuurilla. Sovellusohjelman saatua tehtävänsä suoritetuksi ja palautettua vastauksen www-palvelimen palvelinsovelmasäikeelle tämä valmistaa sopivan HTML-sivun ja palauttaa sen selaimelle. Sovelluspalvelimen näkökulmasta selain ja www-palvelin yhdessä toteuttavat esityspalvelut. 334
Nelikerrosmalli sopii erityisen hyvin korkeaa suoritustehoa vaativiin sovelluksiin, koska se sallii useampia sovelluspalvelimia. Wwwpalvelimessa saattaa olla kuormantasausmoduuli, joka kulloinkin valitsee tietyn sovelluspalvelimen käyttäjän istuntoa varten. Sovelluspalvelin saattaa operoida useisiin saman yrityksen tietokantapalvelimiin (esim. varasto-, toimitus- ja laskutustietokantoihin) sekä myös muiden yritysten tietokantapalvelimiin (esim. luottokorttimaksun käsittelyä varten). Erittäin korkean suoritustehon sovelluksia varten www-palvelimiakin saattaa olla useampia. Silloin tarvitaan ylimääräinen kerros HTTP-reitittimiä, jotka ovat suoraan yhteydessä Internettiin ja joiden tehtävänä on välittää HTTP-pyyntö sopivalle www-palvelimelle. Suoritustehon edelleen lisäämiseksi eri kerroksilla tarvittavaa tietoa voidaan säilyttää välimuisteissa (cache). Www-palvelin voi säilyttää välimuistissaan usein käytettyjä HTML-sivuja. 335
Www-sovelluspalvelimet: J2EE Www-sovelluspalvelin (Web-application server, application server) on ohjelmistotuote, jonka avulla voidaan rakentaa Internetissä toimivia transaktioiden käsittelyjärjestelmiä. Www-sovelluspalvelin tarjoaa samanlaisia toimintoja kuin transaktiomonitori ja sisältää erityisesti www-sovelluksiin suuntautuneita palveluita. Useimmat kaupalliset www-sovelluspalvelimet on rakennettu J2EE-teknologiaa (Java 2 Enterprise Edition) käyttäen; Microsoftin www-sovelluspalvelin perustuu.net-teknologiaan. J2EE sisältää pavuiksi (bean) kutsuttuja Java-luokkia, joita voidaan sovittaa sovellukseen yrityksen liiketoimintasäännöt toteuttaviksi metodeiksi. J2EE:llä voidaan luoda Java-palvelinsovelmia sekä erilaisia www-sovelluksiin suunniteltuja transaktioiden hallintaan liittyviä palveluita. 336
Yrityspavut (enterprise bean) ovat Java-luokkia, joita voidaan käyttää kapseloimaan yrityksen liiketoimintasäännöt. Yrityspapu käynnistyy yleensä palvelinsovelmasta. Yrityspapuja on kolmentyyppisiä: yksilöpapuja, istuntopapuja ja viestin ohjaamia papuja. Yksilöpapu (entity bean) esittää pysyvää liiketoimintaoliota, jonka tila tallennetaan tietokantaan. Tyypillisesti kukin yksilöpapu vastaa tietokantataulua ja pavun kukin ilmentymä vastaa taulun riviä. Esimerkiksi pankkisovelluksessa voisi olla account-niminen yksilöpapu, jossa on kentät account-id, owner-name, social-securitynumber ja balance sekä metodit deposit ja withdraw. account-papu voisi vastata samannimistä tietokantarelaatiota, jossa on samannimiset attribuutit. Jokainen account-pavun ilmentymä vastaa yhtä account-taulun riviä. Jokaisella yksilöpavulla pitää olla yksilöivä avain (pääavain). account-pavulle sellainen on account-id. 337
Yksilöpapuja voidaan käyttää sovellusohjelmassa kuten mitä tahansa muuta olioluokkaa. Erona on, että kaikki yksilöpapuun ohjelmassa tehdyt päivitykset ovat pysyviä, so. ne levitetään vastaavaan tietokannan tietoalkioon. Niinpä esimerkiksi kaikki balance-kentän arvon muutokset account-pavun johonkin ilmentymään näkyvät vastaavan attribuutin päivityksinä vastaavassa relaation monikossa. Pysyvyyttä voi hallita papu itse sovellusohjelmoijan kirjoittaman SQL-koodin avulla tai järjestelmä automaattisesti. Jokainen yksilöpapu on suoritettava osana transaktiota. Koska yksilöpavun tilaa säilytetään tietokannassa, yksilöpapu säilyy elossa sen yksittäistä suorituspyyntöä pidempään ja selviytyy hengissä järjestelmän romahduksestakin. 338
Istuntopapu (session bean) luodaan, kun asiakas aloittaa vuorovaikutuksen järjestelmän kanssa. Istuntopapu ylläpitää asiakkaan istunnon kontekstia ja tarjoaa asiakkaan pyynnöt toteuttavat metodit. Esimerkiksi verkkokaupan shopping-cart-istuntopapu voisi tarjota metodit, joilla asiakas lisää tavaroita ostoskoriin selatessaan tavaraluetteloa ja valitessaan siitä ostettavia tavaroita. Tällaisia metodeja voisivat olla add-item-to-shopping-cart ja check-out. shopping-cartistuntopavun ilmentymän ylläpitämä konteksti identifioi asiakkaan ostoskorin sisältämät tavarat. Istuntopapu voi myös olla tilaton, jolloin se ei ylläpidä kontekstia pyyntöjen välillä. Esimerkkinä tilattomasta istuntopavusta on stock-quote, jonka ilmentymä vastaa jonoon asiakkaan yksittäisiä kyselyitä pörssinoteerauksista. Tässä tapauksessa kontekstia ei tarvita, vaan kaikki pyynnön tyydyttämiseksi tarvittava tieto sisältyy metodikutsun parametreihin. 339
Istuntopavun elinaika on vain yhden istunnon mittainen. Istuntopavun tila ei siis säily istunnosta toiseen eikä järjestelmän romahduksessa. Ostoskorisovelluksessa sanoisimme, että asiakas saa kauppaan saapuessaan oman ostoskorinsa, jonka hän palauttaa kaupasta poistuessaan. Istuntopapu voi käyttää yksilöpapujen palveluksia. Kun asiakas haluaa päättää tilauksensa ostamalla ostoskoriinsa valitsemansa tavarat, kutsutaan check-out-metodia. Tämä puolestaan kutsuu customer-, order- ja shipping-yksilöpapujen metodeja kirjatakseen kaupan tietokannan tauluihin. Istuntopapu voi myös kutsua toisia istuntopapuja, jotka mahdollisesti sijaitsevat muilla J2EE-palvelimilla, mikäli tarvitsee niiden palveluita. Esimerkiksi varojen siirtämiseksi eri pankkien tilien välillä ensimmäisen pankin istuntopapu saattaa tarvita toisen pankin istuntopavun palveluita. 340
Istuntopavun metodi voi olla transaktionaalinen. Esimerkiksi shopping-cart-istuntopavun check-out-metodi voisi käynnistää transaktion. Istuntopavun käynnistämiä transaktioita voi hallita papu itse standardia JDBC-koodia käyttäen tai järjestelmä automaattisesti. Verkkokauppasovelluksen nelikerrostoteutus: 1. Asiakaskone, jossa toimiva www-selain käynnistää wwwpalvelimen palvelinsovelman. 2. Www-palvelin, jossa toimiva palvelinsovelma kutsuu shoppingcart-istuntopavun metodia. 3. Sovelluspalvelin, jossa shopping-cart-istuntopavun metodi kutsuu customer-, order- ja shipping-yksilöpapujen metodeja; yksilöpavut tekevät tiloistaan pysyviä. 4. Tietokantapalvelin, joka ylläpitää pysyvien customer-, order- ja shipping-yksilöpapujen tiloja. 341
Istunto- ja yksilöpapujen metodikutsuihin perustuva kommunikaatio on tahdistettua. Www-palvelimen palvelinsovelma käynnistää sovelluspalvelimen istuntopavun metodin ja jää odottamaan vastausta. Istuntopapu puolestaan kutsuu yksilöpavun metodia ja jää odottamaan vastausta. Tahdistamatonta kommunikaatiota varten J2EE tarjoaa viestin ohjaamat pavut (message-driven bean). Viestin ohjaama papu muistuttaa istuntopapua siinä, että se toteuttaa jonkin yrityksen liiketoimintasääntöjä säilyttämättä tilaansa metodikutsujen välillä. Viestin ohjaaman pavun metodin kutsujan ei kuitenkaan tarvitse jäädä odottamaan kutsun suorituksen valmistumista. Kutsuja voi olla istuntopapu, yksilöpapu tai toinen viestin ohjaama papu tai mikä tahansa Javan viestipalvelua (Java Message Service, JMS) käyttävä järjestelmä tai komponentti. Kutsuja käynnistää viestin ohjaaman pavun lähettämällä sille viestin. Viesti puskuroidaan elpyvään JMS-viestijonoon. 342
Kun uusi viesti saapuu JMS-viestijonoon, järjestelmä kutsuu asianomaista viestin ohjaamaa papua käsittelemään viestin. Viestin ohjaama papu toimii siis kuulostelijana (listener), joka odottelee viestin saapumista. Esimerkiksi ostoskorisovelluksen istuntopavun metodi voisi lähettää tavarantoimitusosaston sovellukselle tahdistamattoman viestin, joka käskee toimittamaan ostetut tavarat, minkä jälkeen istuntopavun metodi voi päättää suorituksensa. Tavarantoimitusosastolla on jono shipping-message-queue, johon se vastaanottaa tällaisia viestejä, ja viestin ohjaama papu shippingmessage-queue-listener, joka käsittelee viestejä yrityksen liiketoimintasääntöjen mukaisesti. 343
Jokaisella viestin ohjaamalla pavulla pitää olla onmessage-metodi, joka käynnistyy automaattisesti viestin saavuttua. Metodi suorittaa viestissä pyydetyn palvelun ja voi siinä tarkoituksessa kutsua muiden papujen metodeja. Viestin ohjaama papu on tilaton: pavun ilmentymän saatua viestin käsitellyksi sen tila vapautetaan ja papu voidaan välittömästi käyttää uudelleen jonossa seuraavana olevan, samalta tai eri sovellukselta peräisin olevan viestin käsittelyyn. Kuten istuntopavun niin myös viestin ohjaaman pavun metodit voivat olla transaktionaalisia, ja käynnistettyä transaktiota voi hallita papu itse tai järjestelmä. 344