Tendencias Tecnologicas en Desarrollo de Aplicaciones

Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones

Página 1 de 1 TTADA

Tendencias Tecnológicas en Arquitecturas y Desarrollo de

Aplicaciones

Trabajos Diciembre 2004

Departamento de Computación Facultad de Ciencias Exactas Universidad de Buenos Aires



Indice Introducción.......................................................................................................................4 eXtreme Programming .......................................................................................................5

¿Qué es XP?................................................................................................................................................... 5 ¿Porqué surge XP?......................................................................................................................................... 5 Principios de XP ............................................................................................................................................ 5 Prácticas de XP .............................................................................................................................................. 7 ¿Es XP económicamente viable? ................................................................................................................... 9 ¿Cuándo usar XP ?......................................................................................................................................... 9 ¿Cuándo NO usar XP ? ................................................................................................................................ 10 XP vs. metodologías tradicionales ............................................................................................................... 10 Conclusiones................................................................................................................................................ 11 Bibliografía .................................................................................................................................................. 11

Extreme Programming vs. CMM .....................................................................................12 ¿Qué es XP?................................................................................................................................................. 12 Prácticas de XP ............................................................................................................................................ 12 XP vs. CMM................................................................................................................................................ 13 Casos de estudio........................................................................................................................................... 14 Bibliografía .................................................................................................................................................. 15

Buenas Practicas ..............................................................................................................16 Introducción ................................................................................................................................................. 16 Porque ? ....................................................................................................................................................... 16 Que Son ?..................................................................................................................................................... 16 Sobre que ?................................................................................................................................................... 17 Desarrollo de Aplicaciones .......................................................................................................................... 17 Conclusiones. ............................................................................................................................................... 22 Referencias................................................................................................................................................... 22

EAI: Un Vistazo General .................................................................................................25 Resumen ...................................................................................................................................................... 25 Qué es EAI? ................................................................................................................................................. 25 Muchos nombres, la misma intención.......................................................................................................... 25 Actualidad.................................................................................................................................................... 26 Futuro........................................................................................................................................................... 28 Conclusión ................................................................................................................................................... 28 Referencias................................................................................................................................................... 29

SOA – Caso de Estudio....................................................................................................30 Introducción ................................................................................................................................................. 30 Requerimientos ............................................................................................................................................ 30 Niveles de Arquitectura ............................................................................................................................... 30 Requisitos de Diseño y Construcción .......................................................................................................... 32 La Arquitectura Orientada a Servicios ......................................................................................................... 32 Despliegue de Componentes........................................................................................................................ 35 Referencias................................................................................................................................................... 38

Model Driven Architecture ..............................................................................................39 Introducción ................................................................................................................................................. 39 Construyendo una aplicación MDA............................................................................................................. 40 Ingeniería de Reversa y Bridge Generation ................................................................................................. 41 Detalle de Conceptos utilizados en MDA.................................................................................................... 42 Productos ..................................................................................................................................................... 44 Conclusiones................................................................................................................................................ 46 Bibliografía .................................................................................................................................................. 47

Integración de Aplicaciones con Web Services ................................................................48 Acerca de este documento ........................................................................................................................... 48 Introducción ................................................................................................................................................. 48 El Problema: La Integración ........................................................................................................................ 48 Solución ....................................................................................................................................................... 49 La Tecnología .............................................................................................................................................. 50 Integrando con SOAP .................................................................................................................................. 54 Conclusión ................................................................................................................................................... 55



Referencias................................................................................................................................................... 56 Business Process Management (BPM) .............................................................................58

Introducción ................................................................................................................................................. 58 ¿Qué es Business Process Management (BPM)?......................................................................................... 58 BPM en la práctica....................................................................................................................................... 60 La tecnología de BPM ................................................................................................................................. 62 BPM hoy...................................................................................................................................................... 65 Conclusiones................................................................................................................................................ 66 Bibliografía .................................................................................................................................................. 67

JAIN/SLEE......................................................................................................................68 Introducción ................................................................................................................................................. 68 Motivación ................................................................................................................................................... 68 Objetivos...................................................................................................................................................... 68 JAIN Service Logic Excecution Enviroment (JSLEE) ................................................................................ 69 Jain Session Initiation Protocol (JSIP)......................................................................................................... 71 JAIN y otras tecnologías de Java (Big Picture)............................................................................................ 72 Estado .......................................................................................................................................................... 72 Conclusión ................................................................................................................................................... 73 Referencias................................................................................................................................................... 73

Programación Orientada a Aspectos.................................................................................74 Introducción ................................................................................................................................................. 74 El problema a resolver ................................................................................................................................. 74 Algunas definiciones básicas ....................................................................................................................... 74 Aprendiendo AOP con un ejemplo .............................................................................................................. 75 Herramientas disponibles para java y .net.................................................................................................... 76 Visión de futuro ........................................................................................................................................... 77 Conclusiones................................................................................................................................................ 78 Bibliografía .................................................................................................................................................. 78

Sistemas de Administración de Contenidos ......................................................................79 ¿Qué es un CMS? ........................................................................................................................................ 79 Algo de historia............................................................................................................................................ 79 Conceptos importantes detrás de un CMS ................................................................................................... 80 ¿Cuándo conviene usar un CMS? [1]........................................................................................................... 80 Beneficios .................................................................................................................................................... 81 Características de un CMS........................................................................................................................... 81 Problemas observados en los CMS.............................................................................................................. 82 Estado actual del mercado de los CMS........................................................................................................ 83 ¿Cómo encontrar el CMS adecuado? [3,6,7,8] ............................................................................................ 84 El futuro de los CMS ................................................................................................................................... 85 Referencias................................................................................................................................................... 85

Self-Healing Systems.......................................................................................................87 Introducción ................................................................................................................................................. 87 Qué son los Self-Healing Systems? ............................................................................................................. 88 Consecuencias para la ingeniería de software? ............................................................................................ 89 Taxonomía de Temas................................................................................................................................... 90 Elementos del modelo del espacio de problemas......................................................................................... 90 La propuesta de IBM: Informática Autónoma ............................................................................................. 91 Propuesta desde la Biología ......................................................................................................................... 93 Otra propuesta: Homeostasis ....................................................................................................................... 94 Propuestas Self-Healing basadas en Arquitecturas ...................................................................................... 94 Casos prácticos de la industria IT ................................................................................................................ 96 Bibliografía ................................................................................................................................................ 106 Links de interés .......................................................................................................................................... 107



Introducción En este documento se presentan los trabajos entregados por los alumnos, como trabajo final de la materia dictada entre octubre y diciembre de 2004. Los trabajos están agrupados por su temática, cubriendo los distintos contenidos ofrecidos en la materia, haciendo hincapié en las citas y referencias que permiten profundizar cada uno de los temas.



eXtreme Programming Adrián Pablo Eidelman

[email protected]

¿Qué es XP? XP es una disciplina de desarrollo de software basada en ideas y prácticas simples y de sentido común que poseen varios años de utilización. El objetivo principal de XP es perderle el miedo al cambio y a través de esto permitir que el desarrollo se adapte constantemente a las necesidades de un negocio que cambia todo el tiempo. XP propone trabajar con una “mentalidad del desahogo” esto significa programar como si se tuviera todo el tiempo del mundo, tomándose el tiempo para escribir pruebas y cambiar el código en cuanto se sienta que se aprendió algo nuevo. Esto es un gran contraste respecto de la “mentalidad del esfuerzo continuo” en la que la mayoría de los desarrollos de software se encuentran hoy inmersos y que trae como resultado retrasos, malhumor, trabajo a desgano y rotación alta de personal.

¿Porqué surge XP? XP surge como una solución a los problemas de las metodologías de desarrollo de software tradicionales. Estas fallan generalmente en brindar al cliente el máximo beneficio que pueda obtener de su inversión. También fallan en un sentido social al quitar importancia al factor humano en pos de los procesos asumiendo una visión de la producción de software comparable a una línea de ensamblaje en la que cada obrero puede ser fácilmente reemplazado sin que se modifique de manera apreciable el funcionamiento general. XP surge también como una forma de mitigar los riesgos inherentes a cualquier desarrollo de software y la mayoría de los cuales no son correctamente encarados por las metodologías tradicionales. Entre estos riesgos encontramos: Llegar a la fecha de finalización del proyecto y enterarnos que el proyecto se retrasará otros seis meses A medida que pasa el tiempo, el costo de agregar nuevas modificaciones al programa se vuelve cada vez más grande La calidad del desarrollo es mucho menor a la esperada Una vez que el programa está listo, al cliente no le sirve porque el negocio cambió mucho desde el inicio del proyecto El sistema tiene muchas funcionalidades que agregan poco valor al negocio del cliente

Principios de XP Antes de poder definir un conjunto de prácticas específicas que permitan resolver o mitigar los riesgos, se debe definir un conjunto de principios que servirán de guía durante todo el desarrollo y permitirán juzgar y evaluar cada una de las prácticas que se quiera introducir. Estos principios también ayudarán a tomar decisiones de forma más rápida y precisa ya que sabiendo hacia donde se quiere ir es más fácil decidir qué camino se acerca o aleja del objetivo.

Realimentación rápida Para contar con una disciplina que se adapte constantemente a los cambios del negocio, es indispensable contar con una realimentación rápida. De esta forma, los programadores podrán aprender constantemente qué necesitan los usuarios y estos podrán entender qué es lo que los primeros pueden hacer por ellos.

Asumir la sencillez Rompiendo con la tradición impuesta por todas las metodologías que la preceden, XP propone resolver los problemas que se presentan de la manera más sencilla posible. En vez de planificar y diseñar para soportar los posibles cambios futuros, solo se debe resolver el problema puntual tal cual se presenta el momento. En el 95% de los casos esto será suficiente y los recursos que se ahorran son mucho más que los necesarios para resolver el 5% restante.



Cambio incremental Es muy raro que un cambio radical y profundo tenga los resultados esperados. Por eso XP propone subdividir un gran cambio en muchos cambios pequeños. De esta forma, es mucho más fácil controlar la aplicación de cada uno e incluso permite ir ajustando los cambios futuros de acuerdo a si los cambios ya implementados tuvieron o no los efectos deseados. Esta estrategia de cambio incremental no solo se aplica a la programación dentro de XP sino también al diseño y la planificación.

Aceptar el cambio Si se desea utilizar XP se debe estar completamente dispuesto a aceptar el cambio constante. Más adelante se verá como XP soporta el cambio constante sin que se introduzcan riesgos para la calidad y funcionamiento del sistema.

Trabajar con calidad La calidad no es una variable independiente que pueda ser ajustada a cualquier nivel. Esto es una verdad tanto para el negocio como para los programadores. El negocio no querrá un producto que no funcione correctamente y los programadores rápidamente se cansarán de trabajar en un proyecto de calidad dudosa.

Enseñar a aprender Mejor que dar pescado es enseñar a pescar. En esto se basa la filosofía de XP. XP no dice cuales son todas las pruebas que se deben implementar para cada funcionalidad. XP propone ciertos lineamientos y está en cada uno de los que deciden adoptarlos explorar y decidir hasta donde deben ser llevados a cabo.

Experimentos concretos Cada vez que se toma una decisión hay una posibilidad de que se este cometiendo un error. Por lo tanto es mejor realizar un pequeño experimento (prototipo, prueba de concepto, etc.) que permita reducir el riesgo y tener mayor confianza en que se va por el camino correcto.

Comunicación abierta y honesta Muchos proyectos son cancelados, se retrasan o sufren seriamente debido a que no se cuenta con una comunicación abierta y honesta. Muchas veces se teme comunicar malas noticias para no parecer el responsable. XP propone todo lo contrario. La única forma de llevar a buen puerto un proyecto es comunicándose constantemente, tanto las buenas como las malas noticias. De esta forma, aquellos que tengan la autoridad o capacidad podrán tomar las decisiones adecuadas cuando todavía hay tiempo de revertir el proceso.

Aceptar la responsabilidad Nada quita más la motivación a una persona o a un equipo que el hecho de que venga alguien a decirles qué es lo que tienen que hacer. En XP, se propone que cada uno tome la responsabilidad acerca de las tareas que va a realizar. Esto no quiere decir que siempre se haga lo que se desea. Si el equipo decide que hay tareas que se deben hacer, alguien tendrá que hacerlas.

Ir ligero de equipaje No se puede esperar llevar mucho equipaje y moverse rápido al mismo tiempo. Los miembros de un equipo XP deben estar preparados para moverse rápidamente en cuanto surja una nueva necesidad de negocio o una mejor solución de diseño. Por lo tanto solo deben llevar consigo aquello que aporta valor al cliente: las pruebas y el código.

Adaptación particular La disciplina propuesta por XP no se encuentra en ningún sentido “cerrada”. De hecho, es parte de la disciplina que cada uno la adapte a sus necesidades y posibilidades particulares. Es cierto que hay unas pocas prácticas que si o si deben ser aplicadas, pero incluso en estos casos se puede decidir cómo y cuándo aplicarlas.

Medidas justas Para poder conocer el estado de un proyecto es inevitable tener que llevar algún tipo de medición. Sin embargo, es de extrema importancia que las medidas utilizadas sean justas ya que podrían llegar a influir la forma de trabajar de cada miembro del equipo.



Prácticas de XP En base a los principios mencionados anteriormente, XP propone doce prácticas que deberían ser llevadas a cabo en todo desarrollo de software. Estas son: El juego de la planificación Versiones pequeñas Metáfora Diseño sencillo Hacer pruebas Recodificación (refactoring) Programación en parejas Propiedad colectiva del código Integración continua Semanas de 40 horas Cliente junto al equipo de desarrollo Estándares de codificación

El juego de la planificación El objetivo del juego de la planificación es determinar de forma rápida y claramente detallada cuál es el alcance de la siguiente versión. Para esto es necesario combinar las prioridades del negocio con las posibilidades y estimaciones técnicas. Las personas del negocio necesitan decidir sobre: el alcance (qué es lo que se necesita hacer para que el sistema genere el mayor valor posible al negocio o sea qué es lo imprescindible y qué lo deseable), las prioridades (qué se hace primero y qué después) y las fechas (para cuando necesita el negocio contar con cada funcionalidad). Por su parte, el personal de desarrollo deberá proveer de un contexto dentro del cual la gente de negocio pueda tomar sus decisiones. Son decisiones de ellos: las estimaciones (cuánto tiempo se tardará en desarrollar cada una de las características requeridas), las consecuencias tecnológicas (hay ciertas decisiones de negocio que requieren un cuidado análisis del posible impacto tecnológico que podrían acarrear en caso de llevarse a cabo), el proceso (cómo se organizará el trabajo y el equipo) y el orden del desarrollo dentro de una versión (a veces es tecnológicamente conveniente desarrollar primero una característica menos prioritaria).

Versiones pequeñas Cada versión debería ser tan pequeña como fuera posible conteniendo solo los requisitos de negocio más importantes. Sin embargo, no se puede perder de vista que cada versión tiene que tener un sentido por sí misma. No se puede implementar la mitad de una característica en una versión y la otra mitad en la siguiente. Cuanto más reducido sea el tiempo de cada versión, mayor será la retroalimentación obtenida y más posibilidades habrá de controlar el presupuesto, los tiempos y la aceptación por parte del cliente.

Metáfora La metáfora sirve de guía para cada proyecto. De ella se toman las palabras a utilizar para describir cada uno de los componentes del proyecto y sirve como un faro que mantiene la cohesión dentro del sistema como un todo.

Diseño sencillo “Pon lo que necesites solo cuando lo necesites”. Esta frase resume muy bien la idea del diseño sencillo en XP y se basa en dos creencias fundamentales: que el futuro es incierto y que será fácil cambiar las cosas en el futuro. XP provee una sencilla lista de pasos para evaluar si un diseño es realmente sencillo. Simplemente debe cumplir con estas cuatro reglas: Funciona con todas las pruebas No tiene lógica duplicada Manifiesta cada intención importante para los programadores Tiene el menor número posible de clases y métodos Un método sencillo para simplificar un diseño es simplemente eliminar cualquier elemento del mismo de forma tal que se sigan cumpliendo las tres primeras reglas.

Hacer pruebas Todas las características del programa deben tener una o más pruebas asociadas. Esto es indispensable para cualquier proyecto XP ya que es lo que permite que con el correr del tiempo el programa sea más modificable (y no menos como sucede en las metodologías tradicionales). Hay dos tipos básicos de pruebas, las de unidad y las funcionales. Las primeras las escriben los programadores y les permite ir incrementando su confianza en el



programa a la vez que pasan a formar parte del mismo. Lo mismo sucede con las pruebas funcionales y los clientes. No se debe malinterpretar esta práctica. La idea no es hacer una prueba para cada método de cada clase sino solo para aquellas funcionalidades importantes que pueden llegar a fallar.

Recodificación (Refactoring) La recodificación implica modificar código que está funcionando para mantener el diseño lo más sencillo posible. Cada vez que un programador debe añadir una nueva característica lo primero que hace es programarla de la manera más sencilla posible. Luego trata de ver la forma de hacer el diseño lo más simple posible y que sigan funcionando las pruebas. A veces, esto lleva más tiempo que el absolutamente necesario para hacer que algo funcione. Sin embargo, es esta pequeña inversión la que permite que sea sencillo de agregar el próximo cambio y el siguiente, etc. Son los pequeños cambios de la recodificación los que permiten hacer grandes cambios en el sistema con bajo riesgo.

Programación en parejas Todo el código del programa debe ser escrito por dos personas sentadas frente a una sola computadora con un teclado y un mouse. Cada uno de los programadores tiene un rol distinto. El que tiene en su poder el teclado y el mouse está ocupado en encontrar la mejor forma de implementar el método. Su pareja, tiene una visión más estratégica y debería pensar en: nuevos casos de prueba que hagan fallar el método, si la aproximación utilizada es la mejor y si hay alguna forma de simplificar el sistema de forma tal que el problema actual desaparezca. La parejas no deben ser fijas y pueden variar hasta dos o tres veces en un mismo día dependiendo de la disponibilidad y de las habilidades requeridas para cada tarea. Esta práctica da como resultado un código fuente de mucha mayor calidad que el que podría producir un programador trabajando por separado. Y contrariamente a lo que podría esperarse, no solo no genera una reducción en la producción de los programadores sino que la mantiene constante (con mayor calidad) o incluso la aumenta.

Propiedad colectiva del código Todos los miembros del equipo son propietarios y responsables de todo el código del sistema. Por lo tanto cualquiera puede hacer un cambio en cualquier lugar siempre y cuando las pruebas sigan andando. De esta forma, se evita el cuello de botella que genera el modelo más tradicional de propietario único del código en el cual se debe requerir al propietario que haga las modificaciones que uno necesita.

Integración continua Todas las parejas deben integrar su código con la última versión estable por lo menos una vez al día. Cada vez que se realiza la integración, los que la hacen deben asegurarse que todas las pruebas se ejecutan correctamente. En caso de no ser así esa pareja deberá corregir el código hasta que pase las pruebas y en caso de no poder, deberá retirar sus actualizaciones y volver a la versión anterior a la integración. Esta práctica asegura que la última versión del código no divergirá demasiado de la versión que cada desarrollador tiene y de esta forma se evitará largas jornadas de integración y aún más largas jornadas de corrección de errores de integración.

Semanas de 40 horas Nadie puede trabajar cómodo y a gusto si todas las semanas está 50 o 60 horas trabajando. Si se mantiene ese ritmo, al poco tiempo los desarrolladores se cansarán y empezarán a producir un código de muy mala calidad y al tiempo buscarán un nuevo lugar de trabajo. Es por esto que XP propone que las semanas no deben ser de más de 40 horas. Puede haber excepciones, pero si estas se prologan por más de una semana seguida entonces es un síntoma de que hay algo que no está andando bien y se deberá revisar lo que se está haciendo.

Cliente junto al equipo de desarrollo Es muy importante para XP que los programadores puedan estar en contacto permanente con el cliente. De esta manera, ellos podrán ir aprendiendo acerca del negocio y consultar todas las dudas que tengan y no tener que esperar días o semanas a que se produzca una reunión y recién ahí saber qué es lo que el cliente quiere. El cliente también puede proporcionar un feedback inmediato acerca del funcionamiento de las nuevas características.

Estándares de codificación Ya que los programadores estarán cambiando constantemente cualquier parte del código, es necesario tener ciertos estándares básicos que den una consistencia de estilo al código. El estándar debería exigir la menor cantidad de trabajo posible y ser consistente con la regla de no duplicar código. Es importante que todo el equipo acepte voluntariamente el estándar.



¿Es XP económicamente viable? Si nos basamos en la creencia tradicional que dice que el costo de hacer una modificación en un programa crece exponencialmente (Figura 1) a medida que se avanza en el desarrollo del mismo, claramente XP no es una disciplina de desarrollo de software viable.

Figura 1

Sin embargo, XP presenta una visión completamente distinta respecto de este punto. XP sostiene que si se aplican las prácticas descritas anteriormente, el costo del cambio no solo no crece exponencialmente sino que tiende a ser como lo muestra la Figura 2.

Figura 2

Por lo tanto, si el costo del cambio crece lentamente a medida que pasa el tiempo, se deberían aplazar las decisiones más importantes para mantener las opciones abiertas. Solo se debería implementar lo que se necesita hoy y no pensando en lo que se necesitará a futuro. Ya que seguramente el negocio cambiará, la inversión de hacer lo que creemos que será útil, seguramente no terminará siendo rentable. Para poder mantener la curva de costo según la Figura 2, XP se basa en dos herramientas claves. La primera es la programación orientada a objetos ya que esta al mantener unido el código con los datos sobre los que opera hace más fácil la introducción de nuevos cambios. La segunda es un subconjunto de las prácticas: el diseño simple y las pruebas automatizadas. El diseño simple mantiene el programa sencillo y solo con lo que se necesita en el momento, por lo tanto es más fácil de modificar y sin las pruebas automatizadas, realizar cualquier cambio sería introducir grandes riesgos sobre un código que ya funcionaba.

¿Cuándo usar XP ? XP puede ser usado para una infinidad de proyectos distintos tanto sean desarrollos nuevos como mantenimiento o modificación de programas existentes. Si el proyecto es nuevo, se pueden aplicar todas las prácticas desde el principio. Sin embargo, en los demás casos, cambiar completamente la forma de trabajo tal vez no sea lo más adecuado. En estos casos, es recomendable seguir este sencillo procedimiento : Identificar el peor problema que se tenga Resolverlo usando XP Cuando deje de ser el peor problema volver al paso 1 En general los problemas más acuciantes de casi cualquier proyecto son la baja calidad del código existente y el desequilibrio en la negociación entre los desarrolladores y el cliente. Por lo tanto en general se empieza aplicando las pruebas automatizadas y el juego de la planificación. Las pruebas se deberán ir generando solo para el código que es necesario modificar. De esta forma se mantiene el principio de hacer solo lo que se necesita hoy y dejar para mañana lo que se necesitará mañana.



¿Cuándo NO usar XP ? XP no es una disciplina que se adapte a todos los proyectos. Es importante antes de decidir aplicarla analizar si el tipo de proyecto que se va a encarar obtendrá beneficios de su uso. No existe una lista exhaustiva de proyectos o tipos de proyectos que no puedan o no deban ser llevados a cabo con XP, lo que si hay es algunos consejos obtenidos a partir de distintas experiencias acerca de qué funcionó y que no. La siguiente lista, muestra solo algunos rasgos que tenían algunos proyectos para los que XP no funcionó: Si la cultura de la empresa consiste en quedarse después de hora para “demostrar el compromiso con el proyecto” Si se va a necesitar más de una o dos docenas de programadores Si el tiempo en el que se obtiene un ejecutable para realizar las pruebas es de más de un día Si se necesita pasar por certificaciones de calidad que llevan varias semanas antes de poner el código en producción Si no se puede replicar (de manera satisfactoria) el entorno de producción de forma de realizar pruebas confiables Si se trata de hacer las cosas de una manera complicada para mantener la compatibilidad con aplicaciones legacy Si no se pueden reordenar los muebles de forma tal que dos programadores trabajen cómodos en una misma máquina De todas formas, todos los días hay nuevos proyectos que se encaran utilizando XP y que mueven la barrera entre lo que antes se consideraba posible y lo que no.

XP vs. metodologías tradicionales A continuación se presenta una lista con algunos puntos en los que las metodologías tradicionales difieren completamente con XP.

Documentación Las metodologías tradicionales ponen un gran énfasis en la documentación, tanto en la forma de manuales como en la de diagramas. A la larga, terminan pasando una de dos cosas, o la documentación empieza a desactualizarse hasta convertirse en inservible o el costo de estar constantemente actualizándola se vuelve un obstáculo en el avance del proyecto. XP ve a la documentación como una herramienta y no como un fin. Por lo tanto solo recomienda documentar cuando esta documentación provea un valor en sí mismo y descartarla en cuanto pase a ser un obstáculo.

Orientación del proceso Las metodologías tradicionales son orientadas al proceso. Esto significa que su objetivo es desarrollar un proceso en donde las personas involucradas sean fácilmente reemplazables. Lo que importa en el proceso son los roles y no las personas que los cumplen. XP es una metodología orientada a las personas ya que reconoce que la única forma de llevar adelante un proyecto exitoso es contando con gente capaz, motivada y que trabaja bien dentro del equipo. No es posible conseguir este tipo de recursos humanos si no se les da la importancia que merecen. Por eso XP trata a los participantes del desarrollo como partes esenciales del proyecto y no accidentales como las metodologías tradicionales.

Predicibilidad de los requerimientos Las metodologías tradicionales siguen un proceso predecible. Para que esto tenga sentido, asumen que se puede predecir en la etapa inicial del proyecto cuales van a ser todas las características esperadas del sistema. Una vez finalizada la etapa de relevamiento, estas metodologías tratan de poner la mayor cantidad de trabas posibles en los cambios de los requerimientos ya que estos implicarían grandes cambios en el plan. XP reconoce que en el mundo altamente competitivo de los negocios, es casi imposible predecir con un grado de acierto alto qué se va a necesitar del sistema dentro de dos o incluso un año. Por lo tanto propone un modelo de desarrollo iterativo en donde el cliente expresa sus necesidades más acuciantes y recibe periódicamente (cada una o tres semanas) versiones incrementales del sistema. De esta forma va teniendo contacto con el mismo y pudiéndolo utilizar mucho antes de que esté completamente finalizado. Así puede enterarse prematuramente si una característica fue interpretada correctamente y si en realidad era tan útil como lo imaginaba.



¿Qué significa un proyecto exitoso? Para las metodologías tradicionales, un proyecto exitoso es aquel que se está ejecutando según el plan en términos de tiempo y costos. Para XP un proyecto es exitoso si y solo si le brinda al cliente el mayor provecho posible. XP pone un gran énfasis en el valor que tiene para el cliente el sistema. Si el negocio cambia drásticamente una vez empezado el proyecto, el desarrollo debe ser capaz de ajustarse a ese cambio. No tiene ningún sentido continuar con un plan que llevará a un sistema inservible o que será poco usado.

Visión del cambio Las metodologías tradicionales ven al cambio como un problema que debe ser evitado a toda costa. Tratan de obtener por escrito con el mayor detalle posible todo lo que hará y lo que no hará el sistema antes de empezar. También los criterios de aceptación de cambios son pactados de antemano y puestos en el contrato. XP ve al cambio como una posibilidad. Una posibilidad de darle al cliente un producto más valioso que el que originalmente se había previsto. La gran mayoría de las prácticas de XP están diseñadas para hacer los cambios posibles.

Conclusiones Hoy en día, cada vez más proyectos deciden adoptar XP como guía del desarrollo. Esto se debe a que XP tiene como objetivo principal producir el mayor beneficio posible al cliente y al mismo tiempo tiene muy en cuenta las necesidades, fuerzas y debilidades de la gente de desarrollo. Además brinda al cliente una sensación de control e inmersión en el proyecto muy superior a la que hasta ahora habían experimentado con otros procesos. Hasta ahora pocas metodologías habían hecho tanto énfasis en la necesidad de comunicación, en las personas y en una relación tan fluida ente el cliente y los desarrolladores como propone XP. Es la visión del autor que cada vez más las pequeñas y medianas empresas que requieren y/o proveen desarrollo de software empezarán a adoptar XP y que no pasará mucho tiempo antes de que XP sea adaptado a otras ramas de la industria. El objetivo de este trabajo fue presentar XP describiendo los principios en los que se basa y las prácticas que de ellos se derivan. También se mostró cómo es que estas prácticas pueden ser económicamente sustentables a pesar de ir en contra de lo que tradicionalmente se creía correcto. Por último se brindó una breve reseña acerca de cuando si y cuando no usar XP junto con un resumen de las diferencias más significativas entre XP y sus antecesoras.

Bibliografía Kent Beck, Extreme Programming Explained Jonas Martinsson, Evaluation of Extreme Programming Pilot Project at Labs2 Martin Fowler, The New Methodology Martin Fowler, Refactoring: Doing Design After the Program Runs Martin Fowler, Variations on a Theme of XP Martin Fowler y Cara Taber, Planning and Running an XP Iteration Daniel Karlström, Introducing Extreme Programming – An Experience Report ��



Extreme Programming vs. CMM

Esteban Franqueiro

[email protected]

¿Qué es XP? Puede clasificarse como una de las metodologías ágiles, surgidas como reacción ante las metodologías ingenieriles y su burocracia. Atribuida a Kent Beck, Ron Jeffries y Ward Cunningham, XP está pensada para pequeños y medianos proyectos con requerimientos vagos y que cambian frecuentemente. Asumiendo que un alto costo del cambio de requerimientos es debido a las tecnologías en uso (patterns, information hiding, etc), XP trata que el proceso de desarrollo de software sea altamente dinámico. El equipo XP trata los cambios a través de un ciclo de vida iterativo de ciclos cortos. Las cuatros actividades básicas en el ciclo de vida de XP son coding, testing, listening y design. El dinamismo es demostrado por cuatro valores: comunicación continua con el cliente y dentro del equipo, simplicidad para enfocarse en la solución mínima, feedback rápido y constante a través del testing de unidad y funcional y el coraje para gestionar los problemas proactivamente.

Prácticas de XP XP se basa en alguna prácticas (llamadas Core Practices1). Las siguientes son algunas de ellas. Whole Team En cada proyecto XP existe un único equipo del que todos los participantes del proyecto son miembros. Este equipo incluye representantes del cliente, que proveen los requerimientos, fijan sus prioridades y le dan dirección al proyecto. Los programadores también son parte de este equipo, así como los testers, que ayudan al cliente a definir los tests de aceptación. También lo son los analistas que ayudan al cliente a definir requerimientos. Suele haber un coach que mantiene al equipo en camino y también puede haber un manager que se encarga de proveer los recursos, manejar la conversación con el exterior, coordinar actividades, etc. Ninguno de estos roles es propiedad de una única persona, cada miembro del equipo contribuye como puede. Los equipos no tienen especialistas, sino contribuyentes con habilidades especiales. Planning Game

El planeamiento en XP se ocupa de dos temas centrales: predecir que objetivos serán alcanzados en la fecha de entrega, y decidir cuál será el siguiente paso.

El énfasis está en darle dirección al proyecto, en vez de predecir exactamente qué se necesitará y cuánto llevará hacerlo. Hay dos pasos que se ocupan de estos temas: Release Planning Práctica en la que los clients presentan las características (features) deseadas y los programadores estiman su dificultad. Con esta estimación de costos y las prioridades de estas características, el cliente plantea un plan de trabajo. Los planes iniciales suelen no ser precisos (ni las prioridades ni las estimaciones son realmente sólidas) y hasta que el equipo no comience a trabajar no puede saberse qué tan rápido irán. Estos planes son revisados regularmente. Iteration Planning Es la práctica en la cual al equipo se le da dirección cada un par de semanas. Las iteración son cada dos semanas, y al final de cada iteración el equipo produce software útil. Durante este planeamiento, el cliente presenta las características requeridas en las próximas dos semanas. Los programadores las dividen en tareas y estiman su costo (a un nivel más fino que el obtenido en release planning).

��



Customer Tests Como parte del pedido de cada característica, los clientes deben definir tests automatizados de aceptación que muestren que la característica está funcionando.

El equipo debería tratar los tests de los cliente como cualquier otro test hecho por programadores: una vez que el sistema los pasa, los deberá pasar siempre. De esta forma el sistema siempre avanza. Small Releases

El equipo genera pequeños releases, produciendo en cada iteración software que corre, que fue testeado y que tiene valor para el cliente. El cliente puede usar este software como quiera, ya sea para evaluarlo o incluso para ser usado en producción (esto último es altamente recomendado).

Simple Design El equipo utiliza diseños simples para construir el software. Comienza simple, y mediante otras prácticas (programmer testing y design improvement) mantienen esta simplicidad. Se mantiene el diseño justo para la funcionalidad actual del sistema. En XP, el diseño no es algo que se haga una sola vez al principio, sino que es algo que se hace constantemente. A lo largo de todo el proyecto hay etapas de diseño (en el planeamiento de releases, de iteraciones, en sesiones de diseño y en revisiones de diseño mediante refactoring). Pair Programming

Todo el software es producido por grupos de dos programadores, sentados uno al lado del otro, en la misma computadora. Esta práctica garantiza que todo el código sea revisado por al menos otro programador, y resulta en un mejor diseño, testing y código. Además, esta práctica sirve para comunicar mejor el conocimiento en el equipo a medida que las parejas van cambiando.

Test-Driven Development El equipo primero crea los tests y luego el código que deberá pasar exitosamente dichos tests. Estos tests se mantienen todos juntos, con el código base, y cada vez que un par de programadores agrega código al repositorio, cada uno de los tests existentes debe correr sin errores.

Design Improvement XP se enfoca en producir, en cada iteración, algo que tenga valor comercial para el cliente. Para esto, el software debe estar bien diseñado. Para mejorar continuamente el diseño, XP usa el proceso de refactoring. Este proceso se basa en eliminar código duplicado, aumentar la cohesión y disminuir el acoplamiento. De esta forma, se comienza con un diseño simple y se lo mantiene. El uso de refactoring va acompañado de testing, de forma que lo que se modificó no rompa cosas que ya funcionaban bien. Continuous Integration Siempre se debe mantener el sistema completamente integrado, lo que implica múltiples builds por día. La falta de integración constante genera, al momento de hacer un build o release, que se encuentren todos los problemas de integración clásicos. Collective Code Ownership

El código le pretence al equipo, no a un programados o par de programadores en particular. Cualquier par puede mejorar cualquier código en cualquier momento. Esto significa que todo el código tiene la atención de todos, lo que aumenta su calidad y reduce defectos.

Esto tiene otras ventajas. Cuando el código tiene un dueño, ciertas características pueden ser implementadas en el lugar equivocado para no tener que esperar a que el dueño del código correcto la implemente. Coding Standards

Todo el equipo sigue las mismas reglas al escribir código. Esto ayuda a cumplir la práctica anterior. Metaphor El equipo consigue una visión común de cómo funciona el sistema (llamada metáfora). Esta puede ser una metáfora de verdad, o simplemente un sistema común de nombres para las cosas, de forma que todos entiendan como funciona el sistema, y dónde buscar la funcionalidad que requieren o agregar nuevas funcionalidades. Sustainable Pace

El equipo trabaja a un ritmo que pueda ser sostenido indefinidamente. Esto significa que trabajan sobre-tiempo cuando es efectivo, y que cuando los programadores están cansados, descansan.

XP vs. CMM Para analizar la compatibilidad de XP con CMM, debemos revisar si puede o no cumplir los KPA’s de CMM. En [4] podemos encontrar un análisis detallado sobre el tema. La siguiente tabla resume dicho informe:

Nivel de CMM KPA Satisfacción en XP2

�� !��"�� !��"��



Requirements Management ++ Software Project Planning ++ Software Project Tracking and Oversight ++ Software Subcontract Management -- Software Quality Assurance +

2

Software Configuration Management + Organization Process Focus + Organization Process Definition + Training Program -- Integrated Software Management -- Software Product Engineering ++ Inter-group Coordination ++

3

Peer Reviews ++ Quantitative Process Management -- 4 Software Quality Management -- Defect Prevention + Technology Change Management -- 5 Process Change Management --

