Arhitektura i projektovanje

softvera
Studijski progam Računarstvo i informatika

- Arhitektura enterprise aplikacija –

1.deo

Katedra za računarstvo
Elektronski fakultet u Nišu

Arhitektura i projektovanje softvera

Prof. dr Dragan Stojanović Računarstvo i informatika
 Izvori
Knjiga
Martin Fowler, Patterns of Enterprise Application Architecture,
Addison-Wesley, 2003
http://martinfowler.com/books.html#eaa
Katalog enterprise arhitekturnih
i projektnih obrazaca
http://martinfowler.com/eaaCatalog

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 2
 Enterprise aplikacije
Informacioni sistemi
Enterprise aplikacije uključuju funkcionalnosti za obradu
plata, evidenciju pacijenata, praćenje isporuke (špedicije),
analizu troškova poslovanja, obračun kredita, osiguranje
klijenata, upravljanje lancem nabavki (SCM), računovodstvo,
upravljanje odnosima sa potrošačima (CRM), planiranje
enterpise resursa (ERP), e-trgovinu, itd.
Enterprise aplikacije ne uključuju sistem za upravljanje
dotokom goriva u automobilima, softver za obradu teksta,
kontrolere lifta, kontrolere industrijskih procesa, operativne
sisteme, prevodioce, računarske igre, itd.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 3
 Karakteristike enterprise aplikacija
Obično uključuju obradu perzistentnih podataka
Velika količina podataka – osrednji sistem obično ima preko 10 GB podataka
organizovanih u milione slogova
Obično veliki broj ljudi konkurentno pristupa podacima. Za mnoge sisteme broj
korisnika je ispod sto, ali za Web zasnovane sisteme broj korisnika je za red
veličine veći (hiljade)
Sa tolikom količinom podataka, u sistemu postoji veliki broj elemenata GUI:
Windows formi, dijalog box-ova, grafikona, tabela, za manipulaciju i vizuelizaciju
tih podataka. Nije neobično da postoji na stotine različitih GUI “ekrana” sa
različitim pogledima na podatke i mogućnostima njihove obrade. Korisnici
enterprise aplikacija često nemaju veliko tehničko znanje u oblasti računarstva i
informatike tako da je neophodno podatke predstaviti na mnogo različitih načina
za različite namene i grupe korisnika
Obilčno postoji potreba da se aplikacija integriše sa ostalim enterprise
aplikacijama u okviru organizacije
Čak i ako kompanije koristi jedinstvenu tehnologiju za integraciju IT sistema,
javljaju se problemi zbog različitosti u poslovnim procesima koji su definisani u
različitim aplikacijama i konceptualnog nesklada podataka (isti podaci mogu
imati različito značenje u različitim aplikacijama i menjati se na različit načine)
Kompleksna poslovna (ne)logika koja može da se menja od slučaja do slučaja,
uz jednu sigurnu stvar: svakako će se menjati tokom korišćenja aplikacije
Arhitektura enterprise aplikacija 1
Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 4
 Arhitektura enteprise aplikacija
Slojevitost je jedna od najuobičajenijih i najvažnijih tehnika koju
projektanti softvera koriste da bi struktuirali i podelili kompleksni
softverski sistem (operativni sistemi, komunikacioni protokoli)
Troslojna arhitektura
Izvor podataka (data source) - Obavlja komunikaciju sa drugim sistemima
koji predstavljaju izvore podataka: baze podataka, messaging sistemi,
menadžeri transakcija, druge enterprise aplikacije, nestruktuirani podaci, itd.
Poslovna (domenska) logika (business, domain logic) - Predstavlja obradu
kojom aplikacija obezbeđuje rešenje problema iz odgovarajućeg domena.
Uključuje izračunavanja zasnovana na ulaznim ili perzistentnim podacima,
validacija podataka koji se dobijaju od sloja prezentacije i pristupa podacima
iz izvora podataka na osnovu komandi koje su primljene od prezentacionog
sloja
Prezentacija (presentation) - Obezbeđuje interakciju između korisnika i
sistema, prikazuje podatke i informacije, putem rich (fat) klijent GUI
(Windows) ili HTML/AJAX, prihvata komande i podatke od strane korisnika
(klik mišem, pritisak na taster), izdaje HTTP zahteve, komande u komandnoj
liniji, itd. i prosleđuje ih sloju domenske logike.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 5
 Glavni obrasci enterprise aplikacija
logika Prezentacija
Page Controller Template View
...

Front Controller Transform View

Domenska

Service Layer Transaction Script

Domain Model Table Module ...

Izvor podataka

Row Data Gateway Active Record

...

Table Data Gateway Data Mapper

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 6
 Domenska logika - obrasci
Kako organizovati “logiku” u okviru sloja domenske
(poslovne) logike sistema?
Postoje tri glavna obrasca:
Transaction Script (Transakcioni skript )
Domain Model (Domenski model)
Table Module (Tabelarni modul)
Može se takođe dodati još jedan obrazac, Service Layer
(Servisni sloj), koji se zasniva na obrascu Domain Model.
Razmotriće se osnovne ideje u okviru svakog obrasca, a
zatim detalji sa primerima

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 7
 Transaction Script
Transaction Script organizuje poslovnu logiku u vidu
procedura gde svaka procedura upravlja i odgovara na
pojedinačni zahtev generisan na prezentacionom sloju
Transaction Script je najjednostavniji način za organizaciju
poslovne logike enterprise aplikacije.
Transaction Script
Uzima ulazne podatke iz prezentacionog sloja;
Obrađuje podatke uz validaciju i odgovarajuća izračunavanja;
Ažurira bazu podataka;
Poziva operacije iz drugih sistema i slojeva;
Odgovara prezentacionom sloju u vidu podataka koje treba prikazati.
Pojedinačna procedura se formira za svaki definisan slučaj
korišćenja ili transakciju.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 8
 Obrazloženje za Transaction Script
Većina poslovnih aplikacija predstavlja samo seriju
transakcija nad bazom podataka.
Svaka transakcija sadrži mali deo poslovne logike, obično
jednostavne, poput selektovanja informacija za prikaz,
validacije ulaznih podataka, obavljanja izračunavanja, itd..
Sa Transaction Script-om zajednička funkcionalnost može
biti podeljena u potprograme, ali svaka transakcija ima
svoju sopstvenu funkciju ili metod iz kojih se, po potrebi,
pozivaju ti potprogrami.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 9
 Struktura Transaction Script-a
Skriptovi treba da budu u klasama odvojenim od prezentacije i izvora
podataka, ili u obliku jedne klase po skriptu ili više skriptova
funkcionalno grupisanih u jednu klasu.
Primer jedne klase po skriptu sa GoF Command obrascem

Koristiti Transaction Script-e za jednostavne probleme koji ne zahtevaju

kompleksne objektne modele.
Arhitektura enterprise aplikacija 1
Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 10
 Transaction Script
Prednosti:
Jednostavnost, sa proceduralnim modelom lakim za razumevanje
Rade veoma dobro sa jednostavnim izvorima podataka, korišćenjem
obrasca Row Data Gateway ili Table Data Gateway (biće obrađeni u
obrascima za izvore podataka)
Granice transakcije su jasno definisane – početak transakcije na
početku procedure, a završetak (commit) transakcije na kraju
procedure.
Nedostaci:
Dupliranje funkcionalnosti zahtevane u različitim akcijama može
kreirati zbrku procedura bez ikakve strukture.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 11
 Primer aplikacije
Primer implementacije Transaction Script-a u Javi u
jednostavnoj aplikaciji.
Kada kompanije registruje prihod od prodaje? Pravila su
kompleksna i zavise od poslovnih propisa, politike
kompanije, uslova ugovora i mnogih drugih faktora.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 12
 Primer aplikacije
Jedan od načina da se upravlja registrovanjem prihoda je
modeliranjem registrovanja prihoda (RevenueRecognition)
za svaki ugovor (Contract) koji se potpiše.

Konceptualni model za registrovanje prihoda po ugovoru

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 13
 Transaction Script - primer
Pretpostavimo da u primeru koristimo sledeći model
podataka:

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 14
 Transaction Script - primer
Jedan od načina za pristup izvoru podataka je korišćenjem obrasca
Table Data Gateway kao omotača za SQL upite (više o pristupu izvorima
podataka biće reči kasnije):

Koristi se MfDate (Martin Fowler datum) i JDBC prepared statement.

Arhitektura enterprise aplikacija 1
Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 15
 Transaction Script - primer
Transaction Script za dobijanje sume registrovanih prihoda
do određenog datuma za dati ugovor:

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 16
 Transaction Script - primer
Objašnjenja vezana za prethodni Transaction Script:
db je gateway objekat baze podataka.
Money je PEAA osnovni obrazac radi tačne podele prihoda.
Iteracija nad JDBC ResultSet-om i getBigDecimal() se koriste za
ekstrakovanje SQL decimalnog polja kao decimalni broj proizvoljne
tačnosti.
Ovaj skript može biti implementiran i korišćenjem SQL agregatne
procedure
• Međutim, poenta je da se razume kako to može biti urađeno
korišćenjem Transaction Script-a.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 17
 Transaction Script - primer
