Harri J. Talvitie | 21.10.2003

Web services -alkuinnostus lähti liikkeelle kevyestä ja yksinkertaisesta perusmallista: XML-rakenteisten sanomien liikuttelua internetin yli ja vieläpä sen "kaikille tutun" HTTP-kuljetusprotokollan päällä.

Vihdoinkin järjestelmien hienojakoista yhdistelyä, vihdoinkin eroon valmistajasidonnaisista ratkaisuista! Tai konkreettisemmin: "Haloo, sinä puolitutun kumppanimme middleware: tässä asiakas ja tuossa tilaus. Hoida homma kotiin!".

Näppärä visio, mutta muutaman vuoden odottelun jälkeen konsepti on alkanut epäilyttää monia. Eihän sovellusten integrointi webbi-XML:n it-ihmemaailmassakaan pelkkää palikkaleikkiä toki ole.

Monen pettymyksen ja viivytyksen jälkeen epäluulo ja varovaisuus on perusteltua: tekniikkarintamalla ei ole kertynyt kypsyyttä, konsensukseen on edetty hitaasti haparoiden.

Konseptin uskottavuutta on entisestään rasittanut markkinoinnin ja todellisuuden huima kuilu. Samalla kun seminaareissa esitetään utopioita ja federaatioita, arkitodellisuus on edelleen askeettista SOAP-sähkösanomien epävarmaa kuljettelua.

Oikeasti hyödyllisten ja järkevällä työmäärällä rakennettavien sekä ylläpidettävien web-sovelluskokonaisuuksien vaatimat lukuisat laajennukset ovat vasta uunituoreita - tai suunnittelupöydillä pahasti kesken. Toteutuksista puhumattakaan.

Duettona improvisoiden vai kapellimestarin partituurein?

Ruohonjuuritasolla työskenteleville ohjelmistoammattilaisille web services -tekniikoiden anti on rajoittunut pikkukokeiluihin ja varovaiseen ensitutustumiseen. Kehitysvälineiden näkökulmasta web services on vain uusi etäkutsutapa vanhojen rinnalla.

Laajimmin yleistynyt web-sovellustekniikka SOAP määrittelee lähinnä vain kirjekuoren: osoitetiedot ja sisään sanoma.

Kusti polkee ja web services vie perille, mutta miten sujuvat jatkot? Mitenkäs itse tilaus sitten käsitellään? Miten hoidetaan poikkeukset ja erikoistapaukset?

Sanomaliikenteen turvallista ja ennakoitavaa kuljetusta varten tarvitaan kehittynyt koneisto.

Web-sovellusviestintä voi yksinkertaisimmillaan olla helppoa: sanoma pisteestä A pisteeseen B ja kuittaus takaisin. Mutkikkaammissa sovelluksissa pallotteluun osallistuu useita osapuolia, joten arkkitehtuurin tulisi hallita esimerkiksi hajautettujen tapahtumien peruutus tai vahvistus.

Turvattu ja hallittu sanomaliikenne ei yksinään riitä. Viestien pohjalta on synnyttävä kaikkien hyväksymä tai edes ymmärtämä lopputulos: tavaran siirto varastosta asiakkaalle tai tieto toimituksen viiväs­tymisestä.

Web-sovelluspalveluihin sovitetut liiketoimintaprosessit etukäteen sovittuine työvaiheineen ja monivaiheisine kulkureitteineen ovat oma maailmansa, joiden käsittelyssä lipsutaan peruskehittäjän reviiriltä astetta rankemmille arkkitehtuurivesille kuten BPEL-protokollan (Business Process Execution Language) ja BizTalkin kaltaisten tuotteiden syövereihin.

Rattaistoja ja rakennusohjeita

Oman web services -konseptin kauppaamisesta on muodostunut it-taloille missio.

Haasteena on käännyttää talous- ja tekniikkaväki ja vakuuttaa siinä sivussa media ja analyytikot. Kaikissa eri tekniikkaleireissä rakennetaan nyt välineiden ja määritysten lisäksi kilvan katu-uskottavia web-sovellusarkkitehtuureja.

Tekniikkafanaatikoille tarjotaan huimasti opiskeltavaa: jokaisella itseään kunnioittavalla infrastruktuuritoimittajalla on vähintään kirjastollinen web-sovellusmäärittelyjä ja arkullinen arkkitehtuureja.

Minkä näistä nyt valitsisin.. ?