Congreso. ANACAP 2009.

Ya está en marcha la segunda edición del ANACAP, el Workshop en Aplicaciones de Nuevas Arquitecturas de Consumo y Altas Prestaciones.

Tendrá lugar los días 19 y 20 de Noviembre del 2009 en la Universidad Rey Juan Carlos de Madrid y los temas de interés son los mismos que el año pasado: Procesamiento de señal, imagen digital y vídeo, Análisis de patrones, Evaluación de rendimiento, Simulación física, Visión computacional, etc.

Si os interesa enviar algún trabajo, el plazo termina el 30 de Septiembre, y os dejo el enlace donde se irá colgando toda la información acerca del Workshop para los que estéis interesados en asistir (los tutoriales fueron un éxito el año pasado para los "no-expertos" en estos temas).

http://www.gavab.etsii.urjc.es/capo/anacap/2009/index.html
aaa

El origen de las fábricas de software

Entrada escrita por Juan José Cabezuelo, Responsable Oficina de Conocimiento Informática Industrial del Grupo Intermark. (jjcabezuelo@grupointermark.com)http://www.grupointermark.com/

Las fábricas de software nacen buscando los beneficios que las líneas de producción industrial aportaron en la calidad de los productos y en la productividad lograda.

Las líneas de producción se basan en tener definido un proceso y un flujo que sigue cada operación en el proceso, además de proveer las herramientas necesarias para llevar a cabo la acción deseada. Para todo esto hay que contar, lógicamente, con personas, que en el caso de la cadena de producción tienen limitadas sus acciones a un entorno restringido.

Desde este punto de vista, la cadena de producción es un mecanismo que permite a un trabajador estar habilitado para tomar una acción altamente eficaz y eficiente en un momento adecuado del proceso. En el entorno de las tecnologías de la información es posible crear cadenas "virtuales" de producción donde el proceso y el flujo estén claramente definidos.

El concepto de fábrica de software aparece por primera vez en 1968. La idea fue desarrollada casi en paralelo por Japón y Estados Unidos, siendo pioneras las compañías System Development Corporation (SDC) e Hitachi a través de Hitachi Software Works.

El concepto de fábrica de software de SDC giró entorno a los siguientes aspectos:

• Control de proyectos y aseguramiento de la calidad
• Creación de procedimientos y estándares en las áreas de diseño, construcción y pruebas de sistema
• Creación de manuales de desarrollo a partir de la retroalimentación de las metodologías puestas en práctica.
  
  

Hitachi desarrolló un modelo de fábrica basado en aspectos como:

• Definición y medición de los procesos de desarrollo de software
• Incorporación de elementos de medición y control de calidad
• Estandarización de cualquier tipo de aplicación en un solo proceso de desarrollo
• Definición de tiempos estándares de actividad, análisis de defectos, etc.
• Creación de herramientas propias de desarrollo
  

Toshiba, por su parte, planteó un modelo de fábrica basada en:

• Estandarización del proceso de desarrollo de software para reducir variaciones entre proyectos
• Reutilización de diseños, programas y componentes para construir nuevos sistemas con objeto de reducir el trabajo redundante y maximizar la productividad
• Introducción del uso de herramientas estándar a fin de elevar los niveles de desempeño de las personas
• Proveer entrenamiento extensivo en las personas
  

Sobre estas bases se apoyan las Software Factory, que están permitiendo hoy en día lograr modelos de producción deslocalizada similares a los existentes en el mundo industrial.

mm

BPM: Business Process Management (y II)

La evolución de la metodología y componentes tecnológicos de las soluciones WorkFlow tradicionales junto a las funcionalidades que permiten la integración de distintos datos y aplicaciones de un organización (ESB, SOA, EAI, etc) constituyen hoy en día las soluciones BPM.

Este tipo de solución permite construir procesos de negocio coordinando actividades interactivas (human task) y servicios (system task).

Una solución BPM alinea procesos de negocio con los objetivos estratégicos de la empresa; diseña e implementa un modelo de negocio que representa la realidad de las actividades realizadas en una organización para generar valor cuantitativo o cualitativo para ésta, establece KPIs que midan el estado e idoneidad de estos procesos y enseña a la dirección de las empresas a optimizar estos procesos con el fin de que la empresa sea más eficiente.

