Studio e Realizzazione di Architetture Concorrenti per Sistemi ad ...
Studio e Realizzazione di Architetture Concorrenti per Sistemi ad ...
Studio e Realizzazione di Architetture Concorrenti per Sistemi ad ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Architetture</strong> <strong>Concorrenti</strong> in prodotti a larga <strong>di</strong>ffusione - CORBA 27<br />
1. Single Thre<strong>ad</strong>: ogni chiamata eseguita dal singolo POA ai servant deve essere<br />
processata sequenzialmente. Un POA può avere chiamate rientranti, ma<br />
l'esecuzione delle stesse non deve avvenire in maniera concorrente.<br />
2. ORB Controlled: la gestione dei thre<strong>ad</strong> è demandata totalmente<br />
all'implementazione dell'ORB.<br />
3. Main Thre<strong>ad</strong>: tutte le richieste demandate a POA che <strong>ad</strong>ottano questa politica<br />
sono eseguite sequenzialmente.<br />
La prima e l'ultima <strong>di</strong> queste politiche sono espressamente pensate <strong>per</strong><br />
salvaguardare l'esecuzione <strong>di</strong> co<strong>di</strong>ce "multi-thre<strong>ad</strong>-unaware".<br />
Le specifiche <strong>di</strong> CORBA <strong>per</strong> la concorrenza sono interamente contenute in quello<br />
che si è presentato: <strong>per</strong> avere qu<strong>ad</strong>ro più approfon<strong>di</strong>to è necessario esaminare le<br />
scelte implementative dei singoli applicativi "CORBA compliant" [Bibl. 13].<br />
2.3.4 Un esempio d'implementazione: ORBacus<br />
ORBacus è un ORB, commercializzato dalla IONA Technologies, compatibile con le<br />
specifiche CORBA in generale e che si rifà <strong>ad</strong> un modello implementativo sviluppato<br />
in C++ ed in Java (risulta quin<strong>di</strong> compatibile con i documenti "C++ Language<br />
mapping" e "IDL/Java Language mapping" <strong>di</strong> OMG).<br />
Essendo un'implementazione, fornisce maggiori specifiche <strong>per</strong> quanto riguarda il<br />
modello <strong>di</strong> concorrenza ed offre allo sviluppatore software <strong>di</strong>verse opportunità <strong>per</strong><br />
rispondere meglio alle esigenze specifiche delle applicazioni che s'intendono creare.<br />
ORBacus <strong>di</strong>vide i modelli che l'utente può <strong>ad</strong>o<strong>per</strong>are, <strong>per</strong> definire come l'ORB<br />
gestisce le comunicazioni e le richieste d'esecuzione, in due categorie principali,<br />
Single-thre<strong>ad</strong>ed e Multi-thre<strong>ad</strong>ed, e lascia l'ulteriore gr<strong>ad</strong>o <strong>di</strong> libertà <strong>di</strong> separarle <strong>per</strong><br />
le implementazioni client e <strong>per</strong> quelle sul lato server. I modelli sono Blocking,<br />
Reactive e Thre<strong>ad</strong>ed <strong>per</strong> il lato client e Reactive, Thre<strong>ad</strong>ed, Thre<strong>ad</strong>-<strong>per</strong>-Client,<br />
Thre<strong>ad</strong>-<strong>per</strong>-Request e Thre<strong>ad</strong> Pool <strong>per</strong> quello server; i para<strong>di</strong>gmi Blocking e<br />
Reactive rientrano nella categoria dei Single-thre<strong>ad</strong>ed, mentre i restanti in quella<br />
Multi-thre<strong>ad</strong>ed.<br />
La politica Blocking è la più semplice: implica che l'ORB si blocca mentre il client<br />
manda una richiesta (nel frattempo non è possibile eseguire altre o<strong>per</strong>azioni).