Proceso para el desarrollo de servicios web

Texto completo

(1)INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY Campus Ciudad de México. Escuela de Graduados en Ingeniería y Arquitectura Maestría en Ciencias Computacionales. PROCESO PARA EL DESARROLLO DE SERVICIOS WEB. TESIS. Blblloteca. QUE PARA OBTENER EL GRADO DE. cae•~•--=<>. MAESTRA EN CIENCIAS COMPUTACIONALES. PRESENTA:. LA LIC. CLAUDIA HERNÁNDEZ GONZÁLEZ. DIRECTOR DE TESIS: DR. BÁRBARO JORGE FERRO CASTRO. MÉXICO D.F.. 2004.

(2) Resumen Con los nuevos requerimientos tecnológicos en la industria de Software y el incremento en la complejidad del desarrollo de aplicaciones, surge la necesidad de desarrollar productos de Software de alta calidad, que garanticen la satisfacción del cliente y que sean desarrollados en tiempo y costo; por lo que se requiere contar con proce-sos y metodologías adecuadas para este fin.. Actualmente, existen procesos de desarrollo de Software que consideran diferentes tipos de proyectos para implementar aplicaciones de diferentes dominios, sin embargo, los procesos no siempre responden a los cambios tecnológicos, dejando fuera aspectos técnicos de las nuevas tecnologías, y que son necesarios para realizar la programación de las aplicaciones. Tal es el caso de los Servicios Web, tecnología reciente que muchas compañías están adoptando para integrar sus sistemas.. Para desarrollar una aplicación basada en esta tecnología y teniendo un proceso definido, este se puede adecuar, o utilizar un proceso para implementar un proyecto basado en componentes como RUP (Rational Unified Process), pero en este caso, el proceso no toma en cuenta algunas consideraciones especiales de los Servicios Web, ya que por ejemplo, un componente es ejecutado normalmente dentro de la misma infraestructura de la compañía que donde es ejecutada la aplicación, pero un Servicio Web puede ser ejecutado remotamente y bajo ciertas condiciones de seguridad y esto no es considerado en el tipo de proyecto basado en componentes de RUP.. En este trabajo se plantea un proceso para el desarrollo de Servicios Web, tomando como referencia CMM (Capability Maturity Model), RUP y estándares de Servicios Web con base en los documentos de la W3C (World Wide Web Consortium) publicados el 11 de Febrero de 2004. Como resultado de este trabajo, se cuenta con un proceso de desarrollo de Software que considera tanto el ciclo de vida del proceso de desarrollo de servicios, como los aspectos técnicos de la tecnología de servicios Web. Como conclusión se presentan resultados de la utilidad del proceso propuesto a través de la implementación de un caso de estudio..

(3) Abstract With the advance in the Software technology as well as the increase in the complexity of the applications development; there is a need to develop high quality Software products which ensure customer satisfaction, these products need to be developed within budget and schedule; therefore, there is a need to have processes and methodologies in order to deliver reliable and usable Software.. Nowadays, there are ad hoc and commercial software processes like RUP (Rational Unified Process), that are useful to implement systems in different domains, however, these processes not always respond to the technological changes, and do not consider technical aspects of the new technologies, which are necessary for the application development.. Web Services is a recent technology that many companies are using in order to integrate their systems. To develop an application using these technology and following a defined process we can tailor the process according to the application and technology needs, or like in the RUP case, using templates for a project development based in components technology, but in these case, the RUP process for these kind of projects do not contemplate special considerations of the Web Services technology such as security conditions, remote access, network framework. Although Web Services can be implemented with the components technology, there are differences to be considered in the process, for example, a component is usually executed in the same company framework where the application that use the component is executed. However, a Web Service can be executed remotely and under security conditions, and these kind of aspects are not considered in the RUP process for components based applications.. As a result of this work we have a software development process that considers both, the service development process life cycle and the technical aspects of the Web Services technology; the process is proposed considering as reference CCM (Capability Maturity Model), RUP and the Web Services standards based on the W3C (World Wide Web Consortium) documents published on February 11 th 2004. As conclusion of this thesis, the result of the proposed process usefulness is presented trough a study case implementation.. lll.

(4) Contenido LISTA DE TABLAS. IX. LISTA DE FIGURAS. X. INTRODUCCIÓN. Xlll. Antecedentes ................................................... ..................................................... .. Xlll. Definición del problema ...................................................................................... .. XIV. Objetivos .............................................................................................................. .. XV. Justificación .................................................................. ....................................... .. xvu. Metodología ......................................................................................................... .. xvm. Descripción de capítulos de la tesis ..................................................................... .. XIX. l. ESTADO DEL ARTE. 1. 1.1 Procesos de desarrollo de Software .............................................................. ... 1. 1.1.1 CMM ............................................................................................... .. 3. 1.1.2 RUP ................................................................................................ ... 7. 1.2 Servicios Web ................................................................................................ .. 13. 1.2.1 Escenarios ................................................... .... .. ............................ ... 21. 1.2.2 Metas y Requerimientos ..................................... .. ........................... .. 34. 41. 2. DEFINICIÓN DEL PROCESO 2.1 Estructura del proceso ................................................................................ .... .. 41. 2.2 Etapas ............................................................................................................. .. 46. 2.2.1 Etapa Definición .............................................................................. .. 49. 2.2.2 Etapa Diseño ............................................................................... ... .. 52. 2.2.3 Etapa Construcción ........................................................................ .. 56. 2.2.4 Etapa Liberación ............................ ............................................... ... 60. 2.3 Actividades .................................................................................................... .. 65. 2.3.1 Planeación....................................................................................... .. 65. 2.3.1.1 Documento Plan del proyecto .......................................... .. 65. V.

(5) CONTENIDO. Vl. 2.3.1.2 Documento Administración de Riesgos .......................... ... 68. 2.3.2 Requerimientos ............................................................................... .. 69. 2.3.2.1 Documento Requerimientos del Sistema.............. ........... .. 69. 2.3.3 Análisis ......................................................................................... ... 71. 2.3.3.1 Documento Casos de uso del sistema.............................. .. 71. 2.3.3.2 Documento. Diagrama de casos de uso ............................ .. 72. 2.3.3.3 Documento Especificación de Servicios Web ................. .. 73. 2.3.4 Diseño ............................................................................................. .. 76. 2.3.4.1 Documento Arquitectura del Sistema.............................. .. 76. 2.3.4.2 Documento Diseño del Sistema....................................... .. 77. 2.3.4.3 Documento Detalle de Servicios Web ............................. .. 79. 2.3.5 Codificación .................................................................................... .. 81. 2.3.5.1 Documento Documentación para usuarios del código .... ... 81. 2.3.5.2 Documento Documentación del código ........................... .. 82. 2.3.6 Pruebas ................... ......................................................................... .. 84. 2.3.6.1 Documento Consideraciones de pruebas para Servicios. Web .................................................................................. .. 84. 2.3.6.2 Documento Casos de prueba............................................ .. 86. 2.3.7 Puesta en Marcha ............................................................................ .. 87. 2.3. 7 .1 Documento Archivos Liberados ....................................... .. 88. 2.3.8 Administración de Cambios y configuración ................................. ... 89. 2.3.8.1 Documento Plan de configuración ................................... .. 89. 2.3.8.2 Documento Petición de cambios ...................................... .. 91. 2.4 Roles ......................................................... ..................................................... .. 94. 2.4.1 Administrador de Proyectos ............................................................ .. 94. 2.4.2 Administrador de Configuración ................................................. .. .. .. 95. 2.4.3 Arquitecto de Software .............................................. ........... .......... .. 96. 2.4.4 Auditor de calidad ....................................................... .................... .. 97. 2.4.5 Desarrollador de Software ......................................... ...................... .. 97. 2.4.6 Probador de Software .................................................................. .... .. 98. 2.5 Calidad ............................................... ............................................. .. ...... .... .. ... 99.

