Rajapintojen käyttö tiedonsiirrossa

Transkriptio

1 Rajapintojen käyttö tiedonsiirrossa Harri Pitkänen Pro gradu tutkielma Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede Joulukuu 2016

2 ITÄ-SUOMEN YLIOPISTO, Luonnontieteiden ja metsätieteiden tiedekunta, Joensuu Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede Opiskelija, Harri Pitkänen: Rajapintojen käyttö tiedonsiirrossa Pro gradu tutkielma, 63 sivua, 1 liite (2 sivua) Pro gradu tutkielman ohjaaja: FT Markku Tukiainen Joulukuu 2016 Tämä pro gradu tutkielma käsittelee rajapintojen käyttöä tiedonsiirrossa. Tutkielma sisältää rajapintojen yleistä teoriaa, sekä tarkemmat määrittelyt ohjelmointi- ja yhdistelmärajapinnoista. Teorian ohessa tuodaan myös esiin erilaisten rajapintojen käyttötarkoituksia, hyötyjä ja haittoja. Tutkielman virallinen tutkimuskysymys pyrkii selvittämään, mikä kolmesta valitusta rajapinnasta soveltuu parhaiten tiedonsiirtoon. Valitut rajapinnat ovat FTP-, SOAP- ja REST-rajapinta. Rajapinnan tiedonsiirron soveltuvuuteen vaikuttaa tässä tutkielmassa eniten tiedonsiirron nopeus. Vertailu on toteutettu testitapauksilla, joissa kaikilla vertailtavilla rajapinnoilla toteutetaan tiedonsiirtoja, sisällöltään ja määrältään vaihtelevilla aineistoilla. Avainsanat: rajapinta, tiedosto, tiedonsiirto, ohjelmisto, kommunikointi ACM-luokat (ACM Computing Classification System, 1998 version): C.0, C.2.0, D.2.2, D.2.11, H.3.

3 Lyhenneluettelo API Application Programming Interface COTS Commercial off-the-shelf FTP File Transfer Protocol HATEOAS Hypermedia as the Engine of Application State HTTP Hypertext Transfer Protocol IETF Internet Engineering Task Force MIT Massachusetts Institute of Technology NTP Network Time Protocol OSFA One-Size-Fits-All REST Representational state transfer SOAP Simple Object Access Protocol TCP Transmission Control Protocol W3C World Wide Web Consortium XML Extensible Markup Language

4 Sisällysluettelo 1 Johdanto Rajapintojen teoria Ohjelmointirajapinnat Ohjelmointirajapintojen määritelmä Ohjelmointirajapintojen käyttötarkoitukset Ohjelmointirajapintojen hyödyt Ohjelmointirajapintojen haitat Yhdistelmärajapinnat Yhdistelmärajapintojen määritelmä Yhdistelmärajapintojen käyttötarkoitukset Yhdistelmärajapintojen hyödyt Yhdistelmärajapintojen haitat Teoriaosan yhteenveto Vertailtavien rajapintojen tekninen kuvaus FTP-rajapinta SOAP-rajapinta REST-rajapinta Tutkimuskysymyksen esittäminen Vertailun toteutus Tulokset Testien luotettavuus ja toistettavuus Testitulosten esittäminen Johtopäätökset Tulosten analysointi Käytännön sovellukset Yhteenveto

5 1 JOHDANTO Rajapintoja on ollut käytössä niin pitkään kuin ohjelmistoilla ja laitteilla on ollut tarve kommunikoida keskenään. Rajapinnat ovat aiemmin olleet yleisiä laitteiden ja ohjelmistojen välillä, mutta nykyisin kahden ohjelmiston välinen rajapinta on hyvin yleinen tapa kommunikoida. Varsinkin verkon yli toimivat rajapinnat ovat yleistyneet verkkoteknologioiden kehittyessä ja verkossa toimivien palvelujen lisääntyessä. Tämä tutkielma käsittelee siis rajapintoja ja pyrkii selvittämään kolmesta ennalta valitusta rajapinnasta, mikä soveltuu parhaiten tiedonsiirtoon kahden palvelimen välillä. Vertailtaviksi valitut rajapinnat ovat FTP-, SOAP- ja REST-rajapinta. Vertailun toteutukseen on tässä tutkielmassa käytetty empiiristä tutkimusta, koska kyseinen tutkimusmenetelmä sopii hyvin rajapintojen tarkasteluun käytännönläheiseltä kannalta. Tutkielman rakenne on seuraava: Luku kaksi käy läpi rajapintojen ja yhdistelmärajapintojen teoriaa. Teoreettinen osio sisältää rajapintojen yleisen määrittelyn, esimerkkejä käyttötarkoituksista, sekä erilaisia hyötyjä ja haittoja. Luvussa kolme esitellään tutkielmassa vertailtavat rajapinnat. Kaikista rajapinnoista käydään läpi lyhyt kuvaus rajapinnan historiasta. Tämän lisäksi rajapinnoista esitetään teknisempi kuvaus niiden toiminnasta, sekä yleisesti tiedostettuja hyviä ja huonoja puolia. Luku neljä määrittelee ja rajaa tutkimuskysymyksen. Samalla esitellään tutkielmassa käytetyt tutkimusmenetelmät ja niiden luonteet. Luvussa viisi jatketaan tutkimuskysymykseen vastauksen tuottavien testitapausten esittelyllä. Testien asettelu ja toteutus on kuvattu mahdollisimman hyvin, pitäen mielessä tutkimuksen toistettavuus. Luvut kuusi ja seitsemän esittelevät testitapausten suorittamisesta saadut tulokset ja niistä tehdyt johtopäätökset. Johtopäätösten lisäksi vertailluista rajapinnoista 2

6 esitetään yleiset esimerkit tilanteista, joissa kyseiset rajapinnat olisivat mahdollisesti paras valinta ongelman ratkaisuun. Luku kahdeksan on yhteenveto, joka kasaa koko tutkielman yhdeksi tiiviiksi esitykseksi. Lisäksi käydään läpi omakohtaiset intressit rajapintojen tutkimiseen, sekä lopuksi mainitaan tutkielman pohjalta mahdollisesti tehtävistä jatkotutkimuksista. 3

7 2 RAJAPINTOJEN TEORIA Normaalisti ohjelmistojen välinen tietojen vaihtaminen pitää määritellä tarkasti ja ohjelmistokohtaisesti suunnitteluvaiheessa. Tämä johtaa tilanteeseen jossa muutosten tekeminen jo toteutettuihin ohjelmistoihin on työlästä. Muutokset pitää yleensä tehdä erikseen kaikkiin mukana oleviin ohjelmistoihin. Myös muut kuin ohjelmistojen kommunikointiin liittyvät muutokset voivat hankaloitua, koska muutoksia tehtäessä on aina otettava huomioon vaikutukset tietojen siirtoon muiden ohjelmistojen välillä. Tämän lisäksi uusien ohjelman osien lisääminen olemassa olevaan ohjelmistoon voi olla työlästä. Ohjelmointirajapintoja käytetään, koska ne helpottavat ohjelmistojen välistä kommunikointia ja sen suunnittelua. Käyttämällä ohjelmointirajapintaa, voidaan ohjelmistojen väliseen tietojen vaihtamiseen tehdä muutoksia helpommin ja uusien ohjelmistojen lisääminen olemassa olevaan järjestelmään on suoraviivaisempaa. Myöskään yksittäisen ohjelmiston sisällä tapahtuvat muutokset vaikuttavat harvemmin ohjelmointirajapinnan toimintaan. Ohjelmointirajapinnalla tarkoitetaan kahden tai useamman ohjelmiston välistä kommunikointikanavaa. Ohjelmointirajapinnat voidaan myös sulauttaa yhteen yhdistelmärajapinnaksi (API Mashup). Termi yhdistelmärajapinta ei ole vakiintunut, mutta tässä tutkielmassa sillä tarkoitetaan kahdesta tai useammasta rajapinnasta yhdisteltyä ohjelmointirajapintaa. Yleiset ohjelmointirajapinnat ovat yleistyneet viime vuosien aikana ja nykyään yhtiöt tarjoavatkin niitä asiakkaittensa käyttöön entistä laajempina. Osa ohjelmointirajapinnoista on maksullisia, osa ilmaisia ja joissakin perusominaisuudet ovat ilmaiset, mutta lisäominaisuuksista pitää maksaa. Esimerkiksi Googlen tarjoaman karttapalvelun ohjelmointirajapinta jakautuu ilmaiseen (Google Maps API) ja maksulliseen (Google Maps API for Work) versioon. Ilmaisversio ei sisällä kaikkia ominaisuuksia, sen käyttöä on rajoitettu ja 4

8 jotkut ominaisuuksista eivät ole niin tehokkaita. Maksullista versiota on myös pakko käyttää, jos ohjelmointirajapintaa käytetään kaupallisiin tarkoituksiin. Ohjelmistojen kehittäjät käytävät entistä useampia ohjelmointirajapintoja niiden yleistymisen myötä. Useiden ohjelmointirajapintojen käytön myötä on syntynyt tarve saada useampi ohjelmointirajapinta sovitettua yhdeksi kokonaisuudeksi, jolloin saadaan aikaan yksi yhtenäinen yhdistelmärajapinta. Teoriaosion rakenne on seuraava: Kohdassa 2.1 käydään ensin yleisellä tasolla läpi ohjelmointirajapintojen määrittely, jonka jälkeen tutustutaan erilaisiin käyttötarkoituksiin. Kohdan 2.1 lopussa käydään läpi, mitä hyötyjä ja haittoja ohjelmointirajapintojen käyttämisestä on. Kohta 2.2 käsittelee yhdistelmärajapintojen määrittelyä, käyttötarkoituksia ja hyötyjä. Tämän lisäksi luvussa käydään läpi mahdollisia haasteita ja haittoja, joita yhdistelmärajapintojen käytöstä voi aiheutua. Kohta 2.3 on teorian yhteenveto, johon on yhdistetty yleisimmät asiat ohjelmointi- ja yhdistelmärajapinnoista. Yhteenvedon lopuksi tehdään päätelmiä näiden molempien käytöstä. 2.1 Ohjelmointirajapinnat Tässä kohdassa käsitellään perinteisiä ohjelmointirajapintoja ja se on jaettu kolmeen alakohtaan. Alakohdissa käydään läpi seuraavia asioita, ohjelmointirajapinnan yleinen määritelmä, ohjelmointirajapintojen yleisimmät käyttötarkoitukset, ohjelmointirajapintojen käytöstä saavutetut hyödyt ja ohjelmointirajapintojen mahdolliset haitat. Ohjelmointirajapinta liittyy aina yhteen tai useampaan ohjelmistoon. Tästä syystä ohjelmointirajapintaa on vaikeahkoa määritellä yleisellä tasolla, liittämättä sitä edes johonkin tarkasteltavaan ohjelmistoon. Yleisesti ottaen ohjelmointirajapinta on määritelmä, joka mahdollistaa kahden tai useamman ohjelmiston keskisen 5

9 kommunikoinnin. Tätä määritelmää on ehkä helpompi ymmärtää tarkastelemalla luvussa esitettyjä käytännön esimerkkejä. Käyttötarkoitusten osalta tavoite on kuvailla, miten monipuolisesti ohjelmointirajapintoja voidaan käyttää ja esittää muutamia käytännön esimerkkejä. Kaikkien käyttötarkoitusten ja sovellusalueiden listaaminen on mahdotonta näin pienen mittakaavan kirjoitelmassa. Hyödyt osion tavoite on tuoda esille asioita, jotka tukevat ohjelmointirajapintojen käyttöä. Vastavuoroisesti haitat osiossa mainitaan ohjelmointirajapintojen käytöstä koituvia ongelmia Ohjelmointirajapintojen määritelmä Ohjelmointirajapinnan avulla voidaan kahden tai useamman ohjelmiston välille luoda yhteinen ja ehjä määritelmä, jonka mukaisesti kyseiset ohjelmistot voivat kommunikoida keskenään. Yhdysvaltalainen Software Engineering Institute (SEI) tarjoaa oman määritelmänsä ohjelmointirajapinnalle [1]: Ohjelmointirajapinta (API) on vanhempaa teknologiaa, joka helpottaa viestien- tai tiedonvaihtoa kahden tai useamman sovellusohjelman välillä. API on virtuaalinen rajapinta kahden yhteydessä olevan ohjelmiston, kuten tekstinkäsittely- ja taulukkolaskentaohjelman, toimintojen välillä. (...) Ohjelmointirajapinta on ohjelmisto, joka tukee monien kaupallisten "suoraan hyllyltä" ostettavien (COTS) ohjelmistotuotteiden tai vastikään kehitettyjen ohjelmistojen järjestelmätason integraatiota olemassa oleviin tai uusiin sovelluksiin. Kuten aiemminkin mainittiin ja sanan ohjelmointirajapinta osasta rajapinta voidaan päätellä, ovat ohjelmointirajapinnat rakenteita, jotka muodostuvat aina vähintään kahden eri sovellusohjelman välille. Esimerkiksi käyttöjärjestelmien 6

10 ohjelmointirajapinnat mahdollistavat ohjelmalle pääsyn käyttämään käyttöjärjestelmän sisäisiä resursseja, kuten tiedostojärjestelmää tai prosessienhallintaa [1]. Olio-ohjelmointikielissä, kuten Javassa, ohjelmointirajapinnaksi voidaan kutsua luokkien julkisten metodien ja rajapintaluokkien, sekä niihin liittyvien dokumenttien, kokonaisuutta. On hyvin yleistä, että sovelluksia, joiden välille ohjelmointirajapinta muodostuu, kehittävät toisistaan erilliset ryhmät [1]. Käyttötarkoituksesta riippuen ohjelmointirajapintojen julkisuus voi vaihdella. Pääasiallisesti ohjelmointirajapinnat voidaan jakaa julkisuuden perusteella kahteen eri ryhmään, joita ovat avoin ja suljettu. Myös näiden kahden ryhmän yhdistelmä on mahdollinen, jolloin tietty osa ohjelmointirajapinnasta on käytössä vain rajatulla määrällä käyttäjiä. Täysin suljetut ohjelmointirajapinnat ovat käytännössä yritysten sisäisesti käyttämiä tai niillä on toteutettu yritysten välistä toimintaa. Tällöin ohjelmointirajapintaa käytetään tehostamaan yrityksen toimintaa esimerkiksi hyödyntämällä aiemmin kehitettyjä järjestelmiä ja vähentämällä kehitykseen käytettävää aikaa. Myös sulautetuissa järjestelmissä ohjelmointirajapinnat ovat lähtökohtaisesti suljettuja. Avoimet ohjelmointirajapinnat ovat julkaistu vapaasti käytettäväksi ja yleensä kuka tahansa voi hyödyntää niitä haluamallaan tavalla. Avoimissakin ohjelmointirajapinnoissa on kuitenkin yleistä, että sen julkaissut yritys tai taho on asettanut käyttöä rajoittavan vastuuvapauslausekkeen. Tekemällä ohjelmointirajapinnasta yleisölle avoin, pyritään yleensä saavuttamaan hyötyä yhteisöön kuuluvien käyttäjien kehittämien ohjelmien ja ominaisuuksien muodossa. Kahden edellä mainitun julkaisutavan lisäksi on olemassa näiden kahden yhdistelmä. Osittain suljetussa ohjelmointirajapinnassa on osioita, joihin on käyttöoikeus vain tietyllä osalla käyttäjistä. Käyttöoikeuksia voidaan rajoittaa esimerkiksi tarjoamalla maksua vastaan ohjelmointirajapinnan palveluista kattavampia versioita tai kokonaan uusia palveluja. Näin saavutetaan samanaikaisesti avoimen ohjelmointirajapinnan tuomat edut ja mahdollistetaan tuottojen saaminen suljetun osan avulla. 7

