1. Skyrius 1: Paskirstytos informacinės sistemos

2. Turinys - Skyrius 1 Informacinės sistemos projektavimas
Sluoksniai ir lygmenys
Projektavimas iš apačios viršun
Projektavimas iš viršaus žemyn
Informacinės sistemos architektūra
Vieno lygmens
Dviejų lygmenų (klientas/serveris)
Trijų lygmenų (middleware – vidurio programinė įranga)
N lygmenų architektūros
Klasteriai ir lygmenų paskirstymas
Bendravimas informacinėje sistemoje
Blokuojantis arba sinchroninis sąveikavimas
Neblokuojantis arba asinchroninis sąveikavimas
©Gustavo Alonso, ETH Zürich.

3. Sluoksniai ir lygmenys
Klientas yra naudotojas ar programa, norinti atlikti operaciją sistemoje. Klientai bendrauja su sistema per prezentacijos sluoksnį
Programinė logika apsprendžia, ką sistema iš tikrųjų daro. Ji pasirūpina veiklos taisyklių vykdymu ir sukuria veiklos procesus. Programinė logika įgauna daugelį formų: programos, apribojimai, veiklos procesai ir t.t.
Resursų tvarkytuvė užsiima duomenų, reikalingų programinei logikai palaikyti, organizavimu (saugojimu, indeksavimu ir išgavimu). Paprastai tai duomenų bazė, bet gali būti ir teksto išgavimo sistema arba bet kokia kita duomenų tvarkymo sistema su užklausų galimybe ir išliekamumu (persistence).
Klientas
Prezentacijos sluoksnis
Programinė logika
Veiklos taisyklės
Resursų tvarkytuvė
Veiklos objektai
Klientas
Klientas
Serveris
Veiklos procesai
Duomenų bazė
Išliekamoji saugykla
©Gustavo Alonso, ETH Zürich.

4. Dėžutės ir strėlės
Kiekviena dėžutė – sistemos dalis.
Kiekviena strėlė – jungtis tarp dviejų sistemos dalių.
Kuo daugiau dėžučių, tuo labiau modulinė sistema: daugiau galimybių paskirstymui ir paraleliškumui. Tai įgalina enkapsuliavimą, komponentinį projektavimą, pakartotinį panaudojimą.
Daugiau dėžučių, daugiau ir strėlių: daugiau sesijų (jungčių) turi būti palaikomos, reikia daugiau koordinavimo. Sistema tampa sunkiau stebima ir tvarkoma.
Kuo daugiau dėžučių, tuo daugiau konteksto persijungimų ir tarpinių žingsnių iki reikiamų duomenų. Efektyvumus smarkiai nukenčia.
Sistemų projektuotojai bando balansuoti tarp modulinio lankstumo ir realių sistemų efektyvumo reikalavimų. Atsiradus sluoksniui, jis paprastai migruoja žemyn ir susijungia su žemesniais sluoksniais.
Sistemų projektavime nėra problemos, kurios nebūtų galima išspręsti pridėjus netiesumo lygmenį. Nėra efektyvumo problemos, kurios nebūtų galima išspręsti nuėmus netiesumo lygmenį.
©Gustavo Alonso, ETH Zürich.

5. Projektavimas iš viršaus žemyn
Sistemos funkcionalumas padalinamas tarp kelių modulių. Moduliai neveikia kaip atskiri komponentai, jų funkcionalumas priklauso nuo kitų modulių funkcionalumo.
Aparatūra paprastai homogeninė, o sistema projektuojama kaip paskirstyta nuo pat pradžių.
architektūra iš viršaus žemyn
PS-B
PS-A
PS-C
projektas iš viršaus žemyn
PL-B
PS-A
PS-B
PL-C
PS-C
PL-D
PL-A
PL-B
PL-C
PL-D
PL-A
RT-1
RT-2
RT-1
RT-2
©Gustavo Alonso, ETH Zürich.

6. Projektavimas iš viršaus žemyn
1. apibrėžiami priėjimo kanalai ir klientų platformos
klientas
2. apibrėžiami prezentacijos
formatai ir protokolai
pasirinktiems klientams
prezentacijos sluoksnis
3. apibrėžiamas funkcionalumas,
būtinas reikiama turiniui ir
formatams prezentacijos
sluoksnyje pateikti
programinės logikos sluoksnis
Informacinė sistema
resursų tvarkymo sluoksnis
4. apibrėžiami duomenų šaltiniai
ir duomenų organizacija, kurios
reikia programinei logikai
įgyvendinti
©Gustavo Alonso, ETH Zürich.

