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 » 26.Portable Object Adapter (POA)


Il Portable Object Adapter

Definito a partire dallo standard CORBA 2.3.

Il POA ha, tra le sue responsabilità, quella di gestire il ciclo di vita degli oggetti CORBA.

Le strategie di gestione oggetti possono essere predisposte dal programmatore.

IL POA ha una struttura gerarchica.


Il Portable Object Adapter

Il rootPOA rappresenta la radice della gerarchia (struttura ad albero), dal quale si possono eventualmente creare altri POA.

Esso viene creato e gestito direttamente dall’ORB, risultando sempre disponibile a un’applicazione servente.

Il riferimento al rootPOA viene restituito dall’ORB con l’operazione resolve_initial_references (“RootPOA“)

All’interno di ogni POA, la corrispondenza oggetto CORBA – Servant viene gestita mediante un’apposita tabella, denominata Active Object Map (AOM).

Tale tabella contiene le corrispondenze tra l’identificativo dell’oggetto servente (nella forma di un Servant) e il suo object reference.

Il Portable Object Adapter

Ad ogni POA possono essere associati due oggetti:

  • il POA Manager, il quale ha le responsabilità di gestire le richieste provenienti dall’ORB destinate ai POA da esso gestiti;
  • l’Adapter Activator, che ha lo scopo di attivare il POA nel caso in cui quest’ultimo, all’arrivo di una richiesta, non sia ancora attivo.

Le politiche di un POA svolgono un ruolo importante nella definizione del comportamento del POA stesso, relativamente alla gestione degli oggetti CORBA e alle strategie di elaborazione delle richieste.

Il rootPOA possiede il proprio insieme di politiche predefinite e non modificabili.

Il programmatore lato servente può comunque predisporre uno o più POA, assegnandone i comportamenti che meglio soddisfano i requisiti dell’applicazione.

Il Portable Object Adapter

La creazione di più POA nell’ambito di un’applicazione servente può essere utile per un eventuale partizionamento dell’applicazione servente in più gruppi di oggetti serventi.

L’interfaccia PortableServer::POA fornisce i metodi per la creazione di oggetti di tipo Policy, denominati policy factories.

Gli oggettiPolicy definiti sono raccolti in un array e forniti come parametro d’ingresso al metodo create_POA(), al fine di creare un POA con le politiche prescelte.

Le politiche di un POA

Sono previste 7 politiche per la definizione del comportamento di un POA

Sono previste 7 politiche per la definizione del comportamento di un POA


Le politiche di un POA


Le politiche di un POA – Retention policy

Retention policy

Indica l’utilizzo o meno dell’AOM, per la memorizzazione delle corrispondenze object reference- oggetti serventi.

Un POA, carente di un AOM, dovrà obbligatoriamente utilizzare un Servant Locator o un Default Servant.

La politica di retention è definita mediante l’utilizzo del metodo create_servant_retention_policy() sull’oggetto POA. A tale metodo si fornisce uno dei seguenti argomenti:

  • RETAIN. Il POA memorizza tutti gli oggetti serventi, da esso gestiti, nell’AOM. In tal caso il POA opera memorizzando l’associazione object reference-object Id nell’AOM;
  • NON_RETAIN. Il POA non utilizza l’AOM. In tal caso, non essendoci alcuna corrispondenza tra object reference ed object Id, l’attivazione degli oggetti serventi viene affidata al Servant Locator oppure al Default Servant.

Le politiche di un POA – Request processing policy

Request processing policy

Indica la modalità di reperimento degli oggetti serventi per l’elaborazione delle richieste ad essi indirizzate. Qui di seguito si illustrano le quattro opzioni configurabili con la politica in oggetto:

  • l’esecuzione da parte del POA del dispacthing delle richieste solo per gli oggetti serventi il cui identificativo risiede nell’AOM;
  • l’attivazione on demand degli oggetti serventi;
  • il reperimento e l’attivazione di un oggetto servente ad ogni richiesta entrante nel POA;
  • l’affidamento delle richieste di servizio ad un default servant.

Le politiche di un POA – Request processing policy

Tale politica viene definita mediante l’invocazione sull’oggetto POA del metodo create_request_processing_policy(), al quale si fornisce uno dei seguenti argomenti:

  • USE_ACTIVE_OBJECT_MAP_ONLY (lo smistamento delle richieste avviene solo per gli oggetti serventi registrati nell’AOM);
  • USE_SERVANT_MANAGER (indica l’utilizzo di un Servant Manager, cioè di un oggetto associato al POA che ha la responsabilità di reperire l’oggetto servente, a cui è indirizzata una richiesta di servizio);
  • USE_DEFAULT_SERVANT  (le richieste destinate ad oggetti serventi non reperibili dal POA, o perché l’oggetto servente non è presente nell’AOM o perché è stata configurata la politica di NON_RETAIN, saranno destinate ad un apposito oggetto, denominato DefaultServant).

Le politiche di un POA – LifeSpan policy

