Sisältö. Tapahtumienhallinta. Tapahtumat (transaktiot) Kaupallinen tapahtuma (transaktio)

Transkriptio

1 Sisältö Janne Kuha Descom Oy Tapahtumat ja ACID-ominaisuudet. Tapahtumamonitorit ja niiden kehitys. Java2 Enterprise Edition lyhyt esittely. Tapahtumanhallinta ja J2EE. IBM WebSphere sovelluspalvelin - tapahtumanhallinnan mekanismit käytännössä. Kaupallinen tapahtuma (transaktio) Tapahtumat (transaktiot) Kaupallinen tapahtuma (transaktio) tarkoittaa palvelun, tuotteen tai informaation valintaa, sen ostamista ja ostetun palvelun sekä siitä maksettavien vastikkeiden vaihtoa tapahtuman eri osapuolten kesken. 1

2 Tekninen tapahtuma (transaktio) Yleisesti Tapahtuma on joukko operaatiota, jotka muuttavat sovelluksen tilaa. Esimerkiksi muutos tietokannan tietoihin. Tekniseltä kannalta ACID-ominaisuudet (selv. myöh.) täyttävä joukko operaatiota. Esimerkiksi tilisiirtoon liittyvät toiminnot ovat kaikki osa samaa tapahtumasarjaa, esim. Ensimmäisen tilin saldon vähennys, toisen tilin saldon kasvattaminen ja lokien kirjoittaminen tilisiirrosta. Sovelluksen tila Sovelluksen tila pitää sisällään mm. muistissa olevat tiedot, massamuisteissa, ja tietokannoissa olevat tiedot Tarkoittaa siis kaikkea sitä tietoa, jonka sovellus tietää Häiriötilanteesta johtuvan uudelleenkäynnistyksen yhteydessä halutaan varmistaa, että sovelluksen tila voidaan palauttaa tapahtumankäsittely Sovelluksen tilan muutokset Sovelluksessa on yleensä tiettyjä sääntöjä, jotka määrittelevät tiedon oikeellisuutta, esimerkiksi, postinumeron täytyy olla kuusi merkkiä pitkä. Sekä sääntöjä, jotka liittyvät tilamuutoksiin, esimerkiksi tilin saldon muuttuminen pitää kirjata myös tilikirjaan. Sovelluksen tila on johdonmukainen ja eheä, silloin kun kaikkia em. säännöt otetaan huomioon. ACID ACID ominaisuudet ovat Atomicity Kaikki työhön kuuluvat alioperaatiot onnistuvat tai ne kaikki peruutetaan takaisin (roll-back). Consistency Tapahtuman jälkeen järjestelmän tila on tunnettu. Isolation Kukin tapahtuma toimii omassa ympäristössään vaikuttamatta muihin tapahtumiin. Tapahtumat näyttävät näin ollen serialisoiduilta. Durability Tapahtuman aiheuttama tilamuutos on pysyvä. 2

3 ACID esimerkkejä Rahan nostaminen automaatista (A) Joko rahat saa automaatista ja tilin saldoa vähennetään, tai kumpaakaan ei tehdä. (C) Automaatista saatu rahamäärä ja tililtä vähennettävä rahamäärä vastaavat toisiaan. (I) Samaa tiliä voidaan käsitellä samanaikaisesti toisesta tapahtumasta (esim. joku tallettaa tilille rahaa). (D) Saldomuutos tallentuu pysyvästi pankkitietoihin. Tapahtumamonitorit Tapahtumanmonitorit Tapahtumamonitorin tarkoituksena on hallinnoida, ohjata ja toteuttaa teknisiä tapahtumia. TM-ohjelmaa käytettäessä sovelluksen kehittäjä voi jättää tapahtumankäsittelyyn liittyvät toiminnot TM-ohjelman huoleksi. Tapahtumamonitorin määritelmä Transaction processing monitor (TP monitor). Name for a class of products typified by CICS, ACMS, Pathway, and Tuxedo, which provide a transaction execution environment on top of conventional (basic) operating systems. Roughly speaking, TP monitors encompass the functionality of both the transaction processing operating system and the transaction processing services. Jim Gray ja Andreas Reuter [Gray,Transaction processing, 1993] 3