(6) CONTENIDO. Vll. 2.5.1 Administración de configuración .................................................... .. 99. 2.5.2 Administración de cambios ............................................................. .. 99. 2.5.3 Revisión y aprobación de documentos .............................................. 100. 2.5.3.1 Documento Revisión de documentos .............................. ... 100. 2.5.4 Verificación de fin de etapa............................................................ .. 102. 2.5.5 Validación del proyecto .................................................................. .. 102. 2.5.5.1 Documento Validación de proyecto ................................. .. 102. 3.- DESARROLLO DEL CASO DE ESTUDIO. 105. 3.1 Etapa Definición ............................................................................................ .. 106. 3.1.1 Plan del proyecto del Agente de viajes ........................................... .. 106. 3.1.2 Documento para la administración de riesgos del Agente de viajes. 109. 3 .1.3 Plan de configuración para el Agente de viajes .............................. .. 109. 3.1.4 Requerimientos del Agente de viajes .............................................. .. 111. 3.1.5 Casos de uso del Agente de viajes ................................................. ... 114. 3. 1. 6 Diagrama de Casos de uso .............................................................. .. 118. 3. l. 7 Especificación del servicio Agente de viajes ................................. ... 119. 3 .1.8 Documento de fin de etapa de definición del servicio Agente de. VIaJeS................................................................................................ 121. 3.2 Etapa Diseño................................................................ .................................. .. 122. 3.2.1 Arquitectura para el Agente de viajes.............................................. 3.2.2 Documento de Diseño para el Agente de viajes.............................. 3.2.3 Detalle del servicio Agente de viajes............................................... 3 .2.4 Casos de prueba para el Agente de viajes........................................ 3.2.5 Documento de Fin de etapa diseño del servicio Agente de viajes.... 122 124 130 13 8 141. 3 .3 Etapa Construcción.......................................................................................... 142. 3.3. l Documento de fin de la etapa de Construcción del servicio Agente de viajes....................................................... ............................................... 142. 3 .4 Etapa Liberación.............................................................................................. 143. 3.4.1 Casos de prueba del servicio Agente de viajes................................. 143. 3.4.2 Documento de archivos liberados del servicio Agente de viajes...... 143. 3.4.3 Documento de fin de la etapa de Liberación del servicio.

(7) CONTENIDO. Vlll. Agente de viajes .............................................................................. . 3.4.4 Documento de validación del proyecto del servicio Agente de. 144. v1aJes ............................................................................................... .. 145. 3.4.5 Petición de cambios ......................................................................... .. 146. 4.- RESULTADOS DE LA APLICACIÓN DEL PROCESO. 147. 4.1 Ventajas de la propuesta de proceso .............................................................. .. 147. 4.2 Etapa Definición ............................................................................................ .. 149. 4.3 Etapa Diseño ................................ .................................................................. .. 150. 4.4 Etapa Construcción ........................................................................................ .. 151. 4.5 Etapa Liberación ............................................................................................ .. 151. 4.6 Limitaciones .................................................................................................. .. 152. 4. 7 Resumen ............................................................................................ ............. .. 152. 5.-CONCLUSIONES Y TRABAJOS FUTUROS. 155. 5.1 Conclusiones ........................................... ....................................................... .. 155. 5.2 Trabajos futuros ............................................................................................. .. 161. APÉNDICE. 163. BIBLIOGRAFÍA. 165. GLOSARIO. 167.

(8) Lista de Tablas 2.1.1 Actividades, tareas y plantillas de la etapa Definición................................................. 43. 2.1.2 Actividades, tareas y plantillas de la etapa Diseño....................... ................................ 44. 2.1.3 Actividades, tareas y plantillas de la etapa Construcción............................................. 45. 2.1.4 Actividades, tareas y plantillas de la etapa Liberación................................................. 46. 2.2.1 Documentos de entrada y salida de la etapa de Definición.......................................... 49. 2.2.2 Documentos de entrada y salida de la etapa de Diseño................................................ 53. 2.2.3 Documentos de entrada y salida de la etapa de Construcción...................................... 57. 2.2.4 Documentos de entrada y salida de la etapa de Liberación.......................................... 61. 2.4.1 Responsabilidades del Administrador del Proyecto..................................................... 94. 2.4.2 Responsabilidades del Administrador de Configuración............................................. 95. 2.4.3 Responsabilidades del Arquitecto de Software............................................................ 96. 2.4.4 Responsabilidades del Auditor de Calidad................................................................... 97. 2.4.5 Responsabilidades del Desarrollador de Software........... ............................................ 97. 2.4.6 Responsabilidades del Probador de Software............................................................... 98. IX.

(9) Lista de Figuras 1.1.1 Estructura de CMM..................................................................................................... 3. 1.1.2 Estructura del proceso RUP (Rational Unified Process) ............................................ 8. 1.2.1 Intercambio de mensajes entre Servicios Web............................................................ 16. 1.2.2 Arquitectura de Servicios Web por roles..................................................................... 18. 1.2.3 Arquitectura de Servicios Web por pila de capas........................................................ 19. 2.1 Estructura del proceso para el desarrollo de Servicios Web........................................... 42. 2.2.1 Actividades por etapas del proceso de desarrollo para Servicios Web....................... 48. 2.2.1. l Flujo de actividades de la etapa Definición.............................................................. 50. 2.2.1.2 Checklist de la etapa Definición............................................................................... 52. 2.2.2.1 Flujo de actividades de la etapa Diseño.................................................................... 54. 2.2.2.2 Checklist de la etapa Diseño..................................................................................... 55. 2.2.3 .1 Flujo de actividades de la etapa Construcción........................................ .................. 58. 2.2.3.2 Checklist de la etapa Construcción........................................................................... 59. 2.2.4.1 Flujo de actividades de la etapa Liberación..................................................... ......... 62. 2.2.4.2 Checklist de la etapa Liberación............................................................................... 64. 2.3.1.1 Plantilla del documento Plan del Proyecto...................................................... ......... 67. 2.3.1.2 Plantilla del documento Administración de Riesgos................................................ 68. 2.3.2.1 Plantilla del documento Requerimientos del Sistema.............................................. 70. 2.3 .3 .1 Plantilla del documento Casos de uso del sistema..................................................... 72. 2.3.3.2 Plantilla del documento Diagrama de Casos de uso.................................................. 73. 2.3.3.3 Plantilla del documento Especificación de Servicios Web............................ ............ 75. 2.3.4.1 Plantilla del documento Arquitectura del Sistema..................... ................................ 77. X.

(10) LISTA DE FIGURAS. x1. 2.3.4.2 Plantilla del documento Diseño del Sistema............................................................. 78. 2.3 .4.3 Plantilla del documento Detalle de Servicios Web.................................................... 81. 2.3.5.1 Plantilla del documento Documentación para usuarios del código........................... 82. 2.3.5.2 Plantilla del documento Documentación del código................................................. 83. 2.3.6.1 Documento Consideraciones de Pruebas para Servicios Web.................................. 85. 2.3.6.2 Plantilla del documento Casos de Prueba.................................................................. 87. 2.3. 7.1 Plantilla del documento Archivos liberados.............................................................. 88. 2.3.8.1 Plantilla del documento Plan de configuración......................................................... 91. 2.3.8.2 Plantilla del documento Petición de cambios............................................................ 93. 2.5.3.1 Plantilla de revisión de documentos......................................................................... 101 2.5 .5 .1 Plantilla de Validación de proyecto.......................................................................... 103.