Determina la persistenza degli object reference, cioè la capacità di mantenere validi gli object reference anche al di fuori del contesto dell’applicazione servente in cui gli oggetti CORBA sono stati creati

Un oggetto CORBA, caratterizzato da un object reference persistente può essere riferito da un oggetto cliente attraverso successive attivazioni del POA o successive esecuzioni dell’applicazione servente.

La politica di lifespan viene definita mediante l’utilizzo del metodo create_lifespan_policy() al quale si fornisce uno dei seguenti argomenti:

  • TRANSIENT
  • PERSISTENT

Le politiche di un POA – ID assignment policy

Indica la modalità di assegnazione dell’object Id, cioè se l’assegnazione è a carico dell’utente (USER_ID) o del POA (SYSTEM_ID).

Viene definita mediante l’utilizzo del metodo create_id_assignment_policy() al quale si fornisce uno dei seguenti argomenti:

  • SYSTEM_ID. è il POA ad avere la responsabilità di generare l’identificativo dell’oggetto servente. Tale politica è utile soprattutto per gli oggetti transienti, avendo questi ultimi un ciclo di vita minore di quello del POA in cui sono registrati.
  • USER_ID. Tale politica conferisce al programmatore la responsabilità dell’assegnazione dell’object Id. Tale politica è utile soprattutto nel caso in cui l’oggetto registrato sia persistente.

Le politiche di un POA – ID uniqueness policy

Indica la possibilità per un oggetto servente di essere associato, mediante il processo di incarnation, a più di un oggetto CORBA.

Viene definita mediante l’utilizzo del metodo create_id_uniqueness_policy(), al quale si fornisce uno dei seguenti argomenti:

  • UNIQUE_ID. Ad ogni oggetto servente è associato un identificativo univoco all’interno del POA dove è registrato
  • MULTIPLE_ID. Un medesimo oggetto servente può essere registrato in un POA con più identificativi.

Le politiche di un POA – Thread policy

Indica la tipologia di gestione dei thread adottata dal POA per l’elaborazione delle richieste provenienti dall’ORB.

Viene definita mediante l’utilizzo del metodo create_thread_policy() al quale si fornisce uno dei seguenti argomenti:

  • ORB_CTRL_MODEL. Secondo tale politica, l’ORB sarà in grado di elaborare le richieste in maniera concorrente, mediante l’utilizzo di più thread. In tal caso l’ORB sarà responsabile dell’assegnazione delle richieste ai thread;
  • SINGLE_THREAD_MODEL. Tale politica indica una modalità di elaborazione delle richieste di tipo single-threaded: cioè le richieste sono elaborate in maniera sequenziale.

Le politiche di un POA – Activation policy

Indica la modalità di attivazione di un oggetto CORBA.

Viene definita mediante l’utilizzo del metodo create_implicit_activation_policy() al quale si fornisce uno dei seguenti argomenti:

  • IMPLICIT_ACTIVATION. Indica la modalità di attivazione implicita: l’associazione (object reference, Object Id, Servant) è realizzata in un sol passo
  • NO_IMPLICIT_ACTIVATION. Indica la modalità di attivazione esplicita: viene prima realizzata l’associazione (Object Id, Servant) e, poi, quella (object reference, Object Id).

Le politiche di un POA – Activation policy

La modalità di attivazione implicita di un oggetto CORBA avviene mediante l’invocazione dei seguenti metodi:

  • org.omg.CORBA.Object _this_object();
  • org.omg.CORBA.Object servant_to_reference(Servant s).

La modalità di attivazione esplicita degli oggetti si esplica in due fasi. Nella prima fase si realizza l’associazione object Id e il Servant, mediante l’invocazione, sull’oggetto POA, di uno dei seguenti metodi:

  • byte [] activate_object(Servant p) throws ServantAlreadyActive, WrongPolicy;
  • void activate_object_with_id(byte[]id, Servant p) throws ServantAlreadyActive, ObjectAlreadyActive, WrongPolicy.

Le politiche di un POA – Activation policy

Una volta registrato l’oggetto servente nel POA, il programmatore dovrà ottenere l’object reference assegnato mediante l’invocazione di uno dei tre metodi di seguito descritti:

  • org.omg.CORBA.Object id_to_reference(byte[]) throws ObjectNoActive, WrongPolicy;
  • org.omg.CORBA.Object create_reference_with_id(byte[] oid,String intf) throws WrongPolicy;
  • org.omg.CORBA.Object _this_object().

Le politiche di un POA – Configurazione

La configurazione di un POA è, in linea generale, il risultato di una combinazione delle politiche precedentemente analizzate.

