SOA:lle on useita, jonkin verran toisistaan poikkeavia määritelmiä. Alla niistä muutamia.

Transkriptio

1 1

2 Tässä esimerkki vaikkapa tyypillisestä yrityksen tietojärjestelmästä. Järjestelmään liitetään uusia osia vähitellen. Eri osat ovat eri tahojen erilaisilla teknologioilla kehittämiä. Osien välinen liitos tehdään aina kun sellainen tarvitaan, milloin mitenkin. Jos liitosta ei suunnitella huolella syntyy tarpeettomia riippuvuuksia eri järjestelmien osien toteutuksien välillä. Kun liitokset tehdään ad hoc -tyyliin yksi kerrallaan, on niiden tekemisessä turhaa työtä. (Liittääkseen kaikki N osaa toisiinsa, tarvitaan N-1 liitosta). Koska järjestelmän osien yhteistoimintaa ei ole suunniteltu, ei välttämättä ole helppoa tapaa käyttää muiden osien toiminnallisuutta. Tämä johtaa päällekkäisyyteen: sama toiminnallisuus toteutetaan useaan paikkaan. Ongelmia siis ovat ainakin tarpeettomat riippuvuudet, päällekkäiset toteutukset ja liitoksien monimutkaisuus. Näistä syistä muutosten teko järjestelmään on vaikeaa. Muun muassa näitä ongelmia palvelukeskeisyys ja palvelupohjainen arkkitehtuuri pyrkii ratkaisemaan. 2

3 Palvelukeskeinen arkkitehtuuri (palvelupohjainen arkkitehtuuri, serviceoriented architecture, SOA) on arkkitehtuurityyli (tai paradigma), jossa järjestelmä koostuu palveluista ja näiden välisestä viestinnästä. Palvelu on itsenäinen ohjelmistokokonaisuus, joka tarjoaa rajapinnan jonkun korkean tason toiminnallisuuden saavuttamiseksi. Palvelut ovat useimmiten sen verran korkealla abstraktiotasolla, että niiden idea voidaan kuvata ohjelmistoista mitään tietämättömällekin: esim. säätietopalvelu, hotellienvarauspalvelu, pörssikurssipalvelu, jne. Olennaista on, että palvelut ovat toisiinsa löyhästi sidottuja (loosely coupled). Riippuvuudet eri palveluiden välillä siis pyritään minimoimaan. Toinen olennainen seikka on, että palvelut ovat autonomisia, eli ovat itse vastuussa siitä miten toteuttavat toiminnallisuutensa kukaan ylempi taho ei sitä määrää. SOA:lle on useita, jonkin verran toisistaan poikkeavia määritelmiä. Alla niistä muutamia. Wikipedia, SOA is a software design and software architecture design pattern based on 3

4 distinct pieces of software providing application functionality as services to other applications. OASIS SOA Reference Model A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. Nicolai M. Josuttis: SOA in Practice SOA is an architectural paradigm for dealing with business processes distributed over a large landscape of existing and new heterogeneous systems that are under the control of different owners. The Open Group Service-Oriented Architecture (SOA) is an architectural style that supports serviceorientation. 3

5 Palvelukeskeisyys ja SOA sopivat hyvin tilanteisiin, joissa kehitetään suurta hajautettua (tai ei-keskitettyä) järjestelmää, jonka eri osat ovat eri tahojen kehittämiä ja ylläpitämiä. Lisäksi eri osat voivat olla eri teknologioilla kehitettyjä. SOA ei varsinaisesti *pyri* esim. eri järjestelmän osien heterogeenisuuteen, mutta hyväksyy, että se on usein todellisuutta. Samoin kuin vaikkapa ketterät ohjelmistonkehitysmenetelmät eivät *pyri* siihen, että ohjelmiston vaatimukset jatkuvasti muuttuvat, mutta hyväksyvät että näin usein käy ja pyrkivät ottamaan sen huomioon. 4

6 SOA pyrkii mm. seuraaviin hyviin asioihin. Yhteistoiminta. Järjestelmän käyttävät yhteisesti sovittua tapaa rajapinnan määrittelyyn ja kommunikointiin. Joustavuus. Vältä riippuvuuksia, jotta järjestelmän muuttaminen on nopeaa. Uudelleenkäyttö. Toteuta tietty toiminnallisuus vain kertaalleen ja tarjoa se palveluna. Hyödynnä legacy-järjestelmiä. Vanhat järjestelmät voidaan kääriä palveluksi. 5

