E’ uno dei servizi fondamentali dell’architettura OMA. Esso gestisce l’associazione tra nomi simbolici e riferimenti remoti, disaccoppiando le applicazioni clienti da quelle serventi.
Le applicazioni serventi usano il servizio dei nomi per registrare i riferimenti degli oggetti CORBA, e associare ad essi un nome simbolico.
Le applicazioni clienti usano il servizio per ottenere il riferimento all’oggetto remoto a partire dal nome simbolico.
La figura illustra le fasi necessarie allo scambio del riferimento remoto tra l’applicazione servente e quella cliente.
L’applicazione servente crea un riferimento remoto (1) e lo registra presso il servizio dei nomi (2)
L’applicazione cliente risolve tale riferimento (3) ed usa l’oggetto remoto (4).
Il servizio dei nomi ha una struttura ad albero.
I nodi sono elementi di tipo NamingContext, definito dallo standard in una apposita interfaccia IDL.
Ogni nodo è caratterizzato da un nome proprio e può contenere sia associazioni nome-riferimento che altri NamingContext.
I NamingContext “figli” di un medesimo NamingContext “padre” non possono avere il medesimo nome.
È invece possibile avere nomi identici per NamingContext non direttamente relazionati nella gerarchia.
Le strutture e le interfacce del servizio dei nomi sono definite entro il modulo IDL CosNaming. Si riconoscono le seguenti definizioni:
NameComponent rappresenta il nome da assegnare ad un NamingContext oppure il nome da associare ad un riferimento remoto
È costituito da due campi di tipo stringa di caratteri
Name è una sequenza di NameComponent utile per la creazione di “catene” di NamingContext con nome.
NamingContext fornisce meccanismi per la registrazione di riferimenti, per il collegamento di nuovi NamingContext e per la navigazione tra i contesti stessi.
BindingIterator è una utility per una navigazione flessibile sull’albero dei nomi.
Fornisce metodi per:
la registrazione di riferimenti (associazione con nome simbolico)
la risoluzione dei riferimenti (a partire da un nome simbolico)
l’aggiunta di un NamingContext in cascata
l’eliminazione di nodi
Il servizio dei nomi è un servizio distribuito su CORBA.
Per risolvere il riferimento alla root del servizio (anch’essa di tipo NamingContext) è possibile utilizzare il metodo
resolve_initial_reference(String nomeServizio)
dove nomeServizio è la stringa NameService.
Il metodo restituisce un oggetto di tipo org.omg.COBA.Object tramite il quale è possibile creare il proxy all’oggetto NamingContext con il consueto uso delle HelperClass.
Supponiamo di voler registrare un riferimento “object3″ associandolo ad un Name del tipo “NContesto1\Contesto2\NomeNuovoOggetto”
Mostra codiceIl codice seguente mostra la programmazione necessaria alla risoluzione dell’oggetto object1 caratterizzato dal nome simbolico NContesto1\NContesto2\ \NomeOggetto1
Mostra codiceAggiunta di un nuovo NamingContext, caratterizzato dal nome NuovoContesto, alla radice del servizio dei nomi.
Mostra codiceGeneralità
Il servizio Trading si pone come intermediario tra le applicazioni serventi, produttrici di oggetti distribuiti, e le applicazioni clienti, utilizzatrici di tali oggetti.
Le applicazioni serventi usano il servizio Trading per “esportare” offerte di servizio forniti dai propri oggetti distribuiti. Questa attività consiste nell’inserimento, presso il servizio Trading, dei valori di alcune proprietà caratterizzanti il servizio stesso.
Le applicazioni clienti usano il servizio di trading per risolvere i servizi che soddisfano i criteri di ricerca; tale attività è detta “importazione” di un servizio.
Per agevolare le procedure di esportazione e di ricerca, il servizio di Trading presenta diverse interfacce:
Rappresenta un contenitore di tipi di servizi. Un tipo di servizio è rappresentato da una struttura ServiceType, costituita dai seguenti campi:
Tramite l’interfaccia ServiceTypeRepository le applicazioni potranno:
Le applicazioni serventi potranno, inoltre, registrare ed eliminare tipi di servizi, rispettivamente con i metodi metodi add_type() e remove_type().
Questa interfaccia è dedicata alle applicazioni serventi per la gestione delle offerte di servizio. In particolare sarà possibile:
Il metodo export() richiede siano forniti in ingresso:
e restituisce un id unico, OfferId, per l’offerta registrata.
OfferId costituisce la chiave per la modifica o il ritiro dell’offerta.
Questa interfaccia è dedicata alle applicazioni clienti per l’importazione dei servizi.
Tramite essa è possibile specificare una ricerca fornendo, all’unico metodo di nome query()
I vincoli, le politiche e le preferenze vanno espresse in un apposito linguaggio (constraint language).
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