11 Ohjelmointirajapinta voi olla yksisuuntainen tai toimia molempiin suuntiin. Yksisuuntaisissa ohjelmointirajapinnoissa vain toinen ohjelmisto-osapuoli lähettää kutsuja ja toinen vastaa kutsuihin. Molempiin suuntiin toimivissa ohjelmointirajapinnoissa molemmat ohjelmisto-osapuolet lähettävät ja vastaavat kutsuihin. Esimerkiksi Googlen tarjoaman karttapalvelun ohjelmointirajapinta on yksisuuntainen rajapinta, koska siinä palvelua käyttävät ohjelmistot lähettävät kutsuja ja palvelu ainoastaan vastaa ohjelmistojen kutsuihin. Molempiin suuntiin toimiva ohjelmointirajapinta voi olla esimerkiksi pikaviestintäohjelman viestien välittämisen toteutus, jossa molemmat osapuolet lähettävät kutsuja ja vastaavat niihin. Yksisuuntaisissa ohjelmointirajapinnoissa toiminta on yleensä keskittynyt niin, että kutsuihin vastaavia osapuolia on yksi ja kutsuja lähettäviä osapuolia useita. Tällöin kutsuja vastaanottava osapuoli toimii palvelimena ja kutsuja lähettävät osapuolet asiakkaina. Tämän vastakohta, eli yksi kutsuja lähettävä osapuoli ja useita palvelevia osapuolia on huomattavasti harvinaisempi. Molempiin suuntiin toimivat ohjelmointirajapinnat ovat hyvin usein yksityisiä. Yleisimmin kaksisuuntaista ohjelmointirajapintaa käytetään kun monta yritystä tarvitsee kommunikointikanavan ohjelmistojensa välille. Toinen yleinen käyttötarkoitus molempiin suuntiin toimivasta ohjelmointirajapinnasta löytyy sulautetuista järjestelmistä. 8

12 Kuva 1. Ohjelmointirajapinnat toimivat liitoskohtina eri laitteiden välillä. Monet suuremmat julkiset ohjelmointirajapinnat ovat yksisuuntaisia. Tyypillinen esimerkki tämän tyylisestä ohjelmointirajapinnasta on jonkun yrityksen tarjoama verkossa toimiva ohjelmointirajapinta. Käyttäjät voivat suorittaa kutsuja yrityksen ohjelmointirajapintaan käyttäen erillistä asiakassovellusta. Asiakassovellus on siis ohjelma, jota hyödyntämällä voidaan tehdä ohjelmointirajapintaan kutsuja eli käyttää kyseistä palvelua. Esimerkiksi suoratoistopalvelu Twitch tarjoaa julkisen ohjelmointirajapinnan, jota hyödyntämällä on toteutettu useita asiakassovelluksia, useille eri käyttöjärjestelmille. Näin toimivat myös Twitterin molemmat julkiset ohjelmointirajapinnat (Twitter REST API ja Search API). Sen lisäksi että ohjelmointirajapinnat voivat toimia yksisuuntaisesti tai molempiin suuntiin, voidaan niiden sisältämät metodikutsut jaotella kahteen eri ryhmään pyyntö (PULL) ja työntö (PUSH). Pyyntö-tyypin metodikutsut pyytävät kohde ohjelmointirajapintaa suorittamaan jonkun toiminnon ja antamaan vastauksen, joka usein sisältää pyydettyjä tietoja. Työntö-tyypin metodikutsut lähettävät tietoja kohde ohjelmointirajapintaan, joka suorittaa tietojen pohjalta toimintoja ja antaa kutsun 9

13 lähettäneelle ohjelmalle yleisimmin vastauksena ainoastaan tiedon suoritettujen toimintojen onnistumisesta. Ohjelmointirajapinnoille, varsinkin julkisille, on myös tyypillistä, että yksi sen kerroksista tehdään abstraktiksi. Kyseisen kerroksen toiminnot määritellään siten, että niiden parametrit ja palautusarvot pysyvät mahdollisimman muuttumattomina julkaisun jälkeen. Jos toiminto on vielä kehityksen alla ja sen parametreihin tai palautusarvoon voi tulla muutoksia, on tämä tärkeää mainita ohjelmointirajapinnan määrittelyssä. Näin ollen ohjelmistokehittäjä tietää, että hänen ohjelmistonsa, joka käyttää ohjelmointirajapinnan vielä kehityksen alla olevia toimintoja, toiminnallisuus voi muuttua tai jopa lakata toimimasta Ohjelmointirajapintojen käyttötarkoitukset Pääsiallinen ohjelmointirajapintojen käyttötarkoitus on mahdollistaa tehokas tapa toteuttaa tiedonvaihto kahden tai useamman ohjelmisto-osapuolen välillä. Tehokkuuden lisäksi ohjelmointirajapinnat pyritään suunnittelemaan niin, että niiden ylläpito ja jatkokehitys ovat vaivattomasti hoidettavissa Määritelmän piilottaminen Yksi yleisimmistä ohjelmointirajapinnan käyttötarkoituksista on piilottaa ohjelmiston määritelmä ja toteutus, eli miten eri ohjelmat ja niiden osat liittyvät toisiinsa tai mitä yksittäiset ohjelmakutsut pitävät sisällään, käyttäjältä. Näin toimimalla voidaan ohjelmistokehitykseen liittyvät työt jakaa osiin, joka on yleistä tietotekniikan toimialalla. Samaa mallia voidaan hyödyntää myös hajautetussa ohjelmistokehityksessä ja sitä pidetäänkin laajalti ainoana skaalautuvana tapana kehittää järjestelmiä erillisistä, osittain itsenäisistä, komponenteista [2]. Piilottamalla ohjelmiston määritelmä ja toteutus, mutta tarjoamalla silti toiminnallisuus, voidaan ohjelmointirajapintoja hyödyntää tehokkaasti ohjelmistokehityksessä. Tällöin on vaivattomampaa ottaa ohjelmiston kehittämiseen mukaan kolmansia osapuolia. Koko ohjelmiston toteutusta ei tarvitse paljastaa, vaan kolmas osapuoli voi toimia ja suorittaa oman osansa ohjelmointirajapinnan 10

14 tarjoamien toimintojen avulla. Tämä helpottaa myös kolmannen osapuolen työskentelyä, koska sen sijaan että heidän täytyisi käydä läpi ja sisäistää koko ohjelmisto, heille riittää ohjelmointirajapintaan perehtyminen. Joissain tapauksissa piilottamista voidaan käyttää myös yrityksen sisäisessä ohjelmistotuotannossa. Oikein toteutettuna, toteutuksen piilottaminen suuremmalta joukolta työntekijöitä, parantaa ylläpidettävyyttä ja vähentää tarvetta ohjelmiston testaamiselle Liitännäisten käyttö Eräs ohjelmointirajapintojen hyödyllisimmistä käyttötarkoituksista on uusien ominaisuuksien kehittämisen tukeminen. Hyödyntämällä ohjelmistoon kuuluvan ohjelmointirajapinnan tarjoamia palveluja, voidaan luoda kokonaan uutta toiminnallisuutta tai muuttaa olemassa olevan toiminnon käyttäytymistä. Tällaista uutta ominaisuutta kutsutaan yleisesti liitännäiseksi (plugin). Liitännäiset toimivat ainoastaan liitettynä johonkin isäntäsovellukseen, jonka ohjelmointirajapinnan tarjoamat palvelut mahdollistavat liitännäisen toiminnan. Ilman isäntäsovellusta toimivat liitännäiset eivät lähtökohtaisesti ole enää liitännäisiä vaan itsenäisiä ohjelmia, joilla on mahdollisuus liittyä toiseen sovellukseen tämän ohjelmointirajapinnan kautta. Esimerkiksi verkkoselaimeen voidaan kehittää liitännäisiä, jotka mahdollistavat eri muotoihin pakattujen videotiedostojen katselun. Käyttämällä liitännäisiä voidaan mahdollistaa ohjelmiston ominaisuuksien hajauttaminen pienemmiksi helpommin hallittaviksi kokonaisuuksiksi, joita voidaan tarpeen mukaan lisätä tai poistaa isäntäsovelluksesta. Joissakin tapauksissa liitännäinen voidaan jopa ottaa käyttöön ilman isäntäsovelluksen uudelleenkäynnistämistä. Kun käytetään liitännäisiä, on tärkeää muistaa niiden riippuvuus isäntäsovelluksen ohjelmointirajapinnasta. Jos isäntäsovellukseen tai sen ohjelmointirajapintaan tulee muutoksia, on mahdollista, että liitännäinen tai jokin sen osa voi toimia väärin tai lopettaa kokonaan toimintansa. Näihin muutoksiin voidaan osittain varautua 11

15 jättämällä myös aiemmat ohjelmointirajapinnan palvelut saataville, ainakin siksi aikaa että liitännäisten kehittäjät ehtivät päivittää liitännäiset tukemaan uudempaa versiota ohjelmointirajapinnasta. Aina tämä ei kuitenkaan ole mahdollista, joten myös liitännäisten olisi hyvä varautua muutoksiin käyttämässään ohjelmointirajapinnassa, esimerkiksi ilmoittamalla päivitystarpeesta ja sulkemalla itsensä hallitusti Pilvipalvelut Nykyaikana erilaiset sähköiset palvelut tarjoavat valtavan määrän dataa joka päivä miljoonille käyttäjille. Kyseinen data voi olla mitä tahansa sähköistä materiaalia esimerkiksi videoita, kuvia, tekstiä, äänitiedostoja tai ohjelmia. Riippumatta datan sisällöstä, on näillä sähköisillä materiaaleilla yksi yhteinen tekijä, niiden täytyy olla tarjolla käyttäjälle jonkin yhteyden kautta. Perinteinen ratkaisu sähköisen median jakeluun käyttäjälle on varastoida se datakeskukseen. Datakeskukset ovat palvelinkeskittymiä, joissa suuria määriä laitteita on yhdistetty säilyttämään, käsittelemään ja tarjoamaan valtavia määriä tietoa. Ajan myötä datamäärät ovat kuitenkin kasvaneet ja datakeskuksien ongelmaksi nousee kapasiteetin riittämättömyys. Toinen merkittävä ongelma on päätelaitteiden alati kasvava kirjo. Datakeskuksen tulee pystyä tarjoamaan sisältönsä useiden eri laitteiden ja ohjelmistojen vaatimusten mukaan, joka kasvattaa ylläpidettävien ohjelmistojen määrää. Pelkästään kapasiteettia kasvattamalla ongelmia ei ole järkevää lähteä ratkaisemaan, koska kustannukset nousevat nopeasti kun tarvitaan suuria määriä lisää fyysistä tilaa, laitteita ja henkilökuntaa. Ongelmaksi voi myös muodostua tarve toimia maailmanlaajuisesti tai fyysisen järjestelmän heikkoudet, esimerkiksi laajat sähkökatkokset. Ohjelmointirajapintoja hyödyntämällä voidaan sähköisten materiaalien säilytys, käsittely ja käyttäjälle tarjoaminen siirtää pois datakeskuksesta ja sijoittaa pilveen. Pilven avulla päästään eroon datakeskuksen skaalautumisongelmasta sekä mahdollisista fyysisistä heikkouksista. Samalla mahdollistetaan helpommin 12

16 maailmanlaajuinen toiminta. Myös päätelaitteiden toisistaan eroavuuden tuottamat ongelmat pystytään minimoimaan ohjelmointirajapintojen avulla. Normaalisti päätelaite pyytää ohjelmistollaan datakeskuksen vastaavalta ohjelmistolta tietoa haluamassaan muodossa. Pilvessä toimiessa kaikkien päätelaitteiden pyynnöt voidaan ohjata yhteen ohjelmointirajapintaan. Tämä ohjelmointirajapinta hoitaa pyynnöt eteenpäin oikeaan paikkaan riippuen päätelaitteesta ja antaa vastauksen halutussa muodossa. Näin ollen itse palvelua voidaan kehittää, kunhan ohjelmointirajapinta pidetään eheänä. Myös eri päätelaitteille kehitettävien ohjelmistojen määrä laskee ja kehitys nopeutuu. Kuva 2. Netflix siirtyi OSFA-mallin ohjelmointirajapinnasta uuteen kerroksittaiseen malliin. Esimerkkinä Netflix on yksi ensimmäisistä suurista yhtiöistä, joka on siirtänyt toimintansa datakeskuksesta pilveen. Samalla Netflix on vaihtanut perinteisen onesize-fits-all (OSFA) -tyyppisen ohjelmointirajapintansa uuteen, paremmin muokattavissa olevaan malliin. Uuden mallin mukaisessa ohjelmointirajapinnassa on päällä sovitinkerros (adapter), joka hoitaa päätelaitteiden kutsut oikeaan paikkaan ja antaa vastaukset halutussa muodossa [3]. 13

17 Yritysten väliseen kommunikointiin Kuten kohdassa 2.1 mainittiin, suljetut ohjelmointirajapinnat ovat käytännössä yritysten sisäisessä käytössä tai niillä hoidetaan yritysten välistä toimintaa. Ohjelmointirajapintojen käyttö yritysten bisneslogiikkojen välisessä kommunikoinnissa luo haasteita ja myös ongelmia ratkaistavaksi. Kuitenkin oikein käytettynä ohjelmointirajapinta voi mahdollistaa sellaisia asioita tai toimintatapoja, joiden kehittämiseen tai toteuttamiseen tarvittavat kustannukset olisivat muuten liian suuret. Esimerkkinä kustannusten minimoinnista voidaan ajatella yritystä, jonka data tarvitaan jatkuvasti eri yritysten saataville. Jos kyseinen yritys kehittää aina uuden ohjelmiston datan siirtoa varten jokaista uutta dataa tarvitsevaa yritystä kohden, niin kustannukset kasvavat uusien ohjelmistojen myötä. Datan tarjoaminen sitä tarvitsevien yritysten saataville käyttämällä ohjelmointirajapintaa, säästää huomattavasti ohjelmistokehityksen kustannuksissa. Yksi ongelma kahden tai useamman yrityksen välisen ohjelmointirajapinnan luomisesta muodostuu tietoturvan varmistamisesta. Vaikka kyseessä ei ole julkinen kaikille avoin ohjelmointirajapinta, on silti mahdollista, että sen avulla joku ulkopuolinen taho pääsee käsiksi yhden tai useamman mukana olevan yrityksen tietoihin. Näin voi tapahtua, jos ohjelmointirajapinta tarjoaa pääsyn kyseisiin tietoihin ja jonkun mukana olevan yrityksen tietoturvataso on riittämätön. Tällöin joku ulkopuolinen voi ensin tunkeutua heikoiten suojatun yrityksen järjestelmään ja ohjelmointirajapintaa käyttäen päästä käsiksi kaikkien sitä käyttävien yritysten tietoihin. Jos tietoturva asiat ovat kunnossa, niin ohjelmointirajapinnan avulla voidaan vastaavasti saavuttaa yksi huomattavan suuri hyöty verrattuna perinteisiin, suoria datayhteyksiä käyttäviin ohjelmistoihin. Normaalisti yritysten väliset ohjelmistot ovat sidottuja käyttämään samoja tai ainakin samantyyppisiä ohjelmointikieliä ja tietorakenteita. Kun käytetään ohjelmointirajapintoja, voivat kaikki samaan järjestelmään liittyvät yritykset tuottaa omat ohjelmistonsa haluamillaan 14

