Elegir opciones de comunicación en .NET
.NET Framework proporciona varias formas de comunicarse con objetos en distintos dominios de aplicación, cada una diseñada teniendo en cuenta un determinado grado de experiencia y flexibilidad. Por ejemplo, gracias al crecimiento de Internet, los servicios Web XML constituyen un atractivo método de comunicación, porque se basan en la infraestructura común del protocolo HTTP y el formato SOAP, que utiliza XML. Se trata de estándares públicos que se pueden utilizar inmediatamente con las infraestructuras Web existentes sin necesidad de tener en cuenta cuestiones adicionales relativas a objetos proxy o servidores de seguridad.
Dado que gran cantidad de aplicaciones requieren funcionalidad que los servicio Web creados mediante ASP.NET no admiten, algunas aplicaciones no pueden utilizar los servicios Web ASP.NET. Utilice la siguiente sección para que le ayude a decidir qué tipo de compatibilidad con aplicaciones distribuidas desea utilizar en su aplicación.
¿ASP.NET, Enterprise Services o .NET Remoting?
ASP.NET, Enterprise Services y .NET Remoting son implementaciones de la comunicación entre procesos (IPC). ASP.NET proporciona una infraestructura, alojada en los Servicios de Internet Information Server (IIS), que controla correctamente los tipos básicos, admite algunos protocolos de servicios Web avanzados (cuando se utiliza con extensiones de servicio Web (WSE)) y con la que están familiarizados los programadores de aplicaciones Web. Enterprise Services es una implementación administrada de COM+ y proporciona toda la flexibilidad y riqueza de la arquitectura COM+. .NET Remoting es un sistema IPC genérico y extensible que se puede autoalojar o alojar en IIS para desarrollar e implementar aplicaciones distribuidas orientadas a objetos. La arquitectura conectable de .NET Remoting permite personalizar protocolos y formatos de conexión.
La elección que se haga entre los modelos de programación debe estar determinada por tres criterios principales: los requisitos empresariales, las necesidades de integración y el modelo de programación con el que se esté familiarizado. Además, los siguientes criterios (ordenados por prioridad) pueden ayudarle a elegir el tipo de tecnología de aplicaciones distribuidas que necesita.
Necesidades de seguridad
De los tres modelos de programación, Enterprise Services cuenta con el conjunto más completo de características de seguridad y satisfará las necesidades de la mayoría de los escenarios. ASP.NET proporciona autenticación a través de IIS y cifrado a través de SSL, y resulta de utilidad para proteger las aplicaciones destinadas a Internet. La seguridad de .NET Remoting se ha visto incrementada gracias a la última versión de .NET Framework. En anteriores versiones de .NET Remoting, si necesitaba cifrar sus llamadas o autenticar el cliente, era necesario utilizar una aplicación basada en HTTP que estuviera alojada en IIS, tanto si se trataba de una aplicación ASP.NET como de una aplicación de interacción remota. En la versión actual, TcpChannel y HttpChannel admiten cifrado SSPI y autenticación integrada de Windows. IpcChannel también admite la autenticación de Windows y la configuración directa de la lista de control de acceso (ACL) en la canalización con nombre. Dado que no se recomienda utilizar objetos remotos en Internet, existen pocos escenarios que requieran HttpChannel. Si debe comunicarse por Internet, se recomienda que utilice ASP.NET para crear servicios Web XML.
Nota
Por motivos de seguridad, es muy recomendable exponer los extremos de interacción remota a través de canales seguros. No exponga nunca extremos de interacción remota inseguros en Internet.
Interoperabilidad
Si tiene que trabajar con distintos sistemas operativos, debe utilizar los servicios Web XML creados por los archivos de ASP.NET. ASP.NET proporciona una flexibilidad considerablemente mayor en la definición de la forma y el estilo de la comunicación SOAP que .NET Remoting. Esta flexibilidad puede facilitar la interoperabilidad con diferentes plataformas y clientes. .NET Remoting no está diseñada para la interoperabilidad con plataformas que no sean .NET.
.NET Framework Remoting no está diseñada para interoperar con servicios Web. Para obtener más información sobre la elección entre los servicios Web y la interacción remota, vea la sección acerca de cómo elegir entre los servicios Web, la interacción remota y Enterprise Services en el artículo de resumen de los procedimientos recomendados para aumentar el rendimiento (en inglés) y la sección de guía normativa para elegir servicios Web, Enterprise Services y .NET Remoting en el artículo acerca de cómo mejorar el rendimiento y la escalabilidad de las aplicaciones .NET (en inglés).
Velocidad
Si la velocidad es realmente un factor determinante, Enterprise Services proporciona el mejor rendimiento para aplicaciones distribuidas. Existe muy poca diferencia de rendimiento entre .NET Remoting y los archivos de ASP.NET cuando una aplicación requiere procesamiento en situaciones reales. Si utiliza .NET Remoting, TcpChannel con BinaryFormatter tiene el mejor rendimiento en varios equipos. En el mismo equipo, se debe utilizar IpcChannel con BinaryFormatter.
Escalabilidad
El alojamiento de la aplicación en IIS le proporciona la escalabilidad que necesita. El autoalojamiento de .NET Remoting requiere que se genere una infraestructura propia de escalabilidad. En cambio, si contempla la posibilidad de utilizar IIS con .NET Remoting para aumentar la escalabilidad, debería pensar en los servicios Web creados mediante ASP.NET.
Uso de las características de Common Language Runtime
Tanto Enterprise Services como .NET Remoting sacan mayor partido de los clientes .NET, por lo que se pueden utilizar las características .NET de la aplicación que no están disponibles para un servicio Web XML creado mediante el uso de ASP.NET, como:
Interfaces
CallContext
Propiedades
Indizadores
C++
Fidelidad de tipos entre las aplicaciones de cliente y servidor
Si estas características son cruciales, elija Enterprise Services, si es posible, y a continuación .NET Remoting.
Diseño de aplicaciones orientado a objetos.
Tanto los objetos de Enterprise Services como de .NET Remoting son objetos que pueden ser tratados como tales. Como consecuencia, se pueden utilizar las siguientes características orientadas a objetos de la aplicación que no están disponibles para ASP.NET.
Referencias a objetos remotos
Varias opciones de activación de objetos
Administración de estados orientada a objetos
Administración de la duración de objetos distribuidos
Si estas características son cruciales, elija Enterprise Services, si es posible, y a continuación .NET Remoting.
Transportes o formatos de conexión personalizados. Si necesita admitir transportes personalizados (por ejemplo, el Protocolo de datagramas de usuarios (UDP)) o formatos de conexión personalizados (por ejemplo, CSV), .NET Remoting es la única arquitectura conectable que puede satisfacer estas necesidades.
Comunicaciones entre dominios de aplicación. Si necesita admitir la comunicación entre objetos en diferentes dominios de aplicación dentro del mismo proceso, debe utilizar .NET Remoting.
En las siguientes secciones se incluye un breve resumen de algunas de las diferencias entre los servicios Web XML creados mediante ASP.NET, el espacio de nombres System.Net, Enterprise Services o .NET Remoting.
Servicios Web XML
Los servicios Web XML creados mediante ASP.NET funcionan bien si genera aplicaciones de ASP (páginas Active Server) con el modelo de aplicación Web y el tiempo de ejecución HTTP de ASP.NET, incluida amplia compatibilidad en Microsoft Visual Studio. NET. Con la infraestructura de servicios Web XML, puede crear fácilmente componentes para que otras aplicaciones los utilicen o usar componentes que otros usuarios hayan creado mediante los protocolos, formatos y tipos de datos más adecuados para las aplicaciones basadas en Web. No se admite la fidelidad absoluta de tipos entre equipos y sólo se pueden pasar algunos tipos de argumentos. Para obtener más información, vea Servicios Web XML creados con ASP.NET y clientes de servicios Web XML.
Espacio de nombres System.Net
Puede utilizar las clases que aparecen en el espacio de nombres System.Net para generar toda una estructura de comunicación a partir del nivel de socket. También puede utilizar las clases System.Net con el fin de implementar protocolos de comunicación y formatos de serialización para conectarlos a la arquitectura de interacción remota. Para obtener más información, vea Programación para redes.
Enterprise Services.
Enterprise Services aprovecha la infraestructura de .NET Remoting para proporcionar toda la riqueza y flexibilidad del modelo de objetos distribuidos de COM+, incluida la compatibilidad con transacciones ampliamente distribuidas.
.NET Remoting
.NET Remoting proporciona herramientas para todo tipo de escenarios de comunicación exhaustiva que incluyan servicios Web XML. Mediante .NET Remoting, se puede:
Publicar o utilizar servicios en cualquier tipo de dominio de aplicación, tanto si ese dominio es una aplicación de consola, un formulario Windows Forms, un servicio de IIS, un servicio Web XML, o un servicio de Windows.
Conservar una fidelidad absoluta del sistema de tipos de código administrado en comunicaciones de formato binario, incluida la compatibilidad de tipos genéricos.
Nota
Los servicios Web XML utilizan el formato SOAP, que no conserva todos los detalles de los tipos.
Pasar objetos por referencia y volver a un determinado objeto en un determinado dominio de aplicación.
Controlar directamente las características de activación y la duración de los objetos.
Implementar y utilizar canales o protocolos de terceros para extender la comunicación y así satisfacer sus necesidades particulares.
Participar directamente en el proceso de comunicación para crear la funcionalidad que necesita.
Vea también
Otros recursos
Objetos remotos
Información general de .NET Framework Remoting
Ejemplos de interacción remota
Interacción remota avanzada