Escenario

Estamos trabajando en un proyecto de plataforma de reportes basada en SSRS [2] el cual tendrá una gran cantidad de usuarios por lo que debemos tomar medidas para asegurar buenos tiempos de respuestas con la infraestructura que tenemos. La idea es evitar tener que hacer Render de los reportes cada vez que los usuarios demandan los distintos informes.

En este Post voy a exponer opciones de mitigación de problemas de desempeño en SSRS en escenarios de alto desempeño. Mi fuente de información para este post es el libro de potente libro de Rodney Landrum y Walter Voytek [1]

Cuando se propone una solución de informes basada en un servidor de reportes versus la construcción programática ad hoc de reportes se busca el obtener diferentes beneficios tales como reutilización, control de acceso consistente, desempeño, etc.

En el aspecto de desempeño hay que entender que en una solución de informes de negocio, no todos los informes tienen una variabilidad de los datos tal que sea necesario construirlo cada vez que un usuario lo requiere. En este tipo de informes es donde se puede aplicar técnicas de mitigación para cuidar el desempeño de la solución de informes.

Opciones de Mitigación

Para los informes que tienen datos que no tienen una taza de cambios muy alta podemos aplicar las siguientes técnicas de mitigación de problemas de performance.

1. Ejecución agendada de Reportes
2. Servicio de subscripción de reportes
3. Instantáneas (snapshots)
4. Caching de Contenido

Ejecución Agendada de Reportes

La idea es programar la ejecución de reportes en momentos predeterminados. Es el servidor quien ejecuta la consulta y genera el informe sin necesidad de intervención del usuario. Estos informes pueden ser almacenados en el servido y así mantener una perspectiva histórica de los datos.

En la siguiente figura se muestra la página de configuración de los reportes agendados.

Ahora, como el reporte se ejecuta por el servicio (usando SQL Server Agent[3]) sin intervención de humanos , los parámetros del informe deben contener valores por defecto o soportar nulos.

El beneficio de usar reportes agendados es que cuando un usuario carga el informe, ve una “foto” que está ya calculado y formateado por lo que la respuesta es “instantánea”.

Instantáneas (SnapShots)

Esta alternativa consiste en almacenar una foto estática del informe. Existen dos tipos de SnapShots:

1. Los que generan una foto del informe en un momento determinado
2. Los que generan fotos históricas del informe en diferentes momentos

Los beneficios de performance de utilizar está técnica son que el reporte ya está pre procesado y que no necesita hacer consultas a la base de datos. La siguiente imagen muestra la configuración del SnapShots.

Caching de Contenido

Está técnica es utilizada cuando los diferentes usuarios ven informes con datos que dependen de parámetros que ellos ingresan. En este caso, el contenido agendado no aplica porque genere el mismo resultado para todos los usuarios. El manejó de Cache de SSRS permite mantener copias de los reportes para cada informe las cuales se generan la primera vez que el cliente ve el informe. Las subsecuentes veces que se pide el informe y si ciertas condiciones coinciden el informe no se vuelve a generar sino que se usa la copia del Cache.

Las condiciones en la cuales un usuario recibirá un informe desde el Cache son:

1. EL usuario subsecuente accede al informe antes que el tiempo de expiración de la copia del Cache se cumpla. Pasado ese tiempo el informe vuelve a calcularse y generar una nueva copia en el Cache.
2. Si los parámetros del informe que el usuario está accediendo cambian, este reporte se calcula y genera una nueva copia en el Cache.
3. El informe de la fuente de datos no está configurado para la autenticación de Windows o pregunte al usuario las credenciales de inicio de sesión

Esta técnica es muy buena para proteger el desempeño de reportes que consumen muchos recursos al hacer el Render. El Trade-Off es que no se pueden usar en informes que tienen datos sensibles en el tiempo, por ejemplo valores de la bolsa en horario de transacciones.Otro tema importante es preocuparse tanto en Cache como SnapShots es el uso de disco. La siguiente imagen es la configuración del Cache.

Servicio de Subscripción de Reportes

A diferencia de las otras tres técnicas presentadas en este Post, este servicio permite calcular los informes y enviarlo a los usuarios subscritos. Hacer esto evita que los usuarios vayan el servidor de informes y pedir su informe sino que el servicio se los envía. Las opciones de envío son las siguientes:

1. Poner una copia en un lugar específico
2. Envió por mail
3. En algún sitio compartido en la red
4. Incluso directo a la impresora

Usar está técnica tiene el beneficio de poder producir los reportes fuera de horarios punta ayudando así a evitar posibles denegación de servicios por sobrecarga de trabajo. Los informes pueden ser generados en diferentes formatos siendo el formato por defecto el Web Archive, pero podría ser otro como una imagen TIF o un PDF.

Podemos trabajar con dos tipos de subscripciones:

Standard Subscriptions: Es una configuración estática para uno o mas usuarios. Los parametros son los mismos para todos.

Data-driven subscriptions: La lista de suscripción es dinámica y puede ser resultado de una consulta. Esta es la forma más potente de trabajo, pero solo está disponible en la versión Enterprise de SQL.

Referencias

[1] Pro SQL Server 2005 Reporting Services

[2] SSRS

[3] SQL Server Agent

Como les comenté hace un tiempo (aquí) no puedo permitir que la gente haga comentarios en este BLOG porque los Chinos me llenan de SPAM.

Escribí hace un tiempo un POST de cómo hacer servicios Windows usando C# (aquí). Recibí la siguiente pregunta a través de un mensaje privado, como es interesante la comparto con ustedes.

La respuesta a la pregunta es Sí!!!!

Para hacerlo te recomiendo que el servicio levante en EndPoint de Windows Comunication Foundation y exponga la funcionalidad del servicio Windows como un servicio WCF. Es lo más simple ¿Se entiende? O es necesario un ejemplo?

Salu2

El gran parte del éxito de un proyecto de software, en empresas de desarrollo, se basa en su forma de trabajo. Esta metodología que usan les sirve para que los miembros del equipo sepan que deben hacer y cuando. Existen muchas metodologías de todos los sabores y colores, en mi opinión todas suman dependiendo del contexto hay que optar por la más eficaz.

Ahora, en los proyecto de minería de datos al igual que en los proyectos de cualquier cosa es necesario seguir una forma de trabajo, es decir una metodología. Aquí les comparto la metodología CRISP –DM, que es libre y se hace cargo de definir cómo y cuando las cosas deben ser hechas.

Al igual que cualquier metodología es un modelo y no un manual de corta palos, ustedes deben adecuarla a la realidad de su propio entorno.

CRISP-DM

La metodología CRISP-DM consta de cuatro niveles de abstracción, organizados de forma jerárquica en tareas que van desde el nivel más general hasta los casos más específicos.

A nivel más general, el proceso está organizado en seis fases, estando cada fase a su vez estructurada en varias tareas generales de segundo nivel. Las tareas generales se proyectan a tareas específicas, donde se describen las acciones que deben ser desarrolladas para situaciones específicas. Así, si en el segundo nivel se tiene la tarea general “limpieza de datos”, en el tercer nivel se dicen las tareas que tienen que desarrollarse para un caso específico, como por ejemplo, “limpieza de datos numéricos”, o “limpieza de datos categóricos”. El cuarto nivel, recoge el conjunto de acciones, decisiones y resultados sobre el proyecto de Data Mining específico.

La metodología CRISP-DM estructura el ciclo de vida de un proyecto de Data Mining en seis fases, que interactúan entre ellas de forma iterativa durante el desarrollo del proyecto.

La primera fase análisis del problema, incluye la comprensión de los objetivos y requerimientos del proyecto desde una perspectiva empresarial, con el fin de convertirlos en objetivos técnicos y en una planificación.

La segunda fase de análisis de datos comprende la recolección inicial de datos, en orden a que sea posible establecer un primer contacto con el problema, identificando la calidad de los datos y estableciendo las relaciones más evidentes que permitan establecer las primeras hipótesis.

Una vez realizado el análisis de datos, la metodología establece que se proceda a la preparación de los datos (tercera fase), de tal forma que puedan ser tratados por las técnicas de modelado. La preparación de datos incluye las tareas generales de selección de datos a los que se va a aplicar la técnica de modelado (variables y muestras), limpieza de los datos, generación de variables adicionales, integración de diferentes orígenes de datos y cambios de formato.

La fase de preparación de los datos, se encuentra muy relacionada con la fase de modelado (cuarta fase), puesto que en función de la técnica de modelado que vaya a ser utilizada los datos necesitan ser procesados en diferentes formas. Por lo tanto las fases de preparación y modelado interactúan de forma sistemática. En la fase de modelado se seleccionan las técnicas de modelado más apropiadas para el proyecto de Data Mining específico. Las técnicas a utilizar en esta fase se seleccionan en función de los siguientes criterios:

• Ser apropiada al problema.
• Disponer de datos adecuados.
• Cumplir los requerimientos del problema.
• Tiempo necesario para obtener un modelo.
• Conocimiento de la técnica.

Antes de proceder al modelado de los datos se debe de establecer un diseño del método de evaluación de los modelos, que permita establecer el grado de bondad de los modelos. Una vez realizadas estas tareas genéricas se procede a la generación y evaluación del modelo. Los parámetros utilizados en la generación del modelo dependen de las características de los datos.

En la quinta fase, la fase de evaluación, se evalúa el modelo, no desde el punto de vista de los datos, sino del cumplimiento de los criterios de éxito del problema. Se debe revisar el proceso seguido, teniendo en cuenta los resultados obtenidos, para poder repetir algún paso en el que, a la vista del desarrollo posterior del proceso, se hayan podido cometer errores. Si el modelo generado es válido en función de los criterios de éxito establecidos en la primera fase, se procede a la explotación del modelo.

Normalmente los proyectos de Data Mining no terminan en la implantación del modelo (sexta fase), sino que se deben documentar y presentar los resultados de manera comprensible en orden a lograr un incremento del conocimiento. Además en la fase de explotación se debe de asegurar el mantenimiento de la aplicación y la posible difusión de los resultados.

Fase 1 Entendimiento del Negocio

