Stiluri arhitecturale fundamentale

1. Stiluri arhitecturale fundamentale • Metode de descompunere controlata in subtaskuri cooperante: • Layers • Pipes and Filters • Blackboard; cu variantele Repository, Active Database • Event-driven (Implicit Invocation); Publisher-Subscriber; Event-Channel

2. Bibliografie pt Event-driven • Slide-uri: http://www.cs.utt.ro/~ioana/arhit/ • POSA vol 1: ch.3.6 (pg. 339-343) • David Garlan, Mary Shaw, An Introduction to Software Architecture, online http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf, ch.3.3 (pg 9-11) • 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)

3. 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. Event Service op Obj1 Obj2 Obj1 Obj2 op Explicit invocation Implicit invocation

4. Event Channel - Structura Publisher Publisher Subscriber Subscriber Event Channel Publisher Publisher Subscriber Subscriber

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

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

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

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

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

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

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

12. Exemplu problema si posibilitati de implementare: Network Management System Management System Managed Objects Router Hub Console Paging 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, e-mail. Fiecare element din management system poate fi configurat sa urmareasca anumite categorii de evenimente

13. 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 e-mail Notification) afecteaza toate Managed Objects

14. Exemplu Network Management:Solutie tip Mediator Managed Objects Management System • Orice schimbare/adaugare in Management System (exemplu: adaugare e-mail 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

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

16. Exemplu Network Management:Solutie tip Event Channel Subscriber Publisher Managed Objects Management System EventChannel Console Hub Paging System Router 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

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

18. Exemplu ImplementareEvent 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)

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

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

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