Las etapas básicas en el funcionamiento de una solución BPM son las siguientes:

-Modelado de los procesos de negocio: En esta etapa se crea un modelo del funcionamiento de la organización y de sus procesos. El principal involucrado es el Analista de Negocios y su labor es
crítica, ya que el corazón de una solución BPM es el modelo del proceso de negocio.

-Implementación: En esta etapa se integran los componentes necesarios para implementar el proceso. El principal involucrado en esta etapa es el Ingeniero de TI si los procesos se implementen como soluciones tecnológicas.

-Ejecución de procesos: Ésta es la etapa en donde se explota el proceso desarrollado previamente, en esta etapa los principales involucrados son los Participantes del proceso. Además aquí es cuando se recolecta la información para control y seguimiento y donde puede utilizarse una solución BAM.

-Control: Ésta es la etapa donde se le da seguimiento a los procesos, y donde se analiza la información de su ejecución, por ejemplo, indicadores de rendimiento, cuellos de botella, caminos críticos, carga de trabajo, etc. Su principal característica es que la información se analiza en tiempo real. En esta etapa los principales involucrados son los Supervisores y la Gerencia.
,,

BPM: Business Process Management (I)

El paradigma de Business Process Management (BPM) se basa en la importancia de integrar todos los procesos de negocio y corporativos de una organización, además de integrar datos y aplicaciones. El objetivo es diseñar y controlar la estructura organizativa de forma flexible, de modo que ésta puede adaptarse rápidamente a nuevas situaciones. Por tanto BPM es el conjunto de servicios y herramientas que facilitan la administración de procesos de negocio, entendiendo por administración de procesos su análisis, definición, ejecución, monitorización y control.

m
Durante los años 90, los sistemas WFMS (WorkFlow Management Systems) fueron los encargados de integrar islas de procesos a alto nivel. Es decir daban soluciones de gestión de proceso allá donde las aplicaciones corporativas no llegaban. Estos sistemas estaban orientados a gestionar actividades de negocio y tenían un carácter rígido. Además, requerían de la interactuación humana para ejecutar las aplicaciones corporativas que intervenían en el WorkFlow (flujo de trabajo) y no tenían capacidad de integrar las aplicaciones que suministraban información o servicios a la organización.

m

WorkFlow era la tecnología que permitía coordinar actividades que eran ejecutadas por personas y se basaba en la definición de los roles, privilegios y reglas de negocio necesarios para llevar acabo dichas actividades.

,
En una herramienta WorkFlow, el usuario comienza indicando el inicio de la actividad, y esto produce un cambio de estado en el sistema. Por ejemplo, se envía una hoja de gastos al departamento de administración y el flujo de trabajo indica que esta hoja de gastos debe ser aprobada por varios superiores y luego debe ser introducida en el sistema ERP por administración.

El sistema WorkFlow indica qué procesos o pasos deben seguirsehasta que dicha hoja es introducida finalmente en el sistema ERP. Los usuarios deben tener en cuenta este proceso y acceder a las aplicaciones transaccionales (ERP) que sean pertinentes para finalizar el flujo de trabajo con éxito. En caso de que estuviéramos hablando de un sistema BPM, la aplicación ERP estaría integrada en el WorkFlow y para el usuario, la validación de la hoja de gastos y su entrada en administración, serían procesos transparentes. Es decir, desde la propia solución BPM, accedería aun interfaz que le permitiría realizar la aprobación y la entrada de la información sin tener constancia de que está levantando los servicios del sistema ERP que permite realizar dichas operaciones.

mm

Patrones EAI (y V)

Terminamos hoy con esta serie de entradas explicando brevemente los patrones que se han identificado en las dos últimas categorías. La primera de ellas, Message Transformation, describe cómo traducir los datos de los formatos de unas aplicaciones a los de otras:

• Envelope Wrapper: Módulo que introduce los datos de las aplicaciones en sobres que cumplen con las especificaciones de la infraestructura de mensajería. Es decir, que los envuelve en el formato adecuado.
• Message Translator: Módulo capaz de traducir entre diferentes formatos de mensajes.
• Content Enricher: Módulo capaz de añadir información externa a un mensaje tras su generación en la aplicación origen, para que el receptor reciba el toda la información que necesita.
• Content Filter: Módulo capaz de eliminar de un mensaje ya generado toda la información innecesaria.
• Claim Check: Módulo que permite reducir el tamaño de los mensajes almacenando parte de la información que incluyen en consignas de datos que sólo los receptores de los mensajes modificados podrán utilizar.
• Normalizer: Módulo compuesto por un enrutador y uno o varios Message Translator.
• Canonical Data Model: Modelo de datos que todas las aplicaciones que se desea integrar deben utilizar para generar y consumir mensajes. Si se utiliza, evita la utilización de wrappers, translators, etc.

En cuanto a la última categoría, System Management, es la que describe cómo monitorizar y controlar el uso que las aplicaciones hacen del sistema de mensajes. También describe cómo analizar el tráfico que se genera y cómo hacer depuración de los errores:

• Control Bus: Se trata de una infraestructura de mensajería igual que la empleada para el intercambio de información entre aplicaciones pero que se encarga de transmitir la información de control de las comunicaciones. Todas las aplicaciones deben conectarse a este bus de control además de a la infraestructura de mensajes para el intercambio de datos.
• Message Store: Es un módulo central para almacenar una copia de todos los mensajes enviados por el canal (o una copia parcial, dependiendo de los campos de los mensajes que se necesiten). Con estas copias, se podrán realizar trabajos de monitorización, control, etc.
• Detour: Se trata de un módulo construido con un router basado en contexto que en ciertos casos, en lugar de encamimar directamente el mensaje desde el origen hasta el destino (sin modificarlo), lo encamina pasando por unos pasos intermedios de control, validación y debug (que pueden introducir modificaciones en el mensaje si fuera necesario).
• Wire Tap: Este tipo de módulo se inserta en el canal de comunicaciones cuando se desea monitorizar una conexión punto a punto. El Wire Tap se convierte en el receptor del mensaje (que llega por su único canal de entrada) y lo reenvía, sin modificaciones, por sus dos canales de salida. Uno, hacia el receptor real y el otro, hacia el canal de monitorización.
• Smart Proxy: Se trata de un módulo intermediario entre aplicaciones que hacen peticiones y aplicaciones que proporcionan contestaciones (servicios). Este proxy almacena las Return Address para que las contestaciones lleguen a las aplicaciones adecuadas.
• Channel Purger: Es un módulo capaz de retirar mensajes del canal de comunicaciones, todos ellos o los que cumplan unos determinados criterios.
• Test Message: Mensaje especial que se utiliza para comprobar el buen o mal funcionamiento de la infraestructura de mensajería y para detectar fallos, cuellos de botella, etc.
• Message History: Campo que se añade a los mensajes, en forma de lista, que almacena el identificador de todas las aplicaciones desde la emisora, que han procesado el mensaje.

Solución Hewlett-Packard para la arquitectura ZLE (II)

Las principales aportaciones del ZLE framework son las siguientes:

• El ZLE framework desarrollado por HP permite una integración de datos, aplicaciones y procesos eficiente. Las tecnologías tradicionales y soluciones EAI y Datawarehousing cubren sólo parte de esta integración.
• La gestión en tiempo real implica poner en explotación una arquitectura tecnológica que sincronice y genere flujos de información. El ZLE framework de HP ha desarrollado una arquitectura que consolida datos y sincroniza aplicaciones a través de un base de datos en tiempo real llamada ZLE datastore. Se puede definir la ZLE data store como una caché de toda la información generada por una organización.
• El ZLE framework utiliza herramientas EAI para mantener las aplicaciones sincronizadas con la ZLE data store, así comolos datos que estas generan. Por tanto existe una bidireccionalidad entre las aplicaciones y la base de datos entiempo real.
• Los datos son redundantes y disponibles entre las aplicacionesy la ZLE data store, pero no entre las distintas aplicaciones. Se utiliza el ZLE data store como middleware de integración de datos y aplicaciones.

mm

Evento. Asegur@IT 6

Este evento acerca de Seguridad Informática suele ser muy interesante y se celebrará mañana jueves 18 en Getafe (Madrid).

Las charlas de este año tratan temas tan variados como la auditoría de redes WiFi, las técnicas de inyección de código en aplicaciones web que utilicen XPath o las Rainbow Tables.

Aquí os dejo el enlace, todavía estáis a tiempo de registraros:

http://www.informatica64.com/aseguraIT6/
aa

Patrones EAI (IV)

Resumimos hoy los patrones dentro de la categoría Message Routing, que describen las diferentes técnicas y mecanismos documentados para enrutar los mensajes desde el origen hacia el destino por los canales de comunicaciones que ofrece el sistema de mensajería.

• Routing slip: Campo que se añade a un mensaje que debe procesarse siguiendo una serie de pasos que no se conocían en tiempo de diseño o que pueden variar de unos mensajes a otros.
• Recipient List: Lista que debe mantener todo enrutador actualizada para saber por que canal de salida encaminar un mensaje dependiendo de cuál sea su dirección destino.
• Content-based router: Enrutador capaz de encaminar la información a un destino u otro dependiendo del contenido de los mensajes.
• Message Filter: Módulo capaz de filtrar los mensajes por contenido de manera que evita la recepción de mensajes indeseados.
• Dynamic router: Enrutador capaz de adaptarse dinámicamente a los cambios en la infraestructura de mensajes. Se suele autoconfigurar tras recibir mensajes que le especifican las modificaciones que han tenido lugar.
• Splitter: Enrutador capaz de dividir un mensaje en sus componentes principales cuándo es necesario que cada uno sea procesado y/o encaminado por separado.
• Aggregator: Enrutador capaz de construir un mensaje a partir de diferentes componentes que debe ser procesados y/o encaminados juntos.
• Resequencer: Enrutador capaz de ordenar según unos criterios dados, los mensajes de una secuencia de mensajes.
• Composed Message Processor: Procesador compuesto normalmente de un splitter, un router y un aggregator, capaz de separar los componentes de un mensaje, procesarlos por separado y reagruparlos para continuar su encaminamiento.
• Scatter-Gather: Enrutador capaz de enviar una petición a varios destinatarios (de hacer un broadcast o multicast) y de agrupar todas las contestaciones en un único mensaje.
• Process Manager: Enrutador capaz de realizar secuencias complejas de pasos (routing slips que no son secuenciales, por ejemplo) para procesar y/o encaminar un mensaje.
• Message Broker: Módulo tipo hub-and-spoke, es decir, enrutador complejo capaz de recibir mensajes de múltiples emisores y de reenviarlo a múltiples destinos.

aaa

Patrones EAI (III)

Hoy resumimos los patrones Messaging Channels (paciencia, con esto llegamos a la mitad), que describen el funcionamiento del sistema de mensajería y las características de los canales de comunicación:

• Channel Adapter: Módulo que permite comunicar el canal del sistema de mensajería con las APIs de las aplicaciones para que éstas sean capaces de enviar y recibir mensajes.
• Point-to-point Channel: Comunicación punto a punto entre emisor y receptor (comunicación uno a uno).
• Publish-Subscribe Channel: Comunicación mediante mecanismos de publicación y suscripción (comunicación uno a muchos).
• Message Bus: Comunicación utilizando un medio compartido de tipo bus (una única infraestructura de mensajes), con un único modelo de datos y un único conjunto de comandos estandarizados. La conexión y desconexión de aplicaciones en este caso debe ser casi inmediata y transparente a los usuarios.
• Datatype Channel: Técnica que consiste en separar en diferentes canales de comunicaciones los datos con diferentes formatos. Así, dependiendo del canal de por el que entre un mensaje, el receptor sabrá directamente cómo procesar los datos.
• Invalid Message Channel: Canal específico al que todos los receptores envían los mensajes que no son capaces de procesar.
• Dead Letter Channel: Canal que utiliza el sistema de mensajería cuando no consigue entregar los mensajes en su destino.
• Guaranteed Delivery: Canal que incorpora un sistema de almacenamiento (por ejemplo, un disco duro), de manea que puede garantizar que los mensajes serán entregados incluso si el sistema
• de mensajería falla.
• Messaging Bridge: Puente que une dos sistemas de mensajería replicando todos los mensajes de uno en el otro y viceversa.

