1.22.2012

WCF: ¿Qué es el metadata exchange - MEX?

Para los que trabajamos a diario con WCF este tema nos puede parecer simple y sencillo de comprender; sin embargo, en ocasiones me encuentro con desarrolladores que pese a que utilizan WCF muy seguido no saben el porque de este endpoint en el archivo de configuración. En este post vamos a aclarar el término y su importancia.

¿Qué es el metadata exchange - MEX?

El endopoint MEX es la manera en que se publica el metadata del servicio. ¿ Y que es este metadata? El metadata del servicio es la información que consumen los clientes para crear el proxy del servicio y así poder llamar el servicio. En otras palabras, cuando accedemos un servicio desde un cliente lo hacemos a través de un proxy – una clase – que se genera a partir del metadata del servicio – más acerca del proxy en el próximo post.

image

¿Es el MEX lo mismo que el WSDL?

Ahora, si hemos usado servicios web desde antes de que WCF entrara a escena nos va a surgir la pregunta ¿Es el MEX lo mismo que el WSDL del servicio? La respuesta es si y no. En realidad el WSDL y el MEX cumplen la misma función pero el MEX es la nueva versión de lo que antes era el WSDL – más al respecto en este link. En otras palabras, el MEX endpoint no es algo definido por Microsoft, si no más bien un estándar establecido por la W3C para exponer la metadata del servicio. El “no”, esta relacionado con el hecho de que aunque los dos hacen lo mismo lo hacen de diferente forma; siendo la principal diferencia el hecho de que el metadata expuesto a través del MEX se obtiene en menos viajes al servidor que si se hace utilizando el WSDL – en realidad para el MEX solo se requiere un viaje en cambio para el WSDL requiere de varios request para obtener todas las partes de la descripción del mensaje. Además el metadata con el MEX se puede exponer a través de más protocolos que el WSDL el cual solo soportaba HTTP(S).

¿Cuáles tipos de MEX tengo disponibles en WCF?

Existen muchos tipos de MEX en WCF, entre los que podemos mencionar MexHttpBinding, MexHttpsBinding, MexTcpbinding. Como podemos ver, la variación que existe esta relacionada a través del protocolo sobre el cual queremos exponer la metadata del servicio.

Etiquetas de Technorati: ,

1.03.2012

Windows AppFabric p2–> Configurando los servicios de WCF y WF

En el post anterior conversamos acerca de la instalación del Windows AppFabric en Windows 7. En este post vamos a configurar el AppFabric para que estén disponibles las funcionalidades de seguimiento, persistencia y caché distribuido.

Configurar el AppFabric

Para configurar el AppFabric tenemos que buscar la aplicación que nos permite llevar a cabo esta tarea, la cual se puede encontrar en el folder del Windows Server AppFabric en el menú de programas.

image

Cuando se ejecuta esta aplicación aparece el wizard para iniciar la configuración del Windows AppFabric.

image

El primer paso es configurar el monitoreo de los servicios y los workflows y luego establecer la configuración de la persistencia. Primero procedemos a configurar el monitoreo de los servicios y lo hacemos seleccionando la opción establecer la configuración de seguimiento o en inglés “Set monitoring configuration”. Luego seleccionamos el proveedor que vamos a utilizar para guardar la información de configuración – SQL Server en este caso - y luego seleccionamos Configurar.

image

En la pantalla de configuración para el seguimiento procedemos a seleccionar las opciones “registrar almacén de seguimiento en web.config” e “inicializar almacén de seguimiento”. En ambos casos estamos diciéndole al wizard que registre o cree la base de datos en SQLExpress y que ponga la configuración en el archivo config raíz para que todos los servicios puedan verla. Además vamos a crear la información para la cadena de conexión y le vamos a indicar como queremos que se llame la base de datos de seguimiento para que el wizard la construya si no existe. Por último, podemos verificamos los usuarios a los que les quedamos dar los permisos de administradores, lectores de la información generada y los editores de esta información.

image

Una vez finalizado le damos aceptar y se procederá con el procedimiento de configuración. Cuando la etapa esté lista nos aparece el siguiente mensaje:

image

En la pantalla inicial del wizard podemos ver que la configuración de este componente esta correcta. Ahora procedemos con la configuración de la persistencia de los workflows la cual es muy similar a la del seguimiento; aquí seleccionamos el proveedor de persistencia que queremos usar – sql server en este caso – y seleccionamos configurar.

image

Al igual que en el caso anterior procedemos a seleccionar las opciones marcadas en la siguiente pantalla para crear la configuración del servicio, la base de datos y el string de conexión general para las aplicaciones.

image

El resultado de la operación se verá a través del mensaje lanzado desde el wizard.

image

El siguiente ítem a configurar es el manejo del caché distribuido. Este es muy importante si las aplicaciones van a estar en un clúster y queremos crear un caché que nos permita reutilizar toda la información que deseamos tener de forma mucho más rápida que ir al repositorio. En este caso seleccionamos el proveedor de XML, ya que el proveedor de SQL Server solo funciona en una máquina que pertenezca a un dominio. También debemos seleccionar el tamaño del clúster con el que vamos a utilizar el caché. Luego de esto seleccionamos la opción configurar en el proveedor de configuración del caché.

image

Es importante indicar que el UNC del archivo XML debe de ser un directorio compartido. Ahora seleccionamos siguiente y nos aparece la opción de configurar el caché. Este paso lo dejamos así ya que es una característica que no vamos a utilizar inicialmente con el AppFabric.

image

La última pantalla nos permite iniciar el IIS para verificar que las opciones del IIS están configuradas y funcionando.

image

Ya en el IIS podemos verificar que tenemos las opciones de persistencia y seguimiento como válidas y disponibles.

image

Etiquetas de Technorati: