Una herramienta basada en cumbia para análisis dinámico de modelos SCA John Marlon Espitia Malagón Universidad de los Andes Facultad de Ingeniería Departamento de Ingeniería de Sistemas y Computación Maestría en Ingeniería de Sistemas y Computación BOGOTÁ DC, 2009
74
Embed
Una herramienta basada en cumbia para análisis dinámico ... Binding ... y COM como las herramientas para desarrollo de componentes más relevantes, estas herramientas a diferencia
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Una herramienta basada en cumbia para análisis dinámico de modelos SCA
John Marlon Espitia Malagón
Universidad de los Andes
Facultad de Ingeniería
Departamento de Ingeniería de Sistemas y Computación
Maestría en Ingeniería de Sistemas y Computación
BOGOTÁ DC, 2009
2
Una herramienta basada en cumbia para análisis dinámico de modelos SCA
John Marlon Espitia Malagón
Tesis de grado.
Director
Jorge Alberto Villalobos Salcedo, PhD.
Profesor Asociado.
Universidad de los andes
Facultad de ingeniería
Departamento de Ingeniería de Sistemas y Computación
Maestría en Ingeniería de Sistemas y Computación
BOGOTÁ DC, 2009
3
Tabla de Contenidos Tabla de Contenidos ........................................................................................................................ 3
Tabla de Figuras............................................................................................................................... 6
Tabla de Figuras Figure 1. Key Elements in the CORBA Component Model [8] ..................................................................... 12 Figure 2. Vista interna de un componente fractal. [10] .............................................................................. 14 Figure 3. Composición y componente compartido en fractal. [4] ............................................................... 15 Figure 4. Servicios para EJB en el Contenedor [12]..................................................................................... 16 Figure 5. Componentes EJB [12]................................................................................................................. 17 Figure 6. Componente Compuesto en Gaita-C [10] ................................................................................... 18 Figure 7. Arquitectura JMX [19]............................................................................................................... 23 Figure 8. Especificaciones de SCA............................................................................................................... 26 Figure 9. Representación gráfica de Service ............................................................................................... 27 Figure 10. Representación gráfica de Reference ........................................................................................ 28 Figure 11. Representación gráfica de Wire................................................................................................. 29 Figure 12. Representación gráfica de Property........................................................................................... 29 Figure 13. Representación gráfica de Component...................................................................................... 30 Figure 14. Representación gráfica de Composite ....................................................................................... 31 Figure 15. Frontend del Caso de Prueba..................................................................................................... 35 Figure 16. Backend del Caso de Prueba...................................................................................................... 36 Figure 17. Vista de elementos SCA............................................................................................................. 37 Figure 18. Vista de un objeto abierto ......................................................................................................... 40 Figure 19. Metamodelo de SCA.................................................................................................................. 49 Figure 20. Máquina de estado de Componente.......................................................................................... 50 Figure 21. Máquina de estado de Wire ...................................................................................................... 51 Figure 22. Máquina de estado de Composite ............................................................................................. 52 Figure 23. Máquina de estado de Domain.................................................................................................. 53 Figure 24. Modelo ejecutable para un dominio.......................................................................................... 54 Figure 25. Modelo ejecutable para SCA...................................................................................................... 54 Figure 26. Service Proxy ............................................................................................................................. 57 Figure 27. Reference Proxy ........................................................................................................................ 57 Figure 28. Construcción de elementos ejecutables .................................................................................... 58 Figure 29. Diagrama detallado service proxy ............................................................................................. 59 Figure 30. Diagrama detallado reference proxy ......................................................................................... 60 Figure 31. Arquitectura General................................................................................................................. 61 Figure 32. Detalle de los componentes generales del diseño ..................................................................... 62 Figure 33. Máquina de estado de Wire ...................................................................................................... 63 Figure 34. Transición Call en el Wire .......................................................................................................... 64 Figure 35. Transición PassCallResult en el Wire.......................................................................................... 65 Figure 36. Diseño solución BAM................................................................................................................. 66 Figure 37. Esquema del framework de pruebas ......................................................................................... 67
7
1. Introducción
Service Component Architecture (SCA) [1] ofrece un modelo de programación para construir
aplicaciones. Cuando se construyen aplicaciones es deseable contar con herramientas que
permitan analizar características de diferentes tipos que sean relevantes para los diferentes
interesados. Service Component Architecture es una tecnología relativamente nueva y se ha
especificado con el fin proporcionar un estándar para construir aplicaciones, el avance en el
desarrollo de diferentes herramientas para SCA no muestra un avance específico en el tema
de herramientas para hacer análisis sobre las aplicaciones construidas bajo este modelo.
Las herramientas que permiten hacer análisis deben tener en cuenta que los análisis que
pueden hacer depende de las características de los elementos a observar, analizar un
elemento o un grupo de elementos consiste en observar las diferentes características de ellos
e interpretarlas, cuantos más puntos de análisis o posibilidades de análisis pueda haber mayor
cantidad de posibilidades de análisis resultan. La capacidad de observación de un elemento
está asociada directamente al tipo de análisis que se puede hacer sobre él, teniendo un mayor
nivel de distinciones de las características del elemento se puede recopilar una mayor
cantidad de información. Si a la capacidad de distinguir se le suma la posibilidad de saber en el
tiempo cuando se puede observar el elemento, el análisis puede ser mucho más poderoso, el
análisis estático describe las características del elemento puntual y el análisis dinámico nos
permite conocer las características cuando por su comportamiento el elemento hace algo
especifico.
SCA por sus características se enmarca como un modelo para construir aplicaciones CBSE
(Component based software engineering), en la actualidad se destaca CCM [2], EJB [3], Fractal
[4] y COM como las herramientas para desarrollo de componentes más relevantes, estas
herramientas a diferencia de SCA proporcionan un conjunto más amplio de detalle en las
facilidades que proveen, no se limitan solo al modelo de componentes sino que también
proporcionan características asociadas a sus requerimientos no funcionales lo que desde su
definición ya determina como debe ser la implementación de las herramientas que soportan
su ejecución. Las características de los modelos de componentes en ejecución se dan como
una suma de la especificación del modelo y la herramienta que facilita su ejecución, la
herramienta puede implementar lo definido para el modelo y con sus características
adicionales proporcionar facilidades al ejecutar el modelo.
En este caso la herramienta para realizar análisis sobre SCA debe proporcionar la capacidad de
observación e intervención en sus elementos, en la actualidad se pueden usar diferentes
tecnologías para dar las capacidades de observación e intervención sobre los elementos se
tiene por ejemplo el uso de programación orientada a aspectos (AOP) y también la
8
intervención manipulando las representaciones de bajo nivel las aplicaciones por ejemplo
bytecode, en este caso se van a usar Objetos Abiertos (Open Objects) [5], los objetos abiertos
se incorporan a las aplicaciones desde su diseño y proporcionan una opción útil cuando se
requiere que las aplicaciones construidas sean altamente observables sin la necesidad de
realizar cambios posteriores o de conocer detalles internos en términos de código fuente. Un
objeto abierto está diseñado para modelar y externalizar el comportamiento relevante de un
elemento. Cuando se trabaja con un objeto abierto se tiene la posibilidad de observar su
comportamiento, su estado, recibir notificaciones de cambios de estado específicos y acceder
a sus propiedades cuando sus estados cambian entre otras.
En este caso SCA ha sido modelado como un modelo ejecutable constituido por los elementos
de SCA donde algunos de sus elementos han sido modelados como objetos abiertos es decir
pueden ser observados y pueden notificar a quien le interese cambios en su estado que
permiten la recopilación de información de la ejecución en ese momento específico.
Como se había mencionado cuando se quiere hacer análisis de algún tipo de modelo, lo
primero que se debe definir es cuál es el modelo y las características a observar. La
herramienta de análisis que se desarrolló tiene como base los elementos definidos para SCA y
la capacidad de observación que brindan los objetos abiertos. En la construcción de la
herramienta que permite el análisis de aplicaciones no hay incorporado elementos que
realicen análisis de las aplicaciones pero si los puntos de intervención y la dinámica que
permite generar los objetos abiertos para conectar aplicaciones que hagan el análisis. En este
trabajo se muestra un caso donde se muestra la ejecución de la aplicación y algunos análisis
hechos sobre su ejecución.
El documento se divide en una parte teórica y otra relacionada directamente con SCA y su
implementación, en la parte teórica se busca dar un contexto global basado en los modelos de
componentes y los lenguajes de descripción de arquitecturas para mostrar las características
de los diferentes modelos y los conceptos que se usan para llegar a la herramienta que
permite el análisis, en la relacionada con SCA se muestra detalle respecto a sus orígenes
históricos, sus elementos, sus características principales, sus ventajas identificadas, luego se
muestra detalle de cómo se logra la formulación del metamodelo y la implementación
definiendo los elementos del modelo ejecutable, la arquitectura de la solución, las
características relevantes de la implementación, las pruebas y el escenario de análisis que sirve
como validación de las posibilidades de la herramienta.
9
2. Marco Teórico
2.1. Arquitectura de Software “La arquitectura de software de un programa o un sistema de computación es la estructura de
estructuras del sistema que incluye componentes de software, sus propiedades relevantes y la
relación entre ellos.” [6].
La arquitectura de software es una disciplina que surge como una necesidad derivada de la
evolución de los sistemas computacionales. Estos inicialmente resuelven problemas
específicos, pero con la evolución del hardware y el crecimiento de las organizaciones se
convierten en soluciones a grandes problemas que involucran diferentes participantes. Las
soluciones informáticas a este tipo problemáticas pueden variar de tamaño y en algunos casos
ser de un tamaño considerable. La arquitectura de software es una herramienta que permite
estructurar estas soluciones informáticas de manera tal que se pueda, resolver un gran
problema como la solución de varios problemas menos complejos trabajando juntos
incorporando el uso de diferentes tecnologías, la participación de diferentes personas
trabajando cooperativamente y finalmente estructurando estas soluciones para que puedan
crecer si es necesario.
Estilos de arquitectura. Una arquitectura de software en general se describe como un
conjunto de elementos que trabajan juntos y pertenecen a la estructura de un sistema de
computación. Esta definición no da un mayor detalle respecto al tipo de elementos tampoco a
como se relacionan y no describe en que estructura están contenidos. Una forma de
estructurar estos elementos es por medio de los estilos de arquitectura. “Un estilo de
arquitectura es la especialización de elementos, tipos de relaciones, junto con una serie de
restricciones de cómo estos pueden ser usados” [7], un estilo de arquitectura da las pautas de
que tipo de elementos existen en un tipo de arquitectura de software, que relaciones existen
entre esos elementos, como ellos se relacionan y que restricciones puede haber sobre los
elementos y sus relaciones.
Estilo de arquitectura componentes y conectores. En el estilo de arquitectura de componentes y conectores C&C [7] esta compuesto por dos
tipos de elementos, su nombre lo indica fácilmente son componentes y conectores, los
componentes son el principal elemento computacional y los conectores definen los
mecanismos de interacción entre los componentes, de manera general este tipo de elementos
se encuentra en los modelos de componentes conocidos. Las formas de interacción y las
restricciones son algunas de las características que permiten realizar diferenciaciones entre
unos y otros, a continuación se muestra una breve descripción de modelos de componentes
conocidos.
10
2.2. Modelos de Componentes
2.2.1. Corba CCM Common Request Broker Architecture (CORBA) es la arquitectura ofrecida por la OMG que
tiene como principal objetivo permitir la comunicación e interoperabilidad de objetos entre
diferentes aplicaciones, ejecutadas en diferentes plataformas y escritas en diversos lenguajes,
esto último es lo que hace a CORBA una alternativa sobre otras tecnologías permite
flexibilidad y portabilidad de las aplicaciones, basado en un paradigma orientado a objetos.
Elementos
• Object Request Broker (ORB), que es el encargado de la localización e invocación de
los métodos sobre los objetos participantes en el sistema, está ubicado en cada
máquina y se encarga de realizar la comunicación de datos con los ORB de otras
máquinas.
• Internet Inter-ORB Protocol (IIOP), es el protocolo estándar de CORBA a través del cual
se efectúa la comunicación.
• Interface Definition Language (IDL), es un lenguaje con el que se especifican las
interfaces con los servicios que los objetos ofrecen, por lo tanto no incluye ninguna
implementación, sino que crea una interfaz en un lenguaje declarativo y neutral, de
manera que sea independiente de la plataforma, una implementación de un objeto
podrá entonces ser ejecutada a través del IDL de manera estática en tiempo de
compilación o de manera dinámica en tiempo de ejecución por el cliente que lo
requiera.
• Objects Adapters (OA), es encargado de recibir las peticiones a través de la red y
permitir que las implementaciones de los objetos accedan a servicios ofrecidos por el
ORB como la generación de referencias para los objetos.
• Corba Services, que son objetos que prestan servicios básicos para el uso e
implementación de componentes CORBA, aquí se resulten accesos a referencias de
objetos, notificación de eventos o cambios de estado, entre otros.
En el Corba Component Model (CCM), un componente se describe por medio del IDL, Existen
dos tipo de componentes básicos y extendido, los componentes básicos simplemente
encapsula un objeto para que tenga propiedades de componente y pueda ofrecer atributo en
cambio los componentes extendidos tienen mayores capacidades en función a los demás
elementos del modelo.
11
Existen otros elementos en el modelo que permiten relacionar el componente con los demás
componentes y con el contenedor, Los componentes cuentan con puertos que permiten
relacionarse con los demás componentes y con su contenedor, entre los tipos de puerto
existen facetas, receptáculos, atributos, orígenes y generadores de eventos (source y sink). Las
facetas son las interfaces que permiten el acceso a la funcionalidad del componente, cada
interface es como una vista del componente que le interesa a un cliente, un receptáculo
describe la necesidad de una funcionalidad que debe ser facilitada por un componente que
tenga una faceta compatible con ese receptáculo, los eventos permiten comunicación
simplemente suscribirse o generar eventos que son consumidos por los interesados que
previamente se han registrado para escuchar estos eventos. Un componente también tiene
propiedades que pueden ser administradas por un factory en el momento de construcción del
componente, las propiedades son un mecanismo de configuración del componente.
Un componente extendido tiene como propiedad poder heredar propiedades de otros
componentes, tener facetas, receptáculos y event source y sink.
La comunicación o trabajo conjunto de componente se da por medio de referencias de un
componente a otro, se reconoce el concepto de conexión en una referencia de un
componente a otro. En el caso de los eventos CCM usa un modelo de eventos publish/suscribe
que es usado por los componentes para comunicarse, los componentes acceden a este por
medio del contenedor quien administra el servicio.
(Figure 1)
12
Figure 1. Key Elements in the CORBA Component Model [8]
Comunicación entre componentes CORBA
CORBA esta fundamentado en dos modelos: uno basado en el modelo de orientado a objetos,
al cual agrega todas sus características como lo son los tipos de datos, abstracción, herencia y
polimorfismo, además se fundamenta en un modelo de referencia o arquitectura conocida
como Object Management Architecture (OMA). CORBA llega a presentar una infraestructura
de framework para construir aplicaciones orientadas a objetos, de esta manera las interfaces
definen los servicios que prestan los objetos, ocultando la programación a bajo nivel de
aplicaciones distribuidas, las funciones y los datos se agrupan en objetos, estos objetos
pueden estar en diferentes máquinas, pero se accederá a ellos a través de funciones normales
dentro un programa; CORBA envuelve el código escrito en otro lenguaje en un paquete que
contiene información adicional sobre las capacidades del código que contiene, y sobre cómo
llamar a sus métodos. Las invocaciones a métodos remotos son enviadas por los clientes
llamando objetos locales llamados “Stubs”, el cual intercepta dichas invocaciones y continúa el
proceso de llevar y retornar automáticamente dicha invocación. La implementación del
objeto, no tiene que conocer el mecanismo por el cual un cliente le ha invocado un servicio.
13
Un programa cliente que desee invocar un método remotamente debe utilizar un stub, el cual
es un objeto local que cumple con la interfaz IDL y que representa al objeto remoto en la
máquina local. Cada invocación a un método del stub es enviada a través del ORB al servidor
donde es recibido por el ORB remoto. Al recibir la invocación, el ORB remoto ejecuta el
skeleton del objeto, el cual es un objeto que también cumple con la interfaz IDL pero que
delega la invocación de un método sobre la implementación real del objeto, los stub y
skeleton utilizados en la comunicación son previamente generados a partir de la definición de
la interfaz IDL.
2.2.2. Fractal Fractal es un modelo de componentes que puede ser usado con diferentes lenguajes de
programación, es diseñado por el consorcio ObjectWeb [9]. El objetivo principal de Fractal es
permitir implementar, instalar y administrar sistemas de software complejos, teniendo como
ventaja sus principales características:
• Componentes compuestos.
• Componentes compartidos.
• Componentes con capacidad de introspección, configuración y reconfiguración.
Fractal tiene en cuenta los conceptos de componentes, interfaces y localización basada en
nombres, tiene un lenguaje IDL que le permite definir declaración genérica de interfaces que
luego es traducida a lenguajes específicos y genera stubs y skeletons para lograr la ejecución.
(Figure 2)
14
Figure 2. Vista interna de un componente fractal. [ 10]
Componentes
Un componente en fractal esta compuesto por un controlador o membrana y un contenido,
interactúa a través de operaciones en puntos de acceso llamadas interfaces similares a un
puerto en otros modelos, cuenta con capacidad introspección que puede ser configurada por
medio de niveles desde caja negra hasta total navegación, puede crear otros componentes,
pasivarse a si mismos, serializarse y pueden ser distribuidos.
Controlador
Se encarga de realizar la administración del componente tanto del mismo como de los
componentes que contiene, provee interfaces externas que permiten exportar interfaces de
negocio, navegar o reconfigurar externamente el componente y también internas que pueden
ser accedidas por los subcomponentes.
Un controlador a su vez esta compuesto de controladores que pueden ser de diferentes tipos
Attribute controller para acceso a atributos, Binding controller permite realizar primitive
bindings, Content controller permite modificar el contenido del componente, Life-cycle
controller permite administrar el ciclo de vida del componente e interceptores que que se
encargan de exportar las interfaces proveídas por los subcomponentes o de redirigir las
peticiones a estos y de realizar pre o post procesamiento si es requerido.
Contenido
Es un número finito de componentes (subcomponentes) que a su vez se encuentran bajo el
control del controlador del componente que los contiene. Estos componentes pueden ser
compartidos, es decir una instancia puede estar contenida en diferentes componentes y por
ende bajo el control de cada uno de ellos.
Interacciones
Las operaciones que definen la interacción en el modelo fractal son de dos tipos One-way
consiste en operación de invocación y two-way consiste en invocación y retorno de resultado,
las interfaces pueden ser de dos tipos Server que permite recibir y responder peticiones y
Cliente que permite emitir y esperar el resultado de peticiones. La interacción entre interfaces
llamada binding y puede ser primitiva entre una interface server y una client o compuesta que
en si es una combinación de primitivas y componentes que en si es un componente y resulta
ser un paralelo al concepto de conectores usado en ADLs.
Composición
15
En fractal es posible hacer composición de componentes un componente complejo puede ser
construido como una composición de componentes internos, en este caso la interface de
control del componente superior controla a los internos y por medio de ella se puede realizar
su configuración, también en una composición un componente puede ser compartido, en otra,
es decir la misma instancia de un componente puede encontrarse al tiempo de dos
componentes compuestos.
(Figure 3)
Figure 3. Composición y componente compartido en fr actal. [4]
Herramientas ofrecidas para Fractal
Cuenta con una implementación de referencia desarrollada en Java llamada Julia, un lenguaje
para diseño llamado FractalADL y una aplicación para diseño llamada FractalGUI.
2.2.3. EJB Los Enterprise Java Beans son los componentes usados en JEE [11] y se encuentran definidos
por la especificación EJB que en este momento se encuentra en la versión 3.0 [3], EJB ofrece
un api que permite el desarrollo de aplicaciones usando este tipo de componentes, uno de los
16
objetivos principales de la tecnología EJB es proporcionar un conjunto de servicios base de
sistema como transacciones y seguridad de tal forma que el desarrollador se enfoque en la
lógica de negocio del componente y no en como proveer requerimientos no funcionales.
Un componente EJB se ejecuta en un Contenedor el cual le proporciona un entorno de
ejecución donde le facilita los servicios mencionados anteriormente, también administra su
ciclo de vida y facilita su localización.
(Figure 4)
Figure 4. Servicios para EJB en el Contenedor [12]
Un EJB es un componente que encapsula una lógica de aplicación y la expone por medio de
métodos en interfaces, son portables, reutilizables y pueden ejecutarse en cualquier servidor
que use el API estándar de EJB, pueden ser locales o remotos según se requiera. En la
especificación 3.0, se definen como de dos tipos Session y Message Driven Bean, los Entitity
Bean pasan a ser definidos en el Java Persistence API [13].
Session Bean, se encargan de realizar una tarea para un cliente, pueden tener estado o no,
cuando tienen estado son llamados Stateful, en este caso el estado esta definido como la
representación de valores de las variables de instancia de la implementación del componente
y en este caso debe ser único para cada cliente lo que se traduce en un estado de
conversación con el cliente mientras se realice la ejecución sobre el mismo componente,
cuando no tiene estado son llamados Stateless lo que quiere decir que no se establece un
17
estado de conversación con el cliente, los de tipo Stateless pueden ser reutilizados y en ambos
casos su ciclo de vida es administrado por el contenedor.
Message Driven Bean, permiten procesar mensajes asincrónicamente actúan como un JMS
Listener [14], los mensajes que consume este tipo de componentes pueden ser enviados por
diferentes aplicaciones que soporten envió de mensajes con la tecnología JMS.
(Figure 5)
Figure 5. Componentes EJB [12]
Los componentes EJB se encuentran agrupados en módulos que contienen a su vez archivos
xml que permiten describir algunas de sus propiedades, la composición estos componente se
logra por medio de referencias a las interfaces de negocio del componente que se quiere
utilizar o por medio de delegación a través de clases java simples.
18
2.2.4. GAITA [15] [16] [10] Es un modelo sincrónico de servicios distribuidos no jerárquicos que viven en una red de
nodos, cada uno de los servicios puede ser localizado por medio de la comunicación entre los
diferentes nodos. Gaita se encuentra construido bajo los principios de:
• Simplicidad de conceptos, se requiere la cantidad mínima de elementos para
garantizar las funcionalidades básicas, las funcionalidades adicionales se deben
agregar como una extensión del modelo inicial.
• Reflexivo, Las definiciones de los elementos son alcanzables desde a partir de sus
instancias.
• Escalable, se define con la posibilidad de incluir características adicionales.
Un componente esta definido en Gaita como un elemento nombrado que cuenta con facetas
(interfaces que ofrece) y receptáculos (interfaces que requiere) y se relacionan entre si por
medio de conectores, un conector resuelve la relación entre el receptáculo del componente
origen y la faceta del componente destino, también cuenta con propiedades que facilitan la
configuración del componente.
Los nodos en gaita están conectados entre si y en ellos se encuentran los componentes y los
conectores, permiten el registro de los componentes, su instanciación y su ejecución de forma
distribuida.
(Figure 6)
Figure 6. Componente Compuesto en Gaita-C [10]
19
La composición en gaita se logra ensamblando componentes dentro de otros, un componente
compuesto esta construido por medio de una red de subcomponentes que se relacionan entre
si por medio de conectores y con el componente compuesto por medio de conectores
especiales, Delegate conecta una faceta del componente compuesto con una de un
componente interno, Subbinding es equivalente al conector mencionado anteriormente
(conecta componentes internos) y Subsumed que conecta un receptáculo de un componente
interno con un receptáculo del componente compuesto.
2.3. Lenguajes de Descripción de Arquitecturas – AD L Esta es una definición de ADL que es apropiada para describir lo que son los lenguajes de
descripción de arquitectura son algunas definiciones de ADL
“Lenguaje descriptivo de modelado que se focaliza en la estructura de alto nivel de la
aplicación antes que en la implementación de módulos concretos.” [17]
Estas son las características que teóricamente deben tener los ADL
• Ser capaz de comunicar una arquitectura a todos los interesados.
• Soportar tareas de creación, validación y refinamiento.
• Ser extensible
• Poder representar las arquitecturas usadas comúnmente
• Poder generar implementaciones rápidas
• Intentar ser comprensible tanto por seres humanos como por maquinas.
• Permitir analizar arquitecturas desde el punto de vista completitud, consistencia,
ambigüedad y desempeño
• Soportar generación automática de aplicaciones.
En la práctica se identifican como desventajas las siguientes:
No existe un estándar asociado al comportamiento de los elementos de la arquitectura se
trata de mostrar cosas con descripciones en algunos casos, en otros con lenguajes de
restricciones pero no existe un consenso en este tema, las representaciones logradas son
difíciles de interpretar y no están integradas a herramientas comerciales para permitir la
generación de aplicaciones que sería el propósito deseado para completar la cadena desde
diseño a por lo menos un esbozo de aplicación, La mayoría de adls están diseñados para
resolver un problema de análisis especifico (DSL) o son muy generales, La comunidad en
20
general en la practica reconoce la descripción de una arquitectura de software como un
conjunto de componentes y conexiones alrededor de ellos pero hay diferentes tipos de
arquitecturas que merecen descripciones a niveles de detalle específicos dependiendo de las
características que sean relevantes para los interesados.
2.3.1. ACME Para esta revisión Acme se considero como el mas relevante de los lenguajes y por esta razón
es mostrado en este documento para revisar algunos otros lenguajes en [18] existe un listado
que proporciona información acerca de sus paginas web.
Acme esta definido como un ADL (Architecture Definition Language) simple y genérico que
puede ser usado para realizar intercambio entre diferentes herramientas de diseño de
arquitectura o como una base para desarrollar nuevas herramientas de análisis y diseño de
arquitecturas, en la practica también es usado como un ADL.
Acme permite describir una arquitectura desde cuatro aspectos: estructural muestra la
organización de un sistema y de las partes que lo integran, propiedades de interés del sistema
o de sus partes que permiten proveer información funcional o no funcional de cada una de
ellas, restricciones que definen como el sistema puede cambiar en el tiempo y tipos y estilos
que definen clases y familias de arquitectura.
Elementos estructurales
La estructura de acme esta definida por siete elementos básicos componentes, conectores,
sistemas, puertos, roles, representaciones y rep-maps.
Los componentes representan elementos computacionales y almacenamientos de datos,
tienes múltiples interfaces llamadas puertos que permiten la interacción con otros
componentes a través de conectores. Los conectores también cuentan con interfaces que en
este caso están definidas por un conjunto de roles, cada rol define un participante en la
interacción que describe el conector, a su vez un conjunto de componentes y conectores
define un sistema, que es una especie de grafo en donde se puede decir que un componente
equivale a un vértice y un conector a un arco, donde la conexión esta definida por la relación
entre los roles del conector y los puertos del componente.
Una característica de Acme es que tanto los componentes como los conectores pueden ser
elementos compuestos representados en detalle por una descripción, esta descripción recibe
el nombre de representación. Acme también permite la creación de diferentes tipos de vista
sobre estos elementos compuestos en el caso que se requiera, por ejemplo se quiere mostrar
una vista simplificada o una vista un poco mas detallada esto se puede realizar por medio de
los representation map (rep-map).
21
Propiedades y Restricciones Cada uno de los siete elementos estructurales descritos anteriormente permiten mostrar el
sistema como una interacción entre ellos y cada una de sus características específicas, con el
fin de proveer la capacidad de expresar características que pueden ser de otro dominio, Acme
provee una lista de propiedades que permiten asociar información específica, estas
propiedades están compuestas de un nombre, tipo(opcional) y un valor.
Con el fin de dar una mayor consistencia a la estructura definida Acme permite definir
restricciones basadas en un lenguaje FOPL (first order predicate logic) que permite aplicar
condiciones sobre los elementos del sistema y sus propiedades por ejemplo que A y B deben
estar conectados o que el elemento Z debe tener una propiedad c, entre otras.
Clases y Familias de Arquitecturas Como se menciono inicialmente el objetivo general de acme es permitir el intercambio de
arquitecturas al revisar cada uno de los elementos que participan en la estructura, las
propiedades y las restricciones se puede notar que no hay especificidad en algún estilo de
arquitectura, ya que se quiere poder representar cualquiera, por este motivo Acme permite
definir estilos de arquitectura, un estilo de arquitectura esta definido como un conjunto de
propiedades y elementos estructurales que definen el vocabulario en la familia, restricciones
que determinan como los las instancias de los tipos deben ser usadas, y un estructura por
defecto que define lo mínimo que debe aparecer en un sistema que pertenezca a esta familia.
Herramientas Acme cuenta con un editor gráfico llamado AcmeStudio que funciona como un plugin de
eclipse que permite editar y crear familias y descripciones usando los elementos nombrados
acá, esta herramienta esta disponible en su sitio web[1].
2.4. Herramientas para Monitoreo
2.4.1. JMX Java Management Extensions (JMX) es una especificación que define una arquitectura de
gestión para facilitar la administración de aplicaciones y servicios. Esta tecnología permite que
desarrollar aplicaciones para ser integradas con algunas aplicaciones empresariales existentes
que la han acogido como estándar. Es usada para dar solución a diferentes problemas en el
manejo y monitoreo de procesos y recursos mientras son creados, instalados e
implementados, tales como: realización de ajustes en tiempo de ejecución, notificación en
cambios de estado y de posibles errores, recolección de estadísticas sobre el comportamiento
de la aplicación, así como cambios en la configuración de la misma, entre otras.
22
2.4.1.1. Arquitectura JMX Esta definida en 3 niveles, que permiten gestionar e integrar los recursos de manera sencilla,
un recurso puede ser instrumentado por uno o mas objetos Java, son conocidos como
MBeans, los cuales son registrados en un servidor central de MBeans que puede funcionar en
cualquier dispositivo que soporte Java:
• Nivel de Instrumentación (Instrumentation Level). En la capa de aplicación, es donde
residen los componentes que facilitan la información necesaria para la gestión de una
aplicación. Estos componentes son desarrollados según las necesidades de gestión
específicas de cada aplicación. Por ejemplo, un componente puede tener un método
para parar un servicio dentro de una aplicación.
• Nivel de Agente (Agent Level). El nivel de agente es el que facilita una interfaz para el
manejo de los componentes del nivel de instrumentación, aquí se registran y se
gestionan los MBeans.
• Nivel de Adaptadores (Manager Level). El nivel de adaptadores, consiste en uno o más
conectores (o adaptadores de protocolo) que proporcionan acceso desde los sistemas
de monitorización remotos. Aquí se crea un puente entre las tecnologías existentes y
las futuras [19].
(Figure 7)
23
Figure 7. Arquitectura JMX [19]
Componentes
MBean: es un objeto JMX que expone permite el acceso a la información de administración
por medio de propiedades y operaciones, definidas en una interfaz especifica, los MBeans no
necesitan conocer con que agente jmx están operando, hay 4 tipos de: Standard MBeans
tienen una implementación básica basada en modelo de implementación de los JavaBeans y
no pueden ser modificados en tiempo de ejecución, Dynamic MBeans define una interfaz más
especifica con mayor flexibilidad en tiempo de ejecución, Open Mbeans son dinámicos que
permiten usar objetos gestionados que luego serán descubiertos en tiempo de ejecución y
Model MBeans otro MBean dinámico, genérico y configurable que se utiliza para
instrumentar recursos en tiempo de ejecución.
Servidor MBean: es el componente principal de un agente JMX, aquí es donde se registran y
se exponen los MBeans para su interacción, los cuales pueden ser registrados por otro MBean,
por el mismo agente JMX o por una aplicación remota, a través de este se hace la localización,
monitoreo de atributos, establecer relaciones entre ellos, carga dinámica, programación de
tareas, definir jerarquías, así como el descubrimiento de otros.
Adaptadores y Conectores: las aplicaciones de gestión acceden a los MBeans remotamente a
través del Servidor MBean. El acceso puede también realizarse a través de los conectores de
adaptadores de protocolos. Las diferentes aplicaciones de gestión utilizan los conectores para
interactuar con los agentes. Mientras que los adaptadores de protocolos se utilizan cuando se
quiere integrar el recurso representado por MBean en un entorno de gestión ya existente.
El API de jmx provee una interfaz remota al servidor MBean a través de la cual se pueden
realizar operaciones.
Beneficios de usar JMX
La tecnología jmx permite a los desarrolladores encapsular componentes de objetos java que
luego pueden ser expuestos en un ambiente distribuido para su integración con sistemas
existentes. Cualquier entidad que necesite ser gestionada, en un futuro, puede ser
instrumentada por medio de MBeans ya que estos brindan la implementación de los recursos
gestionados de forma estándar y para ser incorporados en cualquier agente JMX. Pueden ser
cargados ó eliminados dinámicamente según sea necesario, lo que brinda gran flexibilidad.
24
2.4.2. Business Activity Monitoring – BAM BAM define como ofrecer acceso a indicadores de desempeño en tiempo real, recopilando
información de diferentes fuentes, externas e internas mostrando esta información por medio
de aplicaciones graficas vistosas que faciliten su interpretación [20]. Las herramientas BAM
permiten el análisis y presentación de la información recopilada. Actualmente las diferentes
organizaciones se encuentran estructurando sus procesos n los cuales se realizan diferentes
tipos de actividades que tienen resultados esperados, estos procesos están apoyados en
herramientas informáticas como BPMs, ERPs, CRMs, entre otros, esto facilita la recopilación
de información y la pone disponible en cualquier momento, la tecnología BAM facilita el
acceso y procesamiento de la información de los procesos, transformándola a indicadores que
se pueden entender de forma mucho mas fácil con el fin de permitir su monitoreo.
La tecnología BAM facilita la recolección de información de diferentes fuentes que pueden
estar distribuidas geográficamente o no, por medio del uso de web services, colas de mensajes
u otras tecnologías con el fin de permitir un monitoreo en tiempo real de los procesos que
facilita la toma de decisiones y la recolección de estadísticas de desempeño en, contrario al
monitoreo tradicional BAM se fundamenta en el hecho de recopilar información de múltiples
aplicaciones y otras fuentes internas o externas a la organización. BAM se reconoce como una
inteligencia de negocios BI en tiempo real.
2.4.2.1. Oracle BAM Es una herramienta BAM proveída por Oracle que puede ser usada con herramientas Oracle o
con herramientas de otro fabricante o propias, permite construir y visualizar dashboards y
monitorear aplicaciones por medio de una aplicación web.
Para lograr esto hace uso de mensajería, integración de datos, caches de datos, monitoreo
analítico, alertas y reportes.
Mediante el uso de caches permite la actualización de información a razón de decenas de
miles de operaciones por segundo, cualquier aplicación envía eventos por medio de web
services o JMS, también las aplicaciones legadas pueden enviar información por medio de
adaptadores específicos y también por medio de fuentes de datos externas como bases de
datos, archivos planos y archivos xml. Oracle BAM también puede enviar alertas a Web
Services externos.
La información recopilada se puede estructurar para ser mostrada de diferentes formas, para
esto se ofrece una aplicación para construir reportes basados en listas, charts, tablas, crosstabs
y KPIs.
Oracle BAM cuenta con una suite de herramientas que facilitan la producción de reportes,
BAM Architect permite definir fuentes de datos externas para recibir información por medio
25
de ellas, como colas jms, origenes de datos o bases de datos relacionales, estos datos
finalmente se almacenan en objetos de datos internos cuya estructura también se define con
esta herramienta. Active Studio permite definir los diferentes reportes que se realizan sobre
los objetos de datos internos. Design Studio por medio de un modelo de pipes permite la
relación entre las fuentes de datos externas y los objetos de datos internos por medio de
filtros permite modificar la estructura de datos de entrada en una diferente para ser
almacenada en los objetos de datos, por ejemplo realizar sumas, conversiones y múltiples
operaciones de tal forma que se transforme a la estructura destino.
3. Service Component Architecture – SCA SCA esta definida como un conjunto de especificaciones que describe un modelo para
construir aplicaciones y sistemas utilizando Arquitectura Orientada a Servicios (SOA).
El propósito principal de SCA es la construcción de componentes en los cuales su principal
característica es separar la implementación de la lógica de negocio de lo que es llamado
“assembly” o montaje, de tal forma que el montaje sea un mecanismo de comunicación
genérico y la implementación pueda ser realizada usando diferentes tecnologías, esto se logra
por medio del uso de componentes que implementan la lógica de negocio que a su vez es
expuesta por medio de interfaces, que son llamados servicios cuando son proveídos y
referencias cuando son requeridos, por medio de estos se puede realizar la comunicación o
interacción con otros componentes.
3.1.1. Historia En 2003 BEA e IBM inician su colaboración en la definición de SCA, ya en 2005 se publica la
versión numero 0.9 de sus primeras especificaciones ya con la colaboración de BEA, IBM,
ORACLE, SAP, IONA y Sybase, en 2006 se publica la versión 0.95 de las especificaciones y
entran a colaborar las empresas: Cape Clear, Interface21, Primeton Technologies,
ProgressSoftware, Red Hat, Rogue Wave, Siemens AG, Software AG, Sun, TIBCO y es creado el
grupo OSOA [21], dentro del cual se continuo con el diseño de SCA finalmente en 2007 las
versiones 1.0 de SCA son publicadas y enviadas a un nuevo grupo llamado Oasis [22] que es el
que actualmente se encuentra como responsable de la futura estandarización de las
especificaciones que hacen parte de SCA, para esto se conformaron seis comités técnicos: SCA
Assembly, SCA Policy, SCA Bindings, SCA-J, SCA-BPEL y SCA-C.
26
SCA cuenta con un conjunto de especificaciones que son SCA Assembly Model, SCA Policy
Framework, SCA Transaction Policy, SCA Java Common Annotations and APIs, SCA Java
Component Implementation, SCA Spring Component Implementation, SCA BPEL Client and
Implementation, SCA C++ Client and Implementation, SCA Web Services Binding, SCA JMS
Binding, SCA EJB Session Bean Binding, SCA COBOL Client and Implementation, SCA C Client
and Implementation, y SCA JCA Binding.
Estas especificaciones se pueden agrupar como muestra la siguiente figura.
(Figure 8)
Figure 8. Especificaciones de SCA
La especificación principal es el SCA Assembly Model dentro de el se encuentra todo el modelo
estructural de SCA que comprende los dominios, composites, componentes, wires y otros, el
Policy Framework resume conceptos de requerimientos no funcionales y las dos restantes
están asociadas al uso de tecnologías específicas es decir más al tema de implementación y de
cómo exponer servicios que al tema de descripción de la arquitectura como tal.
Para definir un ensamblaje SCA se cuenta con un lenguaje de definición llamado SCDL (Service
Component Definition Language), en la sección de elementos se muestra el elemento con su
representación grafica y un ejemplo de declaración en SCDL
27
3.1.2. Elementos Los elementos del modelo de ensamblaje se encuentran definidos en la especificación SCA
Assembly, algunos tienen una representación gráfica y otros son tan solo conceptuales, se van
a mostrar los más importantes y los que hagan falta se describirán cuando se haga referencia a
ellos por medio de algún ejemplo o explicación en este documento.
3.1.2.1. Service (Figure 9)
Figure 9. Representación gráfica de Service
Un elemento Service permite declarar la accesibilidad a las operaciones que ofrece una
implementación por medio de una interface, en este caso una a lo que se hace referencia
como implementación es a un Componente o a un Composite, en el caso del Composite el
servicio normalmente es delegado o asociado a un servicio de un componente dentro del
Composite, lo que un servicio representa básicamente es un conjunto de operaciones de una
implementación, para ser usadas por otras implementaciones o para ser expuestas de manera
publica para cualquier cliente externo, para el caso general una implementación puede
proveer múltiples servicios siempre y cuando las interfaces asociadas a este sean
implementadas por el elemento que provee la implementación.
Esto en cuanto a los elementos que se deben implementar los otros elementos son
ResourcesPath que describe donde se almacenan los recursos que debe usar la aplicación
como librerías de las implementaciones y MetamodelDescriptionFile que describe el
metamodelo que se va a implementar.
En el se debe referenciar los archivos donde estan escritas las maquinas de estado y las clases
que implementan cada una de las maquinas de estado junto con la clase que implementa el
runtime.
Por medio del runtime se realizan actividades sobre el modelo en ejecución, el runtime es
especifico para cada implementacion en genera el tipo de actividades estan relacionados con
por ejemplo obtener elementos de la estructura del modelo en tiempo de ejecución, detener
la ejecución, suspender la ejecución, reanudar la ejecución, en general tareas asociadas con el
modelo en tiempo de ejecución.
En resumen usando el framework de openobjectskernel para construir una nueva aplicación es
necesario:
• Definir los elementos y cuales son open objects, para los open objects, diseñar las
máquinas de estado y escribir sus xml.
• Diseñar el lenguaje para describir la estructura de los modelos
<metamodel name="SCA" version="0.1"> <!-- State machines used by the elments of the metamodel --> <state-machine-reference name="defaultDomain" file="domain.xml" />
3. Linda DeMichiel, S.M. and O.C. Michael Keith, JSR 220: Enterprise JavaBeansTM,Version 3.0, EJB 3.0 Simplified API. 2006.
4. Bruneton, E., et al., The FRACTAL component model and its support in Java: Experiences
with Auto-adaptive and Reconfigurable Systems. Software—Practice & Experience, 2006.
36(11-12): p. 1257-1284.
5. Villalobos, J., M. Sánchez, and D. Romero, Executable Models as
Composition Elements in the Construction of Families of
Applications. 6th International Workshop on the Foundations
of Coordination Languages and Software Architectures
(FOCLASA 2007), Portugal, September 2007, 2007.
6. Bass, L., P. Clements, and R. Kazman, Software Architecture in Practice. 2003: Addison-
Wesley Professional.
73
7. Clements, P., et al. Documenting software architectures: views and beyond. 2003.
8. Balasubramanian, K., Composition in the CORBA Component Model, K.E.i.t.C.C. Model, Editor. 2002.
9. Consortium, O. OW2 home page. Available from: http://www.objectweb.org/.
10. Samaniego, G., Lenguaje para Definir Interacción entre componentes: Caso de Requerimientos No Funcionales en Gaita in Depatamento de Ingenieria de SIstemas y Computación. 2008,
Universidad de Los Andes: Bogotá.
11. Sun Microsystems, I. Java EE at a glance. 2009; Available from:
http://java.sun.com/javaee/.
12. Sun Microsystems, I., Enterprise JavaBeans Fundamentals. 2006.
13. Inc., S.M., Enterprise JavaBeans, v 3.0. Java Persistence API. 14. Sun Microsystems, I. Java Message Service (JMS). Available from:
http://java.sun.com/products/jms/.
15. Casallas, R., et al., Gaita-S-V0: Model Final Specification. 2005.
16. Rocha, C., Semánticas para el ensamblaje de servicios y la composición de componentes en un modelo de servicios y componentes, in Depatamento de Ingenieria de SIstemas y
Computación. 2005, Universidad de Los Andes: Bogotá.
17. Reynoso, C. and N. Kicillof, Lenguajes de Descripción de Arquitectura (ADL). 2004.
18. Software Engineering Instute. Architecture Description Languages. 2009; Available from:
http://www.sei.cmu.edu/architecture/adl.html.
19. Sun Microsystems, I. Using JMX agents. 2006; Available from:
30. Barrero, I., Adaptación dinámica de modelos ejecutables extensibles para aplicaciones basadas en control, in Depatamento de Ingenieria de SIstemas y Computación. 2008, Universidad de
Los Andes: Bogotá.
31. Sun Microsystems, I. Class Proxy. 2004; Available from: