Universidad Simón Bolívar Decanato de Estudios de Postgrado Maestría en Ingeniería de Sistemas

Transcripción

1 Universidad Simón Bolívar Decanato de Estudios de Postgrado Maestría en Ingeniería de Sistemas MODELO DE ESPECIFICACIÓN DE CALIDAD PARA LA ARQUITECTURA DE WEB SERVICES Trabajo de Grado presentado a la Universidad Simón Bolívar por Rafael Ramón Alvarado Torres Como requisito parcial para optar al grado de Magíster en Ingeniería de Sistemas Realizado con la tutoría de la Profesora María Angélica Pérez de Ovalles Mayo 2006

2 i

3 ii

4 iii RESUMEN Los Web Services representan un recurso de información que puede ser accedido sobre la Web por otra aplicación, y se comunican usando protocolos estándares de Internet (Thomas, 2003). Dado al crecimiento que ha presentado la implementación de Web Services en los procesos de negocios y considerando a la Arquitectura de Web Services (WSA) como un producto intermedio del proceso de desarrollo de software que incide directamente en la calidad del producto final; se hace necesario estudiar los componentes claves de la WSA con la finalidad de minimizar riesgos y garantizar una WSA que propicie calidad. En este sentido, la investigación que se plantea en el siguiente trabajo, propone un modelo de especificación de la calidad para la arquitectura de Web Services. Para tal fin, se siguieron los pasos del Framework Metodológico del Laboratorio de Investigación de Sistemas de Información (LISI) (Pérez et at., 2004); el cuál se inspira en el método de Investigación Acción y utiliza la metodología DESMET para la fase de evaluación. Por otro lado, se utilizó el enfoque Objetivo-Pregunta-Métrica (GQM) de Basili et al., (1994) en apoyo para la formulación de las métricas del modelo. Gracias a este modelo, las organizaciones pueden disponer de un mecanismo confiable, que basado en el estándar ISO/IEC 9126, especifica los aspectos de calidad relevantes en su arquitectura para Web Services. En consecuencia, facilita el análisis cualitativo de las características de calidad que están presentes e identifica los puntos de sensibilidad y trade offs arquitectónicos para apoyar la toma de decisiones en fases tempranas de diseño. Al finalizar está investigación, se evidenció, con el apoyo del análisis de las decisiones arquitectónicas propuestas por algunas organizaciones desarrolladoras de software, que la arquitectura para Web Services propicia las características de calidad del software: Funcionalidad, Eficiencia, Fiabilidad, Mantenibilidad, Usabilidad y Portabilidad; determinándose que la mínima expresión de la WSA debe estar soportada sobre la arquitectura SOA con la implementación de las tecnologías estándares basadas en ML: SOAP, WSDL, UDDI. Palabras claves: web services, SOA, arquitectura de web services, modelo, calidad, ISO-9126, decisiones arquitectónicas.

5 iv ÍNDICE INTRODUCCIÓN 1-2 CAPITULO I: PLANTEAMIENTO DEL PROBLEMA Contexto del problema Objetivos de investigación 4-6 CAPITULO II: REVISIÓN BIBLIOGRÁFICA 2.1. Web Services Definición Características de los Web Services 2.2. Tecnologías Estándares etensible Markup Language (ML) Simple Object Access Protocol (SOAP) 16 Universal Description, Discovery and Integration (UDDI) Web Services Lenguaje Description (WSDL) Especificaciones Adicionales Arquitectura de los Web Services Arquitectura de Software Definición Importancia Arquitectura Orientada al Servicio (SOA) Arquitectura Básica de Web Services CAPITULO III: ANTECEDENTES Arquitectura de Web Services según IBM Arquitectura de Web Services según Microsoft 37-40

6 v 3.1. Arquitectura de Web Services según Microsoft Arquitectura de Web Services según BEA Arquitectura de Web Services según W3C CAPITULO IV: MARCO METODOLÓGICO Framework Metodológico Enfoque basado en Objetivos, Preguntas y Métricas (GQM) CAPITULO V: MODELO DE ESPECIFICACIÓN DE CALIDAD PARA LA ARQUITECTURA DE WEB SERVICES Modelo Conceptual Modelo de especificación de Calidad CAPITULO VI: APLICACIÓN DE DESMET Objetivos de la Evaluación 6.2. Metodología a seguir Análisis de Contexto Aplicación del Método DESMET CAPITULO VII: EVALUACIÓN DEL MODELO DE ESPECIFICACIÓN DE CALIDAD PARA LA ARQUITECTURA DE WEB SERVICES 7.1. Evaluación de Propuesta CAPITULO VIII: CONCLUSIONES Y RECOMENDACIONES 8.1. Conclusiones 8.2. Recomendaciones REFERENCIAS BIBLIOGRÁFICAS ANEOS (En CD)

7 vi ÍNDICE DE TABLAS Características de los Web Services 14 Resumen de los Esfuerzos de Estandarización 18 Resumen de Especificaciones para Web Services 20 Decisiones Arquitectónicas según IBM Decisiones Arquitectónicas según Microsoft Decisiones Arquitectónicas según BEA Decisiones Arquitectónicas según W3C Cuadro resumen de Arquitecturas para Web Services 47 Fases del método de investigación y acción 50 Tecnologías estándares y sus decisiones arquitectónicas 59 Decisiones Arquitectónicas de Web Services que propician características/subcaracterísticas de calidad de software Condiciones favorables presentes y no presentes en los métodos propuestos por DESMET Escala utilizada para evaluar los criterios 85 Características generales a evaluar para el modelo de especificación de calidad 85 Características específicas a evaluar para el modelo de especificación de calidad 86 Puntos de sensibilidad identificados por características de calidad 90

8 vii ÍNDICE DE FIGURAS Tecnologías Estándares para Web Services 18 Arquitectura Orientada al Servicio 28 Arquitectura Básica de Web Services 31 Arquitectura de Web Services según IBM 34 Arquitectura de Web Services según Microsoft 38 Arquitectura de Web Services según BEA 41 Arquitectura para Web Services según W3C 44 Framework Metodológico del Trabajo de Investigación 51 Niveles del enfoque GQM 54 Modelo de conceptos de la investigación 57 Relación entre los elementos de calidad 60 Árbol de calidad para la WSA basado en ISO Relación entre los elementos del modelo de especificación de calidad para la WSA 62 Relación de la especificación de calidad para la WSA y el enfoque GQM 63 Árbol de calidad mejorado para la WSA basado en ISO Proceso de aplicación de un Análisis de Características por Estudio de Caso 79 Arquitectura para Web Services de la empresa 88 Resultados de las características generales de la evaluación 92 Resultados de las características específicas de la evaluación 93

9 INTRODUCCIÓN Hoy en día las organizaciones presentan una fuerte necesidad de interoperabilidad entre sus servicios y es gracias al uso de nuevas tecnologías, como los Web Services, que estás organizaciones pueden contar con una infraestructura integrada, segura, escalable y disponible que les permite disminuir costos y compartir información de manera confiable. Los Web Services se basan en estándares y ofrecen una alternativa de software independiente de la plataforma para la integración de aplicaciones y automatización de procesos de negocio. Sin embargo, no está claro que la implementación de los Web Services este realizándose con ciertos criterios de calidad y algo que propicia fuertemente la presencia de calidad en los Web Services es su arquitectura. Así mismo, la experiencia señala que la arquitectura de software propicia algunas características de calidad (Bass et al., 1998), las cuales deben ser tomadas en cuenta desde las fases tempranas de diseño. Estas características de calidad, tales como: mantenibilidad, usabilidad, eficiencia, portabilidad, fiabilidad y funcionalidad no pueden ser especificadas directamente sobre la arquitectura. Por ello, una de las formas para especificar que características de calidad propicia la arquitectura para Web Services (WSA) es a través del modelo de calidad. En este sentido, la presente investigación propone un modelo de especificación de calidad basado en el estándar ISO/IEC 9126, para especificar la calidad en la arquitectura de Web Services, como una solución al problema que presentan las organizaciones ante la carencia de una herramienta que evalúe las características de calidad en sus arquitecturas. En este trabajo de grado se siguió el método de Investigación y Acción basado en un framework metodológico del Laboratorio de Investigación de Sistemas de Información (LISI) 1

10 Capitulo I Planteamiento del Problema y se evaluó a través de un Análisis de Características por Estudio de un Caso propuesto por la metodología DESMET. Es importante señalar que la arquitectura de Web Services (WSA) es considerada un producto intermedio dentro del desarrollo de los mismos; razón por la cual, está investigación no propone evaluar la calidad de los Web Services como producto final de software. El principal aporte de este modelo es que propone a las organizaciones desarrolladoras de software un mecanismo confiable, basado en el estándar ISO/IEC 9126 para especificar los aspectos de calidad relevantes en su arquitectura para Web Services. En consecuencia, facilita el análisis cualitativo de las características de calidad que están presentes y apoya la toma de decisiones en fases tempranas de diseño. Como logro adicional, se evaluó el modelo propuesto con el estudio de un caso, encontrándose que el mismo es pertinente, completo, adecuado, preciso en su análisis, organizado, apropiado a la audiencia, legible en sus planteamientos y consistente, entre otros. Adicional a la introducción, el trabajo de investigación está estructurado en varios capítulos como sigue: El Capitulo I, describe la problemática que motivó la realización de está investigación y la formulación de sus objetivos; el Capitulo II, presenta la revisión bibliográfica que sirvió de soporte documental para la investigación; el Capitulo III, muestra los antecedentes de las arquitecturas para Web Services, incluyendo investigaciones anteriores relacionadas con el tema en estudio y algunas propuestas de arquitecturas para Web Services disponibles en el mercado por empresas desarrolladoras de software; el Capitulo IV, presenta en detalle los pasos de la metodología utilizada para el logro de los objetivos; en el Capitulo V, se propone el modelo de especificación de calidad para la arquitectura de Web Services; el Capítulo VI, plantea la aplicación de la metodología DESMET para la selección del método de evaluación, mientras que, en el Capitulo VII es realizada la evaluación del modelo con el método seleccionado; Finalmente, el capitulo VIII muestra las conclusiones y recomendaciones de la investigación realizada. 2

11 Capitulo I Planteamiento del Problema CAPITULO I PLANTEAMIENTO DEL PROBLEMA 1.1 Contexto del problema Hoy en día, ante el exigente mercado competitivo, las empresas tienen la necesidad de mejorar sus procesos, mejorar las relaciones con sus socios y más importante aún, mejorar las relaciones con sus clientes. Es así como gracias al advenimiento de la computación distribuida y con ésta, al crecimiento acelerado de las aplicaciones vía Web, ha surgido el desarrollo de Web Services como una alternativa de integración con plataforma y lenguaje independiente para facilitar la comunicación entre aplicaciones tanto internas como externas (negocios entre empresas). En el mercado existen diversas empresas dedicadas a implementar software de Web Services; las cuáles, basadas en tecnologías estándares para la Arquitectura de Web Services, desarrollan su propia Arquitectura de Web Services e incorporan un conjunto de sus tecnologías adicionales con el fin de contribuir en la implementación de un producto que satisfaga los requerimientos funcionales y no funcionales o de calidad esperados por el cliente. Sin embargo, pueden ser muchos y variados los requerimientos funcionales y no funcionales que las organizaciones pueden esperar satisfacer con la implementación de Web Services; motivo por el cuál, las empresas desarrolladores de software que proveen estos servicios y plataformas deben conocer cuáles características de calidad propician su Arquitecturas para Web Services, a fin de ofrecerles a los clientes la implementación de un producto de software bajo criterios de calidad exigidos. 3

12 Capitulo I Planteamiento del Problema La importancia de plantear la relación entre las Arquitecturas de Web Services y las características de calidad del software tiene su fundamento en los siguientes principios (Bass et al., 2003): La arquitectura es crítica para alcanzar las características de calidad requeridas en un sistema, y estas características deberían ser diseñadas y evaluadas a un nivel arquitectónico. La arquitectura provee la base para alcanzar la calidad en fases tempranas, pero no tendrá éxito sin la debida atención a los detalles de implementación. En ese sentido, las organizaciones desarrolladoras de software no escapan al reto de la calidad, considerando además que la calidad puede ser tomada como un factor de competitividad, convirtiéndose en una propuesta de valor interesante a los clientes. Está situación ha traído como consecuencia que las empresas desarrolladoras de software, en busca de obtener mayor rentabilidad en sus negocios, aboquen sus esfuerzos en proponer nuevas tecnologías, creando su propia Arquitectura para Web Services sobre la base arquitectónica de las tecnologías estándares existentes. Si bien es cierto que está competencia debería contribuir al mejoramiento continuo de los productos desarrollados por estas organizaciones; dada la creciente complejidad de los sistemas y los costos de desarrollo, las empresas que desarrollan arquitecturas para Web Services han propiciado un mayor interés en la búsqueda de la calidad en los Web Services que faciliten la integración entre aplicaciones, preguntándose: Qué características de calidad son propiciadas por su propuesta de arquitectura para Web Services?. Cuáles son las debilidades a nivel de calidad que posee esa arquitectura?. Cómo mejorarla a fin de satisfacer las exigentes necesidades del mercado?. Ante estas interrogantes surge la iniciativa para el estudio de la presente investigación. 4

13 Capitulo I Planteamiento del Problema 1.2 Objetivos de la investigación: Objetivo General: Proponer un modelo de especificación de Calidad para la Arquitectura de Web Services. Objetivos Específicos: Establecer un marco conceptual y referencial que sirva de base para la investigación propuesta. Analizar los antecedentes de las arquitecturas de Web Services según IBM, Microsoft, BEA y W3C con la finalidad de conocer en detalle sus características y aportes más resaltantes en términos de decisiones arquitectónicas. Identificar las características de calidad presentes en las decisiones arquitectónicas para Web Services. Elaborar el árbol de calidad de la Arquitectura para Web Services basado en el modelo ISO-9126 que facilite la el análisis arquitectónico para la toma de decisiones tempranas. Evaluar el modelo de especificación de la calidad bajo un contexto previamente definido. Una vez planteados los objetivos que focalizarán la presente investigación, es necesario mencionar algunos aspectos que sirvieron de justificación a la iniciativa de proponer un modelo de especificación de la calidad para la Arquitectura de Web Services. El desarrollo de la presente investigación contribuirá a determinar las brechas o debilidades que las Arquitecturas de Web Services poseen en relación a las características de calidad del 5

14 Capitulo I Planteamiento del Problema modelo estándar ISO , pudiendo servir de base para implantar mejoras en las diversas arquitecturas propuestas hoy en día para la implementación de Web Services. Adicionalmente, facilitará a las organizaciones desarrolladoras de software la identificación de sus fortalezas en la arquitectura de Web Services relacionadas con un producto de software de calidad que satisface los requerimientos funcionales y no funcionales para el exigente mercado competitivo. En el siguiente capitulo será planteada la revisión bibliográfica que sirvió de base teórica para la investigación, abarcando tópicos referentes a Web Services, características de los Web Services, arquitectura de software, arquitectura de Web Services, entre otras. 6

15 Capitulo II Revisión Bibliográfica CAPITULO II REVISIÓN BIBLIOGRÁFICA El advenimiento de los Web Services ha surgido como alternativa para soportar la integración de aplicaciones distantes ejecutadas en ambientes heterogéneos, facilitando el intercambio de datos y otros servicios a través de la Web, independientes a su plataforma y lenguaje de programación. Hoy en día muchas de las grandes empresas desarrolladoras de software, han planteado diversos enfoques arquitectónicos para implementar Web Services que satisfagan las necesidades de sus negocios. En este sentido, y luego de una exhaustiva investigación, los avances logrados por estas organizaciones pueden ser resumidos como se muestran a continuación: IBM ha desarrollo Web Services Conceptual Architecture (WSCA 1.0) (Kreger 2001), Microsoft ha implementado el Global ML Web Services Architecture (GA) y dispone del FrameWork.NET (Deitel, 2001). SUN Microsystems ha enfocado sus esfuerzos en desarrollar SUN Open Net Environment (SUN ONE) (Sun Microsystems Inc. [SUN], 2003a) BEA Systems propone la plataforma BEA WebLogic 8.1 para la construcción de Web Services (BEA,2004) Oracle ha propuesto el Oracle Application Server Web Services (OracleAS Web Services) 10g (Oracle, 2003). 7

16 Capitulo II Revisión Bibliográfica Lo anteriormente expuesto permite inferir que existe cierta competencia entre algunas empresas desarrolladoras de software con la finalidad de ofrecer mejores tecnologías para el desarrollo e implementación de Web Services, tales como, WebSphere,.Net My Service, entre otros. Bajo este contexto, surge la necesidad de explorar algunos conceptos básicos relacionados con Web Services como parte de la revisión bibliográfica de la presente investigación. En este capitulo serán expuestos diversos enfoques arquitectónicos de los Web Services, abarcando conceptos fundamentales de la Arquitectura de Software y aspectos básicos de Web Services tales como: definición, características, beneficios, estándares y especificaciones adicionales. 2.1 Web Services En esta sección se plantean diversas definiciones de Web Services y algunas características que deben estar presentes en los diferentes enfoques arquitectónicos para el desarrollo de los mismos. De igual manera, se mencionan las funcionalidades más resaltantes provistas por los requerimientos a considerar en el desarrollo de Web Services. Así como, un conjunto de estándares que establecen los lineamientos de uso de los Web Services, y la forma de cómo estos interactúan en la integración de servicios y aplicaciones a través de la Web Definición En el mundo de hoy, para facilitar los negocios las aplicaciones usadas por las empresas requieren comunicarse e integrar datos con otras empresas de una manera más rápida y efectiva. Una de las alternativas de solución para lograr la integración de servicios a través de la Web es lo que se ha denominado Web Services. 8

17 Capitulo II Revisión Bibliográfica En este sentido, es oportuno plantear un conjunto de definiciones de Web Services desde lo más general hasta lo más específico, permitiendo concluir en una definición integral del término que facilite su comprensión y entendimiento. En primer lugar, Thomas (2003) define un Web Service como un servicio que reside en la Web. Mientras Systinet (2002a), plantea que un Web Service es una forma estándar para la comunicación de aplicaciones con otras a través de protocolos estándares de Internet. Estas definiciones generales de Web Services buscan describirlo con base a la utilidad para la cual fueron concebidos, permitiendo establecer una posible clasificación de estos conceptos bajo un Enfoque Funcional. Por otra parte, varios autores, en un nivel más detallado, conciben a los Web Services como una o varias aplicaciones que residen en la Web, donde: Un Web Service es una aplicación lógica programable y accesible usando protocolos estándares de Internet, que tiene una colección de funciones empaquetadas en una entidad simple y publicadas en la red para ser usadas por otros programas (Chaudhary et al., 2002). Un Web Service es una aplicación que provee un Web API, donde un Web API es un API que permite la comunicación entre aplicaciones usando un etensible Markup Language (ML) y la Web. Así mismo, un API soporta la comunicación de aplicaciones (Thomas, 2003). Web Services son aplicaciones ML enrutadas a programas, objetos, o bases de datos, e inclusive a funciones de negocio (Newcomer, 2002). Un Web Service es una aplicación de software accesible a través de la Web mediante un Uniform Resource Locators (URL), que es accedida por clientes usando protocolos basados tanto en ML, como HiperText Transfer Protocol (HTTP). Estos clientes acceden una aplicación Web Service a través de sus 9

18 Capitulo II Revisión Bibliográfica interfaces y conexiones, las cuáles son definidas usando artefactos ML, tales como Web Service Definition Language (WSDL) (SUN, 2003c). Un Web Services es una aplicación lógica programable que tiene una colección de funciones que son empaquetadas como una entidad simple y publicadas en la Web para uso de otros programas a través de protocolos estándares de Internet (Chaudhary et al 2002). Basado en el conjunto de definiciones anteriores, podría concebirse a los Web Services como aplicaciones lógicas programables accesibles a través de la Web, que utilizan funciones y protocolos estándares de Internet. Adicionalmente, gracias al nivel de detalle planteado en estas definiciones del término de Web Services, las mismas pueden ser clasificadas bajo un Enfoque Técnico. Dentro de este enfoque, se describe a los Web Services como programas de software que usan ML para intercambiar información con otros software vía protocolos comunes de Internet. Siguiendo esta perspectiva, un Web Service puede ser definido como una interfaz que describe una colección de operaciones disponibles en la red utilizando mensajes estándares de ML (Kreger, 2001). Por otra parte, según Sun Microsystems Inc. (2003c) para la organización Word Wide Web Consortium (W3C), los Web Services son sistemas de software identificados por un Uniform Resource Identifiers (URI), cuyas interfaces públicas y conexiones son definidas y descritas usando ML. Puede observarse como estos últimos autores, Deitel, Sun Microsystems y Kreger, coinciden en el uso de ML para el desarrollo de los Web Services, y es gracias a la presencia de ML en sus definiciones, que las mismas pueden ser concebidas dentro de un Enfoque Técnico. 10

19 Capitulo II Revisión Bibliográfica Sin embargo, para Waterhouse (2002) los Web Services son en esencia una colección de estándares y protocolos que permiten procesar requerimientos a sistemas remotos mediante una comunicación común, un lenguaje no propietario y usando protocolos de transporte (HTTP, SMTP). Así, Sleeper et al. (2001) se refiere a los Web Services como componentes de software reutilizables, de libre acoplamiento, que semánticamente encapsulan funcionalidad discreta y, son distribuidos y accesibles por programas a través de protocolos estándares de Internet. Mientras que Gunzer et at. (2002), plantea que para la WebServices.org, los Web Services son funciones encapsuladas, compactas, y de libre acoplamiento ofrecidas a través de protocolos estándares; donde: Encapsulado, significa que la implementación de la función nunca es vista desde afuera. Compactas, porque existen descripciones del comportamiento de la función disponibles al público, tanto para enlazarlas a la función como para sus parámetros de entrada y salida. Libre acoplamiento, ya que cambiando la implementación de una función no requiere cambiar la función que la invoca. De esta manera, puede mencionarse que para Sleeper et al. (2001) y Gunzer et al. (2002), los Web Services son componentes de software reutilizables que poseen funciones encapsuladas de libre acoplamiento; permitiendo considerar la clasificación de sus definiciones dentro de un Enfoque Técnico debido al nivel de especificación que emplean en las mismas. En las diversas definiciones se muestra cómo diferentes autores plantean una gama variable de conceptualizaciones que definen a los Web Services desde un enfoque 11

20 Capitulo II Revisión Bibliográfica funcional, basado en la utilidad que brindan los mismos para la integración entre aplicaciones; hasta un enfoque técnico, donde describen a los Web Services como programas o componentes con funciones encapsuladas de libre acoplamiento, que usan ML para comunicar aplicaciones e intercambiar información a través de la Web, y pueden ser identificados por un URL, y utilizados aplicando estándares y protocolos de comunicación. No obstante, todos estos autores en sus definiciones confluyen en el hecho de que los Web Services residen en la Web para prestar un servicio y utilizan protocolos estándares de comunicación. Por esta razón, para fines de esta investigación los Web Services se definen como componentes de software, reutilizables, de libre acoplamiento, disponibles en la Web para facilitar la comunicación entre aplicaciones independientes de la plataforma y del lenguaje de programación en que fueron desarrollados, siendo accedidos a través de protocolos estándares de Internet. Una vez planteada la definición de Web Services, es necesario seguir ahondando en este concepto, por lo cual es necesario plantear las características de calidad más resaltantes presentes en los mismos Características de los Web Services Existen diversas características que describen a los Web Services en su amplia definición; sin embargo, para aportes de está investigación sólo se plantean aquellas características relacionadas con los aspectos de Calidad y Arquitectura de Software. La importancia de plantear está relación tiene su fundamento en los siguientes principios (Bass et al., 2003): 1. La arquitectura es crítica para alcanzar las características de calidad requeridas en un sistema, y estas características deberían ser diseñadas y evaluadas a un nivel arquitectónico. 12

21 Capitulo II Revisión Bibliográfica 2. La arquitectura provee la base para alcanzar la calidad en fases tempranas, pero no tendrá éxito sin la debida atención a los detalles de implementación. Adicionalmente, gracias a las características de los Web Services, se logran describir ciertos elementos que facilitarán el estudio de la arquitectura de software utilizada en los Web Services. Estos elementos, tales como: libre acoplamiento, reutilización, interoperabilidad heterogénea, y el uso de estándares abiertos como HTML, ML, SOAP, UDDI, entre otros, constituirán parte de los componentes claves que deben estar presentes en los requerimientos arquitectónicos para una eficiente y efectiva implementación de los Web Services. Considerando estos elementos, en la Tabla 2.1 se encuentran resumidas las características de los Web Services que satisfacen algunos requerimientos arquitectónicos. Características de los Web Services Las aplicaciones stand-alone pueden fácilmente Requerimientos Arquitectónicos ser integradas en una arquitectura orientada al servicio por la Facilitar la integración de aplicaciones existentes implementación de un Web Services como una interfaz (IBM, 2004). Esta interfaz para el manejo de la comunicación entre aplicaciones heterogéneas es conocida por otros autores como un Web API (Thomas, 2003). Por otra parte, los Web Services permiten a los desarrolladores de aplicaciones de negocio reutilizar y reorganizar los valores de la información existente en los legacy system empresariales, fijando estándares para acceder servicios de capas intermedias y finales tales como un sistema manejador de base de datos y los monitores de transacciones, integrándolos con otras aplicaciones (SUN, 2003c). Permite a diferentes servicios distribuidos ejecutarse sobre Promover la interoperabilidad una variedad de plataformas y arquitecturas de software (SUN, 2003c). 13

22 Capitulo II Revisión Bibliográfica Características de los Web Services Gracias al uso de los métodos de comunicación basados en estándares, los Web Services son de Requerimientos Arquitectónicos Ser independientes de la plataforma plataformas independientes (Systinec, 2002a). Los Web Services soportan protocolos de Internet Garantizar compatibilidad universal estándares, los cuáles ya están residentes sobre cada sistema habilitado para acceso a la web. La mayoría de los vendedores de software preempaquetan con soporte a Web Services los sistemas que desarrollan, tanto que, pueden encontrarse soporte para los Web Services sobre cualquier plataforma, desde pequeños sistemas hasta mainframes (Thomas, 2003). Debido al libre acoplamiento de los Web Services, pueden Facilitar el mantenimiento de los realizarse cambios en un servicio o piezas en la aplicación componentes de software. sin impactar a aquellas que no están relacionadas (Rogue SW, 2004). Dado que los Web Services hacen uso de los protocolos de Propiciar el acceso a servicios en transporte Ubicuos, como HTTP, toman ventaja en la Internet infraestructura existente y permiten que la información sea solicitada y recibida en tiempo real (Rogue SW, 2004). Los Web Services representan la convergencia entre el Propiciar arquitecturas de software desarrollo de aplicaciones basadas en el servicio y la Web. orientadas al servicio En el modelo de Arquitectura Orientada al Servicio (SOA) los procesos de negocio que conforman la aplicación son separados en componentes distribuidos independientes, conocidos como servicios. Estos procesos ínter operan a través de procesos y máquinas para crear una solución al problema del negocio (Rogue SW, 2004). TABLA 2.1 Características de los Web Services FUENTE: Elaboración Propia Los requerimientos arquitectónicos de la Tabla 2.1 pueden ser tipificados en requerimientos funcionales, los cuáles están asociados a funciones específicas, tareas o comportamientos que el Web Services debe soportar; estos manejan características de calidad de funcionalidad (Jazayeri et al., 2000). Dentro de este grupo se encuentra la Integración de Aplicaciones y la Interoperabilidad. Mientras los requerimientos no 14

23 Capitulo II Revisión Bibliográfica funcionales, son las restricciones sobre atributos de las funciones o tareas de los Web Services, y están referidos a la características de calidad diferentes a la funcionalidad (Jazayeri et al., 2000), dentro de los cuales se encuentran: Independencia de la plataforma, Acceso a servicios en Internet, Compatibilidad universal, Arquitectura de software orientada al servicio, Mantenimiento de los componentes de software. La importancia de identificar y clasificar los requerimientos, en funcionales y no funcionales, se basa en que está tipificación facilita una mejor comprensión de los mismos para ser contemplados en el primer paso del desarrollo de la arquitectura de los Web Services (Jazayeri et al., 2000). Por otra parte, gracias a la evolución del acceso a Internet y a los Web Services se puede contar con tecnologías que permiten la comunicación de aplicaciones remotas basadas en estándares abiertos, las cuales buscan satisfacer algunos requerimientos arquitectónicos, tales como, la integración de aplicaciones, interoperabilidad, acceso a servicios en Internet, entre otros. Estas tecnologías constituyen los elementos esenciales en la arquitectura para Web Services y se encuentran soportadas por un conjunto de estándares ampliamente aceptados, los cuales se plantean en la próxima sección. 2.2 Tecnologías Estándares En primer lugar, es preciso definir un Estándar como documentos que contienen especificaciones técnicas u otros criterios precisos, usados consistentemente, tales como reglas, lineamientos o definición de características, los cuales permiten asegurar que, materiales, productos, procesos y servicios se adecuen a sus propósitos (International Organization for Standarization [ISO], 2005). Algunos cuerpos de estandarización, como Organization for the Advancement of Structured Information Standard (OASIS), International Organization for Standarization 15

24 Capitulo II Revisión Bibliográfica (ISO), World Wide Web Consortion (W3C), entre otros; han desarrollado estándares para un amplio rango de tecnologías. Estos estándares representan, por un consenso internacional entre expertos en tecnologías particulares, el estado del arte de los Web Services (ISO, 2005). Uno de los aspectos que hacen a los Web Services atractivos, es que están construidos sobre tecnologías estándares, las cuales tienen una amplia aceptación en la industria desarrolladora de software (Ort et al., 2002). Las tecnologías para Web Services: SOAP, WSDL y UDDI se han convertido en estándares de facto para su desarrollo (Thomas, 2003). De manera resumida, a continuación se presentan las tecnologías estándares, desarrolladas por organismos reconocidos mundialmente, que representan la base para la arquitectura de los Web Services Extensible Markup Language (ML) ML es un lenguaje simple, flexible y robusto ya que fue diseñado por W3C para transmitir mensajes a través de Internet usando protocolos estándares como HTTP (SUN, 2003d) Simple Object Access Protocol (SOAP) ML solventa la necesidad de un lenguaje común, y SOAP satisface la necesidad de un formato de mensajes común. Es un protocolo alámbrico, similar a Internet InterORB Protocol (IIOP) y Java Remote Method Protocol (JRMP), basado en texto, usa un formato de codificación de datos en ML, y HTTP/SMTP para transportar mensajes (SUN, 2003d). 16

25 Capitulo II Revisión Bibliográfica Universal Description, Discovery, and Integration (UDDI) Adicional a ML y SOAP, otra tecnología estándar que juega un importante rol en el desarrollo de los Web Services es UDDI, ya que permite a los desarrolladores y empresas registrarse para publicar, describir y descubrir Web Services en una red (Deitel et al., 2003) Web Services Description Language (WSDL) Es una tecnología estándar basada en ML, que define interfaces, datos, y tipos de mensajes de Web Services, patrones de interacción y protocolos de comunicación (Newcomer, 2003, p.16). La importancia de presentar las especificaciones básicas de las tecnologías estándares: WSDL, UDDI y SOAP, todas basadas en ML; se debe a que las mismas trabajando juntas sobre una Arquitectura Orientada al Servicio (Service Oriented Architecture-SOA) representan la forma más frecuente de implementar los Web Services. Está implementación, como se muestra en la Figura 2.1, ha sido propiciada debido a que SOA soporta la integración entre aplicaciones y sus patrones arquitectónicos permiten describir un servicio (Thomas, 2003, pp ). 17

26 Capitulo II Revisión Bibliográfica FIGURA 2.1 Tecnologías Estándares para Web Services FUENTE: (Thomas, 2003, p. 59) Igualmente, esta figura muestra la implementación de las tecnologías estándares para los Web Services, donde el WSDL, es utilizado para describir el servicio; UDDI, para publicar y descubrir el servicio y SOAP para establecer la comunicación con el servicio (Thomas, 2003, p. 59). Es preciso aclarar que estas tecnologías inicialmente no comenzaron como estándares de la industria desarrolladora de software; por el contrario, debieron atravesar por un proceso de estandarización. Los esfuerzos realizados para estandarizar estas tecnologías se resumen en la Tabla 2.2. Especificación SOAP 1.2 WSDL 2.0 UDDI 2.0 UDDI 3.0 Grupo W3C W3C OASIS OASIS Estatus Inicial Finalización estimada Propuesta Draft Recomendación W3C: Junio Junio 2003 Propuesta Draft: Agosto 2005 Recomendación W3C: Especificación Draft: Julio 2002 Especificaciones OASIS Especificación Draft: Especificaciones OASIS Julio 2006 Mayo 2003 Octubre 2002 Febrero 2005 TABLA 2.2. Resumen de Esfuerzos de Estandarización FUENTE: Adaptado de (Thomas, 2003) Al hablar de estándares, es importante indicar que a pesar de todos estos esfuerzos no se ha logrado establecer un estándar De Jure para cada tecnología de los Web Services, dado que hoy en día, el mayor reconocimiento obtenido es la consideración de ML como un estándar De facto (WRQ, 2002), siendo ML, el componente base para el resto de las tecnologías estándares de los Web Services. La importancia de usar tecnologías estándares para implementar Web Services es proveer las especificaciones de los servicios que los desarrolladores y proveedores necesitan para garantizar la interoperabilidad de los mismos. Por otro lado, dado que las tecnologías 18

27 Capitulo II Revisión Bibliográfica estándares son desarrolladas, validadas y certificadas, por las mejores prácticas de grupos expertos, su utilización en la Ingeniería del Software propicia el desarrollo de Web Services bajo ciertos criterios de calidad, tanto en la arquitectura utilizada como en los requerimientos funcionales y no funcionales que éstos soportan. A pesar de la amplia aceptación que tienen las tecnologías estándares (ML, UDDI, SOAP y WSDL) consideradas básicas en una Arquitectura de Web Services y, en su mayoría, suficientes para alcanzar los objetivos propuestos (Newcomer, 2002, p.219); son requeridas otras especificaciones adicionales para soportar necesidades de seguridad, flujo de procesos, integración Negocio-Negocio y confiabilidad de los mensajes sobre la Web. En la siguiente sección, se plantean algunas de las especificaciones adicionales que complementan una Arquitectura de Web Services. 2.3 Especificaciones Adicionales Anteriormente fueron mencionadas las tecnologías estándares en la Arquitectura de Web Services; sin embargo, dado que estas no proveen suficiente soporte para aplicaciones de negocios complejas y críticas (Newcomer, 2002, p.219), se hace necesario mencionar ciertas especificaciones que sirven de complemento en la Arquitectura de Web Services, las cuales están enfocadas principalmente en las siguientes áreas: Negocios, Seguridad, Flujos de Procesos, Transacciones, Mensajería. El uso de estas especificaciones facilita la identificación de características que satisfacen requerimientos de calidad dentro de la arquitectura de Web Services. En la Tabla 2.3 es mostrado un resumen de las especificaciones para Web servicios de acuerdo al área que soportan. 19

28 Capitulo II Revisión Bibliográfica Área de Soporte Especificación Procesos de negocios (Deitel et al., 2003.p.39) Electronic Business ML (ebml). Seguridad (Newcomer, 2002, p.226) Security Assertion Markup Language (SAML), ML Key Management Specification (KMS), Web Services Security (WS-Security), Web Services License (WS-License), Secure Sockets Layer (SSL), HTTP Secure (HTTPS) Flujos de procesos (Newcomer, 2002, p.233) Web Services Flow Language (WSFL), Web Services Conversation Language (WSCL), LANG Manejo de Transacciones ((Newcomer, 2002, p.226) Business Transaction Protocol (BTP) Mensajería (Newcomer, 2002, p.241) WS-Inspection WS-Routing WS-Referral ML Protocol (MLP) Interfaz de Usuario (Myerson, 2002) Web Services Experience Language (WSL) TABLA 2.3. Resumen de Especificaciones para Web Services FUENTE: Elaboración propia Las Especificaciones expuestas anteriormente en la Tabla 2.3 ayudan a construir una Arquitectura de Web Services capaz de soportar una amplia variedad de aplicaciones focalizadas en las áreas de seguridad, flujos de procesos, transacciones, mensajes, e interfaz de usuario. Para mayor detalle sobre las bondades que cada especificación adicional ofrece en la Arquitectura de Web Services, ver el Anexo A. Hoy en día, las organizaciones han comenzado a usar Web Services en sus negocios, razón por la cual se hace necesario considerar tecnologías adicionales dentro de su Arquitectura básica que sean capaces de: soportar seguridad en las transmisiones, definir enrutación del mensaje SOAP a través de múltiples nodos, localizar otras compañías de Web Services, determinar cómo son administradas electrónicamente las relaciones de los 20

29 Capitulo II Revisión Bibliográfica socios y las interacciones de los Web Services, y describir las posibles interfaces entre estos (Deitel et al., 2003, p.206). Es importante señalar que existen muchas otras especificaciones que contribuyen a mejorar la arquitectura de Web Services, las cuáles están enfocadas hacia diversas áreas de interés. Es así como, las empresas desarrolladoras de software se esfuerzan constantemente en mejorar sus productos y servicios, creando tecnologías adaptadas a las necesidades de sus clientes (Newcomer, 2002, p219). Este esfuerzo puede evidenciarse con la creación de un grupo de arquitectos por parte de la W3C, WS-Arch, que está trabajando en la identificación de las diversas áreas que necesitan ser manejadas para desarrollar una infraestructura de Web Services completa. Ejemplos de estas áreas incluyen: mensajería asíncrona, correlación de mensaje, enrutamiento de mensajes, intercambio de mensajes entre socios, administración de sesiones, políticas, entre otros (Thomas, 2003, p. 133). Una vez concluida la revisión general de los Web Services partiendo desde su definición en los distintos enfoques: conceptual y técnico, siguiendo con sus características presentes a nivel arquitectónico, y, finalizando en las tecnologías estándares) y las especificaciones utilizadas para su desarrollo, se hace necesario profundizar en los aspectos relacionados con la Arquitectura de los Web Services, debido al rol que ésta desempeña para la calidad de los mismos. 2.4 Arquitectura de los Web Services En la presente sección se hace una revisión de los elementos conceptuales que giran entorno a la Arquitectura de Software y sirven de base para el desarrollo de los Web Services. De igual modo, son presentadas las características de la arquitectura SOA, base para el desarrollo de Web Services y finalmente, la arquitectura de Web Services (WSA). 21