Esta fase se centra en la comprensión de los objetivos del proyecto y los requisitos desde una perspectiva de negocio, a continuación, convertir ese conocimiento en una definición de una solución de minería datos y un plan preliminar para lograr los objetivos del negocio.

Las tareas de esta fase con las siguientes:

1. Determinar los objetivos del negocio: comprender completamente desde la perspectiva del negocio lo que el cliente realmente quiere. Además, se deben identificar factores importantes que puedan influir en el desarrollo del proyecto, al principio del mismo. En resumen evitar gastar mucho tiempo respondiendo correctamente a las preguntas de negocio incorrectas.

2. Evaluar la situación: darse cuenta de la real situación del escenario dónde se realizará el proyecto.

3. Determine las metas del proyecto BI: en esta actividad se busca expresar los objetivos de negocio del proyecto en términos técnicos.

4. Elaborar el plan del proyecto: construir el plan para alcanzar los objetivos de minería de datos y los objetivos de negocio. Este plan debe describir las actividades y pasos a seguir durante el resto del proyecto, incluyendo la selección inicial de herramientas y tecnologías.

Fase 2 Entendimiento de los Datos

Esta fase se inicia con una primera recopilación de datos y procede con las actividades específicas a fin de familiarizarse con los datos, para identificar problemas de calidad de los datos, primero para descubrir una visión de los datos o para detectar subconjuntos interesantes para formar las hipótesis de información oculta.

Las tareas de esta fase con las siguientes:

1. Recopilar los Datos iníciales: obtener los datos relevantes para este proyecto. Puede ser necesario cargar estos datos para poder revisarlos bien y lograr entender en que estado se encuentran.

2. Descripción de los Datos: describir los datos, sus propiedades y sus medidas. Se elabora un informe de esto.

3. Revisar los Datos: esta tarea aborda los aspectos de BI del proyecto los cuales pueden abordarse con consultas, visualización y presentación de informes.

4. Verificar la calidad de datos: examinar la calidad de los datos, buscando validar la completitud y veracidad de los datos.

Fase 3 Preparación de los datos

Cubre todas las actividades encaminadas a construir los datos finales a partir de los datos en bruto. Las tareas de preparación de datos probablemente se realizan varias veces, en diferentes ordenes. Sus tareas incluyen la tabla, registro y selección de atributos, así como la transformación y limpieza de datos para herramientas de modelado. Normalmente está fase toma el mayor esfuerzo del proyecto.

Las tareas de esta fase con las siguientes:

1. Seleccionar los Datos: Decidir sobre los datos que deben utilizarse para el análisis. Incluir criterios de pertinencia de los datos para los objetivos, la calidad y técnicas tales como las limitaciones de volumen de datos o tipos de datos. Esta tarea Cubre la selección de atributos, así como la selección de registros en una tabla.

2. Limpieza de los datos: aquí buscamos elevar a calidad de los datos al nivel requerido por las técnicas de BI seleccionadas en el proyecto.

3. Construcción de los datos: tarea orientada a la construcción o cálculo de los atributos calculados o nuevos registros requeridos por el modelo de gestión y no provisto por los datos brutos u operacionales.

4. Integración de Datos: tarea orientada a la integración de los datos de gestión generados a los modelos.

5. Aplicar formatos a los datos.

Fase 4 Modelamiento

En esta fase varias técnicas de modelamiento son seleccionadas y aplicadas, y sus parámetros son calibrados buscando los valores óptimos. Típicamente, existen varias técnicas para resolver un mismo problema de minería de datos. Algunas técnicas tienen requerimientos específicos en la forma de los datos. Por esto a menudo hay que volver a la fase de preparación de datos en estos cosos.

Las tareas de esta fase con las siguientes:

1. Seleccionar la técnica de modelamiento

2. Construcción del modelo de pruebas

3. Implementación del modelo

4. Evaluación del modelo

Fase 5 Evaluación

A estas alturas del proyecto ya se han construido el o los modelos los que aparenta ser correctos, desde la perspectiva del análisis de datos. Antes de proceder a la instalación final del modelo, es importante una evaluación a fondo del modelo y los pasos seguidos para su implementación para estar seguro que cumple con los objetivos de negocio. El objetivo clave es determinar si hay algún asunto de negocios que no se haya tratado con la suficiente profundidad. Al final de esta etapa se debe tener la certeza que los objetivos de negocio fueron alcanzados.

1. Evaluación de los resultados

2. Revisión del proceso

3. Determinar los próximos pasos

Fase 6 Transferencia

La creación del modelo generalmente no es el final del proyecto. Incluso si la finalidad del modelo es aumentar el conocimiento de los datos, los conocimientos adquiridos tendrán que ser organizados y presentados de manera que el cliente puede utilizarlo. Dependiendo de los requisitos, la fase de despliegue puede ser tan simple como generar un informe o tan compleja como la aplicación de una repetible proceso de minería de datos. En muchos casos será el cliente, no el analista de datos, que llevará a cabo los pasos de instalación. Sin embargo, incluso si el analista no lleva acabo la trasferencia el esfuerzo es importante para que el cliente pueda comprender por adelantado qué medidas tendrán que ser llevadas a cabo con el fin de realmente hacer uso de los modelos creados

