Copyright © 1997 Università di Firenze. All rights reserved.

license available.

slide 1/10

OLE 2, come abbiamo già visto nella prima parte, è un termine generico con cui si indicano diverse tecnologie tutte costruite sopra il modello COM. Di fatto, ognuna di queste tecnologie è semplicemente costituita da un insieme di interfacce che un oggetto deve implementare.

Per esempio, un oggetto COM è un OLE Control se supporta determinate interfacce predefinite, denominate IOleControl, IOleObject, IPersistStorage etc.
Un programma che vuole utilizzare un determinato Controllo OLE, quindi, si aspetterà che questo implementi esattamente tutte le funzioni definite nelle interfacce che ogni oggetto di tale tipo deve necessariamente implementare.

E' per questo motivo che tutto funziona correttamente: poichè la struttura di queste interfacce è nota a priori, ogni programma che vuole sfruttare una tecnologia OLE è in grado di conoscere in anticipo ciò che i vari oggetti COM sono in grado di fare per esso.
 

Esaminiamo ora brevemente le principali tecnologie legate a OLE 2:
 
 

• Uniform Data Transfer (UDT) è il nome con cui si indica la tecnologia OLE che permette di effettuare lo scambio di dati tra applicazioni. Nell'era "pre-COM", i meccanismi comunemente utilizzati per il trasferimento di dati tra applicazioni erano la Clipboard ("Cartella Appunti") e il già citato DDE (Dymamic Data Exchange). Il problema principale legato a questi due meccanismi era dato dal fatto che, nel primo caso, il trasferimento dei dati veniva sempre effettuato tramite memoria globale, con un conseguente degrado di prestazioni, mentre nel secondo caso, come già visto, vi era anche la non universale applicabilità. UDT offre invece un metodo di condivisione di dati più flessibile e generale, ma ancora compatibile con la Clipboard, in cui un data producer ha a disposizione delle funzioni per trasferire informazioni ad un data consumer, che ha il compito di prelevarle. Inoltre, una caratteristica molto comoda di UDT è la possibilità di trasferire dati con il mouse, tramite una semplice operazione di drag-and-drop ("trascina e rilascia").

• La tecnologia degli OLE Document è quella, come abbiamo già visto nell'evoluzione storica, che ha provocato inizialmente la nascita di OLE. Un OLE Compound Document è un documento composto che contiene al suo interno dati di vario tipo, i quali possono essere linked (nel caso si trovino in un file separato) o embedded (nel caso si trovino nello stesso file). Mentre un 'linked document' può essere editato dall'utente solo in una sua 'finestra' separata, richiamando l'applicazione che lo può gestire ed eventualmente aggiornando automaticamente le modifiche nel documento composto che lo contiene, un 'embedded document' offre anche la possibilità di essere attivato in-place, tramite il cosiddetto visual-editing. Questo significa ad esempio che, facendo doppio click su un'immagine contenuta all'interno di un documento di Word non si aprirà un'altra applicazione (come accadeva con la prima versione di OLE), ma sarà possibile modificare l'immagine direttamente all'interno di Word. Sembra quasi che l'applicazione Container o Contenitore (client) si "trasformi" per aggiungere alle sue normali funzionalità quelle fornita dall'applicazione server che è in grado di gestire l'oggetto contenuto. E il tutto può avvenire grazie ad un insieme di interfacce COM implementate rispettivamente dalle due applicazioni.

• OLE Automation è una tecnologia che permette ad un oggetto COM di rendersi "programmabile" da altre applicazioni. Per esempio, è possibile da un'applicazione esterna gestire un documento Word, aprendolo, modificandolo e salvandolo! OLE Automation, quindi, permette effettivamente quell'auspicata riusabilità del software a livello binario. Ma questo non è proprio ciò che viene permesso dal modello COM in generale, grazie al meccanismo delle interfacce? Certamente, ma esiste una sottile differenza: un'interfaccia è composta da un insieme prefissato di funzioni; è possibile creare un oggetto COM per implementare una nuova interfaccia, ma questo oggetto risulterebbe di fatto inutile, poichè nessuna applicazione sarebbe a conoscenza dell'esistenza di questa determinata interfaccia e quindi in grado di sfruttare i metodi in essa contenuti. OLE Automation invece, come suggerisce anche il termine, è un meccanismo dinamico. Un oggetto che implementa tale tecnologia è in grado di "rispondere" proprio a domande di questo tipo: "Quante funzioni e quante proprietà mi offri? Come si chiamano? Di che tipo sono e che parametri hanno?". Un programma che utilizzi un oggetto di questo tipo è quindi in grado di richiamare qualsiasi funzione messa a disposizione dall'oggetto stesso, anche senza conoscerne a priori l'esistenza. OLE Automation è alla base degli OLE Control.

