Tappavatko API:t ESB:n?

Määritelläänpä alkuun otsikon termit, jotta ymmärrämme mistä puhutaan.

API (Application Programming Interface) on jo pitkään käytössä ollut termi ohjelmistorajapinnoille.

Viime aikoina termi on vakiintunut tarkoittamaan RESTful Web Servicea eli REST API:a. Tyypillisesti REST API käyttää joko json- tai xml-formaattia tietojen välittämiseen. REST API:t ovat nousseet suosioon, koska ne ovat helppoja ja suoraviivaisia käyttää verrattuna edellisen sukupolven monimutkaisiin SOAP Web Service -rajapintoihin.

ESB (Enterprise Service Bus) puolestaan on arkkitehtuurimalli.

Usein törmää kirjoituksiin, joissa ESB rinnastetaan työkaluksi, jolla on tyypillisesti graafinen käyttöliittymä kehitystyötä varten. On totta, että useat ohjelmistotoimittajat ovat rakentaneet erilaisia työkaluja, joita markkinoivat ESB:nä. Nämä tuotteet tavallisesti implementoivat palveluarkkitehtuurissa käytetyn viestiväylän. Toiset tekevät sen paremmin ja toiset huonommin.

Tämän arkkitehtuurimallin avulla vältetään niin sanottu tiukka sidonta (tight coupling), jossa toiseen järjestelmään kohdistunut muutos vaikuttaa myös siihen tiukasti integroituneisiin järjestelmiin. Vertaa tilanne jossa yhden API:n muutos vaikuttaa kymmeniin siihen integroituneisiin järjestelmiin kooditasolla, koska ne on tiukasti sidottu kyseiseen API:in. Vastaavasti löyhä sidonta (loose coupling) saavutetaan abstraktiokerroksen (esim. viestiväylä) avulla, jolloin integroituvien järjestelmien ei tarvitse olla tietoisia toisistaan.

API:en myötä yksi asia muuttuu

Rajapintojen tuottaminen ja kuluttaminen on monta kertaluokkaa helpompaa kuin aikaisemmin.

REST API:sta on tullut koko teollisuuden hyväksymä ja omaksuma tapa. Samalla myös ohjelmistotoimittajat ovat entistä enemmän kehittäneet REST API-rajapintoja tuotteisiinsa. Pilvimaailmassa REST API on de facto -tapa kommunikoida sovellusten välillä. Useat ohjelmointikielet tarjoavat jo suoraan hyvät työkalut json-muotoisen datan käsittelyyn ja API:en kutsumiseen.

Nyt kun integroituminen järjestelmien välillä on helpompaa kuin koskaan aikaisemmin, niin houkutus rakentaa suoria point-to-point -integraatioita järjestelmien välille on luonnollisesti suurempi. Keskitetyt integraatioväylät ja ESB:t nähdään usein kankeina ja hitaina kehittäjänäkökulmasta. Ja näin tilanne usein onkin, kun käytössä on vuosituhannen vaihteen molemmin puolin EAI-tarkoituksiin kehitettyjä integraatioalustoja.

Projektin tai hankkeen näkökulmasta on helpompi tiukasti integroitua toiseen järjestelmään, kuin miettiä kokonaisuutta arkkitehtuurin tai IT-strategian näkökulmasta.

Usein sovellustoimittajan kaupalliset intressit ovat ristiriidassa tehokkaan integraatiopalvelun kanssa. Ehdottavatpa jotkin tahot jopa, että integraatioalusta koodataan alusta alkaen asiakkaalle sovellustoimittajan toimesta.

Näin saadaan luotua tehokas, mutta asiakkaan kannalta tarpeeton, toimittajalukko.

Suosittelen kuitenkin ensin tutustumaan vaihtoehtoihin esimerkiksi avoimen lähdekoodin ratkaisuista, ennen kuin organisaatiolle dedikoitua integraatioratkaisua ruvetaan rakentamaan räätälikoodina.

Tarve kokonaisuuden hallinnalle ja ymmärrykselle ei API:en myötä katoa. Päinvastoin entistä verkottuneempi maailma tarvitsee monitorointia ja riippuvuuksien hallintaa. API:en välinen integraatio ja orkestrointi eivät jatkossakaan tapahdu itsestään. Yhden sovellustoimittajan näkökulma kokonaisuuteen on edelleen pieni verrattuna asiakkaan kokonaisnäkökulmaan omasta arkkitehtuuristaan.

Edelleen tulee olemaan valmisohjelmistoja ja pilvipalveluita, jotka vaativat integraatiokyvykkyyttä organisaatiotasolla.

Tappavatko API:t sitten ESB:in?

Tällä hetkellä käsite ESB kärsii inflaatiosta ja monet tahot jo tanssivat sen haudalla, mutta API:t eivät poista tarvetta integraatiokyvykkyydelle, monitoroinnille, kokonaisuuden ymmärrykselle ja hallinnalle, orkestraatioille ja fiksulle arkkitehtuurille. Uskon, että ESB arkkitehtuurimallina on henkitoreissaan vielä pitkään ennen kuin se syntyy uudelleen eri nimellä ratkaisemaan API-maailman uusvanhoja ongelmia.