Objetos remotos y no remotos

Es importante recordar que a un objeto creado en un dominio de aplicación, y por consiguiente, concreto para ese dominio, se lo puede llamar directamente desde ese dominio, pero se debe producir algo antes de que ese objeto pueda estar disponible fuera de su dominio. No se pueden publicar de forma eficaz ni se pueden consumir por los límites del dominio todos los tipos de objeto; por consiguiente, debe decidir qué tipo de objeto desea publicar basándose en los requisitos de su aplicación. Para los propósitos de las aplicaciones distribuidas, hay dos categorías de objetos: los objetos no utilizables de forma remota y los objetos utilizables de forma remota.

Objetos no utilizables de forma remota

Algunos objetos no pueden dejar su dominio de aplicación; nunca se pueden calcular las referencias puesto que no declaran ningún método de serialización. Estos objetos no utilizables de forma remota están diseñados para el uso dentro del mismo dominio de aplicación en el que se crearon y siempre se puede acceder a ellos directamente desde ese dominio de aplicación. La mayoría de las clases base en la biblioteca de clases .NET Framework son objetos no utilizables de forma remota. Los objetos no utilizables de forma remota no se pueden copiar o representar en otro dominio de aplicación. A estos objetos solamente se puede acceder desde su dominio de aplicación original.

Objetos utilizables de forma remota.

Se puede tener acceso a los objetos remotos fuera su dominio de aplicación o de su contexto utilizando un proxy, o se pueden copiar, y estas copias se pueden pasar fuera de su dominio de aplicación o de su contexto; es decir, algunos objetos utilizables de forma remota se pasan por referencia y otros por valor.

Los objetos utilizables de forma remota son objetos que funcionan bien en un entorno ampliamente distribuido. Hay dos tipos principales de objetos utilizables de forma remota:

• Objetos de cálculo por valor que se copian y se pasan desde el dominio de aplicación.

• Objetos de cálculo por referencia, para los que se crea un proxy y el cliente lo utiliza para tener acceso al objeto de forma remota.

Objetos de cálculo de referencia por valor

Los objetos de cálculo de referencias por valor (MBV) declaran sus normas de serialización (implementando ISerializable para implementar su propia serialización o marcándose con SerializableAttribute, que indica al sistema que serialice automáticamente el objeto) pero no extiende MarshalByRefObject. El sistema remoto realiza una copia completa de estos objetos y pasa la copia al dominio de la aplicación que hace la llamada. Cuando la copia está en el dominio de aplicación del llamador, las llamadas realizadas a la copia van directamente a esa copia. Además, los objetos MBV que se pasan como argumentos también se pasan por valor. Para pasar instancias de su clase por valor a través de la aplicación o los límites del contexto no tiene más que declarar el atributo SerializableAttribute o implementar ISerializable.

Nota:

Iniciándose con la versión 1.1 de .NET Framework, la infraestructura remota no deserializa automáticamente ciertos tipos en el servidor. Si su aplicación intenta pasar un tipo que no se serializa automáticamente, debe establecer el nivel de deserialización del servidor a Full antes de que el servidor pueda deserializar y utilizar su objeto MBV. Para obtener más información, vea Deserialización automática en .NET Remoting.

Utilice los objetos MBV cuando, por razones de rendimiento o de procesamiento, tenga sentido mover el estado completo del objeto y cualquier funcionalidad ejecutable al dominio de la aplicación de destino. En muchos escenarios, esto reduce los largos viajes de ida y vuelta por la red, que consumen muchos recursos, procesos y límites del dominio de aplicación. Los objetos MBV también se utilizan directamente desde dentro del dominio de aplicación original del objeto. En este caso, puesto que no tiene lugar ningún cálculo de referencias, no se realiza ninguna copia y el acceso es eficaz.

Cree un tipo de cálculo de referencias por valor utilizando SerializableAttribute a menos que esté extendiendo una clase que ya implementa ISerializable. En este caso, debe implementar ISerializable para su tipo.

