INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA
UNIDAD CULHUACAN
TESINA
Seminario de Titulación:
“Las tecnologías aplicadas en redes de computadoras”
DES/ESIME-CUL/5092005/06/2009
SEGURIDAD EN SERVICIOS WEB
Que como prueba escrita de su examen Profesional para obtener el Título de: Ingeniero en
Comunicaciones y Electrónica
Presentan:
Carolina Contreras Reyna José Luis Juárez Ortiz
Oscar Osorio Morales Daniel Rodríguez Ramírez
México D.F. Junio 2009
Agradecimientos
Carolina:
C
on infinito AMOR a mis padres Carlos y Sandra que han sido mi mejor ejemplo e inspiración para amar, ser honesta, trabajar, salir adelante y lograr mis metas.A
mis hermanos Carlos, Víctor y Luis, a quienes adoro con todo mi corazón y que han estado conmigo en todos los momentos de mi vida.A
Dios por darme la salud, amor y fuerza para llevar a cabo cada uno de mis sueños.A
mi familia entera por ser un apoyo y compañía en todo este tiempo.A
mis profesores por su apoyo y consejo en la realización de una de mis metas, mi título profesional.- T
A M A B-
José Luis:
A
mis padres y hermana por enseñarme que la perseverancia y el esfuerzo son el camino para lograr objetivos.A
todas aquellas personas que de una u otra forma, están presentes en el transcurso de mi vida, hago extensivo mi más sincero agradecimiento.Y
en especial a mi Carnal.A
mis papás Nydia y Oscar quienes han sido mi inspiración para salir adelante, por su amor, dedicación y esfuerzo; por estar al pendiente de que nunca me faltara nada y preocuparse en las ocasiones de desvelos, por despertarme a tiempo para estar puntual en la escuela, pero sobre todo por su confianza ya que sin esta nunca hubiese madurado; así como, inculcarme el no conformarme con lo que tengo y luchar por lo que quiero, también por enseñarme a confrontar los problemas de frente y levantarme en momentos en que estos me iban ganando.A
mi hermano Irving por llenar mi vida de momentos de alegría y ser compañero de innumerables aventuras, por tu cariño, por transmitirme tu ambición y fortaleza por vivir la vida y salir día a día con una sonrisa en la cara; también por tu apoyo en momentos difíciles y siempre escucharme cuando más lo necesite.A
mis abuelitos Chelito, Rosita y Pablo por sus consejos y regaños, por su cariño y amor, por todo su tiempo invertido en educarme y hacerme una persona de bien, por recogerme en la escuela y cuidarme en su casa, por enseñarme el valor de la familia y el poder que tiene esta para lograr cosas grandes, por preocuparse y estar al pendiente de mi vida.A
mi novia Olimpia por su amor, cariño, comprensión y tiempo; por estar conmigo en momentos de tristeza pero también de alegrías y triunfos, así como, por mostrarme mis errores e impulsarme a no vencerme, por motivarme y enseñarme que los sueños pueden ser realidad aunque parezcan inalcanzables. Gracias por ser mi amiga, confidente y un motivo para progresar.A
todos mis tíos, de los cuales he aprendido muchas cosas que me sirvieron y servirán a lo largo de mi vida, por su apoyo y sus consejos.A
mis primos por ser parte fundamental de mi vida, por su apoyo y comprensión, por tener las palabras adecuadas para reconfortarme y simplemente por todos los momentos que pasamos y vivimos.E
n especial dedico estas páginas al Sr. Alvaro Osorio Gonzalez que hasta donde me este cuidando, le envió mi agradecimiento por enseñarme a ser una persona recta y responsable, por el cariño que me demostró y los bellos recuerdos que deja en mi memoria; ya que estos se convierten en un de los motores importantes para que llegara a completar este ciclo en mi vida.A todos ustedes “Mil Gracias”
Daniel:
A
mis papás Rigoberto Rodríguez Reyes y María Dolores Ramírez Negrete con todo mi amor, cariño y respeto.A
mis hermanos Rigoberto Rodríguez Ramírez y Rodrigo Alejandro Rodríguez Ramírez ya que gracias a su apoyo, hoy es posible esta tesis.A
mis sobrinos Michelle Abril y Joshua.A
mi familia por siempre creer en mí y por darme su confianza en todo lo que me propongo.Y
a mis profesores por la constancia y dedicación.G
racias.Objetivo
Proporcionar información sobre herramientas, estándares, mejoras prácticas y protocolos para proporcionar y agregar seguridad en la comunicación entre Servicios Web (Web Services), así como ayudar al lector a que obtenga una visión global de cómo se encuentra hoy en día el desarrollo de los Servicios Web (WS), a nivel de operatividad y de seguridad.
Justificación
Hacer un análisis e investigación sobre los estándares útiles para la seguridad en Servicios Web. De igual forma esta se busca ampliar los conocimientos básicos – intermedios sobre los programas y herramientas que existen hoy en día para proporcionar seguridad y confiabilidad al uso de Web Services, como son el envío de mensajes seguros por SOAP y Kerberos.
Esta investigación informa sobre las opciones que existen para enfrentar la seguridad en los WS. Algunas de ellas, las más importantes, las definiremos gracias a WS-Security (Seguridad en Servicios Web), los puntos que se trataran durante el desarrollo del tema son:
• Autenticación y autorización apropiada de un Servicio Web.
• Protección de los mensajes hacia y desde un Web Service para que los mismos sean protegidos de accesos y modificaciones no autorizadas.
Se hablara sobre el modelo unificado que utiliza las tecnologías existentes y que permite que las aplicaciones intercambien mensajes SOAP de forma segura, este modelo es proporcionado por WS- Security.
Uno de los temas importantes que abordaremos será sobre la WS-I (Organización de Interoperabilidad de Web Services), la cual es una organización apoyada por las empresas tecnológicas más grandes del mundo, y que define cómo se deberían cumplir los requerimientos de interoperabilidad al utilizar un conjunto de tecnologías que aseguran la transmisión de los mensajes SOAP.
Y por lo tanto se investigará sobre los desafíos que se tienen al aportar seguridad en un Servicio Web, como:
• Identificación y Autenticación de las partes.
• Identificación y Autenticación de los datos de origen.
• Integridad de los datos: Integridad en el transporte y del mensaje SOAP.
• Confidencialidad de los datos, en el transporte y del mensaje SOAP.
Índice
Capítulo I. Introducción a los Servicios Web
1.1. Definición de los Servicios Web (Web Service) 2
1.2. Perspectiva de los Web Services 4
1.3. Estándares empleados en los Web Services 5
1.4. Ventajas de los Web Services 10
1.5. Inconvenientes de los Web Services 10
1.6. Razones para usar los Web Services 11
1.7. Plataformas EAI y WebServices 11
Capítulo II. Arquitectura Orientada a Servicios (SOA)
2.1. Introducción 14
2.2. Adopción de la arquitectura SOA 16
2.3. Riesgos 17
2.4. Fases de adopción SOA 18
2.4.1. Modelado 19
2.4.1.1. Tipos de servicio 19
2.4.1.2. Políticas de modelado 21
2.4.1.3. Buenas Prácticas de modelado 22
2.4.2. Ensamblado 22
2.4.2.1. Ciclo de desarrollo de servicios 23
2.4.2.2. Políticas de Ensamblado - Fase de Requerimientos 25 2.4.2.3. Políticas de Ensamblado - Análisis y Diseño 26 2.4.2.4. Políticas de Ensamblado - Fase de Construcción 26 2.4.2.5. Políticas de Ensamblado – Pruebas 27
2.4.2.6. Política de Ensamblado 28
2.4.2.7. Buenas Prácticas de Ensamblado 28
2.4.3. Despliegue 29
2.4.3.1. Políticas de Despliegue 29
2.4.3.2. Buenas Prácticas de Despliegue 30
2.4.4. Administración 30
2.4.4.1. Productividad y Acuerdos de Niveles de Servicio 31
2.4.4.2. Monitoreo 31
2.4.4.3. Optimización 33
2.4.4.4. Políticas de Administración 33
2.4.4.5. Buenas Prácticas en Administración 36 Capítulo III. Mensajes Seguros en SOAP, seguridad en Servicios Web (WS - Security)
3.1. Introducción 39
3.1.1. Sistema de seguridad 40
3.1.2. Objetivos y requisitos 42
3.1.2.2. No requisitos 43
3.2. Notaciones y terminología 43
3.2.1. Terminología 44
3.3. Mecanismos de protección del mensaje 45
3.3.1. Modelo de seguridad de los mensajes 45
3.3.2. Protección de mensajes 46
3.3.3. Peticiones inválidas o perdidas 47
3.3.4. Ejemplo 47
3.4. Referencias ID (Identificación). 49
3.4.1. Atributo ID (Identificación) 50
3.4.2. Esquema ID (Identificación) 50
3.5. Seguridad de cabecera 51
3.6. Seguridad en los Tokens 54
3.6.1. Fijación de Tokens de seguridad 54
3.6.1.1. Proceso de las reglas 55
3.6.1.2. Confirmación de reserva 55
3.6.2. Nombre de usuario Token 55
3.6.3. Seguridad binaria en Tokens 57
3.6.3.1.- Adjunto de Tokens de seguridad 57 3.6.3.2.- Codificación binaria Tokens de seguridad 57
3.6.4. XML Tokens 58
3.6.4.1.- Identificar y hacer referencia los Tokens de seguridad 59
3.7. Referencias de Token 59
3.7.1. Elemento de seguridad de Token 59
3.7.2. Referencias directas 61
3.7.3. Llaves de identificadores 63
3.7.4. Referencias embebidas 64
3.7.5. ds:KeyInfo 66
3.7.6. Nombres claves 66
3.8. Firmas 67
3.8.1. Algoritmos 68
3.8.2. Firma usando Tokens 70
3.8.3. Validación de firma 72
3.9. Cifrado 73
3.9.1. Lista de referencias (<xenc:>) 73
3.9.2. XENC: Cifrado clave 75
3.9.3. Procesamiento de las reglas 76
3.9.3.1. Codificación 76
3.9.3.2. Descifrado 77
3.9.4. La transformación del descifrado 78
3.10. Seguridad de tiempo 78
3.11. Tratado de errores 81
3.12. Consideraciones de seguridad 81
3.12.1. Consideraciones generales 82
3.13.2. Consideraciones adicionales 83
3.13.2.1. Repetir 83
3.13.2.2. La combinación de mecanismos de seguridad 83
3.13.2.3. Desafíos 84 3.13.2.4. Fichas de seguridad y protección de claves 84
3.13.2.5. Protección de tiempo e Ids 85
3.14. Notas de interoperabilidad 85 3.15. Consideraciones sobre la privacidad 87
Capítulo IV. Seguridad en Web Services mediante Kerberos 4.1. Introducción a Kerberos 90 4.2. La misión de Kerberos 92
4.2.1. Conexión inicial 93 4.3. Importancia de la información en el ticket 95 4.3.1. Servicios 96 4.3.2. Solicitud de Servicios 97
4.4. Autenticación mutua 98 4.4.1. A los ojos del usuario 98
4.5. Administración 99
5.5.1. Administración general 99 5.5.2. Administración entre sistemas Kerberos 99 5.5.3. Limitaciones 100
Conclusiones 102
Bibliografía 103
Referencias Web 104
Glosario 105
Capítulo I
Introducción a los Servicios Web
1.1. Definición de los Servicios Web (Web Service)
Los Web Services (WS) son una de las tecnologías más atractivas del mundo internet. Hace ya algún tiempo que esta tecnología dejó de ser una moda y una promesa, para convertirse en una realidad con muchas utilidades. Como muestra Google, compañía que inició en Abril del año 2002, con la posibilidad de hacer búsquedas usando su motor de búsqueda (que indexa más de 3.000 millones de documentos Web). Esto se hace mediante WS.
La definición de un Web Service según la W3C (Consorcio World Wide Web), el organismo que se encarga de desarrollar gran parte de los estándares de internet, se define un WS de la siguiente forma: “Un Web Service es una aplicación software identificada mediante una URI (Unidad de Reacción Inmediata) cuyo interfaz es capaz de ser definido, descrito y descubierto mediante artefactos XML (Lenguaje de Marcas Ampliadas), y soportar interacciones directas con otras aplicaciones software usando mensajes basados en XML y protocolos basados en Internet”.
Una definición alternativa podría ser la siguiente: Un servicio Web es un componente software que se basa en las siguientes tecnologías:
• Un formato que describa la interfaz del componente (sus métodos y atributos) basado en
• XML. Por lo general este formato es el WSDL (Lenguaje de Descripción de un Servicio Web).
• Un protocolo de aplicación basado en mensajes y que permite que una aplicación interaccione, use, instancia, llame y/o ejecute al WS. Por lo general este protocolo
• Un protocolo de transporte que se encargue de transportar los mensajes por internet.
Por lo general este protocolo de transporte es HTTP (Protocolo de Transporte de Híper Texto) que es exactamente el mismo que usamos para navegar por la Web.
Los WS, no son por tanto aplicaciones con una interfaz gráfica con la que las personas puedan interaccionar, sino que son software accesible en internet (o en redes privadas que usen tecnologías internet) por otras aplicaciones. De esta forma podemos desarrollar aplicaciones que hagan uso de otras aplicaciones que estén disponibles en internet interaccionando con ellas.
Un típico ejemplo podría ser un WS al que se le pudiese preguntar por una empresa y que nos retornase en tiempo real el valor al que están cotizando las acciones de dicha compañía.
De esta forma cualquier aplicación (ya sea web o de escritorio) que quiera mostrar esta información sólo tendría que solicitarla a través de internet al servicio Web cuando la necesitase.
Otro ejemplo de servicio Web podría ser uno que al pasarle el nombre de una ciudad, nos devolviese la temperatura, humedad, y otras condiciones climatológicas de la misma. Los WS no son la panacea, sino una tecnología apropiada para resolver ciertos problemas.
Básicamente los WS permiten que diferentes aplicaciones, realizadas con diferentes tecnologías, y ejecutándose en toda una variedad de entornos, puedan comunicarse e integrarse.
1.2. Perspectiva de los Web Services
El coste de desarrollar software siempre ha sido altísimo, y la diversidad de las plataformas una realidad desde el inicio de la informática. De hecho conforme más complejas fueron las aplicaciones que las empresas demandaban, más caras era desarrollarlas. Esta situación ha provocado una gran necesidad de reutilizar las aplicaciones ya desarrolladas. Una de estas propuestas es, la estandarización de lenguajes de programación de tal forma que si cualquiera de nosotros escribía un programa en C, solo necesitaríamos un compilador de C en la plataforma específica en la que quisiéramos ejecutar la aplicación. Esto en la realidad es difícil de hacer funcionar, porque en seguida surgieron pequeñas diferencias y extensiones de C que hacían difícil transportar una aplicación entre diferentes plataformas.
Otra posibilidad ha sido la que ha desarrollado Sun con Java, se programa para una plataforma, pero para una plataforma virtual, en este caso para la máquina virtual Java y en cada plataforma real se implementa una máquina virtual de java, que será la encargada de ejecutar las aplicaciones escritas en Java. Las implementaciones son específicas de cada plataforma pero al ser todas las máquinas virtuales exactamente la misma, los programas escritos en Java deben poder ejecutarse sin ningún problema en todas las plataformas que tengan una máquina virtual de Java. Esta apuesta ha demostrado ser muy útil y funcionar bastante bien.
Sin embargo, ¿qué pasa si tenemos varias aplicaciones ya desarrolladas en lenguajes propietarios o en plataformas específicas y queremos que interaccionen entre ellas? El coste
en la mayoría de las situaciones, y es aquí donde los Web Services, así como otras tecnologías, pueden sernos de una grandísima utilidad.
Con los WS podemos reutilizar desarrollos ya utilizados sin importar la plataforma en la que funcionan o el lenguaje en el que están escritos. Los WS se constituyen en una capa adicional a estas aplicaciones de tal forma que pueden interaccionar entre ellas usando para comunicarse tecnologías estándares que han sido desarrolladas en el contexto de internet.
1.3. Estándares empleados en los Web Services
Los estándares son definiciones o formatos que se aprueban o reconocen desde organizaciones de estandarización. Generalmente estos organismos están formados por el conjunto de empresas más representativas de un sector o de un campo de la producción.
Los estándares permiten que las industrias desarrollen componentes con las garantías suficientes de: interacción, funcionalidad y calidad. Ayudan a desarrollar los bloques básicos sobre los que seguir construyendo el edificio tecnológico.
Los estándares son extremadamente importantes en la informática, ya que permiten que se combinen productos de diferentes fabricantes para el desarrollo de sistemas, tanto software como hardware. Sin estándares, sólo los productos de la misma compañía podrían ser usados de forma conjunta.
Actualmente existen estándares para diversos protocolos de comunicación, formatos de datos, lenguajes de programación, etc.
Los organismos más importantes de estandarización son: ANSI (Instituto Nacional Americano de Estándares), IEEE (Instituto de Ingenieros Eléctricos y Electrónicos), ISO (Organización Internacional para la Estandarización), y W3C.
Los WS se construyen sobre estándares y a su vez pretenden ser un estándar con los que construir sistemas a partir de piezas dispares, desarrollas por distintos fabricantes, WS.
Los principales estándares para el desarrollo de WS son los siguientes:
HTTP (Protocolo de Transferencia de Hipertexto ó HyperText Transfer Protocol) Es el protocolo más común de intercambio de información en la World Wide Web (www), el método mediante el cual se transfieren las paginas web a un ordenador.
De este modo, las peticiones de acceso a una página y la respuesta brindada por la misma en forma de contenido de hipertexto utilizan este sistema de comunicación, el cual permanece un tanto "oculto" al usuario final. El protocolo HTTP es utilizado también para enviar formularios con campos de texto, u otro tipo de información en ambos sentidos.
La conexiones realizadas mediante este protocolo no son guardadas por el mismo en ningún sitio, es decir que se trata de un protocolo "sin estado": los datos se pierden, por lo tanto, cuando la transacción de los mismos ha terminado, cosa que da lugar a las cookies (galletitas), archivos livianos que se guardan en determinado sitio del disco duro con el objetivo de almacenar información del usuario. De tal forma, el sitio Web sabrá de quién se trata al volver a acceder al mismo, mostrando por ejemplo su nombre y o permitiendo su acceso sin necesidad de ingresar contraseña, etc.
Las cookies también son utilizadas por ciertos sitios Web para llevar una estadística de sus visitantes.
Es útil saber que los sitios Web cuya dirección de Internet comienza con HTTPS serán seguros; por lo general los navegadores Web informan de esto mostrando un fondo amarillo detrás del texto de la URL, y algún candado.
SOAP. SOAP es un protocolo ligero de mensajes XML que se usa para codificar la información de los mensajes de petición y respuesta de los WS que se envían a través de una red.
Los mensajes SOAP son independientes de los sistemas operativos y de los protocolos, y pueden ser transportados usando una variedad de protocolos Internet, incluyendo SMTP (Protocolo Simple de Transmisión de Correo), y HTTP (Protocolo de Transferencia de Hipertexto).
Dentro del paradigma orientado a objetos, usar un WS es igual que usar cualquier otra clase. Y esto significa instanciarlo, y llamar a sus métodos, pasándoles los parámetros que sean necesarios, y obteniendo a su vez el resultado que nos retornen.
Como ya hemos dicho por lo general llamaremos a WS que no estarán en nuestra máquina local, sino en cualquier servidor accesible desde Internet. Debemos por tanto de disponer de alguna forma de llamar a cualquiera de sus métodos pasándole los parámetros oportunos y obteniendo el resultado de esa llamada (si es que el método devuelve algo después de ser ejecutado). SOAP es un protocolo que define precisamente cómo realizar esta comunicación, es decir, como debemos codificar las llamadas a los métodos de un WS, y como debe el WS codificar el resultado para que nosotros lo podamos interpretar.
Estos mensajes son los que transportarán los protocolos de transporte, por lo general, HTTP.
WSDL es un acrónimo de Lenguaje de Descripción de Servicios Web (Lenguaje de Descripción de los WS), que es un lenguaje XML usado para describir la interfaz de un WS como un conjunto de puntos finales de comunicación (métodos) capaces de intercambiar mensajes (es decir recibir llamadas con sus parámetros correspondientes y generar respuesta con el resultado que le corresponda). WSDL se considera parte integral de UDDI (Descripción Universal de Integración y Descubrimiento ó Universal Description, Discovery and Integration), que debería ser un registro de servicios Web XML (esto último lo explicamos un poquito más abajo).
WSDL es el lenguaje usado por UDDI para describir a los WS. Fue desarrollado de forma conjunta por Microsoft e IBM.
WSDL es un fichero XML que describe el conjunto de métodos expuestos por un WS. Esta descripción incluye el número de argumentos, y tipo de cada uno de los parámetros de cada uno de los métodos, así como la descripción de los elementos que retornan.
Estas descripciones son las que se usan para generar los objetos proxy que usamos en los entornos de desarrollo con los que programamos WS.
Por cada WS, cogemos su descripción WSDL y generamos una clase con la misma interfaz (igual número de métodos y la misma signatura de los mismos) que describe el fichero.
Esta clase es el proxy local del WS.
El código local de un proxy de WS es el encargado de construir las llamadas SOAP al servicio web y de recibir las llamadas SOAP de ese servicio Web.
Usando este patrón el programador es capaz de abstraerse de todos los elementos que intervienen en una llamada a un servicio Web, para él, es exactamente igual a llamar a una clase local (el proxy) y es éste el que se encarga de encapsular la complejidad propio de la comunicación con el servicio Web.
Las clases proxys son generadas por lo general de forma automatiza por la mayoría de los entornos de desarrollo.
UDDI1 es un acrónimo de Integración, Descubrimiento y Descripción Universal. Es un directorio de WS distribuido y basado en Web que permite que se listen, busquen y descubran este tipo de software. Podríamos compararlo con las típicas páginas amarillas.
Los WS están pensados para 3 tipos de escenarios:
Servicios Simples y públicos. Se expondría una funcionalidad simple accesible desde Internet. Ejemplo: Una empresa de transporte podría exponer una función a la que se le pasasen como parámetros el lugar de origen, el lugar de destino, la hora deseada de entrega, y el peso del paquete, y obtendríamos como respuesta el precio del envío.
Integración de aplicaciones. Usamos los servicios web básicamente como extensiones de sistemas ya construidos para que éstos sean accesibles por aplicaciones y sistemas heterogéneos desarrollados bajo cualquier plataforma y lenguaje y que participan en procesos comunes. De esta forma podemos integrar software muy diverso, incluso aplicaciones que realicen transacciones de empresa-a-empresa.
Sistemas de Grid Computing. Existen problemas para los que su resolución exige tener muchos procesadores u ordenadores funcionando de forma coordinada. Lo que se hace es dividir el problema en sub-problemas y resolver cada uno de estos en un nodo de
computación, finalmente con el resultado devuelto por todos estos nodos se obtiene la solución.
1.4. Ventajas de los Web Services
• Aportan interoperabilidad entre aplicaciones de software independientemente de sus propiedades o de las plataformas sobre las que se instalen.
• Los servicios Web fomentan los estándares y protocolos basados en texto, que hacen más fácil acceder a su contenido y entender su funcionamiento.
• Al apoyarse en HTTP, los servicios Web pueden aprovecharse de los sistemas de seguridad firewall (Programa que sirve para filtrar lo que entra y sale de un sistema conectado a una red. Suele utilizarse en las grandes empresas para limitar el acceso de Internet a sus empleados, así como para impedir el acceso de archivos con virus) sin necesidad de cambiar las reglas de filtrado.
• Permiten que servicios y software de diferentes compañías ubicadas en diferentes lugares geográficos puedan ser combinados fácilmente para proveer servicios integrados.
• Permiten la interoperabilidad entre plataformas de distintos fabricantes por medio de protocolos estándar y abiertos. Las especificaciones son gestionadas por una organización abierta, la W3C, por tanto no hay secretismos por intereses particulares de fabricantes concretos y se garantiza la plena interoperabilidad entre aplicaciones.
1.5. Inconvenientes de los Web Services
• Para realizar transacciones no pueden compararse con los estándares abiertos de computación distribuida como CORBA (Arquitectura Común de Destrucción de Solicitud de Objetos ó Common Object Request Broker Architecture).
• Su rendimiento es bajo si se compara con otros modelos de computación distribuida, como RMI (Método de Invocación Remota ó Remote Method Invocation), CORBA, o DCOM (Modelo Objetos de Componentes Distribuidos ó Distributed Component Object Model).
• Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en firewall cuyas reglas tratan de bloquear la comunicación entre programas.
• Existe poca información de servicios web para algunos lenguajes de programación
1.6. Razones para usar los Web Services
Una de las mejores razones por la cual el uso de los Web Services es una buena opción es porque actualmente se basan en HTTP sobre TCP (Protocolo de Control de Transmisión ó Transmission Control Protocol) en el puerto 80. Dado que las organizaciones protegen sus redes mediante firewalls, que filtran y bloquean gran parte del tráfico de Internet, cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan los navegadores.
Los Web Services utilizan este puerto, por la simple razón de que no resultan bloqueados.
Una tercera razón por la que los Web Services son muy prácticos es que pueden aportar gran independencia entre la aplicación que usa el WebService y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más utilizada.
1.7. Plataformas EAI y Web Services
El EAI (Integración de Aplicaciones de Empresas ó Enterprise Application Integration) lo que hace es interconectar a todos esos sistemas, de tal forma que cualquier aplicación conectada al EAI (es decir que tenga un adaptador) puede interactuar con cualquier otra aplicación conectada al EAI.
Podríamos ver al EAI como un traductor que permite que dos sistemas que hablan en idiomas distintos sean capaces de entenderse.
Conforme ha ido pasando el tiempo, los constructores de sistemas EAI han ido añadiendo funciones avanzadas como: el mapeo de datos, la transformación y traducción de datos, la coordinación de transacciones, la gestión de comunicaciones y la gestión de procesos de
negocio. Estas capacidades son críticas para las empresas de cierto tamaño en sus proyectos de integración de sistemas.
Estos productos tienen también su parte menos brillante como el coste, la complejidad, y el uso de arquitecturas propietarias.
Desde la perspectiva de la integración de aplicaciones los servicios Web (de los cuales ya hemos dicho que este es uno de sus escenarios típicos) ofrecen ventajas sobre los sistemas EAI en términos de uso de estándares, simplicidad, y bajo coste, ya que ofrecen una solución rápida y ajustada en coste para resolver problemas de interoperabilidad e integración, usando infraestructuras ya existentes y reutilizando la tecnología de componentes.
Eso sí, tenemos que también ser conscientes que actualmente los servicios Web no son capaces de ofrecer todo el conjunto de características avanzadas de muchos sistemas EAI, como por ejemplo, gestión de la capa de comunicación, coordinación de transacciones, seguridad, etc., aunque son cuestiones sobre las que se está trabajando.
Los servicios Web por tanto son atractivos para soluciones de este tipo en el ámbito de la integración de baja y media complejidad.
Capítulo II
Arquitectura Orientada a Servicios
(SOA)
Cuando se habla de servicios Web se emplea también el término SOA, es por eso que este capítulo lo dedicaremos a entender este termino.
2.1. Introducción
SOA es un acrónimo de Arquitectura Orientada al Servicio. SOA es un método para diseñar y construir soluciones software muy independientes (poco acopladas). La funcionalidad sería accesible programáticamente por otras aplicaciones a través de interfaces publicados y que puedan ser descubiertos. Los servicios Web representan una implementación de una Arquitectura Orientada al Servicio.
Básicamente una arquitectura orientada al servicio es una colección de servicios. Estos servicios se comunican entre ellos. La comunicación puede involucrar simplemente el paso de datos o la coordinación de alguna actividad entre varios servicios.
Las arquitecturas orientadas a servicios no son una cosa nueva. Para mucha gente la primera de estas surgió en el pasado con el uso de DCOM (Modelo distribuido los componentes de objetos ó Distributed Component Object Model) o los ORBs (Destrucción de Solicitud de Objetos ó Object Request Brokers) de CORBA.
La tecnología de los Web Services es la tecnología de conexión más apropiada para las arquitecturas orientadas a servicios.
La Arquitectura Orientada a Servicios es un estilo de arquitectura de TI2 cuya principal característica consiste en establecer un grado de independencia entre la funcionalidad de un sistema y las plataformas de hardware, sistemas operativos y lenguajes de programación con los cuales haya sido implementado.
Definiciones principales dentro de una arquitectura orientada a servicios
La arquitectura está integrada por servicios, infraestructura y software, y tiene como propósito establecer un ambiente en el que los negocios y las tecnologías de información puedan interactuar entre sí para fortalecer la reutilización de funcionalidad ya existente. Sus ventajas pueden resumirse de la siguiente manera:
• Permite a la empresa acelerar y agilizar los procesos de adopción de nuevas estrategias de negocio y le proporciona una ventaja competitiva sobre la competencia.
• Favorece la reutilización de componentes entre diversos procesos de negocio.
• Proporciona mecanismos de medición de resultados y permite tomar acción sobre ellos.
• Permite garantizar resultados repetibles y predecibles.
2 Tecnologías de Información
2.2. Adopción de la arquitectura SOA
La adopción de la arquitectura SOA debe efectuarse de manera iterativa e incremental, basado en el establecimiento de pasos para una exitosa implementación. La adopción inicial se debe efectuar mediante la ejecución de un proyecto que cumpla los criterios de un buen candidato para desarrollarse mediante una Arquitectura Orientada a Servicios.
Fases de adopción de SOA
El nivel de progreso en la adopción se puede ver desde dos perspectivas: visión estratégica y plan de proyecto. La visión estratégica describe el nivel de adopción estimando la madurez actual de la empresa, incluyendo el negocio, las metodologías y la infraestructura existentes.
El plan de proyecto indica la necesidad de establecer objetivos y metas, lo cual incluye el establecimiento de documentación y métricas para la transición. Es importante reconocer que aspectos del plan original pueden cambiar a partir de la experiencia obtenida.
También es posible identificar cuatro niveles de adopción de SOA, los cuales indican el nivel de madurez de esta arquitectura dentro de una empresa.
1. Estado inicial: En este punto la empresa puede estar usando Servicios Web o infraestructura de software con casi ninguna o ninguna alineación con el negocio.
2. Alineación con el negocio: Existen iniciativas de exploración en los activos existentes para encontrar un candidato a un proyecto piloto SOA. Se empieza a establecer el gobierno SOA, se definen mejores prácticas y directrices, se construye nueva tecnología y se desarrollan habilidades.
3. Integración a través de varias líneas de negocio: La adopción trata de ser empresarial y se comienza a integrar aplicaciones entre varias líneas de negocio. Es posible identificar y categorizar servicios comunes a toda la empresa, la gobernabilidad involucra servicios de dominio y la infraestructura puede incrementarse.
4. Enterprise business and IT Transformations: La transformación es amplia en el modelo de negocio existente, el cual puede trasladarse más allá de la empresa para agregarles valor a los clientes o socios de negocio.
2.3. Riesgos
Como cualquier tecnología conlleva riesgos que se deben tomar en cuenta:
• Entregar soluciones muy simples o extremadamente complejas por una pobre administración de requerimientos, donde no se entendieron las necesidades reales, los deseos y/o restricciones (esto no es una particularidad de SOA, este problema se presenta en cualquier actividad de sistemas).
• SOA rompe el paradigma de aplicaciones monolíticas en aplicaciones compuestas por pequeños bloques de negocio (servicios), corriendo en múltiples procesos, en múltiples maquinas y agregando múltiples conexiones. Si no se cuenta con mecanismos de administración y monitoreo adecuados, el gran número de componentes obstaculizará la detección y corrección oportuna de errores y alentará la adopción de nuevas estrategias de cambio.
• Si la gobernabilidad de SOA se convierte en una actividad primordialmente de revisión, los desarrolladores percibirán la arquitectura como un conjunto de pasos innecesarios y agobiantes y sólo los ignoraran.
2.4. Fases de adopción SOA
Es común identificar cuatro fases en el proceso de desarrollo de una Arquitectura Orientada a Servicios: Modelado, Ensamblado, Despliegue y Administración, todas ellas soportados por una base de gobierno y buenas prácticas:
Fases del Ciclo de Vida de SOA
Estas cuatro fases de la arquitectura deben estar acompañadas de un conjunto de reglas, políticas y lineamientos con el fin de que los conceptos y principios de SOA se lleven a cabo, y de que los recursos generados sean administrados correctamente. Es por esta razón que es indispensable contar con un marco de referencia al momento de implantar una arquitectura de este estilo dentro de una empresa. Este marco de referencia, para el caso particular de SOA, recibe el nombre de Gobernabilidad de SOA.
A continuación se describen con mayor detalle las cuatro fases de la metodología orientada a servicios, así como las políticas y buenas prácticas que se deben observar en cada una de ellas.
2.4.1. Modelado
La fase de modelado de servicios es un proceso abstracto que consiste en identificar, comprender y recrear funcionalidad de negocio a partir de la comprensión de requisitos y objetivo, para posteriormente convertir esto en una especificación de servicios. Esta especificación se llevará a cabo en la etapa de ensamblado durante su fase de análisis y diseño.
El modelo de cada servicio se generará como resultado de un proceso de identificación de funcionalidad, en el cual es necesario considerar que un servicio debe encapsular tareas del negocio susceptibles de repetirse, por ejemplo verificar la viabilidad de un crédito, imprimir una póliza o generar una cotización. Contar con un modelo de servicios adecuado permitirá establecer una correlación entre el diseño y la implementación real del servicio, a fin de determinar si los problemas que pudieran presentarse durante la ejecución se deben a limitaciones en el diseño o a limitaciones en el sistema de información que automatiza el servicio.
Además de la especificación funcional, el modelo de un servicio debe contemplar la captura de Indicadores Clave de Rendimiento o KPIs; métricas de negocio con las cuales se podrá determinar en qué grado un servicio se ajusta a los objetivos y requerimientos de negocio, como pudiera ser la medición del número pólizas emitidas por un área, o el tiempo promedio que toma este proceso de emisión.
2.4.1.1. Tipos de servicio
Es necesario hacer una clasificación de los tipos de servicio que pueden existir dentro de la arquitectura SOA de acuerdo al tipo de funcionalidad que engloban, ya que cada clasificación tendrá distintas consideraciones de funcionalidad, rendimiento y seguridad. A continuación se enumeran los tipos de servicio, ordenados de acuerdo a su granularidad de mayor a menor:
• Servicios de negocio: Exponen servicios de alto nivel, compuestos de funciones de negocio requeridos por toda la empresa. Permiten a las aplicaciones compartir funcionalidad e información consolidados, requeridos por los procesos de negocio.
Son los servicios con mayor granularidad, es decir, que en una sola operación para el cliente, el servidor realizará llamadas a múltiples elementos del negocio.
Ejemplos de estos servicios serían manejo de expedientes electrónicos, generación de reportes de desempeño, etc.
• Servicios de dominio: Estos servicios proveen funcionalidad relacionadas con el negocio que es específica para un dominio (una línea, área o segmento de negocio) y que pueden ser usados únicamente por entidades que se encuentren dentro de ese dominio. Estos servicios tienen una granularidad media.
Un ejemplo de estos servicios es la consulta de información de un vehículo asegurado para el área específica de siniestros de autos.
• Servicios de utilidad: Estos proveen los servicios de menor granularidad que proveen funcionalidad común al interior de la empresa. El hecho de ser de menor granularidad implica que en una sola llamada del cliente, el servidor realiza una o pocas llamadas a elementos de funcionalidad del negocio. Los servicios identificados en esta categoría no deberán ser invocados por entidades externas a la empresa.
Ejemplos de estos servicios son acceso a la libreta de direcciones empresarial, gestión de contenidos, generación de documentos, etc.
• Servicios de integración: Estos exponen funcionalidad de aplicaciones ya existentes, sin realizar modificaciones, en forma de servicios. Mediante este tipo de servicios es posible consolidar su acceso y propagarlo a través de diversas áreas de la empresa o incluso a entidades externas. Su granularidad es parcialmente dependiente de las aplicaciones existentes y típicamente requieren una transformación de datos entre los modelos empresariales y los de la aplicación.
Se recomienda poner especial atención durante la definición de estos servicios, sobre todo antes de exponerlos a entidades externas, ya que la mayoría de las veces las aplicaciones existentes no han sido diseñadas con las consideraciones de seguridad y rendimiento requeridas por una arquitectura de servicios.
Un ejemplo de estos servicios es el sistema de cotización y emisión de pólizas de autos (EMA), el cual está desarrollado en Progress, y cuya funcionalidad requiere ser expuesta a socios de negocio.
• Servicios Externos: Estos proveen acceso a los sistemas y aplicaciones de proveedores externos a la empresa. La granularidad de este servicio va a depender del proveedor del servicio, pero suelen ser de granularidad alta.
2.4.1.2. Políticas de Modelado
Política 1. Sólo se expondrán aquellos servicios que estén en las categorías: Integración, Utilidad, Dominio y de Negocio. Es obligatoria la alineación entre los servicios identificados y el proceso de Negocio.
Política 2. Los servicios se deben definir como funciones modulares y discretas de negocio disponibles mediante un Contrato Funcional; un documento NO TÉCNICO, mediante el cual se especifica la funcionalidad esperada del servicio.
Política 3. El nombre de los servicios creados debe ajustarse a una nomenclatura que permita identificar el tipo, el propósito y la versión del servicio. En el caso específico de los Servicios Web, el nombre consiste de una dirección URL que permite identificar el servicio de manera única, y ubicarlo para invocaciones mediante SOAP.
• Servicio: Es el nombre del servicio como tal. Debe describir brevemente (máximo 32 caracteres) el propósito del servicio, empleando UpperCamelCase y comenzando con una letra mayúscula.
• Versión: Debe mostrar los números de versión mayor y menor3 del servicio, separados por un guión bajo (eg. 1_0). En este caso se omite el número de revisión, ya que éstos no implican cambios para los clientes ligados al servicio.
•
Política 4. Para poder iniciar el proceso de ensamblado de un servicio, su contrato debe estar terminado y validado, y debe estar registrado en un repositorio de servicios. El proceso de ensamblado se detalla en la siguiente sección de este documento.
3De acuerdo a los lineamientos de control de versiones descritos en la de la sección de Administración de este documento.
2.4.1.3. Buenas prácticas de Modelado
Práctica 1. Establecer un vínculo correcto entre el área que se dedicara al desarrollo de los Web Services (Tecnologías de la Información, TI) y el área que lo requiere (Negocio) con el propósito de agilizar el proceso de identificación de la funcionalidad que expondrán los servicios. Para ello es necesario que el documento de “Visión” generado por los analistas del área del negocio al definir los requerimientos durante el proceso de “Requerimientos”, se entregue al iniciar la etapa de Modelado de servicios a la Oficina de Administración de Servicios, sin dejar a un lado las reuniones que necesiten realizar dichas áreas de la empresa para aclarar dudas al respecto.
Práctica 2. Ya que las actividades de la fase de modelado se basan en información brindada por el área del negocio, no deben mencionarse cuestiones técnicas en el Contrato Funcional del servicio.
2.4.2. Ensamblado
Una vez concluida la fase de Modelado de Servicios empieza la fase de Ensamblado. En esta fase se deben tomar como base los Contratos Funcionales generados en la fase anterior con el propósito de transformarlos en un conjunto de definiciones y requerimientos funcionales y no funcionales para el Área de TI, que a su vez permiten proceder a la implementación de los servicios.
Una de las claves para aplicar las políticas de gobernabilidad en esta fase de manera exitosa consiste en no intentar aplicarlas todas de una vez. Si se aplican al principio, el diseño tomará mucho más tiempo del necesario, y si se aplican al final, ya que en caso de detectar inconsistencias se pondrán en peligro las fechas de entrega.
Tomando en cuenta que la implementación de un servicio consiste de uno o más artefactos de software, la forma más natural es validar el apego con las políticas de gobernabilidad es hacerlo durante los momentos de transición que existen a lo largo del Ciclo de Vida de Desarrollo de Software. Este proceso de validación recibe el nombre de Ciclo de Desarrollo de Servicios.
2.4.2.1. Ciclo de desarrollo de servicios
La arquitectura SOA no define ni contempla el uso de ninguna metodología o proceso de desarrollo de software en particular, por lo que no sustituye a la metodología de desarrollo de la empresa que la utiliza, sino que la complementa.
La arquitectura SOA básicamente identifica cinco etapas o disciplinas dentro de la metodología de desarrollo, y cada una requiere de la intervención de distintos actores:
Repositorio de servicios. Es esencialmente un contenedor donde se almacena y se mantiene actualizada información de los servicios creados y modificados para así habilitar mecanismos de reutilización y evitar redundancias durante el desarrollo de nuevos servicios. Así mismo, un repositorio de componentes facilita el descubrimiento de servicios y la recuperación de la información necesaria para usarlos, particularmente si éstos deben ser descubiertos fuera del alcance funcional y temporal del proyecto en que fueron creados.
Oficina de Administración de Servicios. Es un área conformada por gente con conocimientos básicos a medios sobre tecnologías de la información y que entienden las necesidades y perspectivas que tiene el área de negocio de la empresa. La Oficina de Administración de Servicios se encarga de identificar y desarrollar todos los procesos para planificar, entregar y soportar los servicios de TI.
Requerimiento. Esta etapa del desarrollo se encuentra ligada con la fase de Modelado de la Arquitectura de Servicios, donde la actividad principal consiste en acordar los términos del Contrato Funcional para cada servicio. Esta etapa del proceso comienza por iniciativa del Área de Negocio, pues es quien genera el requerimiento que será recibido por el Área TI.
Requerimie Análisis y Implementa Pruebas Despliegue PMO
Arquitecto, Constructor, Revisor
de Implementación
Operador
Líder de TI, Ing. de Software, Arquitecto, Custodio de la
Aplicación Analista, Diseñador,
Arquitecto, Líder de TI, Líder del proyecto
Análisis y Diseño. Durante la fase de análisis y diseño se deben revisar los Contratos Funcionales a fin de documentar y describir las actividades requeridas para la construcción de cada servicio, y es cuando la posibilidad de re-uso tiene mayor relevancia.
El análisis realizado durante el desarrollo del servicio principalmente consiste en que la Oficina de Administración de Servicios identifique si la funcionalidad requerida la expone algún servicio registrado en el repositorio de servicios para proceder a utilizarlo o a modificarlo según las necesidades descritas en el Contrato Funcional o indicar que se debe crear un nuevo servicio. Además, en esta fase se convierten los requerimientos contenidos en el Contrato Funcional en especificaciones para la construcción del servicio, es decir, a partir del análisis se inicia el diseño del servicio que consiste en especificar los puntos necesarios para llevar a acabo la fase de Construcción:
• Tipo de servicio a construir
• Consumidores y posibles consumidores del servicio
• Dependencia de otros sistemas o servicios
• Funcionalidad que brindará el servicio para actividades específicas de los consumidores, basándose en los modelos de caso de uso de las actividades específicas del consumidor (ya sea sistema o aplicación que fungirá como cliente del servicio) los cuales deberán entregarse a la Oficina de Administración de Servicios junto con el documento de “Visión” en la etapa de Modelado.
• Interacción que tendrá el servicio dentro de las actividades específicas de los consumidores, incluyendo los diagramas de seguimiento correspondientes.
• Definición de las funciones que integrarán al servicio para cubrir las operaciones funcionales que se requieren, incluyendo los parámetros de entrada y salida, las excepciones posibles que presentarán dichas operaciones y la interacción entre el servicio y los sistemas o servicios de los que depende.
Construcción. Para la construcción de servicios se debe tomar como base la Especificación de Servicio y la especificación técnica para crear servicios, para cubrir las necesidades del negocio que debe abarcar el servicio y para cumplir con los estándares establecidos para la
Una vez creados los servicios se debe actualizar la especificación funcional, incluyendo como anexo la interfaces de los servicios y actualizando los puntos necesarios para que sea una descripción exacta de los mismos.
Pruebas. Esta fase es primordial para determinar si los artefactos de software desarrollados cumplen o no con lo estipulado en sus requerimientos. No obstante, aunque es posible aplicar cualquier tipo de prueba a estos artefactos, es difícil realizar pruebas de interacción convencionales entre Servicios Web, ya que estos pertenecen a la categoría de Sistemas Distribuidos.
Despliegue. Esta es la fase final del ciclo de vida del servicio, y se encuentra ligada con la fase de ensamblado de la arquitectura de servicios, ya que es en esta etapa donde se deben realizar las actividades necesarias para liberar el proyecto solicitado. En esta etapa también es necesario publicar en el repositorio de servicios implementados. Estas actividades y sus lineamientos se describen con más detalle en la sección de Despliegue de este documento.
2.4.2.2. Políticas de Ensamblado – Fase de Requerimientos
Política 1. Únicamente aquella funcionalidad que cumpla con alguno de los siguientes requisitos ameritará ser clasificada como servicio:
• Funcionalidad pensada para exponerse hacia usuarios externos: Este es el caso en que se requiere que una entidad externa, como por ejemplo un socio de negocio, acceda a funcionalidad de un sistema interno. La descripción del servicio típicamente contendrá un alto nivel de funcionalidad, pues la funcionalidad de bajo nivel está pensada para emplearse a nivel interno.
• Funcionalidad que puede ser utilizada por otros sistemas: El servicio se presentará como una capa de interoperabilidad entre sistemas internos de la compañía, de modo que un sistema pueda utilizar funcionalidad existente en otro sin tener que utilizar sus librerías o caer en redundancia.
En caso de que la funcionalidad no cumpla con ninguna de estas características no podrá ser clasificada como servicio, ya que no implica interacción entre dos sistemas y no podrá ser reutilizada.
Política 2. Una vez identificada y validada la funcionalidad que será expuesta por el servicio, el Contrato Funcional deberá ser revisado por la Oficina de Administración de Servicios. El propósito de esta revisión es determinar si la funcionalidad descrita en el Contrato Funcional puede ser cubierta por otro servicio ya existente, y en su caso las modificaciones que se tienen que efectuar al mismo para satisfacer los Niveles de Servicio requeridos.
2.4.2.3. Políticas de Ensamblado – Análisis y Diseño
Política 3. Una vez aprobada, la nueva Especificación del Servicio debe ser generada por el Área de Desarrollo mediante un documento donde se especifiquen los servicios y posteriormente registrado por la Oficina de Administración de Servicios en el repositorio de servicios con el objeto de hacerla disponible a otras áreas de negocio que se encuentren en el proceso de análisis.
2.4.2.4. Políticas de Ensamblado – Fase de Construcción
Política 4. Cada Especificación de Servicio, que el Área de Desarrollo elabore debe incluir una definición de las interfaces del servicio.
Política 5. Las interfaces de comunicación de cada servicio, se deben incluir en la Especificación del Servicio, y deberán incluir una descripción de los mensajes que serán empleados por el servicio. Los mensajes deberán estar catalogados de acuerdo al tipo de información que transportan de acuerdo a los siguientes criterios:
• Mensajes de petición: Son mensajes enviados por consumidores de un servicio, que proporciona información al proveedor para atender la solicitud.
• Mensajes de respuesta: Son mensajes generados por un proveedor de servicios.
Contienen la información obtenida de procesar el servicio y están dirigidos al cliente que hizo la petición.
• Mensajes de error: Son mensajes generados por un proveedor de servicios únicamente en el caso de que ocurran errores o excepciones al momento de procesar un mensaje a solicitud de un cliente.
No es necesario que un servicio defina mensajes de respuesta y error, siempre que se sujete
Política 6. Los mensajes descritos en las interfaces de comunicación de la Especificación de cada servicio deben contar con una estructura de meta-datos (del griego meta y latín datum o dato, literalmente sobredatos) con el propósito de habilitar mecanismos de monitoreo que sea necesario aplicar a los servicios. Esta estructura se debe proporcionar de manera adicional al contenido del mensaje de acuerdo al tipo de mensaje:
• Mensajes de petición:
o Nombre del servicio solicitado o Versión del servicio solicitado
o Cliente (aplicación) que realiza la solicitud o Usuario que realiza la solicitud (si aplica) o Nivel de servicio esperado
• Mensajes de respuesta:
o Nombre del servicio solicitado o Versión del servicio solicitado o Cliente (aplicación) que solicita o Usuario que solicita (si aplica)
• Mensajes de Error:
o Descripción del error
o Aplicación que generó el error
o Ubicación física (IP) de la aplicación que genera el error
2.4.2.5. Políticas de Ensamblado – Pruebas
Política 7. Antes de proceder con la fase de Despliegue de la Metodología de Servicios, se deberán efectuar pruebas de estrés a todas las funciones del servicio. Las pruebas de estrés deberán efectuarse de acuerdo a los procedimientos descritos en la sección ¡Error! No se encuentra el origen de la referencia. de este documento, siendo los de Verificación del desempeño y de Detección de problemas de concurrencia las más importantes.
Los resultados obtenidos para cada procedimiento de prueba deberán ser guardados en un documento, el cual deberá ser incluido como un anexo del Plan de Pruebas de la aplicación a la que pertenezca cada servicio.
Política 8. Una vez efectuadas las pruebas de estrés y elaborado el Documento de Resultado de Pruebas de Estrés se deberá validar que los resultados obtenidos cumplen con los Niveles de Servicio establecidos en el Contrato de Niveles de Servicio correspondiente, el cual se detalla en la sección de Administración de este documento. Esta validación se deberá hacer conjuntamente por parte del Área de Negocio, la Oficina de Administración de Servicios y el Custodio de la Aplicación.
2.4.2.6. Política de Ensamblado
Política 9. Si es necesario realizar cambios a algún servicio como resultado del proceso de pruebas, la Oficina de Administración de Servicios deberá registrar en el repositorio de servicios la nueva versión4 del la Especificación del Servicio y se deberán efectuar nuevamente las pruebas de funcionalidad y estrés correspondientes a fin de validar la funcionalidad completa del servicio.
2.4.2.7. Buenas Prácticas de Ensamblado
Práctica 1. A pesar de que sólo es obligatorio efectuar los procedimientos de Verificación del desempeño y de Detección de problemas de concurrencia, es recomendable que durante las pruebas de estrés se efectúen tantos procedimientos como sea posible con el fin de detectar posibles problemas de desempeño que pudieran presentarse durante la ejecución del servicio.
Práctica 2. Conviene que el Equipo de Desarrollo identifique lo antes posible el escenario5 en el cual se ejecutará el servicio después de la fase de despliegue, que considere sus características durante el diseño del servicio y que se efectúen los procedimientos de Verificación de la viabilidad del escenario durante las pruebas de estrés. De esta forma se evitará incurrir en costos adicionales de administración e infraestructura.
Práctica 3. Es recomendable contar con un proceso de seguimiento de errores a lo largo de la fase de ensamblado, apoyado en un contenedor asignado para este propósito. Deben registrarse tanto los errores presentados como su estado, es decir, cuales de ellos se están arreglando y los errores ya arreglados, su nivel de severidad, su prioridad y los artefactos de software donde se presentaron los errores.
También es importante mencionar los errores conocidos que serán arreglados en una versión posterior y las razones que llevaron a tomar esta decisión. Si en un momento posterior este error es detectado por el consumidor del servicio será posible notificar a quien reportó el error en qué versión será corregido.
2.4.3. Despliegue
La fase de despliegue del ciclo de vida incluye una combinación entre la creación del entorno de hospedaje para las aplicaciones y el despliegue real de esas aplicaciones en la infraestructura determinada. Esto incluye resolver las dependencias existentes entre los recursos de la aplicación, condiciones operativas, requisitos de capacidad e integridad y restricciones de acceso.
Hay diversos asuntos que son pertinentes para la construcción del entorno de hospedaje, incluyendo la presencia de la infraestructura de hospedaje ya existente y que da soporte a aplicaciones legadas y servicios preexistentes. En este punto se deben identificar servidores de aplicaciones, bus de servicio empresarial, orquestación de componentes, pero más allá de eso, se necesitará considerar los ofrecimientos de plataforma apropiados para alojar los procesos de interacción del usuario, los procesos de negocio, los servicios de negocios, los servicios de integración, la lógica de la información y los niveles de seguridad.
También es necesario apegarse a las políticas y técnicas preexistentes que aseguren disponibilidad, confiabilidad, integridad, eficiencia y capacidad de los servicios desarrollados.
2.4.3.1. Políticas de Despliegue
Política 1. El despliegue de cada servicio debe apegarse a los procedimientos descritos en la guía de desarrollo correspondiente, con el propósito de minimizar los tiempos requeridos, así como reducir los errores que pudieran presentarse durante la ejecución de estos
procedimientos. La guía que se tomará como base dependerá de la tecnología con la que se implementó el servicio y de la infraestructura objetivo para el hospedaje del mismo.
Política 2. El Arquitecto deberá asegurar la consistencia de los esfuerzos realizados tanto por el área de infraestructura como por el área de desarrollo durante la ejecución de los procedimientos de despliegue. La consistencia de esfuerzos será mayor en la medida en la que los procedimientos de despliegue, monitoreo y administración que contempla esta etapa se apeguen a los procedimientos descritos en la guía correspondiente.
Política 3. Al finalizar cada proceso de despliegue, la oficina de administración de servicios deberá actualizar en el repositorio de servicios el estatus de los servicios creados o modificados, incluyendo además el resultado de cada procedimiento de despliegue, es decir, si éste fue satisfactorio o si ocurrieron errores y en su caso las causas del error.
2.4.3.2. Buenas Prácticas de Despliegue
Práctica 1. Después del período de despliegue, y si éste fue exitoso, es recomendable designar un período de monitoreo de la infraestructura. Los resultados obtenidos del monitoreo se deben comparar con las métricas y los niveles de servicio esperados en el con el fin de detectar y corregir a tiempo cualquier desviación o fallo.
2.4.4. Administración
La administración es la fase de la metodología de servicios cuyo objetivo es monitorear y optimizar el desempeño de los servicios a través del monitoreo y la gestión sistemática de los mismos. El proceso de optimización requiere necesariamente de información obtenida durante la ejecución de los servicios, la cual deberá ser analizada con el propósito de identificar posibles áreas de oportunidad, así como medir los resultados obtenidos al final del proceso de optimización.
Para analizar correctamente los resultados obtenidos durante la ejecución del servicio es necesario tener en cuenta diversos aspectos, orientados tanto al negocio como al área de TI, de manera que los esfuerzos de optimización sean dirigidos correctamente y maximicen los beneficios obtenidos de este proceso.
2.4.4.1. Productividad y Acuerdos de Niveles de Servicio
El manejo de la productividad permite a la empresa verificar que los servicios trabajan de manera correcta, útil y eficiente, ayudándole a obtener sus objetivos de negocio. De esta manera los objetivos individuales de los servicios se encontrarán ligados a los objetivos organizacionales, brindándoles valor adicional.
Para poder estimar la productividad de un servicio es necesario establecer primero procedimientos de medición6, sin embargo, mientras que la medición se refiere únicamente a la evaluación de aspectos individuales como el número de invocaciones por hora o el tiempo promedio de atención, el manejo de la productividad implica además validar la medida en que estos aspectos individuales se apegan a las metas y objetivos de cada Área de Negocio.
Con la finalidad de medir el apego de un servicio los objetivos que el área de negocio espera del mismo se requiere definir un acuerdo de nivel de servicio (SLA por sus siglas).
Un SLA es un acuerdo negociado entre un proveedor de servicios y sus consumidores, mediante el cual se registra un entendimiento común acerca de los objetivos, prioridades, niveles, responsabilidades o garantías del servicio.
Es importante notar que los SLA están por naturaleza basados en salidas, y en particular, por la forma en la que el consumidor de un servicio recibe el resultado de la invocación de un servicio, es decir, cada SLA se relaciona con la forma en que el cliente recibe el servicio, y no a cómo el proveedor lo expone.
A pesar de que la validación de los SLAs se efectúa principalmente durante la ejecución del servicio, es importante que éstos se definan desde la fase de modelado.
2.4.4.2. Monitoreo
El monitoreo de servicios se refiere al proceso de extracción y seguimiento de la información obtenida durante la operación de un servicio, de tal forma que pueda ser analizada, y además se puedan generar estadísticas acerca del rendimiento de los servicios provistos.
6 Por ejemplo los Indicadores Clave de Desempeño definidos en el Contrato Funcional de un servicio
Es importante comparar los resultados obtenidos del monitoreo del servicio en ejecución con los resultados definidos en su Contrato Funcional, de esta manera se pueden encontrar discrepancias entre ambos, cuellos de botella u otras áreas de oportunidad.
El proceso de monitoreo consiste de los siguientes pasos:
• Recolección: Se concentra en colectar los datos requeridos para monitorear y medir servicios y sus componentes. Es necesario asegurarse de los datos recolectados son los correctos según las definiciones de métricas e indicadores del Contrato Funcional del servicio, pues de lo contrario los reportes generados a partir de ellos mostrarán información equivocada o inexacta.
• Procesamiento: El siguiente paso consiste en procesar los datos recolectados y presentarlos en un formato adecuado para su análisis dependiendo del tipo de reporte solicitado.
• Análisis: Los resultados de la etapa de procesamiento deberán analizarse, aplicando algún tipo de conocimiento de negocio a la información, ya que sin el conocimiento adecuado esta información no tiene ningún significado. El tipo de conocimiento necesario dependerá del Área de Negocio a la cual esté dirigido el reporte, y se busca responder a preguntas como las siguientes:
o ¿Existe algún tipo de tendencia en el comportamiento observado?
o ¿Se requieren acciones correctivas?
o ¿Se está operando de acuerdo a los Niveles de Servicio requeridos?
o ¿Se están alcanzando las metas del negocio?
Recolección Procesamiento Análisis Reporte
• Reporte: Es la forma de presentar o utilizar los resultados de etapas anteriores. Se toma el conocimiento y se presenta convirtiéndolo en sabiduría para la compañía que esta implementando los Web Services. Se utilizan reportes, planes de acción, revisiones, evaluaciones, peticiones de cambio y nuevas oportunidades de mejora.
De esta forma es posible hacer uso de la información recabada a partir del monitoreo de los servicios para efectuar una auditoria de los mismos. Efectuar estos procedimientos de auditoria y control sobre los servicios es fundamental para el buen funcionamiento de la Arquitectura de Servicios de la compañía.
2.4.4.3. Optimización
Una vez que se ha recuperado información de productividad, se han analizado los resultados obtenidos y se han identificado las áreas de oportunidad mediante las auditorias, se debe proceder a optimizar los servicios. De esta manera, la administración de los servicios continúa en forma de un ciclo que optimiza el valor de los servicios proveídos.
Con el fin de liberar un servicio optimizado, existirán cambios que se deberán realizar en los servicios previamente desplegados. Para esto se utilizarán políticas de control de cambios para asegurar métodos estandarizados y procedimientos para hacer los cambios de manera eficiente y minimizar su impacto. Además, deberán apegarse a las políticas de versionamiento en los servicios para facilitar el manejo de los mismos dentro del ciclo de optimización.
2.4.4.4. Políticas de Administración
Política 1. Es necesario que se lleve a cabo la celebración de un Contrato de Niveles de Servicio entre los proveedores y los consumidores de un servicio, mediante el cual la oficina de administración de servicios podrá verificar la productividad de cada servicio y su apego a las necesidades del Área de Negocio.
Política 2. Toda definición de Acuerdos de Nivel de Servicio deberá incluir las siguientes métricas:
