Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Stefano Russo » 28.La comunicazione asincrona


La comunicazione asincrona in CORBA

Al fine di implementare uno schema di comunicazione asincrona e/o ad accoppiamento lasco tra un cliente ed un servente è possibile adottare tre tecniche:

  • distributed callback;
  • servizio di gestione eventi di CORBA (CORBA Event Service);
  • servizio di notifica di CORBA (CORBA Notification Service).

Distributed callback

Trae origine dal modello di programmazione basato su callback.
Il flusso di eventi generati da una richiesta di servizio di distributed callback tra un cliente e un oggetto CORBA è il seguente:

  • il cliente invia una richiesta di servizio a un oggetto remoto, fornendo al contempo un riferimento a un oggetto locale, che vive nel contesto dell’applicazione cliente;
  • l’oggetto esegue il servizio richiesto;
  • al fine di notificare il completamento dell’elaborazione e restituire i risultati, l’oggetto servente richiama un’operazione sull’oggetto cliente il cui riferimento gli è stato fornito assieme alla richiesta;
  • l’oggetto cliente riceve la callback, con cui acquisisce i risultati.

Distributed callback: un esempio

Un’interfaccia per il calcolo di un estratto del conto corrente:

Mostra codice

Distributed callback: un esempio

La richiesta (nell’esempio getEstrattoConto()) viene di norma inviata con un’invocazione di tipo oneway al fine di evitare l’attesa sospensiva da parte del cliente.


Distributed callback: limiti nell’utilizzo

Il meccanismo di comunicazione asincrona realizzato da tale tecnica è basato su un accoppiamento stretto tra oggetto cliente e servente (l’oggetto servente deve conoscere l’interfaccia callback fornita dal cliente).

La comunicazione è del tipo uno–a–uno, vale a dire tra due soli oggetti.

Molto spesso, invece, è necessario realizzare un meccanismo di comunicazione asincrono ad accoppiamento lasco, tra un insieme di clienti e un insieme di serventi.

Event Service: generalità

Un servizio di comunicazione asincrona ad accoppiamento lasco tra un insieme di serventi ed uno dei clienti.

Alcune definizioni

Un evento è un’occorrenza di un oggetto che è di interesse per uno o più oggetti.

Una notifica è un messaggio che un oggetto invia alle parti interessate per comunicare un determinato evento.

Un oggetto notifica l’evento senza conoscere quali sono le parti interessate (accoppiamento lasco).

Event Service: modello concettuale

Due ruoli coinvolti nella comunicazione:

  • Supplier (produttore o fornitore): entità che produce eventi;
  • Consumer (consumatore): entità interessata ad un evento.

Due paradigmi di comunicazione

Push Model: il supplier ha l’iniziativa. Sarà esso a trasferire l’evento al consumer

Pull Model: il consumer ha l’iniziativa. Sarà esso dunque a richiedere i dati al supplier


Event Service: l’Event Channel

È un oggetto CORBA che svolge il ruolo sia di supplier sia di consumer.

Ha lo scopo di disaccoppiare la comunicazione tra i consumer e i supplier. In tal modo un supplier notifica l’evento senza conoscere i consumer interessati.

Dovendosi interfacciare con un insieme di supplier e di consumer, l’Event Channel è costituito da due parti principali:

  • una che funge da consumer per i supplier;
  • una che svolge il ruolo di supplier per i consumer.

Event Service: modelli di comunicazione

L’Event Channel è in grado di garantire la comunicazione asincrona ad accoppiamento lasco tra n produttori e m consumatori.

Si possono avere quattro modelli di comunicazione tra il canale e i consumer e supplier:

  • modello Pull – per la comunicazione con l’Event Channel, sia i supplier che i consumer adottano il modello Pull;
  • modello Push/Pull – i consumer adottano il modello Pull mentre i supplier quello Push;
  • modello Pull/Push – i consumer adottano il modello Push mentre i supplier adottano quello Pull;
  • modello Push – sia i supplier sia i consumer adottano il modello Push.

Event Service: un modello Push/Pull

Un Event Channel collegato a due supplier e tre consumer.

