WCF – EndPoints

Introducción

l  Describen la ubicación de un servicio.

l  Asociados a una dirección y a un contrato del servicio.

l  Un servicio debe proveer al menos un endpoint para ser accesible.

l  También pueden proveer acceso a la metadata de un servicio.

Cumplen una función básica pero fundamental si hablamos de aplicaciones distribuidas, ya que éstos informan dónde se encuentra el servicio y, de esta forma, un cliente puede hacer uso del servicio.

Se encuentran ligados a una dirección y un contrato del servicio. Éstas son las partes que los componen.

Un servicio, para poder funcionar como tal, siempre deberá exponer al menos un endpoint y podrá contener más de uno.

También permitirá acceder a la información de la metadata del servicio mediante otro tipo de endpoint.

l  Compuestos por: Address + Binding + Contract.

l  Punto de acceso del servicio.

l  Debe existir al menos uno por servicio.

Un servicio debe proveer al menos un endpoint para que éste sea accesible, y puede tener múltiples endpoints. Un ejemplo de servicio simple se compone de un solo endpoint, un solo Service Contract y un solo binding, a diferencia de un servicio complejo, que podría tener numerosos endpoints, bindings y contracts.

Diseño de un endpoint

Cuando tenemos un contract y un binding en nuestro servicio, podemos designar un endpoint. Esto implica que se deberá seleccionar una dirección (por ejemplo, http://www.miaplicacion.com/servicio/) y asociarla al Service Contract y al binding que se seleccionaron previamente.

Esto puede ser realizado especificándolo en el archivo de configuración.

¿Qué son las address?

Las address representan la ubicación del endpoint de un servicio. La información de una address consta de los siguientes datos:

* El protocolo de transporte para utilizar:

                Qué protocolo de transporte se usará (TCP, HTTP).

* El nombre de la máquina donde está corriendo el servicio.

                Nombre del “target”, máquina donde se encuentra corriendo el servicio.          

* La ruta de acceso a la máquina que identifica el servicio específico al que se accederá.

                Ruta completa de acceso a la máquina donde se encuentra el servicio.

Tipos de address

Se encuentran distintos tipos de direcciones.

Endpoint Address: es la dirección del endpoint de un servicio al que un cliente puede acceder para utilizar el servicio. Por ejemplo, podría darse de la siguiente manera: http://localhost:8000/MiServicio/.

Un cliente podría dar con ese endpoint address para utilizar el servicio “Miservicio”.

MEX Address: es la dirección de intercambio de metadata. Una endpoint address del tipo HTTP a la cual puede accederse para obtener información del servicio; por ejemplo, http://localhost:8000/MiServicio/. Un cliente puede dar, en este caso, con la MEX address para obtener información del servicio “MiServicio”.

Base Address: es la dirección primaria asociada a un servicio, utilizando una dirección base.

Formatos de address

Existen varios tipos de formatos de direcciones.  Estos formatos están sujetos al tipo de transporte que utilicemos.

La primera parte de una dirección es el esquema que identifica el transporte. El entorno de hosting (donde se alojará el servicio) usualmente impone reglas en el formato de las direcciones.

La persona que desarrolla un servicio selecciona la dirección para los endpoints de éste. El cliente que quiera acceder deberá saber la dirección del endpoint para poder hacer uso del servicio.

Las direcciones deberán ser especificadas mediante código o un archivo de configuración.

l  HTTP Addresses: De uso más frecuente, utilizan protocolo HTTP.

l  HTTPS Addresses: Acceso seguro, utilizan sockets SSL.

l  TCP Addresses: Utilizan protocolo TCP (el esquema net.tcp)

l  Named Pipe Addresses: Utilizan el esquema net.pipe

Con Named Pipe se encuentran 2 diferencias para tener en cuenta:

– La comunicación no puede establecerse a través de distintas máquinas, no es “cross machine”.

– En segundo lugar, los números de puerto son relevantes.

Un ejemplo de dirección Named Pipe podría ser el siguiente:

Net.pipe://localhost/Servicio.

MSMQ Addresses

Las direcciones MSMQ utilizan el esquema net.msmq.

Net.msmq:// nombre-maquina/ tipo de cola / nombre de cola

La estructura difiere de las mencionadas anteriormente.

IIS Addresses

Los servicios que son alojados en IIS siguen un esquema de direccionamiento distinto.

La dirección debe incluir el nombre de un directorio virtual y el archivo .SVC.

Diferente esquema de direccionamiento

http:// nombre-maquina [:puerto] [/ruta directorio virtual] arvhivo.svc 

specificando direcciones endpoint

Mediante código, las direcciones de endoints se pueden especificar de varias maneras. Las direcciones pueden ser del tipo string, Uri o EndpointAddress.

Ejemplo: Mediante código:

Uri address = new Uri("http://localhost:8000/Servicio/Prueba");

            ServiceHost<wcfTesting> service = new ServiceHost<wcfTesting>();

            service.AddEndpoint(typeof(Iwcftest), binding, address);

Ejemplo: Mediante  un archivo de configuración

<endpoint configurationName= “EjemploEndpoint” address= “http://www.miaplicacion.com/servicio/service.svcbinding= “wsProfileDualHttpBinding” contract=“ISampleContact" />

Es importante aclarar que, en ambos casos, las direcciones pueden ser relativas o absolutas.

Publicando y exportando metadata

Importando y exportando metadata con Svcutil

l  Herramienta Svcutil

Ø  Generar código de la metadata de un servicio desde el endpoint de un servicio MEX activo.

Ø  Generar código de la metadata de un servicio leyendo un WSDL y archivos XSD.

Ø  Generar metadata del servicio WSDL y archivos XSD desde el assembly de un servicio.

WCF provee una herramienta disponible para ser utilizada por consola, que permite la importación y la exportación de la metadata de un servicio.

Como puede verse, esta herramienta tiene distintas utilidades y, a su vez, puede recibir algunos parámetros opcionales al utilizarla.

Demo: Generando WSDL y archivos XSD desde el assembly de un servicio:

Una vez que contamos con nuestro servicio compilado, svcutil puede generar los archivos de metadata desde el servicio.

Ejecutar la línea de comando: svcutil miServicio.dll

Controlando la publicación en un archivo de configuración

La publicación de la metadata se puede controlar dentro de un archivo de configuración utilizando el elemento <metadataPublishing>.

Este elemento, que se incluye dentro del elemento <behavior>, contiene tres propiedades:

         enableGetWsdl: si se encuentra en true, esta propiedad provoca que el servicio responda a un pedido HTTP GET para la dirección del servicio con el sufijo ?wsdl.

         enableHelpPage: si se encuentra en true, esta propiedad provoca que se muestre una página de ayuda una vez que el servicio es accedido a través del browser.

          enableMetadataExchange: si se encuentra en true, esta propiedad expone un MEX para el servicio.

Controlando las propiedades en el behavior

En este ejemplo puede observarse cómo, a través de un behavior, se configuran las tres propiedades disponibles, y de esta forma se logra controlar la publicación de la metadata.

<behavior>

      <behavior configurationName="miServicioBehavior">

            <metadataPublishing enableGetwsdl="false"

                  enableHelpPage="false"

                  enableMetadaExchange="false" />

      </behavior>

</behavior>

 

MEX Endpoints

Como se mencionó anteriormente, los endpoints del tipo MEX (Metadata Exchange Endpoint) cumplen la función de exponer información de la metadata de un servicio.

A éstos se puede acceder mediante HTTP, como lo muestra el ejemplo.

Un cliente puede acceder a nuestro MEX endpoint y, así, obtener información sobre el servicio que se encuentre publicado

 

About justindeveloper

I am MCP (Microsoft Certified Professional). MCTS (Microsoft Certified Technology Specialist) and MCPD (Microsoft Certified Professional Developer), also I am SAP Business One Certified!! Desarrollando desde el IDE de Visual Studio NET 2003 hasta ahora con el Visual Studio NET 2010. Desde Microsoft SQL Server 2000 hasta ahora con el Microsoft SQL Server 2008 R2 y tambien con SharePoint, desde WSS 3.0 y MOSS 2007 y ahora familirizandome con el Sharepoint Foundation 2010 & Sharepoint Server 2010. The software development will follow being every time more wonderful!
This entry was posted in Development. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s