30 Capitulo II Revisión Bibliográfica Arquitectura de Software Al momento de desarrollar Web Services es necesario tener en cuenta la importancia de satisfacer, cada día en mayor grado, las necesidades de interoperabilidad y comunicación entre aplicaciones (W3C, 2002). Es por ello, que surge la necesidad de crear o seleccionar una Arquitectura de Software que promueva la interoperabilidad y extensibilidad entre aplicaciones, y facilite la integración entre éstas para desempeñar operaciones más complejas. Dado el rol que representa la Arquitectura de Software en la calidad del desarrollo de Web Services, a continuación son revisados algunos de sus aspectos básicos, tales como: definición e importancia Definición Con la finalidad de conocer la Arquitectura de Software en su propia definición fueron revisadas diversas concepciones expuestas por Arquitectos e Ingenieros de Software, las cuáles se resumen a continuación. En General, Shaw y Garlan (1996) afirman que la Arquitectura de un sistema está definida en términos de una colección de componentes de software e interacciones entre estos componentes. La distribución de los componentes de software en diferentes formas da origen a patrones y estilos arquitectónicos que combinados crean una aspecto fascinante de estudio en el área de los Sistemas de Información llamado Arquitectura de Software. Así, Booch et al. (1999) definen una Arquitectura como el conjunto de decisiones significativas acerca de la organización del sistema: la selección de elementos estructurales e interfaces que conforman el sistema, además del comportamiento específico de cada elemento en las tareas colaborativas, la composición de estos 22

31 Capitulo II Revisión Bibliográfica elementos estructurales y su conducta en subsistemas más grandes, y el estilo arquitectónico que guía esta organización (elementos estructurales, sus interfaces, su colaboración y su composición). Por otra parte, Lane (1999) denomina Arquitectura de Software al estudio de la estructura a gran escala y el rendimiento de los sistemas de software. Aspectos importantes de la arquitectura de sistema incluyen la división de funciones entre módulos del sistema, el significado de la comunicación entre módulos y la representación de la información. Sin embargo, Kruchten (1999) sostiene que la Arquitectura de Software no sólo concierne a la estructura y al comportamiento, sino también a la utilización, funcionalidad, ejecución, flexibilidad, reutilización, comprensibilidad, economía, restricciones técnicas y elementos que afectan múltiples atributos de calidad (tradeoffs). Bass et al. (2003) presentan una definición más general. Ellos indican que la Arquitectura de Software de un programa o sistema es la estructura o estructuras del sistema, la cual comprende componentes de software, propiedades externamente visibles de estos componentes y las relaciones entre ellos. Los componentes pueden ser pequeñas piezas de código como módulos, programas stand-alone (autónomos), sistemas manejadores de Base de Datos (DBMS), entre otros. Por propiedades externamente visibles, estos autores se refieren a las suposiciones que un componente puede hacer de otro, tales como los servicios que este provee, características de rendimiento, manejo de fallas, uso de recursos compartidos, entre otras. El objetivo de esta definición es hacer ver que una Arquitectura de Software debería de alguna forma abstracta presentar suficiente información del sistema que 23

32 Capitulo II Revisión Bibliográfica sirva de soporte para análisis, toma de decisiones o reducción de riesgo (Bass et al., 2003, p.21). En la definición de Arquitectura presentada por (Bass et al., 2003, p.21), se muestra en evidencia las siguientes implicaciones: La Arquitectura define componentes. La Arquitectura comprende información acerca de cómo cada componente interactúa con otros. Esto significa que la Arquitectura específicamente omite información interna del componente que no pertenezca a su conducta. Los sistemas pueden estar conformados por más de una estructura y ninguna estructura puede irrefutablemente ser considerada como la Arquitectura. La definición no especifica qué son los componentes arquitectónicos y sus interrelaciones, ya que un componente de software puede ser un objeto, un proceso, una librería, una base de datos y más. La definición implica que cada sistema de software tiene una Arquitectura, debido a que cada sistema puede ser mostrado como una composición de componentes y relaciones entre ellos. El comportamiento de cada componente es parte de la Arquitectura, de hecho ese comportamiento puede ser observado o discernido desde el punto de vista de otro componente; esto permite a los componentes interactuar con otros componentes, los cuáles obviamente, también forman parte de la arquitectura. De las definiciones anteriores puede notarse como los autores convergen en que la Arquitectura de un sistema se refiere a la organización y estructura interna conformada por un conjunto de componentes de software que se relacionan, trabajan en conjunto, y exponen interfaces de comunicación. Adicionalmente, se puede extender la definición de Arquitectura del Software considerando que la misma permite determinar restricciones de implementación, e identificar 24

33 Capitulo II Revisión Bibliográfica características de calidad en conjunto con los requerimientos funcionales que el sistema debe soportar. Sin embargo, dada la diversidad de los detalles expuestos, se percibe que el concepto de la Arquitectura de Software está aún en crecimiento, razón por la cual puede definirse como un área inmadura dentro del desarrollo de software. Este auge de la Arquitectura de Software se debe en gran medida a su aporte para propiciar la calidad en el desarrollo de software, aspecto importante para el éxito en un exigente mundo de negocios. No obstante, es importante señalar que la calidad no es completamente una función del diseño arquitectónico; para asegurarla, una buena arquitectura es necesaria, pero no suficiente (Bass et al., 2003, p.31). En la siguiente sección se plantean en mayor detalle aquellos aspectos que dan importancia a la Arquitectura de Software Importancia A menudo las personas hacen analogías con la palabra Arquitectura. Comúnmente la Arquitectura se asocia con estructura física (edificios, calles, hardware) y disposición física. Por tal razón, un arquitecto debería diseñar construcciones que provean accesibilidad, estética, iluminación, mantenimiento, entre otros elementos. De este modo un Ingeniero de Software debería diseñar una Arquitectura que proporcione concurrencia, portabilidad, aceptación de cambios, usabilidad, seguridad, y algún otro factor que cubra otras necesidades de los usuarios (Bass et al., 2003). Fundamentalmente la importancia de la Arquitectura de Software radica en tres razones: a. Comunicación entre personas involucradas con el sistema: la Arquitectura de software representa comúnmente un alto nivel de abstracción de un sistema por tanto las personas involucradas en los sistemas (cliente, usuario, gerente de 25

34 Capitulo II Revisión Bibliográfica proyecto, desarrolladores, entre otros) pueden usar ésta como base para crear entendimiento mutuo, formar consenso y comunicarse uno con otro. b. Tempranas decisiones de diseño: La arquitectura de software representa la manifestación de decisiones tempranas de diseño acerca del sistema, permitiendo analizar al sistema antes de ser construido, revisando cómo será su desarrollo, configuración y mantenimiento. Bass et al. (2003), señalan que una Arquitectura define restricciones en la implementación, dicta una estructura organizacional. c. Abstracción transferible de un sistema: una arquitectura de software constituye un modelo de cómo el sistema está estructurado y cómo sus componentes trabajan juntos, este modelo es transferible a varios sistemas; en particular, este modelo puede ser aplicado a otros sistemas que presenten requerimientos similares. De este modo la importancia de la arquitectura de software radica en la necesidad de manejar bajo un mismo contexto los requerimientos de los stakeholders para tomar decisiones de diseño oportunas que influyen tanto en la calidad como en la funcionalidad del sistema; facilitando, a su vez, la creación de modelos arquitectónicos reutilizables para sistemas con requerimientos similares y su consecuente transferencia de decisiones. Una vez revisados el término arquitectura de software y la importancia que esta tiene para el desarrollo de software, en la siguiente sección, se continua con la revisión de los aspectos arquitectónicos considerando diversos detalles relacionados con la Arquitectura Orientada al Servicio que sirve de base arquitectónica para el desarrollo de Web Services (Thomas, 2003, p.30). 26

35 Capitulo II Revisión Bibliográfica Arquitectura Orientada al Servicio (SOA) SOA es un estilo arquitectónico para sistemas distribuidos que se caracteriza por (Thelin, 2003): Estar involucrado con la comunicación de una aplicación de servicio. Ofrecer amplia escalabilidad. Permitir que el punto final de conexión de servicios decida como procesar la solicitud. Garantizar que cada servicio tenga una descripción de interfaz. Ofrecer libre acoplamiento entre el cliente y el servidor. Soportar sistemas de solicitudes/respuestas y pases de mensajes. Para Thomas (2003), la Arquitectura Orientada al Servicio describe un conjunto de componentes establecidos que ayudan a la aplicación cliente a conectarse a un servicio. Estos componentes representan mecanismos usados para describir, publicar, descubrir y comunicar servicios. Según este autor, los roles conceptuales, artefactos y operaciones de una Arquitectura Orientada al Servicio son mostrados en la Figura 2.2. FIGURA 2.2 Arquitectura Orientada al Servicio FUENTE: (Thomas, 2003) 27

36 Capitulo II Revisión Bibliográfica Los tres roles conceptuales básicos en la SOA son Proveedor del servicio, Consumidor del servicio y Administrador del servicio. Donde, el Proveedor suministra el servicio; el consumidor utiliza el servicio y el Administrador, facilita los procesos de publicación y descubrimiento. Los tres artefactos básicos en SOA son Cliente, Servicio, y Contrato de Servicio. El Cliente es el código que el consumidor del servicio usa para acceder al servicio; el Servicio es el código que provee el servicio; y el Contrato de Servicio describe el API (Application Programming Interface) que el Cliente usa para acceder el servicio. Las tres operaciones básicas en SOA son Registro, Búsqueda, y Conexión. Cuando un proveedor hace un servicio disponible, éste lo describe publicando un Contrato de Servicio que especifica su interfaz y lo registra a través de un Administrador de Servicios. Un consumidor consulta al Administrador para buscar un servicio compatible. El Administrador ofrece al Consumidor direcciones donde buscar ese Servicio junto con su Contrato. El Consumidor utiliza el Contrato para establecer la Conexión entre Cliente y Servicio (Systinet, 2002b). Para que los tres (3) roles conceptuales logren las tres (3) operaciones conceptuales, un sistema SOA debe proveer tres (3) componentes arquitectónicos básicos (Systinet, 2002b): a. Transporte: el componente de transporte representa los formatos y protocolos usados para la comunicación con el servicio. El formato de dato especifica los tipos de datos y los formatos de byte stream usados para codificar los datos del mensaje. El protocolo especifica el mecanismo utilizado para empaquetar los datos codificados dentro del mensaje. El protocolo de transferencia específica la semántica de la aplicación que controla el mensaje transferido. El protocolo de transporte ejecuta la transferencia del mensaje actual. 28

37 Capitulo II Revisión Bibliográfica b. Descripción: el componente de descripción representa el lenguaje usado para describir el servicio. La descripción provee la información necesaria para conectar el servicio. Como un mínimo, un lenguaje de descripción provee el significado para especificar el contrato del servicio, incluyendo las operaciones que ejecuta y los parámetros o formatos de mensajes que intercambia. Un lenguaje de descripción es un formato de máquina capaz de ser leído y procesado por un compilador para producir un código de comunicación, como un cliente proxy, etc. Estos fragmentos de códigos generados automatizan la conexión entre el código de la aplicación y los procesos de comunicación, aislando la aplicación de complejos middleware. c. Descubrimiento: el componente de descubrimiento representa el mecanismo usado para registrar o publicar un servicio y encontrar el servicio y su descripción. Los mecanismos de descubrimiento pueden ser usados en tiempo de compilación o de ejecución. Ellos pueden soportar conexiones estáticas o dinámicas. En otro orden de ideas, Systinet (2002b), plantea que los Web Services desde una perspectiva arquitectónica, están basados sobre los principios de diseño de un middleware para la comunicación entre aplicaciones, definiendo a estos principios de diseño como la Arquitectura Orientada al Servicio (SOA). Por otro lado, señala que previo a los Web Services, SOA ya anteriormente han servido de soporte a diversas aplicaciones middleware basadas en RPC, tales como: Common Object Request Broker Architecture (CORBA), Distributed Computing Environment (DCE), Distributed Component Object Model (DCOM) y Java Remote Method Invocation (RMI). Para fines de la presente investigación en la siguiente sección es revisada la Arquitectura de Web Services soportada sobre la Arquitectura SOA. 29

38 Capitulo II Revisión Bibliográfica Arquitectura Básica de Web Services (WSA) En secciones anteriores fueron planteadas las tecnologías estándares usadas para desarrollar Web Services, y más recientemente, la revisión de los componentes de SOA como la Arquitectura sobre la cual éstos se soportan. Para Systinet (2002b, p.3), la Arquitectura de Web Services representa la convergencia de SOA y la Web. Mientras, Stepheson (2003), señala que los Web Services manejan los mecanismos de comunicación para permitir que las funciones sean públicas, mientras SOA maneja las capas y estructura de software. Por otro lado, los tres componentes arquitectónicos funcionales básicos utilizados por SOA para lograr la operación (transporte, descripción y descubrimiento), son implementados en los Web Services usando las tecnologías estándares SOAP, WSDL, and UDDI, respectivamente. En la Figura 2.3 se muestra la Arquitectura Básica de Web Services, que no es más que, las tecnologías estándares implementadas sobre SOA. Un registro UDDI cumple el rol del Administrador del Servicio. Las operaciones de Registro y Búsqueda son implementadas usando los APIs de UDDI Editor y UDDI Búscador. Un documento WSDL describe el Contrato del Servicio, y es usado para conectar el cliente al servicio. Todas las funciones de transporte son desempeñadas usando SOAP (Systinet, 2002b). 30

39 Capitulo II Revisión Bibliográfica FIGURA 2.3 Arquitectura Básica de Web Services FUENTE: (Systinet, 2002b) Las tecnologías estándares de los Web Services trabajando juntas, implementan una extensible y liviana infraestructura basada en la Arquitectura Orientada al Servicio. Los Web Services utilizan las mejores características de ésta Arquitectura y las combinan con la Web y ML originando una Arquitectura para Web Services, que según diversos autores (W3C, 2002; Sleeper et al., 2001; IBM, 2004; Rogue SW, 2004; Systinec, 2002; Thomas, 2003; Newcomer, 2002; Sun 2003; Deitel et at., 2003) se caracteriza por estar basada en estándares y facilitar la implementación de Web Services de libre acoplamiento, autocontenidos, independientes de plataforma, reutilizables; que garanticen interoperabilidad, escalabilidad, integridad, disponibilidad y flexibilidad. Estás características de la arquitectura de Web Services referenciadas en el modelo de calidad ISO/IEC 9126 (ISO, 2001) conllevan a inferir que está arquitectura propicia las características internas de calidad de mantenibilidad, funcionalidad, fiabilidad, eficiencia, usabilidad y portabilidad. 31

40 Capitulo II Revisión Bibliográfica Por otro lado, es importante señalar, que a pesar de las ventajas ofrecidas por la Arquitectura de Web Services (WSA), fueron varias las brechas encontradas por diversas organizaciones a la hora de implementar éstos en sus negocios; razón por la cual, varias organizaciones desarrolladoras de software han dedicado esfuerzos para proponer arquitecturas con especificaciones adicionales basadas en sus plataformas que mejoren la calidad de los Web Services y les permita alcanzar un mayor posicionamiento en el mercado. En el siguiente capítulo se presentan algunas de esas propuestas de Arquitecturas para Web Services, las cuáles servirán de antecedentes y facilitarán la determinación de decisiones arquitectónicas que apoyarán la propuesta del modelo de estimación de calidad. 32

41 Capitulo III Antecedentes CAPITULO III ANTECEDENTES Después de la investigación documental fue necesario señalar que no se encontraron estudios anteriores relacionados con las especificaciones de calidad para la arquitectura de Web Services; si bien, fueron encontradas y analizadas diversas investigaciones sobre: la arquitectura de software; los requerimientos de calidad en la arquitectura de software; las características de calidad en los ambientes de desarrollo de Web Services; y algunas propuestas de arquitecturas para Web Services, ninguna planteó con precisión el tema de las características de calidad para la arquitectura de Web Services. Sin embargo, es importante mencionar el aporte que brindó la propuesta del modelo sistémico para estimación de calidad de un Web Service (MOSCA-WS) realizada por Pérez et al. (2005), los cuáles, proponen una adecuación del Modelo Sistémico de Calidad (MOSCA) aplicable a los Web Services y formulan bajo su contexto de evaluación, un conjunto de métricas para especificar la calidad de un Web Service con un enfoque sistémico; de esta manera, fueron identificadas algunas características de calidad esperadas por un Web Services como un producto de software, encontrándose además, que algunas de estas características son propiciadas por su arquitectura, tales como: interoperabilidad, seguridad, escalabilidad, adaptabilidad y estabilidad. Por otro lado, a fines de construir una base que apoye el modelo de estimación de calidad para la arquitectura de Web Services se hizo necesario analizar las decisiones arquitectónicas presentes en algunas propuestas de Arquitecturas para Web Services según IBM, Microsoft, BEA, y W3C, organizaciones con gran aceptación a nivel de internacional que facilitan la disponibilidad de sus publicaciones y avances tecnológicos. 33

42 Capitulo III Antecedentes Como aporte a una mejor comprensión de las arquitecturas para Web Services, también son mencionadas las tecnologías estándares y especificaciones adicionales propuestas por estas organizaciones en apoyo a cada capa de su modelo arquitectónico. Un mayor detalle de estas tecnologías y especificaciones adicionales para cada arquitectura, es mostrado en el Anexo A. 3.1 Arquitectura de Web Services según IBM La Arquitectura de Web Services propuesta por IBM consiste en un conjunto de capas, Figura 3.1, representadas por las tecnologías estándares (ML, WSDL, SOAP y UDDI), y por una variedad de especificaciones que han surgido a raíz de la necesidad de incorporar nuevos elementos a la arquitectura para satisfacer requerimientos no soportados por las tecnologías estándares (Newcomer, 2002, p.219). FIGURA 3.1 Arquitectura de Web Services según IBM FUENTE: Adaptado de (Kreger, 2001, p. 10) El modelo Arquitectónico para Web Services de IBM, mostrado en la Figura 3.1, muestra como base la capa de Transporte, la cual representa varios protocolos de red. Seguidamente, se encuentra un conjunto de capas que se soportan en la Arquitectura básica de Web Services (WSA), donde, el enlace SOAP entre el Cliente y el Proveedor está representado en la capa de Mensajería ML, el Contrato de servicio (WSDL) se muestra en la capa de Descripción del Servicio y, por último, tanto el registro del Proveedor como la búsqueda del Cliente (UDDI) 34

43 Capitulo III Antecedentes en el Administrador del Servicio son expuestas en las capas de Publicación y Descubrimiento del Servicio, respectivamente. Adicionalmente, IBM plantea como capas emergentes la Descripción del Servicio y la Interfaz de Usuario e incluye en su modelo las capas extendidas de Flujo del Servicio y Contrato del Servicio con la finalidad de mejorar la arquitectura de Web Services para garantizar procesos de negocios, interacciones con Workflows y describir experiencias del usuario. Por otro lado, a fin de satisfacer los requerimientos a nivel de seguridad, calidad de servicio, confiabilidad del mensaje, y gerencia en cada capa horizontal de la arquitectura propuesta, IBM muestra tres capas adicionales verticales, independiente una de otra, llamadas: gestión, calidad de servicio, y seguridad. Finalmente, una vez revisadas las capas expuestas por IBM para la arquitectura de Web Services, es importante resaltar las decisiones arquitectónicas que son consideradas en cada capa (Kreger, 2001), y relacionarlas con las tecnologías y especificaciones adicionales que fortalecen esta propuesta arquitectónica, tal como se muestra en la siguiente Tabla 3.1: Capa Tecnología / Especificación Adicional Decisión Arquitectónica Interfaz del usuario / Facilitar la descripción de las experiencias de los usuarios para WSL presentación su visualización a través de la interfaz de usuario Flujo del servicio Soportar el modelamiento de los procesos de negocios y workflows. Facilitar la descripción de cómo las comunicaciones servicios servicios y flujos son desempeñadas. WSFL Facilitar la coordinación de transacciones atómicas de corta WS-Atomic duración. Transaction Contrato del Servicio Soportar la descripción de contratos entre dos socios y su TPA interacción con respecto al servicio. Habilitar el electrónicos. uso global de información de negocios ebml Permitir la coordinación de tareas múltiples en mensajes de WS-Coordination Web Services. 35

44 Capitulo III Capa Antecedentes Tecnología / Especificación Adicional Decisión Arquitectónica Descubrimiento del servicio Permitir el descubrimiento de Web Services. UDDI Descripción del servicio emergente Facilitar la descripción de características no operacionales de WSEL, IDL los endpoints, tales como características de calidad de servicio. Publicación del servicio Facilitar la publicación del Web Services. UDDI Garantizar interoperabilidad del Web Services. Garantizar una descripción del servicio estándar. Descripción del servicio WSDL Permitir la identificación de que mensajes son requeridos entre el proveedor del servicio y el solicitante del servicio. Facilitar la inspección de Web Services disponibles y conocer WSIL que servicios estos ofrecen. Proveer seguridad para la capa de mensajes ML, agregando WS-Security señales de seguridad y servicios de autenticación. Proveer la definición de información para la comunicación de Web Services. SOAP, ML Garantizar la interoperabilidad del mensaje. Mensajería ML Facilitar la interacción notificaciones o eventos. entre Web Services Garantizar la entrega del mensaje del Web Services. usando WS-Eventing WS-Realible messaging Proveer mecanismos para la transmisión de Web Services y WS-Addressing mensajes de manera neutral a través de la red. Transporte Garantizar interoperabilidad en el transporte. Soportar un ambiente ubicuos para Web Services. Gestión HTTP, SMTP; MQ Soportar descripciones de API s y esquemas para facilitar la WS-Provisioning interoperabilidad entre sistemas aprovisionadores usando Web Services. Facilitar la gestión y control de los componentes del Web WS-Manageability Services. Calidad de servicio Permitir la inclusión de semántica adicional en la descripción WSDL del servicio, tales como, calidad de servicio, costos, propiedades de seguridad. 36

45 Capitulo III Antecedentes Capa Decisión Arquitectónica Tecnología / Especificación Adicional Describir mejoras en el mensaje SOAP para proveer integridad, WS-Security autenticación y confidencialidad. Soportar mecanismos de seguridad en el transporte del HTTPS, SSL, mensaje. IPSec Definir extensiones de seguridad para proveer comunicaciones WS-Secure seguras. Conversation Seguridad Facilitar la implementación de políticas de aserciones para la WS-Security seguridad del Web Services. Policy Facilitar el intercambio de información sobre autenticación y SAML autorización. Definir mecanismos que permitan establecer escenarios de WS-Federation confianza entre varias organizaciones que participan en un Web Services. Definir primitivas adicionales y extensiones para intercambio WS-Trust de señales de seguridad en el Web Services. Definir políticas de seguridad de un Web Services. WS-Policy TABLA 3.1 Decisiones Arquitectónicas según IBM FUENTE: Elaboración propia En la siguiente sesión se realiza una revisión de la Arquitectura para Web Services propuesta por otra de las empresas desarrolladoras de Software; como lo es Microsoft Corporation. 3.2 Arquitectura para Web Services según Microsoft La arquitectura propuesta por Microsoft toma como base los estándares de la arquitectura básica de Web Services (SOAP, ML, WSDL y UDDI), garantizando un alto nivel de interoperabilidad a través de plataformas, lenguajes de programación e integración de aplicaciones (Microsoft, 2002, p. 1). La contribución de esta arquitectura es proveer capacidades adicionales a los componentes básicos de Web Services ML, cuyas especificaciones son construidas sobre las tecnologías estándares de Web Services ML (Microsoft, 2001, p. 1). Esta arquitectura se resume en la Figura 3.2, la cual provee una agrupación de los componentes de Web Services publicados por Microsoft. (Ferguson et. al, 2003). 37

46 Capitulo III Antecedentes FIGURA 3.2 Arquitectura de Web Services según Microsoft FUENTE: Adaptado de (Ferguson et. al, 2003) El modelo Arquitectónico para Web Services de Microsoft, mostrado en la Figura 3.2, muestra como base la capa de Transporte, la cual representa varios protocolos de red. Seguidamente, se encuentra un conjunto de capas que se soportan en la Arquitectura básica de Web Services (WSA), donde, el enlace SOAP entre el Cliente y el Proveedor está representado en la capa de Mensajería, el Contrato de Servicio (WSDL) y tanto el registro del Proveedor como la búsqueda del Cliente (UDDI) en el Administrador del Servicio están expuestas en la capa de Interfaz del Servicio. De manera similar a IBM, Microsoft aporta capas arquitectónicas adicionales en la arquitectura de Web Services a fin de proveer capacidades de disponibilidad, confiabilidad y seguridad, a través de sus capas emergentes: Políticas, Mensajería emergente, Descripción emergente, Módulos de SOAP, y Confiabilidad del mensaje. Mientras que a través de sus capas extendidas: transacciones, y composición del servicio, busca satisfacer necesidades de negocio específicas. 38

47 Capitulo III Antecedentes En resumen, Microsoft enfocado en promover su Arquitectura para Web Services ante las necesidades del mundo real, propone un conjunto de decisiones arquitectónicas (Ferguson et al, 2003), las cuáles son mostradas en la Tabla 3.2 junto a sus tecnologías y especificaciones adicionales para cada una de las capas de la arquitectura propuesta. Capa Composición del servicio Decisión Arquitectónica Tecnología / Especificación Adicional Facilitar la composición de servicios para implementar BPEL4WS soluciones de negocios integradas. Soportar la descripción de transacciones en un Web Services. WS-Transaction Permitir la coordinación de tareas múltiples en mensajes de WSWeb Services. Coordination Transacciones Confiabilidad del mensaje Facilitar la coordinación de transacciones atómicas de corta WS-Atomic duración. Transaction Facilitar la coordinación de transacciones de larga duración. WS-Business Activity Garantizar la entrega del mensaje del Web Services. WS-Reability Message Permitir la definición de mecanismos para establecer WS-Federation escenarios de confianza entre varias organizaciones que participan en un Web Services. Facilitar el encapsulamiento de datos binarios en un mensaje. DIME Permitir empaquetar mensajes binarios a un mensaje SOAP. WS-Attachment Describir mejoras en el mensaje SOAP para proveer integridad, WS-Security autenticación y confidencialidad. Módulos de SOAP Soportar la definición de diversos formatos de licencias, WS-License incluyendo certificados.509 y tickets Kerberos que pueden ser usados como credenciales de seguridad. Soportar la definición de relaciones de confidencialidad, basada WS-Trust en el concepto de Security Tokens Services (STS) Garantizar soporte para acordar sesiones o comunicaciones con WS-Secure claves específicas para firmar y encriptar información. Conversation Proveer mecanismos de direccionamiento para enrutamiento WS-Rounting del mensaje SOAP. Permitir el enrutamiento entre los nodos SOAP sobre una ruta WS-Referral de un mensaje que debe ser configurado dinámicamente Mensajería Emergente Proveer mecanismos para la transmisión de Web Services y WS-Addressing mensajes de manera neutral a través de la red. Descripción Emergente Capacidad para permitir a los Web Services definir WS-Metadata mecanismos que describan lo que otros endpoints necesitan Exchange conocer para interactuar con estos. 39

48 Capitulo III Capa Antecedentes Decisión Arquitectónica Tecnología / Especificación Adicional Descripción Emergente Facilitar la inspección de Web Services disponibles y conocer WS-Inspection que servicios estos ofrecen. Políticas Definir políticas de seguridad de un Web Services. WS-Policy Permitir la descripción de secuencias para preguntar por ítems WSdesde una lista de datos que es útil para un Web Services. Enumeration Mensajería Proveer la definición de información para la comunicación de Web Services. SOAP, ML Garantizar la interoperabilidad del mensaje. Garantizar interoperabilidad del Web Services. Garantizar una descripción del servicio estándar. WSDL, SD Permitir la identificación de que mensajes son requeridos entre Interfaz del Servicio el proveedor del servicio y el solicitante del servicio. Capacidad para definir un protocolo de múltiples WS-Discovery descubrimientos simultáneos para localizar Web Services. Transporte Permitir la publicación y descubrimiento de Web Services. UDDI Garantizar interoperabilidad en el transporte. HTTP, HTTPS, SMTP Soportar un ambiente ubicuos para Web Services. TABLA 3.2 Decisiones Arquitectónicas según Microsoft FUENTE: Elaboración propia Continuando con la revisión de antecedentes que apoyan esta investigación, seguidamente se presenta una revisión de la Arquitectura para Web Services propuesta por BEA Systems. 3.3 Arquitectura para Web Services según BEA Systems BEA Systems espera proveer una sólida arquitectura para Web Services que satisfaga las necesidades de las aplicaciones y procesos de negocio de los clientes, apoyándose en las tecnologías estándares y más recientemente en las especificaciones WS-Security y WSAddressing de las cuáles confía en su futura estandarización (Orchard, 2003, p.4). La estructura de capas que presenta la propuesta de BEA Systems para la Arquitectura de Web Services se muestra en la Figura 3.3 (Onchard, 2003, p 4). 40

49 Capitulo III Antecedentes FIGURA 3.3 Arquitectura de Web Services según BEA FUENTE: Adaptado de (Onchard, 2003, p. 4) El modelo Arquitectónico para Web Services de BEA, mostrado en la Figura 3.3, muestra como base la capa de Transporte, la cual representa varios protocolos de red. Seguidamente, se encuentra un conjunto de capas que se soportan en la Arquitectura básica de Web Services (WSA), donde, el enlace SOAP entre el Cliente y el Proveedor está representado en la capa de Entrega del Servicio, el Contrato de Servicio (WSDL) se muestra en la capa de Descripción del Servicio y tanto el registro del Proveedor como la búsqueda del Cliente (UDDI) en el Administrador del Servicio están expuestas en la capa de Descubrimiento del Servicio. De manera similar a otras empresas de software, BEA aporta decisiones arquitectónicas adicionales en la arquitectura de Web Services a fin de facilitar a los programadores de aplicaciones el desarrollo, prueba e implantación de Web Services interoperables, usando objetos de negocios fuertemente granulados (coarse-grained), integrados con libre acoplamiento y una comunicación de mensajería asíncrona (BEA, 2003, p.4). Estas decisiones arquitectónicas adicionales son mostradas con la incorporación en su modelo de las capas Emergentes: Descubrimiento, Descripción, y Entrega; cuyos esfuerzos están enfocados hacia las áreas de mensajería, políticas y localización de Web Services; y las capas 41

50 Capitulo III Antecedentes Extendidas: Descripción Extendida, y Entrega Extendida, relacionadas con transacciones y procesos de negocio. En este sentido, Onchard (2003) plantea el conjunto de decisiones arquitectónicas que BEA ofrece para el mejoramiento de la Arquitectura de los Web Services. En la Tabla 3.3 son mostradas esas decisiones junto a sus tecnologías y especificaciones adicionales por cada capa. Capa Descripción extendida Decisión Arquitectónica Tecnología / Especificación Adicional Facilitar la composición de servicios para implementar BPEL4WS soluciones de negocios integradas. Soportar la descripción de transacciones en un Web Services. WS-Transaction Entrega extendida Permitir la coordinación de tareas múltiples en mensajes de WSWeb Services. Coordination Descubrimiento emergente Permitir a los Web Services definir mecanismos que describan WS-Metadata lo que otros endpoints necesitan conocer para interactuar con Exchange estos. Definir políticas de seguridad de un Web Services. WS-Policy Describir un modelo general para detallar y comunicar las WS-Policy políticas del Web Services sobre el WS-Policy. Framework Descripción emergente Facilitar la definición de aseveraciones que pueden ser WS-Policy especificadas en una política. Assertions Soportar especificaciones de cómo asociar políticas de WS-Policy aseveración con elementos ML, definiciones tipo WSDL y Attachment entradas de UDDI. Proveer mecanismos para la transmisión de Web Services y WS-Addressing mensajes de manera neutral a través de la red. Garantizar la entrega del mensaje del Web Services. Entrega emergente WS-Reliable Messaging Describir mejoras en el mensaje SOAP para proveer integridad, WS-Security autenticación y confidencialidad. Facilitar la implementación de políticas de aserciones para la WS-Security seguridad del Web Services. Policy Soportar la definición de relaciones de confidencialidad, basada WS-Trust en el concepto de Security Tokens Services (STS) Garantizar soporte para acordar sesiones o comunicaciones con WS-Secure claves específicas para firmar y encriptar información. Conversation Descubrimiento del servicio Permitir la publicación y descubrimiento de Web Services. UDDI 42

51 Capitulo III Capa Descripción del servicio Descripción del servicio Antecedentes Decisión Arquitectónica Tecnología / Especificación Adicional Garantizar interoperabilidad del Web Services. Garantizar una descripción del servicio estándar. WSDL Permitir la identificación de qué mensajes son requeridos entre el proveedor del servicio y el solicitante del servicio. Entrega del servicio Proveer la definición de información para la comunicación de Web Services. SOAP Garantizar la interoperabilidad del mensaje. Transporte Garantizar interoperabilidad en el transporte. Soportar un ambiente ubicuos para Web Services. HTTP, HTTPS, SMTP TABLA 3.3 Decisiones Arquitectónicas según BEA FUENTE: Elaboración propia Continuando con la revisión de antecedentes que apoyan esta investigación, seguidamente se presenta una revisión de la Arquitectura para Web Services propuesta por W3C. 3.4 Arquitectura para Web Services según W3C La organización W3C, 2002, ha definido una referencia de la Arquitectura para Web Services denominada WSA, está referencia no intenta especificar como implementar Web Services, y tampoco impone restricciones en cómo deben ser combinados; tan solo describe tanto las características mínimas que son comunes a todos los Web Services como un número de características que son necesarias para mucho de ellos, pero no para todos (W3C, 2004, p. 6). A continuación, como se ilustra en la Figura 3.4, se explora cada rol e interacción con la finalidad de identificar las capas relevantes dentro de la arquitectura para Web Services (W3C, 2004, p. 64). 43

52 Capitulo III Antecedentes FIGURA 3.4 Arquitectura para Web Services según W3C FUENTE: Adaptado de (W3C, 2004, p. 64) El modelo Arquitectónico para Web Services propuesto por la W3C, mostrado en la Figura 3.4, muestra como base la capa de transporte, la cual representa a los protocolos de red como base a la estructura de capas. Seguidamente, se encuentra un conjunto de capas que se soportan en la Arquitectura básica de Web Services (WSA), donde, el enlace SOAP entre el Cliente y el Proveedor está representado en la capa de Mensajería del Servicio, el Contrato de Servicio (WSDL) se muestra en la capa de Descripción del Servicio y tanto el registro del Proveedor como la búsqueda del Cliente (UDDI) en el Administrador del Servicio están expuestas en la capa de Descubrimiento del Servicio. Por otro lado, W3C propone como complemento a las capas estándares un conjunto de capas emergentes que proveen información adicional para los mensajes y la invocación de Web Services, llamadas: Descubrimiento Emergente, Descripción Emergente, y Mensajería Emergente; y muestra una capa Extendida para la interacción entre Web Services llamada Descripción de Relaciones. En este modelo también se puede constatar la presencia de capas adicionales: capa de Gestión y capa de Seguridad, con las cuáles intenta implementar políticas de seguridad y gestión para Web Services a través de su arquitectura. 44

