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

Stefano Russo » 27.I servizi Naming e Trading


Il servizio dei Nomi

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.

Scambio dei riferimenti tramite servizio dei Nomi

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).


Struttura del servizio dei nomi

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.


Strutture ed interfacce per il servizio dei nomi

Le strutture e le interfacce del servizio dei nomi sono definite entro il modulo IDL CosNaming. Si riconoscono le seguenti definizioni:

  • una struttura, NameComponent;
  • una sequenza non limitata di NameComponent di nome Name;
  • una interfaccia di nome NamingContext;
  • una interfaccia di nome BindingIterator.

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

  • id (il nome vero e proprio, utilizzato nella risoluzione di riferimenti o dei contesti);
  • kind (utile per esplicitare ulteriori informazioni non utilizzati però negli scenari di risoluzione).

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.

org.omg.CosNaming.NamingContext

Fornisce metodi per:
la registrazione di riferimenti (associazione con nome simbolico)

  • void bind(NameComponent[] n,Object obj) throws NotFound, CannotProceed, InvalidName, AlreadyBound
  • void rebind(NameComponent[] n, Object obj) throws NotFound,CannotProceed, InvalidName

la risoluzione dei riferimenti (a partire da un nome simbolico)

  • object resolve(NameComponent[]name) throws NotFound, CannotProceed, InvalidName

l’aggiunta di un NamingContext in cascata

  • bind_context(NameComponent[] n,NamingContext nc)

l’eliminazione di nodi

  • void destroy() throws NotEmpty

Accesso al servizio dei nomi

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.


Accesso al servizio dei nomi


Registrazione di un riferimento in un nodo

Supponiamo di voler registrare un riferimento “object3″ associandolo ad un Name del tipo “NContesto1\Contesto2\NomeNuovoOggetto”

Mostra codice

Risoluzione di un riferimento

Il codice seguente mostra la programmazione necessaria alla risoluzione dell’oggetto object1 caratterizzato dal nome simbolico NContesto1\NContesto2\ \NomeOggetto1

Mostra codice

Aggiunta di un NamingContext

Aggiunta di un nuovo NamingContext, caratterizzato dal nome NuovoContesto, alla radice del servizio dei nomi.

Mostra codice
Struttura risultante

Struttura risultante


Il servizio Trading

Generalità

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.

Interfacce per il servizio di Trading

Per agevolare le procedure di esportazione e di ricerca, il servizio di Trading presenta diverse interfacce:

  • ServiceTypeRepository;
  • Register;
  • Lookup;
  • OfferIterator.

ServiceTypeRepository

Rappresenta un contenitore di tipi di servizi. Un tipo di servizio è rappresentato da una struttura ServiceType, costituita dai seguenti campi:

  • ServiceTypeName, che consiste nel nome del servizio (per esempio Stampa);
  • InterfaceNameType, che consiste nel nome dell’IDL interface per il servizio (per esempio Stampante);
  • una lista di Properties che rappresentano le caratteristiche del servizio.

Tramite l’interfaccia ServiceTypeRepository le applicazioni potranno:

  • ottenere la lista dei ServiceType registrati: metodo list_types();
  • ottenere una loro completa caratterizzazione: metodo describe_type().

Le applicazioni serventi potranno, inoltre, registrare ed eliminare tipi di servizi, rispettivamente con i metodi metodi add_type() e remove_type().

Register

Questa interfaccia è dedicata alle applicazioni serventi per la gestione delle offerte di servizio. In particolare sarà possibile:

  • esportare un’offerta: metodo export()
  • ritirare una offerta registrata: metodo withdraw()
  • modificare un’offerta: metodo modify().

Il metodo export() richiede siano forniti in ingresso:

  • il tipo di servizio al quale riferisce l’offerta;
  • il valore per ognuna delle proprietà caratterizzanti il tipo del servizio;
  • il riferimento all’oggetto distribuito;

e restituisce un id unico, OfferId, per l’offerta registrata.

OfferId costituisce la chiave per la modifica o il ritiro dell’offerta.

Lookup

Questa interfaccia è dedicata alle applicazioni clienti per l’importazione dei servizi.
Tramite essa è possibile specificare una ricerca fornendo, all’unico metodo di nome query()

  • il tipo del servizio;
  • una stringa di vincoli (constraint);
  • una stringa di preferenze (preference);
  • una stringa di politiche (policies);
  • un intero indicante il numero massimo di risultati.

I vincoli, le politiche e le preferenze vanno espresse in un apposito linguaggio (constraint language).

  • 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

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93