1. Plan de transferencia

2. Plan de monitoreo y mantenimiento

3. Producción del reporte final.

4. Revisión del Proyecto

Mas información en las referencias.

Referncias

1.- CRoss Industry Standard Process

2.- Metodologías para la Realización de Proyectos de Data Mining

Los servicios Windows son programas que corren en background independiente del usuario que tenga sesiones activas en un server. Los usamos para múltiples tareas por ejemplo monitorear el estado de un Servicio Web.

Un cliente me pregunta cómo se puede hacer un servicio que monitoree un servicio Web y su tiempo de respuesta.

Fácil, hay que hacer un servicio Windows en C# 😉

Respuesta

Los pasos para construir un servicio Windows, utilizando C# son los siguientes:

1. Crear un proyecto del tipo Windows Services.
2. Implementar la lógica del Servicio.
3. Agregar los parámetros de instalación del servicio.
4. Crear un proyecto de Instalación.
5. Instalar
6. Extra, ¿cómo hacer Debug?

Paso 1: Crear un proyecto del tipo Windows Services.

Visual Studio tiene un tipo de proyecto especial para crear servicios Windows. En el cuadro de dialogo ‘New Project’ hay que seleccionar la opción ‘Windows Services’ como muestra la figura 1.

Figura 1.

Como resultado de esto se crea una clase llamada Service1 que contiene los siguientes métodos:

Service1(): constructor de la clase, aquí debemos incluir la configuración del Servicio.

OnStart(string[] args): Evento cuando el servicio se inicia. Esto ocurre cada vez que el servicio comienza a funcionar.

OnStop(): Evento cuando el servicio se detiene. Aquí se deben eliminar todos los recursos que el servicio utiliza.

Paso 2: Implementar la lógica del Servicio

Este servicio debe hacer lo siguiente:

1. Consumir un Servicio Web cada cierto periodo de tiempo.
2. Validar que el Servicio Web resposponda (no se caiga).
3. Validar que el tiempo de respuesta en menor que cierto valor.
4. Mantener en configuración la URL del Servicio Web, periodo de tiempo en que se repiten las llamadas y el tiempo de respuesta máximo.

Para consumir un Servicio Web utilizamos la funcionalidad de Visual Studio ‘Add Web Reference’ que se muestra en la figura 2. En este ejemplo utilizaré el servicio gratuito de  WebServiceX.

Figura 2.

Para realizar la tarea repetitiva de llamar al servicio Web cada cierto intervalo de tiempo utilizaremos un objeto del tipo System.Timers.Timer. Este objeto tiene la capacidad de levantar un evento cuando pasa cierto periodo de tiempo desde que se activa. En este caso la construcción del Timer se realzia en el método onStart del Servicio Windows, es decir cuando el servicio de levanta comienza a trabajar el Timer. Esto se muestra en el código 1.

   1: protected override void OnStart(string[] args)

   2: {

   3:     //Timer para el control del tiempo entre llamadas.

   4:     myTimer = new System.Timers.Timer();

   5:     //Intervalo de tiempo entre llamadas.

   6:     myTimer.Interval = 1500;

   7:     //Evento a ejecutar cuando se cumple el tiempo.

   8:     myTimer.Elapsed += new System.Timers.ElapsedEventHandler(myTimer_Elapsed);

   9:     //Habilitar el Timer.

  10:     myTimer.Enabled = true;

  11: }

Código 1.

En el evento myTimer_Elapsed se hace la llamada al Servicio Web. Pero, para evitar problemas de concurrencia se detiene el Timer antes de hacer la llamada y luego se vuelve a activar. Esto se muestra en el código 2.

   1: void myTimer_Elapsed(object sender, System.Timers.ElapsedEventArgs e)

   2: {

   3:     //Detiene el Timer

   4:     myTimer.Enabled = false;

   5:     //llama al Servicio Web

   6:     CallServicioWeb();

   7:     //habilita el Timer nuevamente.

   8:     myTimer.Enabled = true;

   9: }

Código 2.

Por último el método CallServicioWeb() hace la llamada y controla el tiempo de respuesta del Servicio. En el código 3 se puede ver la lógica de esto.

   1: void CallServicioWeb()

   2: {

   3:     //Proxy

   4:     SerivicioWeb.GeoIPService Proxy = new ServicioWindowsMonitor.SerivicioWeb.GeoIPService();

   5:     DateTime Tini;

   6:     TimeSpan Tdif;

   7:     try

   8:     {

   9:         //Tiempo de inicio de la llamada

  10:         Tini = DateTime.Now;

  11:         //llamada al servicio 

  12:         Proxy.GetGeoIP("200.10.12.126");

  13:         //Tiempo de respuesta

  14:         Tdif=Tini.Subtract(DateTime.Now);

  15:         if (Tdif.Seconds < -10)

  16:         {

  17:             Log("Servicio Lento: " + Tdif.Seconds.ToString()+ "[S]");

  18:         }

  19:     }

  20:     catch (Exception X)

  21:     {

  22:  

  23:         Log(X.Message);

  24:     }

  25: }

Código 3.

Paso 3: Agregar los parámetros de instalación del servicio.

Para que el servicio pueda ser controlado por el administrador de servicios de Windows debemos agregar dos componentes a nuestro Servicio Windows:

• serviceProcessInstaller: en este componente se debe fijar el usuario con que se ejecuta el servicio. En este caso utilizamos la cuenta Local Service.
• serviceInstaller: Este componente tiene la propiedad ServiceName, que define el nombre con que el Servicio aparece en la consola de Servicios. En este caso lo llamaremos ‘Monitor GeoIP’. Además este componente tiene la propiedad StartType que define si el servicio parte de manera automatica, manual o está desabilitado.

Para instalar estos componentes, en la vista de diseño del Servicio Windows usamos la opción ‘add Instaler’ del botón derecho. Esto se muestra en la figura 2.

Figura 2.

Paso 4: Crear un proyecto de Instalación

Para utilizar el servicio es necesario crear un instalador. Este proyecto instala el software del Servicio Windows en el disco, lo registra y agrega a la consola de servicios del sistema operativo.

Para crear un proyecto de instalación debemos utilizar el dialogo ‘New Project’ con la opción ‘Setup’ como muestra la figura 3.

Figura 3.

Una vez creado el proyecto debemos agregar a este proyecto de instalación en la carpeta ‘Application Folder’ el proyecto de salida. Este es nuestro proyecto de Servicio Windows. La figura 4 muestra cómo hacerlo usando el botón derecho.

Figura 4.

El siguiente paso es agregar este proyecto de salida a las acciones Install, Commit, RollBack y Uninstall. Para ello en la pestaña ‘Solution Explorer’ seleccionamos el botón ‘Custom Action Editor’. Luego en ese editor, agregamos el proyecto a todas las acciones, como lo muestra la figura 5.

Figura 5.

Paso 5: Instalar

Para instalar el Servicio Windows debemos hacer un Built del instalador y luego con el botón derecho sobre el proyecto de instalación ejecutar la instlación.

Una vez instalado, siguiendo los pasos del Wizard, podemos ver el servicio en la consola de servicios del sistema operativo. En la figura 6 se puede ver las propiedades del evento que ya está en la consola de servicios!!!!

Figura 6.

Paso 6: Bonus, Hacer Debug del Servicio.

Para poder hacer debug del servicio podemos hacer un Attach del proceso. Ojo, esto es posible poque lo compilamos en modo Debug. Para hacerlo vamos al menu Debug de Visual Studio, opción Attach. Cuando aparece el dialogo de procesos hay que buscar en la lista el nombe del servicio y apretar el botón attach. En ese momento Visual Studio entra en modo de debug. El dialogo de Attach se muestra en la figura 7.

Figura 7.

Una vez que se está en modo de debug, se puede poner un punto de interupción en el código y hacer debug a gusto.

Esto es lo básico para desarrollar un Servicio Windows, con esto pueden construir desde un sencillo servicio de monitoreo hasta complejos Host de Windows Comunication Foundation por ejemplo.

El código de ejemplo de esta demos pueden bajarlo desde Aquí

Salu2

BizTalk Server es una excelente herramienta para construir procesos de negocio que requieren de integración de sistemas.

Desde que se tienen IDE’s de desarrollo potentes, los desarrolladores están acostumbrados cada vez más a hacer debug de sus aplicaciones e ir viendo el estado de los objetos en memoria mientras se ejecuta la aplicación. Un problema en el desarrollo de orquestaciones es poder hacer debug de lo que estamos desarrollando. Por eso la pregunta, ¿Cómo hacer debug y ver los mensajes?

Respuesta

BizTalk tiene una herramienta llamada Health and Activity Tracking (HAT) que permite hacer consultas de las actividades que el motor servidor BizTalk está ejecutando.

Con esta herramienta podemos hacer debug de las orquestaciones y ver el contenido de los mensajes de cada instancia de servicio que se están ejecutando.

Los pasos para hacer debug son los que se muestran en el siguiente diagrama.

El primer paso no es materia de este POST.

Paso 2: Poner la orquestación en modo debug.

Para esto debemos utilizar la herramienta HAT. Esta herramienta trae consultas pre definidas con la cual podemos ubicar la orquestación que queremos revisar. Usando la consulta Most Recent 100 Service instance podemos ubicar la orquetsación.

Figura 1.

Una vez ubicada la orquestación que buscamos, debemos instanciar el Orchestration debugger utilizando el botón derecho sobre la orquestación, como lo muestra la figura 2.

Figura 2.

Por último debemos poner el o los puntos de ruptura en la orquestación para así poder ver su comportamiento en tiempo de ejecución. Esto se hace con el botón derecho sobre la acción, como muestra la figura 3. Luego de esto hay que cerrar el Orchestration Debugger.

Figura 3. 

Paso 3: Ejecutar la orquestación

Debemos iniciar el proceso de negocio que queremos debugear, esto se hace mandando el mensaje a BizTalk que inicia el proceso.

Paso 4: Encontrar la instancia de la orquestación

Para encontrar la instancia de la orquestación usamos el HAT con una consulta que muestre las orquestaciones que tienen el estado Strated. Cuando pusimos en el paso 2 el punto de ruptura, el motor detiene todas las instancias de esa orquestación en ese punto de ruptura por lo que quedan en estado Started.

Con la siguiente consulta podemos encontrar las instancias.

Código 1: Consulta SQL

El resultado de esta consulta son las instancias que están Started en el servidor.

Paso 5: Attach el proceso y ver el mensaje.

Para poder tomar la instancia y ver el estado de los mensajes debemos ejecutar la consulta y con el botón derecho sobre la orquestación iniciar el Orchestration Debugger. La figura 4 muestra el resultado de la consulta.

Figura 4.

Ahora en el Orchestration Debugger, debemos hacer Attach del proceso para poder cargar la información de la instancia en el Debugger. La figura 5 muestra cómo hacerlo.

Figura 5.

Ahora tenemos toda la información de la instancia a la vista y podemos por ejemplo ver el valor de un mensaje. Este valor podemos verlo en el cuadro de propiedades de las variables o con el botón derecho sobre el mensaje grabarlo en disco.

Figura 6.

Paso 6: Sacar del modo Debug la orquestación

Es muy importante luego de realizar el debug, sacar los puntos de ruptura de la orquestación, sino está seguirá deteniendo todas las instancias de la misma que se ejecuten.

Para esto, en el mismo Orchestration Debugger se deben borrar los puntos de ruptura y luego cerrarlo. Eso es todo!!!

Salu2

Nuevamente recibo una pregunta interesante, los clientes son una fuente de inspiración inagotable. Qué pena no tener más tiempo para Bloger con más frecuencia.

Problema

El equipo de desarrollo he desarrollado una nueva aplicación y requiere saber si está aplicación puede o no ser instalada en un servidor que actualmente aloja otras aplicaciones. ¿Cómo saber si será capaz el servidor de soportar esta nueva aplicación?

Posible Solución

El sentido común dice que midiendo los recursos que actualmente usa el servidor se puede determinar la capacidad “ociosa” disponible para que la nueva aplicación se ejecute. Esto es verdad si y solo sí el uso de recursos fuera lineal.

No voy a entrar en la complejidad de lo que es un sistema lineal, pero en términos simples Un sistema lineal es un sistema que obedece las propiedades de escalado (homogeneidad) y de superposición (aditiva), mientras que un sistema no-lineal es cualquier sistema que no obedece al menos una de estas propiedades.

Asumiendo que los recursos se administran de manera lineal podemos declarar que los recursos usados hoy en el servidor al poner la nueva aplicación, no variaran sino que seguirán constante. Esto es la propiedad de superposición de los sistemas lineales. Esto no es verdad en el mundo real, pero es un supuesto que permite un análisis simple para obtener resultados aproximados evitando las complejidades de los sistemas no lineales.

Ahora, después de haber “forzado” la realidad nos queda medir el uso de recursos. Las mediciones más simples y al alcance de todos en la plataforma Windows se hacen utilizando la herramienta Performance Monitor [1].

Dependiendo del aspecto que se quiera observar son los contadores que debemos utilizar. En el artículo Key Performance Monitor Counters [3] explican que contadores utilizar para responder las siguientes preguntas:

• ¿Cuánto es la disponibilidad del servidor?
• ¿Cuán ocupado está el servidor?
• ¿Está funcionando adecuadamente el Hardware?
• ¿Tienes suficiente RAM? [Muy importante]
• ¿El disco es lo suficientemente rápido?

La gracias de este análisis es que no requiere de un entendimiento profundo de lo que el sistema hace, o como está construido (Java, DotNEt, etc..) Pasa a ser una caja negra. Ahora, para los puristas eso es malo porque no te da razones solo describe comportamiento de el sistema como un todo.

Después de medir, se obtiene la capacidad ociosa del servidor de destino. Podemos representar eso como Recursos Disponibles (Rd).

Los recursos que la nueva aplicación utiliza deben ser medidos de la misma manera. Para medir estos recursos debemos en el ambiente de Test “cargar la aplicación” para poder medir así los recursos que utiliza. Representaremos eso como Recursos Nueva Aplicación (Rna).

Entonces, después de “forzar la realidad” podemos decir que:

Solo en el primer caso, esta prueba simplificada nos da una respuesta práctica. En los otros casos hay que utilizar técnicas más sofisticadas, las cuales deben ser realizadas por gente con más experticia que un desarrollador de software como yo  🙂

Un ejemplo del nivel de complejidad de las medidas para los casos no resueltos con este método pragmático se puede ver en este POST [4] específico para medir desempeño de Web Services construidos en ASPNET.

Referencias

1.- Performance Monitor.

2.- Sistemas Lineales.

3.- Key Performance Monitor Counters.

4.- Medir el desempeño de Servicios Web plataforma DotNet.

Escenario

Para un cliente de la industria Bancaria implementamos autentificación utilizando formularios (Forms authentication) de ASPNET. Este formulario es único para todas las aplicaciones.