4 Perinteisen TM-ohjelmiston rakenne Tapahtumamonitorit Presentation Services TP Monitor Communication Manager Service Request/ Response Send/Receive Dispatch Finish Business Application Program Transaction Manager Application Designer designs and codes. Service Call Join Transaction Resource Managers Log Manager Log Records Transaction Processing (TP) Monitors Tapahtumamonitoreilla on noin 35- vuotinen historia takanaan. Tapahtumamonitoriympäristön ohjelmat on kirjoitettu käyttäen proseduraalisia kieliä, kuten COBOLia tai C:tä. Erittäin järeitä ja luotettavia järjestelmiä. Jim Gray ja Andreas Reuter [Gray,Transaction processing, 1993] Tapahtumamonitorien palvelut Tarjoaa ohjelmointi- ja ajoympäristön transaktionaalisten ohjelmistojen toteuttamiselle Tarjoaa valmiita palveluja kuten käyttöoikeuksien hallinta, kuorman tasaus, konfiguroinnin hallinta, jne. Hallitsee monien eri samanaikaisten käyttäjien tapahtumien käynnistämistä, ajamista ja päättämistä. Eristää eri käyttäjät siten, etteivät he päivitä saman resurssin tietoja samanaikaisesti. Kokonaiskuva TM-ohjelmistojen kehitykseen Mainframe Mini/WAN PC/LAN Client/ Server Internet/ Intranet 1960s s 1970s s 1980s s 1990s s Perinteiset tapahtumamonitoriohjelmistot Komponentti (/olio) tapahtumamonitoriohjelmistot Kehittyneemmät (Proseduraaliset) tapahtumamonitoriohjelmistot 4

5 Perinteiset tapahtumamonitorit Syynä rakentamiseen tarve toteuttaa ensimmäisiä lentolippujen varausjärjestelmiä, pankkijärjestelmiä, jne. Erittäin suljettuja järjestelmiä (yhden alustan - käyttöjärjestelmän ja laitteiston - järjestelmiä). Yksiosaisia eli ohjelmistoja ja niiden osia ei voida juurikaan erotella toisistaan Palvelimina keskuskoneet, sovellusten ohjelmointikielinä Cobol, Assembler Käytössä ei ollut yleisesti käytettyjä tapahtumanhallinnan standardeja. Esimerkiksi: CICS ja IMS Proseduraaliset tapahtumamonitorit 1/2 Proseduraaliset tapahtumamonitoriohjelmistot tällä hetkellä pitkän kehityksen tulos. Ne ovat tunnettuja luotettavuudestaan ja hyvyydestään monimutkaisten tapahtumien hallinnassa. Kalliita Ohjelmistojen toteuttaminen vaatii tavallisesti vaativampaa osaamista Tuotettavat ohjelmat proseduraalisia, käytetyt ohjelmointikielet mm. Cobol, C, C++ Proseduraaliset tapahtumamonitorit 2/2 Usein rajattu joukko käyttöjärjestelmä/laite-alustoja, joille ohjelmistoja saatavilla (usein järeämmille laitealustoille). Tyypillisiä järjestelmiä mm. pankki-, raha-automaatti-, palkanmasku-, vakuutus-, lennonyhtiöiden lennonvarausjärjestelmät. Standardeina esimerkiksi LU 6.2 ~ APPC ~ CPIC Esimerkkinä BEA Tuxedo Komponenttitapahtumamonitorit 1/3 Kehittymisen syyt Historiallinen kehitys: Internet-teknologioiden kehittyminen. Verkottuminen: Heterogeeniset järjestelmät, pienten järjestelmäalustojen käytön yleistyminen, hajauttaminen (esim. CORBA). Oliopohjaisten ohjelmointikielien sekä Komponenttiteknologioiden kehittyminen. Pitää saada tehdä e-business-järjestelmiä ohjelmoimalla olioita ja tuottaa uudelleenkäytettäviä komponentteja. Järjestelmä pitää pystyä hajauttamaan ja pitää saada ohjelmoida Javalla. Niin. ja pitäisi varmaankin niitä tapahtumiakin hallita. 5

