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
 
I corsi di Ingegneria
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Stefano Russo » 25.Programmazione di server CORBA


Oggetto CORBA

E’ un’entità virtuale che può essere localizzata dall’ORB e ricevere richieste di servizio da un cliente.

La sua esistenza è strettamente legata all’oggetto servente (servant) che esso rappresenta.

Non può esistere da solo: al fine di servire le richieste di un cliente, ad esso deve essere associato un oggetto servente.

Oggetto CORBA

Stati di un oggetto CORBA

Stato Non Attivo: è lo stato iniziale, caratterizzato dall’assenza di un’associazione con un servant.

Stato Attivo: in tale stato all’oggetto è associato un servant. Pertanto esso è pronto per servire le richieste di servizio.

Stati di un oggetto CORBA

Stati di un oggetto CORBA


CORBA dal lato servente


CORBA dal lato servente

Classe Servente: è l’entità reale responsabile dell’implementazione delle operazioni descritte nell’interfaccia IDL.

Skeleton Interfaces: sono responsabili del “collegamento” delle istanze della classe servente con la piattaforma sottostante, affinché quest’ultima possa inoltrare correttamente le richieste.

  • Static Skeleton Interface: sono utilizzate nei casi in cui le interfacce IDL siano disponibili a tempo di compilazione (sono le più utilizzate per la loro semplicità).
  • Dynamic Skeleton Interface: sono utilizzate nei casi in cui le interfacce IDL non siano disponibili a tempo di compilazione.

CORBA dal lato servente

Object Adapter: rappresenta l’intermediario tra l’ORB e lo skeleton. Esso svolge una duplice attività:

  • gestisce l’associazione tra un oggetto servente e l’oggetto CORBA;
  • si occupa dello smistamento delle richieste destinate agli oggetti serventi registrati.

ORB: ha il compito di ricevere le richieste destinate ad un oggetto CORBA e di inoltrarle all’Object Adapter opportuno.

Realizzazione della classe servente


Realizzazione della classe servente per ereditarietà

Nella tecnica per ereditarietà, la classe servente è realizzata come estensione dello skeleton InterfaceNamePOA.

La classe servente dovrà fornire l’implementazione di tutti i metodi astratti, ovvero di tutti i metodi dichiarati nell’interfaccia InterfaceNameOperations (contenente tutti metodi definiti nell’interfaccia IDL).

Realizzazione della classe servente per delega

La tecnica di realizzazione per delega è utile qualora l’oggetto servente sia derivato da altre classi specifiche dell’applicazione. In tali casi il suo utilizzo è obbligatorio se si adotta il linguaggio Java, non prevedendo, quest’ultimo, l’ereditarietà multipla.

Nella tecnica per delega, denominata tie approach, la classe servente è associata allo skeleton mediante una classe di intermediazione, denominata InterfaceNamePOATie.

InterfaceNamePOATie fornisce un’implementazione dei metodi definiti nell’interfaccia IDL come semplice delega dei metodi della classe servente associata (classe ServentePerDelega).

E’ a cura del programmatore la predisposizione del meccanismo di delega tra la classe InterfaceNamePOATie e la classe servente.

Realizzazione della classe servente per delega

  1. Creazione di un’istanza della classe servente.
  2. Creazione di un’istanza della classe tie, InterfaceNamePOAtie, alla quale si fornisce il riferimento all’oggetto delegato.

ServentePerDelega oggettoDelegato = new ServentePerDelega(..);

InterfaceNamePOATie servizioA_servant = new InterfaceNamePOATie(oggettoDelegato);

Esempi di realizzazione della classe servente

Operazione IDL con parametro formale di ingresso e di tipo semplice.

Operazione IDL con parametro formale di ingresso-uscita e di tipo definito dall’utente.

Operazione IDL con tipo di ritorno definito dall’utente.

Operazione IDL con eccezione definita dall’utente.

Operazione IDL con valore di ritorno di tipo any.

Operazione IDL con parametro formale di ingresso e di tipo semplice

//IDL
interface ServizioA {
void operazione(in string);
};

Le classi generate dal compilatore necessarie per la realizzazione della classe servente consistono della sola classe ServizioAPOA (classe skeleton).

//classe servente per il servizioA
public class servizioAImpl extends ServizioAPOA {

public void operazione(String parametro) {

//utilizzo del parametro ricevuto
...

}

}

Operazione IDL con parametro formale di ingresso-uscita e di tipo definito dall’utente

interface ServizioC {
struct StrutturaEsempio{
string campo1;
float campo2;
};
void operazione(inout StrutturaEsempio st);
};

Le classi generate dal compilatore necessarie per la realizzazione della classe servente:

  • ServizioCPOA;
  • StrutturaEsempio (classe rappresentazione della struct IDL);
  • StrutturaEsempioHolder (contenitore per la struct).

Operazione IDL con parametro formale di ingresso-uscita e di tipo definito dall’utente

Al fine di realizzare una sorta di scambio per riferimento, il programmatore dovrà utilizzare la classeStrutturaEsempioHolder.

La classe Holder svolge la funzione di contenitore dell’oggetto parametro di scambio.

Le classi Holder per i tipi definiti dall’utente sono generate dal compilatore IDL

Tutte le classi Holder per i tipi primitivi IDL sono definite nel package org.omg.CORBA.

Mostra codice

Operazione IDL con tipo di ritorno definito dall’utente

//IDL
interface ServizioD{
struct StrutturaEsempio{
string campo1;
float campo2;
};
StrutturaEsempio operazione();
};

Le classi generate dal compilatore necessarie per la realizzazione della classe servente:

  • ServizioDPOA;
  • StrutturaEsempio (classe rappresentazione della struct IDL).
Mostra codice

Operazione IDL con eccezione definita dall’utente

Mostra codice

Come si può osservare, la creazione di un'eccezione da inoltrare ad un'applicazione remota, è del tutto analoga al caso in cui si sollevi un'eccezione locale alla classe servente.

Operazione IDL con valore di ritorno di tipo valuetype

//IDL
module modulo{

valuetype OggettoPassatoPerValore{

string metodo();

public string attributo;

};

interface ServizioF {

OggettoPassatoPerValore operazione() ;

};

};

Le classi e le interfacce generate dal compilatore necessarie per la realizzazione della classe servente sono:

  • ServizioFPOA;
  • OggettoPassatoPerValore (rappresentazione del valuetype).

Operazione IDL con valore di ritorno di tipo valuetype

package modulo;
//Esempio di implementazione della classe OggettoImpl
public class OggettoImpl extends OggettoPassatoPerValore {
//costruttore
public OggettoImpl(String attributo) {
this.attributo=attributo;
}
public String metodo() {
//ad esempio...
return attributo; }
}

Il programmatore della classe servente dovrà, in questo caso, fornire anche un’implementazione della classe relativa al tipo restituito dal metodo operazione().

Tale classe, denominata OggettoImpl , sarà un’estensione della classe astrattaOggettoPassatoPerValore, fornita dal compilatore IDL.

Mostra codice

Operazione IDL con valore di ritorno di tipo any

//IDL
interface ServizioG {
any operazione() ;
};

Per la realizzazione della classe servente è necessaria la sola classeServizioGPOA.

La creazione di un’istanza di un tipo Any è affidata ad un oggetto di piattaforma, nella fattispecie all’oggetto org.omg.CORBA.ORB.

La classe servente dovrà pertanto possedere un riferimento a tale oggetto, in genere fornito dall’applicazione servente attraverso il costruttore.

Mostra codice

Skeleton

Lo skeleton costituisce una vista astratta dell’oggetto servente.

Esso è in grado di ricevere una richiesta di invocazione di un metodo per l’oggetto servente incapsulato e di estrarre dalla richiesta i parametri necessari per realizzare l’up-call sull’oggetto incapsulato,

La richiesta di esecuzione di un metodo su un oggetto remoto è contenuta in apposito oggetto di piattaforma, denominatoServerRequest.

Gli skeleton possono essere quindi realizzati in due modi distinti:

  • mediante estensione della classeDynamicImplementation (skeleton dinamici);
  • come implementazione dell’interfacciaInvokeHandler (skeleton statici).

Skeleton

Negli skeleton dinamici

L’oggettoSeverRequest contiene tutte le informazioni necessarie per effettuare l’upcall sull’oggetto servente, consistenti del nome del metodo e della lista dei parametri effettivi.

Grazie a tale oggetto la gestione di una richiesta può essere effettuata anche dinamicamente, cioè senza alcuna conoscenza della firma del metodo da invocare.

Gli skeleton dinamici espletano il loro compito utilizzando i meccanismi noti in letteratura come Dynamic Skeleton Interface.

Skeleton

Negli skeleton statici l’interazione con l’oggettoSeverRequest avviene mediante tre parametri:

  • il primo parametro indica il nome del metodo da invocare;
  • il secondo parametro, di tipoInputStream, è un contenitore per i valori dei parametri effettivi;
  • il terzo parametro, di tipoResponseHandler, è un supporto per la restituzione dei risultati.

Occorre osservare che i tre parametri, forniti non permettono la gestione della richiesta in maniera dinamica.

E’ necessario, infatti, analizzare l’interfaccia IDL e pertanto tali parametri sono direttamente codificati, dal compilatore IDL, dentro lo stub statico.

org.omg.PortableServer.Servant

E’ una classe che rappresenta un’astrazione di tutti gli oggetti serventi.

Un oggetto servente è anche istanza della classeServant.

org.omg.PortableServer.Servant

L’oggetto risultante dall’istanziazione di una classe servente è pertanto idoneo a:

  1. essere gestito come entità incapsulante un oggetto CORBA (ruolo “Servant”);
  2. accettare le richieste di invocazione di un metodo remoto (ruolo “skeleton”);
  3. eseguire il metodo (ruolo “servente”) .

  • 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