Dei due supplier, uno adotta il modello Pull e l’altro quello Push mentre, dal lato consumer, due adottano lo schema Pull e l’altro quello Push. Si dice, pertanto, che l’Event Channel adotta un modello Push/Pull ibrido.


Event Service: il modulo CosEventComm

Definisce le seguenti interfacce IDL

Definisce le seguenti interfacce IDL


Event Service: consumer e supplier

Un consumer di tipo Push dovrà implementare l’interfaccia PushConsumer.

Un consumer di tipo Pull dovrà implementare l’interfaccia PullConsumer.

Un supplier di tipo Pull dovrà implementare l’interfaccia PullSupplier, fornendo i metodi pull() e try_pull().

Un supplier di tipo Push dovrà implementare l’interfaccia PushSupplier, costituita dal solo metodo disconnect_push_supplier().

Event Service: il modulo CosEventComm

Mostra codice

Event Service: consumer

Un consumer di tipo Push dovrà implementare l’interfaccia PushConsumer. Tale interfaccia svolge un ruolo di callback per i supplier, i quali provvederanno ad invocare il metodo push per notificare ai consumer un evento.

Il metodo disconnect_push_consumer() è invocato da un supplier che non desidera più inoltrare eventi a quel determinato consumer.

Un consumer di tipo Pull dovrà implementare l’interfaccia PullConsumer. Tale consumer avrà l’onere di effettuare un polling sul Pull supplier a cui è connesso, invocando il metodo pull().

Il metodo disconnect_pull_consumer() è invocato da un supplier che non desidera più inoltrare eventi al consumer.

Event Service: supplier

Un supplier di tipo Pull, implementando l’interfaccia PullSupplier, fornisce due metodi.

  1. Il metodo pull() è invocato da un consumatore per prelevare un evento. Tale metodo è di tipo bloccante: il consumer permarrà in uno stato di attesa attiva finché non viene generato un evento dal supplier.
  2. Il metodo try_pull(), è di tipo non bloccante. Esso consente di rilevare, ed in caso affermativo di prelevare, la presenza di un evento (la presenza o meno di un evento è fornita mediante il parametro di uscita has_event).

Un supplier di tipo Push dovrà implementare l’interfaccia PushSupplier, con il solo metodo disconnect_push_supplier(). Infatti la produzione e notifica di un evento da parte di un push supplier avviene invocando il corrispondente metodo push() sul consumer.

Si noti che l’evento è un tipo CORBA::Any, per cui è lasciata al programmatore la responsabilità di gestire la conversione di eventi “tipati” in tipi any.

Event Service: il modulo CosEventAdmin

Mostra codice

 

L’interfaccia IDL dell’Event Channel è definita nel modulo CosEventAdmin

L'interfaccia IDL dell'Event Channel è definita nel modulo CosEventAdmin


Event Service: il modulo CosEventAdmin

L’Event Channel è costituito da due gruppi di interfacce:

  • la Proxy Supplier Interface è utilizzata dai consumer per connettersi all’Event Channel in modalità push (interfaccia ProxyPushSupplier) o in modalità pull (interfaccia ProxyPullSupplier);
  • la Proxy Consumer Interface è utilizzata dai supplier (interfacce ProxyPullConsumer e ProxyPushConsumer).

Tali interfacce permettono di disaccoppiare totalmente la comunicazione tra i supplier e i consumer, dando ai supplier (consumer) l’illusione di interagire con un unico consumer (supplier).

Implementazione di un consumer

Passi di sviluppo per implementare un consumer connettendosi ad un EventChannel

Passi di sviluppo per implementare un consumer connettendosi ad un EventChannel


Implementazione di un supplier

Passi di sviluppo per implementare un supplier connettendosi ad un EventChannel

Passi di sviluppo per implementare un supplier connettendosi ad un EventChannel


Event Service: un modello Push


Event Service: esempio

Una semplice applicazione di un modello Push/Pull, con un solo consumer e un solo supplier

Una semplice applicazione di un modello Push/Pull, con un solo consumer e un solo supplier


Event Service: esempio

Diagramma di sequenza che mostra lo scenario di produzione/consumo di un evento nell’esempio

Diagramma di sequenza che mostra lo scenario di produzione/consumo di un evento nell'esempio