• Gli OLE Control costituiscono il "fiore all'occhiello" di OLE. Si tratta di control ("comandi") personalizzati che possono essere utilizzati per aggiungere, in modo molto semplice, funzionalità anche complesse a qualsiasi applicazione. Esistono, ad esempio, Controlli che incapsulano un calendario, un foglio elettronico, o addirittura un intero elaboratore di testi. La tecnologia che consente ad un OLE Control di funzionare correttamente è pero molto complessa: secondo la loro specifica (OLE Control Specification), ci sono decine di interfacce che devono essere implementate dal Controllo e dall'applicazione Contenitore perchè il tutto funzioni correttamente.

Implementare un'applicazione che sfrutti una qualsiasi delle tecnologie OLE è quindi molto difficile, poichè occorre spesso scrivere centinaia di righe di codice per definire ogni funzione di ciascuna delle numerose interfacce necessarie.
Il vantaggio però è che l'implementazione di molte di queste interfacce risulta del tutto identica all'interno di ciascuna applicazione.
Per questo motivo, i vari strumenti di sviluppo disponibili, come Visual C++, Visual Basic o Delphi, mettono a disposizione librerie di classi che implementano già tutte queste interfacce, semplificando notevolmente al programmatore la costruzione di applicazioni OLE.

ActiveX

slide 2/10

 

ActiveX, ultima nata tra le tecnologie basate sul modello COM, è invece esplicitamente orientata verso il mondo Internet, introducendo un insieme di nuove caratteristiche che in alcuni casi sostituiscono o integrano tecnologie precedenti, allo scopo di renderle più adatte ad un utilizzo sulla 'Rete delle reti'.
 
Lo scopo principale di ActiveX è quello, come suggerisce il termine stesso, di rendere "attive" le pagine Web, obbiettivo che in un certo senso la accomuna e la contrappone allo stesso tempo agli applet Java (come vedremo più avanti).

Le normali pagine Html infatti presentano agli utenti delle informazioni statiche, mentre uno dei pregi principali delle tecnologie ActiveX è proprio quello di introdurre una componente dinamica all'interno delle pagine Web, in modo che l'utente possa interagire con esse ed eseguire delle elaborazioni locali.

I primi a beneficiare delle funzionalità di ActiveX sono quindi - non a caso - i programmatori e gli sviluppatori Web intenzionati a migliorare i loro siti WWW con animazioni multimediali, immagini generate dinamicamente, o con qualsiasi altra componente applicativa già familiare agli utenti del desktop di Windows^®.
 

In questo contesto, ActiveX fornisce due strumenti principali per estendere le potenzialità di Internet:
 

• I Documenti ActiveX, che rappresentano una seconda versione dei normali documenti composti di OLE.

 
• I Controlli ActiveX (detti OCX, acronimo di OLE Control eXtension), che possono essere considerati un'estensione 'semplificata' degli OLE Control.

Documenti ActiveX

Un Documento ActiveX è un documento OLE che può essere contenuto all'interno di un browser (ad esempio, un documento Word visualizzato all'interno di Ms-Internet Explorer versione 3.00 o successiva).
La differenza tra i due tipi di documenti, dal punto di vista del programmatore, è minima: si tratta semplicemente di alcune interfacce aggiuntive che devono essere implementate da parte dell'applicazione Doc-Server (in questo caso Word).

Dal punto di vista dell'utente, però, la differenza è notevole.
Grazie ai documenti ActiveX, infatti, diventa possibile utilizzare un browser Internet per visualizzare e gestire file di qualsiasi tipo. Il browser, una volta ottenuto un documento di un certo tipo, si comporta come un normale Contenitore OLE e si mette alla ricerca di un server in grado di gestire quel documento. Dopo averlo trovato, gli cede l'intera area client, offrendo all'utente la possibilità di gestire il documento sfruttando tutte le potenzialità del server.

Controlli ActiveX

In definitiva comunque, dal punto di vista tecnologico ActiveX non aggiunge molto a OLE: qualche interfaccia in più, e una maggiore attenzione rivolta alle problematiche relative al trasporto di componenti software su una rete globale di computer.

Quest'ultimo motivo, insieme all'eccessiva complessità e rigidità della specifica originale dei Controlli OLE, secondo la quale ogni oggetto COM presentava, come già accennato, anche troppa ricchezza di interfacce verso il suo Contenitore, ha portato alla definizione di una nuova specifica più "elastica" ed efficiente, rappresentata appunto dai Controlli ActiveX (OCX).

