Le modalità di comunicazione fra oggetti

Le modalità di comunicazione fra oggetti

Nel modello a oggetti, la comunicazione tra due oggetti può avvenire secondo due differenti modalità: sincrona e asincrona.

La modalità sincrona (Request/Response) è analoga ad una chiamata a procedura/funzione dei linguaggi di programmazione, con il relativo passaggio dei parametri. E’ il middleware che si occupa di raccogliere i valori di questi parametri, di impacchettarli insieme al nome dell’operazione per formare un messaggio e di  inviarli  all’oggetto server; quando questi avrà eseguito il compito richiesto, sempre il middleware impacchetterà il valore di ritorno dei parametri di uscita per restituirli al client. I middleware che si basano su questo meccanismo vengono tipicamente classificati come basati su RPC (Remote Procedure Call). Il client ed il server devono essere contemporaneamente attivi nel momento in cui il servizio viene richiesto e il client rimane in attesa finché il server non comp leta il compito richiesto e  restituisce  la risposta. Tale modalità implica un forte accoppiamento tra il client ed il server, in quanto il client rimane bloccato, consumando risorse, dal momento in cui ha inviato la richiesta  a quello in cui ottiene la ris posta.

Nella modalità asincrona i componenti possono essere attivi in momenti differenti, in quanto la comunicazione avviene attraverso lo scambio di messaggi unidirezionali: il client invia un messaggio ad una coda d’attesa, il server preleva i messaggi dalla coda. In questo modo c’è totale indipendenza tra i due oggetti e la coda d’attesa costituisce l’elemento di disaccoppiamento. In tal caso il middleware si occupa della gestione della coda e dello smistamento dei messaggi; tali middleware vengono  classificati come MOM (Messagge Oriented Middleware) e/o MQM (Message Queueing Middleware).

La modalità di comunicazione asincrona può essere realizzata secondo quattro schemi di interazione tra client e server:

  • Publish and Subscribe – I client ed i server non comunicano in modo diretto, ma partecipano a una relazione ternaria in cui gli oggetti server (publisher) forniscono informazioni, gli oggetti client (subscriber) le ricevono e un terzo soggetto (il distributor) si occupa della distribuzione ai subscriber delle informazioni prodotte dai publisher. La Figura seguente mostra lo schema a oggetti di riferimento per tale modalità di comunicazione asincrona.

    Le modalità di comunicazione fra oggetti - Comunicazione Publish and Subscribe
    Le modalità di comunicazione fra oggetti – Comunicazione Publish and Subscribe
  • Multicasting – In questo schema c’è una conoscenza diretta dei riceventi da parte della sorgente dell’informazione. Tipicamente il multicasting è fatto direttamente dal soggetto sorgente, che si connette ai riceventi e fornisce i messaggi.
  • Instance Based Routing – E’ una variante del PublishandSubscribe, in cui i subscriber non solo dichiarano l’interesse in qualche tipo di messaggi, ma hanno la possibilità di fornire dei criteri di selezione ulteriori, con cui il distributor determina se effettivamente consegnare certi messaggi ai In sostanza mentre nel PublishandSubscribe si possono distinguere i messaggi solamente in base al loro tipo, in questo schema si ha la possibilità di raffinare ulteriormente le tipologie anche in base a sottocaratteristiche degli stessi.
  • Store and Forward – Nello schema PublishandSubscribe il messaggio viene consegnato ai subscriber solo se questi hanno una connessione attiva con il distributor; il messaggio infatti è consegnato immediatamente a tutti i subscriber connessi al momento e quindi cancellato. In pratica il meccanismo è asincrono tra gli oggetti terminali (publisher e subscriber) ma richiede sincronicità tra distributor e subscriber. Nello schema StoreandForward invece, il messaggio viene memorizzato dal distributor non appena ricevuto dal publisher e viene mantenuto fino alla consegna a tutti i subscriber. La consegna avviene al momento della connessione dei subscriber al distributor o su iniziativa del distributor allo scadere di un timeout.

Al fine di mettere maggiormente in luce le caratteristiche di tali quattro modalità di comunicazione, si propone un esempio attinente la realtà della Pubblica Amministrazione (PA), in particolare, la problematica della diffusione di leggi e normative presso tutti i soggetti interessati, pubblici e privati.

Publish and Subscribe

Lo schema Publish and Subscribe è adatto per soddisfare le esigenze informative generali di una pluralità di soggetti (subscriber), a fronte di una pluralità di enti normatori (publisher). Un ente terzo o uno degli enti normatori è in tale caso chiamato a svolgere il ruolo di distributor. Ogni ente normatore inizialmente dichiara, mediante il servizio di registrazione, la propria volontà a pubblicare le normative prodotte che poi, mediante il servizio di pubblicazione, mette a disposizione. Ogni subscriber inizialmente sottoscrive l’abbonamento al servizio, specificando alla produzione normativa di quale o quali enti è interessato. In seguito, il distributor provvede a fornire a ogni subscriber le norme nel frattempo prodotte, inviandogliele (servizio push) o fornendogliele su richiesta (servizio pull).

Multicasting

Lo schema Multicasting è adatto quanto l’ente normatore interessato alla pubblicazione sia uno solo. In tale caso, i subscriber si rivolgono direttamente a lui, sia per l’abbonamento al servizio, sia per la fornitura delle normative prodotte. Il meccanismo Multicasting richiede, in generale, la conoscenza reciproca da parte degli utenti e del fornitore del servizio. Nel caso in cui il servizio informativo sia aperto al pubblico, si parla più propriamente di Broadcasting.

Instance Based Routing

Lo schema Instance Based Routing consentirebbe, nel nostro esempio, di fornire un servizio informativo più diversificato, che permette all’utente di selezionare le norme da ricevere non solo in base alla tipologia (per esempio, “leggi regionali”) e all’ente normatore (per esempio una specifica Regione) ma anche in base al contenuto (per esempio, norme riguardanti le tematiche ambientali, ovvero norme nel cui testo ricorre il termine “documento elettronico”).

Store and Forward

Lo schema Store and Forward , infine, si distingue per la flessibilità del collegamento richiesto fra il distributor e i subscriber che, a differenza dello schema Publish and Subscribe, non è necessario sia attivo al momento della diffusione delle informazioni richieste. Nel nostro esempio, è probabilmente consigliabile lo schema Store and Forward per la fornitura delle norme di interesse a utenti non istituzionali (per esempio, imprese private), per le quali non è realistico ipotizzare un collegamento perennemente attivo con il distributor, mentre per gli utenti istituzionali (gli enti pubblici) lo schema Publish and Subscribe sarebbe di naturale applicazione, anche alla luce della disponibilità della Rete Unitaria.

Precedente Il modello basato sugli oggetti Successivo Progettazione e realizzazione di sistemi a oggetti distribuiti

Lascia un commento

*