aaaa

Patrones EAI (II)

Vamos hoy con la segunda categoría de EAI, Message Construction. En este caso se describen los tipos de mensajes que las aplicaciones pueden intercambiar en función de su tamaño, de su intención, de si se espera una respuesta, etc.

Nos encontramos en esta categoría los siguientes patrones para integración:

• Command Message: Mensaje utilizado para invocar un procedimiento de manera segura en otra aplicación (tipo Remote Procedure Call).
• Document Message: Mensaje utilizado para transferir entre dos aplicaciones una estructura de datos.
• Event Message: Mensaje utilizado para notificar un evento a una o varias aplicaciones observadoras de este evento.
• Message Sequence: Secuencia de mensajes que se utiliza cuando se desea transferir una gran cantidad de información entre dos aplicaciones y no cabe en un único mensaje. Se parte en varios mensajes que se identifican con un número de secuencia para mantener el orden correcto.
• Request-Reply: Mensaje utilizado para establecer una comunicación bidireccional de petición y contestación.
• Format Indicator: Mensaje utilizado para comunicar una modificación en el modelo canónico de datos que se está utilizando para compartir información entre aplicaciones.
• Message Expiration: Campo de un mensaje que permite especificar durante cuanto tiempo es útil. Es decir, una vez pasado el plazo especificado en este campo, el mensaje debe ignorarse.
• Return Address: Campo de un mensaje que lleva una petición, que indica al receptor de la petición el destino de su contestación. Se utiliza con mensajes Request-Reply.
• Correlation Identifier: Campo de un mensaje que lleva una contestación, que permite al emisor de la petición identificar a cuál de sus peticiones se está contestando. Se utiliza con mensajes Request-Reply.

aaa

Solución Hewlett-Packard para la arquitectura ZLE (I)

La arquitectura ZLE puede implementarse llevando a cabo undesarrollo a medida que reutilice las aplicaciones que ya existían en la organización utilizando metodologías de reingeniería de software tipo EAI. O puede utilizar la infraestructura desarrollada por la multinacional Hewlett-Packard (HP), que partiendo del enfoque propuesto por Gartner, comercializa una solución tecnológica para ZLE.

m

Durante algunas entradas analizaremos la solución propuesta por Hewlett-Packard, por ser la única solución específica desarrollada hasta el momento para ZLE.

n

La arquitectura ZLE desarrollada por HP (ZLE framework) esuna arquitectura software y hardware que se basa en un hub virtualllamado (ZLE core). Como se ha comentado anteriormente, ZLE implica la integración de datos y procesos. La principal ventaja de esta arquitectura es que HP funde en ella las funcionalidades de las soluciones BI con las funcionalidades de un EAI, permitiendo al unísono la integración,sincronización y consolidación de la información, el desarrollo del flujo óptimo de entrega de dicha información en toda la organización, la integración de procesos de negocio, la captura de eventos transaccionales, la transformación de mensajes entre aplicaciones y la generación y ejecución de reglas de negocio. Además establecen estándares para el hardware sobre el que se ejecutan los servicios de la plataforma.

m

La tecnología en la que se basa el ZLE framework (a diferencia de las tecnologías basadas en procesos batch, en la quela actualización de datos, se hace por paquetes de información con latencias de más de un día), permite la actualización ysincronización de sistemas y personas en tiempo real. Este concepto aplicado a un ejemplo real, supone que si un posible cliente accede al sitio web de una compañía, este evento, desencadenará en el sistema CRM corporativo las acciones oportunas que permitan proporcionar información adicho cliente potencial, asignarle un comercial para que realice llamadas de prospección, etc.

mm

Barreras en la implantación de ZLE

En esta entrada http://redindustria.blogspot.com/2008/04/zero-latency-enterprise.html os definimos el concepto de ZLE y enunciamos las principales ventajas que aporta esta estrategia.

