Elegir opciones de comunicación en .NET

  • Artículo

Con la introducción de .NET Framework 3.0 e Windows Communication Foundation (WCF), se han unido varias tecnologías en un modelo de programación unificado. WCF sirve como la siguiente versión de Enterprise Services, servicios web ASMX, WSE, MSMQ y .NET Remoting. El tema siguiente se aplica a .NET Framework 2.0. Para obtener más información acerca de WCF y .NET Framework 3.0, vea: Windows Communication Foundation.

.NET Framework proporciona varias formas de comunicarse con los objetos de diferentes dominios de aplicación, cada uno de ellos diseñado con un nivel determinado de especialización y flexibilidad. Por ejemplo, el crecimiento de Internet ha convertido los servicios web de XML en un método atractivo de comunicación porque los servicios web de XML están generados en la infraestructura común del protocolo HTTP y el formato SOAP que usa XML. Éstas son normas públicas y se pueden utilizar de forma inmediata con las infraestructuras Web actuales sin necesidad de preocuparse por problemas con el proxy o el cortafuegos.

Dado que muchas aplicaciones requieren la funcionalidad que Web Servicies creó utilizando ASP.NET y ésta no admite, algunas aplicaciones no pueden utilizar ASP.NET Web Servicies. Utilice la sección siguiente para ayudarle a decidir qué tipo de soporte de aplicaciones distribuido desea para 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, hospedada por Internet Information Services (IIS), que administra bien los tipos básicos, admite algunos protocolos de Servicio Web avanzados (cuando se utiliza con Extensiones de servicio web (WSE)) y está familiarizada con los programadores de la aplicación web. Enterprise Services es una implementación administrada de COM+ y proporciona toda la flexibilidad y riqueza de la arquitectura de COM+. .NET Remoting es un sistema de IPC genérico y extensible que puede hospedarse en sí mismo o en IIS para desarrollar e implementar las aplicaciones distribuidas orientadas a objetos. La arquitectura de .NET Remoting permite protocolos personalizados y formatos de conexión.

Su elección de los modelos de programación debe basarse en tres criterios básicos: los requisitos comerciales, los requisitos de integración y el modelo de programación con los que está familiarizado. Además, los siguientes criterios (se hace una lista en orden de prioridad) pueden ayudarle a elegir el tipo adecuado de tecnología de la aplicación distribuida:

  1. Requisitos de seguridad

    De los tres modelos de programación, Enterprise Services tiene el conjunto más amplio de características de seguridad y funciona con la mayor parte de los escenarios. ASP.NET proporciona la autenticación a través de IIS y el cifrado a través de SSL, y resulta útil para proteger las aplicaciones de escala de Internet. La seguridad de .NET Remoting se ha incrementado con la última versión de .NET Framework. En versiones anteriores de .NET Remoting, si necesitaba cifrar sus llamadas o autenticar a su cliente, tenía que utilizar una aplicación basada en Http hospedada en IIS, ya se tratase de una aplicación ASP.NET o de una aplicación remota. En la versión actual, TcpChannel y HttpChannel admiten cifrado del código SSPI y Autenticación de Windows integrada. IpcChannel también admite la autenticación de Windows y el valor directo de la lista de control de acceso (ACL) en la canalización con nombre. Dado que no se recomienda utilizar objetos remotos por Internet, ahora existen unos pocos escenarios que requieren HttpChannel. Si tiene que comunicarse por Internet, se recomienda que utilice ASP.NET para crear servicios web de XML.

    Nota:

    Por razones de seguridad, se recomienda encarecidamente hacer que los extremos remotos estén disponibles a través de canales seguros. Nunca muestre en Internet los extremos remotos inseguros.

  2. Interoperación

    Si debe interoperar entre sistemas operativos diferentes, debería utilizar servicios web de XML creados por ASP.NET. Los archivos ASP.NET le proporcionan una mayor flexibilidad para definir la forma y el estilo de comunicación SOAP que .NET Remoting. Esta flexibilidad puede hacer más fácil la interoperación con plataformas y clientes diferentes. .NET Remoting no está concebido para interoperar con plataformas distintas de .NET.

    .NET Framework remoto no está pensado para interoperar con servicios web. Para obtener más información acerca de cómo elegir entre los servicios web y la comunicación remota, vea "Cómo elegir entre los servicios Web, la comunicación remota y Enterprise Services" en Procedimientos recomendados de un vistazo y Orientación prescriptiva para elegir servicios Web, Enterprise Services y .NET Remoting.

  3. Velocidad

    Si es cierto que la velocidad es un factor tendencia, Enterprise Services proporciona el máximo rendimiento para las aplicaciones distribuidas. Existe una diferencia muy pequeña entre el rendimiento de los archivos de .NET Remoting y los de ASP.NET puesto que una aplicación requiere un procesamiento real. Si utiliza .NET Remoting, TcpChannel con BinaryFormatter tiene el máximo rendimiento en los equipos. En el mismo equipo, se debería utilizar IpcChannel con BinaryFormatter.

  4. Escalabilidad

    Al hospedar su aplicación dentro de IIS obtendrá la escalabilidad que necesita. .NET Remoting se hospeda en sí mismo y necesita que genere su propia infraestructura de escalabilidad. Si está considerando utilizar IIS con .NET Remoting para ganar escalabilidad, en su lugar, debería tener en cuenta los servicios Web creados al utilizar ASP.NET.

  5. Utilización de características de Common Language Runtime

    Tanto Enterprise Services como .NET Remoting sacan provecho de los clientes de .NET para que usted pueda utilizar en su aplicación las características de .NET que no están disponibles en un servicio web de XML, creadas utilizando ASP.NET, entre las que se incluyen:

    • Interfaces.

    • CallContext.

    • Propiedades.

    • Indicadores.

    • C++.

    • Escriba la fidelidad existente entre las aplicaciones del servidor y del cliente.

    Si estas características son críticas, elija Enterprise Services, si es posible, y a continuación .NET Remoting.

  6. Diseño de aplicación orientado a objetos

    Tanto Enterpise Services como .NET Remoting son objetos y se pueden tratar como tales. Como resultado, en su aplicación puede usar las siguientes características orientadas a objetos que no están disponibles en ASP.NET:

    • Referencias de objetos a los objetos utilizables de forma remota.

    • Varias opciones de activación de objetos.

    • Administración de estados orientada a objetos.

    • Administración del período de duración de los objetos distribuidos.

    Si estas características son críticas, elija Enterprise Services, si es posible, y a continuación .NET Remoting.

  7. Transportes personalizados o formatos de conexión

    Si necesita hacer compatibles los transportes personalizados (por ejemplo, Protocolo de datagramas de usuario (UDP)) o los formatos de conexión personalizados (por ejemplo, CSV), .NET Remoting es la única arquitectura conectable que puede cumplir con estos requisitos.

  8. Aplicación de cruce comunicaciones del dominio

    Si necesita hacer compatible la comunicación entre objetos de dominios de aplicación diferentes dentro del mismo proceso, debe utilizar .NET Remoting.