(11) INTRODUCCIÓN Antecedentes Con la introducción y uso de Internet, cada vez es más frecuente el manejo de transacciones de forma electrónica por lo que actualmente las organizaciones tienen la necesidad de integrar sus sistemas tanto internamente como con sistemas de otras compañías; esta necesidad de integración lleva a las organizaciones a la creación o comunicación de aplicaciones distribuidas, en donde los diferentes usuarios pueden ver las diferentes aplicaciones como una sola teniendo acceso a toda la información. De la necesidad de integrar o comunicar los sistemas surge el requerimiento de que los sistemas sean portables en diferentes ambientes y escalables para que de esta manera las aplicaciones: •. Puedan ser utilizadas por el mayor número de usuarios. •. Tengan mayores niveles de seguridad. •. Se les pueda agregar funcionalidad similar con cambios menores. Al realizar la integración de aplicaciones distribuidas se ha detectado la problemática de tener sistemas operando en diferentes ambientes con diferentes tecnologías, en diferentes plataformas, utilizando diferentes lenguajes de programación. Ademas del incremento en la complejidad de los problemas y los nuevos requerimientos tecnológicos en un mundo competitivo, existe la necesidad de producir el Software bajo parámetros de calidad que garanticen la satisfacción del cliente.. Xlll.

(12) INTRODUCCIÓN. XIV. Los Servicios Web es una alternativa que muchas compañías están adoptando para la integración de sistemas distribuidos y por ser una tecnología reciente surge la necesidad de contar con un proceso para el desarrollo de Servicios Web que sirva para producir Software de alta calidad.. Definición del problema Los Servicios Web es una tecnología reciente que será ampliamente usada ya que se estima que para el año 2007 haya generado 19 billones de dólares [RationalSoftware, 2002]. Además de que esta tecnología esta siendo cada vez más usada [Manes, 2003], los requerimientos que cubre tales como integración de aplicaciones distribuidas, implementación de funciones de misión crítica, operación de forma rápida y precisa y disponibilidad del servicio para todos los usuarios todo el tiempo [Weiser, 2004] son requerimientos que para ser asegurados, es necesario contar con procesos de desarrollo de Software que aseguren que los servicios son desarrollados y puestos en marcha con alta calidad. Actualmente existen procesos para el desarrollo de sistemas de Software como RUP, pero que no considera el desarrollo de aplicaciones basado en Servicios Web. RUP puede ser modificado para desarrollar proyectos basados en servicios, pero esto lleva tiempo de Calidad y procesos de Software [W ei, 2003] y se requiere de personas con conocimiento y experiencia tanto en el proceso a ser modificado como en la tecnología de Servicios Web. En el caso de RUP que tiene adecuado el proceso para diferentes tipos de proyectos, se puede utilizar un tipo de proyecto basado en componentes, sin embargo este tipo de proyecto no considera la forma de modelar la arquitectura basada en servicios ni considera aspectos técnicos de la tecnología como.

(13) INTRODUCCIÓN. XV. XML, WSDL como se indica en [RationalSoftware, 2002], lo que conduce a modificar el proceso para desarrollar aplicaciones basadas en Servicios Web. Con la problemática previamente planteada además de la falta de conocimiento acerca de la tecnología, se tiene la necesidad de contar con un proceso para el desarrollo de Servicios Web, que cubra el ciclo de vida en el desarrollo de sistemas y que contemple los aspectos técnicos de esta tecnología. La idea de realizar esta tesis, es contar con un proceso con el cual se pueda desarrollar aplicaciones basadas en Servicios Web y que no se requiera de ser experto en la tecnología de servicios para poder desarrollar aplicaciones de alta calidad.. Objetivos Contar con un proceso de desarrollo de software para la implementación de Servicios Web, el cual sea fácil de usar, permita una implementación rápida, proporcione una guía en la consideración de aspectos técnicos, de estándares y que contemple el ciclo de vida de desarrollo de aplicaciones basadas en Servicios Web.. El proceso estará definido por medio de plantillas y guías de cómo seguir el proceso, quedando fuera del alcance de esta tesis proveer un software de interacción gráfica para el uso y seguimiento del proceso.. En el flujo del proceso para el desarrollo de Servicios Web se incluyen actividades a realizar de acuerdo a las siguientes áreas clave de proceso: Administración de Requerimientos, Planeación del Proyecto de Software, Seguimiento a los Planes del Proyecto, Aseguramiento de la Calidad del Software, Administración de la Configuración, Enfoque al Proceso de la.

(14) INTRODUCCIÓN. XVI. Organización, Definición del Proceso de la Organización, Ingeniería de Productos de Software, Revisiones de Parejas; que son áreas clave de proceso de CMM de las cuales se hablará posteriormente.. En el proceso se incluye los aspectos a considerar para la implementación de los Servicios Web en cada una de las fases de desarrollo, pero no se incluyen técnicas o métodos para la administración de casos de negocio, administración de requerimientos, análisis, diseño o pruebas del sistema. Así como tampoco técnicas o modelos para la estimación de esfuerzo y costo del proyecto ni tamaño de los productos de software.. Para probar el proceso y obtener resultados de su aplicación, se implementará uno de los casos de estudio que propone la W3C en [He, 2004], en el cual se basa para definir los escenarios y requerimientos para la arquitectura estándar de los Servicios Web.. Para el logro del objetivo principal, se realizarán los siguientes objetivos secundarios:. •. Investigación del estado del arte de procesos de desarrollo de Software. • Investigación de los estándares de Servicios Web • Definición del proceso. •. Planteamiento y desarrollo del caso de estudio siguiendo el proceso propuesto.

(15) INTRODUCCIÓN. xvn. Justificación El trabajo de tesis propuesto tiene una importancia relevante por que la investigación que se realice en el estado del arte tanto de procesos como de estándares de Servicios Web nos llevará a definir y probar un proceso que además de contar con indicadores de calidad para ser un proceso útil y definido, tendrá aspectos técnicos a ser considerados en el desarrollo de Servicios Web.. Teniendo un proceso específico para el desarrollo de Servicios Web las organizaciones o personas que requieran desarrollar Servicios Web, podrían utilizar las plantillas y seguir el proceso que aquí se propone, el cual los guía en una secuencia de pasos por todas las fases del desarrollo de Servicios Web sin importar si están utilizando otro proceso o algún sistema de calidad para el desarrollo de sistemas. Entre los beneficios del proceso se tienen los siguientes: •. Ahorro de tiempo en investigación de procesos y adecuación y cambios a procesos para incluir Servicios Web.. •. Punto de partida en la evaluación de herramientas para la implementación de Servicios Web.. •. Forma estándar de implementar los Servicios Web sin importar la experiencia o nivel del desarrollador.. •. En caso de no contar con un proceso, es un punto de partida para definir un proceso de desarrollo de Software para posteriormente promover una certificación de calidad o nivel de madurez en la organización..

(16) INTRODUCCIÓN. xvm. La implementación del caso de estudio propuesto tiene consideraciones tecnológicas que involucran un amplio conocimiento de los estándares de Servicios Web.. Metodología Para el logro de la meta de esta tesis se utilizará el método "top-down", definiendo un objetivo principal que es la definición del proceso y dividiéndolo en objetivos secundarios como sigue:. En el primer objetivo secundario se realizará la investigación del estado del arte de procesos de desarrollo de Software tomando como base a RUP.. El segundo objetivo secundario es realizar la investigación de los estándares de Servicios Web tomando como marco teórico los estándares definidos por la W3C.. Finalmente se realizará la definición del proceso y se desarrollará el caso de estudio siguiendo el proceso propuesto para obtener y documentar los resultados y las conclusiones de su aplicación..

(17) INTRODUCCIÓN. XIX. Descripción de Capítulos de la Tesis El documento de tesis está dividido en cinco capítulos. El capítulo 1 es un reporte de la investigación realizada sobre el estado del arte de procesos de desarrollo de Software así como de los estándares de Servicios Web y el resultado de esta investigación es usada como referencia para la definición del proceso de desarrollo de Servicios Web. El capitulo 1 está dividido en dos secciones, en la primera se incluye el resultado de la investigación del estado del arte de procesos de Software, se toma como caso específico RUP ya que contempla todo el ciclo de vida en el desarrollo de sistemas de Software y considera el tipo de proyectos basado en componentes el cual provee beneficios para el desarrollo de Servicios Web y en la segunda sección de este capítulo se proporciona un panorama general de los servicios Web y se describen los estándares de ésta tecnología tomando como referencia los estándares definidos por la World Wide Web Consortium o W3C [Booth, 2004]. -versión. publicada el 11 de Febrero de 2004-.. Con base en la investigación realizada tanto en procesos de desarrollo de Software como en estándares de Servicios Web, en el capítulo 2 se define el proceso propuesto para el desarrollo de Servicios Web. El proceso contempla tanto el rol de proveedor de Servicios Web --crear los Servicios Web y ponerlos a disposición para ser usados por alguien más- como el rol de consumidor de Servicios Web -usar Servicios existentes-, donde una organización o persona puede tomar uno o ambos roles. El proceso es definido por medio de guías y plantillas para llevar a cabo cada una de las tareas definidas en el proceso; así mismo, se incluye un diagrama indicando el flujo de las.

