Rajapintojen käyttö tiedonsiirrossa
Harri Pitkänen
Pro gradu –tutkielma
Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede
Joulukuu 2016
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.
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
1
Sisällysluettelo
1 Johdanto ... 2
2 Rajapintojen teoria ... 4
2.1 Ohjelmointirajapinnat ... 5
2.1.1 Ohjelmointirajapintojen määritelmä ... 6
2.1.2 Ohjelmointirajapintojen käyttötarkoitukset ... 10
2.1.3 Ohjelmointirajapintojen hyödyt ... 18
2.1.4 Ohjelmointirajapintojen haitat ... 19
2.2 Yhdistelmärajapinnat ... 20
2.2.1 Yhdistelmärajapintojen määritelmä ... 21
2.2.2 Yhdistelmärajapintojen käyttötarkoitukset ... 22
2.2.3 Yhdistelmärajapintojen hyödyt ... 24
2.2.4 Yhdistelmärajapintojen haitat ... 25
2.3 Teoriaosan yhteenveto ... 25
3 Vertailtavien rajapintojen tekninen kuvaus ... 28
3.1 FTP-rajapinta ... 28
3.2 SOAP-rajapinta ... 30
3.3 REST-rajapinta ... 32
4 Tutkimuskysymyksen esittäminen ... 36
5 Vertailun toteutus ... 38
6 Tulokset ... 46
6.1 Testien luotettavuus ja toistettavuus ... 46
6.2 Testitulosten esittäminen ... 47
7 Johtopäätökset ... 51
7.1 Tulosten analysointi ... 51
7.2 Käytännön sovellukset ... 55
8 Yhteenveto ... 57
2
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
3
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.
4
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
5
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, 2.1.1 ohjelmointirajapinnan yleinen määritelmä, 2.1.2 ohjelmointirajapintojen yleisimmät käyttötarkoitukset, 2.1.3 ohjelmointirajapintojen käytöstä saavutetut hyödyt ja 2.1.4 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
6
kommunikoinnin. Tätä määritelmää on ehkä helpompi ymmärtää tarkastelemalla luvussa 2.1.2 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.
2.1.1 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
7
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.
8
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ä.
9
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
10
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.
2.1.2 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.
2.1.2.1 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
11
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.
2.1.2.2 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
12
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.
2.1.2.3 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
13
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 one- size-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].
14 2.1.2.4 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
15
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.
2.1.2.5 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].
16
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.
17
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.
18
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.
2.1.3.1 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ä.
19
2.1.3.2 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.
2.1.4 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.
2.1.4.1 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.
2.1.4.2 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
20
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, 2.2.1 yhdistelmärajapinnan määritelmä, 2.2.2 yhdistelmärajapintojen yleisimmät käyttötarkoitukset, 2.2.3 yhdistelmärajapintojen käytöstä saavutetut hyödyt ja 2.2.4 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 2.2.2 esitetään yhdistelmärajapintojen käyttötarkoituksia esimerkkien avulla, jotka osaltaan helpottavat yhdistelmärajapinnan käsitteen ymmärtämistä.
21
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.
2.2.1 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].
22
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].
2.2.2 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.
2.2.2.1 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.
23
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].
2.2.2.2 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].
24
Kuva 5 Esimerkki säätietojen ja karttapalvelun yhdistämisestä (http://owm.io/googlemapsapi)
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]
2.2.3 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.
25
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.
2.2.4 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
26
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.
27
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, ohjelmointi- ja yhdistelmärajapintojen, käytöstä ohjelmistotuotannon tehostamisessa, löytyy tulevaisuuden tutkimuskohteita.
28
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 REST- rajapinnan (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 TCP- porttia 20.
29
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
30
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 FTP- protokolla 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 1998. 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
31
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ä.
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
Kuva 6. Havainnollistus SOAP-viestin rakenteesta.
32
pystyä toteuttamaan verkkotuki ja XML-jäsennin, jotta sillä pystytään toteuttamaan SOAP-rajapinta.
3.3 REST-rajapinta
REST-arkkitehtuurin historia alkaa vuodesta 2000. 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 REST- arkkitehtuuria (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
33
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
34
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.
35
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.
36
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
37
täsmällinen tulosjoukko, jota laskennallisesti tarkastelemalla saadaan vastaus tutkimuskysymykseen.
38
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 0.2.0 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
