DA LI POSTOJI SAMO JEDNA "ISPRAVNA" ARHITEKTURA WEB POSLOVNIH APLIKACIJA

Transcription

1 DA LI POSTOJI SAMO JEDNA "ISPRAVNA" ARHITEKTURA WEB POSLOVNIH APLIKACIJA Zlatko Sirotić, univ.spec.inf. Istra informatički inženjering d.o.o. Pula Stranica 1

2 Malo marketinga Stranica 2

3 Autor je (bar neko vrijeme) radio s programskim jezicima / alatima: - "Assembler" za Texas Instruments TI-58 kalkulator (1981.) - Fortran, BASIC (1982.) - Pascal, Assembler za Zilog Z80 (ZX Spectrum) (1983.) - Cobol, dbase III, Prolog (1984.) - ADS (Application Development System ( ) - Oracle Database, Designer, Forms, Reports ( ) - Eiffel, C, C++ ( ) - Java ( ) - Scala ( ) - Oracle ADF ( ) Stranica 3

4 Neki autorovi radovi zadnjih godina - HrOUG 2013: Transakcije i Oracle - baza, Forms, ADF - CASE 2013: Što poslije Pascala? Pa Scala! - HrOUG 2012: Ima neka loša veza (priča o in-doubt distribuiranim transakcijama) - CASE 2012a: Utjecaj razvoja mikroprocesora na programiranje - CASE 2012b: Konkurentno programiranje u Javi i Eiffelu - HrOUG 2011: Kriptografija u Oracle bazi - CASE 2011: SOA i poslovna pravila - HrOUG 2010: Biometrijski sustavi greške i ranjivosti - CASE 2010: Revizija sigurnosti Oracle SUBP-a Stranica 4

5 Teme U ovoj prezentaciji razmatraju se (i) sljedeća pitanja: - Da li je izrada web poslovnih aplikacija postala previše kompleksna? - Da li pisati programski kod za integritet podataka i kod za poslovnu logiku samo u bazi, samo na aplikacijskom serveru, samo na klijentu, ili nekom kombinacijom toga? - Da li u bazi uvijek imati samo jednog usera za pristup iz web aplikacije, ili je u redu "stari" način rada: jedna osoba = jedan user na bazi? Stranica 5

6 Teme (nastavak) U ovoj prezentaciji razmatraju se (i) sljedeća pitanja: - Da li konekcija između baze i aplikacijskog modula treba biti stalna ili privremena (na primjeru Oracle ADF-a)? - Da li veza između korisničke sesije u web pregledniku i aplikacijskog modula treba biti stalna ili privremena (ADF)? - Kako baratati s transakcijama? HTTP je stateless - želimo li atomarne transakcije? Ispravno rukovanje transakcijama vrlo je bitno za poslovne aplikacije. Stranica 6

7 Da li je izrada web poslovnih apl. postala previše kompleksna? Mogućnosti DBMS sustava se stalno povećavaju (plavo). No, negdje poslije godine, te se mogućnosti sve manje koriste (crveno). (Prezentacija Toon Koppelaars-a) Stranica 7

8 Da li je izrada web poslovnih apl. postala previše kompleksna? Prosječan developer nekada je mogao naučiti alat za izradu poslovnih aplikacija za par tjedana. Danas mu treba i par godina. Stranica 8

9 Da li je izrada web poslovnih apl. postala previše kompleksna? Gdje se može pisati programski kod u (standardnoj) JEE arhitekturi: Stranica 9

10 Da li je izrada web poslovnih apl. postala previše kompleksna? Različiti pristupi pisanju tankog ili debelog koda u različitim arhitekturnim slojevima; 1. varijanta je najčešća 8. varijanta (sve tanko) ne postoji ipak treba nešto (i) programirati Stranica 10

11 Kamo staviti određeni programski kod? Može se reći da poslovne aplikacije imaju tri vrste programskog koda: - Kod za rad s korisničkim sučeljem. - Kod za poslovnu logiku. On se može podijeliti na kod za čitanje podataka iz baze i kod za ažuriranje podataka u bazi. Kod za ažuriranje podataka u bazi vrlo često koristi (i) čitanje podataka iz baze. - Kod za osiguravanje integriteta podataka u bazi. Često se ovaj kod brka s kodom za poslovnu logiku, pa nije čudno da se u praksi često isprepliću kod za poslovnu logiku i kod za osiguravanje integriteta podataka. Stranica 11

12 Kamo staviti određeni programski kod? Programski kod za rad s korisničkim sučeljem, kod web aplikacija može se nalaziti: - Na strani aplikacijskog servera, što je najčešće. U JEE arhitekturi riječ je o Java servletima (ili nadogradnji servleta, kao štu su JSP, JSF i dr.). - Na strani klijenta. Najčešće se danas takav kod piše u JavaScriptu, a relativno rijetko u Javi kao Java applet. - Na strani baze, što je dosta rijetko. Takvu arhitekturu ima npr. Oracle APEX alat, kod kojeg se HTML stranice dinamički generiraju pomoću APEX-ovih PL/SQL paketa na bazi. Stranica 12

13 Kamo staviti određeni programski kod? Programski kod za poslovnu logiku, kod web aplikacija može se nalaziti: - Na strani aplikacijskog servera, što je vrlo često. U JEE arhitekturi riječ je o najčešće o EJB-ovima. - Na strani baze. Riječ je o tzv. pohranjenim (stored) procedurama / funkcijama i paketima na bazi. Vrlo često se na strani baze sprema programski kod za tzv. batch obradu. Činjenica je da se najčešće najbrže izvršava upravo kod (za poslovnu logiku) koji se nalazi na bazi. - Na strani klijenta gotovo nikad, čak niti kad se na klijent strani nalaze Java appleti. Stranica 13

14 Kamo staviti određeni programski kod? Programski kod za osiguravanje integriteta podataka u bazi, kod web aplikacija može se nalaziti: - Na strani baze. Najčešće se koriste deklarativna integritetna ograničenja baze, kao što su integritetna ograničenja za jedinstveni ključ (UK), vanjski ključ (FK) i check constraint (CK). Iako je SQL standard još od uključio CREATE ASSERTION naredbu, praktički niti jedan SQL DBMS sustav ju ne podržava (nedavno su se pojavili ne-sql relacijski DBMS sustavi koji ju podržavaju). Zbog toga, kada se programski kod za osiguravanje integriteta podataka želi u cijelosti pisati na strani baze, mora se pribjeći korištenju okidača baze (proceduralni pristup). Stranica 14

15 Kamo staviti određeni programski kod? Programski kod za osiguravanje integriteta podataka, osim na bazi, može se nalaziti: - Na strani aplikacijskog servera. Ovo je vrlo čest pristup u praksi. Želja da se izbjegne (dosta mukotrpna) realizacija integriteta podataka pomoću okidača baze često se navodi kao dovoljan razlog za ovakav izbor. No, time se omogućava da baza bude nezaštićena (u smislu integriteta, ne u smislu sigurnosti podataka općenito). Naime, jedna aplikacija može savršeno čuvati integritet podataka u bazi, dok, nažalost, druga aplikacija može biti tako pisana da to ne osigurava. - Na strani klijenta. Vrlo često se tako rade samo jednostavnije provjere integriteta podataka, koje su istovremeno realizirane i na strani aplikacijskog servera ili/i baze. Stranica 15

16 Koliko usera imati na bazi? U klasičnim klijent-server aplikacijama, obično se radilo tako da je svaki korisnik (osoba) imao svoj vlastiti pristup u bazu, tj. svoj vlastiti korisnički račun (user, shemu) na bazi. Broj korisnika (osoba) obično je bio reda par stotina (ili manje), i svi korisnici su bili poznati (neanonimni). Vrlo često web aplikacije rade se puno većim brojem korisnika (osoba), koji su često i anonimni. Tada izgleda logično da se napušta nekadašnji pristup: jedan korisnik (osoba) = jedan korisnički račun (user) na bazi. Najčešće se uz aplikacijsku shemu (kojih može biti i više, npr. jedna za tablice, a druga za pakete na bazi) radi samo jedan korisnički račun (user). No, time se neminovno smanjuje sigurnost baze. Stranica 16

17 Koliko usera imati na bazi? Nije loše koristiti srednji pristup, kod kojeg se odrede različite vrste korisnika (osoba), a onda se za svaku vrstu korisnika napravi poseban korisnički račun (korisnička shema) na bazi. Na taj način, ako netko provali u bazu kroz korisnički račun koji ima manja prava, ne može raditi ono što bi mogao da je provalio kroz korisnički račun sa većim pravima. No, ponekad se i kod web aplikacija može primijeniti "stari pristup", ako su svi korisnici poznati (neanonimni) i ako ih nema više od nekoliko stotina. Tada se kao prepreka pojavljuje činjenica da se kod web aplikacija često koristi pool konekcija na bazu (connection pool), pa se ne želi da svaki korisnik ima svoj poseban pool. No, tome se može doskočiti primjenom tzv. proxy korisničkog računa. Stranica 17

18 Oracle Forms alat Oracle Forms je Rapid Application Development (RAD) alat, koji je Oracle napravio početkom 80-ih, nedugo nakon nastanka Oracle baze verzije 2 (verzija 1 nije nikada postojala), i radio je kao znakovno orijentirana (character mode) aplikacija na serveru. Sredinom 90-ih napravljena je klijent-server GUI varijanta. Klijent-server varijanta pratila je baze 6, 7 i 8, a Forms verzije bile su 4, 4.5, 5, 6 i 6i. U Forms verziji 6 pojavila se paralelno i web varijanta - Web Forms. Nakon verzije 6i, klijent-server varijanta više ne postoji, tj. verzije od 9i do 11gR2 (verzije 7 i 8 nikad nisu postojale) rade isključivo kao web Forms aplikacija (koja nije baš jeftina). Stranica 18

19 Oracle Forms - klijent-server varijanta Oracle Forms je izvorno pisan u jeziku C, a i sadašnji kod je uglavnom C kod, osim Java appleta (koji se izvršava u pregledniku), te određenih pomoćnih dijelova na AS-u. Developeri u Forms-ima mogu koristiti jezik PL/SQL (Forms ima svoj vlastiti PL/SQL engine), SQL (koji se šalje bazi) i specijalne Forms naredbe (koje baza nema, uglavnom su to naredbe za korisničko sučelje). U novijim verzijama može se koristiti i Java. U klijent server varijanti, Forms aplikacija se u cijelosti izvršava na klijentu, koji komunicira sa bazom preko jedne konekcije, a kroz tu konekciju može ići više sesija baze, tako da svaki Forms aplikacijski modul može imati (ne mora) vlastitu sesiju baze. Stranica 19

20 Oracle Forms web varijanta Stranica 20

21 Oracle Forms - web varijanta Web varijanta radi tako da Java applet na klijentu (koji se brine samo za kreiranje korisničkog sučelja) surađuje sa Forms servisom na aplikacijskom serveru. Forms servis manje-više čini onaj isti kod (pisan u C-u) kao i u klijent-server varijanti. I u ovoj varijanti: - Forms servis drži stalnu konekciju s bazom; - korisnik stalno drži Forms module s kojima radi, sve dok ne završi rad. U suštini, ovaj način rada nema nekih značajnih razlika u odnosu na klijent-server rad. Stranica 21

22 Oracle ADF (Application Development Framework) 6 mjeseci nakon što je Sun izdao verziju Jave 1.0, u Oracleu su odlučili raditi RAD alat temeljen na jeziku Java. Prvo izdanje frameworka, koji se tada nije zvao ADF već JBO (Java Business Objects), uslijedilo je godine. Ubrzo mu je ime promijenjeno u BC4J (Business Components for Java). BC4J je pokrivao onaj dio koji danas pokriva ADF BC. Uz BC4J, Oracle je počeo razvijati i odgovarajući IDE JDeveloper, licencirajući tadašnji Borlandov alat JBuilder. Oracle je temeljito preradio JDeveloper, pri čemu ga je u potpunosti "prepisao" u Java kod. Ubrzo je termin BC4J zamijenjen sa ADF. Od godine Oracle JDeveloper IDE je besplatan. Verzija ADF Essentials je besplatna od ljeta Stranica 22

23 Oracle ADF - struktura Stranica 23

24 Oracle ADF razvoj slojeva Za razliku od "nižeg" dijela, tj. ADF BC-a (bivšeg BC4J-a), "viši" dio, koji se odnosi na Controller i View dio MVC (Model View Controller) arhitekture, razvijao se u velikim skokovima, što je pratilo uobičajena zbivanja u cijeloj softverskoj industriji vezanoj za Java web aplikacije. Poznato je da su se dinamičke stranice u JEE arhitekturi prvo radile u servlet tehnologiji. Na temelju nje nastala je JSP (Java Server Pages) tehnologija. Oracle je ubrzo uvidio da te tehnologije nisu dovoljno produktivne, jer ne omogućavaju odgovarajuće module ili komponente, pa je razvio svoju specijalnu tehnologiju UIX (User Interface XML). Na neki način, UIX su preteča standardne JSF (Java Server Faces) tehnologije, čija je (usavršena) varijanta i ADF JSF. Stranica 24

25 ADF BC Entity Object (EO) Dvije EO definicije (koje predstavljaju npr. dvije tablice na bazi) mogu biti povezane asocijacijom, koja je najčešće nastala iz FK veze među tablicama na bazi. Stranica 25

26 ADF BC EO i zaključavanje redaka Moguća je postavka za određeni AM ili za cijelu aplikaciju. Moguće vrijednosti: - None: ništa se ne radi; - Pessimistic: ne preporuča se za web aplikacije, jer čim netko pokuša promijeniti bilo koji podatak retka, redak ostaje zaključan do kraja transakcije; - Optimistic: optimističko zaključavanje (default); zaključava redak tek na kraju, pa tada provjerava da li su stare vrijednosti polja iz retka jednake onima koje su sada na bazi; može se ubrzati pomoću svojstva Change Indicator; - Optupdate: slično kao optimističko zaključavanje, ali bez zaključavanja, pa ne pruža istu sigurnost. Stranica 26

27 ADF BC View Object (VO) Stranica 27

28 Upit nad BC VO-om Kada se izvodi upit (query) nad VO, može se odrediti koji će se izvor podataka koristiti: - Scan database tables: čita se baza, što je podrazumijevano (default) ponašanje; postavlja se programski sa vo.viewobject.query_mode_scan_database_tables; - Scan view rows: čita se query collection (kolekcija prvo mora biti napunjena upitom na bazu); postavlja se programski sa vo.viewobject.query_mode_scan_view_rows; - Scan entity cache: čita se entity cache (moguće je samo za VO temeljene nad EO); postavlja se programski sa vo.viewobject.query_mode_scan_entity_rows. Također, VO omogućavaju sortiranje i filtriranje redaka u memoriji. Stranica 28

29 Application Module (AM) Stranica 29

30 Dijeljeni (shared) aplikacijski moduli Često je potrebno dijeliti podatke između više korisničkih sesija. Korisnička sesija nije isto što i sesija baze, jer se jedna korisnička sesija može realizirati kroz više sesija baze, što je standardno u web aplikacijama. Za potrebe dijeljenja podataka, ADF ima tzv. dijeljene (ili zajedničke - shared) AM instance. AM instanca može biti dijeljena na razini aplikacije (application level shared application module), pa tada svi korisnici koriste istu AM instancu i vide iste podatke, ili samo na razini korisničke sesije (session level shared AM), gdje AM koje se nalaze u istoj aplikacijskoj sesiji, ali unutar drugog vršnog AM, ne vide podatke iz tako dijeljene AM. Stranica 30

31 Kako pomiriti stateless HTTP protokol i stateful transakcije Stranica 31

32 Kako pomiriti stateless HTTP i stateful transakcije - kolačićima Stranica 32

33 Application Module pool i Connection pool (parametri) Stranica 33

34 Connection pool Postoje dvije vrste connection poolova, koje se koriste u ovisnosti o tome da li se konekcije konfiguriraju kao JDBC URL konekcije, ili JNDI name for a data source konekcije. Ako se koriste JDBC URL konekcije, samo tada se koristi ADF connection pool, a inače se koristi connection pool AS-a. Osnovno pravilo za ADF connection pool je: po jedan connection pool (dakle, skup konekcija, a ne jedna konekcija) se kreira za svaki par <JDBCURL, Username> na svakom JVM-u, pri čemu konekciju dobiva samo root AM instanca (ugniježđene AM instance koriste tu istu konekciju). Veza između AM instance i konekcije (iz connection poola) je po defaultu stalna, ali se može postaviti da nije (čime se u pravilu narušavaju performanse). Stranica 34

35 Application Module pooling Stranica 35

36 Application Module pooling - stanja AM-ova AM pool je kolekcija AM instanci iste vrste. AM pool omogućava da veći broj korisnika može (kvazi) istovremeno raditi na manjem broju AM instanci. AM instanca u poolu može biti u jednom od tri stanja: - bezuvjetno slobodna za korištenje bilo kom korisniku; - slobodna za korištenje, ali referencirana na aplikacijsku sesiju koja ju je prethodno koristila i koja još nije završila; u ovom slučaju AM instanca može se ipak predati drugom korisniku, ovisno o tzv. AM State Management Release Levelu, pri čemu će standardno doći do tzv. pasivizacije (a kasnije aktivacije) AM instance; - zauzeta, kad neki korisnik (odnosno, njegova Java dretva na AS-u) trenutačno koristi tu AM instancu. Stranica 36

37 Application Module pooling - varijante otpuštanja AM-ova Kod vraćanja AM instance u AM pool, postoje tri varijante otpuštanja (release levels): - Managed (default): AM pool preferira zadržati istu AM instancu za istog korisnika, ako je to moguće; ako nije moguće, radi se pasivizacija AM instance (podaci se smještaju u bazu, rjeđe u datoteku), a kasnije se radi aktivacija (druge) AM instance; - Unmanaged: nikakvo stanje se ne pamti; - Reserved: veza 1 : 1 između AM instance i korisnika; podsjeća na Forms način rada; nije preporučljiva za web aplikacije, iako je najjednostavnija! - "Reserved AM release level considered harmful, considered harmful." Stranica 37

38 Application Module pooling - testiranje pasivizacije Kao dio testiranja aplikacije, vrlo je preporučljiva praksa da se AM testiraju sa konfiguracijskim parametrom jbo.ampool.doampooling postavljenim na false. Takva postavka zapravo forsira pasivizaciju i aktivaciju kod svakog zahtjeva, čime se mogu naći greške koje bi se javile tek u malom broju slučajeva normalnog rada. Npr. ako u jednom HTTP request-response paru postavimo varijablu u paketu na neku vrijednost, u drugom HTTP request-response paru (iste aplikacijske sesije) očekivali bismo da se pročita ista vrijednost; no, kod pasivizacije to više neće biti tako, jer drugi HTTP par može dobiti drugu AM instancu, što znači i drugu sesiju na bazi. Stranica 38

39 Zaključak Izrada web poslovnih aplikacija postala je previše kompleksna. No, ponekad je moguće neke stvari pojednostaviti. Npr. nije isto da li radimo web aplikaciju za manji broj poznatih korisnika, ili ogroman broj nepoznatih korisnika. Barem ponekad, dobro je pisati programski kod za integritet podataka i kod za poslovnu logiku (uglavnom) u bazi, a ne (uglavnom) na aplikacijskom serveru (što je uobičajeno). Zbog (ne)sigurnosti, nije dobro u bazi uvijek imati samo jednog usera za pristup iz web aplikacije. Dobro je uvesti više razina usera, pa čak i "stari" način rada jedna osoba = jedan user na bazi (uz upotrebu proxy usera). Stranica 39

40 Zaključak Ako radimo sa Oracle ADF-om, poželjno je raditi tako da konekcija između baze i aplikacijskog modula bude stalna (što je default), ne samo zbog boljih performansi, već i zbog lakšeg rada s transakcijama. Po našem mišljenju, veza između korisničke sesije (u web pregledniku) i aplikacijskog modula treba kod poslovnih aplikacija biti Reserved, a ne Managed (što je default), kod kojega (Managed) može doći do pasivizacije / aktivacije AM-a, što otežava rad s transakcijama. Nažalost, često developeri gledaju na DBMS sustav kao na "crnu kutiju". Nemaju vremena za dublje upoznavanje s mogućnostima konkretnog DBMS-a, drže da su svi DBMS-ovi vrlo slični, žele pisati generički kod (neovisan o DBMS-u) itd. Stranica 40