Studio e Realizzazione di Architetture Concorrenti per Sistemi ad ...

Architetture Concorrenti in prodotti a larga diffusione - Confronti 35
2.4.3 Specifiche per la concorrenza
EJB non entra nel merito dell'interfaccia Container-server (il cui confine non è
neanche eccessivamente delimitato), ma si concentra particolarmente sulle
specifiche per quella Container-Bean: per questo motivo l'amministrazione delle
risorse è nascosta, ed operazioni come la gestione delle connessioni ai database,
quella della memoria e dei thread sono demandati interamente al server (dipendente
dal fornitore). Un server EJB provvede a tutta l'infrastruttura necessaria per
l'esecuzione dei Container.
In EJB non esistono, quindi, specifiche riguardanti le politiche di concorrenza da far
adottare ad un server, ma alcune limitazioni concernenti vengono esplicitamente
imposte alle implementazioni dei Bean per evitare l'insorgere di problemi di
sicurezza, di quelli tipici del multi-threading e favorire il controllo da parte dei
Container:
1. Un Container deve assicurare che al più un thread possa eseguire una data
istanza per volta: se, mentre un'implementazione è in esecuzione, giunge una
seconda richiesta, da parte di un client, sulla stessa istanza, questa deve essere
rifiutata e bisogna lanciare un'opportuna eccezione.
2. Un Bean non deve adottare le primitive di sincronizzazione di Java; in particolare
non deve mai contenere la parola chiave "synchronized". Alcuni Container
potrebbero infatti utilizzare più di una JVM (Java Virtual Machine) per eseguire
diverse istanze invalidando la sincronizzazione.
3. Un Bean non deve mai cercare di amministrare thread: non può invocare primitive
quali stop(), suspend() e resume(), né gestire priorità o gruppi di thread. Queste
funzioni sono di competenza del Container che ne deve avere il controllo assoluto
per l'appropriata gestione dell'ambiente [Bibl. 18]
2.5 Confronti
Tra i prodotti presentati, quelli più facilmente confrontabili sono DCOM e CORBA.