Una tecnica comune per ridurre il numero di chiamate di rete e quello di raggruppare più chiamate ad un metodo in un'unica chiamata. (batching o boxcarring).
DCOM usa molto questa tecnica per chiamate come, richieste di connessione, creazione di un nuovo oggetto, il browse delle proprietà di un oggetto. L' inconveniente di questa tecnica è che il modello di programmazione cambia notevolmente tra connessioni remote e locali, in pratica si avranno due programmi diversi da manutenere e debuggare.
Un esempio reale 1.1
Supponiamo di avere un componente che consente l'accesso ad un database, e restituisce i dati riga per riga o in un subset di righe per ogni chiamata.
In caso di accesso locale lo sviluppatore del client, può semplicemente usare questi metodi per inserire le righe in una listbox una ad una in base all'ampietta della listbox.
In caso di accesso remoto, questo approccio incorre in un elevato traffico di rete, poichè viene eseguita una chiamata per ogni riga interrogata.
Usare i metodi di questo componente in modo batch richiede che lo sviluppatore dimensioni un buffer largo quanto tutte le righe che vuole visualizzare, e richiederle tutte in una sola chiamata, per poi inserirle una ad una nella listbox. Poichè così facendo come abbiamo visto il modello di programmazione è cambiato, lo sviluppatore deve scendere ad un compromesso, perdendo la semplicità del codice per permettere all'applicazione di lavorare efficentemente in un ambiente distribuito.
DCOM rende tutto questo più facile per lo sviluppatore, permettendogli di sviluppare un sistema batch senza che il client debba implementare dei modelli di programmazione di batching.
Infatti DCOM intruduce un meccanismo che permette di iniettare del codice nel client, questo meccanismo è identificato dal proxy object, che può intercettare più chiamate ad un metodo e raggrupparle tutte in una singola chiamata a procedura remota.
Un esempio reale
Lo sviluppatore dell'esempio precedente 1.1, continua a chiamare i metodi per la richiesta delle righe database una ad una, come richiesto dalla logica dell'applicazione.
Così la prima chiamata arriva arriva allo specifico oggetto proxy, che richiede al componente tutte le righe o un subset di queste, e le raccoglie in una cache nell' oggetto proxy. Le chiamate successive vengono eseguite prelevando i dati da questa cache, senza ulteriori chiamate di rete.
Lo sviluppatore lato client, continuerà così ad adottare un semplice modello di programmazione sia che il componente sia locale o remoto, e l'applicazione risulterà ottimizzata per entrambi i casi.
|
|
|
|
|
| Interpretazione OPC
|
|
|
|