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.

¿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: WCF,MEX

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.

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

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.

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.

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:

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.

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.

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

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é.

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.

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

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

Etiquetas de Technorati: Windows AppFabric

Windows AppFabric p1–> Instalándolo en Windows 7

He decidido iniciar con una serie de post acerca del Windows AppFabric para crear arquitecturas distribuidas basadas en un servidor de aplicaciones en tecnologías Microsoft. Este es el primer post de la serie y para empezar he decidido utilizar Windows 7 como sistema operativo base.

Instalar el AppFabric en Windows 7

Ya que muchos utilizamos Windows 7 como sistema operativo de trabajo, o incluso existen empresas donde utilizan un pequeño servidor interno para instalar sus aplicaciones con Windows 7 Enterprise o Profesional decidí escribir este post que aunque parece repetido no lo es, ya que el anterior era acerca de instalar el AppFabric en Windows server 2008 R2 – algo mucho más complicado.

El instalador del AppFabric

Aunque podemos descargar e instalar el AppFabric para windows 7 desde el “Web Platform Installer”, yo prefiero descargarlo directamente desde el sitio de Microsoft y ejecutarlo desde mi máquina.

Como podemos ver en el sitio web de Microsoft dependiendo del sistema operativo que tengamos  debemos descargar el ejecutable establecido. En mi caso, estoy utilizando Windows 7 en 64 bits.

En la página de descargas procedemos con el archivo señalado en la imagen anterior.

Seguidamente procedemos a ejecutar el instalador y luego de la pantalla de bienvenida veremos la siguiente pantalla donde se nos pregunta que componentes deseamos instalar. En mi caso instalaré todos los componentes – por supuesto habrán más post respecto a la función de cada uno de estos componentes.

Luego se hará la comprobación de requisitos del sistema, como pueden ver en la siguiente imagen me falta un requisito para poder instalar el AppFabric.

Como ven, me falta el administrador remoto para IIS, el cual se puede descargar desde el web platform installer o desde el sitio www.iis.net. Cuando lo instalamos nos aparece el wizard de instalación.

Luego de finalizar esta instalación procedemos a darle “actualizar” a wizard del appFabric y ya podemos ver que ya no tenemos advertencias a la hora de continuar con la instalación.

Con eso procedemos a la instalación del AppFabric.

Una vez finalizada la instalación vamos a ver la pantalla de instalación completa y además una recomendación para instalar las últimas actualizaciones de Windows.

En el próximo post vamos a configurar el AppFabric para poder hacer tracking y persistencia de nuestros servicios y workflows.

Etiquetas de Technorati: AppFabric

Error TF237162: There is insufficient system memory on the Team Foundation Server SQL Server to run this query

 

El Problema

Trabajando con TFS en un máquina virtual de pruebas, me encontré este error cuando quise generar un Team project en VS 2010 para tener mis proyectos en una colección específica. Sin embargo se me presentaba el error TFS237162 y no me permitía crear los proyectos. Considerando que cuando instalo SQL Server yo le asigno el mínimo de memoria posible me di cuenta que el error podría andar por ahí.

Solución:

Para solucionar el problema solamente tuve que ir a incrementar la memoria máxima del servidor SQL Server que se usa como capa física de datos – La tenía en 64MB y la subí a 128 MB.

Luego de esto reinicié el servicio de SQL Server Express en la consola de servicios – accesible desde Windows + R  en services.msc

y los proyectos TFS ya pudieron ser creados de manera correcta.

Etiquetas de Technorati: Team Foundation Server

Error 503 Accediendo TFS

Realizando una instalación básica de TFS 2010 en Windows 7, me encontré con el error 503 "Servicio no disponible” cuando quise acceder al sitio del Team Foundation. Investigando un poco me di cuenta que hay 3 posibilidades principales para que este error este sucediendo cuando queremos acceder a la dirección del servidor.

Errores encontrados y soluciones

En primera instancia resultó que el usuario del TFS no era el mismo usuario que tenía el application pool sobre el cual corría el sitio del TFS por lo que procedí a configurar el mismo usuario para ambas acciones. En la siguiente figura se ve el usuario configurado en el administrador del TFS.

Ahora vemos el Application Pool en el IIS con el mismo usuario configurado.

El siguiente error esta relacionado con SQL Server. En mi caso el TFS no podía ver el servidor de base de datos pese a que estaba en la misma máquina. Para solucionar este problema simplemente vamos a la opción de configuración de SQL Server y habilitamos conectividad vía Pipes para la instancia de la base de datos que estamos utilizando.

El último error esta relacionado con el puerto de instalación del TFS. Normalmente este utiliza el puerto 8080 para trabajar en el IIS; sin embargo, si ya tenemos otros sitios web en este servidor IIS el puerto también será utilizado por los otros sitios web que ya fueron creados, con lo cual no puede levantar el servicio del TFS. Para cambiar esto, seleccionamos el sitio web del TFS –> “ Team Foundation Server” y en la opción de enlaces o “Bindings” cambiamos el puerto de 8080 a 8081 – pudiendo ser cualquier otro puerto.

Luego de estos tres cambios ya puedo ver el sitio del TFS.

Etiquetas de Technorati: Team Foundation Server,503

Aprendiendo WF parte 8 – Invocando métodos de otras clases en WF

Quizás la funcionalidad más común a la hora de trabajar con WF en una arquitectura n-layer sea invocar los métodos de los componentes de lógica de negocios. En este post vamos a ver como invocar un método que reside en otro componente.

El método a invocar

En primera instancia vamos a crear un método que recibe una colección de números y me devuelve los números pares. Este método estará en una clase aparte que se llamará MathHelper. El código de esta clase se puede ver en la siguiente figura:

El workflow que invoca el método BuscarPares

Ahora vamos a crear un workflow que va a requerir invocar el método BuscarPares de la clase MathHelper recién mostrada. Este workflow simplemente recibe la lista de los números enteros, los procesa – a través de la clase MathHelper – y retorna la lista solamente conteniendo números pares.

En el workflow creado por la aplicación de consola – Workflow Application – procedemos a crear dos argumentos:

• Lista de entrada: pListaEntrada
• Lista de Salida: pListaNumerosPares

Seguidamente procedemos a agregar una secuencia y luego de esto a agregar la figura que nos va a permitir invocar el método BuscarPares.

Como vemos en la figura anterior, nos falta configurar la figura InvokeMethod la cual nos va a permitir invocar el método BuscarPares en la clase MathHelper.

En este caso, tenemos tres parámetros por completar de manera visual los cuales tienen el siguiente significado:

• TargetType: Este es el tipo de la clase que se va a utilizar en el caso de que se requiera invocar un método estático.
• TargetObject: Este es el tipo de la clase que se va a utilizar en el caso de que se requiera invocar un método de instancia.
• MethodName: El nombre del método a invocar.

En nuestro caso, como vamos a trabajar con un método de instancia tenemos que completar los campos TargetObject y MethodName.

Para el caso del targetObject vamos a tener que declarar una variable del tipo MathHelper dentro del workflow e instanciarla.

La creación de la variable se hace seleccionando la secuencia lanzada al workflow y digitando la variable en la parte inferior del workflow. La variable es la siguiente:

Para inicializar esta variable – para crear la instancia – procedemos con una figura del tipo Assign tal y como se ve a continuación:

Ahora procedemos a  configurar la figura de invocar método con la variable recién creada e inicializada.

Todavía nos falta configurar los parámetros de entrada y el retorno del método que vamos a invocar, para esto vamos a las propiedades de la figura InvokeMethod y configuramos ambos ítems. Primero establecemos que el retorno de la función será asignado a la lista pListaNumerosPares.

El siguiente paso es configurar los parámetros que debe recibir el método, la lista de los números a procesar. Para esto procedemos a seleccionar la propiedad “Parameters” y le damos click en la “elipsis” –> “…”. En esta pantalla procedemos a configurar el parámetro de envío.

Como vemos en la siguiente figura del workflow completo, este ya no tiene errores.

Ahora solo nos queda probar el workflow, para esto vamos a escribir el siguiente código en el método Main.

El resultado al ejecutar el código anterior es el siguiente:

Etiquetas de Technorati: WF4

Linq: TakeWhile y OrderBy

Trabajando con Linq, me ha tocado manipular colecciones de objetos en donde se deben aplicar condiciones a grupos de objetos o procesar objetos mientras se cumpla alguna condición. Un método que sin duda me llamó la atención es el TakeWhile el cual permite procesar los elementos mientras se cumpla la condición dada, si esta condición no se cumple, se descartan todos los elementos a partir del primero que no la cumpla.

Por ejemplo, queremos procesar la lista de productos cuyo precio sea menor de 500, todo esto basado en la siguiente clase de producto.

La lista de productos a procesar es la siguiente:

Ahora para poder cumplir con la condición inicial –> procesar los productos que cuestan menos de 500 <—y considerando que el método takeWhile detiene su procesamiento cuando la condición no se cumple, debemos ordenar la lista de productos retornada por precio, luego de esto vamos a aplicar el TakeWhile. Luego procedemos a retornar la lista resultante.

Al ejecutar el código anterior obtenemos el siguiente resultado:

Etiquetas de Technorati: TakeWhile,Linq,VB.NET

Aprendiendo WF parte 7– Excepciones (1)

Continuando con nuestras serie de post acerca de WF, en esta ocasión nos vamos a enfocar en el manejo de excepciones dentro del workflow. Para esto, vamos a utilizar el workflow del post anterior para manejar las excepciones.

Provocando el error en el workflow

Nuestro ejemplo asume que la lista que viene como parámetro de entrada siempre viene inicializada, es decir ya esta instanciada, pero que pasaría si nos envía una lista nula? Para ver que pasaría vamos a cambiar el código en el programa de consola de la siguiente forma:

Ahora si ejecutamos la aplicación, vamos a obtener el siguiente mensaje de error:

Como podemos ver en la figura anterior, la excepción se lanzo desde el workflow y nosotros no tenemos la más mínima idea de lo que puede estar ocurriendo. Aquí es donde entra el manejo de excepciones.

Agregando Excepciones al Workflow

Vamos a manejar la excepción anterior dentro del workflow utilizando las actividades que workflow foundation ya tiene construidas para tal propósito. Las mismas se pueden ver en la siguiente figura:

Primero vamos a agregar una figura TryCatch para meter nuestro código dentro de este. Luego dentro de la secuencia del try vamos a agregar nuestro código para manipular las colecciones.

Como vemos en la figura anterior tenemos un error en el workflow – signo de admiración – lo cual es provocado porque no hemos configurado el catch del bloque para el manejo de errores. Para reparar este problema vamos a agregar una excepción genérica del tipo System.Exception para procesar todos los errores que se den dentro del bloque en un solo lugar.

Luego hacemos click en la superficie del workflow y nos queda a disposición el bloque de catch para manejar la excepción. En la parte derecha del bloque esta el nombre de la instancia en donde vendrá encapsulada la excepción.

Para este ejemplo simplemente vamos a relanzar la excepción y vamos a poner un mensaje un poco más “legible” para que a la hora de manejarlo del lado del cliente se tenga una mejor noción del problema. Para esto vamos a agregar una figura de rethrow y la vamos a configurar con la instanciación de una nueva excepción y de un mensaje indicando el problema de forma general.

Para esto vamos a ir a las propiedades de la figura rethrow y le vamos a agregar el siguiente código.

Ahora nuestro workflow lucirá de la siguiente manera.

El siguiente paso es manejar la excepción del lado del programa para esto vamos a agregar el siguiente código del cliente de la consola.

Cuando ejecutamos el código anterior vamos a obtener el siguiente resultado.

Etiquetas de Technorati: WF4,Exceptions