Event Service: esempio – IDL

// IDL per la definizione dell'evento
struct Evento {
long eventID;
string messContent;
};

Event Service: esempio – il consumer

import org.omg.CosEventComm.*;
import org.omg.CosEventChannelAdmin.*;
import org.omg.PortableServer.*;
import java.io.*;

public class ConsumerPull extends PullConsumerPOA {
public ConsumerPull() { }

public void disconnect_pull_consumer() {
System.out.println ("disconnect_pull_consumer invocato");
}

Event Service: esempio – il consumer

Mostra codice

Event Service: esempio – il consumer

Mostra codice

Event Service: esempio – il consumer

Mostra codice

Event Service: Federazione di canali

Più Event Channel possono essere organizzati in un’apposita struttura (Event Channel Federation).

Una federazione può essere creata mediante la registrazione di un event channel come consumer di un altro.

Lo sviluppatore avrà la responsabilità di predisporre una federazione organizzata con una topologia che meglio si adatta ai requisiti dell’applicazione.

Event Service: Federazione di Event Channel

Un’applicazione in cui si ha la necessità di trasferire tre tipologie di eventi: eventi di tipo A, di tipo B e di tipo C. Per ogni tipologia viene creato un apposito Event Channel: Event_A, Event_B e Event_C.


Event Service: limiti nell’utilizzo

Lo standard non specifica nessuna qualità del servizio per la notifica degli eventi. In particolare, le specifiche dello standard non affrontano né il problema della persistenza degli eventi, né i parametri di qualità del servizio della loro consegna.

L’unico modo per discriminare eventi è di creare più Event Channel, uno per tipologia. In altre parole, le specifiche dello standard non prevedono alcun meccanismo di filtering degli eventi.

L’Event Channel, così come specificato dallo standard, non è in grado di rendere disponibili le informazioni concernenti il suo stato di esecuzione.

Notification Service: generalità

Nasce con l’obiettivo di superare i limiti dell’Event Service
In particolare tre sono le problematiche affrontate:

  • le strategie di filtraggio degli eventi (filtering);
  • il mantenimento e la gestione di informazioni sullo stato dell’Event Channel;
  • la definizione di parametri di qualità del servizio di consegna degli eventi. I parametri di qualità possono essere specificati per evento, per consumer/supplier e per Event Channel.

Notification Service: architettura


Notification Service: architettura

Le interfacce definite per il Notification Service sono derivate da quelle corrispondenti dell’Event Service. Ciò consente di preservare la compatibilità con le applicazioni scritte utilizzando il servizio di eventi.

L’interfaccia dell’Event Channel fornisce un insieme di metodi per l’accesso alle sue informazioni di stato. Per esempio è possibile, per un consumer o per un supplier, conoscere quante istanze di oggetti proxy sono associate a un particolare Event Channel, cioè è possibile conoscere quanti (e quali) sono i supplier e i consumer connessi.

Notification Service: architettura

Il modello prevede la possibilità di definire nuovi eventi specificando cosiddetti structured event (eventi strutturati):

  • l’header: contenente informazioni generali sulla tipologia dell’evento (nome, dominio di appartenenza, ed alcuni campi opzionali);
  • l’Event Body: contenente le informazioni per il filtraggio degli eventi, le informazioni concernenti la qualità del servizio predisposta per la consegna, il contenuto dell’evento.

Gli eventi strutturati sono memorizzati in un apposito repository, accessibile sia dai consumer sia dai supplier (Event type Repository).

La persistenza degli eventi è realizzata mediante l’ausilio di repository locali sia sui proxy sia sull’Event Channel.

Notification Service: la qualità del servizio

Proprietà di qualità del servizio e i livelli di granularità supportati dal servizio di notifica

Proprietà di qualità del servizio e i livelli di granularità supportati dal servizio di notifica


I materiali di supporto della lezione

Brose G., Vogel A., Duddy K., Java Programming with CORBA – Advanced Techniques for Building Distributed Applications, 3rd edition, OMG Press, John Wiley & Sons, 2001.

Siegel J., CORBA 3 – Fundamentals and Programming, 2nd edition, OMG Press, John Wiley & Sons, 2000.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion