Kulūris definēja sadalītās sistēmas kā “sistēmas, kurās datortīklā esošie aparatūras un/vai programmatūras komponenti sazinās un koordinē savas darbības, apmainoties ar ziņojumiem”.
Šis jēdziens pēdējos gados ir kļuvis populārs vairāku faktoru dēļ. Pirmais faktors, kas veicināja sadalīto sistēmu attīstību, bija ātrdarbīgu vietējo tīklu rašanās. Vēl viens svarīgs faktors bija tehnoloģiskie sasniegumi personālo datoru veiktspējā un programmatūras izstrāde izplatīto lietojumprogrammu atbalstam. Sadalītās sistēmas ir saistītas ar tīmekļa un interneta jēdzienu. Līdz ar tīmekļa attīstību un jaunu jomu, mijiedarbības, vajadzību un lietojumprogrammu parādīšanos parādās Web 2.0 jēdziens. Šo terminu 2004. gadā ieviesa Tims O'Reilijs, lai apzīmētu otro paaudzi tīmekļa vēsturē, kuras pamatā ir lietotāju kopienas un īpašs pakalpojumu klāsts, piemēram, sociālie tīkli, emuāri, wiki vai folksonomijas, kas veicina sadarbību un veiklību. informācijas apmaiņa starp lietotājiem.
Pirmās arhitektūras, kuras var uzskatīt par orientētām uz pakalpojumiem (SOA), balstījās uz CORBA (Common Object Request Broker Architecture), kas darbojās kā abstrakcijas slānis, lai savienotu dažādus arhitektūras elementus un izveidotu pakalpojumus. Citas agrīnās tehnoloģijas bija DCOM (Distributed Component Object Model) vai RPC (Remote Procedure Protocol). Tā kā ir nepieciešams efektīvi izstrādāt un ieviest sadalītās sistēmas tīmeklī, rodas vairāki izaicinājumi, daži ir vērsti uz pašu izstrādi (veiktspēju, lietotāju pieredzi utt.), bet citi ir savstarpēji papildinoši, pamatojoties uz pakalpojumu atkārtotu izmantošanu un savietojamību. No šīm vajadzībām rodas tīmekļa pakalpojumi, kas nodrošina standartizētus mehānismus dažādu lietotāju savienošanai ar informācijas serveriem.
UZ PAKALPOJUMU ORIENTĒTAS ARHITEKTŪRAS
Saskaņā ar SOA (Service Oriented Architecture) tās ir programmatūras arhitektūras, kas definē pakalpojumu izmantošanu, lai atbalstītu biznesa prasības, kuru mērķis ir panākt minimālu iespējamo saikni starp programmatūras aģentiem. Pakalpojums ir pakalpojuma sniedzēja veiktā darba vienība, lai sasniegtu pakalpojuma patērētāja vēlamo gala rezultātu. Gan pakalpojumu sniedzējs, gan pakalpojuma patērētājs ir programmatūras aģentu, nevis to īpašnieku lomas. Vispārīgā nozīmē uz pakalpojumiem orientēta arhitektūra ir programmatūras risinājums, kas paredzēts, lai uzņēmums varētu organizēt un izmantot dažādus procesus. Izmantojot SOA, programmatūras lietojumprogrammas vairs nav milzīgi funkciju un procesu bloki. Tā vietā šīs lietojumprogrammas veido samontēti moduļu pakalpojumi. Atcerieties, ka pakalpojums ir vienkārša programmatūras funkcija (piemēram, CD atskaņošanas atcelšana). To var darbināt pēc pieprasījuma jebkura sistēma neatkarīgi no operētājsistēmas, platformas, programmēšanas valodas vai ģeogrāfiskās atrašanās vietas.
SOA revolucionārs nav pats koncepts, kas pastāv jau ilgu laiku, bet gan fakts, ka to var ieviest, izmantojot WWW (World Wide Web). Tāpat kā tīmekļa lapas tiek ielādētas jebkurā platformā, tīmekļa pakalpojumi darbojas līdzīgi neatkarīgi no platformas, kurā tie ir izveidoti
universālie standarti.
SOA ideja izriet tieši no objektorientētas programmēšanas, kas liecina par saistību starp datiem un to apstrādi. Tādējādi tie formāli definē pakalpojumus, izmantojot interfeisus, kas ir neatkarīgi no pamatā esošās platformas un programmēšanas valodas. Šīs saskarnes slēpj to ieviešanas īpatnības, kas padara tās neatkarīgas no izstrādātājs un programmēšanas valoda. Izmantojot šīs arhitektūras, ir iespējams izstrādāt un ieviest ļoti mērogojamas sistēmas, kas atspoguļo biznesa loģiku un vienlaikus atvieglo mijiedarbību starp dažādām patentētām vai trešo pušu sistēmām. Iemesls, kāpēc mēs vēlamies, lai kāds darītu darbu mūsu vietā, ir tāpēc, ka viņi ir eksperti. Pakalpojuma izmantošana parasti ir lētāka un efektīvāka nekā to darīt pašam. Tātad, lielākā daļa no mums saprot, ka mēs nevaram būt eksperti visā. To pašu noteikumu var piemērot programmatūras sistēmu veidošanai.
Saskarnes ir ārkārtīgi svarīgas, ja tās nav labi definētas vai nedarbojas, sistēma nedarbojas. Vairāk saskarņu integrēšana ir dārga, kā arī palielina kļūdu iespējamību izplatītajās lietojumprogrammās. Attālās saskarnes ir vislēnākā daļa lielākajā daļā izplatīto lietojumprogrammu. Ņemot to vērā, tā vietā, lai katrai lietojumprogrammai izveidotu jaunas saskarnes, ir lietderīgāk atkārtoti izmantot vispārīgās saskarnes visām lietojumprogrammām.
Tā kā mums ir pieejamas tikai dažas vispārīgas saskarnes, ziņojumos ir jāiekļauj lietojumprogrammai raksturīga semantika. Mēs varam nosūtīt jebkāda veida ziņojumus, izmantojot mūsu saskarnes, taču ir jāievēro daži noteikumi, lai teiktu, ka arhitektūra ir orientēta uz pakalpojumu.
– Pirmkārt, ziņojumiem ir jābūt aprakstošiem, nevis pamācošiem, jo pakalpojumu sniedzējs ir atbildīgs par problēmas risināšanu. Piemēram, tas būtu līdzīgi situācijai, kad dodaties uz restorānu un pastāstāt viesmīlim, ko vēlaties dzert un kādas ir jūsu vēlmes, taču mums nevajadzētu pavāram soli pa solim skaidrot, kā pagatavot jūsu ēdienus.
‐ Otrkārt, pakalpojumu sniedzēji nevarēs saprast jūsu pieprasījumu, ja viņu ziņojumi nebūs rakstīti formātā, struktūrā un vārdu krājumā, kas ir saprotams visiem iesaistītajiem. Tādējādi vārdu krājuma un ziņojumu struktūras ierobežošana ir a
nepieciešams efektīvai komunikācijai. Jo ierobežotāks ir ziņojums, jo vieglāk to saprast.
‐ Treškārt, pagarināšanas iespēja ir ļoti svarīga. Pasaule ir pastāvīgi mainīga vieta, un tā mainās arī vide, kurā dzīvo programmatūra. Šīs izmaiņas prasa atbilstošas izmaiņas sistēmas programmatūrā, patērētājiem pakalpojumu, pakalpojumu sniedzēju un ziņojumu apmaiņu. Ja ziņojumi nav paplašināmi, patērētāji un pakalpojumu sniedzēji tiks bloķēti konkrētai pakalpojuma versijai. Ierobežojumi un paplašināmība ir cieši saistīti, jums ir nepieciešami abi, un palielināt vienu nozīmē samazināt otru. Ideāls ir panākt pareizu līdzsvaru.
– Ceturtkārt, SOA ir jābūt mehānismam, kas ļauj patērētājam atklāt pakalpojuma sniedzēju patērētāja meklētā pakalpojuma kontekstā. Mehānismam jābūt elastīgam, un tas nedrīkst būt centralizēts reģistrs.
‐ Piektais, bezvalsts pakalpojums: katrā ziņojumā, ko patērētājs nosūta pakalpojumu sniedzējam, ir jāietver visa informācija, kas pakalpojumu sniedzējam ir nepieciešama, lai to apstrādātu. Šis ierobežojums padara pakalpojumu sniedzēju mērogojamāku, jo pakalpojumu sniedzējam nav jāuzglabā informācija par stāvokli starp pieprasījumiem. To var saukt par “masveida ražošanas pakalpojumu”, jo katru pieprasījumu var apstrādāt vispārīgi. Šis ierobežojums nodrošina arī lielāku redzamību, jo jebkura uzraudzības programmatūra var pārbaudīt neatkarīgu pieprasījumu un iegūt tā nolūku. Tas arī ļauj viegli atgūties no daļējām kļūmēm, jo nav starpstāvokļu, padarot pakalpojumu uzticamāku.
‐ Sestkārt, idempotenti pieprasījumi (kas neveic izmaiņas): programmatūras aģenta saņemtiem dublētiem pieprasījumiem ir tāda pati ietekme kā vienam pieprasījumam. Šī prasība ļauj pakalpojumu sniedzējiem un patērētājiem palielināt kopējo uzticamību pakalpojumu, vienkārši atkārtojot pieprasījumu, ja ir radusies kļūme.
Tātad mēs varam teikt, ka SOA nav rīks, bet gan standartu kopums jaunu, dinamiskāku un mazāk atkarīgu lietojumprogrammu izveidei. SOA atvieglo piekļuvi biznesa loģikai un informācijai starp dažādiem pakalpojumiem sistemātiskā veidā, kā arī var organizēt vairākus attālos pakalpojumus, lai izveidotu vienu. Lielākā daļa no Definīcijas identificē tīmekļa pakalpojumu izmantošanu, ko mēs redzēsim nākamajā nodaļā, ieviešot uz pakalpojumiem orientētu arhitektūru. Tomēr to var ieviest, izmantojot jebkuru citu uz pakalpojumu balstītu tehnoloģiju.