Share via

Hospedar objetos remotos en Internet Information Services (IIS)

  • Artículo

Este tema es específico de una tecnología heredada que se mantiene para la compatibilidad con versiones anteriores con aplicaciones existentes y no se recomienda para nuevo desarrollo. Las aplicaciones distribuidas se deberían desarrollar utilizando  Windows Communication Foundation (WCF).

Para hospedar un objeto remoto en Internet Information Services (IIS), debe configurar el objeto remoto. Normalmente, esto se hace o dentro de un archivo de configuración o mediante programación dentro del código de aplicación de hospedaje. Cuando un objeto remoto se hospeda dentro de IIS puede colocar a la información de configuración un archivo Web.config o puede configurar mediante programación el objeto remoto en el método Application_Start en el archivo Global.asax.

Para utilizar un archivo de configuración para configurar un objeto remoto, haga lo siguiente:

  • Coloque su información de configuración en el archivo Web.config en el directorio virtual de IIS que ha decidido utilizar.

  • Coloque la implementación de tipo remoto en el directorio \bin (o utilice la herramienta caché global de ensamblados (Gacutil.exe) para colocarlo en la caché global de ensamblados).

Al especificar un archivo Web.config, no se admite lo siguiente:

  • Al especificar un nombre de aplicación, el nombre del directorio virtual se convierte en su nombre de aplicación.

  • Utilizar el elemento <debug> en un archivo Web.config que se utiliza para la configuración de .NET Remoting.

  • Utilizar cualquier canal distinto de canal http.

  • Utilice el archivo Web.config y el elemento <client> para configurar automáticamente su aplicación Web del cliente. Si desea utilizar IIS como un cliente remoto, debe llamar a RemotingConfiguration.Configure en el método Application_Start en el archivo Global.asax.

El archivo Web.config todavía contiene la información básica sobre su tipo que el sistema debe conocer, pero algunas declaraciones deben cambiar ligeramente para hospedar el entorno de hospedaje. Por ejemplo, puede configurar de forma personalizada un HttpChanneldeterminado, pero no debería especificar un puerto para el canal; si ASP.NET creara otro dominio de aplicación para administrar la carga, la configuración remota hace que ese nuevo dominio de aplicación intente realizar de nuevo escuchas en el mismo puerto, produciendo una excepción. Por ejemplo, un archivo Web.config para un objeto remoto de .NET hospedado por IIS se podría parecer al ejemplo de código siguiente. En este caso, no es necesario incluir las líneas de configuración de canal, excepto para establecer las propiedades de canal (en este caso, la propiedad priority ).

<configuration>
   <system.runtime.remoting>
      <application>
         <service>
            <wellknown 
               mode="Singleton" 
               type="ServiceClass, ServiceClassAssemblyName"
                objectUri="ServiceClass.rem"
            />
         </service>
         <channels>
            <channel 
               name="MyChannel" 
               priority="100" 
               ref="http"
            />
         </channels>
      </application>
   </system.runtime.remoting>
</configuration>
y0hedwet.note(es-es,VS.100).gifNota:
No especifique un puerto para ninguno de los canales que figuran en la siguiente lista. Si desea que su aplicación realice escuchas en un puerto determinado, utilice el Administrador de servicios de Internet para especificar que IIS realiza escuchas en ese puerto. El canal que usted configura se utiliza automáticamente para administrar solicitudes remotas enviadas en ese puerto.

Para hospedar correctamente los objetos activados en el servidor (es decir, <wellknown>) dentro de IIS, debe tener un objeto Identificador uniforme de recursos (URI) que finaliza con .rem o con .soap. Este requisito no se da para otros dominios de la aplicación host. Para utilizar la herramienta Soapsuds (Soapsuds.exe) para generar los metadatos para un objeto activado en el servidor hospedado en IIS, la dirección URL que se debe pasar como un argumento a Soapsuds.exe es la siguiente:

http://< Equipo >:< Puerto >/< VirtDir >/< ObjectURI >?wsdl

Para los objetos activados en el cliente hospedados en IIS o en cualquier otro dominio de aplicación, no necesita ningún Objeto URI de ninguna forma. La dirección URL para pasar como un argumento a Soapsuds.exe es la siguiente:

http://< Equipo >:< Puerto >/< VirtDir >/RemoteApplicationMetadata.rem?wsdl

La configuración mediante programación en IIS se hace utilizando la página Global.asax. El ejemplo siguiente muestra la misma configuración que el archivo de configuración previamente mostrado, pero utiliza el archivo Global.asax.

<%@ Application Language="VB" %>
<%@ Assembly Name="Server" %>
<%@ Import Namespace="System.Runtime.Remoting" %>
<%@ Import Namespace="System.Runtime.Remoting.Channels" %>
<%@ Import Namespace="System.Runtime.Remoting.Channels.Http" %>
<%@ Import Namespace="Server" %>

Sub Application_Start()
   Dim props = New Hashtable() As IDictionary
   props("name") = "MyChannel" 
   props("priority") = "100" 
   ' Nothing entries specify the default formatters.
   Dim channel As New HttpChannel( _
      props, _
      Nothing, _
      Nothing _
   )
   ChannelServices.RegisterChannel(channel)
   Dim WKSTE As New WellKnownServiceTypeEntry( _
      GetType(ServiceClass), _
      "HttpService", _
      WellKnownObjectMode.SingleCall
   )
   RemotingConfiguration.RegisterWellKnownServiceType(WKSTE)
End Sub

<%@ Application Language="C#" %>
<%@ Assembly Name="Server" %>
<%@ Import Namespace="System.Runtime.Remoting" %>
<%@ Import Namespace="System.Runtime.Remoting.Channels" %>
<%@ Import Namespace="System.Runtime.Remoting.Channels.Http" %>
<%@ Import Namespace="Server" %>
void Application_Start(){
   IDictionary props = new Hashtable();
   props["name"] = "MyChannel";
   props["priority"] = "100";
   // Null entries specify the default formatters.
   HttpChannel channel = new HttpChannel(
      props, 
      null, 
      null
   );
   ChannelServices.RegisterChannel(channel);
   WellKnownServiceTypeEntry WKSTE = new WellKnownServiceTypeEntry(
      typeof(ServiceClass),
      "HttpService", 
      WellKnownObjectMode.SingleCall
   );
   RemotingConfiguration.RegisterWellKnownServiceType(WKSTE);
}

Las entradas siguientes se deben colocar en el archivo Web.config para asegurarse de que se hace referencia a los ensamblados necesarios:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.web>
      <compilation>
        <assemblies>
          <add assembly="System.Runtime.Remoting, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        </assemblies>
      </compilation>
  </system.web>
</configuration>

Para obtener un ejemplo completo, vea Ejemplo de interacción remota: Hospedar en Internet Information Services (IIS).

Utilizar los certificados SSL con .NET Remoting

Los certificados identifican un equipo determinado, el nombre del cual reside en el nombre común del certificado. Sin embargo, es fácil cambiar el nombre de un equipo o utilizar "host local" en los archivos de configuración del cliente, lo que crea una desigualdad entre el cliente y el nombre común en el certificado del servidor. En la versión 1.0 de .NET Framework, se omite esta desigualdad y la llamada se invoca en el servidor.

Iniciándose con la versión 1.1 de .NET Framework, esta desigualdad produce la siguiente excepción: "System.Net.WebException: Se cerró la conexión subyacente: No pudo se establecer la relación de confianza con el servidor remoto." Si no puede configurar el cliente remoto para utilizar el nombre común del certificado, puede invalidar la desigualdad utilizando los valores siguientes en su archivo de configuración de la aplicación cliente:

<system.net>
   <settings>
      <servicePointManager
         checkCertificateName="true"
      />
   </settings>
</system.net>

Para hacer que su cliente pase por alto la desigualdad de nombre de certificado mediante programación, el cliente debe crear una instancia de una clase que implemente la interfaz ICertificatePolicy e implemente CheckValidationResult para devolver true si el valor certificateProblem es 0x800c010f. A continuación, debe registrar el objeto con el objeto System.Net.ServicePointManager pasando el objeto a la propiedad ServicePointManager.CertificatePolicy. El código siguiente es una implementación básica:

Public Class MyPolicy Implements ICertificatePolicy 
   Public Function CheckValidationResult(srvPoint As ServicePoint, certificate As X509Certificate, request As WebRequest, certificateProblem As Integer) As Boolean
      ' Check for policy common name mismatch. 
       If certificateProblem = 0 Or certificateProblem = &H800b010f Then
         Return True
      Else
         Return False
      EndIf
   End Function
End Class

public class MyPolicy : ICertificatePolicy {
   public bool CheckValidationResult(ServicePoint srvPoint, X509Certificate certificate, WebRequest request, int certificateProblem) {
      // Check for policy common name mismatch. 
      if (certificateProblem == 0 || certificateProblem == 0x800b010f)
         return true;
      else
         return false; 
   }
}

El código siguiente registra una instancia de la clase anterior con System.Net ServicePointManager:

System.Net.ServicePointManager.CertificatePolicy = New MyPolicy()

System.Net.ServicePointManager.CertificatePolicy = new MyPolicy();

Autenticación en Aplicaciones remotas hospedadas por IIS

La tabla siguiente describe la configuración que habilita ciertos tipos de comportamiento de autenticación en .NET Remoting al hospedar su servicio en Servicios de Internet Information Server (IIS).

Comportamiento deseado Valores de configuración Comentarios

El servidor autentica el cliente en cada llamada utilizando las credenciales predeterminadas del cliente.

En el servidor, seleccione Autenticación de Windows integrada y borre Acceso anónimo en IIS.

En el cliente, establezca useDefaultCredentials a true.

Éste es el comportamiento predeterminado en la versión 1.0 de .NET Framework cuando useDefaultCredentials es true.

Este comportamiento se admite en la versión 1.1 de .NET Framework si useAuthenticatedConnectionSharing también está establecido a false.

El servidor autentica una vez al cliente utilizando las credenciales predeterminadas del cliente; las llamadas subsiguientes de este cliente utilizan la conexión previamente autenticada.

En el servidor, seleccione Autenticación de Windows integrada y borre Acceso anónimo en IIS.

En el cliente, establezca useDefaultCredentials a true.

Este comportamiento solamente se admite en la versión 1.1de .NET Framework, o superiores.

El servidor autentica una vez al cliente utilizando las credenciales personalizadas o explícitas del cliente; las llamadas subsiguientes de este cliente utilizan la conexión previamente autenticada.

En el servidor, seleccione Autenticación de Windows integrada y borre Acceso anónimo en IIS.

En el cliente, establezca credentials a una implementación de ICredentials o establezca username, password y domain a los valores explícitos. En cualquier caso, debe establecer también unsafeAuthenticatedConnectionSharing a true y proporcionar un valor connectionGroupName que se asigne solamente a un usuario autenticado.

Este comportamiento solamente se admite en la versión 1.1de .NET Framework, o superiores.

Vea también

Referencia

Esquema de configuración de la comunicación remota

Conceptos

Direcciones URL de activación
Configuración de aplicaciones remotas
Ejemplo de comunicación remota: hospedar en Internet Information Services (IIS)