Pattern creazionali
Esempi di architectural patterns illustrati in dettaglio nel seguito:
- MVC;
- Broker.
Il Pattern MVC
Un classico esempio di pattern architetturale è il pattern Model-View-Controller (MVC).
È stato uno dei primi pattern, introdotto nel 1988 con Smalltalk-80.
In realtà è una vera e propria “composizione di pattern”.
La sua fama odierna è dovuta in parte alla diffusione di Java, perché utilizzato per alcuni componenti della libreria Swing.
Alcuni ambienti di sviluppo (Microsoft Visual C++, Jakarta Struts) si basano su tale pattern.
Il Pattern MVC
Nacque dalla necessità di visualizzare dati generici tramite interfaccia grafica (GUI), mediante l’utilizzo di rappresentazioni diverse dei dati stessi.
Consente la realizzazione di una architettura che permette la separazione netta dei componenti di presentazione dei dati dai componenti che gestiscono i dati stessi.
Il Pattern MVC
MVC disaccoppia View e Model, utilizzando un protocollo di sottoscrizione-notifica.
Controller trasforma gli input utente nella View in azioni del Model, implementando la logica di controllo dell’applicazione.
Il Pattern MVC
MVC – Modello
Definisce le regole di business per l’interazione con i dati, esponendo alla View ed al Controller rispettivamente le funzionalità per l’accesso e l’aggiornamento.
Ha la responsabilità di notificare ai componenti della View eventuali aggiornamenti verificatisi in seguito a richieste del Controller, al fine di permettere alle View di presentare dati sempre aggiornati.
MVC – Vista
Gestisce la logica di presentazione dei dati.
Ogni GUI può implementare viste diverse sui dati, e modalità diverse di interazione coi dati
Es.: Modalità asincrona e strategia “push”.
Si può utilizzare un altro pattern (Observer), registrando le View come osservatori del Model. Le View possono quindi richiedere gli aggiornamenti al Model in tempo reale. Inoltre la View delega al Controller l’esecuzione dei processi richiesti dall’utente dopo averne catturato gli input, e la scelta delle eventuali schermate da presentare.
Controller
Ha la responsabilità di trasformare le interazioni dell’utente della View in azioni eseguite dal Model.
Realizza la corrispondenza tra l’input dell’utente e i processi eseguiti dal Model.
Selezionando la schermate della View richieste, il Controller implementa la logica di controllo dell’applicazione.
Aggiornamento dei dati
In risposta a qualche evento il metodo handleEvent() viene invocato sul Controller.
Il Controller esamina lo stato del modello usando il metodo getState() e invoca un metodo di servizio nel modello per cambiare il suo stato.
Il modello cambia lo stato e invoca il suo metodo di notifica per notificare il cambiamento di stato a tutte le View registrate;
Ogni View registrata viene notificata invocando il suo metodo update(). La View esamina lo stato del modello tramite il metodo getState() e si autoaggiorna.
Selezione Schermata
L’utente seleziona una pagina.
La View non decide quale sarà la schermata richiesta, delegando ciò al Controller tramite l’invocazione del suo metodo processSelectPage(), che grazie al pattern Strategy può essere anche cambiato dinamicamente a runtime.
Il Controller decide la pagina da visualizzare, e la comunica alla View invocando il suo metodo showSelectPage().
La View costruisce e presenta all’utente della schermata stessa, controllando se ci sono state modifiche nel modello invocando il metodo getState().
Il Pattern Broker
Il Broker è un pattern architetturale, con schema logico di tipo publish/subscribe:
- gli oggetti serventi rendono noto i servizi forniti;
- oggetti clienti che sono interessati ad a uno o più servizi si iscrivono per utilizzare il servizio;
- pubblicazioni e iscrizioni avvengono presso il Broker.
Conferisce al sistema caratteristiche di trasparenza alla locazione, al linguaggio di programmazione e alla piattaforma target.
L’architettura con Broker rappresenta un sorta di bus (software) virtuale a cui ogni oggetto affida i suoi messaggi.
Il Broker è l’elemento di integrazione fra i “moduli” che compongono il sistema software.
Il Pattern Broker e il modello Client/Server
Il Pattern Broker
Il Broker è un pattern molto utilizzato nelle architetture dei sistemi middleware.
Esempi di middleware che lo utilizzano sono: OMG CORBA, IBM SOM/DSOM, Microsoft OLE 2.x
Una applicazione può accedere a servizi distribuiti semplicemente inviando messaggi all’oggetto appropriato, piuttosto che doversi impegnare in una comunicazione inter-processo di basso livello.
Il Pattern Broker: modello statico
Comprende sei tipi di componenti partecipanti:
- serventi, implementano oggetti che espongono funzionalità, attraverso un’interfaccia che consiste di operazioni e attributi;
- clienti, applicazioni che accedono ai servizi offerti dai serventi;
- broker, componente responsabile della trasmissione delle richieste dai clienti ai serventi, e della trasmissione ai clienti delle risposte o delle eccezioni rilevate;
- bridge, componenti opzionali, utilizzati per nascondere i dettagli di implementazione della comunicazione tra i broker in una rete eterogenea;
- proxy lato cliente, strato software addizionale tra cliente e broker, che rende trasparente al cliente l’accesso ad un oggetto remoto, che appare così come un oggetto locale;
- proxy lato servente, duale del proxy lato cliente.
Il Pattern Broker: modello statico
Il Broker e il Bridge
Un broker è un componente responsabile della trasmissione delle richieste dai clienti ai serventi, e della trasmissione ai clienti delle risposte o delle eccezioni rilevate.
Un broker offre dei metodi (API) ai clienti e ai serventi, che includono operazioni per registrare un server e per invocarne i servizi.
I bridge sono componenti opzionali del pattern, utilizzati per nascondere i dettagli di implementazione della comunicazione tra i broker in modo che, in una rete eterogenea, i broker comunichino in maniera trasparente, rispetto all’architettura di rete e ai sistemi operativi in uso.
Registrazione di un server sul broker locale
1. Il broker viene eseguito nella fase di inizializzazione del sistema. Entra così in un ciclo di attesa eventi, aspettando che arrivino messaggi.
2. L’utilizzatore esegue l’applicazione server, che esegue una fase di inizializzazione dopo la quale si registra presso il broker.
3. Il broker riceve il messaggio di richiesta registrazione, estrae le informazioni necessarie e le memorizza in un’area dati, il repository, che serve per trovare e attivare i server, e invia un messaggio di avvenuta registrazione al server.
4. Ricevuta la conferma, il server entra nel ciclo di attesa delle richieste provenienti dai clienti.
Un cliente invia una richiesta ad un broker locale
Un cliente invia una richiesta ad un broker locale
1. L’applicazione cliente viene eseguita. Durante l’esecuzione del programma il cliente invoca un metodo di un oggetto server remoto.
2. Il proxy lato cliente impacchetta tutti i parametri ed altre informazioni supplementari, in un messaggio che viene trasferito al broker locale.
3. Il broker ricerca la posizione del server richiesto all’interno del suo repository. Se il server è disponibile localmente, il broker trasferisce il messaggio al corrispondente proxy lato server (il caso di server remoto lo vediamo nel prossimo scenario).
4. Il proxy lato server spacchetta i parametri e le informazioni supplementari, tra cui il metodo che bisogna invocare. A questo punto il proxy richiama il servizio appropriato.
5. Dopo che il servizio è stato eseguito, il server restituisce il risultato al proxy lato server, che lo impacchetta, insieme ad informazioni supplementari, in un messaggio che trasferisce poi al broker.
6. Il Broker trasferisce la risposta al proxy lato client.
7. Il proxy lato client riceve la risposta, spacchetta il messaggio e lo invia all’applicazione cliente, che dopo aver ricevuto i dati di suo interesse, continua la sua esecuzione normalmente.
Interazione tra broker tramite il bridge
Interazione tra broker tramite il bridge
1. Il broker A riceve una richiesta di servizio. Esso ricerca nel repository il server responsabile dell’esecuzione del servizio. Siccome il server corrispondente è disponibile presso un altro nodo della rete, A trasmette la richiesta al broker remoto.
2. Il messaggio passa dal broker A al bridge A. Questo componente è responsabile della conversione del messaggio dal protocollo specifico del broker A, in un protocollo di rete comune ai due bridge partecipanti. Dopo la conversione, il bridge A trasmette il messaggio al bridge B.
3. Il bridge B converte il messaggio in ingresso, dal protocollo di rete al formato del protocollo specifico del broker B.
4. Il broker B esegue tutte le azioni necessarie all’arrivo di una richiesta di servizio.
Le lezioni del Corso
2. La modellazione a oggetti e il linguaggio UML (richiami)
3. Generalità su Java e la programmazione ad oggetti
6. Regole di traduzione da UML a Java/C++
7. Programmazione multi-thread
8. Sincronizzazione tra thread
9. Programmazione client-server con socket TCP/IP (Java networkin...
10. Programmazione di applicazioni client-server: il Pattern Proxy...
12. Design Patterns
13. Pattern architetturali - Esempi
14. Design pattern creazionali. Esempi
15. Design pattern strutturali. Esempi
16. Introduzione alle tecnologie middleware
17. Modelli di middleware: RPC, MOM, TP, TS