En el contexto de ese proyecto y buscando que sea lo más seguro posible utilizamos las opciones de cifrado de toda la información que se almacena en las cookies. Para ello utilizamos la opción <forms protection="All">.

Ahora, como el formulario es único para todas las aplicaciones, tuvimos que agregar el atributo <forms EnableCrossAppRedirects ="true"> para que así los clientes una vez autentificados regresaran a la aplicación que querían utilizar.

Solución

Para que esto funcione, ya que el formulario cifra los datos, es necesario que las aplicaciones y el formulario de autentificación compartan las llaves de cifrado. Esto nos obliga a generar y declarar explícitamente las llaves a utilizar. Esto se hace de la siguiente forma.

Tabla1

Este TAG se debe agregar en el archivo de configuración tanto en el formulario de autentificación como en las aplicaciones que deben leer las cookies que generó el formulario.

Un problema común es cómo generar estas llaves. Como generar estas llaves programáticamente pueden verlo en este ejemplo [2] y desarrollar su generador o utilizar este [3] Free directo del WEB.

Enjoy!

Referencias

[1] Cómo: Proteger la autenticación de formularios en ASP.NET 2.0, http://www.microsoft.com/spanish/msdn/articulos/archivo/201205/voices/paght000012.mspx

[2] ASP.NET machineKey Generator, http://www.codeproject.com/aspnet/machineKey.asp

[3] ASP.NET machineKey Generator Software, http://www.developmentnow.com/articles/machinekey_generator.aspx

Problema

Para un proyecto de plataforma móvil estamos haciendo un ESB pequeño que utiliza WCF. La idea es que este ESB permita agregarle nuevos servicios de manera administrativa sin volver a compilar. Estos servicios son expuestos por otros sistemas y no se puede normar los contratos que estos exponen.

WCF permite llamar servicios a los cuales se le conoce su interfaz mediante el uso de ChannelFactory. Esto serviría pero hay una complicación adicional, no tenemos las interfaces en tiempo de diseño sólo en tiempo de ejecución. En resumen se necesitan en este caso dos cosas:

1. Llamar servicios en tiempo de ejecución sin volver a compilar el cliente.
2. Soportar DataContract en las llamadas a los servicios.

 Este es el concepto de adaptador…….

Solución propuesta, Uso de Reflexión

Para el primer problema podemos usar reflexión [2]. La reflexión nos permitirá en tiempo de ejecución hacer una instancia del Proxy para el servicio y de los tipos DataContract [3] que este utilice. Esto quiere decir que en tiempo de ejecución cargamos el Assembly [4] que contenga en Proxy y lo invocamos.

Veamos un ejemplo de un servicio simple en WCF. El código uno muestra el contrato del servicio, esto es lo que describe que es lo que el servicio hace. Luego, el código dos muestra los tipos de datos específicos del contrato del servicio. Por último, el código 3 muestra la implementación del servicio.

Código 1: Contrato de servicio.

Código 2: Datos del Contrato de servicio.

Código 3: Implementación del servicio.

Para que el cliente (ESB) invoque al servicio va a requerir de un Proxy que le permita llamar a los métodos del servicio. Generamos entonces un proxy en un Assembly separado que pueda ser entregado al administrador del ESB para que lo "instale". La instalación no requerirá de compilación del lado del cliente (ESB).

Una vez que tenemos el Assembly podemos hacer una instancia del Proxy y ejecutar sus métodos. Como ejemplo, primero llamaremos al método MyOperation1 del servicio de ejemplo. Para esto construimos un método de llamado en el cliente como se muestra en el código 4.

Código 4: llamada a través del proxy externo.

Este ejemplo utiliza un tipo de datos "primitivo" lo cual puede ser muy común pero no necesariamente así es siempre. Para servicios más complejos se usan tipos de datos complejos los cuales se modelan utilizando DataContract. El próximo ejemplo llama al método MyOperation2 que usa un argumento del tipo DataContract1.

El código 5 muestra cómo podemos llamar a un servicio que tiene como argumento de entrada un tipo de dato complejo haciendo uso de un Proxy externo. El principio es el mismos que en el caos anterior, con la diferencia que ahora debemos instanciar un DataContract y asignarle los valores que correspondan. Para esto usamos las capacidades de Reflexión para instanciar tipos y asignarle valores a sus propiedades como se muestra en el punto 6 del código 5. El código que llama a este método se muestra en el código 6, ahí se puede ver que el parámetro de entrada al método EjecutarProxyTypoComplejo es un diccionario [5] con los valores, el cual será recorrido y asignado dentro del método.

Código 5: llamada a través del proxy externo con un tipo de dato complejo.

Código 6: llamada a través del proxy externo con un tipo de dato complejo.

Con esta técnica todos los futuros servicios pueden ser enlazados utilizando el Proxy autogenerado para cada servicio.  

Referencias

[1] Adapter pattern, http://en.wikipedia.org/wiki/Adapter_pattern

[2] Información general sobre la reflexión, http://msdn2.microsoft.com/es-es/library/f7ykdhsy(VS.80).aspx

