................... ...::: 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.