�¿Qué tienen en común los KPA’s en los que XP falla? Los KPA’s en los que XP falla pueden dividirse principalmente en dos grupos. Los que involucran (sub-) contrataciones de terceros. Aquellos que tienen que ver con procesos a nivel organizacional más que grupal. En el primer grupo entra “Software Subcontract Management”. Esto se debe a que XP está pensado para grupos y proyectos pequeños o medianos, en los que no tiene sentido la contratación de terceros. Por este motivo, la pérdida de este KPA no es realmente importante para decidir si XP es o no compatible con CMM (en los casos en los que XP se aplica, claro). Los restantes KPA’s que XP no satisface caen en el segundo grupo, el de los que se refieren al concepto de institucionalización, o sea, a establecer la idea de “así es como hacemos las cosas acá”. Si bien está implícita en algunas prácticas, XP mayormente ignora la infraestructura que CMM identifica como clave para la institucionalización de buenas prácticas de ingeniería y management. Los KPA’s de CMM, en cambio, comparten características comunes que implementan e institucionalizan procesos. XP ignora algunas de estar prácticas, como las políticas organizacionales, mientras que otras (como entrenamiento y QA) las satisface indirectamente como consecuencia de sus propias prácticas. Finalmente existe otro grupo de prácticas de CMM que XP satisface parcialmente (por ejemplo las relacionadas con temas específicos de proyectos). En general XP se enfoca en el lado técnico del proceso de desarrollo, mientras que CMM se enfoca en temas administrativos. Es por esta razón que XP generalmente ignora los KPA’s relacionados con procesos. Por otro lado, el formalismo de CMM viene dado por las necesidades de proyectos grandes. A medida que los sistemas crecen, se vuelve cada vez más importante el concepto de arquitectura del sistema, y entonces algunas de las prácticas de XP se vuelven difíciles de mantener o implementar. En estos sistemas grandes, variantes del modelo bottom-up de XP (como por ejemplo el diseño basado en arquitectura) pueden ser más apropiados. Un último problema de XP es que los proyectos grandes tienden a ser multidisciplinarios, mientras que XP está dirigida específicamente al software.

Casos de estudio

XP en una empresa CMM Nivel 3 En cierta empresa, la administración decidió que todos los sistemas de la misma debían migrarse a aplicaciones web en 18 meses. El objetivo era reducir costos. Este requerimiento de 18 meses, chocaba contra los 5 años estimados basándose en experiencias y procesos anteriores. Los desarrolladores eligieron trabajar con XP con la esperanza de que esta metodología les permitiera cumplir la fecha impuesta. El equipo modificó algunas de las prácticas de XP para que tuvieran en cuenta el tamaño del proyecto. Esto afectó principalmente las prácticas

� ##��" �$��



relacionadas con el testing, ya que en lugar de primero crear los tests y luego escribir el código que los pase, se formaron equipos de testing independientes de los de desarrollo. Por otro lado, el equipo de QA se quejó ante la administración por la falta de documentación generada. El problema aquí fue que, en lugar de aplicar XP de forma racional dentro de los procesos de la empresa, se formaron bandos que comenzaron a culparse mutuamente. Al momento de escribirse el artículo original, el proyecto es encontraba detenido.

XP en un proyecto de investigación científica Este proyecto se llevó a cabo en el Langley Creativity & Innovations Office del Langley Research Center de la NASA. De los 9 entornos que Beck dice que no son apropiados para XP, 6 van en contra de la cultura existente en el laboratorio3. Según Beck, el principal obstáculo para el éxito de un proyecto XP es la insistencia de tener un diseño a priori, en lugar de ir diseñando el software mientras se lo desarrolla. Esto claramente contrasta con un ambiente como el de la NASA en donde los errores de software pueden ser trágicos. Al contrario que en el caso anterior, este proyecto concluyó de forma más que satisfactoria. Los autores del artículo cuentan que la nueva metodología de desarrollo casi duplicó su productividad comparada con proyectos previos. Este se debió a que si bien produjeron la misma cantidad de código de producción, además produjeron una cantidad similar de código de soporte (en forma de tests, tanto de unidad como de aceptación). También encontraron que el código resultó más conciso y claro (todo esto lo atribuyen a la aplicación sin misericordia del refactoring). Como consecuencia de esta prueba piloto, otros proyectos grandes de la NASA están adoptando XP.

XP en una “empresa RUP” La empresa se dedica al diseño y construcción de servicios de Internet basados en Java, y utilizando las herramientas de Rational. Todo esto bajo el control de RUP. El experimento duró dos años en el contexto de dos laboratorios. El primero completó dos proyectos. Para el primer proyecto aplicaron una versión simplificada de XP. El resultado no fue bueno, cumpliendo la regla 20/80 propuesta por Beck: si se sigue el 80% del proceso, se obtiene el 20% de los beneficios. El problema fue que el proyecto no tuvo control y coordinación. Para el siguiente proyecto siguieron las reglas al pie de la letra y consiguieron alcanzar los objetivos propuestos y algunos más. Actualmente la empresa no utiliza XP, pero aplica sus principios. La empresa ahora mezcla programadores con y sin experiencia XP. El artículo además cuenta las perspectivas de cada uno de ellos frente a la metodología. Este caso muestra la necesidad de no quedarse a mitad de camino en la aplicación del método, y confirma que quienes aplicaron XP en proyectos de escala acotada obtuvieron resultados satisfactorios.

Bibliografía IEEE Software, May/June 2003. www.xprogramming.com www.extremeprogramming.org Extreme Programming from a CMM Perspective. Paulk, M.; IEEE Software, November/December 2001.�

%�& �'�� (� �)��"*� �� "*� �(� �� "*� ��



Buenas Practicas Pablo Demidoff [email protected]

Introducción El objetivo de este trabajo es dar una introducción al tema de Buenas Practicas (Best Practices) y servir como guía para la búsqueda de información en la Web sobre las buenas practicas aplicadas a los temas vistos durante el seminario.

Motivación Buscando en la Web sobre como resolver el problema del “doble clic” en el desarrollo de aplicaciones Web (porque surgió el problema en el trabajo), me encontré con un montón de información sobre el tema de Buenas Practicas, y me di cuenta que hay sobre todos los temas que a uno se le puedan ocurrir y que sobre la mayoría yo no tenia ni idea. Así que me pareció bien escribir una especie de guía que explicara que son y dar puntos de referencia para buscar información sobre las buenas practicas de algunos temas vistos en clase.

Porque ? El desarrollo de software tiene una rica historia que proviene de mas de 40 años de practicas probadas y reales. Desde modelos de programación estructurada a métodos orientados a objetos, el desarrollador es generalmente librado a sus propios recursos para implementar código basado en un proceso de diseño altamente creativo y subjetivo. El acceso a la información sobre el desarrollo de software ya no es un reto. Puede ser, por otro lado, dificultoso asimilar todas las nuevas características, los numerosos recursos, las opciones de herramientas, etc. Cuando hay que escribir un programa o toda una aplicación, los desarrolladores tienen, una y otra vez, el deseo de obtener consejos.

Que Son ? El objetivo de las Buenas Practicas es proveer consejos rápidos, concretos y aplicables que nos asistan en la escritura de código legible, mantenible y eficiente. Las Buenas Practicas están diseñadas para rápidamente ponernos al tanto de aspectos útiles sobre el aspecto tecnológico que estamos analizando. Se puede decir que las Buenas Practicas son algo mas generales que los Patrones (Patterns) dado que estos últimos sirven para dar soluciones a problemas particulares, bien documentados. Las Buenas Practicas por otro lado, se pueden aplicar a cualquier faceta del desarrollo de aplicaciones, desde la escritura de código (formato, nombre variables) hasta que soluciones o técnicas utilizar en determinadas soluciones. Es mas, una Buena Practica, podría llegar a decir, es bueno usar el Patrón XXX para solucionar tal problema. También son conocidas como consejos (tips), técnicas probadas, guías, etc, etc. En el libro Oracle PL/SQL Best Practices (1), el autor intento clasificar los Best Practices por temas, y clasificarlo como si fueran patrones, utilizando los siguientes datos: • Título

Una sentencia que describa la buena practica y provea un identificador para la misma de la forma XXX-nn, donde XXX es el tipo de buena practica, ejemplo, EXC para Excepciones, y nn es el número secuencial dentro de este conjunto de buenas practicas.



• Descripción Una explicación mas larga para la buena practica. Es simplemente no posible cubrir todos los matices en una sola sentencia.

• Ejemplo Nosotros aprendemos mejor con ejemplos, con lo cual, se ilustran a través de código o anécdotas el valor de estas buenas practicas.

• Beneficios

¿ Porque deberíamos molestarnos con esta buena práctica ?. ¿ Cuan crucial es para uno seguir esta recomendación en particular ? . Esta sección ofrece una rápida reseña de los principales beneficios que obtendremos siguiendo esta buena practica.

• Desafíos

Esta sección nos previene sobre los desafíos o inconvenientes que podemos enfrentar al implementar esta buena practica.

• Recursos

En el mundo de la Internet, todo esta conectado, ¡ ningún programador esta solo !. Esta sección recomienda recursos, libros, páginas Web, etc.

Sobre que ? Dado que las Buenas Practicas son consejos, guias, y comentarios, se pueden aplicar a cualquier aspecto de la vida en general. Solo se necesita tener experiencia en algun rubro en particular y dictar los consejos que se crea necesarios. En el ambito del desarrollo de Software, se encuentra buenas practicas de Administración de Proyectos, Diseño de Sites, JSP, Servlets, Struts, EJB, J2EE, Oracle, Seguridad, Administracion de Application Servers (ej. Websphere), etc, et..

Desarrollo de Aplicaciones A continuacion, intentaremos agruparlos según la arquitectura de N-Capas vista en clase, y algunos otrs conceptos como seguridad, administración y metodologia.

Diseño de Sitios Estas guías sirven para definir como tiene que ser un sitio, desde su aspecto hasta como esta distribuida la información, que tipo de información se muestra, y las opciones de accesibilidad que se le brindan a los usuarios. Se utilizan para mantener un aspecto uniforme dentro de una organización u empresa muy grande, en la cual, hay mas de un grupo de desarrollo trabajando sobre el sitio corporativo o institucional. Por ejemplo, el artículo NASA WWW Best Practices (2) dice: “Las Buenas Practicas bosquejadas en este documento sirven como pauta para todas las entidades de la NASA dedicadas al desarrollo y mantenimiento de recursos WWW. Estas pautas facilitan un despliegue consistente, fiable y eficiente de los servicios WWW a través de la agencia. Estos criterios deben ser vistos como recomendaciones base. Estas buenas prácticas continuarán siendo revisadas por la comunidad NASA WWW.”

Desarrollo de Sistemas Estas guías sirven para el desarrollo de software. Son tanto lineamientos sobre como elegir el proceso de desarrollo a utilizar, como obtener los requerimientos, como armar la arquitectura, como elegir el modelo de testeo, etc. Son pautas para cada una de las etapas en el desarrollo de aplicaciones. Por ejemplo, el artículo Best Practices for Software Development Projects (3) dice: “La mayoría de los proyectos de software fracasan. De hecho, el grupo Standish reporta que más del 80% de los proyectos son fallidos porque son sobre presupuestados, tardíos, falta funcionalidad o una combinación de los mismos. Además, 30% de los proyectos de software son tan pobremente ejecutados que hacen que sean



cancelados antes de finalizar. En nuestra experiencia, los proyectos de software usando tecnologías modernas como Java, J2EE, XML y Web Services no son excepciones a esta regla.” Por otro lado, en el libro Designing Enterprise Applications with the J2EE Platform, Second Edition (4) (5), se explican reglas de arquitecturas para aplicar con la tecnología J2EE. En el articulo, Software Development: Best Practices for Developing Enterprise Applications (6), habla sobre 7 practicas que van mas allá de la fase, arquitectura o tipo de proyecto. Estas son (en ingles) Orthogonal, DRY, Model-View, Meta-programming, Automatic, Test First y Refactoring. En el artículo, Capturing and Formalizing Best Practices in a Software Development Organization (7), el autor dice: “El número de recursos que los desarrolladores de software moderno deben utilizar para crear aplicaciones es simplemente increíble. Modelos de procesos, métodos de desarrollo, tecnologías, y herramientas de desarrollo apenas arañan la superficie del arsenal contenido en el kit de herramientas del diseñador de software. Pero la comunidad de ingeniería de software ha por la mayor parte ignorado el conocimiento adquirido y la esencia de la maestría en herramientas, optando en cambio por amontonar nuevos métodos, lenguajes, herramientas y métodos formales sobre la pila de conocimientos. Poco soporte es dado para el entendimiento de cuando las diferentes metodologías deben ser usadas y como ellas deben ser aplicadas al esfuerzo de desarrollo con conjuntos específicos de requerimientos. Este paper presenta una infraestructura que soporta conocimiento evolutivo por técnicas basadas en casos que ayudan a las organizaciones de desarrollo de software a pasar de la metodología tradicional de desarrollo (Standard Development Methodology) a un medio dinámico que capture buenas practicas y las convierta en organizaciones basadas en la información.” En el artículo Reference Architecture: The Best of Best Practices (8), el autor dice: “¿ Porque un proyecto dentro de una organización florece mientras un proyecto dentro con las mismas necesidades fundamentales arquitectónicas, dentro de la misma organización, lucha por mantenerse a flote ?. A menudo, la raíz del problema es la falta de comunicación horizontal a través de todos los proyectos en lo concerniente a elecciones arquitectónicas, tanto para buenas como malas, que fueron realizadas en proyectos pasados. RUP dice que tal “recolección” de buenas practicas dentro de la organización es el primer paso hacia la construcción de una arquitectura de referencia versátil y fuerte. Brevemente, una arquitectura de referencia consiste en información accesible para todos los miembros del equipo del proyecto que provee un conjunto consistente de buenas practicas arquitectónicas. Estas pueden ser plasmadas en muchas formas: artefactos arquitectónicos previos, estándares de la compania, patrones de diseño, frameworks comerciales, etc.”

Capa Presentación Estas Buenas Practicas sirven para como mejorar el desarrollo de la capa de presentación, o sea, como se muestran los datos al usuario. Incluyen a todas las tecnologías que se ocupan de este rubro, como ser HTML, JSP, Servlets, Struts, etc. El sitio de IBM developerWorks contiene toda una sección de JSP Best Practices (9), donde se van publicando artículos periódicamente sobre este tema. �En el artículo, Solving the logout problem properly and elegantly (10), el autor dice: “El manejo correcto del proceso de logout en una aplicación Web protegida por password requiere mas que una llamada al método invalidate() del objeto HttpSession porque la mayoría de los navegadores modernos, con los botones de Adelante y Atrás, permiten a los usuarios avanzar y retroceder en una pagina. Si el botón Atrás causa que el navegador muestre paginas viejas desde sus caches después del proceso de logout, los usuarios de estas aplicaciones inadecuadamente desarrolladas pueden volverse confundidos, perdidos, y preguntarse que ha o pudo haber pasado con sus datos personales. Muchas aplicaciones Web agregan una pagina intimidando a los usuarios a cerrar sus navegadores completamente, esto, de hecho, previniéndolos de hace click en el botón atrás. Otros, usan JavaScript el cual no siempre esta activo en el navegador del cliente. La mayoría de estas soluciones son torpemente implementadas, fallan en funcionar el 100 % de las veces bajo todas las circunstancias, o requieren mucho entrenamiento de los usuarios. Este articulo presenta soluciones para manejar apropiadamente el problema del logout con programas de ejemplo. El autor Kevin Le empieza describiendo una aplicación Web protegida por password ideal. El luego usa programas ejemplo para ilustrar como los problemas se manifiestan y discute soluciones requeridas para solucionar dichos problemas. Centrando la discusión en JSP, el articulo presenta los conceptos que pueden ser



fácilmente entendidos y adoptados para otras tecnologías Web. Le concluye esta discusión mostrando como construir aplicaciones Web con Jakarta Struts puede resolver el problemas mas elegantemente. Programas ejemplo para JSP y Struts están incluidas.” En el sitio developers.sun.com hay un articulo, Servlets and JSP Pages Best Practices (11), que presenta varias Buenas Practicas sobre Servlets y JSP. Al principio, el autor comenta: “Las buenas practicas son enfoques probados para desarrollar aplicaciones Web basadas en servlet y JSP que son de calidad, re-usables y fácilmente mantenibles. Por ejemplo, código embebido Java (scriptlets) en secciones de documentos HTML pueden resultar en aplicaciones complejas que no son eficientes, dificultosas de re-usar, extender y mantener. Las buenas practicas pueden cambiar todo esto.” En el artículo, Struts best practices. Build the best performing large applications (12), el autor dice: “Muchas opciones están disponibles para resolver problemas con Struts. Cuando decidimos entre estas alternativas, la elección debe estar basada en parámetros como la escala del trabajo y la disponibilidad de tiempo. Sin embargo para aplicaciones grandes y con necesidad de buena calidad de servicio, cada decisión se transforma en crucial y esfuerzos extras son requeridos para elegir la solución apropiada. Para ayudarlo con estas decisiones, Puneet Agarwal discute algunas de las buenas practicas para desarrollar aplicaciones basadas en Struts.” En el artículo Best practices for Struts development. Optimize the Struts framework in your Web application development (13), dice: “Mejore el desarrollo de aplicaciones Web usando el flexible framework Struts. Aca, los autores exploran buenas practicas que vos podes seguir para optimizar este framework open source y maduro. Aprenda a usar componentes Struts valiosos y estándares, incluyendo ActionForm, la clase Action y ActionErrors.”

Capa Lógica Aplicación �Estas Buenas Practicas están pensadas para lo que se refiere a modelar la capa de negocios o la lógica de la aplicación. En este trabajo nos concentraremos en los EJB. �En el articulo Ease of Development in Enterprise JavaBeans Technology (14), se explica un poco cuales son los nuevos features de la versión 3.0 de EJB y porque simplifica su uso, dado que la gente es reticente a utilizar dicha tecnología por se un tanto complicada. El sitio de IBM developerWorks contiene toda una sección de EJB Best Practices (15), donde se van publicando artículos periódicamente sobre este tema (casualmente es el mismo autor de los JSP Best Practices). En el artículo, Best practices in EJB exception handling (16), se habla sobre como manejar correctamente el tema de excepciones en EJB.

Capa Administración de Datos �Estas Buenas Practicas están pensadas a la programación del código en la base de datos, y a como optimizar el acceso a los datos, por ejemplo, con el uso de JDBC. En el artículo Scalability and Performance: JDBC Best Practices and Pitfalls (17), se mencionan varias pautas, en varias capas de la arquitectura, siendo: DBMS configuration parameters Physical database design SQL statements and query execution plans JDBC driver setup/configuration JDBC usage from within Java application code JDBC driver selection Application architecture general design issues Esta es una breve descripción de los capitulos del libro Oracle PL/SQL Best Practices (1): Capitulo 1: Comienza con recomendaciones especificas de programación. Ofrece consejos sobre como mejorar todo el proceso por el cual usted escribe código



Capitulo 2: Ofrece una serie de sugerencias sobre como formatear y organizar su código, para que este sea mas legible y, por consiguiente, mas mantenible. Capitulo 3: Toma una vista cercana a como usted debería declarar y manejar datos dentro de programas PL/SQL. Capitulo 4: Es un capitulo “Regreso a los básico” que habla sobre la mejor manera de escribir sentencias IF, ciclos, y hasta la sentencia GOTO. Seguro, estas no son construcciones terriblemente complicadas, pero hay aun correctas e incorrectas formas de trabajar con ellas. Capitulo 5: Cubre otro aspecto critico del desarrollo robusto de aplicaciones: el manejo de excepciones, o que hacer cuando las cosas salen mal. Capitulo 6: Se enfoca en el aspecto más crucial del desarrollo en PL/SQL: como debería escribir las sentencias SQL en sus programas. Capitulo 7: Ofrece consejo sobre la mejor forma de construir procedimientos, funciones y otras unidades de programa que contienen la lógica del negocio. Además incluye buenas practicas para la construcción de parámetros. Capitulo 8: Presenta recomendaciones sobre paquetes, los bloques de construcción de cualquier aplicación basada en PL/SQL bien diseñada. Capitulo 9: Hace foco en como tomar la mejor ventaja de unos pocos de los mas usados paquetes provistos por Oracle Corporation.

Seguridad �Estas Buenas Practicas están relacionadas con el tema de la seguridad en las aplicaciones. Tanto sobre como se piensa (o no) en las mismas, como sobre las tecnologías que existen para evitar las fallas de seguridad en nuestros sistemas. En el artículo Abstracting Application-Level Web Security (18), los autores dicen: “Seguridad Web a nivel aplicación se refiere a vulnerabilidades inherentes en el código de la aplicación en si misma (independientemente de la tecnología en la cual esta implementada o la seguridad del servidor Web y de base de datos sobre la cual esta construido). En los últimos meses vulnerabilidades a nivel aplicación han sido explotadas con serias consecuencias: hackers han trampeado sitios de e-commerce, usuarios y claves han sido cosechados e información confidencial (como direcciones y números de tarjetas de crédito) ha sido violada. En este paper investigamos nuevas herramientas y técnicas que tratan el problema de seguridad a nivel aplicación Web. (i) Describimos un mecanismo de construcción escalable que facilita la abstracción de políticas de seguridad para grandes aplicaciones Web desarrolladas en entornos multiplataforma heterogéneos; (ii) presentamos una herramienta que asiste a los programadores a desarrollar aplicaciones seguras las cuales son fuertes contra una amplia gama de ataques comunes; y (iii) reportamos resultados y experiencias surgidos por nuestra implementación de estas técnicas.” �En el artículo Best Practices for Secure Web Development (19), el autor explica algunos términos básicos del tema y presenta 18 Best Practices, en el siguiente orden: • Seguridad como parte de la idea del negocio. • Seguridad como parte de la recolección de requerimientos. • Seguridad como parte de la arquitectura. • No ser anónimo cuando no queres terminar siéndolo. • No usar cuentas administrativas a menos que sea necesario. • No usar GET para enviar datos delicados. • No confiar en que los clientes (navegadores) mantienen datos importantes entre requerimientos. • No almacenar datos delicados en las mismas paginas ASP o JSP. • Tener cuidado con los comentarios HTML dejados en códigos de produccion. • Cross-site scripting • Chequear el código de ejemplo o generado por wizards. • Middleware security • Declarative vs programmatic • PKI no es una bala de plata.



• Snake oil • La revisión de código es tu amigo. • Mira que usas. • Para resolución de problemas usa los logs. �

Administración de Aplicaciones. Estas Buenas Practicas están relacionadas con la administración de los productos que nos permiten soportar aplicaciones Web, como por ejemplo, los Application Servers. Acá se dan pautas de cómo hacer una correcta instalación y setup, y como ir monitoreando su correcto funcionamiento. En el sitio WebSphere Best Practices Zone: Background Information (20) se da una introducción a la terminología y un punto de acceso hacia los Best Practices. En el artículo Best Practice: Not creating HttpSessions in JSPs by default (21) dice: “No crear HttpSessions en JSPs por defecto. Los JSPs crean HttpSession por defecto. Si no necesitas un HttpSession, podes mejorar la performance simplemente con una linea de directiva JSP. Mediciones de laboratorio mostraron un 5% de mejora en la performance cuando el valor por defecto no es usado.” En el artículo Best Practice: Classpath structure for WebSphere Application Server (22) comenta como es la estructura de classpath del WebSphere, y explica en donde deben ir las clases según la frecuencia con que las mismas son modificadas. En el artículo WebSphere Application Server v4.x. Best Practices using HTTP Sessions (23) dice: “Este white paper contiene consejos y técnicas para ayudar a los desarrolladores a programar mas eficientemente y a los administradores a afinar mejor un servidor de aplicaciones WebSphere de IBM version 4.x. Este documento primero toma un breve ojeada a las opciones disponibles en WebSphere para configurar como las sesiones son manejadas. La segunda sección discute cuando usar cada opción para ayudar al administrador de sistema o desarrollador a identificar cuando y donde una opción es valiosa para usar. Finalmente, buenas practicas de desarrollo de aplicaciones para servlets y JSP, especialmente enfocándose en sesiones HTTP y persistencia con sesiones.” En el artículo Enterprise Java Performance: Best Practices (24), dice: “Este articulo discute buenas practicas para maximizar la performance de volumen de trabajo de Java Enterprise. Primero, introducimos la importancia de la performance en aplicaciones Enterprise Java. Luego describimos nuestros enfoques top-down, data-drive y closed-loop para caracterizar donde los problemas están. Examinamos la performance del software/hardware stack, primero desde una perspectiva a nivel sistema (topología, I/O, red), luego desde la ultima capa de software (nivel aplicación), por la capa media (Java Virtual Machine) y bajamos a la capa de plataforma (procesador, memoria). Concluimos resumiendo nuestras recomendaciones para alcanzar la mejor performance en aplicaciones Enterprise Java.”

Integración de Aplicaciones Empresariales. En esta sección, veremos buenas practicas para la integración de aplicaciones empresariales (EAI – Enterprise Application Integration). Acá se verán guías de cómo hacer para integrar aplicaciones distintas que existen dentro de una empresa, para hacerlas ver que funcionan como una única unidad. Una de las reglas que mas se manejan en la integración de aplicaciones, es desacoplar lo mas posible cada parte de la arquitectura (donde parte puede ser un sistema o componente) para que sea fácil su cambio en un futuro, y que el impacto sea el menor posible. También se menciona a SOA (Service Oriented Arquitecture) como una buena practica porque no esta ligada a una plataforma tecnológica particular. En el sitio Enterprise Integration Patterns (25) se explican los conceptos, las tecnologías involucradas, algunos patrones y buenas practicas. En el articulo Best Practices for Successful EAI (26) el autor explica algunos buenas practicas de EAI. Estas son: Best Practice #1: Building with Deployment in Mind Best Practice #2: Profile Performance Early and Often Best Practice #3: Build a Traceable System Best Practice #4: Reviewing and Addressing Secondary Scenarios



Cosas curiosas si las hay, es que encontré otro articulo en CodeGuru (27) que explica los mismo que el anterior, pero escrito por otros autores. Que coincidencia, no ?, o será que no hay muchas buenas practicas ?. Otro articulo interesante es EIA for CIOs: A Pragmatic Approach (28) en el que se da una visión mas general del tema, y esta enfocada para que la gerencia de las empresas entienda la importancia de la integración de aplicaciones. Y por ultimo, como existen varios productos que dicen solucionar estos problemas, como ser: Symphony (29), TouchPoint (30) y Fiorano (31).

Conclusiones. Como se vio, existe mucho material en Internet, y mucho depende de la experiencia personal, y del conocimiento de los conceptos básicos inherentes a cada tema, tecnología, etc., etc. Espero que esto sirva de punto de partida para poder seguir buscando mas material y para que se tenga una noción de sobre que temas se pueden encontrar consejos útiles y buenas practicas.

Referencias. 1. Oracle PL/SQL Best Practices. Autor: Steven Feuerstein. Editorial: O'Reilly ISBN: 0-596-00121-5 2. NASA WWW Best Practices. Sitio: http://nasa-wbp.larc.nasa.gov/ 3. Best Practices for Software Development Projects. Autor: Mike Perks. Sitio: http://www-106.ibm.com/developerworks/websphere/library/techarticles/0306_perks/perks2.html 4. Designing Enterprise Applications with the J2EE Platform, Second Edition. Autores: Inderjeet Singh, Beth Stearns, Mark Johnson, and the Enterprise Team. Editorial: Addison-Wesley ISBN: 0-201-78790-3 Sitio: http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/ 5. Java BluePrints program. Sitio: http://java.sun.com/blueprints/ 6. Software Development: Best Practices for Developing Enterprise Applications. Autores: Greg Barnes Nelson y Danny Grasse. Sitio: http://support.sas.com/sassamples/papers/enterpriseapps_03jan.pdf 7. Capturing and Formalizing Best Practices in a Software Development Organization Autor: Scott Henninger. Sitio: http://www.cse.unl.edu/~scotth/papers/Henninger_SEKE97.pdf 8. Reference Architecture: The Best of Best Practices Autor: Paul R. Reed, Jr. Sitio: http://www.therationaledge.com/content/sep_02/m_bestPractices_pr.jsp 9. IBM DeveloperWork. JSP Best Practices. Autor: Brett McLaughlin. Sitio: http://www-128.ibm.com/developerworks/java/library/j-jspcol.html 10. Solving the logout problem properly and elegantly Autor: Kevin H. Le. Sitio: http://www.javaworld.com/javaworld/jw-09-2004/jw-0927-logout_p.html



11. Servlets and JSP Pages Best Practices Autor: Qusay H. Mahmoud Sitio: http://www.javaworld.com/javaworld/jw-09-2004/jw-0927-logout_p.html 12. Struts best practices. Build the best performing large applications. Autor: Puneet Agarwal Sitio: http://www.javaworld.com/javaworld/jw-09-2004/jw-0913-struts_p.html 13. Best practices for Struts development. Optimize the Struts framework in your Web application development Autores: Palaniyappan Thiagarajan y Pagadala J Suresh. Sitio: http://www-106.ibm.com/developerworks/library/wa-struts/ 14. Ease of Development in Enterprise JavaBeans Technology Autor: Ed Ort. Sitio: http://java.sun.com/developer/technicalArticles/ebeans/ejbease/ 15. IBM DeveloperWork. EJB Best Practices. Autor: Brett McLaughlin. Sitio: http://www-128.ibm.com/developerworks/java/library/j-ejbcol.html 16. Best practices in EJB exception handling Autor: Srikanth Shenoy. Sitio: http://www-106.ibm.com/developerworks/library/j-ejbexcept.html 17. Scalability and Performance: JDBC Best Practices and Pitfalls Autores: Julia Gutjahr and Andreas Loew. Sitio: http://www.netobjectdays.org/pdf/02/papers/ws-jada/1149.pdf 18. Abstracting Application-Level Web Security Autores: David Scott y Richard Sharp. Sitio: http://www-lce.eng.cam.ac.uk/~djs55/swap/abstracting.pdf 19. Best Practices for Secure Web Development Autor: Razvan Peteanu. Sitio: http://members.rogers.com/razvan.peteanu/best_prac_for_sec_dev4.pdf 20. WebSphere Best Practices Zone: Background Information Sitio: http://www-128.ibm.com/developerworks/websphere/zones/bp/background.html 21. Best Practice: Not creating HttpSessions in JSPs by default Autor: Harvey W. Gunther Sitio: http://www-106.ibm.com/developerworks/websphere/library/bestpractices/not_creating_httpsessions_in_jsps.html 22. Best Practice: Classpath structure for WebSphere Application Server Autor: WebSphere Best Practices Team. Sitio: <lo tengo que buscar nuevamente>. 23. WebSphere Application Server v4.x. Best Practices using HTTP Sessions Autor: David Draeger. Sitio: <lo tengo que buscar nuevamente>. 24. Enterprise Java Performance: Best Practices Revista: Intel Technology Journal, Volume 07, Issue 01. Autores: Kingsum Chow, Ricardo Morin y Kumar Shiv. Sitio: http://developer.intel.com/technology/itj/index.htm 25. Enterprise Integration Patterns Sitio: http://www.eaipatterns.com/ 26. Best Practices for Successful EAI Autor: Andre Yee. Sitio: http://www.ebizq.net/topics/eai/features/1712.html



27. CodeGuru - Best Practices for Successful EAI Autor: Syed Hameed. Sitio: http://www.codeguru.com/Csharp/.NET/net_asp/miscellaneous/print.php/c6777/ 28. EIA for CIOs: A Pragmatic Approach. Autor: Sunil Senan Sitio: http://www.infy.com/services/packaged_applications/setlabs_briefings_vol1_no2-eaiforcios.pdf 29. Symphony Sitio: http://www.objectconsulting.com.au/downloads/Symphonyfactsheet.pdf 30. TouchPoint Sitio: http://www.touchpointsi.com/TouchPointBPO.pdf Sitio: http://www.touchpointsi.com/TouchPointCIS.pdf 31. Fiorano Sitio: http://www.fiorano.com/devzone/why_integration.htm



EAI: Un Vistazo General

Leonardo Brambilla [email protected]

�

Resumen El presente trabajo es una modesta revisión del “estado del arte” de la tecnología EAI. Comienza con un intento de definir EAI, remarcando lo difícil que puede ser acordar sobre la misma. Se comentan otras tecnologías que atacan problemas parecidos y lo confuso que se puede ser a la hora de nombrar técnicas. Luego se nombran los principales proveedores y sus productos actuales; las prácticas actuales para combinar soluciones y los estándares mas populares. Revisamos los objetivos de EAI y su evolución. La aceptación de los Web Services y XML; y la sigla del momento SOA. Finalmente se comentan algunos pronósticos y los próximos pasos.

Qué es EAI? Los negocios y la tecnología han estado integrando aplicaciones desde el inicio de los tiempos, o al menos, desde que creamos nuestras dos primeras aplicaciones. Uno de los mayores obstáculos que encuentran aquellos que quieren entender la tecnología EAI, es que la definición del acrónimo EAI siempre ha estado cambiando. Con la expansión de las economías globales, la evolución de la tecnología y el marketing de los vendedores tratando de establecer sus ventajas y posición en el mercado, hay una confusión general sobre el significado de la integración empresarial de aplicaciones. Dos preguntas comunes e importantes se presentan hoy: Como definir EAI? y Cómo puede beneficiar el negocio? Definir EAI y no morir en el intento: simplemente nos referimos a la integración de aplicaciones al nivel empresarial. “Proceso de integrar múltiples aplicaciones, que fueron desarrolladas de manera independiente, que podrían usar tecnologías incompatibles, y continúen siendo administradas por separado”. EAI no es una tecnología por sí misma, sino una colección de herramientas, técnicas y tecnología que permiten a la aplicaciones ínter-operar de manera efectiva. Para tener una definición completa de EAI, debemos echar un vistazo a la evolución de la industria tecnológica. Actualmente es común referirse a EAI como “Integración de Negocios”. Si bien distintas personas tienen diferentes ideas sobre lo que significa integración de negocios, el punto básico es que la integración de negocios facilita el aumento de la eficiencia y la efectividad de los procesos que manejan el negocio. Esto comprende mejorar la calidad y la disponibilidad de la información, y proveer información sobre demanda y donde sea necesaria, independientemente de la tecnología. Ahora comprendemos que los negocios están marcando el rumbo de la tecnología, y EAI es una suite de soluciones que soportan el negocio. En la economía actual hay una gran demanda de servicios y soluciones provistos por EAI.

Muchos nombres, la misma intención En el vertiginoso mundo de la informática de negocios y servicios parece no haber límites a la hora de ponerle nombres a las técnicas y herramientas. En lugar de trabajar sobre estándares y mejorar las soluciones actuales, los proveedores dedican sus esfuerzos en encontrar algo que diferencie su producto del resto para ponerle otro nombre. Parece ser más una carrera armamentista que una búsqueda de soluciones. Por esto nos encontramos con decenas de nombres y acrónimos a la hora de buscar en el mercado una solución que se ajuste a nuestros problemas. Si bien es cierto que los problemas de sistemas que existen en las compañías son muy variados y amplios, el estado tan segmentado del mercado informático no aporta claridad sobre la cuestión. Haciendo un pequeño relevamiento del estado del arte, nos encontramos con nombres como los siguientes:



EII (Enterprise Information Integration): dicen que integran “a nivel de información”. Logrando una visión unificada de la información empresarial almacenada en distintas fuentes, y de manera sobre demanda. Problemas que desde hace años ataca el Data Warehousing y para el cual se conoce su alta complejidad. No es tan sencillo como suena, pero alguien quiere vendernos un producto. EIP (Enterprise Information Portals): tome sus herramientas de Business Intelligence y Data warehousing, permita que se acceda a su información desde Internet y ya tiene su EIP. EAP (Enterprise Application Portals): permiten el acceso a las aplicaciones de la empresa de manera unificada. Generan una integración a nivel de presentación. El fin es muy parecido al de EAI con la diferencia de que pretenden que parezca mas sencillo. En realidad es una solución mas limitada que EAI ya que no podemos tener tanto control sobre la lógica de negocio. Web Services: hay varios papers y artículos dando vueltas sobre si Web Services es el siguiente paso de EAI, si va a terminar con EAI, o si es una parte de EAI. La realidad parece indicar que Web Services es el medio ideal para la integración de aplicaciones, negocios e información, pero sólo en parte. Aún hay muchos problemas para integrar aplicaciones viejas o propietarias. Si es cierto que hoy en día Web Services cuenta con la ventaja de la estandarización de protocolos y el soporte de las nuevas aplicaciones, por lo tanto se sabe que logrará disminuir la necesidad de EAI, pero no llegará a reemplazarla.