[3]Contratos de Datos, http://www.microsoft.com/spanish/msdn/articulos/archivo/041206/voices/LearnTheABCsOfP.mspx#E3H

[4] What is a .Net Assembly? , http://www.programmersheaven.com/2/FAQ-DOTNET-DOTNET-Assembly-Explained

[5] Dictionary Generic Class, http://msdn2.microsoft.com/en-us/library/xfhwa508.aspx

Cuando se comienza a desarrollar un proyecto de SOA es necesario detenerse a pensar en todos los aspectos a cubrir para que la adopción de este estilo de arquitectura no se convierta en un problema. Comúnmente se piensa que construir servicios es comenzar con una arquitectura orientada a servicios, pero en rigor afirmar esto es como decir que la arquitectura de una casa de hace construyendo ladrillos.

Los temas a incluir en el desarrollo de un proyecto de adopción de SOA que considero fundamentales son los siguientes:

1. Cumplir con los principios de la orientación a Servicios.
2. Diseño de las capas de Servicios.
3. Definición del ciclo de vida de los Servicios
4. Definición de los aspectos operacionales
   1. Soporte de múltiples protocolos estándares.
   2. Despacho garantizado.
   3. Servicios Síncronos y Asíncronos.
   4. Manejo de excepciones.
   5. Seguridad de los Servicios.
   6. Instrumentación.
   7. Contenedor de Servicios
5. Caso de prueba.

Cumplir con los principios de la orientación a Servicios

Los principios de la orientación a servicios son la fundamentación de todo el esfuerzo que se realiza en este tipo de proyectos. Por esta razón se deben cumplir en todo momento con estos principios.

• Los servicios son reusables.
• Los servicios comparten contratos no código.
• Los Servicios tienen bajo acoplamiento.
• Los servicios tienen Fronteras explicitas.
• Los Servicios son modulares y permiten la composición.
• Los Servicios son autónomos.
• Los servicios deben permitir métodos de descubrimiento.

Diseño de las capas de Servicios

En una arquitectura empresarial, es necesario ubicar la capa de servicios entre la capa de negocios y la capa de servicios de aplicación. Lo que se busca lograr con la definición clara de las capas de servicios es poder contestar preguntas fundamentales como:

• ¿Qué lógica será representada por los servicios?
• ¿Cómo se relacionaran estos servicios con la lógica de aplicaciones existentes?
• ¿Cómo los servicios pueden representa de mejor forma los procesos de negocio?
• ¿Cómo pueden los servicios ser construidos e instalados para promover la agilidad?

La siguiente figura muestra una idea de las capas y como se busca definirlas.

Definición del ciclo de vida de los Servicios

Para poder asegurar un resultado predecible en los futuros proyectos de software es necesario definir un proceso de análisis de los servicios que se desean construir.

El ciclo de vida del proyecto es un conjunto de pasos necesarios que deben ser cumplidos para construir los servicios necesarios de una arquitectura SOA. Los proyectos de implementación de una arquitectura orientada a servicios (SOA), siguen al igual que todos los proyectos de software un ciclo de vida definido.

Las etapas de este ciclo de vida son:

• Análisis Orientado a Servicios
• Diseño Orientado a Servicios
• Desarrollo de Servicios
• Prueba de Servicios
• Instalación de Servicios
• Operación de Servicios

Definición de los aspectos de implementación

Este es el primer punto que se ocupa de los aspectos de implementación. Estos temas son importantes para llevar las definiciones conceptuales de alto nivel a definiciones pragmáticas que los equipos de proyectos puedan utilizar. Por supuesto cada definición de estos aspectos debe cumplir con las orientaciones generales definidas con anterioridad.

La lista de aspectos a cubrir son:

• Soporte de múltiples protocolos estándares.
• Despacho garantizado.
• Servicios Síncronos y Asíncronos.
• Manejo de excepciones.
• Seguridad de los Servicios.
• Instrumentación.
• Contenedor de Servicios

Caso de prueba

Como estrategia de validación, necesaria en cualquier proyecto, es necesario realizar un caso de prueba. La idea del caso de prueba es validar que las definiciones hechas son posibles de implementar y útiles para la organización.

Transferencia de Conocimiento

Por último, uno de los mayores problemas que se enfrentan las organizaciones que enfrentan proyectos de orientación a servicios es que cuando los consultores se retiran debe hacerse cargo de la arquitectura, operarla y seguir extendiéndola.

Para facilitar estas tareas se debe incluir un plan de transferencia de conocimiento que es más que escribir manuales o hacer una capacitación.

Estas son las recomendaciones para enfrentar un proyecto de inicio de arquitectura SOA.

En mi trabajo estamos buscando un jefe de proyectos, por lo que tuvimos que redactar alguna descripción del perfil de este Rol. En ese trabajo me mandaron la siguiente tabla de habilidades que debería tener un jefe de proyecto.

Me pareció muy completa y precisa por lo que la comparto en este POST. No tengo clara la fuente, por eso no la cito.

El Project Manager por el alcance de sus funciones, del equipo y recursos que administra, y por las variables y escenarios que se presentan, debería tener en mayor o menor grado algunas de las siguientes habilidades: