Transcript Oblikovanje programske potpore

Oblikovanje programske potpore
MODULARIZACIJA I OBJEKTNO USMJERENA
ARHITEKTURA
2. dio
1
Objektno usmjerena arhitektura – 2. dio
Sadržaj prezentacije:





Raspodijeljeni (engl. Distributed ) sustavi
Arhitektura klijent – poslužitelj
Posrednička arhitektura
Uslužno usmjerena arhitektura – SOA (engl. Servvice oriented
architecture)
Arhitektura sustava zasnovanih na komponentama
Izvor:
T.C.Lethbridge, R.Laganiere: Object-Oriented Software Engineering, 2nd
ed., McGraw-Hill, 2005.
2
Objektno usmjerena arhitektura – 2.dio
Raspodijeljeni (engl. Distributed ) sustavi
3
Raspodijeljeni sustavi
Značajke raspodijeljenih sustava:
• Obrada podataka i izračunavanja obavljaju odvojeni programi.
• Uobičajeno je da su ti odvojeni programi na odvojenom sklopovlju
(računalima, čvorovima, stanicama).
• Odvojeni programi međusobno komuniciraju (kooperiraju) po
računalnoj mreži.
Primjer raspodijeljenog sustava:
Klijent - poslužitelj:
Poslužitelj (engl. server)
• Program koji dostavlja uslugu drugim programima koji su spojeni
na njega preko komunikacijskog kanala.
Klijent:
• Program koji pristupa poslužitelju (ili više njih) tražeći uslugu.
• Poslužitelju mogu pristupiti mnogi klijenti simultano.
4
Raspodijeljeni sustavi – neki primjeri
P2P (Peer-to-Peer)
Svaki čvor u sustavu ima jednake mogućnosti i odgovornosti (čvor je
istovremeno poslužitelj i klijent).
Snaga obrade podataka i izračunavanja u P2P sustavu ovisi o pojedinim
krajnjim čvorovima, a ne o nekom skupnom radu čvorova.
Afinitetna (društvena) mreža (engl. affinity communities)
Jedan korisnik se povezuje s drugim korisnikom u cilju razmjene
informacija ((MP3, video, slike itd.).
Kolaborativno izračunavanje (engl. collaborative computing)
Neiskorišteni resursi (CPU vrijeme, prostor na disku) mnogih računala u
mreži kombiniraju se u izvođenju zajedničkog zadatka (GRID computing,
SETI@home, …).
Instant Messaging
Izmjena tekstovnih poruka između korisnika u stvarnom vremenu.
5
Raspodijeljeni sustavi - primjer
Dijagram objekata s programskim
komponentama
korišteno
(uporabljeno)
sučelje
klijenti
izmjenjuju
poruke
klijenti na
poslužitelju traže
adrese drugih
klijenata
implementirano
sučelje
UML oznaka
Primjer raspodijeljenog sustava u kojem klijenti preko poslužitelja
doznaju za svoje interese te zatim komuniciraju izravno.
6
Problemi u oblikovanju raspodijeljenih sustava:
Kako se smještaju i pokreću funkcije poslužitelja ?
Kako se definiraju i šalju parametri između klijenta i
poslužitelja ?
Kako se rukuje neuspjesima (pogreškama) u komunikaciji ?
Kako se postavlja i rukuje sa sigurnošću ?
Kako klijent pronalazi poslužitelja ?
Koje strukture podataka koristiti i kako rukovati s njima ?
Koja su ograničenja u paralelnom radu dijelova raspodijeljenog
sustava ?
Kako se uopće skupina komponenata usaglašava oko
zajedničkih pitanja ?
7
Objektno usmjerena arhitektura – 2.dio
Arhitektura klijent – poslužitelj
Ciljevi daljnje prezentacije


Detaljnije razmatranje aktivnosti klijenata i poslužitelja.
Metoda oblikovanja arhitekture klijent-poslužitelj temeljena na
ponovnoj i višestrukoj uporabi komponenata (engl. reuse).
8
Klijent – poslužitelj: sekvenca aktivnosti
1.
2.
3.
4.
5.
6.
7.
Poslužitelj započinje s radom.
Poslužitelj aktivira slušanje i čeka na spajanje klijenta (poslužitelj
sluša).
Klijenti započinju s radom i obavljaju razne operacije,
— Neke operacije traže zahtjeve (i odgovore) s poslužitelja.
Kada klijent pokuša spajanje na poslužitelja, poslužitelj mu to
omogući (ako poslužitelj želi).
Poslužitelj čeka na poruke koje dolaze od spojenih klijenata.
Kada pristigne poruka nekog klijenta poslužitelj poduzima akcije
kao odziv na tu poruku.
Klijenti i poslužitelj nastavljaju s navedenim aktivnostima sve do
odspajanja ili prestanka rada.
9
Poslužitelj u komunikaciji s dva klijenta
početak rada i slušanje
spajanje
šalje poruku
šalje odgovor
odspajanje
prestanak slušanja
10
Alternative klijent – poslužitelj arhitekture
• Postoji jedan program na jednom računalu koji obavlja
sve.
• Računala nisu spojena u mrežu već svako računalo
obavlja svoj posao odvojeno.
• Ostvaruje se neki drugi mehanizam (osim klijentposlužitelj) kako bi računala u mreži razmjenjivala
informacije.
Npr. jedan program upisuje u repozitorij podataka a
drugi čita (baze podataka, oglasna ploča, …).
11
Prednosti klijent – poslužitelj arhitekture
•
•
•
•
•
•
Posao se može raspodijeliti na više računala (strojeva).
Klijenti udaljeno pristupaju funkcionalnostima poslužitelja.
Klijent i poslužitelj mogu se oblikovati odvojeno.
Oba entiteta mogu biti jednostavnija.
Svi podaci mogu se držati na jednom mjestu (na poslužitelju).
Obrnuto, podaci se mogu distribuirati na više udaljenih klijenata i
poslužitelja.
• Više klijenata može simultano pristupiti poslužitelju.
• Klijenti mogu ući u natjecanje (kompeticiju) za uslugu poslužitelja
(a i obrnuto).
12
Primjeri klijent – poslužitelj sustava
• The World Wide Web
• E-mail
• Network File System
• Transaction Processing System
• Remote Display System
• Communication System
• Database System
• Usluge u oblaku
13
Funkcionalnosti poslužitelja (UML dijagram stanja)
Poslužitelj se inicijalizira.
Započinje slušati klijentska spajanja.
Rukuje slijedećim tipovima događaja koje potiču klijenti:
1.
2.
3.
događaj
Prihvaća spajanje
Odgovara na poruke
Rukuje odspajanjem klijenta
poslužitelj
kao cjelina
Može prestati slušati.
Mora čisto završiti rad.
za svako spajanje:
a) rukuje spajanjem,
b) reagira na poruku
14
Funkcionalnosti klijenta (UML dijagram aktivnosti)
Klijent se inicijalizira.
Inicijalizira spajanje na poslužitelja.
Interakcija s korisnikom i šalje
poruke poslužitelju.
Rukuje slijedećim tipovima
događaja koje potiče poslužitelj:
1.
2.
interakcija s
poslužiteljem
Odgovara na poruke.
Rukuje odspajanjem poslužitelja.
Mora čisto završiti rad.
(Dijagram aktivnosti nema
asinkrone događaje koji
uvjetuju prijelaze)
interakcija s
korisnikom
Paralelne aktivnosti
15
Tanki i debeli klijent
Sustav tankog klijenta (engl.Thin-client) (a)
• Klijent je oblikovan da bude što je moguće više mali i
jednostavniji.
• Većina posla obavlja se na poslužiteljskoj strani..
• Oblikovnu strukturu klijenta i izvršni kod jednostavno se preuzima
preko računalne mreže.
Sustav debelog klijenta (engl. Fat-client) (b)
• Što je moguće više posla delegira se klijentima.
• Poslužitelj može rukovati s više klijenata.
(a)
(b)
lagano izračunavanje
klijent
poslužitelj
obilno izračunavanje
16
Komunikacijski protokoli
• Poruke koje klijenti šalju poslužitelju formiraju jedan
jezik.
—Poslužitelj mora biti programiran da razumije taj
jezik.
• Poruke koje poslužitelj šalje klijentima također formiraju
jedan jezik.
— Klijenti moraju biti programirani da razumiju taj
jezik.
• Kada klijent i poslužitelj komuniciraju oni razmjenjuju
poruke na ta dva jezika.
• Ta dva jezika i pravila konverzacije čine zajedničkim
imenom protokol.
17
Internet protokoli – skupina TCP/IP
Internet Protocol (IP)
• Određuje put poruka (paketa, "datagrams") od jednog računala do drugog
temeljem njihovih adresa u formatu IPv4 ili IPv6.
Transmission Control Protocol (TCP)
• Nalazi se između primjenskog programa ("aplikacije") i IP protokola..
• Razbija veliku poruku na manje dijelove i šalje dijelove uporabom IP
protokola.
• Osigurava da je poruka uspješno primljena (pojedini IP paketi ispravno
sastavljeni). TCP je pouzdan protokol (UDP- User Datagram Protocol nije).
Svako računalo (čvor) u mreži ima jedinstvenu IP addresu i ime (host
name). Preslikavanje obavlja usluga DNS (engl. Domain Name Service).
• Nekoliko poslužitelja mogu raditi na jednom čvornom računalu u mreži. .
• Svaki poslužitelj na računalu je identificiran preko jedinstvenog broja
ulaznog porta (engl. port number) u rasponu 0 to 65535.
• Kako bi započeo komunikaciju s poslužiteljem klijent mora znati host
name i port number
• Brojevi ulaznih portova 0 – 1023 su rezervirani (npr. port 80 za Web
poslužitelj).
18
Oblikovanje klijent-poslužitelj arhitekture
Specificiraj temeljne poslove poslužitelja i klijenta.
Odredi kako će se posao raspodijeliti (tanki nasuprot debelog klijenta).
Oblikuj detalje skupa poruka koje se razmjenjuju (komunikacijski
protokol).
Oblikuj mehanizme (što se mora dogoditi) prilikom:
— Inicijalizacije
— Rukovanja spajanjima.
— Slanja i primanja poruka.
— Završetka rada.
U oblikovanju koristi princip “Uporabi postojeće gotove
komponente” (princip oblikovanja progr. potpore br. 6)
19
Oblikovanje temeljem iskustva drugih
Inženjeri koji oblikuju programsku potporu trebaju izbjegavati
razvoj programske potpore koja je već bila razvijena.
Tipovi ponovnog korištenja (engl. reuse):
• Ponovno koristi ekspertizu (posebna znanja).
• Ponovno koristi standardna oblikovanja i algoritme.
• Ponovno koristi knjižnice razreda ili procedura.
• Ponovno koristi "snažne" naredbe ugrađene u programski jezik ili
operacijski sustav (npr. Java: try – catch rukovanje iznimkama).
• Ponovno koristi radne okvire (engl. frameworks).
• Ponovno koristi cijela primjenska rješenja (a.k.a. aplikacije).
20
Radni okviri: Podsustavi za ponovno korištenje
Radni okvir (engl. Framework) je učestalo korišten dio
programske potpore koji implementira generičko (opće
ili zajedničko) rješenje problema.
• Osigurava opća (zajednička) sredstva koja se mogu uporabiti u
različitim primjenskim programima (aplikacijama).
Princip:
Primjenski programi koji rade različite, ali na neki način povezane
stvari imaju slične oblikovne obrasce.
21
Objektno usmjereni radni okviri
U objektno usmjerenoj paradigmi radni okvir se sastoji
iz knjižnice razreda.
Radni okvir dodatno sadrži:
• Primjensko sučelje (engl Application programming
interface – API) definirano je kao skup svih javnih (engl.
public) metoda tih razreda.
• Neki od razreda u radnom okviru biti će apstraktni
(operacije se moraju implementirati u podrazredima).
22
Radni okviri i linije proizvoda (engl.
product lines)
• Linije proizvoda (ili porodica proizvoda) je skup svih produkata
izrađenih na zajedničkoj osnovnoj tehnologiji.
• Različiti produkti u liniji proizvoda imaju različite značajke kako bi
zadovoljili različite segmente tržišta.
—Npr. “demo”, “pro”, “lite”, “enterprise” i sl. verzije.
—Lokalizirane verzije su također linije proizvoda.
• Programska tehnologija zajednička svim proizvodima u liniji
proizvoda uključena je u radni okvir (engl. framework).
• Svaki proizvod izrađen je temeljem radnog okvira u kojem su
popunjena odgovarajuća prazna mjesta.
• Iz jednog radnog okvira može se generirati više linija proizvoda.
23
Vrste radnih okvira
Horizontalni radni okvir osigurava veći broj općih i zajedničkih sredstava
koja mogu koristiti mnogi primjenski programi (aplikacije).
Vertikalni radni okvir (primjenski) je mnogo cjelovitiji ali još uvijek traži
popunu nekih nedefiniranih mjesta kako bi se prilagodio specifičnoj primjeni.
usluge koje nudi
radni okvir
primjenski
program
horizontalni
radni okvir
vertikalni
radni okvir
dio koda koji se
mora dodati
24
Primjeri radnih okvira
•
•
•
•
•
•
Radni okvir za rukovanje plaćama.
Radni okvir za rukovanje čestih putnika (engl. frequent flyer) u
avioprometu.
Radni okvir za rukovanje čestih kupaca.
Radni okvir za upis i registraciju predmeta na fakultetu.
Radni okvir za komercijalno web sjedište (e-dućan).
Radni okvir za mrežnu uslugu XYZ .
25
Uporaba objektnog klijent-poslužitelj radnog
okvira (engl. Object Client-Server Framework - OCSF):
OCSF = skup apstraktnih i konkretnih razreda
Postupak uporabe:
•
•
•
•
•
Ne mijenjati apstraktne razrede u OCSF.
Kreirati podrazrede.
Konkretizirati metode u podrazredima.
Nanovo definirati (engl. override) neke metode u podrazredima.
Napisati kod koji kreira instance i inicira akcije.
Izvorni kod OCSF u Javi nalazi se na web stranicama knjige (potrebno
proučiti):
T.C.Lethbridge, R.Laganiere: Object-Oriented Software Engineering, 2nd
ed., McGraw-Hill, 2005.
26
OCSF – tri razreda s istaknutim operacijama
nula ili više
instanci
posebne
oznake dijele
operacije u
kategorije
27
Uporaba OCSF
Programski inženjeri u uporabi OCSF nikada ne
modificiraju tri navedena razreda.
Neke implementirane (konkretne) metode su rigorozno provjerene
(nadamo se) i nisu predviđene za redefiniranje.
Umjesto modifikacije izvornih razreda treba:
• Kreirati podrazrede apstraktnih razreda u radnom okviru i
implementiraj apstraktne metode (učiniti ih konkretnima).
• Redefinirati neke metode posebno označene u kategorije “hook” i
“slot” (vidi raniju sliku apstraktnih razreda) koje su eksplicitno
namijenjene da budu redefinirane.
• Zvati javne metode koje uključuje radni okvir. Te metode su usluge
koje pruža radni okvir (primjensko sučelje – API).
28
Klijentska strana - apstraktan razred: AbstractClient
29
Klijentska strana - AbstractClient
Paralelne aktivnosti na klijentskoj strani
- Čekanje na interakciju s korisnikom i odgovor na interakciju.
- Čekanje na poruku od poslužitelja i reakcija kada poruka stigne.
Ove paralelne aktivnosti izvode se kao višestruke niti izvođenja
(dretve), engl. threads
Bez toga mehanizma, kada bi klijent čekao na jednu vrst ulaza ne bi
mogao raditi ništa drugo niti primati druge vrste ulaza.
U Javi dretva je objekt razreda Thread i uvijek se mora stvoriti:
moja_dretva = new Thread();
Pokreće se pozivom moja_dretva.start() metode koja dalje
aktivira run() metodu unutar koje su funkcionalnosti dretve. To je
ustvari "main()" metoda za dretvu.
30
Paralelne dretve/niti izvođenja – klijentska strana
dretva
nastala
kreiranjem
objekta
klijenta
dretva čitanja
clientReader
kreirana s
openConnection()
dretve kreirane s
clientConnected()
dretva kreirana s
listen()
31
Klijentska strana - AbstractClient
Iz razreda AbstractClient moraju se izvesti podrazredi.
— Podrazred mora osigurati implementaciju operacije:
handleMessageFromServer()
navedenu u skupu <<slot>> oznake. Metoda je zadužena
za odgovarajuću akciju po primitku poruke od poslužitelja.
• Kreirani objekt podrazreda AbstractClient se spaja i šalje
poruke poslužitelju (prva dretva).
• Za čitanje poruka postoji posebna dretva clientReader - vidi
sekvencijski dijagram. Dretva započinje izvođenje nakon što
upravljačka metoda openConnection() pozove
clientReader.start() dretve koja pokreće njenu run()
metodu.
• run() metoda sadrži petlju koja se izvodi tijekom životnog
ciklusa dretve (prima poruke i zove metodu za rukovanje s
porukama).
32
Klijentska strana - AbstractClient
Konstruktor za AbstractClient:
public AbstractClient(String host, int port)
{
// inicijalizacija host i port varijabli
// koje definiraju poslužitelja
this.host = host;
this.port = port;
}
// u pozivu konstruktora postoje konkretni host
// i port
// host i port mogu se postavljati i na drugi
// način – vidi kasnije
33
Kreiranje podrazreda AbstractClient
public class MyClient extends AbstractClient {
. . . // varijable instanci – vidi kasnije
// konstruktor objekta MyClient – prva dretva
public MyClient(String host, int port) {
super(host, port); // iz superrazreda
openConnection(); // upravljačka metoda
}
. . . // druge metode instance
// obvezno konkretizirana metoda
public void handleMessageFromServer(Object msg) {
. . . // implementacija obrade poruke
} }
34
Klijentska strana – metoda openConnection()
// final = ne redefinirati
final public void openConnection(){
// kreira objekt tipa Socket za vezu prema serveru
// parametri host i port servera su u konstruktoru
// ili se mogu postaviti posebnim metodama
clientSocket = new Socket(host, port);
// kreira objekte output i input
// koji šalju i čitaju preko objekta clientSocket
output = new
ObjectOutputStream(clientSocket.getOutputStream());
input = new
ObjectInputStream(clientSocket.getInputStream());
// getOutputStream() i getInputStream() su definirane
// u razredu Socket i zovu se preko clientSocket
35
Metoda openConnection() - nastavak
. . .
// kreiraj dretvu za čitanje poruka poslužitelja
// varijabla clientReader referencira tu dretvu
clientReader = new Thread(this);
// makni zabranu
readyToStop = false;
// startaj dretvu koja aktivira run metodu
clientReader.start();
}
// start() aktivira run() metodu dretve
// koja čeka na poruku poslužitelja i predaje
// poruku metodi handleMessageFromServer()
// za ovu run() metodu čitanja poruke slijedi
// nastavak na slijedećoj slici
36
Klijentska strana – run() prijam poruke
final public void run() { // ne redefinirati
Object msg;
// varijabla za poruku
try {
while(!readyToStop) {
// dohvat poruke s poslužitelja i poziv metode
// za obradu poruke
// dretva čeka poruku na slijedećoj naredbi
msg = input.readObject();
// i kada stigne zove metodu
// handleMessageFromServer() za obradu poruke
if (!readyToStop) {
handleMessageFromServer(msg); }
} }
________________________________________________________
U ovom skraćenom prikazu izbačen je dio try-catch za
manipulaciju iznimkama: catch(Exception ex) {}
37
Klijentska strana – slanje poruke i završetak
Ostale <<control>> operacije
public void sendToServer(Object msg) {
output.writeObject(msg); }
// writeObject je definiran u razredu
// ObjectOutputStream
// output preko clientSocket zna kome šalje
final public void closeConnection() {
readyToStop = true;
closeAll(); }
// closeAll() je implementirana u radnom okviru
_________________________________________________________
U ovom skraćenom prikazu izbačen je catch dio u bloku trycatch za manipulaciju iznimkama: catch(Exception ex) {}
38
Privatni dijelovi razreda AbstractClient
Osobe zadužene za oblikovanje programske potpore ne moraju znati
te detalje, ali može pomoći (implementacija na slijedećoj slici).
Varijable instanci:
• clientSocket (tipa Socket) koja drži sve informacije o vezi s
poslužiteljem (kanal komunikacije).
• output i input tipa ObjectOutputStream i
ObjectInputStream koji se koriste za slanje i prijam objekata
msg (tipa Object)uporabom varijable clientSocket.
• Dretva clientReader tipa Thread. Dretva započinje kada
openConnection pozove start() koja inicira run().
• Varijabla boolean readyToStop za signalizaciju zaustavljanja
dretve čitanja poruka servera (vidi raniji prikaz run() metode).
• Sve su deklarirane prije uporabe (vidi slijedeću sliku)
39
Privatni dijelovi razreda AbstractClient
Varijable instance (sve su private):
// kanal za komunikaciju operacijskog sustava
private Socket clientSocket;
// nizovi za manipulaciju izlaza – ulaza
private ObjectOutputStream output;
private ObjectInputStream input;
// dretva čitanja
private Thread clientReader;
// indikacija kada dretva može završiti
private boolean readyToStop;
// poslužiteljevo ime i broj porta
private String host;
private int port;
40
Javno (engl. public) sučelje AbstractClient
Konstructor AbstractClient() pri stvaranju objekta inicijalizira host
i port varijable poslužitelja na koje će se klijent spojiti.
Upravljačke (<<control>>) metode
• openConnection() (spoj na poslužitelja, koristi host i port
varijable koje inicijalizira konstructor ili preko metoda setHost(),
setPort()
• sendToServer() ( šalje poruku koja može biti bilo koji objekt).
• closeConnection() (zaustavlja rad dretve u petlji i završava).
Pristupne (<<accessor>>) methode (daju info ili mijenjaju vrijednost):
• isConnected() (ispituje da li je klijent spojen)
• getHost() (ispituje koji host – server je spojen)
• setHost() (omugućuje promjenu hosta - dok je klijent odspojen)
• getPort() (ispituje na koji port servera je klijent spojen)
• setPort() (omogućuje promjenu porta dok je klijent odspojen).
• getInetAddress() (dobavlja neke detaljnije informacije o vezi)
41
Callback ( <<hook>>) metode u AbstractClient
Metode koje se mogu redefinirati (ako podrazred ima namjeru
poduzeti neke akcije kao odziv na događaj)
“Callback” metode označene su kao skupina «hook».
• connectionEstablished() (aktivira se uspostavom veze s
poslužiteljem)
• connectionClosed() (aktivira se nakon završetka veze)
• connectionException() (aktivira se kada nešto pođe krivo,
npr. poslužitelj prekida vezu).
Callback funkcije su one koje se ne zovu izravno. (npr. u C++
zovu se preko pokazivača).
Najčešće se callback funkcije zovu kao odziv na neki asinkroni
događaj (sva moderna grafička korisnička sučelja zasnovana su
na callback funkcijama, npr. odziv na miša).
42
Callback metode u AbstractClient
OCSF obično ne implementira te metode. Korisnik ih može redefinirati:
protected void connectionEstablished() {}
// Aktivira se kad je uspostavljena veza
// “Default” implementacije ne čini ništa
// Može se ponovo redefinirati ako potrebno
// slično za završetak veze
protected void connectionClosed() {}
// kao i za obradu iznimke
protected void connectionException(
Exception exception) {}
43
Sažetak: Uporaba razreda AbstractClient
• Kreiraj podrazred od AbstractClient
• U podrazredu implementiraj handleMessageFromServer()
<<slot>> metodu
• Napiši kod koji:
—Kreira instancu klijenta (podrazreda, start prve dretve)
—Pozove openConnection() (start druge dretve)
—Šalje poruku poslužitelju uporabom sendToServer() metode
• Implementiraj connectionEstablished() callback metodu (npr.
izvijesti korisnika)
• Implementiraj connectionClosed() callback (npr. izvijesti
korisnika o čistom završetku veze).
• Implementiraj connectionException() callback (npr. kao odziv
na kvar na mreži).
44
Poslužiteljska strana
45
Poslužiteljska strana
Poslužiteljska strana sadrži dva razreda pa je nešto složeniji rad.
Potrebne su najmanje dvije niti izvođenja (dretve):
- jedna koja sluša novo spajanje klijenta,
- druga (ili više) koja rukuje vezama s klijentima (vidi sekvencijski
dijagram).
Instanca razreda AbstractServer –
Sluša novo spajanje klijenta.
Rukuje s porukom. Ne šalje poruku pojedinom klijentu (to čini instanca od
ConnectionToClient), ali može poslati istu poruku svim
spojenim klijentima metodom sendToAllClients().
Jedna ili više instanci razreda ConnectionToClient –
Rukuje komunikacijama s klijentima i šalju im poruke.
46
Paralelne dretve/niti izvođenja - poslužiteljska strana
dretve kreirane kada i objekti
dretva
connectionListener od ConnectionToClient
kreirana s listen()
47
AbstractServer
48
Javno (engl. public) sučelje AbstractServer
Constructor AbstractServer(), stvara objekt s brojem porta na kojem
poslužitelj sluša. Kasnije se može promijeniti sa setPort() metodom.
Upravljačke (<<controll>>) metode:
• listen() (kreira varijablu/objekt serverSocket koja će slušati na portu
specificiranom konstruktorom, kreira i inicira dretvu, a run() metoda dretve
čeka na spajanje klijenta)
• stopListening() (signalizira run() metodi da prestane slušati. Spojeni
klijenti i dalje komuniciraju).
• close() (kao stopListening() ali odspaja sve klijente)
• sendToAllClients() (šalje poruku svim spojenim klijentima, jedina metoda
iz ove skupine koja se može redefinirati (nije final).
Pristupne (<<accessor>>) metode (ispituju stanje servera):
• isListening() (vraća da li poslužitelj sluša)
• getClientConnections() (vraća niz instanci razreda za vezu s klijentima
ConnectionToClient, može se iskoristiti za neki rad sa svim klijentima)
• getPort() (vraća na kojem portu poslužitelj sluša)
• setPort() (koristi se za slijedeći listen(), nakon zaustavljanja)
• setBacklog() (postavlja veličinu repa čekanja klijenata na "portu")
49
Ostale metode u AbstractServer
Metoda koja se mora implementirati (najvažniji dio koda):
• handleMessageFromClient() (argumenti su primljena poruka te
tko šalje - instanca razreda ConnectionToClient)..
Callback metode koje se mogu redefinirati (aktiviraju se kao odziv na
neki događaj).
• serverStarted() (aktivira se kada poslužitelj započinje prihvaćati
spajanja).
• clientConnected() (aktivira se kada se novi klijent spoji)
• clientDisconnected() (aktivira se kada poslužitelj odspoji
klijenta, argument je instanca razreda ConnectionToClient.
• clientException() (aktivira se kada se klijent sam odspoji ili
kada nastupi kvar u mreži)
• serverStopped() (aktivira se kada poslužitelj prestane prihvaćati
povezivanje s klijentima a kao rezultat stopListening()).
• listeningException() (aktivira se kada poslužitelj prestane slušati
zbog nekog kvara).
• serverClosed() (aktiivraa se nakon završetka rada poslužitelja).
50
ConnectionToClient
Po jedan
objekt/instanca za
svakog spojenog
klijenta
«control»
metode
«accessor»
metode
Tko kreira instancu ?
Početna aktivacija metode listen() u AbstractServer pokreće
dretvu koja u svojoj run() metodi preko metode accept() "socketa"
poslužitelja čeka na spajanje i kreira objekt/instancu razreda
ConnectionToClient (s pripadnom dretvom) - po jedan za svako
spajanje klijenta
51
Javno (engl. public) sučelje ConnectionToClient
ConnectionToClient je konkretan razred. Korisnici ne moraju
kreirati podrazrede.
Za svakog klijenta dok je spojen na poslužitelja kreira se instanca razreda
ConnectionToClient.
Upravljačke (<<controll>>) metode:
• sendToClient() (središnja metoda, koristi se za komunikaciju s
klijentom).
• close() (odspaja klijenta)
Pristupne (<<accessor>>) metode:
• getInetAddress() (dobavlja Internet adresu klijenta)
• setInfo() (omogućuje spremanje proizvoljnih informacija o
klijentu. Npr. posebne privilegije za neke klijente)
• getInfo() (omogućuje čitanje informacija spremljene sa
setInfo()).
52
Uporaba AbstractServer i ConnectionToClient
•
•
Kreiraj podrazred od AbstractServer razreda.
U podrazredu implementiraj handleMessageFromClient() .
•
Napiši kod koji:
— Kreira instancu podrazreda od AbstractServer
— Poziva listen() metodu
— Eventualno odgovara na "call back" clientConnected()
slanjem poruke uporabom metoda iz AbstractServer:
- getClientConnections() ili sendToAllClients()
(pazi: to nisu callback metode)
Implementiraj jednu ili više drugih callback metoda kao odzive na
zanimljive događaje.
•
53
Sinkronizacija rada s više klijenata i druge aktivnosti
Mnoge metode na poslužiteljskoj strani su sinkronizirane. Budući
da postoji više ConnectionToClent objakata/dretvi, koje mogu
istovremenu mijenjati podatke na poslužitelju, sinkronizacija
garantira da se kritične operacije odvijaju jedna po jedna, te se tako
čuva integritet podataka.
Kolekcija objekata razreda ConnectioToClient koje održava
AbstractServer smješteni su u poseban razred (u Javi)
ThreadGroup. Objekt toga razreda će automatski maknuti
instancu kada njena dretva završi radom.
Poslužitelj mora povremeno (npr. svakih 500ms) provjeriti da li je
pozvana metoda stopListening()jer je slušanje rad u samo
jednoj dretvi.
54
Dijelovi implementacije AbstractServer
Varijable instance (privatni dijelovi) s početnim vrijednostima
// pazi - ServerSocket i Socket su različiti razredi
private ServerSocket serverSocket = null;
// dretva slušanja na spajanje klijenta
private Thread connectionListener = null;
// broj porta poslužitelja
private int port;
// povremeni prekid za provjeru na “stop slušanja”
private int timeout = 500;
// duljina repa čekanja klijenata na spajanje
private int backlog = 10;
// grupa dretvi pridružena grupi spojenih klijenata
private ThreadGroup clientThreadGroup;
// indikacija da li je slušanje spremno za završetak
private boolean readyToStop = true;
55
Dijelovi implementacije AbstractServer
Konstruktor objrkta poslužitelja:
public AbstractServer(int port) {
// iniciranje porta poslužitelja
this.port = port;
// iniciranje objekta/strukture za klijente
this.clientThreadGroup =
new ThreadGroup(“ConnectionToClient Threads”); }
Metode instance:
final public void listen() {
// definiranje konekcije i start dretve slušanja
// serverSocket zna za port slušanja i rep čekanja
serverSocket = new ServerSocket(getPort(),backlog);
connectionListener = new Thread(this);
connectionListener.start(); }
// start() pokreće run() metodu dretve, nastavak
56
Dijelovi implementacije AbstractServer
run() metoda u AbstractServer (u ovom prikazu nije uključena
manipulacija iznimkama):
final public void run() {
// poslužitelj skida zabranu rada
readyToStop = false;
// poziv callback metode za opcijsku akciju
serverStarted();
// čekaj na spajanje klijenta, kad se spoji
// podatke o klijentu stavi u varijablu clientSocket
while(!readyToStop)
Socket clientSocket = serverSocket.accept();
// konstruiraj novu instancu ConnectionToClient
// pozivom njegovog konstruktora s parametrom socketa
// klijenta
// dodaj ga u grupu i pokreni njegovu dretvu
new ConnectionToClient(this.clientThreadGroup,
clientSocket, this); }
57
Dijelovi implementacije ConnectionToClient
Varijable instanci (privatni dijelovi):
// razred ConnectionToClient mora znati za poslužitelja
// asocijacija između razreda
private AbstractServer server;
// komunikacijski kanal klijenta
private Socket clientSocket;
// nizovi za čitanje i pisanje
private ObjectInputStream input;
private ObjectOutputStream output;
// indikacija da li je dretva spremna na zaustavljanje
private boolean readyToStop;
58
Dijelovi implementacije ConnectionToClient
Konstruktor objekta ConnectionToClient (biti će pozvan kada se neki klijent
spoji (varijabla clientSocket dobiva podatke o klijentu).
protected ConnectionToClient(ThreadGroup group,
Socket clientSocket, AbstractServer server) {
// inicijalizacija varijabli u novo stvorenom objektu
// razreda ConnectionToClient
this.clientSocket = clientSocket;
this.server = server;
// inicijalizacija nizova za poruku
input = new
ObjectInputStream(clientSocket.getInputStream());
output = new
ObjectOutputStream(client.Socket.getOutputStream());
// start svoje dretve
readyToStop = false;
start(); }
//aktivira run() metodu -> slijedeća slika
59
Dijelovi implementacije ConnectionToClient
run() metoda u ConnectionToClient
final public void run() {
// signal da je klijent spojen
// clientConnected() je "callback" u poslužitelju za
// eventualni odziv npr. preko sendToAllClients()
server.clientConnected(this);
// čekanje, prihvat i obrada poruke
Object msg;
while(!notReadyToStop) {
msg = input.readObject();
// manipulacija porukom preko
// metode razreda AbstractServer
server.handleMessageFromClient(msg, this);
. . . }} // razni odzivi na iznimke
Slanje poruke klijentu (nije dio run() metode):
public void sendToClient(Object msg) {
Output.writeObject(msg)}
60
Primjena OCSF-a: Jednostavan “Chat”
Jednostavan klijent-poslužitelj “instant messaging” sustav:
Zadatak:
Poslužitelj vraća poruku primljenu od nekog klijenta
svim spojenim klijentima.
Izvorni kod programske potpore u Javi nalazi se na web
stranicama knjige (potrebno proučiti):
T.C.Lethbridge, R.Laganiere: Object-Oriented Software
Engineering, 2nd ed., McGraw-Hill, 2005.
61
Jednostavan “Chat”
ConnectionToClient
sučelje je
odvojeno
Započinje s
radom i
implementira
sučelje
OCSF
*
1
Vraća poruke
klijenta svim
ostalim spojenim
klijentima
62
“Chat” poslužitelj
ConnectionToClient
OCSF
*
1
Razred poslužitelja naziva se EchoServer i nastaje kao
podrazred od AbstractServer iz OCSF-a.
EchoServer nema korisničkog sučelja. Nakon
pokretanja izvodi se bez prekida (do primitka npr.
programskog signala kill()).
Glavna metoda (main()) u EchoServer kreira
instancu i poslužitelj počinje slušati pozivom
listen() metode iz AbstractServer.
Metoda handleMessageFromClient() (koja se
uvijek implementira) zove metodu
“static” main
sendToAllClients() ( naslijeđenu iz
AbstractServer) koja prosljeđuje poruku svim metoda
klijentima.
Na slici je prikazan razred ConnectionToClient od
kojega postoje instance za spojene klijente (ali se
ne koriste njihove metode sendToClient(), već
metoda sendToAllClients()poslužitelja.
redefinirane
callback metode
63
Dio implementacije EchoServer (1)
// stvaranje podrazreda
public class EchoServer extends AbstractServer {
final public static int DEF_PORT = 5555;
// konstruktor objekta s definiranim portom slušanja
// na koji se spajaju klijenti
public EchoServer(int port) { super(port); }
// metoda za rukovanje porukom
public void handleMessagFromClient
(Object msg, ConnectionToClient client) {
System.out.println("Message received: "
+ msg + " from " + client);
// i slanje svim spojenim klijentima
this.sendToAllClients(msg); }
. . .
// odzivi na neke call-back metode
64
Dio implementacije EchoServer (2)
Jednostavan "Chat" započinje najprije aktiviranjem poslužitelja.
// početna metoda u poslužitelju
public static void main(String[] args)
{
port = DEF_PORT;
// kreiranje objekta poslužitelja pozivom njegovog
konstruktora i referenciranog preko varijable sv
EchoServer sv = new EchoServer(port);
// započinjanje slušanje
sv.listen();
} // kraj main metode
} // kraj razreda EchoServer
65
Klijent za "chat"
ChatClient je podrazred od
AbstractClient.
ChatClient realizira metodu
handleMessageFromServer()
koja samo inicira prikaz poruke
korisniku pozivom display().
Druge dvije metode u ChatClient
pozivane su od objekta razreda
ClientConsole.
ChatIF je sučelje odvojeno od
funkcijskog dijela, t.j. od
ChatClient.
Implementaciju sučelja (samo jedne
metode display()) obavlja razred
ClientConsole.
Metodu display() zove objekt iz
razreda ChatClient
OCSF
static metoda
66
Klijent za "chat"
Klijentski program započinje s main() metodom u ClientConsole. Ona
kreira instance od dva razreda (ClientConsole i ChatClient) koje se
izvode u dvije odvojene dretve :
• ClientConsole (nije podrazred od AbstractClient)
—implementira sučelje, t.j display() metodu koja prikazuje poruku
na konzoli.
—prihvaća ulaz korisničkih podataka preko implementirane accept()
metode koja šalje te podatke objektu razreda ChatClient pozovom
njegove nove metode handleMessageFromClientUI().
• ChatClient ( podrazred od AbstractClient)
— implementira handleMessageFromServer(), i samo zove
display() metodu korisničkog sučelja.
— metoda handleMessageFromClientUI()prima poruku od
ClientConsole i zove metodu sendToServer() (to je javna
metoda u AbstractClient).
67
Dio implementacije razreda ChatClient
public class ChatClient extends AbstractClient {
// var clientUI je tipa sučelja, treba radi display()
ChatIF clientUI;
// pridruživanje sa sučeljem
// konstruktor objekta od ChatClient
public ChatClient(String host, int port, ChatIF clientUI){
super(host, port);
// poznavanje servera
this.clientUI = clientUI;
// poznavanje sučelja
openConnection(); } // početak veze s poslužiteljem
// rukovanje primljenom porukom poslužitelja i njen prikaz
public void handleMessageFromServer(Object msg) {
clientUI.display(msg.toString()); }
// rukovanje porukom s korisničke konzole i slanje
public void handleMessageFromClientUI(String message) {
sendToServer(message); } // naslijeđena metoda }
// postoje još iznimke, zatvaranje veze i prestanak rada
68
Dio implementacije razreda ClientConsole (1)
public class ClientConsole implements ChatIF {
// odredi port, varijabla razreda
final public static int DEF_PORT = 5555;
// varijabla instance, asocijacija s ChatClient
ChatClient client;
// konstruktor stvara client, t.j.objekt od ChatClient
public ClientConsole(String host, int port) {
client= new ChatClient(host, port, this); }
// prihvat poruke od korisnika i poziv metode u client
public void accept() { BufferedReader fromConsole =
new BufferedReader(new InutStreamReader(System.in));
String message;
while (true) {
message = fromConsole.readLine();
client.handleMessageFromClientUI(message); }
nastavak na slijedećoj slici
69
Dio implementacije razreda ClientConsole (2)
// metoda display() sučelja je implementirana ovdje
public void display(String message) {
System.out.println("> " + message); }
// glavna početna metoda
public static void main(String[] args) {
host = "local host";
// kreacija objekta chat iz ovoga razreda ClientConsole
ClientConsole chat=
new ClientConsole(host, DEF_PORT);
// pozivom konstruktora ClientConsole() stvara se i drugi
// objekt client od razreda ChatClient
// vidi ranije detalje konstruktora ClientConsole()
// čekanje i prihvat poruke od korisnika
chat.accept();
}
} // kraj razreda ClientConsole
// ispušteni su nebitni detalji rukovanja s iznimkama
70
Implementacija sučelja ChatIF
public interface ChatIF
{
// prikazuje poruku metodom display()
public abstract void display(String message);
}
// display()se implementira u razredu ClientConsole
71
Rizici u primjeni klijent – poslužitelj arhitekture
• Sigurnost
Sigurnost je veliki problem bez savršenog rješenja. Potrebno
uporabiti enkripciju, zaštitne zidove (engl. firewalls) i sl.
• Potreba za adaptivnim održavanjem
Budući da se programska potpora za klijente i poslužitelja
oblikuje odvojeno potrebno je osigurati da sva programska
potpora bude kompatibilna prema unatrag (engl. backwards) i
prema unaprijed (engl. forwards), te kompatibilna s drugim
verzijama klijenata i poslužitelja.
72
Principi oblikovanja i raspodijeljena arhitektura
1. Podijeli i vladaj: Podjelom sustava na klijenta i poslužitelja je
uspješan način optimalne podjele.
—Klijent i poslužitelj mogu se oblikovati odvojeno.
2. Povećaj koheziju: Poslužitelj osigurava kohezijski spojenu uslugu
klijentima.
3. Smanji međuovisnost: Uobičajeno je da postoji samo jedan
komunikacijski kanal preko kojega se prenose jednostavne poruke.
4. Povećaj apstrakciju: Odvojene raspodijeljene komponente su dobar
način povećanja apstrakcije.
6. Povećaj uporabu postojećeg: Često je moguće pronaći
odgovarajući radni okvir (engl. framework) temeljem kojega se
oblikuje raspodijeljeni sustav. Međutim, klijent-poslužitelj
arhitektura je često specifična obzirom na primjenu.
73
Principi oblikovanja i raspodijeljena arhitektura
7. Oblikuj za fleksibilnost: Raspodijeljeni sustavi se često vrlo lako
mogu rekonfigurirati dodavanjem novih poslužitelja ili klijenata.
9. Oblikuj za prenosivost: Klijenti se mogu oblikovati za nove
platforme bez promjene poslužiteljske strane.
10. Oblikuj za ispitivanje: Klijenti i poslužitelji mogu se ispitivati
neovisno.
11. Oblikuj konzervativno: U kod koji rukuje porukama mogu se
ugraditi vrlo stroge provjere (npr. rukovanje iznimkama).
74
75
Objektno usmjerena arhitektura – 2.dio
Posrednička arhitektura
Predstavlja proširenje raspodijeljene arhitekture klijent – poslužitelj.
Proširenje se ogleda kroz:



Više razina (naslaga, slojeva), (engl. tiers)
Uvođenje posebnog među-sloja (engl. middleware).
“Brokerska” arhitektura.
76
Posrednička arhitektura
Uvođenje više razina (engl. tiers)







Klijenti i poslužitelji organiziraju se u razine (slojeve, naslage).
Svaka razina pruža uslugu razini iznad.
Svaka razina oslanja se na razinu ispod.
Razina zatvara (skriva, enkapsulira) skup usluga i
implementacijske detalje niže razina o kojoj ovisi (analogno
razredu).
Često niža razina predstavlja “virtualni stroj” za razinu iznad.
Višerazinska arhitektura nije u posebnom smislu slojevita (engl.
layered).
Slojevita (engl. layered) se odnosi na strukturu modula,
dakle statički pogled, dok se višerazinska (engl. tiered)
odnosi na organizaciju u izvođenju (engl. run-time), dakle
dinamički/funkcionalni pogled.
77
Posrednička arhitektura
Trorazinska klijent-poslužitelj arhitektura (engl. 3-tiered)




To je generalizacija klijent-poslužitelj arhitekture.
Znatno bolje promovira skalabilnost i mogućnost jednostavnije
modifikacije.
Nastoji otkloniti neke nedostatke klasične klijent-poslužitelj
arhitekture, a posebice nastoji povećati performanse,
raspoloživost, i sigurnost.
Općenito trorazinska arhitektura sadrži
Korisnička razina
korisničku razinu
(engl user tier), logičku ili
Logička razina
poslovnu razinu (engl. business tier),
te podatkovnu razinu (engl. data tier).
Razina podataka
78
Posrednička arhitektura
Trorazinska klijent-poslužitelj arhitektura (engl. 3-tiered)
Postoje mnoge varijacije trorazinske arhitekture, ovisno koliko se
funkcionalnosti pridodaje svakoj razini.
?
79
Posrednička arhitektura
Uvođenje posredničke razine (engl. middleware)





Nalazi se između klijenta i poslužitelja.
Skriva osobama koji oblikuju raspodijeljeni sustav detalje
operacijskog sustava i druge specifičnosti implementacije.
Posrednička razina preuzima detalje komunikacijske mreže.
Omogućuje osobama koje oblikuju raspodijeljeni sustav da se
usredotoče na primjenski (aplikacijski dio).
Time se lakše oblikuju i razvijaju raspodijeljeni sustavi.
80
Posrednička arhitektura
Uloga posredničke razine (engl. middleware)
81
Posrednička arhitektura
Postoje tri vrste posredničkih arhitektura:

Transakcijski usmjerena (komunikacija s bazama podataka).

Zasnovana na porukama (pouzdana, asinkrona komunikacija).

Objektno usmjerena (sinkrona komunikacija između
raspodijeljenih OBJEKATA).
Najpopularnija objektno usmjerena arhitektura obuhvaća:
CORBA, DCOM, DotNET, EJB (Enterprise JavaBeans, zasnovana na
aktiviranju poruka, engl. Remote Message Invocation - RMI).
Svi ovi posrednički sustavi (referencirani kao Objektno usmjerena
posrednička arhitektura) su zasnovani na udaljenom pozivanju
procedura(engl. Remote Procedure Call - RPC) .
Te arhitekture proširuju RPC uvođenjem mehanizama iz objektno
usmjerene paradigme.
82
Posrednička arhitektura
Tradicijski UNIX,
(1980.g.), kasnije
različite
implementacijske
tehnologije
U objektno usmjerenom
kontekstu: Remote Method
Invocation (RMI)
Must know all
about server
Possible
waiting for
response
Possible answer
83
Posrednička arhitektura
Arhitektura s više razina (engl. n-tier)

Funkcionalne odgovornosti (najviša razina apstrakcije
funkcionalnih zahtjeva u objektno usmjerenoj paradigmi) se
raščlanjuju i pridjeljuju razinama.

Primjer web programa:

Prezentacijska razina

Povezivanje

Web usluge

Logička (poslovna) razina

Podatkovna razina
(trajno čuvanje)
84
Posrednička arhitektura
Arhitektura s više razina (engl. n-tier)

Potrebno je razlikovati funkcionalne odgovornosti od skupa
komponenata u izvođenju (izvođenje odgovornosti).

Preslikavanje odgovornosti na komponente u izvođenju može se
izvesti na više načina.
85
Korisnik
INDEX
mali izresci
DOC
86
Posrednička arhitektura
Arhitektura s više razina (engl. n-tier)








Prednosti:
Oblikovanje temeljem više razine apstrakcije.
Podupire lagano proširenje i promjene sustava (promjena na
jednoj razini utječe samo još na razinu ispod i iznad).
Podupire ponovno korištenje, prenosivost i sl.
Nedostaci:
Teško je odrediti optimalno preslikavanje odgovornosti na
razine.
Ponekad se izračunavanje i funkcionalnosti sustava ne mogu
razbiti na razine.
Ako se želi poboljšati performanse mora se preskakati ili
“tunelirati” kroz razinu.
87
Posrednička arhitektura
Trorazinska klijent-poslužitelj arhitektura (engl. 3-tiered)
Postoje mnoge varijacije trorazinske arhitekture, ovisno koliko se
funkcionalnosti pridodaje svakoj razini.
?
88
Posrednička arhitektura
“Brokerska” arhitektura (“broker” = posrednik)
= standardizacija međusloja (engl. "Middleware")





U objektno usmjerenom stilu arhitekture uvodi se specifična
posrednička razina (engl. specific middleware) koja omogućuje
interoperabilnost u heterogenim sustavima (različiti operacijski
sustavi, različiti programski jezici) u raspodijeljenom okruženju.
To je infrastruktura za raspodijeljene objekte. Time se
transparentno alociraju pojedini aspekti programske potpore na
pojedine čvorove u mreži.
CORBA (Common Object Request Broker Architecture) je jedna
vrlo popularna i standardna posrednička razina za oblikovanje
raspodijeljenih objektno usmjerenih sustava.
O CORBA standardu brine se OMG (Object Managemant Group).
Postoji više implementacija CORBA posredničke razine.
89
Posrednička arhitektura
Što je CORBA model ?





Poslužiteljski objekti posjeduju sučelje koje je neovisno o bilo
kojem programskom jeziku. Dostupno je preko jezika IDL koji se
prevodi u standardne programske jezike (Java, C++, …).
Klijent rukuje podacima i metodama u poslužiteljskom objektu samo
preko sučelja. Sve ostalo (implementacija) potpuno je sakriveno
klijentu. Objekt na poslužiteljskoj strani je tipa interface.
Klijenti i poslužitelji mogu se programirati različitim programskim
jezicima (ali svaki takav programski jezik mora imati kopče za
CORBA-u). To je jezična transparentnost na razini izvornog koda
(ne na binarnoj/izvršnoj razini).
Klijenti i poslužitelji ne brinu se o lokaciji jednog ili drugog. To je
lokacijska transparentnost. Klijenti i poslužitelji mogu biti
implementirani na različitim sklopovskim platformama i operacijskim
sustavima.
CORBA objekti mogu se relocirati po čvorovima u mreži.
90
Posrednička arhitektura – lokani objekti
Što je CORBA model ?
Komunikacija
između klijenta i
poslužiteljskog
objekta unutar
jednog procesa.
Posrednik ORB (Object Request Broker), u obliku programske knjižnice
na strani klijenta i poslužitelja prenosi prevedeni zahtjev klijenta do
poslužiteljskog objekta a pruža i druge servise. Oslanja se i instalira
izravno na operacijski sustav i mrežne servise (TCP/IP).
91
Posrednička arhitektura – udaljeni objekti
IIOP - Internet Inter ORB Protocol
Komunikacija između klijenta i poslužiteljskog objekta u
raspodijeljenim sustavima.
92
Posrednička arhitektura
•
CORBA objekti su zatvoreni i pristupa im se samo preko sučelja. CORBA
objekti su tipa interface (analogno razredu) i implementiraju se u poslužitelju.
•
Za jedno sučelje može postojati više implementacija, a jedna implementacija
može podržavati više sučelja.
•
Identitet objekta se proširuje kako bi sadržavao dodatnu informaciju kao što je
lokacija objekta (npr. host i port broj poslužitelja). Sve to zajedno čini "object
reference".
•
Kako bi se locirao objekt za vrijeme izvođenja, klijent mora znati njegov
"reference". To je tekstovni niz kodiran na specifičan način (klijent ga dekodira) i
sadrži dovoljno informacija da se:
•
•
Uputi zahtjev ispravnom poslužitelju (host, port)
•
Locira ili kreira objekt (ime razreda, podaci/atributi)
"Object reference" se može dobiti na više načina u okviru standardnih ORB
servisa.Najčešće se čita datoteka u koju je poslužitelj upisao referenciju.
93
Posrednička arhitektura
Što su Stub i Skeleton ?
Stub i Skeleton su dijelovi CORBA arhitekture koji preslikavaju programski jezik
klijenta i poslužitelja u pozivanje odgovarajuće uslužne metode. Generiraju se
automatski programiranjem sučelja IDL jezikom. IDL spaja i pomiruje različite
objektne modele i programske jezike.
94
Posrednička arhitektura
Proces oblikovanja uporabom IDL-a koji povezuje klijenta i poslužitelja
Npr: idl2java
translator
generira
oba izvorna
programa
Klijentska strana poziva
metode objekta
Poslužiteljska strana
implementira objekt
95
Posrednička arhitektura
Primjer IDL specifikacije udaljenog objekta "Accounting"
(IDL je poseban jezik sličan pojednostavljenom C++):
module Money { // u jednom modulu može biti više objekata
interface Accounting {
// to je CORBA objekt i njegova
float get_outstanding_balance();};}; // apstraktna metoda
Uporaba CORBA objekta u klijentu (pisanom u jeziku Java):
import org.omg.CORBA.*;
// uvezi sve potrebno
public class Client {
public static void main(String args[]) {
// inicijaliziraj ORB preko lokalne var "orb"
ORB orb = ORB.init(args, null);
// var "acc" referncira udaljeni objekt preko servisa imena
Money.Accounting acc
=Money.AccountingHelper.bind(orb,"Account");
// poziv metode u CORBA objektu
float balance = acc.get_outstanding_balance();
96
Principi oblikovanja i posrednička arhitektura
1. Podijeli i vladaj: Udaljeni objekti mogu biti neovisno oblikovani.
5. Povećaj ponovnu uporabu: Moguće je i poželjno oblikovati
udaljene objekte tako da ih i drugi sustavi mogu koristiti.
6. Povećaj uporabu postojećeg: Možeš koristiti objekte koje su drugi
oblikovali.
7. Oblikuj za fleksibilnost: Posrednik (broker) se može ažurirati.
Objekti se mogu zamijeniti.
9. Oblikuj za prenosivost: Možeš oblikovati klijente za novu
platformu i još uvijek pristupati postojećim brokerima i udaljenim
klijentima na drugim platformama.
11. Oblikuj konzervativno: Možeš rigorozno provjeriti nedvosmisleno
ponašanje udaljenih objekata (Java: try – catch iznimke).
97
Objektno usmjerena arhitektura – 2.dio
Uslužno usmjerena arhitektura
Uobičajena su dva naziva:
Service oriented architecture (SOA)
Service oriented architectural pattern (SOAP)
98
Uslužno usmjerena arhitektura
Uslužno usmjerena arhitektura organizira primjenski program
(cjelovitu aplikaciju) kao kolekciju usluga koje međusobno
komuniciraju uporabom dobro definiranih sučelja.



U kontekstu Interneta, usluge se nazivaju web usluge.
Web usluga je primjenski program kojem se može pristupiti preko
Interneta i koji se može integrirati s drugim uslugama na
web-u kako bi se oblikovao cjeloviti sustav.
Različite komponente u web uslužnom sustavu komuniciraju
uporabom otvorenog standarda kao što je XML.
99
Primjer web usluge (UML dijagram)
implementirano
sučelje
uporabljeno
sučelje
mrežna komunikacija
povezuje
nekoliko
usluga
100
Model web uslužne arhitekture
Model pokazuje kako se web usluge oglašavaju, otkrivaju selektiraju i
koriste.
Registar
usluga i
posrednik
Oglasi !
Nađi !
Web
Services
Description
Language
Universal
description,
discovery
and
integration
Poveži !
Ponuditelj usluge
Simple Object Access Protocol
Tražitelj usluge
Principi oblikovanja i uslužna arhitektura
1. Podijeli i vladaj: Cijeli primjenski program sastoji se iz neovisno
oblikovanih komponenata - usluga.
2. Povećaj koheziju: Web usluge su strukturirane kao slojevi i imaju
dobru funkcionalnu koheziju.
3. Smanji međuovisnost; Web zasnovani primjenski programi su
slabo vezani, a oblikovani su spajanjem raspodijeljenih
komponenata.
5. Povećaj ponovnu uporabu: Web usluga je posebice značajno
ponovno uporabiva komponenta.
6. Povećaj uporabivost postojećeg: Web zasnovane usluge su
oblikovane ponovnom uporabom postojećih web usluga.
8. Planiraj zastaru: Zastarjele usluge mogu se zamijeniti novim
implementacijama bez utjecaja na primjenske programe koje ih
koriste.
102
Objektno usmjerena arhitektura – 2.dio
Arhitektura programske potpore zasnovana na
komponentama
(engl. Component Based Design - CBD)
Izvor:
A. R. Newton, UC Berkeley
103
Arhitektura zasnovana na komponentama
Pouke temeljem procesa oblikovanja programske potpore s
fokusom na princip ponovnog korištenja (engl. reuse) dijelova.
Objektno
usmjeren
pristup
Oblikovanje
zasnovani na
komponentama
Sastavi
komponente u
jedinstveni
produkt
Teško, traži se
vještina
objektnog
programiranja
Lagano - može
izvesti vješt
korisnik
Oblikuj
komponente
Teško, traži se
vještina
objektnog
programiranja
Jako teško,
mora se voditi
računa o mnogo
korisnika
104
Arhitektura zasnovana na komponentama
Rekapitulacija principa ponovnog korištenja
U fokusu arhitekture zasnovane na komponentama je njihovo
ponovno i višestruko korištenje. Princip višestrukog korištenja
u oblikovanju programske potpore manifestirao se tijekom
vremena kroz:

Ponovno korištenje konzistencije (programski jezici).

Ponovno korištenje fragmenata rješenja (knjižnice).

Ponovno korištenje dijelova arhitekture (arhitekturni obrasci –
engl. architectural patterns, design patterns).

Ponovno korištenje arhitekture (radni okviri – engl. frameworks).

Ponovno korištenje cjelokupne arhitekture sustava.
105
Arhitektura zasnovana na komponentama
Programski jezik:

Uvodi kulturu kako se oblikuje program.

Često uvodi dogmu kako neke stvari treba napraviti.

Programski jezik ne osigurava ispravno oblikovanje ali isključuje mnoge
stvari koje unose pogreške.
Knjižnice:

Prvi programski jezici imali su uključene sve funkcionalnosti.

C jezik (1978) izvlači specifične rutine u knjižnice (npr. i/o).

Od tada postoji tendencija odvajanja posebnih funkcionalnosti.
Arhitekturni oblikovni obrasci:



Nastoji se izgraditi katalog najmanjih ponavljajućih dijelova arhitekture
(obracima) u objektno usmjerenom programiranju.
Obrazac je definiran imenom, opisom problema (s uvjetima) koji rješava,
elementima (razredi, odnosu između razreda, odgovornosti,
kolaboracije), te navođenjem dobrih strana uporabe obrasca.
E.Gamma je 1995 identificirao 23 oblikovna obrasca. Danas znatno više.
106
Arhitektura zasnovana na komponentama
Arhitekturni oblikovni obrasci – najpopularnija literatura
107
Arhitektura zasnovana na komponentama
Radni okviri:
Skup razreda i interakcija.

Radni okviri traže oblikovanje podrazreda i implementaciju nekih
operacija.

Radni okviri najčešće nisu posebno prilagođeni pojedinim primjenama
već oslikavaju određene koncepte.

Cjelokupna arhitektura:
Uvodi zasebne stilove, npr.:


Cjevovodi i filtri

Događajno usmjerena

Repozitorij podataka

Virtualni strojevi

…
108
Arhitektura zasnovana na komponentama
Definicija programske komponente




Programska komponenta je jedinica kompozicije s ugovorno
specificiranim sučeljem i kontekstnom ovisnošću.
Programska komponenta može se nezavisno razmjestiti u sustavu
kojega oblikuju drugi dionici.
Programska komponenta je binarna jedinica kompozicije nezavisno
proizvedena.
Programska komponenta nastoji se potvrditi na tržištu komponenata.
Razlika između objekta i komponente

Definicija objekta je tehnička; ne uključuje pojam nezavisnosti.

Kompozicija objekata nije namijenjena širokom krugu korisnika.

Ne postoji niti će postojati tržište objekata.

Objekti ne podržavaju paradigmu “plug-and-play”.
109
Arhitektura zasnovana na komponentama
Temeljni problem u širokoj uporabi komponenata je nepostojanje
zajedničke platforme (okruženja) koja objedinjuje komponente.



Danas komponente surađuju preko definiranog sučelja:
Vrlo brzo pojavit će se potreba za zajedničkom platformom (novim
“operacijskim sustavom”):
U arhitekturi sustava zasnovanog na web uslugama:
Web = Operacijski sustav
110
Arhitektura zasnovana na komponentama
Potencijalne tehnologije kao temelji oblikovanja programske
potpore zasnovanog na komponentama:
CORBA
Dobro: standard (OMG grupa), transparentna komunikacija između
objekata koji su oblikovani različitim programskim jezicima i žive
na različitim strojevima, u heterogenoj raspodijeljenoj okolini.
Loše: Definirani su na razini izvornog koda, a ne na binarnoj razini.
Uvode se posebni protokoli i razjašnjavanje imena objekata (engl.
name service). To donekle usporava rad iako je prijenos
parametara izveden na binarnoj razini. Svi programski jezici
moraju imati kopče za CORBA sučelje.
111
Arhitektura zasnovana na komponentama
Java/JavaBeans:
Dobro: neovisnost o radnoj platformi, kao reakcija na događaj Beans
komponenta može komunicirati i spajati se s ostalim Beans
komponentama, Beans komponenta se može prilagođavati
specijalnoj primjeni, dostupan izvorni kod.
Loše: pretpostavka virtualnog stroja usporava rad, otkriva se
unutarnja struktura. Uključenje samo u Java programe.
.NET
Dobro: binarni i mrežni standard za komunikaciju između objekata,
primjena u više programskih jezika (C#, VB, Javascript,
VisualC++) , moguća je implementacija više globalno poznatih
sučelja (prva metoda u sučelju je queryInterface() , vraća
oznaku ako sučelje nije podržano).
Loše: (upravljanje memorijom), kompatibilnost (MSWindows).
112
Objektno usmjerena arhitektura - Zaključci






U procesu oblikovanja programske potpore teži se povećanju
razine apstrakcije.
Objektno usmjerena arhitektura povećava razinu apstrakcije
uvođenjem koncepta razreda i njihovih različitih odnosa te
dinamičkih akcija i reakcija njihovih instanci (objekata).
Još višu razinu apstrakcije moguće je postići uporabom radnih
okvira (engl. frameworks) koji predlažu skup apstraktnih razreda
(vidi klijent-poslužitelj radni okvir) primjeren pojedinoj primjeni.
Slijedeća, viša razina apstrakcije obuhvaća posredničku i
uslužnu arhitekturu, tu uporabu gotovih komponenata.
Visoka razina apstrakcije postiže se uporabom gotovih
programskih obrazaca (eng. Design patterns).
Mnogi drže da se najviša razina apstrakcije postiže na razini
korisnika koji bi mogli oblikovati primjenski program. Već danas
postoje radna okruženja za modeliranje na toj razinu (engl.
Domain Specific Modeling, Domain Driven Design).
113
Objektno usmjerena arhitektura - Zaključci
No "one size fits all" !!!
2004. god.
2008. god.
2013. god.
114