oblikovanje programske potpore

1

Oblikovanje programske potpore

MODULARIZACIJA I OBJEKTNO USMJERENA ARHITEKTURA

2. dio

2

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.

3

Objektno usmjerena arhitektura – 2.dio

Raspodijeljeni (engl. Distributed ) sustavi

4

Raspodijeljeni sustaviZnač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.

5

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.

6

Raspodijeljeni sustavi - primjer

implementirano sučelje

korišteno (uporabljeno) sučelje

Primjer raspodijeljenog sustava u kojem klijenti preko poslužitelja doznaju za svoje interese te zatim komuniciraju izravno.

klijenti izmjenjuju poruke

klijenti na poslužitelju traže adrese drugih klijenata

UML oznaka

Dijagram objekata s programskim komponentama

7

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 ?

8


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

9

Klijent – poslužitelj: sekvenca aktivnosti

1. Poslužitelj započinje s radom.

2. Poslužitelj aktivira slušanje i čeka na spajanje klijenta (poslužitelj sluša).

3. Klijenti započinju s radom i obavljaju razne operacije,

— Neke operacije traže zahtjeve (i odgovore) s poslužitelja.

4. Kada klijent pokuša spajanje na poslužitelja, poslužitelj mu to omogući (ako poslužitelj želi).

5. Poslužitelj čeka na poruke koje dolaze od spojenih klijenata.

6. Kada pristigne poruka nekog klijenta poslužitelj poduzima akcije kao odziv na tu poruku.

7. Klijenti i poslužitelj nastavljaju s navedenim aktivnostima sve do odspajanja ili prestanka rada.

10

Poslužitelj u komunikaciji s dva klijenta

početak rada i slušanje

prestanak slušanja

šalje poruku

šalje odgovor

spajanje

odspajanje

11

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 klijent-posluž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, …).

12

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

13

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

14

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. Prihvaća spajanje

2. Odgovara na poruke

3. Rukuje odspajanjem klijenta

Može prestati slušati.

Mora čisto završiti rad.

za svako spajanje: a) rukuje spajanjem, b) reagira na poruku

poslužitelj kao cjelina

događaj

15

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. Odgovara na poruke.

2. Rukuje odspajanjem poslužitelja.

Mora čisto završiti rad.

(Dijagram aktivnosti nema asinkrone događaje koji uvjetuju prijelaze)

interakcija s korisnikom

interakcija s poslužiteljem

Paralelne aktivnosti

16

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.

klijent

poslužitelj

(a) (b)lagano izračunavanje

obilno izračunavanje

17

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.

18

Internet protokoli – skupina TCP/IPInternet 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).

19

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)

20

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

21

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.

22

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

23

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.

24

Vrste radnih okviraHorizontalni 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.

dio koda koji se mora dodati

primjenski program

horizontalni radni okvir

vertikalni radni okvir

usluge koje nudi radni okvir

25

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 .

26

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


27

OCSF – tri razreda s istaknutim operacijama

posebne oznake dijele operacije u kategorije

nula ili više instanci

28

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

29

Klijentska strana - apstraktan razred: AbstractClient

30

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.

31

Paralelne dretve/niti izvođenja – klijentska strana

dretva čitanja clientReader kreirana s openConnection()

dretva nastala kreiranjem objekta klijenta

dretve kreirane s clientConnected()

dretva kreirana s listen()

32


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

33


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

34

Kreiranje podrazreda AbstractClientpublic 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

} }

35

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

36

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

37

Klijentska strana – run() prijam porukefinal public void run() { // ne redefiniratiObject 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) {}

38

Klijentska strana – slanje poruke i završetakOstale <<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 try-catch za manipulaciju iznimkama: catch(Exception ex) {}

39

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)

40

Privatni dijelovi razreda AbstractClientVarijable 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;

41

Javno (engl. public) sučelje AbstractClientKonstructor 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)

42

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

43

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) {}

44

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

45

Poslužiteljska strana

46

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.

47

Paralelne dretve/niti izvođenja - poslužiteljska strana

dretve kreirane kada i objekti od ConnectionToClient

dretva connectionListener kreirana s listen()

48

AbstractServer

49

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")

50

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

51

ConnectionToClient

«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

Po jedan objekt/instanca za svakog spojenog klijenta

52

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

53

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.

54

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.

55

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;

56

Dijelovi implementacije AbstractServer Konstruktor objrkta poslužitelja:public AbstractServer(int port) {// iniciranje porta poslužiteljathis.port = port;// iniciranje objekta/strukture za klijentethis.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

57

Dijelovi implementacije AbstractServer run() metoda u AbstractServer (u ovom prikazu nije uključena manipulacija iznimkama):

final public void run() {// poslužitelj skida zabranu radareadyToStop = false;// poziv callback metode za opcijsku akcijuserverStarted();// čekaj na spajanje klijenta, kad se spoji// podatke o klijentu stavi u varijablu clientSocketwhile(!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); }

58

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;

59

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 ConnectionToClientthis.clientSocket = clientSocket;this.server = server;// inicijalizacija nizova za porukuinput = new ObjectInputStream(clientSocket.getInputStream());output = new ObjectOutputStream(client.Socket.getOutputStream());// start svoje dretvereadyToStop = false;start(); } //aktivira run() metodu -> slijedeća slika

60

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 porukeObject 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)}