18 ohjelmointikielillä. Kaikilla yrityksillä voi tämän lisäksi olla käytössä täysin erilaiset tietokannat ja muut oheisjärjestelmät. Kuva 3. Järjestelmä, jossa useita eri ohjelmointikieliä käyttäviä yrityksiä yhteydessä toisiinsa rajapinnan välityksellä. Eri ohjelmointikielet ja oheisjärjestelmät eivät vaikuta toistensa toimintaan, koska niillä ei ole tietoa toisistaan. Ohjelmistojen liittymäkohdat ovat yhteydessä toisiinsa ohjelmointirajapinnan kautta, joka on kaikille ohjelmistoille yhteinen. Tämä lähestymistapa mahdollistaa myös uusien yritysten tuomisen mukaan järjestelmän kehitykseen, ilman mittavia muutoksia mukaan tulevan yrityksen ohjelmistoihin Sulautetut järjestelmät Sulautetut järjestelmät ovat laitteita tai laitekokonaisuuksia, jotka ovat tietokoneohjattuja. Ennen varsinaisia sulautettuja järjestelmiä, piti tietokoneen nykyisin hoitamat ohjaustehtävät hoitaa automatiikkaa ja erityisiä elektroniikan komponentteja käyttäen [4]. 15

19 Edelleenkin on hyvin yleistä, että sulautetut järjestelmät ovat suljettuja. Tämä tarkoittaa sitä että sulautettuun järjestelmään valitaan jo suunnitteluvaiheessa laitteisto ja sitä ohjaava ohjelmisto, joiden avulla järjestelmä pystyy suoriutumaan sille tarkoitetusta tehtävästä parhaalla mahdollisella tavalla. Esimerkkejä tällaisista järjestelmistä ovat pankkiautomaatit, ajotietokoneet ja kodinkoneet kuten mikroaaltouunit. Sulautetut järjestelmät ovat kehittyneet nopeasti, sitä mukaa kun tietokoneet ja prosessorit ovat kehittyneet. Nykyäänkin on kuitenkin yleistä, ettei sulautettuun järjestelmään pysty jälkikäteen lisäämään uusia ohjelmistoja. Tämä tarkoittaa yleensä kolmannen osapuolen ohjelmistoja, joiden toiminta poikkeaa alkuperäisen sulautetun järjestelmän ohjelmiston toiminnasta. On kuitenkin normaalia, että tällaisiin sulautettuihin järjestelmiin on mahdollista asentaa valmistajan tai ylläpitävän tahon ohjelmistopäivityksiä. Uudemmat sulautetut järjestelmät mahdollistavat kolmannen osapuolen ohjelmistojen liittämisen järjestelmään ohjelmointirajapinnan avulla. Yhden laitekategoria tällaisista sulautetuista järjestelmistä muodostavat mobiililaitteet. Esimerkiksi matkapuhelimet ovat jo useita vuosia olleet suurimmaksi osaksi älypuhelimia, joissa käyttäjä ohjaa toimintaa säätelevää tehokasta tietokonetta käyttöjärjestelmän avulla. Matkapuhelimien käyttöjärjestelmät ovat kattavia kokonaisuuksia, joilla saavutetaan kaikki valmistajan suunnittelemat toiminnallisuudet. Yleensä suurin osa toiminnallisuuksista, esimerkiksi soittaminen tai tekstiviestin lähetys, hyödyntävät jotain käyttöjärjestelmän tarjoamaan ohjelmointirajapintaa. Kyseiset ohjelmointirajapinnat ovat monesti myös tarjolla kolmannen osapuolen ohjelmistokehittäjille. Tämä mahdollistaa uusien ohjelmien kehittämisen. Uudet ohjelmat ovat usein paranneltuja versioita valmistajan alkuperäisistä, jolloin alkuperäiseen ohjelmaan tuodaan lisäarvoa uusilla ominaisuuksilla, ohjelman ulkoasua muokkaamalla tai liittämällä siihen toisia ohjelmia. 16

20 Hyvä esimerkki kolmannen osapuolen ohjelmasta matkapuhelimissa on pikaviestintä. Lähtökohtaisesti matkapuhelinten alkuperäiset ohjelmat tarjoavat tekstiviestien ja sähköpostien vastaanottamisen ja lähettämisen omina ohjelminaan. Tämän lisäksi on useita kolmannen osapuolen ohjelmia, joiden avulla käyttäjä voi kommunikoida toisten samaa ohjelmaa käyttävien kanssa. Nämä ohjelmat käyttävät matkapuhelimen ohjelmointirajapintaa toimintaansa ja sen avulla on myös mahdollista luoda ohjelmia, jotka yhdistävät monen ohjelman toiminnan yhteen. Kuva 4. Matkapuhelimen toiminnan ohjaamisen mahdollistava ohjelmointirajapinta. Avoimien ohjelmointirajapintojen yleistyminen sulautetuissa järjestelmissä muodostaa paljon tietoturvaongelmia. Yleisesti ottaen sulautetun järjestelmän valmistaja ei voi estää väärinkäytöksiä, vaan käyttäjän tulee olla tietoinen mihin ohjelmointirajapinnan osiin hän antaa pääsyn kolmannen osapuolen ohjelmalle. Esimerkiksi käyttäjä voi tietämättään tai vahingossa sallia jollekin kolmannen osapuolen ohjelmalle oikeudet tiedustella matkapuhelimensa paikkatietojärjestelmältä sijaintia tai antaa osoitekirjansa vapaasti luettavaksi. 17

21 2.1.3 Ohjelmointirajapintojen hyödyt Ohjelmointirajapintojen käytöstä hyötyvät lähtökohtaisesti kaikki osapuolet. Ohjelmointirajapinnan tarjoavien tahojen hyödyt liittyvät pääsääntöisesti ohjelmistojen ylläpitoon ja kehittämiseen. Ohjelmointirajapinnan tarjoamien palveluiden käyttäjien suurin etu on tietysti siinä, että heillä on ylipäätään mahdollisuus käyttää kyseisen ohjelmointirajapinnan palveluita Ylläpidettävyys ja kehitettävyys Ohjelmointirajapinnan abstraktia kerrosta kuvaa parhaiten testauksesta tuttu musta laatikko malli. Kyseisen mallin mukaan on tiedossa, mitä laatikon sisälle menee ja mitä sieltä tulee ulos, mutta laatikon sisällä tapahtuvista asioista ei tiedetä. Näin ollen ohjelmointirajapintaa käyttävä ohjelmistokehittäjä voi keskittyä toimimaan selvien metodikutsujen kanssa miettimättä erikseen, miten metodikutsun parametreja ja muita tietoja käyttämällä saadaan aikaan palautusarvo. Pitämällä ohjelmointirajapinnan käyttäjälle näkyvän kerroksen abstraktina, eli esittämällä ainoastaan korkeamman tason rakenteen ohjelman toiminnasta, voidaan saavuttaa hyvä ylläpidettävyys ja paremmat jatkokehitysmahdollisuudet. Esimerkiksi ohjelmointirajapinnan käyttäjää ei välttämättä kiinnosta, mitä tietokantaa hänen suorittamansa kutsu käyttää tai miten kyseinen tietokantahaku on toteutettu. Käyttämällä abstraktia kerrosta, ohjelmistokehittäjän ei siis tarvitse tietää ohjelmointirajapinnan sisällä tapahtuvasta toiminnasta. Ohjelmistokehittäjän tiedossa ovat vain ohjelmointirajapinnan metodikutsut, niiden tarvitsemat parametrit ja tuottamat palautusarvot. Tällöin ohjelmointirajapinnan sisällä tapahtuviin toimintoihin on mahdollista tehdä myös sellaisia muutoksia, että ohjelmointirajapintaa käyttävät ohjelmistot eivät häiriinny. Ohjelmointirajapintaan voidaan lisätä uusia sisäisiä toimintoja tai aiempia ominaisuuksia voidaan kehittää vapaasti, mutta tehtävien muutosten vaikutus abstraktin kerroksen toimintaan pitäisi pyrkiä pitämään minimissä. 18

22 Riippumattomuus alustasta tai ohjelmointikielestä Käyttämällä ohjelmointirajapintaa ohjelmiston kehittämisessä voidaan välttää tarve yhden ja saman ohjelmointikielen käyttöön. Näin toimimalla voidaan esimerkiksi uudet laajennukset ohjelmistoon toteuttaa mahdollisesti aiemmasta poikkeavalla ohjelmointikielellä tai käyttää kolmannen osapuolen kehittäjiä, jotka käyttävät kehitettävän ohjelman toteutuksesta poikkeavaa ohjelmointikieltä. Ohjelmointirajapinta mahdollistaa myös ohjelmiston palveluiden tarjoamisen eri alustoille, ilman erillistä tarvetta mittaville kehitystöille jokaisen eri alustan kohdalla Ohjelmointirajapintojen haitat Ohjelmointirajapintojen käyttämisestä voi seurata myös haittoja. Tämä on erityisesti todennäköistä, jos ohjelmointirajapintaa ei ole suunniteltu ja toteutettu huolellisesti tai sen käyttötarkoitus on määritelty epäselvästi Tietoturvan heikentyminen Yksi suurimmista ohjelmointirajapinnan käytön haitoista on sen heikentävä vaikutus ohjelmiston tietoturvaan. Normaalisti ohjelmistot ovat suljettuja kokonaisuuksia, joiden toiminnallisuus ja rakenne ovat käyttäjältä täysin piilotettuina. Ohjelmointirajapinta paljastaa ohjelmiston toiminnallisuutta käyttäjälle tarjoamalla erilaisia palveluita. Tutkimalla ohjelmointirajapinnan tarjoamia palveluita, on mahdollista joissain tapauksissa myös takaisinmallintaa ohjelmiston rakenne. Ohjelmiston toiminnallisuuden ja rakenteen esillä oleminen altistavat sen helpommin erilaisten hyökkäysten kohteeksi. Kyseiset hyökkäykset voivat olla luonteeltaan esimerkiksi ohjelmiston toiminnan estäviä tai pahemmassa tapauksessa ne paljastavat ohjelmiston sisältämän informaation ulkopuolisille tahoille Toiminnallisuuden menettäminen Ohjelmointirajapintoja käyttäessä tulee aina muistaa, että ne tarvitsevat ylläpitoa siinä missä muutkin ohjelmistot. Jos ohjelmointirajapinta tai osa sen tarjoamista 19

23 palveluista lakkaa toimimasta, voi se pahimmassa tapauksessa johtaa sitä käyttävien ohjelmistojen toiminnan lakkaamiseen. Tilanteet, jotka voivat johtaa ohjelmointirajapintaa käyttävän ohjelmiston toiminnan muuttumiseen tai lakkaamiseen ovat pääsääntöisesti seuraavat: 1. Ohjelmointirajapintaan on tehty muutoksia, jolloin sen palvelut eivät toimi enää kuten ohjelmisto olettaa, näin voi käydä esimerkiksi kun ohjelmointirajapinnan palveluiden syöteparametreja muutetaan [5]. 2. Ohjelmointirajapinnan tekemiseen käytetyt ohjelmistokirjastot tai muut siihen liittyvät ohjelmistot vanhenevat, jolloin ohjelmointirajapinnan toiminta heikkenee tai lakkaan kokonaan. 3. Ohjelmiston, johon liittyneenä ohjelmointirajapinta toimii, ylläpito lopetetaan kokonaan ja lopulta se suljetaan. Ohjelmiston toiminnan lakatessa, myös siihen liittyvät ohjelmointirajapinnat lakkaavat toimimasta. 2.2 Yhdistelmärajapinnat Tässä kohdassa käsitellään yhdistelmärajapintoja ja se on jaettu kolmeen alakohtaan. Alakohdissa käydään läpi seuraavia asioita, yhdistelmärajapinnan määritelmä, yhdistelmärajapintojen yleisimmät käyttötarkoitukset, yhdistelmärajapintojen käytöstä saavutetut hyödyt ja yhdistelmärajapintojen mahdolliset haitat. Yhdistelmärajapinnat ovat ohjelmointirajapintoja, jotka koostuvat useista ohjelmointirajapinnoista. Kuten yksittäiset ohjelmointirajapinnat, myös yhdistelmärajapinnat liittyvät yhteen tai useampaan ohjelmistoon. Tämän johdosta myös yhdistelmärajapintoja on vaikea määritellä kovin yleisellä tasolla ja määrittely onkin helpompaa tehdä liittämällä yhdistelmärajapinta johonkin oikeaan tai konkreettiseen ohjelmistoon. Alakohdassa esitetään yhdistelmärajapintojen käyttötarkoituksia esimerkkien avulla, jotka osaltaan helpottavat yhdistelmärajapinnan käsitteen ymmärtämistä. 20

24 Yhdistelmärajapinnat ovat suhteellisen uusi ilmiö. Siitä huolimatta, että niiden käyttö on lisääntynyt, ei niitä ole vielä tutkittu kovin kattavasti. Vaikka erilaisten yhdistelmärajapintojen kirjo on vielä suppea, niin on kaikkien eri käyttötarkoitusten ja sovellusalueiden esitteleminen tässä kirjoitelmassa mahdotonta. Käytännön esimerkit keskittyvätkin yleisimpiin käyttötarkoituksiin, joilla pyritään antamaan mahdollisimman kattava kuva mahdollisista sovellusalueista. Hyödyt-osio pyrkii kokoamaan yhteen syitä yhdistelmärajapintojen käyttämiseen. Vastaavasti haitat-osiossa käsitellään ongelmia, joita yhdistelmärajapintojen käyttämisestä voi seurata Yhdistelmärajapintojen määritelmä Yksinkertaisimmillaan yhdistelmärajapinta pyrkii yhdistämään kahdesta tai useammasta ohjelmointirajapinnasta tai niiden osista yhden kokonaisuuden. Syntyneen yhdistelmärajapinnan tarkoitus on mahdollistaa kaikkien mukana olevien ohjelmointirajapintojen oleellisimpien palveluiden käyttäminen yhdellä kertaa [6]. Pääasiallisesti yhdistelmärajapinta pyrkii tuomaan yhteen kerättyjen ohjelmointirajapintojen palveluihin lisäarvoa. Tämä tapahtuu helpoiten esimerkiksi yhdistämällä useamman tyyppistä tietoa yhteen palvelupyyntöön [7]. Yhdistelmärajapintoja voidaan jaotella kategorioihin monella eri tavalla. Yksi tapa jaottelun tekemiseen on jakaa yhdistelmärajapinnat kahteen eri kategoriaan loppukäyttäjän näkökulmasta riippuen. Nämä kaksi kategoriaa ovat palvelu- ja ulkoasukeskeiset yhdistelmärajapinnat [7]. Palvelukeskeiset yhdistelmärajapinnat toimivat yhdistelemällä eri sovelluksia ja tietolähteitä yhdeksi kokonaisuudeksi, joka näyttäytyy käyttäjälle itsenäisenä sovelluksena. Tämäntyyppinen loppukäyttäjälle suunnattu sovellus pyrkii tekemään alkuperäisten sovellusten tunnistamisesta vaikeampaa ja ennen kaikkea tarpeetonta. Tavoite on luoda uusi ja parempi käyttäjäkokemus integroimalla sovelluksia, ei pelkästään liimata sovelluksia toisiinsa [7]. 21

