architectural patterns etoscana - 20040217
TRANSCRIPT
![Page 1: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/1.jpg)
Architectural Patternsschemi di progetto per architetture software
Seminario e-ToscanaFirenze, 17-18 febbraio 2004
Enrico Vicario, Fabrizio Baldini
Dipartimento Sistemi e InformaticaCentro per la Comunicazione e la Integrazione dei Med ia
Università di Firenze{vicario,fbaldini}@dsi.unifi.it
![Page 2: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/2.jpg)
Patterns
• Soluzioni possibili a problemi ricorrenti• Soluzioni “half-baked”• Basati sulla esperienza• Non teoria ma pratica
• supporto teorico • formalizzazione
• Design Patterns [GHJV95]• principi generali di strutturazione nella transizione verso
l’implementazione• applicati al livello di granularità fine delle class i
• Design Patterns, Idiomi, Pattern architetturali, Pa ttern diIntegrazione, Pattern per architetture di scala enterp rise
![Page 3: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/3.jpg)
Patterns
• Idiomi• Basso livello• Una classe o poche classi• Dipendente dal linguaggio
• Esempio: Singleton• Assicurare l’esistenza di una e una sola classe
di un certo tipo a run-time• Istanza della classe globalmente accessibile• L’implementazione può essere totalmente diversa util izzando
linguaggi diversi
DesignDesign
IdiomsIdioms
dettaglio
scala
public class Singleton{
private static Singleton instance;
protected Singleton(){…}
public static Singleton getInstance(){
if(instance == null) instance = new Singleton();
return instance;}
}
In smalltalk è molto diverso:overriding del metodo new…
new self error ‘errore’
getInstanceTheInstance isNil ifTrue:[TheInstance := super new]
^ TheInstance
![Page 4: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/4.jpg)
Patterns
• Architectural Patterns [Fow03][POSA01]• Macro-livello• Applicazioni di scala enterprise• Persistenza, concorrenza, distribuzione
“An architectural pattern expresses a fundamentalstructural organization schema for software systems…”
• Specifica i sottosistemi• Specifica le responsabilità• Specifica le relazioni tra i sottosistemi
ArchitecturalArchitectural
DesignDesign
IdiomsIdioms
dettagliodettaglio
scala
![Page 5: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/5.jpg)
Architectural Patterns: un po’di storia
• Smalltalk 76:• Interfacce grafiche semplici hanno struttura intrin secamente
modulare (insiemi di componenti text, menu, button, pixel-maps)
• Paradigmi di interazione riconducibili a tipologie d i base (editing, browsing, inspecting)
• Presenza di un modello di dati significativo e speci fico per il contesto applicativo
• Smalltalk-80 [Kras88]:• Componenti grafici di base riutilizzabili per composi zione• Sensori (e.g. InputSensor) per rappresentare e gest ire
l’interazione dell’utente. Possibilità di delegare l ’azione di controllo
• Modello di dati che mantiene la lista dei component i dipendenti dal modello.
![Page 6: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/6.jpg)
Modello, Vista, Controllo
• Smalltalk-80 individua tre macro-componenti che svo lgono differenti funzioni:• Modello: rappresentare i dati e la logica della app licazione• Vista: visualizzazione dei dati di modello sulla inte rfaccia• Controllo: interfacciamento tra modello, vista e dis positivi di
input
• È definita una modalità di interazione tra i compon enti
“An architectural pattern expresses a fundamentalstructural organization schema for software systems…”• Specifica i sottosistemi• Specifica le responsabilità• Specifica le relazioni tra i sottosistemi
![Page 7: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/7.jpg)
Architectural Pattern Model View Controller (MVC)
• “ The Model View Controller (MVC) divides an interactiv eapplication into three components. The model contains t he core functionality and data. Views display information to th e user. Controllers handle user input. Views and controllers tog ethercomprise the user interface” [POSA01]
• Contesto:• Applicazioni interattive• Applicazioni con componenti di web-presentation• In generale: Applicazioni in cui è opportuna la sepa razione tra
interfaccia e modelloNecessità di viste diverse sul modello Diverso grado di stabilità delle componenti modello e interfacciaRiuso di componenti
• Chi utilizza MVC (o sue varianti)?• Librerie Java Swing • Framework MFC• JSP/JavaBean/Servlet
![Page 8: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/8.jpg)
Esempio: Editor LaTeX
• Documento strutturato• document, section, subsection, paragraph• Metainformazione di strutturazione inserita nel test o
![Page 9: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/9.jpg)
Esempio: Editor LaTeX
• Problema:• Visualizzazione dei dati contenuti nel documento con
rappresentazioni diverse sulla interfaccia• Modifica sui dati del documento interagendo con la
applicazione tramite viste diverse• Allineamento delle viste all’informazione presente n el
documento
• Aggiunta di viste sul documento anche a run-time (e. g. preview frame)
• Sostituibilità di componenti di interfaccia e contr ollo senza modifiche al nucleo funzionale della applicazione
![Page 10: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/10.jpg)
Soluzioni possibili?
• Ogni vista contiene alcuni dati del documento? :-(• Riferimenti incrociati tra i componenti vista? :-(
• Occorre aggiornare i dati del documento su ogni com ponente• Componenti di interfaccia strettamente connessi (ch i sono i
componenti attivi? Quali le interfacce delle classi ?)• Difficile introdurre nuovi componenti di interfacci a• Flusso di controllo delle azioni sulla interfaccia “frammentato”
distribuito tra i componenti
SectionFigure
SectionFigure
SectionFigure
![Page 11: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/11.jpg)
Soluzioni possibili?
• Strutturazione delle componenti della applicazione • Model: Modello dei dati e logica della applicazione• View: Interfaccia grafica • Controller: Sensori• Change-Propagation: Meccanismo di comunicazione tra i
componenti
SectionListFigureListData….
ModelModel ViewView
ControllerController
![Page 12: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/12.jpg)
MVC: Modello
• Nucleo funzionale della applicazione: Model• Entità significative nel contesto applicativo• Funzionalità che realizzano la logica della
applicazione• Funzioni di accesso/modifica dei dati del modello• Indipendenza dalla particolare rappresentazione
dei dati nelle componenti di interfaccia • Indipendenza dalla logica di gestione del controllo
• Collaborazioni• Il modello è modificato dai componenti Controller • Mantiene riferimenti alle Viste che mostrano i dati del modello• Invia notifiche alle Viste al cambiamento dei dati
ModelModel ViewView
ControllerController
![Page 13: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/13.jpg)
Esempio CRC Card: Modello
• Caratteristiche del componente Modello: descrizione CRC
Nucleo funzionale della applicazione: Model•Entità significative nel contesto applicativo•Funzionalità che realizzano la logica della applica zione•Indipendenza dalla particolare rappresentazione dei dati nelle componenti di interfaccia •Indipendenza dalla logica di gestione del controllo•Funzioni di accesso ai dati del modello
Collaborazioni•I Controller modificano il modello•Mantiene riferimenti alle viste che mostrano i dati del modello•Le viste ricevono notifiche quando alcuni dati di m odello cambiano Responsibility
• Implementa il nucleo funzionale della applicazione
• Registra le viste dipendenti dal modello
• Notifica i cambiamenti ai componenti dipendenti
Collaborators• View• Controller
Class• Model
![Page 14: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/14.jpg)
MVC: View
• Componenti di interfaccia: View• Visualizzazione di dati di modello
(dati diversi / modi diversi)• Possono essere composte per realizzare
viste più complesse
• Collaborazioni• La vista è associata al modello
Riceve dal modello notifiche di cambiamento dei dat iAccede al modello per ottenere i dati da visualizza re
• La vista crea il proprio controllore
• Collaboration Diagram• Comportamento dinamico del
sistema
2: Inizializza (myView, myModel)
1: Registra (myView)
3: Aggiorna
4: Leggi Dati
ModelModel ViewView
ControllerController
![Page 15: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/15.jpg)
MVC: Controller
• Componenti di gestione eventi: Controller• Ricezione e gestione di eventi dalla interfaccia• Mappatura evento – funzione di gestione
(relazione 1-1 ma non necessariamente)
• Collaborazioni• Il controllore è associato ad una vista (relazione 1 a 1)• Il controllore invoca le funzionalità sul modello e può
modificarne i dati
• Collaboration Diagram1: Input
2: Esegui Funzione
5: Leggi Dati
3: Notifica
4: Aggiorna
ModelModel ViewView
ControllerController
![Page 16: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/16.jpg)
MVC: Class Diagram
• Classi MVC di base: Model, View, Controller• Classi derivate (rif. esempio Editor)
• Model: TeXDocument• View: ObjectView, StructuredTreeView• Controller: TreeController, ObjectController
public class Model{
private Vector setOfViews;[..]
// Aggiunge una nuova vistapublic void attach(View aView){ viewList.addElement(aView); }// Rimuove la vistapublic void detach (View aView){ viewList.removeElement(aView); }
// Notifica il cambiamento alle viste registratepublic void notify(){
Iterator iterator = viewList.listIterator();while(iterator.hasNext())
((View)iterator.next()).update();}
}
public class TeXDocument extends Model{
private Vector sectionList;private Vector figureList;
[…]// Funzione che modifica i datipublic void addSection(…){
[..] //function bodynotify();
}}
public class StructuredTreeView implements View{
private TeXDocument theModel;private TreeController theController;[..]
// Inizializzazionepublic void init (Model model){
[..]theModel = model;theController = createController();[..]
}
// Crea il controllorepublic void createController(){
theController = new TreeController(); theController.init(this, theModel);
}
/* Effettua l’aggiornamento leggendo i dati dal modello */
public void update(){
Section[] sections = theModel.getSections();// Aggiorna la vista con i dati ottenuti[..]
}}
public class TreeController implements Controller{
private TeXDocument theModel;private StructuredTreeView theView;[..]
// Inizializzazionepublic void init (View view, Model model){
theView = view;theModel = model;[..]
}
/* Gestisce gli eventi e.g. aggiornamento di una sezione */
public void handleEvent(Event e){
[..]//Es. Aggiornamento del nome di una sezionetheModel.updateSection(section, “Pattern MVC”);[..]
}}
![Page 17: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/17.jpg)
MVC: Change - Propagation
• Modalità di comunicazione tra componenti: meccanismo Change – Propagation1. Registrazione delle viste
sul modello2. Il modello è modificato
dai controllori3. Il modello notifica
cambiamenti a tutte le viste registrate
4. Le viste richiedono al modello i dati necessari all’aggiornamento della visualizzazione
![Page 18: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/18.jpg)
Design Pattern Observer
• Change-Propagation MVC ààà à Design Pattern Observer
“Define a one-to-many dependency between objects so that when one object changes state, all its dependents a re notified and updated automatically.” [GHJV95]
• Partecipanti• Subject (Observable)
Ha riferimenti agli osservatori che dipendono dal s uo statoFornisce metodi di interfaccia per aggiungere e rim uovere osservatori
• Observer Interfaccia che presenta un metodo di aggiornamento . Le classi che implementano l’interfaccia sono notificati al varia re dello stato del Subject.L’implementazione dell’aggiornamento mantiene lo st ato coerente con quello del Subject.
![Page 19: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/19.jpg)
Design Pattern Observer
• Class Diagram:• Subject equivale al “Model” MVC• Observer equivale a “View” MVC
• Collaborazioni• ConcreteSubject notifica il cambiamento di stato• ConcreteObserver può richiedere informazioni per
l’aggiornamento per sincronizzarsi
![Page 20: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/20.jpg)
Vantaggi derivanti dall’uso di MVC
• Viste multiple sullo stesso modello• Meccanismo efficiente di sincronizzazione delle vis te
(Change-propagation)• Semplicità di sostituzione/aggiunta/modifica di vis te e
controllori
• “Stabilità” del nucleo funzionale della applicazion e • Il modello contiene i dati significativi per la app licazione e le
funzionalità “core” della applicazione• Il modello effettua notifiche agli elementi dipende nti• Il modello dipende dalle viste solo per l’interfacc ia View
![Page 21: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/21.jpg)
Vantaggi derivanti dall’uso di MVC
• Componibilità di viste: “Composite” pattern [GHJV95 ]“ Compose objects into tree structures to represent par t-whole hierarchies. Composite lets clients treat individ ualobjects and compositions of objects uniformly.”
• Vantaggio• Oggetti “foglia” e composizioni hanno la stessa interf accia
(View)• Definizione di “viste” di base combinabili in viste c omplesse
Preview
TextView
CompositeView
![Page 22: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/22.jpg)
Vantaggi derivanti dall’uso di MVC
• Organizzazione gerarchica di controllori “Chain of Responsibility” pattern [GHJV95]“Avoid coupling the sender of a request to its rece iver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the requ estalong the chain until an object handles it.”
• Esempio: Help Contestuale• La richiesta di aiuto viene inoltrata dal component e al
contenitore finchè non è gestita
ComboCtrl
DialogCtrl
successor
![Page 23: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/23.jpg)
Limiti del modello MVC
• Complessità• La terna MVC può essere usata per ogni componente di
interfaccia ma non è necessaria per quelli più semp lici (e.g. semplici campi di testo)
• Inefficienza• Eccessivo numero di “updates” a seguito della richies ta di una
sola funzione sul modello• Non tutti i cambiamenti del modello interessano tut te le viste • La vista può essere in uno stato “inattivo” (e.g. ri dotta a icona)
• Accoppiamento di vista e controllore col modello
![Page 24: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/24.jpg)
Usi Noti: Java
• I componenti delle librerie Java Swing sono realizz ati secondo una variante del modello MVC
• Ogni componente (JButton, JToggleButton… ) ha un modello associato che ne descrive lo stato e i dati
• Alcuni componenti (e.g. JList, JTree) prevedono l’u so esplicito di un modello per consentire la modifica dei dati visualizzati
• Esempio: JButton
Modello UIDelegate
Controllers
![Page 25: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/25.jpg)
Usi noti: MFC - variante Document/View
• Document/View• View/Controller strettamente connessi• Accoppiamento lasco col modello• Più viste sincronizzate• Difficile cambiare il controllo
• Framework MFC• Spesso la vista si occupa della rappresentazione nel la
interfaccia e della gestione del controllo• Possibile delegare la gestione dei messaggi a compo nenti di
controllo separati (:CCmdTarget)
Model
View
Controller
Document
View
![Page 26: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/26.jpg)
• Architettura CART• Cooperazione per eventi (EDA): modalità asincrona pe r
scambio di messaggi• Il NAL svolge funzione di publisher/subscriber per i SIL che
fanno riferimento ad esso
• Comunicazione per eventi• Publisher: invia una “notifica” pubblicando un evento tamite
un messaggio• Subscriber: riceve le notifiche di aggiornamento at traverso la
ricezione del messaggio• ŁŁŁŁ P&S strettamente correlato a Change - Propagation
Publish&Subscribe
NAL aNAL a
NAL bNAL b
NAL cNAL c
NAL dNAL d SILSIL
Publisher
Subscribers
![Page 27: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/27.jpg)
Publish&Subscribe
• Publisher-Subscriber è sinonimo di Observer“The Publisher-Subscriber design pattern helps to kee p the state of cooperating components synchronyzed. [..] On e way propagation of changes: one publisher notifies any number of subscribers.” [POSA01]
• Due differenti protocolli di notifica• Pull model• Push model
![Page 28: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/28.jpg)
Publish&Subscribe: Modelli Push/Pull
• Modello Pull• Il publisher notifica l’avvenuto cambiamento di sta to• Invia solo un set minimale di informazioni• I sottoscrittori richiedono i dati necessari
+ è flessibile: i subscribers scelgono i dati ad es si necessari (e solo quelli)
- richiede molti scambi di messaggi- i subscribers devono “capire” cosa è cambiato
• Il pattern MVC utilizza tipicamente il modello Pull• Il Model invia la notifica• Le Viste sono responsabili ad accedere ai dati nece ssari per
l’aggiornamento
![Page 29: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/29.jpg)
Publish&Subscribe: Modelli Push/Pull
• Modello Push• Il publisher invia con la notifica i dati modificat i
+ Nessuna interazione tra le parti (eccetto la noti fica)+ Più adatto ad una architettura distribuita- Meno flessibile: i subscribers accettano passivament e i dati
inviati- Inefficienza: invio di grosse quantità di dati talvo lta non
richiesti
• Varianti (tra Push e Pull)• Indicazione di quale sottoinsieme dei dati è cambiat o• Invio dei dati di interesse per la “maggior parte” de i
sottoscrittori
![Page 30: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/30.jpg)
• P&S (modello Observer) prevede una interazione dire tta• I Publisher mantengono riferiementi ai subscriber• I Publisher notificano direttamente i subscriber
• Event Channel: P&S per sistemi distribuiti• Disaccoppiamento di publishers e subscribers• Presenza di un mediatore (gestore eventi)
Gestore Eventi (CRIC)
Gestore Eventi (CRIC)
Event Channel
NAL aNAL a
NAL bNAL b
NAL cNAL c
NAL dNAL d SILSIL
Publisher
Subscribers
![Page 31: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/31.jpg)
Event Channel
• Variante proposta da OMG Event Service Spec (1995)
• Contesto• Comunicazione per eventi in un contesto distribuito• I partecipanti non sono interessati ad avere relazio ni tra loro• Partecipanti interessati solo al cambiamento dei da ti
• Struttura• Introduzione di un intermediario: Event Channel
• Collaborazioni• I subscriber si registrano sul Channel• Event Channel è sorgente e destinazione dei messaggi
![Page 32: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/32.jpg)
Event Channel
• Collaboration Diagram• Registrazione dei subscribers• Dispatching dei messaggi• Funzioni aggiuntive di Event Channel: filtraggio, st orage,
autenticazione
![Page 33: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/33.jpg)
• Event Channel è realizzato dai sistemi MOM di Messa ging• Messaging mediato da un Message Server
• Esempio JMS API:• Administered Objects: incapsulano le specifiche
implementazioni vendor-dependent dei provider JMS (Destination, ConnectionFactory)
• Oggetti producer/consumer per l’invio e la ricezione dei messaggi (TopicPublisher, TopicSubscriber, MessageL istener)
Esempio: MOM e JMS API
Publisher SubscriberMessageServer
TopicSubscriber
TopicPublisher
public class MyPublisher{
[…]public MyPublisher(){
/* Ricerca della factory per creare le connessioni col message server */
jndiContext = new InitialContext();connectionFactory = (ConnectionFactory)
jndiContext.lookup("jms/TopicConnectionFactory");
// Ricerca della destinazione (il Topic dei messaggi)destination = (Topic) jndiContext.lookup("MyTopic");
}
[…]public void sendATextMessage(){
connection = connectionFactory.createConnection();session = connection.createSession(…);
/* Creazione del proxy per la comunicazione */publisher = session.createPublisher(destination);message = session.createTextMessage();message.setText(“Hello!”);publisher.publish(message);connection.close();
}}
public class MySubscriber{
[…]public MySubscriber(){
[…]/* Crea context, la ConnectionFactory, Connection,
Session */subscriber = session.createSubscriber(dest);listener = new TextListener();subscriber.setMessageListener(listener);connection.start();
}}--------------
public class TextListener implements MessageListener{
//Metodo di callback per la ricezione dei messaggipublic void onMessage(Message message) {
TextMessage msg = null; if (message instanceof TextMessage) {
msg = (TextMessage) message;String content = msg.getText();[…]
}}
}
![Page 34: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/34.jpg)
• Architettura Event Driven: Publish&Subscribe• Scambio di messaggi tra sistemi distribuiti • Modalità (prevalentemente) asincrona
• Architettura Service Oriented: • Invocazioni di servizio tra sistemi distribuiti• Modalità sincrona
• Architettura CART• Previsto un modello di comunicazione basato su richi este di
servizio ààà à Presenza di un coordinatore di servizio (Broker/Orche strator)
Broker
Broker/Orchestrator
Broker/OrchestratorNAL aNAL a
NAL bNAL b
NAL cNAL c
NAL dNAL dSILSIL
Client
Server
![Page 35: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/35.jpg)
Web Services + Broker
• Architettura CART per l’architettura SOA• WebService Orchestrator è mediatore della comunicazi one
Riceve richieste di servizio dal NALDetermina la locazione del destinatarioDetermina le modalità di invocazioneComunica col NAL di destinazione invocando il servi zio
• La componente presente sul CRIC mantiene un registr y dei servizi e fornisce API per la registrazione dei servi zi
CRICCRIC
NAL aNAL a
SIL a1SIL a1 SIL a2SIL a2
Proxy applic.
NAL bNAL b
SIL b1SIL b1 SIL b2SIL b2
Proxy applic.
WebServicesOrchestrator
registry
![Page 36: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/36.jpg)
Architectural Pattern Broker
• Architettura SOA ben rappresentata dal pattern Brok er
• “The Broker architectural pattern can be used to str ucturedistributed software systems with decoupled componentsthat interact by remote services invocations. A broker is responsible for coordinating communication. Forwarding request, transmitting results […]” [POSA01]
• Contesto e Problematiche• Ambiente distribuito• Sistemi indipendenti tra loro (il client non conosce la locazione
del provider di servizio)• Sistemi eterogenei (indipendenza dalla implementazion e)
• Soluzioni• Introduzione del broker• Invocazione dei servizi sotto forma di “messaggi di ch iamata”
indirizzati al broker
![Page 37: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/37.jpg)
Architectural Pattern Broker: Struttura
• Fornitore di servizi: Server• Implementano i servizi e li espongono tramite interf acce• Descrizione di interfacce: formati IDL (per i WS: WS DL)• Si registrano sul broker
• Coordinatore: Broker• Offre una interfaccia di registrazione per i servizi• Mantiene le informazioni in un registro dei servizi• Trasmette richieste, risposte ed eccezioni nei due s ensi
• Proxy• Rappresentano l’oggetto server sul lato client e il client sul
server. Mascherano la distribuzione dei servizi• Intermediari della comunicazione tra Client/Server e Broker• Lato client: chiamate a procedure ß àß àß àß à messaggi al broker• Lato server: messaggi del broker ß àß àß àß à invocazioni di servizio• Sono generati dal compilatore IDL
![Page 38: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/38.jpg)
Architectural Pattern Broker: Collaborazioni
• Collaboration diagram• Registrazione del servizio• Invocazione da parte di un client
![Page 39: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/39.jpg)
Architectural Pattern Broker
• Vantaggi• Client e Server disaccoppiati (localizzazione, comunicazi one,
distribuzione trasparente)• Client e Server eterogenei (indipendenza dalla
implementazione)• Svantaggi
• Efficienza ààà à schemi alternativi in comunicazione diretta• Criticità dei malfunzionamenti del Broker
• Direct Communication Broker• Client e server comunicano direttamente per ragioni di
efficienza• Client e server condividono il protocollo di comuni cazione• Il Broker inizializza la connessione indicando al clie nt • I Proxy svolgono le attività di comunicazione
• E.g. Web Services• Il broker svolge funzione di registro dei servizi
![Page 40: Architectural Patterns eToscana - 20040217](https://reader033.vdocumenti.com/reader033/viewer/2022051207/543738d6219acdf4648b45e9/html5/thumbnails/40.jpg)
Riferimenti
• [GHJV95] Gamma, Helm, Johnson, Vlissides, “Design Patterns – Elements of Reusable Object-Oriented Software” , Addison-Wesley 1995
• [Fow00] M.Fowler, “UML Distilled” , Addison Wesley 2000• [POSA01] Buschmann, Meunier, Rohnert, Sommerlad, St al,
“Pattern-Oriented Software Architecture” , Wiley 2001• [Fow03] M.Fowler, “Patterns of Enterprise Application
Architecture” , 2003