53 Capitulo III Antecedentes En base a la revisión de la arquitectura sugerida por la W3C puede concluirse que esta arquitectura, en algunas de las capas, es similar con el resto de las arquitecturas para Web Services propuesta por IBM, Microsoft y BEA Systems. Sin embargo, pudiera ser inconsistente desde las perspectivas de un cliente o usuario final, considerando que no satisface algunos requerimientos a nivel de negocios y calidad de servicio. Conscientes de está situación, la W3C (2004), plantea un conjunto de decisiones arquitectónicas que sugiere en beneficio de estandarizar la arquitectura para el desarrollo de Web Services. Estas decisiones arquitectónicas junto con sus tecnologías y especificaciones adicionales son presentadas en la Tabla 3.4. Capa Decisión Arquitectónica Tecnología / Especificación Adicional Facilitar la descripción de colaboración y coordinación entre un conjunto de Web Services. Permitir la descripción de orquestación que refleja una simple coreografía de las llamadas del servicio entre las dos partes del negocio. BPEL4WS Descripción de relaciones Facilitar la composición de servicios para implementar soluciones de negocios integradas. Soportar el establecimiento de acuerdos en la descripción del servicio y la semántica que gobernará la interacción entre ellos. Permitir definir secuencias, condiciones y colaboraciones (coreografía) en las cuáles los mensajes son intercambiados entre los participantes de un Web Services WSChoreography, WS-CDL Descubrimiento del Servicio Permitir la publicación y descubrimiento de Web Services. UDDI Descubrimiento emergente Facilitar la inspección de Web Services disponibles y conocer que servicios estos ofrecen. WS-Inspection, WSIL Garantizar interoperabilidad del Web Services. Garantizar una descripción del servicio estándar. Descripción del servicio Permitir la identificación de que mensajes son requeridos entre el proveedor del servicio y el solicitante del servicio. WSDL Definir la interfaz del servicio. Facilitar el suministro de información suficiente para describir al Web Services y su invocación. Descripción emergente Definir políticas de seguridad de un Web Services. WS-Policy Permitir el manejo de mensajes de entrada y salida en una pantalla para el usuario con el cuál se interactúa. WSDL 45

54 Capitulo III Capa Mensajería del servicio Mensajería emergente Antecedentes Decisión Arquitectónica Tecnología / Especificación Adicional Proveer la definición de información para la comunicación de Web Services. SOAP, ML Garantizar la interoperabilidad del mensaje. Permitir empaquetar mensajes binarios a un mensaje SOAP. WS-Attachment Proveer mecanismos de direccionamiento para enrutamiento del mensaje SOAP. WS-Rounting Garantizar la entrega del mensaje del Web Services. WS-Reliable Messaging Permitir la descripción de un patrón generalizado de intercambio de mensajes. WS-Exchange Patterns Soportar la descripción de transacciones en un Web Services. WS-Transaction Facilitar la transmisión de mensajes protegidos vía SSL ó TLS. WSConfidentiality Soportar el uso de firmas digitales sobre un mensaje. WS-Integrity Proveer mecanismos para especificar propiedades de entrega de WS-Message mensajes abstractas. Delivery Permitir la especificación de datos encriptados de un proceso y MLsu representación en ML. Encryption Facilitar la especificación de las reglas y sintaxis de firmas digitales en ML. Seguridad ML-Signature Soportar mecanismos de seguridad basados en ML para No propone solventar problemas de autenticación, control de acceso basado tecnologías en roles. ampliamente adoptadas Garantizar confiabilidad de datos. No propone tecnologías ampliamente adoptadas Garantizar integridad end to end del Web Services. No propone tecnologías ampliamente adoptadas Gestión Facilitar la gestión y control de los componentes del Web Services. No propone tecnologías ampliamente adoptadas Transporte Garantizar interoperabilidad en el transporte http, SMTP, FTP Soportar un ambiente ubicuos para Web Services. TABLA 3.4 Decisiones Arquitectónicas según W3C FUENTE: Elaboración propia 46

55 Capitulo III Antecedentes Luego de la revisión de las arquitecturas para Web Services propuestas por las organizaciones IBM, Microsoft, BEA Systems y W3C, se concluye que todas implementan los componentes básicos de la Arquitectura SOA sobre capas estándares con sus tecnologías ML, SOAP, WSDL, UDDI (indicadas en las Figuras 3.1, 3.2, 3.3 y 3.4 con color azul). Sin embargo, cada una a dedicado sus esfuerzos en implementar nuevas capas y especificaciones, que adicionales a las estándares, satisfagan las necesidades de negocios y solventen o disminuyen las brechas o debilidades encontradas de los Web Services principalmente en relación a las áreas de Negocio, Seguridad, Flujos de Procesos, Transacciones, Mensajería. Estas capas adicionales para su mejor apreciación fueron resaltadas en las Figuras arquitectónicas con color anaranjado para las capas emergentes y color amarillo para las capas extendidas. En la Tabla 3.5 se muestra una comparación de las capas arquitectónicas presentes en las organizaciones anteriormente revisadas. TABLA 3.5 Cuadro resumen de Arquitecturas para Web Services FUENTE: Elaboración Propia Este análisis de antecedentes permite deducir que existe cierta competencia entre algunas organizaciones desarrolladoras de software con la finalidad de ofrecer mejores arquitecturas 47

56 Capitulo III Antecedentes para el desarrollo e implantación de Web Services, permitiendo visualizar la ausencia, presencia y recurrencia de capas arquitectónicas entre estas organizaciones. También puede observarse que para cada capa y decisión arquitectónica existe un gran número de especificaciones adicionales en busca de satisfacer aspectos no garantizados por las tecnologías estándares y apoyar un área particular de los requerimientos en un Web Services. Además, es importante señalar que existen escenarios donde a pesar que estas especificaciones no son estándares, muchas de ellas están presentes para todas o casi todas las organizaciones revisadas, lo que permite inferir que estas especificaciones pudieran ser consideras tecnologías estándares en un futuro cercano. En el siguiente capitulo será presentada la metodología de investigación que sirvió de guía a las actividades realizadas para el logro de los objetivos planteados. 48

57 Capitulo IV Marco Metodológico CAPITULO IV MARCO METODOLOGICO En este capitulo se presentan las actividades que se deben ejecutar para alcanzar los objetivos planteados en esta investigación. Esas actividades siguen los lineamientos del framework metodológico de Perez et at., (2004). Posteriormente se presenta el enfoque basado en Objetivos, Preguntas y Métricas (GQM) que se utilizó como metodología para la elaboración de las métricas que forman parte del modelo de especificación de calidad para la Arquitectura de Web Services. 4.1 Framework Metodológico Para lograr el modelo de especificación de la calidad para la Arquitectura de Web Services se siguieron las actividades del Framework Metodológico del Laboratorio de Investigación de Sistemas de Información (LISI) de la Universidad Simón Bolívar; el cuál se inspira en el método de Investigación Acción y utiliza la metodología DESMET para la fase de evaluación. Los autores de la investigación acción asumen que los Sistemas de Actividad Humana no pueden ser reducidos para estudios significativos. Ellos creen que las organizaciones humanas, en un contexto donde interactúan con Tecnologías de la Información (TI), como las organizaciones objeto de estudio en esta investigación, sólo pueden ser entendidas como entidades completas (Baskerville, 1999). Susman y Evered (1978), proponen por su parte, una investigación acción, en la cual se detalla un proceso cíclico de cinco fases (Diagnosticar, Planificar la acción, Tomar la acción, Evaluar y Especificar el aprendizaje). Mientras que, Baskerville (1999) identifica la iteración de éstas cinco fases como se muestra en la Tabla 4.1: 49

58 Capitulo IV Marco Metodológico Fase Acciones Diagnosticar Corresponde a la identificación de los problemas primarios que son la causa fundamental de la necesidad de cambio de la organización. Este diagnostico desarrolla los supuestos teóricos (hipótesis de trabajo) acerca de la naturaleza de la organización y el dominio de su problema. Planificar la acción Especificar las acciones organizacionales que deberían relevar o mejorar los principales problemas. El descubrimiento de las acciones planificadas es guiada por el marco teórico, el cual indica el estado futuro para la organización y los cambios que permiten alcanzar este estado. El plan establece el objetivo del cambio y su enfoque. Tomar la acción Implementa el plan de acción. Los investigadores y participantes evalúan los resultados para determinar si los efectos teóricos de la acción fueron alcanzados y si estos efectos resolvieron los problemas. Donde los cambios no fueron exitosos debe establecerse algún marco para la próxima iteración del ciclo de investigación acción. Evaluar Una vez completadas las acciones, los investigadores y demás participantes evalúan las salidas. La evaluación incluye determinar si los efectos teóricos de la acción fueron alcanzados, y si éstos efectos relevaron a los problemas. Si los cambios fueron exitosos, la evaluación se pregunta si los cambios fueron los únicos causantes de este éxito. Si los cambios no fueron exitosos, es necesario establecer un marco para la próxima iteracción del ciclo de investigación acción. Especificar el aprendizaje A partir del resultado de la evaluación, los investigadores especifican el conocimiento adquirido. TABLA 4.1: Fases del método de investigación y acción FUENTE: (Baskerville, 1999) El carácter empírico en la fase de evaluación y selección de métodos en el Investigación Acción (Baskerville, 1999), hace necesario reforzarlo con otra metodología como DESMET, la cual ayuda al evaluador de una organización a planificar y ejecutar la evaluación de manera imparcial y fiable (Kitchenham et al., 1996). Según Kitchenham et al. (1996), la metodología DESMET está compuesta por un conjunto de métodos con sus respectivas herramientas que pueden ser aplicadas por una organización en particular. Está metodología en el caso del presente trabajo de grado, fue utilizada para la planificación y posterior evaluación del modelo propuesto, a fin de evaluar una Arquitectura de Web Services. La aplicación de DESMET constituye uno de los pasos del Framework metodológico, el cual consta de 11 actividades agrupadas en cinco grandes fases, que se corresponden con las fases del método de Investigación Acción descrito anteriormente. En la Figura 4.1 se muestra el framework metodológico del LISI adaptado a la presente investigación. 50

59 Capitulo IV Marco Metodológico FIGURA 4.1 Framework Metodológico del Trabajo de Investigación FUENTE: Adaptado de (Pérez et al., 2004) El framework metodológico establece esta secuencia de actividades para realizar la investigación y las principales salidas de cada una de éstas. Es necesario describir cada una de ellas, destacando su objetivo y las entregas correspondientes. 1. Investigación documental: etapa de la fase de Diagnosticar, consistió en la revisión del material bibliográfico relacionado con aspectos básicos de Web Services tales como: definición, características de calidad, funcionalidad, tecnologías estándares y adicionales. Igualmente, se realizó una revisión exhaustiva de conceptos fundamentales de la Arquitectura de Software, Arquitectura Orientada al Servicio (SOA) y Arquitectura para Web Services; considerando su importancia en el desarrollo de Software. El objetivo es concretar un marco conceptual que soporte el trabajo de investigación. Sus entregas fueron: un conjunto de conceptos tecnológicos y principales problemas que motivan el estudio en el área. 51

60 Capitulo IV Marco Metodológico 2. Análisis de antecedentes de la Arquitectura para Web Services: etapa de la fase de Diagnosticar, consistió en reunir los antecedentes y experiencias más significativas en la implementación de Arquitecturas para Web Services proveniente de las mejores prácticas. El Objetivo es conocer las Arquitecturas para Web Services propuestas por algunas empresas desarrolladoras de Software. Su entrega establece las decisiones arquitectónicas de las Arquitecturas en estudio. 3. Formulación de los objetivos y alcances de la investigación: etapa de la fase de Planificar la acción, consistió en plantear y justificar el problema de la investigación, definir el objetivo principal de la misma y sus objetivos específicos. 4. Formulación de la Instanciación del Framework metodológico: etapa de la fase de Planificar la acción, esta es la actividad de especificación del marco metodológico, en la que se realiza una adaptación del Framework metodológico del LISI (Pérez et al., 2004) al contexto de la presente investigación. 5. Diseño del Modelo de Especificación de Calidad para la Arquitectura de Web Services: etapa de la fase de Tomar la acción, partiendo de etapas anteriores se diseñó una propuesta del modelo de especificación de calidad para la arquitectura de Web Services. El objetivo es plantear una propuesta en versión de prueba. Sus entregas son: la propuesta del modelo de especificación de calidad en versión beta con sus métricas y las consideraciones del contexto donde se debe aplicar. Para la formulación de las métricas se siguió el enfoque Objetivo, Pregunta, Métrica (GQM) de Basili et al., (1994), el cual se describe en la siguiente sección. 6. Análisis de Contexto: segunda etapa de la fase de Tomar la acción, se determinaron las especificaciones y acuerdos necesarios para implementar la propuesta. El objetivo es preparar las herramientas y el contexto donde será evaluada la propuesta. Sus entregas son las consideraciones y preparación del contexto de evaluación. 7. Aplicación de la Metodología DESMET: última etapa de la fase de Tomar la acción, donde se aplicó la metodología DESMET. El objetivo fue seleccionar el método de 52

61 Capitulo IV Marco Metodológico evaluación que mejor se adaptó a la investigación. Sus entregas son: el método por el cual se puede aplicar y evaluar la propuesta de especificación. 8. Evaluación del Modelo de Especificación de calidad para la Arquitectura de Web Services etapa de la fase de Evaluar, donde se evaluó la propuesta del modelo usando el método seleccionado por DESMET. 9. Análisis de Resultados: segunda etapa de la fase de Evaluar, consistió en estudiar los resultados a partir de los objetivos planteados en la investigación, en términos del modelo propuesto y los productos tangibles alcanzados. Al terminar está fase se evaluó si el resultado fue satisfactorio. 10. Refinación de la propuesta del Modelo de Especificación: última etapa de la fase de Evaluar, se realizan las modificaciones a la propuesta para aumentar la confiabilidad del mismo y sus posibilidades de éxito. La entrega de esta etapa será la entrega de una segunda versión formal de la propuesta para futuras iteraciones, sin embargo, debido a que los resultados de la propuesta fueron satisfactorios no fue necesario realizar esta actividad. 11. Conclusiones y recomendaciones: etapa de la fase de especificar el aprendizaje : donde se establecen las conclusiones relativas al modelo propuesto aplicado y sus resultados. Finalmente, se sugieren algunas recomendaciones para futuros refinamientos del modelo propuesto y para investigaciones relacionadas. El ciclo metodológico propuesto soporta la investigación de problemas complejos, partiendo de prácticas exitosas y evaluando el modelo propuesto en versión Beta. Absorbe el aprendizaje y lo incorpora a una nueva propuesta mejorada. Este ciclo puede repetirse n veces; pero para efectos de esta investigación se considera una sola iteración, dadas las limitaciones de tiempo. Según Pressman (2001), la única forma racional de mejorar cualquier proceso es medir atributos del proceso, desarrollando un juego de métricas significativas según estos atributos y 53

62 Capitulo IV Marco Metodológico entonces utilizar las métricas para proporcionar indicadores que conducirán a una estrategia de mejora. A continuación se presenta un enfoque basado justamente en objetivos, preguntas y métricas para evaluar 4.2 Enfoque basado en Objetivos, Preguntas y Métricas - GQM El Objetivo, Pregunta y Métrica del inglés (Goal Question Metric GQM) de Basili et al., (1994), es un enfoque para desarrollar y mantener un programa de métricas significativas que soportan: Alineación de métricas con los objetivos técnicos y de negocios en una organización. Mejora en los procesos de software. Gerencia de riesgo. Mejora en la calidad del producto. Según Basili et al., (1994), el desarrollo de software como cualquier disciplina de ingeniería, requiere de un mecanismo de medición para su corrección y evaluación. Para que este sea efectivo debe estar centrado en objetivos específicos; aplicado a todo el ciclo de vida de los productos, procesos y servicios, y su interpretación debe estar basada en las caracterizaciones del contexto organizacional, ambiente y objetivos. En este sentido, el enfoque GQM desarrollado por Basili et al., (1994), propone tres niveles que pueden observarse en la Figura 4.2. FIGURA 4.2 Niveles del enfoque GQM FUENTE: (Basili et al., 1994) 54

63 Capitulo IV Marco Metodológico Primer Nivel Conceptual (Objetivo): un objetivo es definido por un objeto, conjunto de razones con respecto a varios modelos de calidad y puede tener varios puntos de vista e incluso es relativo a un ambiente particular. Los objetivos mensurables son productos, procesos y recursos. Segundo Nivel Operacional (Pregunta): un conjunto de preguntas es utilizado para caracterizar la forma en que se alcanzará un objetivo específico. Las preguntas tratan de caracterizar el objeto de medición con respecto a un atributo de calidad seleccionado, para determinar su calidad desde un cierto punto de vista. Tercer Nivel Cuantitativo (Métrica): un conjunto de datos es asociado con cada pregunta para responderla de forma cuantitativa. Los datos pueden ser objetivos (si dependen sólo del objeto medido) o subjetivos (si dependen del objeto medido y del punto de vista desde el cual son tomados). Según Basili et al. (1994), el objetivo es refinado en varias preguntas y cada pregunta es refinada en varias métricas. Algunas métricas pueden ser utilizadas para responder varias preguntas de un mismo objetivo, incluso, varios modelos GQM pueden tener también preguntas y métricas en común, dado que las métricas pueden tener diferentes valores dependiendo del punto de vista tomado. Una vez planteado que la metodología utilizada es una instanciación del framework metodológico del LISI propuesta por (Pérez et al.,2004), con el apoyo del enfoque GQM desarrollado por (Basili et al., 1994) se procedió a desarrollar el ciclo metodológico propuesto para esta investigación en los próximos capítulos. Por consiguiente, a continuación se describe la propuesta del modelo de especificación de calidad para la arquitectura de Web Services basado en modelo de calidad ISO-9126 y las decisiones arquitectónicas de los Web Services. 55