Non tutte le combinazione possibili sono valide, in quanto i valori di alcune politiche vincolano la scelta di altri:

  1. l’uso della politica di retention al valoreNON_RETAIN  richiede, per quanto riguarda la politica relativa all’elaborazione delle richieste, la configurazione dei valori USE_DEFAULT_SERVANT oppureUSE_SERVANT_MANAGER;
  2. l’uso della politica di attivazione implicita richiede che la politica di ID assignment sia configurata al valore SYSTEM_ID e la politica di retention al valoreRETAIN;
  3. l’uso della politica di request processing con il valore USE_ACTIVE_OBJECT_MAP_ONLY richiede la configurazione della politica di retention sul valore RETAIN, altrimenti le attivazioni degli oggetti sul POA non verranno memorizzate in maniera permanente sull’AOM;
  4. l’utilizzo di un Default Servant richiede la configurazione della politica di univocità degli identificativi (uniqueness policy) al valore MULTIPLE_ID, in maniera tale che molteplici oggetti CORBA possano essere associati al medesimo oggetto servente (il Default Servant).

Esempio di creazione di un POA

Mostra codice

POAManager

Ha il compito di incapsulare lo stato di elaborazione delle richieste dei POA da esso gestiti.

L’associazione di un POAManager ad un particolare POA avviene all’atto della sua creazione, proprio nel momento in cui si fornisce il POAManager come parametro d’ingresso al metodo create_POA().

Mostra codice

POAManager

Più POA possono condividere lo stesso POAManager

L’associazione di un POAManager ad un particolare POA avviene all’atto della sua creazione, proprio nel momento in cui si fornisce il POAManager come parametro d’ingresso al metodo create_POA().

Gli stati del POAManager sono quattro:

  1. Active: il POAManager, sotto il suo controllo, consegna ai POA tutte le richieste in arrivo;
  2. Holding: il POAManager accoda tutte le richieste per i POA da esso controllati, senza consegnarle;
  3. Discarding: tutte le richieste vengono scartate al momento del loro arrivo e rinviate alle applicazioni clienti;
  4. Inactive: il POAManager non è più in grado di servire richieste e non potrà più essere riattivato.

Servant Manager

E’ una classe concepita per supportare il POA nelle modalità di gestione (attivazione/disattivazione) dinamica degli oggetti serventi.

Le configurazioni possibili sono essenzialmente due e si definiscono mediante due politiche, Request Processing e Servant Retention.


Servant Manager

Il tipo ServantManager è definito in CORBA mediante un’interfaccia IDL, priva di operazioni, che funge da classe base per due diverse specializzazioni: ServantActivatorServantLocator.


ServantActivator

Attivazione
Il POA può ottenere il servente attivando il metodo incarnate() sul ServantActivator. L’associazione del servente con l’oggetto CORBA consiste nella registrazione della coppia ObjectId-Servant presso l’AOM. Realizzata l’associazione, il POA può utilizzare il servente senza l’intermediazione del ServantActivator (l’identificativo del servente è già presente nell’AOM).

Disattivazione
Durante il suo ciclo di vita un POA può ricevere delle richieste che comportano, direttamente o indirettamente, la disattivazione di oggetti CORBA da esso gestiti.

ServantActivator

L’attivazione e la disattivazione avvengono mediante l’invocazione dei metodi presenti nella interfaccia del ServantActivator.


ServantLocator

Il suo utilizzo è consigliato nei casi in cui il numero di oggetti CORBA da mantenere attivi sia troppo elevato e/o la frequenza di utilizzo sia molto bassa.

Al fine di rendere più efficiente l’utilizzo delle risorse di sistema è possibile attivare gli oggetti immediatamente prima del loro uso e disattivarli subito dopo.

L’attivazione e disattivazione sono eseguite mediante l’invocazione dei due metodi preinvoke()e postinvoke().


ServantLocator

Scenario di attivazione dinamica

Scenario di attivazione dinamica


Default Servant

E’ utile in quei casi in cui si debba implementare la classe servente in maniera tale che vi sia un unico Servant in grado di gestire le richieste per più oggetti CORBA.

Il programmatore può realizzare la classe servente secondo una tecnica che prevede la realizzazione di una classe, derivata dallo skeleton, che, come ogni classe servente, fornisce l’implementazione dei metodi definiti nell’interfaccia IDL.

All’arrivo di una richiesta, tale classe dovrà recuperare l’object Id dell’oggetto servente a cui è destinata la richiesta. A tale scopo la piattaforma fornisce un particolare oggetto, denominato Current, il quale fornisce l’Object Id contenuto nella richiesta.

Default Servant

Gli oggetti di tipo Current sono forniti dall’ORB tramite il metodo resolve_initial_references("POACurrent").

Esso è definito dalla seguente interfaccia IDL:

module PortableServer{
interface Current: CORBA::Current{

exception NoContext();
POA get_POA() raises (NoContext);
ObjectID get_object_id() raises (NoContext);

};
};

Default Servant

Un esempio di Default Servant

Mostra codice

Default Servant

Per utilizzare un DefaultServant occorre:

  • creare un POA impostando la politica Request Processing al valore USE_DEFAULT_SERVANT;
  • registrare un’istanza del DefaultServant presso il POA creato al punto precedente, tramite il metodo set_servant(Servant servant).
Mostra codice
  • 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