7 Yksi näkökulma palvelupohjaisuuteen on tarkastella sitä uutena ohjelmistojen abstraktiotasona. Ohjelmistuotannon välineiden ja ohjelmointikielten kehityksessä abstraktiotason nosto on aina näytellyt merkittävää osaa, eikä ole mitään syytä olettaa tähän trendiin tulevan muutosta jatkossakaan. Esimerkiksi ohjelmointikielten kehitys yleisesti on pyrkinyt tarjoamaan ohjelmoijille korkeamman ja ohjelmoijaystävällisemmän abstraktiotason ohjelmien kirjoittamiseksi. Olioperustainen ohjelmistokehitys (ja olioperustaiset ohjelmointikielet) tarjosivat/tarjoavat luonnollisen tavan ajatella ohjelmien käsitteitä (luokat ja oliot) ja niiden suhteisiin perustuvaa ohjelmien rakennetta. Komponentit ja hajautustekniikat edelleen tarjoavat korkeamman abstraktiotason oliokieliinkin verrattuna. Hajautus on periaatteessa yksinkertainen asia, mutta eri komponenttiteknologioilla (RMI, (D)COM, CORBA, ) on kiinnostavia ominaisuuksia. Ensinnäkin ne sallivat integroitavien komponenttien/alisysteemien käsittelemisen mustana laatikkona (rajapinta oleellinen). Komponenttien yhteiskäyttöön ja niiden konfigurointiin liittyvät ongelmat on käytännössä jätetty ohjelmoijien ratkottaviksi. Palvelut voidaankin nähdä seuraavana askeleena abstraktiotason nostossa. 6

8 Palvelu (Service) on autonominen ohjelmistokokonaisuus, jota palvelun asiakkaat (Service customer) käyttävät toteutusriippumattoman rajapinnan kautta. Tästä rajapinnasta käytetään palvelupohjaisten järjestelmien yhteydessä usein nimitystä palvelusopimus (Service contract). Joissain yhteyksissä asiakasta kutsutaan nimellä Service requestor ja itse palvelua nimellä Service provider. Myös muunlaisia nimeämiskäytäntöjä on. 7

9 Palvelut voivat myös omaksua asiakkaan roolin, eli siis kutsua muita palveluita. Palvelupohjaisuuden ideaan kuuluu, että palvelut ovat autonomisia. Ne ovat itse vastuussa siitä, miten ne toteuttavat palvelusopimuksessa määritellyn toiminnallisuuden. Autonomisuuteen kuuluu myös päätösvalta siitä, mitä muita palveluita kutsuu. 8

10 Palvelupohjaisuuden ideaaliin kuuluu, että se mitä palvelua käytetään, päätetään mahdollisimman myöhään (= ns. myöhäinen sidonta, late binding). Tämän mahdollistamiseksi voidaan luoda palvelurekisteri, jolta voi kysellä tietoa saatavilla olevista palveluista. Tämä yleiskuva palvelupohjaisesta arkkitehtuurista on yleisesti käytetty ja sitä kutsutaan toisinaan myös Web-palvelun arkkitehtuuriksi. Sama perusarkkitehtuuri esiintyy useissa eri lähteissä, pienin nimeämismuutoksin varustettuina. Mm. palvelurekisteriä kutsutaan jossain myös nimellä Service Broker. Esimerkkiskenaario: 1.) Palvelu julkistaa (Publish) palvelusopimuksensa palvelurekisteriin (Registry) 2.) Asiakas (Customer) etsii haluttua palvelua kutsuen rekisteripalvelua 3.) Asiakas saa rekisteripalvelusta vastauksen, jossa kuvataan palvelu ja se miten sitä voidaan käyttää. Eli palvelun palvelusopimuksen. 4.) Asiakas kutsuu palvelua saadun kuvauksen perusteella 9

11 Palvelun sisäinen toteutus voidaan tehdä millä tahansa ohjelmointikielellä ja muutenkin miten toteuttaja parhaaksi näkee. Yhteisymmärrys eri järjestelmän osien välillä sen sijaan taas tarvitaan: 1) Kommunikointitavasta 2) Siitä miten palvelusopimus eli palvelun rajapinta määritellään Perinteinen ja edelleenkin käytössä oleva tapa on käyttää kommunikointiin SOAP:ia (Simple Object Access Protocol) ja palvelukuvauksiin WSDL:ää (Web Service Description Language). Molemmat ovat XML-pohjaisia kieliä. Ne ovat osa ns. Web services standardeja, joihin kuuluu monia muitakin. Toinen, yleistyvä tapa, on käyttää REST-rajapintoja (Representational state transfer). Siinä käytetään hyväksi monia HTTP-protokollan tarjoamia ominaisuuksia. Varsinainen kommunikointi voidaan tehdä eri formaateilla. 10