64 Capitulo V Diseño del modelo CAPITULO V MODELO DE ESPECIFICACIÓN DE CALIDAD PARA ARQUITECTURAS DE WEB SERVICES Siguiendo las fases del ciclo metodológico, este capítulo describe el inicio de la fase tomar la acción ; por ello, se propone el modelo conceptual que facilitará el análisis de los conceptos claves planteados en la revisión bibliográfica, así como, el diseño del modelo de especificación de calidad para la arquitectura de Web Services; incluyéndose además, el conjunto de objetivos arquitectónicos identificados en las propuestas de arquitecturas para Web Services y su relación con las características de calidad del modelo estándar ISO/IEC 9126 (2001) los cuáles apoyan al modelo de especificación de calidad propuesto. 5.1 Modelo Conceptual Luego de realizarse la revisión bibliográfica que permitió conocer las diversas definiciones de los Web Services, sus características, arquitectura de software utilizada, tecnologías estándares, y especificaciones adicionales propuestas por empresas desarrolladoras de software; se logró construir una base conceptual que sirvió de soporte al presente trabajo de investigación. Como parte de esta base conceptual, la Figura 5.1 muestra un conjunto de conceptos relacionados con arquitectura de software, SOA, Web Services, arquitectura de Web Services y las características de la calidad según la norma ISO

65 Capitulo V Diseño del modelo FIGURA 5.1 Modelo de conceptos de la investigación FUENTE: Elaboración propia Algunas de las relaciones de estos conceptos (Figura 5.1), se describen a continuación: La arquitectura de software es vista como un artefacto para desarrollar la evaluación arquitectónica contra las metas de calidad. Los métodos de evaluación ayudan a especificar y validar la arquitectura de software usando métodos sistemáticos o procedimientos. La evaluación es hecha con el objetivo de asegurar que la arquitectura en cuestión propicie uno o más metas de calidad (Bass et al., 2003). Los métodos de evaluación determinan la capacidad de la arquitectura para soportar características de calidad. Estos métodos están basados en el modelo de calidad que especifica las características de calidad para ser evaluadas y los mismos pudieran estar apalancados en la norma ISO Adicionalmente, Bosch (2000) menciona que los métodos de evaluación requieren el uso de técnicas de evaluación, tales como: Escenarios, Modelos Matemáticos, Experiencia, y Simulación. 57

66 Capitulo V Diseño del modelo De acuerdo a ISO (ISO/IEC 9126, 2001) la calidad del producto de software puede ser medida en tres aspectos: calidad externa, medida basada en cómo el producto de software actúa o responde; la calidad interna, medida desde las características intrínsecas del producto; y la calidad de uso, basada desde el correcto uso que brinda el usuario. En el contexto de esta investigación, el modelo de calidad interna será el usado para la determinación de las características de calidad propiciadas por la Arquitectura para Web Services. El modelo de calidad de ISO propone un conjunto de seis características de calidad, las cuáles son refinadas como atributos de un producto de software para el cual su calidad es descrita y evaluada. Estas características de calidad son mantenibilidad, funcionalidad, usabilidad, fiabilidad, eficiencia y portabilidad (ISO/IEC 9126, 2001). De la revisión bibliográfica se concluyó que la mantenibilidad, funcionalidad, usabilidad, fiabilidad, eficiencia y portabilidad son características de calidad a ser propiciadas por la arquitectura para Web Services, tomando en cuenta que esta garantiza Web Services de libre acoplamiento, autocontenidos, independientes de plataforma, reutilizables; que facilitan interoperabilidad, escalabilidad, integridad, disponibilidad y flexibilidad (W3C, 2002; Sleeper et al., 2001; IBM, 2004; Rogue SW, 2004; Systinec, 2002; Thomas, 2003; Newcomer, 2002; Sun 2003; Deitel et at., 2003). Por otro lado, los Web Services son componentes que residen en la Web y emplean un conjunto de tecnologías estandarizadas por las organizaciones mundiales OASIS y la W3C, las cuáles, funcionando juntas constituyen la Arquitectura Básica de Web Services (WSA) (Systinet, 2002b, p.3). La Arquitectura para Web Services permite la implementación de Web Services, los cuáles pueden definirse simplemente como servicios que residen en la Web; propios de un proveedor que los ofrece a través de un contrato que se registra en un Administrador de Servicios. El consumidor que requiere el servicio, realiza una solicitud al Administrador para conocer el detalle de conexión del servicio, y una vez obtenida está información, el consumidor desarrolla un cliente para acceder al Web Service. 58

67 Capitulo V Diseño del modelo De está manera, las tecnologías estándares para Web Services: SOAP, WSDL y UDDI soportan la implementación de los tres componentes arquitectónicos funcionales básicos utilizados por la Arquitectura Orientada al Servicio (SOA) para lograr la operación, estos son: transporte, descripción y descubrimiento. Es por ello que Systinet (2002,b) plantea que la Arquitectura básica de Web Services no es más que las tecnologías estándares implementadas sobre SOA. En complemento a las tecnologías estándares, algunas empresas proponen un conjunto de especificaciones adicionales para la arquitectura de Web Services con el fin de proveer suficiente soporte en aplicaciones de negocios complejas y críticas, específicamente en las áreas de: seguridad, negocio, flujo de procesos, transacciones y mensajería (Newcomer, 2002, p.219). Una vez relacionados los conceptos claves revisados en esta investigación, y considerando la importancia de las tecnologías estándares para la arquitectura de Web Services, se determina que la mínima expresión de la arquitectura de Web Services está representada por la implementación de las tecnologías estándares. Adicionalmente, se hace necesario identificar las decisiones arquitectónicas que estas tecnologías soportan, las cuales son mostradas en la Tabla 5.1: Tecnologías Estándares Decisiones arquitectónicas HTTP, HTTPS, FTP, RM/IIOP Garantizar un ambiente ubicuo para Web Services. SOAP-ML Garantizar interoperabilidad del mensaje. Proveer la definición de información para la comunicación del Web Service. WSDL Garantizar una descripción del servicio estándar. UDDI Garantizar la publicación y descubrimiento del Web Service. TABLA 5.1: Tecnologías estándares y sus decisiones arquitectónicas FUENTE: Elaboración propia 59

68 Capitulo V Diseño del modelo Se concluye que la arquitectura para Web Services debe contemplar las decisiones arquitectónicas soportadas por las tecnologías estándares. Bajo esta premisa, previamente a la aplicación del modelo de especificación de calidad, debe validarse que la arquitectura en evaluación corresponda a una arquitectura para Web Services, preguntando por la obligatoria presencia de estas tecnologías estándares. En caso afirmativo, se procede a aplicar el modelo de especificación de calidad para la arquitectura de Web Services presentado en la siguiente sección. 5.2 Modelo de Especificación de Calidad Para proponer la especificación de calidad se tomó como base el conjunto de características de la arquitectura para Web Services revisadas en el capítulo II y la norma de calidad ISO/IEC 9126 (2001). Es importante señalar que la escogencia de la norma de calidad ISO/IEC 9126 (2001) se fundamenta en su amplia aceptación como herramienta estándar para la especificación de calidad. Su estructura contempla seis (6) características de calidad del producto (funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad) y provee las subcaracterísticas de calidad sugeridas (Anexo B). Según Losavio et al., (2003), cada característica es refinada en subcaracterísticas hasta que se obtienen los atributos internos que pueden ser medidos y determinan la calidad interna del producto de software. La Figura 5.2. muestra está relación. FIGURA 5.2 Relación entre los elementos de calidad FUENTE: Adaptado (Losavio, et al., 2003) 60

69 Capitulo V Diseño del modelo Obtenidos los elementos de calidad que fueron planteados en la Figura 5.2, y considerando que la calidad del producto puede ser expresada en diferentes perspectivas o enfoques (ISO/IEC, 2001); es importante señalar que para el contexto de está investigación, la arquitectura de Web Services es considerada un producto intermedio de desarrollo de software, razón por la cual, se reafirma la utilización del enfoque de calidad interna. Con base a lo anteriormente expuesto, se procedió a asociar el conjunto de características de la arquitectura para Web Services con las características y subcaracterísticas de calidad de ISO/IEC 9126, logrando generar el árbol de calidad representado en la Figura 5.3. FIGURA 5.3 Árbol de calidad para la WSA basado en ISO 9126 FUENTE: Elaboración propia En la Figura 5.3, las características de calidad internas son refinadas en subcaracterísticas hasta que se obtienen los atributos internos, representados por las tecnologías estándares necesarias en una arquitectura para Web Services. En este contexto, las métricas son definidas como métodos de medición para asignarles valor y están asociadas a uno o más atributos. En busca de fortalecer el modelo de especificación de calidad para la WSA, fue necesario analizar y determinar las decisiones arquitectónicas propuestas por las arquitecturas sobre 61

70 Capitulo V Diseño del modelo las cuáles los Web Services son implantados, encontrando que las decisiones están dirigidas hacia diferentes componentes arquitectónicos que propician características y subcaracterísticas de calidad. De está manera, los componentes arquitectónicos son refinados en decisiones arquitectónicas que facilitan la identificación de la calidad. Por otro lado, cada decisión arquitectónica fue considerada como un atributo interno que refina una o más subcaracterística de calidad de ISO/IEC, y a su vez, es medido por métricas internas que cuantifican la calidad y determinan su presencia o ausencia en cada decisión analizada. En la Figura 5.4 se plantea la relación entre los elementos de calidad a nivel arquitectónico para Web Services. FIGURA 5.4 Relación entre los elementos del modelo de especificación de calidad para la WSA FUENTE: Elaboración propia El producto final al aplicar el modelo de especificación serán los valores de calidad que deben ser alcanzados para cada atributo interno. Cuando los valores son alcanzados o mejorados entonces, se podrá considerar que la arquitectura propicia las características de calidad requeridas. Es importante indicar que la formulación de las métricas planteadas en el modelo de especificación de calidad propuesto, estarán soportadas bajo el enfoque de GQM de Basili et al., (1994). Este enfoque se presenta como un mecanismo detallado para la definición y elaboración de objetivos medibles, respondiendo a una de las principales inquietudes de esta investigación: Cómo medir la calidad propiciada en la arquitectura de Web Services?. 62

71 Capitulo V Diseño del modelo Al utilizar el enfoque GQM en la construcción del modelo de especificación de calidad, los atributos son interpretados como los objetivos que deben alcanzarse con la arquitectura para Web Services o las decisiones arquitectónicas que deben ser tomadas. Estos son apoyados por las diversas preguntas que se formulan para el logro de los objetivos; y las métricas indican la unidad de medición de los atributos. En la Figura 5.5 es mostrada la relación de la especificación de calidad para la WSA y el enfoque GQM. FIGURA 5.5 Relación de la especificación de calidad para la WSA y el enfoque GQM FUENTE: Elaboración propia En apoyo al modelo de especificación de calidad para la Arquitectura de Web Services, en la siguiente sesión se presentan un conjunto de objetivos arquitectónicos para Web Services analizados contra el modelo ISO/IEC 9126, a fin de determinar las características de calidad que éstos propician. Análisis de los Objetivos Arquitectónicos para Web Services En el capitulo III fueron revisadas las características de las arquitecturas para Web Services propuestas por algunas organizaciones desarrolladoras de software, planteándose las decisiones arquitectónicas que estas consideran para cada capa de sus arquitecturas. Con base a esta revisión, se propone un conjunto de decisiones arquitectónicas esperadas para la WSA, las cuáles fueron transformadas y analizadas como objetivos arquitectónicos a fin de determinar las características y subcaracterísticas de calidad que éstos propician para apoyar a la propuesta del modelo de calidad. En la Tabla 5.2. se muestra el resultado de este análisis. 63

72 Capitulo V Diseño del modelo Características de Calidad según ISO Objetivos Arquitectónicos para Web Services Funcionalidad A Soportar el establecimiento de acuerdos en la descripción del servicio y la semántica que gobernará la interacción entre ellos. Facilitar la colaboración entre Web Services para los negocios Facilitar la composición de servicios para implementar soluciones de negocios integradas. Facilitar la descripción de cómo las comunicaciones servicios - servicios y flujos son desempeñadas. Proveer mecanismos para especificar propiedades de entrega de mensajes abstractas. Soportar el modelamiento de los procesos de negocios y workflows. Habilitar el uso global de información de negocios electrónicos. Permitir la coordinación de tareas múltiples en mensajes de Web Services. Permitir la descripción de orquestación que refleja una simple coreografía de las llamadas del servicio entre las dos partes del negocio. Soportar la descripción de transacciones en un Web Services Facilitar la interoperabilidad en la descripción de colaboración y coordinación entre un conjunto de Web Services. Capacidad para definir un protocolo de múltiples descubrimientos simultáneos para localizar Web Services. Garantizar patrones de descubrimientos soportados sobre la tecnología estándar UDDI Garantizar la interoperabilidad entre acuerdos del servicio. Facilitar la interacción entre Web Services usando notificaciones o eventos. Proveer mecanismos para la transmisión de Web Services y mensajes de manera neutral a través de la red Soportar descripciones de API s y esquemas para facilitar la interoperabilidad entre sistemas aprovisionadores usando Web Services. Soportar la definición de diversos formatos de licencias, incluyendo certificados.509 y tickets Kerberos que pueden ser usados como credenciales de seguridad. Garantizar la interoperabilidad de las transacciones atómicas Definir políticas interoperables de seguridad de un Web Services. Facilitar la inclusión de políticas de aseveración sobre las definiciones de UDDI y WSDL garantizando la interoperabilidad de estos componentes. P I C S Fiabilidad Usabilidad Eficiencia M TF F TD FR FA O UR Mantenibilidad AN FC ES FP Portabilidad AD FI A1 FD 64

73 Capitulo V Diseño del modelo Características de Calidad según ISO Objetivos Arquitectónicos para Web Services Funcionalidad A Soportar la definición de relaciones de confidencialidad, basada en el concepto de Security Tokens Services (STS). Garantizar confiabilidad de datos. Facilitar la implementación de políticas de aserciones Garantizar integridad end to end del Web Services. Permitir la definición de mecanismos para establecer escenarios de confianza entre varias organizaciones que participan en un Web Services Soportar mecanismos de seguridad basados en ML para solventar problemas de autenticación, control de acceso basado en roles. Soportar mecanismos de seguridad en el transporte del mensaje. Describir mejoras de seguridad en el mensaje SOAP para proveer integridad, autenticación y confidencialidad. Facilitar el intercambio de información sobre autenticación y autorización. Facilitar la especificación de las reglas y sintaxis de firmas digitales en ML. Facilitar la transmisión de mensajes protegidos vía SSL ó TLS. Garantizar soporte para acordar sesiones o comunicaciones con claves específicas para firmar y encriptar información. Permitir la especificación de datos encriptados de un proceso y su representación en ML. Proveer seguridad para la capa de mensajes ML, agregando señales de seguridad y servicios de autenticación. Soportar el uso de firmas digitales sobre un mensaje. Garantizar mínimo de fallas del Web Services ocasionadas por sus componentes arquitectónicos Facilitar la coordinación de transacciones atómicas de corta duración. Soportar mecanismos para la reactivación del Web Services. Garantizar la entrega del mensaje ante fallas de los componentes del Web Services Garantizar el funcionamiento del Web Services en caso de errores en el software Facilitar el óptimo desempeño del Web Services. Soportar un mecanismo para consultas de un nodo SOAP a otro nodo SOAP basados en un conjunto de URI's solicitando una o varias referencias de interfaces en el mensaje P I C S Fiabilidad Usabilidad M TF F FR FA Eficiencia O TD UR Mantenibilidad AN FC ES FP Portabilidad AD FI A1 FD 65

74 Capitulo V Diseño del modelo Características de Calidad según ISO Objetivos Arquitectónicos para Web Services Funcionalidad A P I C S Fiabilidad Usabilidad M TF F FR FA Capacidad para definir un protocolo de múltiples descubrimientos simultáneos para localizar Web Services de manera eficiente. Facilitar la inspección de Web Services disponibles y conocer que servicios estos ofrecen. Soportar especificaciones sobre patrones de descubrimiento Facilitar el encapsulamiento de datos binarios o archivos multimedias en un mensaje. Permitir empaquetar mensajes binarios a un mensaje SOAP. Permitir la descripción de secuencias para preguntar por ítems desde una lista de datos que es útil para un Web Services. Proveer mecanismos de direccionamiento para enrutamiento del mensaje Permitir la composición recursiva de Web Services, de tal manera que un Web Services pueda ser usado como componente de otro Web Services. Facilitar la gestión y control de los componentes del Web Services Permitir la descripción de un patrón generalizado de intercambio de mensajes. Permitir el encapsulamiento de objetos Garantizar alta cohesión entre los componentes Facilitar la descripción de las experiencias de los usuarios para su visualización a través de la interfaz de usuario TABLA 5.2 DECISIONES ARQUITECTÓNICAS DE WEB SERVICES QUE PROPICIAN CARACTERÍSTICAS/SUBCARACTERÍSTICAS DE CALIDAD DE SOFTWARE FUENTE: ELABORACIÓN PROPIA Eficiencia O TD UR Mantenibilidad AN FC ES FP Portabilidad AD FI A1 FD A = Adecuación, P = Precisión, I = Interoperabilidad, C = Conformidad, S = Seguridad. M = Madurez, TF = Tolerancia a Fallos, FR = Facilidad de Recuperación. F = Facilidad de Comprensión, FA = Facilidad de Aprendizaje, O = Operatividad. TD = Tiempo de desempeño, UR = Utilización de recursos. AN = Análisis, FC = Facilidad de Cambios, ES = Estabilidad, FP = Facilidad de Pruebas. AD = Adaptabilidad, FI = Facilidad de Instalación, A1 = Adecuación, FD = Facilidad de Reemplazo. 66

75 Capitulo V Diseño del modelo Al analizar la información expuesta en la Tabla 5.2, puede concluirse que los objetivos arquitectónicos para Web Services son capaces de propiciar algunas características de Calidad según la norma de ISO/IEC ; tales como: Funcionalidad, la cual se identifica con la presencia de las subcaracterísticas adecuación, interoperabilidad, precisión y seguridad; Fiabilidad, a través de sus subcaracterísticas: madurez, tolerancia a fallos y facilidad de recuperación; Eficiencia, dada la presencia de las subcaracterísticas de tiempo de desempeño y utilización de recursos; y Mantenibilidad, con sus subcaracterísticas de facilidad de cambios y estabilidad. También, con menor presencia se observa la característica de calidad de Usabilidad. Partiendo del árbol de calidad mostrado en la Figura 5.3 y considerando el conjunto de objetivos arquitectónicos analizados en la Tabla 5.2, se propone un nuevo árbol de calidad mejorado para la WSA basado en la norma ISO , el cual se muestra en la Figura 5.6. FIGURA 5.6 Árbol de calidad mejorado para la WSA basado en ISO 9126 FUENTE: Elaboración propia 67

76 Capitulo V Diseño del modelo Gracias al árbol de calidad mostrado en la Figura 5.6 puede visualizarse la relación de los elementos que intervienen en el modelo de especificación de calidad para la arquitectura de Web Services. Esta relación representa un modelo jerárquico desde un nivel abstracto partiendo desde las características internas del estándar de calidad ISO , hasta un nivel inferior que conlleva al refinamiento de los atributos internos que facilitan su medición y establecen un camino para determinar la calidad en cada atributo evaluado. Este nuevo árbol especifica las características de calidad de ISO/IEC 9126 a ser propiciadas por la arquitectura para Web Services: Funcionalidad, Mantenibilidad, Portabilidad, Usabilidad, Eficiencia y Fiabilidad; Adicionalmente, se refina en subcaracterísticas de calidad, tales como: precisión, seguridad, recuperación, tolerancia a fallos, utilización de recursos y facilidad de aprendizaje. Esta última corresponde a la características de Usabilidad, la cuál es aplicable para aquellos casos donde la interfaz del usuario representa un objetivo arquitectónico del Web Service. Esta nueva versión del árbol de calidad incorpora un nuevo nivel Componentes, en él se persigue agrupar con mayor abstracción los diferentes atributos o decisiones arquitectónicas. Este nivel ofrece una mejor comprensión de la desagregación de la subcaracterística dependiendo de la decisión arquitectónica que se tome. Estos componentes son: Acuerdos para negocios, colaboración para negocios, composición para negocios, entrega del mensaje, flujo del servicio, transacciones, descripción de coordinación, descubrimiento, interacción entre negocios, eventos entre Web Services, intercambio de mensaje, interfaces, interoperabilidad en la seguridad del mensaje, interoperabilidad en las transacciones, políticas interoperables, seguridad interoperable, confiabilidad de datos, seguridad del Web Service, seguridad en el transporte, seguridad en la mensajería, control de fallas, transacciones atómicas, reactivación, confiabilidad del mensaje, disponibilidad, capacidad de desempeño, configuración de rutas en nodos SOAP, eficiencia en el descubrimiento, eficiencia en la Mensajería, enrutamiento del mensaje, composición recursiva de WS, control de componentes, patrón de mensajería, acoplamiento, cohesión, interfaz de usuario. 68

77 Capitulo V Diseño del modelo Por otro lado, en este árbol se observa que existen varios atributos dentro de un componente arquitectónico enfocados a propiciar características de Funcionalidad, Eficiencia, Fiabilidad y Mantenibilidad, descuidando otras características tales como Usabilidad y Portabilidad, está situación es consecuencia de la poca relevancia que tiene la Usabilidad en la arquitectura para Web Services, mientras que la Portabilidad, está implícita en la naturaleza de los componentes estándares de la arquitectura. Una vez identificadas las características de calidad que son propiciadas por el conjunto de objetivos arquitectónicos para Web Services, se procedió a formular las preguntas y métricas que servirán de guía para la evaluación del modelo de especificación de la calidad sobre las arquitecturas para Web Services. Estas preguntas y métricas son detalladas en el Anexo C. Planteados los objetivos, las preguntas y las métricas que facilitarán la evaluación de la arquitectura para Web Services y apoyarán la toma de decisiones arquitectónicas en etapas tempranas, se propone el siguiente algoritmo de evaluación: El porcentaje de presencia de una característica de calidad será determinado basándose en el promedio de todas las subcaracterísticas que a esta le pertenecen. El porcentaje de presencia de una subcaracterística de calidad será determinado en función al promedio del porcentaje de todos los componentes arquitectónicos que a esta pertenecen. El porcentaje de presencia de un componente arquitectónico para Web Services será determinado en función al promedio de todos los objetivos alcanzados dentro de ese componente. Un objetivo es alcanzado cuando el promedio de sus métricas es mayor o igual a 3. Por otro lado, a fin de determinar el nivel de aplicabilidad y confiabilidad de los objetivos propuestos en el modelo, se considera que: 69

78 Capitulo V Diseño del modelo El total de respuestas No Aplica no debe exceder al 10% del total de las preguntas del modelo. El total de respuestas No Sabe no debe exceder al 15% del total de las preguntas del modelo. Con la identificación de los objetivos, los componentes arquitectónicos de los Web Services, las subcaracterísticas de calidad y las características de calidad en la arquitectura para Web Services se podrá realizar un análisis cualitativo sobre la arquitectura evaluada, el cual facilitará la toma de decisiones en las fases tempranas de diseño y la identificación de puntos de sensibilidad que soportan las decisiones arquitectónicas. Siguiendo las actividades del ciclo metodológico, en el próximo capitulo se describe el análisis del contexto y el proceso de selección del método que facilitó la evaluación del modelo de especificación de calidad para la Arquitectura de Web Services, las cuáles representan el cierre de la fase Tomar la Acción. 70

79 Capitulo VI Aplicación del DESMET CAPITULO VI APLICACIÓN DE DESMET El presente capítulo describe la segunda y última etapa de la fase Tomar la Acción, donde se preparó el análisis de contexto y el proceso de selección del método de evaluación más apropiado para el dominio del problema, el método de evaluación resultante fue aplicado al modelo de calidad propuesto. 6.1 Objetivos de la Evaluación En atención a la propuesta del modelo de especificación de calidad para la WSA, se plantearon los siguientes objetivos: a. Objetivo General Evaluar de manera objetiva y eficiente la propuesta del modelo de especificación de calidad para determinar la calidad en la WSA utilizada por alguna empresa en Venezuela. b. Objetivos Específicos - Analizar el contexto donde será evaluado el nuevo modelo. - Seleccionar un método fiable e imparcial para el modelo de especificación de calidad. - Evaluar el modelo mediante el método seleccionado. - Elaborar un análisis de los resultados de la evaluación. 71

80 Capitulo VI Aplicación del DESMET 6.2 Metodología a Seguir Para llevar a cabo la evaluación se siguieron las actividades instanciadas del framework metodológico del LISI (Pérez et al, 2004), donde explícitamente se propone la metodología DESMET como instrumento para identificar el método para evaluar el modelo de especificación de calidad. El primer paso fue el análisis del contexto donde se determinaron las especificaciones y acuerdos necesarios para identificar el método más adecuado Análisis de Contexto Está es la etapa intermedia de la fase tomar la acción. El objetivo fue precisar el contexto donde será evaluado de forma precisa el modelo de especificación de calidad para la WSA. A diferencia de experimentos formales, la evaluaciones de DESMET son dependientes del contexto, lo cuál indica que no se espera tener un método para que sea el mejor en todas las circunstancias. Por lo tanto, DESMET especifica siete criterios técnicos para determinar las circunstancias de evaluación, y así poder elegir el más apropiado (Kitchenham et al, 1996). Estos criterios son: a. El contexto de la evaluación, b. La naturaleza del impacto esperado, c. La naturaleza del objeto de evaluación, d. El alcance del impacto del objeto de evaluación, e. La madurez del objeto de evaluación, f. Tiempo requerido para entender los principios delineados por el objeto de evaluación, g. Tiempo requerido para llegar a ser un experto en el uso del Objeto de Evaluación. h. La madurez de la organización evaluadora. A continuación se explican en detalle cada uno de los criterios de análisis de contexto: 72

81 Capitulo VI Aplicación del DESMET a. El contexto de la evaluación Los elementos que conforman el contexto de la evaluación son: Objeto: Modelo de especificación de calidad para la WSA. Investigador: autor del modelo propuesto, quién también es responsable de realizar su evaluación. Organización: Empresa del ramo de las telecomunicaciones donde labora el investigador y son implementados algunos Web Services. b. Naturaleza del impacto esperado La naturaleza del impacto esperado es cualitativa. Con la evaluación se busca que el modelo de especificación de calidad para la WSA se convierta en una guía que propicie calidad en las organizaciones desarrolladoras de software comercial o software interno. Es importante destacar que este modelo aporta un juicio ó análisis al proceso de desarrollo de software, facilitando la toma de decisiones tempranas y la identificación de puntos de sensibilidad en las decisiones arquitectónicas. c. La naturaleza del Objeto de Evaluación En este trabajo de investigación se presenta un modelo para especificar la calidad en las arquitecturas de Web Services basado en el estándar ISO/IEC , Además, en el capítulo V se detallan las decisiones arquitectónicas que pueden facilitar la identificación de requerimientos en las fases tempranas de diseño e implementación de Web Services bajo una arquitectura que propicia calidad. Tomando en cuenta estos argumentos, se ubica a este objeto de evaluación como una Herramienta dentro de las categorizaciones de DESMET. d. Alcance del impacto del objeto de evaluación El impacto de esta herramienta comprende la dimensión de granularidad del producto porque trata la arquitectura de Web Services como capas y componentes modulares que se 73

82 Capitulo VI Aplicación del DESMET organizan para obtener decisiones arquitectónicas que propician calidad desde las fases tempranas de diseño hasta la implementación. e. Madurez del objeto de evaluación A pesar que el modelo de especificación de calidad para la WSA está basado en ISO 91261, el mismo se define como una propuesta planteada en este trabajo de grado y no es una herramienta comercial, razón por la cual, se considera como un modelo inmaduro. f. Tiempo requerido para entender los principios básicos por el Objeto de Evaluación El tiempo estimado para entender los principios básicos del modelo es medio, considerando entre uno y dos meses aproximadamente para comprender la gama de decisiones arquitectónicas que deben evaluarse y las características de calidad que estas propician. g. Tiempo requerido para llegar a ser un experto en el uso del Objeto de Evaluación El tiempo para llegar a ser un experto es Alto, considerando que se requiere una revisión de los requerimientos del Web Services para la organización a evaluar, dado que la aplicación no adecuada del modelo puede arrojar resultados negativos. h. Evaluación de madurez de la organización Basado en los criterios del nivel de madurez propuestos por Kitchenham et al, (1996), la organización se encuentra en el nivel 2, debido a que no poseen estándares para métricas y el software no es monitoreado en términos cuantitativos, el monitoreo del software es realizado en función a métodos cualitativos, tales como, observación de interacciones con usuarios, incidentes reportados, etc. Finalmente, con el análisis de contexto se logró visualizar varias circunstancias en las cuáles algunos métodos pueden utilizarse para la evaluación, esta actividad es insumo a la selección del método de evaluación de DESMET, el cual será presentado a continuación. 74

83 Capitulo VI Aplicación del DESMET Aplicación del método DESMET La siguiente actividad del ciclo metodológico corresponde a la aplicación del método DESMET. Está es la última etapa de la fase Tomar la Acción de la metodología de investigación y es aquí donde se obtiene un método fiable e imparcial para la evaluación del modelo de especificación de calidad para la arquitectura de Web Services. La metodología DESMET ofrece nueve métodos de evaluación y un conjunto de criterios que ayudan a seleccionar el método apropiado (Kitchenham et al., 1996). A continuación se presenta una breve descripción de los métodos de evaluación: Experimentos cuantitativos: Una investigación del impacto cuantitativo del método organizado como un experimento formal. Estudio de Casos Cuantitativo: una investigación de impacto cuantitativo de método y/o herramientas como un caso de estudio. Encuestas cuantitativas: una investigación del impacto cuantitativo de la herramienta organizada como resumen. Análisis de Características por Proyección: una evaluación basada en características de un simple individuo, quien no sólo determina las características a ser valoradas y su rango de escala. Análisis de Características - Experimento: una evaluación basada en características de un grupo de usuarios potenciales quienes esperan probar las salidas del herramientas en tareas típicas antes de hacer sus evaluaciones. Análisis de Características - Estudio de Casos: una evaluación basada en características ejecutada por quien ha usado el método en un proyecto real. Análisis de Características Estadísticas: una evaluación basada en características proporcionadas por personas que tienen gran experiencia en el uso del método o tienen estudios de la herramienta. 75

84 Capitulo VI Aplicación del DESMET Análisis de Efectos Cuantitativos: Una valoración subjetiva del efecto cuantitativo de la herramienta, basado en la opinión de un experto. Benchmarking: consiste en evaluar el comportamiento de la herramienta en relación con otros ya establecidos. Planteados los métodos de evaluación, en la Tabla 6.1 se resumen las condiciones favorables presentes y no presentes en cada uno de estos métodos, indicando con una donde corresponde: Método de Evaluación Experimento cuantitativo Presente Condiciones favorables Tiempo de aprendizaje relativamente corto Deseo en lograr que el modelo de especificación de calidad sea independiente del contexto satisfac ción 33,33% Modelo de especificación relacionado con una actividad o una tarea simple Beneficios directamente medibles desde las salidas obtenidas Personal con experiencia en mediciones Beneficios cuantificables en un sólo proyecto Proceso de desarrollo estable Escala de tiempo de evaluación proporcional al tiempo de desarrollo de los proyectos Beneficios cuantificables previos a la cancelación del producto Beneficios no cuantificables en un solo proyecto Encuestas cuantitativas NO Beneficios claramente cuantificables Disponibilidad de personal para tomar parte en el experimento Estudio de casos cuantitativos SI % de 0% 33,33% Existencia de una base de datos con datos como: productividad y calidad medida por el modelo de especificación Experiencias en proyectos haciendo uso del modelo de especificación de calidad que se está evaluando. 76

85 Capitulo VI Método de Evaluación Aplicación del DESMET Presente Condiciones favorables SI NO 0% Análisis de características por Proyección Períodos cortos para realizar la evaluación Número grande de características del modelo a evaluar. Análisis de características por Estudio de casos Dificultad para cuantificar beneficios Beneficios observables en un proyecto determinado Población limitada de usuarios del modelo Análisis de características por Experimento Análisis de características por Encuesta Análisis de efectos cuantitativos Benchmarking 60% Proceso de desarrollo estable Escala de tiempo para evaluación proporcional con el tiempo de desarrollo de los proyectos Dificultad para cuantificar beneficios 20% Períodos cortos para realizar la evaluación Tiempo de aprendizaje relativamente corto Beneficios directamente medidos desde los resultados obtenidos de tareas específicas Población variada de usuarios del modelo Dificultad para cuantificar beneficios 25% Población variada de usuarios del modelo Beneficios no observables en un solo proyecto Experiencia en proyectos haciendo uso del modelo de especificación que se está evaluando. Ausencia de procesos de desarrollo estables Disponibilidad de opiniones expertas en evaluaciones de modelos similares Interés en la evaluación de modelos genéricos La salida del modelo puede ser clasificada de acuerdo a las bondades del modelo 25% Requerimiento para mezclar y combinar las características del modelo El modelo de especificación requiere intervención humana dedicada en su implementación % de satisfac ción 50% TABLA 6.1: Condiciones favorables presentes y no presentes en los métodos propuestos por DESMET FUENTE: Elaboración propia 77

86 Capitulo VI Aplicación del DESMET Al analizar los resultados de DESMET en la Tabla 6.1 se puede observar que el método de evaluación que obtuvo mayor porcentaje de satisfacción (60%) con las características del objeto a evaluar, es el método de Análisis de características por estudio de casos. Sin embargo, el método de Benchmarking resultó con un alto porcentaje de satisfacción (50%), cercano al mayor porcentaje. Ante este escenario, Kitchenham et al., (1996) plantea que para ayudar a decidir entre varios métodos DESMET ofrece algunas restricciones o criterios prácticos, los cuáles son: tiempo, riesgo y costo. A continuación se presentan cada uno de ellos relacionados con el modelo en evaluación: El tiempo disponible para evaluar la herramienta puede superar dos meses. Según DESMET, para esta disponibilidad de tiempo, los métodos de evaluación propuestos son: Estudio de casos cuantitativos, Análisis de características por estudio de caso y Análisis de características por encuestas. El costo de la evaluación debe ser medio, dado que este modelo es un trabajo de investigación académico. Para un mediano costo, DESMET propone los siguientes métodos: Estudio de caso cuantitativo, Análisis de características por estudio de caso, Análisis de características por encuestas y Benchmarking. El riesgo de que los resultados de la evaluación lleven a una decisión incorrecta es Alto debido a que los resultados causan impacto en el grado de confiabilidad de la herramienta y por supuesto en el aporte académico de esta investigación. DESMET propone para este criterio los siguientes métodos de evaluación: Análisis de características por estudio de caso y Estudio de caso cuantitativo. De acuerdo a los resultados del análisis de las condiciones favorables (Tabla 6.1), las restricciones o criterios prácticos (Tabla 6.2) y considerando la importancia de evaluar la herramienta propuesta por un método que garantice confiabilidad y seguridad en los resultados, se confirmó que la selección del método de Análisis de características por estudio de caso es factible para la evaluación. La siguiente sección describe en forma general los pasos que conforman este método de evaluación seleccionado. 78

87 Capitulo VI Aplicación del DESMET Análisis de Características por Estudio de Caso Este método consiste en la evaluación de un modelo una vez que este se aplique a un proyecto de software real. La Figura 6.1 describe los pasos que componen el método y muestra dos grandes procesos. FIGURA 6.1 Proceso de aplicación de un Análisis de Características por Estudio de Caso FUENTE: (Kitchenham et al., 1996) El primero es el proceso de Análisis de Características, el cual está conformado por los siguientes pasos: definir el alcance de la evaluación, definir la base de la evaluación, definir roles y responsabilidad, definir premisas y restricciones, definir escalas de tiempo y esfuerzo requeridos, y por último, aplicar el procedimiento de evaluación seleccionado. 79

88 Capitulo VI Aplicación del DESMET El segundo proceso es la aplicación del paso 6 del Análisis de Características, que para efectos de está evaluación es el Estudio de Caso, cuyos pasos son: Seleccionar el método a evaluar, identificar el conjunto de características que permiten la evaluación, seleccionar el proyecto piloto, probar el modelo de especificación de calidad en el proyecto piloto, asignar puntuación a las características a evaluar, analizar los resultados obtenidos y realizar un reporte de la evaluación. Con la selección del método y la ilustración de los pasos que componen el método de evaluación se da por culminado la actividad 7 del framework metodológico, el cual además, da por concluida la fase Tomar la Acción y provee los insumos necesarios para la siguiente fase: Evaluación del modelo propuesto. En el próximo capítulo se describe la actividad 8 y 9 del framework metodológico, siguiendo el método de evaluación sugerido por DESMET. 80

89 Capitulo VII Evaluación de propuesta CAPITULO VII EVALUACIÓN DEL MODELO DE ESPECIFICACIÓN DE CALIDAD PARA LA ARQUITECTURA DE WEB SERVICES En el presente capítulo se presentan las actividades correspondientes a las actividades 8 y 9 del framework metodológico, las cuales se iniciaron con la primera etapa de la fase Evaluar, obteniendo la evaluación del modelo de especificación de calidad sobre una arquitectura para Web Services seleccionada. Posteriormente, siguiendo con la segunda etapa, se analizaron los resultados de la evaluación con base a los objetivos propuestos en está investigación. 7.1 Evaluación de la Propuesta Una vez seleccionado el método de evaluación de DESMET, la próxima actividad es la evaluación de la propuesta aplicando el método resultante de evaluación de Análisis de Características por Estudio de Caso. Cómo se mostró en la Figura 6.1, esta evaluación comprende un proceso general que es el Análisis de características y un proceso específico que es el Estudio de Caso. A continuación se realiza la evaluación del modelo de especificación de calidad para la arquitectura de Web Services, desde el proceso general Análisis de Características hasta el específico Estudio de Caso. 81