Actualidad La confusión y poca claridad a la hora de definir las técnicas y arquitecturas usadas también se hace presente cuando tenemos que ver los productos disponibles en el mercado. Para hacernos una idea podemos poner como ejemplo a IBM, cuya suite de soluciones EAI está compuesta por más de diez productos distintos. TIBCO también hace su aporte a esta tortuosa odisea de armar la solución con doce productos. Tenemos desde message brokers y adaptadores, pasando por administradores de transacciones, manejadores de colas, hasta portales Web y conectores legacy. Los productos más populares de EAI son: Websphere MQ Series (IBM); Bea Weblogic (BEA Systems); BizTalk (Microsoft); TIBCO; MERCATOR; Fabric (WebMethods); ORACLE. El éxito de los proyectos actuales de EAI depende de la acertada selección de herramientas y la capacidad para conectarlas y administrarlas. Si bien varios proveedores apuntan a brindar suites “completas” y aconsejan que sólo se integre con sus productos, los arquitectos apuntan a una combinación de soluciones. Esto les permite obtener el mejor rendimiento en cada uno de los componentes. Lamentablemente en algunos casos esto se ve perjudicado por las limitaciones impuestas por los fabricantes a sus productos, por ejemplo en el caso de Microsoft, cuyas soluciones sólo funcionan en entornos Windows. Entre los estándares mas populares están los siguientes: J2EE, EJB, CORBA, XML, SOAP, WSDL, UDDI, XBRL, SSL, COM+/DCOM, EDI, JavaRMI, RosettaNet. En el siguiente cuadro se puede ver como ha cambiado el enfoque de EAI en los últimos años. Drivers EAI hace 5 años Drivers EAI hoy

Permitir a las empresas manejar sus negocios por Internet mediante la interconexión de sus sistemas y aplicaciones.

Agilizar y modernizar procesos de negocios Internamente y a través de toda la cadena de negocio Mejorar la eficiencia, reducir el riesgo, y aumentar los niveles de producción

Manejar de manera conveniente sus aplicaciones y sistemas ante cambios como adquisiciones, fusiones, desregulaciones de mercados, etc.

Tomar EAI como una infraestructura tecnológica necesaria para el futuro de los proyectos informáticos de la compañía

Automatizar la ejecución de aplicaciones en un complejo proceso de negocios

Maximizar el Retorno de la Inversión hecha en los años anteriores.

Mejorar los niveles de producción Introducir rápidamente las nuevas ofertas en el mercado



En el cuadro de evolución se puede ver como las empresas van agregando valor e importancia a sus proyectos a medida que pasan los años. Actualmente la curva del gráfico se mantiene pero en un período más corto de tiempo. La intención actual es que se pueda pasar de las primeras implementaciones a un buen Manejo de Procesos de Negocios (BPM) en mucho menos tiempo.

Web Services y XML La aceptación a nivel mundial de los estándares de XML y Web services hacen que la mayoría de las empresas encaren sus proyectos de integración de forma tal de incluir la tecnología orientada a servicios. Todo, desde contenido Web, hasta mensajes y datos estructurados pueden ser representados en XML. Hoy, los proyectos mas importantes de casi todas las industrias soportan un esquema estándar de XML. Por ejemplo, el FDIC obliga a todos los bancos asegurados a reportar sus finanzas en un formato llamado XBRL (eXtensible Business Reporting Language). La industria de seguros pide a sus miembros que intercambien la información de pólizas en formato ACORD XML. Wall Street usa un formato de XML llamado FpML (Financial Products Markup Language) para intercambiar subproductos financieros. Si contamos además con que todas las herramientas de integración actuales dan soporte a este lenguaje, podemos imaginar la penetración que tiene hoy y lo importante que es para los proyectos de EAI. La expansión de los Web Services y la proliferación de servicios como componentes para armar infraestructuras de negocios están fomentando el uso de nuevas arquitecturas de desarrollo. En particular la más usada es SOA (Service Oriented Architecture). Los integradores han entendido que el camino a la flexibilidad, facilidad de administración y disminución de los costos, conduce a una arquitectura basada en servicios independientes y transparentes de las aplicaciones que los usan.

SOA intenta ser la moda Service Oriented Architecture (SOA) es un paradigma para el diseño, desarrollo, implementación y administración de distintas unidades lógicas (servicios) dentro de un entorno informático. SOA exige a los desarrolladores que diseñen las aplicaciones como una colección de servicios, aún si los beneficios de ello no son aparentes. Requiere que los desarrolladores piensen más allá de los límites de su aplicación y consideren la reutilización de los servicios o analicen como pueden ser rehusados. SOA demuestra ser un método para construir infraestructuras de software donde los componentes de IT son reunidos en servicios



de negocios “poco acoplados” que pueden ser invocados sin saber donde se ejecutan o en que plataforma. La importancia de SOA proviene del hecho que introduce el reuso y brinda la habilidad de combinar servicios para soportar nuevos procesos de negocios. Los principales productos de EAI ya incluyen soporte para SOA como una de sus funciones mas importantes. Están pensados para la rápida creación de Web Services y su integración a otros entornos por medio de los estándares conocidos. Contar con una SOA es sinónimo de flexibilidad y facilidad de integración, o por lo menos eso es lo que están intentando los nuevos productos para empresas. Basados fuertemente en los estándares conocidos en su mayoría en EAI y Web Services, los proveedores están constantemente agregando propiedades de compatibilidad e integración a sus productos. Permitiendo a los encargados de IT “mezclar” soluciones de distintos vendedores y así contar con las mejores herramientas.

Futuro Según el Integration Consortium (IC) hay cuatro puntos clave a tener en cuenta para el año 2005: arquitectura orientada a servicios (SOA), la batalla por la participación en el mercado de los ESB (enterprise service bus), los vendedores de soluciones luchando con sus estrategias de integración, y la combinación de business intelligence y business integration. Los Web Services, mas que el futuro son el presente, pero de todas formas seguirán siendo el centro de atracción de las inversiones y desarrollos. Van de la mano con SOA y en lo referido a integración de negocios (B2B Business-to-Business) es el estándar a seguir. La tendencia como siempre es abaratar los costos y flexibilizar la tecnología. Los grandes emprendimientos de EAI darán lugar a desarrollos más específicos y focalizados. Además a medida que las empresas van adaptando sus arquitecturas hacia una visión más integradora y de servicios, los futuros cambios e incorporaciones serán menos traumáticos y más sencillos. Los nuevos desarrollos de sistemas para negocios ya vienen con todo lo necesario para su integración con otras herramientas y plataformas. EAI ha madurado, de integración de aplicaciones a integración de procesos de negocio y flujos de trabajo. La tendencia es la automatización inteligente y la integración colaborativa entre aplicaciones, involucrando los procesos de negocio.

Conclusión Las arquitecturas para el soporte de integración, transformación y manejo de mensajes entre aplicaciones continúan evolucionando. Es lógico que no se puedan cambiar todas las aplicaciones que utilizan en una empresa por un solo sistema que “hace todo”. Tampoco es viable estar haciendo integraciones Ad-hoc para cada empresa y aplicación. Hoy nos encontramos con una amplia gama de soluciones para la integración, y empresas especializadas en proveer herramientas para conectar los diversos sistemas empresariales. Lo que se busca es velocidad de reacción a los cambios de mercado, facilidad de mantenimiento y bajos costos. Es llamativa la cantidad de artículos y papers que se publican sobre herramientas, técnicas, estándares y todo lo que tenga que ver con empresas, negocios e informática. Tanto material termina confundiendo y haciendo muy difícil la búsqueda de buenas soluciones. Asimismo es lamentable que los grandes proveedores no se pongan de acuerdo para respetar estándares y arquitecturas. Los Web Services y la arquitectura SOA parecen haber captado bastante atención como para poner un buen marco de trabajo y contar con el apoyo de los grandes proveedores de soluciones. Para terminar tengo dos reflexiones: No hay soluciones completas, buenas y baratas. A veces las soluciones son tan confusas y rebuscadas que no se las distingue de los problemas.



Referencias An Introduction to the True Definition of Enterprise Application Integration (EAI) –The Integration Consortium (enero 2004) Integration Consortium Forecasts Integration Trends for 2005 – Integration Consortium (nov 2004) The EAI Paradigm Shift – Madhavan Krishnan (abril 2004) EAI Principles – John Schmidt (mensual nov 2002 – feb 2003) �EII: Dead on Arrival – Andy Hayler (julio 2004) Enabling Next Generation Enterprises – John Schmidt (julio/agosto 2000) Enterprise Application Integration “Viewpoint” – Parker Shi & Suketu Gandhi (julio/agosto 2001) Enterprise Application Portals – Chuck Kao (feb 2001) Role of EAI: Connect & Transform Enterprise Information - Sai Mungara (ago 2003) SOA Today: Introduction to Service-Oriented Architecture - Jeremy Westerman (ene 2004) Will Web Services Kill EAI? - Martin Bluter (mayo 2002) EAI Market Predictions – John Schmidt (marzo 2004) Intelligent Solutions: What's an Architecture, Anyway? - Claudia Imhoff (dic 2004)

Links relacionados www.eaijournal.com www.ittoolbox.com www.intelligententerprise.com www.intelligentintegration.com www.eai.ittoolbox.com www.dmreview.com www.bijonline.com



SOA – Caso de Estudio Pablo Michelis

[email protected]

Introducción El presente documento tiene como objetivo describir la arquitectura de la solución implementada para resolver la operación distribuida de las tesorería de los locales.

Requerimientos El objetivo del proyecto es construir un modelo de procesos para la administración centralizada de las tesorerías de las tiendas, que establezca estándares sobre la operatoria a través de la incorporación de mejores practicas a partir de la implementación de soluciones informáticas. Dada la distribución geográfica de las tiendas, la capacidad de los enlaces entre éstas y la central, y la dificultad de determinar el alcance definitivo del proyecto en términos de cantidad de tiendas operativas, es que se hace necesario permitir que la infraestructura sea escalable. La naturaleza crítica de esta aplicación radica en que podría llegar a administrar el 100% de la recaudación de la compañía, lo cual hace necesario un gran nivel de disponibilidad y seguridad. Es por este motivo que la escalabilidad horizontal además de permitir distribución de carga, aumentará la disponibilidad de la solución. La escalabilidad horizontal es de fácil implementación en niveles de aplicación que no conservan estado (stateless), pero se dificulta en los niveles de administración de persistencia. Por este motivo los servicios de persistencia se encontrarán en un cluster que pueda crecer verticalmente hasta un umbral pesimista previamente establecido. Los requerimientos de seguridad, tanto en el control de acceso por funciones como en lo que hace a transporte seguro de mensajes, hace necesario contar con servicios de autenticación, control de acceso y mensajería segura entre los diferentes niveles de arquitectura. En resumen, la aplicación presenta a priori los siguientes requerimientos no funcionales:

Distribución de carga. Escalabilidad horizontal y vertical. Autenticación. Control de Acceso. Mensajería

Niveles de Arquitectura El modelo conceptual está basado en la definición de casos de uso, los cuales a su vez se descomponen en interacciones entre cada actor y la aplicación. Siendo el diseño consistente con este concepto, cualquiera sea el cliente con el cual interactúe el usuario, el mismo deberá estar orientado a eventos y acciones, cuya resolución será solicitada al back-end. Las acciones y las respuestas deberán poder ser transportadas hasta y desde el nivel de servicio de aplicación. Necesitaremos entonces componentes que tengan como responsabilidad encapsular y transportar dichas acciones y respuestas. Los requisitos de alta disponibilidad y alta carga transaccional, como así también los requerimientos de escalabilidad de la aplicación, generan necesidades de distribución de componentes de software. Ésta distribución implica también la necesidad de administrar balance de carga entre estos componentes. Existirá entonces un componente en la infraestructura que será responsable de recibir los requerimientos desde el cliente y decidir quien deberá responder a ellos, bajo cierta política de distribución y asignación de responsabilidades. La resolución de cada acción implicará una reacción que luego deberá ser transportada hasta el usuario a través de los mismos canales. El componente del lado del cliente encargado del transporte lo llamaremos adaptador de canal, mientras que el existente en el nivel de servicio de aplicación lo llamaremos dispatcher. En la descripción de casos de uso, se asocian los actores con las interacciones habilitadas, estas asociaciones componen luego la definición de roles del sistema. Los roles serán vinculados a grupos definidos en una estructura organizativa particular sobre el servicio de directorios, y la relación entre éstos y los usuarios del



mismo servicio de directorios nos brindará la información necesaria para implementar los servicios de autenticación y control de acceso sobre el LDAP4. De este modo los usuarios se autenticarán normalmente contra el LDAP quien retornará el certificado, este certificado será adjuntado a las peticiones (acciones) durante el uso de la aplicación y será de utilidad en el momento de efectuar la consulta sobre los grupos asignados durante el control de acceso desde el back-end. Luego de recibida cada acción, un componente que actuará como agente de seguridad, verificará la autorización del usuario tanto para la acción solicitada como así también para la información a la cual quiere acceder. De no estar habilitada la operación para el usuario o por estar intentando el mismo acceder a información no permitida, se generará un evento de auditoria de seguridad en el log del sistema, y una excepción de seguridad será lanzada al cliente5. Las acciones autorizadas por el agente de seguridad son atendidas por un conjunto de gestores de servicio6. Cada gestor de servicio interpreta un conjunto de mensajes que son consistentes con los especificados bajo cada objetivo de negocio. La necesidad de los gestores de servicio radica en que el modelo de negocio estará implementado sobre un modelo orientado a objetos, mientras que el nivel de front-end y distribución de carga deberá ser orientado a servicios debido a los requerimientos sistémicos7. Los componentes que implementan la recepción, validación y delegación de servicios serán distribuidos y no persistirán. Por otra parte los objetos de negocio serán persistentes recibiendo este servicio de una base de datos relacional. A fin de facilitar y acelerar la codificación se utilizará un framework para este propósito. La Ilustración 1 muestra un diagrama de representación del modelo propuesto, en el cual resumimos los siguientes niveles: Nivel de presentación: rendering8, lógica de presentación, lógica de navegación y captura de eventos. Nivel de soporte de infraestructura: captura de peticiones de servicio del cliente, verificación de permisos sobre peticiones de servicio, transporte de excepciones, generación de excepciones no funcionales9, delegación de peticiones de servicio a su gestor de servicio correspondiente, captura de resultado de ejecución de servicio, transporte de respuestas hasta el cliente y logging de eventos. Nivel de Lógica de negocio: ejecución de peticiones de servicio, mantenimiento de invariantes de negocio, generación de excepciones funcionales. Nivel de persistencia: lógica de almacenamiento, caching y políticas de acceso a datos.

unObjetoDeNegociounObjetoDeNegocio

elAgenteDeSeguridad

unGestorDeServicio

unCliente

unaAcción

unAdaptadorDeCanal

transportar: unaAcción

unDispatcherunaAcción

elCatalogoDeAcciones

existe: unaAcción puedeEjecutar: unaAcción

accionrespuesta

respuesta

recibir: unaRespuesta

unaRespuesta

unObjetoDeNegocio

accion

unObjetoDeNegociounObjetoDeNegocio

unObjetoDeNegocio

persistencia

Ilustración 1: Niveles de Arquitectura

+�! �� ,� ��-�.�� /� �� (�� )�� "� ��0�1�2�� 3�4�� "�� (� �� " �$��(�� 4�� 5�� "��6�!�� )��



Requisitos de Diseño y Construcción

La Lógica de la Arquitectura Durante la definición de arquitectura tecnológica, se establecieron los lineamientos técnicos de infraestructura, y se definió la utilización de .NET como soporte tecnológico para la construcción y posterior ejecución del producto. Según se ha mencionado, la arquitectura del sistema se basará en servicios [Sprott2004]. La propuesta estándar de Microsoft para esta implementación es actualmente10 MBI (Microsoft Business Integrator), el cual nos brindará niveles de transporte desde el cliente hasta el nivel de servicio de aplicación, manejo de eventos y excepciones, distribución y catálogo de acciones. Los objetos de negocio serán implementados según la especificación de requerimientos, los cuales utilizarán los servicios de persistencia a partir de DataObjects.NET11. A pesar que los requisitos de seguridad exceden el estándar de la infraestructura tecnológica, debido a que es necesario definir el alcance de funciones de un usuario en función no sólo del rol sino de la ubicación donde está autenticado, utilizaremos por cuestiones de performance la integración de ADS con el MBI a partir de combinar los grupos de usuario con la estructura organizativa propia de la aplicación. De este modo cuando uno indique que un usuario pertenece a un grupo deberá decir dentro de qué nodo de dicha estructura posee ese grupo, de modo que un mismo usuario puede ser gerente en un contexto, y tesorero en otros. Por esto, un grupo genérico indicará las acciones generales del rol (por ejemplo tesorero), mientras que los usuarios deberán ser asociados a grupos dentro de los contenedores del servicio de directorio. Por ejemplo un usuario será tesorero de Lomas, pero podría ser un usuario de solo consulta en el resto de las unidades organizacionales, con lo que la estructura me permitirá anidar el grupo Tesorero_Lomas con el grupo Tesorero, y al asignar este segundo grupo al usuario poder controlar el acceso de los pares <accion, locación>. En el momento de recibir una petición, el dispatcher colaborará antes de delegar cualquier tarea al gestor de servicios, con el ADS para conocer si el grupo al cual pertenece el usuario en el contexto está habilitado para hacer la operación que está intentando efectuar. Cada vez que una acción esté marcada para que registre sucesos de auditoría de seguridad, se “logearán” los intentos de efectuar operaciones inválidas en el EventLog. La interfaz con el usuario está dividida en dos grupos de funciones. El primero se relaciona con la operación de la tienda, la cual tiene requerimientos de “usabilidad” altos. A fin de cumplir con estos requisitos utilizaremos en casi todas las operaciones de tienda clientes WinForm. El segundo grupo se relaciona con aquellos usuarios cuyo acceso es poco frecuente y donde los requerimientos de “usabilidad” no sean tan exigentes. En estos casos utilizaremos interfaces Web a fin de facilitar el futuro despliegue del producto. Los requerimientos de alta disponibilidad contemplan la posibilidad de caídas generales pero con rápida recuperación. Esto nos permite montar los componentes con estado sobre un cluster (DataObjects.NET, objetos de negocio, base de datos), mientras que el resto puede ser distribuido sobre otras unidades de hardware (gestores de servicio, dispatcher, agente de seguridad). Esto nos brinda una arquitectura orientada a servicios stateless para la infraestructura de distribución (alto balance de carga12), mientras que el nivel de lógica de negocio donde el estado es almacenado y alterado se encuentra en cluster13. Cabe aclarar que el dispatcher requiere de un servicio adicional para el balance de carga llamado NLB14.

La Arquitectura Orientada a Servicios15 Hasta aquí se realizó una descripción lógica del modelo de software a ser implementado, la Ilustración 2 nos presenta un resumen de los componentes arquitectónicos y su relación con la infraestructura. Las Actividades invocan Acciones enviándoles un mensaje a través de un Adaptador de Canal . MBI provee cinco Adaptadores de Canal distintos:

DispDirect: es un adaptador para aplicaciones nativas .Net DispCOM: diseñado para aplicaciones desarrolladas en tecnología COM (VB 6.0, VC++, etc) DispXML: pensado para la interoperabilidad, permite enviar mensajes como documentos XML DispAIC: es un Adaptador diseñado para ser "plug & play" con BizTalk Server. DispInternal: para invocar Acciones desde otras Acciones

�7�.��8��77-�8&9�� !$��*"�/��1�� *�'�� .:� / �� ;,��<�� .:=��(� �� (� �� /�� %�� $�� +�� *�'�4��&��-�1� � >�,�� 8��"�&�� 9� ��



Los mensajes de intercambio, denominados "Request" y "Response" representan datos de entrada y de salida de las Acciones respectivamente y pueden contener una cantidad y una estructura arbitraria de datos. Cada Adaptador de Canal es responsable de adecuar los mensajes de acuerdo a quien lo invoca a un formato común especificado por MBI. Los Servicios comunes de MBI son los encargados de transmitir estos mensajes entre las Actividades invocantes y las acciones de forma absolutamente transparente para las aplicaciones. El MBI implementa estos mensajes de "Request" y "Response" con clases .Net. Las Acciones en general especializan estos dos mensajes de acuerdo a sus propios requerimientos. De este modo, la Acción para obtención de Saldos, denominada por ejemplo "GetSaldo", recibirá un "GetSaldoActionRequest" y retornará un "GetSaldoActionResponse" siendo ambas especializaciones de las clases "Request" y "Repsonse" respectivamente. Esta estrategia para implementar mensajes tiene varias ventajas: Son tipos de datos fuertes, por lo tanto pueden ser verificados aun en tiempo de compilación disminuyendo la posibilidad de errores difíciles de detectar El entorno de desarrollo tiene conocimiento de estas clases y su contenido, y por tanto se pueden utilizar facilidades como el "Intellisense" para facilitar aun más el desarrollo Son serializables a documentos XML automáticamente, de modo de facilitan la integración con aplicaciones externas Son clases extensibles con los mecanismos tradicionales de la programación orientada a objetos: herencia, agregación, composición, etc. Están basados en una estructura de datos de Microsoft.NET denominada DataSet de enorme poder expresivo y computacional. Muchas bibliotecas de interfaz de usuario (como ASP.NET, WinForms) y de acceso a datos (ADO.NET) fueron diseñadas específicamente con soporte para DataSets, por eso codificar con Request y Response es natural y sencillo Los mensajes son siempre recibidos por el Dispatcher. Esta componente de infraestructura es siempre opaca al desarrollador. El Dispatcher es un servicio multiusuario y distribuido que funciona en asociación con un catálogo maestro que detalla las características de las Acciones y Entidades definidas en el sistema e incluye información de seguridad, control de acceso, tipo de registro en la bitácora central, requerimientos de transaccionalidad ACID (provista por COM+) para esa acción, tiempo máximo de ejecución de la Acción, etc. Además el Dispatcher constituye el punto central para el reporte de errores y eventos. Aun en los casos en que las Acciones no estuvieran bien codificadas, los errores reportados serán interceptados por el Dispatcher antes de reenviarlos a la Actividad y quedarán registrados en una única bitácora central definible por el usuario. MBI basa su mecanismo de control de fallos y errores en excepciones .Net. Localizada la Acción, ésta es invocada en las condiciones especificadas en el catálogo, pasándole el objeto Request original más información de contexto. Esta información de contexto contiene entre otras cosas: La fecha y hora de invocación: Puede reemplazarse por un componente especial para manejo de fechas que no sean el calendario El usuario que la invoca Conexiones a Bases de Datos predeterminadas Una vez finalizada su ejecución el mensaje de resultado (en la forma de un objeto Response) es reenviado al Adaptador de Canal y de allí a la Actividad. Las Acciones son clases que implementan una interfaz predeterminada por MBI (Framework.Core.IAction):

public interface IAction { void Execute( Command cmd ); }

Cualquier clase que implemente esta interfase es una Acción invocable por el runtime de MBI. El objeto Command encapsula al Request, al Reponse y otra información de contexto que el Dispatcher pone a disposición de la Acción. El Dispatcher cuenta además con un sistema accesorio de "Health Monitoring" que permanentemente verifica el correcto funcionamiento del mismo. Si encuentra problemas se pueden definir políticas para su salvaguarda, incluyendo reinicio completo del sistema en casos extremos.

Servicios Comunes de MBI Log de Transacciones: Las Acciones se pueden configurar, vía el catálogo, para que su actividad sea registrada. Puede elegirse publicar el mensaje de entrada (Request) el de respuesta (Response) ambos o incluso un fragmento. El mecanismo de logging utiliza internamente colas de datos asincrónicas de forma tal de minimizar el impacto de performance en la Acción. Este servicio interactúa íntimamente con los mecanismos de integración y de soporte a procesos de negocio (BPM) de MBI. Soporte Transaccional ACID:



El modo transaccional que soporta una Acción no es necesario definirlo programáticamente. Esto significa que el entorno creará automáticamente, de acuerdo a las definiciones del catálogo de acciones, un contexto transaccional adecuado basado en el soporte de COM+. De esta forma una Acción puede calificarse según:

No soporta transacciones Soporta Requiere Requiere una nueva transacción Ningún requerimiento especial

Si ocurre una falla, debe generase siempre una Excepción, el Dispatcher iniciará automáticamente los "rollbacks" necesarios en cada uno de los recursos transaccionables (XA/LU6.2) Gerenciamiento de Lotes: El Dispatcher puede procesar una o más acciones en un lote o batch. Esto contribuye a minimizar round-trips entre las Actividades y las Acciones. Se encuentra integrado con el soporte de transacciones ACID de MBI, de modo que puede ejecutar cada acción del lote en su propia transacción o alternativamente generar una transacción global para el lote completo. También puede especificarse la política de cancelación del lote: ignorar la acción fallida y continuar o abortar todo el lote a la primera falla. El modo transaccional y la política de cancelación son combinables. Servicio de Cuadratura de Transacciones: Opcionalmente MBI puede verificar que toda acción que comenzó su ejecución haya finalizado y dejar un registro de todas aquellas que o por timeout o por cuestiones externas hayan quedado sin resolución. Este servicio está diseñado para manejar el concepto de "compensación" de transacciones, de modo de poder dejar registro de transacciones importantes que requieran de confirmación de su ejecución (tanto positiva como negativa, pero no indefinida). La tabla de estado de las acciones en ejecución y finalizadas se administra a través de componentes reemplazables: el runtime de MBI incluye un proveedor basado en SQL Server 2000. Administración de Parámetros: El MBI provee dos mecanismos para el suministro y administración de parámetros a los sistemas. En el primero de ellos los parámetros se almacenan como pares <"nombre", "valor">. En el segundo, se provee además una organización jerárquica de los mismos con calificadores de "Entorno", "Módulo", "Submódulo" y "Nombre". Este servicio es público en el sentido amplio, significando que puede ser utilizado no solamente por Acciones y Entidades sino por cualquier otro sistema de la plataforma. De hecho, puede ser invocado desde actividades y desde sistemas construidos en tecnología COM. Ejemplos:

String DatabaseName = Config.GetConfigParam( "DATABASE" ); int Port = int.Parse( Config.GetConfigParam( "PROD", "CLIENTES", "ALTA", "PORT" ) );

En el primer ejemplo, se muestra como obtener un parámetro "plano" denominado "DATABASE". En el segundo, como obtener un parámetro denominado "PORT" del entorno "PROD", módulo "CLIENTES", submódulo "ALTA". La ventaja es que se cuenta con un único repositorio de parámetros de configuración con independencia del soporte persistente que se elija. MBI ofrece dos alternativas: una basada en archivos XML y otra en una base SQL Server 2000. Contexto de Ejecución: Al momento de ser invocadas las Acciones reciben: El Request enviado por la Actividad Un Contexto provisto por el Dispatcher En primer lugar el contexto ofrece conexiones a bases de datos predefinidas en la configuración maestra de MBI que pueden ser referenciadas por nombre, de modo de librar al desarrollador del problema de lidiar con "cadenas de conexión" (Connection strings), etc. Las conexiones disponibles son SqlConnection y OleDbConnection para SQL Server 2000 y otras bases de datos accesibles vía OLEDB respectivamente. Ejemplo:

SqlConnection conn = Context.GetSqlConnection( "CUENTAS" ); Esta sentencia creará una conexión a la base CUENTAS tal cual fuera definida en la configuración maestra de MBI. El contexto además provee la fecha del sistema. Aun cuando parezca trivial, en algunos entornos como el bancario, la fecha del sistema no es necesariamente la fecha de la máquina o la fecha calendario y obedece a reglas de negocio relativamente complejas. MBI permite definir un "proveedor de Fecha y Hora" para ponerlo a disposición, a través del contexto, de quienes desarrollan las acciones.

Date Now = Context.SystemDateTime();



Por último el contexto también provee la identidad del usuario que invoca la Acción, conforme lo especifica Microsoft.NET. Esto permite, por ejemplo, consultar programáticamente los roles asignados al usuario y tomar decisiones de negocio respecto a eso. En un programa:

If( Context.GetUser().IsInRole( "Oficial de Crédito Senior" ) ) { // Se hace algo especifico para los oficiales Senior }

Los roles son arbitrarios y pueden definirse en una base de datos o en un servicio de directorios como Microsoft Active Directory. Registro de Eventos y Errores: El MBI ofrece un registro unificado de eventos y errores. Toda excepción o falla se registran con el mismo mecanismo a repositorios predefinidos por el administrador de la plataforma. El registro se lleva a cabo con un proveedor intercambiable. MBI ofrece dos: uno basado en SQL Server 2000 y otro en el registro de suceso (EventLog) de Windows 2000. Los repositorios no son excluyentes, de forma que si se definen ambos se registrarán eventos y fallas en los dos simultáneamente. Además MBI define dos Excepciones especializadas para ser utilizadas en las aplicaciones: TechException Para reporte de problemas técnicos: No hay conexión a la base de datos, timeout, etc. FunctionalException Para reporte de problemas funcionales: La cuenta es inválida, cliente dado de baja, insuficientes privilegios, etc. El Dispatcher registra estas excepciones automáticamente. Subsidiariamente, el registro puede ser explorado programáticamente utilizando la interfaz IEventLogBrowseProvider. Catálogo de Acciones: El catálogo de acciones sirve como repositorio para el control de ejecución del sistema, además de proveer las bases para la documentación del mismo. En esencia se trata de una base de datos central en la que se especifica cada una de las Acciones instaladas y sus atributos principales: Nombre Descripción Componente físico que implementa la Acción (Namespace.Clase,Assembly) Mensajes de entrada y salda (Request y Response) Características de logging Características de transaccionalidad ACID Roles de usuario para los cuales esta habilitada Entidad Evento que genera El acceso a este repositorio es programático y MBI provee una herramienta con una interfaz de usuario que permite explorar el catálogo, dar de alta nuevos registros, hacer modificaciones, etc. Obsérvese que este repositorio es mandatorio, ya que es un requisito de funcionamiento para el Dispatcher. Esto tiene como consecuencia beneficiosa que todas las transacciones o método de acceso a las Entidades están documentadas de facto y por lo tanto se pueden construir herramientas que exploten este catálogo y asistan en el desarrollo y descubrimiento de funcionalidad.

Despliegue de Componentes Esta sección describe los instalables en cada caja de hardware requeridos por toda la infraestructura de la aplicación, la Ilustración 3 muestra el diagrama de despliegue que resume los siguientes componentes y protocolos: Componentes Instalables 8!�?�!@4�! � ��777� Este componente implementa el servicio de base de

datos. DataObjects.NET Client Este componente implementa el marco de persistencia y consiste

en un conjunto de objetos .NET al cual hace referencia el componente “SAV – Business Objects”. No se requiere monitoreo de este componente por el grupo de operaciones. El package de instalación del application server incluirá la instalación de este componente.

MS – Framework.NET 1.1 Este componente implementa el runtime necesario



para la ejecfución de los objetos “.NET” (CLR). Es el componente “Microsoft .NET Framework 1.1”.

MS – Message Queueing Este componente implementa un servicio de colas necesario para la mensajería asincrónica de MBI. Es el servicio “Message Queue Server” de Microsoft para W2000.

SAV – Business Objects Este componente implementa el servicio de Objetos de Negocio. Consiste en un conjunto de objetos .NET que implementan la lógica del negocio. Estos componentes son los provistos por Autosys Software a fin de implementar la solución. El package de instalación del application server incluirá la instalación de este componente.

MBI Dispatcher Este componente implementa el servicio de distribución (Dispatcher en Ilustracion_2). Consiste en un servicio llamado “Framework Dispatcher Server” que es instalado junto con el paquete de MBI. La información detallada del modo de instalación se puede obtener de [MBIInstalación]

MS – IIS.NET Servicio de Web App Server MBI – Administrative Tools Este componente implementa las herramientas

administrativas necesarias para configurar el MBI. La interfaz de la misma es Web, por lo que debe ser instalado junto con el IIS.

SAV – MBI Common Assemblies Este componente implementa las Class Libraries.NET response y request según se ha descrito en La Arquitectura de Servicios. Para la instalación existirá un package para cada subsistema, el cual será compartido por el cliente y el server que brinde los servicios del respectivo subsistema.

MS – Iexplorer 5.0 SAV – Resources Consiste en los mensajes y etiquetas definidos en

tiempo de compilación, que son dependientes solo del idioma en el cual está siendo ejecutado el cliente.

MBI – Channel Adapter Este componente implementa las funciones de empaquetado de mensajería entre el cliente y el server. Físicamente consiste un una dll copiada al directorio de la aplicación.

MS –OS Cualquier sistema operativo Microsoft que pueda ejecutar Microsoft Internet Explorer 5.0 o superior.

MS – Desktop OS Windows 2000 Professional o Windows XP Professional.

MS – Server OS Windows 2000 Server o Windows 2003.

La instalación será tácitamente la copia de las dlls que implementan las mismas a un directorio del cliente WinForm, del aplication server y del directorio exportado desde el Web Server.

Equipos y Componentes Servidor de Datos MS – SQL Server 2000

MS – Server OS Servidor de Aplicaciones DataObjects.NET Client

MS – Framework.NET 1.1 MS – Message Queueing SAV – Business Objects SAV – Resources MS – Server OS

Servidor de Distribución MS – Framework.NET 1.1 MS – Message Queueing MBI Dispatcher SAV – MBI Common Assemblies



SAV – Resources MS – Server OS

Servidor Web MS – Framework.NET 1.1 MS – IIS.NET MBI – Administrative Tools SAV – MBI Common Assemblies SAV – Resources MBI – Channel Adapter MS – Server OS

Cliente WinForm MS – Framework.NET 1.1 SAV – MBI Common Assemblies SAV – Resources MBI – Channel Adapter MS – Desktop OS

Cliente Web MS – Iexplorer 5.0 MS –OS

Protocolos y Componentes .NET Remoting – Servicio de Dispatcher Se implementa sobre IP en un puerto prefijado que

es el 6001. Esta configuración es almacenada en una archivo de configuración XML (fmw.config) en el server. * Notar que este puerto es el único que debe ser visible por los clientes WinForm. Esto hace posible filtrar fuera de la infraestructura cualquier otro tipo de acceso.

.NET Remoting – Gestores de Servicio Este protocolo es interno en el sentido que no es exportado mas alla del nivel de servicio de aplicación. Los números de puerto utilizados serán definidos luego de la especificación de diseño de cada gestor.

SQL Connection Es una conección nativa de SQL Server. La base de datos no debe permitir conexiones de otro tipo, ni desde otro esquipo que no sea el Servidor de Aplicaciones.

MS - ADO.NET Connection Esta conexión es necesaria para que el dispatcher conozca si las acciones solicitadas están catalogadas. Este catálogo podría residir en una instancia de SQl Server diferente que el modelo de negocio.

http



��

A��

.��

B �� ! ��

&��

8��

C ��

C (�

, ��$��

C (�� D�� /�

C ��

A��

4�� /� �� D��"��

D�� /�4��

�� D��

D��

A��

��

<��

C ��

C (�

A� � �� ! ��

A�� D � ��

8 �� C ��

��

A��

.��

B �� ! ��B �� ! ��

&��

8�� 8��

C ��

C (�

, ��$��

C (�� D�� /�

C ��

A��

4�� /� �� D��"��

D�� /�4��

�� D��

D��

A��

��

<�� <��

C ��

C (�

A� � �� ! ��

A�� D � ��

8 �� C ��

<.NET Remoting>

<.NET Remoting>

http

��

Cliente WinFormMS - Framework .Net 1.1

MS - MBI 2.0 (Channel Adapter)

SAV - MBI Common Asembly

SAV - Resources

MS - Desktop OS

Servidor de WebMS - Framework .Net 1.1

MS - IIS .Net

MS - MBI 2.0 Administrative tools

SAV - MBI Common Asembly

SAV - Resources

MS - Server OS<SQL Connection>

<.NET Remoting>

Servidor de DistribuciónMS - Framework .Net 1.1

MS - Message Queueing

MS - MBI 2.0 (Dispatcher)

MS - Server OS

<<MS - ADO .Net Connection>>

Servidor de AplicacionesMS - Framework .Net 1.1

MS - Message Queueing

Data Object .Net (Client)

SAV - Business Objects

MS - Server OS

Servidor de datosMS - SQL Server 2000

MS - Server OS

Cliente WebFormMS - IExplorer

MS - OS

Ilustración 3: Diagrama de Despliegue

Referencias [MBIInstalación] “Microsoft Business Integrator – Guía de Instalación” (Guia de Instalacion_sp.doc) [Sprott2004] “Understanding Service-Oriented Architecture” (http://msdn.microsoft.com/architecture/soa - Understanding Service-Oriented Architecture)

[DataObjects.NET] “DataObjects.NET Manual” (http://www.x-tensive.com/Data/Downloads/DataObjects.NET/DataObjects.NET%20Manual.pdf)

Ilustración 2: Niveles de Servicio



Model Driven Architecture Lic Gerardo Rossel Catardo

[email protected]

Introducción MDA es básicamente tres cosas:

• Una iniciativa del OMG para desarrollar estándares sobre la idea de que modelar es un mejor fundamento para desarrollar y mantener sistemas.

• Un conjunto de estándares y productos que adhieren a esos estándares • Un conjunto de tecnologías y técnicas asociadas con esos estándares.

La base del desarrollo de MDA es aumentar el nivel de abstracción, la propia historia de la computación puede verse como la historia de elevar el nivel de abstracción. La idea es que la abstracción respecto a la plataforma de hardware es análoga a la abstracción respecto a la plataforma de software como se muestra en la siguiente figura:



Nada Plataforma de Hardware Plataforma de Software

Assembler

Código Assembler Código Lenguajes de AltoNivel

Modelos Ejecutbles

Compiladores CódigoFuente

Compiladores deModelos

Código Máquina1960s

Código Assembler1980s

Código Fuente2000s

El OMG se embarcó en el desarrollo de MDA porque creen que un modelo UML independiente de la plataforma es el secreto de la estabilidad del software y el ROI. Debido a la proliferación de midlewares plantearon la necesidad de realizar un estándar que permitiera modelar en forma independiente de la plataforma y ejecutar el modelo en cualquiera de ellas. Claro que los productos comerciales que soportan MDA no son tan amplios y muchas veces se quedan en modelos ejecutables sobre una plataforma en el mejor de los casos. El rol de UML es fundamental. Toda aplicación desarrollada bajo MDA se basa en un modelo UML independiente de la plataforma. El estándar MDA provee una metodología y permite a las herramientas realizar las siguientes tareas:

• Especificar un sistema en forma independiente de la plataforma que lo soporta. • Especificar plataformas • Elegir una plataforma para el sistema • Transformar la especificación del sistema para una plataforma particular (la elegida en el paso anterior)

Construyendo una aplicación MDA Se comienza con un Modelo Independiente de la Plataforma (PIM Platform-Independent Model) el cual representa la funcionalidad y comportamiento del negocio sin ningún detalle de tecnología. El PIM es un modelo detallado estableciendo Pre y Poscondiciones mediante OCL y la semántica en un Action Language.

PIMModelo

Independientede la

Plataforma

Luego se mapea el PIM a una tecnología de middleware específica utilizando los mapeos estándares del OMG. El código es parcialmente automático y parcialmente escrito a mano. Es posible mapear un PIM a muchas tecnologías de middleware. Esto genera lo que se conoce como Modelo Específico de la Plataforma (PSM, Platform-Specific Model)



PIMModelo

Independientede la

Plataforma

ModeloCORBA

ModeloJ2EE

Modelo.NET

Otros Modelos

Una herramienta MDA debe entonces generar todo o la mayor parte del código para la tecnología seleccionada. Básicamente, mapea PSM a interfaces de la aplicación, código, descriptores de GUI o WUI, consultas SQL, etc.

PIMModelo

Independientede la

Plataforma

ModeloCORBA

ModeloJ2EE

Modelo.NET

Otros Modelos

CORBA J2EE .NET Otros

Ingeniería de Reversa y Bridge Generation Las herramientas MDA para ingeniería de reversa automatizan el descubrimiento de modelos para la reintegración sobre nuevas plataformas.



PIMModelo

Independientede la

Plataforma

AplicacionesLegadas

Otros Modelos

Otros

CTOS

La generación de puentes se simplifica mediante los modelos de aplicaciones comunes simplificando la integración de aplicaciones entre empresas y dentro de la empresa.

PIMModelo

Independientede la

Plataforma

ModeloCORBA

Modelo.NET

CORBASystem .NET

Bridge deInteroperación

Detalle de Conceptos utilizados en MDA

Modelo Un modelo consiste de un conjunto de elementos que describen alguna realidad física, abstracta o hipotética. Los modelos sirven como un medio de comunicación y son más sencillos de construir que las cosas reales. En MDA se crean diferentes modelos a diferentes niveles de abstracción y se vinculan para formar una implementación. Algunos de los modelos son independientes de la plataforma de software (PIM) y otros no (PSM). Los modelos se expresan mediante una combinación de texto y diagramas donde UML juega un rol fundamental.

Plataforma En MDA se define una plataforma como la especificación de un entorno de ejecución para un conjunto de modelos. Algunas plataformas son J2EE, CORBA, .NET, etc. Una plataforma debe tener una implementación de



la especificación: es lo que se denomina realización. La realización puede ser primitiva o compuesta. En el diagrama UML siguiente se muestra las relaciones entre plataforma y las realizaciones.

Mapeo entre modelos Los modelos tienen relaciones semánticas entre sí. MDA soporta el desarrollo interactivo incremental por lo cual el mapeo entre modelos debería ser repetible. De esta forma se pueden expresar los diferentes aspectos de un sistema con su nivel de abstracción apropiado manteniendo los modelos en sincronía. Un mapping entre modelos toma uno o más modelos como entrada y produce un modelo como salida. La reglas para el mapping se describen mediante mapping rules en una función de mapeo. El mapeo en sí, es una aplicación de la función de mapeo. Las mapping rules son descriptas en el nivel de metamodelo. De esta forma, ellas son aplicables a todos los conjuntos de modelos de entrada que conformen a un metamodelo dado.

Modelos Ejecutables Los modelos ejecutables tienen todo lo requerido para producir la funcionalidad deseada de un dominio dado. Lo modelos se ejecutan. Esto permite la entrega incremental, en comunicación con los clientes, de un sistema funcionando. Los modelos ejecutables no son exactamente lo mismo que el código, debido a que, para producir un sistema, deben entrelazarse con otros modelos. Esto último es, en general, realizado por un compilador de modelos. Una de las formas de expresar modelos ejecutables es mediante UML ejecutable que define una semántica de ejecución para un subconjunto computacionalmente completo de UML.

MOF Meta-Object Facility. MOF es la tecnología fundamental de MDA. MOF hace posible definir diferentes lenguajes para modelar distintos aspectos de los sistemas e integrar modelos expresados en dichos lenguajes. UML es, por ejemplo, el lenguaje más conocido y usado basado en MOF. El metamodelo de UML es un modelo MOF.

CWM Common Warehouse Meta-model CWM es un estándar del OMG. Básicamente es un lenguaje de modelización específico para modelar aplicaciones de data warehousing. El metamodelo de CWM es muy similar al metamodelo de UML pero con un conjunto especial de metaclases para modelar aspectos particulares del dominio (Ej. base de datos relacionales). Al diseñar CWM se removió todo aquello que no fuera necesario para su objetivo y se agregaron aquellas cosas específicas para el dominio de los data warehousing. No existen en CWM aspectos de modelización de comportamiento de UML (diagramas de colaboración por ejemplo).



MDA vs. Desarrollo Tradicional MDA comienza desde un nivel de abstracción más alto que otros procesos de diseño. El modelo de más alto nivel (PIM) es muy abstracto: entidades y servicios. El PSM es una descripción completa del sistema en forma de metadatos (es posible en este nivel incorporar al diseño características específicas de la tecnología). El código que se genera a partir del PSM es muy cercano a la aplicación completa. Los algoritmos que generan PSM desde PIM y el código desde PSM deberían ser configurables por el arquitecto.

MDA y Desarrollo “Offshore” Muchas empresas de los países centrales están utilizando la mecánica del desarrollo offshore. ¿Cómo esto se ubica en el desarrollo usando MDA? Las empresas realizan lo que se denomina modelización onshore: los arquitectos y diseñadores producen modelos formales, luego las herramientas MDA generan código y entonces los programadores offshore desarrollan el código que falta. Esta metodología requiere un fuerte proceso de desarrollo para lograr la coordinación adecuada. Además el uso de patrones de diseño y CBD (component-based development) preceden a MDA. Actualmente es evidente que requerir a los programadores que manualmente codifiquen cada instancia de un patrón es ineficiente. Por ejemplo, un generador puede replicar el Value Object pattern casi completamente a partir de un modelo simple de una entidad, suplementado por una pequeña cantidad de trabajo adicional de un programador, ver la figura (extraída del MDA Journal).

Productos En esta sección se describen algunos productos comerciales que implementan MDA. Algunos tienen limitaciones y no son completos pero dan una idea de la factibilidad de la tecnología.

ArcStyler de Interactive Objects



ArcStyler permite capturar la lógica de la aplicación en modelos, los cuales son trasformados automáticamente a varias tecnologías. Es completamente compatible con MDA del OMG. Utiliza el concepto de MDA-Cartridges que son máquinas enchufables (pluggables) que contienen entre otras cosas la lógica de transformación modelo a modelo y modelo a código. Los cartridges son además extensibles mediante las ediciones Architect de ArcStyler. Algunos de los cartridges son:

• Java2 • C# • Web Accessors • EJB 1.1 • EJB 2.0 • BEA WebLogic 7.0 (EJB 2.0) • BEA WebLogic 8.1

Entre las ventajas económicas está la de contar con una edición comunitaria que puede utilizarse para evaluar el producto.

Kennedy Carter Proveen una suite de productos iUML que cuenta con componentes que soportan UML ejecutable desde la administración de requerimientos textuales, a través de la modelización hasta la generación del 100% del código. El siguiente diagrama muestra el proceso propuesto.

SPECIFY DOMAINS

Identify new/reused domains

Manage TextualRequirements

Model system use cases

ANALYSE NEW DOMAINS

Build Static and DynamicModels

and Specify Actions

Model domain use casesExecute and debug the

xUML domain model

PRODUCE TARGET CODE

Automatically apply designpatterns to xUML models

using code generation

VALIDATE ANALYSIS

Integrate multiple domainmodels using bridges

Execute domain use casesExecute system use cases

FORMALISE ABSTRACTDESIGN MODEL

Select or develop suitabletranslation rules, patterns and

mechanisms

Build or Buy an xUML complier

Borland Enterprise Core Objects II Este producto está orientado al desarrollo sobre una sola plataforma que es .NET. No es completamente compatible con MDA ya que por ejemplo los modelos no pueden luego mapearse a otras plataformas, pero puede decirse que soporta MDD (Model Driven Development). Está orientado a aplicaciones ASP.NET y WinForms. Los modelos creados con ECO (usando la herramienta case Together) son mapeados



automáticamente a diversas bases de datos y las mismas son modificadas según evolucionen los modelos de diseño. ECO II hace fuerte uso de OCL para trabajar con el modelo. Por ejemplo, es posible vincular un componente visual al resultado de una expresión OCL sobre el modelo. La siguiente imagen muestra a Delphi 2005 (IDE en donde viene integrado ECO II) en una sesión de modelización:

Conclusiones MDA apunta fundamentalmente al desarrollo productivo y provee una visión basada en la construcción de modelos independientes de la plataforma. Un conjunto de tecnologías claves hacen posible MDA:

• UML – Unified Modeling Language. • MOF – Meta-Object Facility. • XMI – XML Meta-Data Interchange. • CWM – Common Warehouse Meta-model.

Hay actualmente mayor aceptación de las herramientas MDA aunque no se ha extendido su uso en forma masiva. Juntamente a MDA surgen las metodologías de aplicación como ser Agile MDA (basada en los métodos ágiles). Un estudio realizado por The Middleware Company en un desarrollo J2EE con dos grupos de desarrollo, uno siguiendo el desarrollo tradicional y otro utilizando MDA, dio algunas conclusiones interesantes: Mayor productividad, largo alcance del PIM, permite a los arquitectos lograr que el promedio de los desarrolladores utilicen patrones de diseño consistentes. Además, en términos de codificación y calidad de la aplicación, una observación mostró que los defectos encontrados en los métodos de codificación manual requerían arreglo y retesting, esto impacta en la productividad del desarrollo. El grupo de MDA usaba generación automática vía patrones y no requería estos pasos para la construcción de la aplicación. La tabla siguiente muestra el resultado en cantidad de horas.



De cualquier forma es necesario contar con arquitectos y desarrolladores experimentados y capaces. Un miembro del grupo de MDA dijo: “MDA puede hacer a cirujanos de cerebro mejores cirujanos de cerebro, pero no puede hacer a un personal de limpieza un cirujano de cerebro”. Ni viceversa.

Bibliografía [1] www.omg.org Sitio del Object Manager Group [2] Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML. Jim Arlow, Ila Neustadt Addison Wesley Dic. 2003. [3] MDA Explained: The Model Driven Architecture™: Practice and Promise. Anneke Kleppe, Jos Warmer, Wim Bast. Addison Wesley Abril. 2003. [4] MDA Journal. De Select Business Solutions. [5]Convergent Architecture—Building Model-Driven J2EE Systems with UML. Richard Hubert John Wiley & Sons 2002 [6] Model Driven Architecture: Applying MDA to Enterprise Computing. David S. Frankel. OMG Press. 2003



Integración de Aplicaciones con Web Services Pablo Cecconi

[email protected]

Acerca de este documento Este documento analiza la utilización de Web Services como tecnología para el desarrollo de middlewares de integración de aplicaciones. En primer lugar se presenta el contexto del problema, se realiza un análisis de las opciones y se presenta una solución genérica. Luego se introducen los Web Services, explicando a grandes rasgos su funcionamiento y las tecnologías que los soportan para profundizar luego un poco más específicamente en SOAP. Finalmente se explica cómo podrían utilizarse las tecnologías descriptas para solucionar el problema de la integración de aplicaciones y el soporte que los diferentes fabricantes ofrecen a esas tecnologías.

Introducción Casi todas las empresas, instituciones u organismos gubernamentales cuentan con diferentes áreas o departamentos que usan uno o más sistemas informáticos y bases de datos específicos para realizar sus tareas y administrar su información. En el 99% de los casos estos sistemas no fueron desarrollados para trabajar juntos y en muchos casos ni siquiera fueron desarrollados por el mismo equipo de desarrolladores. Sin embargo, tarde o temprano surge naturalmente la necesidad de integrarlos, ya sea porque se necesita una interfase unificada que permita cruzar información de diferentes fuentes, evitar la duplicación de información y los problemas de consistencia asociados o bien ofrecer servicios que utilicen Internet, e-commerce u otras tecnologías nuevas. Durante muchos años, los departamentos de sistemas de las empresas desarrollaron soluciones punto-a-punto y los desarrolladores de middleware escribieron millones de líneas de código con el objetivo de lograr interoperabilidad entre aplicaciones y datos. Debido a la proliferación de diferentes soluciones ofrecidas por distintos proveedores de software y empleando distintas tecnologías que, como suele suceder, son incompatibles entre sí; en muchos casos se llegó incluso a tener que desarrollar middleware para el middleware. En este documento se analiza la utilización de Web Services (SOAP y otras tecnologías basadas en XML) como medio para integrar aplicaciones. Se presenta un panorama actualizado del estado-del-arte en materia de Web Services, sus ventajas y desventajas para el uso como herramienta de integración y una descripción de los productos más importantes disponibles en el mercado que soportan esta tecnología.

El Problema: La Integración Las empresas en general poseen una variedad de aplicaciones que proveen niveles de interacción que van desde lo muy simple a lo muy complejo. Las funcionalidades incluídas en estos sistemas ofrecen, a su vez, distintos niveles y capacidades de acceso, desde funciones indocumentadas y aplicaciones aisladas a sistemas compuestos totalmente desarrollados.

Consideraciones de contexto Para resolver correctamente el problema de la integración de aplicaciones es necesario tener en cuenta las siguientes consideraciones:

��La mayoría de las empresas poseen múltiples sistemas que nunca fueron diseñados para trabajar juntos. Las unidades de negocios que son las bases de estos sistemas tienen su foco en los requerimientos funcionales más que en las arquitecturas. Debido a que los sistemas desarrollados a lo largo de la vida de una empresa varían mucho en términos de arquitecturas, las empresas suelen tener una mezcla de sistemas con arquitecturas incompatibles.

��Muchas aplicaciones estan organizadas en 3 capas lógicas: presentación, lógica de negocios y datos.



��La mayoría de las aplicaciones de negocios comerciales desarrolladas en la última década proveen interfaces de programación documentadas para permitir el acceso a las funcionalidades de negocios incorporadas en la aplicación. Los proveedores de software ofrecen estas APIs específicamente para permitir la integración con software externo.

��Las interfaces funcionales que provee una aplicación típicamente se abstraen de la representación subyacente de los datos y son por lo tanto más estables.

��Acceder a una función que reside en otra aplicación resulta una extensión natural del modelo de programación de aplicaciones tradicional al que los desarrolladores están habituados. La semántica para acceder a una función externa que reside en otra aplicación es similar a hacer una llamada a un método local. Esto permite una integración natural con aplicaciones existentes.

��Hacer actualizaciones directas al repositorio de datos de otra aplicación (Integración a nivel de datos) pasa por encima de toda la lógica de negocios y las validaciones incorporadas en la capa de lógica de negocios de la aplicación. Como resultado, existe un alto de riesgo de corromper el repositorio de datos de la aplicación.

��Muchas interfaces de programación son específicas de un cierto lenguaje y no están disponibles remotamente a no ser que hayan sido desarrolladas sobre una tecnología específica como ser el Microsoft .NET framework o Common Object Request Broker Arquitecture (CORBA).

Solución Integrar aplicaciones a nivel de la capa de lógica de negocios permitiendo que las funciones de negocios de una aplicación (la fuente) sean accedidas por otras aplicaciones (el destino) como se muestra en la figura 1 (página Error! Bookmark not defined.). A este tipo de integración se lo denomina integración funcional. Para que una aplicación externa pueda integrarse con la aplicación fuente a través de integración funcional deben satisfacerse dos condiciones:

��La función de negocios que se desea debe estar disponible dentro de la lógica de negocios de la aplicación fuente.

��La API de la aplicación fuente debe ser accesible remotamente.

Figura 1. Integración de aplicaciones en la capa de lógica de negocios Si la función de negocios deseada no está disponible, es necesario modificar la aplicación fuente. Si esto último no fuera posible se debería agregar la nueva función por fuera y luego comunicarse con la aplicación a través de alguna otra forma de integración, tal como integración a nivel de datos o a nivel de presentación. Este enfoque tiene menos efectos colaterales y está generalmente disponible en la mayoría de los tipos de aplicaciones. Muchas aplicaciones solo exponen sus funciones de negocios como una API local dependiente de un lenguaje de programación particular tal como C++ o C#. En esos casos, se debe crear un adaptador o middleware local que haga de interface y traduzca los mensajes entrantes de otras aplicaciones en llamadas a la API local y viceversa. En muchos casos este tipo de adaptadores pueden ser lo suficientemente genéricos como para soportar diferentes funciones sin tener que modificarlos para cada función que se quiera publicar.



Contexto resultante La integración funcional es uno de los patterns más comunmente usados para integración de aplicaciones a nivel empresarial o business-to-business. Sin embargo, no existe una única forma de llevarla cabo y una vez que uno se decidió por este tipo de integración debe elegir la manera más apropiada según su situación. Las opciones disponibles se resumen en los siguientes patterns:

��Integración a través de objetos distribuidos

��Integración a través de un middleware orientado a mensajes

��Integración orientada a servicios (a través de Web Services basados en XML)

En el presente documento se discute solamente cómo la última de estas opciones puede ser usada para integración funcional de aplicaciones y cómo es soportada por los principales frameworks de aplicaciones como Microsoft .NET y Java 2 enterprise edition [J2EE].

La Tecnología

Web Services Los Web Services proveen un mecanismo estandar para que las aplicaciones puedan publicar y subscribirse a servicios de software a través de Internet o de una intranet. Las aplicaciones clientes (usuarios de Web Services) pueden localizar los services que proveen los servidores de aplicaciones (proveedores de Web Services) usando el estandar Universal Discovery, Description, and Integration (UDDI), obtener la definición de la interfase usando Web Services Description Language (WSDL), e intercambiar datos usando documentos XML a través de SOAP sobre protocolos universales tales como HTTP, FTP, y SMTP.

Una definición más formal de Web Services de acuerdo con IBM es la siguiente:

Los Web Services son un nuevo tipo de aplicación Web. Son aplicaciones auto-contenidas, auto-descriptas, que pueden publicarse, localizarse y ser invocadas a través de la Web. Los Web Services realizan funciones que pueden ir desde simples pedidos hasta complicados procesos de negocios. Una vez que un Web Service se halla publicado otras aplicaciones (y otros Web Services) pueden descubrirlo e invocarlo.

El funcionamiento de los Web Services es comparable al de la Web estandar en la que un servidor HTTP responde pedidos a un Web browser enviando páginas HTML. Similarmente, en los Web Services existe un servidor SOAP basado en HTTP que escucha pedidos SOAP de aplicaciones cliente. El servidor SOAP interpreta los pedidos (que posiblemente incluyen datos en formato XML) y luego responde al cliente. La respuesta puede consistir de una descripción en formato WSDL de los Web Services disponibles en el servidor; un mensaje de estado tal como la indicación de que un recurso no está disponible o que una transacción fue exitosa; o datos encapsulados en un documento XML bien formado. Para la aplicación cliente de un Web Service, éste aparece como una llamada a un método local, solo que la llamada es traducida a XML (basándose en el estandar SOAP) y enviada a través de la red a la aplicación proveedora del servicio. Visto desde el punto de vista de una arquitectura n-tier, los Web Services son solo una puerta de acceso a un servicio que luego puede ser implementado por otros tipos de middleware (en este caso sería una especie de middleware para middlewares). Así el Web Service consta de un listener que maneja los pedidos y una fachada que expone las operaciones soportadas por la lógica de negocios, que puede ser implementada a su vez por una plataforma de middleware tradicional (RMI, CORBA, DCOM, etc.) como se ilustra en la siguiente figura:



Debido a que los Web Services son accesibles usando URLs, HTTP, y XML, están al alcance de cualquier aplicación desde cualquier plataforma de software o hardware. Tal como se mencionó más arriba, las principales tecnologías que conforman los cimientos de los Web Services son XML, SOAP, WSDL y UDDI. Dando por sentado que todos conocen de qué se trata XML; vamos a centrarnos en la otra tecnología fundamental que es SOAP con el objetivo de dar una idea más clara de las potencialidades de los Web Services como medio de integración de aplicaciones.

SOAP En un principio SOAP, que originalmente significaba “Simple Object Access Protocol”, fue una tecnología pensada para hacer que DCOM y CORBA funcionaran a través de Internet. Sin embargo, con el tiempo el foco de la especificación se amplió con el objetivo de servir a una audiencia mucho más amplia y se convirtió así en un framework generalizado de mensajería basada en XML.

Este cambio de foco provocó un problema con la “O” en el acrónimo, lo que tuvo como consecuencia que el SOAP 1.2 Working Group decidiera no deletrearlo para evitar confusiones. Así, la definición oficial actual, que se encuentra en la más reciente especificación de SOAP 1.2, ni siquiera menciona los objetos:

SOAP es un protocolo liviano pensado para intercambiar información estructurada en un ambiente descentralizado y distribuido. SOAP utiliza tecnologías XML para definir un framework de mensajería extensible, que provea una construcción de mensaje que pueda ser intercambiada sobre una variedad de protocolos subyacentes. El framework fue diseñado para ser independiente de cualquier modelo de programación particular u otras semánticas específicas de implementación.

SOAP define una manera de mover mensajes XML desde el punto A al punto B (ver figura 2 en la página Error! Bookmark not defined.). Para lograrlo provee un framework de mensajería basado en XML que es 1) extensible, 2) usable sobre una variedad de protocolos de red subyacentes, y 3) independiente de modelos de programación. Figura 2. Mensajería SOAP sencilla.

En primer lugar, una de las claves de SOAP es la extensibilidad. A la vez, como se evidencia por la falta soluciones a problemas típicos de sistemas distribuidos como la seguridad, el ruteo, etc. la simplicidad continúa siendo uno de los objetivos primordiales de diseño de SOAP. Mientras tanto, Microsoft, IBM y otros proveedores de software están trabajando en un conjunto común de extensiones a SOAP para agregarle estas y otras características que la mayoría de los desarrolladores espera encontrar. La iniciativa se denomina Global XML Web Services Arquitecture (GXA) y Microsoft ya liberó una implementación de referencia de varias de esas especificaciones bajo el nombre de Web Services Enhancements 1.0 SP1 for Microsoft .NET (WSE). En segundo término, SOAP puede usarse sobre cualquier protocolo de transporte tal como TCP, HTTP, SMTP, o incluso MSMQ. La especificación de SOAP provee un framework flexible para definir bindings de protocolo arbitrarios y provee un binding explícito para HTTP debido a su popularidad de forma tal de mantener la



interoperabilidad. Más aún, el modelo de procesamiento de SOAP permite incluso la presencia de múltiples nodos intermediarios cada uno con su propio protocolo, como lo ilustra la figura 3. Figura 3. Mensajería sofisticada en SOAP

Finalmente, SOAP no está restringido a ningún modelo de programación ni está atado a RPC. SOAP define un modelo para el procesamiento individual de mensajes de una sola vía y pueden combinarse múltiples mensajes en un intercambio de mensajes completo. En la figura 2 se ilustra un mensaje donde el emisor no recibe respuesta, pero el receptor podría enviar una respuesta al emisor como lo ilustra la figura 4 (página Error! Bookmark not defined.). SOAP permite emplear cualquier pattern de intercambio de mensajes entre los cuales request/response es solo uno de ellos. Aunque suelen confundirse, request/response no es lo mismo que RPC. Si bien es cierto que RPC usa request/response, lo inverso no es cierto. Debido a la popularidad de RPC, sin embargo, SOAP define un mecanismo estandar para ser usado con RPC. Figura 4. Intercambio de mensajes siguiendo el pattern request/response

Framework de mensajería El núcleo de SOAP es el framework de mensajería que define un conjunto de elementos XML para “empaquetar” mensajes XML arbitrarios para transportar entre sistemas.

El framework consiste de los siguientes elementos XML: Envelope, Header, Body y Fault, todos lo cuales forman parte de un namespace en SOAP 1.1 denominado http://schemas.xmlsoap.org/soap/envelope/. El elemento Envelope contiene un elemento Header opcional seguido por un elemento Body mandatorio. El elemento Body representa el cuerpo del mensaje y es un contenedor genérico para cualquier número de elementos de cualquier namespace; por lo tanto es aquí donde finalmente van los datos que se desean enviar. Por ejemplo, el siguiente mensaje SOAP representa un pedido para transferir fondos entre dos cuentas bancarias:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <x:TransferFunds xmlns:x="urn:examples-org:banking"> <from>22-342439</from> <to>98-283843</to> <amount>100.00</amount> </x:TransferFunds> </soap:Body> </soap:Envelope>

Si el receptor soporta request/response y puede procesar el mensaje exitosamente, podria enviar otro mensaje SOAP de vuelta al emisor como ilustra el siguiente ejemplo:



<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <x:TransferFundsResponse xmlns:x="urn:examples-org:banking"> <balances> <account> <id>22-342439</id> <balance>33.45</balance> </account> <account> <id>98-283843</id> <balance>932.73</balance> </account> </balances> </x:TransferFundsResponse> </soap:Body> </soap:Envelope>

El framework también define un elemento llamado Fault para representar errores. Esto es esencial ya que sin una representación estandar para los errores cada aplicación debería inventar la suya y sería imposible que una infraestructura genérica distinga entre éxito y fracaso de una operación.



Integrando con SOAP La integración orientada a servicios es un pattern posible para realizar integración funcional que conecta sistemas permitiendoles consumir y proveer Web Services basados en XML. Las interfases con esos sistemas se describen a través de contratos de Web Services Definition Language (WSDL). Los sistemas interactúan unos con otros utilizando mensajes SOAP, generalmente a través de HTTP utilizando serialización.

En este esquema una interface de servicio expone la funcionalidad como Web Service y un Service Gateway encapsula en el consumidor la lógica necesaria para acceder a los servicios como muestra la siguiente figura: Figura 5. Conexión entre un proveedor y un consumidor de Web Services

La integración orientada a servicios hace posible la interoperabilidad usando XML y XML Schemas como la base del intercambio de mensajes y usando SOAP como framework de mensajería. Mientras que XML Schema provee un sistema de tipos portable entre arquitecturas técnicas dispares, SOAP provee un framework de mensajería extensible que no está atado a ninguna implementación propietaria o protocolo de transporte y permite el intercambio de mensajes sincrónicos o asincrónicos según las necesidades. A pesar de estas ventajas, una variable a considerar antes de decidirse por esta estrategia es la performance. El uso de XML implica un costo de serialización, deserialización y parsing de los documentos XML. Además, los documentos XML son, en general, mucho más grandes que sus equivalentes binarios porque contienen metadatos y esto podría incrementar el tamaño de los paquetes que deben procesarse durante un intercambio de mensajes. Sin embargo, debido a los bajos costos actuales del poder de procesamiento estas cuestiones podrían resolverse a través de hardware más potente. Además, existe la posibilidad de negociar interoperabilidad por performance usando una codificación binaria dentro de los mensajes SOAP si fuera necesario. Finalmente, dado que esta estrategia cuenta con el apoyo de los más grandes proveedores de software, es muy probable que evolucione de forma tal de resolver los problemas de performance existentes hoy en día.

Soporte de los fabricantes Casi todas las últimas versiones de los principales entornos de desarrollo integrados de aplicaciones y aplicaciones de diseño ofrecen soporte para XML, SOAP y WSDL. Desde Visual Studio .NET (en lenguajes que van desde Visual Basic a C++), Borland Delphi/Kylix, Jbuilder y C++ Builder, Sun Forte for Java, IBM WebSphere Studio y muchos otros incluyendo toolkits open-source. Por su parte, compañias como Rational y TogetherSoft proveen herramientas de diseño y modelado que también integran estas tecnologías. Además, la mayoría de las herramientas mencionadas ofrecen métodos muy sofisticados para incorporar Web Services en las aplicaciones. En muchos casos, el proceso es casi idéntico a comunicarse con un objeto local o invocar una biblioteca de clases; el IDE o el framework de aplicaciones maneja toda la plomería por detrás de la escena.

Microsoft .NET El ambiente Microsoft .NET trata a los Web Services basados en XML como una parte integral de las piezas fundamentales de la plataforma, que incluyen el .NET Framework, Visual Studio .NET (VS.NET), y ASP.NET. .NET tiene incorporado el soporte para construir clientes y servidores de Web Services estandares por igual. En el framework .NET, las aplicaciones cliente pueden invocar un Web Service implementando un Web Service listener.

La integración funcional usando Microsoft .NET podría hacerse así:

��El server (proveedor del Web Service) puede implementar el Web Service en cualquiera de los lenguajes soportados por la plataforma .NET, tales como C#, VB.NET, o Managed C++, que pueden compilarse en Microsoft Intermediate Language (MSIL) y ejecutados en una máquina virtual llamada Common Language Runtime (CLR).



��El Web Service puede instalarse en una plataforma .NET.

��La aplicación cliente (usuario del Web Service) puede implementar el Web Service listener usando MSXML o ASP.NET e invocar el Web Service usando una llamada a un método.

J2EE J2EE es un conjunto de especificaciones, cada una de las cuales determina como deben operar cada una de sus funciones. Existe una API de Java para hacer RPC basado en XML (JAX-RPC) que permite implementar integración basada en Web Services. JAX-RPC usa XML para hacer llamadas a procedimiento remoto (RPC) y expone una API para hacer marshalling y unmarshalling de argumentos, transmitir y recibir llamadas a procedimiento.

La integración funcional usando JAX-RPC podría hacerse así:

��Definir e implementar un Web Service basado en JAX-RPC. La implementación puede ser en una aplicación Java stand-alone o con Enterprise Java Beans (EJB). La API de JAX-RPC puede usarse para crear wrappers basados en SOAP para conformar una interface WSDL para clases Java o EJBs existentes.

��Instalar el Web Service en un sistema que posea el runtime de JAX-RPC server. El tipo de instalación dependerá de la implementación del Web Service; por ejemplo, si la implementación la provee un EJB, la instalación será en un contenedor EJB.

��Invocar el Web Service desde el cliente en el puerto descripto por el documento WSDL. Para la aplicación cliente, la invocación del Web Service aparecería como una llamada a un método local.

Conclusión Los Web Services constituyen una excelente alternativa a tener en cuenta a la hora de considerar la integración de aplicaciones que no fueron diseñadas para trabajar en conjunto ya que las tecnologías que los soportan son estándares apoyados por los más importantes proveedores de software de la industria.

Por otra parte, el hecho de que SOAP permita utilizar cualquier protocolo de transporte, aunque el más usado sea HTTP, asegura la interoperabilidad a nivel de red, mientras que XML provee tipos de datos portables que aseguran la interoperabilidad a nivel de datos. Casi por primera vez en la historia, un conjunto tan grande de fabricantes y miembros de la comunidad informática en general se han puesto de acuerdo en apoyar un estandar común. Este hecho se verifica en la disponibilidad de una inmensa cantidad de herramientas y soluciones disponibles en el mercado para trabajar con Web Services. Aunque algunas tengan un mayor o menor grado de desarrollo, madurez o facilidad de uso, es casi imposible no encontrar una solución que se adapte a las necesidades de un proyecto de integración, ya sea que se trate de EAI, B2B, de una o más aplicaciones o incluso de middlewares propietarios.



Referencias 1. “A Web Services Primer” – Venu Vasudevan

http://webservices.xml.com/lpt/a/ws/2001/04/04/webservices/index.html 2. “Using Web Services for Application Integration” - Gunjan Samtani, 2002.

http://builder.com.com/5102-6389-1045211.html 3. “Functional Integration – Integration Patterns”

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/archfunctionalintegration.asp 4. “Web Service Facade for Legacy Applications” - Naveen Yajaman, Microsoft Corporation; Josh Brown,

Implement.com; Shanmugam Subramaniam, Tony John, Narsimha Reddy, and Venkataraman R, Digitial GlobalSoft (offshore division of HP); Andrew Mason, Microsoft Corporation, Jun 2003. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/wsfacadelegacyapp.asp

5. “Software as a service – How to think of Web Services” - Alan Zeichick, 2004. http://www.devx.com/SummitDays/Article/6649/2213?pf=true

6. “Integration with Web Services” - Steve Vinoski, IONA Technologies, Dic 2003. http://www.iona.com/hyplan/vinoski/pdfs/IEEE-Integration_With_Web_Services.pdf

7. “Welcome to WSIF: Web Services Invocation Framework” http://ws.apache.org/wsif/index.pdf

8. “Understanding SOAP” - Aaron Skonnard, Mar 2003. http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us//dnsoap/html/understandsoap.asp

9. “The Argument Against SOAP Encoding” - Tim Ewald, Oct 2002. http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnsoap/html/argsoape.asp

10. “Wired-Wireless Integration: A Middleware Perspective” - Giovanni Rimassa, Parma University, Oct 2002. http://dsonline.computer.org/0209/d/w5icon.htm

11. “Decide Between J2EE and .NET Web Services” - Eric Newcomer, Oct 2002. http://www.ftponline.com/wss/2002_10/magazine/columns/webservices/default_pf.aspx

12. “J2EE 1.4 Eases Web Service Development” - Frank Sommers, Jun 2003. http://www.javaworld.com/javaworld/jw-06-2003/jw-0620-webservices_p.html

13. “Developing Web Services With J2EE 1.4” - Qusay H. Mahmoud, Feb 2004. http://java.sun.com/developer/technicalArticles/J2EE/j2ee_ws/

14. “Is Your Middleware Dead?” - Steve Vinoski, IONA Technologies, Oct 2004. http://dsonline.computer.org/0409/d/w5towp.htm



Business Process Management (BPM) Ivana Saló

[email protected]

Introducción Desde la realización de procesos implícitos en las prácticas de negocio utilizadas durante los años 20, pasando por la reingeniería de procesos y técnicas de documentación a finales de los años 80, hasta la gestión de workflow de documentos que florecieron al finalizar la década del 90. En los últimos años, la necesidad de alinear la estrategia a la operación de negocio y el desarrollo de la tecnología de información, han generado nuevas formas de gestionar los procesos en las organizaciones. Business Process Management (BPM) se perfila como una nueva tendencia para aumentar la eficiencia del negocio y generar las ventajas competitivas que exige el mercado. �Con el paso del tiempo la visión sobre los procesos y las iniciativas de mejoramiento organizacional fueron cambiando y se evidenciaron esfuerzos por realizar cambios en actividades del negocio, que se percibían como de mayor importancia por su impacto en el desempeño financiero. De esta óptica se originaron los sistemas conocidos como ERP (Enterprise Resource Planning), los cuales participaron como elementos de almacenamiento y consulta de información del proceso y no contaron con mecanismos robustos para controlar la gestión de los procesos de negocio de manera integral. En la actualidad asistimos a un escenario de gestión en el cual los procesos requieren de ser gestionados independientemente de un dominio específico de un sistema. Ellos, constituyen el foco y la unidad primaria de iniciativas de automatización e integración de información, necesarios para responder ágilmente a los cambios exigidos por la dinámica del mercado. La gestión de procesos de negocio en estas condiciones ha dado origen a una nueva etapa en la gestión de procesos denominada Business Process Management (BPM). �Resulta relevante al realizar una breve introducción al concepto de BPM resaltar que del mismo modo que EAI integra y desarrolla el valor del estrato de aplicaciones de una empresa, BPM se integra en el ámbito de los procesos de negocio con lo que mejora significativamente el valor colectivo de los sistemas existentes. Solo tendrá el éxito augurado por los especialistas si se estructura como un nivel de procesos independiente situado sobre los sistemas existentes, integrándose y, por lo tanto, protegiendo inversiones tecnológicas anteriores con independencia de las normas técnicas o arquitecturas escogidas en el pasado (que por cierto, son las que permiten el actual funcionamiento del negocio en su conjunto). Este concepto es denominado en el entorno anglosajón como ENS (Enterprise Nervous System), considerando los procesos de negocio de misión crítica como una auténtica columna vertebral corporativa desde la cual surgen el resto de procesos y subprocesos que engloban la totalidad de la actividad en una gran compañía, independientemente de su sector o tipo de negocio. La decisión de las grandes corporaciones adoptando este tipo de arquitecturas, en donde el proceso de negocio se convierte en la estructura básica a automatizar e integrar, da lugar al desarrollo de dos tecnologías complementarias al universo BPM tal y como lo conocemos, ambas centradas en la optimización de procesos en entornos cambiantes y complementarias entre sí, la conocida como BREs (Business Rules Engines) o Motores de Reglas y la denominada BPA (Business Process Analysis) o Modelización de Procesos. �

¿Qué es Business Process Management (BPM)? Existen diferentes puntos de vista sobre el concepto de BPM, aunque relativo consenso sobre sus beneficios: Para KHAN Rashid16 es la disciplina de modelar, automatizar, administrar y optimizar procesos para incrementar la rentabilidad de un negocio. De manera general, la rentabilidad es un concepto que se aplica cuando se desea medir los resultados obtenidos en la realización de una actividad económica, luego de haber asignado unos

�0�EFA��C��$��.��&�8�!�"*� ��&�� 9� ��G��77%�



recursos (humanos, tecnológicos, financieros) a la obtención de dichos resultados. En otras palabras, la rentabilidad nos da una medida del rendimiento que un capital ha obtenido en un período determinado. BPM por lo tanto aumenta la relación entre la rédito que se genera y los medios utilizados. En esta óptica, el objetivo de la gestión de procesos esta concentrada en el aumento de la rentabilidad. Smith Howard17 define BPM como una nueva aproximación para abordar y gestionar procesos de innovación en las compañías que construye el mejoramiento, a partir del estado actual de un proceso en un momento determinado y que plantea una diferencia radical frente a la reingeniería; la cual construye el mejoramiento desde la redefinición total del proceso. En esta óptica BPM se convierte en una respuesta al caos operativo que presentan las compañías en la actualidad . De manera integral, la administración de procesos de negocio, o BPM, es la práctica de mejorar la eficacia y la eficiencia de cualquier organización automatizando los procesos de negocio de la organización. Para así mejorar la gestión de los procesos de negocio de la firma de principio a fin, a partir de la definición deliberada, colaborativa e incremental de la tecnología; para alcanzar claridad en la dirección estratégica, alineación de los recursos de la empresa y disciplina de mejoramiento continuo, necesarias para cumplir las expectativas de los clientes. Por lo tanto, BPM es la aplicación de técnicas y herramientas de software para modelizar, gestionar y optimizar los procesos de negocio de la organización. BPM proporciona una capa de proceso independiente que controla cómo gente y tecnología interactúan para alcanzar los objetivos o resolver los indicadores dominantes del funcionamiento de la organización. �

Objetivos de BPM » Muchas compañías tiene procesos de negocio que son únicos para su modelo del negocio. Puesto que

estos procesos tienden a desarrollarse en un cierto plazo mientras que el negocio reacciona a las condiciones de mercado, la solución de BPM que se elige debe ser fácilmente adaptable a las nuevas condiciones y requisitos y continuar siendo un ajuste perfecto para la compañía.

» Para utilizar BPM con eficacia, las organizaciones deben dejar de centrarse exclusivamente en los datos y su administración, y adoptar un acercamiento orientado a procesos que no haga ninguna distinción entre el trabajo hecho por un ser humano y una computadora.

» La idea de BPM es juntar los procesos, la gente y la información. » Identificar los procesos de negocio es relativamente fácil, lo que es difícil es encontrar los dueños para

esos procesos. » BPM implica no sólo manejar los procesos de negocio dentro de la empresa sino también implica la

integración en tiempo real de los procesos de una compañía con las de sus proveedores, socios de negocio y clientes.

» BPM implica mirar la automatización horizontalmente en vez de verticalmente.

Una solución BPM tiene seis componentes

�� BPM IDE. La administración de procesos de negocio (BPM) IDE es un ambiente integrado del diseño usado para diseñar procesos, reglas, acontecimientos y excepciones. Crear una definición estructurada de cada proceso es muy importante para cualquier negocio y el IDE permite a un usuario del negocio diseñar todos los procesos sin ayuda de técnicos informáticos.

�� Motor de proceso. El motor de proceso de una solución de la administración de procesos de negocio no pierde de vista los estados y las variables para todos los procesos activos. Dentro de un sistema complejo podría haber millones de procesos que entrecruzan registros y datos.

�� Directorio de Usuario. Los administradores pueden definir a la gente en el sistema por nombre, el departamento, el rol e incluso el nivel potencial de la autoridad. Este directorio permitirá que las tareas sean enviadas automáticamente a los recursos definidos.

�� Workflow. Ésta es la infraestructura de comunicación que transmite las tareas al individuo apropiado. �� Supervisión/Monitoreo de Procesos. Permite a los usuarios seguir el funcionamiento de sus procesos

actuales y el funcionamiento del personal que está ejecutando estos procesos. �� Integración. Los servicios de la integración (EAI) y/o del Web del uso de la empresa son críticos a

BPM pues los procesos de negocio requerirán datos de sistemas dispares a través de la organización.

�3�!89:F�F�*��19�BAC�� &�� 8�� >�$ �$��*�� :$ �� '$��$�$�� "�� "��$ �� /�"�"�� 77%��



Ventajas del BPM ��Dominio completo de los procesos de negocio. BPM facilita que las compañías programen sus

procesos actuales, automaticen su ejecución, supervisen su funcionamiento actual y realicen cambios durante la marcha para mejorar los procesos actuales.

��Crecimiento de BPM. BPM es uno de los segmentos del mercado que crecen con mayor velocidad en la industria del software.

��Automatización de tareas. El software del BPM permite automatizar esas tareas que se estén realizando actualmente en forma manual. Muchas de estas tareas requieren un cierto tipo de aplicación de procesos, procesos de aprobación o rechazo, notificaciones e informes. Una solución de BPM puede hacer que estos procesos sean automáticos.

��Reducción de plazos en los procesos de soporte al negocio. La redefinición de fases, facilitando la elaboración de algunas de ellas en paralelo, la eliminación de tiempos muertos y la automatización de tareas, reducen drásticamente el tiempo global de ejecución de los procesos del negocio.

��Optimización de costos. El BMP, mediante la modelización y la aportación de métricas, permite identificar tareas innecesarias a eliminar y cuantificar los procesos en términos de plazos y consumos de recursos, elementos ambos imprescindibles para avanzar en un proceso continuo de optimización de costos.

��Integración de personas y sistemas en los procesos automatizados. Tanto los recursos humanos y técnicos de una empresa son vitales para sus operaciones, BPM consigue mejorar los procesos de la forma que se desee, sin restricciones tecnológicas y aprovechando el conocimiento adquirido por el personal actual.

��Integridad y calidad de procesos. La monitorización de los procesos asegura que estos se realicen conforme a los estándares definidos, asegurando la calidad e integridad de los mismos.

��Integración de terceras partes en los procesos. La automatización de procesos, combinada con la accesibilidad derivada de las tecnologías web, permite a clientes, proveedores, organismos públicos, etc., terceras partes en general, participar en el proceso de forma automatizada, directa y eficiente, abriendo la organización en términos tanto de acceso a los procesos como de acceso a información.

��Consolidación de la información derivada de la gestión de los procesos. Esta información aporta una perspectiva de dónde está y de cómo lo hacemos, complementariamente a los sistemas transaccionales, que aportan una perspectiva de qué hacemos. Toda esta información, normalizada en un repositorio corporativo, configurará la base del auténtico datawarehouse integral de la compañía.

��Mayor flexibilidad y agilidad para adaptarse al cambio. Busca reducir los obstáculos con los que puede encontrarse en un futuro, adaptándose frente a los cambios que deba sufrir el BPM al modificarse algún proceso del negocio.

BPM en la práctica En definitiva las soluciones BPM facilitan que una compañía sea capaz de redefinir y automatizar sus procesos de negocio simplificándolos, acortando su duración y reduciendo el número de errores.

Para implantar un proyecto BPM, es necesario realizar una adecuada definición, modelización y automatización de los procesos organizativos, pero para garantizar el éxito de la aplicación, es preciso ir más lejos. El éxito radica en la necesidad de fusionar la definición de los procesos (componente normativo y de organización) con la mecanización de los mismos (sistemas de información). En otras palabras, es necesario que el “proceso” y la “normativa” se integren y se soporten en el sistema de información. Y la realidad muestra que el mayor obstáculo que se encuentran las organizaciones para abordar un BPM se localiza en cuestiones como:

o Existencia de procesos no automatizados (procesos auxiliares, soporte, administrativos...) o Existencia de actividades y tareas no soportadas desde los sistemas operacionales (gestión documental,

flujos de aprobación, etc.) o Complejidad en la implementación de las soluciones workflow de mercado. o Materialización de gran parte de los procesos en soporte papel (soporte documental, constancia de

decisiones, análisis de información...); frecuentemente, falta de sincronización con las transacciones de negocio.

o Necesidad inminente de incorporar en la gestión de procesos las últimas tecnologías: soportes digitalizados, workflow, gestión documental, acceso telemático, firma digital, etc.



La implementación de BPM involucra la articulación de la estrategia, los procesos y la tecnología de una empresa para generar valor al negocio. A diferencia de los modelos de gestión anteriores, BPM se concentra en la articulación de las iniciativas estratégicas con los procesos de negocio, apalancados en estándares tecnológicos que facilitan su despliegue alineado en las operaciones diarias de la organización.

Figura 1. BPM articula la estrategia, los procesos y la tecnología de una organización

Para lograr esta articulación es necesario desarrollar una serie de procesos que permiten alinear de manera controlada, los aspectos estratégicos del negocio, a través de la identificación y articulación de los conceptos claves del proceso y la asociación de los componentes tecnológicos que permitan flexibilizar los cambios en la cotidianidad empresarial.

En la práctica, la implantación de esta disciplina de mejoramiento requiere, por parte de la empresa, una dosis de pensamiento en procesos de negocio y la utilización de tecnologías de Información centradas en procesos.

Figura 2. Dimensiones del proceso en BPM. Pensar en procesos de negocio significa que las acciones de cambio que se ejercen sobre el proceso, son evaluadas y planeadas teniendo en cuenta las diferentes dimensiones que juegan en la dinámica del mismo. Esto quiere decir que el proceso se evalúa revisando las actividades que se llevan a cabo, buscando eliminar aquellas que no adicionan valor e identificando las políticas, reglas de negocio y normas que determinan las decisiones que la organización toma sobre el proceso. De igual manera se examinan los trabajos y roles que la empresa destina a la realización del proceso, con el fin de gestionar las barreras culturales, paradigmas, conocimientos y competencias requeridas para su realización.



De igual manera se analiza la estructura de la organización, con el fin de coordinar las diferentes áreas, jerarquías y dependencias que influencian su desempeño. Las condiciones físicas ejercen especial influencia sobre determinados procesos, ya que las condiciones ambientales y geográficas pueden determinar mejoras o reducciones en la generación de valor en determinada actividad del negocio. Las habilidades y competencias del talento humano que participa en la operación del proceso, constituyen otro de los pilares al abordar el proceso de mejoramiento. Finalmente la infraestructura de información y comunicaciones son examinadas para identificar los repositorios de información y las actividades del proceso modelado bajo BPM que consulta o almacena información en otros sistemas del negocio. La identificación de estas interfaces constituye un factor de éxito en la implementación de proyectos de automatización ya que en ellos están generalmente los mayores esfuerzos en la implementación de plataformas tecnológicas y se utilizan para dimensionar el alcance de las diferentes fases del proceso de mejora. La gestión de estos componentes requiere tecnología para actuar con agilidad y facilitar procesos de cambio.

La tecnología de BPM La tecnología que posibilita la implementación y adopción de BPM constituye una categoría nueva de sistemas de información denominada Business Process Management System (BPMS). Inicialmente, y de manera general, un BPMS puede ser definido como un conjunto de utilidades de software para definir, implementar y mejorar procesos de negocio que cumplen con un grupo de características técnicas necesarias para aplicar el concepto de BPM.

�

��

Figura 3 .Business Process Management Systems (BPMS) Estos sistemas permiten manejar el ciclo de vida del proceso a través de características funcionales y no funcionales que posibilitan definir, modelar, implementar y mejorar el proceso durante su operación. Un sistema BPMS esta en capacidad de realizar las siguientes operaciones:

�� Modelado de procesos de negocio. �� Provee entornos de desarrollo de aplicaciones para colaboración entre procesos de negocio. �� Generación, actualización y publicación de documentación de procesos. �� Simulación de procesos de negocio para evaluar su comportamiento en situaciones de carga exigidas en

determinados momentos del proceso. �� Integración de información proveniente de otros sistemas de negocio. �� Automatización de procesos. �� Colaboración entre las empresas que participan en la cadena productiva de la organización. �� Despliegue de aplicaciones que soportan el proceso en condiciones tales que no se requiere mayor

conocimiento y experiencia de un usuario final. �� Análisis de procesos y comportamiento de la operación. �� Gestión de ciclo de generación publicación y consumo del conocimiento generado en la operación del

proceso.



Estas características constituyen la base sobre la cual se desarrolla el modelado, simulación e implementación de procesos en una compañía. La flexibilidad y agilidad en el diseño de procesos, se basan en la abstracción de la realidad que plasma el arquitecto de negocio y las posibilidades del sistema para representar esta realidad de manera gráfica.

Los sistemas BPMS incluyen funcionalidades para representar la interrelación de las diferentes dimensiones del proceso de manera gráfica.

¿Quiénes son los vendedores del software BPM? �Muchas compañías del software hacen soluciones del software de BPM. Los siguientes son alguna de ellas:

• Microsoft (BizTalk) • Savvion • TIBCO (with the Acquisition of Staffware) • Business Objects • Cognos • Computer Associates • Metastorm • Fuego • Lombardi Software • FileNet • Staffware • Vitria • IBM • BEA

�

¿Qué es un Workflow BPM? �

Antes de definir lo que es WorkFlow debemos tener una definición clara de qué es un Proceso de Negocio:

“Un proceso es un orden específico de actividades de trabajo, que se realizan en el tiempo, en lugares específicos y por personas o sistemas, con un principio, un fin, y entradas y salidas claramente definidas. Es decir, una estructura cohesionada y coordinada adecuadamente para la acción”.

Ahora bien, podemos definir el WorkFlow como

“La automatización de los procesos de negocio durante el cual documentos, información y tareas son pasados de un participante a otro, incluso el cliente, acorde a un conjunto de reglas procedimentales.”

Entonces, un workflow:

- es un elemento esencial de la administración de procesos de negocio (BPM). - es un término usado para describir cómo se define el trabajo y cómo se asigna y programa el trabajo. - define la secuencia y las condiciones base sobre las cuales fluye el trabajo. - maneja el encaminamiento del trabajo entre los recursos. Los recursos pueden ser gente, sistemas o

máquinas. - administra el orden en la cual se manejan estos pasos. - permite a empleados supervisar y, configure de nuevo el flujo de un proceso de negocio según lo

necesitado.



Para entenderlo mejor, a través del dibujo de la figura 4 podemos ver que existen diferentes capas en la arquitectura empresarial: Bases de datos, Sistemas y Aplicaciones, Procesos de Negocio y Roles

(Clientes,personal, proveedores, partners, etc.).

Figura 4. Capas de la arquitectura empresarial El objetivo de un sistema de workflow es, a través de un motor, gestionar de forma automatizada los procesos y flujo de actividades, documentos, imágenes y datos, orquestando e integrando los recursos informáticos y los roles. Con la Tecnología WorkFlow:

o El trabajo no queda trabado o extraviado. o Los jefes pueden enfocarse más en los problemas del negocio y del personal, tal como el rendimiento y

capacitación individual, mejoras de procedimientos, y casos especiales, más que en la rutina de asignación de tareas.

o Los procedimientos son formalmente documentados y seguidos de forma exacta y estándar, asegurando que el trabajo es llevado a cabo atendiendo a la planificación, cumpliendo a su vez todos los requerimientos y normas del negocio y externos.

o La persona adecuada, dispositivo o sistema es asignado a cada caso, y los casos más importantes o críticos en el tiempo, son asignados primero. Los usuarios no gastan tiempo escogiendo sobre qué caso trabajar, aplazando así aquellos casos de resolución más dificultosa.

o Se logra el procesamiento paralelo, donde 2 o más actividades no dependientes pueden ser realizadas concurrentemente, generando así beneficios en cuanto a reducción de tiempo de los procesos, mejor servicio al cliente y reducción de costos.

o Se convierte el entorno de trabajo “Reactivo” a un entorno “ProActivo”, con todas las ventajas y beneficios que esto conlleva.

En cuanto a las principales funcionalidades que la tecnología WorkFlow provee, podemos destacar las siguientes:

�� Asignar actividades a las personas de forma automática y según algún criterio o cargas de trabajo. �� Recordar a las personas sus actividades, las cuales son parte de una cola de WorkFlow. �� Optimizar la colaboración entre personas que comparten actividades. �� Automatizar y controlar el flujo de documentos, datos e imágenes. �� Asignarle proactivamente a las personas que deben ejecutar las actividades, todos los recursos

necesarios (documentos, información, aplicaciones, etc.) en cada una de ellas.



�� Definir y controlar “alertas” según criterios de tiempo, de evento o de condición, provocando así algún mensaje a un supervisor, un “escalado” de actividades a otras personas para que las resuelvan, y/o una reasignación automática.

�� Modificar los procesos y gestionar excepciones “en vivo”, o “al vuelo”, y desde cualquier lugar. Es decir, permitir modificar cualquier instancia de proceso ya iniciada, sin necesidad de volver a iniciarla y sin necesidad de escribir código. Además, a través de cualquier navegador para que realmente se pueda realizar desde cualquier lugar.

�� Proveer una vista on line para supervisores del estado y un histórico de cada instancia de proceso, de cada actividad, y del desempeño de las personas.

�� Hacerles llegar a cada persona sus actividades y alertas, independientemente de su ubicación geográfica, a través de la WEB, e-mail, SMS, o cualquier otro dispositivo móvil.

�� Proveer métricas para responsables de áreas, organizadores, gestores de procesos y calidad, tanto para efectos de mejora continua como de indicadores de calidad y de gestión.

�� Integrarse fácilmente con otros sistemas, aplicaciones y ERPs. �� Proveer un alto nivel de soporte para la interacción humana

Los beneficios, tanto tangibles como intangibles, son numerosos. A continuación describo los más importantes :

��Mejora la atención y servicio al cliente. ��Incrementa el número de actividades ejecutadas en paralelo. ��Minimiza el tiempo requerido por los participantes para acceder a la documentación, aplicaciones y

bases de datos. ��Disminuye “drásticamente” el tiempo de transferencia de trabajo, información y documentos entre

actividades. ��Asegura la continua participación y colaboración de todo el personal en el proceso. ��Disminuye “drásticamente” el tiempo que los participantes, supervisores y administradores necesitan

para conocer la situación de un ítem de trabajo (por ejemplo, orden de compra, participación de siniestro, pedido de cliente).

��Simplificación de salidas - “outputs” - automáticas. Documentos Word, faxes, e-mails, mensajes cortos a móviles, etc.

��Disponibilidad de mecanismos para una mejor gestión y optimización de procesos.

BPM hoy Con respecto al posicionamiento que los jugadores tradicionales en la industria están adoptando al respecto de la tecnología BPM, éste viene marcado fundamentalmente por su origen tecnológico. Así, fabricantes tradicionales provenientes de entornos EAI como Tybco o Vitria presentarán mayores fortalezas en aquellos entornos en donde la incidencia de pasos automáticos entre aplicaciones sea mayor mientras que jugadores tradicionales en el entorno Workflow como Staffware o W4 se mostrarán más capaces de gestionar excepciones y monitorizar los rendimientos de procesos con intervención humana, evolucionando en sus desarrollos en los últimos años hacia conceptos como el STP (Straight Through Processing) en donde un proceso es gestionado de principio a fin mediante pasos automáticos sin intervención manual alguna. La confluencia de distintos entornos y su necesidad de integración obligan a un considerable esfuerzo de desarrollo e integración en los proveedores de tecnología. Mención aparte merece la postura de los grandes integradores de sistemas y consultores, como Accenture, Cap, Gemini, Ernst & Young o Soluziona entre muchos otros, grandes prescriptores tradicionales de sistemas de información en las grandes corporaciones. Las altas tasas de crecimiento de la tecnología BPM no estaría teniendo lugar sin que este influyente sector de actividad en la industria hubiera apostado con firmeza por las herramientas de gestión automatizada de procesos como infraestructura de desarrollo, incrementando la eficiencia de sus equipos en los grandes proyectos tecnológicos y reduciendo los costos repercutibles en el cliente final. La Tecnología WorkFlow está evolucionando a pasos agigantados gracias a los nuevos estándares y las nuevas tecnologías surgidas en estos últimos años. Aunque la contribución de los WorkFlows tradicionales de producción, ad hoc, administrativos y colaborativos, es aún notable hoy en día, hay una nueva generación que quizás sea un híbrido que reúne lo mejor de todos los sistemas WorkFlow y otras tecnologías. Como las empresas cada vez más se están orientando hacia los procesos, decantándose principalmente por el e-Business, esta nueva generación de tecnología BPMS (Business Process Management System) está siendo actualmente más investigada y perfeccionada que nunca.



Esta nueva generación supera las anteriores limitaciones, conocidas en los ’90, incorporando amplias capacidades de integración con modernas arquitecturas Java, .Net y XML, principalmente. Adicionalmente, se les están sumando otras tecnologías como WebServices, Motores de Reglas de Negocio y BAM-Business Activity Monitoring. De acuerdo con Howard Smith y Peter Fingar, avalados por la BPMI (Business Process Management Initiative) y la WFMC (WorkFlow Management Coalition), hoy en día ya podemos decir que “los BPMS permiten a las empresas modelizar, implementar y gestionar los procesos de negocio, que abarcan múltiples aplicaciones empresariales, departamentos, y ‘partners’, detrás de los cortafuegos y sobre Internet. Los BPMS son una nueva categoría de software y abren una nueva era en la infraestructura de las TI.” Los BPMS pueden ser vistos de 2 formas: a) como una nueva plataforma sobre la cual serán construidas la próxima generación de aplicaciones, o b) como una nueva capacidad profundamente incrustrada en las categorías existentes de sistemas. En cada caso, adquiriendo los BPMS, las empresas ganan un control sin precedentes sobre la gestión de los procesos y recursos, dándole a su vez más valor a sus sistemas y aplicaciones existentes, y acelerando el logro de los objetivos del negocio. Los BPMS deben reunir 3 requerimientos obligatorios: Flexibilidad extrema, Fiabilidad y Seguridad. Deben poseer capacidades de escalabilidad, alto rendimiento, tolerancias a fallos y calidad de servicio, para poder ser aceptados como un componente de misión crítica de la infraestructura. Y desde que esta tecnología ha pasado la frontera de la empresa - para dirigirse al exterior -, éstos deben también ofrecer niveles avanzados de seguridad. Como podemos apreciar en el gráfico siguiente, los BPMS serán en pocos años el elemento crítico de la infraestructura tecnológica en las empresas, tal como han sido los DBMS en estos últimos 15 años, y pasaremos de una orientación a datos, a una orientación empresarial centrada en procesos.

Conclusiones BPM es el entendimiento, gestión e innovación de los procesos bajo estándares internacionales, alineados con la estrategia de negocio para asegurar la efectividad del proceso y crear valor a la cadena productiva de la empresa y su sector. Constituye un nuevo paradigma para abordar procesos de mejora que aumenta la eficiencia y facilita integración entre diferentes compañías. Se lleva a la práctica integrando la estrategia, los procesos y la tecnología, la cual emplea estándares de modelado para permitir una comunicación fluida y con menor esfuerzo entre procesos de negocio y las compañías del sector.



Se perfila como una nueva línea de pensamiento que atiende necesidades tangibles de las empresas y abre nuevos nichos de mercado para nuevas empresas que se enfoquen en temas de gestión empresarial.

Bibliografía �� What is Business Process management (BPM)? www.bpmtutorial.com �� Matices sobre BPM – Javier Larraz.

www.computing-es.com/Actualidad/Inform%C3%A1tica_profesional/Empresas/2003215029 �� Business Process Management (BPM): articulando estrategia, procesos y tecnología... – Luis Fernando

Sanchez Maldonado. www.degerencia.com/articulos.php?artid=611 �� BPMS, Tecnología para la Integración y Orquestación de Procesos, Sistemas y Organización - Renato de

Laurentiis Gianni. www.rrhhmagazine.com/inicio.asp?url=/articulos.asp?id=253 �� Gestión de Procesos de Negocio. www.imarketing.es/bpm.asp �� Process Management. www.qpr.com �� BPM Simplified – A step-by step guide to Business Process Management with Ultimus BPM Suite.

www.ultimus.com �� Evaluating Integration Brokers: Applying 13 technical selection criteria to Ensemble universal integration

platform. http://www.intersystems.com/ensemble/technology/evaluating-integration-brokers.pdf



JAIN/SLEE Jorge Andres Brassara

[email protected]

Introducción JAIN (Java API for Integrated Networks) es la definición de un conjunto de interfaces que permitirán el rápido desarrollo de productos y servicios basados en comunicaciones sobre Java, vía la integración de redes heterogéneas como la red telefónica tradicional, redes de datos e inalámbricas, y la estandarización de interfaces. En otras palabras, JAIN es una extensión de la plataforma Java para las telecomunicaciones. Los servicios de telecomunicación incluyen, entre otros, al control de llamadas, mensajería, presencia y ubicación de equipos, y afectan desde dispositivos móviles hasta grandes servidores de aplicación de telecomunicaciones. El desarrollo de las especificaciones es llevado a cabo bajo los términos de JSPA (Java Specification Agreement) y de JCP (Java Community Process), permitiendo la colaboración de muchas partes. Entre ellas, se encuentran compañías tales como IBM, Motorola, NTT y Vodafone.

Motivación Actualmente, la industria de comunicaciones está formada por un gran número de sistemas cerrados y propietarios. En general, no existen interfaces comunes y los distintos sistemas suelen ser incompatibilidades entre sí. A pesar de que los organismos detrás de los estándares están constantemente tratando estos temas, los avances que se han logrado son escasos. Además de problemas a nivel protocolo y estándares, hay ciertas incompatibilidades técnicas que fuerzan a las aplicaciones sólo a correr sobre la plataforma o red para la cuál han sido desarrolladas. Como resultado de todos estos factores, el desarrollo de las actuales aplicaciones de telecomunicaciones es un proceso caro y que lleva mucho tiempo, la migración a nuevas plataformas es compleja y su mantenimiento (principalmente, agregar funcionalidad) es más costoso aún. Se espera que JAIN convierta el actual mercado de las telecomunicaciones (formado por un conjunto de sistemas cerrados y propietarios, dispares entre sí) en una arquitectura abierta y coherente de redes de comunicación, dónde los servicios puedan ser rápidamente creados y desplegados, y puedan ser fácilmente desplazados a otras plataformas o tipos de red. Se busca un efecto similar al obtenido por J2EE en la industria IT, pero en las telecomunicaciones. La estandarización permitirá la interoperabilidad entre las distintas implementaciones de los servicios y llevará a los desarrolladores de servicios a escribir bloques modulares y reutilizarlos. La funcionalidad puede ser producida simplemente conectando estos bloques entre sí, utilizando distintas combinaciones. Los ciclos de implementación de nuevos servicios serán drásticamente reducidos.

Objetivos

Servicios Portables La tecnología Write Once, Run Anywhere se encuentra actualmente restringida por la utilización de interfaces propietarias. Esto incrementa los tiempos de desarrollo, retrasa el ingreso al mercado, y el mantenimiento se hace más complejo. Al utilizar JCP, las interfaces propietarias son estandarizadas en interfaces uniformes de Java resultando en el desarrollo de aplicaciones verderamente portables.

Convergencia de redes JAIN permite a las aplicaciones y servicios correr en redes de distinto tipo, tales como las redes telefónicas, de datos e inalámbricas. A medida que pasa el tiempo, la demanda de los usuarios sobre la convergencia de estas



redes aumenta y JAIN permitirá acelerar esta integración. Por ejemplo, esta tecnología hará que el proceso de migración de aplicaciones que corren sobre la red telefónica tradicional hacia Internet sea un tarea sencilla y directa.

Desarrollo abierto Al definir APIs de Java para comunicaciones fáciles de usar, esta tecnología puede aprovechar la masiva comunidad de programadores ya existente.

Unificación de IT y telecomunicaciones En cierto momento, la existencia de una esfera separada de telecomunicaciones tenía sentido, pero no lo tiene hoy en día. Los requerimientos de telecomunicaciones, como la alta disponibilidad y redes confiables, no son más los únicos requerimientos. Por otro lado, muchas industrias IT demandan ahora tales servicios. Como resultado de ello, no tiene sentido escribir aplicaciones solamente de telecomunicaciones. El reúso es posible entre las industrias. Por ello, la distinción entre las aplicaciones IT y de telecomunicaciones comienza a ser cada vez mas difusa. La incorporación de millones de programadores IT, traerá a las telecomunicaciones la economía de escala que la industria de la computación viene disfrutando hace tiempo.

JAIN Service Logic Excecution Enviroment (JSLEE) La especificación de la API de SLEE define un framework de aplicación para el desarrollo de servicios portables de telecomunicaciones. Se define una arquitectura de comunicaciones asincrónica y manejadas por eventos. De todas las APIs de comunicación de JAVA, SLEE es el componente principal y tiene un rol central en la mayoría de topologías de redes de comunicación de Java. Los sistemas de comunicación son típicamente orientados a eventos y asincrónicos. Contrariamente, los sistemas enterprise usualmente utilizan invocaciones directas a métodos. Una arquitectura enterprise existente está definida por la especificación de Enterprise JavaBeans. Dadas las diferencias en los requerimientos entre sistemas basados en eventos y sistemas enterprise, se motivó la especificación de JSLEE a través de JCP. En la siguientre tabla, se muestran algunas de estas diferencias:

Comunicaciones Enterprise Invocaciones -Típicamente asincrónico

Eventos tales como triggers de protocolos Los eventos se mapean con invocaciones a métodos

- Típicamente sincrónico Bases de Datos, Sistemas EAI, Llamadas RPC

Granularidad de los Eventos

Eventos de granularidad fina y alta frecuencia

Eventos de granularidad gruesa y baja frecuencia

Componentes

Objetos livianos conteniendo poca lógica de negocios, ciclos de vida cortos y transitorios: rápida creación y eliminación.

Objetos pesados de acceso a datos, que pueden tener ciclos de vida largos y persistentes.

Fuentes de Datos Múltiples fuentes de datos (ej, eventos disparados por protocolos)

Sistemas Back-end y servidores de Base de Datos

Transacciones

-Transacciones livianas Se completan más rápido y son más frecuentes

-Transacciones de Base de Datos Tardan más en completarse y son menos frecuentes

Cómputo

- Cómputo-intensivo Las principales entradas y salidas son invocaciones a recursos, mensajes y eventos

- Acceso a Base de Datos-intensivo

Los cuatro elementos básicos de SLEE son: resource adapters, eventos, activity context y el entorno de ejecución, que contiene los objetos SBB (Service Building Blocks). En la siguiente figura se puede observar la relación entre estos elementos:



Resource Adapters Los resource adapters se encargan de la comunicación (envío y recepción de eventos) con los sistemas externos al SLEE, por ejemplo, dispositivos de red, pilas de protocolos, directorios o bases de datos. La arquitectura SLEE define de qué manera las aplicaciones que corren bajo SLEE interactúan con los recursos externos a través de los resource adapters. Estos adaptadores amoldan el recurso a las necesidades de SLEE. El tipo de resource adapter declara las características comunes para un conjunto de resource adapters definiendo las clases de Java implementadas y los tipos de evento que pueden ser disparados por adaptadores del mismo tipo. De acuerdo a la arquitectura SLEE, un resource adapter es una implementación específica del fabricante para un tipo de resource adapter particular. La arquitectura de los resource adapters provee un framework para recibir y enviar eventos a diferentes recursos de red. La utilización de estos adaptadores para acceder a recursos manejados por eventos es similar a la utilización de JDBC para acceder a Bases de Datos. La estandarización de la arquitectura de los resource adapters previene que cada fabricante cree una interfaz propietaria para el adaptador de su propio recurso de red.

Eventos Los eventos transportan información de una entidad dentro del SLEE a otra. Sólo las entidades SBB pueden consumir y producir eventos, mientras que otras entidades (como los resource adapters, el mismo SLEE y facilities de SLEE) sólo pueden producir eventos. Cada evento es representado por un objeto event (subclase de java.lang.Object) y un tipo de evento. El tipo de evento determina como el SLEE hará el ruteo del evento, es decir, qué objetos SBB recibirán el evento y procesarán el mismo con los métodos de handling de eventos.

Activity y Activity Context Una activity representa un stream de eventos relacionados entre sí. La representación en Java de esta entidad lógica es el objeto activity, que puede ser creado por un resource adapter o bien por las facilities del SLEE. Un ejemplo de objeto activity, puede ser una llamada de teléfono.



Un activity context es una entidad lógica que representa la actividad que se está llevando a cabo dentro del SLEE y también mantiene atributos que las entidades SBB desean compartir. Es el encargado de recibir y rutear los eventos hacia los componentes SBB. Los eventos pueden ser duplicados y ser enviados a varios SBBs. Los objetos activity usualmente son generados por los eventos provenientes de la red externa. Los resource adapters escuchan estos eventos y crean los objetos activity correspondientes. Estos objetos son situados en el activity context del SLEE. A partir de allí, el SLEE es el responsable de la entrega de los eventos generados a los objetos SBB. De igual manera, los objetos SBB pueden acceder la interfaz del activity context para obtener acceso al objeto activity corriente. Luego, puede disparar eventos a este objeto, que serán entregados a los resource adapters y a la red subyacente. Es importante notar que el modelo de eventos de SLEE esta basado en un modelo publish/susbcribe, similar a JMS. Este modelo desacopla los productores de los consumidores de eventos vía un mecanismo indirecto. Los consumidores de eventos se suscriben a los eventos “adjuntándose” a los activity contexts. Los productores de eventos publican los eventos en los activity contexts. Los productores de eventos no están enterados de los consumidores de los mismos, y viceversa. Los activity contexts definidos mantiene las relaciones entre los productores y consumidores. Como principales ventajas de este modelo, se encuentran:

• Desacoplamiento del productor y consumidor de eventos, facilitándo la modularidad y aislamiento de errores.

• Las aplicaciones y desarrolladores de drivers de eventos sólo tienen que conocer la interfaz con los activity contexts.

• Elimina las referencias directas entre productores y consumidores de eventos, aumentando la robustez al disminuir las referencias inválidas.

• El modelo de distribución de eventos es único y consistente.

Entorno de ejecución y SBBs Un SBB (Service Building Blocks) es un componente de SLEE y es hosteado por un contenedor SLEE. El contendor actúa como el entorno de ejecución del SBB y provee los siguientes servicios de infraestructura al SBB:

• Manejo de recursos y ciclo de vida • Concurrencia • Seguridad • Persistencia • Transacciones

Cada componente SBB contiene una clase abstracta SBB. El desarrollador del SBB debe implementar una clase abstracta SBB para cada componente SBB. La clase abstracta SBB esta compuesta por métodos concretos, que contiene la lógica de aplicación del componente, y ciertos métodos abstractos implementados por el SLEE, que tratan con las cuestiones de infraestructura anteriormentre enumeradas. El entorno de ejecución es el responsable de crear el pool de instancias de estas clases abstractas. Este proceso puede ser comparado con la creación de un componente EJB.

Jain Session Initiation Protocol (JSIP) SIP (Session Initiation Protocol) es un protocolo de señalización utilizado en una gran cantidad de aplicaciones para redes basadas en IP, tales como conferencias vía Intenet, telefonía, VoIP, presencia, notificación de eventos y mensajería instantánea. Actualmente, SIP juega un papel clave en la industria de las telecomunicaciones, ya que ha tenido un grado importante de adopción. Por estas razones, se ha puesto principal atención en este protocolo y se definió una API específica para el mismo.



JAIN y otras tecnologías de Java (Big Picture) La siguiente topología de red muestra una típica solución Java para comunicaciones. Se basa en las principales tecnologías de Java (J2ME, J2SE y J2EE), junto con tecnologías emergentes de comunicaciones (JAIN SLEE, JAIN SIP, etc.). Esta topología de red provee una manera de visualizar cómo se relacionan entre sí las distintas tecnologías en el dominio de las comunicaciones.

Basados en las especificaciones JAIN y SLEE, los servicios de comunicación corriendo en un SLEE podrían comunicarse directamente con sistemas enterprise existentes vía RMI o cualquier otro protocolo que soportado por el servidor J2EE. Contrariamente, si un servicio enterprise necesita disparar algún tipo de funcionalidad expuesta por un servicio de telecomunicaciones, necesita comunicarse vía un resource adapter de SLEE. El resource adapter mapea luego el requerimiento en eventos de SLEE y direcciona estos eventos a los SBBs. Las aplicaciones corriendo en un dispositivo móbil no necesitan utilizar J2ME para acceder a funcionalidad provista por el servidor. Por ejemplo, para MMS (Multimedia Messaging System), el Agente MMS en el dispositivo cliente no está típicamente implementado en Java. Un cliente Web en un equipo desktop también puede estar implementado en cualquier lenguaje de programación. Será compatible con los servicios ofrecidos por el servidor, siempre y cuando protocolo como http sean soportados. A diferencia de J2SE, J2ME no provee la funcionalidad para conectar directamente con EJBs. Esto se debe a que RMI no es soportado en dispositivos móbiles de bajos recursos. Para intercambiar información con sistemas externos, dispositivos móbiles que soportan J2ME podrían utilizar conexiones HTTP.

Estado En el presente, faltan algunas de las APIs para telecomunicaciones (por ejemplo, MM1 para mensajería multimedia), lo cual significa que el desarrollador debe implementar estas APIs. Inclusive, las interfaces entre estos protocolos y el SLEE (resource adaptors) no se encuentran definidos en la actual especificación de JSLEE, lo que hace casi imposible para los fabricantes ingresar al mercado y menos crear uno.



En los últimos meses (septiembre/octubre de 2004), expertos del JSR se reunieron para completar la especificación de las interfaces de los resource adapters, y dejarla lista para revisión pública. Otro problema, es la falta de JVMs embebidas en el equipamento actual de telecomunciaciones, que restingen en gran parte la funcionalidad de JAIN. Los fabricante de equipos y proveedores de JVMs deberán trabajas conjuntamente para incluir JVMs en futuras actualizaciones. De todas maneras, el futuro de JAIN es prometedor. Un comunidad actividad se encuentra en plena evolución, especialmente alrededor de SIP. A medida que JSLEE avanza más profundamente sobre la comunicaciones, más empresas interesadas en tecnologías Java y de redes se han unido al JSLEE Expert Group, incluyendo compañias internacionales de telecomunicaciones como Alcatel, Vodafone y NTT DoCoMo. Muchas de estas compañias ya han realizado implementaciones exitosas de servicios basados en JAIN/SLEE. Además, varios proveedores de equipamento de red están haciendo planes de productos SLEE para el 2005

Conclusión La iniciativa JAIN ciertamente abre el mundo de las telecomunicaciones al lenguaje de programación Java. La visión de una red unificada en donde los servicios son portables, escalables, extensibles, interoperables, y fluyen libremente sin modificaciones a través de las redes, es muy poderosa. JAIN es el primer paso hacia la integración de redes IP, inalámbricas, celulares y telefónicas. Al proveer entornos e interfaces basados en estándares de la industria para crear servicios y aplicaciones para redes inteligentes, JAIN dará la oportunidad a vendedores de software independientes, proveedores de servicios de red, vendedores de equipos y telefónicas de crear componentes basados en Java y hacer crecer estratégicamente sus negocios. A pesar de que JAIN está recién en sus comienzos, la promesa de esta tecnología ha motivado a varias empresas con muchos años en la industria. Esta tecnología tiene el potencial para revolucionar la industria de las telecomunicaciones y abrir muchas oportunidades ha quienes logren capitalizarla.

Referencias • "JAIN and Java in Communications." Sun Microsystems. March 2004. • JAIN API Specifications, 2003 and 2004: http://java.sun.com/products/jain/api_specs.html • “JAIN SLEE Principles”. Sun Microsystems. http://java.sun.com/products/jain/article_slee_principles.html • Ferry, D.; Page, D.; Lim, S.; and O'Doherty, Phelim. 2003. "JAIN SLEE Tutorial." Sun Microsystems:

http://jainslee.org/downloads/jainslee-tutorial-04.pdf • Syscon’s JDJ: “JAIN/SLEE Opening the telecommunications world for Java”: http://sys-

con.com/story/?storyid=46230&DE=1



Programación Orientada a Aspectos

Fernando Taboada

[email protected]

Introducción Existen ciertos problemas en la programación de sistemas que ni las técnicas procedurales ni las técnicas orientadas a objetos aportan una buena solución de diseño. Generalmente, son problemas que fuerzan una solución dispersa a través del código repitiendo código que es común a distintas funcionalidades. El ejemplo típico es el log de una aplicación que suele impactar en casi todas las capas de la misma, por lo tanto su solución suele estar dispersa por el código empeorando el diseño y dificultando el mantenimiento. El problema fue identificado en la década del 70 y se lo conoce como el problema de la separación de incumbencias (separation of concerns). En el año 1997 un grupo de Xerox Parc encabezado por Gregor Kiczales propuso la programación orientada a aspectos (AOP, por las siglas Aspect Oriented Programing) como una nueva técnica de programación, que complementaría a la programación orientada a objetos y resolvería ese problema. Según el paper original, aquellos problemas o incumbencias que no tienen una buena solución se refieren a aspectos que atraviesan (cross-cut) la funcionalidad básica de la aplicación. La técnica propuesta permite expresar claramente esos aspectos en los programas de una manera adecuadamente aislada de la funcionalidad básica. Años más tarde de proponer la técnica, gente de Xerox Parc propuso el lenguaje AspectJ como extensión orientada a aspectos para el lenguaje Java. Desde ese entonces han surgido diversos frameworks orientados a aspectos para distintos lenguajes de programación. AOP está en continuo desarrollo y es un área de bastante interés en ingeniería de software, aunque aun no fue adoptada de una manera clara por la industria.

El problema a resolver Como dije en la introducción, el problema a resolver es el de la separación de incumbencias. En general se dice que las incumbencias son los diferentes temas de los que es necesario ocuparse para resolver un problema. Entre ellos están las funcionales básicas de la aplicación así como también las que hacen referencia a requerimientos no funcionales. La mayoría de las técnicas de diseño se guían al modelar por una determinada visión jerárquica de la organización del sistema. El problema es que las incumbencias no funcionales no suelen adaptarse a este tipo de jerarquías. En las construcciones provistas por los lenguajes de programación el problema se repite. Por ejemplo, en el paradigma imperativo la jerarquía está dada por el árbol de ejecución. En el paradigma de objetos por la jerarquía de clases y la composición de objetos. El problema surge cuando una incumbencia afecta a distintas partes del sistema que no aparecen relacionadas en la jerarquía. Esas incumbencias que aparecen diseminadas en el código se llaman incumbencias transversales (crosscutting concerns) y generan código disperso y enredado (scattering and tangling). Se habla de código disperso cuando hay un mismo servicio que es invocado de manera similar desde muchas partes del programa. Código enredado se da cuando una misma operación tiene que acceder a varios servicios que no hacen a su funcionalidad especifica. El código enredado y disperso genera baja traceabilidad (oscurece la relación entre una incumbencia y su implementación), baja productividad (obliga al programador a desviar la atención de la funcionalidad básica a implementar), poco reuso de código, baja calidad de código y problemas de evolución y mantenibilidad.

Algunas definiciones básicas AOP introduce una nueva unidad de modularidad llamada aspecto que intenta modularizar y separar distintas incumbencias. Ejemplos típicos de incumbencias son seguridad, manejo de excepciones, persistencia, logging, distribución, replicación, y sincronización.



Una vez identificadas las incumbencias y modularizadas en aspectos estos pueden ser aplicados al código que define la funcionalidad básica. Más adelante veremos como se logra la aplicación, pero para eso antes necesitamos definir algunos conceptos básicos:

• JoinPoints: son puntos en un programa. Ejemplos son las llamadas a métodos, a constructores y la lectura y escritura de variables.

• PointCuts: es un predicado sobre atributos de los JoinPoints. Permiten seleccionar un conjunto de JoinPoints. Por ejemplo, se pueden seleccionar métodos en base a los parámetros que reciben, haciendo pattern maching en los nombres, etc.

• Advice: especifican el comportamiento de un JoinPoint identificado por un PointCut. El código especificado en un Advice es ejecutado cuando se ejecuta un JoinPoint seleccionado por un PointCut. Un Advice puede ser ejecutado antes, después o en vez de la ejecución del JoinPoint (before, after, around).

• Aspects: empaquetan Advice y PointCuts en una unidad funcional de manera similar a la que OOP usa clases para empaquetar propiedades y métodos en unidades cohesivas.

La aplicación de los aspectos al resto del código se logra mediante un mecanismo llamado entretejido (weaving) que puede hacerse en distintos momentos de la vida de un programa. Una posibilidad es tomar el código base y los aspectos, y producir un nuevo código fuente con el resultado del entretejido, insertando los Advice en los JoinPoints indicados por el PointCut correspondiente. Otra posibilidad es durante la compilación, generando código objeto que cumpla la funcionalidad base más la de los aspectos. Finalmente esta la opción del llamado entretejido dinámico, por el cual se controla la ejecución del programa y, cada vez que se llega a un punto de unión incluido en un PointCut de un aspecto, se ejecuta el Advice asociado. La forma de especificar los aspectos puede ser mediante código con una sintaxis adicional o no al lenguaje y/o a través de un XML, según el framework que se utilice. Detrás de los aspectos hay dos ideas referentes a la aplicación de los PointCuts que deberían cumplirse en todo framework: prescindencia y cuantificación. La primera tiene que ver con los principios de abstracción y encapsulamiento. Un programador no debería tener en cuenta al desarrollar una funcionalidad que aspectos se le aplicarán luego. La cuantificación se refiere a que los aspectos deben poder aplicarse de forma genérica a un conjunto de JoinPoints.

Aprendiendo AOP con un ejemplo Para entender AOP mostraré un ejemplo utilizando AspectJ para realizar logging. En el ejemplo se muestra como se loguea en el framework open source Cactus utilizado para facilitar el testeo de componentes java server-side. Así se vería un código para logguear sin utilizar AOP: public void doGet(JspImplicitObjects theObjects) throws ServletException { logger.entry("doGet(...)"); … logger.exit("doGet"); }

Utilizando AOP el código para loguear no debería aparecer en ningún método. A cambio de eso se define un aspecto, en el que se indican los PointCut, indicándoles un nombre y el conjunto de JoinPoints a los que aplica. Además se definen los Advise, indicando en que momento se ejecutan, a que PointCuts se aplican y cuál es la acción a realizar. public aspect AutoLog { pointcut publicMethods() : execution(public * org.apache.cactus..*(..)); pointcut logObjectCalls() : execution(* Logger.*(..)); pointcut loggableCalls() : publicMethods() && ! logObjectCalls(); before() : loggableCalls(){ Logger.entry(thisJoinPoint.getSignature().toString()); }



after() : loggableCalls(){ Logger.exit(thisJoinPoint.getSignature().toString()); } }

Por último, el siguiente ejemplo muestra el tercer tipo de Advice, around, que permite reemplazar la ejecución de un método por otro código o no utilizando la palabra clave proceed. void around(): call(public void Hello.say()){ if(Math.random() > .5){ proceed();//go ahead with the method call } else{ System.out.println("Fate is not on your side."); } }

Herramientas disponibles para java y .net A continuación enumeraré las principales herramientas existentes hasta el momento para Java y para .Net Las herramientas para Java cuentan con grado de madurez mayor, mientras que la mayoría de las herramientas para .Net están actualmente en etapa de desarrollo.

Herramientas disponibles para Java: AspectJ: es una extensión al lenguaje Java para soportar AOP. Es el primer framework para el desarrollo orientado a aspectos, es open source y tiene chances de ser adoptado como parte del lenguaje. AspectWerkz: es más liviano que AspectJ y en algún sentido es mejor ya que no modifica la sintaxis de Java, con lo cual no requiere soporte adicional por parte de las IDE y puede tomar ventaja de las herramientas que completan código. Los aspectos pueden ser definidos en un XML o mediante atributos runtime. AspectWerkz utiliza modificación del bytecode en runtime. Dynaop: es un framework que utiliza una estrategia de proxy para implementar los aspectos. EAOP (Event-based Aspect-Oriented Programing): JoinPoints representados con eventos, los aspectos pueden ser combinados entre sí con operadores, permite aplicar aspectos a otros aspectos y permite administración dinámica de los aspectos, permitiendo instanciarlos, componerlos y destruirlos en runtime. JBoss AOP: incorpora AOP en el application server JBoss. Permite aplicar interceptores y patrones a clases Java, componer JoinCuts, crear Advice encapsulados en clases Java, HotDeploy para deployar interceptores en runtime, mediante el mecanismo de AOP llamado Introductions agregar una interface arbitraria a una clase, definir metadatos para las clases o los proxies y finalmente AOP dinámico permitiendo agregar o quitar interceptores en tiempo de ejecución. JAC (Java Aspect Components): es un proyecto que tiene por objetivo desarrollar una capa middleware orientada a aspectos. La idea es que muchas de las incumbencias técnicas que suelen estar acopladas a los application servers sean reemplazadas por componentes orientados a aspectos. Estos componentes en forma de aspectos serían agregables de manera dinámica a los application servers. Los componentes que provee JAC permiten encargarse de la persistencia manejando colecciones y referencias, clustering (balance de carga, consistencia de datos, cache, etc), seguridad (definición de usuarios, permisos de acceso, autentificación), RAD (Rapid Application Development) para desarrollar interfaces Swing y Web de manera sencilla y rápida.

Herramientas disponibles para .Net Dentro del framework .Net existen algunas herramientas que facilitarían la implementación de incumbencias transversales mediante un proxy que intercepte las llamadas a algunos métodos. El caso de la validación de formularios en asp.Net es uno en los que se aplican algunas ideas de AOP. Las validaciones no se insertan en los campos a ser validados sino en el mecanismo de validación, pero por otro lado no hay forma de definir que una validación aplica a cierto patrón de campos. La autenticación de usuarios para todas las páginas de aplicación web tampoco se hace en todas las páginas, con lo cual es otro caso de aplicación de ideas de AOP.



De todas maneras, estas herramientas no son orientadas a aspectos ya que no respetan la propiedad de cuantificación y no permiten al usuario definir sus propios aspectos.

Algunas de los frameworks existentes son:

LOOM.net: es la implementación más avanzada que aplica a todos los lenguajes que se ejecuten en el framework .Net

Weave.Net: está basada en la especificación de AspectJ.

AopDotNetAddIn: es un AddIn para VisualStudio.Net

SetPoint: es un proyecto para agregar AOP al framework .Net. La novedad es que permite agregar PointCuts definiéndolos desde un punto de vista semántico, con lo cual evitaría uno de los problemas de AOP que es la especificación mediante sintaxis de los PointCuts, lo cual trae problemas, por ejemplo, al cambiar nombres de los métodos. Además es desarrollado por gente de nuestra facultad.

Visión de futuro Si bien hay cierta competencia entre los teams de desarrollo de frameworks orientados a aspectos, también hay cierto sentido de colaboración con el fin de promover AOP. Si se toman las cosas buenas de cada uno de ellos se podría armar un framework mucho más potente. Por ejemplo, AspectJ tiene un visualizador de aspectos que permite visualizar como afectarán los Advice al código del sistema y sería bueno que todo framework pueda utilizar este visualizador. Por otro lado, hay posibilidades de estandarizar AOP, la cual se puede dar en diferentes niveles. Puede ser a nivel de la JVM o a nivel del CLR en .Net. JRockit ya lo ofrece y la JDK 1.5 ofrece bastante más en este sentido con Annotations que permite incorporar a cualquier construcción metadatos que pueden ser utilizados en conjunto con un framework de aspectos. Por otro lado es posible que en algún tiempo existan constructores específicos para crear Aspectos, PointCuts, etc. en los lenguajes Java y .Net. También existe un proyecto llamado EarlyAspects que toma las ideas de aspectos para la etapa de identificación de requerimientos y arquitectura. Hay propiedades como la seguridad, mobilidad, disponibilidad que suelen ser incumbencias que afectan a más de un requerimiento y a más de un componente en la arquitectura. Esto permitiría razonar temprano en el ciclo de desarrollo de software en cuanto a los aspectos, evitando problemas más adelante. Los servicios middleware encajan perfecto con la filosofía de aspectos ya que suelen ser servicios que afectan a más de una incumbencia. Se puede utilizar aspectos para tracing, logging, manejo de errores y monitoreo de performance. También en este sentido, los application servers están comenzando a traer nuevos servicios para facilitar el desarrollo orientado a aspectos. Estos servicios incluirían persistencia de objetos, cache, seguridad y transacciones entre otros. El desarrollador debería desarrollar objetos Java en forma normal sin preocuparse de esos temas y luego aplicar los servicios más tarde. La integración de aplicaciones (EAI, Enterprise Application Integration) también parece beneficiarse utilizando aspectos para integrar debido a que distintos equipos de desarrollo tienen que aplicar los mismos requerimientos no funcionales o bien estos requerimientos deben aplicarse a distintas aplicaciones existentes. Uno de los usos de aspectos en EAI es para el merge entre el intercambio interno de información de las aplicaciones con el intercambio externo a un bus de información común. Por ejemplo, en un proyecto era necesario distribuir las notificaciones internas de observers al bus de información de integración, en este caso un Vitria bus. Además era necesario implementar observers para entidades que entablaran un ciclo de vida select, update, delete y los cambios de estados y parte de los datos era necesario informarlos al Vitria Bus. En el primer caso se implementó con aspectos con Advice del tipo Around en los métodos que distribuían las notificaciones internas. En el segundo caso también se usaron aspectos Around en todos los JoinPoints que causaran cambios de estado significantes. Otro uso importante de aspectos en EAI es para el reemplazo del uso de las infraestructuras propias de servicios de cada aplicación por una infraestructura común. En el ejemplo del que hablaba antes, el acceso a servicios en una de las aplicaciones era a través de proxies implementados como singletons, entonces con aspectos Around se



interceptó los getInstance para que devuelvan la instancia del proxy de servicio de la infraestructura común, sin modificar el código original. Finalmente es muy útil utilizar aspectos para soportar un modelo de datos común a todas las aplicaciones y para la implementación de requerimientos no funcionales. Según las conclusiones del proyecto que mencioné como ejemplo, el uso de aspectos resultó en un 95% menos de líneas de código de integración, la performance se incrementó en un factor de 2 y el tiempo de desarrollo se redujo en un factor de 4. Según se espera una de las tendencias más importantes en tecnología es que crezca el uso de webservices. También para esta tecnología parece ayudar el uso de aspectos. Facilitaría la adaptación de la aplicación a cambios en el mundo de los servicios, por ejemplo si un servicio dejar de existir o cambia y también para el encapsulamiento de código de management con aspectos que formarían una capa entre la aplicación y el mundo de los servicios Por el lado negativo, podemos decir que la industria del software todavía no ha adoptado AOP de una forma clara. Una de las razones puede ser la falta de claridad que introducen los aspectos para razonar sobre los programas. Otra es la reusabilidad reducida, ya que la forma de definir los aspectos parece atarlos a una aplicación específica. De todas maneras, existen proyectos que intentan solucionar estos inconvenientes.

Conclusiones Uno de los objetivos principales de los nuevos lenguajes de programación es la separación de incumbencias. En este sentido la programación orientada a objetos provee un alto grado de abstracción, permitiendo a los programadores desarrollar sistemas complejos que sean elegantes, mantenibles, con componentes reusables, funcionalidades bien encapsuladas y otros tantos beneficios. Sin embargo, como dije anteriormente existen problemas que para los que OOP no provee una manera adecuada de resolverlos. Estos problemas son las incumbencias transversales que suelen afectar a más de una funcionalidad de la aplicación. Los aspectos surgen como un nivel de abstracción más por sobre los objetos complementando su uso en beneficio de una mejor calidad de software. Si bien la programación orientada a objetos no es la única propuesta para solucionar el problema de las incumbencias transversales, es la de mayor aceptación. El incremento de soluciones de middleware, el aumento de las actividades de integración de aplicaciones, así como el aumento de la tecnología de webservices parecen dar empuje al desarrollo orientado a aspectos, facilitando el desarrollo de requerimientos no funcionales y la combinación y administración de webservices. En este momento hay numerosos proyectos de AOP y cada vez es más el número de desarrolladores que cuentan con el know how acerca de aspectos, pero de todas maneras se puede decir que la tecnología recién esta dando sus primeros pasos y queda bastante camino por recorrer para llegar, por ejemplo, al grado de aceptación que tiene hoy la programación orientada a objetos

Bibliografía 1. Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Marc

Loingtier, John Irwin. Aspect-Oriented Programming. ECOOP 1997 2. G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm y W. Griswold. An Overview of AspectJ, ECOOP

2001. 3. James Holmes. AOP: Taking Abstraction One Step Further. Oracle Magazine Septiembre/Octubre 2004 4. Nicolás Kicillof. Programación Orientada a Aspectos (AOP)

http://www.ajlopez.net/ArticuloVe.php?Id=611 5. Arno Schmidmeier, Using AspectJ to Eliminate Tangling Code in EAI-Activities 6. María Agustina Cibrán, Bart Verheecke, Modularizing Web Services Management with AOP 7. Anis Charfi1, Mira Mezini. Aspect-Oriented Web Service Composition with AO4BPEL



Sistemas de Administración de Contenidos ��

�Gabriel Bulfón

[email protected] ��

Han pasado varios años desde que aparecieron en el mercado los primeros productos para la administración de contenido orientados principalmente al manejo de sitios web. Pero a pesar de esta evolución y mejora constante en un mercado tan competitivo, aún se está muy lejos de la madurez y queda mucho por hacer.

¿Qué es un CMS? Un CMS es una herramienta de software diseñada para ayudar a los administradores de contenido a recolectar, administrar y publicar sus contenidos (Fig. 1). Utiliza un repositorio central (base de datos y/o sistema de archivos) para mantener los contenidos y otros datos referidos a los mismos (metadata, reglas, relaciones existentes entre contenidos e información de soporte como por ej. categorizaciones o taxonomías). En un sentido amplio, CMS describe al software que permite a los administradores fundamentalmente crear y actualizar más fácilmente los contenidos.

Fig. 1 – Manejo de contenidos en un CMS

Algo de historia Cuando internet dejó de ser una herramienta exclusiva del ámbito universitario y comenzó a extenderse, muchas empresas decidieron tener presencia en la web publicando sitios que inicialmente contenían información institucional y algunos datos para atraer a potenciales clientes a contactarse para satisfacer sus inquietudes y principalmente hacer negocios (exhibiendo sus teléfonos, direcciones de email, direcciones postales, etc).

RECOLECCIÓN

PUBLICACIÓN

ADMINISTRACIÓN



Luego descubrieron que mucha gente se acercaba a sus sitios y entonces decidieron proporcionar más información, principalmente acerca de productos y servicios. Más adelante comprobaron que internet estaba a la altura de otros canales, especialmente en lo que se refiere a promoción y comercialización de productos y atención al cliente. Y así aparecieron nuevos elementos como los banners, el e-commerce y los chats para atención online. ��Tanta información diversa y hasta a veces repetida en diferentes destinos (internet, intranet corporativa, extranets para proveedores, mailings, newsletters, etc) se puede convertir en algo inmanejable y con altísimos costos de actualización. A raíz de este notable crecimiento surgió la necesidad de elaborar herramientas para administrar y organizar esta información simplificando las tareas de creación, edición y publicación de contenidos [5,12] (Fig. 2). ��

��

Fig 2 – Fuentes y destinos en un ECM. ��

Conceptos importantes detrás de un CMS Administrar contenidos implica recolectarlos, administrarlos y publicarlos en los destinos deseados de manera eficiente.

��Las tareas de recolección se refieren tanto a la creación como a la importación de información.

Esta información es convertida a un formato común (por ejemplo XML) y segmentada en partes discretas llamadas componentes de contenido. Estos componentes son contenedores de metadata para los contenidos y facilitan el almacenamiento, organización y recuperación de la información.

��Los contenidos son administrados dentro de un repositorio que está formado por registros en una

base de datos y/o archivos que contienen componentes de contenido a los que se les suma datos administrativos.

�� Para hacer disponible el contenido, el CMS lo publica en los destinos indicados (por ej. sitios web,

documentos para imprimir, newsletters, etc.) Un CMS ayuda a organizar y automatizar estos procesos de recolección, administración y publicación. ��

¿Cuándo conviene usar un CMS? [1] �� Cuando hay mucha información para procesar manualmente (muchos items de contenidos o

muchos tipos de contenido).



�� Si el diseño de una publicación necesita ser separado del contenido para que si se necesitase

cambiar el diseño de cada página no haya que modificarlo todo a mano. ��Cuando son muchos los autores de contenido y los contenidos son entregados en diversos

formatos. �� Si la información cambia muy rápido como para ser procesada a mano. ��Cuando se necesita crear más de un destino de publicación a partir de una misma base de

contenido. ��Cuando el destino de publicación requiere personalización. ��

Fig 3 – Motivos para utilizar un CMS.

Beneficios Cuando el volumen de contenidos y/o la cantidad de gente que contribuye con contenidos son muy grandes, un CMS facilita, simplifica y organiza las tareas de recolectar contenido. �Entre los beneficios que obtenemos al utilizar un CMS podemos mencionar: ��Tenemos una sola fuente de contenidos. �

�� Facilita y promueve la reutilización de los contenidos. �� Podemos manejar diferentes versiones para los contenidos. �� Se simplifica el mantenimiento de los contenidos. �� Se puede mantener la consistencia de la información en varios destinos. ��La creación y publicación de contenidos es más fácil. ��

Características de un CMS �Existen algunas características básicas que deberían estar presentes en cualquier CMS para que el sistema funcione eficientemente y ahorre dinero. Entre ellas podemos mencionar: ��El repositorio central del CMS para el contenido corporativo debe ser accesible a un rango amplio

de usuarios técnicos y no técnicos. Su interfase debe ser fácil de usar y su arquitectura debe

Muchas publicaciones ��

Demasiado cambio ��

Demasiado contenido �� !��

Muchos colaboradores �� "�� #�$��!��



ajustarse al marco de trabajo definido por el área de tecnología de la organización. Además, debe manejarse con menús y se deben poder agregar páginas y ser vinculadas fácilmente.

��Crear, diseñar y publicar contenido web debería ser automatizable según las necesidades de la organización.

��Debería reducir el tiempo que los programadores gastan en construir formularios a medida para

manejar contenidos para que ese tiempo pueda emplearse en el front-end del sitio. ��El diseño de la interfase de usuario debería ser cambiable utilizando templates (por ejemplo

mediante templates XSLT que transformen en HTML a los contenidos representados en documentos XML)

��La herramienta CMS debería poder ser usada para manejar usuarios, grupos, roles y permisos de

forma centralizada. Debería tener la facilidad de autenticar usuarios o grupos que pertenezcan a dominios Windows o Unix.

��Debería poder utilizar las últimas tecnologías en bases de datos e Internet y ser usada en cualquier

sistema operativo o plataforma. ��Tendría que proveer de una buena seguridad para los contenidos. Debería controlar quién está

habilitado para publicar el sitio y quién tiene permitido ver qué contenido. ��Debería eliminar el gran volumen de actualizaciones redistribuyendo el trabajo de publicación

entre los autores de contenido quienes pueden publicar y actualizar sus propios contenidos en forma simple y a través de herramientas basadas en navegadores web.

��Tendría que reducir los costos y tiempos de mantenimiento. La mayoría de las operaciones de

mantenimiento deberían ser automáticas. �� Para los autores de contenido deben tener facilidades como: seleccionar diferentes tipos de

contenido, cortar y pegar desde otras aplicaciones, poner fechas de publicación y de vencimiento, indexación automática de páginas y vinculación.

��El CMS debería poder escalar en términos de performance, integración con otras aplicaciones y el

agregado de características particulares. ��Debería permitir construir taxonomías o categorizaciones para clasificar los contenidos [11]. ��Tendría que permitir definir diferentes destinos y para cada contenido poder indicar en qué

destino publicarlo. ��Debería facilitar el almacenamiento de contenidos multilenguaje (localización). ��Debería ayudar a generar menús de navegación de manera simple y links entre páginas en forma

automática. ��

Problemas observados en los CMS �Hay muchas críticas que hacer a los CMS. Aún los productos comerciales que llevan años y han pasado por varias versiones no llegan a cubrir las necesidades de sus usuarios. �Descubrir qué incomoda más a los usuarios puede ayudar a comenzar a tratar esos problemas constructivamente. Un informe del Asilomar Institute for Information Arquitecture (AIfIA) identifica



los mayores obstáculos detectados para que los CMS sean efectivos [2]. Entre los más importantes encontramos: ��El software comercial es muy caro.

��Requieren demasiadas modificaciones para implementar requisitos particulares. ��Hay dificultades para evaluar a los vendedores. ��El software comercial requiere de mucho tiempo para ser implementado. ��No son lo suficientemente flexibles como para adaptarse al diseño ya definido del sitio web. �� Poseen procesos muy pobres para migrar contenidos antiguos.

��El workflow no se adapta a nuestras necesidades. �� Presentan dificultades para integrarse con otros sistemas. �

�

Estado actual del mercado de los CMS �Se estima que hay más de mil productos CMS en todo el mundo. En su gran mayoría son desarrollos pequeños de compañías locales y solo unos pocos pertenecen a vendedores “globales”. �Los fabricantes están mejorando continuamente sus productos y sus capacidades varían mucho entre distintos productos. Tampoco existe mucho consenso en lo que se refiere a terminología y funcionalidades. Muchos conceptos adquieren nombres distintos según el producto del que se esté hablando. Y en general, no hay una correlación real entre el precio de los productos y las capacidades que ofrece. El estudio sectorial, basado en la herramienta analítica conocida como "cuadrantes mágicos" de Gartner, describe los puntos fuertes y débiles de los fabricantes en mercados específicos, situando a las compañías en los cuadrantes según su visión de mercado y su capacidad de ejecución. Para Gartner, las empresas visionarias son aquellas que presentan un enfoque claro sobre la dirección del mercado y que orientan sus esfuerzos en este sentido, y que todavía están en condiciones de optimizar sus servicios. Según Gartner los líderes tienen los mejores valores combinados de visión de mercado y su capacidad de ejecución. Ellos están trabajando muy bien y están preparados para el futuro con una visión claramente articulada para ECM (Enterprise Content Management). En un contexto de CMS, ellos tienen socios fuertes, presencia global, son financieramente son consistentes, tienen una amplia plataforma de soporte, un buen soporte a sus clientes y dominan en una o más tecnologías o mercados verticales. Tienen la capacidad de entregar un paquete ECM completo y escalable.



��

Fig 4 - Cuadrante Mágico para ECM, 2004 �Estudios de Gartner predicen que para el año 2006 el 50% de los actuales fabricantes de ECM se habrán fusionado o habrán sido adquiridos por otros y que hacia fines de 2007 Microsoft, IBM, Oracle y SAP compartirán el 50% de las ganancias por productos ECM.

¿Cómo encontrar el CMS adecuado? [3,6,7,8] �En el mundo de los CMS, incluyendo productos comerciales y otros gratuitos y open source, no existe un producto que sea el mejor en términos absolutos. Sí encontramos una gran variedad de productos con grandes diferencias en cuanto al diseño y a sus capacidades [4]. La clave está en encontrar el producto que mejor se adapta a nuestras necesidades. Por lo tanto primero tenemos que identificar cuáles son los requerimientos de nuestro negocio. Los principales aspectos a tener en cuenta para seleccionar un CMS son: ��Costos: existen productos open-source gratuitos con buenas características y calidad, y productos

comerciales con valores que van desde mil dólares hasta varios cientos de miles de dólares. �� Infraestructura tecnológica: qué tecnologías se utilizan en la organización. ��Usabilidad: interfases aptas para ser usadas por redactores y editores de contenido ��Metadata: facilidades para definir e incorporar metadata a los contenidos. ��Reutilización de contenidos: no sólo poder publicar contenidos en diferentes destinos sino

también poder crear contenidos que contengan otros contenidos (por Ej. un artículo que contenga links e imágenes) [10]

��Repositorios para los documentos: poder elegir en qué motor de base de datos almacenar el

contenido. �� Instalación del producto: simplicidad. ��Metodología de implementación ��Versionado: manejo de versiones de los contenidos.



��Motor de búsqueda: provisión de un buscador de contenidos potente, eficiente y con muy buena performance.

��Autosuficiencia de diseño y administración: facilidades para crear y modificar el diseño para la

presentación de los contenidos. ��Autosuficiencia de desarrollo: buena documentación de las APIs de programación para

personalizar tareas de creación, administración y publicación de contenidos. ��Administración de múltiples destinos de distinto tipo. ��Características de los destinos: configuración de las propiedades más importantes de los sitios web

(por Ej. si tiene páginas con contenido configurable por el navegante, si admite registración de usuarios, etc.)

��Workflow: posibilidad de definir workflows para cada tipo de contenido con varios niveles de

aprobación. �� Integración con otros sistemas: facilidades para importar contenidos de diversas fuentes y

publicarlos en diferentes destinos y formatos.

El futuro de los CMS En los últimos años hemos observado cómo todas las tecnologías que giran alrededor de XML se han ido incorporando a casi cualquier desarrollo de software [9]. En los CMS también se puede observar esta tendencia y en general vemos cómo se utiliza XML para representar a los contenidos y XSLT para transformarlos y ajustarlos al formato de presentación deseado. Seguramente esto se convertirá en la espina dorsal de los CMS y probablemente se generen estándares de comunicación entre los distintos productos líderes del mercado que permitan la reutilización de contenidos inclusive entre distintas empresas y organismos [13,14]. Por otro lado, también nos encontraremos con interfases de carga de contenidos mucho más amigables y fácilmente integrables a los distintos programas utilizados actualmente para crear los distintos contenidos (editores gráficos, procesadores de texto, planillas de cálculo, etc.) Si bien este crecimiento será liderado seguramente por las grandes compañías, probablemente, en un área que evoluciona tan rápidamente, habrá espacio para que organizaciones más pequeñas se adapten y desarrollen más pronto lo que hoy mismo están reclamando los usuarios.��

Referencias �� !��!�� "�

��#�� $��% ��&��'��(��% ��(&��(��

�� )�&��*� ��!�+��,�%��&&&��&��-��(*� ��

�.�� /� ��' ��/��!�� 0��!�1&�2��3��%��#44#��&&&��&��5#.6��44#��

�6�� 7��1�� !��0��&&&�� &%��-��

�



8�� $�% �� !�9 ��%��!�2��:::��&%��- �&��&%��- �::��".�� ;�&5!%��

�<�� !�+�� !��%��#44#�$��&&&�� #�4=#��<6:=#�.<<6<4=#�44��

�>�� ? ��!�+�� @��%��#44#�$��&&&�� #�4A�<6:A:.<:�8A44��

�:�� B�C�$��D��$ � �!�0� ��!��#44��&&&��'��%(��#44��4��'�4�4�'�(��

��4��,�� $�% ��!�2��,��- �!�1�*��%��#44.��&&&��'��&2�� E�� ;�� D/564:44#46�

��$��"�� A�� '��F��!�+''��!��%��#44��&&&��'��%(��#44��4:��'�4�4:'#(�� ;��

��#��G�� !�C�& �,��!�2%�� #44��&&&��'��%(��#44��4.��'�4�4.�(�� ;��

��C��-��&��'��'��!�+��,�%��!�9��#44��&&&��&��%('��

��.��'�� '��!C��2�� 0��/��%��3��2��!�/��+�,��%�� &&&�� '��'�



Self-Healing Systems Mónica Silva

[email protected]

Introducción Actualmente un importante requerimiento en crecimiento de los sistemas basados en software es la habilidad de adaptarse ellos mismos en tiempo de ejecución para manejar cosas tales como variabilidad de recursos, cambios en las necesidades de los usuarios, y fallas del sistema. Esta característica de los sistemas de software es la que se da por llamar “Auto-adaptación” (Self-Adaptation), Auto-Curable (Self-Healing), Auto-Reparación (Self-Repair). El desafío de la Informática Autónoma involucra muchas áreas y se aplica en diversos niveles, todos aportan algún paso en la evolución de los sistemas autónomos. Investigaciones actuales incluyen temas como: robotics planning, sistemas de control, diseño de lenguajes de programación para adaptación, arquitectura de software, informática tolerante a fallas (fault-tolerant), y máquinas de aprendizaje.

Por qué son importantes los Self-Healing Systems? La sociedad actual crea una carga de trabajo altamente variable e impredecible sobre sistemas conectados en red, redes que a su vez interconectan sistemas distribuidos y heterogéneos. La importancia y complejidad de estos sistemas requiere cada vez más y más habilidad de profesionales de IT para instalar, configurar, operar, ajustar y mantener este tipo de sistemas. Esto nos lleva a pensar en la necesidad de una “informática autónoma”. Así como el sistema nervioso autónomo libera a la parte conciente de nuestro cerebro de la carga de lidiar con detalles vitales pero de las funciones más básicas de nuestros sistemas, la informática autónoma debería liberar a las administradores de sistemas de la mayoría de las tareas rutinarias administrativas y operativas actuales. Además en la práctica se arman grupos enormes para “sostener” cosas que en realidad muchas de las tareas que incluyen podrían ser automatizables. De ese modo las empresas podrían orientar sus capacidades de IT hacia el corazón de sus negocios, en vez de invertir cada vez más tiempo en lidiar con la complejidad de los sistemas informáticos. Irving Wladawsky-Berger bosquejo la solución en el Kennedy Consulting Summit en Noviembre del 2001: “Hay sólo una respuesta: la tecnología debe manejarse a si misma. Ahora bien, con esto no quiero decir algo lejano de proyectos de AI; lo que quiero decir es que necesitamos desarrollar el software correcto, la arquitectura correcta, los mecanismos correctos...de modo tal que en vez de que la tecnología se comporte como lo hace habitualmente en esa forma pedante y necesitando de humanos que hagan todo por ella, ésta comience a comportarse más como una computadora “inteligente” como nosotros esperamos que sea, y que comience preocupándose ella misma por sus necesidades. Si no se siente bien, entonces hace algo. Si alguien la está atacando, el sistema lo reconoce y lidia con el ataque. Si necesita más poder computacional, va y lo obtiene, y no se queda buscando asuntos humanos para alcanzarlos.” Un ejemplo sencillo y cotidiano, y no por eso menor, donde este nuevo tipo de sistemas del que estamos hablando puede comenzar aportando: los profesionales de IT terminan funcionando como “intérpretes” o traductores de lenguaje máquina a acción. Es decir, hay gente que trabaja de eso, que mira un “error code 62” y dice “ah, falta instalar el patch 413”. Es básicamente un traductor! Eso podría ser automatizable. Más aun, entonces el sistema “sabe” que le falta instalar un programa, otra tarea operativa perfectamente automatizable. Pero veamos, la automatización de la administración de recursos informáticos es a caso un nuevo problema o una nueva necesidad para la ciencia de la computación? Definitivamente, no. Por décadas, los componentes de sistema y el software han evolucionado para lidiar con la creciente complejidad del control de sistemas, recursos compartidos y administración de correcto funcionamiento. La informática autónoma es exactamente la siguiente evolución lógica de esa tendencia del pasado dirigida a entornos informáticos actuales cada vez más complejos y más distribuidos. Además de toparnos con el problema de la alta complejidad para administrar los sistemas actuales, vemos que cuando se ponen en marcha desarrollos de sistemas que cubran estos aspectos la aplicación de las técnicas actuales tornan dicho desarrollo en algo muy costoso en tiempo y en dinero. Y que aún realizando las inversiones necesarias, la aplicación de dichas técnicas suelen ser más y más complejas a medida que vamos hacia sistemas de mayor escala, llegando mucho de ello hasta ser impracticables. Parecería ser que las técnicas actuales, y la forma de encarar y desarrollar los sistemas es la que no encaja con el tipo de sistemas que esperamos. Según marca la experiencia, es una utopía pretender especificación 100% completas, que además ser imposibles de relevar, requerirían un congelamiento de las necesidades de los usuarios, lo cual es totalmente irrealista.



Por otro lado, en la actualidad es muy elevado el costo que tienen las compañías en la prevención de caídas de sistemas, en los procesos de recuperación, y en las pérdidas de “transacciones”, datos, clientes (o como sea que se mida su negocio), durante esas caídas, o como efecto colateral de la baja calidad de servicio. Todas estas cuestiones nos hablan de la necesidad de un giro sustancial en la evolución tecnológica hacia un cambio radical en el desarrollo, entrega y soporte de los sistemas de software: Eras de Oro de la Informática:

Era Mainframes � la computadora como un activo de la compañía

Era Desktops � la computadora como una herramienta personal

Era Redes � la computadora como un nodo de una grilla información / servicio mundial Era Informática Omnipresente (Ubiquitous Comupting)

� la computadora como un asistente personal Computadoras e información potencialmente en todo lados

�� Miles de elementos informáticos a nuestra disposición �� Universo heterogéneo

o Desktops, mainframes, PDA´s, etc o Aparatos inteligentes o Computadoras wearable o Censores y actuators

�� No sólo teclados: interfaces de voz / palabra / gesto �� Convergencia de comunicaciones, información e informática �� Usuarios móviles

Así, los sistemas necesitarán a) ser composiciones de partes construidas por muchas empresas, b) ejecutar continuamente, c) operar en entornos donde los recursos cambian frecuentemente, y d) ser usados por usuarios móviles. En cierto mondo se estaría forzando una redirección del esfuerzo en tiempo diseño hacia un esfuerzo en tiempo de ejecución.

Qué son los Self-Healing Systems? Centralmente lo que estaría cambiando en los sistemas es su capacidad para manejar automáticamente y en forma optimizada:

�� cambios en las necesidades de usuarios, �� recursos variables, �� fallas, �� movilidad de usuarios.

Estos serían los Self-Healing Systems. Existe una amplia variedad de puntos de vistas a cerca de la definición de self-healing systems: self-healing, self-configuring, self-optimizing, self-adaptative, self-stabilizing, self-managing, self-*, adaptative, reflective, congnitive, homeostatic, autonomic. Aunque aun no hay una definición consensuada. Intuitivamente se trata de sistemas que de alguna manera son capaces de “curarse” a si mismos, o bien, sistemas que son responsables de su propio comportamiento. Para reordenar un poco la terminología y ubicar algunos conceptos y expectativas, consideremos las cuatro características fundamentales de los futuros sistemas informáticos autónomos propuestas por Ganek en el IBM Systems Journal 2003:

�� Self-Configuring: capacidad de adaptarse automáticamente a ambiente que cambian dinámicamente. Alcanzando con esta capacidad a toda la infraestructura IT y con la mínima intervención humana posible.

�� Self-Healing: capacidad de descubrir, diagnosticar y reaccionar a interrupciones. Con el objetivo de minimizar las caídas del sistema, apuntando a disponibilidad continua.

�� Self-Optimizing: capacidad de monitorear y ajustar los recursos automáticamente. Maximizando eficientemente la utilización de los recursos para satisfacer las necesidades del usuario final sin intervención humana.

�� Self-Protecting: capacidad de anticiparse, detectar, identificar y protegerse a si mismo de ataques de cualquier origen.



Qué nuevas características se requieren en los sistemas de software para soportar self-healing?

�� Reflejo: capacidad de entender su propio estado y salud, reconocer tendencias en su propio comportamiento, precisar áreas de problema.

�� Autoadaptación: capacidad de ajustar sus propias capacidades para, elegantemente, hacer frente a cambios de recursos, necesidades de usuario, fallas de sistema, violaciones de seguridad y privacidad.

�� Conocimiento del contexto: capacidad de reconocer situaciones contextuales que puedan ayudar a identificar qué políticas y estrategias son apropiadas.

�� Task-driven: conciente de su propósito.

Consecuencias para la ingeniería de software? Desde el punto de vista de David Garlan los self-healing systems son el producto una nueva etapa en la evolución de la programación. En el pasado, los sistemas que soportaban algún tipo de auto-adaptación eran raros, típicamente asociado a dominios como switches de telecomunicaciones o software de control del espacio profundo, donde no era una opción apagar el sistema para hacerle una actualización, y donde la intervención humana no era siempre posible. Sin embargo, actualmente cada vez más sistemas tienen estos requerimientos, incluyendo sistemas de e-commerce y sistemas móviles embebidos. Estos sistemas requieren ejecutar continuamente con el mínimo descuido humano y la capacidad de hacer frente a recursos variables (ancho de banda, disponibilidad de servidores, etc.), fallas de sistema (caída de servidores y redes, fallas en componentes externos, etc.), y cambio en las prioridades de los usuarios (en un momento alta fidelidad de video streams, en otro momento baja fidelidad, etc.). La auto-reparación de los sistemas tradicionalmente ha sido manejada dentro de la aplicación, a nivel de código. Por ejemplo, típicamente las aplicaciones utilizan mecanismos genéricos como manejo de excepciones o timeouts para disparar respuestas específicas de la aplicación frente a una falla o anomalía del sistema. Este tipo de mecanismos tiene la atracción de poder atrapar el error en el momento de la detección, y están bien soportados por modernos lenguajes de programación (ej, excepciones de Java) y librerías runtime (ej, timeouts para RPC). Sin embargo, tienen el problema de ser difícil de determinar cuál es la verdadera fuente del problema, y por lo tanto que tipo de acción curativa realmente se requiere. Más aun, en tanto que pueden atrapar errores, no están bien adaptados para reconocer anomalías más “suaves”, tales como degradación de la performance sobre algún camino de comunicación, o fallas transitorias de un servidor. El espectro de propuestas de auto-adaptabilidad es amplio. Partiendo de propuestas más básicas que combinan especificaciones de adaptación con especificaciones de la aplicación, la idea es separa los asuntos concernientes a la adaptación del software de los asuntos concernientes a la funcionalidad específica de la aplicación. Así, podemos dar un paso más en esa separación con los algoritmos on-line, y luego con algoritmos genéricos o parametrizados, y luego con selección de algoritmos, hasta llegar a la programación evolutiva. Una clara separación entre adaptación del software y función del software facilita su análisis y evolución independiente. Entonces, lo que se plantea es que mientras los avances técnicos en estrechas áreas de tecnología de adaptación proveen algún beneficio, los mayores beneficios vendrán desarrollando una extensa metodología de adaptación que abarque desde la adaptación en pequeña escala hasta la adaptación en gran escala, y a partir de allí desarrollar la tecnología que soporte el rango total de adaptaciones. A continuación se muestran tres principales aspectos que los ingenieros y arquitectos de software deben replantear en la construcción de sistemas en este contexto:

Tema Tradicionalmente SHS Manejo de complejidad a través de abstracción

Mostrar propiedades o funciones ocultando detalles

(más sutil) mostrar funciones deseadas, tolerar desviaciones razonables, mostrar requerimientos de recursos que necesariamente encajen con las expectativas del usuario

Si hay errores que no se propaguen al usuario

Escribir software correcto Incluir mecanismos de monitoreo y reparación para detectar errores y arreglarlos cuando es posible

Diseñar sistemas teniendo en cuenta su evolución

Usar administración de la configuración para construir sistemas para entornos reconocibles

Soportar configuración dinámica y sintonización automática para tantos entornos diferentes como encuentre



Taxonomía de Temas Actualmente desde muchas áreas de investigación, tanto en laboratorios como en productos comerciales, se está comenzando a incluir y considerar muchos de los asuntos relacionados a sistemas autónomos. En su mayoría cada uno ataca algunas características en particular, y con procesos, técnicas e implementaciones ad-hoc. Sin bien no es la aspiración de máxima, es un camino a recorrer, y el uso y las costumbres de desarrollo con estas nuevas tendencias, todas aportarán en su medida. El siguiente es un esquema de clasificación de aspectos relacionados con los self-healing systems.

• Control Theory

• Fault tolerance y Dependability • Classical techniques

• Immunology General

• Autonomic Computing

• Networks, Distributed Systems,

Middleware • Adaptive middleware • Adaptive network protocols • Chroma and other CMU OS work • Multi-fidelity systems

• Mobile Systems • Ubiquitous Computing

• Task-oriented computing • Context-aware computing • Resource-aware computing (including energy-aware,

adaptive resource assignment, etc.) • Agent-based systems

• Biology Simulation • Biological Models: Santa Fe Institute

• User Interfaces • User Modeling • Learning by watching • Intelligent tutoring systems • Intelligent user interfaces; Attentive User Interfaces

• Collaborative Computing

Dominio de Aplicación

• Games

• Architectural models • Architecture-based Adaptation

• Algorithms/code-based • Self-stabilizing algorithms • Hot swapping • Safe mobile code

• Formal models • Coordination Languages • Formal reasoning about mobile systems

• Genetic algorithms/alternative models • AI approaches, including Neural Nets • Amorphous Computing • Multicellular Automata

• Agents

Herramientas, Mecanismos y Técnicas

• Economic theory

• Improve system performance/Resource

usage

• Improve user experience; reduce user distractions

Objetivos

• Improve dependability

En esta área es conveniente distinguir espacio de problemas de espacio de soluciones. Una taxonomía de los elementos del espacio de problemas de los sistemas self-healing es de suma utilidad ya que por un lado nos podría permitir entender qué elementos y en qué grado son cubierto (self-heal) por un determinado sistema, y por otro lado métodos, mecanismos, técnicas pueden ser descriptos por el grupo de elementos que cubre o aspira a cubrir. Una propuesta de esta taxonomía es presentada en Koopman, P. Elements of the self-healing system problem space. Workshop on Architecting Dependable Systems (WADS03), May 2003 (surgida a partir del Fisrt Workshop on Self-Healing Systems (WOSS´02)):

Elementos del modelo del espacio de problemas


91

Modelo de Falla �� Duración de la falla �� Manifestación de la falla �� Fuente de la falla �� Granularidad �� Expectativa del perfil / tipo de falla

Respuesta del Sistema �� Detección de la falla �� Degradación �� Respuesta a la falla �� Recuperación de la falla �� Constantes de tiempo �� Seguro

Completitud del sistema �� Completitud arquitectónica �� Conocimiento del diseñador �� Auto-conocimiento del sistema �� Evolución del sistema

Contexto de diseño �� Nivel de abstracción �� Homogeneidad de los componentes �� Predeterminación de comportamiento �� Compromiso del usuario en la salud (heal) �� Linealidad del sistema �� Alcance del sistema

La propuesta de IBM: Informática Autónoma Un on demand e-business es un empresa cuyo proceso de negocio – integrado de punta a punta a lo largo de todo la compañía y con los socios clave, los proveedores y los clientes – puede responder con agilidad y velocidad cualquier demanda del cliente, oportunidad del mercado, o amenaza externa. Para lograr los beneficios del on demand e-business los clientes necesitarán abrazar una nueva arquitectura que les permitirá ir más allá de los límites tradicionales de la compañía. Este contexto operativo on demand tiene cuatro características esenciales: integrado, abierto, virtual y autónomo. La informática autónoma fue concebida como una forma de ayudar a reducir el costo y la complejidad de poseer y operar un infraestructura de IT. En un contexto autónomo, los componentes de sistemas – desde el hardware como las PC´s y los mainframes, hasta el software como sistema operativo y aplicaciones de negocio – tiene las cuatro características fundamentales del self-managing: self-configuring, self-healing, self-optimizing y self-protecting, también llamadas “características self-CHOP”. Estos atributos de self-managing son la base del entorno de la informática autónoma. Ellos sugieren que las tareas involucradas en configurar, curar, optimizar y proteger el sistema IT son iniciadas debido a situaciones que las tecnologías detectan, y que a su vez esas tareas son llevadas a cabo por esas mismas tecnologías. Conjuntamente, estas características intuitivas y colaborativas permiten a la empresa operar eficientemente con pocos recursos humanos, mientras baja el costo y se incrementa la habilidad de la organización para reaccionar al cambio. Es importante tener en mente que los atributos self-CHOP no son independientes uno de otro. Específicamente, los cuatro atributos a la vez permiten la habilidad de hacer cambios a la configuración de uno o más aspectos del sistema IT. La motivación para el cambio de configuración es diferente para cada uno de los atributos. La arquitectura de la informática autónoma se basa en la premisa de que implementar los atributos self-managing involucra un control loop (“ciclo de control”) inteligente. Este ciclo recolecta información del sistema, la analiza, toma decisiones y realiza los ajustes necesarios en el sistema. La arquitectura organiza los control loops en dos elementos principales: el elemento administrado, y el administrador autónomo. El elemento administrado es lo que el administrador autónomo está controlando. El administrador autónomo es un componente que implementa un control loop en particular. Este control loop está definido por la arquitectura de referencia de informática autónoma,

como lo muestra el gráfico de la derecha.

En una arquitectura de informática autónoma,

los control loops facilitan la administración del sistema

Estos control loops pueden ser aplicados en diferentes formas como lo muestra el siguiente diagrama:

�


TTADA 2004 Página 92 de 92

♦ Un loop puede estar implementado por la combinación de varios productos y herramientas de administración. En el diagrama serían el administrador de configuración, el administrador de balanceo de carga y el administrador de riesgo.

♦ Un control loop puede ser suministrado por un proveedor de recurso, el cual embebe un loop en su entorno de ejecución de un recurso en particular

Los control lopp se pueden presentar en dos formas: como herramientas de administración o embebidos en recursos del sistema La utilización de estas combinaciones permite explotar al máximo el potencial de la arquitectura de informática autónoma que la compañía configure.

Una evolución, no una revolución: niveles de madurez y sofisticación de la administración La incorporación de las capacidades de autonomía en un contexto informático es un proceso evolutivo logrado a través de la tecnología – pero esto es en última instancia implementado por cada empresa a través de la adopción de esas tecnologías, procesos de soporte y conocimientos. A lo largo de la evolución, la industria continuará entregando herramientas de self-management para mejorar la productividad de los profesionales IT. Para entender el nivel de sofisticación de las herramientas y capacidades que son, y serán, entregadas por la industria, consideramos los siguientes cinco niveles de madurez de autonomía:

La evolución de la autonomía aparece gradualmente a lo largo de las cinco fases

♦ En el Nivel Básico, los profesionales IT administran cada elemento de la infraestructura independientemente y lo configuran, lo monitorean y ocasionalmente lo reemplazan.

♦ En el Nivel Administrado, las tecnologías de administración de sistemas pueden ser utilizadas para recolectar información de sistemas dispersos en unas pocas consolas, ayudando a reducir el tiempo que le toma al administrador recolectar y sintetizar esa información, a medida que el entorno IT se vuelve cada vez más complejo.

♦ En el Nivel Predecible, nuevas tecnologías se introducen para proveer correlación a lo largo de varios elementos de la infraestructura. Esos elementos pueden comenzar a reconocer patrones, predecir la configuración óptima y proveer aviso sobre qué curso de acción debería tomar el administrador.

♦ En el Nivel Adaptativo, el contexto IT puede automáticamente tomar acciones basado en la información disponible y el conocimiento de qué está sucediendo en el ambiente. A medida que estas tecnologías



mejoran y que la gente se va sintiendo más cómoda con los avisos y el poder de predicción de estos sistemas, las tecnologías pueden progresar hacia el nivel adaptativo.

♦ En el Nivel Autónomo, las políticas y los objetivos de negocio gobiernan la operatoria de la infraestructura IT. Los usuarios interactúan con la herramientas de tecnología autónoma para monitorear los procesos de negocio, alterar los objetivos, o ambos.

Cómo evoluciona la tecnología para soportar informática autónoma? Los niveles de madurez de autonomía demuestran que las capacidades self-managing no se pueden incorporar de a un solo paso rápido. Por el contrario, constituyen un concepto que se impregna en todos los aspectos de un sistema. La siguiente figura refuerza esta observación mostrando una posible relación entre los niveles de madurez, los tres contextos de toma de decisiones (recurso, composición de recursos y solución de negocio), y las partes del administrador de autonomía:

Progresando a lo largo de los cinco niveles de madurez de autonomía, los negocios pueden evolucionar su entorno IT hacia niveles completamente autónomos Esta relación nos lleva a dos observaciones interesantes. En primer lugar, a media que aumenta el nivel de madurez, va cambiando el contexto de toma de decisiones del administrador de autonomía. En segundo lugar, las diferentes partes del administrador de autonomía se implementan en cada nivel de madurez. Las partes de ejecución y monitoreo se implementan en los niveles básico y administrado. De ese modo, en estos dos niveles los profesionales IT son responsable de realizar las funciones de las partes de análisis y planificación. La parte de análisis del administrador de autonomía es provista en el nivel de madurez predecible. En este nivel, los profesionales de IT son responsables de la función de planificación. En el nivel adaptativo y autónomo, todas las partes del administrador de autonomía están funcionando de modo que los profesionales de IT pueden delegar el trabajo al sistema. La diferencia entre esto niveles de madurez está en el contexto de toma de decisiones. El nivel de madurez adaptativo soporta el contexto del recurso en si mismo o el contexto de las composiciones de recursos, y el nivel autónomo soporta el contexto de las soluciones de negocio.

Propuesta desde la Biología Un enfoque que parte de fundamentos completamente distinto a los expuestos en los puntos anteriores, es el que surge inspirado desde la biología. Es decir, partiendo de conocimientos acerca de elementos del mundo biológico



intentar hallar los modelos, técnicas y mecanismos que indiquen cómo mantener la “salud”, protegerse, conocer el entorno, adaptarse, reparase. La biología está repleta de ejemplos de sistemas con notable robustez y propiedades self-healing. Eso incluye:

Morphogenesis: un célula sola se transforma en un organismo completo siguiendo un programa codificado en sus ADN que evoluciona en miles de millones de años. Heridas curables: casi todos los organismos complejos tiene algún tipo de mecanismo para curar heridas simples. Regeneración: muchos organismos pueden regenerar nuevas cabezas, miembros, órganos enteros u otros partes de del cuerpos si los originales se pierden o se dañan.

Se puede observa también que los métodos de la naturaleza para programar tienen las siguientes propiedades interesantes:

Conciencia ambiental: aunque las células tiene capacidad limitada de comunicación, ellas reaccionan en forma diferente en respuesta a características detectadas del ambiente circundante. Adaptación: muchas células tiene una gran capacidad de adaptabilidad. Redundancia: los organismos típicamente tienen muchas células dedicadas a la misma función a lo largo del desarrollo, de modo tal que fallas en células individuales no tienen consecuencias sobre le sistema. Descentralización: no hay una coordinación global, y hay una comunicación limitada para la mayoría del proceso de desarrollo. El control se realiza localmente afectado por el comportamiento de las células vecinas.

Otra propuesta: Homeostasis Esta propuesta se basa en la idea de relajar precisión y completitud de conocimiento, produciendo mayor elasticidad para los cambios del entorno. Para muchos sistemas en la práctica, la “salud” se corresponde con asegurar en forma razonable que el sistema trabajará suficientemente bien respecto del propósito para el que fue desarrollado.

Suficiente corrección: el grado en el cual un sistema debe ser dependable con el fin de servir para el propósito que su usuario piensa, y para hacerlo lo suficientemente bien para satisfacer las necesidades actuales y las expectativas de dichos usuarios.

Así los sistemas self-healing deberían perseguir el objetivo de ser suficientemente buenos para la tarea que están manejando. Homeostasis es la propensión de un sistema a resistir automáticamente al cambio de su estado normal, o deseado, o de equilibrio cuando el contexto externo ejerce fuerzas para conducirlo de ese estado. Software homeostasis como una propiedad de un sistema de software se refiere a la capacidad del sistema para mantener su estado de operación normal, o la mejor aproximación posible a ese estado, como resultado de su operación normal. Esa operación debería tanto mantener un buena operación normal, como así también implícitamente reparar anormalidades, o desviaciones del comportamiento esperado. Autor de referencia: Mary Shaw.

Propuestas Self-Healing basadas en Arquitecturas Retomemos la idea planteada al comienzo sobre la necesidad de desarrollar una extensa metodología de adaptación que abarque desde la adaptación en pequeña escala hasta la adaptación en gran escala, y a partir de allí desarrollar la tecnología que soporte el rango total de adaptaciones. A continuación de se muestran dos propuestas basadas en arquitecturas.

“An Architecture-Based Approach to Self-Adaptive Software”



Oreizy y otros en “An Architecture-Based Approach to Self-Adaptive Software.”abordan este tema de lleno y proponen un proceso de alto nivel en un método de propósito general para sistemas de software auto-adaptables (self-adaptative). La siguiente figura muestra el proceso. Además de proponer el método general, los autores proponen métodos, técnicas y herramientas actuales existentes, en desarrollo o en etapa de investigación, para cada etapa del proceso. Es decir, que no se quedan en un modelo meramente teórico sino que incluyen en la propuesta elementos prácticos, claro que no masivamente probados. Si bien cada aspecto del método propuesto ha sido el foco de muchas investigaciones, lo novedoso es la integración de todos estos aspectos en una metodología de software auto-adaptativo conjunta.

“Increasing System Dependability through Architecture-based Self-repair” Por otro lado una técnica en importante crecimiento para mejorar la cualidad dependability de los sistemas es proveer al sistema en tiempo de ejecución de mecanismos para adaptarse para que se acomode a variabilidad de recursos, errores del sistema y requerimientos cambiantes. Para tales sistemas auto-reparables (self-repairing) uno de los problemas más difíciles es determinar cuándo es necesario un cambio, y conocer qué tipo de adaptación se requiere. Garlan y otros en “Increasing System Dependability through Architecture-based Self-repair” describen una solución parcial en la cual en tiempo de ejecución se mantienen modelos de diseño arquitectónicos estilizados (stylized) como un vehículo para monitorear el comportamiento del sistema automáticamente , para detectar cuándo el comportamiento del sistema cae más allá de cierto rango aceptable, y para decidir un estrategia de reparación de alto nivel. La siguiente figura muestra el marco de adaptación propuesto:

La principal característica innovadora de esta propuesta es la capacidad de especializar un marco runtime de adaptación genérico para soportar estilos arquitectónicos y características particulares de interés. Específicamente, una descripción formal de un estilo arquitectónico define para una familia de sistemas relacionados las condiciones bajo las cuales la adaptación debe ser considerada, provee una base analítica para detectar anomalías, y sirve como una base para desarrollar estrategias de reparación acordes.



El método propuesto se plantea enfocado principalmente en el rol de los estilo de arquitecturas para interpretar comportamientos del sistema, identificar problemas, y sugerir curas. Se describen muy comprensiblemente cada parte de la propuesta. Además los autores van un paso más allá, y llevaron adelante una prueba a modo de ejemplo para describir de punta a punta cómo cada elemento del marco de adaptación propuesto funciona conjuntamente para lograr la adaptación en tiempo de ejecución. El ejemplo cubre una importante clase de sistemas web-based client-server, se trata de un simple balanceo de carga de un sistema web-based client-server, basado en el monitoreo del comportamiento relacionado a la performance. Acá también se aplican métodos, herramientas y estándares existentes en cada elemento para armar la aplicación final. El experimento incluye gráficos de comparación de comportamiento del sistema con y sin reparación:

Así mismo los autores plantean algunos aspecto interesante para investigar, profundizar, y/o mejorar:

♦ Es siempre posible mapear reparaciones de la arquitectura con correspondientes cambios en el sistema? ♦ Es siempre posible monitorear información run time relevante? ♦ Es razonable esperar que las técnicas de análisis puedan manejar un conjunto suficientemente amplio de

aspectos para informarnos estrategias de reparación? ♦ Desarrollar mecanismos que provean una adaptabilidad más ricas a los sistemas que se están ejecutando. ♦ Nuevas capacidades de monitoreo, e infraestructura reutilizable para relacionar valores monitoreados

con las arquitecturas. ♦ Nuevos métodos analíticos para arquitectura que nos permitan especificar los principios de las políticas

de adaptación. ♦ Investigar mecanismos de políticas de reparación más inteligentes. ♦ Link entre arquitecturas y requerimientos. ♦ Adaptaciones del sistema necesarias a raíz de cambios en las necesidades del usuario. ♦ Desarrollo de instancias concretas de la propuesta para algunos de los marcos arquitectónicos habituales,

ej. EJB, Jini, y CORBA.

Casos prácticos de la industria IT

Introducción Esta sección es el resultado de la búsqueda de aplicaciones (utilización) de los conceptos de self-healing systems presentados en los primeros apartados de este informe.



La búsqueda comenzó dentro de Microsoft. Luego quedó muy asociada a IBM y partners debido a la utilización del término “autonomic” como patrón de búsqueda. Y luego utilizando referencias así adquiridas, y búsqueda de términos en conjunción con J2EE se completó esta etapa. A continuación se presenta una descripción muy general del material hallado, resaltando algunos puntos relevantes. Incluyendo también algunos comentarios y conclusiones arribados realizando estas búsquedas. De todo el material encontrado se extrajeron algunas partes de notas y sitios que se incluyen textualmente en la última sección “Error! Reference source not found.”. Algunos son breves y otros no tanto, lo cual ha sido intencional ya que considero que algunos podrían aportar mayor claridad que un resumen, como así también exponer más claridad y detalle sobre los diferentes temas asociados. En la presentación detallada de los resultados obtenidos no se respetó el orden en que fueron encontrados sino el siguiente: primero casos varios extraídos de artículos de revistas y sitios de información de informática y tecnología a fin de presentar inicialmente un abanico más amplio y menos tendencioso; en segundo lugar se presentan los casos Microsoft – sólo algunos a modo de ejemplo-; y por último los casos IBM. En general, todos ellos contienen una referencia temporal de publicación, e incluyen un link al sitio de donde fue extraído el material.

Descripción general El tema self-healing systems e informática autónoma ha evolucionado mucho desde su surgimiento, digamos año 2001 aproximadamente, hasta hoy. Incluso hoy en día sigue siendo un tema abierto y cada vez con más variantes. Pero es cierto que desde aquel tema lleno de propuestas y buenas intenciones a hoy hay más puestas en práctica. En la búsqueda de casos de estudio surgieron principal y mayoritariamente herramientas de soporte para la administración de recursos el área IT. Si bien esta no fue la intención, y se trató de desviar la búsqueda, es natural encontrarse con esto ya que es allí donde se focalizó la atención del área: “si queremos menos skill para administrar los recursos contemos con herramientas más poderosas e inteligentes que monitoreen, sugieran o hagan lo que nuestros operadores deberían hacer”. Si miramos la taxonomía presentada en las primeras secciones de este informe, cabe pensar que estos casos caen dentro de los temas coloreados con azul, y tal vez se aproximen a los coloreados en un color más claro:

• Control Theory

• Fault tolerance y Dependability

• Immunology General

• Autonomic Computing

• Networks, Distributed Systems

• Mobile Systems

• Ubiquitous Computing

• Biology Simulation

• User Interfaces

• Collaborative Computing

Dominio de Aplicación

• Games

• Architectural models

• Algorithms/code-based

• Formal models

• Genetic algorithms/alternative models

• Agents

Herramientas, Mecanismos y Técnicas

• Economic theory

• Improve system performance/Resource usage

• Improve user experience; reduce user distractions Objetivos • Improve dependability



Más que posiblemente existan casos sobre los temas no coloreados, pero en principio no surgieron en esta búsqueda. Sobre Ubiquitous Computing existe mucho material, basta hojear en los workshops internacionales del tema (ver “Error! Reference source not found.”). Biology Simulation, Genetic algorithms / alternative models particularmente resultan muy interesantes, no se incluyen ya que están fuera del alcance de los temas de interés de la materia del contexto de este informe (para más información ver “Error! Reference source not found.”). Retomando el material encontrado, estas herramientas tiene distintas formas de presentación. Algunas son propuestas de lenguajes estándares a usar para publicar o leer información de estados cambiantes. Otras son modelos de desarrollo, de armado de arquitecturas y orquestación de toda la infraestructura IT, generalmente acompañados de módulos o paquetes de software que refieren a cierta parte de la salud, o monitoreo, o facilidad de administración, o análisis, o balanceo de carga, incluso varios de ellos adaptados para varias de las tecnologías actualmente más comunes. En este tipo de herramientas IBM parece haber sido el precursor del tema ya que es notoria la claridad y distinción detallada de los aspectos de autonomía que cubre cada una de sus herramientas. También, es notorio que cada vez más varias empresas y tecnologías se encuentran en proyectos aliados con IBM implementando en sus productos estos conceptos. Particularmente IBM ofrece un toolkit de informática autónoma, un conjunto de herramientas que cubren los distintos aspectos y partes de la autonomía de distintas herramientas y recursos, como servidores, bases de datos, SO, etc. Además algunos de estos componentes o estándares vienen incluidos en algunos de sus productos. Por su lado Microsoft, si bien no expone documentación sobre teorías, estudios o fundamentos del por qué sistemas autónomos o self-*, menciona y asigna todas estas cualidades y beneficios en casi todas sus herramientas actuales. Incluso el framework .NET parecería ser la base que reúne y sustenta todos estos conceptos ahora y en el futuro. En lo que refiere a la competencia y diferencia de visión entre IBM y Microsoft sobre el tema rescatamos el siguiente comentario extraído de un artículo:

IBM’s Barel said that the biggest difference between IBM and its competitors is the “breadth of how we’re approaching it. The value of autonomics is greatest when you can provide autonomic behavior across the entire infrastructure. With Microsoft, it’s about a new way to build apps from [the] start to instrument them for better self-management behavior. With IBM, it’s about an evolution to infrastructure from what companies have in place. We let people evolve the infrastructure and introduce autonomics one at a time.”

Y esto que menciona Barel pareciera notarse bastante en los casos encontrados de cada uno.

Casos varios Self-healing systems – ADTmag.com

By Colleen Frye, ADTmag.com September, 2003 Propuestas de “Autonomic computing” de diferentes empresas: IBM has rolled out its “Autonomic Blueprint” and “on-demand” initiative. Microsoft announced its Dynamic Systems Initiative (DSI). Sun Microsystems has a detailed plan for its N1 technologies and utility computing. And Hewlett-Packard (HP) has its Adaptive Enterprise strategy. The plans encompass both hardware and software, outsourcing and in-sourcing. Large systems management vendors like Candle, Computer Associates and others, are laying out strategies for how they will support these plans. Herramientas para desarrollo de sistemas autónomos de IBM:

��

��

��

��

!�� "��#� �� $� �� %��

�� &��'�� ( �� (��

�� !�� )��



��* ��+��

�� Self-Healing IBM vs Microsoft IBM’s Barel said that the biggest difference between IBM and its competitors is the “breadth of how we’re approaching it. The value of autonomics is greatest when you can provide autonomic behavior across the entire infrastructure. With Microsoft, it’s about a new way to build apps from [the] start to instrument them for better self-management behavior. With IBM, it’s about an evolution to infrastructure from what companies have in place. We let people evolve the infrastructure and introduce autonomics one at a time.” Propuestas de Microsoft For its part, Microsoft has also laid out a blueprint. Microsoft’s Dynamic Systems Initiative (DSI) is said to unify hardware, software and service vendors around a software architecture that centers on the System Definition Model (SDM). The SDM is said to provide a common contract between development, deployment and operations across the IT life cycle. SDM is a live XML-based blueprint that captures and unifies the operational requirements of applications with data center policies. Windows Server 2003 is the first step toward delivering on this initiative. Future releases of Visual Studio, Microsoft server applications and management solutions will also support SDM. Windows Server 2003 capabilities include the following: * Automated Deployment Services (ADS) -- a provisioning and administration tool; * Windows System Resource Manager -- dynamic systems resource management; * Volume Shadow Copy Services and Virtual Disk Service -- storage virtualization; * Network Load Balancing -- dynamic load-balancing for incoming traffic; * Windows Server Clustering -- high-availability and scalable services; and * Virtual Server -- machine technology for consolidation and migration. One area where Microsoft and IBM differ in their approach is what Microsoft calls “the root of the problem.” Said a Microsoft spokesperson: “Fundamentally, these systems cannot become more intelligent until both the applications and the OS are developed with operations in mind. Management has been, and IBM continues to push it as, an afterthought to application and system design. It has to be baked in from the inception of an application.” Microsoft has been working closely with Hewlett-Packard on DSI, and in May debuted a joint development effort: the Dynamic Data Center (DDC). The DDC features a combination of HP servers, software, storage and networking hardware that are connected based on a prescribed network architecture. Microsoft software dynamically assigns, provisions and centrally manages the DDC resources. “It is fair to categorize the work HP has done with Microsoft around the DDC as investments that intersect with and enable them to realize their Adaptive Enterprise strategy,” commented the Microsoft spokesperson. “As HP’s Adaptive Enterprise strategy matures, we will be able to talk more about how our joint collaboration relates to this strategy.” Microsoft has also been working with other vendors, including IBM. IBM has been doing work with its xSeries around Microsoft’s ADS tool and the SDM. Propuesta de HP Launched in May, HP’s Adaptive Enterprise strategy also focuses on more closely linking business and IT. As part of the initiative, HP announced new Adaptive Enterprise services, including a set of business agility metrics, and new methodologies for designing and deploying application and network architectures to support constantly changing business needs. Also announced was software for virtualizing server environments and new self-healing solutions for HP OpenView. Hewlett-Packard’s Darwin Reference Architecture is a framework for creating a business process-focused IT that dynamically changes with business needs, and has upgraded HP ProLiant blade servers. Propuesta de Sun Microsystems Inc. Sun Microsystems Inc., Santa Clara, Calif., has also laid out its plans for both a more dynamic data center and utility computing. Sun’s N1 architecture comprises foundation resources, virtualization, provisioning, and policy and automation. Foundation resources are the various IT components already in place. Virtualization allows for the pooling of those resources. Provisioning maps business services onto the pooled resources, and policy and automation enable a customer to create rule-defining performance objectives for a given service. Based on set policies, N1 will manage the environment, adding and removing resources as needed to maintain service-level objectives. A��&��8�� "�!��8�� H�I��D��*�� $ �"��H�� J:��* H �� $��$ ��"�� *$ ��"�$ ��#� #�� "��(��$��*� ��"*� �� !��"�� $�� K�

Product OpalisRobot - 2004

OpalisRobot Today, IT departments must take a pragmatic approach to increasing productivity and managing costs - the mandate is to optimize processes and gain the benefits originally promised from technology investments. To achieve these goals, many IT departments are looking at automation solutions that do not require rip and replace strategies or intensive change in corporate procedures.



A��"��9:�� $ �� :$�� $ �� "�� #�$ ��$ ��$��"�� (� �� "�� <��C�� $�� *��*�$�� ""�� $ � �� "��9:��

OpalisRobot’s robust automation engine ensures consistent and repeatable performance by delivering the tools to implement formalized procedures that capture, model, and execute IT activities. It orchestrates IT processes through the use of workflow, conditional logic, event based scheduling, and other features such as integration between popular system management tools, email, databases, logs, file systems, and native operating system functions. OpalisRobot's workflow environment provides a large library of configurable objects to drag-drop-and-link, enabling rapid construction and deployment of automated processes. Customers report reduced costs of transactions and improved coordination of activities. Once processes have been automated, organizations are also able to reduce the number of users needed to complete a transaction, freeing up valuable IT resources to focus on more strategic projects. Automation and Integration Benefits

♦ Facilitate IT & business process efficiency ♦ Increase IT & business process quality ♦ Reduce operating costs ♦ Reduce time for process completion

Related Pages OpalisRobot Connector Access Packs (CAPs) extend OpalisRobot with application specific objects and workflows.

♦ OpalisRobot CAP for MOM ♦ OpalisRobot CAP for SMS ♦ OpalisRobot CAP for Veritas Backup Exec ♦ OpalisRobot CAP for Remedy HelpDesk ♦ OpalisRobot CAP for VMware

♦ Maintenance Procedure Automation ♦ Data and File Automation ♦ Business Intelligence Automation

Case Studies More and more companies are deciding to use Opalis to drive their automated IT-based business processes. On this page you'll find case studies on how Opalis products are used throughout the world.

HP OpenView self-healing services – September 2004

A smarter solution that saves time and money! Giving customers choices for faster resolution by providing solution information automatically Self-Healing Services helps enable faster problem resolution by providing customers with potential solutions to OpenView application fault. It engages customers with automatic notification when faults occur, facilitate customer access to fault analysis reports generated through automated decision systems, and optionally allow customers to request additional support assistance for a fault via electronic case logging, routing, and tracking. Self-Healing Services allow HP Support engineers to address support issues faster by automatically collecting system and application data needed to begin troubleshooting an OpenView application problem. Support engineers have immediate access to this data and the customer’s incident report if the customer decides to open a support case via the Self-Healing interface. When requested, customers can easily send additional data files through the self-healing infrastructure. HP is delivering on its promises HP is driving customer time-saving services into the most customer-visible phase of the software lifecycle. With the HP OpenView Self-Healing services, HP is delivering on its promises to personalize the customer experience and enable proactive management. Supported products and platforms The current version of Self-Healing services (version 1.30) supports HP OpenView Network Node Manager, OpenView Operations-Unix, OpenView Operations-Windows, Service Desk/Windows, and OVPA. Supported platforms are HP-UX 11.x, Solaris 2.6 - 2.9, and Windows XP, NT, and 2000.



Application Performance Solutions for Web-J2EE

VERITAS i³™ for Web-J2EE VERITAS i³ for Web-J2EE provides a complete application performance management solution for web-based applications anchored by J2EE application servers. The integrated solution allows IT managers to quickly isolate poor performing web pages and transactions then correlate them with the appropriate J2EE methods. This ensures that IT managers focus on the definitive root cause of the problem - not the symptoms. Web-based applications continue to play a key role for all businesses. When performance problems begin to impact end-users, IT managers need detailed information. It's not enough to know there is a problem - IT managers need to know where the problem is and how to fix it. The performance data collected from the web client, web server, and J2EE tier is comprehensive but does not introduce overhead. The VERITAS i3 for Web-J2EE solution is designed to be run in a production environment. Benefits

♦ Ensures web-based application presentation layer is optimized ♦ Validates the web server / J2EE application design & architecture ♦ Provides visibility in context as transactions move from web to J2EE tier ♦ Follow transaction performance from the J2EE tier into the database ♦ Part of VERITAS i3 end-to-end performance management solution

Application Performance Solutions for SAP

VERITAS i³™ for SAP enables you to guarantee the performance of SAP Applications VERITAS i³ delivers a proven Application Performance Management solution that continuously collects high-quality metrics from each supporting tier of the SAP infrastructure (web server, application server, database and storage) and correlates these metrics to build a clear picture of SAP performance from the end-user perspective—response time. VERITAS i³ cuts through organization and technology barriers to detect and correct the root cause of application slowdowns. The VERITAS i³ solution also ensures application performance manageability and maximizes your ROI in the deployment of mySAP modules. The Benefits

♦ Optimize end-user response time; improve overall Quality of Service ♦ Reduce "roll-out" time of your SAP upgrade projects ♦ Eliminate "blamestorming" through the use of breakthrough TotalCorrelation technology ♦ Find the definitive root cause of performance degradation in minutes ♦ Resolve problems faster using the expert advice of SmarTune™

Casos Microsoft Windows 2000 Professional: Most Reliable Windows Ever

Protects Against User Error In the past, if a user incorrectly installed or removed an application, or accidentally changed one of the application files, he or she could cause a system failure. In Windows 2000, when a user makes this type of mistake, applications can repair themselves. Microsoft calls this ability "self healing applications." Self-healing applications are made possible by the Microsoft Installer technology. With the Installer, if installing or deleting an application—or even a part of an application—causes a problem, the operating system fixes it. For example, if a newly installed application has a dynamic-link library (DLL) with a name identical to another application's DLL, the Installer knows to store the two files in different folders. To further ensure that applications work correctly with Windows, Microsoft joined forces with business customers and independent software vendors (ISVs) to create an application certification program. To be certified, an application must meet technical reliability criteria, such as minimizing DLL conflicts, providing self-repairing installation, and maintaining user settings.

10 Firsts of Microsoft SQL Server

First to provide a self-configuring, self-managing, self-healing, enterprise quality database Collaborating with customers and industry partners, SQL Server pioneered the first self-configuring, self-managing, self-healing database. Consistent customer feedback was that databases, overall, were hard to manage, maintain and required extensive IT investment for both people and processes. To help alleviate the burden on IT and to help lower the overall management costs of data management products, Microsoft innovated a new way to have the database perform self-



optimization, self-configuration and also self-healing. SQL Server can grow and shrink the database automatically. SQL Server can also self-optimize and self-manage through query optimization, automatic memory configuration, automatic processor utilization/thresholds and by providing innovative wizards to help administrators perform the routine tasks that normally drive up the cost of data management. Other products still rely on administrators tweaking knobs and pushing buttons to configure the database. Microsoft believes that having a self-configuring database that can adjust automatically to changes in the database’s operating environment such as memory constraints, network bandwidth, and processor utilization, provides the best benefit to the customer with regards to performance, cost savings, and the ability for administrators to provide higher-value services rather than low-level tweaking of the data management platform. Click to view some of the innovations in self-management that SQL Server provides such as the Index Tuning Wizard, auto-management interfaces, and query optimization. Read how Pennzoil leveraged the self-tuning and management innovations of SQL Server to lower their costs and boost their productivity at http://www.microsoft.com/resources/casestudies/CaseStudy.asp?CaseStudyID=11220.

Airespace – empresa perteneciente al Microsoft Partner Solutions Center -

Company Overview Airespace is a market leader in the design and development of intelligent wireless networking platforms that support business-critical applications. The Airespace Wireless Enterprise Platform makes WLAN deployment and management simple and cost effective, while providing seamless integration with existing business networks. Airespace has revolutionized the WLAN industry with its AireWave Director™ Software, which provides dynamic RF intelligence for network optimization, airtight security, seamless mobility, and support for real-time applications, such as voice. With AireWave Director Software, wireless networks are self-configuring, self-optimizing, and self-healing. As a result, Airespace has become the wireless platform of choice for hospitals, universities, and Fortune 100 companies who want to put their air space to work.

Microsoft .NET Framework Developer Center

Features Overview The .NET Framework 1.1 is an integral Microsoft Windows® component for building and running the next generation of software applications and Extensible Markup Language (XML) Web services—components that facilitate integration by sharing data and functionality over the network through standard, platform-independent protocols such as XML, SOAP, and HTTP. The .NET Framework provides:

♦ A highly productive, standards-based environment for integrating existing investments with next-generation applications and services.

♦ The agility to solve the challenges of deployment and operation of enterprise-scale applications. The .NET Framework consists of two main parts: the common language runtime (CLR) and a unified set of class libraries, including ASP.NET for Web applications and Web services, Windows Forms for smart client applications, and ADO.NET for loosely coupled data access. Improved Operations Improve Performance The .NET Framework improves the performance of typical Web applications. ASP.NET

includes advanced compilation and caching features that can improve performance dramatically over existing Active Server Pages (ASP) applications. Simplify Application Deployment With .NET Framework metadata technology, installing applications is as easy as

copying them into a directory. Side-by-side execution helps to eliminate "DLL hell" and other potential versioning conflicts. Smart client applications may even be deployed to client desktops in the same manner as Web applications, through remote Web servers, with No-Touch Deployment. The .NET Framework is capable of self-healing when applications are damaged, and applications can be upgraded while they are running. Run More Reliable Applications The .NET Framework includes technologies to make applications more reliable. For

example, memory, threads, and processes are managed by the .NET Framework to ensure that memory leaks don't occur. And ASP.NET monitors running Web applications and can automatically restart them at administrator-defined intervals. Be Confident with Code Access and Role-based Security The .NET Framework security system provides fine-

grained, method-level control over what applications can and can't do based on who wrote the code, the purpose of the code, where it was installed from, and who is trying to run it.



Casos IBM Autonomic Computing Toolkit

IBM issues toolbox for autonomy Autonomic toolkit covers management, problem determination By Gillian Law, IDG News Service February 20, 2004 IBM launched the Autonomic Computing Toolkit to help developers build autonomic elements into their systems last week. Based on the Eclipse open source framework, the toolkit contains embeddable components, tools, usage scenarios, and documentation, IBM said. The components cover four key areas. The Autonomic Management Engine monitors the application, identifies any problems, and decides what should be done to correct them, while the Integrated Solutions Console allows a company's IT administration to be monitored and run centrally over a Web-based infrastructure. The Solution Installation and deployment technologies are core to autonomic computing, spotting interdependencies between applications to reduce installation and configuration problems. The fourth component group, Problem Determination technologies, includes features designed to speed up analysis of the root cause of problems. There is, as yet, no standard for self-healing technology, as the area is still developing, and this means that companies such as IBM and Microsoft are developing in very different directions, said IDC analyst Chris Ingle. Microsoft, for instance, aims to develop self-healing, autonomic computing within its Visual Studio. "There needs to be some unification, as everyone's releasing different things. There are groups trying to establish standards, but it's what gets deployed first that becomes the standard," Ingle said.

An autonomic computing roadmap

Nicholas Chase, President, Chase & Chase, Inc.17 Feb 2004, Updated 21 Oct 2004 Cutting through the hype The tools within the Autonomic Computing Toolkit (see Resources) are the first steps toward bringing to you an architecture that enables system components to not only think, but also to converse with each other in order to think better. An autonomic computing architecture consists of several core capabilities:

• Solution installation and deployment technologies • Integrated Solutions Console • Problem determination • Autonomic management • Provisioning and orchestration • Complex analysis • Policy-based management • Heterogeneous workload management

I'll discuss each of these goals, and show you how you can start working towards them. Problem determination Now, the whole idea of an autonomic computing architecture is to create a system that's self-configuring, self-healing, self-optimizing, and self-protecting. In order to do that, the system needs to be able to recognize problems, determine their cause, and take the appropriate action to correct the problem. The most logical way to do that would be through the use of logs. If you're an application developer, you know what logs are typically used for: tracking back to a problem if the user finds one. Most of the time, they're not meant for general consumption. In fact, in many cases, application logs are meant for just one person -- the application developer. The application developer knows that if the system is shutting down unexpectedly, he or she is looking for an event that says "unexpected termination." Or is it "unexpected quit"? Or "Help! The monkey's running loose with a pointed stick!" The point is that in order for an automated system to be able to use log files in determining a problem, logs must have a common format. That format is the Common Base Events format, an XML-based vocabulary. Common Base Event V1.0.1 defines eleven situation categories -- StartSituation, StopSituation, ConnectSituation, ConfigureSituation, RequestSituation, FeatureSituation, DependencySituation, CreateSituation, DestroySituation, ReportSituation, AvailableSituation -- and provides an OtherSituation category to support product specific requirements. If an application outputs events in this format, an autonomic computing system can use that information to determine when and if there's a problem and what to do about it by correlating events into situations. For example, one possible (and highly simplified) situation could be: Listing 1. Simplified example Application server can't connect to the database



+ Application server can ping database server machine = Database is down The system can then consult a symptom database to determine that if the database is down, it should attempt to restart it and notify an administrator that a problem has occurred. (The symptom database can also play a part in correlating events to situations.) But what if you already have an application and it doesn't output events in Common Base Events format? Does that mean you can't integrate it into an autonomic computing system? In this case, you have two choices: you can either change the application, or you can use the Generic Log Adapter, which converts legacy-based events into the Common Base Events format. The Adapter Configuration Editor tool, part of the Autonomic Computing Toolkit, integrates with WebSphere Studio Application Developer or the Eclipse platform and enables you to create rules the Generic Log Adapter can use to convert your logs to the format that an autonomic computing system can understand. The Autonomic Computing Toolkit also includes another Eclipse-based tool, the Log and Trace Analyzer. This tool provides a graphical interface that you can use to view events from the logs of different applications. If these events are in the Common Base Events format, you can even see a correlated view of the events and determine the sequence of occurrence of these events -- a welcome improvement for system developers and support staff. Autonomic management For an autonomic computing system to discover and control events and situations, it uses a control loop that constantly monitors the system looking for events to handle. This control loop is defined by the autonomic computing reference architecture, as shown in Figure 2:

��

�

:$ �D��$ �� *$��$� � �� *�$��:$ �� "�� >�

1. Monitor: First, the system looks for the events, detected by the sensor from whatever source -- be it a log file or an in-memory process. The system uses the knowledge base to understand what it's looking at.

2. Analyze: When an event occurs, the knowledge base contains information that helps to determine what to do about it.

3. Plan: After the event is detected and analyzed, the system needs to determine what to do about it using the knowledge base. The symptom database might have information, or a central policy server might determine the action to take.

4. Execute: When the plan has been formulated, it's the effector that actually carries out the action, as specified in the existing knowledge base.

Although the control loop is a single conceptual process, it doesn't have to be carried out by a single product. For example, IBM® Director and Toshiba ClusterPerfect products can share the control loop, with Director carrying out the monitor and analyze processes and ClusterPerfect carrying out the plan and execute steps. The Autonomic Computing Toolkit includes the Autonomic Management Engine (AME), which can perform all of these steps for you. Of course, AME needs to be able to communicate with your product, which isn't as complicated as it sounds. AME can communicate with any product as long as there is an appropriate Resource Model in place. The Resource Model tells AME what it's looking for, be it a log entry or the status of a particular process. You can create your own Resource Model using the Autonomic Computing Toolkit's Resource Model Builder Tool, which can be integrated into WebSphere Studio Application Developer or the Eclipse IDE. Provisioning and orchestration -> IBM Tivoli® Provisioning Manager Complex analysis As you might have surmised by now, some of this processing can involve some fairly complex logic. In the case of a Java technology implementation (such as that provided by the Autonomic Computing Toolkit), you might opt to use JavaBeans components that provide artificial intelligence-like capabilities.

!�� $ �A��D��:��'��*�� "*� �$�� $ � �� :�� "�$�*�$��$� � ��*�'��L��$ ��"��'�� $�� $ � A� �� &�� 4 �� .�� A&4.�� 7�� 9&8��$�M�'�� C �� A&4.�� A�� & ��$��,��& �� *� ��"�� 4 ��& ��$�� $�� &�� C�� & ��$��"�*��

�



�$��"�� A�� & �� A�� A� �� 1�� /�� A&4.� ��7� �� *�$� � � �� "� � $�� '��"�� $�� *�$�� '�� "��

��init��process��timer��

Policy-based management -> Tivoli Access Manager Heterogeneous workload management All right, you've gotten this far. You've installed your applications into the system using Installable Units, you're managing it from the Integrated Solutions Console, and you're monitoring and resolving problems by using the Autonomic Management Engine. Is that it? Well, not quite. The ultimate goal of autonomic computing systems is the system in which everything is tracked, from start to finish, and constantly optimized for better performance above and beyond resolving problems. In short, it's business workload management. Products such as the Enterprise Workload Manager (EWLM) component of the IBM Virtualization Engine provide hetergeneous workload management capabilities. They enable you to automatically monitor and manage multi-tiered, distributed, heterogeneous or homogeneous workloads across an IT infrastructure to better achieve defined business goals for end-user services. These capabilities allow you to identify work requests based on service class definitions, track performance of those requests across server and subsystem boundaries, and manage the underlying physical and network resources to set specified performance goals for each service class. To take full advantage of workload management capabilities provided by products such as EWLM, applications need to be able to provide performance information in the Application Response Measurement (ARM) standard format. The IBM® Software Development Kit (SDK) for EWLM is a tool to aid in the development and test of ARM 4.0-level instrumentation in applications and middleware, and the development and test of EWLM ARM Adapter library implementations. Next steps The tools and technologies that enable systems to become self-configuring, self-healing, self-optimizing, and self-protecting are ready for you to use. Download the IBM Autonomic Computing Toolkit and start creating applications that will use the autonomic computing core capabilities. Some capabilities, such as solution installation, integrated solutions console, problem determination and autonomic management are part of the Autonomic Computing Toolkit itself. Others, such as complex analysis, policy-based management, and heterogeneous workload management require additional software. But, however you look at it, and however you build it, it's not hype anymore.

New to Autonomic computing

What IBM tools and products are available for autonomic computing? What IBM tools and products are available for autonomic computing?

1�� ,�*��$ �A��D��:��'��$�� A�� 4��/��A9N�� M��*�� $ � :��'�� "" �� $�� $�� ,�*��$ �A��D��:��'�� "�� /� � ��

O��L�� $��9&8��* �$��'��$��$��"�� $��$��* �� *��>�

• DB2 UDB Stinger and autonomic computing make a good pair. Read this article to learn why. • For a glimpse of orchestration and provisioning in action, take a peek at how IBM Tivoli Identity Manager with

IBM Tivoli Directory Integrator provision identities to a third-party application. • Take a look at the many intersections between autonomic computing technology and WebSphere products in

this set of articles on WebSphere and autonomic computing. • In this article about the integration of IBM Tivoli Access Manager 3.9 with WebSphere Application Server

you'll see autonomic features working to enable self-healing systems. • For more information on autonomic computing function being woven into IBM products, check these Web

sites: o developerWorks Grid computing o developerWorks DB2 o developerWorks Tivoli o developerWorks WebSphere



Understand the autonomic manager concept

Real life examples of autonomic managers

D� �� *�� O��*��$�* � ��"�� " �� 1�� /�� ,&�P�� *��$�� $ ��" �� $��*��

• DB2 -- The relational database management system (RDBMS) uses autonomic computing for a number of features. The first is a health monitor to maintain optimum performance of the database system. If any performance issues are found, DB2 will report the findings and offer expert advice on how to correct the situation. A configuration adviser helps the novice user in configuring an expert system -- something that would have normally taken a long time to set up. Future releases will concentrate on the self-healing and self-protecting segments of the autonomic computing system.

• Tivoli® -- The Intelligent Management Software solution contains all four areas of the autonomic computing environment. Elements of the toolset can self-configure (Configuration Manager), self-optimize (Workload Scheduler), self-heal (Enterprise Console) and self-protect (Risk Manager).

• eServer -- The Enterprise Workload Manager (EWLM) component of the IBM Virtualization Engine provides hetergeneous workload management capabilities. EWLM enables you to automatically monitor and manage multi-tiered, distributed, heterogeneous or homogeneous workloads across an IT infrastructure to better achieve defined business goals for end-user services. These capabilities allow you to identify work requests based on service class definitions, track performance of those requests across server and subsystem boundaries, and manage the underlying physical and network resources to set specified performance goals for each service class.

Bibliografía

♦ A. G. Ganek and T. A. Corbi. “The dawning of the autonomic computing era.” IBM Systems Journal, Special Issue on Autonomic Computing.Vol 42, No 1, 2003.

♦ Avizienis, J.-C. Laprie and B. Randell. “Fundamental Concepts of Dependability”, Research Report N01145, LAAS-CNRS, April 2001. (citeseer, local)

♦ D. Garlan, S. Cheng, and B. Schmerl. “Increasing System Dependability through Architecture-based Self-repair”. In Architecting Dependable Systems, R. de Lemos, C. Gacek, A. Romanovsky (Eds), Springer-Verlag, 2003.

♦ David Garlan “Curso Self-Healing Systems”, Carnegie Mellon University, Spring Semestre 2003.

♦ IBM “An architectural blueprint for autonomic computing” IBM and autonomic comuting, ibm.com/autonomic, April 2003.

♦ Koopman, P. Elements of the self-healing system problem space. Workshop on Architecting Dependable Systems (WADS03), May 2003.

♦ M. Shaw. “'Self-Healing': Softening Precision to Avoid Brittleness”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02). Charleston, South Carolina, November 2002, pp.111-113.

