Sip, como se lee. Estaba yo en mi oficina trabajando duro, no durando en el trabajo, y de repente me saludan por MSN muy amablemente Ana. Yo por no ser descortés le devuelvo su cariñoso saludo. Tengo en mi MSN 146 contactos, de toda una vida online y viendo esto hay varios que no se quienes son

Después de hablar cosas normales y sin profundidad, ella me dice “tú no eres mi amigo Juan Pablo”. Bingo, la verdad no tenía yo idea tampoco con quien hablaba. Esto me pareció divertido por lo menos, ya que charlamos un rato sin que cayéramos en cuenta de ello.

Después de caer en conciencia de que no nos conocíamos, procedimos como humanos civilizados a presentarnos y compartir intereses, etc. Estas cosas no pasaban cuando yo era un pendex, porque no existía MSN. Recuerdo que usé ICQ porque unos compañeros de la U adictos al CHAT, Matias y Andres, me dijeron “JP el ICQ es como un BEEPER pero de Internet”. Para los pendex, les cuento que antes del advenimiento del celular había una tecnología llamada BEEPER, que era como SMS pero por radio frecuencia y solo podías enviarlos a través de una operadora telefónica, y recibirlo en un aparato con un display monocromático de unos 8 caracteres.

Es esos días, nadie usaba MSN ni ICQ, encontrase con alguien era un milagro, ahora la cosa es diferente. Yo vivo online, paso casi todo el día ONLINE tanto en el trabajo cómo en la casa. Hablo más con mis amigos por MSN que por teléfono y me pasan estas  experiencias digitales.

Ana fue un gusto.

He estado mirando el Beta de esta maravilla y estoy gratamente impresionado. Es la herramienta  que los Developer .NET necesitábamos para pasar de desarrollos “duros” a modelos de “flujos de trabajo” sin tener que utilizar herramientas costosísimas. No digo que las herramientas de workflow no agreguen valor, pero en el 80% de los proyectos en mi pueblo no tienen presupuesto para licencias esos motores Premium.

WWF es un componente CORE de la siguiente versión del Framework .NET llamado WinFx. WWF fue concebido con los siguientes objetivos claves:

1. Proveer un solo motor de Workflow para la ejecución de este tipo de aplicaciones en la plataforma .NET.
2. Soportar todo tipo de flujos de trabajo, del tipo centrados en humanos y aplicaciones.
3. Apoyar a los actuales desarrolladores .NET a implementar aplicaciones que implementen el estilo MODEL-DRIVEN WORKFLOW.
4. Permitir el desarrollo de componentes de WORKFLOW re-usables con puntos de extensión para que los desarrolladores puedan incluirlos en sus aplicaciones.

Creo que esté CORE COMPONENT será uno de los más importantes para los desarrolladores en la próxima generación de aplicaciones.

Pronto les cuento cual es su arquitectura……

El sábado me voy al PDC. Quienes han ido me han dicho que es puro filete técnico lo que se ve ahí. Cuando comento de este viaje, los “colegas” se extrañan por dos razones principalmente.

La primera versa sobre el financiamiento, no es compresible para muchos pagar por eventos cómo estos. No me queda claro que sea porque no tienen las lukas sino porque de tenerlas  mejor se compran un TV gigante para ver cosas que no los hagan pensar.

La segunda dicta sobre el poco tiempo que tengo en mi nuevo trabajo, 2 semanas, para viajar una semana y no estar “produciendo”. Me parece que no ven el valor de estar al día es los aspectos tecnologicos para las compañías. Por esto, vienen empresas de afuera y nos dan “Boleta” en los aspectos técnicos, nos quitan los clientes. Esto sin ni siquiera tener oficina en el país.

La ingeniería de roles para RBAC es el proceso de definición de roles, permisos y asignación de permisos para cada role.  Esto es esencialmente un proceso de ingeniería de requerimientos de roles (RE). La ingeniería de roles es el primer paso hacia la implementación de un sistema RBAC.

La ingeniería de roles pude ser descompuesta en tres etapas. No veremos el detalle de cada etapa, pero describiremos los objetivos de cada una de las etapas, porque no todas las actividades de este modelo de procesos son necesarias en este caso.

La primera consiste en el análisis de los permisos y roles que se quiere implementar. El nombre de está etapa en ingles ROLE-PERMISSION ANALYSIS (RAP). A esta etapa ingresan los objetivos de las aplicaciones, información del contexto y un análisis de escenario. Cómo resultado de está etapa se obtienen roles y permisos candidatos.

La segunda etapa llamada ROLE-PERMISSION REFINEMENT, tiene como objetivo el concretar el análisis para producir los roles y permisos definitivos. A esta etapa ingresan los roles, escenarios  y permisos candidatos para su refinamiento. El resultado de está etapa son roles y permisos definitivos, lo que podemos llamar el modelo RBAC.