(18) INTRODUCCIÓN. XX. actividades del proceso y se incluyen las fases involucradas en el ciclo de vida de los Servicios Web. Como parte del proceso y para garantizar la calidad en el desarrollo del Servicio Web se incluyen: •. Prácticas de revisión de cada documento generado para detectar posibles errores antes de pasar a la fase siguiente.. •. Plantillas de validación en cada fase, para garantizar que se ha seguido el proceso realizando todas las actividades que en él se indican.. •. Guía y plantilla para la administración de configuración para llevar el control de todos los archivos generados en el desarrollo del Servicio Web.. •. Guía y plantilla para la administración de cambios y mantenimiento de Servicios Web.. Una vez que el proceso ha sido definido y con el propósito de probar la utilidad, funcionalidad y uso del proceso propuesto, en el capitulo 3 se describe y se implementa un caso de estudio que involucra el desarrollo de Servicios W eh, el caso de estudio que se implementa en este capítulo es uno de los casos de estudio usado por la W3C para la definición de escenarios y requerimientos de la arquitectura estándar de Servicios Web. Se seleccionó este caso de estudio debido a que es de complejidad alta e involucra consideraciones técnicas significativas en el desarrollo de Servicios Web [He, 2004]. El capítulo inicia con la descripción del caso de estudio, posteriormente se documentan las plantillas siguiendo el proceso para cada fase del desarrollo y finalmente se incluyen algunas evidencias de la fase de la puesta en marcha y funcionamiento del caso de estudio..

(19) INTRODUCCIÓN. XXI. Después de implementar el caso de estudio, en el capítulo 4 se presentan los resultados de la aplicación del proceso al caso de estudio, se habla de los pasos que se siguieron del proceso propuesto, se documentan ventajas y desventajas de seguir el proceso, y se evalúa si la información recabada en la investigación de estándares de Servicios Web es de utilidad durante el desarrollo y si el proceso cumple con los objetivos establecidos al inicio de la tesis.. Finalmente se presentan las conclusiones de la presente tesis, así como propuestas de trabajo para el futuro. Este capítulo final está dividido en dos partes, en la primera se habla de las conclusiones de la tesis, haciendo un resumen del trabajo realizado tanto en la parte de investigación como de los resultados de la implementación del proceso, se evalúan los resultados con respecto a los objetivos planteados al inicio de la tesis y se documentan las lecciones aprendidas durante el desarrollo de la tesis. En la segunda parte de este capítulo se presentan algunas, ideas, necesidades y motivaciones del autor de la tesis para continuar con este trabajo tanto en el área de procesos como en el área de Servicios Web..

(20) CAPÍTULO 1 Estado del Arte Este capítulo está dividido en dos partes, en la primera se presenta un reporte de la investigación en el estado del arte de procesos de desarrollo de Software y en la segunda parte la investigación sobre los estándares de Servicios Web.. 1.1 Procesos de desarrollo de Software Iniciamos con la definición de proceso. "Un proceso es una secuencia de pasos a realizar para alcanzar un propósito" [Camegie, 1998]. Y un "proceso de desarrollo de Software es un conjunto de actividades, métodos, prácticas y transformaciones que las personas emplean para desarrollar y mantener software y productos asociados tales como planes de proyecto, documentos de diseño, código, casos de prueba, manuales de usuario, etc" [Camegie, 1998]. El proceso de desarrollo de Software integra personas con habilidades, capacitación y motivación, procedimientos y métodos para la realización de las actividades, así como herramientas y equipo para el desarrollo de Software. En el caso de procesos de desarrollo de Software existen diferentes organizaciones que proporcionan la infraestructura -como CMM e ISO 9001- de lo que debe incluir un proceso de desarrollo de Software, existen también procesos definidos como RUP y metodologías para el desarrollo de Software.. 1.

(21) CAPÍTULO l. ESTADO DEL ARTE. 2. Para esta tesis se ha seleccionado CMM (Capability Maturity Model) por que describe las características esperadas de un proceso de Software aunque no describe como implementarlo. Así como RUP que es un proceso de Software que cubre el ciclo de vida completo [Pollice,2003] en el desarrollo de Software..

(22) CAPÍTULO l. ESTADO DEL ARTE. 3. 1.1.1 CMM. Es una infraestructura para el desarrollo y mejora de procesos de desarrollo de Software, determina la madurez de los procesos de organizaciones que solicitan evaluar sus procesos a través de CMM, establece metas para la mejora de procesos, asigna prioridades para las acciones de mejora de procesos [Schaeffer, 1998]. CMM está basado en las mejores prácticas de la industria de Software, provee un "benchmark" de la madurez de procesos de Software y es ampliamente usado para definir y evaluar la madurez de. procesos de Software en organizaciones con diferentes dominios. [Herbsleb, 1994]. En CMM la madurez del proceso en una organización está dividida en 5 niveles [Carnegie, 1998] de menor a mayor. En la siguiente figura se ilustra la estructura de CMM.. Niveles de madurez. Áreas clave de proceso proceso Organizadas por Características comunes. Prácticas clave. Actividades o Infraestructura. Figu,ra 1.1.1 -- Estructura de CMM.

(23) CAPÍTULO l. ESTADO DEL ARTE. 4. CMM es un modelo que describe los atributos esenciales que caracterizan a una organización en un nivel de madurez particular, los niveles de madurez indican la capacidad del proceso y están formados por áreas clave del proceso. Las áreas clave del proceso están divididas en 5 bloques que indican las prácticas o conjunto de actividades a ser realizadas dependiendo del nivel de madurez como se muestra a continuación: •. Para organizaciones con nivel de madurez 1, CMM no tiene definidas áreas clave de proceso.. •. En el nivel 2 las prácticas se enfocan en la administración y requerimientos del proyecto. Las prácticas que deben realizarse son las siguientes: 1. Administración de Requerimientos.- En esta práctica se deben establecer los requerimientos para tener un entendimiento común entre el cliente y quienes participan en la realización del proyecto. 2. Planeación del Proyecto de Software.- Establece que deben tenerse planes (de proyecto, calidad, configuración, cambios y pruebas) para la elaboración del proyecto. 3. Seguimiento a los Planes del Proyecto.- Establece que debe darse seguimiento a los planes del proyecto para controlar el progreso del proyecto de Software. 4. Administración de Subcontratistas de Software.- Esta práctica solo aplica para las organizaciones que subcontratan organizaciones externas para desarrollar toda o una parte del proyecto de Software. 5. Aseguramiento de la Calidad del Software.- Establece las actividades a ser realizadas para administrar el proceso usado en la elaboración de proyectos de Software..

(24) CAPÍTULO l. ESTADO DEL ARTE. 5. 6. Administración de la Configuración.- Establece que hay que mantener y controlar la integridad de los productos de Software durante todo el ciclo de vida del proyecto.. •. El nivel 3 está orientado a que el proceso esté definido e institucionalizado, es decir, usado por todos los proyectos que se realicen en una organización y las prácticas que deben cumplirse además de las del nivel 2 son: 1. Enfoque al Proceso de la Organización.- Se describen las actividades y responsabilidades en el proceso. 2. Definición del Proceso de la Organización.- Se definen, desarrollan y mantienen actividades para la mejora del proceso. 3. Programa de Capacitación.- Se definen y se da seguimiento a un plan para la mejora de habilidades y conocimientos de las personas participantes en los proyectos. 4. Administración de la Integración del Software.- Establece las actividades para integrar al grupo de ingeniería y de administración del proceso. 5. Ingeniería de Productos de Software.- Se definen las actividades, metodologías, y estándares, para la implementación del Software (diseño, codificación, pruebas). 6. Coordinación de Grupos.- Establece la integración entre los diferentes grupos de la organización e ingeniería. 7. Revisiones de Parejas.- Se definen las actividades para eliminar errores o defectos de una forma fácil y eficiente de los productos de Software.. •. El nivel 4 se enfoca en establecer un enfoque cuantitativo tanto del proceso como los productos de Software, en este nivel las prácticas clave del proceso son: 1. Administración Cuantitativa del Proceso.- En esta práctica se da seguimiento al desempeño del proceso..

(25) CAPÍTULO J. ESTADO DEL ARTE. 6. 2. Administración de la Calidad del Software.- Establece contar con un entendimiento cuantitativo de la calidad de los productos de Software. •. El nivel 5 cubre aspectos tanto de la organización como de los proyectos, se enfoca a la mejora continua del proceso de Software y tiene las siguientes áreas clave de proceso: 1. Prevención de Defectos.- Se identifican causas raíz de los defectos para poder prevenirlos. 2. Administración de Cambio de Tecnología.- Se identifican beneficios de las nuevas tecnologías. 3. Administración de Cambio de Proceso.- Establece las actividades para la mejora continua del proceso para incrementar la productividad en el desarrollo de Software.. Cada área clave del proceso está formada por las siguientes características comunes que sirven para la implementación o institucionalización de la práctica:. • Compromiso a desempeñar.-Aquí se definen las acciones que define la organización para la realización de la práctica. Como por ejemplo, establecer un grupo para la administración de proyectos, etc.. • Habilidad a desempeñar.- Son las precondiciones que deben existir para desempeñar la práctica, por ejemplo que las personas cuenten con las habilidades y conocimientos para realizar una actividad específica por ejemplo de pruebas, codificación o administración de proyectos. •. Actividades realizadas.- _Se establecen roles y responsabilidades y acciones para llevar a cabo la práctica.. • Análisis y medición.- Se definen las métricas que se colectarán para controlar la práctica..

(26) CAPÍTULO l. ESTADO DEL ARTE. 7. • Verificando la implementación.- Se describen los pasos para asegurar que las actividades son realizadas de acuerdo al proceso establecido.. 1.1.2 RUP. Es un proceso de ingenieria de Software basado en el ciclo de vida iterativo, ingeniería de Software orientada a objetos y en las mejores prácticas de la industria del Software para orientar en las actividades de desarrollo de Software [Pollice, 2003] por medio de guías, plantillas y herramientas para las diferentes fases del desarrollo de sistemas.. La estructura de RUP está dividida en dos dimensiones, una horizontal llamada fases que es la dimensión del tiempo la cual muestra el progreso del proyecto en un determinado tiempo y la dimensión de contenido en el eje vertical llamada Disciplinas que describe las actividades a ser realizadas en el proyecto. La siguiente figura ilustra las dos dimensiones de RUP..

(27) 8. CAPÍTULO l. ESTADO DEL ARTE. Fases Disciplinas. Modelo del Negocio. 1. Inicio. Elaboración. 11. Construcción. 11. ----. /. Transición. 11. --. '. Requerimientos Análisis y Diseño Implementación Pruebas Puesta en marcha Administración de Cambios y Configuración Administración de Proyectos. .. :. :. /. Ambiente ~-In-i-ci_a_l~. i8abl l8abl ¡cons 1 ¡cons 1 ¡cons ¡Tran IITran L.!l..JLJgj. 1. 1. 2. n. #1. 1. #2. Iteraciones Figura 1.1.2-Estructura del proceso RUP (Rational Unified Process) [Rational,2002]. Las fases están divididas en cuatro: Inicio, Elaboración, Construcción y Transición y se llevan a cabo de forma iterativa dependiendo de la naturaleza del proyecto, es decir, un proyecto puede tener una o más repeticiones de las 4 fases del proceso. Cada fase tiene una meta que tiene que ser cumplida al final de la misma, por ejemplo al final de la fase de inicio se tiene que tener establecido el objetivo o visión del proyecto, en el cual se establecen los requerimientos, restricciones, características, riesgos y límites del proyecto, el plan de desarrollo del proyecto y las herramientas y estándares a usar en la implementación. En la fase de Elaboración al final se tiene que tener la arquitectura del sistema, el modelo de diseño, los casos de uso, el modelo de datos, así como especificaciones y.

(28) CAPÍTULO l. ESTADO DEL ARTE. 9. herramientas a usar en la fase de construcción. En la fase de Construcción se implementa el sistema y al final se debe tener el sistema ejecutable listo para iniciar con las pruebas. En la fase de transición se libera el producto y al final se debe tener el sistema a liberar junto con sus notas de liberación, documento de instalación, material de capacitación así como material de soporte para el usuario. Durante cada fase del proceso se actualizan los documentos que se utilizan durante el ciclo de vida del proyecto tales como, plan del proyecto, lista de riesgos, plan de iteración, caso de desarrollo, plan de configuración, etc. Las disciplinas son las actividades a realizar durante el desarrollo del sistema y en cada una se producen documentos que avalen la realización de la actividad. Las disciplinas en RUP son Requerimientos, Análisis y Diseño, Implementación, Pruebas, Puesta en marcha, Administración de cambios y configuración, Administración del proyecto, ambiente y modelado de negocios. Cada disciplina tiene un flujo de trabajo en el cual se realizan las actividades para producir los artefactos o documentos siguiendo una serie de plantillas o herramientas del proceso. Para la realización de las actividades, en el proceso están definidos roles los cuales establecen claramente mediante un flujo, las actividades y responsabilidades de una persona que tome el rol en el proceso. Existen diferentes roles para cada disciplina y una persona puede tomar diferentes roles, los roles están agrupados en Analistas, Desarrolladores, Probadores, Administradores y otros roles, y estos grupos a su vez están divididos en roles específicos tales como. Analista del sistema, Arquitecto de Software, Diseñador, Ingeniero del proceso,. Administrador del proyecto, Especialista de herramientas, etc..

(29) CAPÍTULO l. ESTADO DEL ARTE. 10. El proceso RUP está basado en las meJores prácticas de desarrollo de Software [Pollice,2003] y son las siguientes: •. Desarrollo iterativo.- Consiste en diferentes iteraciones en donde los elementos son integrados progresivamente, el cambio a requerimientos se incluye en alguna de las iteraciones, incrementa el reuso y permite la mejora y refinamiento del producto.. •. Administración de requerimientos.- En esta práctica se deben definir, documentar, organizar y darle seguimiento a los requerimientos del producto de software.. •. Arquitectura basada en componentes.- Esta práctica tiende a reducir el tamaño y complejidad de la solución.. •. Modelo Visual.- RUP enfatiza la creación y mantenimiento de modelos y técnicas orientadas a objetos por medio de UML (Unified Modeling Language) [Booch,2001], para ayudar al equipo del proyecto a visualizar, construir, documentar la estructura y comportamiento del sistema, entender como interactúan los componentes e identificar defectos.. •. Verificación de calidad.- Administración de calidad a través de todo el ciclo de vida del proyecto. Incluyendo calidad en el producto, en el servicio y en el proceso. Se deben tener criterios de calidad y métricas que proporcionen información para mejorar la elaboración el producto. En RUP la calidad se administra por medio de las guías, "checkpoints", plantillas y actividades para todas las disciplinas del proceso.. •. Administración de cambios.- Esta práctica se tiene durante todo el ciclo de vida del proyecto, facilita la comunicación y ayuda a mantener el monitoreo de los cambios. Se debe tener un plan desde la fase de inicio y se deben documentar todos los cambios a cualquier documento..