6 Komponenttitapahtumamonitorit 2/3 Komponenttitapahtumamonitorit (Component Transaction Monitors - CTM) ovat kahden eri teknologian yhteenliittymiä Tapahtumamonitorit ja tapahtumankäsittely Hajautetut oliojärjestelmät ja hajautetut viestinvälitysjärjestelmät (ORB) Komponenttitapahtumamonitorit perusosat Hajautetut oliot (tai komponentit) infrastruktuuri, sisältäen tapahtumanhallinnan Palvelimella ajettava komponenttimalli (sovelluskohtainen) Komponenttitapahtumamonitorit 3/3 Useiden CORBA-pohjaisten järjestelmien ongelma Kommunikaatio ja hajautusteknologioista on sovittu, mutta ei sopimusta palvelimen päässä olevasta komponenttimallista (jokaisella oma) Vastauksena tähän ongelmaan kehitettiin mm. Enterprise JavaBeans standardi Samoja sovelluksia voidaan käyttää eri valmistajien sovelluspalvelinten sisällä. Yhteenveto Proseduraaliset tapahtumamonitoriohjelmistot: Ohjelmointikieli, aika ajanut ohitse toteutustavoista, osaajien löytäminen hankalampaa. Ei ole suunniteltu internet-maailman ehdoilla. Ohjelmistojen kehitystyö tasaantunut - luotettavuus hyvä. Isot olemassa olevat järjestelmät toteutettu hyvin pitkälti tälle pohjalle. Komponenttitapahtumamonitoriohjelmistot: Uudehkoja järjestelmiä, kehitystyö nopeaa - luotettavuus huonompi. Nykyiset muodissa olevat sovellusten kehitystavat, osaajien löytäminen helpompaa. Java2 Enterprise Edition - lyhyt esittely 6

7 Mikä on J2EE? Java 2 Platform, Enterprise Edition (J2EE) technology tarjoaa komponenttipohjaisen lähtötavan sovelluksien suunnitteluun, kehittämiseen, koostamiseen ja ajoympäristöön viemiseen. Mitä J2EE tarjoaa? J2EE-alusta tarjoaa Hajautetun ja monitasoisen sovellusmallin. Mahdollisuuden komponenttien uudelleenkäyttöön Yhtenäistetyn turvallisuusmallin. Joustavan tapahtumanhallinnan. J2EE-arkkitehtuurin tasot FAT-client Thin-client ASIAKAS JAVA GUI Asiakasohjelma PDA, jne Selain Asiakastaso Tapahtumanhallinta ja J2EE Servletit & JSP-sivut Web-taso PALVELIN EJBkomponentit Liiketoimintataso TIETOKANTAPALVELIN tai LEGACYJÄRJESTELMÄT Tietokannat Legacyjärjestelmät EIS-taso 7

8 Tapahtumat J2EE-alustalla Tapahtumat voivat olla hajautettuina usean eri komponentin, palvelimen ja tietokannan välillä. Tapahtuman epäonnistuessa kussakin tapahtumaan kuuluvassa osasessa perutaan muutokset kyseiseen järjestelmään (jos mahdollista) Tapahtumaan liittyvän kontekstin ja kokonaisuuden pitää hallussa tapahtumahallitsija (transaction manager) Kullakin järjestelmään kuuluvalla osalla on oma resurssihallitsija. Tapahtumanhallintaan liittyvät osat Transaction Manager tarjoaa kaikki peruspalvelut, joita tarvitaan tapahtumanhallinnan yhteydessä Transaction Processing Monitor (TP-Monitor) tarjoaa tapahtumainfastruktuurin Resource Manager tarjoaa tapahtumaan osallistuvat resurssit järjestelmän käyttöön (esimerkiksi tietokantapalvelin) Tapahtumalokeihin kirjoitetaan tieto kustakin tapahtumasta ja niiden tilasta (ACID). Tapahtumakonteksti välitetään kullekin samaan transaktioon osallistuvalle komponentille. Hajautettu tapahtuma Tapahtumanhallitsijan tehtävät Transaktio konteksti Sovelluspalvelin 1 Sovelluspalvelin 2 Resurssi Resurssi Transaktio Tietokanta 2 Resurssi Tietokanta 1 Resurssi Tapahtumanhallitsijan (transaction manager) tehtävänä on huolehtia Tapahtuman tarkasta rajaamisesta, siten että sillä on tietty alku ja loppu (demarcation). Tapahtumakontekstin luomisesta Huolehtia 2-osaisen varmistuksen suorittamisesta (2-phase commit / 2PC) Tapahtumaan liittyvät kolme komentoa aloita (begin) transaktion aloittaminen toteuta (commit) kaikki transaktioon liittyvät muutokset toteutetaan ja niistä tulee pysyviä peruuta (rollback) kaikki transaktioon liittyvät muutokset perutaan 8