Transaction Script calcuateRevenueRecognitions dodaje
odgovarajuće registrovane prihode u bazu podataka u
skladu sa tipom proizvoda.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 18
 Transaction Script - primer

Objašnjenja:
allocate() je metod klase Money za podelu novca.
Transaction Script treba da zna za sve moguće tipove proizvoda
(Word processors, Spreadsheets, i Databases).
Arhitektura enterprise aplikacija 1
Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 19
 Transaction Script - primer
U okviru Gateway-a treba definisati odgovarajuće metode za
nalaženje (finder) i umetanje (insert) slogova :

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 20
 Transaction Script - interakcija

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 21
 Domain Model
Domain Model predstavlja objektni model domena koji
uključuje i ponašanje i podatke.
Metode objektno-orijentisane analize i projektovanja
(OOAD) se koriste za razvoj modela domena, koji se
organizuje u skladu sa imenicama (nouns) u domenu.
Domenski objekti enkapsuliraju i podatke i ponašanje
sistema i definišu se u skladu sa dva osnovna tipa:
Objekti koji odgovaraju podacima sa kojima sistem radi (poslovnim
podacima);
Objekti koji enkapsuliraju poslovna pravila.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 22
 Domain Model
Postoje dve vrste domenskog modela:
Jednostavni modeli koji izgledaju kao dizajn baze podataka, sa jednim
domenskim objektom za svaku tabelu u bazi podataka, tako da je moguće
koristiti jednostavan obrazac Active Record (Aktivni slog) za mapiranje
objekata u bazu podataka.
Za kompleksnu domensku logiku neophodni su mnogo složeniji modeli ali je
teže postići mapiranje na bazu podataka, pa se zahteva kompleksniji
obrazac Data Mapper.
Objašnjenja za kompleksnije domenske modele:
Podeliti logiku i staviti delove logike u klase u kojima po prirodi pripadaju.
U J2EE, Fowler preporučuje POJO (Plain Old Java Objects) za Domain
Model, a ne entity beans definisane u okviru EJB. Ovim se omogućava
razdvajanje domenskog modela od implementacionog okruženja.
Podsetiti se korisnih obrazaca u GoF za organizaciju domenskih klasa.
Koristiti obrazac Data Mapper za mapiranje objekata na izvor podataka i po
potrebi implementirati obrazac Service Layer kao interfejs prema
prezentacionom sloju.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 23
 Domain Model
Prednosti:
Domenska logika je organizovana tako da svaki tip objekta upravlja
svojom sopstvenom validacijom, izračunavanjem, itd.
Domain Model je skalabilan u slučaju da izvor podataka postaje
kompleksniji.
Nedostaci:
Može biti teško da se prati ponašanje i efekti jedne akcije
Može biti teško da se odrede granice transakcije, jer jedan objekat
može startovati transakciju a drugi objekat da je završi.
Prema Fowler-u, potrebno je dosta vremena za softver inženjere da
se naviknu na ovakav pristup.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 24
 Domain Model - primer
Koristi se isti sistem za
registrovanje prihoda,
iako domenska logika
sistema nije dovoljno
kompleksna da bi
opravdala korišćenje
Domain Model-a.

Domain Model za
registrovanje prihoda
korišćenje GoF obrasca
Strategy

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 25
 Domain Model - primer

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 26
 Domain Model - primer
Sada, izračunavanje prihoda registrovanog do određenog datuma
uključuje Contract i RevenueRecognition, iteracijom po listi postojećih
prihoda (revenueRecognitions).

Kompleksnost je veća nego kod Transaction Script-a pošto je

neophodno uključiti više objekata. Ali pridruživanje ponašanja samo uz
objekte koji su neophodni u implementaciji određenog poslovnog pravila
omogućava skalabilnost i smanjuje spregu.
Arhitektura enterprise aplikacija 1
Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 27
 Domain Model - primer

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 28
 Domain Model - primer

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 29
 Domain Model - primer

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 30
 Domain Model - primer

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 31
 Domain Model - primer
Dat je test kôd za demonstraciju korišćenja ovog modela:

Kada se izračunava registrovanje prihoda vezanih za

određeni ugovor, Contract ne mora da zna o različitim
podklasama kojima su definisane strategije registrovanja.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 32
 Domain Model - primer
