Al termine della giornata dopo una chiaccherata con Dario, ho fatto una domanda in merito alle ottimizzazioni possibili per un dialog tra un client ed un server Indigo nello stesso appdomain.
In COM eravamo abituati bene e, quando oggetti client e server stavano all'interno dello stesso apartment godevano della notevole ottimizzazione di avere un accesso diretto, tramite puntatore, come se l'infrastruttura COM non esistesse e fosse stato allocata una normale classe C++.
Nella mia domanda ho subito premesso che questo con Indigo non è possibile by design, in quanto oggetti e servizi sono due cose molto diverse, tanto che in Indigo un metodo privato di un oggetto si può esporre in un servizio. Come ho già detto nel precedente post questo ha molto senso per me e lo condivido pienamente.
Fatto sta però che mi sarei aspettato di vedere una sorta di ottimizzazione sotto le spoglie di un binding analogo a NetTcpBinding o NetNamedPipeBinding che in maniera trasparente al client permettesse una sorta di via preferenziale e che non compromettesse le performance nell'accesso locale.
David mi ha risposto che questo è un problema che non dovrebbe essere indirizzato nella prima versione di Indigo ma che è stato ovviamente preso in considerazione dal team di Don Box. Al momento l'unica ottimizzazione, dice David, è che le comunicazioni tra processi nella stessa macchina vengono effettuate tramite named pipes invece di tcp o http e questo è già un buon passo perchè evita la notevole latenza del redirector di rete.
In conclusione la natura SOA di Indigo gli impedirà di sostituirsi a Remoting che rimmarrà vivo e vegeto a lungo.
Paradossalmente invece i WS asmx come li conosciamo oggi, saranno interamente sostituibili visto che convivono già con alcuni concetti di SOA.