FACULTAD 5
“PROCESO DE DESARROLLO PARA APLICACIONES COMPUESTAS EN UNA INICIATIVA SOA”
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas
Autor: Yainury Peraza García
Tutor: Ing. Luis Enrique Hernández Vega Cotutor: Ing. Jorge Infante Osorio
La Habana Junio 2012
Yainury Peraza García – Universidad de las Ciencias Informáticas I DECLARACIÓN DE AUTORÍA
Declaro ser autora de la presente tesis y reconozco a la Universidad de las Ciencias Informáticas los derechos patrimoniales de la misma, con carácter exclusivo. Para que así conste firmo la presente a los ___ días del mes _________ del año 20__.
_________________________
Yainury Peraza García Autora
____________________________ ________________________
Luis Enrique Hernández Vega Jorge Infante Osorio Tutor Cotutor
Yainury Peraza García – Universidad de las Ciencias Informáticas II DATOS DEL CONTACTO
Ing. Luis Enrique Hernández Vega
Centro de Trabajo: Centro de Consultoría y Desarrollo de Arquitectura Empresarial. Universidad de Ciencias Informáticas.
Categoría docente: Instructor Correo electrónico: [email protected]
Ing. Jorge Infante Osorio
Centro de Trabajo: Centro de Consultoría y Desarrollo de Arquitectura Empresarial. Universidad de Ciencias Informáticas.
Categoría docente: Instructor Correo electrónico: [email protected]
Yainury Peraza García – Universidad de las Ciencias Informáticas III AGRADECIMIENTOS
A mi mamá, por ser mi guía y amiga, gracias por tu dedicación a lo largo de todos estos años, sin ti no hubiera sido posible este día.
A mi papá, por apoyarme y ayudarme siempre.
A mi abuelita querida por su cariño y por su apoyo.
A mis tías María Elena e Iliana por ayudarme y estar siempre cuando más las necesito.
A Fernando por estar siempre tan preocupado por mí.
A mis amistades que me apoyaron en todo momento, a los distantes, a los cercanos, a los de siempre.
A mi tutor y amigo por su dedicación y apoyo incondicional.
Yainury Peraza García – Universidad de las Ciencias Informáticas IV DEDICATORIA
A toda mi familia, en especial a mis padres Betty y Ángel por su apoyo incondicional y ser mi inspiración durante estos años.
A mis abuelos que con su cariño y dedicación me han enseñado a enfrentar mejor la vida.
A mi hermano y primos que espero servirle de ejemplo para su futuro.
A mis abuelos Arquel y Haydee donde quiera que estén.
Yainury Peraza García – Universidad de las Ciencias Informáticas V RESUMEN
Con el presente trabajo investigativo quedó conformado un proceso para el desarrollo de aplicaciones compuestas a partir de los servicios candidatos identificados en iniciativas orientadas a servicios, que garantice una mejor elaboración del producto en proyectos productivos de software. Para esto se realizó un estudio de las metodologías de desarrollo de software orientadas a servicios, teniendo en cuenta sus características, beneficios y limitaciones para el tema en cuestión, seleccionando CBDI-SAE como metodología base. Se definieron las fases, capas, disciplinas, actividades, roles y artefactos que rigen el proceso de desarrollo en aplicaciones compuestas. La validación de la investigación se realizó mediante el Método Delphi, el cual arrojó resultados satisfactorios después de haber encuestado a los expertos seleccionados para validar el proceso propuesto.
PALABRAS CLAVE:
aplicaciones compuestas, metodología de desarrollo, proceso de desarrollo, SOA.
Yainury Peraza García – Universidad de las Ciencias Informáticas VI ÍNDICE
INTRODUCCIÓN ... 1
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA ... 7
1.1 Arquitectura Orientada a Servicios (SOA). ... 7
1.2 Aplicaciones Compuestas. ... 8
1.3 Metodologías de desarrollo de software para SOA. ... 10
1.3.1 Arquitectura y Modelado Orientado a Servicios (SOMA). ... 10
1.3.2 CBDI - Servicio de Arquitectura e Ingeniería (CBDI-SAE). ... 12
1.3.3 Repeatable Quality (RQ). ... 14
1.3.4 Framework de Arquitectura Orientada a Servicio (SOAF). ... 15
1.3.5 Metodología de Thomas Erl ... 16
1.4 Tabla resumen de las metodologías para SOA. ... 17
1.5 Conclusiones parciales ... 20
CAPÍTULO 2: PROCESO DE DESARROLLO PARA APLICACIONES COMPUESTAS ... 21
2.1 Introducción. ... 21
2.2 Alcance del Proceso de Desarrollo. ... 21
2.3 Premisas para la aplicación del Proceso de Desarrollo. ... 21
2.4 Descripción del Proceso de Desarrollo. ... 22
2.5 Fases. ... 23
2.6 Capas y Disciplinas... 23
2.7 Roles. ... 25
2.8 Artefactos de entrada al Proceso de Desarrollo. ... 26
2.9 Descripción de artefactos del Proceso de Desarrollo. ... 26
2.10 Descripción de Actividades. ... 29
2.10.1 Disciplina de Arquitectura y diseño de las soluciones ... 29
2.10.2 Disciplina de Arquitectura y Diseño Orientados a Servicios ... 30
2.10.3 Disciplina de Transición de los Sistemas Legados ... 32
2.10.4 Disciplina de Aprovisionamiento de la Solución ... 34
2.10.5 Disciplina de Especificación y Diseño de Servicios ... 37
Yainury Peraza García – Universidad de las Ciencias Informáticas VII
2.10.6 Disciplina de Implementación de los Servicios ... 40
2.10.7 Disciplina de Ensamblaje de las Soluciones ... 42
2.10.8 Disciplina de Despliegue de las Soluciones y Servicios ... 45
2.11 CONCLUSIONES PARCIALES ... 47
CAPÍTULO 3: VALIDACION DEL PROCESO DE DESARROLO. ... 48
3.1 Introducción. ... 48
3.2 Métodos de Expertos. ... 48
3.3 Método Delphi... 49
3.4 Aplicación del Método. ... 49
3.4.1 Proceso de selección de los expertos. ... 49
3.4.2 Cálculo del Coeficiente de Competencia... 50
3.4.3 Elaboración del cuestionario para la validación de la propuesta. ... 52
3.4.4 Desarrollo práctico y explotación de resultados. ... 53
3.4.5 Tabulación de los resultados por preguntas. ... 54
3.5 Conclusiones Parciales. ... 58
CONCLUSIONES ... 59
RECOMENDACIONES ... 60
REFERENCIAS BIBLIOGRÁFICAS ... 61
BIBLIOGRAFÍA CONSULTADA ... 64
GLOSARIO ... 65
ANEXOS ... 66
Yainury Peraza García – Universidad de las Ciencias Informáticas VIII
INDICE DE TABLAS
Tabla 1: Tabla resumen de Metodologías para SOA ... 19
Tabla 2: Coeficiente de conocimiento o información ... 51
Tabla 3: Coeficiente de argumentación ... 51
Tabla 4: Grados de Adecuación ... 54
INDICE DE FIGURAS Figura 1: Representación del Proceso de Desarrollo ... 22
Figura 2: Diagrama de Actividades de la Disciplina Arquitectura y Diseño de las Soluciones ... 29
Figura 3: Diagrama de Actividades de la Disciplina Arquitectura y Diseño Orientados a Servicios ... 30
Figura 4: Diagrama de Actividades de la Disciplina Transición de los Sistemas Legados ... 32
Figura 5: Diagrama de Actividades de la Disciplina Aprovisionamiento de la Solución ... 34
Figura 6: Diagrama de Actividades de la Actividad Certificar la Solución ... 34
Figura 7: Diagrama de Actividades de la Disciplina Especificación y Diseño de Servicios ... 37
Figura 8: Diagrama de Actividades de la Actividad Certificar y Publicar Servicios... 38
Figura 9: Diagrama de Actividades de la Disciplina Implementación de los Servicios ... 40
Figura 10: Diagrama de Actividades de la Disciplina Ensamblaje de las Soluciones ... 42
Figura 11: Diagrama de Actividades de la Actividad Probar la Solución Desplegada ... 43
Figura 12: Diagrama de Actividades de la Actividad Desplegar Servicios ... 45
Figura 13: Diagrama de Actividades de la Actividad Desplegar los Componentes de la Solución ... 46
Figura 14: Nivel de adecuación de la pregunta 1 ... 54
Figura 15: Nivel de adecuación de la pregunta 2 ... 55
Figura 16: Nivel de adecuación de la pregunta 3 ... 56
Figura 17: Nivel de adecuación de la pregunta 4 ... 56
Figura 18: Nivel de adecuación de la pregunta 5 ... 57
Figura 19: Nivel de adecuación de las preguntas de la encuesta ... 58
Yainury Peraza García – Universidad de las Ciencias Informáticas 1 INTRODUCCIÓN
En el mundo actual el campo de la informática se ha desarrollado cada vez más. En sus inicios el desarrollo tradicional del software implicó la construcción de aplicaciones monolíticas que reflejan una estructura en grupos funcionales muy acoplados involucrando los aspectos referidos a la presentación, procesamiento y almacenamiento de la información. Esta estrategia de utilizar aplicaciones compactas causa gran cantidad de problemas de integración en sistemas de software complejos, como pueden ser los sistemas de gestión de una empresa o los sistemas de información integrados consistentes en más de una aplicación. Estas aplicaciones suelen desprender importantes problemas de escalabilidad, disponibilidad, seguridad e integración. (1)
A nivel mundial el mundo empresarial se enfrenta a un reto que con los años se ha venido intensificando independiente del sector o industria: la reducción de sus costos mientras aumenta su agilidad y velocidad para innovar respecto a sus ofertas en el mercado. Hoy en día la mayoría de las aplicaciones de negocio son eficaces en la automatización de las transacciones, pero no permiten la colaboración a través de fronteras funcionales; lo cual conduce a una pérdida de la productividad debido a que los usuarios se ven obligados a interactuar con un conjunto de herramientas y a menudo integrar manualmente los datos en cada uno de los sistemas. (2)
En los últimos años con el desarrollo de las tecnologías de la información surge el modelo de computación distribuida, el cual centra sus esfuerzos en resolver diferentes problemas asociados con la administración distribuida de los sistemas cliente servidor.
Todo este avance tecnológico motiva la introducción y utilización de la Arquitectura Orientada a Servicios (en inglés Service Oriented Architecture o SOA) el cual es un concepto de arquitectura de software que define la utilización de los servicios para dar soporte a los requerimientos de software y exponer los procesos de negocio como servicios, propiedad que define el carácter flexible de esta arquitectura. (3)
Yainury Peraza García – Universidad de las Ciencias Informáticas 2
Con el avance de las soluciones de software aparecen las aplicaciones compuestas. Las cuales utilizan nuevos paradigmas como los portlets1 y los mashups2 para combinar en una única aplicación información procedente de diferentes fuentes. (4)
En la actualidad las aplicaciones compuestas requieren de un nuevo enfoque de gestión que establezca una correlación dinámica entre los servicios de aplicaciones y los componentes de código compartidos que sustentan esos servicios. (5)
El desafío más grande durante la gestión de aplicaciones compuestas complejas es la obtención de la visibilidad necesaria para que se puedan ejecutar las funciones esenciales de las Tecnologías de la Información (TI): gestión de incidentes y problemas, gestión de cambios y entregas de software, gestión de capacidad, gestión de disponibilidad, gestión del nivel de servicio y gestión de la configuración. (5) Las compañías operando con una Arquitectura Orientada a Servicios están bien preparadas para desarrollar aplicaciones compuestas. Con las funciones de negocio desarrolladas como servicios, las nuevas aplicaciones pueden reutilizar servicios existentes (6). Además se pueden construir aplicaciones compuestas por medio de la composición y orquestación de servicios.
Con todo este avance han surgido una serie de metodologías orientadas a servicios, que tratan de reducir el nivel de dificultad y asegurar resultados más controlables y repetibles en su implantación.
Algunas de estas metodologías son revisiones de metodologías de desarrollo tradicional de software orientado a objetos, y otras han sido creadas desde cero alrededor del concepto de “servicio” tal y como se entiende en SOA (7). Sin embargo, un estudio sobre estas metodologías y un análisis de sus propiedades, es que la mayoría son tratadas desde un punto de vista general, sin referirse a propuestas específicas (8).
En la Universidad de las Ciencias Informáticas (UCI) se desarrollan proyectos de gestión universitaria propios de esta institución y proyectos de gestión empresarial que se han implantado en diferentes empresas. En algunos casos dichos sistemas necesitan de una comunicación e integración con otros
1 Componentes modulares de las interfaces de usuario gestionadas y visualizadas en un portal web, es decir, pequeñas aplicaciones Web hospedadas en un portal.
2 Página Web que cuenta con información de fuentes múltiples agrupadas para crear una vista integrada y consolidada de la información combinada.
Yainury Peraza García – Universidad de las Ciencias Informáticas 3
sistemas, en función de satisfacer demandas relacionadas con el intercambio de información y de interoperabilidad entre ellos, para lo cual el empleo de SOA es una decisión correcta.
Uno de los centros de desarrollo pertenecientes al entorno productivo de la UCI es el Centro de Consultoría y Desarrollo de Arquitectura Empresarial (CDAE), el cual incluye en sus misiones servicios de consultoría para la implantación de una SOA, identificándose varias líneas en función de cubrir cada una de las áreas que definen la aplicación de una SOA, estableciendo metodologías de desarrollo, guías de adopción y propuestas de arquitecturas de referencia que se sustenten sobre el empleo de tecnologías libres. Actualmente se desarrollan investigaciones que tributan a algunas de estas áreas, siendo la definición de procesos de desarrollo de SOA, una de las líneas investigativas más importantes.
En proyectos de software desarrollados por el CDAE que se componen por un conjunto de módulos comprendidos en la construcción de aplicaciones compuestas, como el portal de gestión empresarial OICIM (Operaciones Industriales del Centro Inmunología Molecular) (9), ocurrieron un conjunto de incidencias durante la ejecución de las fases de desarrollo que afectaron la elaboración del software. En entrevistas realizadas a sus desarrolladores se evidenciaron hechos como:
Los procesos de diseño recibían como entrada un modelo de casos de uso y requisitos de software. Los diseñadores eran forzados a realizar técnicas y métodos de identificación de servicios desconociendo que estas actividades no son realizadas por su rol. Esto implicaba que en la mayoría de los casos no se ejecutara la identificación de servicios de la forma más correcta pues no tenían una idea clara de los procesos de negocio que debían ser descompuestos.
No se elaboraba un diseño o contrato de los servicios previo a la implementación. Los diseñadores solamente confeccionaban un documento que describía y contenía detalles de los servicios. Se entendía que parte de la implementación era la confección del contrato de servicios.
Se realizó la implementación de los servicios web antes de realizar un diseño o contrato de servicio. Los desarrolladores hacían uso de métodos de generación de contratos. Implicando que con un nuevo cambio en la implementación y código del servicio pudiera ocurrir la generación de un contrato diferente al anterior.
Yainury Peraza García – Universidad de las Ciencias Informáticas 4
El desarrollo de los componentes y servicios de presentación fue afectado por los cambios continuos en los contratos generados, teniendo que adaptar sus clientes de servicios a los nuevos contratos.
No se realizaban las pruebas necesarias durante el desarrollo del producto. Solamente cuando los componentes o servicios de presentación eran ensamblados y desplegados se realizaban pruebas al software, en las cuales se detectaban errores unitarios, de integración y diseño que podían haberse detectado con anterioridad.
No se confeccionó un portafolio de servicios. Durante el desarrollo del software no se tenía una idea clara del estado de los servicios en su ciclo de vida y para los arquitectos era muy engorroso identificar las dependencias entre servicios y los componentes de la solución.
Estas deficiencias provocan retrasos en el desarrollo de aplicaciones compuestas. En muchos casos se debe al desconocimiento de las actividades a realizar y de los artefactos a generar en cada una de las disciplinas por parte del equipo de desarrollo; provocando en algunos casos que los proyectos no se desarrollen de la mejor forma, debido a la falta de conocimiento y organización por parte del equipo de desarrollo.
Como centro de este trabajo se plantea el siguiente problema a resolver: ¿Cómo desarrollar aplicaciones compuestas a partir de los servicios candidatos identificados en iniciativas SOA que garantice una mejor elaboración del producto?
Por tanto se plantea como objeto de estudio los procesos de desarrollo para SOA y el campo de acción comprende los procesos de desarrollo de aplicaciones compuestas en iniciativas SOA.
El objetivo general de la investigación consiste en desarrollar un proceso de desarrollo de aplicaciones compuestas a partir de los servicios candidatos identificados en iniciativas SOA que garantice una mejor elaboración del producto.
Para darle cumplimiento al objetivo general se presentan los siguientes objetivos específicos:
Analizar las metodologías de desarrollo de software orientadas a servicios para seleccionar la metodología base para realizar el proceso de desarrollo a proponer.
Desarrollar el proceso de desarrollo de aplicaciones compuestas en una iniciativa SOA.
Yainury Peraza García – Universidad de las Ciencias Informáticas 5
Validar el proceso de desarrollo utilizando un método de expertos.
Por todo lo antes planteado la idea a defender es: si se desarrolla un proceso de desarrollo de aplicaciones compuestas a partir de los servicios candidatos identificados en iniciativas SOA entonces se garantizará una mejor elaboración del producto.
Para dar cumplimiento al objetivo general se plantean las siguientes tareas de la investigación:
Investigación de metodologías de desarrollo de software orientadas a servicios.
Selección de la metodología base que permita la extensión, para a partir de ella conformar el proceso de desarrollo para aplicaciones compuestas en una iniciativa SOA.
Descripción de los elementos presentes en la concepción de un entorno para el desarrollo de aplicaciones compuestas en una iniciativa SOA.
Descripción del proceso de desarrollo de aplicaciones compuestas para SOA.
Validación del proceso de desarrollo mediante el método Delphi.
Para el desarrollo de esta investigación se emplearon varios métodos en la búsqueda y procesamiento de la información como son:
Métodos teóricos:
Analítico sintético: Se hace uso de este método para la identificación de conceptos empleados dentro del campo de la investigación de las Arquitecturas Orientadas a Servicios, analizando documentos para la extracción de los elementos más importantes sobre el tema en cuestión.
Histórico – lógico: Este método es utilizado para conocer, con mayor profundidad los antecedentes y las tendencias actuales referidas a las metodologías de desarrollo de software orientadas a servicios, centrando la investigación en la evaluación de criterios que permitan elaborar una propuesta para el desarrollo de aplicaciones compuestas.
Métodos empíricos:
Encuesta: Este método es utilizado para encuestar a los expertos que evaluarían el proceso de desarrollo a proponer y así conocer su valoración acerca del trabajo realizado.
Yainury Peraza García – Universidad de las Ciencias Informáticas 6
Entrevista: Este método es utilizado para entrevistar a los desarrolladores de proyectos productivos de aplicaciones compuestas para notar sus deficiencias en la elaboración del software.
Métodos matemáticos:
Método Delphi: Este método es utilizado para determinar la validez y objetividad del proceso de desarrollo propuesto en la investigación.
El presente documento está estructurado en tres capítulos:
Capítulo 1: Fundamentación Teórica: Se realiza una pequeña panorámica del desarrollo alcanzado por algunas metodologías en el trabajo con SOA y las características de cada una de ellas con el objetivo de seleccionar una metodología base para el desarrollo de las aplicaciones compuestas en una iniciativa SOA.
Capítulo 2: Proceso de Desarrollo para Aplicaciones Compuestas: Se realiza la propuesta del proceso de desarrollo de aplicaciones compuestas en una iniciativa SOA. Se define y describe para cada disciplina las actividades y los artefactos que la conforman.
Capítulo 3: Validación del Proceso de Desarrollo: Se expone la validación del proceso de desarrollo propuesto a través de la aplicación del método Delphi.
Yainury Peraza García – Universidad de las Ciencias Informáticas 7 CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA
El presente capítulo hace alusión a los conceptos fundamentales referentes a la investigación. Es la base teórica para la comprensión del trabajo que se desarrolla. Se realizó una revisión de algunas de las metodologías disponibles para desarrollar sistemas de información basados en Arquitecturas Orientadas a Servicios, ofreciendo un enfoque general de los aspectos relacionados a la existencia y experiencia de estas metodologías de desarrollo brindando una pequeña descripción de cada una de ellas.
1.1 Arquitectura Orientada a Servicios (SOA).
En la actualidad no existe una definición única sobre la Arquitectura Orientada a Servicios (SOA), la misma varía de acuerdo con la empresa o consultora del sector de la TI que la emita:
Según OASIS (Organización de Estándares Abiertos Avanzados para la Informatización de la Sociedad) (10) SOA es: “un paradigma para organizar y utilizar capacidades distribuidas, funciones que pueden estar bajo el control de diferentes dominios, proporcionando un medio uniforme para ofrecer, descubrir y utilizar dichas capacidades para producir los efectos deseados para cubrir una necesidad”. (11)
Según la empresa IBM (International Business Machines) (12) la Arquitectura Orientada a Servicios es un
“Modelo de componente que interrelaciona las diferentes unidades funcionales de las aplicaciones, denominadas servicios, a través de interfaces y contratos bien definidos entre esos servicios. La interfaz se define de forma neutral, y debería ser independiente de la plataforma hardware, del sistema operativo y del lenguaje de programación utilizado. Esto permite a los servicios, construidos sobre sistemas heterogéneos, interactuar entre ellos de una manera uniforme y universal”. (13)
Para el OMG (Grupo de Gestión de Objetos) (14) una arquitectura SOA es un “estilo arquitectural para una comunidad de consumidores y proveedores de servicios para alcanzar valor mutuo, de forma que:
(15)
- Se permite a los participantes de la comunidad el trabajo conjunto con mínima dependencia tecnológica.
- Especifica los contratos a los que las organizaciones, personas y tecnologías deben adherirse para participar en la comunidad.
- Garantiza que el valor y los procesos del negocio son aportados por la comunidad.
Yainury Peraza García – Universidad de las Ciencias Informáticas 8
- Permite el uso de una gran variedad de tecnologías para facilitar las interacciones dentro de la comunidad.”
De manera general se puede definir más claramente a SOA como un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio, controlando el desarrollo de las TI. La idea que presenta SOA es construir una arquitectura en base a un gran conjunto de servicios independientes y localizables de manera transparente y agnósticos de la tecnología. Estos servicios que podrían denominarse básicos, permitirán construir servicios de mayor valor añadido mediante la composición o el engranaje de estos servicios básicos.
1.2 Aplicaciones Compuestas.
Una aplicación compuesta es una extensión del concepto mashup. Los mashups surgen con el objetivo de combinar contenido de múltiples páginas Web para crear una nueva página que usará la información combinada de una nueva forma. Una aplicación compuesta es similar, combinando información de fuentes múltiples. Para realizar una aplicación compuesta es necesario que las distintas aplicaciones se comuniquen entre sí y cuando consultemos información en una de ellas, se actualice la información en el resto. Las aplicaciones compuestas permiten reutilizar datos, reglas, lógica y procesos de negocios desde sus aplicaciones existentes. (6)
El modo de construir aplicaciones compuestas en una arquitectura SOA cambia respecto al modelo tradicional. En el nuevo paradigma las aplicaciones se construyen por medio de composición de servicios (16); aplicándose no solo a un único servicio, sino a la relación existente entre una colección de servicios teniendo como ventajas la automatización de la información de un servicio a otro, además de la creación de servicios complejos partiendo de otros servicios. Es tal la relevancia de la composición de servicios que sirve de base para las nuevas tendencias en el modelado de procesos de negocio. (17)
Actualmente se han definido dos escenarios para la composición de servicios: (18)
Orquestación de servicios web. se utiliza principalmente en procesos de negocio. En este tipo de integración un proceso central (que puede ser otro servicio web) toma el control de los diferentes servicios web y se encarga de su coordinación. Los servicios web implicados en la orquestación no
Yainury Peraza García – Universidad de las Ciencias Informáticas 9
tienen conocimiento de formar parte de dicha integración. Solamente el coordinador central conoce el objetivo que debe alcanzar el proceso.
Coreografía de servicios web:describe una colaboración entre una colección de servicios con el fin de lograr un objetivo común. Describe las interacciones en las que participan los diferentes servicios para conseguir este objetivo y las dependencias entre dichas interacciones, ocasionadas por el control de flujo, los mensajes correlacionados y restricciones de tiempo. A diferencia de la orquestación, se trata de un escenario donde no existe ningún punto de centralización o coordinador.
En una aplicación compuesta la presentación de información hacia el usuario se realiza por medio de portlets de nueva generación, que soportan acceso remoto (WSRP: Servicio Web de Portlet Remoto). Un portlet es un componente web basado en tecnología Java, administrado por un portlet contenedor, que procesa peticiones y genera contenido dinámico. Los portlets son empleados por los portales como componentes de interfaz de usuario que proveen una capa de presentación a los Sistemas de Información (19). Estos portlets, proyectan su funcionalidad para ser consumida por un portal cliente que no necesita instalar absolutamente nada del portlet remoto y que además es capaz de aplicar su estilo gráfico local.
(16)
Una aplicación compuesta es una implementación del patrón de diseño Composite View (Vista Compuesta), que describe una estructura de interfaz de usuario recursiva de vistas que contienen elementos secundarios que son vistas. (20)
SOA describe una categoría de aplicaciones compuestas de proveedor de servicios y componentes de los servicios de consumo, que separa la lógica empresarial y la transparencia de las ofertas para la ubicación de los proveedores de servicios y consumidores. El enfoque SOA le permite reemplazar o actualizar los componentes individuales en la aplicación sin afectar otros componentes o al proceso en su conjunto. (21) Una aplicación compuesta consta de módulos de acoplamiento flexible que se descubren y componen dinámicamente en tiempo de ejecución, los cuales contienen componentes visuales y no visuales que representan al sistema. Disponer de un sistema compuesto de módulos compuestos proporciona varias ventajas. Los módulos pueden agregar los datos procedentes de distintos sistemas en la misma aplicación. Además, el sistema puede evolucionar más fácilmente con el tiempo. A medida que cambien
Yainury Peraza García – Universidad de las Ciencias Informáticas 10
los requisitos del sistema se pueden agregar nuevos módulos al mismo con menos dificultades que en un sistema no modular. Los módulos existentes pueden evolucionar de forma más independiente.
Finalmente, distintos equipos pueden desarrollar, probar y mantener los módulos. (20)
1.3 Metodologías de desarrollo de software para SOA.
Un conjunto de metodologías han surgido para atender la enorme demanda de la Arquitectura Orientada a Servicios; tales como: la Arquitectura y Modelado Orientado a Servicios (SOMA), CBDI-Servicio de Arquitectura e Ingeniería (CBDI-SAE), Repeatable Quality (RQ), Framework de Arquitectura Orientada a Servicio (SOAF) y la Metodología de Thomas Erl.
1.3.1 Arquitectura y Modelado Orientado a Servicios (SOMA).
Verdadera metodología de modelado desarrollada por IBM. Define un enfoque integrado sobre el proceso de desarrollo SOA que cubre desde su concepción hasta su monitorización y mantenimiento; describiendo un conjunto de productos y tecnologías de modelado agnósticas, actividades de análisis y diseño y técnicas para construir SOA. (22)
Esta metodología especifica su alcance y los requerimientos no funcionales, como por ejemplo la calidad de servicios. Toma decisiones para su realización y crea un modelo de servicio que incluye un portfolio de servicios.
Consiste en un ciclo iterativo de refinamiento dividido en tres fases:
Identificación de servicios candidatos y flujos.
Especificación de servicios, componentes y flujos.
Realización que involucra la toma de decisiones.
En primer lugar, se define un modelo del negocio y una serie de plantillas para los distintos tipos de soluciones de integración posibles. A continuación se identifican los servicios que formarán parte de la arquitectura combinando varias fuentes: las metas de la empresa, un modelo conceptual del entorno, y los sistemas informáticos ya implantados. Posteriormente se estructurarán, racionalizarán y especificarán todos los servicios especificados en una arquitectura coherente. Puede que se haya identificado un gran número de servicios, por lo que se seleccionará el subconjunto que reporte el mayor retorno en inversión y
Yainury Peraza García – Universidad de las Ciencias Informáticas 11
se pospondrá el resto. Finalmente, se implementarán, depurarán e implantarán los servicios para ser sometidos a monitorización. (7)
SOMA toma prácticas de RUP (Proceso Unificado de Rational) para la identificación de servicios y para ver cómo los procesos de negocio son efectuados a través de la ejecución de servicios. Además permite identificar antipatrones e indica la forma de evitarlos.
La metodología se halla implementada como una serie de extensiones a RUP, y utiliza el estándar Lenguaje Unificado de Modelado (Unified Modeling Language o UML) (23) con algunas extensiones para el modelado. Ello implica una serie de ventajas y desventajas, se trata de una metodología compleja en la que se elabora un gran número de documentos intermedios y se utilizan numerosas herramientas. Por tanto, esta metodología puede no ser la mejor opción para empresas pequeñas y medianas de fabricación. Una metodología más ligera sería más efectiva en estos casos. (7)
Un proyecto que aplique la metodología SOMA, podría considerar como beneficioso, los puntos que se indican a continuación:
Define para cada fase, los posibles antipatrones y la forma de evitarlos.
Contempla los tres pasos fundamentales concernientes al desarrollo de servicios desde la identificación de servicios candidatos y flujos, selección de servicios, componentes y flujos que serán expuestos, y las decisiones acerca de cómo serán implementados.
Utiliza las buenas prácticas del análisis y diseño orientado a objetos, también UML como herramienta de modelado y UDDI (Descripción Universal, Descubrimiento e Integración) para la publicación y descubrimiento de servicios.
SOMA crea continuidad entre los negocios y las implementaciones de TI extendiendo las características de los negocios (por ejemplo, objetivo e indicadores de rendimiento claves) en el análisis TI y decisiones de arquitectura. El análisis y modelado realizado durante SOMA es agnóstico con respecto a la tecnología y el producto, establece un contexto para tomar decisiones específicas de tecnología y productos en las últimas fases del ciclo de vida. (24). Sin embargo la metodología SOMA tiene como limitación la falta de aplicación de modelado de servicios y técnicas de diseño.
Yainury Peraza García – Universidad de las Ciencias Informáticas 12
1.3.2 CBDI - Servicio de Arquitectura e Ingeniería (CBDI-SAE).
CBDI-SAE es una estrategia para la entrega y manejo de las actividades del ciclo de vida de una SOA.
Surgió a partir de la documentación de experiencias sobre arquitecturas orientadas a servicios (25). El Fórum de CBDI se encuentra actualmente desarrollando una metodología como parte de su framework de referencia para SOA.
Sus vistas son: (26)
Negocio: Esta vista se centra en analizar y comprender las necesidades del negocio, y sobre como el negocio opera en términos de metas y objetivos, organización estructural, procesos e información.
Especificación: Esta vista se centra en planear y especificar los servicios software desde una perspectiva independiente de la plataforma. Provee un medio para pensar en profundidad sobre la lógica de los servicios y su interrelación.
Implementación: Esta vista se centra en el empaquetado de los servicios en unidades de automatización, identificando interdependencias y determinando las restricciones de implementación que gobernaran el diseño interno y el despliegue de las mismas.
Despliegue: Esta vista se centra en la exploración y definición de la plataforma para la ejecución de los servicios. Permite el mapeo de la vista de implementación a unidades de automatización, construyendo una configuración optima de la plataforma.
Tecnología: Esta vista se centra en asegurarse de que las tecnologías estén en su lugar para habilitar el ciclo de vida de los servicios a todos los niveles. Desde planificación hacia especificación, diseño y ejecución hasta su retiro.
El proceso de CBDI-SAE tiene como objetivo abarcar todo el ciclo de vida de SOA, incluido el despliegue, la supervisión y las actividades de gobierno. CBDI-SAE define principalmente una arquitectura de referencia y procesos. Se propone soportar estándares de desarrollo y sugerir que las empresas vendedoras de soluciones aplicables en SOA implementen sus herramientas de acuerdo a estándares basados en meta modelos para que el trabajo a realizar sea más fácil y efectivo (27).
Modelo de referencia CBDI-SAE
Yainury Peraza García – Universidad de las Ciencias Informáticas 13
Es un framework que extiende el modelo de referencia de OASIS (28) con el objetivo de proveer una vista conceptual más detallada a un nivel profesional, que pueda simplemente ser mapeado al modelo OASIS, más una arquitectura de referencia y modelos de procesos que informen las tareas de arquitectura.
Las partes esenciales en este modelo de referencia son los procesos y las buenas prácticas, dado que proponen ser guía para la arquitectura, aprovisionamiento, ensamblado de la solución y tareas de tipo operacionales y de gobierno. También deja en claro su foco en estándares, protocolos, herramientas, patrones y la identificación de políticas y gobierno.
Los principios sobre los que se basa CBDI-SAE son: (26)
Nivel de empresa: atiende a las necesidades de la empresa en su totalidad.
Dirigido por políticas: separación de la designación de políticas de las responsabilidades del proyecto.
Basado en gobierno: asegurando que se cumplan las políticas.
Estandarización: reducción de la complejidad a través de servicios compartidos para el negocio y la infraestructura.
Abstracción: permite la agilidad entregando servicios abstractos que puedan soportar varios contextos.
Composición: soporta líneas de requerimientos del negocio específicas que reúsan e incorporan estándares del negocio y servicios tecnológicos.
Modularidad: que reduce la dependencia y por esto mismo el horizonte de cambio.
Virtualización: crea transparencia sobre los recursos subyacentes y luego la independencia de proveer y demandar decisiones del ciclo de vida y adquisiciones.
Dirigido a futuro: comprensión de las necesidades reales del negocio para la agilidad y estabilidad de ingeniería donde sea apropiado y donde sea realmente necesario.
Arquitectura inherentemente ágil: implementa una arquitectura de capas que facilita el cambio.
Basado en modelo: usa modelos de forma proactiva para manejar el alcance a los principios acordados.
Meta Modelo SOA
Contiene una definición detallada de todos los artefactos que se necesitan para gestionar el ciclo de vida completo de un servicio, de tal manera que se pueda establecer normas adecuadas, técnicas,
Yainury Peraza García – Universidad de las Ciencias Informáticas 14
herramientas y políticas que aseguren que existe una trazabilidad completa desde la perspectiva del negocio a través del servicio ejecutado. (26)
Arquitectura de Referencia
Define una arquitectura de referencia partiendo de un framework que unifique de forma cohesiva las áreas y componentes de una arquitectura empresarial convencional con los cambios que introduce SOA.
Comprende una serie de áreas que proveen una estructura de clasificación para documentar librerías o base de datos que contengan o hagan referencia a estándares, herramientas, políticas, plantillas, patrones y componentes reusables que formen la arquitectura de referencia SOA. (26)
Estructura de Proceso
Se conoce que cuenta con cuatro capas y que dentro de las mismas aparecen diferentes disciplinas en las que se desarrollan las actividades que dan solución a determinado proceso. No se cuenta con una descripción ni de las capas existentes ni de las disciplinas contenidas en dichas capas, por lo que se puede tomar como punto de partida este esqueleto y desarrollarlo para confeccionar un framework propio.
(26)
Un punto a favor es que especifica un plan de adopción SOA. Además, se basa en estándares, protocolos, herramientas, patrones, identificación de políticas y gobierno. Sin embargo, hasta el momento no se encuentran implementaciones llevadas a cabo mediante este framework que permitan determinar mejor sus beneficios y limitaciones en la práctica.
1.3.3 Repeatable Quality (RQ).
Metodología propietaria de Oracle desarrollada en sus inicios por Sun Microsystems. Está basada en roles, iterativa e incremental para el desarrollo de proyectos sobre SOA. Emplea una combinación de estándares de industria, UML y RUP y técnicas XP (Programación Extrema). Guía el ciclo de vida SOA mediante la implementación de plantillas listas para usar e implementar en todas las fases del ciclo de vida. (29)
Las iteraciones son guiadas por riesgos, diseñadas para ubicar las áreas de mayor riesgo tanto técnicas como de negocio. En cada una se entrega un componente ejecutable que será evaluado de acuerdo a los requerimientos del negocio. (29)
Yainury Peraza García – Universidad de las Ciencias Informáticas 15
Consta de cinco fases:
creación
elaboración
construcción
transición
concepción
Provee artefactos que identifican, definen y documentan el proyecto. Estos ilustran el uso de un método top-down (descendente), dirigido por el negocio. Utiliza la descomposición de arquitectura usando una solución dirigida por casos de uso de negocio para construir el framework de servicios y técnicas de análisis de reducción donde cada caso de uso puede dividirse en consumidor y servicios. (29)
Los artefactos que maneja son:
Entendimiento claro del sistema, servicios, prácticas y procesos que pueden ser mejorados.
Informe de preparación SOA, es un reporte de las oportunidades relacionadas a los servicios más significantes, reúso, posibles brechas, factores críticos de éxito y riesgos.
Recomendaciones tácticas y estratégicas y líneas guía para la adopción a SOA.
Buenas prácticas, patrones de diseño, esquemas y recomendaciones.
Podría considerarse como puntos a favor las siguientes características:
Toma buenas prácticas de metodologías como RUP y XP.
Utiliza UML como herramienta de modelado.
Impulsa el incremento en el nivel de comunicación a través de talleres tanto para personal técnico como para funcionales del negocio.
Sin embargo, una de las limitaciones que posee es que no provee suficiente información disponible y de acceso libre para analizar y profundizar de antemano sus características.
1.3.4 Framework de Arquitectura Orientada a Servicio (SOAF).
Es un Framework Orientado a Servicios desarrollado por IEEE (Instituto de Ingenieros Eléctricos y Electrónicos). Consta de cinco fases del proceso de desarrollo de software: (30)
Elicitación de información
Yainury Peraza García – Universidad de las Ciencias Informáticas 16
Identificación del servicio
Definición del servicio
Realización de servicio
Plan de trabajo y planificación
Se basa en dos tipos de actividades de modelado simultáneamente: “Para-ser” de modelado, que es el enfoque de la empresa de arriba a abajo orientado a describir los procesos de negocio, y el modelado “tal y como son”, que es el enfoque ascendente que describe cómo los procesos de negocio actuales se forman por las aplicaciones existentes. (30)
Una limitación que presenta es que no posee material disponible y de libre acceso, donde se explique en detalle éste framework. Tampoco se han encontrado casos de estudio sobre desarrollos en SOA con éste framework. (30)
1.3.5 Metodología de Thomas Erl3
La metodología de análisis y diseño orientado a servicios documentada en el libro SOA: Concepts, Tecnology and Designse se considera como la primera en ser publicada de manera independiente o neutral a los proveedores de tecnologías. Constituye una guía “paso a paso” que describe una serie de fases del ciclo de vida de una SOA: (31)
Análisis de servicios.
Diseño orientado a servicios
Desarrollo de servicios
Prueba de servicios
Despliegue de servicios
Administración de servicios Sus dos fases principales son:
análisis
diseño.
3 Es considerado uno de los pioneros de SOA. Se destaca por la enunciación de los principios de orientación a servicios que han constituido uno de los pilares para la definición de SOA. Ha escrito varios libros sobre arquitectura orientada a servicios, sus conceptos y desarrollo en la práctica.
Yainury Peraza García – Universidad de las Ciencias Informáticas 17
En la fase de análisis se identifican servicios candidatos a partir de modelos de negocio o de los sistemas legados de la empresa y luego estos servicios son realizados como servicios web en la fase de diseño.
Esta fase se realiza a partir del diseño secuencial de tres tipos básicos de servicios: servicios de entidad, servicios de aplicación y servicios de tareas. (31)
El proceso descrito por Thomas Erl resulta bastante detallado en cuanto a tareas y pasos para realizar cada actividad haciendo mención además a buenas prácticas a tener en cuenta. Provee una descripción detallada de cómo crear servicios web pero queda atado solamente a este tipo de tecnología para la realización de SOA. No define explícitamente artefactos de entrada y salida al proceso de manera que dificulta la formalización de la especificación de servicios resultante así como la información necesaria de entrada al proceso de diseño. (31)
1.4 Tabla resumen de las metodologías para SOA.
Metodo logía
Fases Características Beneficios Limitaciones
SOMA Identificación Especificación Realización
Toma prácticas de RUP.
Permite identificar antipatrones e indica la forma de evitarlos.
Elabora un gran número de documentos
intermedios y se utilizan numerosas
herramientas.
Define para cada fase, los posibles antipatrones y la forma de evitarlos.
Utiliza las buenas prácticas del análisis y diseño orientado a objetos.
Utiliza UML como
herramienta de modelado.
Falta de aplicación de modelado de servicios y técnicas de diseño.
CBDI- SAE
Negocio Especificación Implementación Despliegue Tecnología
Define principalmente una arquitectura de referencia y procesos.
Propone soportar estándares de
Especifica un plan de adopción SOA.
Como framework, se basa en estándares,
protocolos, herramientas
Hasta el momento no se encuentran implementaciones llevadas a cabo mediante este
Yainury Peraza García – Universidad de las Ciencias Informáticas 18
desarrollo basados en meta modelos.
y patrones y en la
identificación de políticas y gobierno.
framework.
RQ Creación
Elaboración Construcción Transición Concepción
Se basa en RUP, con proceso iterativo e incremental.
Guía el ciclo de vida SOA mediante la implementación de plantillas.
Provee artefactos que ilustran el uso de un método descendente, dirigido por el negocio.
Toma buenas prácticas de metodologías como RUP y XP.
Utiliza UML como
herramienta de modelado.
No provee suficiente información
disponible y de acceso libre para analizar y
profundizar de antemano sus características.
SOAF Elicitación Identificación Definición Realización Plan de trabajo y planificación
Es un Framework Orientado a Servicios desarrollado por IEEE.
Se basa en dos tipos de actividades de
modelado
simultáneamente:
“Para-ser ” y “tal y como son”
Incorpora una serie de técnicas y directrices para la identificación
sistemática de los servicios, decidir la granularidad de servicios y servicios de modelado.
No posee material disponible y de libre acceso, donde se explique en detalle éste framework.
No se han
encontrado casos de estudio sobre desarrollos en SOA con éste
Framework.
Thomas Erl
Análisis Diseño
Guía “paso a paso” que describe una serie de fases del ciclo de vida de una SOA.
Identifica servicios
Resulta bastante detallado en cuanto a tareas y pasos para realizar cada actividad haciendo mención a
No define explícitamente artefactos de entrada y salida al proceso.
Yainury Peraza García – Universidad de las Ciencias Informáticas 19
candidatos a partir de modelos de negocio.
buenas prácticas a tener en cuenta.
Dificulta la
formalización de la especificación de servicios.
Tabla 1: Tabla resumen de Metodologías para SOA
En resumen se puede constatar que de las metodologías SOA presentes en la literatura consultada solo una parte muy pequeña de ellas cubre el diseño de servicios, de estas algunas son propietarias por lo que no se tiene total disponibilidad de su contenido y el resto presenta una o varias de las siguientes deficiencias:
No disponibilidad de artefactos y roles.
Omiten o no son suficientemente explícitas con aspectos importantes en el diseño de servicios como el caso de los principios de orientación a servicios, requisitos no funcionales o atributos de calidad del servicio, diseño de mensajes de error en los servicios, etc.
Después de hacer un estudio sobre algunas de las metodologías existentes para el desarrollo de SOA, y teniendo en cuenta sus características, beneficios y limitaciones, se seleccionó la metodología CBDI-SAE como metodología base para realizar el proceso de desarrollo para aplicaciones compuestas en una iniciativa SOA; ya que ofrece de forma clara todos los términos referidos a una Arquitectura Orientada a Servicio, engloba no solo los aspectos relacionados con la tecnología sino también todo lo referente a arquitectura, procesos, gobierno, buenas prácticas y principios de SOA, además que permite la conveniencia de la arquitectura SOA desde el punto de vista del negocio, por lo que ha llegado a convertirse en un espacio líder en cuanto a metodologías y diseño SOA se refiere. Además esta propuesta consta en su estructura de procesos de varias capas, lo que hace un trabajo más organizativo y detallado.
Es decir, en las demás metodologías se hace referencia como tal al manejo de los servicios mediante las etapas definidas en cada uno de ellas, logrando como resultado final una solución SOA, pero no se detalla o especifica exactamente un proceso dedicado al desarrollo de dicha solución. Esta metodología especifica un plan de adopción SOA y como framework, se basa en estándares, protocolos, herramientas, patrones y en la identificación de políticas y gobierno; lo que es beneficioso para el trabajo con SOA y aplicaciones compuestas.
Yainury Peraza García – Universidad de las Ciencias Informáticas 20
1.5 Conclusiones parciales
En este capítulo se logró profundizar sobre diversas metodologías que hoy en día son guías en lo referente a la Arquitectura Orientada a Servicios. Se analizaron los aportes más importantes de las mismas en cuanto al desarrollo de soluciones SOA para aplicaciones compuestas. Se consideró utilizar la metodología CBDI-SAE como metodología base para realizar el proceso de desarrollo a proponer.
Yainury Peraza García – Universidad de las Ciencias Informáticas 21 CAPÍTULO 2: PROCESO DE DESARROLLO PARA APLICACIONES
COMPUESTAS
2.1 Introducción.
Después de realizarse un estudio del marco teórico conceptual de la investigación, se da paso a la solución propuesta, describiendo un proceso de desarrollo para aplicaciones compuestas en una iniciativa SOA; brindando un proceso específico por el cual el equipo de desarrollo marcará su trabajo en los diferentes proyectos productivos.
2.2 Alcance del Proceso de Desarrollo.
Este proceso de desarrollo es aplicable a cualquier proyecto que adopte una Arquitectura Orientada a Servicios, siempre y cuando se posean los servicios candidatos capturados y entregados con anterioridad a este proceso. Éste ofrece una descripción detallada de todas las actividades involucradas en las disciplinas que comprenden una aplicación compuesta. De cada una de estas actividades se especifican:
tareas, artefactos de entrada, artefactos de salida y roles necesarios para la correcta realización de las mismas.
2.3 Premisas para la aplicación del Proceso de Desarrollo.
Para la correcta aplicación del proceso de desarrollo, son necesarias las siguientes premisas:
Personal capacitado: es necesario que todos los roles involucrados en el proceso de desarrollo entiendan los principios a tener en cuenta para la aplicación del proceso, conozcan al detalle las actividades a realizar, los artefactos a generar y el papel que jugará cada uno. La preparación del personal ayudará significativamente a la correcta y rápida aplicación del proceso.
Disponibilidad de los artefactos necesarios: para comenzar la realización del proceso se contará con los artefactos: Inventario de servicios candidatos y Modelo de servicios candidatos. Ambos artefactos se obtienen de la determinación de los procesos a analizar, como parte del proyecto, y se descomponen de forma iterativa obteniéndose servicios candidatos como tentativas futuras de servicios de software. (32)
Yainury Peraza García – Universidad de las Ciencias Informáticas 22
Infraestructura: es necesario contar con la adecuada infraestructura tecnológica que requiere el desarrollo de aplicaciones compuestas. Se hace necesaria una infraestructura compleja adecuándose a los principios de reusabilidad, bajo acoplamiento, alta disponibilidad y seguridad de los servicios. (33)
Cultura organizacional: para lograr el éxito del proceso es necesario que exista un buen trabajo en equipo, donde cada rol mantenga una buena comunicación con el resto del equipo de desarrollo, facilitando el acceso a la información.
2.4 Descripción del Proceso de Desarrollo.
Este proceso está compuesto por cuatro fases dentro de las cuales forman parte un grupo de disciplinas que son las encargadas de llevar a cabo todo el desarrollo de las actividades, además estas son separadas por tres capas para lograr así un mayor rendimiento y una mejor organización del trabajo.
Figura 1: Representación del Proceso de Desarrollo
Yainury Peraza García – Universidad de las Ciencias Informáticas 23
2.5 Fases.
Las fases permiten mejorar el planeamiento, ejecución y control del proyecto, se caracterizan por la conclusión y la aprobación de uno o más artefactos entregables que servirán de entrada a la próxima fase o incluso para decidir la continuidad del proyecto. La consecución exitosa de cada fase es indispensable para poder continuar adelante.
A continuación se muestran las fases y se describe cada una de ellas: (34)
Arquitectura: Esta fase se centra en el desarrollo de una arquitectura que cumpla con las expectativas del cliente y del grupo de desarrollo, diseñando la solución que se quiere obtener al finalizar el proyecto.
Diseño: Esta etapa de diseño se basa fundamentalmente en el diseño de los componentes de la solución y de los servicios, en caso de ser necesario se rediseñan las características del negocio orientado a servicios.
Ensamblaje: En esta fase el personal enfoca su trabajo en la implementación como tal de los servicios y en todos los aspectos que tienen que ver con las Unidades de Automatización (UA), ya sean de descripción, codificación, diseño y pruebas de estas. Se genera una solución donde se garantice el cumplimiento de los requisitos así como su correcto ensamblaje.
Ejecución: Para que esta fase finalice de manera exitosa es necesario que mediante las instrucciones de despliegue se desplieguen las UA y se realicen pruebas sobre ellas.
2.6 Capas y Disciplinas.
El proceso cuenta con tres capas que dividen el trabajo, separando las disciplinas para una mayor organización, seguidamente se dará una explicación de en qué consisten y cuáles son los objetivos de dichas capas (35) y las disciplinas que forman parte de ellas.
Capa de Consumo: Es la capa donde se realizan las actividades de cara a los clientes y personal del negocio dentro de la empresa. Es de vital importancia en escenarios relacionados con la cartera de aplicaciones de racionalización, optimización de procesos o el desarrollo de nuevas aplicaciones.
Yainury Peraza García – Universidad de las Ciencias Informáticas 24
Las disciplinas dentro de esta capa trabajan de forma progresiva e iterativamente determinando el diseño de la arquitectura de negocio establecida en la empresa, y el modelo de la información contenida en ella.
Además especifica las soluciones de negocio a ser construidas usando servicios.
Engloba las siguientes disciplinas:
Disciplina de Arquitectura y diseño de las soluciones: Se encarga de desarrollar la arquitectura de referencia de las soluciones de forma que cumpla con las especificaciones del cliente y del equipo de desarrollo.
Disciplina de Aprovisionamiento de la solución: Se encarga de especificar la forma de uso de las aplicaciones, así como su diseño de bajo nivel y su integración con el resto de las aplicaciones como un todo.
Disciplina de ensamblaje de las soluciones: Esta disciplina de encarga de la codificación y prueba de las soluciones basadas en el uso de los servicios.
Capa de Provisión: En esta capa se ubican las disciplinas directamente relacionadas con el diseño de la arquitectura de servicios, la especificación de los bloques de construcción de SOA, el diseño, implementación y prueba de los servicios. Así como la gestión del portafolio de servicios y las aplicaciones legadas.
Disciplina de Arquitectura y Diseño Orientados a Servicios: Esta disciplina es la que permite realizar un mapeo de la arquitectura de referencia a las especificaciones concretas de la empresa obtenidas a partir de la captura de los requerimientos del negocio. Prepara y evoluciona el Plan del Portafolio de servicios para el proyecto.
Disciplina de Transición de los Sistemas Legados: Es la disciplina encargada de crear un plan de transición de los sistemas legados, que permite adentrarlos en la visión orientada a servicios provista por la arquitectura de referencia.
Disciplina de Especificación y Diseño de Servicios: Es la disciplina encargada de tomar los servicios provenientes de la disciplina Arquitectura y Diseño Orientados a Servicios y formalizar su especificación y diseño, certificándolos como mecanismo de liberación de los mismos para su implementación y uso en las aplicaciones a desarrollar en el negocio.
Disciplina de Implementación de los Servicios: Es la disciplina encargada de diseñar, implementar y probar las unidades de automatización requeridas para realizar los servicios.
Yainury Peraza García – Universidad de las Ciencias Informáticas 25
Capa de Habilitación: En esta capa se despliegan los componentes de la solución y los servicios, garantizando un correcto despliegue de los mismos.
Disciplina de Despliegue de las Soluciones y Servicios: se encarga del despliegue de las soluciones y servicios en sus ambientes de despliegue de acuerdo con sus especificaciones y requerimientos de diseño.
2.7 Roles.
Los roles son una definición abstracta que especifican el comportamiento y las responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempeñar diversos roles, así como un mismo rol puede ser representado por varias personas. Sus responsabilidades abarcan tanto el llevar a cabo un conjunto de actividades como responder por la elaboración de un conjunto de artefactos. Además describen cómo los individuos deberán comportarse en el contexto de un proyecto. A continuación se muestra la propuesta de roles a utilizar.
Jefe de Proyecto: Responsable del equipo del proyecto. Define y controla el plan del proyecto.
Determina la estructura de trabajo, organiza y gestiona los roles necesarios. Traza estrategias de trabajo. Monitoriza el trabajo del equipo.
Diseñador de Servicios: Ayuda al arquitecto de servicio a definir el modelo de la SOA. Crea el diseño detallado de los servicios a partir de ese modelo para que los desarrolladores lo implementen. Define los contratos de interfaces de los servicios (WSDL: Lenguaje de Descripción de Servicio Web). Define los esquemas de los mensajes que se intercambian (entrada y salida).
Arquitecto de Servicios: Responsable del modelo de servicios, o sea de qué elementos funcionales existirán en la SOA, sus relaciones y coherencia dentro de la arquitectura. Gestiona la arquitectura de servicios de negocio. Maximiza las oportunidades de reutilización. Mantiene la consistencia y coherencia del modelo de servicios.
Desarrollador de Servicios: Es el encargado de realizar la implementación de orquestación de servicios y procesos. Desarrolla los servicios (implementa lógica del servicio). Desarrolla los módulos cliente que consumen servicios. Asegura que los servicios están ajustados a los estándares y buenas prácticas. Implementa las interfaces de servicio (WSDL) definidas por el rol
“Diseñador de Servicios”. Se encarga de la integración de los sistemas operacionales y la documentación de Código; así como también de las pruebas pertinentes a los servicios.
Yainury Peraza García – Universidad de las Ciencias Informáticas 26
Arquitecto SOA: Define tanto la infraestructura tecnológica como los modelos técnicos con impacto en toda la compañía, comunes a varias aplicaciones. Mediador entre negocio y tecnología.
Más que de la estructura del sistema, se preocupa de la integración con los otros sistemas o con los componentes existentes. Traduce desde conceptos y componentes de negocio en componentes y conceptos TI. Asegura que los “Desarrolladores de Servicios” no sobreexpongan funcionalidades como servicios (cualquier cosa se puede publicar como Web Service). Encargado del modelo de proceso integrado (con definición de los componentes TI asociados), y del modelo de los servicios.
Diseñador de Aplicaciones Compuestas: Responsable de diseñar los componentes de la solución ya definidos con anterioridad. Una vez diseñados los componentes es el encargado de especificar cada componente de una forma más detallada, es decir, una descripción formal de cada uno de ellos, para que posteriormente los desarrolladores de aplicaciones compuestas implementen esta solución. Además, es el que le realiza el diseño a la lógica interna de dichos componentes.
Desarrollador de Aplicaciones Compuestas: Responsable de implementar cada uno de los componentes de la solución así como la lógica interna de los mismos según el diseño especificado en el modelo de componentes. Realiza los primeros planes de prueba y somete al sistema a dicho plan. Realiza las correcciones que sean oportunas.
2.8 Artefactos de entrada al Proceso de Desarrollo.
Inventario de servicios candidatos: Documento que contiene el nombre del servicio, clasificación según la taxonomía, nombre de las operaciones que posee, breve descripción de la lógica asociada de la operación, descripción textual y formato de la información de entrada y salida, y caso de uso al que pertenece cada operación.
Modelo de servicios candidatos: Se representan los servicios y los casos de uso que pertenecen a los procesos de consumo y sus relaciones, los servicios que pertenecen a los procesos de larga y corta duración y sus relaciones, los servicios que pertenecen a actividades humanas y sus relaciones, y las actividades automatizadas y sus relaciones.
2.9 Descripción de artefactos del Proceso de Desarrollo.
Yainury Peraza García – Universidad de las Ciencias Informáticas 27
• Arquitectura de la solución: Este artefacto contiene los procesos que comprenden la solución donde se muestre gráficamente el funcionamiento del proceso de acorde al entorno de negocio y a su mayor por ciento de automatización, así como los servicios candidatos que responden a dichos procesos.
• Especificación y diseño de los servicios: Este artefacto contiene una serie de secciones que especifican las características del servicio a usar. Dentro de las mismas se encuentran:
Propiedades del servicio ante el negocio: se describe el propósito del servicio, el dominio al que pertenece, sus consumidores potenciales, su estabilidad y los factores críticos de éxito que posee.
Propiedades técnicas: se describe el dominio, el propietario técnico del servicio, las operaciones que realiza y los servicios que consume.
Calidad de servicio: que define los requerimientos de desempeño y seguridad.
Cumplimiento de las normas: define los estándares que el servicio debe seguir o son utilizados.
Especificación de operaciones: donde se especifica el tipo de operaciones a realizar con el servicio.
Contrato de servicio: contiene el archivo WSDL del servicio.
• Identificación de componentes: Documento con el nombre de cada componente identificado a partir de la arquitectura de la solución. Los componentes estarán ordenados de más a menos complejos y numerados por el sistema decimal. Se especificará además cuáles son los componentes claves dentro de la solución. Hay que tener en cuenta como consideración clave para este artefacto que se debe mantener el orden de complejidad de los componentes.
• Modelo de componentes: Elaborado a partir de la definición y el ordenamiento de los componentes. Contiene el diseño de todos los componentes presentes en la solución representando específicamente los servicios que provee o necesita cada uno. Hay que tener en cuenta como consideración clave que se tiene que mantener el orden especificado en la definición de los componentes.
• Especificación de los componentes: Elaborado a partir de la definición, el ordenamiento y del diseño realizado a los componentes. Contiene para cada componente una especificación donde se define: nombre, descripción, tipo, nombre de servicios que provee, descripción de los servicios y las funciones que provee, nombre de los servicios que necesita así como descripción de los servicios que consume.