(30) CAPÍTULO l. ESTADO DEL ARTE. 11. RUP también está definido con base en los principios básicos de un proceso de Software efectivo entre los cuales se encuentran: 1. Visión.- Que indica contar con documentos que describan hacia donde va el producto, tales como casos de uso, casos de negocio, enunciado del problema, etc. 2. Plan.- Este principio indica que hay que tener planes para darle seguimiento al progreso del proyecto; entre los planes que incluye RUP se tienen: Plan de administración de requerimientos, Plan de administración de configuración, Plan para resolución de problemas, Plan de aseguramiento de la calidad, Plan de pruebas. 3. Manejo de riesgos.- Identificar desde una fase temprana del proyecto los riesgos que pongan en peligro la liberación del proyecto. 4. Casos de negocio.- Examinar a detalle los caso de negocio incluyendo planes económicos para la realización del proyecto. 5. Arquitectura.- De la misma forma que se mencionó en las mejores prácticas. 6. Prototipos.- Realizar prototipos que ayuden a delimitar el alcance del proyecto, involucrar al usuario en el producto que se tendrá al finalizar el proyecto y detectar riesgos a tiempo. 7. Evaluación.-. Probar los resultados de forma regular. En RUP se realiza después. de cada iteración evaluando si se requiere trabajar en un área específica, evaluando si se cubrieron las metas de acuerdo al plan, etc. 8. Petición de cambios.- De forma similar a la práctica de administración de cambios en este principio se indica que se requiere dar seguimiento, prioridad y controlar los cambios y de esta forma llevar un registro de decisiones..

(31) 12. CAPÍTULO l. ESTADO DEL ARTE. 9. Soporte al usuario.- Este principio se lleva a cabo en la disciplina de puesta en marcha del sistema, se requiere de proporcionar al usuario de un mecanismo por el cual pueda realizar preguntas o tenga ayuda en el momento de no saber como usar el sistema, aquí se debe contemplar la forma en que el usuario pueda obtener ayuda de forma fácil. 10. Proceso.- Contar con un proceso que se pueda adecuar dependiendo de la naturaleza y necesidades del proyecto. Es importante seguir un proceso para facilitar la comunicación entre los miembros del proyecto, así como tener un entendimiento acerca de quienes están realizando qué actividades y cuando.. RUP es un proceso que ha considerando tanto las mejores prácticas como los principios esenciales en el desarrollo de Software, y puede ser utilizado para diferentes tipos de proyecto de Software independientemente del dominio, cada proyecto puede adecuar los documentos que generará para su proyecto como se indica en la disciplina Ambiente,. aunque RUP tiene. definidos los tipos de: proyectos pequeños, practicas ágiles, soluciones e-business, soluciones basadas en componentes y usabilidad. para los cuales existe el proceso a seguir (flujo de. actividades y plantillas que deben ser realizadas por el proyecto). Esto se puede seguir como está indicado en el proceso o también se puede adecuar por el proyecto..

(32) CAPÍTULO l. ESTADO DEL ARTE. 13. 1.2 Servicios Web Esta tecnología es un mecanismo para la integración de aplicaciones que utiliza· las características de la arquitectura orientada a servicios y las combina con las características de la Web. La filosofia de los Servicios Web es tener aplicaciones integradas que puedan ser usadas por quien sea, desde donde sea y con cualquier clase de dispositivos.. Los Servicios Web: •. Son recursos basados en tecnologías Web por lo tanto: o. Pueden ser accedidos usando protocolos Web estándar.. o. Permiten la escalabilidad, simplicidad, diseño modular y descentralización.. o. Son fáciles de usar en interfaces Web.. o. Son aplicables a cualquier tipo de ambientes Web, Internet, Intranet y Extranet.. •. Son independientes de plataforma y lenguajes del vendedor.. •. Son independientes del modelo de programación.. •. Soportan comunicación universal usando conexiones débilmente acopladas. lo cual. permite: o. Que el cliente y el servicio puedan utilizar diferentes plataformas y lenguajes de programación.. o. Reduce el costo de mantenimiento [Manes,2003].. o. Incrementa la reusabilidad [Manes,2003].. •. Soportan los "frameworks" de seguridad existentes.. •. Simplifican el proceso de integración de aplicaciones [Manes,2003].. •. Permiten la reusabilidad de servicios sin conocer la implementación de estos..

(33) CAPÍTULO J. ESTADO DEL ARTE. 14. •. Permiten el reuso de aplicaciones implementadas en tecnologías existentes.. •. La puesta en marcha es fácil y rápida.. •. Para el caso de integración de aplicaciones, el costo tanto en el desarrollo como la puesta en marcha es menor a utilizar tecnología "middleware" [Manes,2003].. •. Permiten el acceso con dispositivos remotos.. •. Se utilizan para integrar aplicaciones: o Punto a punto. o B2B ("Business to Business"). o. B2C ("Business to Consumer").. o. Entre departamentos, agencias, compañías, etc.. •. Buscan la estandarización y automatización para la integración de aplicaciones.. •. Utilizan el intercambio de mensajes basados en XML.. La arquitectura orientada al servicio (SOA) es una de las tecnologías base para los servicios Web; uno de los beneficios clave de esta arquitectura es el débil acoplamiento que permite que la arquitectura sea flexible y permita responder mejor, más rápido y a un bajo costo a los cambios. SOA asegura consistencia en los procesos de negocio debido al reuso de los servicios y procesos. SOA busca: La separación de la lógica del negocio de la funcionalidad, prevenir el acceso a cada servicio y el contrato de servicio entre consumidores y proveedores para el intercambio de información [Champion,2004]. Los requerimientos de SOA son:.

(34) CAPÍTULO l. ESTADO DEL ARTE. 15. 1. Transporte: En este requerimiento se debe especificar el formato para el intercambio de datos y el o los protocolos que pueden utilizarse para la comunicación de servicios. 2. Descripción: Aquí se debe especificar la información necesaria para interactuar con los servicios incluyendo nombres, operaciones con sus parámetros , formatos de mensaje, etc. Esta información es usada por procedimientos para deducir código de comunicación como por ejemplo server skeletons, stubs, clientes proxy, etc. 3. Descubrimiento: Es el requerimiento en el cual se especifica cual es el mecanismo usado para buscar y publicar un servicio.. La forma en que los Servicios Web cubren los requerimientos de SOA son los siguientes: l. Para el transporte se utiliza el formato de datos XML, protocolo XML (XML-RPC,. SOAP) y como protocolo de transferencia se pude utilizar alguno de los siguientes protocolos HTTP (POST/GET), SMTP o BEEP. 2. Para la descripción se utiliza WSDL (Web Service Description Language). 3. Para el descubrimiento se utiliza UDDI (Universal Description, Discovery and integration).. Más adelante se da una explicación de XML (XML-RPC,SOAP), HTTP (POST/GET), SMTP, BEEP, WSDLy UDDI. La figura 1.2.1 ilustra las alternativas que se tienen para el intercambio de mensaJes utilizando protocolos XML: XML-RPC, SOAP y HTTP POST/GET los cuales son independientes de la plataforma..

(35) 16. CAPÍTULO l. ESTADO DEL ARTE. Servidor A. Servidor A. Servidor A. XML-RPC. SOAP. Servidor B. Servidor B. Servidor IITTP POST /GET. B. Figura 1. 2.1-- Intercambio de mensajes entre Servicios Web. Los tres protocolos se utilizan para el intercambio de mensajes entre Servicios Web y los dos primeros (XML-RPC y SOAP) están basados en XML. •. XML-RPC es un protocolo simple que utiliza XML para realizar llamados a procedimientos remotos (RPC). Las peticiones son codificadas en XML (incluyendo nombre del método y parámetros) y enviadas vía HTTP-POST y el resultado es incluido en la parte de la respuesta en el cuerpo de HTTP. XML-RPC es la forma más fácil de iniciar un Servicio Web y es más simple que SOAP, solo que a diferencia de SOAP no cuenta con el servicio de descripción del lenguaje el cual documenta al Servicio Web.. •. SOAP también es un protocolo basado en XML para el intercambio de información entre computadoras y su enfoque principal es el llamado a procedimientos remotos vía HTTP ,.

