Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Ttada 2004
Ttada 2004
Tendencias Tecnolgicas en
Arquitecturas y Desarrollo de
Aplicaciones
Departamento de Computacin
Facultad de Ciencias Exactas
Universidad de Buenos Aires
Pgina 1 de 1
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
Qu es XP?................................................................................................................................................. 12
Prcticas de XP ............................................................................................................................................ 12
XP vs. CMM ................................................................................................................................................ 13
Casos de estudio........................................................................................................................................... 14
Bibliografa .................................................................................................................................................. 15
Introduccin ................................................................................................................................................. 16
Porque ? ....................................................................................................................................................... 16
Que Son ?..................................................................................................................................................... 16
Sobre que ?................................................................................................................................................... 17
Desarrollo de Aplicaciones .......................................................................................................................... 17
Conclusiones................................................................................................................................................ 22
Referencias................................................................................................................................................... 22
Resumen ...................................................................................................................................................... 25
Qu es EAI? ................................................................................................................................................. 25
Muchos nombres, la misma intencin.......................................................................................................... 25
Actualidad.................................................................................................................................................... 26
Futuro........................................................................................................................................................... 28
Conclusin ................................................................................................................................................... 28
Referencias................................................................................................................................................... 29
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
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
Pgina 2 de 2
TTADA
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
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
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
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 3 de 3
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 4 de 4
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.
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 5 de 5
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.
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.
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 6 de 6
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 7 de 7
TTADA
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.
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.
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 8 de 8
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 9 de 9
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.
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.
Pgina 10 de 10
TTADA
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
Pgina 11 de 11
TTADA
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 Practices1).
Las siguientes son algunas de ellas.
Whole Team
En cada proyecto XP existe un nico equipo del que todos los participantes del proyecto son miembros. Este
equipo incluye representantes del cliente, que proveen los requerimientos, fijan sus prioridades y le dan 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).
Pgina 12 de 12
TTADA
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 XP2
! "
! "
Pgina 13 de 13
TTADA
4
5
++
++
++
-+
+
+
+
--++
++
++
--+
---
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
##
Pgina 14 de 14
" $
TTADA
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.
& '
"*
"*
Pgina 15 de 15
"*
TTADA
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.
Pgina 16 de 16
TTADA
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
Pgina 17 de 17
TTADA
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
Pgina 18 de 18
TTADA
TTADA
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.
Pgina 20 de 20
TTADA
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.
TTADA
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
Pgina 22 de 22
TTADA
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
Pgina 23 de 23
TTADA
Pgina 24 de 24
TTADA
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.
TTADA
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
Permitir a las empresas manejar sus negocios por
Internet mediante la interconexin de sus sistemas y
aplicaciones.
Manejar de manera conveniente sus aplicaciones y
sistemas ante cambios como adquisiciones, fusiones,
desregulaciones de mercados, etc.
Automatizar la ejecucin de aplicaciones en un
complejo proceso de negocios
Mejorar los niveles de produccin
Pgina 26 de 26
TTADA
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.
TTADA
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.
Pgina 28 de 28
TTADA
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
Pgina 29 de 29
TTADA
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
Pgina 30 de 30
TTADA
unCliente
accion
respuesta
transportar: unaAccin
accion
recibir: unaRespuesta
unAdaptadorDeCanal
unaAccin
respuesta
unObjetoDeNegocio
unObjetoDeNegocio
unObjetoDeNegocio
unDispatcher
persistencia
existe: unaAccin
elCatalogoDeAcciones
puedeEjecutar: unaAccin
unObjetoDeNegocio
unObjetoDeNegocio
unObjetoDeNegocio
elAgenteDeSeguridad
!
.
"
0
12
3
4
(
-
5
6
,
/
"
" $
"
!
Pgina 31 de 31
)
TTADA
. 8
77- 8&9
1
* '
;
,
<
.:=
(
!$ *"/
.: /
(
$
+
-
* '4
1
>,
Pgina 32 de 32
&
8
"&
9
TTADA
TTADA
Pgina 34 de 34
TTADA
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
8! ? !@4!
777
DataObjects.NET Client
MS Framework.NET 1.1
Pgina 35 de 35
MS Message Queueing
MBI Dispatcher
MS IIS.NET
MBI Administrative Tools
MS Iexplorer 5.0
SAV Resources
MS OS
MS Desktop OS
MS Server OS
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
Servidor de Aplicaciones
Servidor de Distribucin
Pgina 36 de 36
Servidor Web
Cliente WinForm
Cliente Web
Protocolos y Componentes
.NET Remoting Servicio de Dispatcher
SAV Resources
MS Server OS
MS Framework.NET 1.1
MS IIS.NET
MBI Administrative Tools
SAV MBI Common Assemblies
SAV Resources
MBI Channel Adapter
MS Server OS
MS Framework.NET 1.1
SAV MBI Common Assemblies
SAV Resources
MBI Channel Adapter
MS Desktop OS
MS Iexplorer 5.0
MS OS
SQL Connection
MS - ADO.NET Connection
http
Pgina 37 de 37
TTADA
A
!
<
A
D
C(
C(
D
/
C(
B
!
&
D "
Servidor de Web
Cliente WebForm
MS - IExplorer
MS - IIS .Net
MS - OS
http
<.NET Remoting>
Servidor de Distribucin
MS - Framework .Net 1.1
MS - Message Queueing
<SQL Connection>
Cliente WinForm
MS - Framework .Net 1.1
<.NET Remoting>
Servidor de datos
<.NET Remoting>
MS - Server OS
Servidor de Aplicaciones
MS - Framework .Net 1.1
MS - Message Queueing
Data Object .Net (Client)
SAV - Business Objects
MS - Server OS
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.xtensive.com/Data/Downloads/DataObjects.NET/DataObjects.NET%20Manual.pdf)
Pgina 38 de 38
TTADA
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:
Pgina 39 de 39
TTADA
Cdigo Assembler
Modelos Ejecutbles
Assembler
Compiladores Cdigo
Fuente
Compiladores de
Modelos
Cdigo Mquina
1960s
Nada
Cdigo Assembler
1980s
Plataforma de Hardware
Cdigo Fuente
2000s
Plataforma de Software
El OMG se embarc en el desarrollo de MDA porque creen que un modelo UML independiente de la plataforma
es el secreto de la estabilidad del software y el ROI. Debido a la 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)
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)
Pgina 40 de 40
TTADA
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
Pgina 41 de 41
TTADA
PIM
Modelo
Independiente
de la
Plataforma
Aplicaciones
Legadas
Otros Modelos
CTOS
Otros
Modelo
.NET
Modelo
CORBA
CORBA
System
.NET
Bridge de
Interoperacin
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
Pgina 42 de 42
TTADA
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.
TTADA
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.
Pgina 44 de 44
TTADA
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
FORMALISE ABSTRACT
DESIGN MODEL
VALIDATE ANALYSIS
Integrate multiple domain
models using bridges
TTADA
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.
Pgina 46 de 46
TTADA
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
Pgina 47 de 47
TTADA
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.
Pgina 48 de 48
TTADA
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.
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.
Pgina 49 de 49
TTADA
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 autocontenidas, 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:
Pgina 50 de 50
TTADA
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:
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
Pgina 51 de 51
TTADA
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.
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:
Pgina 52 de 52
TTADA
Pgina 53 de 53
TTADA
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.
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).
Pgina 54 de 54
TTADA
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:
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.
Pgina 55 de 55
TTADA
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
Pgina 56 de 56
TTADA
Pgina 57 de 57
TTADA
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.
EFA C $
Pgina 58 de 58
& 8 ! "*
&
77%
TTADA
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.
!89
:F F *
"
Pgina 59 de 59
19 BAC
&
"
8
$
/ ""
>$ $
:$
'$
$$
77%
TTADA
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
o
o
o
o
Pgina 60 de 60
TTADA
TTADA
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.
Pgina 62 de 62
TTADA
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:
-
Pgina 63 de 63
TTADA
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.).
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.
Pgina 64 de 64
TTADA
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.
Pgina 65 de 65
TTADA
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.
Pgina 66 de 66
TTADA
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
Pgina 67 de 67
TTADA
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
Pgina 68 de 68
TTADA
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.
Granularidad
los Eventos
Componentes
de
Fuentes de Datos
Transacciones
Cmputo
Comunicaciones
-Tpicamente asincrnico
Eventos tales como triggers de protocolos
Los eventos se mapean con invocaciones a
mtodos
Eventos de granularidad fina y alta
frecuencia
Objetos livianos conteniendo poca lgica
de negocios, ciclos de vida cortos y
transitorios: rpida creacin y eliminacin.
Mltiples fuentes de datos (ej, eventos
disparados por protocolos)
-Transacciones livianas
Se completan ms rpido y son ms
frecuentes
- Cmputo-intensivo
Las principales entradas y salidas son
invocaciones a recursos, mensajes y
eventos
Enterprise
- Tpicamente sincrnico
Bases de Datos, Sistemas EAI, Llamadas
RPC
Eventos de granularidad gruesa y baja
frecuencia
Objetos pesados de acceso a datos, que
pueden tener ciclos de vida largos y
persistentes.
Sistemas Back-end y servidores de Base
de Datos
-Transacciones de Base de Datos
Tardan ms en completarse y son menos
frecuentes
- 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:
Pgina 69 de 69
TTADA
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.
TTADA
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.
Pgina 71 de 71
TTADA
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.
Pgina 72 de 72
TTADA
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
Pgina 73 de 73
TTADA
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.
TTADA
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.
logger.exit("doGet");
}
TTADA
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.");
}
}
TTADA
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
Pgina 77 de 77
TTADA
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.
2.
3.
4.
5.
6.
7.
Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Marc
Pgina 78 de 78
TTADA
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.
RECOLECCIN
ADMINISTRACIN
PUBLICACIN
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).
Pgina 79 de 79
TTADA
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 ecommerce 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).
Cuando hay mucha informacin para procesar manualmente (muchos items de contenidos o
muchos tipos de contenido).
Pgina 80 de 80
TTADA
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.
Demasiado contenido
Muchos colaboradores
"
#$
Demasiado cambio
Muchas publicaciones
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
Pgina 81 de 81
TTADA
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.
Pgina 82 de 82
TTADA
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.
Pgina 83 de 83
TTADA
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.
TTADA
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.
Referencias
!
$ %
)&
. /
6 7
Pgina 85 de 85
&
'
!+
' /
&&& &
1
&&&
,%
&&&
!
"
(& (
&
0
! 1 &2
5#.6
44#
!
&%
- (*
3
% #44#
TTADA
$%
- &
<
!9 %
&%
- ::
!+
!
% #44#$
#4=# <6:=# .<<6<4=# 44
&&&
?
!+
#4A<6:A
:.<: 8A
44
: B C$
&&&
D$
'
!0
$%
&&&
'
&&&
'
&&&
G
'
&
&&&
&
"
! C&
'
%(
'
F
! +'
'
!
#44 4: ' 4 4:'
#(
,
%(
! 2% #44
#44 4. ' 4 4. (
'
!+
,%
%('
!9
Pgina 86 de 86
'
! / +,
% #44#$
! 2 , - ! 1 * % #44.
&2
E ;
D
/564:44#46
'
2
&&&
#44
#44 4 ' 4 4 '(
%(
4,
:::
;&5 !%
".
&&&
>
C -
!2
% #44
;
#44
!C
%
'
'
TTADA
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 (SelfRepair). 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.
TTADA
Era Desktops
Era Redes
la computadora como un nodo de una grilla informacin / servicio mundial
Era Informtica Omnipresente (Ubiquitous Comupting)
la computadora como un asistente personal
Pgina 88 de 88
TTADA
Tema
Tradicionalmente SHS
Mostrar propiedades o funciones (ms sutil) mostrar funciones deseadas, tolerar desviaciones
ocultando detalles
razonables, mostrar requerimientos de recursos que necesariamente
encajen con las expectativas del usuario
Escribir software correcto
Incluir mecanismos de monitoreo y reparacin para detectar errores
y arreglarlos cuando es posible
Usar administracin de la
Soportar configuracin dinmica y sintonizacin automtica para
configuracin para construir
tantos entornos diferentes como encuentre
sistemas para entornos
reconocibles
Pgina 89 de 89
TTADA
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.
General
Dominio
Aplicacin
Herramientas,
Mecanismos
Tcnicas
Objetivos
Control Theory
Mobile Systems
Ubiquitous Computing
Biology Simulation
Collaborative Computing
Architectural models
Formal models
Agents
Improve dependability
Classical techniques
Adaptive middleware
Adaptive network protocols
Chroma and other CMU OS work
Multi-fidelity systems
Autonomic Computing
de
Immunology
User Interfaces
Task-oriented computing
Context-aware computing
Resource-aware computing (including energy-aware,
adaptive resource assignment, etc.)
Agent-based systems
Biological Models: Santa Fe Institute
User Modeling
Learning by watching
Intelligent tutoring systems
Intelligent user interfaces; Attentive User Interfaces
Games
Algorithms/code-based
Architecture-based Adaptation
Self-stabilizing algorithms
Hot swapping
Safe mobile code
Coordination Languages
Formal reasoning about mobile systems
AI approaches, including Neural Nets
Amorphous Computing
Multicellular Automata
Economic theory
En esta rea es conveniente distinguir espacio de problemas de espacio de soluciones. Una 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)):
TTADA
Modelo de Falla
Duracin de la falla
Manifestacin de la falla
Fuente de la falla
Granularidad
Expectativa del perfil / tipo de falla
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
91
2004
Pgina 92 de 92
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.
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.
2004
Pgina 93 de 93
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.
2004
Pgina 94 de 94
TTADA
2004
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.
2004
Pgina 96 de 96
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:
General
Dominio de Aplicacin
Herramientas,
Tcnicas
Objetivos
TTADA
Mecanismos
Control Theory
Mobile Systems
Ubiquitous Computing
Biology Simulation
User Interfaces
Collaborative Computing
Games
Architectural models
Algorithms/code-based
Formal models
Genetic algorithms/alternative models
Agents
Economic theory
Improve system performance/Resource usage
Improve user experience; reduce user distractions
Improve dependability
2004
Pgina 97 de 97
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 selfmanagement 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
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.
"
#
&
(
!
TTADA
'
)
2004
Pgina 98 de 98
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 selfmanagement 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.
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.
A
& 8
"! 8
HI
D
*
$ " H
J
:
* H
$ $
"
*$
"$
#
#
"
(
$ *
"*
!
"
$
K
Today, IT departments must take a pragmatic approach to increasing productivity and managing costs - the mandate is to
optimize processes and gain the benefits originally promised from technology investments. To achieve these goals, many
IT departments are looking at automation solutions that do not require rip and replace strategies or intensive change in
corporate procedures.
TTADA
2004
Pgina 99 de 99
"
$
$
9
:
$
"
"
"
* $
*
$
<
:$
$
# $
C
$
"
"
"
9
:
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.
Related Pages
OpalisRobot Connector Access Packs (CAPs) extend OpalisRobot with application specific objects and workflows.
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.
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 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.
The current version of Self-Healing services (version 1.30) supports HP OpenView Network Node Manager, OpenView
Operations-Unix, OpenView Operations-Windows, Service Desk/Windows, and OVPA. Supported platforms are HP-UX
11.x, Solaris 2.6 - 2.9, and Windows XP, NT, and 2000.
TTADA
2004
VERITAS i for Web-J2EE provides a complete application performance management solution for web-based
applications anchored by J2EE application servers. The integrated solution allows IT managers to quickly isolate poor
performing web pages and transactions then correlate them with the appropriate J2EE methods. This ensures that IT
managers focus on the definitive root cause of the problem - not the symptoms.
Web-based applications continue to play a key role for all businesses. When performance problems begin to impact endusers, IT managers need detailed information. It'
s not enough to know there is a problem - IT managers need to know
where the problem is and how to fix it. The performance data collected from the web client, web server, and J2EE tier is
comprehensive but does not introduce overhead. The VERITAS i3 for Web-J2EE solution is designed to be run in a
production environment.
Benefits
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
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.
Collaborating with customers and industry partners, SQL Server pioneered the first self-configuring, self-managing, selfhealing database. Consistent customer feedback was that databases, overall, were hard to manage, maintain and required
extensive IT investment for both people and processes. To help alleviate the burden on IT and to help lower the overall
management costs of data management products, Microsoft innovated a new way to have the database perform self-
TTADA
2004
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 highervalue services rather than low-level tweaking of the data management platform. Click to view some of the innovations in
self-management that SQL Server provides such as the Index Tuning Wizard, auto-management interfaces, and query
optimization.
Read how Pennzoil leveraged the self-tuning and management innovations of SQL Server to lower their costs and boost
their productivity at http://www.microsoft.com/resources/casestudies/CaseStudy.asp?CaseStudyID=11220.
Airespace 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.
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 finegrained, method-level control over what applications can and can'
t do based on who wrote the code, the purpose of the
code, where it was installed from, and who is trying to run it.
TTADA
2004
Casos IBM
Autonomic Computing Toolkit
IBM issues toolbox for autonomy
Nicholas Chase, President, Chase & Chase, Inc.17 Feb 2004, Updated 21 Oct 2004
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
TTADA
2004
Autonomic management
For an autonomic computing system to discover and control events and situations, it uses a control loop that constantly
monitors the system looking for events to handle. This control loop is defined by the autonomic computing reference
architecture, as shown in Figure 2:
:$ D
$
* $ :$
*$ $
"
>
Monitor: First, the system looks for the events, detected by the sensor from
whatever source -- be it a log file or an in-memory process. The system uses
the knowledge base to understand what it'
s looking at.
2. Analyze: When an event occurs, the knowledge base contains information that
helps to determine what to do about it.
Plan: After the event is detected and analyzed, the system needs to determine what to do about it using the
knowledge base. The symptom database might have information, or a central policy server might determine the
action to take.
Execute: When the plan has been formulated, it'
s the effector that actually carries out the action, as specified in
the existing knowledge base.
1.
3.
4.
As you might have surmised by now, some of this processing can involve some fairly complex logic. In the case of a Java
technology implementation (such as that provided by the Autonomic Computing Toolkit), you might opt to use JavaBeans
components that provide artificial intelligence-like capabilities.
!
$ A
:
$
$
9
&8
*
&
$
TTADA
$M
D
$ A
'
"
&
2004
:
"$ * $
&
C
' *
$
4
A&4.
4
C
"*
$
* ' L$ "
'
.
A&4.
7
A &
$
,
&
$
&
$
" *
$
/
"
A&4.
A
* $
&
1
"
"
init process
A
* $
'
'
"
timer
Next steps
The tools and technologies that enable systems to become self-configuring, self-healing, self-optimizing, and selfprotecting are ready for you to use. Download the IBM Autonomic Computing Toolkit and start creating applications that
will use the autonomic computing core capabilities. Some capabilities, such as solution installation, integrated solutions
console, problem determination and autonomic management are part of the Autonomic Computing Toolkit itself. Others,
such as complex analysis, policy-based management, and heterogeneous workload management require additional
software.
But, however you look at it, and however you build it, it'
s not hype anymore.
1
M
, *
$ :
$ A
'
"
"
$ A
O L
$
*
TTADA
9
&8 *
D
$ '
:
$
:
$ $
"
'
'
/ A9
N
$
, *
/
"
$
$ *
>
DB2 UDB Stinger and autonomic computing make a good pair. Read this article to learn why.
For a glimpse of orchestration and provisioning in action, take a peek at how IBM Tivoli Identity Manager with
IBM Tivoli Directory Integrator provision identities to a third-party application.
Take a look at the many intersections between autonomic computing technology and WebSphere products in
this set of articles on WebSphere and autonomic computing.
In this article about the integration of IBM Tivoli Access Manager 3.9 with WebSphere Application Server
you'
ll see autonomic features working to enable self-healing systems.
For more information on autonomic computing function being woven into IBM products, check these Web
sites:
o developerWorks Grid computing
o developerWorks DB2
o developerWorks Tivoli
o developerWorks WebSphere
2004
"
*
*
1
$*
/
"
"
,& P
$
DB2 -- The relational database management system (RDBMS) uses autonomic computing for a number of
features. The first is a health monitor to maintain optimum performance of the database system. If any
performance issues are found, DB2 will report the findings and offer expert advice on how to correct the
situation. A configuration adviser helps the novice user in configuring an expert system -- something that would
have
normally
taken
a
long
time
to
set
up.
Future releases will concentrate on the self-healing and self-protecting segments of the autonomic computing
system.
Tivoli -- The Intelligent Management Software solution contains all four areas of the autonomic computing
environment. Elements of the toolset can self-configure (Configuration Manager), self-optimize (Workload
Scheduler), self-heal (Enterprise Console) and self-protect (Risk Manager).
eServer -- The Enterprise Workload Manager (EWLM) component of the IBM Virtualization Engine provides
hetergeneous workload management capabilities. EWLM enables you to automatically monitor and manage
multi-tiered, distributed, heterogeneous or homogeneous workloads across an IT infrastructure to better achieve
defined business goals for end-user services. These capabilities allow you to identify work requests based on
service class definitions, track performance of those requests across server and subsystem boundaries, and
manage the underlying physical and network resources to set specified performance goals for each service class.
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)
David Garlan Curso Self-Healing Systems, Carnegie Mellon University, Spring Semestre 2003.
IBM An architectural blueprint for autonomic computing IBM and autonomic comuting,
ibm.com/autonomic, April 2003.
Koopman, P. Elements of the self-healing system problem space. Workshop on Architecting Dependable
Systems (WADS03), May 2003.
M. Shaw. '
Self-Healing'
: Softening Precision to Avoid Brittleness. Proceedings of the First ACM
SIGSOFT Workshop on Self-Healing Systems (WOSS '
02). Charleston, South Carolina, November 2002,
pp.111-113.
Mary Shaw. Beyond Objects: A Software Design Paradigm Based on Process Control. ACM Software
Engineering Notes, Vol 20, No 1, January 1995.
TTADA
2004
Pgina 106 de 106
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
Control Theory
Fault tolerance
Immunology
Autonomic Computing
Bibliografa
General
TTADA
2004
A. G. Ganek and T. A. Corbi. The dawning of the autonomic computing era. IBM Systems Journal, Special Issue on Autonomic Computing.Vol
42, No 1, 2003.
M. Shaw. '
Self-Healing'
: Softening Precision to Avoid Brittleness. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems
(WOSS '
02). Charleston, South Carolina, November 2002, pp.111-113.
Avizienis, J.-C. Laprie and B. Randell. Fundamental Concepts of Dependability, Research Report N01145, LAAS-CNRS, April 2001. (citeseer,
local)
Mary Shaw. Beyond Objects: A Software Design Paradigm Based on Process Control. ACM Software Engineering Notes, Vol 20, No 1, January
1995.
User Interfaces
Model-based
Approaches
User Modeling
Learning by watching
Intelligent tutoring systems
Intelligent user interfaces; Attentive User Interfaces
Architecture-based Adaptation
Rainbow-like approaches
Oriezy, P., Gorlick, M.M., Taylor, R.N., Johnson, G., Medvidovic, N., Quilici, A., Rosenblum, D., and Wolf, A. An Architecture-Based Approach
to Self-Adaptive Software. IEEE Intelligent Systems 14(3):54-62, May/Jun. 1999.
D. Garlan, S. Cheng, and B. Schmerl. Increasing System Dependability through Architecture-based Self-repair. In Architecting Dependable
Systems, R. de Lemos, C. Gacek, A. Romanovsky (Eds), Springer-Verlag, 2003.
Ioannis Georgiadis, Jeff Magee and Jeff Kramer. Self-Organising Software Architectures for Distributed Systems. Proceedings of the First ACM
SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
Gross, P.N., Gupta, S., Kaiser, G.E., Kc, G.S., Parekh, J.J. An Active Events Model for Systems Monitoring. Proceedings of the Working
Conference on Complex and Dynamic System Architecture, Brisbane, Australia, Dec 2001.
Combs, N., Vagel, J. Adaptive Mirroring of System of Systems Architectures. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing
Systems (WOSS '
02).
Bond, A., Sud, J. Service Composition for Enterprise Programming. Proceedings of the Working Conference on Complex and Dynamic System
Architecture, Brisbane, Australia, Dec 2001.
Eric M. Dashofy, Andr van der Hoek, Richard N. Taylor. Towards architecture-based self-healing systems. Proceedings of the First ACM
SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
David Garlan, Bradley Schmerl. Model-based adaptation for self-healing systems. Proceedings of the First ACM SIGSOFT Workshop on SelfHealing Systems (WOSS '
02).
Rogrio de Lemos, Jos Luiz Fiadeiro. An architectural support for self-adaptive software for treating faults. Proceedings of the First ACM
SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
Sam Michiels, Lieven Desmet, Nico Janssens, Tom Mahieu, Pierre Verbaeten DistriNet. Self-adapting concurrency: the DMonA architecture.
Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
Marija Mikic-Rakic, Nikunj Mehta, Nenad Medvidovic. Architectural style requirements for self-healing systems. Proceedings of the First ACM
SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
David S. Wile. Towards a synthesis of dynamic architecture event languages. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing
Systems (WOSS '
02).
Jonathan Aldrich, Vibha Sazawal, Craig Chambers, David Notkin. Architecture-centric programming for adaptive systems. Proceedings of the
First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
Nathan Combs, Jeff Vagle. Adaptive mirroring of system of systems architectures. Proceedings of the First ACM SIGSOFT Workshop on SelfHealing Systems (WOSS '
02).
Mobility, Ubiquitous
Computing,
OS
Support
TTADA
Task-oriented computing
Context-aware computing
Resource-aware computing (including energy-aware, adaptive
resource assignment, etc.)
Agent-based systems
2004
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 SelfHealing Systems (WOSS '
02).
Alternative Models of
Computation
Radhika Nagpal, Attila Kondacs, and Catherine Chang. Programming Methodology for Biologically-Inspired Self-Assembling Systems. AAAI
Symposium '
03.
Stephanie Forrest, Steven A. Hofmeyr, and Anil Somayaji. Computer immunology. Communications of the ACM, v.40 n.10, p.88-96, Oct. 1997.
Stephen F. Bush and Amit B. Kulkarni. Genetically Induced Communication Network Fault Tolerance. SFI Workshop: Resilient and Adaptive
Defence of Computing Networks 2002.
S. George, D. Evans, and L. Davidson. A biologically inspired programming model for self-healing systems. Proceedings of the First ACM
SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
Orna Raz, Philip Koopman, Mary Shaw. Enabling automatic adaptation in systems with under-specified elements. Proceedings of the First ACM
SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
Johann Schumann, Stacy Nelson. Toward V&V of neural network based controllers. Proceedings of the First ACM SIGSOFT Workshop on SelfHealing Systems (WOSS '
02).
Self-stabilizing algorithms
Hot swapping
Safe mobile code
Sanny Gustavsson, Sten F. Andler. Self-stabilization and eventual consistency in replicated real-time databases. Proceedings of the First ACM
SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
Networks, Distributed
Systems,
and
Middleware
TTADA
Adaptive middleware
Adaptive network protocols
Chroma and other CMU OS work
Multi-fidelity systems
2004
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).
Classical techniques
Koopman, P. Elements of the self-healing system problem space. Workshop on Architecting Dependable Systems (WADS03), May 2003.
Shelton, C., Koopman, P. & Nace, W. A framework for scalable analysis and design of system-wide graceful degradation in distributed embedded
systems. WORDS03, January 2003.
Formal Models
Coordination Languages
Formal reasoning about mobile systems
Jeff Magee, Naranker Dulay, Susan Eisenbach, and Jeff Kramer. Specifying Distributed Software Architectures. Fifth European Software
Engineering Conference, Barcelona 1995.
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.
Jonathan Appavoo, Kevin Hui, Michael Stumm, Robert W. Wisniewski, Dilma Da Silva, Orran Krieger, Craig A. N. Soules. An infrastructure for
multiprocessor run-time adaptation Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
Gordon S. Blair, Geoff Coulson, Lynne Blair, Hector Duran-Limon, Paul Grace, Rui Moreira, Nikos Parlavantzas. Reflection, self-awareness and
self-healing in OpenORB . Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
Giuseppe Valetto, Gail Kaiser. A case study in software adaptation. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems
(WOSS '
02).
Z. Yang, B. H. C. Cheng, R. E. K. Stirewalt, J. Sowell, S. M. Sadjadi, P. K. McKinley. An aspect-oriented approach to dynamic adaptation.
Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
Stephen Fickas, Robert J. Hall. Self-healing open systems. Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS
'
02).
P. Inverardi, F. Mancinelli, G. Marinelli. Correct deployment and adaptation of software applications on heterogenous (mobile) devices.
Proceedings of the First ACM SIGSOFT Workshop on Self-Healing Systems (WOSS '
02).
Walker, Murphy, Steinbok and Robillard. Efficient Mapping of Software System Traces to Architectural Views. Proc. of CASCON, November
2000.
Jonathan Aldrich, Craig Chambers, and David Notkin. ArchJava: Connecting Software Architecture to Implementation. In proceedings of ICSE
2002, May 2002.
P. Oreizy, N. Medvidovic, R. N. Taylor. Architecture-Based Runtime Software Evolution. In Proceedings of the 20th International Conference on
Software Engineering, pp. 177-186, Kyoto, Japan, April 1998.
TTADA
2004