una herramienta basada en cumbia para análisis dinámico ... binding ... y com como las...
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
1. Introducción ............................................................................................................................... 7
2. Marco Teórico ........................................................................................................................... 9
2.1. Arquitectura de Software................................................................................................ 9
Estilo de arquitectura componentes y conectores. ............................................................................ 9
2.2. Modelos de Componentes ............................................................................................ 10
2.2.1. Corba CCM................................................................................................................... 10
2.2.2. Fractal .......................................................................................................................... 13
2.2.3. EJB................................................................................................................................ 15
2.2.4. GAITA [15] [16] [10]..................................................................................................... 18
2.3. Lenguajes de Descripción de Arquitecturas – ADL........................................................ 19
2.3.1. ACME ........................................................................................................................... 20
Propiedades y Restricciones...................................................................................................... 21
Clases y Familias de Arquitecturas............................................................................................ 21
Herramientas............................................................................................................................. 21
2.4. Herramientas para Monitoreo ...................................................................................... 21
2.4.1. JMX .............................................................................................................................. 21
2.4.1.1. Arquitectura JMX .................................................................................................... 22
2.4.2. Business Activity Monitoring – BAM ........................................................................... 24
2.4.2.1. Oracle BAM ............................................................................................................. 24
3. Service Component Architecture – SCA ........................................................................ 25
3.1.1. Historia ........................................................................................................................ 25
3.1.2. Elementos.................................................................................................................... 27
3.1.2.1. Service ..................................................................................................................... 27
3.1.2.2. Reference ................................................................................................................ 27
3.1.2.3. Interface .................................................................................................................. 28
3.1.2.4. Binding .................................................................................................................... 28
3.1.2.5. Implementation ...................................................................................................... 28
4
3.1.2.6. Wire......................................................................................................................... 29
3.1.2.7. Property .................................................................................................................. 29
3.1.2.8. Component ............................................................................................................. 30
3.1.2.9. Composite ............................................................................................................... 30
3.1.2.10. Component Type ................................................................................................ 31
3.1.2.11. Domain................................................................................................................ 32
3.1.3. Ejemplo........................................................................................................................ 32
3.1.4. Caso de Prueba............................................................................................................ 35
(Figure 16) ................................................................................................................................. 36
3.1.5. Características de SCA ................................................................................................. 36
3.1.6. Herramientas............................................................................................................... 38
4. Proyecto Cumbia ........................................................................................................... 38
4.1.1. Modelos ejecutables y objetos abiertos ..................................................................... 38
4.1.2. CumbiaOpenObjectsKernel ......................................................................................... 40
4.1.3. Motores que usan objetos abiertos ............................................................................ 44
5. Solución para el análisis de Modelos SCA. .................................................................... 45
5.1. Metamodelo de SCA...................................................................................................... 47
5.1.1. Elementos Del Metamodelo........................................................................................ 50
5.1.2. Máquina de estado de Componente........................................................................... 50
5.1.3. Maquina de estado de Wire ........................................................................................ 50
5.1.4. Maquina de estado de Composite .............................................................................. 51
5.1.5. Maquina de estado de Domain ................................................................................... 52
5.2. Motor de SCA usando Objetos Abiertos ....................................................................... 53
5.2.1. Caracteristicas ............................................................................................................. 53
5.2.2. Diseño.......................................................................................................................... 55
5.2.3. Service y Reference ..................................................................................................... 56
5.3. Diseño detallado de la implementación........................................................................ 58
5.4. Arquitectura del Motor ................................................................................................. 61
5.5. Experimentación y Pruebas........................................................................................... 62
5.5.1. Pruebas........................................................................................................................ 67
5.5.2. Framework de Pruebas................................................................................................ 67
5
6. Conclusiones y Trabajo futuro.............................................................................................. 70
6.1. Conclusiones: ................................................................................................................ 70
6.2. Trabajos futuros: ........................................................................................................... 71
7. Bibliografía............................................................................................................................... 72
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.
3.1.2.2. Reference (Figure 10)
<service name="MyValueService" promote="MyValueServiceComponent"> <interface.java interface="services.myvalue.MyValueService"/> <binding.ws port="http://www.myvalue.org/MyValueService# wsdl.endpoint(MyValueService/MyValueServiceSOAP)"/>
</service>
28
Figure 10. Representación gráfica de Reference
Este elemento permite a una implementación A declarar la necesidad de utilizar un servicio
que es ofrecido por una implementación B, una referencia es un servicio del cual la
implementación A puede ejecutar operaciones sobre la implementación B, tanto las
referencias como los servicios están tipados por una interface entonces en este caso debe
existir compatibilidad entre el servicio y la interface asociada.
3.1.2.3. Interface Por medio de estas se realiza la definición de las funciones de negocio de los componentes, las
interfaces son usadas por los servicios y referencias, un servicio expone una interface y una
referencia requiere una interface, una interface puede estar implementada usando interfaces
escritas en Java, WSDL 1.1 portType y WSDL Interface.
3.1.2.4. Binding Facilitan el acceso a servicios y referencias, por ejemplo el acceso de un cliente externo, usan
diferentes tecnologías como RMI, WSDL, JMS o EJB.
3.1.2.5. Implementation Es un artefacto de software que implementa un requerimiento de negocio y lo ofrece como un
servicio, para funcionar puede requerir servicios de otras implementaciones que son
inyectados como referencias. Puede ser en diferentes tecnologías como Java, Bpel, una
transformación xslt o una clase en c++, un composite SCA también puede ser usado como una
implementación.
<interface.java interface="services.stockquote.StockQuoteService"/>
<reference name="StockQuoteService" promote="MyValueServiceComponent/StockQuoteService"> <interface.java interface="services.stockquote.StockQuoteService"/> <binding.ws port="http://www.stockquote.org/StockQuoteService# wsdl.endpoint(StockQuoteService/StockQuoteServiceSOAP)"/>
</reference>
29
3.1.2.6. Wire (Figure 11)
Figure 11. Representación gráfica de Wire
Permite conectar un Servicio con una Referencia de manera explicita, cuando se crea una
Referencia se puede indicar cual es el servicio con el cual se quiere conectar, pero el wire
también permite realizar esta conexión indicando el servicio y la referencia que van a ser
conectados.
3.1.2.7. Property (Figure 12)
Figure 12. Representación gráfica de Property
Permiten la configuración externa de una implementación se les puede especificar un tipo de
dato y un valor.
<property name="SimpleTypeProperty"> MyValue </property>
<wire source=" ValueServiceComponent/StockQuoteService" target=" MyValueServiceComponent/StockQuoteService" />
<implementation.java class="services.myvalue.MyValueServiceImpl"/> <implementation.bpel process="MoneyTransferProcess"/> <implementation.composite name="MyValueComposite"/>
30
3.1.2.8. Component
(Figure 13)
Figure 13. Representación gráfica de Component
Son elementos que proveen funciones de negocio, son los que ejecutan en si las tareas o el
procesamiento, permiten que su implementación sea definida en diferentes tecnologías,
cuentan con propiedades que permiten su configuración, exponen servicios o requieren
servicios por medio de referencias y pueden conectar sus referencias con servicios de otros
componentes a través de un elemento wire.
3.1.2.9. Composite (Figure 14)
<component name="MyValueServiceComponent"> <implementation.java class="services.myvalue.MyValueServiceImpl"/> <property name="currency">EURO</property> <reference name="customerService"/> <reference name="stockQuoteService"/>
</component>
31
Figure 14. Representación gráfica de Composite
Representa la unidad básica de composición dentro de SCA. Un composite es un ensamble de
Componentes, Servicios, Referencias y Wires que se interconectan entre ellos y asocian sus
servicios o referencias a los del composite. Un Composite también puede ser usado como la
implementación de un componente y como una unidad de deployment.
3.1.2.10. Component Type Representa los aspectos configurables de una implementación, consiste en los servicios que
ofrece, las referencias que usa y las propiedades que tiene.
<componentType xmlns="http://www.osoa.org/xmlns/sca/1.0"> <service name="MyValueService">
<interface.java interface="services.myvalue.MyValueService"/> </service> <reference name="customerService">
<interface.java interface="services.customer.CustomerService"/> </reference> <reference name="stockQuoteService">
<interface.java interface="services.stockquote.StockQuoteService"/>
</reference> <property name="currency" type="xsd:string">USD</property>
</componentType>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="http://foo.com" name="MyValueComposite" > <service name="MyValueService" promote="MyValueServiceComponent"/> <component name="MyValueServiceComponent">
<implementation.java class="services.myvalue.MyValueServiceImpl"/> <property name="currency">EURO</property> <reference name="customerService"/> <reference name="stockQuoteService"/>
</component> <reference name="CustomerService"
promote="MyValueServiceComponent/customerService"/> <reference name="StockQuoteService" promote="MyValueServiceComponent/stockQuoteService"/>
</composite>
32
3.1.2.11. Domain En SCA la definición textual de dominio es “Representa un conjunto de servicios proveídos por
una área que es controlada por una organización.” [1]. Un dominio es el elemento que
permite acceder a los elementos, es el elemento que encapsula en si una aplicación, un
dominio contiene los composites que hacen parte del ensamblaje, de ellos por lo menos uno
debe asociarse como desplegable o “deployable”, los composites que son definidos con esta
característica exponen sus servicios para estar disponibles externamente.
3.1.3. Ejemplo El siguiente ejemplo muestra como los diferentes elementos pueden ser usados de manera
conjunta, es tomado íntegramente de [23].
Service AccountService
Reference StockQuote Service
AccountData Service Component
bigbank.accountcomposite
AccountService Component Service
AccountService
AccountData Service
34
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="bigbank.accountcomposite"> <service name="AccountService" promote="AccountServiceComponent">
<interface.java interface="services.account.AccountService" /> <binding.ws port="http://www.example.org/AccountService#
wsdl.endpoint(AccountService/AccountServiceSOAP)" /> </service>
<component name="AccountServiceComponent">
<implementation.java class="services.account.AccountServiceImpl" /> <reference name="StockQuoteService" /> <reference name="AccountDataService" target="AccountDataServiceComponent/AccountDataService" />
<property name="currency">EURO</property>
</component>
<component name="AccountDataServiceComponent">
<implementation.bpel process="QName" /> <service name="AccountDataService">
<interface.java interface="services.accountdata.AccountDataService" /> </service>
</component>
<reference name="StockQuoteService" promote="AccountServiceComponent/StockQuoteService"> <interface.java interface="services.stockquote.StockQuoteService" /> <binding.ws port="http://example.org/StockQuoteService# wsdl.endpoint(StockQuoteService/StockQuoteServiceSOAP)" />
</reference>
</composite>
StockQuote bigbank.accountcomposite
AccountService Component Service
AccountService
Reference StockQuote Service
AccountData Service Component
Reference StockQuote Service
3.1.4. Caso de Prueba Con el fin de realizar las pruebas se realizo la implementación de un escenario de prueba con
base en un escenario definido en un tutorial dentro del proyecto Caramelos, el escenario
consiste en una tienda virtual que expone los servicios de la tienda, la tienda esta dividida en
un frontend y un backend, el front expone los servicios de la tienda y tiene dependencias de
los servicios en el backend, el backend cuenta con servicios relacionados con inventarios,
clientes y ordenes de compra. El frontend esta implementado por medio de un composite
donde existen los componentes StoreComponent expone servicios de la tienda, se encarga de
realizar tareas en conjunto con los componentes internos, OffersExpert realiza el cálculo de las
ofertas que aplican a una orden, LocationExpert se encarga hacer cálculos dependientes de la
ubicación del cliente como opciones de envío y tarifas de impuestos, el backend provee
servicios para administrar el inventario, los clientes y las órdenes con los componentes
InventoryComponent, CustomerComponent y OrdersComponent. La tienda usa servicios de
entidades externas en este caso empresas de envío de mercancías por medio de las cuales se
realiza el envío de las órdenes. El frontend y backend son dos composites que se encuentran
distribuidos y su comunicación se da usando un binding RMI, los componentes tienen su
implementación en java, los componentes de las empresas de envío TCC, DHL, FedEx tienen su
implementación como un composite que internamente se implementa con un componente
que tiene su implementación en java, a continuación se muestra los modelos de la estructura
en SCA de la tienda.
(Figure
15)
Figure 15. Frontend del Caso de Prueba
36
(Figure 16)
Figure 16. Backend del Caso de Prueba
3.1.5. Características de SCA La estructura de ensamblaje de SCA permita la composición y creación de jerarquías de
elementos que son descritas de forma clara en función de los elementos que provee, los
componentes y composites se comportan de manera similar tienen propiedades en común
como sus propiedades, servicios y referencias, pueden ser reutilizados, un composite puede
ser la implementación de otro o la implementación de un componente de la misma forma un
componente puede tener como implementación un composite. Esta nueva capa de
37
ensamblaje permite una separación de la estructura de la solución y la implementación, en
este caso SCA define la estructura e interacción y las diferentes tecnologías permiten la
implementación de la lógica del negocio de cada uno de los componentes.
Por medio de los binding se logra la interconectividad de los componentes y composites con o
desde implementaciones o clientes diferentes tecnologías, los binding proporcionan métodos
de acceso a los componentes, encapsulando los protocolos de comunicación, serialización de
datos, etc.
En SCA se especifica de manera explicita la configuración de propiedades no funcionales como
capacidades y restricciones sobre componentes y sus interacciones por medio de la
especificación SCA Policy Framework.
Otra forma de ver los elementos de SCA es en función a como se comportan al construir una
aplicación en ese caso el dominio se abstrae como la unidad de despliegue, los composites
como una unidad de aplicación compuesta por componentes, servicios, referencias y los wire
entre ellos teniendo en cuenta que la implementacion de un componente puede ser un
composite.
(Figure 17)
Dominio Unidad Despliegue
Composite Aplicación
Composite
Components Services
Wire
References
Dominio Unidad Despliegue
Composite Aplicación
Composite
Components Services
Wire
References
Figure 17. Vista de elementos SCA
38
3.1.6. Herramientas SCA cuenta con varias implementaciones que se han desarrollado en proyectos de código
abierto y también con aplicaciones en las empresas reconocidas en la industria del software en
el caso de código abierto las herramientas se desarrollan explícitamente para proveer SCA, en
el caso propietario se incluye SCA en los productos tradicionales de aplicaciones empresariales
como un soporte mas para ayudar a desarrollar aplicaciones SOA o para estructurar
aplicaciones que ya existen.
Algunas implementaciones disponibles son:
• Rogue Wave® HydraSCA [24].
• WebSphere Application Server V7 Feature Pack for Service Component Architecture
[25].
• BEA AquaLogic® Service Bus 3.0 [26]
• Apache Tuscany [27]
• Fabric3 [28]
En [29] se muestra una lista de algunas implementaciones aunque al revisarlas algunas no
estaban actualizadas, las mencionadas en la lista anterior fueron consultadas en Enero de
2009.
4. Proyecto Cumbia El Proyecto Cumbia inicio en el año 2004 dentro del Grupo de Construcción de Software del
Departamento de Sistemas de la Universidad de Los Andes bajo el liderazgo del Profesor Jorge
Villalobos, el objetivo principal del proyecto al iniciar fue realizar investigación en procesos de
workflow y herramientas para estos procesos, teniendo en cuenta conceptos de modelos
ejecutables, a lo largo de estos años estas ideas se han refinado y han dado como producto
una buena cantidad de tesis de grado y el concepto de Objetos Abiertos y la composición de
estos para construir aplicaciones que en su mayoría resuelven problemas de control.
4.1.1. Modelos ejecutables y objetos abiertos Los modelos ejecutables extensibles dentro de cumbia representan dominios de una
aplicación, en Cumbia los metamodelos materializan los elementos del problema a modelar en
39
instancias especificas para volverlas ejecutables usando el concepto de objeto abierto como
herramienta para enriquecer la semántica de los metamodelos.
Los objetos abiertos son los mismos objetos clásicos pero cuentan con características
adicionales que les permiten exponer información acerca de su estado.
Los objetos tradicionales tienen un estado que se interpreta como la combinación de valores
de sus atributos, para conocer su estado es necesario llamar sus métodos, el numero de
estados es una combinación de su numero de atributos, pero el numero de estados relevantes
no es el numero total sino un subconjunto de ellos, ya que algunos pueden no ser de interés.
Estos estados se materializan en una maquina de estados y pueden ser nombrados, la
maquina de estados puede publicar notificaciones cuando algo ocurre en ella para coordinar
tareas con otros elementos.
Un objeto abierto esta compuesto de una entidad (Objeto tradicional), una maquina de
estados asociada a esta entidad y su conjunto de acciones. La interface del Objeto Abierto es
la misma de la entidad mas un conjunto de métodos para navegar la maquina de estados. En
el concepto tradicional la composición y coordinación se da por métodos en interfaces, en
objetos abiertos es posible componer y coordinar elementos usando maquinas de estado
como manejadores de composición ofreciendo un mecanismo de coordinación mas expresivo
que el tradicional.
Los eventos generados por la maquina de estados son consumidos por esta misma o por otras
estos pueden cambiar el estado. Cuando una maquina de estados cambia de un estado a otro
se generan los siguientes eventos: se abandona el estado, la transición inicia, la transición
finaliza y se llega al nuevo estado.
Una transición conecta dos estados y esta asociada a un evento. Los eventos son almacenados
en una de cola para ser procesados.
Los eventos son descritos por medio de una dupla compuesta por el nombre del elemento que
se espera haya generado el evento y el tipo de evento esperado. El nombre del elemento no
necesariamente es un identificador único, puede estar asociado a tipos de elementos.
Otros elementos son las acciones que están asociadas a transiciones que son ejecutadas de
manera sincrónica cuando una transición es procesada. Las acciones agregan semántica a los
cambios de estado por ejemplo llamando objetos abiertos. Se pueden definir reglas de
coordinación sincrona o asincrona.
(Figure 18)
40
Entity
OPEN OBJECT
doX()
doY()
doZ()
Action1 Action2 Action3
Terminated
ActiveInitInactive
[DOM-CONT] domainInitialized
[ME] activated
[ME] restarted
[ME] terminate
[COMPONENT] NewComponent
[WIRE] NewWire
CompleteElements ComponentCreated
WireCreated
executeA1() executeA2() executeA3()
Entity
OPEN OBJECT
doX()
doY()
doZ()
Action1 Action2 Action3
Terminated
ActiveInitInactive
[DOM-CONT] domainInitialized
[ME] activated
[ME] restarted
[ME] terminate
[COMPONENT] NewComponent
[WIRE] NewWire
CompleteElements ComponentCreated
WireCreated
Terminated
ActiveInitInactive
[DOM-CONT] domainInitialized
[ME] activated
[ME] restarted
[ME] terminate
[COMPONENT] NewComponent
[WIRE] NewWire
CompleteElements ComponentCreated
WireCreated
executeA1() executeA2() executeA3()
Figure 18. Vista de un objeto abierto
Los objetos abiertos proveen tres tipos de extensión, el primero modificando las acciones
asociadas a la maquina de estado es llamado extensión simple, otro es cambiando la
estructura de la maquina de estados agregando o removiendo estados y transiciones, el ultimo
es mediante la especialización de objetos abiertos que ya existen.
4.1.2. CumbiaOpenObjectsKernel Como se menciono anteriormente el concepto de modelo ejecutable y de objetos abiertos se
ha venido desarrollando desde hace varios años, inicialmente en el tema de Cumbia XPM y
luego como activo para la generación de otra aplicaciones, esta evolución ha permitido una
generalización de conceptos alrededor de los objetos abiertos fruto de esto se tiene ahora un
framework que facilita y da un marco a la construcción de aplicaciones usando estos objetos,
el framework recibe el nombre de CumbiaOpenObjectsKernel y esta definido como “una
plataforma para la ejecución de modelos ejecutables extensibles basados en Open Objects”.
La tarea inicial para definir una aplicación es definir el metamodelo de la aplicación, la
definición de este consiste en definir que objetos deben ser objetos abiertos y definir sus
maquinas de estado.
El framework da una estructura para la creación de aplicaciones pero en si la implementación
y el detalle de lo que el metamodelo hace es responsabilidad de los interesados en la nueva
aplicación. Teniendo la descripción del metamodelo, se debe definir el modelo propio de la
aplicación por ejemplo un modelo SCA en este caso la declaración del modelo debe hacerse en
41
conjunto con la el metamodelo, como ya se menciono el metamodelo es la concepción general
del problema y el modelo es un caso particular (instancia) que se quiere ejecutar. Cuando se
ejecuta una instancia de un dominio es necesario contar con la información de las instancias,
en el framework esto se define por medio de un archivo xml.
El xml anterior muestra la estructura general sin detalles del archivo de definición, este de
manera conceptual esta compuesto por:
• El metamodelo al cual esta asociada la definición, identificado por medio de su
nombre y versión, también el nombre dado a la definición.
• Las extensiones de objetos abiertos que se van a usar en la definición.
• Los elementos del modelo en si, por ejemplo para este caso ahí debería estar la
información de los elementos SCA que se definieron como objetos abiertos en el
metamodelo, en el caso que se haya definido a componente como objeto abierto ahí
deberían estar los diferentes componentes que van a intervenir por ejemplo los
componentes de reserva, facturación, etc.
• El runtime del modelo, más adelante se explicara que responsabilidades tiene este.
• El Modelo, es la parte en la que la nueva aplicación debe incluir sus elementos, en el
caso de SCA en la parte de modelo estarán las definiciones como las que se mostraron
en el ejemplo en la sección de SCA incluyendo sus Composites, Componentes,
<?xml version="1.0" encoding="ISO885915" ?> <definition metamodel="SCA" version="0.1" modelName="Simple Market"> <!-- Extensiones del modelo -->
<metamodelextensions> : </metamodelextensions> <!—Defiinicion de los elementos usados en el modelo-->
<elements> : </elements>
<!--Runtime Configuration--> <runtime />
<!-- Definicion de la estructura del dominio --> <model> : </model> </definition>
42
Referencias y los demás elementos de SCA que hacen parte de la definición, por
decirlo así en el modelo se define la parte especifica de la aplicación.
La definición anterior es lo que el framework leeria para cargar el modelo, el framework
realiza las tareas similar a un template method donde la nueva implementación tiene la
responsabilidad de implementar algunos artefactos específicos para cada problema, por
ejemplo como cargar el modelo que se va a ejecutar, la especificación de comunicación de los
roles en la maquina de estados, la implementación de las entidades y las acciones en los
elementos que son objetos abiertos. Estos artefactos implementan interfaces requeridas por
el framework y son proporcionados al framework por medio de un archivo que contiene lo
siguiente.
StructureLoaderClass (Cargador del modelo), se encarga de realizar la carga del modelo
desde los archivos xml, realiza la carga de lo que se llamó anteriormente modelo especifico de
la aplicación, que se encuentra en el tag model, también tiene la responsabilidad de relacionar
los objetos abiertos ya cargados por el framework con la información especifica de la
aplicación, en un caso especifico la información cargada aquí puede ser la de la entidad como
se hizo referencia en los Objetos Abiertos que están compuestos por la entidad mas otros
elementos. En este caso se implementa lo que en el archivo se llama
StructureLoaderClass y StructureInstantiatorClass que corresponden a las
interfaces ModelStructureLoader y ModelStructureInstantiator
respectivamente.
RoleResolverClass (Procesador de Roles), como se menciono antes para un Objeto
Abierto un evento esta descrito como una dupla compuesta por (quien se espera haya
generado el evento, identificador del evento), el concepto de “quien se espera haya generado
el evento” se asimila en el framework como el concepto de Rol de esta manera un Objeto
Abierto espera eventos específicos generados por un determinado Rol. La información de que
roles y eventos procesa un Objeto Abierto se encuentra detallada en la maquina de estados de
cada elemento pero la interpretación de quien o que elemento juega el rol en cada caso debe
proveerse de manera programatica por medio del RoleResolverClass, este es especifico
para cada problema y debe ser implementado de acuerdo a la interface RoleResolver.
StructureLoaderClass=uniandes.cumbia.sca.loaders.SCAStructureLoader StructureInstantiatorClass=uniandes.cumbia.sca.instansiation.SCAStructureInstantiator RoleResolverClass=uniandes.cumbia.sca.instansiation.SCARoleResolver ResourcesPath=../CumbiaDistribution/lib/SCAOpenObjects.jar StateMachinesPath=../CumbiaDistribution/data/SCAStateMachines MetamodelDescriptionFile=../CumbiaDistribution/data/SCAMetamodel.xml
43
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" />
<state-machine-reference name="defaultComposite" file="composite.xml" />
<state-machine-reference name="defaultComponent" file="component.xml" />
<state-machine-reference name="defaultWire" file="wire.xml" />
<state-machine-reference name="defaultService" file="service.xml" />
<!-- Elements of the metamodel --> <type name="Domain" class=" Domain" statemachine="defaultDomain" />
<type name="Composite" class="Composite" statemachine="defaultComposite" />
<type name="Component" class=" XComponent" statemachine="defaultComponent"
<type name="Wire" class="XWire" statemachine="defaultWire" />
<!-- Runtime Configuration --> <runtime class="SCARuntime" />
</metamodel>
44
• Implementar las clases que componen el metamodelo, el runtime, clases que necesita
el kernel, clase para cargar la estructura de los modelos, la clase para resolver los
roles, el motor
• Escribir el archivo de configuración para el kernel.
4.1.3. Motores que usan objetos abiertos Desde el inicio del proyecto cumbia se han desarrollado diferentes motores basados en
objetos abiertos que resuelven diferentes tipos de problemas, estos son:
4.1.3.1. Cumbia XPM
Es un metamodelo diseñado para modelar aplicaciones que donde el componente de control
juegue un papel importante, estas aplicaciones pueden ser motores de workflow, sistemas de
e-learning, plataformas de orquestación o herramientas de trabajo colaborativo, fue el
primero de los productos desarrollado con objetos abiertos y sirvió como espacio de
experimentación para refinar los conceptos asociados a estos, cuenta con una especificación
formal y una implementación llamada JCumbia.
4.1.3.2. Cumbia XRM
Consiste en un metamodelo que permite la asignación de recursos, los recursos son asignados
a actividades en un proceso, el metamodelo tiene en cuenta los recursos y las reglas de cómo
asignarlos, fue diseñado como un dominio complementario a XPM, cuenta con su
especificación y una implementación.
4.1.3.3. Cumbia XTM
Permite la asignación de restricciones o reglas de tiempo en una actividad de un proceso de
también es complementario a XPM, se encuentra especificado en la que se caracterizaron una
serie de reglas de tiempo asociadas a la ejecución de actividades y existe una implementación.
4.1.3.4. Cumbia XAM
Es un modelo para describir la composición entre diferentes modelos cumbia, en los ya
mencionados XRM y XTM se dice que son complementarios a XPM esto significa que deben
trabajar de manera conjunta, XAM permite definir una aplicación que en el contexto de
cumbia es un conjunto de diferentes dominios que necesitan trabajar de manera coordinada,
XAM cuenta con una especificación y su respectiva implementación que actualmente es usada
por otras aplicaciones mencionadas en esta lista.
4.1.3.5. Caffeine
45
Es un motor de BPEL esta construido bajo los conceptos de una fabrica de aplicaciones de
workflow usando los activos existentes en cumbia, caffeine representa los elementos de bpel
como elementos de cumbia XPM para lograr su ejecución, actualmente soporta un
subconjunto de los elementos de BPEL y se esta trabajando en un proyecto de grado para
avanzar en la implementación de la totalidad de las facilidades propuestas en BPEL.
4.1.3.6. PaperExpress
Es una herramienta de trabajo colaborativo que permite a los participantes trabajar
conjuntamente en la redacción de artículos, paperExpress modela el proceso de escribir un
articulo mediante el uso de XPM y administra el proceso de escritura tanto el grupo de
participantes como las posibles modificaciones en el proceso de escritura por medio del uso
de adaptación dinámica [30] sobre el proceso en ejecución.
5. Solución para el análisis de Modelos SCA. Un modelo puede ser tan analizable como posibilidades de observación haya en el, en los
casos de los modelos de componentes ya vistos hay muchas posibilidades de análisis dado el
diseño que tienen en el caso de Fractal desde su concepción se define la interfaz de control o
membrana que permite configurar los componentes, esto da desde diseño una herramienta
para poder acceder al modelo para reconfiguración, en el caso de CCM y EJB que son
componentes que viven en un contenedor la relación componente/contenedor da puntos en
los cuales es posible también realizar algunos tipos de análisis. Estos modelos están diseñados
fuertemente a su implementación de hecho el modelo de componentes es una pequeña
sección en sus implementaciones y se hace un gran énfasis en como debe ser su
implementación y en los contratos que los componentes deben cumplir los componentes con
el entorno por ejemplo el contenedor.
En SCA la situación varía un poco, esta diseñado con la idea de estandarizar la construcción de
aplicaciones como se vio las especificaciones están divididas y se pueden caracterizar en
conjuntos, en el assembly es donde se define el modelo de componentes de una manera muy
sencilla y asociada a lo que son los elementos en el estilo componentes, dejando de lado
niveles de detalle de implementación, en este modelo no se muestran capacidades ni para
controlar ni para administrar.
Se puede decir que un modelo de componentes en abstracto brinda unas ventajas pero que la
implementación o las herramientas que permiten poner a marchar ese modelo de
componentes brindan ventajas adicionales y explotan las características de los modelos, es por
esta razón que los ya mencionados Fractal, EJB y CCM exigen detalles de implementación para
lograr características importantes en sus modelos de ejecución, con esto se concluye que para
tener una herramienta de ejecución que permita hacer análisis sobre un modelo se debe
pensar en un modelo en este caso SCA mas una implementación que explote las posibilidades
46
del modelo para realizare análisis, claro que esta implementación depende del tipo de análisis
que se quiera hacer, en el caso del análisis estático por ejemplo model-checking no es
necesario instanciar el modelo ni ejecutarlo se puede verificar su consistencia desde el punto
de vista estructural, los elementos respetan su estructura, desde el punto de vista de
relaciones los elementos cumplen con los contratos que fueron definidos las referencias y
servicios cumplen con las interfaces definidas, también pueden existir algunos casos de
análisis ya un poco mas dinámico se puede analizar el modelo que servicios provee que
componente y si las interfaces definidas por los servicios son implementadas por la
implementación de componente, esto también se puede realizar sin la necesidad de ejecutar
el modelo.
En este caso el análisis al que se quiere llegar es al análisis dinámico, se quiere poder observar
el modelo en tiempo de ejecución y en instantes de tiempo específicos, para lograr esto es
necesario contar con lo siguiente: el modelo en ejecución para que pueda ser dinámico,
mecanismos para poder observar el modelo y un mecanismo que permita determinar en que
instantes de tiempo se puede realizar la observación. Los modelos ejecutables modelados con
el uso de objetos abiertos dan características a los elementos de expresar su comportamiento
en función a una maquina de estados, asociar acciones en diferentes momentos cuando hay
un cambio de estado (antes, durante y después) y la posibilidad de notificar estos cambios a
interesados que se han registrado previamente.
SCA es una propuesta nueva data de 2005 y su especificación final es de 2007, al indagar por
herramientas que permitan realizar análisis sobre los modelos de SCA no se encuentra en la
actualidad una herramienta que permita recopilar información acerca de la ejecución de
aplicaciones hechas usando SCA, se encuentra información respecto a análisis para verificar a
SCA formalmente, pero no se cuenta con herramientas que permitan realizar análisis
dinámico sobre la ejecución de modelos implementados en SCA, la solución que se propone
tiene en cuenta el concepto de objetos abiertos dentro de la estructura de la aplicación
desarrollada para resolver el problema, por medio de objetos abiertos se modelan elementos
que realizan la ejecución y que permiten la relación de componentes con otros, la utilización
de los objetos abiertos junto con la definición del metamodelo de SCA permiten a las
entidades usuarias de la aplicación la posibilidad de conectar a los objetos abiertos cualquier
herramienta que en el momento de ejecución permite la recopilación de sin tener que
modificar la estructura ya existente, esto nos brinda la posibilidad de realizar análisis dinámico
del comportamiento de las aplicaciones que se estén ejecutando, un componente de manera
natural estaría definido como de caja negra pero con la incorporación de SCA se permite la
instrumentación de este que además de ser navegable también brinda la opción de notificar a
los interesados cuando su estado cambie, en el momento de un cambio es posible navegar por
todo el modelo para recopilar información no solo del elemento que genera el evento sino de
todos los elementos de la estructura aprovechando la capacidad de reflexividad de los
47
metamodelos implementados usando objetos abiertos. Las técnicas actuales que nos
permitirían esto podrían ser mas bien instrusivas o requerir recompilaciones de código o de
modificación del bytecode para lograr esto, en el caso de esta aplicación la exposición del api
de cumbia que bien podría ser ocultado facilita la instalación de las herramientas de análisis
sobre los elementos del metamodelo.
La solución entonces es tener el modelo SCA y brindarle la posibilidad de ser analizable por
medio de las características de observación e instrumentación que brindan los objetos
abiertos, en este caso también se ve que la implementación del modelo de componentes da
características adicionales pero en este caso no colocando requerimientos en el modelo desde
su concepción sino con la adición de una forma de percepción del modelo, en este caso se
modela SCA como modelo ejecutable, se definen algunos elementos como objetos abiertos y
con base en ese modelo se realiza la implementación de la herramienta.
5.1. Metamodelo de SCA La característica principal de este metamodelo es reflejar la forma como interactúan los
elementos de SCA para llevar a cabo la ejecución de servicios, teniendo en cuenta los posibles
estados iniciales, finales e intermedios de algunos de sus elementos, con el objetivo de poder
materializar los estados relevantes para poder proporcionar la capacidad de intervención
deseada. Aunque el metamodelo se muestra como un modelo estructural, una forma
adecuada de describirlo es profundizando en la interacción de sus elementos en tiempo de
ejecución, esto nos permite hacer énfasis en sus relaciones y mostrar el metamodelo como un
todo, la descripción del metamodelo al referirse a sus elementos por cuestiones didácticas se
supone un ambiente de ejecución en donde al hacer referencia a los elementos se hace
referencia a instancias de los tipos de elementos abstractos en un ambiente de ejecución.
El propósito de una aplicación construida con un modelo SCA no es mas que publicar servicios
de componentes para que sean utilizados por los interesados en este, así la operación básica
es llamado a una operario de un servicio, el llamado a una operación de un servicio en SCA
ocurre por medio de un estimulo realizado por una entidad externa al metamodelo, que envía
una señal en este caso un Call que compuesto de un descripción y un conjunto de parámetros,
la ejecución de este call, puede provocar la interacción de diferentes componentes del modelo
y de muchas instancias de ellos dependiendo del comportamiento de la Implementación del
Componente donde se ejecute el call. Un componente es la unidad de procesamiento en SCA,
es el que provee Servicios a los sobre los que se van a realizar llamados a sus operación que
son materializadas en este caso por los call. Los componentes tienen una implementación que
debe implementar los servicios que el componente expone, sobre su Implementación es
donde finalmente se ejecutan los call.
48
En un caso simple el llamado a una operación se hace por medio de un Servicio que genera un
call sobre un componente que es ejecutado sobre su implementación. Un componente
configura una implementación por medio de sus Propiedades y sus Referencias, en el caso
anterior se describía un llamado simple o directo sobre un servicio de un componente que
esta disponible externamente, existe otro caso donde una implementación ha sido
configurada con referencias, las referencias describen la dependencia de servicios de otros
componentes, esta dependencia se describe de manera explicita por medio de un Wire,
cuando una implementación tiene referencias es posible que un call ejecutado sobre ella
provoque el llamado a operaciones sobre servicios de otro u otros componentes, en este caso
se da un o unos nuevos call pero con la participación de mas elementos, este call consiste en
un llamado a una operación sobre una o unas de las referencias de la implementación, una
referencia permite el llamado a un servicio de otro componente por medio del wire, lo que
ocurre en este caso es la llamada a una operación sobre una referencia que finalmente es
ejecutada en el la implementación del componente referenciado contando con la participación
de un wire, en este caso el call generado por la implementación debe ser por decirlo así
propagado a través de estos elementos, estos dos tipos de llamado describen la interacción
básica que se da en el metamodelo, cualquier ejecución se da como un conjunto de llamados
de este tipo sobre uno o muchos servicios de los componentes.
Si se observa un ensamblaje SCA desde el punto de vista estructural se tiene al dominio como
el elemento básico de despliegue, representa el elemento que permite exhibir una aplicación,
un dominio permite el acceso a los servicios de la aplicación, facilita la interacción entre los
clientes externos y el metamodelo. Un dominio esta compuesto de un conjunto de
composites. La (Figure 19) muestra el metamodelo formulado para SCA.
Figure 19. Metamodelo de SCA
5.1.1. Elementos Del Metamodelo Los elementos modelados como objetos abiertos son domain, composite, component y wire.
5.1.2. Máquina de estado de Componente Un componente es la unidad ejecutable en este modelo, es el que finalmente recibe los
llamados a los servicios y los ejecuta sobre la implementación. La maquina de estado del
componente tiene cuatro estados, su estado inicial es Inactive, al ser creada una nueva
instancia de un componente debe realizarse algunas operaciones sobre él, básicamente
asociadas con el estado de sus propiedades y relaciones con los wire, al ya estar listo pasa al
estado Waiting, esto quiere decir que está disponible para procesar las llamadas a las
operaciones que ofrece, existen dos estados mas LocalCalling y WireCalling son usados en los
casos de las llamadas directas y delegadas respectivamente, en el caso de la llamada directa se
usa el mecanismo de comunicación por método de los objetos abiertos y en el caso de la
llamada delegada se usa el mecanismo por eventos del wire en el que el Componente
representa el rol TARGET.
(Figure 20)
LocallCalling
Waiting
initialize [ME]
Inactive
wireCall [ME]
Call
WireCalling
call [ME]
makecall [WIRE]
endWireCall [ME]
endCall [ME]
WireCall
PassWireCall
EndCall
EndWireCall
LocallCalling
Waiting
initialize [ME]
Inactive
wireCall [ME]
CallCall
WireCalling
call [ME]
makecall [WIRE]
endWireCall [ME]
endCall [ME]
WireCallWireCall
PassWireCall
EndCallEndCall
EndWireCallEndWireCall
Figure 20. Máquina de estado de Componente
5.1.3. Maquina de estado de Wire Un wire es el elemento que facilita la comunicación entre componentes, permite que una
referencia de un componente A haga un llamado a un servicio de un componente B. La
relación del wire con el componente destino o “target” se realiza por medio de su maquina de
51
estado. La máquina de estado del wire tiene cuatro estados, su estado inicial es Inactive, al ser
creada una nueva instancia se realizan operaciones asociadas con el estado de sus propiedades
y relaciones con los componentes y pasa a estado Init en este estado espera el evento
dataPassed que corresponde a una llamada hecha por la implementación del componente
source del wire, recibe la información de la llamada, y se mantiene en estado Waiting, cuando
la llamada es resulta por el componente TARGET se recibe un evento callExecuted pasa a
estado PassingData espera un evento callReturned que determina que ya se recibió el llamado
y retorna al estado Active para recibir nuevas ejecuciones.
(Figure 21)
PassingData
Active
callExecuted [TARGET]
InitPassData
dataPassed [ME]
Inactive
Initialize [ME]PassCall
wireCall [ME]
MakeCall
callReturned[ME]
PassingData
Active
callExecuted [TARGET]
InitPassDataPassData
dataPassed [ME]
Inactive
Initialize [ME]PassCallPassCall
wireCall [ME]
MakeCall
callReturned[ME]
Figure 21. Máquina de estado de Wire
5.1.4. Maquina de estado de Composite Composite es la unidad de composición natural en SCA en este caso contiene los elementos
ejecutables Component y Wire recibe eventos de ellos para administrar algunas de sus
propiedades. Al ser instanciado al igual que los demás inicia en estado Inactive cuando el
dominio pasa a estado Init, este genera un evento que pasa al composite usando el rol DOM-
CONT que cambia el su estado a Init. Cuando el composite es activado por medio de la accion
CompleteElements pasa a estado Active, en este estado recibe eventos del wire y componente
cuando es creada la instancia de cada uno de ellos, estando en estado Active también puede
recibir un evento terminate que lo cambia a estado Terminated y de este puede ser reiniciado
a Active por medio de un evento restarted.
52
(Figure 22)
Terminated
ActiveInitInactive
[DOM-CONT] domainInitialized[ME] activated
[ME] restarted
[ME] terminate
[COMPONENT] NewComponent
[WIRE] NewWire
CompleteElementsComponentCreated
WireCreated
Figure 22. Máquina de estado de Composite
5.1.5. Maquina de estado de Domain Domain es el elemento que permite el acceso a la aplicación, en esta implementación es el
elemento raíz del metamodelo, cuenta con características para finalizarse que equivale a
finalizar la aplicación y para suspender su ejecución. Su máquina de estado inicia en estado
Inactive cuando el dominio es inicializado recibe un evento domainInitialized y pasa a estado
Init, este evento también pasa el composite a estado Init, cuando ya todo el dominio es
activado pasa a estado Active, en ese estado puede ser terminado o suspendido, estando
suspendido reactivarse y estando terminado puede reiniciarse.
(Figure 23)
53
Suspended
Terminated
ActiveInitInactive
[ME] domainInitialized[ME] activated [ME] reactivate
[ME] restarted
[ME] terminate
[ME] suspend
Suspended
Terminated
ActiveInitInactive
[ME] domainInitialized[ME] activated [ME] reactivate
[ME] restarted
[ME] terminate
[ME] suspend
Figure 23. Máquina de estado de Domain
5.2. Motor de SCA usando Objetos Abiertos
5.2.1. Caracteristicas
Para la implementación de este motor se uso el framework de objetos abiertos, este ha sido
usado en los diferentes motores mencionados anteriormente, en esos casos la mayoría de los
motores han sido modelos ejecutables que responden a requerimientos relacionados con
procesos de workflow, en algunos casos se ha usado la definición de los motores usando
objetos abiertos y se incluye el uso de Cumbia XPM como componente de control, en el caso
de esta implementación la situación resulta un poco diferente aunque hay control, el
componente de control no es el suficiente como para soportarlo con XPM. La siguiente figura
describe el la estructura que se usa para implementar modelos ejecutables cumbia (Figure 24).
54
MODELO EJECUTABLE PARA UN DOMINIO
INSTANCIA ELEMENTO 1
ELEMENTO 1
ELEMENTO 2
ESPACIO DE MATERIALIZACIÓN
ESPACIO DE ABSTRACCIÓN
INSTANCIA ELEMENTO 2
MODELO EJECUTABLE PARA UN DOMINIO
INSTANCIA ELEMENTO 1
ELEMENTO 1
ELEMENTO 2
ESPACIO DE MATERIALIZACIÓN
ESPACIO DE ABSTRACCIÓN
INSTANCIA ELEMENTO 2
Figure 24. Modelo ejecutable para un dominio
Esta estructura es la que se ha manejado en los diferentes motores y la que se usará para
esta implementación en este caso el esquema a utilizar es el siguiente. (Figure 25)
SCA
Domain
Instancia Domain
ESPACIO DE MATERIALIZACIÓN
ESPACIO DE ABSTRACCIÓN
Composite
Component
WireInstancias Composite
Instancias Component
Instancias Wire
Figure 25. Modelo ejecutable para SCA
55
Con lo experiencia acumulada en el proyecto cumbia es evidente la utilidad de los Objetos
Abiertos como una herramienta para construir aplicaciones que respondan a un modelo
ejecutable y que se modelan como una estructura jerárquica incluyendo un conjunto de
elementos abstracto que definen el modelo de la aplicación en este caso SCA y sus elementos.
Entonces en este caso se tiene una aplicación donde la estructura esta definida por el modelo
ejecutable del dominio SCA, que tiene definidos unos elementos de manera abstracta y las
instancias de estos en conjunto con las de otros elementos constituyen el modelo completo de
la aplicación.
El elemento primordial de ejecución en este caso es el componente sobre el se realizan las
operaciones y el a su vez las realiza sobre la implementación pero teniendo en cuenta la
información de propiedades que es asignada al componente y al composite, en el caso de un
composite este expone servicios pero al final van a ser promovidos (promote) a un
componente que es el que realiza la ejecución, desde el punto de vista de quien realiza el
llamado a una operación de un servicio, se pueden distinguir dos casos básicos, dependiendo
de quien acceda al servicio, si se accede por medio de un cliente externo de ahora en delante
se define que es un llamado directo y si el cliente es un componente interno, es decir se
accede por medio de un wire o una referencia que en el caso practico es equivalente se define
como un llamado delegado, de ahora en adelante estas se definen como operaciones básicas
dentro de esta implementación para la ejecución de cualquier tipo de servicio, de esta forma
cualquier llamado a un servicio se hace por medio de un llamado directo y de este se pueden
generar llamados delegados entre diferentes componentes, que pueden ser tantos como sean
requeridos dependiendo del diseño del componente o del composite.
5.2.2. Diseño Ya se mostró cuales son los elementos que definen un ensamblaje en SCA y se definió un
metamodelo base para el modelo ejecutable que será utilizado en esta implementación, como
ya se menciono el énfasis se hace entorno a los conceptos de llamado directo y delegado,
partiendo de esta premisa se definen los elementos respecto a que tipo de elementos deben
ser y que tarea juegan dentro de la arquitectura de la implementación, se distinguen dos tipos
de elementos relevantes, los objetos abiertos de los que ya se ha hablado bastante y los Proxy
[31], los demás son elementos normales que se implementan de manera convencional o que
responden a un propósito especifico que se describirá cuando se requiera.
Los elementos que son objetos abiertos son dominio, composite, componente y wire,
estructuralmente existe una dependencia entre ellos, un dominio contiene composites y este
a su vez wires y componentes, como se menciono anteriormente en el caso de los llamados
directos se hace por medio de un servicio de un componente y en el caso de un llamado
56
delegado se hace sobre una referencia usando la pareja wire y componente, donde estos se
comunican o relacionan usando sus características de objetos abiertos.
Los elementos que se modelan como Proxy son el servicio y la referencia, claro que el servicio
se materializa de esta forma solo en el caso del llamado directo y la referencia en el caso del
llamado delegado, los Proxys se usan con el fin de poder mostrar a los clientes externos y a las
implementaciones una vista Java pero con la posibilidad de interceptar los llamados
efectuados para ser procesados de acuerdo al tipo de llamado.
Los elementos restantes propiedades, interfaces, binding e implementación, tienen incidencia
en la implementación pero no un comportamiento ejecutable explicito y este se mencionara
mas adelante.
5.2.3. Service y Reference El elemento service y reference facilitan a los clientes los llamados sobre el metamodelo, en
este caso especifico la implementación se realiza en Java, para dar una perspectiva Java a los
clientes es necesario interceptar los llamados a operaciones hechos por los clientes tanto
externos como internos, en el caso de los clientes externos, los llamados se dan sobre servicio
y en el caso interno las referencias son inyectadas en las implementaciones quienes son las
que realizan los llamados a operaciones, en este caso el llamado por medio de un servicio es el
llamado directo y el llamado por medio de de una referencia es el llamado delegado. Esto hace
emerger la necesidad de mostrar estos dos elementos como importantes dentro de la
estructura de la ejecución del metamodelo, estos dos elementos son los que permiten que los
clientes accedan al metamodelo para ejecutar sus servicios.
(Figure 26)
57
XComponent<<openobject>>
Implementation.java
Proxy
Figure 26. Service Proxy
(Figure 27)
Aimpl.java
XComponent<<openobject>>
Bimpl.java
Proxy
XWire<<openobject>>
Figure 27. Reference Proxy
58
5.3. Diseño detallado de la implementación Ya se han definido los elementos y se han explicado en detalle se va a mostrar el metamodelo
sobre el cual se construye la aplicación, se consideraron los elementos que son objetos
abiertos sobre los que se formuló el metamodelo. El diseño de la aplicación se puede ver en
función a cuatro vistas generales, la primera describe la estructura desde el punto de vista de
los objetos abiertos y los elementos que permiten la construcción de ellos, la segunda muestra
como se realizo la abstracción del ensamblaje de SCA que es la misma mostrada para el
metamodelo, aunque algunos de estos elementos no son ejecutables ellos permiten
configurar los elementos ejecutables para que realicen sus tareas, por ejemplo los valores de
propiedades que son asignados a las implementaciones, establecer las relaciones entre los
diferentes componentes por medio de sus wire, referencias y servicios, en el caso de los
binding exponer servicios por medio de RMI o localizar referencias también por medio de RMI,
el tercer y cuarto diagrama muestran como se realiza la relación entre los proxy y los objetos
abiertos, el tercero muestra la parte de la estructura del metamodelo que se usa para una
llamada directa y el cuarto la parte que se usa para una llamada delegada.
(Figure 28)
Figure 28. Construcción de elementos ejecutables
59
(Figure 29)
Figure 29. Diagrama detallado service proxy
(Figure 30)
60
Figure 30. Diagrama detallado reference proxy
61
5.4. Arquitectura del Motor
(Figure 31)
SCA Engine
CumbiaAPI SCA API
SCA
Metamodel
Open Objects
Kernel
SCA Engine
CumbiaAPI SCA API
SCA
Metamodel
Open Objects
Kernel
Figure 31. Arquitectura General
Como ya se ha mencionado el motor funciona apoyado en el framework
CumbiaOpenObjectsKernel para materializar el metamodelo de SCA, el motor realiza la
implementacion del metamodelo y de las demás características para poder ejecutar un
modelo SCA, las entidades externas interactúan con el motor para ejecutar aplicaciones SCA y
para conectar aplicaciones de análisis, en el primer caso el SCA Api permite acceder a servicios
de los cuales se pueden invocar operaciones y en el caso de análisis se proporciona una visa
cumbia donde se puede navegar por el modelo, solicitar elementos específicos por medio del
runtime, instalar sensores, acciones y todos los elementos para interactuar con el motor en
tiempo de ejecución.
(Figure 32)
62
CumbiaOpenObjectsKernel
SCA Metamodel
SCAAnalysisPlugins
BAMBandwidthAnalysis
SCAEngine
InstanceImplementation
FactoryConversation
Manager
RMI Publisher Proxys
Figure 32. Detalle de los componentes generales del diseño
El Engine de SCA proporciona la implementación de tareas complementarias a las del
metamodelo para lograr la ejecución completa de la aplicación, el administrador de instancias
se encarga de manejar las instancias sobre las que los componentes van a ejecutar ya que
estas cuentan con un ciclo de vida donde tienen en cuenta las referencias, propiedades y el
scope que se haya definido, el administrador de conversaciones maneja los identificadores y
junto con el administrador de instancias se encarga de garantizar el correcto funcionamiento
de las llamadas con estados conversacionales, el publicador rmi proporciona la infraestructura
necesaria para poder exponer servicios o ubicar referencias usando el binding RMI, finalmente
los proxys como ya se menciono proporcionan las vistas del metamodelo para los clientes
tanto externos como internos.
5.5. Experimentación y Pruebas Mediante el siguiente escenario de experimentación se muestra que es posible realizar análisis
sobre una aplicación SCA, en este documento ya se definió un escenario sobre el cual se va a
realizar la experimentación, el caso es el siguiente:
Se quiere determinar la necesidad de ancho de banda para la aplicación en el caso de ser
distribuida, supongamos que los componentes se encuentran distribuidos en una red y al
haber dependencias entre ellos se deben realizar llamados que pueden recibir respuestas esto
genera un intercambio de datos, la red funciona actualmente pero se quiere determinar el
impacto de la nueva aplicación para saber si se requieren cambios en la infraestructura, el
intercambio de datos entre los componentes debe ser proporcional al numero de llamadas a
las operaciones de sus servicios y a las respuestas producto de estos llamados.
63
En este caso es necesario recopilar la cantidad de datos que se intercambia en los llamados
entre componentes, el punto adecuado para obtener esta información es el Wire, como se
menciono en el diseño el wire es el elemento que facilita las llamadas a servicios cuando un
componente es cliente de otro, esta es la maquina de estados del wire.
PassingData
Active
callExecuted [TARGET]
InitPassData
dataPassed [ME]
Inactive
Initialize [ME]PassCall
wireCall [ME]
MakeCall
callReturned[ME]
PassingData
Active
callExecuted [TARGET]
InitPassDataPassData
dataPassed [ME]
Inactive
Initialize [ME]PassCallPassCall
wireCall [ME]
MakeCall
callReturned[ME]
Figure 33. Máquina de estado de Wire
Al mirar en detalle cuando el evento wireCall es recibido en el estado Init es porque se ha
recibido un Call de un componente cliente, esta transición se llama Call en esta transición es
posible acceder al Call que se va a ejecutar esto se puede realizar agregando una acción en la
transición que realice esta tarea.
64
Figure 34. Transición Call en el Wire
La accion CollectCallInfo se encarga de recopilar la información relevante para realizar el
análisis
ComponenteOrigen ComponenteDestino FechaHora Tamaño del call
En el caso del retorno es posible contar con la información cuando es generado por el
componente destino el evento callExecuted estando el wire en estado Active, en este caso el
componente destino esta retornando la respuesta al llamado, en este caso la transición se
llama PassCallResult de la misma forma es necesario instalar una acción para recopilar la
información.
Active Init
dataPassed
PassCall wireCall
MakeCall
CollectCallI
nfo
65
Figure 355. Transición PassCallResult en el Wire
En este caso la información es recopilada por la acción CollectReturnInfo y la información
recopilada es la siguiente.
ComponenteOrigen ComponenteDestino FechaHora Tamaño del retorno
La tarea de instalar una acción en una transición es sencilla es necesario obtener la transición
sobre la cual se quiere instalar la acción profundizando en el tema para obtener una transición
es necesario saber sobre cual elemento y cual transición se requiere esto se obtiene por
medio del runtime con un método getElement que recibe la ruta
wire|NombreDomain:NombreComposite:NombreWire|PassCallResult, la primera
parte indica el tipo de elemento este caso un Wire, la siguiente la ruta del wire
dominio:composite:wire finalmente el nombre de la transición, por medio de esto se obtiene
un elemento tipo Transition y ya estando en la transición se invoca el siguiente método para
agregar la acción addAction( actionName, actionImplementation ).
PassingData
Active
callExecuted [TARGET]
PassData
dataPassed [ME]
MakeCall
callReturned[ME]
CollectReturnInfo
66
De este modo se obtiene la información pero no basta con tener la información suelta para
poder llevar a cabo el análisis de la información es necesario procesar los datos recolectados
para tener resultados del análisis, en este caso para ilustrar las posibilidades el análisis la
información es realizado por el Software BAM de Oracle
(Figure 36)
ENTERPRISE MESSAGE RECEIVER
OC4JJMS TOPIC
SCA OPEN OBJECTS
JMS MESSANGE
DOMAIN ELEMENTS
ORACLE DATA OBJECTS
ORACLE BAM
REPORTS
....
..
Figure 366. Diseño solución BAM
Dentro de este escenario de validación se construyo una pequeña herramienta para poder
visualizar información recopilada del motor en reportes en Oracle BAM, el propósito de la
herramienta es mostrar información recopilada de los call y sus respuestas.
La figura anterior muestra la estructura de cómo funciona la aplicación, en términos generales
consiste en la generación mensajes JMS con la información recolectada en las acciones a una
cola que recibe la información para Oracle BAM, los mensajes son generados a medida que
son generados los eventos en el wire que hacen ejecutar las acciones, estos mensajes llegan al
Enterprise Message Receiver como una cadena de caracteres que representa un XML allí se les
aplica una transformación XSL y son almacenados como Oracle Data Objects. Los reportes que
67
componen la consola son generados a partir de la información almacenada en estos Oracle
Data Objects.
5.5.1. Pruebas Las pruebas del correcto funcionamiento del motor de SCA que se ha implementado se
realizaron sobre el necesario ya definido, las pruebas comprenden pruebas al
comportamiento funcional del escenario y del correcto funcionamiento de los elementos que
se definieron como objetos abiertos.
5.5.2. Framework de Pruebas Dentro de los elementos que han sido desarrollados en Cumbia se encuentra todo un estudio
de cómo hacer pruebas sobre modelos ejecutables, para esta tarea se definió un framework
de pruebas [32]. Existe una herramienta que facilita esta tarea, la herramienta permite la
observación y recolección de información sobre el motor. El proceso de pruebas consiste en la
recolección de información de los artefactos del motor para ser analizada por medio de
aserciones dentro de pruebas al finalizar la ejecución, esta recolección se realiza por medio de
la ejecución del motor y en conjunto con el framework de pruebas, para realizar esto se
requiere la implementación de algunos artefactos específicos para cada motor.
Figure 377. Esquema del framework de pruebas
Motor SCA
Sensores
Test Assertions
Traces
Tracers
68
El framework de pruebas también aprovecha las propiedades de los objetos abiertos, el
framework consiste en un kernel que facilita la instalación de artefactos sobre los elementos
del metamodelo, se hace por medio de sensores que son instalados en las transiciones de los
elementos similar a las acciones en el concepto de objetos abiertos, en el momento de
ejecutar una transición es posible realizar interacción con el modelo, los sensores se encargan
de instalar tracers, los tracers incorporan lógica que permite recopilar información de la
ejecución en el metamodelo, esta información es almacenada en traces sobre el que
finalmente en las pruebas se realizan aserciones, los tracers también tienen como
responsabilidad evaluar la información de las trazas para mostrarla de la manera adecuada, en
el caso de estos corren de manera local, por lo cual este framework no puede probar
aplicaciones distribuidas pero si probar cada parte en este caso probar cada composite.
Para formular las pruebas es necesario realizar las ejecuciones sobre el motor es decir dar los
estímulos para que el motor se ejecute, algo similar a lo que hace un cliente del motor, un
cliente solicita un servicio y luego realiza una ejecución, para este propósito en el framework
de pruebas es necesario definir un programa de animación, un programa de animación esta
escrito en un lenguaje que es específico para cada caso, para este motor es necesario definirlo,
el lenguaje de animación para este caso permite la solicitud de servicios sobre el dominio que
se esta probando y luego la definición de un programa donde se pueden hacer llamados sobre
las operaciones del servicio.
<animation name="animation0"> <instances>
<service id="3" name="customerService" class="store.customers.CustomersExternal" serviceName="CustomerComponent/CustomersExternal" />
</instances> <program>
<command name="DELAY">value=2000;</command> <command name="INSTRUCTION">
<instruction id="a" name="createCustomer" serviceId="3"> <variables>
<variable name="cc" value="100000000" type="java.lang.String" /> <variable name="name" value="Pedro Pérez" type="java.lang.String" /> <variable name="password" value="mipassword" type="java.lang.String" /> <variable name="location" value="Bogota, Colombia" type="java.lang.String" /> <variable name="address" value="Cll 19 No. 11" type="java.lang.String" />
</variables> </instruction>
</command> </program> </animation>
69
Para el proceso de pruebas se requiere probar el correcto funcionamiento del motor dados los
estímulos, el lenguaje de animación permite la obtención de servicios y la ejecución de
operaciones en servicios, las características que se probaron fueron:
• Al solicitar un servicio todos los elementos que van a participar se encuentran en
estado de espera.
• El resultado de la ejecución de una operación es la esperada.
• La ejecución en el caso del llamado directo se hace sobre el componente esperado.
• La ejecución en el caso del llamado directo cuando este tiene dependencias sobre
llamados delegados se realiza en el orden adecuado y sobre los elementos adecuados.
• La ejecución del llamado a una operación se realiza en el composite esperado.
• Los valores asignados a las propiedades son los que efectivamente se declararon en
los archivos de definición.
• Las ejecuciones múltiples en paralelo sobre un mismo componente tiene el resultado
adecuado.
70
6. Conclusiones y Trabajo futuro
6.1. Conclusiones:
• Se construyo una herramienta que permite el análisis de aplicaciones definidas usando
SCA, la herramienta obtenida combina los conceptos de SCA con las posibilidades de
observación e interacción de los objetos abiertos, lo que resulta en una herramienta
que permite el análisis dinámico, en este caso se exploró la suma de dos modelos para
poder lograr esto a diferencia de otros modelos de componentes que deben proveer
este tipo de características desde su concepción.
• Es posible realizar el análisis dinámico por medio de la herramienta, el modelo
formulado como base tiene en cuenta los estados por los cuales pasan los elementos y
que son relevantes con la construcción usando objetos abiertos se pone al alcance
externo, los estados relevantes de los componentes y un mecanismo para interactuar
con el metamodelo cuando los eventos ocurren de una forma sencilla por medio de
interfaces e independiente de los detalles internos de al implementación.
• Se exploro SCA como una herramienta que permite definir aplicaciones que separan la
estructura de la implementación, con el paso de la investigación se encuentra a SCA
mas como una herramienta que permite estructurar aplicaciones a un nivel de
abstracción un poco mas alto dejando la implementación como un problema que se
resuelve con el uso de diferentes tecnologías, es este caso se exploro el caso de
implementaciones en Java, actualmente SCA soporta otras mas y cuenta con
mecanismos para poder extender este soporte para adicionar implementaciones en
otras tecnologías, en el caso Java existen algunos detalles que debe correlacionar la
definición de la arquitectura con las implementaciones por medio de anotaciones,
esto no resulta tan beneficioso pues se aumenta un poco la complejidad al llevar
información de descripción al nivel de código entonces resulta de mayor dificultad la
interpretación del detalle de la arquitectura de las aplicaciones construidas.
71
• Se mostró que el concepto de Modelos Ejecutables y Objetos abiertos en el que se ha
venido trabajando como activo principal para la fabrica de aplicaciones basadas en
workflows, también puede ser usado como concepto para modelar en este caso un
modelo ejecutable como lo es SCA pero que no esta ligado a un workflow sino a un
modelo de componentes, aunque es importante anotar que el uso de las maquinas de
estado puede llegar a convertir las herramientas desarrolladas en aplicaciones con alta
dependencia secuencial, es importante saber tomar las decisiones en cuanto a que
elementos deben modelarse como objetos abierto, en este trabajo se intento
combinar la capacidad de paralelismo de los objetos convencionales usando proxys y
comunicando a estos con objetos abiertos pero con la construcción de instancias de
manera dinámica para suplir la situación de ejecución secuencial pero compartiendo
elementos de ejecución como las implementaciones.
• Resulto en este caso de utilidad importante el uso del framework
CumbiaOpenObjectsKernel, de una manera independiente al uso de objetos abiertos
las capacidades que tiene para estructurar aplicaciones donde el modelo pueda ser
jerárquico y responda o no a un modelo ejecutable resultan beneficiosas a la hora de
construir una aplicación que cumpla con estas características.
6.2. Trabajos futuros: Con los conceptos recopilados y la experiencia vivida en esta investigación surge un conjunto
de interrogantes que podrían ser planteados como ideas para trabajos futuros o como temas
de profundización en los conceptos de SCA.
• En SCA existe un conjunto de especificaciones asociadas a políticas de ejecución estas
definen restricciones sobre como deben comportarse los elementos en un
ensamblaje, puede resultar interesante profundizar conceptualmente en este tema
como una posibilidad para formular metamodelos de políticas bien sea para SCA o
para los modelos que ya se han ejecutado en el proyecto Cumbia.
• Explorar la posibilidad de incluir en la herramienta la implementación de componentes
en tecnologías adicionales a Java es posible pensar en implementaciones usando
procesos en XPM con el objetivo de construir aplicaciones XPM estructuradas por
medio de SCA.
• Se ha venido explorando en Cumbia el concepto de adaptación dinámica en modelos
ejecutables, la incorporación de este concepto en este trabajo podría resultar en un
modelo altamente configurable.
72
7. Bibliografía 1. Beisiegel, M., et al., Sca service component architecture - assembly model specification. 2007.
2. Object Management Group OMG. Corba Component Model Specification. 2006; Available
from: http://www.omg.org/docs/formal/06-04-01.pdf.
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:
http://java.sun.com/javase/6/docs/technotes/guides/jmx/overview/agent.html.
20. McCoy, D., Business Activity Monitoring: Calm Before the Storm. Gartner Research Note
LE-15-9727, 2002.
21. OSOA. OSOA Home. Available from: http://osoa.org/display/Main/Home.
22. OASIS. OASIS Open CSA. Available from: http://www.oasis-opencsa.org/.
23. Edwards, M., SCA: Flexible and Agile Composition of Distributed SOA Applications. JavaOne
2008, 2008.
24. Rogue Wave Software. Rogue Wave HydraSCA. 2008; Available from:
http://www.roguewave.com/products/hydra/hydrasca.php.
25. IBM Corporation. WebSphere Application Server V7 Feature Pack for Service Component
Architecture. 2008; Available from: http://www-
01.ibm.com/software/webservers/appserv/was/featurepacks/sca/.
26. Oracle Corporation. BEA Enterprise Service Bus. Available from:
http://www.bea.com/framework.jsp?CNT=requirements.htm&FP=/content/products/aqu
alogic/service_bus/.
27. Apache Tuscany. Available from: http://tuscany.apache.org.
28. Fabric3. Available from: http://fabric3.codehaus.org/.
29. Graham, B. and E. Mike. Implementation examples and tools. 2008; Available from:
http://osoa.org/display/Main/Implementation+Examples+and+Tools.
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:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Proxy.html.
32. Moreno, S., A Testing Framework for Dinamyc Composable Executable Models, in Depatamento
de Ingenieria de SIstemas y Computación. 2008, Universidad de Los Andes: Bogotá.
74