25 Ulkoasukeskeiset yhdistelmärajapinnat ovat yleensä graafisia elementtejä, joihin on yhdistetty eri sovelluksia ja tietolähteitä. Yleisin ilmenemismuoto tämän kaltaiselle yhdistelmärajapinnalle on yksi yleisnäkymä, johon tuodaan tietoa erilaisten widgettien avulla. Koska eri sovelluksia ja tietolähteitä ei ole yritettykään piilottaa käyttäjältä, ovat alkuperäiset sovellukset yleensä tunnistettavissa [7]. Toinen mahdollinen tapa yhdistelmärajapintojen kategorisointiin löytyy teknisestä näkökulmasta katsottuna. Teknisin perustein yhdistelmärajapinnat voidaan jakaa neljään eri kategoriaan, jotka ovat palvelu-, tieto-, työväline- ja risteymätyyppiset yhdistelmärajapinnat [7]. Palvelutyyppisiin yhdistelmärajapintoihin kuuluvat kaikki palveluita yhteen integroivat rajapinnat. Tietotyyppiset yhdistelmärajapinnat koostuvat rajapinnoista, jotka yhdistelevät eri tietolähteitä. Työvälinetyyppiset yhdistelmärajapinnat ovat vastaavia palvelutyyppisten kanssa, mutta ne pohjautuvat loppukäyttäjällä sijaitsevissa sovelluksissa tapahtuvaan tietojen yhdistämiseen. Risteymätyyppiset yhdistelmärajapinnat koostuvat aiemmin mainittujen yhdistelmistä [7] Yhdistelmärajapintojen käyttötarkoitukset Yhdistelmärajapinnat pyrkivät siis yhdistämään yhden tai useamman ohjelmointirajapinnan tarjoamia palveluita ja tietolähteitä yhdeksi kokonaisuudeksi, joka voi myös joissain tapauksissa tarkoittaa täysin uuden ja itsenäisen sovelluksen syntymistä. Tässä luvussa käydään läpi kaksi yhdistelmärajapinnan yleisimmistä käyttötarkoituksista Ohjelmointirajapintojen uudelleenkäyttö Nykyaikana on yleistä, että ohjelmistot pyritään kehittämään mahdollisimman modulaarisiksi, eli hajauttamaan eri toiminnallisuudet omiksi pienemmiksi kokonaisuuksikseen. Näitä pienempiä kokonaisuuksia, niin sanottuja moduuleja, yhdistelemällä saadaan lopputuloksena aikaan ohjelmisto, joka on tarkoitettu loppukäyttäjää varten. 22

26 Modulaarinen kehitystapa hyötyy huomattavasti ohjelmointirajapintojen käytöstä. Eri kehittäjät voivat toimia jokainen oman moduulin parissa, mutta he pystyvät silti käyttämään yhtä yhteistä ohjelmointirajapintaa, joka tuottaa kaikkien moduulien tarvitsemia palveluita tai tietoja. Kun ohjelmointirajapinta on kerran kehitetty hyvin, niin sitä pystytään hyödyntämään aina kun sen tarjoamia palveluita tarvitaan toisten ohjelmiston osien kehittämiseen. Yhdistelmärajapinnat hyödyntävät kyseistä ohjelmointirajapintojen uudelleenkäytettävyyttä ja vievät sen vielä pidemmälle yhdistelemällä useampia ohjelmointirajapintoja yhteen. Yhdistelmärajapinnan käyttämisen etuna on se, ettei kehittäjän tarvitse erikseen liittää ohjelmistoaan aiempiin olemassa oleviin ohjelmistoihin, vaan liitosten mahdollistavat toiminnot ovat jo toteutettu mukana olevissa ohjelmointirajapinnoissa. Toinen etu saavutetaan vähentyneenä testauksen tarpeena, koska ohjelmointirajapintojen tarjoamien palveluiden sisällöstä vastaavat ohjelmistot ovat lähtökohtaisesti testattuja ja ylläpidettyjä [8] Eri tietolähteiden yhdistäminen Yhdistelmärajapinnat pyrkivät ottamaan tietoa kahdesta tai useammasta lähteestä ja yhdistämään nämä keskenään. Esimerkkinä kyseisestä tilanteesta voidaan tarkastella säätietojen ja karttapalvelun yhdistämistä. Tällaisessa tilanteessa yleensä yksi ohjelmointirajapinta tarjoaa karttapalvelun, joka esittää käyttäjälle normaalisti vain karttoja ja sijaintitietoja. Muut ohjelmointirajapinnat tarjoavat säätietoja. Tämän jälkeen säätiedot vielä liitetään kartalle, niiden mukana tulevien paikkatietojen avulla. Kun nämä ohjelmointirajapinnat yhdistetään, saadaan aikaan yhdistelmärajapinta, jonka avulla voidaan esittää säätietoja kartalla [6]. 23

27 Kuva 5 Esimerkki säätietojen ja karttapalvelun yhdistämisestä ( Kuvan 5 esimerkissä samaan palveluun on liitetty Googlen karttapalvelu (Google Maps JavaScript API) ja OpenWeatherMapin säätietopalvelu (OpenWeatherMap API). Lopputuloksena saadaan ulkonäöltään Googlen karttapalvelun näköinen karttasovellus, joka tarjoaa myös säätietoja. [9, 10] Yhdistelmärajapintojen hyödyt Yhdistelmärajapintojen hyödyt ovat hyvin samankaltaiset kuin ohjelmointirajapintojenkin. Tämä on osaltaan luonnollista, koska yhdistelmärajapinnat koostuvat ohjelmointirajapinnoista. Hyötyihin kuuluu ohjelmointirajapinnoillekin ominainen hyvä kehitettävyys ja ylläpidettävyys. Myös yhdistelmärajapinnat ovat usein riippumattomia alustasta ja ohjelmointikielestä, mutta tämän hyödyn kohdalla voi tapahtua poikkeuksia mukana olevien ohjelmointirajapintojen määrän kasvaessa. 24

28 Erityinen hyöty yhdistelmärajapintojen käytöstä voidaan saavuttaa lopputuloksena saatavan palvelun arvon kasvamisena, kun kahden tai useamman ohjelmointirajapinnan tarjoamat palvelut liitetään yhdeksi yhdistelmärajapinnaksi. Syntyneen palvelukokonaisuuden teoreettinen arvo pitäisi lähtökohtaisesti olla suurempi, kuin yhdistettyjen tietolähteiden yhteenlaskettu arvo Yhdistelmärajapintojen haitat Kuten yhdistelmärajapintojen hyödyt, myös niiden haitat seuraavat suhteellisen johdonmukaisesti ohjelmointirajapintojen haittoja. Haittojen suhteen yhdistelmärajapinnat ovat kuitenkin herkempiä ongelmiin, kun verrataan yksittäisiin ohjelmointirajapintoihin. Tämä johtuu yleensä siitä, että yhdistelmärajapinnoissa on useita eri rajapintoja, jolloin kukin rajapinta tuo omat ongelmansa yhdistelmärajapintaan. Tietoturvan heikentyminen on yleinen huolenaihe, aina kun käsitellään ohjelmistojen tarjoamia tietoja. Tämä on erityisen aiheellinen huoli, jos yhdistelmärajapinta on avoin tai edes osittain avoin. On myös olennaista huomioida, että vaikka kaikki tai osa yhdistelmärajapintaan kuuluvista ohjelmointirajapinnoista olisikin suljettuja, voivat niiden palvelut ollakin lopullisessa ohjelmistossa avoimia. Tietoturvaa heikentää entisestään se tosiasia, että yhden ohjelmointirajapinnan sijaan, niitä on yhdistelmärajapinnan kautta hyökkäyksille alttiina useampia. Myös toiminnallisuuden menettämiseen on suurempi riski yhdistelmärajapinnalla kuin yksittäisellä ohjelmointirajapinnalla. Tämä johtuu siitä, että yhdistelmärajapinnan toiminnallisuus voi heikentyä tai lakata kokonaan, jos yhdenkin mukana olevan ohjelmointirajapinnan taustalla oleva ohjelmisto muuttuu tai poistuu käytöstä. 2.3 Teoriaosan yhteenveto Ohjelmointirajapinnat ovat toiminnallisia kerroksia ohjelmistojen välillä, joiden avulla kyseiset ohjelmistot voivat kommunikoida keskenään. Pääasiallisesti 25

29 ohjelmointirajapintojen tarjoamat palvelut sisältävät joko ohjelmallisia toimintoja tai tietolähteitä. Ohjelmointirajapinnat voivat olla avoimia, suljettuja tai osittain suljettuja. Riippuen ohjelmointirajapinnan käyttötarkoituksesta, ne voivat toimia yksi- tai kaksisuuntaisesti. Yhdistelmärajapinnat ovat kahden tai useamman ohjelmointirajapinnan yhdistelmiä, joilla on ominaisuuksia kaikista mukana olevista ohjelmointirajapinnoista. Yhdistelmärajapinnat näyttäytyvät ja toimivat kuten ohjelmointirajapinnat, eikä niiden käyttäminen eroa juurikaan yksittäisten ohjelmointirajapintojen käytöstä. Ohjelmointirajapintoja tai niistä koostuvia yhdistelmärajapintoja käyttämällä saavutetaan monia hyötyjä, kuten tehokkaampi ohjelmistotuotanto uudelleenkäytettävyyden avulla. Toinen hyöty, varsinkin avoimissa ohjelmointirajapinnoissa, on ohjelmiston määritelmän ja toteutuksen piilottaminen käyttäjältä. Joissain tapauksissa voidaan hyöty saavuttaa riippumattomuutena alustasta tai ohjelmointikielestä. Yhdistelmärajapintojen etuna yksittäisiin ohjelmointirajapintoihin on mahdollisuus tarjota monien eri ohjelmointirajapintojen palveluita yhdestä paikasta, jolloin lopputuloksena saadaan arvokkaampi palvelu. Haitat ohjelmointi- tai yhdistelmärajapintoja käytettäessä ovat lähes samat, riippumatta kumpi näistä kahdesta on kyseessä. Huomattavaa kuitenkin on, että yhdistelmärajapintojen tapauksessa haitat ja riskit ovat yleensä suurempia. Heikompi tietoturva, joka aiheutuu, kun ohjelmiston toimintoja tai sen käsittelemää tietoa annetaan käyttäjän ulottuville, on yksi haitoista. Riskinä voidaan nähdä mahdollinen toiminnallisuuden menettäminen, jos palveluita tai tietoa alun perin tarjonnut ohjelmisto muuttuu tai lakkaa toimimasta. Lopuksi voidaan todeta, että vaikka ohjelmointi- ja yhdistelmärajapintojen käytössä on omat ongelmansa, voivat ne oikein käytettynä tuoda huomattavia etuja ja mahdollistaa asioita, jotka muuten olisivat hankalia tai jopa mahdottomia toteuttaa. Ohjelmointirajapinnat ovat nykyisin erittäin yleisiä ja sen myötä yhdistelmärajapintojenkin määrä on alkanut kasvaa. 26

30 Yhdistelmärajapintoja ei ole vielä tutkittu niin kattavasti kuin ohjelmointirajapintoja. Toisaalta yhdistelmärajapinnat ovat käytännössä ohjelmointirajapintoja, joten niiden tutkimukset voivat olla jossain määrin liitettävissä toisiinsa. Molempien, ohjelmointija yhdistelmärajapintojen, käytöstä ohjelmistotuotannon tehostamisessa, löytyy tulevaisuuden tutkimuskohteita. 27

31 3 VERTAILTAVIEN RAJAPINTOJEN TEKNINEN KUVAUS Tässä luvussa käsitellään tutkielmassa vertailtavien rajapintojen teknisiä toteutuksia. Se koostuu kolmesta kohdasta, jotka jakaantuvat seuraavasti, kohta 3.1 käsittelee vanhempaa tekniikkaa edustavalla FTP tiedonsiirrolla (File Transfer Protocol) toteutettua rajapintaa, kohta 3.2 keskittyy esittelemään SOAP-rajapinnan toimintaa (Simple Object Access Protocol) ja lopuksi kohdassa 3.3 käydään läpi RESTrajapinnan (Representational State Transfer) toiminta. Rajapintojen etuja tai haittoja ei ole tarkoitus vielä tässä osiossa vertailla keskenään toisten rajapintojen kanssa. Sen sijaan pyrkimys on esitellä kaikkien rajapintojen ominaisuudet ja taustaa yleisellä tasolla. 3.1 FTP-rajapinta Tiedonsiirrossa FTP-protokollaa on käytetty 1970-luvulta lähtien, jolloin sen ensimmäiset versiot kehitettiin Yhdysvalloissa, tarkemmin vuonna 1971 MIT:n yliopistossa. FTP-protokolla on säilynyt melkein samanlaisena julkaisustaan lähtien. Ajan mittaan tehdyt muutokset ovat lähinnä lisänneet uusia ominaisuuksia, kuten virheenkorjauksen viesteihin tai helpottaneet tiedonsiirtoa esimerkiksi palomuureilla suojattujen palvelinten välillä. Pelkkä FTP ei itsessään ole rajapinta, vaan se on ainoastaan tiedonsiirtoprotokolla. FTP-standardi mahdollistaa tiedostojen siirron kahden tietokoneen välillä. Tietokoneet jakautuvat FTP-yhteydessä asiakkaaksi ja palvelimeksi, joista ensimmäinen ottaa yleensä yhteyttä ja jälkimmäinen vastaanottaa yhteyden. Itse tiedostojen siirto tapahtuu hyödyntäen TCP-protokollaa, jonka päälle FTP-yhteys muodostetaan. Perinteisesti FTP-yhteydet käyttävät TCP-porttia 21 yhteyden muodostamiseen ja hallinnointiin. Itse tiedonsiirtoon käytetään normaalisti TCPporttia

32 FTP-rajapinnan toiminta perustuu siis siirtotiedoston käyttämiseen. Tämä tarkoittaa sitä, että rajapinta tarvitsee erillisen ohjelmiston rajapinnan molempiin päihin, jotka tuottavat ja purkavat yhden tai useamman siirtotiedoston. Siirtotiedostot ovat tiedostoja, jotka sisältävät siirrettävän datan ja ne voivat olla periaatteessa mitä tahansa tiedostomuotoa. Yleisesti käytettyjä tiedostomuotoja ovat esimerkiksi.csv,.xml ja joskus jopa normaali.txt tiedosto. Vaikka FTP-rajapinta vaatii erillisen siirtotiedoston luomisen, niin se voi myös joissain tapauksissa toimia etuna. Esimerkiksi jotkut jo olemassa olevat ohjelmistot tukevat tietojen tuontia tiedostosta tai vientiä tiedostoon entuudestaan, jolloin mahdollisesti voidaan tarvita vähemmän rajapinnan kehitystyötä. Kun tiedostoja siirretään voi FTP-yhteyteen kuuluva palvelin olla kahdessa eri tilassa, aktiivisessa ja passiivisessa. Aktiivisessa tilassa palvelin pyrkii itse avaamaan yhteyden asiakkaaseen ja aloittamaan tiedonsiirron. Passiivisessa tilassa toimiva palvelin sen sijaan odottaa, että asiakas avaa yhteyden, jonka jälkeen palvelin aloittaa tiedonsiirron. FTP-rajapinnassa itse tiedonsiirto ei vaadi paljoa kehitystyötä, koska tiedostojen siirtäminen on helppoa toteuttaa. Eniten aikaa kuluukin siirtotiedostoja luovan ja lukevan järjestelmän kehittämiseen. Jos siirtotiedoston luominen ja lukeminen täytyy toteuttaa kokonaan rajapintaa varten ja tämän lisäksi siirrettävät tiedot ovat monimutkaisia, voi rajapinnan toteutus olla erittäin työläs. Seuraavaksi on esitetty yksi mahdollinen shell-skripti, jota voidaan hyödyntää tiedostojen palvelimelta toiselle lähettämisen automatisoinnissa. 1: #!/bin/sh 2: FILES=./FolderToLookFilesFrom/* 3: if[ $(ls A./FolderToLookFilesFrom/) ]; then 4: for f in $FILES 5: do 6: echo Processing $f 7: local_path=$f 29

33 8: remote_path=/remote/path/goes/here 9: ftp -n ServerHere <<EOF 10: quote USER UserName 11: quote PASS Password 12: put $local_path $remote_path 13: quit 14: EOF 15: done 16: fi Mahdollisen raskaan kehitystyön lisäksi tietoturva on FTP-rajapinnan heikkous. Se on haavoittuvainen eritoten viestipaketteja kaappaaville haittaohjelmille, koska FTPprotokolla ei salaa lähetettyjä viestejä. Haavoittuvuuden korjaaminen käyttämällä salattuja yhteyksiä on myös ongelmallista, koska FTP-protokolla käyttää useita portteja tietojen siirtämisessä. 3.2 SOAP-rajapinta SOAP (Simple Object Access Protocol) on kehitetty suurimmaksi osaksi Microsoftin toimesta. Sen ensimmäisen version määritelmä valmistui vuonna Määritelmä ei kuitenkaan ollut julkinen ennen vuotta 1999, jolloin Microsoft jätti sen IETF:n (Internet Engineering Task Force) käsiteltäväksi. SOAP ei kaikesta huolimatta saavuttanut standardin statusta ennen kuin vuonna 2003, jolloin se lisättiin W3C:n (World Wide Web Consortium) suosittamiin määrittelyihin. Kuten nimi antaa ymmärtää, on SOAP-protokolla yksinkertaisille olioille. Sen tarkoitus on mahdollistaa yksinkertaisten olioiden tietojen lähettäminen ja vastaanottaminen www-sovelluspalveluiden kesken. Olioiden tietoja sisältävien viestien olennainen ominaisuus on myös niiden rakenteellinen määrittely. Viestien muotona SOAP-viesteissä käytetään XML-kielellä kirjoitettua tietorakennetta. Nämä viestit toteuttavat www-sovelluspalvelun protokollasarjasta viestintäkerroksen, joka vastaa siitä että osapuolet viestintäkanavan molemmissa 30

34 päissä ymmärtävät viestien sisällön samalla tavalla. Rakenteeltaan SOAP-viesti jakaantuu kolmeen osaan. Ensimmäinen eli uloin osa viestistä on kirjekuori, joka määrittelee viestin rakenteen ja antaa ohjeet miten kyseistä rakennetta tulee käsitellä. Toinen ja kolmas osa ovat kirjekuoren sisällä, mutta omina erillisinä kokonaisuuksinaan. Toinen osa sisältää viestiin ja sitä lähettävään tai vastaanottavaan sovellukseen liittyvien tietojen koodauskäytännöt. Kolmas osa sisältää itse viestittävän olion metodikutsuja tai vastauksia. Itse tiedonsiirtoon voidaan SOAP-viestien osalta soveltaa mitä tahansa tiedonsiirtoprotokollaa, mutta yleisimmin käytetään HTTP-protokollaa. Tämä on luontevaa, koska www-sovelluspalvelut toimivat jo valmiiksi samassa www ympäristössä. Kuva 6. Havainnollistus SOAP-viestin rakenteesta. SOAP-rajapintaa voidaan myös laajentaa esimerkiksi tietoturvaa lisäämällä. Yksi tapa on tunnistetietojen käyttäminen viestissä esimerkiksi luomalla turvatunniste ja lisäämällä se viestiin. Turvatunnisteen avulla viestin vastaanottaja voi varmistua viestin lähettäjästä. Toinen tapa lisätä tietoturvaa on salata viesti, jolloin voidaan estää, tai ainakin hankaloittaa, kolmansia osapuolia saamaan selville viestin sisältö. Laajennettavuuden lisäksi SOAP-rajapinnan vahvuudeksi voidaan lukea riippumattomuus ohjelmointikielestä ja -mallista. Ohjelmointikielen tulee kuitenkin 31

35 pystyä toteuttamaan verkkotuki ja XML-jäsennin, jotta sillä pystytään toteuttamaan SOAP-rajapinta. 3.3 REST-rajapinta REST-arkkitehtuurin historia alkaa vuodesta Tuolloin REST-termiä käytti ja määritteli ensimmäisen kerran Roy Fielding tohtorinväitöskirjassaan "Architectural Styles and the Design of Network-based Software Architectures", Kalifornian yliopistossa, Irvinessä. REST ei itsessään ole rajapinta, vaan malli, jonka avulla voidaan rajapintojen arkkitehtuuria ja rakennetta määritellä toimimaan paremmin. Kyseinen malli sisältää useita eri rajoituksia ja pakotteita, joita noudattamalla rajapinnan toiminnallisuuden tulisi REST-mallin mukaan parantua. Jos ohjelmisto noudattaa kaikkia REST-mallin määrittelemistä pakotteista, voidaan kyseisen ohjelmiston todeta noudattavan RESTarkkitehtuuria (eng. RESTful). Seuraavat rajoitukset määrittelevät REST-arkkitehtuurin: Yhdenmukainen rajapinta. REST-mallin perusperiaate on yhdenmukainen rajapinta. REST-mallin mukaan rajapinnan yhdenmukaisuus saavutetaan resurssien tunnistuksella, resurssien muokkaamisella esitysten avulla, itsekuvaavilla kutsuilla ja hypermedian käyttämisellä tilan muuttamiseen (eng. HATEOAS). Yhdenmukaistamalla rajapintaa, pyritään yksinkertaistaa ohjelman arkkitehtuuria, joka mahdollistaa ohjelman eri osien muokkaamisen itsenäisinä kokonaisuuksina. Asiakas-palvelin. Asiakkaiden ja palvelinten välillä tulee olla yhdenmukainen rajapinta. Tämä mahdollistaa sen, ettei asiakaspään tarvitse säilyttää tietoa. Tämän seurauksena rajapinnan asiakaspää pystytään helpommin siirtämään toimimaan eri ohjelmistoissa. Palvelinpään ei tarvitse tietää mitään asiakaspään toiminnasta, jonka seurauksena kehitystyö yksinkertaistuu ja skaalautuvuus paranee. Tilattomuus. Asiakaspään lähettämien kutsujen tietoja ei säilytetä palvelinpäässä, sen sijaan jokainen asiakaspään kutsu sisältää kaikki tarvittavat tiedot palvelinpäälle 32

36 kutsun käsittelemiseksi. Näin ollen tilaa ylläpidetään ainoastaan asiakaspäässä. Tarvittaessa asiakaspää voi lähettää kutsun mukana sen hetkisen tilansa palvelinpäälle, mutta silloinkin tilaa käytetään ainoastaan kyseisen kutsun käsittelyyn, eikä sitä tallenneta palvelinpäähän. Välimuisti. Koska asiakaspää voi tarvittaessa säilöä kutsujen vastauksia välimuistiin, tulee vastausten olla yksiselitteisesti säilöttävissä olevia tai sitten ilmaista ettei niitä voi säilöä. Tällä tavalla toimittaessa estetään asiakaspäätä käyttämästä väärää informaatiota tulevien kutsujen muodostamiseen. Kerroksittaisuus. Asiakaspää ei pysty tietämään, onko se yhteydessä palvelimeen vai välissä olevaan toimijaan. Tärkein REST-arkkitehtuurin vahvuus onkin yhdenmukainen rajapinta. Yhdenmukaisuuden myötä arkkitehtuuria saadaan hajautettua ja järjestelmä yksinkertaistuu kokonaisuudessaan. Oleellinen piirre, joka mahdollistaa hajauttamisen, on asiakas- ja palvelinpäiden mahdollisuus toimia tietämättä toisistaan. Koska asiakas- ja palvelinpäät ovat käytännössä itsenäisiä kokonaisuuksia, voidaan niitä periaatteessa kehittää täysin erillään. Näin ollen myös kehitystyöstä vastaavat tahot voivat jakaantua ja olla erillisiä molemmille kokonaisuuksille, jolloin kehitykseen käytettävien resurssien hallinta helpottuu. Asiakas- ja palvelinpäät voidaan myös tarvittaessa korvata vastaavilla olemassa olevilla tai kokonaan uusilla. Ainut ehto kaikille asiakas- ja palvelinpään muutoksille on, että ne toteuttavat niiden välissä olevan yhtenäisen rajapinnan. Yhtenäiseen rajapintaan ei tulisi tulla muutoksia. Kerroksittaisuuden ansiosta REST-arkkitehtuuriin pohjautuviin rajapintoihin voidaan lisätä erilaisia ominaisuuksia. Yksi mahdollinen lisäominaisuus on kuormituksen tasaaminen eri palvelinpäiden kesken kuormituksen kasvaessa tietyn pisteen yli. Koska asiakaspäälle ei ole väliä, onko se yhteydessä palvelimeen vai välissä olevaan toimijaan, niin kutsut voidaan esimerkiksi ohjata yhden välittäjän kautta eri palvelimille, asiakaspään tästä mitään tietämättä. Kerroksittaisuuden avulla voidaan 33

37 myös lisätä tietoturvaa. Tämä voidaan toteuttaa esimerkiksi lisäämällä asiakas- ja palvelinpään välissä toimivaan kuormantasaajaan viestien käsittelyä. Näin ollen viestit voidaan varmentaa, ennen kuin ne edes päätyvät palvelinpäähän asti. REST-arkkitehtuurin määritelmä sisältää myös yhden valinnaisen rajoitteen. Rajoitteen mukaan asiakaspää voi vastaanottaa suorituskelpoista ohjelmakoodia vastauksena palvelinpäälle lähetettyihin kutsuihin (eng. Code on demand). Ohjelmakoodit voivat olla esimerkiksi Java-sovelmia tai JavaScript-tiedostoja. Kyseisen toiminnallisuuden ansiosta REST-arkkitehtuuriin pohjautuva rajapinta on entistä mukautuvampi erilaisiin tilanteisiin, mutta yleisesti ottaen näin laajaa mukautuvuutta tarvitaan vain harvoin. Myös mahdollisuus käyttää erilaisia tietoformaatteja, parantaa REST-arkkitehtuurin soveltuvuutta erilaisiin tilanteisiin. Tietoformaattia ei ole siis rajattu mihinkään tiettyyn, vaan käytettäväksi voidaan valita mikä tahansa määritelty tietoformaatti. Tämän lisäksi useamman eri tietoformaatin käyttö yhdessä rajapinnassa on mahdollista. Pääsääntöisesti REST-rajapinnat käyttävät JSON- tai XML-muotoisia viestejä. Vaikka REST-arkkitehtuuria noudattavilla rajapinnoilla on edellytykset toimia tehokkaasti, on niillä myös huonoja puolia. Yleisesti ottaen huonot puolet eivät ole kuitenkaan suoranaisia haittoja, vaan pikemminkin joidenkin tekniikoiden tai toimintamallien käyttäminen on arkkitehtuurin puitteissa mahdotonta tai ainakin haastavaa. Yksi haaste REST-arkkitehtuurin kannalta on tietoturvan yksinkertaisuus viestien välityksessä, sekä viestien välittäminen itsessään. Ainut selkeä keino salattuun viestien välittämiseen REST-arkkitehtuurin toteuttavassa rajapinnassa on käyttää SSL-yhteyttä, joka jo itsessään rikkoo REST-arkkitehtuuria rajoittavia periaatteita. Tämä tarkoittaa sitä, että salattua yhteyttä pitkin välitettyjä viestejä ei voida uudelleenohjata. Viestien sisältö täytyy myös salata kokonaisuudessaan, jolloin esimerkiksi ohjaustietojen salaamatta jättäminen ei ole mahdollista. 34

38 Toinen haaste REST-arkkitehtuurissa tulee tilattomuuden rajoituksesta. Koska tilaa ei missään vaiheessa tallenneta palvelinpäähän, on asiakaspään huomattavasti vaikeampi palautua virhetilanteista. Tilattomuus voi aiheuttaa ongelmia myös tietyissä järjestelmissä käyttäjien erittelemisessä yksiselitteisiin sessioihin. Tilattomuuden aiheuttamia ongelmia voidaan yrittää kiertää pitämällä yllä asiakaspään tilaa myös palvelinpäässä, mutta tämänkaltainen ratkaisu eroaa jo suurelta osin alkuperäisen REST-arkkitehtuurin mukaisesta rajapinnasta. 35

39 4 TUTKIMUSKYSYMYKSEN ESITTÄMINEN Tässä tutkielmassa vertaillaan kolmea rajapintaa. Vertailtavat rajapinnat ovat FTP-, SOAP- ja REST-rajapinnat. Rajapintoja testataan vertailussa siirtämällä tietoja palvelimelta toiselle. Tutkielma pyrkii selvittämään, mikä tutkittavista rajapinnoista soveltuu parhaiten tiedonsiirtoon eri kokoisten tietomäärien kanssa toimiessa. Pelkän tietomäärän muuttamisen lisäksi, tutkitaan myös rajapintojen käyttäytymistä kun tiedot ovat moniulotteisia. Tämä tarkoittaa sitä, että osa tiedosta on jakautunut pienempiin osatietoihin, jotka yhdessä muodostavat yhden kokonaisuuden. Tiedonsiirtoon parhaiten soveltuva rajapinta tarkoittaa tässä tutkielmassa tehokkainta rajapintaa. Tehokkuus määritellään kolmen ominaisuuden avulla. Ensimmäinen ominaisuus on rajapinnan käyttämä aika tiedonsiirrossa palvelimelta toiselle. Toinen ominaisuus on itse rajapinnan toiminnalliseksi saattamiseen kuluva kehitysaika, kun oletetaan ettei käytettävissä ole aiempaa kyseiseen tilanteeseen soveltuvaa rajapintaratkaisua. Kolmantena vertailtavana ominaisuutena on rajapinnan toteuttavan ohjelmakoodin koko rivimääränä. Tutkimusmenetelmänä käytetään empiiristä tutkimusta. Empiirinen tutkimus pyrkii saamaan tietoa tutkittavasta kohteesta tarkkailemalla ja tekemällä mittauksia. Mittaukset ovat tässä tutkielmassa pääosin eri toimintoihin käytetyn ajan tai ohjelmakoodin rivien määrän mittaamista. Empiirinen tutkimus sopii tämän tutkielman tutkimusmenetelmäksi, koska rajapintojen toimintaa tiedonsiirrossa on luontaista tarkastella käytännön sovellusten kautta. Toisekseen rajapintojen kehittämiseen käytettävän ajan teoreettinen arviointi on erittäin hankalaa, koska siihen vaikuttavat tekijät ovat niin merkittäviä lopputuloksen kannalta. Tutkielma on luonteeltaan kvantitatiivinen. Kvantitatiivinen tutkimus on määrällistä tutkimusta, joka pohjautuu tilastollisiin menetelmiin. Tutkielman tavoite on tuottaa 36

40 täsmällinen tulosjoukko, jota laskennallisesti tarkastelemalla saadaan vastaus tutkimuskysymykseen. 37

41 5 VERTAILUN TOTEUTUS Teknisesti rajapintojen vertailu toteutetaan kahta palvelinta käyttäen. Fyysiset palvelinkoneet sijaitsevat samassa lähiverkossa, jolloin verkkoviiveen vaikutus tutkielmassa suoritettuihin testeihin saadaan minimoitua. Koska tutkielmassa käytettävät rajapintaohjelmat ovat suhteellisen kevyitä ja vähän resursseja vaativia, ajetaan niitä palvelinkoneilla sijaitsevilla virtuaalikoneilla. Tietojen siirrossa FTP-rajapinta käyttää siirtotiedostoa, joka tämän tutkielman testeissä on normaali tekstitiedosto. Luonnollisesti SOAP- käyttää määrittelynsä mukaista tietoformaattia, eli se lähettää viestinsä XML-muodossa. REST-rajapinta käyttää tämän tutkielman testitapauksissa JSON-muodossa olevia viestejä. Tutkielmassa vertailtavien rajapintojen vaatimien ja testituloksia käsittelevien ohjelmien toteuttamiseen käytetään Java-ohjelmointikieltä. Tämä sisältää rajapintojen toteutuksen SOAP- ja REST-rajapintojen osalta, sekä siirtotiedoston luovan ja purkavan ohjelmiston FTP-rajapintaa varten. Tämän lisäksi FTP-rajapintaa varten on toteutettu yksi shell-skripti. Kummankin palvelinalustan käyttöjärjestelmänä toimii GNU/Linux, tarkemmin määriteltynä CentOS release 6.5 (Final). Molemmissa palvelimissa on myös asennettuna tutkielman rajapintojen vaatimat ohjelmistot. Kyseiset ohjelmistot ovat seuraavat: SFTP protocol version 3, watch version ja Java version 1.8.0_102. SFTP ohjelmaa tarvitaan luonnollisesti FTP-rajapinnan toteutukseen. Tämän lisäksi FTP-rajapinta vaatii erillisen tahon, joka laukaisee siirtotiedoston varsinaisen siirron. Tämän tutkielman testeissä laukaisevana mekanismina on käytetty shell-skriptiä, jota Unix-ympäristön watch-työkalu operoi. Javaa, eli Javan virtuaalikonetta, tarvitaan SOAP- ja REST-rajapintojen ajamiseen. Selvyyden vuoksi tässä tutkielmassa käytetään palvelimille seuraavaa nimeämiskäytäntöä. Palvelinta jolla tiedot luodaan ja jolta ne lähetetään kutsutaan 38

42 nimellä P1. Vastaavasti palvelin jolle tiedot siirretään ja joka huolehtii tietojen purkamisesta ja tarkastamisesta on nimeltään P2. Tutkielmaa varten on myös toteutettu erillinen tietoa generoiva kirjasto. Kyseisen kirjaston toteutus on tehty Java-ohjelmointikielellä ja toteutus on liitetty kaikkien rajapintojen tavoin tutkielman liitteeksi. Koska vastaanottavalla palvelimella P2 tulee olla mahdollista tarkastaa siirrettyjen tietojen oikeellisuus, on tietojen generointi mahdollistettu pseudo-satunnaisesti. Näin ollen, sekä rajapinnan lähettävä, että vastaanottava ohjelmisto luovat täsmälleen samat tiedot ja samassa järjestyksessä käynnistyessään. Koska tietoja generoiva kirjasto on rajapinnoista erillinen kokonaisuus ja kaikki rajapinnat käyttävät sitä, ei sitä lasketa mukaan rajapintojen kehitystyöhön käytettyyn aikaan. Tiedot generoidaan ainoastaan kerran, silloin kun rajapinta käynnistetään. Näin ollen tietojen generointi ei vaikuta rajapinnan tietojen siirtoon, eikä myöskään vastaanottavassa päässä tietojen oikeellisuuden tarkastamiseen kuluvaan aikaan. Koska tässä tutkielmassa rajapinnat ovat toteutettu Java-ohjelmointikielellä, tullaan Javan oliorakennetta hyödyntämään yksinkertaisen ja moniulotteisen tietomallin toteuttamisessa. Tämä tarkoittaa sitä, että yksinkertainen tieto koostuu vain ja ainoastaan yhdestä oliotyypistä. Moniulotteinen tieto pohjautuu siirrettäessä yhteen oliotyyppiin, mutta se pitää sisällään myös muita oliotyyppejä. Seuraavaksi on esitetty testeissä käytetyt Java-oliot. Kaikista olioista esitellään ainoastaan pelkistetty versio, josta on jätetty pois kaikki olion ohjelmakutsut, ohjelmakirjastojen tuonnit, sekä mahdolliset rajapintakohtaiset annotaatiot. 39

43 Yksinkertaisen tietomallin mukainen olio 1: Temperature { 2: Integer id; 3: Integer wstslave; 4: Integer wstmaster; 5: Date timestamp; 6: Integer value; 7: } Moniulotteisen tietomallin mukainen olio ja siihen liittyvät oliot. 1: User { 2: Name name; 3: Address address; 4: List<PhoneNumber> phonenumbers; 5: } 1: Name { 2: String firstname; 3: String lastname; 4: } 1: Address { 2: String street; 3: String building; 4: Integer zipcode; 5: } 1: PhoneNumber { 2: String number; 3: String countrycode; 4: } 40

44 Esitetyn tietomallin mukaiset oliot tarvitaan kaikkiin rajapintoihin, joten ne on toteutettu kerran yhteen rajapintaan ja sen jälkeen kopioitu kahteen muuhun rajapintaan sellaisenaan. Olioiden toteuttamiseen kulunutta aikaa ei lasketa rajapinnan toteutukseen kuluneeseen aikaan. Sen sijaan eri rajapinnat vaativat erinäisiä muutoksia perus olioon, jotta rajapinnan toteutus voi hyödyntää oliota. Näiden muutosten toteuttaminen olioihin on laskettu mukaan muutoksia vaativan rajapinnan toteuttamiseen kuluneeseen aikaan. Vertailtavista ominaisuuksista tiedonsiirron nopeus tarkoittaa tietojen siirtämiseen palvelimelta toiselle ja tietojen oikeellisuuden tarkastamiseen kulunutta aikaa. Tiedonsiirron nopeuden mittaamista varten, rajapintoihin tulee implementoida ylimääräinen toiminnallisuus, jota kutsutaan tästä eteenpäin kellottajaksi. Kyseisen toiminnallisuuden tulee mahdollistaa rajapintojen toiminta-ajan mittaamisen. Käytännössä tämä tapahtuu tallentamalla aika, jolloin rajapinta aloittaa tietojen siirtämisen toiselle palvelimelle sekä aika, jolloin toinen rajapinnan osa on vastaanottanut ja tarkastanut lähetetyt tiedot onnistuneesti. Tarkemmin määriteltynä kellottaja kirjoittaa palvelimella P1 sijaitsevaan tiedostoon aloitusaikaleiman, kun tietojen lähettäminen alkaa. Kun rajapinta saa tiedot onnistuneesti tarkastettua palvelimella P2, kirjoittaa kellottaja kyseisellä palvelimella sijaitsevaan tiedostoon lopetusaikaleiman. Tämän jälkeen laskemalla alku- ja loppuaikaleimojen välillä kuluneen ajan, saadaan rajapinnalta tietojen siirtämiseen kulunut aika. Kellottaja on toteutettu erillisenä Java kirjastona. Näin ollen kellottaja voidaan sisällyttää kaikkien kolmen rajapinnan Javalla toteutettujen ohjelmien sisälle mahdollisimman vähällä vaivalla. Koska kellottajan suorittama toiminto vaatii erittäin vähän resursseja ja se toimii vain tiedonsiirron alku- ja loppuhetkillä, voidaan olettaa, että se ei vaikuta rajapinnan suoritusaikaan merkitsevästi. Käytännössä kellottajan ohjelmakoodi suoritetaan juuri ennen siirron aloittamista palvelimella P1 ja vastaavasti heti siirron jälkeen palvelimella P2. Palvelinten kellot ovat synkronoitu käyttäen samaa NTP-palvelinta (Network Time Protocol). Näin ollen molempien palvelinten kellojen tulisi olla samassa ajassa, mutta ne voivat hetkellisesti erota 41

45 toisistaan yksittäisiä millisekunteja. Näin pienet eroavaisuudet kellojen välillä eivät vaikuta testitulosten oikeellisuuteen, johtuen testitapausten riittävän suuresta määrästä. Kuva 7. Havainnollistus yksittäisen testitapauksen tapahtumista. Yksittäinen testitapaus sisältää kuvan 7 mukaiset vaiheet. Kuten aiemmin mainittiin, tietojen generointi tapahtuu ainoastaan kerran rajapinnan käynnistyessä. Tästä johtuen tietojen generointi ei myöskään sisälly yksittäiseen testitapaukseen. Toinen rajapintojen vertailtavista ominaisuuksista on kehitystyöhön vaadittava aika. Kyseisen ominaisuuden mittaaminen itsessään on yksiselitteistä. Kellotetaan ohjelmointityö ja kaikki vaadittavat ylimääräiset tehtävät, jotka vaaditaan rajapinnan toiminnalliseksi saattamiseen. Ylimääräiset tehtävät voivat olla esimerkiksi palvelimen asetusten muokkaamista tai tarvittavien ohjelmistojen asentamista. Kehitystyöhön vaadittavan ajan mittaaminen on siis helppoa ja tulosten vertailu keskenään on yksinkertaista. Ongelmalliseksi kyseisen ominaisuuden tarkastelussa tutkielman kannalta nousee toistettavuus. Jokainen ohjelmistokehittäjä toteuttaa rajapinnat omalla yksilöllisellä tavallaan, jotka yleensä vaativat eri määrän kehitykseen käytettyä aikaa. Vaikka useampi ohjelmistokehittäjä toteuttaisi saman rajapinnan pääosin samalla tavalla, niin todennäköisesti eroja kehitykseen käytetyssä ajassa ilmenisi silti. Tällöin vaikuttavana tekijänä ovat ohjelmistokehittäjän ammatillinen osaaminen, mutta myös motivaatio. Näistä syistä johtuen rajapintojen kehitystyöhön käytetylle ajalle annetaan tässä tutkielmassa pienempi painoarvo rajapinnan tehokkuuteen, kuin rajapinnan tiedonsiirtonopeudelle. Lähtökohtaisesti kehitystyöhön käytettävä aika on kuitenkin niin merkittävä osa rajapinnan tehokkuutta kokonaisuudessaan, että sen kokonaan 42

46 pois jättäminen vertailusta vääristäisi saatuja tuloksia enemmän kuin tulosten tulkitseminen huomioiden ohjelmistokehittäjän taidot. Jotta rajapintojen kehittämiseen käytettävän ajan mittaaminen ja vertailu olisi toistettavissa, on myös tutkielman testeissä toimiva ohjelmistokehittäjä määriteltävä mahdollisimman hyvin. Tässä tutkielmassa sama henkilö suorittaa kaikki rajapintojen vertailuun tarvittavat toimenpiteet. Kyseisellä henkilöllä on kuuden vuoden ammatillinen kokemus ohjelmistotuotannosta Java-ohjelmointikielellä, tietojenkäsittelytieteen maisteria vastaava koulutus, sekä vahva harrastuksellinen kiinnostus ohjelmointiin ja tietotekniikkaan. Henkilö on myös toteuttanut aiemmin rajapintoja käyttäen kaikkia kolmea tutkielmaan valittua teknologiaa. Tämän tutkielman rajapintojen toteuttavan henkilön työmotivaatio ei vaikuta rajapintojen kehittämiseen kuluvaan aikaan. Rajapinnat toteutetaan ilman palkkiota, mutta toteuttavan henkilön kiinnostus aihepiiriin riittää toimimaan tarpeeksi suurena kannustimena. Toimenpiteet sisältävät muun muassa itse rajapintojen toteutuksen, tarvittavien ohjelmistojen asentamisen ja kaikkien ohjelmistojen konfiguroinnin. Seuraavaksi on esitetty kehitysaihiot toteutettavista toimenpiteistä. FTP-rajapinta Siirtotiedoston luovan ja lukevan ohjelmiston toteutus FTP-ohjelmistoa ohjaavan skriptin toteutus SOAP ja REST-rajapinnat Rajapinnan toteutus Yleiset Tietoja generoivan kirjaston toteutus Kellottajan toteutus Kellottajan tuottamia tietoja lukeva ohjelma 43

47 Kuten jo aiemmin mainittiin toteutetaan tietojen generoinnista ja kellottamisesta vastaavat kirjastot erikseen, eivätkä ne vaikuta rajapintojen toteutukseen laskettuun aikaan. Tietojen generoimisen tai kellottajan toteuttaminen erikseen jokaiseen rajapintaan johtaisi myös oppimisefektiin, joka vääristäisi toteutukseen käytettyä aikaa. Oppimisefekti tarkoittaa sitä, että kolmatta kertaa samaa kohtaa toteuttaessaan, koehenkilö suoriutuisi kyseisestä kohdasta huomattavasti aiempaa nopeammin. Rajapintojen kehitystyöhön vaikuttavia tekijöitä ovat myös ohjelmointikielien ja muiden ohjelmistojen määrä. Juuri tästä syystä tässä tutkielmassa käytettävä ohjelmointikieli, sekä muut ohjelmistot on määritelty tarkasti. Ohjelmointikielen tai muiden tarvittavien ohjelmistojen muuttaminen vaikutus rajapinnan tiedonsiirtonopeuteen ei todennäköisesti ole merkittävä. Tarkastellessa rajapinnan kehitystyöhön vaadittavaa aikaa tai ohjelmistokoodin määrää, vaikutuksen voidaan olettaa olevan merkittävämpi. Ohjelmakoodin määrän käyttäminen tehokkuuteen vaikuttavana tekijänä ei sinänsä ole yksiselitteinen mittauskohde. Ohjelmiston suorituksen kannalta koodirivien määrä on käytännössä yhdentekevä, kun vertaillaan saman asian toteuttavien rajapintojen tehokkuuseroja. Toisaalta mitä enemmän ohjelmakoodia tarvitaan, niin sitä vaikeammaksi ohjelmistovirheiden korjaus ja ohjelmiston jatkokehittäminen muuttuu. Näin ollen ohjelmakoodin määrälle voidaan antaa pieni painoarvo rajapinnan tehokkuuteen. Tässä tutkielmassa toteutettavien rajapintojen eroja ohjelmakoodin määrässä voidaan pitää viitteellisenä, koska toteutetut rajapinnat ovat kooltaan ja toiminnallisuudeltaan verrattain yksinkertaisia. Rajapintojen tehokkuuden tarkastelu tuottaa kvantitatiivisia tuloksia kaikista rajapinnoista seuraavasti. 1. Tiedonsiirtoon käytetty aika, kun tietomalli on yksinkertainen (yksi olio) ja tietomäärä pieni (1000 oliota) 2. Tiedonsiirtoon käytetty aika, kun tietomalli on yksinkertainen (yksi olio) ja tietomäärä suuri (10000 oliota) 44

48 3. Tiedonsiirtoon käytetty aika, kun tietomalli on moniulotteinen (yksi olio, jonka sisällä useita olioita) ja tietomäärä pieni (1000 oliota) 4. Tiedonsiirtoon käytetty aika, kun tietomalli on moniulotteinen (yksi olio, jonka sisällä useita olioita) ja tietomäärä suuri (10000 oliota) 5. Rajapinnan kehittämiseen käytetty aika 6. Rajapinnan ohjelmakoodin määrä Lähtökohtaisesti tiedonsiirtorajapinnat toimivat moniulotteista tietomallia käyttäen ja tarvittaessa moniulotteisesta tietomallista yksinkertaiseen siirtyminen on yleensä vaivattomampaa, kuin kokonaisen yksinkertaista tietomallia käyttävän rajapinnan toteutus. Tässä tutkielmassa rajapinnan kehittämiseen käytetty aika sisältää molemmat sekä yksinkertaisen tietomallin, että moniulotteisen tietomallin rajapinnat. Tarkastelemalla tiedonsiirtoa usealla eri tietomallin ja tietomäärän yhdistelmällä pystytään entisestään painottamaan tiedonsiirtoon käytettyä aikaa rajapinnan tehokkuuteen vaikuttavana tekijänä. Tiedonsiirtoon käytetyn ajan tarkastelu eri tilanteissa on muutenkin looginen tarkastelun kohde, koska siitä saadaan helpommin suuria määriä vertailukelpoisia mittauksia. Kuten aiemmin todettiin, rajapintojen kehittämiseen käytetty aika ja ohjelmakoodin määrä riippuvat rajapinnan toteuttavasta ohjelmistokehittäjästä, jolloin useampien mittaustulosten saanti on huomattavasti hankalampaa. Useamman ohjelmistokehittäjän tapauksessa myös tuloksiin vaikuttavien muuttujien määrä kasvaa ja muuttujien merkitsevyys painottuu eri tavalla. 45

49 6 TULOKSET Tässä luvussa käsitellään tutkielman kohteena olevien rajapintojen ohjelmistoista, niiden kehittämisestä ja niiden testaamisesta saatua aineistoa. Luku on jaettu kahteen kohtaan, joista ensimmäinen 6.1 käy läpi aineiston paikkansapitävyyttä ja testien toistettavuutta. Toisessa kohdassa 6.2 esitellään saadut tulokset. 6.1 Testien luotettavuus ja toistettavuus Aineistoa on koottu jokaista rajapintaa kohti sama määrä seuraavasti toistoa, yksinkertainen olio, 1000 oliota toistoa, moniulotteinen olio, 1000 oliota toistoa, yksinkertainen olio, oliota toistoa, moniulotteinen olio, oliota Tutkielman näkökulmasta toistoa on riittävä määrä tuottamaan tarpeeksi luotettava tulosjoukko jokaista erilaista testitapausta kohden. Myös kaikissa testeissä käytettyjen olioiden, eli toisin sanoen siirrettävän tiedon, määrä on tarpeeksi vaihteleva, jotta eroja voidaan havaita myös yksittäiseen rajapintaan kohdistuvien testien välillä. Toistojen määrä, kappaletta, tuli valituksi osittain myös testien keston vuoksi. Suuremmilla toistomäärillä testien suorittaminen kestäisi paljon kauemmin, jolloin aikataulut voivat koitua ongelmaksi, varsinkin jos testejä joudutaan uusimaan useamman kerran. Testien ajaminen yhdenaikaisesti samalla palvelimella voi johtaa tilanteeseen, jossa testattavat rajapinnat vaikuttavat toistensa suorituksiin. Useamman identtisen palvelimen käyttö testien ajamiseen yhtäaikaisesti tuottaa hyvin todennäköisesti riittävän luotettavia tuloksia, mutta tässä tutkielmassa käytettiin ainoastaan yhtä palvelinparia. Lisäämällä toistojen määrää testeihin, ei myöskään näennäisesti saavuteta merkittävästi lisää tulosjoukon tarkkuutta, mutta kuitenkin kasvatetaan olennaisesti 46

50 testien suorittamiseen tarvittavaa aikaa. Toisaalta mahdollisten virhetilanteiden ilmeneminen on hieman todennäköisempää testien ajokertojen kasvaessa, mutta tämän tutkielman osalta virhetilanteiden löytämisellä ja tarkastelulla on huomattavasti pienempi painoarvo tehokkuuteen nähden. Tässä tutkielmassa käytettävät testit ovat täysin toistettavissa. Testeissä käytettyjen, tutkielmaa varten luotujen, ohjelmien lähdekoodit löytyvät lopusta liitteinä. Testejä toistettaessa voi olla mahdollista, että jostain käytetystä ohjelmakirjastosta tai ohjelmistosta ei ole saatavilla täsmälleen samaa versiota, kuin mitä tässä tutkielmassa on käytetty. Tämän ei kuitenkaan pitäisi vaikuttaa testien tuloksiin merkittävästi. Esimerkiksi eri versio CentOS-käyttöjärjestelmästä testipalvelimella, jolla testit ajetaan, ei vaikuta testituloksiin. Jos testipalvelimella on kokonaan eri käyttöjärjestelmä kuin tämän tutkielman testeissä käytetyillä testipalvelimella, on todennäköistä, että myös osa käytetyistä ohjelmista on korvattava jollain vastaavalla, saatavilla olevista vaihtoehdoista. Tutkielmaa toistettaessa voidaan näin ollen käyttää vastaavia ohjelmistoja, siten että testitulokset eivät merkittävästi muutu. Kaikki eroavaisuudet alkuperäisen tutkielman käyttämiin testeihin tulee kuitenkin merkitä ylös huolellisesti ja ottaa tarkasteluun, jos huomattavia eroavaisuuksia ilmenee testituloksissa. Toistettavuuden osalta hyvin hankala osa-alue tässä tutkielmassa ovat rajapintojen toteuttamiseen käytetty ohjelmakoodin määrä, sekä kehitystyöhön käytetty aika. Käytännössä näiden kahden tekijän osalta saatuja tuloksia ei voida järjestelmällisesti toistaa, mutta myöskään kyseisten tekijöiden painoarvo tutkielmassa toteutetussa vertailussa ei ole merkittävän suuri. 6.2 Testitulosten esittäminen Testejä varten suoritettiin siis yhteensä toistoa, joka tarkoittaa toistoa jokaista rajapintaa kohden. Kyseisistä testeistä saatiin tilastollisia tuloksia rajapintojen tiedonsiirtonopeudesta. 47

51 Tässä luvussa on esitetty myös rajapintojen toteutukseen vaadittujen ohjelmakoodirivien määrät, sekä jokaisen rajapinnan kehitystyöhön käytetty aika. Taulukko 1. Tiedonsiirtojen kokonaiskestot (KK) ja yhden tiedonsiirron keskiarvo (KA) oliota / toistoa oliota / toistoa yksinkertainen moniulotteinen yksinkertainen moniulotteinen FTP KK 130min 42s 131min 39s 135min 5s 138min 5s KA 0,784s 0,789s 0,810s 0,828s SOAP KK 12min 16s 21min 9s 89min 27s 162min 49s KA 0,073s 0,126s 0,536s 0,976s REST KK 1min 56s 2min 10s 16min 26s 17min 6s KA 0,011s 0,012s 0,098s 0,102s Rajapintojen suoriutumista tiedonsiirrosta eri testitapauksissa esitetään tiedonsiirtoihin kuluneena aikana. Taulukko 1 esittää jokaiselle rajapinnalle kaikista eri testitapauksista kaksi asiaa, jotka ovat kokonaiskesto (KK) tiedonsiirron toteuttamiseen, sekä keskiarvon (KA) yhden tiedonsiirron toteuttamiseen. Kokonaiskestoja esittäessä, tulokset on aina pyöristetty seuraavaan täyteen sekuntiin. Tämä ei vaikuta tuloksiin tai niiden tulkintaan merkittävästi, kun otetaan huomioon tulosten laaja vaihtelualue. 48

52 Taulukko 2. Yksittäisten tiedonsiirtojen minimi- ja maksimikestot oliota / toistoa oliota / toistoa yksinkertainen moniulotteinen yksinkertainen moniulotteinen FTP MAX 3,450s 3,813s 1,569s 1,934s MIN 0,548s 0,536s 0,559s 0,559s SOAP MAX 1,653s 2,851s 4,538s 9,249s MIN 0,030s 0,059s 0,272s 0,521s REST MAX 0,332s 0,524s 0,708s 0,593s MIN 0,003s 0,005s 0,036s 0,039s Tiedonsiirtojen kestojen suhteen on myös olennaista tieto yksittäisen tiedonsiirron maksimi- (MAX) ja minimikestosta (MIN). Taulukko 2 esittää jokaisen rajapinnan kaikkiin testitapauksiin yksittäisten tiedonsiirtojen keston, joissa on kestänyt eniten ja vähiten aikaa. Taulukkoon 2 on merkitty harmaalla taustalla kolme solua. Nämä kolme kohtaa nousevat tarkasteltaessa esille muista tuloksista erityisesti poikkeavina ja niiden huomioiminen on olennaista myös tuloksia käsiteltäessä. 49

53 Taulukko 3. Ohjelmakoodin määrä ja kehitystyöhön käytetty aika. Ohjelmakoodin määrä Kehitysaika FTP 437 loc 5h 22min SOAP 496 loc 4h 43min REST 443 loc 3h 16min Taulukko 3 esittää rajapintojen varsinaisten ohjelmakoodirivien määrän ja rajapinnan toiminnalliseksi saattamiseen käytetyn ajan. Ohjelmakoodiriveiksi on laskettu varsinaiset ohjelman toimintaan liittyvät rivit. Tyhjät rivit ja mahdolliset kommentit eivät kuulu mukaan rivimäärän laskentaan. 50

54 7 JOHTOPÄÄTÖKSET Tämä luku on jaettu kahteen kohtaan. Kohdassa 7.1 käydään läpi tutkielmassa saatuja tuloksia ja vastataan tutkimuskysymykseen. Tämän jälkeen kohdassa 7.2 pohditaan saatujen johtopäätösten sopivuutta reaalimaailman käyttötapauksiin. 7.1 Tulosten analysointi Testitulosten pohjalta tarkastellaan ensimmäiseksi kaikkien rajapintojen käyttäytyminen eri testitapauksissa yksi rajapinta kerrallaan. Samalla tuodaan esille ja käsitellään mahdolliset poikkeustapaukset, jotka tulevat ilmi yksittäisen rajapinnan testituloksista. FTP-rajapinnan tulokset ovat ennakko-odotusten vastaisia. Lähtökohtaisesti oletus on, että tietomäärän kasvaessa ja tietosisällön monimutkaistuessa, myös tiedonsiirtoon tarvittava aika kasvaa. Sen sijaan FTP-rajapinta kulutti tietojen siirtoon kaikissa neljässä testitapauksessa lähes saman verran aikaa. Tulosten yhtäläisyyteen yksi selitys on varsinaisella FTP-ohjelmalla tehtyyn siirtotiedoston lähettämiseen ja vastaanottamiseen kulutettu aika. Koska siirtotiedoston koko ei eri testitapauksissa vaihtele huomattavasti ja on muutenkin varsin pieni, kuluu näin ollen siirtotiedoston siirtämiseen lähes sama aika. Pienet erot syntyvät itse siirtotiedoston luomisesta ja lukemisesta. Kokonaiskestoon vaikuttaa FTP-rajapinnassa myös siirtotiedostoa lähettäessä ja tarkastaessa mahdollisesti tapahtuvat 0,1s viiveet, jotka syntyvät kun tarkastellaan onko siirtotiedosto valmis lähetettäväksi tai luettavaksi. On myös otettava huomioon, että tämän tutkielman testeissä FTP-rajapinta käyttäytyy samalla tavoin kuin SOAP- ja REST rajapinnat. Tämä tarkoittaa sitä, että FTP-rajapinta luo uuden siirtotiedoston vasta kun edellinen on kokonaan lähetetty. Tiedostojen siirtäminen tapahtuisi todennäköisesti nopeammin, jos siirtotiedostoja luotaisiin niin nopeasti kuin mahdollista ja useampi tiedosto siirrettäisiin yhdellä 51

55 yhteyden avaamisella. Toteutettu testaustapa vastaa kuitenkin paremmin reaalimaailman tilannetta, jossa todennäköisesti kaikki tiedonsiirtoa eivät kuitenkaan tapahtuisi täsmälleen peräkkäin. Kaikista vertailtavista rajapinnoista SOAP-rajapinnan tulokset käyttäytyivät eniten tavalla, jota voisi yleisesti odottaa. Eli yksinkertaisten olioiden siirtäminen oli nopeampaa kuin moniulotteisten olioiden. Toinen odotettu tulos oli, että olion siirrossa kuluu pidempi aika kuin 1000 olion siirrossa. Myös tämä piti paikkansa, ero siirtonopeudessa pienemmän ja suuremman tietomäärän välillä kasvoi huomattavan suureksi. SOAP-rajapinnan tiedonsiirtojen kokonaiskeston lähes tuplaantuminen voi selittyä rajapinnan käyttämästä tietoformaatista. Kaikki oliot muutetaan viestiä lähettäessä XML-muotoon ja viestin vastaanottamisen jälkeen puretaan takaisin olioiksi. Olion muuntaminen XML-muotoiseksi viestiksi taas on raskasta ja muuttuu sitä raskaammaksi, mitä enemmän oliolla on ominaisuuksia. Näin ollen moniulotteiset oliot, jotka sisältävät enemmän tietoa ja ominaisuuksia, ovat huomattavasti raskaampia muuntaa XML-muotoon, kuin yksinkertaiset oliot. Myös REST-rajapinnan tulokset mukailevat suurimmaksi osaksi yleisiä odotuksia. Suurempi tietomäärä vie huomattavasti enemmän aikaa kuin pieni tietomäärä ja yksinkertaisten olioiden siirto tapahtuu nopeammin kuin moniulotteisten. Jos kuitenkin vertaillaan yksinkertaisten ja moniulotteisten olioiden siirtonopeuksia keskenään tarkemmin, niin huomataan että niiden välillä ei ole suurta eroa. Pienemmän tietomäärän testitapauksessa ero on noin 10% luokkaa ja suuremmalla tietomäärällä testattaessa 5% luokkaa. REST-rajapinnan siirtonopeuksien pienet erot yksinkertaisten ja moniulotteisten olioiden siirtoa verratessa ilmaisevat viestien enkoodaamisen ja dekoodaamisen tehokkuutta. Tämä tarkoittaa, että olioiden muuntaminen JSON-muotoon säilyttää tehokkuutensa hyvin myös moniulotteisten olioiden kanssa toimiessa. Näin ollen erot eri testitapausten välillä jäävät vähäisiksi ja pienenevät entisestään tietomäärän kasvaessa. 52

56 Tässä tutkielmassa tiedonsiirtorajapintoja vertaillaan tehokkuuden suhteen. Tehokkuuden mittareista suoritusnopeus on yksiselitteinen ja määrittelee rajapinnan toiminnallisen tehokkuuden suhteellisen hyvin. Kaikkien rajapintojen tiedonsiirtoon käytettyjä aikoja vertaillessa, REST-rajapinta nousee selvästi muita rajapintoja paremmaksi. SOAP-rajapinta suoriutuu kohtalaisesti ja on toiseksi nopein kaikissa muissa paitsi suuremmalla tietomäärällä moniulotteisten olioiden kanssa, jolloin se putoaa viimeiseksi. FTP-rajapinta suoriutuu kaikista testitilanteista melkein yhtä hitaasti, mutta tämän myötä se on myös SOAP-rajapintaa nopeampi raskaimmassa testissä. Erot rajapintojen nopeuksissa selittyvät REST- ja SOAP-rajapintojen osalta todennäköisesti viestien muodostamiseen kulutetulla ajalla. REST-rajapinnan käyttämä JSON-muotoinen viesti on tehokkaampi rakentaa ja purkaa, kuin SOAPrajapinnan käyttämä XML-muotoisen viesti. FTP-rajapinnan jääminen useammassa testissä huomattavan paljon muita hitaammaksi selittyy suurimmaksi osaksi varsinaisen tiedonsiirron hitaudella. Pääasiallisesti itse siirtotiedosto on nopea luoda ja lukea, mutta siirron toteuttava SFTP-ohjelma kuluttaa paljon aikaa yhteyden muodostamiseen ja tiedoston siirtämiseen. Rajapintojen tiedonsiirtonopeuksiin liittyvistä testituloksista nousee esille kahden rajapinnan osalta painoarvoltaan pieni, mutta kuitenkin huomioitava asia. Kun tarkastellaan eri testitapausten yksittäisten tiedonsiirtojen minimi- ja maksimikestoja, voidaan huomata kolme poikkeamaa. FTP-rajapinnan pienen tietomäärän ja yksinkertaisten sekä moniulotteisten olioiden testitapauksissa, maksimikesto on huomattavasti suurempi kuin vastaavissa suuremman tietomäärän testeissä. Sama poikkeama löytyy myös REST-rajapinnan suuren tietomäärän yksinkertaisten olioiden maksimikestosta, joka on odotusten vastaisesti moniulotteisten olioiden testiä suurempi. Koska kyseiset poikkeamat ovat kuitenkin kaukana vastaavien testitapausten yksittäiseen tiedonsiirtoon käytetyn ajan keskiarvosta, voidaan olettaa kyseessä olevan ainoastaan yksittäinen tai harvoin tapahtuva poikkeama. Tällaiset yksittäiset poikkeamat eivät vaikuta testitulosten luotettavuuteen. Jos poikkeamia olisi paljon 53

57 enemmän, ne vaikuttaisivat myös huomattavassa määrin rajapintojen testitapausten kokonaiskestoihin ja keskiarvoihin. Ohjelmakoodin määrän mainittiin olevan yksi vähäisemmistä rajapinnan tehokkuutta mittaavista ominaisuuksista. Tässä tutkielmassa rajapintojen ohjelmakoodirivien määrät ovat erittäin lähellä toisiaan. Näin ollen, varsinkin koska kyseessä on painoarvoltaan vähäpätöisempi mittari, ohjelmakoodin määrällä ei ole merkitystä tämän tutkielman lopputulokseen. Toinen pienemmällä painoarvolla mukaan otettu tehokkuuden mittari oli rajapinnan toiminnalliseksi kehittämiseen kulutettu aika. Kehitysaika on joka tapauksessa vain suuntaa-antava, koska rajapinnat on toteutettu pääasiallisesti tiedonsiirtonopeuden testaamista varten ja ovat näin ollen laajuudeltaan todella pieniä. Tutkielmassa toteutetuista rajapinnoista REST-rajapinta valmistui nopeimmin, SOAP-rajapinta toiseksi nopeimmin ja eniten aikaa kului FTP-rajapinnan toimintavalmiuden saavuttamiseen. Kehitystyön osalta REST- ja SOAP- rajapinnat olivat hyvin suoraviivaisia kehittää. Yleisesti ottaen kyseiset rajapinnat käyttävät erillistä sovelluspalvelinta. Tässä tutkielmassa erillisen sovelluspalvelimen käyttäminen on kuitenkin päätetty jättää pois ja rajapinnat toteuttavat itse palvelinpään, joka tarjoaa tietoliikenteen tarvitsemat palvelut. Tämä todennäköisesti lisäsi kyseisten rajapintojen kehitysaikaa, mutta ei merkittävästi. SOAP-rajapinnan osalta viestejä vastaanottava pää oli tämän tutkielman osalta hieman, REST-rajapinnan vastaavaa, hitaampi kehittää. FTP-rajapinnan kehitystyö oli siirtotiedoston luomisesta ja purkamisesta vastaavien ohjelman osien osalta yksinkertaista, mutta silti työlästä ja aikaa vievää. Enemmän aikaa kului kuitenkin itse tiedonsiirron toteuttamiseen. Suurin haaste oli saada varsinainen FTP-siirto alkamaan mahdollisimman pian siirtotiedoston valmistumisen jälkeen. Sama ongelma oli vastaanottavassa päässä, jossa siirtotiedoston purkamista ei saanut aloittaa ennen kuin tiedosto oli varmasti siirtynyt kokonaan. 54

58 Kun kaikista tutkielmassa käytetyistä rajapinnan tiedonsiirtoon soveltuvuuden mittareista saadut tulokset yhdistetään, voidaan rajapinnat asettaa paremmuusjärjestykseen seuraavasti. REST-rajapinta suoriutui kaikilla osa-alueilla muita paremmin tai vähintään yhtä hyvin, joten se on tutkielmassa vertailluista rajapinnoista tehokkain. SOAP-rajapinta jäi selvästi jälkeen REST-rajapinnan siirtonopeudesta, mutta oli kuitenkin pääosin FTP-rajapintaa tehokkaampi. FTPrajapinta suoriutui suurimmasta osasta mittareita huonoiten kaikista kolmesta rajapinnasta. 7.2 Käytännön sovellukset Tutkielman tavoite oli löytää kolmesta vertailtavasta tiedonsiirtorajapinnasta tehokkain, jossa tehokkuudella tarkoitetaan tämän tutkielman osalta pääasiallisesti tiedonsiirtonopeutta. Vertailun vuoksi kaikista rajapinnoista käydään kuitenkin läpi yksi käytännön tilanne, jossa kyseinen rajapinta on hyödyllinen ja mahdollisesti myös parhaiten tilanteeseen soveltuva. Esimerkit eivät ole täysin yksityiskohtaisia ongelmia vaan pikemminkin yleisiä tilanteita, joissa tietyn rajapinnan käytöstä voidaan hyötyä. FTP-rajapinnan vahvuus ei selvästikään ole usean peräkkäisen ja tietomäärältään suhteellisen pienen viestin lähettämisessä. Sen sijaan sen käyttäminen suurempien tietomäärien siirtämiseen harvalla aikavälillä voisi olla huomattavasti hyödyllisempi käyttökohde. Tällaisten eräajojen suorittamiseen voi joissakin tapauksissa olla pakko käyttää FTP-rajapintaa, varsinkin jos toimitaan hieman vanhempien laitteiden ja ohjelmistojen parissa. Tällaisissa tapauksissa voi esimerkiksi siirtotiedoston käsittelevä ohjelmisto olla jo olemassa, jolloin säästytään osittain ylimääräiseltä kehitystyöltä. SOAP-rajapinnan käytöstä hyödytään eniten, kun tarvitaan varmuus viestien rakenteesta ja sisällöstä. Rajapinnan käyttämien XML-viestien rakenteen ja sisällön varmistaminen on helppoa, joskaan ei kovin nopeaa. Näin ollen SOAP-rajapinta 55

59 soveltuu hyvin tilanteisiin, joissa siirretään jatkuvasti tietoa, mutta viestien sisällön oikeellisuus on nopeutta tärkeämpää. REST-rajapinta on parhaimmillaan kun tarvitaan nopeutta. Tällainen tilanne on esimerkiksi kun kaksi eri palvelimilla toimivaa ohjelmistoa tarvitsevat tiedon siitä, missä tilassa toinen ohjelmisto on. Tällöin tulee kuitenkin viestien sisällön tarkastaminen toteuttaa erikseen. 56

60 8 YHTEENVETO Tässä tutkielmassa käsitellään tiedonsiirtorajapintoja. Koska tiedonsiirtorajapintoja on olemassa useita erilaisia, on tähän tutkielmaan valittu ainoastaan kolme rajapintaa. Näistä rajapinnoista SOAP- ja REST-rajapinnat edustavat nykyaikaisia rajapintoja, kun taas FTP-rajapinta on valittu mukaan tuomaan vertailupohjaa hieman vanhemman teknologian rajapintoihin. Rajapinnat ovat yleisesti ottaen ohjelmistokutsujen lähettämistä ja vastaanottamista määriteltyjen ohjelmistojen välillä. Niiden käyttötarkoitus on tehdä ohjelmistojen välisestä viestinnästä ja uusien ohjelmistojen kehittämisestä helpompaa. Varsinkin uusien ohjelmistojen integrointi olemassa oleviin tulee helpommaksi rajapintoja hyödyntämällä. Sulauttamalla rajapintoja yhteen, voidaan luoda uusia laajempia yhdistelmärajapintoja. Rajapinnat voivat myös toimia suurempien tietomäärien siirtämisessä ohjelmistojen välillä, yksittäisten ohjelmistokutsujen sijaan. Rajapintojen käyttö, varsinkin julkisten rajapintojen, on lisääntynyt huomattavasti teknologian kehityksen myötä. Yhä useammat yritykset tarjoavat ohjelmistoihinsa julkisia rajapintoja, joita hyödyntämällä ohjelmistojen kehittäjät luovat täysin uusia sovelluksia. Rajapintoja käyttäessä on kuitenkin erityisen tärkeää valita oikea rajapinta tilannekohtaisesti. Joskus tarvitaan tiukasti määriteltyä ja verifioitua tietoa, toiste tarve voi olla mahdollisimman nopealle tiedonsiirtonopeudelle. Teknisesti ottaen tutkielmassa vertailtavat rajapinnat toimivat seuraavasti. SOAPrajapinta käyttää viesteissään määrittelynsä mukaisesti XML-muotoa. RESTrajapinnan viestit ovat tässä tutkielmassa JSON-muotoisia. Molemmat näistä rajapinnoista on valittu toimimaan HTTP-yhteyden välityksellä. FTP-rajapinta siirtää FTP-yhteyttä käyttäen siirtotiedostoja, jotka ovat tässä tutkielmassa pelkkiä tekstitiedostoja. Tutkielmaan vertailtavaksi valituista rajapinnoista selvitetään, mikä rajapinta on tehokkain tiedonsiirron kannalta. Tehokkuuden mittareista tärkein on tiedonsiirtonopeus. Muita tehokkuuden mittareita ovat ohjelmakoodirivien määrä ja 57

61 rajapinnan toiminnalliseksi kehittämiseen kulunut aika, mutta näiden mittareiden painoarvo on huomattavasti pienempi. Mittareiden painoarvot jakaantuvat tarkemmin seuraavasti: tiedonsiirtonopeus 70%, ohjelmakoodirivien määrä 10% ja kehittämiseen kulunut aika 20%. Tämä johtuu pääosin siitä, että tässä tutkielmassa rajapintoja tarkastellaan eniten toteuttamalla varsinaisia tiedonsiirtoja erilaisilla testitapauksilla, jolloin vertailukelpoista materiaalia saadaan eniten tiedonsiirtonopeuksista. Kvantitatiivisen tutkimuksen käyttäminen tutkielman toteuttamiseen, rajapintojen kehittämiseen käytetystä ajoista ja ohjelmakoodirivien määristä useilla eri testihenkilöillä, olisi myös erittäin hankalaa toteuttaa. Tällöin saatuihin tuloksiin vaikuttaisi todella monia tekijöitä eri testihenkilöiden välillä. Tässä tutkielmassa toteutetuista testitapauksista ja rajapinnoista kerättyjen tulosten perusteella voidaan todeta, että vertailtavista rajapinnoista REST-rajapinta oli ylivoimaisesti paras rajapinta tiedonsiirtoon. SOAP-rajapinta oli saatujen tulosten perusteella toiseksi tehokkain ja FTP-rajapinta jäi huonoimmaksi. Kaikilla vertailluilla rajapinnoilla on kuitenkin olemassa tilanteita reaalimaailmassa, jolloin ne soveltuvat parhaiten tiedonsiirtorajapinnaksi. Tutkielman testeissä käytettyjen rajapintojen ja muiden ohjelmien, jotka toteutettiin tutkielmaa varten, lähdekoodit ovat saatavilla osoitteesta ( ). Testitapaukset ja asetelmat on myös kuvattu mahdollisimman tarkasti, jotta tutkielman jäljitettävyys säilyisi mahdollisimman hyvänä. [11] Jatkotutkimuksia, joita tämän tutkielman pohjalta voidaan tehdä, olisivat ainakin seuraavia: Saman tutkimuksen toteuttaminen huomattavasti suuremman mittakaavan testirajapinnoilla ja mahdollisesti käyttäen useita eri kehittäjiä. Tiedonsiirtorajapintojen tutkiminen tietojen validointiin ja tietoturvaan keskittyen. Pelkästään REST-rajapintaan keskittyvä tutkimus, joka käsittelee useampia eri osa-alueita. 58

62 VIITTEET [1] de Souza C. R. B., et al. (2004): Sometimes You Need to See Through Walls A Field Study of Application Programming Interfaces. Proceedings of the ACM Conference on Computer-Supported Cooperative Work, Chicago, IL, USA, [2] de Souza C. R. B., et al. (2004): How a Good Software Practice thwarts Collaboration The Multiple roles of APIs in Software Development. Foundations of Software Engineering, Newport Beach, CA, USA, [3] Embracing the Differences: Inside the Netflix API Redesign, The Netflix Tech Blog, ( ) [4] Heath S. (2003): Embedded Systems Design. Newnes, An imprint of Elsevier Science, Oxford. [5] Fowler, M. (2002): Public versus Published Interfaces. IEEE Software, 19(2), [6] Zang N., Rosson M., Nasser V. (2008): Mashups: Who? What? Why? Proceedings of the ACM Conference on Human Factors in Computing Systems (CHI), Florence, Italy, [7] Soylu A. M., et al. (2012): Mashups by Orchestration and Widget-based Personal Environments: Key Challenges, Solution Strategies, and an Application, Program, 46(4), [8] Tanaka M., Kume T., Matsuo A. (2011): Web API Creation for Enterprise Mashup IEEE World Congress on Services (SERVICES), Washington, DC, USA,

63 [9] Google Inc. (2016) Google Maps JavaScript API pt/ ( ) [10] OpenWeatherMap, Inc. (2016) OpenWeatherMap API ( ) [11] Tutkielmaa varten toteutettujen rajapintojen ja ohjelmien lähdekoodit ( )