Uso creativo di MarshalByRefObject

Question

Sono stato sbattere la testa cercando di capire alcune cose. Quindi, sto cercando consigli e materiale di ricerca (tramite link). Ecco lo scenario:

Abbiamo una biblioteca (diciamo, commonlib) che contiene risorse necessarie da numerose altre applicazioni (ad esempio, AppA, AppB, APPC, e così via ...). Ora, il modo in cui questo sta lavorando è istanze Appa, controlla se la porta specifica è disponibile. Se non lo è, allora calci commonlib ( "Hey, sveglia") e il servizio viene avviato. Poi AppA è felice e si parte.

Ora, ho fatto un sacco di ricerca su Remoting.Channels e sono giunto alla conclusione che sto iniziando un programma costruito su una tecnologia che è considerato 'legacy'. Beh ... non mi piace. Onestamente, WCF è molto più luminosa di quanto abbiamo bisogno e non pienamente implementato in Mono. Ci stanno prendendo di mira la compatibilità multi-piattaforma (Windows, Mono, Linux) in modo che sta occupando tutte le opzioni.

L'idea di servizi remoti iniziato, in primo luogo, perché volevamo commonlib ad essere un'istanza singola garantita (se ho capito bene, un Singleton è praticamente garantita solo per essere un singleton all'interno di un determinato dominio di applicazione - sentitevi liberi di correggere me se sbaglio). Ad ogni modo, mi sono reso conto della potenza di servizi remoti e ha deciso di iniziare a qualche implementazione sperimentale. Ho avuto successo nel mio uso iniziale del MarshalByRefObject. Ma, io sono preoccupato per la continua implementazione di questa tecnologia legacy.

Quindi, con tutto questo ... io sto considerando come posso implementare commonlib (come applicazione host) e, senza servizi remoti, implementare MarshalByRefObject attraverso Stream, standard TCP Socket, o qualche altro modo. Quello che sto pensando è, invece di instancing AppA per ottenere commonlib in esecuzione, basta implementare commonlib come l'applicazione di base. Poi, si seleziona quello che app (in realtà solo un 'ospitato' .dll) che si desidera istanziato all'interno commonlib. Commonlib sarebbe quindi caricare DLL che nel quadro commonlib insieme a qualsiasi personalizzato controlli che hanno ospitato usi app. Insieme a questa idea, mi piacerebbe rinunciare ai requisiti (per ora) che commonlib deve essere un vero e proprio Singleton.

Quindi ... questo è un dettaglio del nostro scenario. Ancora una volta, la mia domanda è in realtà 2 parti: (a) ciò che la tecnologia (i) dovrei ricerca, e (b) ho bisogno di essere interessato con lo status retaggio della tecnologia Remoting

?

Tutti gli altri consigli, commenti o domande sono più che benvenuti.

UPDATE 1: Sto partendo con questo frammento . Questo mi permetterà di caricare un file (o uno script), con un elenco di applicazioni (o plug-in) che sono stati installati. Posso creare questo file in formato XML o in formato binario. Quando si installa una nuova applicazione, è possibile aggiungere il file e percorso. Hmmm ... Non necessariamente bisogno di usare MarshalByRefObject.

Answer 1

Mentre WCF non può essere il più completo in Mono, Mono 2.6 fornisce tutto il necessario per Silverlight / Moonlight, quindi un'implementazione WCF-based dovrebbe essere perfettamente fattibile. Finché non si tenta niente esotica (diversi tipi di trasporto, gli ispettori ecc) che dovrebbe essere più che sufficiente a fornire uno stack RPC che è certo tra le finestre / mono / etc.

La differenza fondamentale tra WCF e servizi remoti è in utilizzo - si basa comunicazione remota abbondano un oggetto che finge di essere ad un'estremità diverso, dove, come WCF si basa su un servizio; il punto è che si dovrebbe basare le interazioni intorno metodi discreti (invece di accedere alle proprietà, ecc) -. Questo ha anche il vantaggio di aiutare rendendo esplicito quando si attraversa il confine

Un'altra opzione sarebbe quella di scrivere un server socket molto di base; molto leggero, e si potrebbe usare qualcosa come protobuf-net per fornire un portatile implementazione serializzatore (cross-platform) (non si dovrebbe davvero fidate BinaryFormatter tra i due - è ... flakey).

In breve - non vorrei costruire intorno MarshalByRefObject a tutti ; Vorrei scrivere un livello di servizio, qualcosa di simile:

interface IMyService {
    void Method1();
    int Method2(string s);
}

e astratto questi dettagli dal chiamante. Se si finisce per utilizzare WCF, che poi è tutti è necessario; e per il supporto la comunicazione remota esistente vorrei scrivere un'implementazione IMyService che incapsula (privatamente) tutta la storia MarshalByRefObject. Idem se ho scritto un server socket.

Answer 2

Non sono sicuro che il .NET Remoting è reso obsoleto da WCF. Penso che abbiano un po 'diversi casi di utilizzo; WCF (intenzionalmente) ha il concetto di "maresciallo per riferimento" perché è progettato per distribuire e (relativamente) applicazioni con accoppiamento che può essere preferibile evitare protocolli chiacchierone dovuti alla latenza ecc Se i componenti sono naturalmente strettamente accoppiati, latenza sarà basso ma prestazioni deve essere elevata, preservando ricche tipi NET è importante, ecc quindi Remoting può ancora essere una buona misura. In ogni caso, io non mi preoccuperei di essere "legacy", le tecnologie "legacy", almeno su Windows / .NET hanno un modo di stare in giro per un bel po 'di tempo se ottengono una discreta quantità di utilizzo. Remoting esiste ancora nella più recente (4.0) versione di .NET.

Niente di tutto questo è inteso come un'affermazione che Remoting necessariamente è la soluzione migliore per la vostra situazione ...