♦ Mary Shaw. “Beyond Objects: A Software Design Paradigm Based on Process Control”. ACM Software Engineering Notes, Vol 20, No 1, January 1995.



♦ Oriezy, P., Gorlick, M.M., Taylor, R.N., Johnson, G., Medvidovic, N., Quilici, A., Rosenblum, D., and Wolf, A. “An Architecture-Based Approach to Self-Adaptive Software.” IEEE Intelligent Systems 14(3):54-62, May/Jun. 1999.

♦ S. George, D. Evans, and L. Davidson. “A biologically inspired programming model for self-healing systems.” Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

Links de interés � David Garlan Curso Self-Healing Systems, Carnegie Mellon University, Spring Semestre 2003. � Temas de investigación sobre Ubiquitous Computing puede encontrarse en Seventh International

Conference on Ubiquitous Computing (UBICOMP´05). � Trabajos preliminares y afines sobre Ubiquitous Computing pueden encontrase en conferencias anteriores

http://www.ubicomp.org/previous_conferences.html � Temas de investigación sobre Self-Healing Systems puede encontrarse en el Workshop on Self-Healing

Systems (WOSS´02). � IBM Systems Journal, Special Issue on Autonomic Computing � Temas de investigación sobre Self-Managed Systems puede encontrarse en el Workshop on Self-Managed

Systems (WOSS´04). � Bibliografía más reciente puede encontrarse en el Workshops on Architecting Dependable Systems (WADS

´04) en la International Conference on Software Engineering (ICSE ´04) y en la International Conference on Dependable Systems and Networks (DSN ´04).

� Trabajos preliminares y afines pueden encontrase en el Workshops on Architecting Dependable Systems

(WADS ´03) en la International Conference on Software Engineering (ICSE ´03). Y en el Workshops on Architecting Dependable Systems (WADS ´02) en la International Conference on Software Engineering (ICSE ´02).

� Trabajos focalizados en temas relacionadas al análisis dinámico (en tiempo de ejecución) pueden

encontrarse en Second International Workshop on Dynamic Análisis (WODA´04). � Trabajos del amplia área de Autonomic Computing pueden encontrarse en First IEEE International

Conference on Autonomic Computing (ICAC´04). � IBM Autonomic computing for develpers.

Tema • Subtema

♦ Bibliografía

• Control Theory • Fault tolerance • Immunology General • Autonomic Computing



♦ A. G. Ganek and T. A. Corbi. “The dawning of the autonomic computing era.” IBM Systems Journal, Special Issue on Autonomic Computing.Vol 42, No 1, 2003.

♦ M. Shaw. “'Self-Healing': Softening Precision to Avoid Brittleness”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02). Charleston, South Carolina, November 2002, pp.111-113.