61

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


62

Jednostavan “Chat”

Vraća poruke klijenta svim ostalim spojenim klijentima

sučelje je odvojeno

Započinje s radom i implementira sučelje

ConnectionToClient

1

*OCSF

63

“Chat” poslužitelj

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 sendToAllClients() ( naslijeđenu iz AbstractServer) koja prosljeđuje poruku svim 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.

“static” main metoda

redefinirane callback metode

ConnectionToClient

1

*OCSF

64

Dio implementacije EchoServer (1)

// stvaranje podrazredapublic class EchoServer extends AbstractServer {final public static int DEF_PORT = 5555;// konstruktor objekta s definiranim portom slušanja// na koji se spajaju klijentipublic EchoServer(int port) { super(port); }// metoda za rukovanje porukompublic 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

65

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

66

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

static metoda

OCSF

67

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

68

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

69

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

70

Dio implementacije razreda ClientConsole (2)// metoda display() sučelja je implementirana ovdjepublic 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

71

Implementacija sučelja ChatIF

public interface ChatIF

{

// prikazuje poruku metodom display()

public abstract void display(String message);

}

// display()se implementira u razredu ClientConsole

72

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.

73

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.

74

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

76


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.

77


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.

78


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čku razinu (engl user tier), logičku iliposlovnu razinu (engl. business tier),te podatkovnu razinu (engl. data tier).

Korisnička razina

Logička razina

Razina podataka

79


Trorazinska klijent-poslužitelj arhitektura (engl. 3-tiered)Postoje mnoge varijacije trorazinske arhitekture, ovisno koliko se funkcionalnosti pridodaje svakoj razini.

?

80


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.

81


Uloga posredničke razine (engl. middleware)

82


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.

83


U objektno usmjerenom kontekstu: Remote Method Invocation (RMI)

Possible answer

Tradicijski UNIX, (1980.g.), kasnije različite implementacijske tehnologije

Possible waiting for response

Must know all about server

84


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)

85


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.

86

mali izresci

INDEX

DOC

Korisnik

87


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.

88


Trorazinska klijent-poslužitelj arhitektura (engl. 3-tiered)Postoje mnoge varijacije trorazinske arhitekture, ovisno koliko se funkcionalnosti pridodaje svakoj razini.

?

89


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

90


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

91

Posrednička arhitektura – lokani objekti

Što je CORBA model ?

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

Komunikacija između klijenta i poslužiteljskog objekta unutar jednog procesa.

92

Posrednička arhitektura – udaljeni objekti

Komunikacija između klijenta i poslužiteljskog objekta u raspodijeljenim sustavima.

IIOP - Internet Inter ORB Protocol

93


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

94


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

95


Proces oblikovanja uporabom IDL-a koji povezuje klijenta i poslužitelja

Klijentska strana poziva metode objekta

Poslužiteljska strana implementira objekt

Npr: idl2java

generira oba izvorna programa

translator

96


Primjer IDL specifikacije udaljenog objekta "Accounting" (IDL je poseban jezik sličan pojednostavljenom C++):module Money { // u jednom modulu može biti više objekatainterface Accounting { // to je CORBA objekt i njegovafloat get_outstanding_balance();};}; // apstraktna metoda

Uporaba CORBA objekta u klijentu (pisanom u jeziku Java):import org.omg.CORBA.*; // uvezi sve potrebnopublic 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 imenaMoney.Accounting acc

=Money.AccountingHelper.bind(orb,"Account");// poziv metode u CORBA objektufloat balance = acc.get_outstanding_balance();

97

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

98


Uslužno usmjerena arhitektura

Uobičajena su dva naziva:

Service oriented architecture (SOA)Service oriented architectural pattern (SOAP)

99

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.

100

Primjer web usluge (UML dijagram)

mrežna komunikacijaimplementirano sučelje

uporabljeno sučelje

povezuje nekoliko usluga

Model web uslužne arhitektureModel pokazuje kako se web usluge oglašavaju, otkrivaju selektiraju i koriste.

Web Services Description Language

Universal description, discovery and integration

Simple Object Access Protocol

Nađi !Oglasi !

Poveži !

Registar usluga i posrednik

Tražitelj uslugePonuditelj usluge

102

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.

103


Arhitektura programske potpore zasnovana na komponentama

(engl. Component Based Design - CBD)

Izvor:A. R. Newton, UC Berkeley

104

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

Oblikuj komponente

Teško, traži se vještina objektnog programiranja

Jako teško, mora se voditi računa o mnogo korisnika

Lagano - može izvesti vješt korisnik

105


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.

106


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.

107


Arhitekturni oblikovni obrasci – najpopularnija literatura

108


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

…

109


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

110


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

111


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.

112


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

113

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

114

Objektno usmjerena arhitektura - Zaključci

No "one size fits all" !!!

2004. god. 2008. god. 2013. god.

oblikovanje programske potpore

Documents