Neka objašnjenja i opažanja vezana za primer:
U primeru se vidi kako se zahtev prosleđuje od objekta do objekta
sve dok ne stigne do objekta koji je kvalifikovan da obradi zahtev.
To je tipično za Domain Model (uostalom kao i za sve OO sisteme).
Obrazac Strategy je efikasan kada treba da se refaktoriše
proceduralni kôd koji sadrži mnogo uslovnih naredbi i grananja.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 33
 Domain Model - interakcija

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 34
 Table Module
Table Module predstavlja jednu instancu koja upravlja
poslovnom logikom za sve vrste u tabeli (pogledi, upitu)
baze podataka.
Table Module je sličan domenskim klasama u domenskom
modelu, ali je mnogo više vezan za strukturu baze
podataka.
U ovom slučaju imamo jedan-na-jedan mapiranje između
tabela/pogleda baze podataka i klasa u sloju domenske
logike, tako da se koristi jedna instanca klase za svaku
tabelu.
Ovim se pojednostavljuje mapiranje na izvor podataka, ali
po cenu manje fleksibilne organizacije domenske logike.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 35
 Table Module - struktura

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 36
 Table Module
Ako se želi korišćenje podataka iz određene tabele baze
podataka, klijent treba da:
Izda upit u bazu podataka;
Dobije odgovor u vidu skupa slogova (Record Set);
Koristi skup slogova za instanciranje objekta tipa Table Module;
Poziva operacije (metode) objekta Table Module, prosleđujući
identifikator za izdvajanje konkretnih vrsta tabele u skupu slogova.
Table Module može biti kolekcija statičkih metoda (metoda
klase) ili instanca odgovarajuće klase.
Instance omogućavaju nasleđivanje i inicijalizaciju sa
konkretnim Record Set-om koji je obično obezbeđen u
okviru softverske platforme koja se koristi
Result set - JDBC
Data set - ADO.NET

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 37
 Table Module - interakcija
Tipična interakcija sa Table Module-om

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 38
 Table Module - interakcija
Interakcija po slojevima sa Table Module-om

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 39
 Table Module
Prednosti:
Struktuiraniji nego Transaction Script
Lakše je razumevanje toka izvršavanje poslovnih pravila u odnosu na
Domain Model
Manje kompleksno mapiranje na izvor podataka u odnosu na Domain Model
GUI okruženja obično obezbeđuju direktnu podršku za prikaz RecordSet-ova,
tako da Table Module i u sloju domenske logike obezbeđuju jednostavno,
direktno mapiranje između prezentacionog i sloja izvora podataka, uz
dodatnu validaciju i manipulaciju podacima koji prolaze kroz sloj domenske
logike. Razvoj .NET enterprise aplikacija funkcioniše na taj način (Microsoft
ADO, Microsoft COM).
Nedostaci:
Za ekstremno jednostavne aplikacije, lakše je implementirati Transaction
Script
Za kompleksne aplikacije, Table Module nije dovoljno fleksibilan i skalabilan
kao Domain Model.
Detalje implementacije primera u C# za registrovanje prihoda
korišćenjem Tabelarnog modula možete naći u knjizi.
Arhitektura enterprise aplikacija 1
Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 40
 Izbor arhitekture domenske logike
Pravi izbor obrasca za domensku logiku zavisi od
kompleksnosti domenske logike i softverskih alata i
razvojnih okruženja koje su na raspolaganju za
implementaciju konkretnog obrasca (paradigme).
U okviru iste aplikacije često se koristi mešavina sva tri
obrasca.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 41
 Service Layer
Service Layer definiše granicu aplikacije (sloja domenske logike) u vidu
skupa servisa koji definišu skup raspoloživih operacija i koordinišu
odgovor aplikacije na svaku od tih operacija
Service Layer se formira u obliku API kojim se razdvaja prezentacija od
domenske logike, obezbeđujući laku podršku za višestruke interfejse.

Pored razdvajanja, u okviru

Service Layer-a mogu se
implementirati funkcije koje su
zajedničke za više objekata u
modelu domena i slučajevima
korišćenja, poput:
Kontrole transakcija
Sigurnosti

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 42
 Obrazloženje za Service Layer