La última etapa, llamada ROLE-PERMISSION MAINTENANCE (RPM), tiene como objetivo fijar las políticas adecuadas para que el modelo RBAC se mantenga vigente en el tiempo. Las principales actividades de esta etapa de operación son:

• Mantenimiento de roles.
• Mantenimiento de permisos.
• Mantención de la relación roles y permisos.
• Delegar administración. 

El diagrama muestra el modelo de procesos explicado en esta sección que fue escrito por Qingfeng He, de la universidad de Carolina del Norte.

El patrón MESSAGE BROKER

Es un componente que administra
las comunicaciones entre aplicaciones. La idea es que todas las aplicaciones se
comuniquen entre sí a través de él. Las aplicaciones envían un mensaje que
contiene dos tipos de datos, datos fuera de banda y de negocio. Los primeros
son información de contexto que es usada por el MESSAGE BROKER. Un ejemplo de
estos datos es la aplicación de destino del mensaje. Los datos de negocio se refieren
específicamente a los datos que la aplicación destino requiere para efectuar la
llamada requerida por la aplicación generadora del request.

El MESSAGE BROKER administra
información de contexto que le permite hacer un MATCH entre el contenido de los
datos fuera de banda. Un ejemplo de esto es que el mensaje dice una aplicación
de destino como “aplicación_1”, “ventas”, “666”, etc. De ese identificador de
aplicación de destino el BROKER debe determinar dónde está la aplicación y cómo
se comunica con ella. Es aquí donde utiliza la información de contexto
administrada por él. En ella encuentra correlato entre el contenido del mensaje
y una dirección física y canal de trasporte.

Las cuatro responsabilidades
básicas del BROKER son:

1. Recibir mensajes desde las aplicaciones
   registradas.
2. Determinar la aplicación de destino y el canal de
   comunicaciones a usar con ella.
3. Administrar cualquier diferencia con la interfaz de
   la aplicación de destino.
4. Enviar el mensaje a la aplicación destino, si
   corresponde responder a la aplicación de origen.

El siguiente diagrama muestra un
esquema de este patrón de integración.

¿Cómo implementarlo en BizTalk 2004?

Para implementar un MESSAGE
BROKER con BizTalk 2004 sólo es necesario hacer uso de BizTalk MESSAGING. Esto
rompe una idea recurrente en los desarrolladores los cuales piensan que toda
solución hecha en BizTalk necesariamente involucra una “orquestación”.

BizTalk MESSAGING provee varias
formas de enrutar, procesar y enviar mensajes entre
procesos de negocio.  Las tareas
principales que provee el servicio de MESSAGING son:

1. Recepción de documentos (mensajes).
2. PARSES de los mensajes entrantes para determinar su
   tipo especifico.
3. Extraer las llaves de identificación y valores
   usados en las reglas de ruteo.
4. Envío de mensajes a sus respectivos destinatarios.
5. Hacer traking de los
   mensajes.

BizTalk utiliza un modelo llamado
“Publish and Subscribe” que
le permite mayor escalamiento, tanto en la base de datos como en el
procesamiento de los mensajes. El concepto de suscripción  es el criterio que describe que tipos de
mensajes recibirá cada destinatario.

La idea es implementar un canal
de recepción de mensajes, que en jerga BizTalk sería un “puerto de recepción”,
para que las aplicaciones envíen ahí sus mensajes. Luego, según un criterio de
suscripción, el mensaje será despachado al puerto de salida que corresponda.
Esto suena muy simple, y en rigor lo es usando BizTalk.

Los pasos necesarios para
implementar el BROKER son:

1. Crear un esquema de mensaje
1. Promover los valores que se usaran cómo identificadores
   en el criterio de suscripción.
2. Crear un puerto de recepción y un lugar de
   recepción.
3. Crear los puertos de salida.
1. Configurar los filtros necesarios.
2. Suscribir los puertos al mensaje.
4. Iniciar los puertos de entrada y salida.

Después de esto ya se tiene listo
el BROKER para un tipo de mensajes. Aquí hay que tener claridad que lo
importante es poder definir un mensaje de negocio lo suficientemente genérico
que permita tener información fuera de banda que sea usada por BizTalk e
información del negocio que será usada por la aplicación destino.

Crear el esquema del mensaje

Usando Visual Studio creamos el siguiente esquema.

Este esquema sólo nos da la
estructura del mensaje. Ahora debemos “destacar” que partes del mensaje
usaremos cómo criterios de la suscripción. Esto se hace promoviendo por ejemplo
el campo APLICACIÓN del TAG HEADER.

Para esto se debe apretar el
botón derecho sobre el campo y seleccionar “QUICK PROMOTION”. Esto hace que ese
valor ahora pueda ser usado en los filtros de ruteo y
criterios de suscripción. La siguiente imagen muestra el resultado de la
promoción del campo aplicación.

Crear un puerto de recepción y un lugar de recepción

Crear los puertos de salida

Iniciar los puertos de entrada y salida