Uso creativo de MarshalByRefObject

Question

Me he estado golpeando la cabeza tratando de resolver algunas cosas.Entonces, estoy buscando asesoramiento y material de investigación (a través de enlaces).Este es el escenario:

Tenemos una biblioteca (por ejemplo, CommonLib) que contiene recursos necesarios para varias otras aplicaciones (por ejemplo, AppA, AppB, AppC, etc.).Ahora, la forma en que esto funciona actualmente son instancias de AppA, verifica si el puerto específico está disponible.Si no es así, inicia CommonLib ("Oye, despierta") y se inicia el servicio.Entonces AppA se alegra y nos vamos.

Ahora, he investigado mucho sobre Remoting.Channels y he llegado a la conclusión de que estoy iniciando una aplicación basada en una tecnología que se considera "heredada".Bueno... eso no me gusta.Honestamente, WCF supone una sobrecarga mucho mayor de la que necesitamos y no está completamente implementada en Mono.Nuestro objetivo es la compatibilidad multiplataforma (Windows, Mono, Linux), por lo que estamos investigando todas las opciones.

La idea de la comunicación remota comenzó, en primer lugar, porque queríamos que CommonLib fuera una instancia única garantizada (según tengo entendido, prácticamente solo se garantiza que un singleton sea un singleton dentro de un dominio de aplicación determinado; no dude en corregirme si 'Estoy mal).De todos modos, me di cuenta del poder de la comunicación remota y decidí comenzar una implementación experimental.Tuve éxito en mi uso inicial de MarshalByRefObject.Pero me preocupa la implementación continua de esta tecnología heredada.

Entonces, con todo esto... estoy considerando cómo puedo implementar CommonLib (como aplicación host) y, sin comunicación remota, implementar MarshalByRefObject a través de Stream, TCP Socket estándar o de alguna otra forma.Lo que estoy pensando es que, en lugar de crear una instancia de AppA para ejecutar CommonLib, simplemente implemente CommonLib como la aplicación base.Luego, selecciona qué aplicación (en realidad solo un .dll 'alojado') desea crear una instancia dentro de CommonLib.CommonLib luego cargaría ese .dll en el marco CommonLib junto con los controles personalizados que utilice la aplicación alojada.Junto con esta idea, renunciaría al requisito (por ahora) de que CommonLib debe ser un singleton genuino.

Entonces... ese es un detalle de nuestro escenario.Nuevamente, mi pregunta consta realmente de 2 partes:(a) ¿Qué tecnología(es) debo investigar, y (b) ¿Debo preocuparme por el estado heredado de la tecnología remota?

Cualquier otro consejo, comentario o pregunta será más que bienvenido.

ACTUALIZACIÓN 1:estoy empezando con este fragmento.Esto me permitirá cargar un archivo (o script) con una lista de aplicaciones (o complementos) que se han instalado.Puedo crear este archivo con formato Xml o Binario.Cuando se instala una nueva aplicación, se pueden agregar el archivo y la ruta.Hmmm... No necesariamente necesito usar MarshalByRefObject.

Answer 1

Si bien WCF puede no ser tan completo en Mono, Mono 2.6 proporciona todo lo necesario para Silverlight/Moonlight, por lo que una implementación basada en WCF debería ser perfectamente factible.Siempre y cuando no intente nada exótico (diferentes transportes, inspectores, etc.), debería ser más que suficiente proporcionar una pila RPC que sea confiable entre Windows/mono/etc.

La diferencia clave entre WCF y la comunicación remota está en uso - la comunicación remota se basa en un objeto que pretende estar en un extremo diferente, mientras que WCF se basa en un servicio;El punto es que debes basar tus interacciones en métodos discretos (en lugar de acceder a propiedades, etc.); esto también tiene la ventaja de ayudar a hacerlo explícito cuando cruzas el límite.

Otra opción sería escribir un servidor de socket muy básico;muy liviano, y podrías usar algo como protobuf-net para proporcionar una implementación de serializador portátil (multiplataforma) (realmente no deberías confiar BinaryFormatter entre los dos - es...escamoso).

En resumen, no construiría alrededor MarshalByRefObject en absoluto;Escribiría una capa de servicio, algo como:

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

y abstraer estos detalles lejos de la persona que llama.Si terminas usando WCF, entonces eso es todo necesitas;y para el soporte remoto existente, escribiría un IMyService implementación que encapsula (en privado) todo MarshalByRefObject historia.Lo mismo ocurre si escribí un servidor de socket.

Answer 2

No estoy seguro de que .NET Remoting es obsoleto por la WCF. Creo que tienen algo diferentes casos de uso; WCF (deliberadamente) no tiene el concepto de "Marshal de referencia", pues está diseñado para distribuida y (relativamente) aplicaciones débilmente acoplados que podría ser necesario evitar protocolos hablador debido a la latencia, etc. Si sus componentes son, naturalmente, estrechamente unidas, la latencia será baja, pero las necesidades de rendimiento a ser altos, preservando tipos de .NET ricos es importante, etc, entonces Conexión remota todavía puede ser una buena opción. De todos modos, yo no me preocuparía por ser "legado", tecnologías "heredados" por lo menos en Windows / .NET tiene una forma de permanecer alrededor durante bastante tiempo si reciben una buena cantidad de uso. Comunicación remota todavía existe en el más reciente (4.0) versión de .NET.

Nada de esto se entiende como una afirmación de que la interacción remota necesariamente es el mejor ajuste para su situación ...