Tendencias Tecnologicas en Desarrollo de Aplicaciones

Tendencias Tecnolgicas en Arquitecturas y Desarrollo de Aplicaciones
Pgina 1 de 1 TTADA

Tendencias Tecnolgicas en
Arquitecturas y Desarrollo de
Aplicaciones

Trabajos Diciembre 2004

Departamento de Computacin
Facultad de Ciencias Exactas
Universidad de Buenos Aires

Pgina 2 de 2 TTADA

Indice
Introduccin....................................................................................................................... 4
eXtreme Programming....................................................................................................... 5
Qu es XP?................................................................................................................................................... 5
Porqu surge XP?......................................................................................................................................... 5
Principios de XP ............................................................................................................................................ 5
Prcticas de XP.............................................................................................................................................. 7
Es XP econmicamente viable? ................................................................................................................... 9
Cundo usar XP ?......................................................................................................................................... 9
Cundo NO usar XP ?................................................................................................................................ 10
XP vs. metodologas tradicionales ............................................................................................................... 10
Conclusiones................................................................................................................................................ 11
Bibliografa .................................................................................................................................................. 11
Extreme Programming vs. CMM..................................................................................... 12
Qu es XP?................................................................................................................................................. 12
Prcticas de XP............................................................................................................................................ 12
XP vs. CMM................................................................................................................................................ 13
Casos de estudio........................................................................................................................................... 14
Bibliografa .................................................................................................................................................. 15
Buenas Practicas .............................................................................................................. 16
Introduccin................................................................................................................................................. 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 intencin.......................................................................................................... 25
Actualidad.................................................................................................................................................... 26
Futuro........................................................................................................................................................... 28
Conclusin ................................................................................................................................................... 28
Referencias................................................................................................................................................... 29
SOA Caso de Estudio.................................................................................................... 30
Introduccin................................................................................................................................................. 30
Requerimientos ............................................................................................................................................ 30
Niveles de Arquitectura ............................................................................................................................... 30
Requisitos de Diseo y Construccin .......................................................................................................... 32
La Arquitectura Orientada a Servicios......................................................................................................... 32
Despliegue de Componentes........................................................................................................................ 35
Referencias................................................................................................................................................... 38
Model Driven Architecture .............................................................................................. 39
Introduccin................................................................................................................................................. 39
Construyendo una aplicacin MDA............................................................................................................. 40
Ingeniera de Reversa y Bridge Generation ................................................................................................. 41
Detalle de Conceptos utilizados en MDA.................................................................................................... 42
Productos ..................................................................................................................................................... 44
Conclusiones................................................................................................................................................ 46
Bibliografa .................................................................................................................................................. 47
Integracin de Aplicaciones con Web Services ................................................................ 48
Acerca de este documento ........................................................................................................................... 48
Introduccin................................................................................................................................................. 48
El Problema: La Integracin ........................................................................................................................ 48
Solucin ....................................................................................................................................................... 49
La Tecnologa .............................................................................................................................................. 50
Integrando con SOAP .................................................................................................................................. 54
Conclusin ................................................................................................................................................... 55
Pgina 3 de 3 TTADA

Referencias................................................................................................................................................... 56
Business Process Management (BPM) ............................................................................. 58
Introduccin................................................................................................................................................. 58
Qu es Business Process Management (BPM)?......................................................................................... 58
BPM en la prctica....................................................................................................................................... 60
La tecnologa de BPM................................................................................................................................. 62
BPM hoy...................................................................................................................................................... 65
Conclusiones................................................................................................................................................ 66
Bibliografa .................................................................................................................................................. 67
JAIN/SLEE...................................................................................................................... 68
Introduccin................................................................................................................................................. 68
Motivacin................................................................................................................................................... 68
Objetivos...................................................................................................................................................... 68
JAIN Service Logic Excecution Enviroment (JSLEE) ................................................................................ 69
Jain Session Initiation Protocol (JSIP)......................................................................................................... 71
JAIN y otras tecnologas de Java (Big Picture)............................................................................................ 72
Estado .......................................................................................................................................................... 72
Conclusin ................................................................................................................................................... 73
Referencias................................................................................................................................................... 73
Programacin Orientada a Aspectos................................................................................. 74
Introduccin................................................................................................................................................. 74
El problema a resolver ................................................................................................................................. 74
Algunas definiciones bsicas ....................................................................................................................... 74
Aprendiendo AOP con un ejemplo.............................................................................................................. 75
Herramientas disponibles para java y .net.................................................................................................... 76
Visin de futuro ........................................................................................................................................... 77
Conclusiones................................................................................................................................................ 78
Bibliografa .................................................................................................................................................. 78
Sistemas de Administracin de Contenidos ...................................................................... 79
Qu es un CMS? ........................................................................................................................................ 79
Algo de historia............................................................................................................................................ 79
Conceptos importantes detrs de un CMS ................................................................................................... 80
Cundo conviene usar un CMS? [1]........................................................................................................... 80
Beneficios .................................................................................................................................................... 81
Caractersticas de un CMS........................................................................................................................... 81
Problemas observados en los CMS.............................................................................................................. 82
Estado actual del mercado de los CMS........................................................................................................ 83
Cmo encontrar el CMS adecuado? [3,6,7,8] ............................................................................................ 84
El futuro de los CMS ................................................................................................................................... 85
Referencias................................................................................................................................................... 85
Self-Healing Systems....................................................................................................... 87
Introduccin................................................................................................................................................. 87
Qu son los Self-Healing Systems? ............................................................................................................. 88
Consecuencias para la ingeniera de software? ............................................................................................ 89
Taxonoma de Temas................................................................................................................................... 90
Elementos del modelo del espacio de problemas......................................................................................... 90
La propuesta de IBM: Informtica Autnoma ............................................................................................. 91
Propuesta desde la Biologa ......................................................................................................................... 93
Otra propuesta: Homeostasis ....................................................................................................................... 94
Propuestas Self-Healing basadas en Arquitecturas ...................................................................................... 94
Casos prcticos de la industria IT ................................................................................................................ 96
Bibliografa ................................................................................................................................................ 106
Links de inters.......................................................................................................................................... 107
Pgina 4 de 4 TTADA

Introduccin
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 estn agrupados por su temtica, cubriendo los distintos contenidos ofrecidos en la materia,
haciendo hincapi en las citas y referencias que permiten profundizar cada uno de los temas.

Pgina 5 de 5 TTADA

eXtreme Programming
Adrin Pablo Eidelman
adrianenlared@yahoo.com.ar

Qu es XP?
XP es una disciplina de desarrollo de software basada en ideas y prcticas simples y de sentido comn que
poseen varios aos de utilizacin.
El objetivo principal de XP es perderle el miedo al cambio y a travs 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, tomndose el tiempo para escribir pruebas y cambiar el cdigo 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
mayora de los desarrollos de software se encuentran hoy inmersos y que trae como resultado retrasos,
malhumor, trabajo a desgano y rotacin alta de personal.
Porqu surge XP?
XP surge como una solucin a los problemas de las metodologas de desarrollo de software tradicionales. Estas
fallan generalmente en brindar al cliente el mximo beneficio que pueda obtener de su inversin. Tambin fallan
en un sentido social al quitar importancia al factor humano en pos de los procesos asumiendo una visin de la
produccin de software comparable a una lnea de ensamblaje en la que cada obrero puede ser fcilmente
reemplazado sin que se modifique de manera apreciable el funcionamiento general.
XP surge tambin como una forma de mitigar los riesgos inherentes a cualquier desarrollo de software y la
mayora de los cuales no son correctamente encarados por las metodologas tradicionales. Entre estos riesgos
encontramos:
Llegar a la fecha de finalizacin 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 ms
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 prcticas especficas que permitan resolver o mitigar los riesgos, se debe
definir un conjunto de principios que servirn de gua durante todo el desarrollo y permitirn juzgar y evaluar
cada una de las prcticas que se quiera introducir. Estos principios tambin ayudarn a tomar decisiones de
forma ms rpida y precisa ya que sabiendo hacia donde se quiere ir es ms fcil decidir qu camino se acerca o
aleja del objetivo.
Realimentacin rpida
Para contar con una disciplina que se adapte constantemente a los cambios del negocio, es indispensable contar
con una realimentacin rpida. De esta forma, los programadores podrn aprender constantemente qu necesitan
los usuarios y estos podrn entender qu es lo que los primeros pueden hacer por ellos.
Asumir la sencillez
Rompiendo con la tradicin impuesta por todas las metodologas que la preceden, XP propone resolver los
problemas que se presentan de la manera ms sencilla posible. En vez de planificar y disear 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 ms que los necesarios para resolver el
5% restante.
Pgina 6 de 6 TTADA

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 pequeos. De esta forma, es mucho ms fcil controlar la aplicacin 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 programacin dentro de XP
sino tambin al diseo y la planificacin.
Aceptar el cambio
Si se desea utilizar XP se debe estar completamente dispuesto a aceptar el cambio constante. Ms 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 rpidamente se cansarn de trabajar en un proyecto de calidad dudosa.
Ensear a aprender
Mejor que dar pescado es ensear a pescar. En esto se basa la filosofa 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 decisin hay una posibilidad de que se este cometiendo un error. Por lo tanto es mejor
realizar un pequeo experimento (prototipo, prueba de concepto, etc.) que permita reducir el riesgo y tener
mayor confianza en que se va por el camino correcto.
Comunicacin abierta y honesta
Muchos proyectos son cancelados, se retrasan o sufren seriamente debido a que no se cuenta con una
comunicacin 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 comunicndose
constantemente, tanto las buenas como las malas noticias. De esta forma, aquellos que tengan la autoridad o
capacidad podrn tomar las decisiones adecuadas cuando todava hay tiempo de revertir el proceso.
Aceptar la responsabilidad
Nada quita ms la motivacin 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 rpido al mismo tiempo. Los miembros de un equipo XP
deben estar preparados para moverse rpidamente en cuanto surja una nueva necesidad de negocio o una mejor
solucin de diseo. Por lo tanto solo deben llevar consigo aquello que aporta valor al cliente: las pruebas y el
cdigo.
Adaptacin particular
La disciplina propuesta por XP no se encuentra en ningn 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 prcticas que
si o si deben ser aplicadas, pero incluso en estos casos se puede decidir cmo y cundo aplicarlas.
Medidas justas
Para poder conocer el estado de un proyecto es inevitable tener que llevar algn tipo de medicin. Sin embargo,
es de extrema importancia que las medidas utilizadas sean justas ya que podran llegar a influir la forma de
trabajar de cada miembro del equipo.
Pgina 7 de 7 TTADA

Prcticas de XP
En base a los principios mencionados anteriormente, XP propone doce prcticas que deberan ser llevadas a cabo
en todo desarrollo de software. Estas son:
El juego de la planificacin
Versiones pequeas
Metfora
Diseo sencillo
Hacer pruebas
Recodificacin (refactoring)
Programacin en parejas
Propiedad colectiva del cdigo
Integracin continua
Semanas de 40 horas
Cliente junto al equipo de desarrollo
Estndares de codificacin
El juego de la planificacin
El objetivo del juego de la planificacin es determinar de forma rpida y claramente detallada cul es el alcance
de la siguiente versin. Para esto es necesario combinar las prioridades del negocio con las posibilidades y
estimaciones tcnicas. 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 despus) 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 (cunto tiempo se
tardar en desarrollar cada una de las caractersticas requeridas), las consecuencias tecnolgicas (hay ciertas
decisiones de negocio que requieren un cuidado anlisis del posible impacto tecnolgico que podran acarrear en
caso de llevarse a cabo), el proceso (cmo se organizar el trabajo y el equipo) y el orden del desarrollo dentro
de una versin (a veces es tecnolgicamente conveniente desarrollar primero una caracterstica menos
prioritaria).
Versiones pequeas
Cada versin debera ser tan pequea como fuera posible conteniendo solo los requisitos de negocio ms
importantes. Sin embargo, no se puede perder de vista que cada versin tiene que tener un sentido por s misma.
No se puede implementar la mitad de una caracterstica en una versin y la otra mitad en la siguiente. Cuanto
ms reducido sea el tiempo de cada versin, mayor ser la retroalimentacin obtenida y ms posibilidades habr
de controlar el presupuesto, los tiempos y la aceptacin por parte del cliente.
Metfora
La metfora sirve de gua 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 cohesin dentro del sistema como un todo.
Diseo sencillo
Pon lo que necesites solo cuando lo necesites. Esta frase resume muy bien la idea del diseo sencillo en XP y
se basa en dos creencias fundamentales: que el futuro es incierto y que ser fcil cambiar las cosas en el futuro.
XP provee una sencilla lista de pasos para evaluar si un diseo es realmente sencillo. Simplemente debe cumplir
con estas cuatro reglas:
Funciona con todas las pruebas
No tiene lgica duplicada
Manifiesta cada intencin importante para los programadores
Tiene el menor nmero posible de clases y mtodos
Un mtodo sencillo para simplificar un diseo es simplemente eliminar cualquier elemento del mismo de forma
tal que se sigan cumpliendo las tres primeras reglas.
Hacer pruebas
Todas las caractersticas del programa deben tener una o ms pruebas asociadas. Esto es indispensable para
cualquier proyecto XP ya que es lo que permite que con el correr del tiempo el programa sea ms modificable (y
no menos como sucede en las metodologas tradicionales). Hay dos tipos bsicos de pruebas, las de unidad y las
funcionales. Las primeras las escriben los programadores y les permite ir incrementando su confianza en el
Pgina 8 de 8 TTADA

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 prctica. La idea no es hacer una prueba para cada mtodo de cada clase sino solo
para aquellas funcionalidades importantes que pueden llegar a fallar.
Recodificacin (Refactoring)
La recodificacin implica modificar cdigo que est funcionando para mantener el diseo lo ms sencillo
posible. Cada vez que un programador debe aadir una nueva caracterstica lo primero que hace es programarla
de la manera ms sencilla posible. Luego trata de ver la forma de hacer el diseo lo ms simple posible y que
sigan funcionando las pruebas. A veces, esto lleva ms tiempo que el absolutamente necesario para hacer que
algo funcione. Sin embargo, es esta pequea inversin la que permite que sea sencillo de agregar el prximo
cambio y el siguiente, etc. Son los pequeos cambios de la recodificacin los que permiten hacer grandes
cambios en el sistema con bajo riesgo.
Programacin en parejas
Todo el cdigo 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 mtodo. Su pareja, tiene una visin ms
estratgica y debera pensar en: nuevos casos de prueba que hagan fallar el mtodo, si la aproximacin 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 da dependiendo de la
disponibilidad y de las habilidades requeridas para cada tarea. Esta prctica da como resultado un cdigo fuente
de mucha mayor calidad que el que podra producir un programador trabajando por separado. Y contrariamente a
lo que podra esperarse, no solo no genera una reduccin en la produccin de los programadores sino que la
mantiene constante (con mayor calidad) o incluso la aumenta.
Propiedad colectiva del cdigo
Todos los miembros del equipo son propietarios y responsables de todo el cdigo 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 ms tradicional de propietario nico del cdigo en el
cual se debe requerir al propietario que haga las modificaciones que uno necesita.
Integracin continua
Todas las parejas deben integrar su cdigo con la ltima versin estable por lo menos una vez al da. Cada vez
que se realiza la integracin, los que la hacen deben asegurarse que todas las pruebas se ejecutan correctamente.
En caso de no ser as esa pareja deber corregir el cdigo hasta que pase las pruebas y en caso de no poder,
deber retirar sus actualizaciones y volver a la versin anterior a la integracin. Esta prctica asegura que la
ltima versin del cdigo no divergir demasiado de la versin que cada desarrollador tiene y de esta forma se
evitar largas jornadas de integracin y an ms largas jornadas de correccin de errores de integracin.
Semanas de 40 horas
Nadie puede trabajar cmodo y a gusto si todas las semanas est 50 o 60 horas trabajando. Si se mantiene ese
ritmo, al poco tiempo los desarrolladores se cansarn y empezarn a producir un cdigo de muy mala calidad y
al tiempo buscarn un nuevo lugar de trabajo. Es por esto que XP propone que las semanas no deben ser de ms
de 40 horas. Puede haber excepciones, pero si estas se prologan por ms de una semana seguida entonces es un
sntoma 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 podrn ir aprendiendo acerca del negocio y consultar todas las dudas que tengan y no tener que
esperar das o semanas a que se produzca una reunin y recin ah saber qu es lo que el cliente quiere. El cliente
tambin puede proporcionar un feedback inmediato acerca del funcionamiento de las nuevas caractersticas.
Estndares de codificacin
Ya que los programadores estarn cambiando constantemente cualquier parte del cdigo, es necesario tener
ciertos estndares bsicos que den una consistencia de estilo al cdigo. El estndar debera exigir la menor
cantidad de trabajo posible y ser consistente con la regla de no duplicar cdigo. Es importante que todo el equipo
acepte voluntariamente el estndar.
Pgina 9 de 9 TTADA

Es XP econmicamente viable?
Si nos basamos en la creencia tradicional que dice que el costo de hacer una modificacin 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 visin completamente distinta respecto de este punto. XP sostiene que si se
aplican las prcticas 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 deberan aplazar las
decisiones ms importantes para mantener las opciones abiertas. Solo se debera implementar lo que se necesita
hoy y no pensando en lo que se necesitar a futuro. Ya que seguramente el negocio cambiar, la inversin de
hacer lo que creemos que ser til, seguramente no terminar siendo rentable.
Para poder mantener la curva de costo segn la Figura 2, XP se basa en dos herramientas claves. La primera es la
programacin orientada a objetos ya que esta al mantener unido el cdigo con los datos sobre los que opera hace
ms fcil la introduccin de nuevos cambios. La segunda es un subconjunto de las prcticas: el diseo simple y
las pruebas automatizadas. El diseo simple mantiene el programa sencillo y solo con lo que se necesita en el
momento, por lo tanto es ms fcil de modificar y sin las pruebas automatizadas, realizar cualquier cambio sera
introducir grandes riesgos sobre un cdigo que ya funcionaba.
Cundo usar XP ?
XP puede ser usado para una infinidad de proyectos distintos tanto sean desarrollos nuevos como mantenimiento
o modificacin de programas existentes. Si el proyecto es nuevo, se pueden aplicar todas las prcticas desde el
principio. Sin embargo, en los dems casos, cambiar completamente la forma de trabajo tal vez no sea lo ms
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 ms acuciantes de casi cualquier proyecto son la baja calidad del cdigo existente y el
desequilibrio en la negociacin entre los desarrolladores y el cliente. Por lo tanto en general se empieza
aplicando las pruebas automatizadas y el juego de la planificacin. Las pruebas se debern ir generando solo
para el cdigo que es necesario modificar. De esta forma se mantiene el principio de hacer solo lo que se necesita
hoy y dejar para maana lo que se necesitar maana.

Pgina 10 de 10 TTADA

Cundo 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 tenan algunos proyectos para los que XP no funcion:
Si la cultura de la empresa consiste en quedarse despus de hora para demostrar el compromiso con el
proyecto
Si se va a necesitar ms de una o dos docenas de programadores
Si el tiempo en el que se obtiene un ejecutable para realizar las pruebas es de ms de un da
Si se necesita pasar por certificaciones de calidad que llevan varias semanas antes de poner el cdigo en
produccin
Si no se puede replicar (de manera satisfactoria) el entorno de produccin 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 cmodos en una misma
mquina
De todas formas, todos los das 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. metodologas tradicionales
A continuacin se presenta una lista con algunos puntos en los que las metodologas tradicionales difieren
completamente con XP.
Documentacin
Las metodologas tradicionales ponen un gran nfasis en la documentacin, tanto en la forma de manuales como
en la de diagramas. A la larga, terminan pasando una de dos cosas, o la documentacin empieza a desactualizarse
hasta convertirse en inservible o el costo de estar constantemente actualizndola se vuelve un obstculo en el
avance del proyecto.

XP ve a la documentacin como una herramienta y no como un fin. Por lo tanto solo recomienda documentar
cuando esta documentacin provea un valor en s mismo y descartarla en cuanto pase a ser un obstculo.
Orientacin del proceso
Las metodologas tradicionales son orientadas al proceso. Esto significa que su objetivo es desarrollar un proceso
en donde las personas involucradas sean fcilmente reemplazables. Lo que importa en el proceso son los roles y
no las personas que los cumplen.

XP es una metodologa 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 metodologas
tradicionales.
Predicibilidad de los requerimientos
Las metodologas 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 caractersticas esperadas del sistema. Una vez
finalizada la etapa de relevamiento, estas metodologas tratan de poner la mayor cantidad de trabas posibles en
los cambios de los requerimientos ya que estos implicaran 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 ao. Por lo tanto propone un modelo de
desarrollo iterativo en donde el cliente expresa sus necesidades ms acuciantes y recibe peridicamente (cada
una o tres semanas) versiones incrementales del sistema. De esta forma va teniendo contacto con el mismo y
pudindolo utilizar mucho antes de que est completamente finalizado. As puede enterarse prematuramente si
una caracterstica fue interpretada correctamente y si en realidad era tan til como lo imaginaba.

Qu significa un proyecto exitoso?
Para las metodologas tradicionales, un proyecto exitoso es aquel que se est ejecutando segn el plan en
trminos 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 drsticamente una vez empezado el
proyecto, el desarrollo debe ser capaz de ajustarse a ese cambio. No tiene ningn sentido continuar con un plan
que llevar a un sistema inservible o que ser poco usado.
Visin del cambio
Las metodologas 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.
Tambin los criterios de aceptacin 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 ms valioso que el que
originalmente se haba previsto. La gran mayora de las prcticas de XP estn diseadas para hacer los cambios
posibles.
Conclusiones
Hoy en da, cada vez ms proyectos deciden adoptar XP como gua 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. Adems brinda al cliente una sensacin de control e
inmersin en el proyecto muy superior a la que hasta ahora haban experimentado con otros procesos. Hasta
ahora pocas metodologas haban hecho tanto nfasis en la necesidad de comunicacin, en las personas y en una
relacin tan fluida ente el cliente y los desarrolladores como propone XP.
Es la visin del autor que cada vez ms las pequeas y medianas empresas que requieren y/o proveen desarrollo
de software empezarn 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 prcticas que de
ellos se derivan. Tambin se mostr cmo es que estas prcticas pueden ser econmicamente sustentables a pesar
de ir en contra de lo que tradicionalmente se crea correcto. Por ltimo se brind una breve resea acerca de
cuando si y cuando no usar XP junto con un resumen de las diferencias ms significativas entre XP y sus
antecesoras.
Bibliografa
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 Karlstrm, Introducing Extreme Programming An Experience Report


Extreme Programming vs. CMM

Esteban Franqueiro
eaf@dc.uba.ar

Qu es XP?
Puede clasificarse como una de las metodologas giles, surgidas como reaccin ante las metodologas
ingenieriles y su burocracia. Atribuida a Kent Beck, Ron Jeffries y Ward Cunningham, XP est pensada para
pequeos y medianos proyectos con requerimientos vagos y que cambian frecuentemente.
Asumiendo que un alto costo del cambio de requerimientos es debido a las tecnologas en uso (patterns,
information hiding, etc), XP trata que el proceso de desarrollo de software sea altamente dinmico. El equipo XP
trata los cambios a travs de un ciclo de vida iterativo de ciclos cortos. Las cuatros actividades bsicas en el ciclo
de vida de XP son coding, testing, listening y design. El dinamismo es demostrado por cuatro valores:
comunicacin continua con el cliente y dentro del equipo, simplicidad para enfocarse en la solucin mnima,
feedback rpido y constante a travs del testing de unidad y funcional y el coraje para gestionar los problemas
proactivamente.

Prcticas de XP
XP se basa en alguna prcticas (llamadas Core Practices
1
).
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 direccin
al proyecto.
Los programadores tambin son parte de este equipo, as como los testers, que ayudan al cliente a definir los
tests de aceptacin. Tambin lo son los analistas que ayudan al cliente a definir requerimientos.
Suele haber un coach que mantiene al equipo en camino y tambin puede haber un manager que se encarga de
proveer los recursos, manejar la conversacin 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 sern alcanzados en la
fecha de entrega, y decidir cul ser el siguiente paso.
El nfasis est en darle direccin al proyecto, en vez de predecir exactamente qu se necesitar y cunto llevar
hacerlo. Hay dos pasos que se ocupan de estos temas:
Release Planning
Prctica en la que los clients presentan las caractersticas (features) deseadas y los programadores estiman su
dificultad. Con esta estimacin de costos y las prioridades de estas caractersticas, el cliente plantea un plan de
trabajo. Los planes iniciales suelen no ser precisos (ni las prioridades ni las estimaciones son realmente slidas)
y hasta que el equipo no comience a trabajar no puede saberse qu tan rpido irn. Estos planes son revisados
regularmente.
Iteration Planning
Es la prctica en la cual al equipo se le da direccin cada un par de semanas. Las iteracin son cada dos semanas,
y al final de cada iteracin el equipo produce software til. Durante este planeamiento, el cliente presenta las
caractersticas requeridas en las prximas dos semanas. Los programadores las dividen en tareas y estiman su
costo (a un nivel ms fino que el obtenido en release planning).

1
No soy partidario de traducir los nombres originales de las cosas. Por esta razn, voy a dejar los nombres de
en su idioma original (por ejemplo, los nombres de las prcticas, etc.).