9 Tapahtumahallinnan käytännössä IBM WebSphere sovelluspalvelin Tapahtumanhallinnan mekanismit käytännössä Transaktioon kuuluvat osaset toimivat ACID-periaatteiden mukaisesti. EJB-komponenttien yhteydessä voidaan transaktiot määritellä kahdella tapaa Deployment descriptorissa (asennuskuvain, käytönkuvain) tapahtuma Java Transaction APIn avulla erikseen käsittelemällä ohjelmallisesti transaktioita Tapahtuma-asetusten määrittely Esimerkki tapahtuma-asetusten määrittelystä Seuraavat transaktioattribuutit voivat esiintyä deployment descriptorissa REQUIRED REQUIRES_NEW SUPPORTS MANDATORY NOT_SUPPORTED NEVER BEAN_MANAGED Sovelluspalvelimen tehtäväksi jää huolehtia transaktioon liittyvistä asioista (aloitus, toteutus ja peruutus), mikäli transaktiot määritellään deployment descriptorissa. <container-transaction> <method> <ejb-name>searchmanager</ejb-name> <method-intf>local</method-intf> <method-name>listcompanies</method-name> <method-params> <method-param>fi.descom.searchkey</method-param> </method-params> </method> <trans-attribute>required</trans-attribute> </container-transaction> <container-transaction> <method> <ejb-name>searchmanager</ejb-name> <method-intf>local</method-intf> <method-name>listdepartments</method-name> <method-params> <method-param>fi.descom.searchkey</method-param> </method-params> </method> <trans-attribute>requiresnew</trans-attribute> </container-transaction> 9

10 2-osainen varmistus (2-phase commit) 2-osainen varmistus (2-phase commit) 2-osainen varmistus on protokolla, jonka avulla hoidetaan tapahtumaeheys järjestelmissä, joihin liittyy enemmän kuin yksi resurssihallitsija 2-osaisella varmistuksella pidetään huoli siitä, että mikä tahansa tapahtumaan kuuluva osa (tietokanta, jne.) voi määrätä koko transaktion vedettäväksi takaisin (roll-back) Kukin samaan tapahtumaan liittyvä resurssihallitsija ilmoittautuu osaksi tapahtumaa 1. 2-osaisessa varmistuksessa transaktiosta vastaava kysyy ensin kaikilta osa-puolilta onko kyseinen tapahtuma niille mahdollinen ja sen jälkeen päättää voidaanko transaktiossa edetä. 2. Jos transaktiossa voidaan edetä, ilmoitetaan kaikille osapuolille että niiden tulee toteuttaa (commit) kyseinen tapahtuma. 3. Vielä tässäkin vaiheessa mikä tahansa osa voi ilmoittaa ettei kykene hoitamaan transaktion vaatimuksia, jolloin kaikille osapuolille ilmoitetaan perumisesta (abort / roll-back). Tietokanta 2 1. valmistaudu 2. valmis 3. Toteuta tai keskeytä Resurssi Transaktio WebSphere 2PC / XA Kysymyksiä? lähde: 10