♦ Avizienis, J.-C. Laprie and B. Randell. “Fundamental Concepts of Dependability”, Research Report N01145, LAAS-CNRS, April 2001. (citeseer, local)

♦ Mary Shaw. “Beyond Objects: A Software Design Paradigm Based on Process Control”. ACM Software Engineering Notes, Vol 20, No 1, January 1995.

• User Modeling • Learning by watching • Intelligent tutoring systems User Interfaces • Intelligent user interfaces; Attentive User Interfaces

• Architecture-based Adaptation

Model-based Approaches

• Rainbow-like approaches

♦ Oriezy, P., Gorlick, M.M., Taylor, R.N., Johnson, G., Medvidovic, N., Quilici, A., Rosenblum, D., and Wolf, A. “An Architecture-Based Approach to Self-Adaptive Software.” IEEE Intelligent Systems 14(3):54-62, May/Jun. 1999.

♦ D. Garlan, S. Cheng, and B. Schmerl. “Increasing System Dependability through Architecture-based Self-repair”. In Architecting Dependable Systems, R. de Lemos, C. Gacek, A. Romanovsky (Eds), Springer-Verlag, 2003.

♦ Ioannis Georgiadis, Jeff Magee and Jeff Kramer. “Self-Organising Software Architectures for Distributed Systems”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Gross, P.N., Gupta, S., Kaiser, G.E., Kc, G.S., Parekh, J.J. An Active Events Model for Systems Monitoring. Proceedings of the Working Conference on Complex and Dynamic System Architecture, Brisbane, Australia, Dec 2001.