90 Capitulo VII Evaluación de propuesta Análisis de Características Siguiendo los pasos del Análisis de Características mostrados en la Figura 6.1, se procedió a desarrollar cada uno de éstos sobre la investigación: 1. Definir el alcance de la investigación: El presente trabajo de investigación contempla la evaluación de un modelo de especificación de calidad para la arquitectura de Web Services, con el apoyo de un equipo desarrollador de software en una organización venezolana dedicada al ramo de las telecomunicaciones. 2. Definir la base de la evaluación: Según Kitchenham et al. (1996), el nivel de confianza requerido por la evaluación está enlazado con la profundidad de la investigación realizada. La presente evaluación está basada en el estudio bibliográfico y metodológico documentado en capítulos anteriores. 3. Definir los roles y responsabilidades: Los roles relacionados con el ejercicio de evaluación son los siguientes: Patrocinante: El ejercicio de evaluación se encuentra patrocinado tanto por el Laboratorio de Investigación de Sistemas de Información de la Universidad Simón Bolívar (LISI) como por la empresa de telecomunicaciones donde se realizó la evaluación. El LISI como laboratorio de investigación se encuentra interesado en llevar a cabo la evaluación y es por ello que suministra toda su experiencia como apoyo en este proceso, mientras que, la empresa de telecomunicaciones facilitó sus instalaciones y parte del recurso humano especializado. Coordinador: Es el responsable de llevar a cabo la evaluación, en este caso, está referido al autor del presente trabajo. Sus responsabilidades son: Preparación del plan de evaluación, identificación del objeto de la evaluación, identificación y definición de las características a evaluar en el modelo de especificación de 82

91 Capitulo VII Evaluación de propuesta calidad, organización del objeto de evaluación, recopilación y análisis de los resultados obtenidos y preparación del informe final junto a las recomendaciones. Usuarios del modelo: Son los usuarios potenciales del modelo de especificación de calidad para la arquitectura de Web Services, a efectos de está investigación, este rol es desempeñado por el equipo de desarrollo de Software de la organización donde será evaluada la arquitectura para Web Services. 4. Definir las premisas y restricciones: El proceso de evaluación se encuentra sujeto a los siguientes factores: Disponibilidad de tiempo y dedicación por parte del Coordinador quién realizará el proceso como parte fundamental de su trabajo de grado. Duración máxima para la realización de la evaluación, la cual está determinada por el tiempo exigido para la culminación del trabajo de grado. Disponibilidad del ambiente requerido para realizar la evaluación, constituida por el tiempo y la atención prestada por el equipo desarrollador de software en la organización donde se realizará la evaluación. 5. Definir las escalas de tiempo y esfuerzo requerido: Para Kitchenham et al. (1996), es necesario especificar las actividades que se realizarán para completar el proceso de evaluación y el tiempo estimado que se dedicará a cada actividad, a continuación se presentan dichas actividades: Elaboración del plan de evaluación: 1 día Elaboración de los instrumentos de evaluación: 8 días Solicitud y aprobación del proceso de evaluación por parte de la organización: 5 días. Evaluación y ponderación de las características: 6 días Elaboración de conclusiones y recomendaciones a la empresa: 5 días 83

92 Capitulo VII Evaluación de propuesta 6. Aplicar el procedimiento de evaluación seleccionado: Una vez desarrollados los pasos generales correspondientes al Análisis de las Características, se procedió con los pasos del proceso relativo al Estudio de Caso mostrado anteriormente en la Figura 6.1. Estudio de Caso En la presente sección son detalladas los pasos que se llevaron a cabo durante el Estudio de Caso: 1. Seleccionar la herramienta a evaluar En este caso la herramienta está representada por el modelo de especificación de calidad para la arquitectura de Web Services, el cual propone un conjunto de objetivos arquitectónicos que deben ser satisfechos por la arquitectura para Web Services a fin de propiciar altos niveles de calidad. 2. Identificar el conjunto de características que permiten la evaluación Para poder evaluar de una forma efectiva el modelo de especificación de calidad, fue necesario establecer un conjunto de aspectos a evaluar que van desde lo más general a lo más específicos. Según Kitchenham et al. (1996) estos aspectos son llamados características y los dividen en dos tipos: Simples: cuando el aspecto a evaluar se encuentra presente o ausente en el contexto de evaluación, esto es determinado mediante una escala nominal (Si, No). Compuestas: cuando la existencia o conformidad del aspecto evaluado puede ser medido por una escala ordinal. Para efectos de está evaluación se utilizaron sólo características simples para obligar al evaluador a establecer un criterio claro de aceptación (Ver Tabla 7.1). 84

93 Capitulo VII Evaluación de propuesta Escala 1: Significa que el modelo o métrica tiene el criterio establecido. 0: Significa que el modelo o métrica no cumple el criterio establecido. TABLA 7.1: Escala utilizada para evaluar los criterios FUENTE: Elaboración propia Las características más generales evalúan el modelo a un nivel macro, su definición conceptual se presenta en la Tabla 7.2 Características generales Descripción Pertinencia del modelo Se refiere a si el modelo de especificación de calidad corresponde para la WSA Completitud de las características involucradas Se refiere si las características de calidad: Funcionalidad, Usabilidad, Eficiencia, Mantenibilidad, Portabilidad y Fiabilidad dan cobertura total a las decisiones arquitectónicas para la calidad de la WSA Adecuación al contexto Se refiere a si el modelo se adapta al contexto de evaluación. Precisión del nivel de análisis especificado por el modelo Se refiere si el nivel de análisis del modelo en el proyecto piloto fue determinante. Entendimiento del modelo Se refiere a la facilidad de aprendizaje del modelo. Consistencia Interna Se refiere a la coherencia entre los componentes del modelo. Apropiado a la audiencia Se refiere al nivel de detalle presentado en la descripción del modelo. Organización del modelo Evaluar el orden de las ideas planteadas en el modelo. Legibilidad de los planteamientos Indica el nivel de redacción de las ideas planteadas. Facilidad de implementación Se refiere a la facilidad de implementación de las recomendaciones del modelo. Aceptación de resultados Aplicable a la habilidad del modelo para producir resultados esperados. Relevancia de resultados Indica si los resultados del modelo fueron importantes para su consideración en la arquitectura. Utilización de los resultados Se refiere al aprovechamiento de los resultados del modelo. Soporte para la toma de decisiones Indica si los resultados del modelo sirven de soporte para la toma de decisiones. Costo-Efectividad Se refiere si el costo de aplicar el modelo se compensa con la efectividad del mismo. TABLA 7.2: Características generales a evaluar para el modelo de especificación de calidad FUENTE: Adaptado de Kitchenham et al. (1996) 85

94 Capitulo VII Evaluación de propuesta Una vez identificadas las características generales, fue necesario establecer un conjunto de características específicas que permitan evaluar las métricas del modelo. Las características a considerar se presentan en la Tabla 7.3 Característica específica Descripción Pertinencia de la métrica Se refiere si la métrica es adecuada para medir la existencia o no de la característica donde se encuentra Factibilidad de la métrica Se refiere si es factible medir la característica propuesta en la métrica dentro del contexto de evaluación Nivel de profundidad de la métrica Se refiere a si la métrica a verificar tiene el nivel de profundidad adecuado para que el resultado sea relevante Escala de la métrica Se refiere a si la escala propuesta es adecuada para medir la métrica TABLA 7.3: Características específicas a evaluar para el modelo de especificación de calidad FUENTE: Adaptado de Perez et al. (2005) Establecidas las características generales y específicas a aplicar para evaluar el modelo de especificación de calidad para la WSA, se hizo necesario plantear el criterio de aceptación. Dicho criterio es mencionado a continuación: Para que el modelo de calidad se considere aceptable, el 75% o más de las características generales deben ser aceptables. Para que una característica general se considere aceptable, debe obtener el 75% o más del promedio de todas las respuestas positivas por parte de los evaluadores. Para que una métrica se considere aceptable debe tener el 75% o más del promedio de todas las respuestas para dicha métrica. Culminado el paso de identificación de las características que permitieron la evaluación y una vez establecido el criterio de aceptación a utilizar, se da por culminado el paso 2 del estudio de caso. Siguiendo con los pasos mostrados en la Figura 6.1, a continuación se procedió con la selección del proyecto piloto. 86

95 Capitulo VII Evaluación de propuesta 3. Seleccionar el proyecto piloto El siguiente paso dentro del proceso que se debe seguir para realizar el Estudio de Caso fue la selección de un proyecto. Para está selección se utilizaron los siguientes criterios: El tamaño de la organización debe ser medio, como mínimo. El proyecto debería ser de alta relevancia para la organización. Se requiere que el proyecto haya sido desarrollado por al menos dos personas. La organización debería estar dispuesta a colaborar a lo largo de la aplicación del modelo de especificación de calidad para la arquitectura de Web Services y del posterior proceso de evaluación. De acuerdo a estos criterios se seleccionó una empresa dedicada a las Telecomunicaciones en Venezuela, con más de 12 años de experiencia, que ha logrado obtener un posicionamiento en el mercado gracias al ofrecimiento constante de nuevos productos y servicios a sus clientes, incluyendo dentro de estos, el autoservicio, a través de un portal Web. Por razones de confidencialidad está empresa se mantendrá en anonimato. El proyecto seleccionado corresponde a la implementación de un Web Services que es invocado por medio de una aplicación Web que facilita la autogestión de los clientes, esta aplicación permite la creación de cuentas y activación de líneas celulares a través de una opción en el portal Web de la organización. La plataforma tecnológica utilizada por la empresa para la implementación de Web Services está basada en Oracle Jdeveloper 10g y su arquitectura es mostrada en la Figura 7.1. El equipo del proyecto está conformado por dos desarrolladores y un líder de proyecto. 87

96 Capitulo VII Evaluación de propuesta FIGURA 7.1: Arquitectura para Web Services de la empresa FUENTE: Elaboración propia Con la aplicación del modelo de especificación de calidad para la WSA, la empresa espera contar con una evaluación de calidad cualitativa sobre su arquitectura que le facilite la toma de decisiones pertinentes a fin de aumentar su nivel de calidad en la implementación de los Web Services, y por consiguiente, ofrecer una mejor calidad de servicio a sus clientes. A continuación se procederá con la prueba del modelo de especificación de calidad sobre el proyecto piloto, paso 4 del estudio de caso (Figura 6.1) 4. Probar el modelo en el proyecto piloto Para realizar está prueba se elaboró un cuestionario. Este cuestionario está divido en tres partes, la primera contiene 4 métricas y es utilizado para validar que efectivamente el modelo sea aplicado sobre una WSA, considerando la presencia de las tecnologías estándares; la segunda parte, presenta una ficha técnica del proyecto donde se describen aspectos generales del mismo; y la tercera parte, contiene las 95 métricas que permitirán analizar la calidad de la arquitectura del proyecto piloto (Anexo D) 88

97 Capitulo VII Evaluación de propuesta Los encargados de realizar la prueba del modelo sobre el proyecto piloto fueron asignados por la Gerencia de Desarrollo de Aplicaciones de la empresa de Telecomunicaciones con apoyo del Coordinador responsable de la evaluación. La aplicación de los cuestionarios se llevó a cabo en las instalaciones de la empresa. Con relación a los resultados de probar el modelo de especificación de calidad en el proyecto piloto, se determinó en primer lugar, que la arquitectura evaluada es propia para Web Services debido a que esta conformada por los componentes estándares: Transporte, Mensajería, Descubrimiento y Descripción, los cuáles representan la mínima expresión de la arquitectura para Web Services. En segundo lugar, el análisis arrojado por el modelo determinó que la característica de funcionalidad está presente en 23,13%, obtenidos gracias a la presencia de las subcaracterísticas Adecuación (45,83%), Interoperabilidad (30%) y Seguridad (16,67%); mientras que Fiabilidad se encuentra presente en 33,33%, con sus subcaracterísticas madurez (100%) y tolerancia a fallos (33,33%). Por otro lado se detectó la presencia de la característica Eficiencia con 25%, dado la existencia de su subcaracterística utilización de recursos (25%); mientras que la característica de Mantenibilidad arrojó un 50%, con su subcaracterística estabilidad (100%). El detalle de los resultados de está evaluación es presentado en el Anexo F. En tercer lugar, se detectaron los puntos de sensibilidad que inhiben la arquitectura de Web Services y castigan algunas características y subcaracterísticas de calidad, entre ellas: Funcionalidad con la subcaracterística seguridad y Eficiencia con la subcaracterística tiempo de desempeño. La ausencia de las decisiones arquitectónicas mostradas en la Tabla 7.4 inhiben las mencionadas subcaracterísticas. 89

98 Capitulo VII Evaluación de propuesta Funcionalidad/ Implementación de políticas de aserciones Seguridad Garantizar la integridad end to end del Web Services Facilitar la especificación de reglas y sintaxis de firmas digitales en ML Permitir la definición de escenarios de confianza entre varios Web Services Eficiencia/ Tiempo de desempeño Soporte a mecanismos para consultas de un nodo SOAP a otro nodo SOAP Capacidad para definir un protocolo de múltiples descubrimientos simultáneos. Soportar especificaciones sobre patrones de múltiples descubrimientos. Facilitar el encapsulamiento de datos binarios o archivos multimedia en un mensaje. TABLA 7.4: Puntos de sensibilidad identificados por características de calidad FUENTE: Elaboración propia En cuarto lugar, se identificó como trade off que la arquitectura propicia mantenibilidad pero castiga la eficiencia, esto se debe ante la necesidad de satisfacer algunos requerimientos específicos de la organización, tales como: facilidad para aplicar constantes cambios sin impactar la estabilidad de la aplicación. Este requerimiento es soportado gracias al continuo encapsulamiento de los componentes arquitectónicos, sin embargo, este encapsulamiento afecta fuertemente la desempeño del Web Service. Se recomienda entonces, incorporar algunos componentes arquitectónicos de seguridad en la mensajería, configuración de rutas, encapsulamiento de datos binarios o archivos multimedias, enrutamiento del mensaje y patrones de descubrimiento que puedan mitigar las debilidades de seguridad y eficiencia, habilitando a la WSA para soportar las decisiones arquitectónicas planteadas en la Tabla 7.4, y garantice la implementación de Web Services seguros, capaces de integrar aplicaciones tanto internas como externas a la organización con altos niveles de confianza y desempeño 90

99 Capitulo VII Evaluación de propuesta Una vez evaluado el modelo de especificación sobre el proyecto piloto, se continuó con el paso 5 del proceso de evaluación. 4. Asignar puntuación a las características a evaluar El próximo paso del proceso que se debe seguir para realizar el Estudio del Caso es la asignación de puntuación a las características a evaluar (ver Figura 6.1). Para la recolección de los datos necesarios en este paso se preparó un cuestionario (Anexo E), el cual permitió evaluar el modelo de especificación de la calidad para la WSA en el contexto existente. Este cuestionario consta de dos partes, la primera parte, evalúa las características generales del modelo, y la segunda parte, evalúa las características específicas sobre las métricas utilizadas en todos los cuestionarios. El fundamento de está evaluación consistió en que el personal ejecutor fue el mismo que participó en la aplicación del modelo de especificación de calidad para la WSA sobre el proyecto piloto, está interacción les ha preparado para realizar la evaluación en el contexto existente. Una vez recolectados los datos se procedió a realizar un análisis del resultado obtenido, el cual se presentará en la sección de Resultados. Con la recolección de los datos se completó la primera actividad de la fase Evaluar correspondiente a la actividad 8 del framework metodológico y se da inicio a la segunda actividad: Análisis de resultados. 5. Análisis de resultados y Preparar reporte de evaluación Este es el último paso del proceso de estudio del caso (ver Figura 6.1) el cual corresponde al análisis de los resultados obtenidos en la evaluación de las características generales descritas en el paso 2. 91

100 Capitulo VII Evaluación de propuesta Con relación a la evaluación de las características generales del modelo de calidad propuesto, los resultados son los siguientes: a. Resultado general de la evaluación del modelo de especificación de calidad para la arquitectura de Web Services. La Figura 7.2 muestra el resultado con relación a las características generales utilizadas para la evaluación del modelo. FIGURA 7.2: Resultados de las características generales de la evaluación FUENTE: Elaboración propia Cómo puede observarse en la Figura 7.2 los resultados obtenidos de la aplicación del cuestionario referente al modelo de calidad (Anexo E) determinaron el 100% de aceptación en cada una de las características generales evaluadas por los participantes. Para todas las características de calidad evaluadas en el modelo de manera general se obtuvo que las mismas eran pertinentes, completas en cuanto a las decisiones arquitectónicas que fueron consideradas, adecuadas al contexto, con un nivel de detalle necesario. En cuento al uso del modelo, manifestaron que este fue de fácil entendimiento, consistente, apropiado al nivel de experticia; sus preguntas estaban 92

101 Capitulo VII Evaluación de propuesta ordenadas y bien redactadas, lo que facilitó la legibilidad y análisis del cuestionario de evaluación. Por otro lado, con relación a los resultados arrojados del modelo, fue manifestada la aceptación de las recomendaciones, las cuáles tomarán en consideración para la toma de decisiones y podrán ser implementadas a mediano plazo. De esta manera, esperan obtener resultados efectivos sobre los costos asociados a la evaluación de su arquitectura. Con base a los resultados obtenidos de las características generales anteriores y tomando en cuenta que el criterio de aceptación establecido es del 75% se considera entonces que el modelo de calidad es aceptable, respecto a la evaluación llevada a cabo en la empresa. b. Resultados específicos de la evaluación del modelo de especificación de calidad para la arquitectura de Web Services. La Figura 7.3 muestra el resultado de la evaluación en base a todas las métricas planteadas en el modelo. FIGURA 7.3: Resultados de las características específicas de la evaluación FUENTE: Elaboración propia Como puede observarse en la Figura 7.3, todas las métricas fueron 100% conformes con el nivel de aceptación, es decir, los evaluadores consideraron que al menos el 75% de las métricas planteadas en el modelo son pertinentes en cuanto al 93