Direcciones de extremo
Cada punto de conexión tiene una dirección asociada a él, que se utiliza para ubicar e identificar el punto de conexión. Esta dirección está compuesta 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) con la clase EndpointAddress, que contiene una propiedad Identity opcional que permite la autenticación del punto de conexión por parte de otros puntos de conexión que intercambian mensajes con él, y un conjunto de propiedades Headers opcionales, que definen cualquier otro encabezado SOAP requerido para alcanzar el 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 URI de una Dirección
El URI de la dirección de la mayoría de transportes tiene cuatro partes. Por ejemplo, las cuatro partes del URI http://www.fabrikam.com:322/mathservice.svc/secureEndpoint se pueden desglosar del siguiente modo:
Scheme (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 de extremo de un servicio puede especificarse de manera imperativa mediante código o de manera declarativa mediante configuración. Normalmente, no resulta muy práctico definir los puntos de conexión en el código ya que los enlaces y las direcciones de un servicio implementado son, por lo general, diferentes de los utilizados durante el desarrollo del servicio. Generalmente, es más práctico definir extremos de servicio mediante la configuración en lugar del código. Mantener la información del enlace y el direccionamiento fuera del código permite cambiar los extremos sin tener que recompilar ni implementar la aplicación.
Definición de una dirección mediante 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.
Definición de una dirección mediante código
Una dirección de punto de conexión se puede crear mediante código con la clase EndpointAddress. 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 extremo también se puede representar en WSDL como un elemento EPR de WS-Addressing dentro del elemento wsdl:port del extremo correspondiente. El EPR contiene la dirección del extremo, así como todas las propiedades de la 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 acceso a Internet a menudo hospedan muchas aplicaciones en el mismo servidor y en el mismo sitio para aumentar la densidad del sitio y reducir el costo total de propiedad. Estas aplicaciones se enlazan normalmente en las diferentes direcciones base. Un sitio web de Internet Information Services (IIS) puede contener varias aplicaciones. Se puede tener acceso a las aplicaciones en un sitio a través de uno o más enlaces de 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 utilizada para tener acceso al sitio.
El siguiente ejemplo muestra los componentes que se pueden encontrar 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, que resulta en 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, se producía una excepción ArgumentException durante la activación.
.NET Framework 3.5 permite a los proveedores de acceso a Internet hospedar varias aplicaciones con direcciones base diferentes para el mismo esquema en el mismo sitio.
Por ejemplo, un sitio podría contener las direcciones base siguientes:
http://payroll.myorg.com/Service.svchttp://shipping.myorg.com/Service.svc
Con .NET Framework 3.5, se especifica un filtro de prefijo en el nivel AppDomain en el archivo de configuración. Esto se hace con el elemento <baseAddressPrefixFilters>, que contiene una lista de prefijos. Las direcciones base de entrada, proporcionadas por IIS, se filtran en función de la lista de prefijos opcional. De forma predeterminada, cuando no se especifica un prefijo, se atraviesan 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 utiliza filtros de prefijos.
<system.serviceModel>
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="net.tcp://payroll.myorg.com:8000"/>
<add prefix="http://shipping.myorg.com:8000"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
</system.serviceModel>
En este ejemplo, se pasan net.tcp://payroll.myorg.com:8000 y http://shipping.myorg.com:8000, que son las únicas direcciones base para sus respectivos esquemas.
baseAddressPrefixFilter no admite los caracteres comodín.
Las direcciones base proporcionadas por IIS pueden tener direcciones enlazadas a otros esquemas no presentes en la lista baseAddressPrefixFilters. Estas direcciones no se filtran.
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 se limita a los esquemas del protocolo HTTP.
En el ejemplo siguiente, se muestra el código de configuración que usa multipleSiteBindingsEnabled en <serviceHostingEnvironment>.
<system.serviceModel>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" >
</serviceHostingEnvironment>
</system.serviceModel>
Cuando se habilitan varios enlaces de sitios mediante esta configuración, se ignora cualquier configuración de baseAddressPrefixFilters, tanto para el protocolo HTTP como para el protocolo no HTTP.
Para obtener más información y ejemplos, consulte Compatibilidad con varios enlaces 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 la dirección de punto de conexión para los siguientes fines:
Para especificar la dirección del agente de escuchas de servicio, la ubicación en la que el extremo realiza escuchas de mensajes,
Para especificar el filtro de dirección de SOAP, la dirección que espera un punto de conexión como un encabezado SOAP.
Se pueden especificar los valores de cada uno de estos propósitos por separado, permitiendo varias extensiones de direccionamiento que cubren escenarios útiles:
Intermediarios SOAP: un mensaje enviado por un cliente atraviesa uno o más servicios adicionales que procesan el mensaje antes de que alcance su destino final. Los intermediarios SOAP pueden realizar varias tareas, como almacenar en memoria caché, enrutar, equilibrar la carga o validar el esquema en los mensajes. Para lograr este escenario, los mensajes se envían a una dirección física independiente (
via) que hace referencia al intermediario en lugar de simplemente a una dirección lógica (wsa:To) que hace referencia al destino final.La dirección que realiza escuchas del extremo es un URI privado y está establecida en un valor diferente del de su propiedad
listenURI.
La dirección de transporte especificada por via es la ubicación a la que se debería enviar inicialmente un mensaje de camino a alguna otra dirección remota especificada por el parámetro to donde se encuentra el servicio. En la mayoría de los escenarios de Internet, el URI via es igual que la propiedad Uri de la dirección final to del servicio. Estas dos direcciones solo se pueden distinguir cuando es necesario el enrutamiento manual.
Encabezados de direccionamiento
Uno o más encabezados SOAP pueden direccionar un extremo además de su URI básico. Un conjunto de escenarios donde esto es útil es un conjunto de escenarios intermediarios de SOAP donde un extremo requiere que los clientes de ese extremo incluyan encabezados SOAP destinados a intermediarios.
Puede definir encabezados de dirección personalizados de dos maneras: mediante código o mediante configuración:
Mediante código, los encabezados de dirección personalizados se crean usando la clase AddressHeader y, a continuación, se utilizan en la construcción de una clase EndpointAddress.
En la configuración, los encabezados personalizados (<headers>) se especifican como elementos secundarios del elemento <endpoint>.
Generalmente, la configuración es preferible al código, puesto que permite cambiar los encabezados después de la implementación.
Direcciones de escuchas personalizadas
Puede establecer la dirección de escuchas en un valor diferente que el URI del punto de conexión. Esto es útil en escenarios intermediarios donde la dirección SOAP que se va a exponer es la de un intermediario de SOAP público, mientras que la dirección donde el punto de conexión realmente realiza escuchas es una dirección de la red privada.
Puede especificar una dirección de escuchas personalizada mediante código o configuración:
Mediante código, especifique una dirección de escuchas personalizada agregando una clase ClientViaBehavior a la colección de comportamientos del extremo.
En la configuración, especifique la dirección de una escucha personalizada con el atributo
ListenUridel elemento <endpoint> del servicio.
Filtro de direcciones SOAP personalizado
Uri se utiliza junto con cualquier propiedad Headers para definir el filtro de direcciones SOAP de un extremo (AddressFilter). De forma predeterminada, este filtro comprueba que un mensaje entrante tenga un encabezado de mensaje To que coincida con el URI del punto de conexión y que todos los encabezados de punto de conexión necesarios se encuentren en el mensaje.
En algunos escenarios, un extremo recibe todos los mensajes que llegan en el transporte subyacente y no solo aquéllos con el encabezado To adecuado. Para habilitar esto, el usuario puede utilizar la clase MatchAllMessageFilter.