♦ Combs, N., Vagel, J. Adaptive Mirroring of System of Systems Architectures. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Bond, A., Sud, J. Service Composition for Enterprise Programming. Proceedings of the Working Conference on Complex and Dynamic System Architecture, Brisbane, Australia, Dec 2001.

♦ Eric M. Dashofy, André van der Hoek, Richard N. Taylor. “Towards architecture-based self-healing systems”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ David Garlan, Bradley Schmerl. “Model-based adaptation for self-healing systems”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Rogério de Lemos, José Luiz Fiadeiro. “An architectural support for self-adaptive software for treating faults”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Sam Michiels, Lieven Desmet, Nico Janssens, Tom Mahieu, Pierre Verbaeten DistriNet. “Self-adapting concurrency: the DMonA architecture”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Marija Mikic-Rakic, Nikunj Mehta, Nenad Medvidovic. “Architectural style requirements for self-healing systems”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ David S. Wile. “Towards a synthesis of dynamic architecture event languages”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Jonathan Aldrich, Vibha Sazawal, Craig Chambers, David Notkin. “Architecture-centric programming for adaptive systems”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Nathan Combs, Jeff Vagle. “Adaptive mirroring of system of systems architectures”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

• Task-oriented computing • Context-aware computing • Resource-aware computing (including energy-aware, adaptive

resource assignment, etc.)

Mobility, Ubiquitous Computing, OS Support • Agent-based systems



♦ Joao Pedro Sousa, David Garlan. Aura: an Architectural Framework for User Mobility in Ubiquitous Computing Environments.

♦ Rajesh Balan, Joao Pedro Sousa, M. Satyanarayanan. Meeting the Software Engineering Challenges of Adaptive Mobile Applications.

♦ Shankar R.Ponnekanti, Brian Lee, Armando Fox, Pat Hanrahan,and Terry Winograd. ICrafter: A Service Framework for Ubiquitous Computing Environments.

♦ Asim Smailagic and Daniel Siewiorek.Application Design for Wearable and Context-Aware Computers. IEEE Pervasive Computing, Vol. 1, No, 4, Dec 2002, pp. 20-29.

♦ Michael N. Huhns, Vance T. Holderfield, Rosa Laura Zavala Gutierrez. Robust Software Via Agent-Based Redundancy. AAMAS’03, July 1-2, 2003, Melbourne, Australia.

♦ Robert E. Smith and Nick Taylor. A Framework for Evolutionary Computation in Agent-Based Systems.

♦ E. Grishikashvili. Investigation into Self-Adaptive Software Agents Development. Distributed Multimedia Systems Engineering Research Group Technical Report. 27 April 2001.

♦ Guoqiang Zhong, Babak Hodjat, Tarek Helmy and Makoto Amamiya. Software Agent Evolution in Adaptive Agent Oriented Software Architecture. International Workshop on Principles of Software Evolution, pp. 130-134, 1999.

♦ Jason Flinn and M. Satyanarayanan. Energy-Aware Adaptation for Mobile Applications. Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP), 1999.

♦ Chen Lee, John Lehoczky, Raj Rajkumar and Dan Siewiorek. On Quality of Service Optimization with Discrete QoS Options. Proceedings of the IEEE Real-time Technology and Applications Symposium, June 1999.

♦ Rolf Neugebauer and Derek McAuley. Congestion Prices as Feedback Signals: An Approach to QoS Management. Proceedings of the 9th ACM SIGOPS European Workshop, pp. 91--96, Kolding, Denmark, September 2000.

♦ Satyanarayanan, M. The Evolution of Coda. ACM Transactions on Computer Systems, Volume 20, No. 2, May 2002.

♦ C. Dabrowski, K. Mills. “Understanding self-healing in service-discovery systems”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

• Biological Models: Santa Fe Institute • AI approaches, including Neural Nets • Amorphous Computing

Alternative Models of Computation • Multicellular Automata

♦ Radhika Nagpal, Attila Kondacs, and Catherine Chang. Programming Methodology for Biologically-Inspired Self-Assembling Systems. AAAI Symposium '03.

♦ Stephanie Forrest, Steven A. Hofmeyr, and Anil Somayaji. Computer immunology. Communications of the ACM, v.40 n.10, p.88-96, Oct. 1997.

♦ Stephen F. Bush and Amit B. Kulkarni. Genetically Induced Communication Network Fault Tolerance. SFI Workshop: Resilient and Adaptive Defence of Computing Networks 2002.

♦ S. George, D. Evans, and L. Davidson. “A biologically inspired programming model for self-healing systems.” Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Orna Raz, Philip Koopman, Mary Shaw. “Enabling automatic adaptation in systems with under-specified elements”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Johann Schumann, Stacy Nelson. “Toward V&V of neural network based controllers”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

• Self-stabilizing algorithms • Hot swapping Algorithms and Code • Safe mobile code

♦ Sanny Gustavsson, Sten F. Andler. “Self-stabilization and eventual consistency in replicated real-time databases”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

• Adaptive middleware • Adaptive network protocols • Chroma and other CMU OS work

Networks, Distributed Systems, and Middleware

• Multi-fidelity systems



♦ Fabio Kon, Fabio Costa, Gordon Blair, Roy H. Campbell. Adaptive middleware: The case for reflective middleware.Communications of the ACM, June 2002, Volume 45, Issue 6.

♦ Loyall, J., Schantz, R., Zinky, J., Pal, P., Shapiro, R., Rodrigues, C., Atighetchi, M., Karr, D., Gossett, J.M., Gill, C.D. Comparing and contrasting adaptive middleware support in wide-area and embedded distributed object applications. 21st International Conference on Distributed Computing Systems, April 2001, pp. 625-634.

♦ Narasimhan, P., Moser, L.E., Melliar-Smith, P.M. Strong replica consistency for fault-tolerant CORBA applications. The Sixth International Workshop on Object-Oriented Real-Time Dependable Systems, 2001, pp. 10-17.

♦ D. Reilly, A. Taleb-Bendiab, A. Laws, N. Badr. “An instrumentation and control-based approach for distributed application management and adaptation”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

Fault Tolerance and Dependability

• Classical techniques

♦ Koopman, P. Elements of the self-healing system problem space. Workshop on Architecting Dependable Systems (WADS03), May 2003.

♦ Shelton, C., Koopman, P. & Nace, W. A framework for scalable analysis and design of system-wide graceful degradation in distributed embedded systems. WORDS03, January 2003.

• Coordination Languages

Formal Models • Formal reasoning about mobile systems

♦ Jeff Magee, Naranker Dulay, Susan Eisenbach, and Jeff Kramer. Specifying Distributed Software Architectures. Fifth European Software Engineering Conference, Barcelona 1995.

♦ Antónia Lopes, José Luiz Fiadeiro, and Michel Wermelinger. Architectural Primitives for Distribution and Mobility. SIGSOFT 2002/FSE-10, Nov. 18-22, 2002, Charleston, SC, USA.

Más bibliografía (no clasificada): ♦ Jonathan Appavoo, Kevin Hui, Michael Stumm, Robert W. Wisniewski, Dilma Da Silva, Orran Krieger, Craig A. N. Soules. “An infrastructure for

multiprocessor run-time adaptation ” Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Gordon S. Blair, Geoff Coulson, Lynne Blair, Hector Duran-Limon, Paul Grace, Rui Moreira, Nikos Parlavantzas. “Reflection, self-awareness and self-healing in OpenORB ”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Giuseppe Valetto, Gail Kaiser. “A case study in software adaptation”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Z. Yang, B. H. C. Cheng, R. E. K. Stirewalt, J. Sowell, S. M. Sadjadi, P. K. McKinley. “An aspect-oriented approach to dynamic adaptation”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Stephen Fickas, Robert J. Hall. “Self-healing open systems”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ P. Inverardi, F. Mancinelli, G. Marinelli. “Correct deployment and adaptation of software applications on heterogenous (mobile) devices”. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

♦ Walker, Murphy, Steinbok and Robillard. Efficient Mapping of Software System Traces to Architectural Views. Proc. of CASCON, November 2000.

♦ Jonathan Aldrich, Craig Chambers, and David Notkin. ArchJava: Connecting Software Architecture to Implementation. In proceedings of ICSE 2002, May 2002.

♦ P. Oreizy, N. Medvidovic, R. N. Taylor. Architecture-Based Runtime Software Evolution. In Proceedings of the 20th International Conference on Software Engineering, pp. 177-186, Kyoto, Japan, April 1998.

Tendencias Tecnologicas en Desarrollo de Aplicaciones

Documents

Transcript of Tendencias Tecnologicas en Desarrollo de Aplicaciones