7. Projektavimas iš apačios viršun
Projektavime iš apačios viršun daug bazinių komponentų jau egzistuoja. Tai atskiros sistemos, kurias reikia integruoti į naujas sistemas.
Tie komponentai nebūtinai nustoja dirbti kaip atskiri komponentai. Dažnai senos programos tęsia darbą tuo pat metu kaip ir naujos.
Tai nutinka dažnai, nes pamatinės sistemos jau egzistuoja ir negali būti lengvai pakeistos.
Daug darbo ir produktų šioje srityje susiję su middleware, tarpiniu sluoksniu, naudojamu bendrai sąsajai sukurti, spręsti heterogeniškumo problemas ir tvarkytis su pasiskirstymu.
Nauja
programa
“Palikimo”
programa
“Palikimo” sistemos
©Gustavo Alonso, ETH Zürich.

8. Projektavimas iš apačios viršun
PS-B
PS-A
PS-A
PS-B
PS-C
PS-C
iš apačios viršun architektūra
PL-B
PL-B
PL-D
PL-C
PL-C
PL-A
PL-D
PL-A
apvalkalas
apvalkalas
apvalkalas
apvalkalas
apvalkalas
apvalkalas
palikimo programa
palikimo programa
palikimo
sistema
palikimo
sistema
palikimo
sistema
©Gustavo Alonso, ETH Zürich.

9. Projektavimas iš apačios viršun
1. apibrėžiami priėjimo kanalai
ir klientų platformos
klientas
2. išnagrinėjai esami resursai
ir jų funkcionalumas
prezentacijos
sluoksnis
3. esami resursai apvelkami ir
jų funkcionalumas integruojamas
į derančią sąsają
programinės logikos sluoksnis
Informacinė sistema
4. programinės logikos išvestys
adaptuojamos taip, kad jas
būtų galima naudoti su
reikiamais priėjimo kanalais ir
klientų protokolais
resursų tvarkymo sluoksnis
©Gustavo Alonso, ETH Zürich.

10. Vienas lygmuo: pilnai centralizuotas
Prezentacijos sluoksnis, programinė logika ir resursų tvarkyklė sukurtos kaip monolitinis vienetas.
Vartotojai/programos pasiekia sistemą per terminalus, bet informacija juose kontroliuoja serveris. (Taip vadinami “kvaili” terminalai).
Tai buvo tipinė mainframe’ų architektūra su šiais privalumais:
nėra priverstinių konteksto persijungimų valdymo sraute (viskas vyksta sistemos viduje),
viskas centralizuota, resursų tvarkymas ir valdymas lengvesni,
sistema gali būti smarkiai optimizuota užlyginant atskyrimus tarp sluoksnių.
1-lygmens architektūra
Serveris
©Gustavo Alonso, ETH Zürich.

11. Dviejų lygmenų: klientas/serveris
Kai kompiuteriai tapo galingesni, prezentacijos sluoksnį buvo galima iškelti pas klientą. Tai suteikė keletą privalumų:
Klientai nepriklausomi viens nuo kito: vienas gali turėti keletą prezentacijos sluoksnių priklausomai nuo poreikių.
Galima pasinaudoti kliento pajėgumais ir turėti sudėtingus prezentacijos sluoksnius. Tai taip pat taupo resursus serverio pusėje.
Atsirado API (Application Program Interface) sąvoka. Sąsaja kreiptis į sistemą iš išorės. Tai įgalina projektuotojus sujungti keletą sistemų į vieną.
Resursų tvarkyklė mato tik vieną klientą: programinę logiką. Tai pagerina efektyvumą, nes nereikia palaikyti klientų jungčių/sesijų.
2-lygmenų architektūra
Serveris
©Gustavo Alonso, ETH Zürich.

12. resursų tvarkymo sluoksnis
Kliento/serverio API
Kliento/serverio sistemos įvedė paslaugos sąvoką (klientas iškviečia paslaugą, įgyvendintą serverio)
Kartu su paslaugos sąvoka, klientas/serveris įvedė paslaugos sąsajos sąvoką (kaip klientas gali iškviesti tam tikrą paslaugą)
Visos kartu paimtos, visų serverio teikiamų paslaugų sąsajos (nesvarbu, ar programinės, ar sisteminės) apibrėžia serverio Application Program Interface (API), kuri nusako, kaip bendrauti su serveriu iš išorės
Daug standartizavimo pastangų buvo paskatintos reikalo apsispręsti dėl bendros API tam tikro tipo serveriui
serverio API
paslaugos
sąsaja
paslaugos
sąsaja
paslaugos
sąsaja
paslaugos
sąsaja
paslauga
paslauga
paslauga
paslauga
serveris
resursų tvarkymo sluoksnis
©Gustavo Alonso, ETH Zürich.

13. Techniniai 2 lygmenų architektūros aspektai
Atsiranda aiškūs techniniai privalumai, pereinat nuo vieno lygmens į veijų lygmenų architektūras:
pasinaudojama kliento galimybėmis ir darbas nukeliamas klientams
darbas serveryje vykstas vienoje sferoje (scope) (beveik kaip ir 1 lygmens),
serverio architektūra yra vis dar tvirtai apjungta ir gali būti optimizuojamas ignoruojant prezentacijos reikalus
pakankamai nesudėtinga tvarkyti ir valdyti programinės inžinerijos prasme
Tačiau dviejų lygmenų architektūros turi ir trūkumų:
Serveris turi tvarkytis su visais įmanomais prisijungimais iš klientų. Maksimalus klientų skaičius apsprendžiamas serverio palaikomų prisijungimų skaičiumi.
Klientai yra “pririšti” prie sistemos, nes nėra standartinio prezentacijos sluoksnio. Jei norima prisijungti prie dviejų sistemų, klientui reikia dviejų prezentacijos sluoksnių.
Nėra gedimų ar apkrovų valdymo. Jei serveris nedirba, niekas nedirba. Taip pat, kliento sukurta apkrova tiesiogiai paveikia kitų darbą, nes visi konkuruoja dėl tų pačių resursų.
©Gustavo Alonso, ETH Zürich.

14. Pagrindiniai kliento/serverio trūkumai
Tvarkymasis su heterogeniškomis sistemomis perkeliamas klientui.
Klientas turi žinoti, kur yra informacija, kaip ją pasiekti ir kaip užtikrinti suderinamumą
Tai labai neefektyvu visomis prasmėmis (programų projektavimas, perkeliamumas, pakartotinis panauduimas, efektyvumas, nes kliento galimybės ribotos ir pan.).
Šių problemų negalima patenkinamai išspręsti, pasiliekant prie dviejų lygmenų modelio.
Serveris A
Serveris B
Jei klientas nori pasiekti du ar daugiau serverių, 2 lygmenų architektūra sukelia keletą problemų:
pamatinės sistemos nežino viena apie kitą
nėra bendros veiklos logikos
klientas yra integravimo taškas (vis “storesni” klientai)
©Gustavo Alonso, ETH Zürich.

15. Trys lygmenys: middleware
Trijų lygmenų sistemoje visi trys sluoksniai yra pilnai atskirti.
Sluoksniai paprastai būna paskirstyti, pasinaudojant visišku projekto moduliariškumu (dviejų lygmenų sistemose, serveris paprastai centralizuotas)
Middleware paremta sistema yra trijų lygmenų architektūra. Tai kiek supaprastinta, bet iš esmės teisinga, nes pamatinės sistemos gali būti laikomos juodosiomis dėžėmis. Iš tiesų, 3 lygmenų architektūra galima tik su middleware sistemomis (priešingu atveju, klientas susiduria su tomis pačiomis problemomis kaip ir 2 lygmenų sistemose).
3-lygmenų architektūra
©Gustavo Alonso, ETH Zürich.

16. Middleware middleware
Middleware tėra netiesumo lygmuo tarp klientų ir kitų sistemos sluoksnių.
Ji įveda papildomą veiklos logikos sluoksnį, apjungiantį visas pamatines sistems.
Taip darydama middleware sistema:
supaprastina klientų projektavimą, sumažindama sąsajų skaičių,
suteikia skaidrų priėjimą prie pamatinių sistemų,
Tarnauja kaip platforma tarpsisteminiam funkcionalumui ir aukšto lygio programinei logikai, bei
pasirūpina resursų suradimu, jų pasiekimu ir surinkimu.
Bet middleware sistema yra kaip ir kitos sistemos! Ji gali būti 1 lygmens, 2 lygmenų, 3 lygmenų ...
klientai
Middleware arba globali programinė logika
Lokali programinė logika
Lokalios resursų tvarkyklės
middleware
Serveris A
Serveris B
©Gustavo Alonso, ETH Zürich.

17. Techniniai middleware aspektai
Middleware sluoksnio įvedimas padeda, nes:
būtinų sąsajų skaičius smarkiai sumažinamas:
klientai mato tik vieną sistemą (middleware),
vietinės programos mato tik vieną sistemą (middleware),
centralizuoja valdymą (pačios middleware sistemos yra paprastai 2 lygmenų),
plačiai suteikia būtiną funkcionalumą visiems klientams,
leidžia įgyvendinti funkcionalumą, kurį kitokiu atveju būtų labai sunku pasiekti, ir
tai yra pirmas žingsnis tvarkantis su programų heterogeniškumu (kai kuriomis jo formomis).
Middleware sluoksnis komplikuoja padėtį, nes:
tai dar vienas netiesumo lygmuo,
tai sudėtinga programinė įranga,
tai kūrimo platforma, o ne išbaigta sistema
©Gustavo Alonso, ETH Zürich.

18. Trijų lygmenų middleware paremta sistema ...
Išoriniai klientai
Išorinis klientas
vidiniai klientai
valdymas
middleware sistema
jungiančioji logika
naudotojo logika
middleware
apvalkalai
Resursų tvarkyklės
2 lygmenų sistemos
2 lygmenų sistema
Resursų tvarkyklė
©Gustavo Alonso, ETH Zürich.

19. N-lygmenų: prisijungimas prie interneto
N-lygmenų architektūra atsiranda sujungus keletą trijų lygmenų sistemų tarpusavyje ir/ar pridėjus papildomą sluoksnį, kad klientai galėtų pasiekti sistemą per Web serverį
Iš pradžių, Web sluoksnis buvo sistemos išorėje (tikrai papildomas sluoksnis); dabar jis įtraukiamas į prezentacijos sluoksnį serverio pusėje (middleware infrastruktūros dalis trijų lygmenų sistemoje arba tiesiogiai serverio dalis dviejų lygmenų sistemoje)
Papildomas Web sluoksnis leido atsirasti “aplikacijų serverių” sąvokai, naudojamai pavadinti middleware platformas, turinčias priėjimą per internetą
klientas
N-lygmenų
architektūra
Web naršyklė
Web serveris
prezentacijos
sluoksnis
HTML filtras
programinės logikos
sluoksnis
middleware
resursų tvarkymo sluoksnis
informacinė sistema
©Gustavo Alonso, ETH Zürich.

20. N-lygmenų sistemos realybėje
INTERNETAS
ugniasienė
vidiniai
klientai
Web
serverių
klasteris
LAN
LAN
LAN
middleware
programinė
logika
LAN,
vartai
LAN
middleware
programinė
logika
LAN
Apvalkalai ir
vartai
resursų tvarkymo sluoksnis DB
serveris
failų
serveris
programa
papildomi resursų
tvarkymo sluoksniai
©Gustavo Alonso, ETH Zürich.

21. Blokuojantis ar sinchroninis bendravimas
Tradiciškai, informacinės sistemos naudoja blokuojančius iškvietimus (klientas siunčia užklausą paslaugai ir laukia, kol paslaugos atsakymas ateina, prieš tęsdamas darbą)
Sinchroninis bendravimas reikalauja, kad abi pusės būtų be “on-line” režime: kvietėjas daro užklausą, gavėjas gauna užklausą, apdoroja užklausą, išsiunčia atsakymą, kvietėjas gauna atsakymą.
Kvietėjas turi laukti, kol ateina atsakymas. Gavėjas nebūtinai turi egzistuoti kreipimosi metu (TP-monitoriai, CORBA ar DCOM sukuria paslaugos/serverio /objekto atvejį kreipimosi metu, jei dar neegzistuoja), bet bendravimui reikia, kad klientas ir serveris abu būtų “gyvi” tuo pat metu
klientas
serveris
Iškvietimas
Gavimas
tuščias laikas
Atsakas
Atsakymas
Sinchronizuodamas klientą ir serverį, šis veikimo režimas pasižymi keletu trūkumų:
prisijungimo kaštai
didesnė trikčių tikimybė
sunku identifikuoti ir reaguoti į triktis
tai sistema vienas-prie-vieno; ji nepraktiška įdėtiniams iškvietimams ar sudėtingam bendravimui (problemos tampa dar sunkesnės)
©Gustavo Alonso, ETH Zürich.

