JavaCro'14 - Is there a single “correct” web architecture for business apps – Zlatko Sirotić

DA LI POSTOJI SAMO JEDNA
"ISPRAVNA" ARHITEKTURA
WEB POSLOVNIH APLIKACIJA
Stranica 1ISTRA INFORMATIČKI INŽENJERING
JavaCro 2014 - Da li postoji samo jedna
"ispravna" arhitektura web poslovnih aplikacija?
Zlatko Sirotić, univ.spec.inf.
Istra informatički inženjering d.o.o.
Pula

Malo marketingaMalo marketinga ☺☺

Autor je (bar neko vrijeme) radioAutor je (bar neko vrijeme) radio
s programskim jezicima / alatima: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 (1985. – 1999.)
- ADS (Application Development System (1985. – 1999.)
- Oracle Database, Designer, Forms, Reports (1995. - )
- Eiffel, C, C++ (1998. - )
- Java (2003. - )
- Scala (2012. - )
- Oracle ADF (2013. - )

Neki autorovi radovi zadnjih godinaNeki 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
- 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

TemeTeme
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?

TemeTeme (nastavak)(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.

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

Da li je izrada web poslovnihDa li je izrada web poslovnih aplapl..
postala previše kompleksna?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.

Gdje se može pisati programski kod
u (standardnoj) JEE arhitekturi:

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

Kamo stavitiKamo staviti
određeni programski kod?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
- 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.

određeni programskiodređeni programski kod?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.).
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.

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.

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).
(CK).
Iako je SQL standard još od 1992. 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).

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

KolikoKoliko userausera imati na bazi?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
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.

KolikoKoliko userausera imati na bazi?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.
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.

OracleOracle FormsForms alatalat
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.
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).

OracleOracle FormsForms
-- klijentklijent--server varijantaserver 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
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.

OracleOracle FormsForms –– web varijantaweb varijanta

OracleOracle FormsForms
-- web varijantaweb 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:
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.

Oracle ADF (Oracle ADF (ApplicationApplication
Development Framework)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 1999. godine. Ubrzo mu
je ime promijenjeno u BC4J (Business Components for Java).
BC4J je pokrivao onaj dio koji danas pokriva ADF BC.
BC4J je pokrivao onaj dio koji danas pokriva ADF BC.
Uz BC4J, Oracle je počeo razvijati i odgovarajući IDE
JDeveloper, licencirajući 1998. tadašnji Borlandov alat
JBuilder. Oracle je 2001. temeljito preradio JDeveloper, pri
čemu ga je u potpunosti "prepisao" u Java kod.
Ubrzo je termin BC4J zamijenjen sa ADF.
Od 2005. godine Oracle JDeveloper IDE je besplatan.
Verzija ADF Essentials je besplatna od ljeta 2012.

Oracle ADFOracle ADF -- strukturastruktura

OracleOracle ADFADF –– razvoj slojevarazvoj 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
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.

ADF BCADF BC EntityEntity ObjectObject (EO)(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.

ADF BCADF BC EOEO
i zaključavanje redakai 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
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.

ADF BCADF BC ViewView ObjectObject (VO)(VO)

Upit nad BC VOUpit nad BC VO--omom
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.

ApplicationApplication Module (AM)Module (AM)

DijeljeniDijeljeni ((sharedshared))
aplikacijskiaplikacijski modulimoduli
Č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.

Kako pomiritiKako pomiriti statelessstateless HTTPHTTP
protokol iprotokol i statefulstateful transakcijetransakcije

Kako pomiritiKako pomiriti statelessstateless HTTPHTTP
ii statefulstateful transakcijetransakcije -- kolačićimakolačićima

ApplicationApplication ModuleModule poolpool
ii ConnectionConnection poolpool (parametri)(parametri)

ConnectionConnection poolpool
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
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).

ApplicationApplication ModuleModule poolingpooling

-- stanja AMstanja AM--ovaova
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.

-- varijante otpuštanja AMvarijante otpuštanja AM--ovaova
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
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." ☺☺☺☺

-- testiranje pasivizacijetestiranje 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.
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.

ZaključakZaključ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
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).

ZaključakZaključ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
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.

JavaCro'14 - Is there a single “correct” web architecture for business apps – Zlatko Sirotić

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (11)

Destaque

Destaque (20)

Semelhante a JavaCro'14 - Is there a single “correct” web architecture for business apps – Zlatko Sirotić

Semelhante a JavaCro'14 - Is there a single “correct” web architecture for business apps – Zlatko Sirotić (20)

Mais de HUJAK - Hrvatska udruga Java korisnika / Croatian Java User Association

Mais de HUJAK - Hrvatska udruga Java korisnika / Croatian Java User Association (20)

JavaCro'14 - Is there a single “correct” web architecture for business apps – Zlatko Sirotić