Reflektiomekanismien rooli palveluorientoituneissa järjestelmissä Seminaarityö 30.10.2007 Tom Bertell
Sisältö 1 Johdanto... 1 2 Dynaamisuus palveluorientoituneiden järjestelmissä...2 2.1 Yleistä... 2 2.2 Dynaamiset ominaisuudet...3 3 Reflektio ja väliohjelmistot...4 3.1 Reflektio yleisesti...4 3.2 Reflektiivinen väliohjelmistomalli...5 4 Open ORB-reflektiivinen väliohjelmisto...9 4.1 Arkkitehtuuri...9 4.2 Havaintoja...11 5 Yhteenveto... 12 Lähteet...13
1 1 Johdanto Palveluperustainen arkkitehtuuri (Service Oriented Architecture, SOA) on jo jonkin aikaa tarjonnut pohjan nykyaikaisten liiketoimintaprosessien toteuttavien järjestelmien suunnittelulle ja toteutukselle. Palveluorientoitunut arkkitehtuuri on hajautettujen järjestelmien suunnittelu ja toteutustyyli, jonka keskeisinä periaatteina ovat löyhä kytkentä ja palvelujen dynaaminen sidonta [Wee06]. Palveluorientoituneiden järjestelmien luonteen vuoksi palveluita voidaan haluta lisätä tai poistaa, sekä niiden ominaisuuksia muuttaa jopa ajonaikaisesti. Tämän lisäksi nykyaikaiset ketterät liiketoimintamallit ovat tuoneet mukanaan uusia vaatimuksia järjestelmän dynaamisuudelle ja ajonaikaiselle mukautumiselle. Palveluperustaisten järjestelmien suunnittelu, rakentaminen ja ylläpito on erittäin haasteellista. Väliohjelmistot ovat yleisesti käytetty konsepti, jota on käytetty helpottamaan näiden monimutkaisten järjestelmien toteutusta ja toimintaa. Perinteiset väliohjelmistot eivät ole kuitenkaan tarjonneet tarpeeksi monipuolisia mekanismeja palveluperustaisten järjestelmien dynaamisten ominaisuuksien toteuttamiselle [KCB02]. Reflektiota on käytetty jo 1980-luvulta lähtien tuomaan ohjelmointikieliin kaivattua joustavuutta ja dynaamisuutta. Reflektiota voidaan käyttää dynaamisten ominaisuuksia lisäämiseen myös väliohjelmistoihin, jolloin niiden ominaisuuksiin ja käyttäytymiseen voidaan helposti ja tehokkaasti vaikuttaa ajonaikaisesti [HLM05]. Luvussa 2 esitellään palveluorientoituneiden järjestelmien yleispiirteitä ja minkälaisia dynaamisia ominaisuuksia niiden toiminnassa pitää ottaa huomioon. Luvussa 3 selvitetään mitä reflektiolla tarkoitetaan yleisesti ja miten reflektion kautta voidaan lisätä väliohjelmistojen avoimuutta ja dynaamisuutta. Luvussa 4 tutkitaan Open ORB-reflektiivisen väliohjelmiston arkkitehtuuria ja miten se mukautuu ajonaikaisiin konfiguraation muutoksiin.
2 2 Dynaamisuus palveluorientoituneiden järjestelmissä Tässä luvussa kuvataan palveluperustaisten järjestelmien yleiset toimintaperiaatteet. Lisäksi tuodaan esille minkälaisia dynaamisia ominaisuuksia palveluperustaisissa järjestelmissä tulisi ottaa huomioon. 2.1 Yleistä Palveluorientoituneet järjestelmät koostuvat löyhästi toisiinsa kytketyistä palveluista, jotka sidotaan toisiinsa dynaamisesti. Palvelulla tarkoitetaan jonkin liiketoiminnallisen kokonaisuuden toteuttamaa komponenttia, jolla on hyvin määritelty rajapinta. Jotta palvelu kykenee toimimaan osana palveluorientoitunutta järjestelmää, pitää sillä olla tiettyjä yhteentoimivuuden mahdollistavia ominaisuuksia. Ensinnäkin palvelulla pitää olla abstrakti kuvaus palvelun tarjoamasta rajapinnasta ja sen toiminnallisuuden. Kuvauksen tulee pitää sisällään kaikki tieto siitä mitä palvelun pyytäjä tarvitsee palvelun kutsumiseen. Toiseksi palvelun tarjoajien pitää julkaista palvelun rajapinta jossain, jotta muiden olisi mahdollista löytää palvelu ja kutsua sitä [Wee06]. Kuvassa 1 on esitetty palveluorientoituneen arkkitehtuurin osapuolet ja toiminnot. Sido Palvelun kutsuja Etsi Palvelu Julkaise Palvelurekisteri Kuva 1: SOA osapuolet
3 Palveluorientoituneen järjestelmän suunnittelussa ja rakentamisessa pitää ottaa huomioon monia koko järjestelmää koskevia asioita kuten pysyvyyden hallinta, tietoturva, resurssien hallinta ja synkronointi [BBC05]. Näiden asioiden toteuttaminen monimutkaisiin hajautettuihin järjestelmiin on erittäin haastavaa. Väliohjelmistokonsepti on kehitetty helpottamaan monimutkaisten hajautettujen järjestelmien kehittämistä ja käyttöä. Ne toimivat nimensä mukaisesti sovelluksen ja käyttöjärjestelmän välillä. Väliohjelmistot peittävät alempien tasojen yksityiskohdat ja käyttöjärjestelmäkohtaiset rajapinnat. Väliohjelmistoja käyttämällä ohjelmoija pystyy kirjoittamaan helposti ympäristöstä toiseen siirrettäviä sovelluksia, eikä ohjelmoijan tarvitse tuntea alla olevaa käyttöjärjestelmää. 2.2 Dynaamiset ominaisuudet Tähän mennessä kaupallisesti toteutetut palveluperustaisuuden tarjoamat väliohjelmistot ovat olleet melko staattisia. Kaikki järjestelmän toimintaa ja arkkitehtuuria koskevat valinnat ja asetukset on pitänyt tehdä järjestelmän rakentamisvaiheessa tai ne vaativat ainakin järjestelmän uudelleen käynnistyksen tullakseen käyttöön. Taulukossa 1 on lueteltu joitain järjestelmän dynaamisia ominaisuuksia, joiden muutoksiin väliohjelmistojen olisi hyödyllistä pystyä mukautumaan. Dynaaminen ominaisuus Tietoturva Selitys Todennustavan vaihtaminen. (Saattaa vaihdella riippuen kutsujasta) Suorituskyky Suorituskyvyn monitorointi. Pakkausalgoritmin muuttaminen. Dynaaminen sidonta Palvelun valinta Poikkeustilanteiden käsittely Asiakkaan sitominen palveluun vasta ajonaikana. Sopivan palvelun valinta palvelun laatukriteerien perusteella (QoS). Virhe- ja poikkeustilanteiden käsittely ja virhetilanteista toipuminen.
Räätälöidyn liiketoimintalogiikan kutsuminen ta suorittaa tilanteeseen räätälöityä Ennen tai jälkeen varsinaisen palvelun kutsun voidaan halu- liiketoimintalogiikkaa. Versiointi Konfiguroinnin muuttaminen Monitorointi ja lokikirjoitus Jos palvelusta on tullut uusi versio, se halutaan heti käyttöön asiakkaille. Palvelujen konfiguroinnin muuttaminen ajonaikaisesti. Monitoroinnin ja lokikirjoituksen lisääminen palvelun suorituksen eri vaiheisiin. Taulukko 1: Järjestelmän dynaamisia ominaisuuksia 3 Reflektio ja väliohjelmistot Tässä luvussa selvitetään mitä laskennallisella reflektiolla tarkoitetaan ja miten reflektiota voidaan hyödyntää väliohjelmistojen kontekstissa. 3.1 Reflektio yleisesti Laskennallisella reflektiolla tarkoitetaan ohjelman tai järjestelmän kykyä tehdä päätelmiä itsestään ja muuttaa toimintaansa näiden päätelmien perusteella. Jotta järjestelmä pystyisi näin toimimaan, pitää sillä olla käyttäytymistään ja rakennettaan kuvaava malli, joka on kausaalisesti yhdistetty itse järjestelmään. Kausaalisella yhdistämisellä tarkoitetaan sitä, että mallin muutokset heijastuvat suoraan järjestelmään ja sama pätee myös toiseen suuntaan, jos järjestelmää muutetaan [Mae87]. Reflektio ei ole uusi käsite, vaan se esiteltiin ohjelmointikielissä jo 80-luvulla. Reflektio otettiin melko nopeasti käyttöön olio-ohjelmointikielistä, joista sen käyttö laajeni käyttöjärjestelmien kautta väliohjelmistoihin [HLM05]. Esimerkiksi Java-ohjelmointikielessä reflektio on ollut mukana jo versiosta 1.2 lähtien. Reflektiota voidaan käyttää erottamaan varsinainen sovelluslogiikka muusta toiminnallisuudesta. Esimerkkinä transaktiokäsittelyn lisääminen palvelun kutsuun.
5 3.2 Reflektiivinen väliohjelmistomalli Samoja reflektiomekanismeja, joita käytetään ohjelmointikielissä, voidaan käyttää myös väliohjelmistoissa. Väliohjelmistojen tasolla reflektiolla tarkoitetaan sitä, että järjestelmällä on kuvaus omasta sisäisestä toiminnasta ja rakenteestaan. Järjestelmän kuvausta itsestään kutsutaan metatasoksi (meta-level) ja järjestelmää itseään perustasoksi (base-level) (kuva 2). Jotta järjestelmä olisi reflektiivinen niin näiden kuvausten pitää olla kausaalisesti yhteydessä toisiinsa eli väliohjelmiston metatasolle tehtävät muutokset heijastuvat välittömästi väliohjelmiston varsinaiseen toteutukseen perustasolle ja toisin päin jos toteutusta muutetaan, niin myös metamalli muuttuu [Mae87]. Kuva 2: Reflektiivinen järjestelmä [HLM05] Järjestelmä tarjoaa metarajapinnan tai metaolioprotokollan (metaobject protocol, MOP), jonka kautta päästään käsiksi perustason rakenteisiin. Metaolioprotokollan ominaisuuksiin kuuluvat operaatiot alla olevan alustan tutkimiseksi ja sitä kautta sen ominaisuuksien muuttamiseen. Tämä on selkeä ero perinteisiin väliohjelmistoihin verrattuna, jotka piilottavat toiminnallisuuden sisäänsä ja tarjoavat vain rajapinnat toiminnallisuuden käyttämiseen. Reflektiota on käytetty väliohjelmistoissa tarjoamaan parempaa ajonaikaista konfiguroituvuutta ja dynaamista sopeutumista, jotka helpottavat väliohjelmiston päällä toimivien palvelujen yhteentoimivuutta.
6 Perustasolla on väliohjelmistojen tarjoamat yleiset palvelut ja metataso tarjoaa mahdollisuuden palvelujen tutkimiseen (inspection) ja niiden toiminnan mukauttamiseen (adaptation) ympäristön muuttuessa. Osat joita järjestelmästä halutaan kuvata saattavat olla hyvinkin monimutkaisia, jolloin niiden kuvaaminen yhdellä metamallilla saattaa olla vaikeaa. Tästä syystä järjestelmän osat kuvataan yleensä useilla erillisillä metamalleilla, joista kukin tarjoaa näkymän johonkin tiettyyn järjestelmän osaan. Metamallit voidaan edelleen kuvata meta-metamalleiksi ja ketjua voidaan teoriassa jatkaa loputtomiin. Reflektiiviset väliohjelmistot tarjoavat yleisesti kaksi erilaista reflektiotapaa: rakenteeseen kohdistuvan (structural) reflektion ja käyttäytymiseen kohdistuvan (behavioural) reflektion [GGL02]. Rakenteeseen kohdistuva reflektio mahdollistaa järjestelmän sisäisen rakenteen tutkimisen ja muuttamisen. Käytökseen kohdistuva reflektion avulla voidaan järjestelmän tai sen osien toiminnallisuutta tutkia ja muuttaa. Jos järjestelmän kaikkien osien rakennetta ja toimintaa pysyttäisiin vapaasti muuttamaan, niin järjestelmä menisi helposti tilaan, jossa se ei toimisi enää ollenkaan tai se toimisi väärin. Tästä syystä järjestelmästä kuvataan metamallilla vain ne osat, joihin halutaan tehdä muutoksia. Lisäksi metamalleihin lisätään rajoitteita, jotka varmistavat, että järjestelmä toimii oikein myös dynaamisten muutosten jälkeen. Rakenteellisesta reflektiosta esimerkkinä voisi olla palveluiden komposition muuttaminen ajonaikaisesti. Reflektiivisessä väliohjelmistossa tähän riittää palvelujen sidoksia kuvaavan metamallin muuttaminen kuvaamaan uutta tilannetta. Oletetaan tilanne jossa palvelu C1 on sidottu palveluun C2, ja palvelun C2 tilalle halutaan asettaa saman rajapinnan toteuttava palvelu C3 (kuva 3). Vanha sidos (C1, C2) C2 C1 Uusi sidos (C1, C3) C3 Kuva 3: Sidoksen muuttaminen
7 Väliohjelmistotasolla tapahtuu seuraavaa (kuva 4): 1. Valvoja (kuvassa monitor) on väliohjelmiston metatason palvelu, joka pyytää arkkitehtuurin metatasoa luomaan uuden palvelun C3, poistamaan sidoksen palvelujen C2 ja C1 väliltä ja luomaan uuden sidoksen palvelujen C3 ja C1 välille. 2. Arkkitehtuurin metataso poistaa vanhan sidoksen palvelujen C2 ja C1 väliltä ja luo uuden sidoksen. 3. Tästä lähtien palvelun C1 kutsut menevät palvelulle C3. Kuva 4: Sidoksen muuttamisen sekvenssikaavio[bbc05] Käytökseen kohdistuvasta reflektiosta esimerkkinä voisi olla palvelun todennustavan vaihtaminen. Todennustapa voidaan haluta vaihtaa ajonaikaisesti ja se saattaa olla riippuvainen kutsuvasta palvelusta. Koska todennustapa voi vaihdella palvelun suorituskerrasta toiseen sitä ei kannata toteuttaa kiinteästi palveluun, vaan todennus voidaan lisätä palveluun dynaamisesti kutsun yhteydessä. Oletetaan, että palvelu C1 kutsuu palvelua C2 ja palvelu C1 vaatii todennuksen. Tämä voitaisiin toteuttaa reflektiivisessä väliohjelmistossa siten, että palvelun C2 metatason rajapintaan lisättäisiin todennuspalvelun kutsu ennen varsinaista palvelun kutsua.
8 Väliohjelmistotasolla tapahtuu seuraavaa (kuva 5): 1. Valvoja (kuvassa Monitor-palvelu) on väliohjelmiston metatason palvelu, joka on luonut sidoksen palvelun C1 ja C2 välille. 2. Valvoja luo todennuspalvelun (kuvassa PreMethodB). 3. Valvoja lisää todennuspalvelun kutsun palveluiden väliseen sidokseen. 4. Kun palvelu C1 kutsuu palvelun C2 MethodB()-metodia, niin kutsutaan ensin todennuspalvelua PreMethodB. Kuva5: Todennuksen lisäämisen sekvenssikaavio[bbc05]
9 4 Open ORB-reflektiivinen väliohjelmisto Tässä luvussa esitellään reflektiivistä Open ORB-väliohjelmistoa, sekä tutkitaan päällisin puolin sen arkkitehtuuria ja sitä miten se suhtautuu järjestelmältä vaadittaviin rakenteen ja toiminnallisuuden ajonaikaisiin muutoksiin. 4.1 Arkkitehtuuri Open ORB-projekti on pyrkinyt suunnittelemaan erittäin konfiguroituvan väliohjelmiston, joka tukee useita hajautetuilta järjestelmiltä toivottuja dynaamisia ominaisuuksia [GGL02]. Väliohjelmiston perustoiminnallisuus koostuu komponenteista, joista voidaan koostaa sopivan toiminnallisuuden toteuttavia komponenttikehyksiä (component framework). Komponenttikehykset sisältävät rajoitteet, joita komponenttikehyksen sisäisen rakenteen pitää noudattaa. Komponenttikehyksillä on selkeästi määritellyt riippuvuudet muihin komponentteihin, jonka avulla niistä on yksinkertaista koostaa uusia rakenteita. Määriteltyjen sääntöjen ja riippuvuuksien avulla väliohjelmisto pystyy pitämään järjestelmän sallitussa tilassa dynaamisen konfiguroinnin yhteydessä. Perustaso koostuu perinteisistä väliohjelmiston komponenteista, joiden toteutus paljastetaan metatason komponenteilla. Dynaamista konfigurointia varten järjestelmän jokaista komponenttia kohti on vähintään yksi metatason komponentti. Jokaista perustason komponenttia kohden voi olla joukko metatason komponentteja, jota kutsutaan komponentin meta-avaruudeksi [BBC05]. Väliohjelmiston metamalli on jaettu selkeiksi osiksi, jotka tarjoavat loogisen näkymän järjestelmän eri osien toteutukseen. Metamallit ovat arkkitehtuuri- (architecture), rajapinta- (interface) ja sieppausmetamalli (interception) (kuva 6).
10 Kuva 6: Väliohjelmiston perustaso ja metataso [KCB02] Rajapinta- ja arkkitehtuurimetamallit mahdollistavat rakenteellisen reflektion ja tekevät selkeän eron komponentin ulkoisen toiminnallisuuden (rajapinnat) ja sisäisen rakenteen välille. Rajapintametamalli paljastaa komponentin tarjoamat ja tarvitsemat rajapinnat operaatioineen. Metamalliin liittyvä metaolioprotokolla mahdollistaa elementtien listaamisen ja etsimisen, joten se mahdollistaa esimerkiksi komponentin tarjoamien palvelujen dynaamisen etsimisen. Rajapintametamalli tarjoaa siten samanlaisen toiminnallisuuden kuin Javan Reflection API, joka avulla ohjelmoija pystyy hyödyntämään komponenttien dynaamisesti löydettyjä ominaisuuksia. Arkkitehtuurimetamalli on keskittynyt nimensä mukaisesti kuvaamansa komponentin sisäiseen toteutukseen. Kuvaus jakaantuu kahteen osaan: komponenttikaavioon (component graph) ja arkkitehtuurisiin sääntöihin (architectural constraints), joista ensimmäinen kuvaa komponentin suhteen muihin komponentteihin ja toinen kuvaa säännöt joilla komponentteja voidaan yhdistellä. Komponenttikaavio on keskeinen osa mallia. Se kuvaa joukon komponentteja, jotka on yhdistetty toisiinsa paikallisilla sidoksilla (local bindings). Paikallinen sidos pitää sisällään kuvauksen komponentin rajapinnoista. Malliin liittyvä metaolioprotokolla mahdollistaa komponenttien lisäämisen, poistamisen ja korvaamisen ja sääntöjen muuttamisen. Tämä mahdollistaa dynaamisen mukautumisen. Perinteisissä
11 väliohjelmistoissa tämän kaltainen toiminnallisuus olisi piilossa komponentin käyttäjältä, mutta arkkitehtuurimetamallin avulla järjestelmän rakennetta voidaan tutkia ja se pystyy mukautumaan ympäristön muutoksiin ajonaikaisesti. Open ORB-väliohjelmistossa sieppausmetamalli tukee käyttäytymiseen kohdistuvaa reflektiota. Sen avulla järjestelmän komponenttien rajapintoihin voidaan lisätä dyynamisesti sieppaajia (interceptor). Sieppaajien avulla on mahdollista suorittaa uutta toiminnallisuutta ennen ja jälkeen komponenttien kutsujen. Tämän mekanismin avulla järjestelmään voidaan lisätä ajonaikaisesti esimerkiksi monitorointi-, tietoturva- ja laskutuspalveluja [GGL02]. Kuvassa 6 on vielä mukana resurssimetamalli (resource metamodel), jonka avulla olisi mahdollista päästä suoraan käsiksi järjestelmän resurssien hallintaan ja sitä kautta resursseihin. Resurssimetamallia ei kuitenkaan ole enää mukana väliohjelmiston uudemmissa versioissa, joten sen toimintaa ei käsitellä tässä sen tarkemmin. 4.2 Havaintoja Vaikka tässä luvussa esitelty reflektiivinen väliohjelmisto on vain yksi esimerkki lukuisten reflektiivisten väliohjelmistojen joukossa, niin niiden kaikkien tarjoama toiminnallisuus on hyvin samankaltainen. Kaikissa reflektiivisissä väliohjelmistoissa on yhteisenä pyrkimyksenä lisätä väliohjelmistojen joustavuutta, dynaamisuutta ja mukautuvuutta reflektion käytöllä ja siten ne tukevat yhteentoimivien järjestelmien rakentamista ja käyttöä. Open ORB-väliohjelmiston avulla olisi mahdollista toteuttaa useat palveluorientoituneiden järjestelmien taulukossa 1 mainitut dynaamiset ominaisuudet. Open ORB-väliohjelmiston avulla on onnistuneesti toteutettu mm. seuraavia ajonaikaista mukautumista tukevia järjestelmiä: Mukautuva multimediajärjestelmä: Järjestelmä pystyy mukautumaan muuttamalla puskurin kokoa ja lähetyksen laatua ympäristön mukaan. Mukautuva mobiiliväliohjelmisto: Komponenttien liikennöintitapa pystyy mukautumaan tarjolla olevien palvelujen mukaisesti.
12 Mukautuva verkkoarkkitehtuuri: Mahdollistaa kaikkien verkkoarkkitehtuurin kerrosten mukautumisen käyttämällä reflektiota. Tätä ominaisuutta hyödynnetään verkon kokonaislaajuisessa virheistä toipumisessa. 5 Yhteenveto Palveluorientoituneiden järjestelmien rakentaminen ja ajaminen on niiden avoimen ja dynaamisen luonteensa vuoksi haastavaa. Väliohjelmistoja on käytetty helpottamaan näiden monimutkaisten järjestelmien integraatiota. Perinteiset väliohjelmistot eivät ole mahdollistaneet järjestelmien rakenteen ja ominaisuuksien joustavaa dynaamista konfigurointia ja mukautumista ympäristön muutoksiin. Tätä varten on kehitetty reflektiivisiä väliohjelmistoja, jotka tarjoavat pääsyn järjestelmän sisäiseen rakenteeseen ja toiminnallisuuteen metarajapintojen kautta. Järjestelmän sisäisen toiminnan paljastaminen reflektion kautta mahdollistaa järjestelmien mukautumisen ympäristön muutoksiin ja täysin uusien dynaamisten ominaisuuksien lisäämistä järjestelmiin. Reflektion tarjoamia mahdollisuuksia voitaisiin hyödyntää palveluperustaisten järjestelmien toiminnassa. Koska reflektioon ja reflektiivisiin järjestelmiin liittyvät aiheet ovat melko monimutkaisia ja poikkeavat melkoisesti perinteisestä tavasta ajatella järjestelmien ominaisuuksia, niin uskon, että on vielä pitkä matka siihen, kun reflektio on yleinen ominaisuus kaupallisessa käytössä olevissa väliohjelmistoissa.
13 Lähteet BBC05 GGL02 HLM05 KCB02 Mae87 Wee06 N. Bencomo, G. Blair, G. Coulson, P. Grace, and A. Rashid. Reflection and aspects meet again: runtime reflective mechanisms for dynamic aspects. In AOMD '05: Proceedings of the 1st workshop on Aspect orien ted middleware development, New York, NY, USA, 2005. ACM Press. Blair Gordon, S. Coulson Geoff, Blair Lynne, Duran-Limon Hector, Grace Paul, Moreira Rui, Parlavantzas Nikos. Reflection, Self-Awareness and Self-Healing in OpenORB. WOSS '02: Proceedings of the first workshop on Self-healing systems. Gang Huang, Xuanzhe Liu and Hong Mei (2005) Towards Dependable Service-Oriented Architecture via Reflective Middleware, International J ournal of Simulation and Process Modeling, Vol.?, No.?, 2005. Fabio Kon, Fabio Costa, Gordon Blair, and Roy H. Campbell. The case for reflective middleware. Commun. ACM, 45(6):33-38, 2002. Pattie Maes. Concepts and experiments in computational reflection. In OOPSLA '87: Conference proceedings on Object-oriented programming systems, languages and applications, pages 147-155, New York, NY, USA, 1987. ACM Press. Weerawarana S., et al., Web Services Platform Architecture. Prentice Hall, 2006