Compartir a través de

Direcciones de punto de conexión

Cada punto de conexión tiene una dirección asociada, que se usa para localizar e identificar el punto de conexión. Esta dirección consta principalmente de un identificador uniforme de recursos (URI), que especifica la ubicación del punto de conexión. La dirección del punto de conexión se representa en el modelo de programación de Windows Communication Foundation (WCF) por la EndpointAddress clase , que contiene una propiedad opcional Identity que habilita la autenticación del punto de conexión por otros puntos de conexión que intercambian mensajes con él y un conjunto de propiedades opcionales Headers , que definen cualquier otro encabezado SOAP necesario para llegar al servicio. Los encabezados opcionales proporcionan información de direccionamiento adicional y más detallada para identificar o interactuar con el punto de conexión de servicio. La dirección de un punto de conexión se representa en la conexión como una referencia de punto de conexión (EPR) WS-Addressing.

Estructura de URI de una dirección

El URI de dirección para la mayoría de los transportes tiene cuatro partes. Por ejemplo, las cuatro partes del URI http://www.fabrikam.com:322/mathservice.svc/secureEndpoint se pueden detallar de la siguiente manera:

  • Esquema: http:

  • Máquina: www.fabrikam.com

  • (opcional) Puerto: 322

  • Ruta de acceso: /mathservice.svc/secureEndpoint

Definición de una dirección para un servicio

La dirección del punto de conexión de un servicio se puede especificar de forma imperativa mediante código o mediante declaración a través de la configuración. La definición de puntos de conexión en el código no suele ser práctica porque los enlaces y direcciones de un servicio implementado suelen ser diferentes de los usados mientras se desarrolla el servicio. Por lo general, es más práctico definir puntos de conexión de servicio mediante la configuración en lugar de código. Mantener la información de enlace y direccionamiento fuera del código les permite cambiar sin tener que volver a compilar o volver a implementar la aplicación.

Definición de una dirección en la configuración

Para definir un punto de conexión en un archivo de configuración, use el <elemento endpoint> . Para obtener más información y un ejemplo, consulte Especificación de una dirección de punto de conexión.

Definir una dirección en el código

Se puede crear una dirección de punto de conexión en el código con la EndpointAddress clase . Para obtener más información y un ejemplo, consulte Especificación de una dirección de punto de conexión.

Puntos de conexión en WSDL

Una dirección de punto de conexión también se puede representar en WSDL como un elemento EPR WS-Addressing dentro del elemento wsdl:port del punto de conexión correspondiente. El EPR contiene la dirección del punto de conexión, así como cualquier propiedad de dirección. Para obtener más información y un ejemplo, consulte Especificación de una dirección de punto de conexión.

Compatibilidad con varios enlaces de IIS en .NET Framework 3.5

Los proveedores de servicios de Internet suelen hospedar muchas aplicaciones en el mismo servidor y sitio para aumentar la densidad del sitio y reducir el costo total de propiedad. Estas aplicaciones se enlazan normalmente a direcciones base diferentes. Un sitio web de Internet Information Services (IIS) puede contener varias aplicaciones. Se puede acceder a las aplicaciones de un sitio a través de uno o varios enlaces IIS.

Los enlaces de IIS proporcionan dos partes de información: un protocolo de enlace e información de enlace. El protocolo de enlace define el esquema sobre el que se produce la comunicación y la información de enlace es la información que se usa para acceder al sitio.

En el ejemplo siguiente se muestran los componentes que pueden estar presentes en un enlace de IIS:

  • Protocolo de enlace: HTTP

  • Información de enlace: Dirección IP, puerto, encabezado de host

IIS puede especificar varios enlaces para cada sitio, lo que da como resultado varias direcciones base para cada esquema. Antes de .NET Framework 3.5, WCF no admitía varias direcciones para un esquema y, si se especificaban, generaba una excepción ArgumentException durante la activación.

.NET Framework 3.5 permite a los proveedores de servicios de Internet hospedar varias aplicaciones con direcciones base diferentes para el mismo esquema en el mismo sitio.

Por ejemplo, un sitio podría contener las siguientes direcciones base:

  • http://payroll.myorg.com/Service.svc

  • http://shipping.myorg.com/Service.svc

Con .NET Framework 3.5, especifique un filtro de prefijo en el nivel de AppDomain en el archivo de configuración. Esto se hace con el <elemento baseAddressPrefixFilters> , que contiene una lista de prefijos. Las direcciones base entrantes, proporcionadas por IIS, se filtran en función de la lista de prefijos opcional. De forma predeterminada, cuando no se especifica un prefijo, se pasan todas las direcciones. Al especificar el prefijo, se provoca que solo la dirección base coincidente para ese esquema se pase a través.

A continuación se muestra un ejemplo de código de configuración que usa los filtros de prefijo.

<system.serviceModel>  
  <serviceHostingEnvironment>  
     <baseAddressPrefixFilters>  
        <add prefix="net.tcp://payroll.myorg.com:8000"/>  
        <add prefix="http://shipping.myorg.com:8000"/>  
    </baseAddressPrefixFilters>  
  </serviceHostingEnvironment>  
</system.serviceModel>

En el ejemplo anterior, net.tcp://payroll.myorg.com:8000 y http://shipping.myorg.com:8000 son las únicas direcciones base, para sus respectivos esquemas, que se pasan a través.

baseAddressPrefixFilter no admite los caracteres comodín.

Las direcciones base proporcionadas por IIS pueden tener direcciones enlazadas a otros esquemas que no están presentes en baseAddressPrefixFilters la lista. Estas direcciones no son filtradas.

Compatibilidad de varios enlaces IIS en .NET Framework 4.0 y posteriores

A partir de .NET 4, puede habilitar la compatibilidad con varios enlaces en IIS sin tener que elegir una sola dirección base mediante el establecimiento del valor de la propiedad ServiceHostingEnvironment de la clase MultipleSiteBindingsEnabled en true. Esta compatibilidad está limitada a esquemas de protocolo HTTP.

A continuación se muestra un ejemplo de código de configuración que usa multipleSiteBindingsEnabled en <serviceHostingEnvironment>.

<system.serviceModel>  
  <serviceHostingEnvironment multipleSiteBindingsEnabled="true" >  
  </serviceHostingEnvironment>  
</system.serviceModel>

Se omite cualquier configuración de baseAddressPrefixFilters, para los protocolos HTTP y no HTTP, cuando se habilitan varios enlaces de sitio mediante esta configuración.

Para obtener más información y ejemplos, consulte Soporte para múltiples vinculaciones de sitio de IIS y MultipleSiteBindingsEnabled.

Extensión del direccionamiento en servicios WCF

El modelo de direccionamiento predeterminado de los servicios WCF usa el URI de dirección del punto de conexión para los siguientes fines:

  • Para especificar la dirección de escucha del servicio, la ubicación en la que el punto de conexión escucha los mensajes,

  • Para especificar el filtro de direcciones SOAP, se debe indicar la dirección que un punto de conexión espera recibir como encabezado SOAP.

Los valores de cada uno de estos propósitos se pueden especificar por separado, lo que permite varias extensiones de direccionamiento que abarcan escenarios útiles:

  • Intermediarios SOAP: un mensaje enviado por un cliente atraviesa uno o varios servicios adicionales que procesan el mensaje antes de que llegue a su destino final. Los intermediarios SOAP pueden realizar diversas tareas, como el almacenamiento en caché, el enrutamiento, el equilibrio de carga o la validación de esquemas en los mensajes. Este escenario se logra enviando mensajes a una dirección física independiente (via) que tiene como destino el intermediario en lugar de simplemente a una dirección lógica (wsa:To) que tiene como destino el destino final.

  • La dirección de escucha del punto de conexión es un URI privado y se establece en un valor diferente al de su listenURI propiedad.

La dirección de transporte que via especifica es la ubicación a la que se debe enviar inicialmente un mensaje en su camino a alguna otra dirección remota especificada por el parámetro en el to que se encuentra el servicio. En la mayoría de los escenarios de Internet, el via URI es el mismo que la Uri propiedad de la dirección final to del servicio. Solo distingue entre estas dos direcciones cuando debe realizar el enrutamiento manual.

Encabezados de direccionamiento

Un punto de conexión puede ser direccionado mediante uno o varios encabezados SOAP además de su URI básico. Un conjunto de escenarios en los que esto resulta útil es un conjunto de escenarios de intermediarios SOAP en los que un punto de conexión requiere que sus clientes incluyan encabezados SOAP dirigidos a intermediarios.

Puede definir encabezados de dirección personalizados de dos maneras: mediante código o configuración:

  • En el código, cree encabezados de dirección personalizados mediante la clase AddressHeader, y luego se utiliza en la construcción de un EndpointAddress.

  • En la configuración, los <encabezados> personalizados se especifican como elementos secundarios del elemento <endpoint>.

La configuración suele ser preferible al código, ya que permite cambiar los encabezados después de la implementación.

Direcciones de escuchas personalizadas

Puede establecer la dirección de escucha en un valor diferente al URI del punto de conexión. Esto es útil en escenarios intermedios en los que la dirección SOAP que se va a exponer es la de un intermediario SOAP público, mientras que la dirección en la que el punto de conexión realmente escucha es una dirección de red privada.

Puede especificar una dirección de escucha personalizada mediante código o configuración:

  • En el código, especifique una dirección de escucha personalizada agregando una ClientViaBehavior clase a la colección de comportamientos del punto de conexión.

  • En la configuración, especifique una dirección de escucha personalizada utilizando el atributo ListenUri del elemento de punto de conexión de servicio<>.

Filtro de direcciones SOAP personalizado

Uri se usa junto con cualquier Headers propiedad para definir el filtro de direcciones SOAP de un punto de conexión (AddressFilter). De forma predeterminada, este filtro comprueba que un mensaje entrante tiene un To encabezado de mensaje que coincide con el URI del punto de conexión y que todos los encabezados de punto de conexión necesarios están presentes en el mensaje.

En algunos escenarios, un punto de conexión recibe todos los mensajes que llegan al transporte subyacente y no solo los que tienen el encabezado adecuado To . Para habilitar esto, el usuario puede usar la MatchAllMessageFilter clase .

Consulte también