1. Stiluri si tipare arhitecturale fundamentale

2. Architectural Pattern
“An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.”
[POSA1]/pag.12
Exemple:
Model-View-Controller cu variante pentru GUI: Document-View (MFC), Model-View-Presenter sau aplicatii Web: Model-2
Broker

3. Architectural Style
“An architectural style defines a family of software systems in terms of their structural organization. An architectural style expresses components and the relationships between them, with the constraints of their application, and the associated composition and design rules for their construction.”
[POSA1]/pag.394
Exemplu: stilul Pipes-and-filters
Componente: toate au acelasi tip, Filter.
componente procesatoare de date, au 1 sau mai multe porturi de intrare si 1 sau mai multe porturi de iesire
Relatii dintre 2 componente: conectori Pipe
conector binar unidirectional care transmite fluxul de date de la un port de iesire al unui filtru spre un port de intrare al altui filtru
Constrangeri si reguli:
Un filtru nu trebuie sa cunoasca identitatea filtrelor de la care primeste sau la care transmite date

4. Stiluri arhitecturale fundamentale
Continutul cursului si bibliografie:
Layers
[POSA1] – in 2.2
Pipes and Filters
Blackboard; cu variantele Repository, Active Database
Event-driven (Implicit Invocation); cu variantele Publisher-Subscriber, Event- Bus
[POSA1] – din 3.6
S. Gupta, J. Hartkopf, S. Ramaswamy: Event Notifier, a Pattern for Event Notification, in Java Report, 1998 (republished as chapter 11 in the book More Java Gems, Cambridge University Press, 2000)
Bibliografie generala optionala:
David Garlan, Mary Shaw, An Introduction to Software Architecture, online
POSA

5. Layers
Stilul Layers (pe niveluri): adecvat aplicatiilor care pot fi descompuse in grupuri de subtaskuri, fiecare grup reprezentand un anumit nivel de abstractizare. Fiecare nivel utilizeaza servicii furnizate de nivelul(urile) de sub el
Exemplu tipic:
Stive de protocoale de retea
Fiecare nivel se ocupa de un anumit aspect al comunicarii in retea si utilizeaza serviciile nivelului inferior
POSA

6. Exemplu tipic pentru Layers
POSA1
[POSA]-Fig/P.31

7. Layers: Context & Problema
Un sistem de mari dimensiuni care necesita descompunere in subsisteme (nu poate fi implementat monolitic)
Problema:
Caracteristica dominanta a sistemului este un amestec de operatii de nivel inalt si de nivel scazut de abstractizare, operatiile de nivel inalt depind de operatiile de nivel mai jos
Uneori apare si o structurare pe orizontala, independenta de structurarea verticala pe niveluri: mai multe operatii sunt pe acelasi nivel de abstractizare, dar intre ele independente (exemplu – nivelurile OSI unde apar mai multe functii insirate cu and)
Date initiale: specificatiile functionale pentru operatiile de nivel inalt, descrierea unei platformei tinta, dar cu mentiunea de portabilitate si pentru alte platforme.

8. Layers - Analiza
Interfetele intre layers trebuie proiectate astfel incat sa fie stabile (modificarile facute intr-un layer sa nu afecteze celelalte)
Partile sistemului (layers) trebuie sa fie inlocuibile (se poate inlocui implementarea unui layer)
Partile de nivel mai scazut (layers de la baza stivei) trebuie proiectate astfel incat sa poata fi eventual reutilizate si in alte sisteme
Granularitatea descompunerii in layers trebuie bine determinata !
Granularitate prea mare: (prea putine layers de mari dimensiuni)
Granularitate prea mica: (prea multe layers de mici dimensiuni)

9. Layers: Solutie - structura
Sistemul este structurat pe subsisteme organizate ca o stiva de nivele
Nivelul cel mai jos este Layer1
Nivelul cel mai sus este LayerN
Tiparul se bazeaza pe restrictionarea relatiei uses, aceasta fiind permisa doar intre anumite subsisteme:
LayerJ is allowed to use LayerJ-1
[POSA]-Fig/P.34

