Copy Link
Add to Bookmark
Report
4x09 Client Server Systems
...................
...::: phearless zine #4 :::...
......................>---[ Client/Server Systems ]---<.....................
............................>---[ by pawwa ]---<............................
nemanja[at]ssl-mail[dot]com
///////////////////////////////////////////////////////////////////////////
--==<[ 0. Uvod / Motivacija
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Mozda je pomalo zavidno, a i tesko napisati dobar uvod za ovako siroku temu.
Uvod kao i svaki bi trebao da bude motivacione prirode, i da upozna sa sadrzinom.
Tacniji naziv dokumenta bi trebao da bude "distribuirani informacioni sistemi
sa klijent/server arhitekturom". Izabran je kraci naziv jer je kompaktniji.
Intenzivne promene koje se desavaju u poslednjih deset godina u poslovnom
okruzenju organizacija zahtevaju sto vise informacija i sto kompleksnije
aplikacije. To je doprinelo brzom razvoju IT-a, posebno informacionih sistema
u cijem se sredistu nalaze baze podataka odnosno sistemi za upravljanje bazama
podataka. Danas dominantna arhitektura IS-a jesu klijent/server bazirani
informacioni sistemi.
Ovaj tekst jeste deo mog dvomesecnog truda da se upoznam sa osnovnim idejama i
tehnoloskim aspektima domena klijent server sistema. Nema sadrzaja zato sto je
ovo u stvari moj zakljucak cele stvari. Dakle, ovo su informacije koje sam
prikupio sa raznih izvora. Tom prilikom sam se i upoznao sa ORACLE sistemom
za upravljanje bazama podataka. Predstavljeni su sabijeni osnovni pojmovi,
koncepti i tehnologije.
Sadrzaj ne postoji i zato da vas ne bi ometao u citanju, jer smatram da
se covek cesto koncentrise na sam sadrzaj, a ne na samu svrhu i logicni tok
svega sto je napisano. Npr. istorija nekih tehnologija se ne prica jer je to
smor, vec zato sto iz toga zakljucujemo nesto o sadasnjem stanju tehnologija i
zbog cega su nastale.
Tekst moze da se procita za oko 1 sat tako da procitajte ga, makar vam nesto
i ne bude razumljivo.
///////////////////////////////////////////////////////////////////////////
--==<[ 1. Zakljucak
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Hajde da se prvo upoznamo sa *osnovnom* terminologijom:
IT (Information Technology), odnosno Informacione Tehnologije, predstavljaju
skup metoda i sredstava iz oblasti racunarstva i telekomunikacija koji pomazu
u prikupljanju, cuvanju, obradi i prenosu informacija.
Radi lakseg pamcenja ja koristim ovu formulu:
IT=(m+s)R+T koje rade sa informacijama.
Drugi naziv za IT je ICT sto je akronim za Information Communication
Technologies. Neki ljudi tako zovu IT -- mozda sa pravom kazu: "Gde su tu
komunikacije?".
IS (Information System), odnosno informacioni sistem je sistem gde se veze
sistema sa okolinom i veze objekata unutar sistema ostvaruju *razmenom
informacija*.
DBMS (Data Base Management System), odnosno sistem za upravljanje bazama
podataka je software za cuvanje i koriscenje podataka, *uz logicku i fizicku
nezavisnost podataka od programa*, i jednostavan jezik za pristup bazi podataka.
BP (Baza Podataka), predstavlja skup medjusobno povezanih podataka sa
minimumom redundanse (dupliciranja), koji koriste svi procesi obrade
(aplikacije) u sistemu.
DBMS, naravno, nije isto sto i BP!
Informacioni sistem:
+-----------------+
| A1 A2 A3 | A1, A2, A3 -- aplikacije.
| ^ ^ ^ |
| | | | |
| | | | |
| | | | |
| +-------------+ |
| | | | | | |
| | | | | | |
| | V V V | |
| |Baza Podataka| |
| | | |
| | | |
| +-------------+ |
| DBMS |
+-----------------+
Ove definicije pokusajte da razumete i zapamtite. Ako nesto ne razumete,
pretrazite internet o tome (npr. Google, Webster, Wikipedia.org).
Da bismo bolje razumeli zasto su baze podataka i DBMS-ovi razvijeni moramo
utvrditi razloge zbog kojih je ta tehnologija nastala. Sve to vidimo u
nedostacima ranijih tehnologija koje su se bavile upravljanjem podacima:
U prvoj etapi (1955-1970) podacima se programski upravljalo na sekvencijalan
nacin: u osnovi je bio finansijski problem, ulazni podaci su bili organizovani
u fajlove koje aplikacija obradjuje i cuva rezultate u izlaznom, master fajlu.
To je bila etapa tradicijalnog upravljanja podacima i u nazivu stoji
sekvencijalno zbog toga sto se rekordima upravljalo sekvencijalno zbog
tehnologije magnetnih traka. Inace ovaj koncept je i dalje primenjljiv u
bankarskim sistemima.
Kljucno ovde je da je to tehnologija koja je zasnovana na fajlovima, stoga
se i zove tradicionalna fajlovska obrada. Posle, evolucijom, ovo se svelo na
racunar na kome se vrti aplikacija, u nju unosimo podatke i dobijamo iz nje
izvestaje. Veoma bitna stvar ovde je da u aplikaciji postoji definicija
fajlova. Ako razmislimo, ogranicenja su ocigledna:
1. Razdvojenost i izolovanost podataka
(Svaka aplikacija (prodaja, ugovori...) ima svoj ulaz i izlaz.
Tacnije, ne moze jedna aplikacija da koristi fajlove koje koristi neka
druga aplikacija)
2. DUPLICIRANJE!
(ovo je posebno vazno -- problem je bio kako odrzavati visestruke kopije
podataka)
3. Podaci nisu nezavisni od aplikacije
4. Fiskni upiti
5. Proliferacija (velik porast) aplikativnih programa
6. Nekompatibilnost fajlova
Ako vec znate nesto o bazama podataka verovatno da primecujete suprotnost
svih ovih ogranicenja u tehnologiji baza podataka.
Veoma vazno je da su ova ogranicenja posledica dve stvari:
1. Definicija fajlova je u aplikaciji
2. Ne postoji kontrola pristupa podacima (osim one koju namece aplikacija)
Zakljucak ove etape sledi: problem je pre svega kod ODRZAVANJA, a da ne
govorimo o memorijskim zahtevima u vreme ove etape.
Novi pristup problemu je BP koja je pod DBMS-om -- javila se druga etapa:
On-line IS. Ovi sistemi su bili oslonjeni na hijerarhijski ili mrezni model
baze podataka. Ogranicenja ova dva modela su poznata: slozeno upravljanje,
redundansa (dupliciranje), slozen i dug razvoj BP...
U ovoj, drugoj, etapi postojao je MF (Mainframe -- kompjuter velike snage)
i u njemu software koji se zove TPM (Tele Processing Monitor - tele processing
nam govori da se radi o daljinskoj obradi). Na periferiji (po kompaniji)
postojali su terminali koji su se kacili na MF, a TPM se ponasao kao
multiplekser konekcija. Sva obrada je bila u MF koji je imao On-Line BP.
"On-Line" zato da bi se ukazala razlika na starije tehnolgije -- u prvoj
etapi nismo imali azurno stanje sem na nivou fajla. Sledi -- ova arhitektura
se dobro pokazala u sistemima za rezervacije...
Tu se javila obrada zasnovana na BP. Sve aplikacije u prvoj etapi su imale
izlazne fajlove. Koncept BP omogucava da se korisnici obracaju DBMS-u, a ne
file sistemu. To je znacajan pomak.
Prve znacajne koncepte BP su donele CODASYL i DBTG grupe 1971. i definisale
dvonivovski pristup:
1. Shema (svi podaci u BP)
2. Subshema (aplikativni/korisnicki podaci)
CODASYL/DBTG su definisale predlog za tri jezika:
1. DDL shema (jezik za definisanje podataka -- sa njim projektujemo BP)
2. DDL subshema (jezik aplikativnih programera)
3. DML (jezik za manipulisanje podacima -- koriste ih krajnji korisnici)
ANSI nije usvojio ovaj standard! Sledeca bitna prekretnica je tzv. ANSI/X3/SPARC
pokusaj standardizacije. Oni su 1975. predlozili 3-nivovsku organizaciju:
1. Spoljna shema
2. Logicka shema
3. Fizicka shema
Shema je inace ukupna slika podataka BP. Spoljna shema je vidjenje baze ocima
konkretne aplikacije. Konceptualna shema predstavlja stvarne ukupne podatke, a
o internoj shemi vodi racuna DBMS -- to su fizicki podaci.
ANSI/X3/SPARC su uveli veoma bitnu stvar: sistemski katalog. Moram priznati da
me to jos uvek zbunjuje i nisam nasao informacije o tome, ali ukratko u njemu
se nalaze meta podaci -- podaci i informacije o bazi podataka. To je bitno jer
on omogucava onu ultra-vaznu osobinu DBMS-a: LOGICKU I FIZICKU NEAVISNOST
PROGRAMA OD PODATAKA, a to je krucijalni koncept BP.
Ovo X3 bi trebalo da vas podseca na 3-tier odnosno troslojnu arhitekturu.
Kljucno u ovoj arhitekturi je da imamo pogled korisnika po spoljnoj shemi!!!
Dakle, videli smo sada dva vazna koncepta BP: prvi su uveli DDL i DML jezike,
definisali 2-nivovksu arhitektruru, a ovi drugi su uveli sistemski katalog i
definisali 3-nivovsku arhitekturu.
To bi bila istorija, hajde da vidimo kategorije savremenih DBMS-ova:
1) RDBMS - relacioni sistem za upravljanje bazama podataka. Za ove ste 100%
culi ako znate bar nesto o bazama podataka. Svi podaci u BP su predstavljeni
na uniforman nacin -- pomocu tabela! Cak su i relacije (veze) izmedju entiteta
predstavljene tabelama. To je prvi plus -- jednostavnost.
Relacije su implicitne -- preko stranog kljuca.
Iza RDBMS stoji precizna matematika. Podacima se pristupa ovim redom:
BP->TABELA->REKORD (vrsta)->ATRIBUT (kolona).
Svaka kolona ima tip podataka (tipova podataka ima ogranicen broj!).
Jezik za manipulisanje podacima je standardizovan (SQL):
1. 1989 SQL 1 ("ANSI-89")
2. 1992 SQL 2
3. 1999 SQL 3 (obiman - 2000 stranica)
Svaki sledeci standard je superset onog prethodnog. Razvoj tezi ka SQL 4, a
malo ko je i uskladjen od proizvodjaca sa SQL 3. I ono sto je potrebno
naglasiti je da standard precizira sta software treba da ima, a ne i kako
to radi...
Primeri: IBM DB2, MS SQL Server, Oracle 7, Sybase 10/11, Informix...
2) Multimedijalne BP (od 1995 pa nadalje)
U ove BP svrstavaju se Objektno Relacioni DBMS (OR DBMS) i Objektno
Orijentisani DBMS (OO DBMS).
OR DBMS je pokusaj spajanja objektnih i relacionih koncepata. Koriste
model podataka koji BP daje objektnu orijentisanost. Postoje ADT -- Abstract
Data Types koji mogu sadrzati tekst, sliku, grafiku, vremenski markirane
podatke, georeferencirane podatke. Dakle, neki podaci u tabelama mogu imati
bogatiju strukturu.
Mnoge posebnosti OO tehnogogije su podrzane u maloj meri ili nisu uopste
podrzane. Nedostaje i direktna podrska OO jezicima.
Jezik sa manipulisanje podacima je prosireni SQL - Object SQL koji
obuhvata upite sa ugnjezdenim objektima, ADT objektima...
Primeri:
1. Sybase Enterprise Aplication Server
2. Informix Universal Server (Illustra)
3. IBM Universal DB (DB2 Extenders)
4. MS Repository
5. Oracle Universal Server (Oracle 8)
Napomena: koja je razlika izmedju RDBMS i ORDBMS? Prva razlika koju bih
ja primetio jeste naravno objektna orijentisanost BP kod ORDBMS! Znaci
podrzani su OO koncepti i ADT tipovi.
OO DBMS -- za ovu tehnologiju ne postoji oficijelni de-jure standard, ali
de-facto standard je donela ODMG v.2.0. Ovde su podrzani OO tehnologije kao
sto su visestruko nasledjivanje, enkapsulacija, koncept klasa...
Veoma zanimljivo je da OO BP prosiruje mogucnosti OO jezika.
OO jezik je jezik kako za aplikaciju tako i za BP.
ODMG 1993. predlaze standard za OQL -- jezik za upit DB objekata.
On nije 100% kompatibilan sa SQL-om, ali vecina OO BP podrzava i SQL
putem ODBC-a.
Dakle, primarni interfejs za kreiranje i manipulaciju objekata je direktnom
upotrebom nativnog objektnog jezika.
Primeri:
Gemstone, Jasmine (CAI), Itasca (Ibex obj. sys.), Poet v.5.0, O2 (Ardent s/w)...
Bitno je naglasiti da je malo proizvodjaca i korisnika OO BP!
Ok. Mi govorimo non-stop o DBMS-ovima, a mozda ne znamo tacno sta su oni
i kakve su im funkcije. Inace, ja imam jednog kolegu sa ETF-a koji studira
elektroniku i malo zna o racunarima. Imao je jedan predmet o osnovama racunarstva.
Jednom kada smo razgovarali o bazama podataka pitao me je: "Sta je DBMS? Ne
shvatam to -- to je ono sto me interesuje?!". Nisam tada znao precizno da mu
objasnim DBMS.
Ako vas neko to pita recicete mu da DBMS obezbedjuje
1. Kreiranje BP putem DDL
2. Koriscenje BP putem DML
3. Konstrolisani pristup podacima (secate se -- ovo je bio nedostatak etape I...)
- katalog dostupan korisniku
- sigurnost
- integritet
- kontrola konkurentnosti, oporavka...
Dakle DBMS ima funkcije memorisanja, pretrazivanja i azuriranje podataka sto je
prirodno. Mora da obezbedi katalog (vazno -- pre toga nije bilo) dostupan
korisniku. Setimo se -- katalog je opis strukture podataka -- meta podaci...
DBMS mora da podrzava transakcije. Potrebno je da postoji mehanizam za upravljanje
konkurentnim pristupom, zatim servisi integriteta, oporavka, autorizacije...
Da me drug to pita danas, nacrtao bih mu i strukturu DBMS software-a, ali to
prevazilazi granice ovog dokumenta.
SQL? SQL je inicijalno bio upitni jezik i bio je slozen. Danas, SQL je
interaktivni upitni jezik, koristi se za programiranje BP, povezivanje
sa umrezenim BP, jezik definisanja i administracije podataka. On je
neproceduralan sto ce reci da njime definiesmo samo koje rezultate hocemo,
a ne i kako cemo do njih doci. Postoje tri standarda ovog jezika koje sam
napomenuo ranije u ovom tekstu.
Hajde da vidimo sta je to SQL server. U C/S sistemu aplikacija od SQL servera,
koji se cesto naziva i SQL-Engine ili DB-Server, zahteva podatke i servise
povezane sa tim podacima (npr. sort).
Posto bazu podataka napada veliki broj konkurentnih korisnika, DB server mora
da obezbedi zasticeno okruzenje koje stiti korisnike, tj. da obezbedi mehanizam
za konkurentni pristup, servise oporavka, integriteta i sigurnosti, zakljucavanje,
kontrola transakcija... On upravlja izvrsavanjem SQL instrukcija i konvertuje ih u
optimizovani plan pristupa za izvrsavanje tih instrukcija.
Danas, SQL server je mesavina standardne SQL funkcionalnosti + specificna
prosirenja od strane razlicitih proizvodjaca.
Danas se koriste tri razlicite arhitekture SQL DB servera, za prihvatanje
udaljenih klijentskih zahteva:
1. Proces-Based
2. Multithread
3. Hybrid
Process-Based se sastoji od dediciranih serverskih procesa na serveru -- dakle,
svaka korisnicka aplikacija ima svoj adresni prostor. Ovo je prednost jer
obezbedjuje maksimalnu sigurnost. Drugo -- za svoje multitasking poslove
obraca se lokalnom OS-u. OS brine ovde o adresnoj zastiti! Naravno,
ova arhitektura ne stedi memorijske i CPU resurse.
Primeri ove arhitekture su Informix, DB2, Oracle 6.
Multithread se sastoji iz jednog vise-nitnog procesa. Sve konekcije, aplikacije
i BP rade u istom adresnom prostoru. Ovo obezbedjuje odlicne performanse, ali ne
i visoku (potpunu) sigurnost. Ima svoj interni scheduler, koji je "preemptive"
i on je nativno slabiji od schedulera lokalnog OS-a. Duge transakcije mogu
zauzeti resurse!!
Primeri: MS SQL Server, Sybase
Hibridna arhitektura je mesavina proces-po-klijentu i multi-nitne arhitekture.
Nudi najbolji balans izmedju sigurnosti i performansi. Mana ovde je sto se mogu
javiti kasnjenja u redu cekanja.
Primeri: Oracle 7, Oracle 8
Treba shvatiti da izbor nije kritican za neki LAN bazirani DSS sistem, ali moze
biti problem kod ozbiljnih produkcionih sistema (OLTP). U svakom slucaju, izabrana
arhitektura ce da utice na rad celokupnog C/S sistema.
Sto se tice DB API-ja, vazno je da znate da postoje dva tipa:
1. ESQL (Embeded SQL - Staticki SQL)
2. CLI (noviji, konceptualno prostiji - Call Level Interface - Dinamicki SQL)
Dosta je vazno da razumete ESQL i CLI jer su ipak to nacini povezivanja
klijenta i servera. Ako vas interesuje vise o tome potrazite internet :).
Kakvi tipovi IS postoje? Postoje OLTP i DSS informacioni sistemi.
OLTP (Online Transaction Processing) su produkcioni sistemi. Glavna namena im je
unos/prihvat podataka. Koriste se u "Front-Office" -- salteri, banke, poste...
Imaju uski skup funkcija, veoma vazna im je pouzdanost, performanse i efikasnost.
Moraju da rade 365X24X7.
DSS (Decission Support System) su sistemi za podrsku odlucivanju. Koriste se u
"Back-Office", i namena im je prvenstveno u analiticke svrhe! Imaju siri skup
funkcija, obicno koriste neki matematicki model, akcenat je stavljen na
fleksibilnost pre svega. Tipicni DSS produkti su OLAP (Online-Analitical
Processing), DM (Data Mining), DW (Data Warehousing), IIS (Intelligent IS).
Sve do sada ste citali o jednom domenu: Upravljanje podacima. Ono sto sledi
jeste domen upravljanja procesima. Razmatraju se nacini izvodjenja kompleksnih
izmena nad podacima uz ocuvanje njihove konsistentnosti. Osnova svega je
transakcija.
Transakcija je UOW -- Unit Of Work -- jedinica posla. Sastoji se od jedne ili vise
akcija nad BP koje se tretiraju kao *celina posla*! Dakle, nad BP transakcija je
elementarna funkcija. Ili ce se izvrsiti ili nece. Ako je transakcija uspesna
onda se kaze da je komitovnana (COMMIT), a ako je neuspesna onda je vracena na
pocetak (ROLL BACK) ili napustena (ABORT).
Dakle transakcija je prakticno vise SQL akcija. Mi ovde govorimo o dinamickoj
prirodi podataka.
Vazna svojstva transakcija su ACID:
A - Atomicity - Atomarnost - zahtev da transakcija bude nedeljiva.
C - Consistency - Konsistentnost - zahtev da aplikacija pomera BP
iz jednog konsistentnog stanja u drugo.
I - Isolation - Izolovanost - zahtev da jedna transakcija ne utice na drugu.
D - Durabiliy - Trajnost - zahtev da su efekti transakcije posle komitovanja
trajni.
Malo pre sam spomenuo da govorimo o dinamickoj prirodi podataka. Tu se logicno
javlja pitanje upravljana konkurentnog pristupa -- kada se vise transakcija
obavlja nad jednom BP. Logicno, moze doci do zbrke.
Pre razmatranja toga, da naglasim da treba razlikovati konkurentno i simultano!
Konkurentno je nekoliko aktivnosti u istoj jedinici vremena.
Simultano je nekoliko aktivnosti u potpuno istom vremenskom momentu.
Potencijalni problemi konkurentnosti:
1. Necisto citanje
2. Nepotpuno citanje
3. Pojava fantomskih redova
4. Izgubljeno azuriranje
Evo dacu primere
1. Necisto citanje:
Odigravaju se dve transakcije. Jedna pretrazuje neki podatak, zatim ga azurira.
Druga transakcija pretrazuje isti taj podatak i procita ga. Prva transakcija
sada uradi ROLL BACK cime se izmene nad podacima vracaju u prvobitno stanje.
Dakle, ona druga transakcija radi sada sa pogresnim podacima.
2. Nepotpuno citanje:
Prva transakcija pretrazuje, druga azurira, prva ponovo pretrazuje.
Ovde ista velicina ima dve razlicite vrednosti u tabeli.
3. Pojava fantomski redova:
Prva transakcija pretrazuje set podataka. Druga neke podatke doda neke obrise.
prva ponov pretrazuje podatke. Sada prva ima neke izmenjene podatke, a neke nema.
4. Izgubljeno azuriranje:
Prva transakcija pretrazuje i azurira. Druga azurira. Prva hoce da radi ROLL BACK,
ali ne moze jer je Druga promenila vrednost tog podatka, zatim Druga radi COMMIT.
Ocigledno ovo su problemi koji realno mogu da nastanu. Naravno -- postoje
rutine koje se primenjuju za kontrolu konkurentnosti:
Prva i tradicionalna metoda je tzv. pesimisticka metoda i ona je manje-vise
svima poznata - na referisane objekte se postavljaju LOCK-ovi. Kada je objekat
pod LOCK-om druga transakcija ne moze da mu pristupa. Tehnika je efikasna, ali
ima posledice na performanse. Obicno se realizuje prtimenom TPM (Transaction
Processing Monitor) monitora i LOCK manager-a.
Moguca poboljsanja ovog pristupa su:
1. Granularnost zakljucavanja
2. Tipovi i nivoi zakljucavanja (nivo stranice, rekorda, tabele;
tipovi deljeni ili ekskluzivni...)
3. Trajanje zakljucavanja (lock-ovi se stavljaju tipicno kada se objekat
referencira, a otpustaju kada se transakcija zavrsi.)
4. Detekcija i razresenje Dead--Lock-ova.
Dead-Lock se desi kada transakcije jedna drugu sprecavaju da se izvrse (npr.
jedna azurira podatak X, druga azurira Y, sada prva hoce da azurira Y, a druga
X.). To se resava tako sto DBMS jednu odbaci, a druga se izvrsava.
Ovom pesimistickom pristupu postoji alternativa sa vremenskim markiranjem od
pocetka transakcije, cime se LOCK-ovi izbegavaju, a kod konflikta dolazi kod
rollblack-a i restart-a.
Postoji i optimisticki pristup, gde se validacija podataka proverava neposredno
pre COMMIT-a. NA BAZI PRETPOSTAVKE DA JE NIVO RIZIKA MALI!
Postoje i problemi sa transparentnoscu procesa, tj. kada se transakcija razlicito
ponasa sto je posledica nesklada dva razlicita okruzenja (npr. u jednom okruzenju
se koristi AUTOCOMMIT, a u drugom ne).
Sada kada znate dosta osnovnih stvari prelazimo na sledeci domen, koji se i tice
ovog dokumenta najvise: Distribuirani sitemi. Osnovne definicije slede.
Distribuirano == podeljeno.
Distribuirana obrada je izvrsavanje kooperativnih procesa koji komuniciranju preko
informacione mreze. Relazuje se kao centralizovana BP kojoj se moze pristupiti
preko mreze.
Distribuirana BP je logicki skup podataka, koji su fizicki podeljeni na vise DB
servera.
Distribuirani DBMS je s/w koji upravlja distribuiranom BP, na takav nacin da su
aspekti distribucije transaprentni za krajnjeg korisnika.
Multi-database sistem je sistem sa vise BP gde svaka lokacija odrzava kompletnu
autonomiju.
Postavlja se pitanje: centralizacija ili distribucija? Pa, ovo je stvar iskustva.
Centralizaciju koristiti ako se podaci cesto azuriraju sa vise lokacija, ako
klijent zeli da izvrsi transakciju iz bilo koje poslovnice... Centralizacija ima
primenu kod sistema za rezervaciju...
Napomena: kod centralizacije obrada je DISTRIBUIRANA -- svi mogu da pristupe BP.
Poceli smo da pricamo o distribuiranim informacionim sistemima. Ako navedemo
samo definiciju, to je ok, ali pitanje je koji su nacini distribucije podataka.
Postoji cetiri tehnike distribucije podataka.
Particionisanje je deljenje tabela BP horizontalno (po rekordima) ili vertikalno
(po kolonama), i ti fragmenti se distribuiraju na 2 ili vise servera.
Prednosti su u koriscenju (pogledi), ovo je efikasno i sigurno.
Nedostaci su losije performanse, integritet.
Primeri: ED (elektro distributivna) preduzeca, osiguranja...
Ekstrakt je prosta i jeftina tehnika distribucije podataka. Glavno obelezje ovde
je da se ekstrakt ne azurira! Znaci koristi se za podatke koji se ne menjaju ili
jako retko menjaju -- obicno istorijski podaci.
Tu postoji primarna BP i njen deo je ekstrakt.
Postoji tri tipa ekstrakta: prosti, vremenski markiran (full image) i osvezeni
(parcijalni image).
Veoma popularna tehnika distribucije podataka je replika. Replika je kopija master
BP koja se moze azurirati. Sinhronizacija master BP sa replikom se vrsi slanjem
inkrementalnog imidza sa replike (pri svakoj promeni ili periodicno).
Primarna BP SE NE AZURIRA -- samo njena kopija - replika.
Sinhrona replika -- podaci se azuriraju cim je BP modifkikovana koriscenjem
2PC protokola.
Asinhrona replika -- podaci se azuriraju posle nekog vremena (n*sec).
Keshiranje je dinamcka replika. Dakle, privremeno (dinamicki) se stvara kopija BP
ili njenog dela. Poboljsava performanse ako se jednom referisani podaci ponovo
koriste (Internet) ili ako se podaci retko menjaju. Problem je mehanizam
odrzavanja konsistentnosti keseva.
Modeli obrade podataka:
1. Centralizovana
2. Personalna
3. Distribuirana
Svaki model obrade podrzan je odgovarajucom arhitekturom IS-a:
1. Centralizovana vise-korisnicka arhitektura
- se realizuje umrezenim terminalima prikljucenim na centralni, host racunar, koji
je najcesce MF (Mainframe -- racunar velike snage). Sve komponente sistema su
na MF. Ovo je tipicno poslovne aplikacije i IS OLTP tipa.
Prednosti: tehnologija je stabilna, dobro podrzana. Obezbedjuje funkcije
za rad 200-10000 korisnika.
Nedostaci: tehnologije su proizvodjacke, medjusobno su nekompatibilne, skupe su za
implementaciju, znacajni su troskovi nadogradnje.
2. Distribuirana personalna arhitektura
- realizuje se tako sto su sve komponente (podaci i aplikacije) na jednoj
racunarskoj platformi (PC) namenjenoj za koriscenje od strane jenog korisnika.
Ti racunari su ili stand-alone ili povezani u LAN.
3. Distribuirana vise-korisnicka arhitektura
- se realizuje sa vise racunara njihovim povezivanjem u LAN. Komponente se mogu
naci na razlicitim racunarima, ali podaci su obicno na jednom racunaru koji ima
ulogu file-servera.
Nedostaci: File-server postaje usko grlo -- intenzivan je saobracaj na mrezi.
Sa povecanjem korisnika, pogorsavaju se i performanse.
Prednosti DIS sistema su svakako njihova fleksibilnost, lokalna autonomija,
povecana pouzdanost i raspolozivost (kroz fault-tolerance i redundansu),
poboljsane performanse, skalabilnost (racunari i druge IT komponente se mogu
uspesno locirati i zameniti kako bi se zadovoljile sadasnje i buduce potrebe...).
Vidimo da su prednosti brojne, ali je ovim IS teze upravljati jer su kompleksniji
u domenu administracije, sigurnosti, odrzavanja... Mnogo vise komponenti mogu
potencijalno otkazati (prosecne PC komponente)...
Govorili smo o modelima obrade i odgovarajucim arhitekturama IS, hajde sada da
vidimo koje su to arhitekture DIS:
1. Master/Slave
Ovde master proces inicira i upravlja dijalogom sa drugim -- slave procesima.
Slave proces samo odgovara na komande master-a. Master ima definsian skup komandi
i odgovarajuce odgovore. Ovo je bila arhitektura u doba On-line IS.
2. Klijent server
Klijent server je najcesce koriscna paradigma za struktuiranje DIS.
Klijent zahteva servis koji obezbedjuje jedan ili vise servera (procesa).
Serverima se pristupa preko jasno definisanog interfejsa. Diajlog se odigrava
po principu zahtev/odgovor, koriscenjem protokola tipa zahtev/odgovor.
Klijentski i serverski procesi su ravnopravni.
3. Model od-sloja-do-sloja (P2P)
Ova arhitektura eliminise potrebu za posebnim serverima. Svaka stanica se ponasa
kao klijent i kao server. Sve stanice su ravnopravne, i medjusobno dele resurse.
P2P mreze obicno pocinju sa deljenjem fajlova i resursa (stampaci).
Prednost je mogucnost upotrebe neiskoriscenog procesorskog vremena (SETI @ Home).
Nedostaci: P2P mreze su skoro uvek jednostavnije i jeftinije od C/S sistema, ali
otvaraju brojna pitanja u pogledu PERFORMANSI i SIGURNOSTI MREZE.
4. Groupware - Grupni model
GW je s/w koji podrzava kreiranje, tok i pracenje visoko nestrukturirane
informacije, a kao direktna podrska kolaborativnoj grupnoj aktivnosti.
GW oraganizuje informacije u dokumente, koje pomera putem e-mail-a.
Pet baznih tehnologija cini GW:
1. Upravljanje multimedijalnim podacima
2. Workflow
3. e-mail
4. Konferencije
5. Planiranje
Ni jedan GW software ne podrzava sve tehnologije. Primeri:
1. Lotus Notes/Domino 5.0
2. Novel Group Wise
3. MS Exchange
GW se koristi kada jedan proces traba da posalje poruku svima u grupi i ocekuje
odgovor od jednog ili vise clanova grupe.
GW je tzv. kolaborativni software, i integrise rad na jednom projektu pomocu
nekoliko konkurentnih korisnika na razlicitim radnim stanicama.
5. Model distribuiranih objekata
Objekat je sacinjen od metoda i atributa. Objekti komuniciraju preko ORB-a:
Object Request Broker. Kako objekti mogu da medjusobno komuniciraju, tako se
stvara mreza objekata. Komuciraju slanjem poruke koje pozivaju neku metodu
iz skupa metoda koji definise interfejs objekta.
Popularni standard za implementaciju distribuiranih objekata je CORBA.
Prednosti:
- Objekat je prirodna jedinica distribucije
- Obezbedjuje osnovu za integraciju DIS
- Veca produktivnost razvoja/odrzavanja
6. Model multimedijlanog toka (stream)
Kao npr. Video stream.
Da pricamo malo o najpopularnijoj arhitekturi: Klijent/Server.
Klijent/Server predstavlja arhitekturu koja se sastoji od dve platforme, gde jedna
ima ulogu klijenta, a druga servera. Platforme (h/w i OS) su povezane
komunikacionom vezom.
Klijent je proces koji inicira zahteve i ima aktivnu ulogu.
Server je proces koji odgovara na zahteve klijenta i ima pasivnu ulogu.
Mogu se klasifikovati po hijerarhiji (dvonivovska, visenivovska), lokaciji
(udaljeni i lokalni serveri) i nameni/funkciji.
Klasicikacija prema nameni:
1. File-Serveri
Glavna namena jeste zajednicko koriscenje fajlova. Klijent zahteva rekorde
od file--server-a. Intenzivan je saobracaj na mrezi jer se fajlovi vracaju
klijentu preko mreze pa ih on lokalno pretrazuje. Ovo je dobro za deljenje
velikih data objekata tipa inzenjerski crtezi, dokumenti, slike...
2. DB Serveri
Klijent salje SQL instrukcije serveru. Rezultati se vracaju preko mreze. Kod
koji izvrsva zahteve i podaci se nalaze na istoj masini. Na strani klijenta
se mora napisati kod za klijentsku aplikaciju, ili se mora kupiti upitni alat.
DB serveri su osnova za DSS i DW sisteme.
3. Transakcioni Serveri
Sa transakcionim serverom klijent pokrece udaljene procedure koje se nalaze na
serveru. Te procedure izvrsavaju grupu SQL instrukcija.
Komunikacija se odigrava jednostavnim zahtev/odgovor porukama -- SQL instrukcije
su agregirane u transakcije!
Kod se mora napisati i za klijent i za serversku stranu.
Klijent je obicno GUI.
Server je obicno OLTP sa transakcijama nad BP.
Postoje dve varijante OLTP servera:
1.OLTP lite -- na bazi store procedura.
2.OLTP heavy -- na bazi TPM monitora.
4. Groupware Serveri
GW adresira upravljanje polu-strukturiranim informacijama tipa: mail,
tekst, slika, bulletin board, workflow...
GW stavlja ljude u direktan kontakt.
Mnogi GW produkti koriste e-mail kao middleware.
5. Objektni Aplikacioni Server
Sa ovakvim serverom, c/s aplikacija je napisana kao skup objekata. Objekti
komuniciraju preko ORB-a pozivanjem udaljenih metoda. ORB locira instancu
te klase na serverskom objektu i vraca rezultate klijentskom objektu.
ORB - Object Request Broker - Objektni Raspodejlivac
RMI - Remote Method Invocation
6. Web Aplikacioni Server
OVi serveri omogucavaju klijentu da bude "super-tanak" (samo browser), dok je
server debeo. Klijent poziva dokumente koriscenjem RPC-olikog protokla (HTTP),
gde parametre predaje kao stringove. Server vraca rezultate po imenu dokumenta.
Nova generacija: integracija weba i distribuiranih objekata: Object Web.
Kada govorimo o dvoslojnim sistemima, i komponentama DIS, pitanje je do kog stepena
treba vrsiti distribuciju tih komponenti.
Kod dvoslojnih sistema aplikacija je ta koja vrsi prevagu da li ce sistem da bude
sa arhitekturom debeli server ili debeli klijent. Dakle, kada govorimo o
dvoslojnoj arhitekturi aplikacija postoje:
1. Debeli klijent - obrada i prezentacija su na klijentu
2. Debeli server - obrada i podaci su na serveru.
U slucaju debelog klijenta, on ima GUI + aplikaciju pa preko SQL-a, File I/O ili
HTTP-a komunicira sa serverom koji mu obezbedjuje podatke. U slucaju debelog
servera aplikacija je na strani servera.
Kada govorimo o troslojnoj arhitekturi aplikacije situacija
sa slojevima je sledeca:
1. Prezentaciona komponenta
2. Zajednicki aplikacioni servisi
3. Zajednicki servisi podataka
Iz prethodnog numerickog listinga mozemo zakljuciti da troslojna arhitektura
sistema obezbedjuje tanki klijent!
Dakle, klijent je browser sa Active X ili Java Beans podrskom, pa preko
middleware-a tipa RPC, ORB, MOM, HTTP-a komunicira sa drugim slojem na kome
je aplikativna logika, zatim aplikacioni server (AS) komunicira sa DB serverom
putem SQL-a ili nekog drugog data access protokola/jezika.
Komparacija arhitektura:
Svojstvo 2-slojna 3-slojna
________________________________________________________________
Administracija Kompleksna Manje kompleksna
Sigurnost Niska Visoka
Performanse Slabe Dobre
Skalabilnost Slaba Odlicna
Lakoca razvoja Visoka Postaje bolja
Hajde da ovo ne bude puko nabrajenje vec da se objasne stvari:
2-slojna je kompleksnija sto je posledica vise aplikativne logike kojom
treba upravljati na klijentu. 3-slojna je manje kompleksna jer se moze
centralo upravljati na AS.
Sigurnost 2-slojne je na nivou podataka, dok kod 3-slojne se moze fino
poredesavati na nivou servisa, metoda ili tipa objekta.
2-slojna ima slabije performanse kao posledica veceg SQL saobracaja.
Losija skalabilnost 2-slojne kao posledica ogranicenih mogucnosti upravljanja
komunikacionim linkovima klijenta. 3-slojna kontrolise nadolazece sesije, moze
distribuirati opterecenje na vise servera.
Druge pogodnosti u vezi sa 3-slojnom u odnosu na 2-slojnu su:
Enkapsulacija podataka, ponovno koriscenje aplikacije, server-to-server
infrastruktura, podrska za internet, izbor mogucnosti komunikacija...
Iz ovoga vidimo da je osnovno svojstvo dvoslojne arhitekture u stvari
lakoca razvoja aplikacija posebno upotrebom vizuelnih alata. Dakle, ovo
je podesno za aplikacije na nivou radne grupe, za DSS, manji groupware,
jednostavni web publishing...
Troslojna arhitektura je podesna kada se prevazilaze granice odeljenskog LAN-a:
1. Vise od 300 konkurentnih korisnika
2. Kada ima vise od dva DBMS-a
3. Kada je veliko transakciono opterecenje (vise od 50000 trans. na dan)
4. Ako su aplikacije na razlicitim prog. jezicima
Kao relevantni podatak 1998. u 33% sistema koristile troslojni model!
Pitanje koje opet treba postaviti je i koliko se planira da aplikacija "zivi".
Ukoliko joj zivotni vek nece biti narocito dugacak onda je mozda bolje da se
opredelimo za 2-slojnu arhitekturu (manja kompleksnost, a troskovi odrzavanja
rastu, ali ne puno).
Ukoliko aplikacija treba da radi godinama i da se taj sistem odrzava,
onda je definitivno bolja 3-slojna arhitektura jer su troskovi odrzavanja
manji, a zivotni vek duzi -- trajniji.
Sledece o cemu cemo da pricamo jeste osnovna struktura aplikacija.
C/S aplikacija se sastoji od sledecih delova:
PS: Prezentacioni servisi - upravljaju prikazom informacije korisniku, odredjuju
izgled (look) aplikacije. Pre je su to bili protokoli tipa VT 100, 3270, a danas
je to X-Window System.
PL - Prezentaciona logika - predstavlja nadogradju na PS i odredjuje ponasanje
aplikacije (feel). Pre su to bili odgvori tipa DA/NE, a danas su to procedure
koje se pozivaju na odredjeni dogadjaj (event).
FL - Funkcionalna logika - samo ime kaze: imeplementira poslovnu logiku.
DL - Logika podataka - odredjuje kako ce se objekat podatka ponasati u resursima
podataka. Pre je to bilo fiksirano u kodu, danas je to relacioni pogled ili
store procedures.
DS - Servisi podataka - upravlja definicijom strukture i manipulacijom vrednostima
objekta podatka u resursima podataka. Ranije su se realizovali od strane
file-manager-a (OS), a danas pomocu SQL interfejsa.
Za kraj da razmotrimo kljucnu komponentu C/S sistema: Middleware.
Middleware se nalazi izmedju klijenta i servera. Generalna definicija
On je s/w koji se koristi za komunikaciju aplikacije
i sistema (OS, DBMS, Komunikacije...). Koriscenjem zajednickog MW API-ja
maskira se kompleksnost komponenata nizeg nivoa.
Middleware predstavlja tehnologiju ravijenu pocetkom 90-tih godina sa ciljem
povecanja interoperabilnosti u heterogenom okruzenju.
Postoje komunikacioni, informaciono i upravljacki MW. Od svih koji postoje
opisacu najstariji MW servis: RPC i noviji: CORBA.
RPC je najstariji tip MW. Skracenica je Remote Procedure Call. RPC omogucava da
se procedura pozove iz jednog programa, a da se izvrsava unutar drugog, na drugom
racunaru. Bitno je da koristi sinhroni mehanizam sto znaci da svaki RPC poziv
prekida izvrsenje programa, blokirajuci MW, sto odmah ima posledice na performanse.
Klijent i server rade kao dva odvojena procesa. Ovi procesi komuniciraju putem
"stub-ova". Stub je s/w koji obavlja *konverziju* lokalnih proceduralnih poziva
u seriju mreznih RPC poziva. Podaci se predaju RPC transapornom protokolu nizeg
nivoa koji salje poruke.
IDL kompajler je kljucni deo koji se koristi za generisanje stub-ova, koji se
potom linkuju sa programima klijenta.
Vecina UNIX sistema isporucuje RPC razvojne biblioteke kao deo baznog OS-a.
RPC je bio deo OSF DCE, i deo je MS COM-a.
Zbog ogranicenja po performansama ne preporucuje se koriscenje RPC-a po
sporijim mrezama kao sto je Internet.
CORBA implementira middleware baziran na arhitekturi distribuiranih objekata.
Distribuirani objekti su u stvari mali aplikacioni programi koji koriste
standardne interfejse i protokole za medjusobnu komunikaciju.
Tako jedan distribuirani objekat na UNIX serveru i drugi objekat na NT serveru
mogu da razmenjuju informacije ili izvrsavaju aplikativne funkcije pozivanjem
metoda.
Ovo je omoguceno jer su oba objekta kreirana koriscenjem istog standarda (CORBA).
Distribuirani objekti najbolje rade u Enterprise domenima koji imaju potrebu da
dele veliki broj zajednickih metoda.
Zabluda je da je koriscenje distribuiranih objekata lako sto ilustruje i broj
propalih projekata!
CORBA je standard, a ne tehnologija. OMG konzorcijum je kreirao standard i
specifikacije (ali ne i s/w) koji omogucavaju interoperabilnost i portabilnost
distribuiranih OO aplikacija.
Kljucna komponenta CORBA arhitekture je ORB - Object Request Broker.
ORB omogucava objektima da interaguju u heterogenom distribuiranom okruzenju.
CORBA je najznacajniji MW projekat koji je preduzela IT zajednica!
Za sam kraj da nabrojimo nacine povezivanja klijenta i servera (DB MW):
--1. Nativni (proprietary) DB MW (u obliku biblioteka, API - ESQL i CLI)
Kljucno ovde je da su performanse najbolje koriscenjem nativnog API-a.
--2. DB MW tipa zajednickog interfejsa (standardizacija SQL-a, SAG CLI,
X/OpenSQLCLI, MS ODBC)
ODBC potpuno kontrolise MS, stalno se menja, OK je za read-only funkcije...
JDBC je SQL API za aplikacije, aplete i servlete napisane na Java-i. JDBC
definise Java klase da predstavi: konekcije, SQL iskaze, rezultujuce skupove,
meta-podatke BP i druge DB objekte.
MS OLE DB je mehanizam za pristup razlicitim izvorima podaataka za Windows C i C++
(Relacioni pogledi, File, Excel...).
ADO (Active-X Data Objekti) je sloj preko OLE DB, koji obezbedjuje pristup
podacima jezicima bez pointer-a (Visual Basic) i skript jezicima tipa Java Script
i VB Script. Pre se ovo zvalo DAO (kako me nervira zbunjujuca terminologija).
Sta reci -- MS se igra sa nama :).
--3. DB MW tipa zajednickog gateway-a
--4. DB MW tipa zajendnickog protokola
Kraj. Sto bi rekla Cow iz Cow & Chicken animiranog filma - The Ind :)).
///////////////////////////////////////////////////////////////////////////
--==<[ 2. Zakljucak zakljucka
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Sta je klijent/server model? Da li biste mogli da u nekoliko recenica sta ste
upravo procitali? Sta je Groupware? Koji su nacini povezivanja klijenta i
servera.
Heh. Ako ne znate nema veze. Zato sam tu ja i ovaj zakljucak zakljucka.
C/S je najcesce koriscena paradigma za struktuiranje distribuiranih informacionih
sistema.
Klijent/Server predstavlja arhitekturu koja se sastoji od dve platforme, gde jedna
ima ulogu klijenta, a druga servera. Platforme (h/w i OS) su povezane
komunikacionom vezom.
Klijent zahteva servis koji obezbedjuje jedan ili vise servera (procesa).
Serverima se pristupa preko jasno definisanog interfejsa. Diajlog se odigrava
po principu zahtev/odgovor, koriscenjem protokola tipa zahtev/odgovor.
Klijentsi i serverski procesi su ravnopravni.
Klijent je proces koji inicira zahteve i ima aktivnu ulogu.
Server je proces koji odgovara na zahteve klijenta i ima pasivnu ulogu.
Server je vazan deljeni resurs koji mora obezbediti servise za veliki
broj konkurentnih korisnika.
Middleware je kljucna komponenta C/S sistema. Nalazi se izmedju aplikacije
i komponenata nizeg nivoa (DBMS, OS, Komunikacije).
To je tehnologija razvijena pocetkom 90-tih sa ciljem povecanja interoperabilnosti
u hetereogenom okruzenju.
Sta smo joj naucili i zakljucili? :)
Sta je DBMS? On obezbedjuje:
1. Kreiranje BP upotrebom DDL-a
2. Koriscenje BP upotrebom DML-a
3. Kontrolisani pristup BP
Replikacija je cesto koriscena tehnika distribucije podataka,
ali treba imati odgovarajucu mreznu opremu.
Za male sisteme pogodan je visekorisnicki DIS sa file-serverom.
Dobro je za deljenje velikih data objekata (inz. crtezi, slika
dokumenata). Sa povecanjem korisnika pogorsavaju se performanse.
Za velike sistme (200-10000 korisnika) centralizovana vise-korisnicka
arhitektura IS, OLTP tipa je tipicna (MF) -- za poslovne aplikacije.
Prednosti DIS-a su brojne (fleksibilnost, performanse, skalabilnost
lokalna autonomija, sigurnost), ali su kompleksniji u domenu administracije i
odrzavanja.
sigurnosti.
CORBA je najznacajniji MW poduhvat od strane IT-a.
3. Jkra
_________
Yeah. Pozdrav za #linux. Ja sam zaokruzio ovo i shvatio neke stvari sto je
bitno. Nadam se da je neko od vas takodje shvatio neke stvari. Ljudi pa svaki
IT strucnjak bi trebao to da zna :D.
Ajd vidimo se.
PS. Ako neko hoce da sazna vise o ovome postoji i extended verzija ovog teksta
koju me je mrzelo da zavrsim. Taj tekst je mnogoo duzi i sa nekim je ASCII
slicicama. Ako ga neko zeli -- pogledajte na mom sajtu.