El sistema remoto realiza un uso extenso de los objetos serializables. Una referencia a un objeto en otro dominio de aplicación, representada en el sistema remoto por la clase ObjRef, es autoserializable; debe ser posible copiarla exactamente y enviarle la copia a un cliente. Además, los objetos que transfieren datos son, a menudo, objetos serializables. Por ejemplo, el conjunto de datosextiende MarshalByValueComponent, que implementa ISerializable.

Excepciones remotas definidas por el usuario

Las excepciones definidas por el sistema son todas tipos de cálculo de referencias por valor (implementan la interfaz ISerializable) que, cuando las inicia un objeto remoto, se copian automáticamente en el llamador si las configuraciones remotas lo permiten. Iniciándose con la versión 1.1 de .NET Framework, el elemento <customErrors> debe estar establecido en off para permitir a las excepciones fluir al llamador.

Para obtener más información sobre cómo crear un tipo de excepción que puede ser iniciado por un objeto remoto y puede ser detectado por un llamador remoto, vea Cómo: Crear un tipo de excepción que puede ser iniciado por objetos remotos

Objetos de cálculo por referencia

Los objetos de cálculo por referencia (MBR) son objetos utilizables de forma remota que se extienden al menos a System.MarshalByRefObject. Dependiendo de qué tipo de activación se ha declarado, cuando un cliente crea una instancia de un objeto MBR en su propio dominio de aplicación, la infraestructura de .NET Remoting crea un proxy que representa al objeto MBR y devuelve al llamador una referencia a ese proxy. A continuación, el cliente realiza las llamadas en el proxy. .NET Remoting calcula las referencias de esas llamadas al dominio de aplicación del objeto remoto e invoca la llamada.

Nota:
Si el cliente está en el mismo dominio de aplicación que el objeto MBR, la infraestructura devuelve una referencia directa del objeto MBR al cliente, evitando la sobrecarga de calcular referencias.

Si System.MarshalByRefObject se pasa como un parámetro, se convierte en un proxy en el otro dominio de aplicación cuando llega la llamada. Los valores devueltos del MBR y los parámetros out trabajan de la misma forma.

Nota:

Iniciándose con la versión 1.1 de .NET Framework, la infraestructura de .NET Remoting no deserializa automáticamente ciertos tipos en el servidor. Por ejemplo, para obtener la compatibilidad para los objetos MBR, pasados como parámetros, debe establecer el nivel de deserialización del servidor a Full antes de que el servidor pueda deserializar y utilizar el parámetro MBR. Para obtener más información, vea Deserialización automática en .NET Remoting.

Debería utilizar objetos MBR cuando el estado del objeto y de cualquier funcionalidad ejecutable debería quedarse en el dominio de aplicación en el que se creó. Por ejemplo, un objeto que posee un campo interno que es un manipulador del sistema operativo debería extender System.MarshalByRefObject porque el manipulador del sistema operativo no sería significativo en otro dominio de aplicación, en otro proceso, o en otro equipo. A veces un objeto también puede ser prohibitivamente grande; esto podría funcionar en un servidor robusto, pero no cuando se envía a través de una conexión a un módem de 33.6 KB/s.

Objetos enlazados por contexto

Los objetos enlazados por contexto son objetos MBR que heredan de System.ContextBoundObject, que, a su vez, hereda de System.MarshalByRefObject. Puede pensar en un contexto como una subdivisión de un dominio de aplicación que proporciona un entorno enriquecido para los objetos que residen en él durante la ejecución. Por ejemplo, un contexto podría garantizar que varios subprocesos no tengan acceso simultáneamente a los objetos. Cada dominio de aplicación tiene un contexto predeterminado. La mayor parte del código administrado crea los objetos y llama a los miembros directamente desde dentro del mismo dominio de aplicación utilizando el contexto predeterminado de ese dominio, sin los problemas relacionados con el contexto. Todos los tipos que heredan de System.ContextBoundObject se exponen a otros contextos (en el mismo dominio o en otros dominios) como proxys.

Por ejemplo, suponga tiene un método en un tipo que forma parte de una transacción y, por lo tanto, está enlazado por las reglas concretas del contexto en el que se creó. Ese tipo debería heredar de System.ContextBoundObject para que se tenga acceso al objeto de su propio contexto, y el sistema pueda exigir las reglas con respecto a las transacciones asociadas a ese objeto y a sus métodos. Si se llama a System.ContextBoundObject desde otro contexto dentro del mismo dominio de aplicación, se crea un proxy para el llamador pero la comunicación del inter-contexto no pasa por el sistema del canal, que aumenta la eficacia de la llamada en esta situación.

Dado que el cruzar cada límite lleva tiempo de proceso, debería determinar qué límites debe cruzar su objeto antes de decidir qué tipo de objeto utilizable de forma remota debería ser su servidor. Se puede acceder directamente a los objetos concretos de un contexto sólo desde ese contexto. Lo mismo ocurre con los objetos concretos de un dominio de aplicación determinado. Para utilizar cualquier objeto de forma remota, el sistema remoto debe cruzar correctamente un límite de contexto, un límite de aplicación, o ambos, antes de invocar el objeto del servidor desde el interior de cualquier límite concreto. Si no necesita que una comprobación del contexto llame a su objeto, no debería hacer que su tipo remoto extienda System.ContextBoundObject; System.MarshalByRefObject y realice una comprobación mejor. Si necesita una comprobación de contexto, debería extender System.ContextBoundObject, pero debe entender que se debe cruzar el límite adicional antes de que se realice la llamada en su objeto.

Ámbito de publicación

Diferentes sistemas remotos tienen formas distintas de decidir qué miembros y qué tipo de miembros se pueden utilizar de forma remota. .NET Remoting expone objetos a otros dominios de aplicación como si fueran locales, con las excepciones siguientes:

• Miembros estáticos

  Los campos y métodos estáticos nunca se utilizan de forma remota y el acceso de campo se realiza mediante una memoria directa. Es decir, .NET Remoting siempre trata con miembros de instancia de algún formulario.

• Campos de instancia y descriptores de accesos

  Para los campos de instancia y los métodos de descriptor de acceso, el sistema inserta una comprobación durante el tiempo de ejecución con el fin de determinar si el objeto es un proxy. Si no es un proxy, el acceso de campo es directo. De lo contrario, el proxy proporciona descriptores de acceso al llamador.

• Métodos privados

  Los métodos privados no se pueden utilizar de forma remota. No puede encapsular y pasar de forma remota un delegado a un método privado.

• Delegados.

  Los delegados son objetos de cálculo de referencias por valor. El objeto dentro del delegado puede ser cualquier tipo de objeto utilizable de forma remota: un objeto serializable, un objeto MarshalByRefObject o un objeto ContextBoundObject. La única excepción es que un delegado de un método de interfaz no se puede utilizar correctamente de forma remota. El delegado encapsula la implementación del método de interfaz, exigiendo a la información de tipo del cliente que esté disponible para el servidor.

• Invalidar los métodos en el objeto.

  Debido a razones de rendimiento, los métodos virtuales en Objeto siempre se ejecutan localmente en el dominio de aplicación donde se los llama. Las llamadas a cualquiera de los métodos siguientes sólo van al objeto remoto cuando estos métodos se han invalidado en el objeto remoto:

  • Equals

    Este método virtual se ejecuta remotamente si se invalida.

  • GetHashCode

    Este método se ejecuta localmente.

  • ToString

    Este método virtual se ejecuta remotamente si se invalida.

  • Equals (la versión estática)

    Este método se ejecuta localmente.

  • MemberwiseClone

    Este método se ejecuta localmente.

Consulte también

Tareas

Cómo: Crear un tipo de excepción que pueda ser iniciado por objetos remotos

Otros recursos

.Información general de comunicación remota de .NET Framework
Hacer que los objetos sean remotos

Copyright © 2007 Microsoft Corporation. Reservados todos los derechos.