La principale differenza tra i "vecchi" OLE Control e i "nuovi" Controlli ActiveX è data infatti dal minor numero di interfacce che devono essere obbligatoriamente implementate dal Controllo.
In pratica, al Controllo vengono date meno responsabilità, permettendogli di essere più "leggero", mentre al Contenitore viene richiesto di essere più "intelligente", in quanto deve essere responsabile della gestione di Controlli che sono in grado di svolgere meno compiti dei loro predecessori.

Attualmente un oggetto COM, per essere considerato un Controllo ActiveX, deve supportare la sola interfaccia-base IUnknown ed essere "autoregistrante", cioè capace di inserire le proprie entries nel registro di sistema (piccola differenza con un oggetto COM standard, ma utile proprietà nei collegamenti in rete).

I Controlli ActiveX sono dunque dei componenti software di ridotte dimensioni, adatti ad essere prelevati attraverso Internet e ad essere utilizzati all'interno di pagine Web, sfruttando un qualsiasi browser ActiveX-compatibile.
 

Come vedremo nel caso specifico dell'ActiveMovie, tutto ciò che si basa sulla tecnologia COM è "modulare", nel senso che le applicazioni software possono essere "costruite" tramite l'opportuno assemblaggio di oggetti precostituiti e l'implementazione delle relative interfacce.

slide 3/10

Le Interfacce Standard

slide 4/10

 
 
Tale modalità comune prevede la specifica di un insieme di Interfacce Standard per tutti gli oggetti COM (vedi slide precedente) ed una serie di norme per la creazione dei Control Containers (Contenitori di Controlli) per garantire l'interazione effettiva tra client e server.
 

 
 
 
 
Il Control Container

slide 5/10

 
 
Questi Contenitori di Controlli - di solito realizzati in Visual Basic - sono dei client "intelligenti", nel senso che sanno perfettamente gestire un determinato Controllo ActiveX, comunicando e interagendo con esso (vedi slide precedente).

Esempio di Contenitore di Controlli

slide 6/10

 
 
Un tipico esempio di Contenitore di Controlli è lo stesso browser della Microsoft, il già citato Internet Explorer 3.0x, che può 'richiamare' i Controlli ActiveX al momento opportuno e rendere così "attive" le pagine Web nei confronti dell'utente che le visualizza, anche se il codice di un Controllo può trovarsi sul Server Web ed essere scaricato - in modo trasparente all'utente - solo quando deve essere eseguito (es. gli applet Java, gestiti come oggetti COM).
 

Un vantaggio che i Controlli ActiveX possono però vantare rispetto agli applet Java è dato dall'enorme numero di OCX attualmente esistenti e disponibili; questi Controlli possono facilmente essere riutilizzati sul Web, e la loro quantità e qualità sono tali da poter soddisfare le esigenze di chiunque voglia progettare una pagina Web interattiva.

Il grande svantaggio invece dei Controlli ActiveX è dato dalla loro mancanza di portabilità: essi, a differenza degli applet Java che possono girare - grazie alla JVM (Java Virtual Machine) - potenzialmente su qualsiasi piattaforma, sono programmi compilati che possono funzionare solo sui sistemi operativi che li supportano.

Tecnologicamente, inoltre, si tratta di due cose del tutto diverse: Java è un linguaggio di programmazione ad oggetti adatto allo sviluppo di applicativi per il Web, mentre ActiveX è una tecnologia che permette a più applicazioni di collaborare tra loro, anche attraverso Internet.
 

Concludendo, possiamo affermare che, "dal punto di vista strategico, ActiveX rappresenta un gran risultato; grazie a questa tecnologia infatti, Microsoft riesce ad "assorbire" Internet all'interno delle proprie strategie di sviluppo e di vendita senza rivoluzionare nulla anzi, fornendo un valore aggiunto alle sue soluzioni preesistenti." (L. Vandoni)
Questo "assorbimento" però, se venisse completato con successo, farebbe perdere ad Internet una delle sue caratteristiche peculiari: l'indipendenza dal sistema operativo.

I componenti di ActiveX non possiedono infatti al loro interno tutto ciò di cui necessitano per poter funzionare correttamente in ogni ambiente. Un documento ActiveX per poter essere gestito richiede, come abbiamo già detto, la presenza di un server. Un Controllo ActiveX per poter funzionare richiede, come minimo, la presenza di un sistema ActiveX-compatibile (come Ms-Windows^®), se non quella di una o più librerie dinamiche (DLL).

Una rete Internet che permetta di sfruttare questa tecnologia è quindi un sistema i cui nodi siano dei Personal Computer, una rete dunque molto simile a quella attuale e piuttosto diversa da quella, prevista da alcuni, i cui nodi saranno costituiti invece da Network Computer, telefoni cellulari o addirittura televisori.

ActiveX attualmente è supportato pienamente solo da Ms-Internet Explorer; Netscape lo supporta solamente attraverso dei plug-in (una sorta di "estensioni installate" nel browser per estendere le sue funzionalità). Inoltre, i tipi di documenti standard che possono essere gestiti sono in pratica i documenti delle applicazioni di Ms-Office (Word, Excel, PowerPoint etc.). 

 

slide 7/10

Anche se, in base alla nuova specifica, un Controllo ActiveX deve rispettare specifiche meno "esigenti", vi è comunque la necessità di informare un Contenitore sulle capacità e sui requisiti della "componente" da esso richiesta, magari evitando di utilizzare come identificatori semplici stringhe di testo inserite nel registro.

Attualmente, un Contenitore può conoscere tutte le funzionalità di un Controllo ActiveX (o di un qualsiasi altro Oggetto COM) tramite le cosiddette Categorie Componenti, universalmente identificate da particolari stringhe GUID del registro di sistema chiamate appunto CATID (Identificatori di Categoria), senza che sia necessaria l'istanziazione dell'oggetto stesso.

Una categoria componente definisce una specifica area di funzionalità, un sottoinsieme di metodi o anche la modalità d'uso di una o più interfacce supportate dall'oggetto; di conseguenza, potendo un singolo Controllo supportare diverse interfacce con modalità differenti, ad esso potranno corrispondere diversi CATID.

Tali categorie componenti non sono però di solito relazionate (ereditarietà) o ordinate (gerarchia) in alcun modo tra loro.
 

Anche per il caso, viceversa, che sia il Controllo a richiedere certe caratteristiche al suo Contenitore - in modo così da evitare un'inutile istanziazione o un utilizzo non corretto dell'oggetto stesso - esistono appositi CATID nel System Registry.

Va infine evidenziata la differenza tra i CLSID (Class Identifier) e i CATID che, pur essendo entrambi GUID (Global Unique Identifier), indicano rispettivamente una particolare implementazione di un oggetto COM (come istanza di una specifica classe) e alcune sue funzionalità (metodi nelle interfacce) le quali possono essere implementate differentemente per due oggetti con diversi CLSID, dando anche luogo allo stesso CATID.

L'archittura ActiveMovie

Per concludere la trattazione sulle tecnologie COM-ActiveX, accenniamo brevemente ad ActiveMovie.

ActiveMovie è una architettura modulare della famiglia COM-ActiveX, sviluppata con lo specifico scopo di controllare e processare flussi (stream) di dati multimediali tempo-correlati.
In particolare permette, tramite funzioni "runtime" (cioè richiamabili in tempo reale durante l'esecuzione di un'applicazione), la riproduzione di suoni e immagini digitali codificati nei formati più diffusi (MPEG, AVI, DAT, MOV, MID, WAV, etc.) tramite la RUNDLL32.EXE (in Windows 95^®).
 

 

 
 
Il Filter Graph Manager ed il Filter Graph: i filtri

slide 8/10

 

L'architettura ActiveMovie si basa sull'uso dei filtri, componenti modulari connessi - tramite altri oggetti componenti detti Pin - nel Filter Graph (schema o configurazione di filtri), il quale a sua volta è gestito dal Filter Graph Manager (letteralmente: gestore del "grafo dei filtri").

Tutti questi sono oggetti COM, ai cui metodi le applicazioni possono quindi accedere direttamente solo tramite opportune interfacce, sempre però attraverso la mediazione del Filter Graph Manager (es. metodo RUN e interfaccia IMediaControl) oppure tramite un Controllo ActiveMovie ActiveX^TM(.OCX), o anche utilizzando l'MCI (Multimedia Control Interface).

 
 
 
 
Graph Editor Tool e tipi di filtri

slide 9/10

 

Nell'utilizzo del Filter Graph Manager, anche se non strettamente necessario, è comunque utile conoscere almeno i principi base dello schema dei filtri, per poterne eventualmente implementare uno proprio (visivamente con il Graph Editor Tool).

ActiveMovie è infatti, in questo senso, un'architettura "aperta e personalizzabile" in quanto si può inserire in un prefigurato schema di filtri, oppure "runtime" in un filter graph già esistente, un filtro custom appositamente implementato per un'eventuale applicazione che debba trattare i dati multimediali in un particolare modo.

Tale implementazione può essere fatta, ad esempio, in linguaggio C++, sfruttando delle librerie di classi base che facilitano lo sviluppo delle interfacce degli oggetti in tal modo creati.
 

I diversi tipi di filtri sono in definitiva classificabili in tre categorie fondamentali:
 

Filtri sorgente (Source Filters),

che prelevano il flusso dei dati multimediali da una certa sorgente per introdurli nel filter graph.

Filtri di trasformazione o di elaborazione (Transform Filters)

che ricevono i dati da un filtro sorgente o da un altro filtro di trasformazione e li processano, per poi inoltrarli a loro volta ad altri filtri.

Filtri di resa o di presentazione (Rendering Filters)

che presentano i dati finalmente elaborati all'utente, solitamente indirizzandoli ad una periferica hardware o software di output (video, file, etc.).

Ovviamente alcuni filtri saranno dati da un'opportuna combinazione di questi tipi base.
 

 
Esempio di Filter Graph per un filmato MPEG

slide 10/10

 

 
Ad esempio, un filter graph, il cui scopo sia quello di riprodurre un file video compresso secondo lo già citato standard MPEG (Motion Picture Expert Group), farà uso dei seguenti filtri:
 

1. Un filtro sorgente, per leggere i dati multimediali dal disco.
2. Un filtro di trasformazione "splitter", per analizzare lo stream di dati e dividere i flussi MPEG audio e video.
3. Un filtro di trasformazione, per decomprimere i dati video.
4. Un filtro di trasformazione, per decomprimere i dati audio.
5. Un filtro di rendering, per visualizzare i dati video sullo schermo.
6. Un filtro di rendering, per inviare i dati audio alla scheda sonora.

E' chiaro che, affinché il filter graph lavori correttamente, i filtri devono essere collegati rispettando un ordine preciso, ordine che deve regolare anche il flusso dei dati.

E' comunque sempre il filter graph manager ad occuparsi delle connessioni tra i filtri di elaborazione e del controllo del flusso multimediale oltre ad essere in grado di ricercare, ed eventualmente implementare, lo schema di filtri più adatto ad un certo tipo di dati (a meno che il filter graph non sia già preconfigurato).

In tale ricerca il filter graph manager usa l'oggetto Filter Mapper (mappatore di filtri) per leggere il registro di sistema e determinare i filtri più adatti a processare i dati in questione, filtri che saranno scelti in base al loro "valore di merito" e, se possibile, collegati tra loro fino a raggiungere un eventuale filtro di resa per completare così lo schema.

Nel controllo del flusso sono anche inclusi i comandi start (play), pause e stop e altre funzionalità tipiche di un lettore multimediale, come la riproduzione temporizzata o la ricerca di un particolare punto nello stream di dati; tali controlli sono mediati, tramite opportuni metodi, dallo stesso filter graph manager che permette una comunicazione bidirezionale tra gli stati e gli eventi dei filtri installati e le applicazioni client.

Il gestore dei filtri, infine, dispone di interfacce (IDeferredCommand e IQueueCommand) che permettono alle applicazioni di accodare dei comandi a certi eventi o condizioni.
 

 
Bibliografia
 
 

Tutte le informazioni su COM, OLE ed ActiveX sono state tratte, per gentile concessione, dal capitolo 4 della Tesi di Laurea dell'Ing. Claudio Bottallo, dal titolo "Progetto e Realizzazione di un Video-Server MPEG con Tecnologia ActiveX", cui fanno riferimento anche i rimandi di approfondimento     .

 
 

Le SLIDE fanno parte della presentazione.ppt (opportunamente modificata e integrata con altre diapositive) relativa al seminario "Lo Standard COM e le tecnologie da esso derivate. Sviluppo di Controlli ActiveX" tenuto dall'Ing. Claudio Bottallo nel mese di Maggio 1997, durante il corso di "Tecnologie della Telematica" (Prof. F. Pirri) della Facoltà di Ingegneria Elettronica di Firenze.

 
 

Altre informazioni sono state attinte da varie fonti, tra cui:

 
 

L'articolo di Lorenzo Vandoni  "OLE, COM e ActiveX" , in particolare per le Tecnologie di OLE, i Documenti ActiveX e i Controlli ActiveX.

 
 

Il sito Internet ufficiale dell'ActiveX (www.activex.com), per quanto riguarda le Caratteristiche di COM ed ActiveX.

 
 

Il libro "Understanding ActiveX and OLE" di David Chappell, Ed. Microsoft Press, 1996, in particolar modo per la parte relativa alle Categorie Componenti e agli OLE Document.

 

---

     

---