Me llegó la invitación para el evento MVP Open Day en Chile. En este evento los manager del programa MVP vienen a Santiago de Chile a conocer las comunidades locales, recibir feedback y compartir experiencias.
Esta es la invitación, será una excelente oportunidad de intercambiar ideas. Todo lo interesante que no sea NDA lo compartiré en este BLOG.
Estoy es una muy buena noticia. Microsoft va a entregar los códigos fuentes del Framework 3.5 para que los developer puedan hacer debug de manera integrada con sus programas y además usarlo de referencia de implementación.
La segunda utilización me parece mucho más útil que la primera, pero eso puede ser porque no hago tanto código como me gustaría.
Les dejo el Link donde pueden encontrar la información de primera fuente.
Salu2,
En los 2 POST anteriores he tratado el tema del motor de reglas de Windows Workflow Foundation. El primero es una introducción que permite entender el concepto de RuleSet y cómo usarlo en un Workflow. El segundo explica cómo funciona el tema de las dependencias de las reglas y la manera de administrar las re evaluaciones por cambios de las condiciones de validación.
Ahora voy a mostrar algo que es muy potente. Hasta ahora, las reglas de negocio se encuentran compiladas dentro del Assembly del Workflow. La consecuencia de esto es que es necesario para cambiar las reglas volver a compilar. Esto es un contra sentido, porque la idea de desacoplar las reglas de código de programación es poder tener una separación clara de el código del Wrokflow de las reglas.
En este Post voy a tratar de explicar cómo usar una pieza de software de terceros que permite poner el RuleSet de negocio en una base de datos y así cambiar las reglas sin volver a compilar.
Lo primero que debo presisar es que voy a utilizar un software de terceros llamado “External RuleSet Toolkit”[1]. Este código es de ejemplo y demuestra como almacenar en SQL el RuleSet. Además trae una interfaz Windows Forms para modificar las reglas en la DB y así los Workflow no son alterados por cambios en las reglas de negocio.
Lo primero que hay que entender es la arquitectura de esta solución. El siguiente diagrama muestra un WorkflowRuntime que tiene 3 instancias de Workflow corriendo. Cada una de esas instancias tiene una Custom Activity llamada “Custom Policy Activity”, que se encarga de obtener el RuleSet desde la base de datos a través del servicio “RuleSet Services”. Este Servicio debe ser agregado al WorkflowRuntime para que esta actividad de Políticas cutomizada pueda comunicarse con el RuleSet Repository que esta en la base de datos.
Imagen 1.
Además de los componentes para el Workflow este ejemplo de código trae el RuleSet Designer que es una interfaz gráfica para administrar los elementos del RuleSet Repository. Esta interfaz se muestra en la imagen 2.
Imagen 2.
Para poder usar el componente se deben cumplir con el proceso de instalación. Estos no los voy a explicar porque están perfectamente detallados en el manual de instalación de este ejemplo de código.
Para usar este componente vamos a importar el RuleSet que usamos en el primer ejemplo del primer post de esta serie. Como sabemos las reglas de guardan en un archivo de extensión .rule. Usando la aplicación RuleSet Designer vamos a importar el archivo wfReglasEjemplo_1.rule que está en este ejemplo de código [2]. Una vez importado grabamos el RuleSet para que así quede persistente en la base de datos.
Ahora, creamos un Workflow secuencial y le agregamos la actividad customizada PolicyFromService que es la que enlaza con las reglas de la base de datos a través del Servicio. El workflow se ve como la siguiente imagen.
Imagen 3.
Las propiedades de la actividad PolicyFromService son:
1.- RuleSet Name: nombre del juego de reglas a usar.
2.- Major Version: numero de verison.
3.- Menor Version: número de sub versión.
EL RuleSet de nuestro ejemplo se llama Rule Set1. LA versión es la por defecto 1.0.
Ahora para que esto funcione debemos incluir el servicio de comunicaciones con el repositorio de la reglas en la base de datos. Para eso al runtime del Workflow agregamos el Servicio RuleSet Services. Para esto agregamos el siguiente código.
|
workflowRuntime.AddService(new RuleSetService()); |
Código 1.
Con esto tenemos listo nuestro ejemplo. Si lo ejecutamos obtenemos el resultado A=15, B=5, C=5, D=2 y E=7. Las reglas para hacer los cambios de los valores los leyó desde la base de datos!!!!!.
Ahora, vamos a cambiar los valores para comprobar que descaplamos las reglas del Assembly. Para ello usamos la herramienta RuleSet Designer. Lo que haremos es mantener dos versiones de las reglas, así dependiendo de un valor usaremos una u otra regla.
Primero creamos una copia de las reglas, para eso usamos la función copy. Al hacer eso, nos aparece una nueva versión que por defecto es la versión 2.0. Usando la opción de Edit Rule, nos aparece el mismo formulario usamos antes para cambiar las reglas de Rule Set.
Si cambiamos las reglas y las grabamos en la base de datos el workflow inmediatamente comenzará a evaluar con el nuevo set de Reglas. Los valores de las reglas del segundo ejemplo son:
|
Código 3: Reglas Ejemplo II
Las Reglas versión 2.0 se muestran en la siguiente imagen.
Imagen: Reglas Versión 2.0
Los resultados obtenidos al usar las reglas 2.0 son A=15, B=5, C=5, D=2 y E=7000, y para esto no tuvimos que compilar.
Buenos eso es, espero lo encuentren de tanta utilidad como yo!.
El ejemplo de este POST pueden descargarlo desde aquí.
Salu2
[1] External RuleSet Toolkit, http://wf.netfx3.com/files/folders/rules_samples/entry309.aspx
[2] Ejemplo de código de Reglas, http://desarrollo.datco.cl/materialpublico/Test2_Reglas.zip
Siguiendo con esta secuencia de POST orientados a tratar de explicar cómo funciona el motor de Reglas de Windows Workflow Foundation. En el primer POST tenemos se explica cómo funcionan la evaluación de reglas de un RulesSet y cómo se re evalúan por defecto.
En este pequeño POST trataré de explicar cómo se puede controlar la ejecución de reglas atómicas del RuleSet sin dependencia entre ellas. La idea es que en algunos escenarios complejos, quien escribe las reglas necesita tener mayor control sobre el comportamiento de las re evaluaciones, específicamente limitar la cantidad de reevaluaciones. Con esto se busca evitar loops infinitos, resultados erróneos por iteraciones de las reglas y algo no menor, mejorar el desempeño.
En nivel de control que permite Windows Workflow Foundation se puede configurar en dos puntos:
Esta propiedad actua a nivel de RuleSet, y tiene las siguientes tres posibilidades:
1. Full Chaining: este es el comportamiento por defecto que está descrito en el primero post de esta serie. Pueden verlo aquí.
2. Explicit Update Only: está opción deshabilita las dependencias implícitas y por atributos, dejando la posibilidad solo a las explicitas declaradas usando Update.
Un ejemplo sería con el RuleSet del código 1 y los métodos del código 2 utilizando Chaining Behavior con el valor por defecto Full Chaining el valor de salida de las variables A, B, C, D y E son 15, 5, 5, 2 y 7 respectivamente.
Ahora si se cambia la propiedad Chaining Behavior a Explicit Update Only, el resultado cambia a 15, 0, 5, 2, 0. Esto ocurre porque en este modo de se ignoran las dependencias declaradas como atributos.
|
Código 1
|
private int A = 0; private int B = 0; private int C = 5; private int D = 2; private int E = 0; //Omitido el resto del código….Ver el proyecto de ejemplo [RuleWrite("B")] private void CambiarB(int valor) { this.B = valor; } [RuleWrite("A")] private void CambiarA(int valor) { this.A = valor; } [RuleWrite("E")] private void CambiarE(int valor) { this.E = valor; } |
Código 2
Para poder obtener el mismo comportamiento que en la primera prueba tenemos que cambiar el RueSet a lo mostrado en el código 3.
|
Código 3
Al poner la dependencia de forma explícita entonces el motor de reglas cuando evalúa la regla 2, re evalúa a regla 4. El resultado obtenido es 15, 5, 5, 2 y 7 respectivamente.
3. Sequiencial: esta es la opción final y lo que hace es forzar a que el motor realice las evaluaciones en un orden línea estricto, es decir no re evalúa las dependencias.
Si al ejemplo anterior, le cambiamos el valor a Secuencial, entonces obtenemos el resultado 15, 0 ,5, 2 y 0 porque no hay re evaluación de la Regla 4
Está propiedad se aplica a nivel de Reglas y permite la re evaluación o no de la regla. Los valore posibles son:
En el ejemplo anterior, si la Regla 4 es marcada con Never entonces los valores de salida con 15, 0, 5, 2 y 0 porque la Regla 4 no se re evaluó.
Está función es muy interesante porque permite controlar la ejecución de dependencias entre reglas relacionadas. Al incluir Halt en la acción THEN o ELSE, entonces el RuleSet retorna de manera inmediata el control al código que lo invocó.
Con lo expuesto en este POST más el primer POST de RULE ENGINE ya se puede echar a volar la imaginación y buscar las aplicaciones prácticas de está tecnología. Yo ya la uso en proyectos Reales.
Espero seguir con otro Post (esto solo es una expresión de deseo) que muestra otros aspectos de Rules Engine de Windows Workflow Foundation.
EL código fuente del ejemplo mostrado se puede descargar desde aquí.
Salu2
La tecnología DotNet Framework 3.0 tiene un componente para implementar Workflow’s[0] llamado Windows Workflow Foundation [1]. Este no es un producto de Workflow sino un motor de workflow más herramientas para los desarrolladores para que construyan sus propias soluciones de Workflow.
Dentro de las cosas más interesantes que veo en WF se encuentra su motor de Reglas de negocio (Rule Engine)[2].
Rules Engine permite hacer desde evaluación de condiciones lógicas hasta la definición y evaluación de complejas reglas que conforman políticas. En este post voy a tratar de explicar cómo se implementan esas políticas y cómo podemos usarlas en nuestros Worklows.
Lo primero que hay que entender es que las políticas son definidas por un conjunto de reglas semánticas llamado RuleSet. Estas reglas son del estilo If/Then/Else. Para poder invocar desde un Workflow la evaluación de un RuleSet se usa la actividad Policy[3].
Las Reglas que componen un RuleSet tienen una propiedad llamada Priority, que permite asignarle una prioridad a cada regla. El procedimiento de Evaluación del RuleSet es el siguiente:
Veamos el siguiente ejemplo. Tenemos un Workflow sencillo de 3 Actividades, el que se muestra en la imagen 1. La primera actividad muestra los valores de las variables A, B, C, D, E en la consola. La segunda actividad es una Política que tiene 4 reglas que están priorizadas y la última muestra los valores después de aplicar el RuleSet de reglas.
Imagen 1: Workflow de Ejemplo y RuleSet.
El RuleSet se ve en la imagen 1. Las reglas se ejecutan desde la mayor prioridad (4) hasta la menor (1). El proceso en que se ejecutan las reglas es el siguiente:
Quedando cuando se ejecutan los valores mostrados en la imagen 2 en color Rojo.
Imagen 2: resultados.
Las dependencias entre las reglas son identificadas de tres maneras por el Rules Engine:
Este tipo de dependencia es la que vimos en el ejemplo 1, donde las acciones cambian valores que se usan en otras reglas.
La dependencia por atributos es usado en reglas que llaman a métodos en el Workflow. Como llama a un método no tiene como deducir implícitamente que reglas debe ReEvaluar. Para usar este tipo de dependencia se debe usar uno de estos tres atributos en el método:
Veamos un ejemplo para que sea más simple de entender. Tenemos un Workflow igual al anterior pero con el RuleSet mostrado en la imagen 3. Las reglas son las mismas que antes, pero en vez de cambiar los valores de las propiedades A,B, C, D y E directamente en la acción de la regla se invoca a un método.
El código de cada uno de los métodos invocados desde el RuleSet se muestra en el código 1.
Pueden ver en la imagen 4 que el resultado de la evaluación es el mismo que en ejemplo de reglas implícitas porque se hacen los mismos cambios de valores pero en métodos decorados con los atributos que le dan al motor de regla la información necesaria para actuar.
Imagen 3
|
[RuleWrite("B")] private void CambiarB(int valor) { this.B = valor; } [RuleWrite("A")] private void CambiarA(int valor) { this.A = valor; } [RuleWrite("E")] private void CambiarE(int valor) { this.E = valor; } |
Código 1.
La dependencia explicita se basa e declarar uno mismo los cambios que ocurren al ejecutar una acción. Para ello se usa la instrucción Update de esta forma Update("this/A") por ejemplo para indicarle al motor que el valor de la propiedad A cambio.
La única ventaja que he encontrado en la dependencia explicita es que se puede hacer por ejemplo esto Update("this/OrdenCompra/*") que le indica al motor que todos los atributos de la orden de compra cambian con esa acción. Esto es notable!!.
El próximo ejemplo se muestra en la imagen 4. Las reglas contienen ahora en la acción la directiva Update. El código de los métodos ya no tiene la directiva RuleWrite, por lo que el motor se entera del cambio de manera explícita. El código de los métodos de cambio, sin el atributo, se muestra en el código 2.
Por último el resultado sigue siendo el mismo!!! Y se muestra en la imagen 4.
Imagen 4.
|
private void CambiarB(int valor) { this.B = valor; } private void CambiarA(int valor) { this.A = valor; } private void CambiarE(int valor) { this.E = valor; } |
Código 2.
Imagen 4
El motor de reglas es mucho más potente de lo que se muestra en este POST, espero seguir explicando cómo funciona en una serie de post que quiero hacer sobre Windows Forkflow Foundation Rules Engine.
El código fuente de los ejemplos pueden descargarlos dese este Link
Salu2
[0] Sistemas de Workflow, http://es.wikipedia.org/wiki/Sistemas_de_workflow
[1] Windows Workflow Foundation, http://msdn2.microsoft.com/en-us/netframework/aa663328.aspx
[2] Introduction to the Windows Workflow Foundation Rules Engine, http://msdn2.microsoft.com/en-us/library/aa480193.aspx
[3] Introducing Microsoft Windows Workflow Foundation: An Early Look , http://msdn2.microsoft.com/en-us/library/aa480215.aspx
Los desarrolladores de aplicaciones móviles independiente de la tecnología que utilicen manejan el concepto de computación ocasionalmente conectada (OCC).
Las aplicaciones OCC tienen que tomar una decisión de arquitectura muy importante para enfrentar este problema: Data-Centric y Service-Oriented.
Las aplicaciones que utilizan la estrategia de Data-Centric tienen una base de datos relacional (RDBMS) en el cliente. Las capacidades de esta base de datos son utilizadas para propagar los cambios en los datos locales al servidor, administrando el proceso de sincronización, detectando y resolviendo los conflictos de datos.
La segunda aproximación es utilizar Service-Oriented, que almacena los datos locales en mensajes que son puestos en colas cuando el cliente está fuera de línea. Después que se restablece la conexión esos mensajes son enviados al servidor para ser procesados.
A continuación se desarrollan ambas aproximaciones.
Cuando se usa está aproximación, el servidor publica los datos a ser utilizados y los clientes se suscriben a los datos que necesitan, entonces obtienen una copia de los datos que necesitan antes de desconectarse.
Mientras la aplicación esta fuera de línea, los cambios son hechos sobre los datos locales mediante la interacción de la aplicación con sus datos locales.
Cuando el dispositivo vuelve a conectarse, la base de datos local propaga los cambios realizados a los datos locales. También, los cambios hechos en el servidor central son propagados hacia el cliente.
Cualquier conflicto ocurrido durante la fase de unión de los datos es manejado por el motor de resolución de conflictos, en base a reglas. Estas reglas son implementadas tanto en el servidor como en el cliente, de acuerdo a las propias reglas de negocio de la aplicación.
El proceso de fusión (Merge) de los cambios en los datos es conocido cómo Merge Replication. Los cambios pueden ocurrir de manera autónoma tanto el servidor como en el cliente, por esto no se utilizan transacciones ACID. En vez de una transacción, cuando se realiza el merge, todos los suscriptores recibirán el dato cambiado en el publicador.
La principal ventaja de usar esta aproximación es que todo el seguimiento de los cambios está contenido dentro de las funcionalidades de la base de datos. Generalmente, la base de datos incluye código para detectar conflictos de datos a nivel de filas y columnas a nivel de base de datos, códigos de validación y restricciones del dato. En este sentido el único trabajo que se debe hacer es armar el esquema de replicación para la aplicación móvil que optimice la resolución de conflictos y actualización de datos.
En este modelo, la sincronización de los datos es responsabilidad del motor de datos, por lo tanto, no es necesario codificar funcionalidades para ello. Se define que tablas son las que necesitan ser sincronizadas y el motor de datos se encarga de llevar el rastro de los datos, sincronizarlos y resolver conflictos. En este punto, la resolución de conflictos, si los criterios que vienen no son suficientes, pueden extenderse utilizando código.
Por otra parte, al existir una base de datos central, después que los clientes sincronizan los datos, se puede asegurar la convergencia de los datos es completa.
Las desventajas que aparecen al usar este modelo son las siguientes:
Los escenarios recomendados para usar esta aproximación son:
Ø Se puede sincronizar utilizando HPPTS, VPN o la LAN.
Con esta aproximación, los clientes interactúan con el servidor central consumiendo servicios a través de mensajes definidos. Pueden tener o no un cache de datos local. La ventaja es que no se necesita una base de datos local instalada en el cliente. Esto significa que está aproximación puede ser aplicada a muchos tipos de dispositivos sin las restricciones del uso de un motor de base de datos local.
El uso de está aproximación de servicios es particularmente apropiada cuando las aplicaciones deben operar en ambientes como Internet y Extranet. Esto porque es posible habilitar en el firewall la entrada de las peticiones de los clientes, por ejemplo Web Service.
El uso de servicios permite mantener bajo acoplamiento, lo que significa que puede interactuar con diferentes esquemas de base de datos.
La principal desventaja de está aproximación es que es responsabilidad del constructor del sistema codificar toda la funcionalidad que guarda relación con el modelo transaccional de Store and Forware de mensajes, como también implementar la contención de transacciones cuando el cliente está fuera de línea.
El uso de una aproximación de servicios se desempeña mejor en escenarios en los que la aplicación necesita interactuar con muchos servicios diferentes, provistos por diferentes servidores. Se comporta muy bien con múltiples trasportes, ya que es independiente el mensaje al trasporte usado. Por ejemplo un trasporte es Web Services.
Los escenarios recomendados para usar esta aproximación son:
Si se quiere desarrollar aplicaciones OCC utilizando una orientación de servicios se deben considerar los siguientes puntos principales:
Este es un informe que hizo InfoWorld en julio del 2007, recién salido del horno para el público general.
Lo he revisado y tiene interesantes resultados, alguno de los cuales comparto aquí.
Por supuesto mejor lo consiguen y leen completo ustedes mismos para evitar interpretaciones equivocadas de los cuadros que les comparto 😉
salu2
En este link hay un muy buen POST de como alamcenar información de configuración para aplicaciones BizTalk.
BizTalkLATAM’s Blog : ¿Donde guardo mis parámetros de configuración?
salu2
Por fin se liberó a nivel mundial el Plug-in de BlackBerry para Visual Studio .NET. Este permite generar aplicaciones para BlackBerry.
Se puede descargar del siguiente Link:
Visual Studio Plugin Now Available Globally | BlackBerry Developer Community
Yo ya tengo el mio funcionando!!!!! 😉
salu2
Este documento muestra una completa comparación hecha entre dos aplicaciones que tienen la misma funcionalidad. Una de estas aplicaciones está implementada en .NET (.NET StockTrader) versus otra hecha en IBM WebSphere (Trade 6.1 performance sample).
Este documento contiene la comparación de desempeño en diferentes configuraciones de las aplicaciones, incluyendo el desempeño de los Web Services, desempeño de la mensajería, etc.
El documento incluye todos los parámetros de sintonía y detalles de pruebas con la idea que uno pueda repetirla las pruebas para así corroborar los sorprendentes resultados que presenta el informe.
EL informe pueden descárgalo desde aquí
Ahora, para los Developer como yo, les paso el el link desde donde pueden descargar la aplicación .NET 3.0 StockTrader
Salu2
..:: Liarjo of Locksley ::.. 