Ingo Rammer è l’autore di "Advanced .NET Remoting" e "Advanced .NET Remoting in VB.NET", ritenuti indispensabili da qualunque programmatore Remoting. Ingo vive a Vienna, in Austria, e si occupa di sviluppo, formazione e consulenza. Lavora per varie compagnie nel campo delle telecomunicazioni e dell’industria software. Il suo interesse è rivolto in particolare all’architettura delle applicazioni .NET. Può essere contatto tramite il suo Web site http://www.ingorammer.com, dove mantiene il weblog e una raccolta di risorse utili per il programmatore.

R: Ho iniziato a prendere confidenza con .NET quando ancora si chiamava NGWS (Next Generation Windows Services) – penso che fosse un po’ prima della beta 1. In realtà non ho subito intuito le straordinarie funzionalità di Remoting. Fino a quando non ho partecipato ad una conferenza per sviluppatori in Germania. In una sessione si parlava del modello di estendibilità di Remoting e fu proprio in quel momento che decisi di scrivere un libro: quella tecnologia era esattamente quello che volevo avere dai tempi di DCOM e di Java RMI. Quindi potremmo dire che ho capito le più importanti caratteristiche di Remoting e le sue potenzialità in circa 5 minuti ad una conferenza ;-)

R: È una storia divertente. Subito dopo la sessione appena citata, Dan Appleman tenne un’altra sessione su Remoting. Arrivato alle conclusioni disse "bene, come ho già detto, non c’è una documentazione su Remoting e, come probabilmente sapete, sono uno dei fondatori di una casa editrice. Quindi se qualcuno di voi volesse scrivere un libro su questo argomento..." – a quel punto sono balzato in piedi – nel bel mezzo del discorso – ho alzato la mano e ho promesso davanti a tutti che lo avrei fatto io! Abbiamo firmato il contratto sette giorni dopo.

R: Capovolta di 180 gradi. Adesso viaggio moltissimo per lavoro, e sono invitato a parlare a conferenze ed eventi in molte nazioni.

R: Oh, grazie mille per le belle parole! Ho aperto quella pagina per metterci le mie impressioni mentre stavo lavorando (in segreto) al libro. Volevo rendere disponibili alcuni esempi e spezzoni di codice alla comunità di sviluppatori. Allo stesso tempo partecipavo ai newsgroup Microsoft per capire i problemi degli altri sviluppatori su Remoting , in modo da poterli trattare in dettaglio nel libro. Penso che la partecipazione ai newsgroup e dotnetremoting.cc abbiano contribuito ad innalzare la qualità dei contenuti.

R: La sua architettura a livelli (layer) facilmente estendibile. Permette la creazione di componenti riusabili quando sono combinati con custom attribute e Reflection. [vedere l’articolo di Sabbadin su questo speciale, NdA]

R: Penso che manchi un qualche supporto da parte di Visual Studio. Ad esempio, per adesso ognuno deve scriversi a mano i file di configurazione.

R: Essenzialmente c’è la modifica alla politica di sicurezza durante la serializzazione: per passare un oggetto per riferimento o passare i membri privati di un oggetto, bisogna specificare un flag nel file di configurazione, altrimenti sarà sollevata un’eccezione. Una buona cosa, peccato che probabilmente impedirà ad alcune applicazioni scritte per il framework 1.0 di funzionare – quindi non dimenticate di aggiornare il file di configurazione.

R: In realtà non è un workaround, Remoting semplicemente usa il supporto per la sicurezza offerto dal protocollo di trasporto sottostante. Ed è un ottima scelta di progettazione – e lo stesso vale per i Web service. In ogni caso è disponibile una implementazione per la sicurezza per TcpChannel su MSDN.

R: In realtà, molti programmatori Java sconsigliano di usare gli EJB session beans per il loro impatto negativo sulle prestazioni. Conosco un po’ di siti Java ad alto traffico che hanno rimosso gli EJB dopo alcuni test sulle performance.

E poi credo sia meglio e più semplice "scalare il prima possibile" – che in .NET significa scalare il layer ASP.NET insieme alla logica business in proc. Tenete presente che la l’ASP.NET session state è nettamente superiore a quello del vecchio ASP.

R: Avere esperienza con DCOM, CORBA o RMI può sicuramente aiutare – in fondo stiamo parlando comunque di applicazioni distribuite. Non credo che conoscere EJB sia di grande aiuto perchè EJB è in pratica solo un service layer, mentre Remoting è un communication layer (come RMI or IIOP che è usato dagli EJBs). Apparte questo, è sempre più semplice imparare una nuova tecnologia quando la puoi confrontare con una più vecchia. In questo modo puoi porti delle domande del tipo"Come risolve Remoting questo o quel problema che avevo con DCOM?".

R: Ho iniziato la mia carriera – non ridete – con Perl su Linux nel 1995. Circa un anno dopo sono passato a VB5 e VB6 che ho usato per cinque anni. Ho anche lavorato con Java un paio di anni prima dell’avvento di .NET. Ho utilizzato i rispettivi protocolli per distribuire le applicazioni (DCOM e RMI) e ho lavorato con molte tecnologie server back-end Microsoft (SQL Server, MSMQ, Exchange).

R: Dipende, come sempre. Ma credo che per questo tipo di applicazioni sia meglio usare i socket perché – almeno con i canali TcpCannel e HttpChannel predefiniti – non c’è supporto per la comunicazione bidirezionale su un’unica connessione. Remoting richiederebbe sempre un'altra connessione nel senso contrario tra server e client, e questo non è sempre possibile con firewall, proxy e NAT in mezzo.

R: Don è un mio caro amico e penso che quello che intenda dire sia che .NET Remoting non dovrebbe essere usato come backend per i Web service – nonostante la presenza di un SoapFormatter. Ed in questo sono assolutamente d’accordo. Per i Web service bisogna prendere la strada di ASP.NET + WSE 1.0. Sempre.

Penso poi che si debba considerare come saranno usate le applicazioni: Remoting è la scelta ideale se .NET è sia sul client che sul server, su una LAN od una corporate WAN, ed entrambi i lati sono sviluppati nella stessa società.

Se invece bisogna integrare piattaforme differenti, di differenti società, in diverse trust zone, Remoting non sarebbe di grande aiuto. Non penso ad esempio che vedremo molte delle specifiche WS-* (GXA) implementate nello stack di Remoting.

R: Spero di no. È comunque responsabilità del programmatore gestire gli oggetti di IIS con la sicurezza HTTP. Remoting da molte possibilità – ma anche ulteriori responsabilità. Tutti i programmatori dovrebbero prendersi cura di questi aspetti.

R: Dato che passo praticamente metà del mio tempo a viaggiare, ci sono due versioni di "giornata alla Ingo Rammer": in viaggio e a casa.

Con "in viaggio" intendo quando devo fornire qualche servizio (consulenza o sviluppo) ad un cliente o parlare ad una conferenza. Questo significa stare in un hotel – con tutti i vantaggi e svantaggi conseguenti. Quei giorni sono particolarmente intensi: alzarsi presto, lavorare dai clienti, tornare in hotel, lavorare su qualche articolo o esempio fino a tarda notte.

Quando sono a casa invece è la situazione è meno stressante. Mi alzo verso le 8, leggo le email, i weblog e gli articoli fin verso le 9-10. Poi faccio colazione con la mia fidanzata Katja. Dopo torno a lavoro, il che significa armeggiare con qualche nuova tecnologia, scrivere articoli, preparare qualche sessione di conferenza o sviluppare realmente qualcosa. Cerco sempre di concentrare il mio lavoro in modo da finire verso le 8 di sera, ma di solito non finisco prima di mezzanotte ;-)

R: Scartando lo spam (circa 30 messaggi al giorno) e le mailing list (circa 400 - 500 al giorno), ricevo 20-30 email. Il più delle volte riesco a rispondere, ma non sempre sono in grado di farlo subito. Soprattutto dopo le conferenze, quando non ho controllato la mailbox per sette giorni e mi ritrovo con qualche centinaio di email non risposte!

R: Certamente! Sono stato parecchie volte in vacanza e anche per fare una conferenza su Remoting all’Università di Milano nel giugno 2002. Non vedo l’ora di tornare. Posso confessare una cosa? Ho bevuto caffè in circa 20 nazioni, ma nessuno fa l’espresso così buono come gli italiani!

R: Ecco alcune semplici regole. Non usate SoapSuds. Definite un’interfaccia e accedere ai componenti remoti tramite quella. Se avete bisogno del 100% di scalabilità, usate oggetti SingleCall SAO ed evitate oggetti CAO e gli eventi. Fate girare i componenti remoti in IIS e configurateli affinchè usino il binary formatter. [vedi anche www.ingorammer.com/Articles/REMOTINGVS.ASP.NETWEBSERV.html, NdA] Questa configurazione garantisce una buona soluzione in termini di sicurezza, prestazioni e scalabilità.

Questo articolo è tratto dalla rivista Visual Basic& .NET Journal n.51 (Maggio\Giugno 2003)

Copyright Gruppo Editoriale Infomedia (http://www.infomedia.it)