Las secciones siguientes incluyen un breve resumen de algunas de las diferencias entre los servicios web de XML creados con ASP.NET, el espacio de nombres System.Net, Enterprise Services y .NET Remoting.

Servicios Web XML

Los servicios Web de XML creados utilizando ASP.NET funcionan bien si genera las aplicaciones de páginas Active Server (ASP) utilizando el modelo de la aplicación Web y el tiempo de ejecución Http de ASP.NET, incluyendo la alta compatibilidad con Microsoft Visual Studio .NET. Con la infraestructura del servicio web de XML puede crear fácilmente componentes para que los usen otras aplicaciones o usar componentes que otras aplicaciones han creado con protocolos, formatos y tipos de datos más apropiados para las aplicaciones basadas en la Web. No se admite la fidelidad de tipo entre los equipos y solamente se pueden pasar algunos tipos de argumentos. Para obtener más información, vea Servicios web XML creados con ASP.NET y clientes de servicio web XML.

System.Net (Espacio de nombres)

Puede utilizar las clases del espacio de nombres System.Net para generar una estructura de comunicación completa del nivel del socket. También puede utilizar las clases System.Net para implementar los protocolos de comunicación y los formatos de serialización que puede conectar en la arquitectura remota. Para obtener más información, vea Network Programming.

Enterprise Services

Enterprise Services se genera en la infraestructura de .NET Remoting para proporcionar toda la variedad y flexibilidad del modelo de objetos distribuidos de COM+, incluyendo la compatibilidad para transacciones ampliamente distribuidas.

.NET Remoting

.NET Remoting proporciona las herramientas para muchos escenarios de comunicación global que incluyan servicios web de XML. Utilizando .NET Remoting puede:

  • Publicar o tener acceso a los servicios en cualquier tipo de dominio de aplicación, aunque ese dominio sea una aplicación de consola, un formulario Windows Form, IIS, un servicio web de XML o un servicio de Windows.

  • Conserve la fidelidad del sistema de tipos de código administrada por completo en comunicaciones con formato binario, incluyendo la compatibilidad para los tipos genéricos.

    Nota:

    Los servicios Web de XML utilizan formato SOAP, que no conserva todos los detalles de tipo.

  • Pase los objetos por referencia y vuelva a un objeto determinado en un dominio de aplicación determinado.

  • Controle directamente las características de activación y los períodos de duración de los objetos .

  • Implemente y utilice canales o protocolos de otro fabricante para extender la comunicación con el fin de conseguir los requisitos deseados.

  • Participe directamente en el proceso comunicativo para crear la funcionalidad que necesita.

Consulte también

Otros recursos

.Comunicación remota de .NET
.Información general de comunicación remota de .NET Framework
Ejemplos de comunicación remota
Comunicación remota avanzada
Windows Communication Foundation

Copyright © 2007 Microsoft Corporation. Reservados todos los derechos.