12 Mitä uutta SOA tarjoaa olemassa oleviin ajattelutapoihin ja tekniikoihin verrattuna? Jos asiaa tarkastellaan puhtaasti ohjelmistoarkkitehtuurisesta näkökulmasta, ei SOA periaatteessa vaikuta kovinkaan kiinnostavalta eikä e näytä tarjoavan oleellisesti paljonkaan uutta (vrt. hajautusteknologiat). Edellä mainitut SOAn periaatteet ja vaatimukset voidaan hyvin pitkälle katsoa samoiksi odotuksiksi ne, joita hajautustekniikoilta aikoinaan odotettiin ja edellytettiinkin: korkea abstraktiotaso, toteutuskieli- ja/tai alustariippumattomuus, autonomisuus, mahdollisimman löyhät sidonnat, tavoitteena itsenäiset ja pitkäikäiset komponentit, ketteryys vaatimusten hallinnassa jne. Hajautustekniikat eivät kuitenkaan kyenneet kovin hyvin vastaamaan näihin haasteisiin. SOAlta ja Web-palveluilta odotetaankin paljon näiden haasteiden näkökulmasta. Esimerkiksi löyhät sidonnat voidaan toteuttaa mielenkiintoisesti Web-palveluteknologioita hyödyntäen, joista käytännössä ollaan päästy sopimukseen (WSDL ja SOAP, näihin palataan myöhemmin). Lisäksi muitakin eroja tuntuu löytyvän. SOAa ja Web-palveluita ei ole tarkoitettu vain RPC-tyyppiseen kommunikointiin. Lisäksi tavoitteena on paitsi ohjelmiston myös niiden hallinnan hajautus. SOA voidaankin kuitenkin katsoa tietynlaiseksi hypyksi seuraavalle abstraktiotasolle (komponentit->palvelut). 11

13 SOA:a ei kuitenkaan kannata eikä pidä tarkastella vain puhtaasta ohjelmistotuotannollisesta näkökulmasta. SOA:n ehkäpä suurin uutuusarvo on siinä, että se tuo ohjelmistoteknistä ja liiketoimintaorientoitunutta näkökulmaa lähemmäksi toisiaan, tai ainakin se mahdollistaisi tämän. Tämä ei ole ollut yhtä selvästi näkyvissä ennen (vrt. olioperustaisuus tai hajautustekniikat). SOA mahdollistaa palveluekosysteemit (kuten niitä usein kutsutaan), jotka koostuvat palveluista, joilla omat liiketoimintaprosessit. Tällöin liiketoimintaprosessien ja niiden vaatimusten ymmärtäminen oleellista palveluiden toteuttamisessa. Osittain tämän vuoksi, kuten aiemmin mainittiin, oleellisena erona komponenttiteknologioihin verrattuna on se, että komponentteja tarkastellaan yleensä niiden rakenteen kannalta, kun taas palveluita tulisi tarkastella niiden tarjoaman toiminnallisuuden kannalta. Käsitteiden kanssa on syytä kuitenkin olla huolellinen: esim. palvelu ja arkkitehtuuri tarkoittavat eri asioita ohjelmistokehityksen ja liiketoiminnan näkökulmista. Myös esimerkiksi tehokkuudella ja uudelleenkäytöllä on eri implikaatiot: ohjelmistotekniikan kannalta nämä termit ovat tuttuja, mutta liiketoiminnan näkökulmasta näillä viitataan usein tehokkaaseen informaatiojärjestelmien hyödyntämiseen ja esim. kustannus-hyötytehokkuus analyyseihin. 12

14 Esimerkki taas vaikkapa jostain yrityksestä. Yrityksellä on laskutusjärjestelmä ja varastonhallintajärjestelmä, jotka ovat eri tahojen eri teknologioilla kehittämiä. Laskutusjärjestelmässä on tietokanta, joka sisältää asiakastiedot. Varastojärjestelmäkin tarvitsisi näitä tietoja, joten pitää tehdä jonkinlaista järjestelmien integraatiota. 13

15 Huono esimerkki 1: varastojärjestelmä lukee tiedot suoraan tietokannasta samaan tapaan kuin laskutusjärjestelmä. Ongelmana tässä on se, että järjestelmien välille tulee tarpeeton riippuvuus asiakastietokannan toteutuksesta. Nyt jos haluttaisiin vaikkapa vaihtaa tietokannan rakennetta tai tietokannanhallintajärjestelmää, niin muutoksia pitäisi tehdä myös varastonhallintajärjestelmään (ja kaikkiin muihin tietokantaa käyttäviin osiin). 14

16 Huono esimerkki 2: luodaan varastojärjestelmälle oma varastonhallinnan tarpeisiin räätälöity asiakastietokanta. Ongelma tässä on ensinnäkin se, että joudutaan tekemään osittain päällekkäisiä toteutuksia. Lisäksi tietokannat on jotenkin synkronoitava keskenään, joten edellisen esimerkinkään riippuvuusongelmilta ei vältytä. 15

17 Esimerkki palvelupohjaisesta integraatiosta. Jaetaan järjestelmä palveluihin, joilla on tarkasti määritelty toteutusriippumaton rajapinta. Yksi palvelu vastaa yhdestä loogisesta kokonaisuudesta. 16