Tendencias Tecnológicas en Arquitecturas y Desarrollo de

Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Tendencias Tecnológicas en
Arquitecturas y Desarrollo de
Aplicaciones
Trabajos Diciembre 2004
Departamento de Computación
Facultad de Ciencias Exactas
Universidad de Buenos Aires
Página 1 de 1
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 2 de 2
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 3 de 3
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 4 de 4
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
eXtreme Programming
Adrián Pablo Eidelman
adrianenlared@yahoo.com.ar
¿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.
Página 5 de 5
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 6 de 6
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 7 de 7
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 8 de 8
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
¿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.
Página 9 de 9
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
¿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.
Página 10 de 10
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
¿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
Página 11 de 11
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Extreme Programming vs. CMM
Esteban Franqueiro
eaf@dc.uba.ar
¿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).
Página 12 de 12
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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 sobretiempo 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
! "
! "
Página 13 de 13
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Requirements Management
Software Project Planning
Software Project Tracking and Oversight
Software Subcontract Management
Software Quality Assurance
Software Configuration Management
Organization Process Focus
Organization Process Definition
Training Program
Integrated Software Management
Software Product Engineering
Inter-group Coordination
Peer Reviews
Quantitative Process Management
Software Quality Management
Defect Prevention
Technology Change Management
Process Change Management
2
3
4
5
++
++
++
-+
+
+
+
--++
++
++
--+
---
¿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
##
Página 14 de 14
" $
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
%
& '
(
)
"*
"*
Página 15 de 15
(
"*
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Buenas Practicas
Pablo Demidoff
pd4f@dc.uba.ar
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.
Página 16 de 16
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
•
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
Página 17 de 17
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 18 de 18
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 19 de 19
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 20 de 20
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
•
•
•
•
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
Página 21 de 21
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 22 de 22
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 23 de 23
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 24 de 24
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
EAI: Un Vistazo General
Leonardo Brambilla
lbrambil@dc.uba.ar
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:
Página 25 de 25
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Permitir a las empresas manejar sus negocios por
Internet mediante la interconexión de sus sistemas y
aplicaciones.
Manejar de manera conveniente sus aplicaciones y
sistemas ante cambios como adquisiciones, fusiones,
desregulaciones de mercados, etc.
Automatizar la ejecución de aplicaciones en un
complejo proceso de negocios
Mejorar los niveles de producción
Página 26 de 26
Drivers EAI hoy
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
Tomar EAI como una infraestructura tecnológica
necesaria para el futuro de los proyectos informáticos
de la compañía
Maximizar el Retorno de la Inversión hecha en los
años anteriores.
Introducir rápidamente las nuevas ofertas en el
mercado
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 27 de 27
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 28 de 28
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 29 de 29
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
SOA – Caso de Estudio
Pablo Michelis
pmicheli@cencosud.com.ar
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
Página 30 de 30
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
unGestorDeServicio
unaAcción
unaRespuesta
unCliente
accion
respuesta
transportar: unaAcción
accion
recibir: unaRespuesta
unAdaptadorDeCanal
unaAcción
respuesta
unObjetoDeNegocio
unObjetoDeNegocio
unObjetoDeNegocio
unDispatcher
persistencia
existe: unaAcción
elCatalogoDeAcciones
puedeEjecutar: unaAcción
unObjetoDeNegocio
unObjetoDeNegocio
unObjetoDeNegocio
elAgenteDeSeguridad
Ilustración 1: Niveles de Arquitectura
+
!
.
"
0
12
3
4
(
-
5
6
,
/
(
)
"
" $
(
4
"
!
Página 31 de 31
)
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
>,
Página 32 de 32
&
8
"&
9
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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:
Página 33 de 33
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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();
Página 34 de 34
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
DataObjects.NET Client
MS – Framework.NET 1.1
Página 35 de 35
Este componente implementa el servicio de base de
datos.
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.
Este componente implementa el runtime necesario
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
MS – Message Queueing
SAV – Business Objects
MBI Dispatcher
MS – IIS.NET
MBI – Administrative Tools
SAV – MBI Common Assemblies
MS – Iexplorer 5.0
SAV – Resources
MBI – Channel Adapter
MS –OS
MS – Desktop OS
MS – Server OS
para la ejecfución de los objetos “.NET” (CLR). Es
el componente “Microsoft .NET Framework 1.1”.
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.
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.
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]
Servicio de Web App Server
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.
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.
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.
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.
Cualquier sistema operativo Microsoft que pueda
ejecutar Microsoft Internet Explorer 5.0 o superior.
Windows 2000 Professional o Windows XP
Professional.
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
Servidor de Aplicaciones
Servidor de Distribución
Página 36 de 36
MS – SQL Server 2000
MS – Server OS
DataObjects.NET Client
MS – Framework.NET 1.1
MS – Message Queueing
SAV – Business Objects
SAV – Resources
MS – Server OS
MS – Framework.NET 1.1
MS – Message Queueing
MBI Dispatcher
SAV – MBI Common Assemblies
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Servidor Web
Cliente WinForm
Cliente Web
Protocolos y Componentes
.NET Remoting – Servicio de Dispatcher
.NET Remoting – Gestores de Servicio
SAV – Resources
MS – Server OS
MS – Framework.NET 1.1
MS – IIS.NET
MBI – Administrative Tools
SAV – MBI Common Assemblies
SAV – Resources
MBI – Channel Adapter
MS – Server OS
MS – Framework.NET 1.1
SAV – MBI Common Assemblies
SAV – Resources
MBI – Channel Adapter
MS – Desktop OS
MS – Iexplorer 5.0
MS –OS
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.
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
Página 37 de 37
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
.
A
!
<
A
D
C(
8
A
,
D
4
$
C
C
C
C(
D
/
C(
A
B
!
C
4
/
&
D
D
D "
/
8
A
Ilustración 2: Niveles de Servicio
Servidor de Web
Cliente WebForm
MS - Framework .Net 1.1
MS - IExplorer
MS - IIS .Net
MS - OS
http
MS - MBI 2.0 Administrative tools
SAV - MBI Common Asembly
SAV - Resources
MS - Server OS
<.NET Remoting>
Servidor de Distribución
MS - Framework .Net 1.1
MS - Message Queueing
<SQL Connection>
MS - MBI 2.0 (Dispatcher)
MS - Server OS
Cliente WinForm
MS - Framework .Net 1.1
<.NET Remoting>
Servidor de datos
<.NET Remoting>
MS - MBI 2.0 (Channel Adapter)
MS - SQL Server 2000
<<MS - ADO .Net Connection>>
MS - Server OS
SAV - MBI Common Asembly
SAV - Resources
MS - Desktop OS
Servidor de Aplicaciones
MS - Framework .Net 1.1
MS - Message Queueing
Data Object .Net (Client)
SAV - Business Objects
MS - Server 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.xtensive.com/Data/Downloads/DataObjects.NET/DataObjects.NET%20Manual.pdf)
Página 38 de 38
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Model Driven Architecture
Lic Gerardo Rossel Catardo
grossel@computer.org
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:
Página 39 de 39
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Código Assembler
Código Lenguajes de Alto
Nivel
Modelos Ejecutbles
Assembler
Compiladores Código
Fuente
Compiladores de
Modelos
Código Máquina
1960s
Nada
Código Assembler
1980s
Plataforma de Hardware
Código Fuente
2000s
Plataforma de Software
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.
PIM
Modelo
Independiente
de 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)
Página 40 de 40
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
PIM
Modelo
Independiente
de la
Plataforma
Modelo
CORBA
Modelo
J2EE
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.
PIM
Modelo
Independiente
de la
Plataforma
Modelo
CORBA
Modelo
J2EE
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.
Página 41 de 41
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
PIM
Modelo
Independiente
de la
Plataforma
Aplicaciones
Legadas
Otros Modelos
CTOS
Otros
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.
PIM
Modelo
Independiente
de la
Plataforma
Modelo
.NET
Modelo
CORBA
CORBA
System
.NET
Bridge de
Interoperació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
Página 42 de 42
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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).
Página 43 de 43
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 44 de 44
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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 Textual
Requirements
Model system use cases
ANALYSE NEW DOMAINS
Build Static and Dynamic
Models
and Specify Actions
Model domain use cases
Execute and debug the
xUML domain model
FORMALISE ABSTRACT
DESIGN MODEL
VALIDATE ANALYSIS
Integrate multiple domain
models using bridges
Select or develop suitable
translation rules, patterns and
mechanisms
Execute domain use cases
Execute system use cases
Build or Buy an xUML complier
PRODUCE TARGET CODE
Automatically apply design
patterns to xUML models
using code generation
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
Página 45 de 45
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 46 de 46
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 47 de 47
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Integración de Aplicaciones con Web Services
Pablo Cecconi
pc@educ.ar
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.
Página 48 de 48
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 49 de 49
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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 autocontenidas, 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:
Página 50 de 50
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 51 de 51
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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:
Página 52 de 52
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
<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.
Página 53 de 53
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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).
Página 54 de 54
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 55 de 55
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 56 de 56
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Página 57 de 57
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Business Process Management (BPM)
Ivana Saló
isalo@dc.uba.ar
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 $
Página 58 de 58
.
& 8 ! "*
&
9
G
77%
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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 *
"
Página 59 de 59
19 BAC
&
"
8
$
/ ""
>$ $
*
:$
'$
$$
77%
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
o
o
o
o
Existencia de procesos no automatizados (procesos auxiliares, soporte, administrativos...)
Existencia de actividades y tareas no soportadas desde los sistemas operacionales (gestión documental,
flujos de aprobación, etc.)
Complejidad en la implementación de las soluciones workflow de mercado.
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.
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.
Página 60 de 60
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 61 de 61
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 62 de 62
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 63 de 63
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
o
o
o
o
o
El trabajo no queda trabado o extraviado.
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.
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.
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.
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.
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.
Página 64 de 64
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 65 de 65
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 66 de 66
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 67 de 67
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
JAIN/SLEE
Jorge Andres Brassara
abrassara@softhome.net
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
Página 68 de 68
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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:
Invocaciones
Granularidad
los Eventos
Componentes
de
Fuentes de Datos
Transacciones
Cómputo
Comunicaciones
-Típicamente asincrónico
Eventos tales como triggers de protocolos
Los eventos se mapean con invocaciones a
métodos
Eventos de granularidad fina y alta
frecuencia
Objetos livianos conteniendo poca lógica
de negocios, ciclos de vida cortos y
transitorios: rápida creación y eliminación.
Múltiples fuentes de datos (ej, eventos
disparados por protocolos)
-Transacciones livianas
Se completan más rápido y son más
frecuentes
- Cómputo-intensivo
Las principales entradas y salidas son
invocaciones a recursos, mensajes y
eventos
Enterprise
- Típicamente sincrónico
Bases de Datos, Sistemas EAI, Llamadas
RPC
Eventos de granularidad gruesa y baja
frecuencia
Objetos pesados de acceso a datos, que
pueden tener ciclos de vida largos y
persistentes.
Sistemas Back-end y servidores de Base
de Datos
-Transacciones de Base de Datos
Tardan más en completarse y son menos
frecuentes
- 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:
Página 69 de 69
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 70 de 70
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 71 de 71
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 72 de 72
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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://syscon.com/story/?storyid=46230&DE=1
Página 73 de 73
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Programación Orientada a Aspectos
Fernando Taboada
fernandopablotaboada@yahoo.com.ar
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.
Página 74 de 74
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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());
}
Página 75 de 75
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 76 de 76
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 77 de 77
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
2.
3.
4.
5.
6.
7.
Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Marc
Loingtier, John Irwin. Aspect-Oriented Programming. ECOOP 1997
G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm y W. Griswold. An Overview of AspectJ, ECOOP
2001.
James Holmes. AOP: Taking Abstraction One Step Further. Oracle Magazine Septiembre/Octubre 2004
Nicolás Kicillof. Programación Orientada a Aspectos (AOP)
http://www.ajlopez.net/ArticuloVe.php?Id=611
Arno Schmidmeier, Using AspectJ to Eliminate Tangling Code in EAI-Activities
María Agustina Cibrán, Bart Verheecke, Modularizing Web Services Management with AOP
Anis Charfi1, Mira Mezini. Aspect-Oriented Web Service Composition with AO4BPEL
Página 78 de 78
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Sistemas de Administración de Contenidos
Gabriel Bulfón
gabrielbulfon@hotmail.com
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.
RECOLECCIÓN
ADMINISTRACIÓN
PUBLICACIÓN
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).
Página 79 de 79
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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 ecommerce 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).
Página 80 de 80
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Demasiado contenido
Muchos colaboradores
"
#$
!
Demasiado cambio
!
Muchas publicaciones
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
Página 81 de 81
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
Página 82 de 82
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 83 de 83
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
Página 84 de 84
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
!
#
$ %
)&
. /
6 7
Página 85 de 85
&
'
*
!+
' /
&&& &
1
&&&
(
,%
&&&
!
"
(& (
&
0
! 1 &2
5#.6
44#
!
&%
%
!
- (*
3
% #44#
0
-
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
8
&%
$%
- &
<
!9 %
&%
- ::
!+
!
% #44#$
#4=# <6:=# .<<6<4=# 44
&&&
?
!+
#4A<6:A
:.<: 8A
44
: B C$
&&&
D$
'
!0
!
$%
&&&
'
&&&
'
&&&
G
'
&
&&&
&
$
"
#
.
A
! C&
'
%(
'
F
! +'
'
!
#44 4: ' 4 4:'
#(
,
%(
! 2% #44
#44 4. ' 4 4. (
'
!+
,%
%('
!9
Página 86 de 86
'
! / +,
% #44#$
! 2 , - ! 1 * % #44.
&2
E ;
D
/564:44#46
'
2
&&&
@
#44
#44 4 ' 4 4 '(
%(
4,
3
:::
;&5 !%
".
&&&
>
C -
!2
% #44
;
;
#44
!C
2
0
/
%
%
'
'
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
Self-Healing Systems
Mónica Silva
msilva@dc.uba.ar
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 (SelfRepair). 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.
Página 87 de 87
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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, selfconfiguring, 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.
Página 88 de 88
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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 (más sutil) mostrar funciones deseadas, tolerar desviaciones
ocultando detalles
razonables, mostrar requerimientos de recursos que necesariamente
encajen con las expectativas del usuario
Escribir software correcto
Incluir mecanismos de monitoreo y reparación para detectar errores
y arreglarlos cuando es posible
Usar administración de la
Soportar configuración dinámica y sintonización automática para
configuración para construir
tantos entornos diferentes como encuentre
sistemas para entornos
reconocibles
Si hay errores que no se
propaguen al usuario
Diseñar sistemas teniendo en
cuenta su evolución
Página 89 de 89
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
General
Dominio
Aplicación
Herramientas,
Mecanismos
Técnicas
Objetivos
•
•
•
•
Control Theory
•
Networks, Distributed Systems,
Middleware
•
•
Mobile Systems
Ubiquitous Computing
•
•
Biology Simulation
•
•
Collaborative Computing
•
•
Architectural models
•
Formal models
•
Genetic algorithms/alternative models
•
•
Agents
•
Improve system performance/Resource
usage
•
Improve user experience; reduce user
distractions
•
Improve dependability
Fault tolerance y Dependability
Classical techniques
•
•
•
•
•
•
•
Adaptive middleware
Adaptive network protocols
Chroma and other CMU OS work
Multi-fidelity systems
Autonomic Computing
de
y
•
Immunology
User Interfaces
•
•
•
•
•
•
Task-oriented computing
Context-aware computing
Resource-aware computing (including energy-aware,
adaptive resource assignment, etc.)
Agent-based systems
Biological Models: Santa Fe Institute
User Modeling
Learning by watching
Intelligent tutoring systems
Intelligent user interfaces; Attentive User Interfaces
Games
Algorithms/code-based
•
•
•
•
•
•
•
•
•
Architecture-based Adaptation
Self-stabilizing algorithms
Hot swapping
Safe mobile code
Coordination Languages
Formal reasoning about mobile systems
AI approaches, including Neural Nets
Amorphous Computing
Multicellular Automata
Economic theory
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
Página 90 de 90
TTADA
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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 selfprotecting, 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:
91
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
♦ 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
TTADA
2004
Página 92 de 92
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
TTADA
2004
Página 93 de 93
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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”
TTADA
2004
Página 94 de 94
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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 Selfrepair” 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:
TTADA
2004
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.
Página 95 de 95
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
TTADA
2004
Página 96 de 96
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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:
General
Dominio de Aplicación
Herramientas,
Técnicas
Objetivos
TTADA
Mecanismos
•
•
•
•
Control Theory
•
•
•
•
•
•
•
Networks, Distributed Systems
•
•
y •
•
•
•
•
•
•
Fault tolerance y Dependability
Immunology
Autonomic Computing
Mobile Systems
Ubiquitous Computing
Biology Simulation
User Interfaces
Collaborative Computing
Games
Architectural models
Algorithms/code-based
Formal models
Genetic algorithms/alternative models
Agents
Economic theory
Improve system performance/Resource usage
Improve user experience; reduce user distractions
Improve dependability
2004
Página 97 de 97
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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 selfmanagement 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:
!
"
#
&
$
(
(
!
TTADA
%
'
)
2004
Página 98 de 98
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
*
+
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 selfmanagement 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
HI
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.
TTADA
2004
Página 99 de 99
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
TTADA
2004
Página 100 de 100
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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 endusers, 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, selfhealing 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-
TTADA
2004
Página 101 de 101
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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 highervalue 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 finegrained, 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.
TTADA
2004
Página 102 de 102
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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
TTADA
2004
Página 103 de 103
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
+ 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
$
* $ :$
*$ $
"
>
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.
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.
Execute: When the plan has been formulated, it'
s the effector that actually carries out the action, as specified in
the existing knowledge base.
1.
3.
4.
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
:
$
$
9
&8
*
&
$
TTADA
$M
D
$ A
'
"
&
2004
:
"$ * $
&
C
' *
$
4
A&4.
4
C
"*
$
* ' L$ "
'
.
A&4.
7
A &
$
,
&
$
&
$
" *
Página 104 de 104
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
$
/
"
A&4.
A
* $
7
&
A
1
"
"
$
init process
A
* $
$
'
'
"
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 selfprotecting 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
M
*
, *
$ :
$ A
'
"
"
$ A
O L
$
*
•
•
•
•
•
TTADA
9
&8 *
D
D
$ '
:
$
:
$ $
"
'
'
$
A
4
/ A9
N
$
, *
/
"
$
$ *
>
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
2004
Página 105 de 105
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
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.
TTADA
2004
Página 106 de 106
♦
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
♦
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
•
•
•
•
Control Theory
Fault tolerance
Immunology
Autonomic Computing
Bibliografía
General
TTADA
•
2004
Página 107 de 107
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
♦
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 Interfaces
Model-based
Approaches
•
•
•
•
User Modeling
Learning by watching
Intelligent tutoring systems
Intelligent user interfaces; Attentive User Interfaces
•
•
Architecture-based Adaptation
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 SelfHealing 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 SelfHealing Systems (WOSS '
02).
Mobility, Ubiquitous
Computing,
OS
Support
TTADA
•
•
•
Task-oriented computing
Context-aware computing
Resource-aware computing (including energy-aware, adaptive
resource assignment, etc.)
• Agent-based systems
2004
Página 108 de 108
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
♦
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 SelfHealing Systems (WOSS '
02).
Alternative Models of
Computation
•
•
•
•
Biological Models: Santa Fe Institute
AI approaches, including Neural Nets
Amorphous Computing
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 SelfHealing Systems (WOSS '
02).
Algorithms and Code
♦
•
•
•
Self-stabilizing algorithms
Hot swapping
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).
Networks, Distributed
Systems,
and
Middleware
TTADA
•
•
•
•
Adaptive middleware
Adaptive network protocols
Chroma and other CMU OS work
Multi-fidelity systems
2004
Página 109 de 109
Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones
♦
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.
Formal Models
•
•
Coordination Languages
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.
TTADA
2004
Página 110 de 110