(36) CAPÍTULO l . ESTADO DEL ARTE. 17. es más complicado que XML-RPC ya que en la petición de serv1c10 utiliza "XML namespaces" y "XML schemas" y al igual que XML-RPC en la petición incluye el nombre del método y los parámetros. •. HTTP es el protocolo más usado para el transporte de servicios que además de simple y estable la mayoría de "firewalls" permiten el tráfico a través de este protocolo. Soluciones de este tipo tenemos CGI, "Servlets", ASP, etc.. Hay dos formas de ver la arquitectura de los Servicios Web, una es por roles y la otra es a través de una pila de capas como se describe a continuación:. 1) Para el caso de la arquitectura por roles se tienen tres actores. El registro de los servicios.- Que es el directorio de servicios lógico y centralizado, aquí. •. se registran los servicios con la documentación necesaria para poder ser ejecutados tales como: nombre del servicio, parámetros utilizados, valores de regreso, sitio en donde se encuentra el servicio para su invocación, etc. •. El proveedor del servicio.- Que es la organización que proporciona el servicio, lo pone disponible para su ejecución y da de alta su documentación en el registro de servicios para su localización.. •. El cliente que requiere el servicio.- Es el consumidor de servicios.. En este escenario el cliente que requiere de un servicio lo busca en el registro de servicios, una vez que el cliente encontró el servicio que necesita, lo invoca desde el sitio en donde es proporcionado por el proveedor. La siguiente figura ilustra la arquitectura por roles..

(37) 18. CAPÍTULO l. ESTADO DEL ARTE. /. ... ~. 1. -Descubre servicio. /. / Registro de .. serv1c1os 1/. /. / Cliente de se rv1c1os I/. 2.-Invoca servicio. /. .... Proveedor .... de Servicios 1/. Figura 1.2.2 -- Arquitectura de Servicios Web por roles. 2) Para el caso de la arquitectura de Servicios Web como pila de capas la cual se ilustra en la figura 1.2.2 se tienen cuatro capas, en la de más bajo nivel se especifica el protocolo que se encarga del transporte de mensajes; en esta capa los protocolos de transporte que se pueden utilizar son (HTTP, SMTP, FTP, BEEP). En la siguiente capa se tiene el mecanismo que se encarga de la codificación de mensajes el cual esta basado en XML (XML-RPC, SOAP). En la siguiente capa se describe la interfaz pública de un Servicio Web por medio del WSDL (Web Service Description Language), y en la capa de más alto nivel encontramos el UDDI (Universal Description, Discovery, and Integration) que se encarga de centralizar los servicios en un registro común para facilitar la búsqueda y publicación de los Servicios Web. La figura siguiente muestra la arquitectura mencionada:.

(38) CAPÍTULO l. ESTADO DEL ARTE. 19. f-/_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __,,/. Descubrimiento. UDDI. Descripción. Mensajes XML. 1. WSDL. XML-RPC, SOAP,XML. 1. Transporte. HTTP, SMTP, FTP, BEEP. .___ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ____,,1/. Figu,ra 1.2.3 -- Arquitectura de Servicios Web por pila de capas. • UDDI representa la especificación técnica para publicar y encontrar los Servicios Web, permite a cualquier persona buscar en los datos de UDDI y permite a cualquier compañía registrar tanto datos generales de la compañía como información de los servicios que provee. La información capturada en UDDI está dividida en tres categorías: 1. Páginas blancas.- Que incluye información general acerca de la compañía. 2. Páginas amarillas.- Que incluye datos clasificados generales de la compañía así como de los servicios que ofrece. 3. Páginas verdes.- Que incluye información técnica de los Servicios Web. •. WSDL. es un lenguaje con gramática en formato XML para especificar la interfaz. pública de un Servicio Web, la cual incluye información como: 1. Todas las funciones públicas disponibles. 2. Tipos de datos para los mensajes XML. 3. Información especifica del protocolo de transporte a ser usado..

(39) CAPÍTULO l. ESTADO DEL ARTE. 20. 4. Dirección de localización del servicio. •. XML como vimos anteriormente XML-RPC y SOAP son los protocolos para la transmisión de mensajes.. •. HTTP es una buena opción para integrar aplicaciones remotas pero no es el protocolo ideal ya que HTTP fue creado originalmente para la recuperación de documentos, y los llamados a procedimientos remotos demandan mayor eficiencia y confiabilidad que la recuperación de archivos. Una alternativa al protocolo HTTP es el protocolo HTTP-R ó "HTTP-Reliable" que mejora HTTP para asegurar la confiabilidad de los mensajes. HTTP_R asegura que el mensaje sea entregado al destinatario enviando una confirmación cuando este es entregado y en caso contrario reporta que el mensaje no fue entregado. Otra alternativa a HTTP es el protocolo BEEP (Blocks Extensible Exchange Protocol) que es un marco de trabajo de la IETF (Internet Engineering Task Force) de las mejores prácticas para construir protocolos nuevos; BEEP se encuentra sobre TCP (Transmission Control Protocol) y entre las características que incluye tenemos el protocolo de "handshaking" inicial, autenticación, seguridad y recuperación de errores. Con BEEP se pueden crear protocolos nuevos para una variedad de aplicaciones, incluyendo funcionalidad para el manejo de mensajes, transferencia de archivos y administración de red [Cerami,2002]..

(40) CAPÍTULO J. ESTADO DEL ARTE. 21. 1.2.1 Escenarios Un escenario de uso cubre un paso en la ruta de interacciones del caso de uso de un Servicio Web, así que los siguientes escenarios, cubren todos los casos que se puedan presentar en los Servicios Web. Esto ayuda a definir las metas y requerimientos para la definición de la arquitectura estándar.. 1.- Envío de un mensaje a un destinatario.- En este escenario un emisor envía un mensaje a un solo destinatario y no requiere respuesta de recepción. Por ejemplo, la actualización de precios a una aplicación, cada 15 minutos. Este escenario requiere un mecanismo de enviar un mensaje a un solo destinatario, donde el emisor no requiere información de si el mensaje fue enviado o si este ha sido recibido por el destinatario. El protocolo de transporte puede implementar un mecanismo de respuesta, pero el estado de envío y recepción de mensaje no es regresado al emisor.. 2.- Envío de un mensaje a múltiples destinatarios.- En este escenario un emisor envía un mensaje a un conjunto de destinatarios y no requiere respuesta de recepción. Por ejemplo, la actualización de precios a diferentes aplicaciones, cada 15 minutos. Este escenario requiere un mecanismo de entrega del mismo mensaJe a múltiples destinatarios, puede ser implementado utilizando tecnología de distribución multicast siempre y cuando el protocolo de transporte soporte esta tecnología, o aplicar el escenario 1 a una lista de distribución de destinatarios..

(41) CAPÍTULO l. ESTADO DEL ARTE. 22. 3.- Petición/Respuesta.- Este escenario involucra el intercambio electrónico de documentos entre dos participantes, en donde el emisor empaqueta y envía uno o más documentos y el destinatario procesa el contenido del mensaje y envía una respuesta al emisor; por ejemplo, en una aplicación de compras, el emisor hace una petición de ordenes de compra y el destinatario después de procesar la petición responde con una confirmación de la orden. En este caso se tienen dos aplicaciones, la que envía el mensaje y la aplicación que lo recibe lo procesa y envía una respuesta. Se puede utilizar un protocolo de transporte que soporte la correlación de una petición y su respuesta de recepción en donde si el mensaje enviado no fue recibido o procesado por el destinatario, el protocolo de transporte debe reportar el estado del mensaje, como ejemplo de esta característica petición/repuesta, tenemos el protocolo HTTP. Si el protocolo de transporte no soporta el modelo petición/repuesta, la identificación de mensajes y correlación puede ser provista por encabezados SOAP.. 4.- Llamados a procedimientos remotos. El emisor invoca un servicio pasando el nombre del servicio y los parámetros por medio de un mensaje que será transmitido al destinatario servidor. En este caso el mensaje consiste en un conjunto de parámetros serializados usados para invocar un procedimiento remoto el cual responde con un conjunto de resultados. Este es un modelo de programación diferente al intercambio de documentos y al igual que en el escenario 3 se requiere de un protocolo de transporte petición/respuesta pero con los parámetros y resultados serializados.. 5.- Múltiples fallas.- Debido a que los métodos de interfaz de los servicios Web pueden fallar por diversas razones, la W3C en [He,2004] especifica que se debe tener la declaración de.

(42) CAPÍTULO l. ESTADO DEL ARTE. 23. un método que reporte fallas múltiples. Que de acuerdo a [Sommerville, 1995] se tiene las siguientes: •. Transitorias.- Que ocurren solo bajo ciertos valores de entrada.. •. Permanentes.- Que ocurren con todas las entradas al servicio.. •. Recuperables.- Son fallas bajo las cuales el servicio se recupera sin necesidad de de intervención de un operador.. •. No recuperables.- En este caso se requiere de la intervención del oeprador para que el servicio se recupere de la falla.. •. No-corrupto.- La falla no corrompe el estado del sistema o de los datos.. •. Corrupto.- La falla corrmpe el estado del sistema o de los datos.. También se debe considerar la tolerancia a fallas que es una de las estratégias para alcanzar la confiabilidad del servicio, la cual asume que existen fallas en el servicio pero provee de mecanismos en el software para que la operación del servicio continue aun cuando se presenten las fallas. Los aspectos a considerar en la tolerancia a fallas son los siguientes: •. Detección de fallas.- El servicio debe detectar que una combinación de estados particular ha resultado o resultará en fallas del servicio.. •. Evaluación de daños.- Detectar partes afectadas por las fallas del servicio.. •. Recuperación de fallas.- El sitema debe reestablecerse a su estado conocido como "seguro" al presentarse las fallas.. •. Reparación de fallas.- Involucra modificar el sistema para que no vuelva a fallar por la falla detectada..

(43) CAPÍTULO l. ESTADO DEL ARTE. 24. 6.- Respuesta con confirmación.- En este caso el emisor requiere intercambio de datos con el destinatario en una forma confiable; para esto requiere notificación del estado del envío de datos hacia el destinatario, esto es, notificación de si los datos fueron entregados al destinatario de forma exitosa o hubo un error en la entrega. En este caso el protocolo de transporte debe soportar el modelo de intercambio de mensajes Petición/Respuesta. 7.- Tercer participante intermediario.- En este escenario se tiene un tercer participante que interviene en el intercambio de información entre dos entidades, por ejemplo un intermediario para la compra y venta de productos en donde el comprador solicita información de un producto a un vendedor intermediario y este solicita información a diferentes proveedores, recopila la información y se la envía al comprador final. En este caso el vendedor intermediario actúa como canal para transacciones comerciales entre el comprador y el proveedor seleccionado; este intercambio de información ocurre en transacciones tipo B2B (Business to Business). Este escenario consiste de un conjunto de mensajes Petición/Respuesta entre el comprador y el vendedor intermediario el cual a su vez contacta a los proveedores a través de intercambio de mensajes Petición/Respuesta.. 8.- Comunicación vía múltiples intermediarios.- En este caso un mensaje es reenviado a su destinatario final vía uno o varios intermediarios en representación del emisor inicial, asegurándose que el mensaje fue enviado y recibido por las partes involucradas (emisor inicial y destinatario final)..

(44) CAPÍTULO l. ESTADO DEL ARTE. 25. Cualquier manejador de servicios de mensajes intermediario que reenvía el mensaje debe guardar la información de ruteo en el encabezado de la información de ruteo. Encabezados de ruteo firmados así como la información de quienes leen el mensaje debe ser guardada en el mensaje para propósitos de auditoria.. 9.-Caching.- Es un mecanismo de almacenamiento temporal que permite mantener datos o instrucciones que son accesados constantemente y evita el aceso continuo a fuentes de información centralizadas. Algunas aplicaciones requieren de esta característica para hacer más eficiente el uso de ancho de banda. "Caching" es usado frecuentemente como optimización en sistemas distribuidos, puede ser usado para evitar rehacer cálculos o accesos complejos a bases de datos cuando los datos no han sufrido cambios y de esta manera evitar accesos y procesamientos. Otro uso de "caching" se tiene en la transmisión de datos conservando una copia de la información transmitida en lugar de hacer accesos repetidos al repositorio central de información, lo cual reduce el uso de ancho de banda de la red y la carga de trabajo del servidor central que proporciona la información.. 10.- Ruteo.- Este escenario cubre el caso cuando una entidad requiere información explícita de un servicio pero no desea proporcionar sus datos de identidad (JP). En este caso se solicita la información a través de un intermediario anónimo el cual es el responsable de hacer el llamado, solicitar la información al servicio final y una vez que tiene la información, regresada a la entidad inicial..

(45) CAPÍTULO l. ESTADO DEL ARTE. 26. 11.-Rastreo.- Para propósitos de auditoria un proveedor de serv1c1os reqmere darle seguimiento a los mensajes que han llegado para conocer exactamente a través de cuántos intermediarios los mensajes han pasado antes de llegar a su destino final. El rastreo de la ruta de un mensaje puede ser realizado agregando un encabezado de rastreo al mensaje además de cualquier información de ruteo.. 12.- Caching con expiración.- Este escenario es similar al 9 pero aquí se cubren los casos cuando la información se actualiza por tiempo, por ejemplo en el caso de actualización de precios a las 8 de la mañana, las aplicaciones que utilizan esta información mantienen los precios de forma local y al siguiente día después de la actualización de precios hacen una consulta al repositorio central con los nuevos precios y de esta forma actualizan sus precios sin tener que hacer accesos cada vez que usan los precios.. 13.- Intercambio de mensajes en una conversación.- Involucra dos socios en un proceso de intercambio de información complejo por medio del envío de mensajes múltiple. Por ejemplo entre sistemas de "supply chain management" o de recuperación de información. Las interacciones entre socios de negocios usualmente son más complejas que un simple intercambio de mensajes Petición/Respuesta ya que se requiere de una infraestructura que permita tener una conversación por medio del intercambio de mensajes, así como tener múltiples conversaciones al mismo tiempo, lo cual nos lleva a tener los siguientes requerimientos: •. Que el emisor tenga la posibilidad de especificar información en el mensaje para su uso interno, por ejemplo ID de Conversación para que de esta manera esta información sea.

(46) CAPÍTULO l. ESTADO DEL ARTE. 27. incluida en mensajes subsecuentes, y el destinatario debe regresar esta información en los mensajes de la misma conversación. •. Se repite el caso anterior para el destinatario.. •. Tanto el emisor como el destinatario deben tener una especificación de secuencia de mensajes permitidos.. •. Tanto el emisor como el receptor deben tener una especificación de características estáticas del intercambio.. 14.- Petición con datos encriptados.- En este escenano dos aplicaciones acuerdan intercambiar todos los datos encriptados y ambas aplicaciones están de acuerdo en la tecnología de encripción a utilizar. Los datos son encriptados por la aplicación que originalmente envía los datos y estos son enviados a la aplicación destino vía SOAP, y la aplicación que recibe el mensaje con los datos encriptados, los desencripta siguiendo la tecnología acordada.. 15.- Encabezado de mensaje y encripción.- Dos socios que desean intercambiar mensajes pueden acordar enviar los mensajes con firma encriptada y verificar uno o mas encabezados del mensaje tales como el encabezado de ruteo y encabezado de conversación. El emisor del mensaje es el que firma el encabezado. El encabezado de ruteo puede ser anexado al encabezado del mensaje y además puede ser firmado por el manejador del servicio del mensaje. Este escenario es aplicable cuando el mensaje es enviado por un canal de comunicación que no es seguro como SMTP (Simple Mail, Transfer Protocol)..