Enterprise aplikacije često imaju različit interfejs za istu
funkcionalnost, na primer:
Puni (rich, fat) klijent GUI
Integracioni prolaz (gateway) za druge aplikacije
U tom slučaju, poslovna logika se može podeliti u dva dela:
Domenska logika, koja se odnosi čisto na domen problema (npr.
strategije za registrovanje prihoda);
Aplikaciona logika ili workflow logika.
Service Layer može grupisati deo ili celokupnu aplikacionu
logiku u okviru skupa servisa koji ga čine, tako da je sloj
domenske logike mnogo generalniji i reupotrebljiviji za
različite aplikacije.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 43
 Service Layer
Koliko deo poslovne logike smestiti u Service Layer?
Operacioni skriptovi - U okviru klasa Service Layer-a imamo
operacione (transakcione) skriptove koji implemetiraju aplikacionu
logiku sa jednostavnim Aktivnim slogom (Active Record) modelom
izvora podataka i/ili Domain Model koji implementira domensku
logiku.
Domenska fasada - Service Layer predstavlja samo fasadu, a sva
funkcionalnost je definisana u objektima u domenskom sloju koji se
pozivaju iz servisnog sloja (po principu Facade obrasca).
Uobičajenije je da se aplikaciona logika implementira
korišćenjem servisa (operacionih skriptova) u Service Layer-
u, dok se domenska logika implementira u okviru domenskih
objekata Domain Model (Table Module).

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 44
 Projektovanje servisa
Moraju se grupisati eksterne operacije u klase servisnog sloja, koje se
nazivaju servisi, i obično im se ime završava rečju Service.
Obezbediti da servisi budu krupne funkcionalnosti (coarse grained), čime
se minimizuje broj raspoloživih poziva servisa.
Ovim se omogućava kasniji udaljeni pristup servisima.
Da bi se odredili i pronašli servisi, treba početi od modela slučajeva
korišćenja i/ili specifikacije korisničkog interfejsa. Obično postoji 1-na-1
korespondencija između CRUD (Create, Read, Update, or Delete)
slučajeva korišćenja i operacija Servisnog sloja.
Za Java implementaciju, Fowler preporučuje EJB stateless session bean-
ove za implementaciju aplikacione logike u vidu operacionih skriptova u
servisnom sloju, koji zatim komuniciraju sa POJO domenskim objektima
koji implementiraju domensku logiku.
Ne koristiti Service Layer ukoliko se očekuje da poslovna logika ima
samo jednu vrstu klijenta (UI), ali ako je moguće da postoji više od
jedne vrste različitih klijenata vredi razmotriti implementaciju servisnog
sloja.
Arhitektura enterprise aplikacija 1
Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 45
 Service Layer - primer
Najpre će biti implementiran POJO Service Layer.
Da bi se primer učinio zanimljivijim, biće dodata određena
aplikaciona logika u aplikaciju za registrovanje prihoda.
Kada se izvrši obračun registrovanih prihoda, neophodno je
Poslati e-mail administratoru ugovora;
Poslati poruku putem message-oriented middleware-a drugim
integrisanim aplikacijama.
Sada klasa RecognitionService nasleđuje supertip servisnog
sloja (klasa ApplicationService) i koristi EmailGateway i
IntegrationGateway.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 46
 Service Layer - primer
POJO dijagram klasa za servis za registrovanje prihoda

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 47
 Service Layer - primer
Ignorišući perzistentnost objekata, primer koda bi izgledao:

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 48
 Service Layer - primer
Pretpostavlja se da klasa Contract sadrži metode za čitanje
podataka o ugovorima iz sloja izvora podataka na osnovu ID
ugovora.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 49
 Service Layer - primer
Za sada se ignorišu transakcije – u stvari operacija
calculateRevenueRecognitions() treba da bude atomična.
EJB poseduje ugrađenu podršku za transakcije upravljane
od strane kontejnera (container-managed transactions). Ako
se koriste stateless session bean-ovi sa business interface-
om, tada se upravljanje distribuiranim transakcijama postiže
deklarisanjem calculateRevenueRecognitions,
sendEmailMessage, i publishRevenueRecognitionCalculation
metoda kao transakcionih. Metode RecognitionService klase
iz POJO primera su nepromenjeni definisani u klasi
RecognitionServiceBeanImpl

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 50
 Service Layer - primer
EJB dijaram klasa RecognitionService

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 51
 Zaključak - Domenska logika
Do sada su prikazani glavni arhitekturni pristupi za
projektovanje sloja poslovne logike.
Uglavnom su ignorisane mogućnosti i mehanizimi za
perzistentnost domenskih objekata.
To će biti tema sledećih predavanja.

Arhitektura enterprise aplikacija 1

Prof. dr Dragan Stojanović Arhitektura i projektovanje softvera 52