Direcciones de extremo
Cada extremo tiene una dirección asociada a él, que se utiliza para ubicar e identificar el extremo. Esta dirección está compuesta principalmente de un Identificador uniforme de recursos (URI), que especifica la ubicación del extremo. La dirección del extremo se representa en el modelo de programación de Windows Communication Foundation (WCF) mediante la clase EndpointAddress, que contiene una propiedad Identity opcional que permite la autenticación del extremo por parte otros extremos 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 extremo de servicio. La dirección de un extremo se representa en la conexión como una referencia de extremo (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 puede dividir en los siguientes elementos:
Esquema: http:
Equipo: 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 extremos 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 volver a compilar ni implementar la aplicación.
Definición de una dirección mediante configuración
Para definir un extremo en un archivo de configuración, utilice el elemento <endpoint> element. Para obtener detalles y un ejemplo, vea Especificación de una dirección de extremo.
Definición de una dirección mediante código
Una dirección de extremo se puede crear mediante código con la clase EndpointAddress. Para obtener detalles y un ejemplo, vea Especificación de una dirección de extremo.
Extremos 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 detalles y un ejemplo, vea Especificación de una dirección de extremo.
Compatibilidad de varios enlaces 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 iniciaba 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:
Con .NET Framework 3,5, especifica un filtro de prefijo en el nivel del AppDomain en el archivo de configuración. Esto se realiza mediante 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 el ejemplo anterior, net.tcp://payroll.myorg.com: 8000 y http://shipping.myorg.com: 9000 son las únicas direcciones base, para sus esquemas respectivos, 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 no presentes en la lista baseAddressPrefixFilters. Estas direcciones no se filtran.
Compatibilidad de varios enlaces IIS en .NET Framework 4
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 MultipleSiteBindingsEnabled de la clase ServiceHostingEnvironment 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 información detallada y ejemplos, vea Soportar múltiples enlaces de sitios de IIS y MultipleSiteBindingsEnabled.
Extensión del direccionamiento en servicios WCF
El modelo de direccionamiento predeterminado de los servicios de WCF usa el URI de la dirección de extremo 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 extremo 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.
Mediante configuración, los <headers><endpoint> personalizados se especifican como elementos secundarios del elemento.
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 extremo. 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 extremo 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.
Mediante configuración, especifique una dirección de escuchas personalizada con el atributo ListenUri del 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 extremo y que todos los encabezados de extremo 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.
Vea también
Conceptos
Especificación de una dirección de extremo
Identidad del servicio y autenticación