TCA ja TSA web-arkkitehtuurit

Mainio ajatuksia herättävä opetusartikkeli web-arkkitehtuureista: (webapps)

Artikkeli ei käsittele ”muotitermejä” MVC, MVVM jne, vaan keskittyy kuvaamaan sovelluksen eri osien sijaintia ja yhteistyötä, ja tekee sen hyvin selkeästi. Jatkamme tästä aineesta parin blogin verran.

Kevyt client -arkkitehtuuri (thin client architecture, TCA) ja tavallaan sen vastakohta, kevyt server -arkkitehtuuri (thin server architecture, TSA) käydään läpi. Käsittelemme tässä blogissa näiden arkkitehtuurien käytännön eroja.

Sivujen lataamisnopeudessa ei ole suuria eroja, koska likimain sama määrä dataa siirtyy kummassakin tapauksessa clientin ja serverin väliä. TCA:ssa sivu rakennetaan (esim. Javalla) kerralla serverilla ja lähetetään clientille. Sivun rakentaminen on hitaampaa TSA:ssa clientilla, jossa tyypillisesti ladataan HTML-sivu ja sivulla näytettävä data eri palvelukutsuissa. Sivu on kuitenkin suoraan HTML:aa eikä prosessointia tarvita serverilla ja pienissä erissä lataaminen tuo keveyden vaikutelman käyttäjälle. Nopeuserot ovat tässä minimaalisia.

Ajax-toiminnot ovat välttämättömyys, olipa kyse kummasta arkkitehtuurista hyvänsä. Molemmissa tämä toimii ongelmitta. TSA on tässä selvästi yksinkertaisempi rakenne, koska siinä käytetään vain Ajaxia datan tuomiseen sivulla. TCA puolestaan tuo yleensä aloitusdatan sivun latautumisen yhteydessä. Yksinkertaisuus on tässä etu TSA:lle; A on aina yksinkertaisempi kuin A + B, olivatpa A ja B kuinka hyviä tekniikoita tahansa. Toki TCA:ssakin voidaan käyttää vain Ajaxia datan siirtoon, mutta useimmat TCA-frameworkit juuri perustuvat koko sivun generointiin serverilla.

TSAn ongelma voi olla, kuten em. artikkelissa todetaan, tehon tarve clientilla, jos päätelaite on mobiili. Lisääntyvä kuorma tulee sovelluslogiikasta, joka on tässä clientilla. Tätä haittaa voidaan kompensoida suunnittelulla, ja laskentaa voidaan toki toteuttaa myös tilattomassa serveripäässä, jos nopeus on ongelma. Suurempi tekijä tehontarpeen kannalta clientilla on yleensä tolkuton ja kritiikitön Javascript-kirjastojen käyttö, ne hidastavat sovellusta ja niiden osuus ladatattavasta sivun datamäärästä on yllättävän suuri. Se on ongelma niin TSA- kuin TCA-ratkaisuissa. Datan hallinta selaimella on suunnittelun ydinkohtia, kaikkea mahdollista dataa ei pidä tuoda kerralla clientille, vaan sitä mukaa kuin käyttäjä tarvitsee.

Vielä pahempi TCA:n ongelma on tilan hallita. TSA:ssa sovelluslogiikka ja sovelluksen tila (ts. sovelluksen hallitsema data) on selaimessa, TCA:ssa ne ovat serverilla. Näin käyttäjäkunnan määrän kasvaessa, sovelluksesta riippuen jossain vaiheessa tämä alkaa näkyä selvästi hitautena TCA-ratkaisuissa. TSA:n kutsut ovat serveripäässä tilattomia, ja kuormittavat serveria vähän. Hyvä esimerkki TSA-ratkaisujen toteuttajasta ja käyttäjästä on Google, jonka kaikki nykyisin käytettävät web-tekniikat ovat tyyppiä TSA. Jos jokin yritys tietää web-sovellusten kuormasta, niin Google. Tämä skaalautuvuus on pysyvä etu TSA:lle suhteessa TCA:han.

TCA:n perusetuna on pidetty sovelluksen koodin sijoittuminen piiloon serverille. Tämä ero kutistuu kuitenkin hyvällä TSAn rakenteen suunnittelulla hyvin pieneksi. Tilatonta businesslogiikkaa käytetään palvelukutsujen yhteydessä aivan kuten TCA-rakenteessa. On myös mahdollista tehdä laskentaa serverilla: kutsu ja parametrit palvelimelle, laskenta ja paluuarvot clientille. Näin laskenta tapahtuu piilossa palvelimella. Riippumatta arkkitehtuurista businesslogiikka on parasta sijoittaa palvelimelle.

Seuraavassa blogissa sepät käyvät läpi tunnetuimmat arkkitehtuurimallien lyhenteet, kuten MVC, MVVM ja MCP.