10. Layers: structura caracteristica
Fiecare layer ascunde layer-ele de sub el fata de layer-ele de deasupra
[POSA]-Fig/P.35

11. Structura nivelurilor
POSA pag 35
[POSA]-Fig/P.35

12. Layers: Scenarii de comportament
Top-down communication
Bottom-up communication
POSA pag 36

13. Layers: Scenarii de comportament
Top-down communication:
un client adreseaza o cerere nivelului superior LayerN. Acesta are nevoie de serviciile nivelului de sub el pentru a rezolva cererea clientului. Layer N- 1 la randul sau va utiliza Layer N-2, etc, pana ajunge la Layer 1.
Variante: daca nivelurile implementeaza si informatii de “stare”, este posibil ca comunicatia nu ajunga pana la nivelul de jos, ci sa fie rezolvata complet de un nivel intermediar
De obicei, Layer J transpune o cerere primita de la Layer J+1 in mai multe operatii cerute la Layer J-1, considerate la un “nivel de abstractizare mai redus”
POSA pag 36

14. Layers: top-down communication
EVENIMENT, CAUZA
calls
Directie permisa pentru
relatii de tip uses
POSA pag 36

15. Layers: Scenarii de comportament
Bottom-up communication:
Un lant de actiuni este declansat din nivelul inferior Layer1 (de ex un device driver detecteaza o modificare). Layer1 trimite o notificare catre Layer2, acesta incepe transformarea datelor asociate si trimite o notificare catre Layer 3, etc.
Trebuie realizata prin callback ! Acest mecanism realizeaza un flux ascendent de date si control, dar fara a rezulta relatii Uses de tip ascendent
POSA pag 36

16. Layers:Bottom-up communication
Directie permisa pentru
relatii de tip uses
POSA pag 36
calls via callback
EVENIMENT, CAUZA

17. Paranteza despre Mecanismul Callback
Solutia pentru situatiile descrise de relatiile:
FB calls FA dar A uses B si B does not use A
Mecanismul Callback: numele rutinelor din modulul A (de ex FA) de apelat din cadrul modulului B sunt transmise de sus in jos, in forma de date. Specificatia unui nivel inferior include doar obligatia ca intr-o anumita situatie (FB) sa apeleze rutina care i-a fost comunicata mai sus
Acest mecanism realizeaza un flux ascendent de date si control, dar fara a rezulta relatii Uses de tip ascendent -> nu contravine restrictiilor stilului Layered A FA B FB
Clements 85-86

18. Exemplu situatie callback
O aplicatie gestioneaza date despre studenti si realizeaza diferite prelucrari asupra acestora, inclusiv sortarea alfabetica.
O alta aplicatie lucreaza cu reprezentarea unor puncte geometrice in plan, printre prelucrarile asupra acestora este si sortarea in ordinea distantei fata de origine
Posibil ca alte aplicatii din alte domenii sa necesite sortarea unor date
Pentru toate aplicatiile, se va alege o arhitectura de tip layers, cu 2 nivele
Layer-ul Generic Utilities este refolosit intre diferitele aplicatii si trebuie sa contina o rutina generica de sortare
DomainLogic
uses
GenericUtilities
Clements 85-86

19. Exemplu situatie callback
StudentAdministration
main
compare
GenericUtilities
sort
Clements 85-86

20. Posibilitati implementare callback

21. Layers: Pasi de definire a unei arhitecturi
Definirea criteriului de abstractizare: ce “inrudeste” elementele apartinand aceluiasi nivel ?
De ex: distanta fata de HW, complexitatea conceptuala
Determinarea numarului de niveluri: compromis intre:
Prea multe: regie prea mare, probleme de performanta
Prea putine: structura deficitara
Numirea nivelurilor si atribuirea de functii:
Specificarea serviciilor:
Good practice: nivelurile inferioare implementeaza un numar restrans de servicii, nivelurile superioare implementeaza un numar mai mare de servicii
Reconsiderarea pasilor anteriori, pana la solutia finala
Specificarea interfetelor nivelurilor
Asigura posibilitatea de a schimba implementarea unui nivel
Stabilirea structurii nivelurilor
Un nivel complex este implementat prin mai multe componente
Asigurarea decuplarii intre niveluri
Un nivel nu trebuie sa cunoasca identitatea nivelului de deasupra sa