Customer Tests
Como parte del pedido de cada caracterstica, los clientes deben definir tests automatizados de
aceptacin que muestren que la caracterstica est funcionando.
El equipo debera 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 pequeos releases, produciendo en cada iteracin 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 produccin (esto ltimo es altamente recomendado).
Simple Design
El equipo utiliza diseos simples para construir el software. Comienza simple, y mediante otras prcticas
(programmer testing y design improvement) mantienen esta simplicidad. Se mantiene el diseo justo para la
funcionalidad actual del sistema.
En XP, el diseo 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 diseo (en el planeamiento de releases, de iteraciones, en sesiones
de diseo y en revisiones de diseo 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 prctica garantiza que todo el cdigo sea revisado por al menos otro
programador, y resulta en un mejor diseo, testing y cdigo.
Adems, esta prctica 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 cdigo que deber pasar exitosamente dichos tests.
Estos tests se mantienen todos juntos, con el cdigo base, y cada vez que un par de programadores
agrega cdigo al repositorio, cada uno de los tests existentes debe correr sin errores.
Design Improvement
XP se enfoca en producir, en cada iteracin, algo que tenga valor comercial para el cliente. Para esto, el software
debe estar bien diseado. Para mejorar continuamente el diseo, XP usa el proceso de refactoring. Este proceso
se basa en eliminar cdigo duplicado, aumentar la cohesin y disminuir el acoplamiento. De esta forma, se
comienza con un diseo simple y se lo mantiene.
El uso de refactoring va acompaado 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 mltiples builds por da. La falta
de integracin constante genera, al momento de hacer un build o release, que se encuentren todos los problemas
de integracin clsicos.
Collective Code Ownership
El cdigo le pretence al equipo, no a un programados o par de programadores en particular. Cualquier
par puede mejorar cualquier cdigo en cualquier momento. Esto significa que todo el cdigo tiene la
atencin de todos, lo que aumenta su calidad y reduce defectos.
Esto tiene otras ventajas. Cuando el cdigo tiene un dueo, ciertas caractersticas pueden ser implementadas en
el lugar equivocado para no tener que esperar a que el dueo del cdigo correcto la implemente.
Coding Standards
Todo el equipo sigue las mismas reglas al escribir cdigo. Esto ayuda a cumplir la prctica anterior.
Metaphor
El equipo consigue una visin comn de cmo funciona el sistema (llamada metfora). Esta puede ser una
metfora de verdad, o simplemente un sistema comn de nombres para las cosas, de forma que todos entiendan
como funciona el sistema, y dnde buscar la funcionalidad que requieren o agregar nuevas funcionalidades.
Sustainable Pace
El equipo trabaja a un ritmo que pueda ser sostenido indefinidamente. Esto significa que trabajan sobre-
tiempo cuando es efectivo, y que cuando los programadores estn cansados, descansan.

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

Nivel de CMM KPA Satisfaccin en XP
2

2
+ Stisfaccin parcial.
++ Satisfaccin completa.

Requirements Management ++
Software Project Planning ++
Software Project Tracking and Oversight ++
Software Subcontract Management --
Software Quality Assurance +
2
Software Configuration Management +
Organization Process Focus +
Organization Process Definition +
Training Program --
Integrated Software Management --
Software Product Engineering ++
Inter-group Coordination ++
3
Peer Reviews ++
Quantitative Process Management --
4
Software Quality Management --
Defect Prevention +
Technology Change Management -- 5
Process Change Management --

Qu tienen en comn los KPAs en los que XP falla?
Los KPAs 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 ms que grupal.

En el primer grupo entra Software Subcontract Management. Esto se debe a que XP est pensado para grupos
y proyectos pequeos o medianos, en los que no tiene sentido la contratacin de terceros. Por este motivo, la
prdida 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 KPAs que XP no satisface caen en el segundo grupo, el de los que se refieren al concepto de
institucionalizacin, o sea, a establecer la idea de as es como hacemos las cosas ac. Si bien est implcita en
algunas prcticas, XP mayormente ignora la infraestructura que CMM identifica como clave para la
institucionalizacin de buenas prcticas de ingeniera y management.

Los KPAs de CMM, en cambio, comparten caractersticas comunes que implementan e institucionalizan
procesos. XP ignora algunas de estar prcticas, como las polticas organizacionales, mientras que otras (como
entrenamiento y QA) las satisface indirectamente como consecuencia de sus propias prcticas. Finalmente existe
otro grupo de prcticas de CMM que XP satisface parcialmente (por ejemplo las relacionadas con temas
especficos de proyectos).

En general XP se enfoca en el lado tcnico del proceso de desarrollo, mientras que CMM se enfoca en temas
administrativos. Es por esta razn que XP generalmente ignora los KPAs 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 ms importante el concepto de arquitectura del sistema, y entonces algunas de las
prcticas de XP se vuelven difciles de mantener o implementar.
En estos sistemas grandes, variantes del modelo bottom-up de XP (como por ejemplo el diseo basado en
arquitectura) pueden ser ms apropiados.

Un ltimo problema de XP es que los proyectos grandes tienden a ser multidisciplinarios, mientras que XP est
dirigida especficamente al software.
Casos de estudio
XP en una empresa CMM Nivel 3
En cierta empresa, la administracin decidi que todos los sistemas de la misma deban migrarse a aplicaciones
web en 18 meses. El objetivo era reducir costos. Este requerimiento de 18 meses, chocaba contra los 5 aos
estimados basndose en experiencias y procesos anteriores. Los desarrolladores eligieron trabajar con XP con la
esperanza de que esta metodologa les permitiera cumplir la fecha impuesta. El equipo modific algunas de las
prcticas de XP para que tuvieran en cuenta el tamao del proyecto. Esto afect principalmente las prcticas

-- No satisfecho.

relacionadas con el testing, ya que en lugar de primero crear los tests y luego escribir el cdigo que los pase, se
formaron equipos de testing independientes de los de desarrollo.
Por otro lado, el equipo de QA se quej ante la administracin por la falta de documentacin 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 artculo original, el proyecto es encontraba detenido.
XP en un proyecto de investigacin cientfica
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
laboratorio
3
.
Segn Beck, el principal obstculo para el xito de un proyecto XP es la insistencia de tener un diseo a priori,
en lugar de ir diseando 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 trgicos.
Al contrario que en el caso anterior, este proyecto concluy de forma ms que satisfactoria. Los autores del
artculo cuentan que la nueva metodologa de desarrollo casi duplic su productividad comparada con proyectos
previos. Este se debi a que si bien produjeron la misma cantidad de cdigo de produccin, adems produjeron
una cantidad similar de cdigo de soporte (en forma de tests, tanto de unidad como de aceptacin). Tambin
encontraron que el cdigo result ms conciso y claro (todo esto lo atribuyen a la aplicacin sin misericordia del
refactoring).
Como consecuencia de esta prueba piloto, otros proyectos grandes de la NASA estn adoptando XP.
XP en una empresa RUP
La empresa se dedica al diseo y construccin de servicios de Internet basados en Java, y utilizando las
herramientas de Rational. Todo esto bajo el control de RUP.
El experimento dur dos aos en el contexto de dos laboratorios. El primero complet dos proyectos. Para el
primer proyecto aplicaron una versin 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 coordinacin.
Para el siguiente proyecto siguieron las reglas al pie de la letra y consiguieron alcanzar los objetivos propuestos
y algunos ms.
Actualmente la empresa no utiliza XP, pero aplica sus principios. La empresa ahora mezcla programadores con y
sin experiencia XP. El artculo adems cuenta las perspectivas de cada uno de ellos frente a la metodologa.
Este caso muestra la necesidad de no quedarse a mitad de camino en la aplicacin del mtodo, y confirma que
quienes aplicaron XP en proyectos de escala acotada obtuvieron resultados satisfactorios.
Bibliografa
IEEE Software, May/June 2003.
www.xprogramming.com
www.extremeprogramming.org
Extreme Programming from a CMM Perspective. Paulk, M.; IEEE Software, November/December 2001.

3
Beck dice que l nunca construy software para misiles, con lo cual no puede opinar al respecto.
Paradjicamente el software que se construy en este proyecto es justamente software para misiles.

Buenas Practicas
Pablo Demidoff
pd4f@dc.uba.ar
Introduccin

El objetivo de este trabajo es dar una introduccin al tema de Buenas Practicas (Best Practices) y servir como
gua para la bsqueda de informacin en la Web sobre las buenas practicas aplicadas a los temas vistos durante
el seminario.

Motivacin
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 montn de informacin 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 mayora yo
no tenia ni idea. As que me pareci bien escribir una especie de gua que explicara que son y dar puntos de
referencia para buscar informacin 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 aos de practicas probadas y reales.
Desde modelos de programacin estructurada a mtodos orientados a objetos, el desarrollador es generalmente
librado a sus propios recursos para implementar cdigo basado en un proceso de diseo altamente creativo y
subjetivo.

El acceso a la informacin sobre el desarrollo de software ya no es un reto. Puede ser, por otro lado, dificultoso
asimilar todas las nuevas caractersticas, los numerosos recursos, las opciones de herramientas, etc. Cuando hay
que escribir un programa o toda una aplicacin, los desarrolladores tienen, una y otra vez, el deseo de obtener
consejos.

Que Son ?
El objetivo de las Buenas Practicas es proveer consejos rpidos, concretos y aplicables que nos asistan en la
escritura de cdigo legible, mantenible y eficiente.
Las Buenas Practicas estn diseadas para rpidamente ponernos al tanto de aspectos tiles sobre el aspecto
tecnolgico 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 cdigo (formato,
nombre variables) hasta que soluciones o tcnicas utilizar en determinadas soluciones. Es mas, una Buena
Practica, podra llegar a decir, es bueno usar el Patrn XXX para solucionar tal problema.

Tambin son conocidas como consejos (tips), tcnicas probadas, guas, 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:

Ttulo
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 nmero secuencial
dentro de este conjunto de buenas practicas.


Descripcin
Una explicacin 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 travs de cdigo o ancdotas el valor de
estas buenas practicas.

Beneficios
Porque deberamos molestarnos con esta buena prctica ?. Cuan crucial es para uno seguir esta
recomendacin en particular ? . Esta seccin ofrece una rpida resea de los principales beneficios que
obtendremos siguiendo esta buena practica.

Desafos
Esta seccin nos previene sobre los desafos o inconvenientes que podemos enfrentar al implementar esta
buena practica.

Recursos
En el mundo de la Internet, todo esta conectado, ningn programador esta solo !. Esta seccin recomienda
recursos, libros, pginas 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 Administracin de Proyectos, Diseo
de Sites, JSP, Servlets, Struts, EJB, J2EE, Oracle, Seguridad, Administracion de Application Servers (ej.
Websphere), etc, et..

Desarrollo de Aplicaciones
A continuacion, intentaremos agruparlos segn la arquitectura de N-Capas vista en clase, y algunos otrs
conceptos como seguridad, administracin y metodologia.

Diseo de Sitios
Estas guas sirven para definir como tiene que ser un sitio, desde su aspecto hasta como esta distribuida la
informacin, que tipo de informacin se muestra, y las opciones de accesibilidad que se le brindan a los usuarios.
Se utilizan para mantener un aspecto uniforme dentro de una organizacin u empresa muy grande, en la cual, hay
mas de un grupo de desarrollo trabajando sobre el sitio corporativo o institucional.

Por ejemplo, el artculo 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 travs de la agencia. Estos criterios deben ser vistos como
recomendaciones base. Estas buenas prcticas continuarn siendo revisadas por la comunidad NASA WWW.

Desarrollo de Sistemas
Estas guas 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 artculo Best Practices for Software Development Projects (3) dice:
La mayora de los proyectos de software fracasan. De hecho, el grupo Standish reporta que ms del 80% de los
proyectos son fallidos porque son sobre presupuestados, tardos, falta funcionalidad o una combinacin de los
mismos. Adems, 30% de los proyectos de software son tan pobremente ejecutados que hacen que sean

cancelados antes de finalizar. En nuestra experiencia, los proyectos de software usando tecnologas 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 tecnologa 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 artculo, Capturing and Formalizing Best Practices in a Software Development Organization (7), el autor
dice:
El nmero de recursos que los desarrolladores de software moderno deben utilizar para crear aplicaciones es
simplemente increble. Modelos de procesos, mtodos de desarrollo, tecnologas, y herramientas de desarrollo
apenas araan la superficie del arsenal contenido en el kit de herramientas del diseador de software. Pero la
comunidad de ingeniera de software ha por la mayor parte ignorado el conocimiento adquirido y la esencia de la
maestra en herramientas, optando en cambio por amontonar nuevos mtodos, lenguajes, herramientas y mtodos
formales sobre la pila de conocimientos. Poco soporte es dado para el entendimiento de cuando las diferentes
metodologas deben ser usadas y como ellas deben ser aplicadas al esfuerzo de desarrollo con conjuntos
especficos de requerimientos.
Este paper presenta una infraestructura que soporta conocimiento evolutivo por tcnicas basadas en casos que
ayudan a las organizaciones de desarrollo de software a pasar de la metodologa tradicional de desarrollo
(Standard Development Methodology) a un medio dinmico que capture buenas practicas y las convierta en
organizaciones basadas en la informacin.

En el artculo Reference Architecture: The Best of Best Practices (8), el autor dice:
Porque un proyecto dentro de una organizacin florece mientras un proyecto dentro con las mismas
necesidades fundamentales arquitectnicas, dentro de la misma organizacin, lucha por mantenerse a flote ?.
A menudo, la raz del problema es la falta de comunicacin horizontal a travs de todos los proyectos en lo
concerniente a elecciones arquitectnicas, tanto para buenas como malas, que fueron realizadas en proyectos
pasados. RUP dice que tal recoleccin de buenas practicas dentro de la organizacin es el primer paso hacia la
construccin de una arquitectura de referencia verstil y fuerte.
Brevemente, una arquitectura de referencia consiste en informacin accesible para todos los miembros del
equipo del proyecto que provee un conjunto consistente de buenas practicas arquitectnicas. Estas pueden ser
plasmadas en muchas formas: artefactos arquitectnicos previos, estndares de la compania, patrones de diseo,
frameworks comerciales, etc.

Capa Presentacin
Estas Buenas Practicas sirven para como mejorar el desarrollo de la capa de presentacin, o sea, como se
muestran los datos al usuario. Incluyen a todas las tecnologas que se ocupan de este rubro, como ser HTML,
JSP, Servlets, Struts, etc.

El sitio de IBM developerWorks contiene toda una seccin de JSP Best Practices (9), donde se van publicando
artculos peridicamente sobre este tema.

En el artculo, Solving the logout problem properly and elegantly (10), el autor dice:
El manejo correcto del proceso de logout en una aplicacin Web protegida por password requiere mas que una
llamada al mtodo invalidate() del objeto HttpSession porque la mayora de los navegadores modernos, con los
botones de Adelante y Atrs, permiten a los usuarios avanzar y retroceder en una pagina. Si el botn Atrs causa
que el navegador muestre paginas viejas desde sus caches despus 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, previnindolos de hace click en el botn atrs.
Otros, usan JavaScript el cual no siempre esta activo en el navegador del cliente. La mayora 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 aplicacin 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 discusin en JSP, el articulo presenta los conceptos que pueden ser

fcilmente entendidos y adoptados para otras tecnologas Web. Le concluye esta discusin mostrando como
construir aplicaciones Web con Jakarta Struts puede resolver el problemas mas elegantemente. Programas
ejemplo para JSP y Struts estn 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 fcilmente mantenibles. Por ejemplo, cdigo 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 artculo, Struts best practices. Build the best performing large applications (12), el autor dice:
Muchas opciones estn disponibles para resolver problemas con Struts. Cuando decidimos entre estas
alternativas, la eleccin debe estar basada en parmetros como la escala del trabajo y la disponibilidad de tiempo.
Sin embargo para aplicaciones grandes y con necesidad de buena calidad de servicio, cada decisin se
transforma en crucial y esfuerzos extras son requeridos para elegir la solucin apropiada. Para ayudarlo con estas
decisiones, Puneet Agarwal discute algunas de las buenas practicas para desarrollar aplicaciones basadas en
Struts.

En el artculo 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 estndares, incluyendo ActionForm, la clase Action y ActionErrors.

Capa Lgica Aplicacin

Estas Buenas Practicas estn pensadas para lo que se refiere a modelar la capa de negocios o la lgica de la
aplicacin. 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 versin 3.0 de EJB y porque simplifica su uso, dado que la gente es reticente a utilizar
dicha tecnologa por se un tanto complicada.

El sitio de IBM developerWorks contiene toda una seccin de EJB Best Practices (15), donde se van publicando
artculos peridicamente sobre este tema (casualmente es el mismo autor de los JSP Best Practices).

En el artculo, Best practices in EJB exception handling (16), se habla sobre como manejar correctamente el
tema de excepciones en EJB.

Capa Administracin de Datos

Estas Buenas Practicas estn pensadas a la programacin del cdigo en la base de datos, y a como optimizar el
acceso a los datos, por ejemplo, con el uso de JDBC.

En el artculo 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 descripcin de los capitulos del libro Oracle PL/SQL Best Practices (1):
Capitulo 1: Comienza con recomendaciones especificas de programacin. Ofrece consejos sobre como mejorar
todo el proceso por el cual usted escribe cdigo


Capitulo 2: Ofrece una serie de sugerencias sobre como formatear y organizar su cdigo, para que este sea mas
legible y, por consiguiente, mas mantenible.

Capitulo 3: Toma una vista cercana a como usted debera declarar y manejar datos dentro de programas PL/SQL.

Capitulo 4: Es un capitulo Regreso a los bsico 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 ms crucial del desarrollo en PL/SQL: como debera 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 lgica del negocio. Adems incluye buenas practicas para la construccin de
parmetros.

Capitulo 8: Presenta recomendaciones sobre paquetes, los bloques de construccin de cualquier aplicacin
basada en PL/SQL bien diseada.

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 estn relacionadas con el tema de la seguridad en las aplicaciones. Tanto sobre como se
piensa (o no) en las mismas, como sobre las tecnologas que existen para evitar las fallas de seguridad en
nuestros sistemas.

En el artculo Abstracting Application-Level Web Security (18), los autores dicen:
Seguridad Web a nivel aplicacin se refiere a vulnerabilidades inherentes en el cdigo de la aplicacin en si
misma (independientemente de la tecnologa 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 aplicacin han sido
explotadas con serias consecuencias: hackers han trampeado sitios de e-commerce, usuarios y claves han sido
cosechados e informacin confidencial (como direcciones y nmeros de tarjetas de crdito) ha sido violada. En
este paper investigamos nuevas herramientas y tcnicas que tratan el problema de seguridad a nivel aplicacin
Web. (i) Describimos un mecanismo de construccin escalable que facilita la abstraccin de polticas de
seguridad para grandes aplicaciones Web desarrolladas en entornos multiplataforma heterogneos; (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 implementacin de estas tcnicas.

En el artculo Best Practices for Secure Web Development (19), el autor explica algunos trminos bsicos del
tema y presenta 18 Best Practices, en el siguiente orden:
Seguridad como parte de la idea del negocio.
Seguridad como parte de la recoleccin de requerimientos.
Seguridad como parte de la arquitectura.
No ser annimo cuando no queres terminar sindolo.
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 cdigos de produccion.
Cross-site scripting
Chequear el cdigo de ejemplo o generado por wizards.
Middleware security
Declarative vs programmatic
PKI no es una bala de plata.

Snake oil
La revisin de cdigo es tu amigo.
Mira que usas.
Para resolucin de problemas usa los logs.

Administracin de Aplicaciones.

Estas Buenas Practicas estn relacionadas con la administracin de los productos que nos permiten soportar
aplicaciones Web, como por ejemplo, los Application Servers. Ac se dan pautas de cmo hacer una correcta
instalacin y setup, y como ir monitoreando su correcto funcionamiento.

En el sitio WebSphere Best Practices Zone: Background Information (20) se da una introduccin a la
terminologa y un punto de acceso hacia los Best Practices.

En el artculo 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 artculo 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 segn la frecuencia con que las
mismas son modificadas.

En el artculo WebSphere Application Server v4.x. Best Practices using HTTP Sessions (23) dice:
Este white paper contiene consejos y tcnicas 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 seccin discute cuando usar cada opcin para ayudar al administrador de
sistema o desarrollador a identificar cuando y donde una opcin es valiosa para usar. Finalmente, buenas
practicas de desarrollo de aplicaciones para servlets y JSP, especialmente enfocndose en sesiones HTTP y
persistencia con sesiones.

En el artculo 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 estn. Examinamos
la performance del software/hardware stack, primero desde una perspectiva a nivel sistema (topologa, I/O, red),
luego desde la ultima capa de software (nivel aplicacin), 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.

Integracin de Aplicaciones Empresariales.

En esta seccin, veremos buenas practicas para la integracin de aplicaciones empresariales (EAI Enterprise
Application Integration). Ac se vern guas de cmo 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 integracin de aplicaciones, es desacoplar lo mas posible cada parte
de la arquitectura (donde parte puede ser un sistema o componente) para que sea fcil su cambio en un futuro, y
que el impacto sea el menor posible. Tambin se menciona a SOA (Service Oriented Arquitecture) como una
buena practica porque no esta ligada a una plataforma tecnolgica particular.

En el sitio Enterprise Integration Patterns (25) se explican los conceptos, las tecnologas involucradas, algunos
patrones y buenas practicas.

En el articulo Best Practices for Successful EAI (26) el autor explica algunos buenas practicas de EAI. Estas son:
Best Practice #1: Building with Deployment in Mind
Best Practice #2: Profile Performance Early and Often
Best Practice #3: Build a Traceable System
Best Practice #4: Reviewing and Addressing Secondary Scenarios

Cosas curiosas si las hay, es que encontr otro articulo en CodeGuru (27) que explica los mismo que el anterior,
pero escrito por otros autores. Que coincidencia, no ?, o ser que no hay muchas buenas practicas ?.

Otro articulo interesante es EIA for CIOs: A Pragmatic Approach (28) en el que se da una visin mas general del
tema, y esta enfocada para que la gerencia de las empresas entienda la importancia de la integracin 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 bsicos inherentes a cada tema, tecnologa, etc., etc.
Espero que esto sirva de punto de partida para poder seguir buscando mas material y para que se tenga una
nocin de sobre que temas se pueden encontrar consejos tiles y buenas practicas.
Referencias.
1. Oracle PL/SQL Best Practices.
Autor: Steven Feuerstein.
Editorial: O'Reilly
ISBN: 0-596-00121-5

2. NASA WWW Best Practices.
Sitio: http://nasa-wbp.larc.nasa.gov/

3. Best Practices for Software Development Projects.
Autor: Mike Perks.
Sitio: http://www-106.ibm.com/developerworks/websphere/library/techarticles/0306_perks/perks2.html

4. Designing Enterprise Applications with the J2EE Platform, Second Edition.
Autores: Inderjeet Singh, Beth Stearns, Mark Johnson, and the Enterprise Team.
Editorial: Addison-Wesley
ISBN: 0-201-78790-3
Sitio: http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/

5. Java BluePrints program.
Sitio: http://java.sun.com/blueprints/

6. Software Development: Best Practices for Developing Enterprise Applications.
Autores: Greg Barnes Nelson y Danny Grasse.
Sitio: http://support.sas.com/sassamples/papers/enterpriseapps_03jan.pdf

7. Capturing and Formalizing Best Practices in a Software Development Organization
Autor: Scott Henninger.
Sitio: http://www.cse.unl.edu/~scotth/papers/Henninger_SEKE97.pdf

8. Reference Architecture: The Best of Best Practices
Autor: Paul R. Reed, Jr.
Sitio: http://www.therationaledge.com/content/sep_02/m_bestPractices_pr.jsp

9. IBM DeveloperWork. JSP Best Practices.
Autor: Brett McLaughlin.
Sitio: http://www-128.ibm.com/developerworks/java/library/j-jspcol.html

10. Solving the logout problem properly and elegantly
Autor: Kevin H. Le.
Sitio: http://www.javaworld.com/javaworld/jw-09-2004/jw-0927-logout_p.html


11. Servlets and JSP Pages Best Practices
Autor: Qusay H. Mahmoud
Sitio: http://www.javaworld.com/javaworld/jw-09-2004/jw-0927-logout_p.html
12. Struts best practices. Build the best performing large applications.
Autor: Puneet Agarwal
Sitio: http://www.javaworld.com/javaworld/jw-09-2004/jw-0913-struts_p.html

13. Best practices for Struts development. Optimize the Struts framework in your Web application development
Autores: Palaniyappan Thiagarajan y Pagadala J Suresh.
Sitio: http://www-106.ibm.com/developerworks/library/wa-struts/

14. Ease of Development in Enterprise JavaBeans Technology
Autor: Ed Ort.
Sitio: http://java.sun.com/developer/technicalArticles/ebeans/ejbease/

15. IBM DeveloperWork. EJB Best Practices.
Autor: Brett McLaughlin.
Sitio: http://www-128.ibm.com/developerworks/java/library/j-ejbcol.html

16. Best practices in EJB exception handling
Autor: Srikanth Shenoy.
Sitio: http://www-106.ibm.com/developerworks/library/j-ejbexcept.html

17. Scalability and Performance: JDBC Best Practices and Pitfalls
Autores: Julia Gutjahr and Andreas Loew.
Sitio: http://www.netobjectdays.org/pdf/02/papers/ws-jada/1149.pdf

18. Abstracting Application-Level Web Security
Autores: David Scott y Richard Sharp.
Sitio: http://www-lce.eng.cam.ac.uk/~djs55/swap/abstracting.pdf

19. Best Practices for Secure Web Development
Autor: Razvan Peteanu.
Sitio: http://members.rogers.com/razvan.peteanu/best_prac_for_sec_dev4.pdf

20. WebSphere Best Practices Zone: Background Information
Sitio: http://www-128.ibm.com/developerworks/websphere/zones/bp/background.html

21. Best Practice: Not creating HttpSessions in JSPs by default
Autor: Harvey W. Gunther
Sitio: http://www-106.ibm.com/developerworks/websphere/library/bestpractices/not_creating_httpsessions_in_jsps.html

22. Best Practice: Classpath structure for WebSphere Application Server
Autor: WebSphere Best Practices Team.
Sitio: <lo tengo que buscar nuevamente>.

23. WebSphere Application Server v4.x. Best Practices using HTTP Sessions
Autor: David Draeger.
Sitio: <lo tengo que buscar nuevamente>.
24. Enterprise Java Performance: Best Practices
Revista: Intel Technology Journal, Volume 07, Issue 01.
Autores: Kingsum Chow, Ricardo Morin y Kumar Shiv.
Sitio: http://developer.intel.com/technology/itj/index.htm

25. Enterprise Integration Patterns
Sitio: http://www.eaipatterns.com/

26. Best Practices for Successful EAI
Autor: Andre Yee.
Sitio: http://www.ebizq.net/topics/eai/features/1712.html

27. CodeGuru - Best Practices for Successful EAI
Autor: Syed Hameed.
Sitio: http://www.codeguru.com/Csharp/.NET/net_asp/miscellaneous/print.php/c6777/

28. EIA for CIOs: A Pragmatic Approach.
Autor: Sunil Senan
Sitio: http://www.infy.com/services/packaged_applications/setlabs_briefings_vol1_no2-eaiforcios.pdf

29. Symphony
Sitio: http://www.objectconsulting.com.au/downloads/Symphonyfactsheet.pdf

30. TouchPoint
Sitio: http://www.touchpointsi.com/TouchPointBPO.pdf
Sitio: http://www.touchpointsi.com/TouchPointCIS.pdf

31. Fiorano
Sitio: http://www.fiorano.com/devzone/why_integration.htm


EAI: Un Vistazo General

Leonardo Brambilla
lbrambil@dc.uba.ar

Resumen

El presente trabajo es una modesta revisin del estado del arte de la tecnologa EAI. Comienza con un intento
de definir EAI, remarcando lo difcil que puede ser acordar sobre la misma. Se comentan otras tecnologas que
atacan problemas parecidos y lo confuso que se puede ser a la hora de nombrar tcnicas. Luego se nombran los
principales proveedores y sus productos actuales; las prcticas actuales para combinar soluciones y los
estndares mas populares. Revisamos los objetivos de EAI y su evolucin. La aceptacin de los Web Services y
XML; y la sigla del momento SOA. Finalmente se comentan algunos pronsticos y los prximos pasos.

Qu es EAI?

Los negocios y la tecnologa han estado integrando aplicaciones desde el inicio de los tiempos, o al menos, desde
que creamos nuestras dos primeras aplicaciones. Uno de los mayores obstculos que encuentran aquellos que
quieren entender la tecnologa EAI, es que la definicin del acrnimo EAI siempre ha estado cambiando. Con la
expansin de las economas globales, la evolucin de la tecnologa y el marketing de los vendedores tratando de
establecer sus ventajas y posicin en el mercado, hay una confusin general sobre el significado de la integracin
empresarial de aplicaciones. Dos preguntas comunes e importantes se presentan hoy: Como definir EAI? y
Cmo puede beneficiar el negocio?

Definir EAI y no morir en el intento: simplemente nos referimos a la integracin de aplicaciones al nivel
empresarial. Proceso de integrar mltiples aplicaciones, que fueron desarrolladas de manera independiente, que
podran usar tecnologas incompatibles, y continen siendo administradas por separado.

EAI no es una tecnologa por s misma, sino una coleccin de herramientas, tcnicas y tecnologa que permiten a
la aplicaciones nter-operar de manera efectiva. Para tener una definicin completa de EAI, debemos echar un
vistazo a la evolucin de la industria tecnolgica. Actualmente es comn referirse a EAI como Integracin de
Negocios. Si bien distintas personas tienen diferentes ideas sobre lo que significa integracin de negocios, el
punto bsico es que la integracin 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 informacin, y proveer
informacin sobre demanda y donde sea necesaria, independientemente de la tecnologa. Ahora comprendemos
que los negocios estn marcando el rumbo de la tecnologa, y EAI es una suite de soluciones que soportan el
negocio. En la economa actual hay una gran demanda de servicios y soluciones provistos por EAI.

Muchos nombres, la misma intencin

En el vertiginoso mundo de la informtica de negocios y servicios parece no haber lmites a la hora de ponerle
nombres a las tcnicas y herramientas. En lugar de trabajar sobre estndares 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 ms una carrera armamentista que una bsqueda de soluciones. Por esto nos encontramos
con decenas de nombres y acrnimos a la hora de buscar en el mercado una solucin que se ajuste a nuestros
problemas.

Si bien es cierto que los problemas de sistemas que existen en las compaas son muy variados y amplios, el
estado tan segmentado del mercado informtico no aporta claridad sobre la cuestin. Haciendo un pequeo
relevamiento del estado del arte, nos encontramos con nombres como los siguientes:

EII (Enterprise Information Integration): dicen que integran a nivel de informacin. Logrando una visin
unificada de la informacin empresarial almacenada en distintas fuentes, y de manera sobre demanda. Problemas
que desde hace aos 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 informacin 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 integracin a nivel de presentacin. El fin es muy parecido al de EAI con la diferencia de que
pretenden que parezca mas sencillo. En realidad es una solucin mas limitada que EAI ya que no podemos tener
tanto control sobre la lgica de negocio.

Web Services: hay varios papers y artculos 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 integracin de aplicaciones, negocios e informacin, pero slo en parte. An hay muchos problemas para
integrar aplicaciones viejas o propietarias. Si es cierto que hoy en da Web Services cuenta con la ventaja de la
estandarizacin 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 confusin y poca claridad a la hora de definir las tcnicas y arquitecturas usadas tambin 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 ms de diez productos distintos. TIBCO
tambin hace su aporte a esta tortuosa odisea de armar la solucin 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 ms 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 seleccin de herramientas y la capacidad para conectarlas y administrarlas. Si bien varios
proveedores apuntan a brindar suites completas y aconsejan que slo se integre con sus productos, los
arquitectos apuntan a una combinacin 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 slo funcionan en
entornos Windows.

Entre los estndares mas populares estn 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 aos.

Drivers EAI hace 5 aos Drivers EAI hoy
Permitir a las empresas manejar sus negocios por
Internet mediante la interconexin de sus sistemas y
aplicaciones.
Agilizar y modernizar procesos de negocios
Internamente y a travs de toda la cadena de negocio
Mejorar la eficiencia, reducir el riesgo, y aumentar los
niveles de produccin
Manejar de manera conveniente sus aplicaciones y
sistemas ante cambios como adquisiciones, fusiones,
desregulaciones de mercados, etc.
Tomar EAI como una infraestructura tecnolgica
necesaria para el futuro de los proyectos informticos
de la compaa
Automatizar la ejecucin de aplicaciones en un
complejo proceso de negocios
Maximizar el Retorno de la Inversin hecha en los
aos anteriores.
Mejorar los niveles de produccin
Introducir rpidamente las nuevas ofertas en el
mercado


En el cuadro de evolucin se puede ver como las empresas van agregando valor e importancia a sus proyectos a
medida que pasan los aos. Actualmente la curva del grfico se mantiene pero en un perodo ms corto de
tiempo. La intencin 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 aceptacin a nivel mundial de los estndares de XML y Web services hacen que la mayora de las empresas
encaren sus proyectos de integracin de forma tal de incluir la tecnologa 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 estndar 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 informacin de
plizas en formato ACORD XML. Wall Street usa un formato de XML llamado FpML (Financial Products
Markup Language) para intercambiar subproductos financieros. Si contamos adems con que todas las
herramientas de integracin actuales dan soporte a este lenguaje, podemos imaginar la penetracin que tiene hoy
y lo importante que es para los proyectos de EAI.

La expansin de los Web Services y la proliferacin de servicios como componentes para armar infraestructuras
de negocios estn fomentando el uso de nuevas arquitecturas de desarrollo. En particular la ms usada es SOA
(Service Oriented Architecture). Los integradores han entendido que el camino a la flexibilidad, facilidad de
administracin y disminucin 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 diseo, desarrollo, implementacin y
administracin de distintas unidades lgicas (servicios) dentro de un entorno informtico.

SOA exige a los desarrolladores que diseen las aplicaciones como una coleccin de servicios, an si los
beneficios de ello no son aparentes. Requiere que los desarrolladores piensen ms all de los lmites de su
aplicacin y consideren la reutilizacin de los servicios o analicen como pueden ser rehusados. SOA demuestra
ser un mtodo para construir infraestructuras de software donde los componentes de IT son reunidos en servicios

de negocios poco acoplados que pueden ser invocados sin saber donde se ejecutan o en que plataforma. La
importancia de SOA proviene del hecho que introduce el reuso y brinda la habilidad de combinar servicios para
soportar nuevos procesos de negocios.

Los principales productos de EAI ya incluyen soporte para SOA como una de sus funciones mas importantes.
Estn pensados para la rpida creacin de Web Services y su integracin a otros entornos por medio de los
estndares conocidos.

Contar con una SOA es sinnimo de flexibilidad y facilidad de integracin, o por lo menos eso es lo que estn
intentando los nuevos productos para empresas. Basados fuertemente en los estndares conocidos en su mayora
en EAI y Web Services, los proveedores estn constantemente agregando propiedades de compatibilidad e
integracin a sus productos. Permitiendo a los encargados de IT mezclar soluciones de distintos vendedores y
as contar con las mejores herramientas.

Futuro

Segn el Integration Consortium (IC) hay cuatro puntos clave a tener en cuenta para el ao 2005: arquitectura
orientada a servicios (SOA), la batalla por la participacin en el mercado de los ESB (enterprise service bus), los
vendedores de soluciones luchando con sus estrategias de integracin, y la combinacin de business intelligence
y business integration.

Los Web Services, mas que el futuro son el presente, pero de todas formas seguirn siendo el centro de atraccin
de las inversiones y desarrollos. Van de la mano con SOA y en lo referido a integracin de negocios (B2B
Business-to-Business) es el estndar a seguir.

La tendencia como siempre es abaratar los costos y flexibilizar la tecnologa. Los grandes emprendimientos de
EAI darn lugar a desarrollos ms especficos y focalizados. Adems a medida que las empresas van adaptando
sus arquitecturas hacia una visin ms integradora y de servicios, los futuros cambios e incorporaciones sern
menos traumticos y ms sencillos. Los nuevos desarrollos de sistemas para negocios ya vienen con todo lo
necesario para su integracin con otras herramientas y plataformas.

EAI ha madurado, de integracin de aplicaciones a integracin de procesos de negocio y flujos de trabajo. La
tendencia es la automatizacin inteligente y la integracin colaborativa entre aplicaciones, involucrando los
procesos de negocio.

Conclusin

Las arquitecturas para el soporte de integracin, transformacin y manejo de mensajes entre aplicaciones
continan evolucionando. Es lgico 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 aplicacin. Hoy nos encontramos con una amplia gama de soluciones para la integracin, y empresas
especializadas en proveer herramientas para conectar los diversos sistemas empresariales. Lo que se busca es
velocidad de reaccin a los cambios de mercado, facilidad de mantenimiento y bajos costos.

Es llamativa la cantidad de artculos y papers que se publican sobre herramientas, tcnicas, estndares y todo lo
que tenga que ver con empresas, negocios e informtica. Tanto material termina confundiendo y haciendo muy
difcil la bsqueda de buenas soluciones. Asimismo es lamentable que los grandes proveedores no se pongan de
acuerdo para respetar estndares y arquitecturas.

Los Web Services y la arquitectura SOA parecen haber captado bastante atencin como para poner un buen
marco de trabajo y contar con el apoyo de los grandes proveedores de soluciones.

Para terminar tengo dos reflexiones:
No hay soluciones completas, buenas y baratas.
A veces las soluciones son tan confusas y rebuscadas que no se las distingue de los problemas.

Referencias
An Introduction to the True Definition of Enterprise Application Integration (EAI) The Integration Consortium
(enero 2004)

Integration Consortium Forecasts Integration Trends for 2005 Integration Consortium (nov 2004)

The EAI Paradigm Shift Madhavan Krishnan (abril 2004)

EAI Principles John Schmidt (mensual nov 2002 feb 2003)

EII: Dead on Arrival Andy Hayler (julio 2004)

Enabling Next Generation Enterprises John Schmidt (julio/agosto 2000)

Enterprise Application Integration Viewpoint Parker Shi & Suketu Gandhi (julio/agosto 2001)

Enterprise Application Portals Chuck Kao (feb 2001)

Role of EAI: Connect & Transform Enterprise Information - Sai Mungara (ago 2003)

SOA Today: Introduction to Service-Oriented Architecture - Jeremy Westerman (ene 2004)

Will Web Services Kill EAI? - Martin Bluter (mayo 2002)

EAI Market Predictions John Schmidt (marzo 2004)

Intelligent Solutions: What's an Architecture, Anyway? - Claudia Imhoff (dic 2004)
Links relacionados
www.eaijournal.com
www.ittoolbox.com
www.intelligententerprise.com
www.intelligentintegration.com
www.eai.ittoolbox.com
www.dmreview.com
www.bijonline.com


SOA Caso de Estudio
Pablo Michelis
pmicheli@cencosud.com.ar
Introduccin
El presente documento tiene como objetivo describir la arquitectura de la solucin implementada para resolver la
operacin distribuida de las tesorera de los locales.
Requerimientos
El objetivo del proyecto es construir un modelo de procesos para la administracin centralizada de las tesoreras
de las tiendas, que establezca estndares sobre la operatoria a travs de la incorporacin de mejores practicas a
partir de la implementacin de soluciones informticas.

Dada la distribucin geogrfica de las tiendas, la capacidad de los enlaces entre stas y la central, y la dificultad
de determinar el alcance definitivo del proyecto en trminos de cantidad de tiendas operativas, es que se hace
necesario permitir que la infraestructura sea escalable.
La naturaleza crtica de esta aplicacin radica en que podra llegar a administrar el 100% de la recaudacin de la
compaa, lo cual hace necesario un gran nivel de disponibilidad y seguridad. Es por este motivo que la
escalabilidad horizontal adems de permitir distribucin de carga, aumentar la disponibilidad de la solucin.
La escalabilidad horizontal es de fcil implementacin en niveles de aplicacin que no conservan estado
(stateless), pero se dificulta en los niveles de administracin de persistencia. Por este motivo los servicios de
persistencia se encontrarn 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 autenticacin, control de acceso y mensajera segura
entre los diferentes niveles de arquitectura.
En resumen, la aplicacin presenta a priori los siguientes requerimientos no funcionales:
Distribucin de carga.
Escalabilidad horizontal y vertical.
Autenticacin.
Control de Acceso.
Mensajera
Niveles de Arquitectura
El modelo conceptual est basado en la definicin de casos de uso, los cuales a su vez se descomponen en
interacciones entre cada actor y la aplicacin. Siendo el diseo consistente con este concepto, cualquiera sea el
cliente con el cual interacte el usuario, el mismo deber estar orientado a eventos y acciones, cuya resolucin
ser solicitada al back-end.
Las acciones y las respuestas debern poder ser transportadas hasta y desde el nivel de servicio de aplicacin.
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 tambin los requerimientos de
escalabilidad de la aplicacin, generan necesidades de distribucin de componentes de software. sta
distribucin implica tambin 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 poltica de distribucin y asignacin de responsabilidades.
La resolucin de cada accin implicar una reaccin que luego deber ser transportada hasta el usuario a travs
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 aplicacin lo llamaremos dispatcher.
En la descripcin de casos de uso, se asocian los actores con las interacciones habilitadas, estas asociaciones
componen luego la definicin de roles del sistema. Los roles sern vinculados a grupos definidos en una
estructura organizativa particular sobre el servicio de directorios, y la relacin entre stos y los usuarios del

mismo servicio de directorios nos brindar la informacin necesaria para implementar los servicios de
autenticacin y control de acceso sobre el LDAP
4
.
De este modo los usuarios se autenticarn normalmente contra el LDAP quien retornar el certificado, este
certificado ser adjuntado a las peticiones (acciones) durante el uso de la aplicacin 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 accin, un componente que actuar como agente de seguridad, verificar la autorizacin
del usuario tanto para la accin solicitada como as tambin para la informacin a la cual quiere acceder. De no
estar habilitada la operacin para el usuario o por estar intentando el mismo acceder a informacin no permitida,
se generar un evento de auditoria de seguridad en el log del sistema, y una excepcin de seguridad ser lanzada
al cliente
5
.
Las acciones autorizadas por el agente de seguridad son atendidas por un conjunto de gestores de servicio
6
. 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 distribucin de carga
deber ser orientado a servicios debido a los requerimientos sistmicos
7
. Los componentes que implementan la
recepcin, validacin y delegacin de servicios sern distribuidos y no persistirn. Por otra parte los objetos de
negocio sern persistentes recibiendo este servicio de una base de datos relacional. A fin de facilitar y acelerar la
codificacin se utilizar un framework para este propsito.

La Ilustracin 1 muestra un diagrama de representacin del modelo propuesto, en el cual resumimos los
siguientes niveles:
Nivel de presentacin: rendering
8
, lgica de presentacin, lgica de navegacin y captura de eventos.
Nivel de soporte de infraestructura: captura de peticiones de servicio del cliente, verificacin de permisos sobre
peticiones de servicio, transporte de excepciones, generacin de excepciones no funcionales
9
, delegacin de
peticiones de servicio a su gestor de servicio correspondiente, captura de resultado de ejecucin de servicio,
transporte de respuestas hasta el cliente y logging de eventos.
Nivel de Lgica de negocio: ejecucin de peticiones de servicio, mantenimiento de invariantes de negocio,
generacin de excepciones funcionales.
Nivel de persistencia: lgica de almacenamiento, caching y polticas de acceso a datos.

unObjetoDeNegocio
unObjetoDeNegocio
elAgenteDeSeguridad
unGestorDeServicio
unCliente
unaAccin
unAdaptadorDeCanal
transportar: unaAccin
unDispatcher
unaAccin
elCatalogoDeAcciones
existe: unaAccin puedeEjecutar: unaAccin
accion
respuesta
respuesta
recibir: unaRespuesta
unaRespuesta
unObjetoDeNegocio
accion
unObjetoDeNegocio
unObjetoDeNegocio
unObjetoDeNegocio
persistencia

Ilustracin 1: Niveles de Arquitectura

4
Servicio de Directorios
5
El transporte de esta excepcin entre los niveles de arquitectura ser tambin responsabilidad de la
infraestructura.
6
Faade pattern.
7
La complejidad del problema se implementa con cierta facilidad gracias al modelo basado en objetos, mientras
que las necesidades de distribucin son satisfechas por la arquitectura orientada a servicios. La impedancia
entre estos modelos es atendida en el nivel de gestores de servicio.
8
Presentacin visual de componentes e informacin.
9
Son las relacionadas con eventos no esperados provenientes de problemas sistmicos.

Requisitos de Diseo y Construccin
La Lgica de la Arquitectura
Durante la definicin de arquitectura tecnolgica, se establecieron los lineamientos tcnicos de infraestructura, y
se defini la utilizacin de .NET como soporte tecnolgico para la construccin y posterior ejecucin del
producto.
Segn se ha mencionado, la arquitectura del sistema se basar en servicios [Sprott2004]. La propuesta estndar
de Microsoft para esta implementacin es actualmente
10
MBI (Microsoft Business Integrator), el cual nos
brindar niveles de transporte desde el cliente hasta el nivel de servicio de aplicacin, manejo de eventos y
excepciones, distribucin y catlogo de acciones.
Los objetos de negocio sern implementados segn la especificacin de requerimientos, los cuales utilizarn los
servicios de persistencia a partir de DataObjects.NET
11
.
A pesar que los requisitos de seguridad exceden el estndar de la infraestructura tecnolgica, debido a que es
necesario definir el alcance de funciones de un usuario en funcin no slo del rol sino de la ubicacin donde est
autenticado, utilizaremos por cuestiones de performance la integracin de ADS con el MBI a partir de combinar
los grupos de usuario con la estructura organizativa propia de la aplicacin. 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 genrico indicar las acciones generales del rol (por ejemplo tesorero), mientras que los
usuarios debern ser asociados a grupos dentro de los contenedores del servicio de directorio. Por ejemplo un
usuario ser tesorero de Lomas, pero podra 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, locacin>.
En el momento de recibir una peticin, 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 operacin que est intentando efectuar. Cada vez que una accin est marcada para que registre sucesos
de auditora de seguridad, se logearn los intentos de efectuar operaciones invlidas en el EventLog.
La interfaz con el usuario est dividida en dos grupos de funciones. El primero se relaciona con la operacin 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 cadas generales pero con rpida
recuperacin. 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 distribucin (alto balance de carga
12
), mientras que el nivel de lgica de
negocio donde el estado es almacenado y alterado se encuentra en cluster
13
. Cabe aclarar que el dispatcher
requiere de un servicio adicional para el balance de carga llamado NLB
14
.
La Arquitectura Orientada a Servicios
15

Hasta aqu se realiz una descripcin lgica del modelo de software a ser implementado, la Ilustracin 2 nos
presenta un resumen de los componentes arquitectnicos y su relacin con la infraestructura.
Las Actividades invocan Acciones envindoles un mensaje a travs de un Adaptador de Canal . MBI provee
cinco Adaptadores de Canal distintos:
DispDirect: es un adaptador para aplicaciones nativas .Net
DispCOM: diseado para aplicaciones desarrolladas en tecnologa COM (VB 6.0, VC++, etc)
DispXML: pensado para la interoperabilidad, permite enviar mensajes como documentos XML
DispAIC: es un Adaptador diseado para ser "plug & play" con BizTalk Server.
DispInternal: para invocar Acciones desde otras Acciones

10
En Marzo 2005 MBI se convierte a Shadowfax.
11
Framework de persistencia para .NET extremadamente transparente para el desarrollador, para ms detalles
ver [DataObjects.NET].
12
Notar que la distribucin de carga es por mensaje ya que no existe el concepto de sesin.
13
Para la implementacin inicial el cluster ser responsable de los procesos de distribucin, est previsto poder
separar este nivel de ser necesario escalar horizontalmente.
14
Network Load Balancing
15
Fuente: Documentacin del Microsoft Business Integrator

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 comn
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 Accin para
obtencin 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 compilacin disminuyendo la
posibilidad de errores difciles 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 ms el desarrollo
Son serializables a documentos XML automticamente, de modo de facilitan la integracin con aplicaciones
externas
Son clases extensibles con los mecanismos tradicionales de la programacin orientada a objetos: herencia,
agregacin, composicin, etc.
Estn 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 diseadas especficamente 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 asociacin con un catlogo
maestro que detalla las caractersticas de las Acciones y Entidades definidas en el sistema e incluye informacin
de seguridad, control de acceso, tipo de registro en la bitcora central, requerimientos de transaccionalidad ACID
(provista por COM+) para esa accin, tiempo mximo de ejecucin de la Accin, etc.
Adems 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 sern interceptados por el Dispatcher antes de
reenviarlos a la Actividad y quedarn registrados en una nica bitcora central definible por el usuario. MBI basa
su mecanismo de control de fallos y errores en excepciones .Net.
Localizada la Accin, sta es invocada en las condiciones especificadas en el catlogo, pasndole el objeto
Request original ms informacin de contexto. Esta informacin de contexto contiene entre otras cosas:
La fecha y hora de invocacin:
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 ejecucin 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 Accin invocable por el runtime de MBI.
El objeto Command encapsula al Request, al Reponse y otra informacin de contexto que el Dispatcher pone a
disposicin de la Accin.
El Dispatcher cuenta adems con un sistema accesorio de "Health Monitoring" que permanentemente verifica el
correcto funcionamiento del mismo. Si encuentra problemas se pueden definir polticas para su salvaguarda,
incluyendo reinicio completo del sistema en casos extremos.
Servicios Comunes de MBI
Log de Transacciones:
Las Acciones se pueden configurar, va el catlogo, 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 asincrnicas de forma tal de minimizar el impacto de performance en
la Accin. Este servicio interacta ntimamente con los mecanismos de integracin y de soporte a procesos de
negocio (BPM) de MBI.
Soporte Transaccional ACID:

El modo transaccional que soporta una Accin no es necesario definirlo programticamente. Esto significa que el
entorno crear automticamente, de acuerdo a las definiciones del catlogo de acciones, un contexto
transaccional adecuado basado en el soporte de COM+. De esta forma una Accin puede calificarse segn:
No soporta transacciones
Soporta
Requiere
Requiere una nueva transaccin
Ningn requerimiento especial
Si ocurre una falla, debe generase siempre una Excepcin, el Dispatcher iniciar automticamente los "rollbacks"
necesarios en cada uno de los recursos transaccionables (XA/LU6.2)
Gerenciamiento de Lotes:
El Dispatcher puede procesar una o ms 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 accin del lote en su propia transaccin o alternativamente generar una
transaccin global para el lote completo. Tambin puede especificarse la poltica de cancelacin del lote: ignorar
la accin fallida y continuar o abortar todo el lote a la primera falla. El modo transaccional y la poltica de
cancelacin son combinables.
Servicio de Cuadratura de Transacciones:
Opcionalmente MBI puede verificar que toda accin que comenz su ejecucin haya finalizado y dejar un
registro de todas aquellas que o por timeout o por cuestiones externas hayan quedado sin resolucin. Este
servicio est diseado para manejar el concepto de "compensacin" de transacciones, de modo de poder dejar
registro de transacciones importantes que requieran de confirmacin de su ejecucin (tanto positiva como
negativa, pero no indefinida). La tabla de estado de las acciones en ejecucin y finalizadas se administra a travs
de componentes reemplazables: el runtime de MBI incluye un proveedor basado en SQL Server 2000.
Administracin de Parmetros:
El MBI provee dos mecanismos para el suministro y administracin de parmetros a los sistemas. En el primero
de ellos los parmetros se almacenan como pares <"nombre", "valor">. En el segundo, se provee adems una
organizacin jerrquica de los mismos con calificadores de "Entorno", "Mdulo", "Submdulo" y "Nombre".
Este servicio es pblico 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 tecnologa 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 parmetro "plano" denominado "DATABASE". En el
segundo, como obtener un parmetro denominado "PORT" del entorno "PROD", mdulo "CLIENTES",
submdulo "ALTA".
La ventaja es que se cuenta con un nico repositorio de parmetros de configuracin 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 Ejecucin:
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 configuracin maestra de MBI
que pueden ser referenciadas por nombre, de modo de librar al desarrollador del problema de lidiar con "cadenas
de conexin" (Connection strings), etc. Las conexiones disponibles son SqlConnection y OleDbConnection para
SQL Server 2000 y otras bases de datos accesibles va OLEDB respectivamente.
Ejemplo:
SqlConnection conn = Context.GetSqlConnection( "CUENTAS" );
Esta sentencia crear una conexin a la base CUENTAS tal cual fuera definida en la configuracin maestra de
MBI.
El contexto adems 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 mquina o la fecha calendario y obedece a
reglas de negocio relativamente complejas. MBI permite definir un "proveedor de Fecha y Hora" para ponerlo a
disposicin, a travs del contexto, de quienes desarrollan las acciones.
Date Now = Context.SystemDateTime();

Por ltimo el contexto tambin provee la identidad del usuario que invoca la Accin, conforme lo especifica
Microsoft.NET. Esto permite, por ejemplo, consultar programticamente los roles asignados al usuario y tomar
decisiones de negocio respecto a eso.
En un programa:
If( Context.GetUser().IsInRole( "Oficial de Crdito 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 excepcin 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
registrarn eventos y fallas en los dos simultneamente.
Adems MBI define dos Excepciones especializadas para ser utilizadas en las aplicaciones:
TechException
Para reporte de problemas tcnicos:
No hay conexin a la base de datos, timeout, etc.
FunctionalException
Para reporte de problemas funcionales:
La cuenta es invlida, cliente dado de baja, insuficientes privilegios, etc.
El Dispatcher registra estas excepciones automticamente. Subsidiariamente, el registro puede ser explorado
programticamente utilizando la interfaz IEventLogBrowseProvider.
Catlogo de Acciones:
El catlogo de acciones sirve como repositorio para el control de ejecucin del sistema, adems de proveer las
bases para la documentacin 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
Descripcin
Componente fsico que implementa la Accin (Namespace.Clase,Assembly)
Mensajes de entrada y salda (Request y Response)
Caractersticas de logging
Caractersticas de transaccionalidad ACID
Roles de usuario para los cuales esta habilitada
Entidad
Evento que genera
El acceso a este repositorio es programtico y MBI provee una herramienta con una interfaz de usuario que
permite explorar el catlogo, dar de alta nuevos registros, hacer modificaciones, etc.
Obsrvese 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 mtodo de acceso a las Entidades estn
documentadas de facto y por lo tanto se pueden construir herramientas que exploten este catlogo y asistan en el
desarrollo y descubrimiento de funcionalidad.

Despliegue de Componentes
Esta seccin describe los instalables en cada caja de hardware requeridos por toda la infraestructura de la
aplicacin, la Ilustracin 3 muestra el diagrama de despliegue que resume los siguientes componentes y
protocolos:

Componentes Instalables
MS - SQL Server 2000 Este componente implementa el servicio de base de
datos.
DataObjects.NET Client
Este componente implementa el marco de persistencia y consiste
en un conjunto de objetos .NET al cual hace referencia el
componente SAV Business Objects.
No se requiere monitoreo de este componente por el grupo de
operaciones.
El package de instalacin del application server
incluir la instalacin de este componente.
MS Framework.NET 1.1 Este componente implementa el runtime necesario

para la ejecfucin de los objetos .NET (CLR). Es
el componente Microsoft .NET Framework 1.1.
MS Message Queueing Este componente implementa un servicio de colas
necesario para la mensajera asincrnica de MBI.
Es el servicio Message Queue Server de
Microsoft para W2000.
SAV Business Objects Este componente implementa el servicio de Objetos
de Negocio. Consiste en un conjunto de objetos
.NET que implementan la lgica del negocio.
Estos componentes son los provistos por Autosys
Software a fin de implementar la solucin.
El package de instalacin del application server
incluir la instalacin de este componente.
MBI Dispatcher Este componente implementa el servicio de
distribucin (Dispatcher en Ilustracion_2). Consiste
en un servicio llamado Framework Dispatcher
Server que es instalado junto con el paquete de
MBI. La informacin detallada del modo de
instalacin se puede obtener de [MBIInstalacin]
MS IIS.NET Servicio de Web App Server
MBI Administrative Tools Este componente implementa las herramientas
administrativas necesarias para configurar el MBI.
La interfaz de la misma es Web, por lo que debe ser
instalado junto con el IIS.
SAV MBI Common Assemblies Este componente implementa las Class
Libraries.NET response y request segn se ha
descrito en La Arquitectura de Servicios. Para la
instalacin existir un package para cada
subsistema, el cual ser compartido por el cliente y
el server que brinde los servicios del respectivo
subsistema.
MS Iexplorer 5.0
SAV Resources Consiste en los mensajes y etiquetas definidos en
tiempo de compilacin, que son dependientes solo
del idioma en el cual est siendo ejecutado el
cliente.
MBI Channel Adapter Este componente implementa las funciones de
empaquetado de mensajera entre el cliente y el
server. Fsicamente consiste un una dll copiada al
directorio de la aplicacin.
MS OS Cualquier sistema operativo Microsoft que pueda
ejecutar Microsoft Internet Explorer 5.0 o superior.
MS Desktop OS Windows 2000 Professional o Windows XP
Professional.
MS Server OS Windows 2000 Server o Windows 2003.
La instalacin ser tcitamente la copia de las dlls que implementan las mismas a un directorio del
cliente WinForm, del aplication server y del directorio exportado desde el Web Server.

Equipos y Componentes
Servidor de Datos MS SQL Server 2000
MS Server OS
Servidor de Aplicaciones DataObjects.NET Client
MS Framework.NET 1.1
MS Message Queueing
SAV Business Objects
SAV Resources
MS Server OS
Servidor de Distribucin MS Framework.NET 1.1
MS Message Queueing
MBI Dispatcher
SAV MBI Common Assemblies

SAV Resources
MS Server OS
Servidor Web MS Framework.NET 1.1
MS IIS.NET
MBI Administrative Tools
SAV Resources
MBI Channel Adapter
MS Server OS
Cliente WinForm MS Framework.NET 1.1
SAV Resources
MBI Channel Adapter
MS Desktop OS
Cliente Web MS Iexplorer 5.0
MS OS

Protocolos y Componentes
.NET Remoting Servicio de Dispatcher Se implementa sobre IP en un puerto prefijado que
es el 6001. Esta configuracin es almacenada en
una archivo de configuracin XML (fmw.config) en
el server.
* Notar que este puerto es el nico que debe ser
visible por los clientes WinForm. Esto hace posible
filtrar fuera de la infraestructura cualquier otro tipo
de acceso.
.NET Remoting Gestores de Servicio Este protocolo es interno en el sentido que no es
exportado mas alla del nivel de servicio de
aplicacin. Los nmeros de puerto utilizados sern
definidos luego de la especificacin de diseo de
cada gestor.

SQL Connection Es una coneccin 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 conexin es necesaria para que el dispatcher
conozca si las acciones solicitadas estn
catalogadas. Este catlogo podra residir en una
instancia de SQl Server diferente que el modelo de
negocio.
http

Presentacin Procesos y Lgica de Negocio Persistencia
Actividades
Entidad
Gestor de
Servicios
Base de
datos
Marco de
Persitencia
Resp.
Req.
Despachador
Req. +
Contexto
Resp.
Adaptador
de canal
Log. de excepciones
Configuracin
Contexto
Log. de
transacciones
Catlogo
Control
de terminacin
Administrador de consola
Capa de Servicios Comunes
Objeto de
Negocio
Resp.
Req.
Agente de
Seguridad
Accin +
Credencial
Mensaje Resp.
Presentacin Procesos y Lgica de Negocio Persistencia
Actividades
Entidad
Gestor de
Servicios
Gestor de
Servicios
Base de
datos
Marco de
Persitencia
Marco de
Persitencia
Resp.
Req.
Despachador
Req. +
Contexto
Resp.
Adaptador
de canal
Log. de excepciones
Configuracin
Contexto
Log. de
transacciones
Catlogo
Control
de terminacin
Administrador de consola
Capa de Servicios Comunes
Objeto de
Negocio
Objeto de
Negocio
Resp.
Req.
Agente de
Seguridad
Accin +
Credencial
Mensaje Resp.

<.NET Remoting>
<.NET Remoting>
http
Presentacin Presentacin
Procesos y Lgica de Negocio Persistencia
Cliente WinForm
MS - Framework .Net 1.1
MS - MBI 2.0 (Channel Adapter)
SAV - MBI Common Asembly
SAV - Resources
MS - Desktop OS
Servidor de Web
MS - IIS .Net
MS - MBI 2.0 Administrative tools
SAV - MBI Common Asembly
SAV - Resources
MS - Server OS
<SQL Connection>
<.NET Remoting>
Servidor de Distribucin
MS - Message Queueing
MS - MBI 2.0 (Dispatcher)
MS - Server OS
<<MS - ADO .Net Connection>>
Servidor de Aplicaciones
MS - Message Queueing
Data Object .Net (Client)
SAV - Business Objects
MS - Server OS
Servidor de datos
MS - SQL Server 2000
MS - Server OS
Cliente WebForm
MS - IExplorer
MS - OS

Ilustracin 3: Diagrama de Despliegue
Referencias
[MBIInstalacin] Microsoft Business Integrator Gua de Instalacin (Guia de Instalacion_sp.doc)
[Sprott2004] Understanding Service-Oriented Architecture (http://msdn.microsoft.com/architecture/soa -
Understanding Service-Oriented Architecture)
[DataObjects.NET] DataObjects.NET Manual (http://www.x-
tensive.com/Data/Downloads/DataObjects.NET/DataObjects.NET%20Manual.pdf)
Ilustracin 2: Niveles de Servicio

Model Driven Architecture
Lic Gerardo Rossel Catardo
grossel@computer.org

Introduccin

MDA es bsicamente tres cosas:
Una iniciativa del OMG para desarrollar estndares sobre la idea de que modelar es un mejor
fundamento para desarrollar y mantener sistemas.
Un conjunto de estndares y productos que adhieren a esos estndares
Un conjunto de tecnologas y tcnicas asociadas con esos estndares.

La base del desarrollo de MDA es aumentar el nivel de abstraccin, la propia historia de la computacin puede
verse como la historia de elevar el nivel de abstraccin. La idea es que la abstraccin respecto a la plataforma de
hardware es anloga a la abstraccin respecto a la plataforma de software como se muestra en la siguiente figura:


Nada Plataforma de Hardware Plataforma de Software
Assembler
Cdigo Assembler
Cdigo Lenguajes de Alto
Nivel
Modelos Ejecutbles
Compiladores Cdigo
Fuente
Compiladores de
Modelos
Cdigo Mquina
1960s
Cdigo Assembler
1980s
Cdigo Fuente
2000s

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 proliferacin de midlewares plantearon la
necesidad de realizar un estndar 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 aplicacin desarrollada bajo MDA se basa en un modelo UML
independiente de la plataforma.
El estndar MDA provee una metodologa 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 especificacin del sistema para una plataforma particular (la elegida en el paso anterior)

Construyendo una aplicacin MDA

Se comienza con un Modelo Independiente de la Plataforma (PIM Platform-Independent Model) el cual
representa la funcionalidad y comportamiento del negocio sin ningn detalle de tecnologa. El PIM es un modelo
detallado estableciendo Pre y Poscondiciones mediante OCL y la semntica en un Action Language.
PIM
Modelo
Independiente
de la
Plataforma

Luego se mapea el PIM a una tecnologa de middleware especfica utilizando los mapeos estndares del OMG.
El cdigo es parcialmente automtico y parcialmente escrito a mano. Es posible mapear un PIM a muchas
tecnologas de middleware. Esto genera lo que se conoce como Modelo Especfico de la Plataforma (PSM,
Platform-Specific Model)


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 cdigo para la tecnologa seleccionada.
Bsicamente, mapea PSM a interfaces de la aplicacin, cdigo, 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

Ingeniera de Reversa y Bridge Generation

Las herramientas MDA para ingeniera de reversa automatizan el descubrimiento de modelos para la
reintegracin sobre nuevas plataformas.


PIM
Modelo
Independiente
de la
Plataforma
Aplicaciones
Legadas
Otros Modelos
Otros
CTOS

La generacin de puentes se simplifica mediante los modelos de aplicaciones comunes simplificando la
integracin de aplicaciones entre empresas y dentro de la empresa.

PIM
Modelo
Independiente
de la
Plataforma
Modelo
CORBA
Modelo
.NET
CORBA
System
.NET
Bridge de
Interoperacin

Detalle de Conceptos utilizados en MDA
Modelo
Un modelo consiste de un conjunto de elementos que describen alguna realidad fsica, abstracta o hipottica. Los
modelos sirven como un medio de comunicacin y son ms sencillos de construir que las cosas reales.
En MDA se crean diferentes modelos a diferentes niveles de abstraccin y se vinculan para formar una
implementacin. Algunos de los modelos son independientes de la plataforma de software (PIM) y otros no
(PSM). Los modelos se expresan mediante una combinacin de texto y diagramas donde UML juega un rol
fundamental.
Plataforma
En MDA se define una plataforma como la especificacin de un entorno de ejecucin para un conjunto de
modelos. Algunas plataformas son J2EE, CORBA, .NET, etc. Una plataforma debe tener una implementacin de

la especificacin: es lo que se denomina realizacin. La realizacin 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 semnticas entre s. MDA soporta el desarrollo interactivo incremental por lo cual
el mapeo entre modelos debera ser repetible. De esta forma se pueden expresar los diferentes aspectos de un
sistema con su nivel de abstraccin apropiado manteniendo los modelos en sincrona.
Un mapping entre modelos toma uno o ms modelos como entrada y produce un modelo como salida. La reglas
para el mapping se describen mediante mapping rules en una funcin de mapeo. El mapeo en s, es una
aplicacin de la funcin 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 comunicacin con los clientes, de un sistema
funcionando. Los modelos ejecutables no son exactamente lo mismo que el cdigo, 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
semntica de ejecucin para un subconjunto computacionalmente completo de UML.
MOF Meta-Object Facility.
MOF es la tecnologa 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 ms conocido y usado basado en MOF. El metamodelo de UML es un modelo MOF.

CWM Common Warehouse Meta-model
CWM es un estndar del OMG. Bsicamente es un lenguaje de modelizacin especfico 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 disear CWM se removi todo aquello que no fuera necesario para su objetivo y se agregaron aquellas cosas
especficas para el dominio de los data warehousing. No existen en CWM aspectos de modelizacin de
comportamiento de UML (diagramas de colaboracin por ejemplo).

MDA vs. Desarrollo Tradicional
MDA comienza desde un nivel de abstraccin ms alto que otros procesos de diseo. El modelo de ms alto
nivel (PIM) es muy abstracto: entidades y servicios. El PSM es una descripcin completa del sistema en forma
de metadatos (es posible en este nivel incorporar al diseo caractersticas especficas de la tecnologa).
El cdigo que se genera a partir del PSM es muy cercano a la aplicacin completa. Los algoritmos que generan
PSM desde PIM y el cdigo desde PSM deberan ser configurables por el arquitecto.

MDA y Desarrollo Offshore
Muchas empresas de los pases centrales estn utilizando la mecnica del desarrollo offshore. Cmo esto se
ubica en el desarrollo usando MDA? Las empresas realizan lo que se denomina modelizacin onshore: los
arquitectos y diseadores producen modelos formales, luego las herramientas MDA generan cdigo y entonces
los programadores offshore desarrollan el cdigo que falta. Esta metodologa requiere un fuerte proceso de
desarrollo para lograr la coordinacin adecuada.

Adems el uso de patrones de diseo y CBD (component-based development) preceden a MDA. Actualmente es
evidente que requerir a los programadores que manualmente codifiquen cada instancia de un patrn 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 pequea cantidad de trabajo adicional de un programador,
ver la figura (extrada del MDA Journal).

Productos
En esta seccin se describen algunos productos comerciales que implementan MDA. Algunos tienen
limitaciones y no son completos pero dan una idea de la factibilidad de la tecnologa.
ArcStyler de Interactive Objects


ArcStyler permite capturar la lgica de la aplicacin en modelos, los cuales son trasformados automticamente a
varias tecnologas. Es completamente compatible con MDA del OMG.
Utiliza el concepto de MDA-Cartridges que son mquinas enchufables (pluggables) que contienen entre otras
cosas la lgica de transformacin modelo a modelo y modelo a cdigo. Los cartridges son adems 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 econmicas est la de contar con una edicin 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
administracin de requerimientos textuales, a travs de la modelizacin hasta la generacin del 100% del cdigo.
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
PRODUCE TARGET CODE
Automatically apply design
patterns to xUML models
using code generation
VALIDATE ANALYSIS
Integrate multiple domain
models using bridges
Execute domain use cases
Execute system use cases
FORMALISE ABSTRACT
DESIGN MODEL
Select or develop suitable
translation rules, patterns and
mechanisms
Build or Buy an xUML complier

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

automticamente a diversas bases de datos y las mismas son modificadas segn evolucionen los modelos de
diseo.
ECO II hace fuerte uso de OCL para trabajar con el modelo. Por ejemplo, es posible vincular un componente
visual al resultado de una expresin OCL sobre el modelo.
La siguiente imagen muestra a Delphi 2005 (IDE en donde viene integrado ECO II) en una sesin de
modelizacin:

Conclusiones
MDA apunta fundamentalmente al desarrollo productivo y provee una visin basada en la construccin de
modelos independientes de la plataforma. Un conjunto de tecnologas 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 aceptacin de las herramientas MDA aunque no se ha extendido su uso en forma
masiva. Juntamente a MDA surgen las metodologas de aplicacin como ser Agile MDA (basada en los mtodos
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 diseo consistentes. Adems, en trminos de codificacin y calidad de la aplicacin, una
observacin mostr que los defectos encontrados en los mtodos de codificacin manual requeran arreglo y
retesting, esto impacta en la productividad del desarrollo. El grupo de MDA usaba generacin automtica va
patrones y no requera estos pasos para la construccin de la aplicacin. La tabla siguiente muestra el resultado
en cantidad de horas.


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

Bibliografa
[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 ArchitectureBuilding 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


Integracin de Aplicaciones con Web Services
Pablo Cecconi
pc@educ.ar

Acerca de este documento
Este documento analiza la utilizacin de Web Services como tecnologa para el desarrollo de middlewares de
integracin de aplicaciones.
En primer lugar se presenta el contexto del problema, se realiza un anlisis de las opciones y se presenta una
solucin genrica.
Luego se introducen los Web Services, explicando a grandes rasgos su funcionamiento y las tecnologas que los
soportan para profundizar luego un poco ms especficamente en SOAP.
Finalmente se explica cmo podran utilizarse las tecnologas descriptas para solucionar el problema de la
integracin de aplicaciones y el soporte que los diferentes fabricantes ofrecen a esas tecnologas.
Introduccin
Casi todas las empresas, instituciones u organismos gubernamentales cuentan con diferentes reas o
departamentos que usan uno o ms sistemas informticos y bases de datos especficos para realizar sus tareas y
administrar su informacin. 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 informacin de diferentes fuentes, evitar la duplicacin de informacin y los problemas de
consistencia asociados o bien ofrecer servicios que utilicen Internet, e-commerce u otras tecnologas nuevas.
Durante muchos aos, los departamentos de sistemas de las empresas desarrollaron soluciones punto-a-punto y
los desarrolladores de middleware escribieron millones de lneas de cdigo con el objetivo de lograr
interoperabilidad entre aplicaciones y datos. Debido a la proliferacin de diferentes soluciones ofrecidas por
distintos proveedores de software y empleando distintas tecnologas 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 utilizacin de Web Services (SOAP y otras tecnologas 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 integracin y una descripcin de los
productos ms importantes disponibles en el mercado que soportan esta tecnologa.
El Problema: La Integracin
Las empresas en general poseen una variedad de aplicaciones que proveen niveles de interaccin que
van desde lo muy simple a lo muy complejo. Las funcionalidades includas 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 integracin de aplicaciones es necesario tener en cuenta
las siguientes consideraciones:
La mayora de las empresas poseen mltiples sistemas que nunca fueron diseados para trabajar
juntos. Las unidades de negocios que son las bases de estos sistemas tienen su foco en los
requerimientos funcionales ms que en las arquitecturas. Debido a que los sistemas desarrollados a
lo largo de la vida de una empresa varan mucho en trminos de arquitecturas, las empresas suelen
tener una mezcla de sistemas con arquitecturas incompatibles.
Muchas aplicaciones estan organizadas en 3 capas lgicas: presentacin, lgica de negocios y datos.

La mayora de las aplicaciones de negocios comerciales desarrolladas en la ltima dcada proveen
interfaces de programacin documentadas para permitir el acceso a las funcionalidades de negocios
incorporadas en la aplicacin. Los proveedores de software ofrecen estas APIs especficamente para
permitir la integracin con software externo.
Las interfaces funcionales que provee una aplicacin tpicamente se abstraen de la representacin
subyacente de los datos y son por lo tanto ms estables.
Acceder a una funcin que reside en otra aplicacin resulta una extensin natural del modelo de
programacin de aplicaciones tradicional al que los desarrolladores estn habituados. La semntica
para acceder a una funcin externa que reside en otra aplicacin es similar a hacer una llamada a un
mtodo local. Esto permite una integracin natural con aplicaciones existentes.
Hacer actualizaciones directas al repositorio de datos de otra aplicacin (Integracin a nivel de
datos) pasa por encima de toda la lgica de negocios y las validaciones incorporadas en la capa de
lgica de negocios de la aplicacin. Como resultado, existe un alto de riesgo de corromper el
repositorio de datos de la aplicacin.
Muchas interfaces de programacin son especficas de un cierto lenguaje y no estn disponibles
remotamente a no ser que hayan sido desarrolladas sobre una tecnologa especfica como ser el
Microsoft .NET framework o Common Object Request Broker Arquitecture (CORBA).
Solucin
Integrar aplicaciones a nivel de la capa de lgica de negocios permitiendo que las funciones de
negocios de una aplicacin (la fuente) sean accedidas por otras aplicaciones (el destino) como se
muestra en la figura 1 (pgina Error! Bookmark not defined.).
A este tipo de integracin se lo denomina integracin funcional. Para que una aplicacin externa pueda
integrarse con la aplicacin fuente a travs de integracin funcional deben satisfacerse dos condiciones:
La funcin de negocios que se desea debe estar disponible dentro de la lgica de negocios de la
aplicacin fuente.
La API de la aplicacin fuente debe ser accesible remotamente.
Figura 1. Integracin de aplicaciones en la capa de lgica de negocios

Si la funcin de negocios deseada no est disponible, es necesario modificar la aplicacin fuente. Si esto ltimo
no fuera posible se debera agregar la nueva funcin por fuera y luego comunicarse con la aplicacin a travs de
alguna otra forma de integracin, tal como integracin a nivel de datos o a nivel de presentacin. Este enfoque
tiene menos efectos colaterales y est generalmente disponible en la mayora de los tipos de aplicaciones.
Muchas aplicaciones solo exponen sus funciones de negocios como una API local dependiente de un lenguaje de
programacin 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
genricos como para soportar diferentes funciones sin tener que modificarlos para cada funcin que se
quiera publicar.


Contexto resultante
La integracin funcional es uno de los patterns ms comunmente usados para integracin 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 integracin debe elegir la manera ms
apropiada segn su situacin. Las opciones disponibles se resumen en los siguientes patterns:
Integracin a travs de objetos distribuidos
Integracin a travs de un middleware orientado a mensajes
Integracin orientada a servicios (a travs de Web Services basados en XML)
En el presente documento se discute solamente cmo la ltima de estas opciones puede ser usada para
integracin funcional de aplicaciones y cmo es soportada por los principales frameworks de aplicaciones como
Microsoft .NET y Java 2 enterprise edition [J2EE].
La Tecnologa
Web Services
Los Web Services proveen un mecanismo estandar para que las aplicaciones puedan publicar y
subscribirse a servicios de software a travs 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 definicin de la interfase usando Web Services Description Language (WSDL), e
intercambiar datos usando documentos XML a travs de SOAP sobre protocolos universales tales
como HTTP, FTP, y SMTP.
Una definicin ms formal de Web Services de acuerdo con IBM es la siguiente:
Los Web Services son un nuevo tipo de aplicacin Web. Son aplicaciones auto-
contenidas, auto-descriptas, que pueden publicarse, localizarse y ser invocadas a travs
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 pginas 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 descripcin en formato WSDL de los Web Services disponibles en el servidor;
un mensaje de estado tal como la indicacin de que un recurso no est disponible o que una transaccin fue
exitosa; o datos encapsulados en un documento XML bien formado.
Para la aplicacin cliente de un Web Service, ste aparece como una llamada a un mtodo local, solo que la
llamada es traducida a XML (basndose en el estandar SOAP) y enviada a travs de la red a la aplicacin
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 sera 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 lgica de negocios, que puede ser implementada a su vez por una
plataforma de middleware tradicional (RMI, CORBA, DCOM, etc.) como se ilustra en la siguiente figura:

Debido a que los Web Services son accesibles usando URLs, HTTP, y XML, estn al alcance de cualquier
aplicacin desde cualquier plataforma de software o hardware.
Tal como se mencion ms arriba, las principales tecnologas 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 tecnologa fundamental que es SOAP con el objetivo de dar una idea ms clara de las
potencialidades de los Web Services como medio de integracin de aplicaciones.
SOAP
En un principio SOAP, que originalmente significaba Simple Object Access Protocol, fue una
tecnologa pensada para hacer que DCOM y CORBA funcionaran a travs de Internet. Sin embargo,
con el tiempo el foco de la especificacin se ampli con el objetivo de servir a una audiencia mucho
ms amplia y se convirti as en un framework generalizado de mensajera basada en XML.
Este cambio de foco provoc un problema con la O en el acrnimo, lo que tuvo como consecuencia que el
SOAP 1.2 Working Group decidiera no deletrearlo para evitar confusiones. As, la definicin oficial actual, que
se encuentra en la ms reciente especificacin de SOAP 1.2, ni siquiera menciona los objetos:
SOAP es un protocolo liviano pensado para intercambiar informacin estructurada en
un ambiente descentralizado y distribuido. SOAP utiliza tecnologas XML para definir un
framework de mensajera extensible, que provea una construccin de mensaje que pueda
ser intercambiada sobre una variedad de protocolos subyacentes. El framework fue
diseado para ser independiente de cualquier modelo de programacin particular u
otras semnticas especficas de implementacin.
SOAP define una manera de mover mensajes XML desde el punto A al punto B (ver figura 2 en la pgina
Error! Bookmark not defined.). Para lograrlo provee un framework de mensajera basado en XML que es 1)
extensible, 2) usable sobre una variedad de protocolos de red subyacentes, y 3) independiente de modelos de
programacin.

Figura 2. Mensajera 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 tpicos de sistemas distribuidos como la seguridad, el ruteo, etc. la simplicidad contina
siendo uno de los objetivos primordiales de diseo de SOAP. Mientras tanto, Microsoft, IBM y otros
proveedores de software estn trabajando en un conjunto comn de extensiones a SOAP para agregarle estas y
otras caractersticas que la mayora de los desarrolladores espera encontrar. La iniciativa se denomina Global
XML Web Services Arquitecture (GXA) y Microsoft ya liber una implementacin de referencia de varias de
esas especificaciones bajo el nombre de Web Services Enhancements 1.0 SP1 for Microsoft .NET (WSE).
En segundo trmino, SOAP puede usarse sobre cualquier protocolo de transporte tal como TCP, HTTP, SMTP, o
incluso MSMQ. La especificacin de SOAP provee un framework flexible para definir bindings de protocolo
arbitrarios y provee un binding explcito para HTTP debido a su popularidad de forma tal de mantener la

interoperabilidad. Ms an, el modelo de procesamiento de SOAP permite incluso la presencia de mltiples
nodos intermediarios cada uno con su propio protocolo, como lo ilustra la figura 3.

Figura 3. Mensajera sofisticada en SOAP

Finalmente, SOAP no est restringido a ningn modelo de programacin ni est atado a RPC. SOAP define un
modelo para el procesamiento individual de mensajes de una sola va y pueden combinarse mltiples mensajes
en un intercambio de mensajes completo. En la figura 2 se ilustra un mensaje donde el emisor no recibe
respuesta, pero el receptor podra enviar una respuesta al emisor como lo ilustra la figura 4 (pgina 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 mensajera
El ncleo de SOAP es el framework de mensajera 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 genrico para cualquier nmero de
elementos de cualquier namespace; por lo tanto es aqu donde finalmente van los datos que se desean enviar.
Por ejemplo, el siguiente mensaje SOAP representa un pedido para transferir fondos entre dos cuentas bancarias:

<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<x:TransferFunds xmlns:x="urn:examples-org:banking">
<from>22-342439</from>
<to>98-283843</to>
<amount>100.00</amount>
</x:TransferFunds>
</soap:Body>
</soap:Envelope>
Si el receptor soporta request/response y puede procesar el mensaje exitosamente, podria enviar otro mensaje
SOAP de vuelta al emisor como ilustra el siguiente ejemplo:


<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<x:TransferFundsResponse
xmlns:x="urn:examples-org:banking">
<balances>
<account>
<id>22-342439</id>
<balance>33.45</balance>
</account>
<account>
<id>98-283843</id>
<balance>932.73</balance>
</account>
</balances>
</x:TransferFundsResponse>
</soap:Body>
</soap:Envelope>
El framework tambin define un elemento llamado Fault para representar errores. Esto es esencial ya que sin una
representacin estandar para los errores cada aplicacin debera inventar la suya y sera imposible que una
infraestructura genrica distinga entre xito y fracaso de una operacin.

Integrando con SOAP
La integracin orientada a servicios es un pattern posible para realizar integracin funcional que
conecta sistemas permitiendoles consumir y proveer Web Services basados en XML. Las interfases
con esos sistemas se describen a travs de contratos de Web Services Definition Language (WSDL).
Los sistemas interactan unos con otros utilizando mensajes SOAP, generalmente a travs de HTTP
utilizando serializacin.
En este esquema una interface de servicio expone la funcionalidad como Web Service y un Service Gateway
encapsula en el consumidor la lgica necesaria para acceder a los servicios como muestra la siguiente figura:

Figura 5. Conexin entre un proveedor y un consumidor de Web Services

La integracin 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 mensajera. Mientras que XML Schema
provee un sistema de tipos portable entre arquitecturas tcnicas dispares, SOAP provee un framework de
mensajera extensible que no est atado a ninguna implementacin propietaria o protocolo de transporte y
permite el intercambio de mensajes sincrnicos o asincrnicos segn 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 serializacin, deserializacin y parsing de los documentos XML. Adems, los
documentos XML son, en general, mucho ms grandes que sus equivalentes binarios porque contienen
metadatos y esto podra incrementar el tamao 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 podran
resolverse a travs de hardware ms potente. Adems, existe la posibilidad de negociar interoperabilidad por
performance usando una codificacin binaria dentro de los mensajes SOAP si fuera necesario. Finalmente, dado
que esta estrategia cuenta con el apoyo de los ms grandes proveedores de software, es muy probable que
evolucione de forma tal de resolver los problemas de performance existentes hoy en da.
Soporte de los fabricantes
Casi todas las ltimas versiones de los principales entornos de desarrollo integrados de aplicaciones y
aplicaciones de diseo 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, compaias como Rational y
TogetherSoft proveen herramientas de diseo y modelado que tambin integran estas tecnologas.

Adems, la mayora de las herramientas mencionadas ofrecen mtodos muy sofisticados para incorporar Web
Services en las aplicaciones. En muchos casos, el proceso es casi idntico a comunicarse con un objeto local o
invocar una biblioteca de clases; el IDE o el framework de aplicaciones maneja toda la plomera por detrs 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 integracin funcional usando Microsoft .NET podra 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 mquina
virtual llamada Common Language Runtime (CLR).

El Web Service puede instalarse en una plataforma .NET.
La aplicacin 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 mtodo.
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 integracin 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 integracin funcional usando JAX-RPC podra hacerse as:
Definir e implementar un Web Service basado en JAX-RPC. La implementacin puede ser en
una aplicacin 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
instalacin depender de la implementacin del Web Service; por ejemplo, si la implementacin
la provee un EJB, la instalacin ser en un contenedor EJB.
Invocar el Web Service desde el cliente en el puerto descripto por el documento WSDL. Para la
aplicacin cliente, la invocacin del Web Service aparecera como una llamada a un mtodo
local.
Conclusin
Los Web Services constituyen una excelente alternativa a tener en cuenta a la hora de considerar la
integracin de aplicaciones que no fueron diseadas para trabajar en conjunto ya que las tecnologas
que los soportan son estndares apoyados por los ms importantes proveedores de software de la
industria.
Por otra parte, el hecho de que SOAP permita utilizar cualquier protocolo de transporte, aunque el ms 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
informtica en general se han puesto de acuerdo en apoyar un estandar comn. 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 solucin que se adapte a las necesidades de un proyecto de integracin, ya sea
que se trate de EAI, B2B, de una o ms aplicaciones o incluso de middlewares propietarios.


Referencias
1. A Web Services Primer Venu Vasudevan
http://webservices.xml.com/lpt/a/ws/2001/04/04/webservices/index.html
2. Using Web Services for Application Integration - Gunjan Samtani, 2002.
http://builder.com.com/5102-6389-1045211.html
3. Functional Integration Integration Patterns
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/archfunctionalintegration.asp
4. Web Service Facade for Legacy Applications - Naveen Yajaman, Microsoft Corporation; Josh Brown,
Implement.com; Shanmugam Subramaniam, Tony John, Narsimha Reddy, and Venkataraman R, Digitial
GlobalSoft (offshore division of HP); Andrew Mason, Microsoft Corporation, Jun 2003.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/wsfacadelegacyapp.asp
5. Software as a service How to think of Web Services - Alan Zeichick, 2004.
http://www.devx.com/SummitDays/Article/6649/2213?pf=true
6. Integration with Web Services - Steve Vinoski, IONA Technologies, Dic 2003.
http://www.iona.com/hyplan/vinoski/pdfs/IEEE-Integration_With_Web_Services.pdf
7. Welcome to WSIF: Web Services Invocation Framework
http://ws.apache.org/wsif/index.pdf
8. Understanding SOAP - Aaron Skonnard, Mar 2003.
http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us//dnsoap/html/understandsoap.asp
9. The Argument Against SOAP Encoding - Tim Ewald, Oct 2002.
http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnsoap/html/argsoape.asp
10. Wired-Wireless Integration: A Middleware Perspective - Giovanni Rimassa, Parma University, Oct 2002.
http://dsonline.computer.org/0209/d/w5icon.htm
11. Decide Between J2EE and .NET Web Services - Eric Newcomer, Oct 2002.
http://www.ftponline.com/wss/2002_10/magazine/columns/webservices/default_pf.aspx
12. J2EE 1.4 Eases Web Service Development - Frank Sommers, Jun 2003.
http://www.javaworld.com/javaworld/jw-06-2003/jw-0620-webservices_p.html
13. Developing Web Services With J2EE 1.4 - Qusay H. Mahmoud, Feb 2004.
http://java.sun.com/developer/technicalArticles/J2EE/j2ee_ws/
14. Is Your Middleware Dead? - Steve Vinoski, IONA Technologies, Oct 2004.
http://dsonline.computer.org/0409/d/w5towp.htm



Business Process Management (BPM)
Ivana Sal
isalo@dc.uba.ar

Introduccin
Desde la realizacin de procesos implcitos en las prcticas de negocio utilizadas durante los aos 20, pasando
por la reingeniera de procesos y tcnicas de documentacin a finales de los aos 80, hasta la gestin de
workflow de documentos que florecieron al finalizar la dcada del 90. En los ltimos aos, la necesidad de
alinear la estrategia a la operacin de negocio y el desarrollo de la tecnologa de informacin, 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 visin sobre los procesos y las iniciativas de mejoramiento organizacional fueron
cambiando y se evidenciaron esfuerzos por realizar cambios en actividades del negocio, que se perciban como
de mayor importancia por su impacto en el desempeo financiero. De esta ptica se originaron los sistemas
conocidos como ERP (Enterprise Resource Planning), los cuales participaron como elementos de
almacenamiento y consulta de informacin del proceso y no contaron con mecanismos robustos para controlar la
gestin de los procesos de negocio de manera integral.

En la actualidad asistimos a un escenario de gestin en el cual los procesos requieren de ser gestionados
independientemente de un dominio especfico de un sistema. Ellos, constituyen el foco y la unidad primaria de
iniciativas de automatizacin e integracin de informacin, necesarios para responder gilmente a los cambios
exigidos por la dinmica del mercado. La gestin de procesos de negocio en estas condiciones ha dado origen a
una nueva etapa en la gestin de procesos denominada Business Process Management (BPM).

Resulta relevante al realizar una breve introduccin 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, integrndose y, por lo tanto, protegiendo inversiones tecnolgicas anteriores con
independencia de las normas tcnicas 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
anglosajn como ENS (Enterprise Nervous System), considerando los procesos de negocio de misin crtica
como una autntica columna vertebral corporativa desde la cual surgen el resto de procesos y subprocesos que
engloban la totalidad de la actividad en una gran compaa, independientemente de su sector o tipo de negocio.

La decisin de las grandes corporaciones adoptando este tipo de arquitecturas, en donde el proceso de negocio se
convierte en la estructura bsica a automatizar e integrar, da lugar al desarrollo de dos tecnologas
complementarias al universo BPM tal y como lo conocemos, ambas centradas en la optimizacin 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 Modelizacin 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 Rashid
16
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 realizacin de una actividad econmica, luego de haber asignado unos

16
KHAN Rashid, Evaluating BPM Software, Business Integration Journal, 2003

recursos (humanos, tecnolgicos, financieros) a la obtencin de dichos resultados. En otras palabras, la
rentabilidad nos da una medida del rendimiento que un capital ha obtenido en un perodo determinado. BPM por
lo tanto aumenta la relacin entre la rdito que se genera y los medios utilizados.
En esta ptica, el objetivo de la gestin de procesos esta concentrada en el aumento de la rentabilidad.

Smith Howard
17
define BPM como una nueva aproximacin para abordar y gestionar procesos de innovacin en
las compaas 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 reingeniera; la cual construye el mejoramiento
desde la redefinicin total del proceso.
En esta ptica BPM se convierte en una respuesta al caos operativo que presentan las compaas en la actualidad
.

De manera integral, la administracin de procesos de negocio, o BPM, es la prctica de mejorar la eficacia y la
eficiencia de cualquier organizacin automatizando los procesos de negocio de la organizacin. Para as mejorar
la gestin de los procesos de negocio de la firma de principio a fin, a partir de la definicin deliberada,
colaborativa e incremental de la tecnologa; para alcanzar claridad en la direccin estratgica, alineacin 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 aplicacin de tcnicas y herramientas de software para modelizar, gestionar y optimizar
los procesos de negocio de la organizacin. BPM proporciona una capa de proceso independiente que controla
cmo gente y tecnologa interactan para alcanzar los objetivos o resolver los indicadores dominantes del
funcionamiento de la organizacin.

Objetivos de BPM
Muchas compaas 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 solucin de BPM que se elige debe ser fcilmente adaptable a las nuevas
condiciones y requisitos y continuar siendo un ajuste perfecto para la compaa.
Para utilizar BPM con eficacia, las organizaciones deben dejar de centrarse exclusivamente en los datos
y su administracin, y adoptar un acercamiento orientado a procesos que no haga ninguna distincin
entre el trabajo hecho por un ser humano y una computadora.
La idea de BPM es juntar los procesos, la gente y la informacin.
Identificar los procesos de negocio es relativamente fcil, lo que es difcil es encontrar los dueos para
esos procesos.
BPM implica no slo manejar los procesos de negocio dentro de la empresa sino tambin implica la
integracin en tiempo real de los procesos de una compaa con las de sus proveedores, socios de
negocio y clientes.
BPM implica mirar la automatizacin horizontalmente en vez de verticalmente.
Una solucin BPM tiene seis componentes

BPM IDE. La administracin de procesos de negocio (BPM) IDE es un ambiente integrado del diseo
usado para disear procesos, reglas, acontecimientos y excepciones. Crear una definicin estructurada
de cada proceso es muy importante para cualquier negocio y el IDE permite a un usuario del negocio
disear todos los procesos sin ayuda de tcnicos informticos.
Motor de proceso. El motor de proceso de una solucin de la administracin de procesos de negocio
no pierde de vista los estados y las variables para todos los procesos activos. Dentro de un sistema
complejo podra 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 automticamente a los recursos definidos.
Workflow. sta es la infraestructura de comunicacin que transmite las tareas al individuo apropiado.
Supervisin/Monitoreo de Procesos. Permite a los usuarios seguir el funcionamiento de sus procesos
actuales y el funcionamiento del personal que est ejecutando estos procesos.
Integracin. Los servicios de la integracin (EAI) y/o del Web del uso de la empresa son crticos a
BPM pues los procesos de negocio requerirn datos de sistemas dispares a travs de la organizacin.

17
SMITH Howard, FINGAR Peter, Business Process Management: the third wave. The breakthrough that
redefines competitive advantage for the next fifty years, 2003

Ventajas del BPM
Dominio completo de los procesos de negocio. BPM facilita que las compaas programen sus
procesos actuales, automaticen su ejecucin, 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.
Automatizacin de tareas. El software del BPM permite automatizar esas tareas que se estn
realizando actualmente en forma manual. Muchas de estas tareas requieren un cierto tipo de aplicacin
de procesos, procesos de aprobacin o rechazo, notificaciones e informes. Una solucin de BPM puede
hacer que estos procesos sean automticos.
Reduccin de plazos en los procesos de soporte al negocio. La redefinicin de fases, facilitando la
elaboracin de algunas de ellas en paralelo, la eliminacin de tiempos muertos y la automatizacin de
tareas, reducen drsticamente el tiempo global de ejecucin de los procesos del negocio.
Optimizacin de costos. El BMP, mediante la modelizacin y la aportacin de mtricas, permite
identificar tareas innecesarias a eliminar y cuantificar los procesos en trminos de plazos y consumos de
recursos, elementos ambos imprescindibles para avanzar en un proceso continuo de optimizacin de
costos.
Integracin de personas y sistemas en los procesos automatizados. Tanto los recursos humanos y
tcnicos de una empresa son vitales para sus operaciones, BPM consigue mejorar los procesos de la
forma que se desee, sin restricciones tecnolgicas y aprovechando el conocimiento adquirido por el
personal actual.
Integridad y calidad de procesos. La monitorizacin de los procesos asegura que estos se realicen
conforme a los estndares definidos, asegurando la calidad e integridad de los mismos.
Integracin de terceras partes en los procesos. La automatizacin de procesos, combinada con la
accesibilidad derivada de las tecnologas web, permite a clientes, proveedores, organismos pblicos,
etc., terceras partes en general, participar en el proceso de forma automatizada, directa y eficiente,
abriendo la organizacin en trminos tanto de acceso a los procesos como de acceso a informacin.
Consolidacin de la informacin derivada de la gestin de los procesos. Esta informacin aporta una
perspectiva de dnde est y de cmo lo hacemos, complementariamente a los sistemas transaccionales,
que aportan una perspectiva de qu hacemos. Toda esta informacin, normalizada en un repositorio
corporativo, configurar la base del autntico datawarehouse integral de la compaa.
Mayor flexibilidad y agilidad para adaptarse al cambio. Busca reducir los obstculos con los que
puede encontrarse en un futuro, adaptndose frente a los cambios que deba sufrir el BPM al modificarse
algn proceso del negocio.

BPM en la prctica
En definitiva las soluciones BPM facilitan que una compaa sea capaz de redefinir y automatizar sus procesos
de negocio simplificndolos, acortando su duracin y reduciendo el nmero de errores.

Para implantar un proyecto BPM, es necesario realizar una adecuada definicin, modelizacin y automatizacin
de los procesos organizativos, pero para garantizar el xito de la aplicacin, es preciso ir ms lejos.

El xito radica en la necesidad de fusionar la definicin de los procesos (componente normativo y de
organizacin) con la mecanizacin de los mismos (sistemas de informacin). En otras palabras, es necesario
que el proceso y la normativa se integren y se soporten en el sistema de informacin.

Y la realidad muestra que el mayor obstculo que se encuentran las organizaciones para abordar un BPM se
localiza en cuestiones como:

o Existencia de procesos no automatizados (procesos auxiliares, soporte, administrativos...)
o Existencia de actividades y tareas no soportadas desde los sistemas operacionales (gestin documental,
flujos de aprobacin, etc.)
o Complejidad en la implementacin de las soluciones workflow de mercado.
o Materializacin de gran parte de los procesos en soporte papel (soporte documental, constancia de
decisiones, anlisis de informacin...); frecuentemente, falta de sincronizacin con las transacciones de
negocio.
o Necesidad inminente de incorporar en la gestin de procesos las ltimas tecnologas: soportes
digitalizados, workflow, gestin documental, acceso telemtico, firma digital, etc.


La implementacin de BPM involucra la articulacin de la estrategia, los procesos y la tecnologa de una
empresa para generar valor al negocio. A diferencia de los modelos de gestin anteriores, BPM se concentra en
la articulacin de las iniciativas estratgicas con los procesos de negocio, apalancados en estndares tecnolgicos
que facilitan su despliegue alineado en las operaciones diarias de la organizacin.

Figura 1. BPM articula la estrategia, los procesos y la tecnologa de una organizacin

Para lograr esta articulacin es necesario desarrollar una serie de procesos que permiten alinear de manera
controlada, los aspectos estratgicos del negocio, a travs de la identificacin y articulacin de los conceptos
claves del proceso y la asociacin de los componentes tecnolgicos que permitan flexibilizar los cambios en la
cotidianidad empresarial.
En la prctica, la implantacin de esta disciplina de mejoramiento requiere, por parte de la empresa, una dosis de
pensamiento en procesos de negocio y la utilizacin de tecnologas de Informacin 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 dinmica del mismo. Esto
quiere decir que el proceso se evala revisando las actividades que se llevan a cabo, buscando eliminar aquellas
que no adicionan valor e identificando las polticas, reglas de negocio y normas que determinan las decisiones
que la organizacin toma sobre el proceso.

De igual manera se examinan los trabajos y roles que la empresa destina a la realizacin del proceso, con el fin
de gestionar las barreras culturales, paradigmas, conocimientos y competencias requeridas para su realizacin.

De igual manera se analiza la estructura de la organizacin, con el fin de coordinar las diferentes reas,
jerarquas y dependencias que influencian su desempeo.
Las condiciones fsicas ejercen especial influencia sobre determinados procesos, ya que las condiciones
ambientales y geogrficas pueden determinar mejoras o reducciones en la generacin de valor en determinada
actividad del negocio.
Las habilidades y competencias del talento humano que participa en la operacin del proceso, constituyen otro
de los pilares al abordar el proceso de mejoramiento. Finalmente la infraestructura de informacin y
comunicaciones son examinadas para identificar los repositorios de informacin y las actividades del proceso
modelado bajo BPM que consulta o almacena informacin en otros sistemas del negocio.
La identificacin de estas interfaces constituye un factor de xito en la implementacin de proyectos de
automatizacin ya que en ellos estn generalmente los mayores esfuerzos en la implementacin de plataformas
tecnolgicas y se utilizan para dimensionar el alcance de las diferentes fases del proceso de mejora.
La gestin de estos componentes requiere tecnologa para actuar con agilidad y facilitar procesos de cambio.

La tecnologa de BPM

La tecnologa que posibilita la implementacin y adopcin de BPM constituye una categora nueva de sistemas
de informacin 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 caractersticas tcnicas
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 travs de caractersticas funcionales y no
funcionales que posibilitan definir, modelar, implementar y mejorar el proceso durante su operacin. Un sistema
BPMS esta en capacidad de realizar las siguientes operaciones:

Modelado de procesos de negocio.
Provee entornos de desarrollo de aplicaciones para colaboracin entre procesos de negocio.
Generacin, actualizacin y publicacin de documentacin de procesos.
Simulacin de procesos de negocio para evaluar su comportamiento en situaciones de carga exigidas en
determinados momentos del proceso.
Integracin de informacin proveniente de otros sistemas de negocio.
Automatizacin de procesos.
Colaboracin entre las empresas que participan en la cadena productiva de la organizacin.
Despliegue de aplicaciones que soportan el proceso en condiciones tales que no se requiere mayor
conocimiento y experiencia de un usuario final.
Anlisis de procesos y comportamiento de la operacin.
Gestin de ciclo de generacin publicacin y consumo del conocimiento generado en la operacin del
proceso.

Estas caractersticas constituyen la base sobre la cual se desarrolla el modelado, simulacin e
implementacin de procesos en una compaa. La flexibilidad y agilidad en el diseo de procesos, se
basan en la abstraccin de la realidad que plasma el arquitecto de negocio y las posibilidades del
sistema para representar esta realidad de manera grfica.
Los sistemas BPMS incluyen funcionalidades para representar la interrelacin de las diferentes dimensiones del
proceso de manera grfica.

Quines son los vendedores del software BPM?

Muchas compaas 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 definicin clara de qu es un Proceso de
Negocio:

Un proceso es un orden especfico de actividades de trabajo, que se realizan en el tiempo, en lugares
especficos 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 accin.

Ahora bien, podemos definir el WorkFlow como

La automatizacin de los procesos de negocio durante el cual documentos, informacin 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 administracin de procesos de negocio (BPM).
- es un trmino usado para describir cmo se define el trabajo y cmo 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
mquinas.
- 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 segn lo
necesitado.

Para entenderlo mejor, a travs 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 travs de un motor, gestionar de forma automatizada los procesos y
flujo de actividades, documentos, imgenes y datos, orquestando e integrando los recursos informticos y los
roles.

Con la Tecnologa WorkFlow:

o El trabajo no queda trabado o extraviado.
o Los jefes pueden enfocarse ms en los problemas del negocio y del personal, tal como el rendimiento y
capacitacin individual, mejoras de procedimientos, y casos especiales, ms que en la rutina de
asignacin de tareas.
o Los procedimientos son formalmente documentados y seguidos de forma exacta y estndar, asegurando
que el trabajo es llevado a cabo atendiendo a la planificacin, cumpliendo a su vez todos los
requerimientos y normas del negocio y externos.
o La persona adecuada, dispositivo o sistema es asignado a cada caso, y los casos ms importantes o
crticos en el tiempo, son asignados primero. Los usuarios no gastan tiempo escogiendo sobre qu caso
trabajar, aplazando as aquellos casos de resolucin ms dificultosa.
o Se logra el procesamiento paralelo, donde 2 o ms actividades no dependientes pueden ser realizadas
concurrentemente, generando as beneficios en cuanto a reduccin de tiempo de los procesos, mejor
servicio al cliente y reduccin de costos.
o Se convierte el entorno de trabajo Reactivo a un entorno ProActivo, con todas las ventajas y
beneficios que esto conlleva.

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

Asignar actividades a las personas de forma automtica y segn algn criterio o cargas de trabajo.
Recordar a las personas sus actividades, las cuales son parte de una cola de WorkFlow.
Optimizar la colaboracin entre personas que comparten actividades.
Automatizar y controlar el flujo de documentos, datos e imgenes.
Asignarle proactivamente a las personas que deben ejecutar las actividades, todos los recursos
necesarios (documentos, informacin, aplicaciones, etc.) en cada una de ellas.

Definir y controlar alertas segn criterios de tiempo, de evento o de condicin, provocando as algn
mensaje a un supervisor, un escalado de actividades a otras personas para que las resuelvan, y/o una
reasignacin automtica.
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 cdigo. Adems, a travs de cualquier navegador para que realmente se pueda
realizar desde cualquier lugar.
Proveer una vista on line para supervisores del estado y un histrico de cada instancia de proceso, de
cada actividad, y del desempeo de las personas.
Hacerles llegar a cada persona sus actividades y alertas, independientemente de su ubicacin
geogrfica, a travs de la WEB, e-mail, SMS, o cualquier otro dispositivo mvil.
Proveer mtricas para responsables de reas, organizadores, gestores de procesos y calidad, tanto para
efectos de mejora continua como de indicadores de calidad y de gestin.
Integrarse fcilmente con otros sistemas, aplicaciones y ERPs.
Proveer un alto nivel de soporte para la interaccin humana

Los beneficios, tanto tangibles como intangibles, son numerosos. A continuacin describo los ms importantes :

Mejora la atencin y servicio al cliente.
Incrementa el nmero de actividades ejecutadas en paralelo.
Minimiza el tiempo requerido por los participantes para acceder a la documentacin, aplicaciones y
bases de datos.
Disminuye drsticamente el tiempo de transferencia de trabajo, informacin y documentos entre
actividades.
Asegura la continua participacin y colaboracin de todo el personal en el proceso.
Disminuye drsticamente el tiempo que los participantes, supervisores y administradores necesitan
para conocer la situacin de un tem de trabajo (por ejemplo, orden de compra, participacin de
siniestro, pedido de cliente).
Simplificacin de salidas - outputs - automticas. Documentos Word, faxes, e-mails, mensajes cortos
a mviles, etc.
Disponibilidad de mecanismos para una mejor gestin y optimizacin de procesos.

BPM hoy

Con respecto al posicionamiento que los jugadores tradicionales en la industria estn adoptando al respecto de la
tecnologa BPM, ste viene marcado fundamentalmente por su origen tecnolgico. As, fabricantes tradicionales
provenientes de entornos EAI como Tybco o Vitria presentarn mayores fortalezas en aquellos entornos en
donde la incidencia de pasos automticos entre aplicaciones sea mayor mientras que jugadores tradicionales en el
entorno Workflow como Staffware o W4 se mostrarn ms capaces de gestionar excepciones y monitorizar los
rendimientos de procesos con intervencin humana, evolucionando en sus desarrollos en los ltimos aos hacia
conceptos como el STP (Straight Through Processing) en donde un proceso es gestionado de principio a fin
mediante pasos automticos sin intervencin manual alguna. La confluencia de distintos entornos y su necesidad
de integracin obligan a un considerable esfuerzo de desarrollo e integracin en los proveedores de tecnologa.

Mencin 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
informacin en las grandes corporaciones. Las altas tasas de crecimiento de la tecnologa BPM no estara
teniendo lugar sin que este influyente sector de actividad en la industria hubiera apostado con firmeza por las
herramientas de gestin automatizada de procesos como infraestructura de desarrollo, incrementando la
eficiencia de sus equipos en los grandes proyectos tecnolgicos y reduciendo los costos repercutibles en el
cliente final.

La Tecnologa WorkFlow est evolucionando a pasos agigantados gracias a los nuevos estndares y las nuevas
tecnologas surgidas en estos ltimos aos. Aunque la contribucin de los WorkFlows tradicionales de
produccin, ad hoc, administrativos y colaborativos, es an notable hoy en da, hay una nueva generacin que
quizs sea un hbrido que rene lo mejor de todos los sistemas WorkFlow y otras tecnologas. Como las
empresas cada vez ms se estn orientando hacia los procesos, decantndose principalmente por el e-Business,
esta nueva generacin de tecnologa BPMS (Business Process Management System) est siendo actualmente
ms investigada y perfeccionada que nunca.


Esta nueva generacin supera las anteriores limitaciones, conocidas en los 90, incorporando amplias
capacidades de integracin con modernas arquitecturas Java, .Net y XML, principalmente. Adicionalmente, se
les estn sumando otras tecnologas 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 da ya podemos decir que los BPMS permiten a las
empresas modelizar, implementar y gestionar los procesos de negocio, que abarcan mltiples aplicaciones
empresariales, departamentos, y partners, detrs de los cortafuegos y sobre Internet. Los BPMS son una nueva
categora 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 sern construidas la
prxima generacin de aplicaciones, o b) como una nueva capacidad profundamente incrustrada en las categoras
existentes de sistemas. En cada caso, adquiriendo los BPMS, las empresas ganan un control sin precedentes
sobre la gestin de los procesos y recursos, dndole a su vez ms 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 misin crtica de la infraestructura. Y desde que esta tecnologa ha pasado la
frontera de la empresa - para dirigirse al exterior -, stos deben tambin ofrecer niveles avanzados de seguridad.

Como podemos apreciar en el grfico siguiente, los BPMS sern en pocos aos el elemento crtico de la
infraestructura tecnolgica en las empresas, tal como han sido los DBMS en estos ltimos 15 aos, y pasaremos
de una orientacin a datos, a una orientacin empresarial centrada en procesos.

Conclusiones

BPM es el entendimiento, gestin e innovacin de los procesos bajo estndares 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
integracin entre diferentes compaas. Se lleva a la prctica integrando la estrategia, los procesos y la
tecnologa, la cual emplea estndares de modelado para permitir una comunicacin fluida y con menor esfuerzo
entre procesos de negocio y las compaas del sector.

Se perfila como una nueva lnea de pensamiento que atiende necesidades tangibles de las empresas y abre
nuevos nichos de mercado para nuevas empresas que se enfoquen en temas de gestin empresarial.

Bibliografa

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 tecnologa... Luis Fernando
Sanchez Maldonado. www.degerencia.com/articulos.php?artid=611

BPMS, Tecnologa para la Integracin y Orquestacin de Procesos, Sistemas y Organizacin - Renato de
Laurentiis Gianni. www.rrhhmagazine.com/inicio.asp?url=/articulos.asp?id=253

Gestin de Procesos de Negocio. www.imarketing.es/bpm.asp

Process Management. www.qpr.com

BPM Simplified A step-by step guide to Business Process Management with Ultimus BPM Suite.
www.ultimus.com

Evaluating Integration Brokers: Applying 13 technical selection criteria to Ensemble universal integration
platform. http://www.intersystems.com/ensemble/technology/evaluating-integration-brokers.pdf


JAIN/SLEE
Jorge Andres Brassara
abrassara@softhome.net
Introduccin

JAIN (Java API for Integrated Networks) es la definicin de un conjunto de interfaces que permitirn el rpido
desarrollo de productos y servicios basados en comunicaciones sobre Java, va la integracin de redes
heterogneas como la red telefnica tradicional, redes de datos e inalmbricas, y la estandarizacin de interfaces.
En otras palabras, JAIN es una extensin de la plataforma Java para las telecomunicaciones. Los servicios de
telecomunicacin incluyen, entre otros, al control de llamadas, mensajera, presencia y ubicacin de equipos, y
afectan desde dispositivos mviles hasta grandes servidores de aplicacin de telecomunicaciones.

El desarrollo de las especificaciones es llevado a cabo bajo los trminos de JSPA (Java Specification Agreement)
y de JCP (Java Community Process), permitiendo la colaboracin de muchas partes. Entre ellas, se encuentran
compaas tales como IBM, Motorola, NTT y Vodafone.

Motivacin

Actualmente, la industria de comunicaciones est formada por un gran nmero 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 detrs de los estndares estn constantemente tratando estos temas, los
avances que se han logrado son escasos. Adems de problemas a nivel protocolo y estndares, hay ciertas
incompatibilidades tcnicas que fuerzan a las aplicaciones slo a correr sobre la plataforma o red para la cul 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 migracin a nuevas plataformas es
compleja y su mantenimiento (principalmente, agregar funcionalidad) es ms costoso an.

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 comunicacin,
dnde los servicios puedan ser rpidamente creados y desplegados, y puedan ser fcilmente 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 estandarizacin 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
implementacin de nuevos servicios sern drsticamente reducidos.

Objetivos

Servicios Portables
La tecnologa Write Once, Run Anywhere se encuentra actualmente restringida por la utilizacin de interfaces
propietarias. Esto incrementa los tiempos de desarrollo, retrasa el ingreso al mercado, y el mantenimiento se hace
ms 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 telefnicas, de
datos e inalmbricas. A medida que pasa el tiempo, la demanda de los usuarios sobre la convergencia de estas

redes aumenta y JAIN permitir acelerar esta integracin. Por ejemplo, esta tecnologa har que el proceso de
migracin de aplicaciones que corren sobre la red telefnica tradicional hacia Internet sea un tarea sencilla y
directa.
Desarrollo abierto
Al definir APIs de Java para comunicaciones fciles de usar, esta tecnologa puede aprovechar la masiva
comunidad de programadores ya existente.

Unificacin de IT y telecomunicaciones
En cierto momento, la existencia de una esfera separada de telecomunicaciones tena sentido, pero no lo tiene
hoy en da. Los requerimientos de telecomunicaciones, como la alta disponibilidad y redes confiables, no son
ms 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 reso es posible
entre las industrias.
Por ello, la distincin entre las aplicaciones IT y de telecomunicaciones comienza a ser cada vez mas difusa. La
incorporacin de millones de programadores IT, traer a las telecomunicaciones la economa de escala que la
industria de la computacin viene disfrutando hace tiempo.

JAIN Service Logic Excecution Enviroment (JSLEE)
La especificacin de la API de SLEE define un framework de aplicacin para el desarrollo de servicios portables
de telecomunicaciones. Se define una arquitectura de comunicaciones asincrnica y manejadas por eventos. De
todas las APIs de comunicacin de JAVA, SLEE es el componente principal y tiene un rol central en la mayora
de topologas de redes de comunicacin de Java.

Los sistemas de comunicacin son tpicamente orientados a eventos y asincrnicos. Contrariamente, los sistemas
enterprise usualmente utilizan invocaciones directas a mtodos. Una arquitectura enterprise existente est
definida por la especificacin de Enterprise JavaBeans. Dadas las diferencias en los requerimientos entre
sistemas basados en eventos y sistemas enterprise, se motiv la especificacin de JSLEE a travs de JCP. En la
siguientre tabla, se muestran algunas de estas diferencias:

Comunicaciones Enterprise
Invocaciones -Tpicamente asincrnico
Eventos tales como triggers de protocolos
Los eventos se mapean con invocaciones a
mtodos
- Tpicamente sincrnico
Bases de Datos, Sistemas EAI, Llamadas
RPC
Granularidad de
los Eventos
Eventos de granularidad fina y alta
frecuencia
Eventos de granularidad gruesa y baja
frecuencia
Componentes

Objetos livianos conteniendo poca lgica
de negocios, ciclos de vida cortos y
transitorios: rpida creacin y eliminacin.
Objetos pesados de acceso a datos, que
pueden tener ciclos de vida largos y
persistentes.
Fuentes de Datos Mltiples fuentes de datos (ej, eventos
disparados por protocolos)
Sistemas Back-end y servidores de Base
de Datos
Transacciones

-Transacciones livianas
Se completan ms rpido y son ms
frecuentes
-Transacciones de Base de Datos
Tardan ms en completarse y son menos
frecuentes
Cmputo

- Cmputo-intensivo
Las principales entradas y salidas son
invocaciones a recursos, mensajes y
eventos
- Acceso a Base de Datos-intensivo

Los cuatro elementos bsicos de SLEE son: resource adapters, eventos, activity context y el entorno de
ejecucin, que contiene los objetos SBB (Service Building Blocks). En la siguiente figura se puede observar la
relacin entre estos elementos:


Resource Adapters

Los resource adapters se encargan de la comunicacin (envo y recepcin 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 interactan con los recursos
externos a travs de los resource adapters. Estos adaptadores amoldan el recurso a las necesidades de SLEE.

El tipo de resource adapter declara las caractersticas 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 implementacin especfica 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 utilizacin de estos adaptadores para acceder a recursos manejados por eventos es similar a la
utilizacin de JDBC para acceder a Bases de Datos. La estandarizacin 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 informacin de una entidad dentro del SLEE a otra. Slo las entidades SBB pueden
consumir y producir eventos, mientras que otras entidades (como los resource adapters, el mismo SLEE y
facilities de SLEE) slo 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 recibirn el evento y
procesarn el mismo con los mtodos de handling de eventos.

Activity y Activity Context

Una activity representa un stream de eventos relacionados entre s. La representacin en Java de esta entidad
lgica 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 telfono.


Un activity context es una entidad lgica que representa la actividad que se est llevando a cabo dentro del SLEE
y tambin 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 sern 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 va un mecanismo indirecto. Los
consumidores de eventos se suscriben a los eventos adjuntndose a los activity contexts. Los productores de
eventos publican los eventos en los activity contexts. Los productores de eventos no estn 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, facilitndo la modularidad y aislamiento de
errores.
Las aplicaciones y desarrolladores de drivers de eventos slo 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 invlidas.
El modelo de distribucin de eventos es nico y consistente.

Entorno de ejecucin y SBBs

Un SBB (Service Building Blocks) es un componente de SLEE y es hosteado por un contenedor SLEE. El
contendor acta como el entorno de ejecucin 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 mtodos concretos, que contiene la lgica de aplicacin del
componente, y ciertos mtodos abstractos implementados por el SLEE, que tratan con las cuestiones de
infraestructura anteriormentre enumeradas.
El entorno de ejecucin es el responsable de crear el pool de instancias de estas clases abstractas. Este proceso
puede ser comparado con la creacin de un componente EJB.

Jain Session Initiation Protocol (JSIP)

SIP (Session Initiation Protocol) es un protocolo de sealizacin utilizado en una gran cantidad de aplicaciones
para redes basadas en IP, tales como conferencias va Intenet, telefona, VoIP, presencia, notificacin de eventos
y mensajera instantnea.
Actualmente, SIP juega un papel clave en la industria de las telecomunicaciones, ya que ha tenido un grado
importante de adopcin.
Por estas razones, se ha puesto principal atencin en este protocolo y se defini una API especfica para el
mismo.


JAIN y otras tecnologas de Java (Big Picture)

La siguiente topologa de red muestra una tpica solucin Java para comunicaciones. Se basa en las principales
tecnologas de Java (J2ME, J2SE y J2EE), junto con tecnologas emergentes de comunicaciones (JAIN SLEE,
JAIN SIP, etc.). Esta topologa de red provee una manera de visualizar cmo se relacionan entre s las distintas
tecnologas en el dominio de las comunicaciones.

Basados en las especificaciones JAIN y SLEE, los servicios de comunicacin corriendo en un SLEE podran
comunicarse directamente con sistemas enterprise existentes va RMI o cualquier otro protocolo que soportado
por el servidor J2EE. Contrariamente, si un servicio enterprise necesita disparar algn tipo de funcionalidad
expuesta por un servicio de telecomunicaciones, necesita comunicarse va 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 mbil 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 tpicamente implementado en Java.

Un cliente Web en un equipo desktop tambin puede estar implementado en cualquier lenguaje de programacin.
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 mbiles de bajos recursos. Para intercambiar informacin con sistemas
externos, dispositivos mbiles que soportan J2ME podran utilizar conexiones HTTP.

Estado

En el presente, faltan algunas de las APIs para telecomunicaciones (por ejemplo, MM1 para mensajera
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 especificacin de JSLEE,
lo que hace casi imposible para los fabricantes ingresar al mercado y menos crear uno.


En los ltimos meses (septiembre/octubre de 2004), expertos del JSR se reunieron para completar la
especificacin de las interfaces de los resource adapters, y dejarla lista para revisin pblica.

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 debern trabajas
conjuntamente para incluir JVMs en futuras actualizaciones.

De todas maneras, el futuro de JAIN es prometedor. Un comunidad actividad se encuentra en plena evolucin,
especialmente alrededor de SIP. A medida que JSLEE avanza ms profundamente sobre la comunicaciones, ms
empresas interesadas en tecnologas Java y de redes se han unido al JSLEE Expert Group, incluyendo compaias
internacionales de telecomunicaciones como Alcatel, Vodafone y NTT DoCoMo. Muchas de estas compaias ya
han realizado implementaciones exitosas de servicios basados en JAIN/SLEE. Adems, varios proveedores de
equipamento de red estn haciendo planes de productos SLEE para el 2005

Conclusin

La iniciativa JAIN ciertamente abre el mundo de las telecomunicaciones al lenguaje de programacin Java. La
visin de una red unificada en donde los servicios son portables, escalables, extensibles, interoperables, y fluyen
libremente sin modificaciones a travs de las redes, es muy poderosa. JAIN es el primer paso hacia la integracin
de redes IP, inalmbricas, celulares y telefnicas. Al proveer entornos e interfaces basados en estndares 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 telefnicas de crear
componentes basados en Java y hacer crecer estratgicamente sus negocios. A pesar de que JAIN est recin en
sus comienzos, la promesa de esta tecnologa ha motivado a varias empresas con muchos aos en la industria.
Esta tecnologa 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
Syscons JDJ: JAIN/SLEE Opening the telecommunications world for Java: http://sys-
con.com/story/?storyid=46230&DE=1


Programacin Orientada a Aspectos

Fernando Taboada
fernandopablotaboada@yahoo.com.ar

Introduccin

Existen ciertos problemas en la programacin de sistemas que ni las tcnicas procedurales ni las tcnicas
orientadas a objetos aportan una buena solucin de diseo. Generalmente, son problemas que fuerzan una
solucin dispersa a travs del cdigo repitiendo cdigo que es comn a distintas funcionalidades. El ejemplo
tpico es el log de una aplicacin que suele impactar en casi todas las capas de la misma, por lo tanto su solucin
suele estar dispersa por el cdigo empeorando el diseo y dificultando el mantenimiento.
El problema fue identificado en la dcada del 70 y se lo conoce como el problema de la separacin de
incumbencias (separation of concerns).
En el ao 1997 un grupo de Xerox Parc encabezado por Gregor Kiczales propuso la programacin orientada a
aspectos (AOP, por las siglas Aspect Oriented Programing) como una nueva tcnica de programacin, que
complementara a la programacin orientada a objetos y resolvera ese problema. Segn el paper original,
aquellos problemas o incumbencias que no tienen una buena solucin se refieren a aspectos que atraviesan
(cross-cut) la funcionalidad bsica de la aplicacin. La tcnica propuesta permite expresar claramente esos
aspectos en los programas de una manera adecuadamente aislada de la funcionalidad bsica.
Aos ms tarde de proponer la tcnica, gente de Xerox Parc propuso el lenguaje AspectJ como extensin
orientada a aspectos para el lenguaje Java. Desde ese entonces han surgido diversos frameworks orientados a
aspectos para distintos lenguajes de programacin. AOP est en continuo desarrollo y es un rea de bastante
inters en ingeniera de software, aunque aun no fue adoptada de una manera clara por la industria.
El problema a resolver

Como dije en la introduccin, el problema a resolver es el de la separacin 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 estn las funcionales bsicas de la aplicacin as como tambin las que hacen referencia a requerimientos
no funcionales.
La mayora de las tcnicas de diseo se guan al modelar por una determinada visin jerrquica de la
organizacin del sistema. El problema es que las incumbencias no funcionales no suelen adaptarse a este tipo de
jerarquas. En las construcciones provistas por los lenguajes de programacin el problema se repite. Por ejemplo,
en el paradigma imperativo la jerarqua est dada por el rbol de ejecucin. En el paradigma de objetos por la
jerarqua de clases y la composicin de objetos.
El problema surge cuando una incumbencia afecta a distintas partes del sistema que no aparecen relacionadas en
la jerarqua. Esas incumbencias que aparecen diseminadas en el cdigo se llaman incumbencias transversales
(crosscutting concerns) y generan cdigo disperso y enredado (scattering and tangling). Se habla de cdigo
disperso cuando hay un mismo servicio que es invocado de manera similar desde muchas partes del programa.
Cdigo enredado se da cuando una misma operacin tiene que acceder a varios servicios que no hacen a su
funcionalidad especifica.
El cdigo enredado y disperso genera baja traceabilidad (oscurece la relacin entre una incumbencia y su
implementacin), baja productividad (obliga al programador a desviar la atencin de la funcionalidad bsica a
implementar), poco reuso de cdigo, baja calidad de cdigo y problemas de evolucin y mantenibilidad.

Algunas definiciones bsicas

AOP introduce una nueva unidad de modularidad llamada aspecto que intenta modularizar y separar distintas
incumbencias. Ejemplos tpicos de incumbencias son seguridad, manejo de excepciones, persistencia, logging,
distribucin, replicacin, y sincronizacin.

Una vez identificadas las incumbencias y modularizadas en aspectos estos pueden ser aplicados al cdigo que
define la funcionalidad bsica. Ms adelante veremos como se logra la aplicacin, pero para eso antes
necesitamos definir algunos conceptos bsicos:

JoinPoints: son puntos en un programa. Ejemplos son las llamadas a mtodos, 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 mtodos en base a los parmetros que reciben, haciendo
pattern maching en los nombres, etc.
Advice: especifican el comportamiento de un JoinPoint identificado por un PointCut. El cdigo
especificado en un Advice es ejecutado cuando se ejecuta un JoinPoint seleccionado por un PointCut.
Un Advice puede ser ejecutado antes, despus o en vez de la ejecucin 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 mtodos en unidades cohesivas.

La aplicacin de los aspectos al resto del cdigo 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 cdigo base y
los aspectos, y producir un nuevo cdigo fuente con el resultado del entretejido, insertando los Advice en los
JoinPoints indicados por el PointCut correspondiente. Otra posibilidad es durante la compilacin, generando
cdigo objeto que cumpla la funcionalidad base ms la de los aspectos. Finalmente esta la opcin del llamado
entretejido dinmico, por el cual se controla la ejecucin del programa y, cada vez que se llega a un punto de
unin incluido en un PointCut de un aspecto, se ejecuta el Advice asociado.
La forma de especificar los aspectos puede ser mediante cdigo con una sintaxis adicional o no al lenguaje y/o a
travs de un XML, segn el framework que se utilice.

Detrs de los aspectos hay dos ideas referentes a la aplicacin de los PointCuts que deberan cumplirse en todo
framework: prescindencia y cuantificacin. La primera tiene que ver con los principios de abstraccin y
encapsulamiento. Un programador no debera tener en cuenta al desarrollar una funcionalidad que aspectos se le
aplicarn luego. La cuantificacin se refiere a que los aspectos deben poder aplicarse de forma genrica 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 vera un cdigo para logguear sin utilizar AOP:

public void doGet(JspImplicitObjects theObjects) throws ServletException {
logger.entry("doGet(...)");

logger.exit("doGet");
}

Utilizando AOP el cdigo para loguear no debera aparecer en
ningn mtodo. A cambio de eso se define un aspecto, en el que
se indican los PointCut, indicndoles un nombre y el conjunto
de JoinPoints a los que aplica. Adems se definen los Advise,
indicando en que momento se ejecutan, a que PointCuts se
aplican y cul es la accin a realizar.

public aspect AutoLog {

pointcut publicMethods() : execution(public * org.apache.cactus..*(..));

pointcut logObjectCalls() :
execution(* Logger.*(..));

pointcut loggableCalls() : publicMethods() && ! logObjectCalls();

before() : loggableCalls(){
Logger.entry(thisJoinPoint.getSignature().toString());
}

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

Por ltimo, el siguiente ejemplo muestra el tercer tipo de Advice, around, que permite reemplazar la ejecucin de
un mtodo por otro cdigo 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 continuacin 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 mayora de las herramientas para
.Net estn actualmente en etapa de desarrollo.

Herramientas disponibles para Java:
AspectJ: es una extensin 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 ms liviano que AspectJ y en algn 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 cdigo. Los aspectos pueden ser definidos en un XML o mediante atributos runtime. AspectWerkz
utiliza modificacin 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 administracin
dinmica 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 dinmico permitiendo agregar o quitar
interceptores en tiempo de ejecucin.

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 tcnicas que suelen estar acopladas a los
application servers sean reemplazadas por componentes orientados a aspectos. Estos componentes en forma de
aspectos seran agregables de manera dinmica 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 (definicin de usuarios, permisos de acceso, autentificacin), RAD
(Rapid Application Development) para desarrollar interfaces Swing y Web de manera sencilla y rpida.
Herramientas disponibles para .Net
Dentro del framework .Net existen algunas herramientas que facilitaran la implementacin de incumbencias
transversales mediante un proxy que intercepte las llamadas a algunos mtodos. El caso de la validacin 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 validacin, pero por otro lado no hay forma de definir que una
validacin aplica a cierto patrn de campos. La autenticacin de usuarios para todas las pginas de aplicacin
web tampoco se hace en todas las pginas, con lo cual es otro caso de aplicacin de ideas de AOP.

De todas maneras, estas herramientas no son orientadas a aspectos ya que no respetan la propiedad de
cuantificacin y no permiten al usuario definir sus propios aspectos.
Algunas de los frameworks existentes son:
LOOM.net: es la implementacin ms avanzada que aplica a todos los lenguajes que se ejecuten en el
framework .Net
Weave.Net: est basada en la especificacin 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
definindolos desde un punto de vista semntico, con lo cual evitara uno de los problemas de AOP que es la
especificacin mediante sintaxis de los PointCuts, lo cual trae problemas, por ejemplo, al cambiar nombres de
los mtodos. Adems es desarrollado por gente de nuestra facultad.
Visin de futuro

Si bien hay cierta competencia entre los teams de desarrollo de frameworks orientados a aspectos, tambin hay
cierto sentido de colaboracin con el fin de promover AOP. Si se toman las cosas buenas de cada uno de ellos se
podra armar un framework mucho ms potente. Por ejemplo, AspectJ tiene un visualizador de aspectos que
permite visualizar como afectarn los Advice al cdigo del sistema y sera 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 ms en este sentido
con Annotations que permite incorporar a cualquier construccin metadatos que pueden ser utilizados en
conjunto con un framework de aspectos.

Por otro lado es posible que en algn tiempo existan constructores especficos para crear Aspectos, PointCuts,
etc. en los lenguajes Java y .Net.

Tambin existe un proyecto llamado EarlyAspects que toma las ideas de aspectos para la etapa de identificacin
de requerimientos y arquitectura. Hay propiedades como la seguridad, mobilidad, disponibilidad que suelen ser
incumbencias que afectan a ms de un requerimiento y a ms de un componente en la arquitectura. Esto
permitira razonar temprano en el ciclo de desarrollo de software en cuanto a los aspectos, evitando problemas
ms adelante.

Los servicios middleware encajan perfecto con la filosofa de aspectos ya que suelen ser servicios que afectan a
ms de una incumbencia. Se puede utilizar aspectos para tracing, logging, manejo de errores y monitoreo de
performance.
Tambin en este sentido, los application servers estn comenzando a traer nuevos servicios para facilitar el
desarrollo orientado a aspectos. Estos servicios incluiran persistencia de objetos, cache, seguridad y
transacciones entre otros. El desarrollador debera desarrollar objetos Java en forma normal sin preocuparse de
esos temas y luego aplicar los servicios ms tarde.

La integracin de aplicaciones (EAI, Enterprise Application Integration) tambin 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 informacin de las
aplicaciones con el intercambio externo a un bus de informacin comn. Por ejemplo, en un proyecto era
necesario distribuir las notificaciones internas de observers al bus de informacin de integracin, en este caso un
Vitria bus. Adems 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 mtodos que distribuan las notificaciones
internas. En el segundo caso tambin 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 aplicacin por una infraestructura comn. En el ejemplo del que hablaba antes, el acceso a servicios en
una de las aplicaciones era a travs de proxies implementados como singletons, entonces con aspectos Around se

intercept los getInstance para que devuelvan la instancia del proxy de servicio de la infraestructura comn, sin
modificar el cdigo original.
Finalmente es muy til utilizar aspectos para soportar un modelo de datos comn a todas las aplicaciones y para
la implementacin de requerimientos no funcionales.
Segn las conclusiones del proyecto que mencion como ejemplo, el uso de aspectos result en un 95% menos
de lneas de cdigo de integracin, la performance se increment en un factor de 2 y el tiempo de desarrollo se
redujo en un factor de 4.

Segn se espera una de las tendencias ms importantes en tecnologa es que crezca el uso de webservices.
Tambin para esta tecnologa parece ayudar el uso de aspectos. Facilitara la adaptacin de la aplicacin a
cambios en el mundo de los servicios, por ejemplo si un servicio dejar de existir o cambia y tambin para el
encapsulamiento de cdigo de management con aspectos que formaran una capa entre la aplicacin y el mundo
de los servicios

Por el lado negativo, podemos decir que la industria del software todava 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
aplicacin especfica. De todas maneras, existen proyectos que intentan solucionar estos inconvenientes.
Conclusiones

Uno de los objetivos principales de los nuevos lenguajes de programacin es la separacin de incumbencias. En
este sentido la programacin orientada a objetos provee un alto grado de abstraccin, 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 ms de una funcionalidad de la aplicacin. Los aspectos surgen
como un nivel de abstraccin ms por sobre los objetos complementando su uso en beneficio de una mejor
calidad de software. Si bien la programacin orientada a objetos no es la nica propuesta para solucionar el
problema de las incumbencias transversales, es la de mayor aceptacin.
El incremento de soluciones de middleware, el aumento de las actividades de integracin de aplicaciones, as
como el aumento de la tecnologa de webservices parecen dar empuje al desarrollo orientado a aspectos,
facilitando el desarrollo de requerimientos no funcionales y la combinacin y administracin de webservices.
En este momento hay numerosos proyectos de AOP y cada vez es ms el nmero de desarrolladores que cuentan
con el know how acerca de aspectos, pero de todas maneras se puede decir que la tecnologa recin esta dando
sus primeros pasos y queda bastante camino por recorrer para llegar, por ejemplo, al grado de aceptacin que
tiene hoy la programacin orientada a objetos

Bibliografa
1. Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Marc
Loingtier, John Irwin. Aspect-Oriented Programming. ECOOP 1997
2. G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm y W. Griswold. An Overview of AspectJ, ECOOP
2001.
3. James Holmes. AOP: Taking Abstraction One Step Further. Oracle Magazine Septiembre/Octubre 2004
4. Nicols Kicillof. Programacin Orientada a Aspectos (AOP)
http://www.ajlopez.net/ArticuloVe.php?Id=611
5. Arno Schmidmeier, Using AspectJ to Eliminate Tangling Code in EAI-Activities
6. Mara Agustina Cibrn, Bart Verheecke, Modularizing Web Services Management with AOP
7. Anis Charfi1, Mira Mezini. Aspect-Oriented Web Service Composition with AO4BPEL


Sistemas de Administracin de Contenidos
{Content Management System - CMS)

Gabriel Bulfn
gabrielbulfon@hotmail.com

Han pasado varios aos desde que aparecieron en el mercado los primeros productos para la administracin de
contenido orientados principalmente al manejo de sitios web. Pero a pesar de esta evolucin y mejora constante
en un mercado tan competitivo, an se est muy lejos de la madurez y queda mucho por hacer.

Qu es un CMS?

Un CMS es una herramienta de software diseada 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 informacin de soporte como por ej. categorizaciones o
taxonomas).

En un sentido amplio, CMS describe al software que permite a los administradores fundamentalmente
crear y actualizar ms fcilmente los contenidos.

Fig. 1 Manejo de contenidos en un CMS
Algo de historia

Cuando internet dej de ser una herramienta exclusiva del mbito universitario y comenz a
extenderse, muchas empresas decidieron tener presencia en la web publicando sitios que inicialmente
contenan informacin institucional y algunos datos para atraer a potenciales clientes a contactarse
para satisfacer sus inquietudes y principalmente hacer negocios (exhibiendo sus telfonos, direcciones
de email, direcciones postales, etc).

RECOLECCIN
PUBLICACIN
ADMINISTRACIN

Luego descubrieron que mucha gente se acercaba a sus sitios y entonces decidieron proporcionar ms
informacin, principalmente acerca de productos y servicios. Ms adelante comprobaron que internet
estaba a la altura de otros canales, especialmente en lo que se refiere a promocin y comercializacin
de productos y atencin al cliente. Y as aparecieron nuevos elementos como los banners, el e-
commerce y los chats para atencin online.

Tanta informacin 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 altsimos costos de actualizacin. A raz de este notable crecimiento surgi la
necesidad de elaborar herramientas para administrar y organizar esta informacin simplificando las
tareas de creacin, edicin y publicacin de contenidos [5,12] (Fig. 2).

Fig 2 Fuentes y destinos en un ECM.

Conceptos importantes detrs de un CMS

Administrar contenidos implica recolectarlos, administrarlos y publicarlos en los destinos deseados de
manera eficiente.

Las tareas de recoleccin se refieren tanto a la creacin como a la importacin de informacin.
Esta informacin es convertida a un formato comn (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, organizacin y recuperacin de la informacin.

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 recoleccin, administracin y publicacin.

Cundo conviene usar un CMS? [1]

Cuando se presentan algunas de las siguientes situaciones en una organizacin se hace necesario
comenzar a utilizar una herramienta CNS (Fig. 3):

Cuando hay mucha informacin para procesar manualmente (muchos items de contenidos o
muchos tipos de contenido).

Si el diseo de una publicacin necesita ser separado del contenido para que si se necesitase
cambiar el diseo de cada pgina no haya que modificarlo todo a mano.

Cuando son muchos los autores de contenido y los contenidos son entregados en diversos
formatos.

Si la informacin cambia muy rpido como para ser procesada a mano.

Cuando se necesita crear ms de un destino de publicacin a partir de una misma base de
contenido.

Cuando el destino de publicacin requiere personalizacin.

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 reutilizacin de los contenidos.

Podemos manejar diferentes versiones para los contenidos.

Se simplifica el mantenimiento de los contenidos.

Se puede mantener la consistencia de la informacin en varios destinos.

La creacin y publicacin de contenidos es ms fcil.

Caractersticas de un CMS

Existen algunas caractersticas bsicas que deberan 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 tcnicos y no tcnicos. Su interfase debe ser fcil de usar y su arquitectura debe
Muchas publicaciones

Canales de contenido
Personalizaciones
Demasiado cambio

Flujo de contenido
Revisin de diseo
Demasiado contenido

tems de contenido
Tipos de contenido
Muchos colaboradores

Diversidad de autores
Orgenes complejos

ajustarse al marco de trabajo definido por el rea de tecnologa de la organizacin. Adems, debe
manejarse con mens y se deben poder agregar pginas y ser vinculadas fcilmente.

Crear, disear y publicar contenido web debera ser automatizable segn las necesidades de la
organizacin.

Debera 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 diseo de la interfase de usuario debera ser cambiable utilizando templates (por ejemplo
mediante templates XSLT que transformen en HTML a los contenidos representados en
documentos XML)

La herramienta CMS debera poder ser usada para manejar usuarios, grupos, roles y permisos de
forma centralizada. Debera tener la facilidad de autenticar usuarios o grupos que pertenezcan a
dominios Windows o Unix.

Debera poder utilizar las ltimas tecnologas en bases de datos e Internet y ser usada en cualquier
sistema operativo o plataforma.

Tendra que proveer de una buena seguridad para los contenidos. Debera controlar quin est
habilitado para publicar el sitio y quin tiene permitido ver qu contenido.

Debera eliminar el gran volumen de actualizaciones redistribuyendo el trabajo de publicacin
entre los autores de contenido quienes pueden publicar y actualizar sus propios contenidos en
forma simple y a travs de herramientas basadas en navegadores web.

Tendra que reducir los costos y tiempos de mantenimiento. La mayora de las operaciones de
mantenimiento deberan ser automticas.

Para los autores de contenido deben tener facilidades como: seleccionar diferentes tipos de
contenido, cortar y pegar desde otras aplicaciones, poner fechas de publicacin y de vencimiento,
indexacin automtica de pginas y vinculacin.

El CMS debera poder escalar en trminos de performance, integracin con otras aplicaciones y el
agregado de caractersticas particulares.

Debera permitir construir taxonomas o categorizaciones para clasificar los contenidos [11].

Tendra que permitir definir diferentes destinos y para cada contenido poder indicar en qu
destino publicarlo.

Debera facilitar el almacenamiento de contenidos multilenguaje (localizacin).

Debera ayudar a generar mens de navegacin de manera simple y links entre pginas en forma
automtica.

Problemas observados en los CMS

Hay muchas crticas que hacer a los CMS. An los productos comerciales que llevan aos y han
pasado por varias versiones no llegan a cubrir las necesidades de sus usuarios.

Descubrir qu incomoda ms a los usuarios puede ayudar a comenzar a tratar esos problemas
constructivamente. Un informe del Asilomar Institute for Information Arquitecture (AIfIA) identifica

los mayores obstculos detectados para que los CMS sean efectivos [2]. Entre los ms 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 diseo 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 ms de mil productos CMS en todo el mundo. En su gran mayora son desarrollos
pequeos de compaas locales y solo unos pocos pertenecen a vendedores globales.

Los fabricantes estn mejorando continuamente sus productos y sus capacidades varan mucho entre
distintos productos.

Tampoco existe mucho consenso en lo que se refiere a terminologa y funcionalidades. Muchos
conceptos adquieren nombres distintos segn el producto del que se est hablando.

Y en general, no hay una correlacin real entre el precio de los productos y las capacidades que ofrece.

El estudio sectorial, basado en la herramienta analtica conocida como "cuadrantes mgicos" de
Gartner, describe los puntos fuertes y dbiles de los fabricantes en mercados especficos, situando a las
compaas en los cuadrantes segn su visin de mercado y su capacidad de ejecucin.

Para Gartner, las empresas visionarias son aquellas que presentan un enfoque claro sobre la direccin
del mercado y que orientan sus esfuerzos en este sentido, y que todava estn en condiciones de
optimizar sus servicios.

Segn Gartner los lderes tienen los mejores valores combinados de visin de mercado y su capacidad
de ejecucin. Ellos estn trabajando muy bien y estn preparados para el futuro con una visin
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 ms tecnologas o mercados
verticales. Tienen la capacidad de entregar un paquete ECM completo y escalable.


Fig 4 - Cuadrante Mgico para ECM, 2004

Estudios de Gartner predicen que para el ao 2006 el 50% de los actuales fabricantes de ECM se
habrn fusionado o habrn sido adquiridos por otros y que hacia fines de 2007 Microsoft, IBM, Oracle
y SAP compartirn el 50% de las ganancias por productos ECM.

Cmo 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 trminos absolutos. S encontramos una gran variedad de productos
con grandes diferencias en cuanto al diseo 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
cules 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 caractersticas y calidad, y productos
comerciales con valores que van desde mil dlares hasta varios cientos de miles de dlares.

Infraestructura tecnolgica: qu tecnologas se utilizan en la organizacin.

Usabilidad: interfases aptas para ser usadas por redactores y editores de contenido

Metadata: facilidades para definir e incorporar metadata a los contenidos.

Reutilizacin de contenidos: no slo poder publicar contenidos en diferentes destinos sino
tambin poder crear contenidos que contengan otros contenidos (por Ej. un artculo que contenga
links e imgenes) [10]

Repositorios para los documentos: poder elegir en qu motor de base de datos almacenar el
contenido.

Instalacin del producto: simplicidad.

Metodologa de implementacin

Versionado: manejo de versiones de los contenidos.

Motor de bsqueda: provisin de un buscador de contenidos potente, eficiente y con muy buena
performance.

Autosuficiencia de diseo y administracin: facilidades para crear y modificar el diseo para la
presentacin de los contenidos.

Autosuficiencia de desarrollo: buena documentacin de las APIs de programacin para
personalizar tareas de creacin, administracin y publicacin de contenidos.

Administracin de mltiples destinos de distinto tipo.

Caractersticas de los destinos: configuracin de las propiedades ms importantes de los sitios web
(por Ej. si tiene pginas con contenido configurable por el navegante, si admite registracin de
usuarios, etc.)

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

Integracin 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 aos hemos observado cmo todas las tecnologas que giran alrededor de XML se han
ido incorporando a casi cualquier desarrollo de software [9]. En los CMS tambin se puede observar
esta tendencia y en general vemos cmo se utiliza XML para representar a los contenidos y XSLT
para transformarlos y ajustarlos al formato de presentacin deseado. Seguramente esto se convertir en
la espina dorsal de los CMS y probablemente se generen estndares de comunicacin entre los
distintos productos lderes del mercado que permitan la reutilizacin de contenidos inclusive entre
distintas empresas y organismos [13,14].

Por otro lado, tambin nos encontraremos con interfases de carga de contenidos mucho ms amigables
y fcilmente integrables a los distintos programas utilizados actualmente para crear los distintos
contenidos (editores grficos, procesadores de texto, planillas de clculo, etc.)

Si bien este crecimiento ser liderado seguramente por las grandes compaas, probablemente, en un
rea que evoluciona tan rpidamente, habr espacio para que organizaciones ms pequeas se adapten
y desarrollen ms pronto lo que hoy mismo estn reclamando los usuarios.

Referencias

1. Content Nanagement Tutorial http:fferptoday.comfCNSfContent-Nanagement-Tutorial.aspx

2. The Problems with CNS http:ffaifia.orgfpgfthe_problems_with_cms.php

3. How to evaluate a CNS - James Robertson http:ffwww.steptwo.com.aufpapersfkmc_evaluatef

+. Demystifying Document Nanagement - Nichael Bronder - New Architect Octubre 2002
http:ffwww.newarchitectmag.comfdocumentsfs=2+51fna1002af

5. You Need a Content Nanagement System - Nartin Burns
http:ffwww.easyweb.co.ukfarticlesfcms.html


6. Choosing a Publishing System - Elizabeth Chapin - Agosto 1999
http:ffwebmonkey.wired.comfwebmonkeyf99f33findex+a.html?tw=e-business

7. From Chaos to Control - John Clyman - Septiembre 2002 PC Nagazine
http:ffwww.pcmag.comfarticle2f02C17592C+775702C00.asp

8. Content Nanagement Systems at a Glance - John Clyman - Septiembre 2002 PC Nagazine
http:ffwww.pcmag.comfarticle2f0,1759,9+7916,00.asp

9. XNL Puts Content !n Play - Bill Trippe - Narzo 2003
http:ffwww.transformmag.comfdb_areafarchsf2003f03ftfm0303f1_1.shtml

10. Reuse Neans Nore Than Nultichannel Publishing - Ann Rockley - Noviembre 200+
http:ffwww.transformmag.comfcontentmgmtfshowArticle.jhtml?article!D=50900205

11. Putting it Together: Taxonomy, Classification 8 Search - Jeff Norris - Septiembre 2003
http:ffwww.transformmag.comfdb_areafarchsf2003f09ftfm0309f2_1.shtml?fcontentmgmt

12. Nanage Content virtually - Lowell Rapaport - Abril 2003
http:ffwww.transformmag.comfdb_areafarchsf2003f0+ftfm030+tp_1.shtml?fcontentmgmt

13. Looking towards the future of CN - James Robertson - Enero 2003
http:ffwww.steptwo.com.aufpapersfcmb_futuref

1+. Future Trends of Content Nanagement Systems (CNS) for e-Learning: A Tool Based Database
Oriented Approach - Dr. JSR Subrahmanyam
http:ffwww.cdacindia.comfhtmlfpdffSession3.1.pdf


Self-Healing Systems
Mnica Silva
msilva@dc.uba.ar
Introduccin
Actualmente un importante requerimiento en crecimiento de los sistemas basados en software es la habilidad de
adaptarse ellos mismos en tiempo de ejecucin para manejar cosas tales como variabilidad de recursos, cambios
en las necesidades de los usuarios, y fallas del sistema. Esta caracterstica de los sistemas de software es la que
se da por llamar Auto-adaptacin (Self-Adaptation), Auto-Curable (Self-Healing), Auto-Reparacin (Self-
Repair). El desafo de la Informtica Autnoma involucra muchas reas y se aplica en diversos niveles, todos
aportan algn paso en la evolucin de los sistemas autnomos. Investigaciones actuales incluyen temas como:
robotics planning, sistemas de control, diseo de lenguajes de programacin para adaptacin, arquitectura de
software, informtica tolerante a fallas (fault-tolerant), y mquinas 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 heterogneos. La importancia y complejidad de estos
sistemas requiere cada vez ms y ms 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 informtica autnoma. As
como el sistema nervioso autnomo libera a la parte conciente de nuestro cerebro de la carga de lidiar con
detalles vitales pero de las funciones ms bsicas de nuestros sistemas, la informtica autnoma debera liberar a
las administradores de sistemas de la mayora de las tareas rutinarias administrativas y operativas actuales.
Adems en la prctica se arman grupos enormes para sostener cosas que en realidad muchas de las tareas que
incluyen podran ser automatizables. De ese modo las empresas podran orientar sus capacidades de IT hacia el
corazn de sus negocios, en vez de invertir cada vez ms tiempo en lidiar con la complejidad de los sistemas
informticos.
Irving Wladawsky-Berger bosquejo la solucin en el Kennedy Consulting Summit en Noviembre del 2001: Hay
slo una respuesta: la tecnologa 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 tecnologa se comporte como lo hace habitualmente
en esa forma pedante y necesitando de humanos que hagan todo por ella, sta comience a comportarse ms como
una computadora inteligente como nosotros esperamos que sea, y que comience preocupndose 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 ms 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 intrpretes o
traductores de lenguaje mquina a accin. Es decir, hay gente que trabaja de eso, que mira un error code 62 y
dice ah, falta instalar el patch 413. Es bsicamente un traductor! Eso podra ser automatizable. Ms aun,
entonces el sistema sabe que le falta instalar un programa, otra tarea operativa perfectamente automatizable.
Pero veamos, la automatizacin de la administracin de recursos informticos es a caso un nuevo problema o
una nueva necesidad para la ciencia de la computacin? Definitivamente, no. Por dcadas, los componentes de
sistema y el software han evolucionado para lidiar con la creciente complejidad del control de sistemas, recursos
compartidos y administracin de correcto funcionamiento. La informtica autnoma es exactamente la siguiente
evolucin lgica de esa tendencia del pasado dirigida a entornos informticos actuales cada vez ms complejos y
ms distribuidos.
Adems 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 aplicacin de las tcnicas
actuales tornan dicho desarrollo en algo muy costoso en tiempo y en dinero. Y que an realizando las inversiones
necesarias, la aplicacin de dichas tcnicas suelen ser ms y ms complejas a medida que vamos hacia sistemas
de mayor escala, llegando mucho de ello hasta ser impracticables.
Parecera ser que las tcnicas actuales, y la forma de encarar y desarrollar los sistemas es la que no encaja con el
tipo de sistemas que esperamos. Segn marca la experiencia, es una utopa pretender especificacin 100%
completas, que adems ser imposibles de relevar, requeriran un congelamiento de las necesidades de los
usuarios, lo cual es totalmente irrealista.

Por otro lado, en la actualidad es muy elevado el costo que tienen las compaas en la prevencin de cadas de
sistemas, en los procesos de recuperacin, y en las prdidas de transacciones, datos, clientes (o como sea que
se mida su negocio), durante esas cadas, o como efecto colateral de la baja calidad de servicio.

Todas estas cuestiones nos hablan de la necesidad de un giro sustancial en la evolucin tecnolgica hacia un
cambio radical en el desarrollo, entrega y soporte de los sistemas de software:

Eras de Oro de la Informtica:
Era Mainframes la computadora como un activo de la compaa
Era Desktops la computadora como una herramienta personal
Era Redes la computadora como un nodo de una grilla informacin / servicio mundial
Era Informtica Omnipresente (Ubiquitous Comupting)
la computadora como un asistente personal
Computadoras e informacin potencialmente en todo lados
Miles de elementos informticos a nuestra disposicin
Universo heterogneo
o Desktops, mainframes, PDAs, etc
o Aparatos inteligentes
o Computadoras wearable
o Censores y actuators
No slo teclados: interfaces de voz / palabra / gesto
Convergencia de comunicaciones, informacin e informtica
Usuarios mviles

As, los sistemas necesitarn 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
mviles. En cierto mondo se estara forzando una redireccin del esfuerzo en tiempo diseo hacia un esfuerzo en
tiempo de ejecucin.
Qu son los Self-Healing Systems?
Centralmente lo que estara cambiando en los sistemas es su capacidad para manejar automticamente y en
forma optimizada:
cambios en las necesidades de usuarios,
recursos variables,
fallas,
movilidad de usuarios.
Estos seran los Self-Healing Systems.
Existe una amplia variedad de puntos de vistas a cerca de la definicin de self-healing systems: self-healing, self-
configuring, self-optimizing, self-adaptative, self-stabilizing, self-managing, self-*, adaptative, reflective,
congnitive, homeostatic, autonomic. Aunque aun no hay una definicin 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 terminologa y ubicar algunos conceptos y expectativas, consideremos las cuatro
caractersticas fundamentales de los futuros sistemas informticos autnomos propuestas por Ganek en el IBM
Systems Journal 2003:

Self-Configuring: capacidad de adaptarse automticamente a ambiente que cambian dinmicamente.
Alcanzando con esta capacidad a toda la infraestructura IT y con la mnima intervencin humana
posible.
Self-Healing: capacidad de descubrir, diagnosticar y reaccionar a interrupciones. Con el objetivo de
minimizar las cadas del sistema, apuntando a disponibilidad continua.
Self-Optimizing: capacidad de monitorear y ajustar los recursos automticamente. Maximizando
eficientemente la utilizacin de los recursos para satisfacer las necesidades del usuario final sin
intervencin humana.
Self-Protecting: capacidad de anticiparse, detectar, identificar y protegerse a si mismo de ataques de
cualquier origen.

Qu nuevas caractersticas 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.
Autoadaptacin: 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 polticas y estrategias son apropiadas.
Task-driven: conciente de su propsito.

Consecuencias para la ingeniera de software?
Desde el punto de vista de David Garlan los self-healing systems son el producto una nueva etapa en la
evolucin de la programacin. En el pasado, los sistemas que soportaban algn tipo de auto-adaptacin eran
raros, tpicamente asociado a dominios como switches de telecomunicaciones o software de control del espacio
profundo, donde no era una opcin apagar el sistema para hacerle una actualizacin, y donde la intervencin
humana no era siempre posible. Sin embargo, actualmente cada vez ms sistemas tienen estos requerimientos,
incluyendo sistemas de e-commerce y sistemas mviles embebidos. Estos sistemas requieren ejecutar
continuamente con el mnimo descuido humano y la capacidad de hacer frente a recursos variables (ancho de
banda, disponibilidad de servidores, etc.), fallas de sistema (cada 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-reparacin de los sistemas tradicionalmente ha sido manejada dentro de la aplicacin, a nivel de cdigo.
Por ejemplo, tpicamente las aplicaciones utilizan mecanismos genricos como manejo de excepciones o
timeouts para disparar respuestas especficas de la aplicacin frente a una falla o anomala del sistema. Este tipo
de mecanismos tiene la atraccin de poder atrapar el error en el momento de la deteccin, y estn bien
soportados por modernos lenguajes de programacin (ej, excepciones de Java) y libreras runtime (ej, timeouts
para RPC). Sin embargo, tienen el problema de ser difcil de determinar cul es la verdadera fuente del
problema, y por lo tanto que tipo de accin curativa realmente se requiere. Ms aun, en tanto que pueden atrapar
errores, no estn bien adaptados para reconocer anomalas ms suaves, tales como degradacin de la
performance sobre algn camino de comunicacin, o fallas transitorias de un servidor.

El espectro de propuestas de auto-adaptabilidad es amplio. Partiendo de propuestas ms bsicas que combinan
especificaciones de adaptacin con especificaciones de la aplicacin, la idea es separa los asuntos concernientes
a la adaptacin del software de los asuntos concernientes a la funcionalidad especfica de la aplicacin. As,
podemos dar un paso ms en esa separacin con los algoritmos on-line, y luego con algoritmos genricos o
parametrizados, y luego con seleccin de algoritmos, hasta llegar a la programacin evolutiva. Una clara
separacin entre adaptacin del software y funcin del software facilita su anlisis y evolucin independiente.

Entonces, lo que se plantea es que mientras los avances tcnicos en estrechas reas de tecnologa de adaptacin
proveen algn beneficio, los mayores beneficios vendrn desarrollando una extensa metodologa de adaptacin
que abarque desde la adaptacin en pequea escala hasta la adaptacin en gran escala, y a partir de all
desarrollar la tecnologa que soporte el rango total de adaptaciones.

A continuacin se muestran tres principales aspectos que los ingenieros y arquitectos de software deben
replantear en la construccin de sistemas en este contexto:

Tema Tradicionalmente SHS
Manejo de complejidad a travs
de abstraccin
Mostrar propiedades o funciones
ocultando detalles
(ms sutil) mostrar funciones deseadas, tolerar desviaciones
razonables, mostrar requerimientos de recursos que necesariamente
encajen con las expectativas del usuario
Si hay errores que no se
propaguen al usuario
Escribir software correcto Incluir mecanismos de monitoreo y reparacin para detectar errores
y arreglarlos cuando es posible
Disear sistemas teniendo en
cuenta su evolucin
Usar administracin de la
configuracin para construir
sistemas para entornos
reconocibles
Soportar configuracin dinmica y sintonizacin automtica para
tantos entornos diferentes como encuentre

Taxonoma de Temas
Actualmente desde muchas reas de investigacin, tanto en laboratorios como en productos comerciales, se est
comenzando a incluir y considerar muchos de los asuntos relacionados a sistemas autnomos. En su mayora
cada uno ataca algunas caractersticas en particular, y con procesos, tcnicas e implementaciones ad-hoc. Sin
bien no es la aspiracin de mxima, es un camino a recorrer, y el uso y las costumbres de desarrollo con estas
nuevas tendencias, todas aportarn en su medida.

El siguiente es un esquema de clasificacin de aspectos relacionados con los self-healing systems.

Control Theory

Fault tolerance y Dependability Classical techniques
Immunology
General
Autonomic Computing

Networks, Distributed Systems,
Middleware
Adaptive middleware
Adaptive network protocols
Chroma and other CMU OS work
Multi-fidelity systems
Mobile Systems
Ubiquitous Computing
Task-oriented computing
Context-aware computing
Resource-aware computing (including energy-aware,
adaptive resource assignment, etc.)
Agent-based systems
Biology Simulation Biological Models: Santa Fe Institute
User Interfaces User Modeling
Learning by watching
Intelligent tutoring systems
Intelligent user interfaces; Attentive User Interfaces
Collaborative Computing

Dominio de
Aplicacin
Games

Architectural models Architecture-based Adaptation
Algorithms/code-based Self-stabilizing algorithms
Hot swapping
Safe mobile code
Formal models Coordination Languages
Formal reasoning about mobile systems
Genetic algorithms/alternative models AI approaches, including Neural Nets
Amorphous Computing
Multicellular Automata
Agents

Herramientas,
Mecanismos y
Tcnicas
Economic theory

Improve system performance/Resource
usage

Improve user experience; reduce user
distractions

Objetivos
Improve dependability

En esta rea es conveniente distinguir espacio de problemas de espacio de soluciones. Una taxonoma de los
elementos del espacio de problemas de los sistemas self-healing es de suma utilidad ya que por un lado nos
podra permitir entender qu elementos y en qu grado son cubierto (self-heal) por un determinado sistema, y por
otro lado mtodos, mecanismos, tcnicas pueden ser descriptos por el grupo de elementos que cubre o aspira a
cubrir. Una propuesta de esta taxonoma 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 (WOSS02)):
Elementos del modelo del espacio de problemas
91
Modelo de Falla
Duracin de la falla
Manifestacin de la falla
Fuente de la falla
Granularidad
Expectativa del perfil / tipo de falla
Respuesta del Sistema
Deteccin de la falla
Degradacin
Respuesta a la falla
Recuperacin de la falla
Constantes de tiempo
Seguro
Completitud del sistema
Completitud arquitectnica
Conocimiento del diseador
Auto-conocimiento del sistema
Evolucin del sistema
Contexto de diseo
Nivel de abstraccin
Homogeneidad de los componentes
Predeterminacin de comportamiento
Compromiso del usuario en la salud (heal)
Linealidad del sistema
Alcance del sistema
La propuesta de IBM: Informtica Autnoma
Un on demand e-business es un empresa cuyo proceso de negocio integrado de punta a punta a lo largo de todo
la compaa 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 necesitarn abrazar una nueva arquitectura que
les permitir ir ms all de los lmites tradicionales de la compaa. Este contexto operativo on demand tiene
cuatro caractersticas esenciales: integrado, abierto, virtual y autnomo.
La informtica autnoma 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 autnomo, los componentes de sistemas desde el hardware
como las PCs y los mainframes, hasta el software como sistema operativo y aplicaciones de negocio tiene las
cuatro caractersticas fundamentales del self-managing: self-configuring, self-healing, self-optimizing y self-
protecting, tambin llamadas caractersticas self-CHOP.
Estos atributos de self-managing son la base del entorno de la informtica autnoma. Ellos sugieren que las
tareas involucradas en configurar, curar, optimizar y proteger el sistema IT son iniciadas debido a situaciones
que las tecnologas detectan, y que a su vez esas tareas son llevadas a cabo por esas mismas tecnologas.
Conjuntamente, estas caractersticas intuitivas y colaborativas permiten a la empresa operar eficientemente con
pocos recursos humanos, mientras baja el costo y se incrementa la habilidad de la organizacin para reaccionar
al cambio.
Es importante tener en mente que los atributos self-CHOP no son independientes uno de otro. Especficamente,
los cuatro atributos a la vez permiten la habilidad de hacer cambios a la configuracin de uno o ms aspectos del
sistema IT. La motivacin para el cambio de configuracin es diferente para cada uno de los atributos.

La arquitectura de la informtica autnoma se basa en la
premisa de que implementar los atributos self-managing
involucra un control loop (ciclo de control) inteligente.
Este ciclo recolecta informacin 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 autnomo. El elemento administrado es lo
que el administrador autnomo est controlando. El
administrador autnomo es un componente que implementa
un control loop en particular. Este control loop est definido
por la arquitectura de referencia de informtica autnoma,
como lo muestra el grfico de la
derecha.
En una arquitectura de informtica
autnoma,
los control loops facilitan la
administracin del sistema
Estos control loops pueden ser
aplicados en diferentes formas como lo
muestra el siguiente diagrama:


TTADA 2004 Pgina 92 de 92

Un loop puede estar implementado por la combinacin de varios productos y herramientas de
administracin. En el diagrama seran el administrador de configuracin, 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 ejecucin de un recurso en particular

Los control lopp se pueden presentar en dos formas: como herramientas
de administracin o embebidos en recursos del sistema
La utilizacin de estas combinaciones permite explotar al mximo el potencial de la arquitectura de informtica
autnoma que la compaa configure.
Una evolucin, no una revolucin: niveles de madurez y sofisticacin de la
administracin
La incorporacin de las capacidades de autonoma en un contexto informtico es un proceso evolutivo logrado a
travs de la tecnologa pero esto es en ltima instancia implementado por cada empresa a travs de la adopcin
de esas tecnologas, procesos de soporte y conocimientos. A lo largo de la evolucin, la industria continuar
entregando herramientas de self-management para mejorar la productividad de los profesionales IT. Para
entender el nivel de sofisticacin de las herramientas y capacidades que son, y sern, entregadas por la industria,
consideramos los siguientes cinco niveles de madurez de autonoma:

La evolucin de la autonoma aparece gradualmente a lo largo de las cinco fases
En el Nivel Bsico, los profesionales IT administran cada elemento de la infraestructura
independientemente y lo configuran, lo monitorean y ocasionalmente lo reemplazan.
En el Nivel Administrado, las tecnologas de administracin de sistemas pueden ser utilizadas para
recolectar informacin de sistemas dispersos en unas pocas consolas, ayudando a reducir el tiempo que
le toma al administrador recolectar y sintetizar esa informacin, a medida que el entorno IT se vuelve
cada vez ms complejo.
En el Nivel Predecible, nuevas tecnologas se introducen para proveer correlacin a lo largo de varios
elementos de la infraestructura. Esos elementos pueden comenzar a reconocer patrones, predecir la
configuracin ptima y proveer aviso sobre qu curso de accin debera tomar el administrador.
En el Nivel Adaptativo, el contexto IT puede automticamente tomar acciones basado en la informacin
disponible y el conocimiento de qu est sucediendo en el ambiente. A medida que estas tecnologas


mejoran y que la gente se va sintiendo ms cmoda con los avisos y el poder de prediccin de estos
sistemas, las tecnologas pueden progresar hacia el nivel adaptativo.
En el Nivel Autnomo, las polticas y los objetivos de negocio gobiernan la operatoria de la
infraestructura IT. Los usuarios interactan con la herramientas de tecnologa autnoma para monitorear
los procesos de negocio, alterar los objetivos, o ambos.
Cmo evoluciona la tecnologa para soportar informtica autnoma?
Los niveles de madurez de autonoma demuestran que las capacidades self-managing no se pueden incorporar de
a un solo paso rpido. Por el contrario, constituyen un concepto que se impregna en todos los aspectos de un
sistema. La siguiente figura refuerza esta observacin mostrando una posible relacin entre los niveles de
madurez, los tres contextos de toma de decisiones (recurso, composicin de recursos y solucin de negocio), y
las partes del administrador de autonoma:

Progresando a lo largo de los cinco niveles de madurez de autonoma, los negocios pueden evolucionar su
entorno IT hacia niveles completamente autnomos
Esta relacin 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 autonoma.
En segundo lugar, las diferentes partes del administrador de autonoma se implementan en cada nivel de
madurez. Las partes de ejecucin y monitoreo se implementan en los niveles bsico y administrado. De ese
modo, en estos dos niveles los profesionales IT son responsable de realizar las funciones de las partes de anlisis
y planificacin. La parte de anlisis del administrador de autonoma es provista en el nivel de madurez
predecible. En este nivel, los profesionales de IT son responsables de la funcin de planificacin. En el nivel
adaptativo y autnomo, todas las partes del administrador de autonoma estn 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 autnomo soporta el contexto de las soluciones de negocio.
Propuesta desde la Biologa
Un enfoque que parte de fundamentos completamente distinto a los expuestos en los puntos anteriores, es el que
surge inspirado desde la biologa. Es decir, partiendo de conocimientos acerca de elementos del mundo biolgico


intentar hallar los modelos, tcnicas y mecanismos que indiquen cmo mantener la salud, protegerse, conocer
el entorno, adaptarse, reparase.

La biologa est repleta de ejemplos de sistemas con notable robustez y propiedades self-healing. Eso incluye:
Morphogenesis: un clula sola se transforma en un organismo completo siguiendo un programa
codificado en sus ADN que evoluciona en miles de millones de aos.
Heridas curables: casi todos los organismos complejos tiene algn tipo de mecanismo para curar
heridas simples.
Regeneracin: muchos organismos pueden regenerar nuevas cabezas, miembros, rganos enteros u
otros partes de del cuerpos si los originales se pierden o se daan.

Se puede observa tambin que los mtodos de la naturaleza para programar tienen las siguientes propiedades
interesantes:
Conciencia ambiental: aunque las clulas tiene capacidad limitada de comunicacin, ellas reaccionan
en forma diferente en respuesta a caractersticas detectadas del ambiente circundante.
Adaptacin: muchas clulas tiene una gran capacidad de adaptabilidad.
Redundancia: los organismos tpicamente tienen muchas clulas dedicadas a la misma funcin a lo
largo del desarrollo, de modo tal que fallas en clulas individuales no tienen consecuencias sobre le
sistema.
Descentralizacin: no hay una coordinacin global, y hay una comunicacin limitada para la mayora
del proceso de desarrollo. El control se realiza localmente afectado por el comportamiento de las clulas
vecinas.
Otra propuesta: Homeostasis
Esta propuesta se basa en la idea de relajar precisin y completitud de conocimiento, produciendo mayor
elasticidad para los cambios del entorno.
Para muchos sistemas en la prctica, la salud se corresponde con asegurar en forma razonable que el sistema
trabajar suficientemente bien respecto del propsito para el que fue desarrollado.
Suficiente correccin: el grado en el cual un sistema debe ser dependable con el fin de servir para el
propsito 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 deberan perseguir el objetivo de ser suficientemente buenos para la tarea que estn
manejando.

Homeostasis es la propensin de un sistema a resistir automticamente 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 operacin normal, o la mejor aproximacin posible a ese estado, como resultado de su operacin
normal. Esa operacin debera tanto mantener un buena operacin normal, como as tambin implcitamente
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 metodologa de
adaptacin que abarque desde la adaptacin en pequea escala hasta la adaptacin en gran escala, y a partir de
all desarrollar la tecnologa que soporte el rango total de adaptaciones. A continuacin de se muestran dos
propuestas basadas en arquitecturas.
An Architecture-Based Approach to Self-Adaptive Software


Oreizy y otros en An Architecture-Based Approach to Self-Adaptive Software.abordan este tema de lleno y
proponen un proceso de alto nivel en
un mtodo de propsito general para
sistemas de software auto-adaptables
(self-adaptative). La siguiente figura
muestra el proceso.

Adems de proponer el mtodo
general, los autores proponen
mtodos, tcnicas y herramientas
actuales existentes, en desarrollo o en
etapa de investigacin, para cada
etapa del proceso. Es decir, que no se
quedan en un modelo meramente
terico sino que incluyen en la
propuesta elementos prcticos, claro
que no masivamente probados. Si
bien cada aspecto del mtodo
propuesto ha sido el foco de muchas
investigaciones, lo novedoso es la
integracin de todos estos aspectos en
una metodologa de software auto-adaptativo conjunta.
Increasing System Dependability through Architecture-based Self-repair
Por otro lado una tcnica en importante crecimiento para mejorar la cualidad dependability de los sistemas es
proveer al sistema en tiempo de ejecucin 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 ms difciles es determinar cundo es necesario un cambio, y conocer qu tipo de
adaptacin se requiere. Garlan y otros en Increasing System Dependability through Architecture-based Self-
repair describen una solucin parcial en la cual en tiempo de ejecucin se mantienen modelos de diseo
arquitectnicos estilizados (stylized) como un vehculo para monitorear el comportamiento del sistema
automticamente , para detectar cundo el comportamiento del sistema cae ms all de cierto rango aceptable, y
para decidir un estrategia de reparacin de alto nivel. La siguiente figura muestra el marco de adaptacin
propuesto:

La principal caracterstica innovadora de esta
propuesta es la capacidad de especializar un marco
runtime de adaptacin genrico para soportar estilos
arquitectnicos y caractersticas particulares de
inters. Especficamente, una descripcin formal de
un estilo arquitectnico define para una familia de
sistemas relacionados las condiciones bajo las cuales
la adaptacin debe ser considerada, provee una base
analtica para detectar anomalas, y sirve como una
base para desarrollar estrategias de reparacin
acordes.


El mtodo 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.
Adems los autores van un paso ms all, y llevaron adelante una prueba a modo de ejemplo para describir de
punta a punta cmo cada elemento del marco de adaptacin propuesto funciona conjuntamente para lograr la
adaptacin en tiempo de ejecucin. 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 tambin se aplican mtodos, herramientas y estndares existentes en cada elemento para armar la aplicacin
final.

El experimento incluye grficos de comparacin de comportamiento del sistema con y sin reparacin:

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 informacin run time relevante?
Es razonable esperar que las tcnicas de anlisis puedan manejar un conjunto suficientemente amplio de
aspectos para informarnos estrategias de reparacin?
Desarrollar mecanismos que provean una adaptabilidad ms ricas a los sistemas que se estn ejecutando.
Nuevas capacidades de monitoreo, e infraestructura reutilizable para relacionar valores monitoreados
con las arquitecturas.
Nuevos mtodos analticos para arquitectura que nos permitan especificar los principios de las polticas
de adaptacin.
Investigar mecanismos de polticas de reparacin ms inteligentes.
Link entre arquitecturas y requerimientos.
Adaptaciones del sistema necesarias a raz de cambios en las necesidades del usuario.
Desarrollo de instancias concretas de la propuesta para algunos de los marcos arquitectnicos habituales,
ej. EJB, Jini, y CORBA.
Casos prcticos de la industria IT
Introduccin
Esta seccin es el resultado de la bsqueda de aplicaciones (utilizacin) de los conceptos de self-healing systems
presentados en los primeros apartados de este informe.


La bsqueda comenz dentro de Microsoft. Luego qued muy asociada a IBM y partners debido a la utilizacin
del trmino autonomic como patrn de bsqueda. Y luego utilizando referencias as adquiridas, y bsqueda de
trminos en conjuncin con J2EE se complet esta etapa.
A continuacin se presenta una descripcin muy general del material hallado, resaltando algunos puntos
relevantes. Incluyendo tambin algunos comentarios y conclusiones arribados realizando estas bsquedas.
De todo el material encontrado se extrajeron algunas partes de notas y sitios que se incluyen textualmente en la
ltima seccin Error! Reference source not found.. Algunos son breves y otros no tanto, lo cual ha sido
intencional ya que considero que algunos podran aportar mayor claridad que un resumen, como as tambin
exponer ms claridad y detalle sobre los diferentes temas asociados.
En la presentacin detallada de los resultados obtenidos no se respet el orden en que fueron encontrados sino el
siguiente: primero casos varios extrados de artculos de revistas y sitios de informacin de informtica y
tecnologa a fin de presentar inicialmente un abanico ms amplio y menos tendencioso; en segundo lugar se
presentan los casos Microsoft slo algunos a modo de ejemplo-; y por ltimo los casos IBM. En general, todos
ellos contienen una referencia temporal de publicacin, e incluyen un link al sitio de donde fue extrado el
material.
Descripcin general
El tema self-healing systems e informtica autnoma ha evolucionado mucho desde su surgimiento, digamos ao
2001 aproximadamente, hasta hoy. Incluso hoy en da sigue siendo un tema abierto y cada vez con ms
variantes. Pero es cierto que desde aquel tema lleno de propuestas y buenas intenciones a hoy hay ms puestas en
prctica.
En la bsqueda de casos de estudio surgieron principal y mayoritariamente herramientas de soporte para la
administracin de recursos el rea IT. Si bien esta no fue la intencin, y se trat de desviar la bsqueda, es
natural encontrarse con esto ya que es all donde se focaliz la atencin del rea: si queremos menos skill para
administrar los recursos contemos con herramientas ms poderosas e inteligentes que monitoreen, sugieran o
hagan lo que nuestros operadores deberan hacer. Si miramos la taxonoma 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 ms claro:

Control Theory
Fault tolerance y Dependability
Immunology
General
Autonomic Computing

Networks, Distributed Systems
Mobile Systems
Ubiquitous Computing
Biology Simulation
User Interfaces
Collaborative Computing
Dominio de Aplicacin
Games

Architectural models
Algorithms/code-based
Formal models
Genetic algorithms/alternative models
Agents
Herramientas, Mecanismos y
Tcnicas
Economic theory

Improve system performance/Resource usage
Improve user experience; reduce user distractions
Objetivos
Improve dependability



Ms que posiblemente existan casos sobre los temas no coloreados, pero en principio no surgieron en esta
bsqueda. 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 estn fuera del alcance de los temas de
inters de la materia del contexto de este informe (para ms informacin ver Error! Reference source not
found.).

Retomando el material encontrado, estas herramientas tiene distintas formas de presentacin. Algunas son
propuestas de lenguajes estndares a usar para publicar o leer informacin de estados cambiantes. Otras son
modelos de desarrollo, de armado de arquitecturas y orquestacin de toda la infraestructura IT, generalmente
acompaados de mdulos o paquetes de software que refieren a cierta parte de la salud, o monitoreo, o facilidad
de administracin, o anlisis, o balanceo de carga, incluso varios de ellos adaptados para varias de las
tecnologas actualmente ms comunes.
En este tipo de herramientas IBM parece haber sido el precursor del tema ya que es notoria la claridad y
distincin detallada de los aspectos de autonoma que cubre cada una de sus herramientas. Tambin, es notorio
que cada vez ms varias empresas y tecnologas se encuentran en proyectos aliados con IBM implementando en
sus productos estos conceptos.
Particularmente IBM ofrece un toolkit de informtica autnoma, un conjunto de herramientas que cubren los
distintos aspectos y partes de la autonoma de distintas herramientas y recursos, como servidores, bases de datos,
SO, etc. Adems algunos de estos componentes o estndares vienen incluidos en algunos de sus productos.

Por su lado Microsoft, si bien no expone documentacin sobre teoras, estudios o fundamentos del por qu
sistemas autnomos o self-*, menciona y asigna todas estas cualidades y beneficios en casi todas sus
herramientas actuales. Incluso el framework .NET parecera ser la base que rene y sustenta todos estos
conceptos ahora y en el futuro.

En lo que refiere a la competencia y diferencia de visin entre IBM y Microsoft sobre el tema rescatamos el
siguiente comentario extrado de un artculo:
IBMs Barel said that the biggest difference between IBM and its competitors is the breadth of how were
approaching it. The value of autonomics is greatest when you can provide autonomic behavior across the entire
infrastructure. With Microsoft, its about a new way to build apps from [the] start to instrument them for better self-
management behavior. With IBM, its 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 autnomos de IBM:
In addition to the blueprint, IBM has made some new tools available on its
Alphaworks site to help users develop autonomic systems that will be compliant with
the blueprint. These include the Log & Trace Tool, which puts log data from different
system components into a common format. The Agent Building and Learning
Environment (Able) is a rules engine for complex analysis. Business Workload
Management utilizes the ARM standard to help identify the cause of bottlenecks and
adjust resources as needed to meet performance objectives. And the Tivoli Autonomic
Monitoring Engine has embedded self-healing technology. In addition, in May, IBM


acquired Think Dynamics, maker of an orchestrated provisioning solution that will be
incorporated into the blueprint.
Self-Healing IBM vs Microsoft
IBMs Barel said that the biggest difference between IBM and its competitors is the breadth of how were
approaching it. The value of autonomics is greatest when you can provide autonomic behavior across the entire
infrastructure. With Microsoft, its about a new way to build apps from [the] start to instrument them for better self-
management behavior. With IBM, its 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. Microsofts 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 HPs 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
Microsofts ADS tool and the SDM.
Propuesta de HP
Launched in May, HPs 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-Packards 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. Suns 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.
According to Bill Mooz, director of Sun Microsystems Utility Computing, N1 will be leveraged in
the firms utility computing strategy. "Today, were seeing that the infrastructure is where most
of the action is, around pay-per-use models for acquiring hardware, software and storage. Sun is
fully committed to this model.

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.


Automation of an IT process starts by analyzing the necessary steps. This includes
assessing the roles of personnel, applications, and systems - then orchestrating
that information into a sequence of automated steps. OpalisRobot provides this
ability and rewards organizations with increased productivity and efficiency,
enabling the return on investment originally promised from IT assets.
OpalisRobots 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 customers incident report if the customer decides to open a support case via the Self-Healing
interface. When requested, customers can easily send additional data files through the self-healing infrastructure.

HP is delivering on its promises
HP is driving customer time-saving services into the most customer-visible phase of the software lifecycle. With the HP
OpenView Self-Healing services, HP is delivering on its promises to personalize the customer experience and enable
proactive management.

Supported products and platforms
The current version of Self-Healing services (version 1.30) supports HP OpenView Network Node Manager, OpenView
Operations-Unix, OpenView Operations-Windows, Service Desk/Windows, and OVPA. Supported platforms are HP-UX
11.x, Solaris 2.6 - 2.9, and Windows XP, NT, and 2000.


Application Performance Solutions for Web-J2EE
VERITAS i for Web-J2EE
VERITAS i for Web-J2EE provides a complete application performance management solution for web-based
applications anchored by J2EE application servers. The integrated solution allows IT managers to quickly isolate poor
performing web pages and transactions then correlate them with the appropriate J2EE methods. This ensures that IT
managers focus on the definitive root cause of the problem - not the symptoms.

Web-based applications continue to play a key role for all businesses. When performance problems begin to impact end-
users, IT managers need detailed information. It's not enough to know there is a problem - IT managers need to know
where the problem is and how to fix it. The performance data collected from the web client, web server, and J2EE tier is
comprehensive but does not introduce overhead. The VERITAS i3 for Web-J2EE solution is designed to be run in a
production environment.

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

Application Performance Solutions for SAP
VERITAS i for SAP enables you to guarantee the performance of SAP Applications
VERITAS i delivers a proven Application Performance Management solution that continuously collects high-quality
metrics from each supporting tier of the SAP infrastructure (web server, application server, database and storage) and
correlates these metrics to build a clear picture of SAP performance from the end-user perspectiveresponse 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 applicationor even a part of an applicationcauses a problem, the operating system fixes it. For example, if
a newly installed application has a dynamic-link library (DLL) with a name identical to another application's DLL, the
Installer knows to store the two files in different folders.
To further ensure that applications work correctly with Windows, Microsoft joined forces with business customers and
independent software vendors (ISVs) to create an application certification program. To be certified, an application must
meet technical reliability criteria, such as minimizing DLL conflicts, providing self-repairing installation, and maintaining
user settings.

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


optimization, self-configuration and also self-healing. SQL Server can grow and shrink the database automatically. SQL
Server can also self-optimize and self-manage through query optimization, automatic memory configuration, automatic
processor utilization/thresholds and by providing innovative wizards to help administrators perform the routine tasks that
normally drive up the cost of data management. Other products still rely on administrators tweaking knobs and pushing
buttons to configure the database.

Microsoft believes that having a self-configuring database that can adjust automatically to changes in the databases
operating environment such as memory constraints, network bandwidth, and processor utilization, provides the best
benefit to the customer with regards to performance, cost savings, and the ability for administrators to provide higher-
value services rather than low-level tweaking of the data management platform. Click to view some of the innovations in
self-management that SQL Server provides such as the Index Tuning Wizard, auto-management interfaces, and query
optimization.

Read how Pennzoil leveraged the self-tuning and management innovations of SQL Server to lower their costs and boost
their productivity at http://www.microsoft.com/resources/casestudies/CaseStudy.asp?CaseStudyID=11220.

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

Microsoft .NET Framework Developer Center
Features Overview
The .NET Framework 1.1 is an integral Microsoft Windows component for building and running the next generation of
software applications and Extensible Markup Language (XML) Web servicescomponents that facilitate integration by
sharing data and functionality over the network through standard, platform-independent protocols such as XML, SOAP,
and HTTP.
The .NET Framework provides:
A highly productive, standards-based environment for integrating existing investments with next-generation
applications and services.
The agility to solve the challenges of deployment and operation of enterprise-scale applications.
The .NET Framework consists of two main parts: the common language runtime (CLR) and a unified set of class libraries,
including ASP.NET for Web applications and Web services, Windows Forms for smart client applications, and ADO.NET
for loosely coupled data access.

Improved Operations
Improve Performance The .NET Framework improves the performance of typical Web applications. ASP.NET
includes advanced compilation and caching features that can improve performance dramatically over existing Active
Server Pages (ASP) applications.
Simplify Application Deployment With .NET Framework metadata technology, installing applications is as easy as
copying them into a directory. Side-by-side execution helps to eliminate "DLL hell" and other potential versioning
conflicts. Smart client applications may even be deployed to client desktops in the same manner as Web applications,
through remote Web servers, with No-Touch Deployment. The .NET Framework is capable of self-healing when
applications are damaged, and applications can be upgraded while they are running.
Run More Reliable Applications The .NET Framework includes technologies to make applications more reliable. For
example, memory, threads, and processes are managed by the .NET Framework to ensure that memory leaks don't occur.
And ASP.NET monitors running Web applications and can automatically restart them at administrator-defined intervals.
Be Confident with Code Access and Role-based Security The .NET Framework security system provides fine-
grained, method-level control over what applications can and can't do based on who wrote the code, the purpose of the
code, where it was installed from, and who is trying to run it.



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

An autonomic computing roadmap
Nicholas Chase, President, Chase & Chase, Inc.17 Feb 2004, Updated 21 Oct 2004
Cutting through the hype
The tools within the Autonomic Computing Toolkit (see Resources) are the first steps toward bringing to you an
architecture that enables system components to not only think, but also to converse with each other in order to think better.
An autonomic computing architecture consists of several core capabilities:
Solution installation and deployment technologies
Integrated Solutions Console
Problem determination
Autonomic management
Provisioning and orchestration
Complex analysis
Policy-based management
Heterogeneous workload management
I'll discuss each of these goals, and show you how you can start working towards them.
Problem determination
Now, the whole idea of an autonomic computing architecture is to create a system that's self-configuring, self-healing,
self-optimizing, and self-protecting. In order to do that, the system needs to be able to recognize problems, determine their
cause, and take the appropriate action to correct the problem. The most logical way to do that would be through the use of
logs.
If you're an application developer, you know what logs are typically used for: tracking back to a problem if the user finds
one. Most of the time, they're not meant for general consumption. In fact, in many cases, application logs are meant for
just one person -- the application developer. The application developer knows that if the system is shutting down
unexpectedly, he or she is looking for an event that says "unexpected termination." Or is it "unexpected quit"? Or "Help!
The monkey's running loose with a pointed stick!"
The point is that in order for an automated system to be able to use log files in determining a problem, logs must have a
common format.
That format is the Common Base Events format, an XML-based vocabulary. Common Base Event V1.0.1 defines eleven
situation categories -- StartSituation, StopSituation, ConnectSituation,
ConfigureSituation, RequestSituation, FeatureSituation,
DependencySituation, CreateSituation, DestroySituation, ReportSituation,
AvailableSituation -- and provides an OtherSituation category to support product specific
requirements. If an application outputs events in this format, an autonomic computing system can use that information to
determine when and if there's a problem and what to do about it by correlating events into situations. For example, one
possible (and highly simplified) situation could be:
Listing 1. Simplified example
Application server can't connect to the database


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

The Control loop is the system by which events can be
detected and dealt with. The process involves four steps:
1. Monitor: First, the system looks for the events, detected by the sensor from
whatever source -- be it a log file or an in-memory process. The system uses
the knowledge base to understand what it's looking at.
2. Analyze: When an event occurs, the knowledge base contains information that
helps to determine what to do about it.
3. Plan: After the event is detected and analyzed, the system needs to determine what to do about it using the
knowledge base. The symptom database might have information, or a central policy server might determine the
action to take.
4. Execute: When the plan has been formulated, it's the effector that actually carries out the action, as specified in
the existing knowledge base.
Although the control loop is a single conceptual process, it doesn't have to be carried out by a single product. For example,
IBM Director and Toshiba ClusterPerfect products can share the control loop, with Director carrying out the monitor
and analyze processes and ClusterPerfect carrying out the plan and execute steps.
The Autonomic Computing Toolkit includes the Autonomic Management Engine (AME), which can perform all of these
steps for you. Of course, AME needs to be able to communicate with your product, which isn't as complicated as it
sounds. AME can communicate with any product as long as there is an appropriate Resource Model in place. The
Resource Model tells AME what it's looking for, be it a log entry or the status of a particular process.
You can create your own Resource Model using the Autonomic Computing Toolkit's Resource Model Builder Tool,
which can be integrated into WebSphere Studio Application Developer or the Eclipse IDE.
Provisioning and orchestration -> IBM Tivoli Provisioning Manager
Complex analysis
As you might have surmised by now, some of this processing can involve some fairly complex logic. In the case of a Java
technology implementation (such as that provided by the Autonomic Computing Toolkit), you might opt to use JavaBeans
components that provide artificial intelligence-like capabilities.
Still in its early stages, the Autonomic Computing Toolkit will ultimately include software that
provides these capabilities. To get an idea of how this might eventually work, it's helpful to look
at an emerging technology tool, the Agent Building and Learning Environment (ABLE) 2.0,
currently available on IBM alphaWorks (see Resources). ABLE provides AbleBeans such as Data
Beans to read and write data to and from various sources, Learning Beans that implement
reasoning such as decision trees and Bayesian reasoning, and Rules Beans such as forward



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

New to Autonomic computing
What IBM tools and products are available for autonomic computing?
What IBM tools and products are available for autonomic computing?
For starters, Download the Autonomic Computing Toolkit at no charge. Available on Linux, AIX,
and Windows, the Toolkit offers tools and technologies that let you implement autonomic
problem determination, solution installation, and common system administration. Download it,
try it out, and join the Autonomic Computing Toolkit user forums to discuss your experience.
You'll discover that at IBM, we think so highly of autonomic computing technology that we use it
in our own products:
DB2 UDB Stinger and autonomic computing make a good pair. Read this article to learn why.
For a glimpse of orchestration and provisioning in action, take a peek at how IBM Tivoli Identity Manager with
IBM Tivoli Directory Integrator provision identities to a third-party application.
Take a look at the many intersections between autonomic computing technology and WebSphere products in
this set of articles on WebSphere and autonomic computing.
In this article about the integration of IBM Tivoli Access Manager 3.9 with WebSphere Application Server
you'll see autonomic features working to enable self-healing systems.
For more information on autonomic computing function being woven into IBM products, check these Web
sites:
o developerWorks Grid computing
o developerWorks DB2
o developerWorks Tivoli
o developerWorks WebSphere


Understand the autonomic manager concept
Real life examples of autonomic managers
Currently, autonomic computing is still new and is constantly evolving. You will, however, find
autonomic manager features currently available in some tools and products. For example, DB2
is available as a trial download so that you can start investigating the autonomic features right
away.
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.

Bibliografa

A. G. Ganek and T. A. Corbi. The dawning of the autonomic computing era. IBM Systems Journal,
Special Issue on Autonomic Computing.Vol 42, No 1, 2003.
Avizienis, J.-C. Laprie and B. Randell. Fundamental Concepts of Dependability, Research Report
N01145, LAAS-CNRS, April 2001. (citeseer, local)
D. Garlan, S. Cheng, and B. Schmerl. Increasing System Dependability through Architecture-based
Self-repair. In Architecting Dependable Systems, R. de Lemos, C. Gacek, A. Romanovsky (Eds),
Springer-Verlag, 2003.
David Garlan Curso Self-Healing Systems, Carnegie Mellon University, Spring Semestre 2003.
IBM An architectural blueprint for autonomic computing IBM and autonomic comuting,
ibm.com/autonomic, April 2003.
Koopman, P. Elements of the self-healing system problem space. Workshop on Architecting Dependable
Systems (WADS03), May 2003.
M. Shaw. 'Self-Healing': Softening Precision to Avoid Brittleness. Proceedings of the First ACM
SIGSOFT Workshop on Self-Healing Systems (WOSS '02). Charleston, South Carolina, November 2002,
pp.111-113.
Mary Shaw. Beyond Objects: A Software Design Paradigm Based on Process Control. ACM Software
Engineering Notes, Vol 20, No 1, January 1995.


Oriezy, P., Gorlick, M.M., Taylor, R.N., Johnson, G., Medvidovic, N., Quilici, A., Rosenblum, D., and
Wolf, A. An Architecture-Based Approach to Self-Adaptive Software. IEEE Intelligent Systems
14(3):54-62, May/Jun. 1999.
S. George, D. Evans, and L. Davidson. A biologically inspired programming model for self-healing
systems. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

Links de inters
David Garlan Curso Self-Healing Systems, Carnegie Mellon University, Spring Semestre 2003.

Temas de investigacin sobre Ubiquitous Computing puede encontrarse en Seventh International
Conference on Ubiquitous Computing (UBICOMP05).

Trabajos preliminares y afines sobre Ubiquitous Computing pueden encontrase en conferencias anteriores
http://www.ubicomp.org/previous_conferences.html

Temas de investigacin sobre Self-Healing Systems puede encontrarse en el Workshop on Self-Healing
Systems (WOSS02).

IBM Systems Journal, Special Issue on Autonomic Computing

Temas de investigacin sobre Self-Managed Systems puede encontrarse en el Workshop on Self-Managed
Systems (WOSS04).

Bibliografa ms 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 anlisis dinmico (en tiempo de ejecucin) pueden
encontrarse en Second International Workshop on Dynamic Anlisis (WODA04).

Trabajos del amplia rea de Autonomic Computing pueden encontrarse en First IEEE International
Conference on Autonomic Computing (ICAC04).

IBM Autonomic computing for develpers.

Tema
Subtema
Bibliografa

Control Theory
Fault tolerance
Immunology General
Autonomic Computing


A. G. Ganek and T. A. Corbi. The dawning of the autonomic computing era. IBM Systems Journal, Special Issue on Autonomic Computing.Vol
42, No 1, 2003.
M. Shaw. 'Self-Healing': Softening Precision to Avoid Brittleness. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems
(WOSS '02). Charleston, South Carolina, November 2002, pp.111-113.
Avizienis, J.-C. Laprie and B. Randell. Fundamental Concepts of Dependability, Research Report N01145, LAAS-CNRS, April 2001. (citeseer,
local)
Mary Shaw. Beyond Objects: A Software Design Paradigm Based on Process Control. ACM Software Engineering Notes, Vol 20, No 1, January
1995.

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

Architecture-based Adaptation
Model-based
Approaches
Rainbow-like approaches
Oriezy, P., Gorlick, M.M., Taylor, R.N., Johnson, G., Medvidovic, N., Quilici, A., Rosenblum, D., and Wolf, A. An Architecture-Based Approach
to Self-Adaptive Software. IEEE Intelligent Systems 14(3):54-62, May/Jun. 1999.
D. Garlan, S. Cheng, and B. Schmerl. Increasing System Dependability through Architecture-based Self-repair. In Architecting Dependable
Systems, R. de Lemos, C. Gacek, A. Romanovsky (Eds), Springer-Verlag, 2003.
Ioannis Georgiadis, Jeff Magee and Jeff Kramer. Self-Organising Software Architectures for Distributed Systems. Proceedings of the First ACM
SIGSOFT Workshop on Self-Healing Systems (WOSS '02).
Gross, P.N., Gupta, S., Kaiser, G.E., Kc, G.S., Parekh, J.J. An Active Events Model for Systems Monitoring. Proceedings of the Working
Conference on Complex and Dynamic System Architecture, Brisbane, Australia, Dec 2001.
Combs, N., Vagel, J. Adaptive Mirroring of System of Systems Architectures. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing
Systems (WOSS '02).
Bond, A., Sud, J. Service Composition for Enterprise Programming. Proceedings of the Working Conference on Complex and Dynamic System
Architecture, Brisbane, Australia, Dec 2001.
Eric M. Dashofy, Andr van der Hoek, Richard N. Taylor. Towards architecture-based self-healing systems. Proceedings of the First ACM
David Garlan, Bradley Schmerl. Model-based adaptation for self-healing systems. Proceedings of the First ACM SIGSOFT Workshop on Self-
Healing Systems (WOSS '02).
Rogrio de Lemos, Jos Luiz Fiadeiro. An architectural support for self-adaptive software for treating faults. Proceedings of the First ACM
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
David S. Wile. Towards a synthesis of dynamic architecture event languages. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing
Systems (WOSS '02).
Jonathan Aldrich, Vibha Sazawal, Craig Chambers, David Notkin. Architecture-centric programming for adaptive systems. Proceedings of the
First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).
Nathan Combs, Jeff Vagle. Adaptive mirroring of system of systems architectures. Proceedings of the First ACM SIGSOFT Workshop on Self-

Task-oriented computing
Context-aware computing
Resource-aware computing (including energy-aware, adaptive
resource assignment, etc.)
Mobility, Ubiquitous
Computing, OS
Support
Agent-based systems


Joao Pedro Sousa, David Garlan. Aura: an Architectural Framework for User Mobility in Ubiquitous Computing Environments.
Rajesh Balan, Joao Pedro Sousa, M. Satyanarayanan. Meeting the Software Engineering Challenges of Adaptive Mobile Applications.
Shankar R.Ponnekanti, Brian Lee, Armando Fox, Pat Hanrahan,and Terry Winograd. ICrafter: A Service Framework for Ubiquitous Computing
Environments.
Asim Smailagic and Daniel Siewiorek.Application Design for Wearable and Context-Aware Computers. IEEE Pervasive Computing, Vol. 1, No, 4,
Dec 2002, pp. 20-29.
Michael N. Huhns, Vance T. Holderfield, Rosa Laura Zavala Gutierrez. Robust Software Via Agent-Based Redundancy. AAMAS03, July 1-2, 2003,
Melbourne, Australia.
Robert E. Smith and Nick Taylor. A Framework for Evolutionary Computation in Agent-Based Systems.
E. Grishikashvili. Investigation into Self-Adaptive Software Agents Development. Distributed Multimedia Systems Engineering Research Group
Technical Report. 27 April 2001.
Guoqiang Zhong, Babak Hodjat, Tarek Helmy and Makoto Amamiya. Software Agent Evolution in Adaptive Agent Oriented Software Architecture.
International Workshop on Principles of Software Evolution, pp. 130-134, 1999.
Jason Flinn and M. Satyanarayanan. Energy-Aware Adaptation for Mobile Applications. Proceedings of the 17th ACM Symposium on Operating
Systems Principles (SOSP), 1999.
Chen Lee, John Lehoczky, Raj Rajkumar and Dan Siewiorek. On Quality of Service Optimization with Discrete QoS Options. Proceedings of the
IEEE Real-time Technology and Applications Symposium, June 1999.
Rolf Neugebauer and Derek McAuley. Congestion Prices as Feedback Signals: An Approach to QoS Management. Proceedings of the 9th ACM
SIGOPS European Workshop, pp. 91--96, Kolding, Denmark, September 2000.
Satyanarayanan, M. The Evolution of Coda. ACM Transactions on Computer Systems, Volume 20, No. 2, May 2002.
C. Dabrowski, K. Mills. Understanding self-healing in service-discovery systems. Proceedings of the First ACM SIGSOFT Workshop on Self-

Biological Models: Santa Fe Institute
AI approaches, including Neural Nets
Amorphous Computing
Alternative Models of
Computation
Multicellular Automata
Radhika Nagpal, Attila Kondacs, and Catherine Chang. Programming Methodology for Biologically-Inspired Self-Assembling Systems. AAAI
Symposium '03.
Stephanie Forrest, Steven A. Hofmeyr, and Anil Somayaji. Computer immunology. Communications of the ACM, v.40 n.10, p.88-96, Oct. 1997.
Stephen F. Bush and Amit B. Kulkarni. Genetically Induced Communication Network Fault Tolerance. SFI Workshop: Resilient and Adaptive
Defence of Computing Networks 2002.
S. George, D. Evans, and L. Davidson. A biologically inspired programming model for self-healing systems. Proceedings of the First ACM
Orna Raz, Philip Koopman, Mary Shaw. Enabling automatic adaptation in systems with under-specified elements. Proceedings of the First ACM
Johann Schumann, Stacy Nelson. Toward V&V of neural network based controllers. Proceedings of the First ACM SIGSOFT Workshop on Self-

Self-stabilizing algorithms
Hot swapping
Algorithms and Code
Safe mobile code
Sanny Gustavsson, Sten F. Andler. Self-stabilization and eventual consistency in replicated real-time databases. Proceedings of the First ACM

Adaptive middleware
Adaptive network protocols
Chroma and other CMU OS work
Networks, Distributed
Systems, and
Middleware
Multi-fidelity systems


Fabio Kon, Fabio Costa, Gordon Blair, Roy H. Campbell. Adaptive middleware: The case for reflective middleware.Communications of the ACM,
June 2002, Volume 45, Issue 6.
Loyall, J., Schantz, R., Zinky, J., Pal, P., Shapiro, R., Rodrigues, C., Atighetchi, M., Karr, D., Gossett, J.M., Gill, C.D. Comparing and contrasting
adaptive middleware support in wide-area and embedded distributed object applications. 21st International Conference on Distributed Computing
Systems, April 2001, pp. 625-634.
Narasimhan, P., Moser, L.E., Melliar-Smith, P.M. Strong replica consistency for fault-tolerant CORBA applications. The Sixth International
Workshop on Object-Oriented Real-Time Dependable Systems, 2001, pp. 10-17.
D. Reilly, A. Taleb-Bendiab, A. Laws, N. Badr. An instrumentation and control-based approach for distributed application management and
adaptation. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '02).

Fault Tolerance and
Dependability
Classical techniques
Koopman, P. Elements of the self-healing system problem space. Workshop on Architecting Dependable Systems (WADS03), May 2003.
Shelton, C., Koopman, P. & Nace, W. A framework for scalable analysis and design of system-wide graceful degradation in distributed embedded
systems. WORDS03, January 2003.

Coordination Languages
Formal Models
Formal reasoning about mobile systems
Jeff Magee, Naranker Dulay, Susan Eisenbach, and Jeff Kramer. Specifying Distributed Software Architectures. Fifth European Software
Engineering Conference, Barcelona 1995.
Antnia Lopes, Jos Luiz Fiadeiro, and Michel Wermelinger. Architectural Primitives for Distribution and Mobility. SIGSOFT 2002/FSE-10, Nov.
18-22, 2002, Charleston, SC, USA.

Ms bibliografa (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.
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.
Walker, Murphy, Steinbok and Robillard. Efficient Mapping of Software System Traces to Architectural Views. Proc. of CASCON, November
2000.
Jonathan Aldrich, Craig Chambers, and David Notkin. ArchJava: Connecting Software Architecture to Implementation. In proceedings of ICSE
2002, May 2002.
P. Oreizy, N. Medvidovic, R. N. Taylor. Architecture-Based Runtime Software Evolution. In Proceedings of the 20th International Conference on
Software Engineering, pp. 177-186, Kyoto, Japan, April 1998.

Tendencias Tecnologicas en Desarrollo de Aplicaciones

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tendencias Tecnologicas en Desarrollo de Aplicaciones

Cargado por

Copyright:

Formatos disponibles

Tendencias Tecnolgicas en Arquitecturas y Desarrollo de Aplicaciones

También podría gustarte