Il middleware DCOM per sistemi distribuiti

Il modello di cooperazione fra oggetti proposto da Microsoft è caratterizzato dall’integrazione, in un unico quadro tecnologico (si veda la figura seguente), di soluzioni per la memorizzazione dei dati, l’esecuzione di attività di back-office e la fornitura di servizi di front-office.

Gli oggetti possono essere prodotti con svariati ambienti e linguaggi di sviluppo e comunicano tra loro mediante il protocollo o middleware DCOM.

Il middleware DCOM è un’estensione dell’architettura COM (Common Object Model) attraverso la quale Microsoft realizza l’integrazione tra componenti software. I componenti Microsoft, per poter interoperare all’interno della piattaforma Windows, devono essere conformi ad una specifica a livello binario, object oriented e proprietaria della Microsoft, chiamata COM. DCOM  estende l’applicabilità della tecnologia COM, utilizzabile  solo all’interno della stessa macchina, in quanto senza richiedere modifiche ai componenti trasmette le richieste a componenti remoti su altre macchine utilizzando un sottostante protocollo di comunicazione. Bisogna notare, inoltre, che con l’uscita di Windows 2000, la differenza tra COM (protocollo di comunicazione tra oggetti sulla stessa macchina) e DCOM (protocollo di comunicazione tra oggetti remoti, semplice estensione di COM) scompare, e si ha un unico protocollo di comunicazione, completamente trasparente rispetto a componenti locali o remoti, chiamato COM+.

DCOM ha una doppia valenza; infatti esso è sia una specifica per l’interoperabilità a livello binario tra componenti software, sia un’infrastruttura software per la creazione, la comunicazione e la gestione di componenti software. Da un lato cioè specifica come devono essere codificati i componenti di una applicazione in modo da assicurarne l’interoperabilità, dall’altro è un’infrastruttura (middleware) che offre servizi per la gestione della comunicazione tra i componenti, presentandosi come un object broker. Le piattaforme supportate sono tutte quelle per le quali è previsto il funzionamento di ambienti Windows.

Il maggior  punto di forza di DCOM è il completo supporto della Microsoft, che si  traduce nella disponibilità di tool e componentware che ad oggi CORBA ancora non possiede; questo rende ad oggi più semplice e meno costoso lo sviluppo di prototipi ad oggetti distribuiti.

DCOM si presenta come una soluzione proprietaria e non adeguata ad un’architettura eterogenea; questo modello appare quindi maggiormente adatto per la realizzazione di applicazioni distribuite nell’ambito di un’unica organizzazione, piuttosto che per la comunicazione fra sistemi indipendenti. Tuttavia sono state intraprese dalla stessa Microsoft e da altri produttori di software alcune iniziative per implementare le specifiche DCOM su altre piattaforme, in particolare su sistemi UNIX e mainframe.

Il middleware DCOM implementa un concetto di ORB assai simile a quello di CORBA, ma, dal punto di vista di architetturale, appare attualmente meno efficiente, in quanto richiede un maggior numero di livelli di interazione in rete necessari per innescare lo stesso servizio.

L’Object Model

In COM/DCOM i componenti interagiscono tra loro e con l’infrastruttura attraverso insiemi di funzioni denominate interfacce; l’interfaccia determina una sorta di contratto tra il componente che la realizza ed i suoi potenziali client, e le funzioni, dette anche metodi, sono tra di loro semanticamente collegate. Un componente può implementare più interfacce, e la stessa interfaccia può essere implementata da più componenti. Una classe allora altro non è che un’implementazione di un insieme d’interfacce (definizione più pragmatica di quella classica OO in cui una classe è l’astrazione di un concetto) ed un oggetto (componente) è un’istanza di una specifica classe.

COM/DCOM non supporta l’ereditarietà ma introduce meccanismi alternativi orientati al riuso. Infatti secondo le opinioni dei progettisti Microsoft che l’ereditarietà sia impraticabile in un ambiente complesso ed eterogeneo.

Con il meccanismo del Contenimento (Figura 30) un oggetto (componente esterno) che vuole riusare il codice di un altro oggetto (componente interno) si comporta a tutti gli effetti come un client. Di fatto, il componente interno non ha alcuna percezione della differenza  tra  l’essere  invocato  all’interno  di  una  tecnica di contenimento e  l’essere invocato in una qualunque altra situazione da un normale client. In altre parole, il componente esterno implementa le proprie interfacce utilizzando le interfacce del componente interno. Il componente esterno può anche implementare nuovamente un’interfaccia supportata dal componente interno, implementando tutti i relativi metodi con una semplice invocazione dei corrispondenti metodi del componente interno. Inoltre il componente esterno può specializzare l’interfaccia aggiungendo codice prima e dopo le invocazioni ai metodi del componente interno.

L’Aggregazione, invece, è una variante del Contenimento e consiste nell’esporre direttamente ad un client le interfacce selezionate del componente aggregato facendo in modo che esse vengano percepite a tutti gli effetti come interfacce proprie del componente esterno. In tale modo, il componente esterno non è costretto a implementare nuovamente le interfacce di interesse del componente interno, inviando in modo esplicito le invocazioni al componente interno. Al contrario, il componente esterno espone direttamente l’interfaccia del componente interno come se fosse propria. I client percepiscono quell’interfaccia come un’interfaccia nativa del componente esterno e non hanno alcuna conoscenza del fatto che essa è stata “aggregata”, anche se le invocazioni dirette ai metodi di quell’interfaccia saranno in realtà gestite direttamente dal componente interno. Il vantaggio fondamentale dell’aggregazione rispetto al contenimento consiste nel fatto che il componente esterno non è costretto a implementare nuovamente un’interfaccia già supportata da un componente interno. Tuttavia, il componente esterno non è in grado di specializzare nessuna delle funzioni di quell’interfaccia.

Un esempio schematico dell’utilizzo di questi due meccanismi è il seguente. Si supponga di aver definito la classe Persona, con il metodo CalcoloReddito() e di voler definire una sottoclasse Donna; in un modello OO classico Donna sarebbe una specializzazione di Persona, ereditandone tutti i metodi ed attributi; invece in COM/DCOM si usa una delle soluzioni seguenti:

• con il Contenimento, la classe Donna, tra i suoi attributi privati, possiede un’istanza di Persona; nel codice che implementa CalcolaReddito(), ci sarà una chiamata al corrispondente metodo CalcolaReddito() dell’istanza privata di Persona (più eventualmente altre operazioni);
• con l’Aggregazione, la classe Donna aggrega Persona; in tal modo, implicitamente, ogni Donna contiene anche un’istanza di Persona (non si deve dichiarare in modo esplicito), ed ogni volta che viene invocato CalcolaReddito(), in modo trasparente questo consiste nel chiamare CalcolaReddito() sull’istanza mascherata di Persona; in questo caso però non posso aggiungere alcuna

Va notato che in un modello OO classico l’allocazione di un oggetto della classe Donna porta all’allocazione di un solo oggetto, mentre in COM/DCOM in ogni caso devo allocare due oggetti, uno della classe Donna ed uno della classe Persona.

Componenti e architetrura del middleware DCOM

In DCOM un client è una qualunque porzione di codice che, possedendo un puntatore ad un oggetto, ne invoca i metodi quando necessario.

Un server, che nella terminologia Microsoft è chiamato ActiveX, è un’opportuna struttura di programma che “circonda” una classe affinché essa sia fruibile dai suoi potenziali client.

Ogni piattaforma che supporta COM/DCOM deve fornire un’implementazione per l’infrastruttura (ORB). In ambiente Windows attualmente tale implementazione viene fornita sotto forma di libreria condivisa (DLL) che offre come servizi principali:

• funzioni per la creazione di applicazioni: per i client servizi per la creazione di componenti, per i server servizi per l’esposizione delle classi supportate;
• servizi che, partendo dall’identificatore unico di una classe, determinano quale server la realizza e dove esso risiede (implementator locator);
• meccanismi standard di controllo dell’allocazione delle

Per quanto riguarda i servizi di implementator locator per il reperimento dei server attualmente COM/DCOM prevede la memorizzazione su un registro di sistema dell’associazione tra i vari identificatori delle classi e i relativi server. La tipologia di tale registro varia in funzione dell’implementazione di COM/DCOM su di una particolare piattaforma, ma è necessario in ogni caso includere nell’associazione l’identificatore della classe e l’indicazione dei server disponibili.

In ambiente Microsoft Windows viene utilizzato il registro di configurazione e questa soluzione attualmente è uno dei punti deboli di COM/DCOM, in quanto rende complessa la riallocazione dei componenti (la difficoltà di riallocare componenti può creare problemi di diverso tipo quali la difficoltà di scalabilità del sistema distribuito) e obbliga ogni client a memorizzare nel registro della propria macchina l’indirizzo di tutti i possibili server che si prevede  utilizzerà. Successivi rilasci di DCOM dovrebbero risolvere questo problema adottando una soluzione simile a quella di CORBA, in cui l’ORB gestisce questo problema in modo del tutto trasparente per i client e in cui un server deve notificarsi solo  all’ORB e non ad ogni potenziale macchina client.

Per quanto riguarda la gestione delle chiamate ai servizi dei server, DCOM utilizza un meccanismo analogo a quello di CORBA che prevede oggetti che girano nello stesso processo del client e corrispondenti oggetti di tipo stub che girano nello stesso processo del server.