22. Sinchroniškumo kaina
Sinchroniškiems kreipiniams reikia, kad tarp kvietėjo ir gavėjo būtų palaikoma sesija.
Sesijų palaikymas yra brangus ir naudoja CPU resursus. Taip pat egzistuoja limitas, kiek sesijų galima būti aktyvios vienu metu (taip ribojant skaičių, kiek klientų gali prisijungti prie serverio vienu metu)
Dėl to kliento/serverio sistemos dažnai naudoja prisijungimų kaupimą, kad būtų optimizuotas resursų panaudojimas
turi atvirų prisijungimų fondą
asocijuoja giją su kiekvienu prisijungimu
paskirsto prisijungimus pagal poreikius
Sinchroniškam bendravimui reikia konteksto kiekvienam iškvietimui ir kontekstų valdymo sistemos įeinantiems iškvietimams. Kontekstas turi būti perduodamas su kiekvienu iškvietimu, nes jis identifikuoja sesiją, klientą ir bendravimo pobūdį.
request()
naudotis atsaku
gauti
apdoroti
grąžinti
sesijos
trukmė
request()
naudotis atsaku
receive
process
return ?
Kontekstas dingo
Reikia pradėti iš naujo!!
©Gustavo Alonso, ETH Zürich.

23. Sinchronizuotų iškvietimų triktys
Jei klientas ar serveris sutrinka, kontekstas pametamas, o resinch-ronizavimas gali būti komplikuotas.
Jei triktis įvyko prieš 1, nieko nenutiko
Jei triktis nutinka po 1 bet prieš 2 (nulūžta gavėjas), prarandama užklausa
Jei triktis nutinka po 2 bet prieš 3, pašaliniai veiksniai gali sukelti nesuderinamumą
Jei triktis nutinka po 3 bet prieš 4, atsakas pametamas, bet veiksmas įvyko (kartoti?)
Kas aiškinasi, kas nutiko?
Surasti, kurioje vietoje nutiko triktis, gali būti nelengva. Dar blogiau, jei kreipiniai vyksta grandine (pvz., klientas kreipiasi į serverį, kuris kreipiasi į kitą serverį), triktis gali nutikti bet kurioje grandinės vietoje. 1
request()
naudotis atsaku 2
gauti
apdoroti
grąžinti 4 3 1
request()
naudotis atsaku
pertrauka
bandyti dar 2
gauti
apdoroti
grąžinti 3 2’
gauti
apdoroti
grąžinti 3’
©Gustavo Alonso, ETH Zürich.

24. Du sprendimai SUSTRIPRINTAS PALAIKYMAS
Kliento/serverio sistemos ir middleware platformos turi mechanizmų, galinčių tvarkytis su sinchroninio bendravimo sukeltomis problemomis:
Transakcinis bendravimas: to enforce exactly once execution semantics and enable more complex interactions with some execution guarantees
Paslaugų replikavimas ir apkrovų balansavimas: to prevent the service from becoming unavailable when there is a failure (however, the recovery at the client side is still a problem of the client)
ASINCHRONINIS BENDRAVIMAS
Using asynchronous interaction, the caller sends a message that gets stored somewhere until the receiver reads it and sends a response. The response is sent in a similar manner
Asynchronous interaction can take place in two forms:
non-blocking invocation (a service invocation but the call returns immediately without waiting for a response, similar to batch jobs)
persistent queues (the call and the response are actually persistently stored until they are accessed by the client and the server)
©Gustavo Alonso, ETH Zürich.

25. Pranešimų eilių sudarymas
Reliable queuing turned out to be a very good idea and an excellent complement to synchronous interactions:
Suitable to modular design: the code for making a request can be in a different module (even a different machine!) than the code for dealing with the response
It is easier to design sophisticated distribution modes (multicast, transfers, replication, coalescing messages) an it also helps to handle communication sessions in a more abstract way
More natural way to implement complex interactions between heterogeneous systems
request()
eilė
gauti
apdoroti
grąžinti
eilė
naudoti atsaką
©Gustavo Alonso, ETH Zürich.