En esta entrada, describimos las principales barreras que pueden encontrarse a la hora de llevarla a cabo.

m

Las primeras de las barreras tiene que ver con las personas, ya que suele existir una actitud negativa por parte de los integrantes de una organización ante la implantación de nuevos sistemas de información y nuevos procedimientos de negocio. Los procesos de negocio suelen presentar latencias excesivas para abordar la implantación de una estrategia ZLE y suele existir resistencia por parte del personal para llevar a cabo las acciones necesarias para reducir estas latencias. En cuanto a la dirección de las organizaciones, suelen percibir que la adaptación a un entorno ZLE es un proceso complejo y costoso, que no siempre termina compensando la inversión realizada.

m
El resto de barreras suelen ser más bien tecnológicas. El aislamiento de ciertos sistemas dentro de las organizaciones y la existencia de cajas negras de información a las que no se puede acceder, dificulta mucho la consecución del nivel de integración entre sistemas necesario para obtener ZLE. Además, hay que enfrentarse a la incompatibilidad de sistemas software y/o hardware de diferentes procedencias y fabricantes así como a la existencia de islas de información a diferentes niveles (tanto transaccional como tiempo real).

mm

Patrones EAI (I)

Comenzamos hoy con una serie de entradas que resumen los patrones EAI (Enterprise Application Integration) actuales.

Estos patrones documentan las prácticas de integración de aplicaciones mediante paso de mensajes (es decir, utilizando middleware de tipo MOM) más habituales y sirven de gran ayuda a la hora de abordar un proyecto de integración o interoperabilidad.

Los patrones de EAI se agrupan en categorías que representan diferentes tipos de problema y resumen los distintos tipos de soluciones exploradas hasta el momento. Actualmente son seis categorías y estos son los patrones para la primera de ellas, Message Endpoints, que describe las diferentes maneras de conectar las aplicaciones con los sistemas de mensajes, es decir, define cómo las aplicaciones pueden enviar y recibir mensajes: de manera síncrona o asíncrona, directamente o a través de algún bloque de código con funciones concretas, recibiendo todos los mensajes o utilizando algún tipo de filtro, etc.

• Messaging Gateway: El código necesario para enviar y recibir mensajes está separado del resto de la aplicación.
• Messaging Mapper: Existe un bloque de código encargado de convertir los objetos de negocio al formato necesario para acceder a la infraestructura de mensajería y viceversa.
• Transactional client: El acceso al sistema de mensajería para enviar y recibir mensajes se contempla como una transacción explícita por parte de las aplicaciones.
• Polling Consumer: Para recibir los mensajes se necesita una comprobación por parte del receptor para ver si hay mensajes pendientes.
• Event-driven Consumer: El sistema de mensajería activa un evento para avisar al receptor de al llegada de un nuevo mensaje.
• Competing Consumer: Varios receptores conectados a un mismo canal pueden recibir los mensajes que llegan por él. Deben competir por recibirlos, porque una vez entregado un mensaje en un receptor, no llega a los demás.
• Message Dispatcher: Varios receptores conectados a un mismo canal pueden recibir los mensajes que llegan por él. Entre ellos y el canal se coloca un repartidor que recibe los mensajes y los entrega al receptor adecuado en cada caso.
• Idempotent Receiver: Un receptor puede recibir el mismo mensaje en múltiples ocasiones sin que esto afecte al funcionamiento de la aplicación.
• Service Activator: La recepción del mensaje se hace en un activador que invoca a un servicio concreto o al servicio que haya pedido el mensaje.
• Selective Consumer: El receptor filtra los mensajes recibidos por el canal de manera que sólo procesa aquéllos que cumplen sus criterios de búsqueda.
• Durable Subscriber: Cuando se utilizan sistemas de publicación y suscripción, este tipo de endpoint permite guardar los mensajes que se han publicado mientras el receptor estaba desconectado para que no se pierdan.

Para obtener más información acerca de estos patrones (los más complicados se entienden muy bien con los diagramas), os dejo el siguiente enlace, en el que también tenéis la información del libro en el que están publicados los patrones:

http://www.eaipatterns.com
aaa