Coulouris määritteli hajautetut järjestelmät "järjestelmiksi, joissa tietokoneverkossa olevat laitteisto- ja/tai ohjelmistokomponentit kommunikoivat ja koordinoivat toimintaansa vaihtamalla viestejä".
Tästä konseptista on tullut suosittu viime vuosina useiden tekijöiden vuoksi. Ensimmäinen tekijä, joka edisti hajautettujen järjestelmien kehitystä, oli nopeiden paikallisten verkkojen syntyminen. Toinen tärkeä tekijä oli henkilökohtaisten tietokoneiden suorituskyvyn tekninen kehitys ja hajautettuja sovelluksia tukevien ohjelmistojen kehittäminen. Hajautetut järjestelmät liittyvät Webin ja Internetin käsitteeseen. Webin kehityksen ja uusien alueiden, vuorovaikutusten, tarpeiden ja sovellusten ilmaantumisen myötä Web 2.0:n käsite syntyy. Tim O'Reilly loi tämän termin vuonna 2004 viittaamaan verkon historian toiseen sukupolveen, joka perustuu käyttäjäyhteisöihin ja erityisiin palveluihin, kuten sosiaalisiin verkostoihin, blogeihin, wikeihin tai folksonomioihin, jotka kannustavat yhteistyöhön ja ketterään. tietojen vaihto käyttäjien välillä.
Ensimmäiset arkkitehtuurit, joita voidaan pitää palvelukeskeisinä (SOA), perustuivat CORBA:han (Common Object Request Broker Architecture), joka toimi abstraktikerroksena arkkitehtuurin eri elementtien yhdistämiseksi ja palveluiden rakentamiseksi. Muita varhaisia tekniikoita olivat DCOM (Distributed Component Object Model) tai RPC (Remote Procedure Protocol). Tarve suunnitella ja toteuttaa hajautettuja järjestelmiä Webissä tehokkaasti tuo mukanaan useita haasteita, joista osa keskittyy itse kehittämiseen (suorituskyky, käyttökokemus jne.) ja toiset täydentäviä, perustuen palvelujen uudelleenkäytettävyyteen ja yhteensopivuuteen. Näistä tarpeista syntyy verkkopalveluita, jotka tarjoavat standardoituja mekanismeja eri käyttäjien yhdistämiseksi tietopalvelimiin.
PALVELUKESKEISET ARKKITEHTUURIT
SOA:n (Service Oriented Architecture) mukaan ne ovat ohjelmistoarkkitehtuureja, jotka määrittelevät liiketoiminnan tarpeita tukevien palvelujen käytön, joiden tavoitteena on saavuttaa mahdollisimman pieni kytkentä ohjelmistoagenttien välillä. Palvelu on työn yksikkö, jonka palveluntuottaja suorittaa palvelun kuluttajan toivoman lopputuloksen saavuttamiseksi. Sekä palveluntarjoaja että palvelun kuluttaja ovat ohjelmistoagenttien, eivät omistajiensa rooleja. Yleisesti ottaen palvelukeskeinen arkkitehtuuri on ohjelmistoratkaisu, jonka avulla yritys voi organisoida ja hyödyntää erilaisia prosesseja. SOA:n myötä ohjelmistosovellukset eivät ole enää valtavia toimintojen ja prosessien lohkoja. Sen sijaan nämä sovellukset koostuvat kootuista modulaarisista palveluista. Muista, että palvelu on yksinkertainen ohjelmistotoiminto (kuten CD-levyn toiston peruuttaminen). Sitä voidaan käyttää pyynnöstä missä tahansa järjestelmässä käyttöjärjestelmästä, alustasta, ohjelmointikielestä tai maantieteellisestä sijainnista riippumatta.
Vallankumouksellista SOA:ssa ei ole itse konsepti, joka on ollut olemassa jo pitkään, vaan se, että se voidaan toteuttaa WWW:n (World Wide Web) kautta. Aivan kuten verkkosivut latautuvat millä tahansa alustalla, verkkopalvelut toimivat samalla tavalla riippumatta alustasta, jolla ne on rakennettu
yleismaailmallisia standardeja.
Idea SOA:sta juontaa juurensa suoraan olio-ohjelmoinnista, mikä viittaa tiedon ja sen käsittelyn väliseen suhteeseen. Siten ne määrittelevät muodollisesti palvelut rajapintojen kautta, jotka ovat riippumattomia taustalla olevasta alustasta ja ohjelmointikielestä. Nämä rajapinnat piilottavat toteutuksensa erityispiirteet, mikä tekee niistä riippumattomia kehittäjä ja ohjelmointikieli. Näiden arkkitehtuurien avulla on mahdollista suunnitella ja toteuttaa erittäin skaalautuvia järjestelmiä, jotka heijastavat liiketoimintalogiikkaa ja samalla helpottavat vuorovaikutusta erilaisten omistamien tai kolmannen osapuolen järjestelmien välillä. Syy, miksi haluamme jonkun tekevän työn puolestamme, on se, että he ovat asiantuntijoita. Palvelun käyttäminen on yleensä halvempaa ja tehokkaampaa kuin itse tekeminen. Joten useimmat meistä ymmärtävät, että emme voi olla asiantuntijoita kaikessa. Samaa sääntöä voidaan soveltaa ohjelmistojärjestelmien rakentamiseen.
Liitännät ovat erittäin tärkeitä, jos ne eivät ole hyvin määriteltyjä tai eivät toimi, järjestelmä ei toimi. Liitäntöjen lisääminen on kallista ja lisää myös virheiden mahdollisuutta hajautetuissa sovelluksissa. Etäliitännät ovat useimpien hajautettujen sovellusten hitain osa. Kaiken tämän vuoksi uusien käyttöliittymien rakentamisen sijaan jokaiselle sovellukselle on järkevämpää käyttää uudelleen yleisiä rajapintoja kaikille sovelluksille.
Joten koska meillä on käytettävissä vain muutama yleinen käyttöliittymä, meidän on sisällytettävä viesteihin sovelluskohtainen semantiikka. Voimme lähettää minkä tahansa tyyppisiä viestejä käyttöliittymien kautta, mutta joitain sääntöjä on noudatettava, jotta voidaan sanoa, että arkkitehtuuri on palvelukeskeinen.
– Ensinnäkin viestien tulee olla kuvaavia, ei opettavia, sillä palveluntarjoaja on vastuussa ongelman ratkaisemisesta. Se olisi esimerkiksi samanlainen tilanne kuin mennä ravintolaan ja kertoa tarjoilijalle, mitä haluaisit juoda ja mieltymyksesi, mutta meidän ei pitäisi selittää kokille, kuinka ruoat valmistetaan askel askeleelta.
‐ Toiseksi palveluntarjoajat eivät voi ymmärtää pyyntöäsi, jos heidän viestinsä eivät ole kirjoitettuja kaikille osapuolille ymmärrettävässä muodossa, rakenteessa ja sanastossa. Näin ollen sanomien sanaston ja rakenteen rajoittaminen on a
tarvitaan tehokkaan viestinnän kannalta. Mitä rajoitetumpi viesti on, sitä helpompi se on ymmärtää.
‐ Kolmanneksi pidennysmahdollisuus on elintärkeä. Maailma on jatkuvasti muuttuva paikka, samoin kuin ympäristö, jossa ohjelmisto elää. Nämä muutokset edellyttävät vastaavia muutoksia järjestelmäohjelmistoon, kuluttajiin palveluista, palveluntarjoajista ja heidän vaihtamistaan viesteistä. Jos viestit eivät ole laajennettavissa, kuluttajat ja palveluntarjoajat lukitaan tiettyyn palvelun versioon. Rajoitus ja laajennettavuus liittyvät läheisesti toisiinsa, tarvitset molempia, ja toisen lisääminen tarkoittaa toisen vähentämistä. Ihanteellinen on saavuttaa oikea tasapaino.
– Neljänneksi SOA:ssa on oltava mekanismi, jonka avulla kuluttaja voi löytää palveluntarjoajan kuluttajan etsimän palvelun yhteydessä. Mekanismin on oltava joustava, eikä se saa olla keskitetty rekisteri.
‐ Viides, valtioton palvelu: Jokaisen kuluttajan palveluntarjoajalle lähettämän viestin tulee sisältää kaikki tiedot, joita palveluntarjoaja tarvitsee sen käsittelemiseksi. Tämä rajoitus tekee palveluntarjoajasta skaalautuvampaa, koska palveluntarjoajan ei tarvitse tallentaa tilatietoja pyyntöjen välillä. Tätä voidaan kutsua "massatuotantopalveluksi", koska jokainen pyyntö voidaan käsitellä yleisesti. Tämä rajoitus tarjoaa myös enemmän näkyvyyttä, koska mikä tahansa valvontaohjelmisto voi tarkastaa itsenäisen pyynnön ja poimia sen tarkoituksen. Tämä mahdollistaa myös helpon toipumisen osittaisista vioista, koska välitiloja ei ole, mikä tekee palvelusta luotettavamman.
‐ Kuudenneksi idempotentit pyynnöt (jotka eivät tee muutoksia): ohjelmistoagentin vastaanottamilla kaksoispyynnöillä on sama vaikutus kuin yhdellä pyynnöllä. Tämä vaatimus antaa palveluntarjoajille ja kuluttajille mahdollisuuden lisätä laitteen yleistä luotettavuutta palvelun toistamalla pyyntö, jos vika on tapahtunut.
Voimme siis sanoa, että SOA ei ole työkalu, vaan pikemminkin joukko standardeja uusien, dynaamisempien ja vähemmän riippuvaisten sovellusten rakentamiseen. SOA mahdollistaa systemaattisesti pääsyn eri palvelujen väliseen liiketoimintalogiikkaan ja tietoon ja voi myös organisoida useita etäpalveluita yhdeksi kokonaisuudeksi. Suurin osa Määritelmät identifioivat Web Services -palvelun käytön, jota näemme seuraavassa luvussa, palvelukeskeisen arkkitehtuurin toteutuksessa. Se voidaan kuitenkin toteuttaa millä tahansa muulla palvelupohjaisella tekniikalla.