Al fine di implementare uno schema di comunicazione asincrona e/o ad accoppiamento lasco tra un cliente ed un servente è possibile adottare tre tecniche:
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:
Un’interfaccia per il calcolo di un estratto del conto corrente:
Mostra codiceLa 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.
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.
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).
Due ruoli coinvolti nella comunicazione:
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
È 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:
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:
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.
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().
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.
Un supplier di tipo Pull, implementando l’interfaccia PullSupplier, fornisce due metodi.
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.
L’Event Channel è costituito da due gruppi di interfacce:
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).
// IDL per la definizione dell'evento
struct Evento {
long eventID;
string messContent;
};
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");
}
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.
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.
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.
Nasce con l’obiettivo di superare i limiti dell’Event Service
In particolare tre sono le problematiche affrontate:
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.
Il modello prevede la possibilità di definire nuovi eventi specificando cosiddetti structured event (eventi strutturati):
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.
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
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.
Object Management Group, Common Object Request Broker Architecture (CORBA) v. 2.6, 2001.