22. Layers: variante Relaxed Layered Systems: Layering through inheritance
se relaxeaza restrictia is-allowed-to-use:
Un nivel poate utiliza toate nivelurile de sub el
un nivel poate fi doar partial opac:
Anumite servicii sunt vizibile doar nivelului imediat urmator, dar alte servicii pot fi utilizate de toate nivelurile de deasupra
Afecteaza negativ maintenability
Merita utilizat in doar in sisteme care nu se modifica des si a caror performanta e importanta
Layering through inheritance
Nivelul inferior = clasa de baza; Nivelurile superioare sunt realizate prin mostenire (implementation inheritance) de la nivelurile inferioare
Fragile base class problem: o modificare a reprezentarii datelor in clasa de baza (nivelul inferior) necesita recompilarea tuturor celorlalte
Nu e o idee buna!

23. Layers: Proprietati ale stilului
Avantaje:
Reusability: fiecare layer poate fi reutilizat individual, daca implementeaza o abstractizare coerenta a unor servicii si are o interfata bine definita si documentata
Portability: interfetele standardizate ale nivelurilor permit limitarea efectelor modificarilor in cadrul unui singur nivel
Testability: nivelurile pot fi testate independent
Exchangeability: se poate inlocui implementarea unui anumit nivel
Atentionari:
Cascades of changing behaviour: modificarea comportamentului unui nivel poate avea efecte negative asupra comportamentului sistemului:
Lower efficiency: daca la fiecare nivel apar transormari ale datelor transferate, performanta este mai slaba decat in cazul unei implementari monolitice
Unnecessary work: daca nivelurile inferioare realizeaza operatii care nu sunt cerute de nivelurile superioare
POSA

24. Layers: Observatii in concluzie
Stitul arhitectural layers se bazeaza pe restrictionarea directiilor permise ale relatiilor de dependenta statica de cod (de tip uses)
Restrictionarea directiilor permise ale relatiilor de tip uses (si mai ales evitarea dependentelor ciclice !) este pe de alta parte si un principiu general pentru un design bun!
Exista tool-uri care permit analiza relatiilor de dependenta
Exemple:
NDepend, dependencyfinder, Lattix, JDepend, etc
ART

25. Pipes and Filters
Pipes and Filters: structura adecvata pentru sistemele care proceseaza fluxuri de date. Fiecare pas de procesare este realizat de un Filtru. Datele sunt transmise intre doua filtre succesive prin conducte (Pipes). Este posibila recombinarea Filtrelor in alte sisteme.
Exemplul cel mai tipic: pipeline de comenzi unix:
ls | grep old | more

26. Alt exemplu: domeniu aplicatie: Signal processing&Virtual Instrumentation

27. Context & Problema Context: Procesarea fluxurilor de date
Problema: o aplicatie care poate fi descompusa in mod natural in mai multe etape de procesare;
Este nevoie de flexibilitate in viitor, obtinuta prin reordonarea componentelor (etapelor de procesare)
Este posibila constructia unei familii de sisteme asemanatoare prin utilizarea a diferite subseturi de componente
Componentele ne-adiacente nu utilizeaza informatii comune
Este luata in considerare posibilitatea ca etapele sa fie rulate in regim multitasking
Solutia nu este aplicabila aplicatiilor interactive, conduse de evenimente

28. Solutie - structura
Sistemul se descompune natural in etape de procesare secventiala
Fiecare etapa este implementata de o componenta de tip Filtru
Caracteristicile unui Filtru:
Citeste date din fluxul de intrare
Realizeaza un anumit tip de procesare pe datele de intrare
Produce date pe fluxul de iesire
Etapele de procesare sunt legate prin fluxul de date din sistem
Pipes (conducte):
transporta fluxul de date intre 2 filtre consecutive
Implementarea unei conducte poate utiliza diferite tehnici: apel de functie, apeluri sistem pipe, etc.

29. [POSA]-Fig/P.56

30. Solutie - comportament
Tipuri de Filtre:
Pasive: activitatea lor este declansata explicit de filtrul precedent (push) sau de filtrul urmator (pull)
Active: corpul filtrului consta dintr-un ciclu continuu in care citeste-proceseaza-scrie date
Daca filtrele sunt de tip activ, Pipe trebuie sa realizeze si sincronizarea intre filtre active, prin bufferare
Citirea si producerea datelor trebuie facuta incremental, pentru a reduce latenta si a permite o eventuala procesare concurenta

31. Passive Filters: Push pipeline vs Pull pipeline
[POSA]-Fig/P.58

32. Active Filter: Push/pull pipeline
POSA 60
[POSA]-Fig/P.60

33. Pipes and Filters – Exemplu ? [POSA]
Exemplu: Un compilator pentru un nou limbaj de programare Mocha (Modular Object Computation with Hypothetical Algorithms)
Compilatorul trebuie sa fie portabil pe diferite platforme => se defineste limbajul intermediar AuLait (Another Universal Language for IntermediateTranslation) care se executa pe o masina virtuala Cup (Concurrent Uniform Processor)

34. Exemplu Compilator Pipes and Filters
[POSA]-Fig/P.53

35. Exemplu – aplicarea solutiei
[POSA]-Fig/P.57

36. Exemplu – aplicarea solutiei (cont)
Primele 4 etape ale compilatorului Mocha sunt implementate in acelasi program pentru ca utilizeaza date in comun
Codificarea tabelei de simboluri pentru a fi transmisa intre aceste etape ar fi fost mult mai voluminoasa decat restul datelor transmise, rezultand scaderea eficientei
Ultima etapa (backend) este realizata ca procese separate, pentru ca necesita flexibilitate
Exemplu de compilare si optimizare program pentru HW Sun:
Mocha <prog.mocha | optauLait | auLait2SPARC > prog.exe
Exemplu de compilare si interpretare:
Mocha <prog.mocha | cup
[POSA]-Fig/P.65

37. Pasi de definire a unei arhitecturi pipes-and-filters
Divizarea functionalitatii sistemului intr-un numar de stagii intermediare de procesare
Definirea formatului datelor care se transmit pe fiecare pipe
Format uniform => flexibilitate maxima, dar poate afecta negativ eficienta
Alegerea tipului de pipe pentru fiecare conexiune. Tipul de pipe influenteaza tipurile de filtre – pasive sau active
Proiectarea filtrelor
Rule of thumb: One filter should do one thing well => asigura reutilizarea individuala
Proiectarea mecanismului de tratare a erorilor
Mecanisme de resincronizare a pipeline
Realizarea sistemului prin asamblarea filtrelor
POSA

38. Proprietati ale stilului Pipes-and-filters
Avantaje:
Flexibilitate prin recombinare:
Reusability pentru componentele filtru
Dezvoltare rapida
Posibilitate de procesare concurenta
Atentionari:
Imposibil de mentinut o informatie de stare comuna accesibila in mod eficient tuturor filtrelor
Overhead datorita operatiilor de transformare a formatului datelor
Error handling

39. Discutie: Pipes-and-Filters vs Layers
Layer A
Filter A
Filter B
Filter C
Layer B
Layer C

40. Discutie: Pipes-and-Filters vs anumiti design patterns

41. Blackboard
Blackboard: tipar adecvat problemelor in care mai multe subsisteme specializate, independente, contribuie la gasirea unei solutii
Exemplu: Inteligenta artificiala – recunoasterea vorbirii
Date de intrare:
vorbirea inregistrata ca waveform
Sistemul accepta nu numai cuvinte izolate, ci si fraze
Sintaxa frazelor si vocabularul utilizat sunt restrictionate in concordanta cu un anumit tip de aplicatie (ex interogare baza de date)
Date de iesire:
reprezentare interna (comanda corespunzatoare) pentru fraza recunoscuta
La gasirea solutiei contribuie subsisteme independente, specializate pe domenii diferite: acustica-fonetica, lingvistica, statistica
POSA

42. Exemplu pentru arhitectura BB
Sistem de recunoastere a vorbirii
HEARSAY-II KS BB
Word Creation
POSA 71
Syllable Creation
Segmentation
[POSA]-Fig/P.70

43. Solutie - Blackboard
Structura: o colectie de elemente independente (Knowledge Sources) care lucreaza in acelasi timp pe o structura de date comuna (Blackboard), in vederea rezolvarii unei probleme
Fiecare KS este specializat pe o anumita parte a problemei comune
KS sunt independente: nu exista interactiuni directe intre ele
Ordinea de activare a KS nu este prestabilita, ci rezulta in mod dinamic in functie de evolutia datelor din BB.
Poate utiliza o componenta centrala de control care evalueaza starea curenta a BB si activeaza KS
Continutul BB: Solution space – consta din solutii partiale (hypotesis), la diferite nivele de abstractizare
Pe parcursul rezolvarii problemei, KS produc noi ipoteze, modifica gradul de incredere in valabilitatea unei ipoteze, sau elimina ipoteze care se dovedesc false

44. Solutie - Blackboard
[POSA]-Fig/P.77

45. Solutie - Blackboard BB: KS Control
Permite KS sa citeasca si sa scrie date KS
Conditie: evalueaza starea curenta a solutiilor partiale din BB si determina daca in aceste conditii are ceva de facut
Actiune: efectueaza calculele specifice, acestea pot duce la modificarea starii BB
Control
Monitorizeaza BB
Activeaza activitatile de evaluare sau de actiune ale KS
POSA 79
[POSA]-Fig/P.79

46. Scenariu exemplu
[POSA]-Fig/P.80

47. Pasi de definire a unei arhitecturi Blackboard
Definirea problemei: stabilirea domeniilor de cunostiinte implicate, definirea intrarilor si a proprietatilor lor (zgomote, variatiuni)
Definirea spatiului solutiei: solutii partiale/complete, de nivel inalt/de nivel intermediar
Divizarea procesului de rezolvare in pasi: defineste regulile dupa care solutiile se transforma in solutii de un nivel de abstractizare mai inalt;
Stabilirea knowledge sources si a a sarcinilor acestora
Definirea vocabularului BB: gasirea unei reprezentari a datelor astfel incat toate KS sa poata scrie si citi din BB
Descrierea controlului: Controlul implementeaza o strategie oportunista care determina ce KS pot face modificari la BB. Tinta este construirea unei ipoteze acceptabile (credibilitatea > prag)
Implementarea KS: separarea in partea de conditie si partea de actiune; o KS nu trebuie sa cunoasca celelalte KS sau componenta de Control

48. Varianta - Repository Generalizare a Blackboard
Nu exista o componenta centrala de control si KS nu au partea de execCondition
Ordinea de executie a KS este determinata de utilizator sau de un program principal
Exemple:
Baze de date clasice
CASE Toolset

49. Varianta – Active Database
Baza de date contine mai multe tipuri de date
Un KS este asociat cu un anumit tip de date si este activat cand un element de acel tip este modificat
Activarea KS se face prin evenimente: initial, fiecare KS isi inregistreaza interesul pentru o anumita portiune a bazei de date. Cand se intampla modificari in acea portiune, KS este notificat

50. Proprietati ale stilului Blackboard
Avantaje:
Permite experimentarea cu diferiti algoritmi si euristici
Changeability
Reusability pentru KS
Fault tolerance
Atentionari:
Testability: redusa
Low efficiency
Complexitate ridicata la realizare

51. Event-driven
Event-driven(Implicit invocation): componente reactioneaza la evenimente produse de alte componente necunoscute lor. Stilul suporta un grad mare de dinamism in ceea ce priveste aparitia de noi componentele participante si introducerea unor noi tipuri de evenimente.
Definitioa din Garlan&Shaw – Intro to SwArch
Exemplu din Event Notifier, a Pattern for Event Notification,
Gupta, Hartkopf, Ramaswamy, Java Report 1998
Event Service op
Obj1 op
Obj2
Obj1
Obj2
Explicit invocation
Implicit invocation

52. Event Channel - Structura
Publisher
Publisher
Subscriber
Subscriber
Event Channel
Publisher
Publisher
Subscriber
Subscriber

53. Event Channel - Aplicabilitatea
Exista componente care produc evenimente, dar nu cunosc identitatea componentelor care vor “consuma” aceste evenimente si nici exact modul in care vor consuma evenimentele. (Publisher)
Este posibil ca mai multi publisheri sa produca acelasi tipuri de evenimente.
Exista componente care sunt interesate sa primeasca anumite tipuri de evenimente, dar nu cunosc/nu le intereseaza identitatea componentelor care le-au produs (Subscriber)
Este posibil ca un Subscriber sa fie interesat de mai multe tipuri diferite de evenimente
Este posibil ca o componenta sa fie in acelasi timp Publisher si Subscriber pentru diferite evenimente
Componentele participante (Publisheri sau Subscriberi) pot fi adaugate/scoase in mod dinamic din sistem
Noi tipuri de evenimente pot fi adaugate in mod dinamic
Componetele pot fi localizate in procese distincte (distribuite)

54. Event Channel – Modele de comunicare
De obicei, cand un eveniment este receptionat de (unul sau mai multi) Subscriber-i, se realizeaza un transfer de date intre Publisher-ul care a generat evenimentul si Subscriber-ii respectivi
Se pot defini 4 categorii de modele de comunicare, in functie de modul in care se realizeaza acest transfer de date:
Push: Publisher-ul este sursa activa care initiaza transferul de date, Subscriber este destinatie pasiva. Event Channel = Notifier
Pull: Subscriber initiaza (cere) transferul de date de la sursa (Publisher) pasiva. Event Channel = Procurer
Hibrid Push/Pull: Publisher-ii si Subscriber-ii sunt initiatori activi ai transferurilor, care au loc intr-un/dintr-un buffer de la Event Channel = Queue
Hibrid Pull/Push: Publisher-ii si Subscriber-ii sunt entitati pasive, initiativa transferurilor de date ii apartine lui Event Channel = Intelligent Agent

55. Push: Notifier Active behaviour Passive behaviour Publisher Subscriber
Push data
Push data
Notifier
Publish Event
Receive Event
Data Transfer

56. Pull: Procurer Passive behaviour Active behaviour Publisher Subscriber
Pull data
Pull data
Procurer
Publish Event
Receive Event
Data Transfer

57. Hybrid Push/Pull: Queue
Active behaviour
Active behaviour
Publisher
Subscriber
Push data
Pull data
Queue
Publish Event
Receive Event
Data Transfer

58. Hybrid Pull/Push: Intelligent Agent
passive behaviour
passive behaviour
Publisher
Subscriber
Pull data
Push data
Intelligent Agent
Publish Event
Receive Event
Data Transfer

59. Discutie: comparatie modele Push/Pull
Avantaje/Dezavantaje
Utilitate (exemple situatii)
Posibilitati implementare

60. Structura unei aplicatii Event-Driven
Componente (Elemente): Publishers, Subscribers
Connectori (Relatii): publish event, subscribe to event type
Infrastructura: Event Channel. De obicei nu face parte din aplicatie ! Poate fi un messaging/ event middleware de tip Java Message Service, CORBA message service, etc
Publisher
Publisher
Subscriber
Subscriber
Event Channel
Publisher
Publisher
Subscriber
Subscriber

61. Exemplu problema si posibilitati de implementare: Network Management System
Managed Objects
Management System
Router
Hub
Console
Paging
Definitioa din Garlan&Shaw – Intro to SwArch
Exemplu din Event Notifier, a Pattern for Event Notification,
Gupta, Hartkopf, Ramaswamy, Java Report 1998
Managed Objects: elemente de retea monitorizate; sunt in numar mare, de diverse tipuri, si pot fi pornite sau oprite in mod dinamic. Cand sunt pornite, activitatea lor e monitorizata de elemente din Management System.
Evenimente monitorizate: erori neasteptate in functionare (de diverse grade de gravitate), indicatori de performanta
Management System: cuprinde elemente de tip console, pagere, . Fiecare element din management system poate fi configurat sa urmareasca anumite categorii de evenimente

62. Exemplu Network Management: Solutie simplista
Managed Objects
Management System
Probleme:
Solutie nescalabila: Fiecare Managed object trebuie sa trimita direct notificari fiecarui obiect din management system
Orice schimbare/adaugare in Management System (exemplu: adaugare Notification) afecteaza toate Managed Objects

63. Exemplu Network Management: Solutie tip Mediator
Managed Objects
Management System
Orice schimbare/adaugare in Management System (exemplu: adaugare Notification) afecteaza doar Mediator
Scalabilitate mai buna (numarul de dependente este n+m in loc de n*m)
Probleme:
Nu suporta adaptarea dinamica si diferentiata a sistemului de management (de ex fiecare managed object sa fie monitorizat doar de un subset (eventual dinamic variabil) de obiecte din Management System

64. Exemplu Network Management: Solutie tip Observer
Managed Objects
Management System
Managed Objects nu trebuie sa cunoasca de dinainte multimea de obiecte din management system pe care le notifica
Probleme:
Fiecare obiect din management system trebuie sa cunoasca fiecare managed object pe care il monitorizeaza.
Dezavantaje:
Numarul de managed objects poate fi foarte mare
Managed objects pot sa apara si sa dispara

65. Exemplu Network Management: Solutie tip Event Channel
Publisher
Subscriber
Managed Objects
Management System
EventChannel
Hub
Console
Router
Paging System
Asigura o decuplare mult mai puternica intre Managed Objects si Management System
Managed Objects nu cunosc identitatea obiectelor din Management System
Obiectele din Management System nu cunosc identitatea managed Objects, ci doar tipurile evenimentelor generate de acestia

66. Event Channel
Asigura o decuplare mult mai puternica intre Publisher-i si Subscriber-i
Publisher-ii nu cunosc identitatea Subscriber-ilor lor
Subscriberii nu cunosc identitatea Publisher-ilor, ci doar tipurile evenimentelor generate de acestia
Intre Publisher si Subscriber se interpune un Event Channel (asemanator Mediator)
Scenariu:
Concrete Subscriber se inregistreaza la Event Channel, specificand tipul de evenimente de care este interesat
Concrete Publisher anunta la EventChannel producerea unui eveniment
EventChannel determina ce Concrete Subscribers sunt interesati de acest eveniment
Event Channel ii informeaza pe acestia de evenimentul produs

67. Exemplu Implementare Event Notifier [Gupta, Hartkopf, Ramaswamy]
EventService: intermediaza transmiterea de evenimente intre publisher si subscriber
Publisher (Hub, Router): emite evenimente
Subscriber: interfata pentru toti consumatorii de evenimente
ConcreteSubscriber (Console, Pager): subscrie la EventService pentru anumite tipuri de evenimente, trateaza evenimentele implementand interfata Subscriber
Event: Baza ierarhiei de tipuri de evenimente
Filter: elimina evenimente care nu sunt de interes pentru un anumit subscriber (de exemplu, un ConcreteSubscriber poate fi interesat de un anumit tip de evenimente – de exemplu FaultEvent, cu exceptia celor provenind de la un anumit Hub particular)

70. Discutie Implementare Event Notifier
Subscriptia se bazeaza pe tipuri de evenimente si nu pe identitatea unui publisher
Publisheri si Subscriberi sunt independenti. Cuplarea intre ei se reduce la cunoasterea unui set de evenimente permise (semantica evenimentelor si datele asociate)
Subscrierea la un anumit tip de eveniment cuprinde automat si toate subtipurile sale
Filtrarea evenimentelor se poate face in plus fata de tipul evenimentului in functie de alte atribute (de ex sursa evenimentului, datele asociate, etc)
Dezavantaj: type safety vs generalitate:
Class
isKindOf method in Event
Inform(event): cast la tipul (tipurile) asteptate de evenimente
Dezavantaj: Event Service e un point of bottleneck – performanta si fiabilitate redusa. Solutie: mai multe EventServices, fiecare specializat intr-o anumita categorie de evenimente
Facilitati optionale: Advertisment and Discovery of available Event Types

71. Variante ale stilului Event-Driven
Active Database: combinatie cu Blackboard:
Distributed Event Notification: combinatie cu Broker:

72. Implementari reprezentative
Publisher-Subscriber simplu:
Mecanisme incorporate in unele limbaje de programare:
Java: Event - Listener
C#: Event - delegate
Event Channel: incorporat in infrastructuri (middleware) pentru aplicatii distribuite
Java Message Service (JMS)
Corba Event Service

73. Concluzii privind Stilurile arhitecturale fundamentale (1)
descriu scheme de structurare a unui sistem din puncte de vedere diferite
Structura statica (Module viewtype): Layers
Structura dinamica de runtime (Component & connector viewtype): Pipes-Filters, Blackboard, Event-driven
Sunt solutii elementare de structuri foarte simple
In sisteme reale, pot apare in stare “pura” sau combinate/hibridizate

74. Concluzii privind Stilurile arhitecturale fundamentale (2)
Alegerea unui anumit stil arhitectural pentru o aplicatie poate influenta caracteristicile/calitatile proiectului
For further reading: David Garlan, Mary Shaw, An Introduction to Software Architecture, Technical Report Carnegie-Mellon University, no CMU-CS ,
Analizeaza probleme diferite din punctul de vedere al avantajelor/dezavantajelor aduse solutiei de aplicarea unui anumit stil arhitectural
Laborator: problema medicilor specialisti care diagnosticheaza pacienti

75. Concluzii privind Stilurile arhitecturale fundamentale (3)
Alegerea unui anumit stil arhitectural pentru o aplicatie poate influenta caracteristicile/calitatile proiectului
Laborator: problema medicilor specialisti care diagnosticheaza pacienti
Pipes&Filtes
Blackboard
EventDriven
Performance (timpul de diagnosticare)
Response quality (acuratetea diagnosticului)
Concurrency (usurinta si eficienta concurentizarii activitatii medicilor)
Reusability (posibilitatea de refolosire a Medicilor in alte sisteme)
Modifiability: (usurinta de a efectua modificari ulterioare - exemple: adaugarea unor Medici noi, Schimbarea politicii de consultatii a spitalului, etc

76. Concluzii privind Stilurile arhitecturale fundamentale (4)
Sunt stiluri/tipare cu un grad foarte ridicat de abstractizare, reprezinta solutii de organizare structurala independente de o anumita paradigma de programare sau de o anumita tehnologie
Componentele acestor tipare arhitecturale pot avea granularitati diferite, de la obiecte, componente, si pana la aplicatii care sunt integrate
For further reading: Enterprise Integration Patterns
Carte: Enterprise Integration Patterns, by Gregor Hohpe and Bobby Woolf, A Martin Fowler Signature Book, Addison Wesley, 2004
Site asociat cartii:
Shared Database (Repository):
Pipes and Filters:
Messaging (Event-Driven)