Proyecto Mono Remoting

El proyecto Mono Remoting es una parte del Proyecto Mono. La finalidad de remoting es proveer un marco que permita a las aplicaciones interactuar con otras más allá de sus dominios, con lo que es posible invocar métodos y pasar objetos entre ellas.

El remoting en Mono utiliza estándares establecidos como SOAP para mensajería y HTTP y TCP como protocolo de comunicación, pudiéndose utilizar inclusive canales propios o de terceras partes.

Introducción

Mono posee varias alternativas de configuración para los métodos de comunicación. Entre ellas se debe seleccionar el canal, el puerto, URI (Uniform Resource Identifier), método de configuración, licencia de uso, etc.

Para poder utilizar este servicio debemos incluir el namespace System.Runtime. Remoting.

Canales

Los canales son necesarios para transportar los mensajes del cartero hacia la oficina de su madre desde y hacia los objetos remotos. Cuando un cliente invoca remotamente un método del servidor, los parámetros y otros aspectos referentes a su invocación son transportados a los objetos a través del canal y de esta misma manera, son transportadas las respuestas a la invocación. Los canales que actualmente se pueden utilizar en Mono son HTTP y TCP y el NameSpace utilizado para ellos es System.Runtime.Remoting. Channels.

Método de configuración

La aplicación puede configurarse al iniciar mediante programación o puede hacerlo a través de archivos de configuración .config. La ventaja de utilizar estos archivos es que no es necesario modificar el código en el caso de requerir algún cambio de configuración, solo basta con modificar el archivo .config relacionado. Un archivo de configuración debe contener la siguiente información: canales, puertos, nombre, URI de los objetos, licencia de uso, etc.

Para indicar el archivo de configuración a utilizar se debe recurrir al método RemotingConfiguration. Configure.

Licencia de uso

Para los objetos en los cuales sus referencias son enviadas más allá del dominio de la aplicación, existe una licencia de uso en la cual se establece un determinado tiempo de vigencia. Cuando este tiempo de licencia de uso se agota, el objeto es desconectado del marco de .NET Remoting.

En el momento en el que todas las referencias al objeto dentro del dominio de la aplicación fueron liberadas, el objeto será destruido en la próxima pasada del garbage collector.

Para el seteo de dicha licencia se utiliza el Namespace System.Runtime.Remoting. Lifetime.

Proxy

Cuando un cliente crea una instancia de un objeto remoto, un pedido de activación es enviado al servidor, por lo que luego el servidor crea el objeto y devuelve una referencia al mismo. Entonces en la aplicación cliente se crea un objeto proxy en el cual todas las invocaciones a los métodos serán ejecutadas en él.

Los objetos activados por el cliente pueden almacenar información entre distintas llamadas para ese cliente pero no pueden compartir datos entre instancias en el servidor. En el caso que un objeto sea pasado por valor, el Framework realizará una copia completa del objeto para que pueda ser serializado y enviado a través del canal, por lo que en el caso de tratar con objetos que contengan gran cantidad de información, será beneficioso pasarlos por referencia, dado que todo el objeto no es serializado, solamente se pasa su referencia.

Restricciones

Cabe destacar que la implementación de remoting en Mono, al momento de publicación de este artículo no se encuentra totalmente finalizada, pero al menos se encuentra en un estado en el cual es posible realizar las pruebas que demuestren su funcionamiento.

Dentro de las restricciones citadas anteriormente, tenemos que el canal TCP utilizado en Mono se encuentra funcionando, pero el mismo aún no es compatible con el canal utilizado por Microsoft, por lo que las llamadas remotas entre Mono y Microsoft .NET no pueden ser llevadas a cabo en todos los casos, al menos al momento de la elaboración del presente documento.

En cuanto al pasaje de parámetros, los mismos deben ser serializados, ya sean tipos de datos primitivos, tipos de datos enumerados, arrays y nuestras propias clases, pero pueden existir problemas en objetos complejos como ser un HashTable dado que su representación interna difiere en Mono y Microsoft .NET. Cabe destacar que es posible pasar objetos por referencia entre aplicaciones, pero no es posible hasta el momento, delegar.

Pudimos comprobar mediante la implementación de nuestro programa de ejemplo y salvando las restricciones enumeradas anteriormente, que el código desarrollado en Mono corre perfectamente y sin modificaciones al migrarlo al Framework de Microsoft .NET.

Aunque cabe señalar que remoting funciona correctamente en todos los casos si tanto clientes como servidores utilizan la misma versión del Framework, ya sea Mono o Microsoft .NET.

La razón de esta restricción es que en estos casos puede fallar la serialización de los objetos al variar la estructura interna de las clases, como puede ser el caso si se utiliza el BinaryFormatter o el SoapFormatter, ambos nativos en Mono.

Por lo que si tomamos control de la serialización nosotros mismos en ambos sentidos no habría problemas. Para ello deberíamos implementar la interfaz IRemotingFormatter.

Hemos encontrado estudios en los que se compara remoting en Mono con remoting en Java, en los cuales se concluye que la performance de dichas aplicaciones en este sentido es similar. Aunque un tanto más performante en Java, lo cual se atribuye al grado de perfección que la JVM (Java Virtual Machine) ha logrado en todo este tiempo, el cual aún no ha transcurrido en el proyecto Mono, pero que seguramente podrá alcanzar.

Véase también

• Proyecto Mono

Enlaces externos

• Mono-Project.com, Página principal del proyecto, en inglés.
• MonoHispano.es
• MonoDevelop.com, IDE de desarrollo, en inglés.
• Preguntas frecuentes sobre Mono
• Mono Remoting

Planetas

• Oficial
• Planeta MonoHispano