UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
La Universidad Católica de Loj
a
ÁREA TÉCNICA
TÍTULO DE INGENIERO EN SISTEMAS INFORMÁTICOS Y
COMPUTACIÓN
Consideraciones de Arquitectura de Software a nivel de Diseño Arquitectónico
y Desarrollo de Software para minimizar vulnerabilidades en aplicaciones web
basados en OWASP Top Ten 2013, caso de estudio arquitectura: SOA.
TRABAJO DE TITULACIÓN
AUTOR: Tenezaca Lima, Miguel Alejandro
DIRECTOR: Guamán Coronel, Daniel Alejandro, Mgs.
LOJA – ECUADOR
Esta versión digital, ha sido acreditada bajo la licencia Creative Commons 4.0, CC BY-NY-SA: Reconocimiento-No comercial-Compartir igual; la cual permite copiar, distribuir y comunicar públicamente la obra, mientras se reconozca la autoría original, no se utilice con fines comerciales y se permiten obras derivadas, siempre que mantenga la misma licencia al ser divulgada. http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es
ii
APROBACIÓN DEL DIRECTOR DEL TRABAJO DE TITULACIÓN
Magister
Daniel Alejandro Guamán Coronel
DOCENTE DE LA TITULACIÓN
De mi consideración:
El presente trabajo de titulación: “Consideraciones de Arquitectura de Software a nivel de Diseño Arquitectónico y Desarrollo de Software para minimizar vulnerabilidades en aplicaciones web basados en OWASP Top Ten 2013, caso de estudio arquitectura: SOA”, realizado por Miguel Alejandro Tenezaca Lima, ha sido orientado y revisado durante su ejecución, por cuanto se aprueba la presentación del mismo
Loja, marzo de 2016
f). ...
iii
DECLARACIÓN DE AUTORÍA Y CESIÓN DE DERECHOS
“Yo Miguel Alejandro Tenezaca Lima declaro ser autor (a) del presente trabajo de titulación: “Consideraciones de Arquitectura de Software a nivel de Diseño Arquitectónico y Desarrollo de Software para minimizar vulnerabilidades en aplicaciones web basados en OWASP Top Ten 2013, caso de estudio arquitectura: SOA”, de la Titulación de Sistemas Informáticos y Computación, siendo el Ing. Daniel Alejandro Guamán director (a) del presente trabajo; y eximo expresamente a la Universidad Técnica Particular de Loja y a sus representantes legales de posibles reclamos o acciones legales. Además certifico que las ideas, conceptos, procedimientos y resultados vertidos en el presente trabajo investigativo, son de mi exclusiva responsabilidad.
Adicionalmente declaro conocer y aceptar la disposición del Art. 88 del Estatuto Orgánico de la Universidad Técnica Particular de Loja que en su parte pertinente textualmente dice: “Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos científicos o técnicos y tesis de grado o trabajos de titulación que se realicen con el apoyo financiero, académico o institucional (operativo) de la Universidad”
f). ...
iv
DEDICATORIA
Mi trabajo de fin de titulación lo dedico con cariño:
A Dios, que me dio la oportunidad de vivir y el maravilloso regalo de mi familia.
A mis padres, que me han apoyado firmemente y han depositado toda su confianza en mí, brindándome sus sabias enseñanzas y gracias a ellos he podido culminar mis estudios profesionales.
v
AGRADECIMIENTO
Un cordial y respetuoso agradecimiento por la culminación del presente trabajo de fin de titulación: A Dios por la vida y las bendiciones que me ha dado.
A mis padres por su apoyo incondicional.
A mi director de Trabajo de fin de titulación por su apoyo y orientación durante la elaboración de este trabajo.
vi
CONTENIDO
CONTENIDO ... vi
ÍNDICE DE FIGURAS ... x
ÍNDICE DE TABLAS ... xiii
RESUMEN ... 1
ABSTRACT ... 2
INTRODUCCIÓN ... 3
Delimitación y definición del problema ... 4
Objetivos ... 5
Objetivo General ... 5
Objetivos Específicos ... 5
GLOSARIO DE TÉRMINOS ... 6
CAPÍTULO I ... 8
ESTADO DEL ARTE ... 8
1.1. Arquitectura de Software. ... 9
1.1.1. Definición. ... 9
1.1.2. Características de la Arquitectura de software. ... 10
1.1.3. Ventajas y desventajas del uso de Arquitecturas de software ... 10
1.1.4. Ciclo de desarrollo de la Arquitectura de Software. ... 11
1.2. Estilos Arquitectónicos ... 12
1.2.1. Definición ... 12
1.2.2. Tipos de estilos arquitectónicos... 12
1.3. Patrones ... 16
1.3.1. Patrones Arquitectónicos ... 16
1.3.2. Patrones de Diseño. ... 20
vii
1.4.1. Definición ... 27
1.4.2. Estructura y características de los Servicios Web ... 28
1.4.3. Especificaciones de los servicios web ... 29
1.4.4. Ventajas y desventajas de los Servicios Web ... 31
1.5. Arquitectura Orientada a Servicios. ... 32
1.5.1. Definición ... 32
1.5.2. Principios de la Orientación a Servicios. ... 33
1.5.3. Características de un servicio web SOA ... 35
1.5.4. Ventajas y desventajas de SOA ... 36
1.5.5. Elementos de SOA. ... 38
1.5.6. Capas de la arquitectura SOA. ... 39
1.5.7. Funcionamiento de SOA. ... 40
1.6. Vulnerabilidades ... 41
1.6.1. Definición ... 41
1.6.2. Tipos de vulnerabilidades ... 42
1.7. OWASP (The Open Web Application Security Project) ... 44
1.7.1. Definición ... 44
1.7.2. OWASP Top Ten ... 45
CAPÍTULO II ...50
PROPUESTA DE SOLUCIÓN ...50
2.1. Identificación de vulnerabilidades ... 51
2.2. Patrón arquitectónico ... 52
2.3. Patrones de diseño ... 52
2.4. Herramientas para el desarrollo del prototipo ... 53
2.5. Identificación de protocolos y estándares de seguridad ... 56
CAPÍTULO III ...64
viii
3.1 Diseño Arquitectónico de la aplicación ... 65
3.1.1. Web Service ... 66
3.1.2. Client App ... 67
3.2. Diseño de base de datos ... 67
3.3. Diseño de Seguridad ... 67
3.3.1. Codificación ... 67
3.3.2. Configuración ... 68
3.3.3. Base de datos ... 70
CAPÍTULO IV ...71
IMPLEMENTACIÓN DE LA SOLUCIÓN ...71
4.1. Base de datos ... 72
4.2. Codificación ... 73
4.3. Seguridad ... 79
4.3.1. Servicio Web ... 79
4.3.2. Aplicación Cliente Servicio Web ... 84
4.3.3. Filtros de Seguridad ... 84
CAPÍTULO V ...88
VALIDACIÓN ...88
5.1. Validación de Diseño... 89
5.2. Validación de Código ... 90
5.2.1. Primera Iteración ... 91
5.2.2. Segunda Iteración ... 93
5.3. Validación de Seguridad ... 94
5.3.1. Validación con Herramientas ... 94
5.3.2. Validación Manual ... 99
CONCLUSIONES ... 104
ix
BIBLIOGRAFÍA ... 106
ANEXOS ... 110
A. Modelo Entidad-Relación de base de datos. ... 111
B. Procedimientos almacenados implementados. ... 112
C. Documento WSDL del servicio web PftWebService implementado sin seguridad. ... 113
D. Configuración SAML con WSIT – Servicio web. ... 115
x
ÍNDICE DE FIGURAS
Figura 1. Arquitectura Centrada en Datos ... 13
Figura 2. Arquitectura Flujo de Datos ... 13
Figura 3. Arquitectura Llamada y Retorno ... 14
Figura 4. Arquitectura Orientada a Objetos ... 14
Figura 5. Arquitectura Orientada a Servicios... 15
Figura 6. Relación de abstracción entre estilos y patrones arquitectónicos ... 26
Figura 7. Especificaciones de los servicios web ... 30
Figura 8. Integración SOA ... 33
Figura 9. Interrelación entre los Principios SOA ... 35
Figura 10. Elementos de SOA. ... 38
Figura 11. Capas de SOA. ... 39
Figura 12. Ciclo de funcionamiento de los servicios web SOA ... 40
Figura 13. SQL Injection ... 46
Figura 14. Ejemplo de sentencia SQL... 46
Figura 15. Ejemplo de SQL Injection ... 47
Figura 16. Secuencia de comandos en sitios cruzados ... 48
Figura 17. Exposición de datos sensibles. ... 49
Figura 18. Componentes WSIT ... 55
Figura 19. Ejemplo de SOAP Request y SOAP Response ... 57
Figura 20. Estructura de documento WSDL ... 58
xi
Figura 22. Autenticación SAML ... 60
Figura 23. Estándares de seguridad implementados en servicios SOAP ... 61
Figura 24. Diseño arquitectónico de aplicación SOA propuesta ... 66
Figura 25. Creación de Procedimientos Almacenados en MySQL... 72
Figura 26. Procedimientos Almacenados ... 73
Figura 27. Dependencias - Archivo POM.xml ... 74
Figura 28. Diagrama de paquetes del proyecto pft-ws ... 75
Figura 29. Archivo glassfish-resources.xml ... 76
Figura 30. Paquete DAO ... 76
Figura 31. Clase PftPersonaService - Paquete Service ... 77
Figura 32. Operación getPersonas – PftWebService ... 78
Figura 33. Operación getModalidades – PftWebService ... 78
Figura 34. Operación personaPorCedula – PftWebService ... 79
Figura 35. Clase FiltroSecurity ... 84
Figura 36. Configuración de filtros de seguridad - web.xml ... 85
Figura 37. Clase XSSRequestWrapper ... 86
Figura 38. Código para encriptar – DES ... 87
Figura 39. Diseño arquitectónico – Validación ... 89
Figura 40. Patrón de Diseño Facade – Validación ... 90
Figura 41. Estabilidad del prototipo - Validación ... 90
Figura 42. Primera Iteración SonarQube ... 91
Figura 43. Segunda Iteración SonarQube ... 93
xii
Figura 45. Captura del tráfico con HTTPS - Wireshark ... 98
Figura 46. Cliente sin autenticación SAML ... 98
Figura 47. Captura de errores de autenticación SAML ... 99
Figura 48. Consulta de personas por cédula ... 99
Figura 49. Ataque SQL Injection ... 100
Figura 50. Código incorrecto de consulta SQL ... 100
Figura 51. Código correcto de consulta SQL ... 101
Figura 52. Aplicación Web contra ataque SLQ Injection ... 101
Figura 53. Insertar código JavaScript en la base de datos ... 102
Figura 54. Resultado de la Inserción de script en la base de datos ... 102
Figura 55. Ataque XSS ... 103
Figura 56. Modelo Entidad Relación de la base de datos... 111
Figura 57. Editar Atributos del Servicio Web – Configuración ... 115
Figura 58. Selección del mecanismos de seguridad - Configuración WSIT ... 116
Figura 59. Configuración Keystore ... 117
Figura 60. Configuración Truststore ... 117
Figura 61. Encriptación y Firmado de mensajes SOAP ... 118
Figura 62. Importación del WSDL en el cliente ... 119
Figura 63. Editar atributos del servicio web cliente ... 119
Figura 64. Configuración Keystore – Cliente ... 120
Figura 65. Configuración Truststore – Cliente ... 120
xiii
ÍNDICE DE TABLAS
Tabla 1. Patrones arquitectónicos ... 18
Tabla 2. Patrones de diseño... 22
Tabla 3. Diferencias entre estilos arquitectónicos y patrones arquitectónicos ... 26
Tabla 4. Ventajas y desventajas de los servicios web ... 31
Tabla 5. Ventajas y desventajas de la Arquitectura Orientada a Servicios ... 37
Tabla 6. Mitos y realidades sobre SOA. ... 41
Tabla 7. Resumen de tecnologías utilizadas... 62
Tabla 8. Requerimientos para configuración de SAML Authorization Vouches with Certificates .. 69
Tabla 9. Apis de java utilizadas en el proyecto ... 73
Tabla 10. Prueba de código con SonarQube - Iteración 1 ... 92
Tabla 11. Alertas del prototipo sin seguridad ... 95
Tabla 12. Alertas del prototipo con seguridad ... 96
1
RESUMEN
La orientación a servicios permite la integración y automatización de procesos de las empresas los mismos que al estar disponibles en la web son vulnerables a sufrir algún tipo de ataque; por ende existen organizaciones como OWASP encargadas de concientizar a los desarrolladores en la creación de software seguro y de calidad mediante el uso de normas y recomendaciones para evitar vulnerabilidades. El presente trabajo se centró en la implementación de un prototipo para mitigar vulnerabilidades de tipo: SQL Injection, XSS y exposición de datos sensibles en aplicaciones web construidas bajo el estilo arquitectónico SOA utilizando el patrón arquitectónico MVC, patrones de diseño Facade y DAO, técnicas de seguridad OWASP a nivel de codificación y configuración en el lenguaje de programación Java EE en Glassfish y la especificación WS-Security.
Finalmente el prototipo fué validado con herramientas como: Structural Analysis for Java, SonarQube, OWASP ZAP, Vega y Wireshark, para comprobar la calidad del prototipo a nivel de diseño, de codificación y de seguridad para contrarrestar los tipos de vulnerabilidades.
Palabras Clave: Exposición de datos sensibles, Inyección SQL, OWASP, SOA, SOAP,
2
ABSTRACT
Services orientation allow the integration and automating process of business the same as being available on the network are vulnerable to suffer any type of attack, there are some organization as OWASP responsable of raising awareness to the developers in the creation of a secure software and the quality through the use of standards and recommendations to avoid vulnerabilities. The present work was focus on the implementation of a prototype to reduce vulnerabilities such as: SQL Injection, XSS and exposure of sensitive data in web applications built under SOA using MVC as architectural pattern, Facade and DAO as design patterns, and principles and best practices given by OWASP to writing secure code, through Java EE configure the Glassfish Server and WS-Security specification.
Finally, the prototype was validate with tools such as: Structural Analysis for Java, SonarQube, OWASP, Vega and Wireshark, to analyze the quality of the prototype in terms of coding, design and security to counteract the vulnerability type’s.
3
INTRODUCCIÓN
Internet ofrece el ambiente ideal para la creación de aplicaciones web que permiten el intercambio de información, transacciones electrónicas entre otras funcionalidades, sobre todo permitiendo la interacción entre las empresas y sus clientes. La Arquitectura Orientada a Servicios (SOA) permite integrar diversos tipos de aplicativos mediante los servicios web, los cuales deben cumplir ciertos requisitos del cliente y además poseer ciertos estándares de seguridad que garanticen que la aplicación final sea de calidad.
Bajo este criterio en el presente proyecto se propone que a través del uso del patrón arquitectónico MVC y de los patrones de diseño Facade y DAO se minimicen las vulnerabilidades a nivel de desarrollo de código de dichas aplicaciones, para ello se realiza un análisis y estudio de algunas metodologías, técnicas y procedimientos que asociadas a dicha arquitectura permitan cumplir con el objetivo desde el punto de vista de diseño y desarrollo de software.
Para el desarrollo del proyecto se han propuesto las siguientes actividades para su cumplimiento: • Contextualización del estado de arte para el desarrollo del producto software.
• Diseño de la solución/prototipo software. • Desarrollo de la solución/prototipo Software. • Validación de la solución/prototipo software
4
Delimitación y definición del problema
En la actualidad SOA ha adquirido una gran importancia debido a que permite la flexibilidad y la integración de aplicativos desarrollados en diferentes plataformas, realizar transacciones e intercambiar información, lo que ha permitido generar nuevas oportunidades y problemas. El software inseguro amenaza de forma permanente y directa a las aplicaciones o servicios expuestos en la web, lo que hace que los sistemas sean vulnerables, poniendo en riesgo la información que se maneja en éstos. Por tal razón el presente proyecto busca obtener una guía con las normas y estándares de seguridad que se adapte al diseño y desarrollo de aplicaciones web con el estilo arquitectónico SOA.
OWASP es una fundación sin fines de lucro que busca combatir los diferentes riesgos que se asocian a las aplicaciones web; en ésta investigación se considera que en función de los tipos de vulnerabilidades expuestos en el Top Ten 2013 de OWASP debe analizarse los tipos de vulnerabilidades a considerar cuando se trabajan con el estilo arquitectónico SOA. Uno de los objetivos principales de OWASP es crear conciencia en los desarrolladores para escribir un buen código con la finalidad de incrementar la seguridad en las aplicaciones web.
El presente trabajo tiene como propósito investigar, analizar y poner en práctica algunas consideraciones a nivel de diseño arquitectónico y desarrollo de software para la elaboración de aplicaciones web seguras con el fin de minimizar ciertos tipos de vulnerabilidades que pueden incidir al utilizar un estilo arquitectónico SOA.
5
Objetivos
Objetivo General
Identificar los patrones, métricas y estándares que asociados al estilo arquitectónico SOA permitan minimizar algunos de los tipos de vulnerabilidades listados en OWASP Top Ten 2013 desde el punto de vista de diseño arquitectónico y desarrollo de software.
Objetivos Específicos
• Analizar los tipos de vulnerabilidades que pueden afectar la seguridad de una aplicación de software diseñada bajo un estilo arquitectónico SOA.
• Identificar los patrones de diseño, patrones arquitectónicos, patrones de seguridad o frameworks que permitan y garanticen un diseño arquitectónico adecuado y una codificación de software segura para aplicarlo en una arquitectura orientada a servicios. • Diseñar e implementar un prototipo de software utilizando patrones, métricas, estándares
6
GLOSARIO DE TÉRMINOS
API.- Aplication Programming Interface (Interfaz de Programación de Aplicaciones).
CORBA.- Common Object Request Broker Architecture (Arquitectura común de intermediarios en
peticiones a objetos).
DAO.- Data Access Object (Objeto de Acceso a Datos).
DCOM.- Distributed Component Object Model (Modelo de Objetos de Componentes Distribuidos).
EJB.- Enterprise JavaBeans (Beans empresariales de Java).
HTTP.- Hypertext Transfer Protocol (Protocolo de Transferencia de Hipertexto).
HTTPS.- Hypertext Transfer Protocol Secure (Protocolo de Transferencia de Hipertexto Seguro).
IDE.- Integrated Development Enviromment (Ambiente de Desarrollo Integrado).
J2EE.- Java 2 Platform Enterprise Edition (Edición Empresarial de la Plataforma Java 2).
JPA.- Java Persistence Api (Api de Persistencia de Java).
JSF.- Java Server Faces.
JSP.- JavaServer Pages.
MVC.- Model View Controller (Modelo Vista Controlador).
ORM.- Object-Relational Mapping (Mapeo Objeto-Relacional)
OWASP.- The Open Web Application Security Project.
OWASP ZAP.- OWASP Zed Attack Proxy.
RPC.- Remote Procedure Call (Llamadas a Procedimientos Remotos).
SMTP.- Simple Mail Transfer Protocol (Protocolo para Transferencia Simple de Correo).
SOA.- Service Oriented Architecture (Arquitectura Orientada a Servicios).
SOAP.- Simple Object Access Protocol (Protocolo Simple de Acceso a Datos).
7
SSL.- Secure Sockets Layer.
TOKEN.- Un token de seguridad (también token de autenticación o token criptográfico).
UDDI.- Universal Description, Discovery and Integration.
URI.- Uniform Resource Identiflier
W3C.- World Wide Web Consortium.
WS-BPEL.- Web Service Business Process Execution Language (Lenguaje de Ejecución de
Procesos de Negocio con Servicios Web).
WS-CDL.- Web Services Choreography Description Language (Lenguaje para la descripción de
Coreografías de Servicios Web).
WSDL.- Web Services Description Language (Lenguaje de Descripcipon de Servicios Web).
WS-I.- Web Service Interoperability.
WSIT.- Web Service Interoperability Technologies.
XML.- eXtensible Markup Language (Lenguaje de Marcas extensible).
8
CAPÍTULO I
9
1.1. Arquitectura de Software.
1.1.1. Definición.
Cervantes (2010) se refiere a la arquitectura de software como la estructuración del sistema elaborado en etapas iniciales del desarrollo del software, la misma que representa un diseño de alto nivel con el objetivo de satisfacer los atributos de calidad y servir como de guía de referencia para los desarrolladores.
Para L. F. Fernández (2006) la arquitectura de software “ha emergido como una disciplina de gran importancia dentro de la ingeniería de software. Una arquitectura adecuada es pieza clave para lograr tanto requerimientos funcionales como no funcionales de un sistema. Por otro lado una arquitectura no adecuada puede ser catastrófica”.
La arquitectura de software se puede definir como la “estructura o estructuras del sistema, que comprenden componentes de software, las propiedades externamente visibles de esos componentes, y las relaciones entre ellos” (Gardazi & Shahid, 2009). Y Bosch (2000), complementa el concepto de arquitectura de software mencionando que la arquitectura de software es importante porque afecta el desempeño, la potencia, la capacidad de distribución y el mantenimiento de un sistema.
La arquitectura de software identifica los diferentes componentes del sistema, la interacción entre ellos y la configuración del sistema, la arquitectura de software se puede documentar de manera adecuada mediante el uso de diagramas simples donde se indican los componentes o elementos del sistema y la interacción entre ellos. La técnica de la arquitectura es la descomposición del sistema en componentes más pequeños con aspectos específicos comunes, mediante la abstracción, y que al unirse y organizarse permiten la solución de un problema específico más grande. En la arquitectura de software se contemplan las propiedades de un sistema en su entorno formada por sus elementos, relaciones y por los principios de su diseño y evolución.
Como lo menciona Bosch (2000), la arquitectura de un sistema depende de los requerimientos no funcionales como: Rendimiento, Seguridad, Protección, Disponibilidad y Mantenibilidad.
• Rendimiento.- Se refiere a las respuestas del sistema, ya sea el tiempo requerido para
10
• Seguridad.- Se debe usar una estructura en capas para proteger los componentes más
vulnerables en las capas más internas, con un alto nivel de seguridad aplicado en dichas capas.
• Protección.- La arquitectura se debe diseñar de modo que las operaciones
relacionadas con la protección se ubiquen en algún componente individual. Con esto se reduce los costes y los problemas de validación de la protección.
• Disponibilidad.- La arquitectura tiene que diseñarse para incluir componentes
redundantes de manera que sea posible sustituir y actualizar los componentes sin detener el sistema
• Mantenibilidad.- La arquitectura debe diseñarse usando componentes auto contenidos
que puedan cambiarse con facilidad, conservando su funcionamiento normal.
1.1.2. Características de la Arquitectura de software.
Una buena arquitectura de software debe poseer las siguientes características:
• Facilidad para los usuarios y desarrolladores en la comprensión del sistema.
• La planificación de proyectos, el análisis de riesgo, la organización, el proceso de desarrollo, los ciclos de trabajo, el hardware, la garantía de calidad y los requerimientos son factores influyentes de la arquitectura de software
• Es una representación abstracta de alto nivel de la estructura del sistema describiendo las partes que lo integran.
• Contiene patrones que controlan la composición y las restricciones del sistema. • Implica aspectos de diseño y desarrollo de software.
• Se compone de los componentes, las propiedades y las relaciones que se establecen entre ellos.
• Es la base de la construcción del software.
• Se concentra en los requerimientos no funcionales del sistema.
1.1.3. Ventajas y desventajas del uso de Arquitecturas de software
11
del equipo de desarrollo, sirve como puente entre los requerimientos del sistema y la implementación, permite la reutilización y permite predecir y mitigar riesgos ofreciendo un software de calidad (C. Reynoso, 2004). Por otro lado, una arquitectura no adecuada puede ser catastrófica, Clements & Northrop (1996) nombra algunos aspectos negativos de la arquitectura de software: no existe un criterio unificado acerca de la arquitectura de software, limitaciones tecnológicas y el tiempo de elaboración del marco de referencia es bastante amplio.
1.1.4. Ciclo de desarrollo de la Arquitectura de Software.
Cervantes (2010) menciona que el ciclo de desarrollo de la arquitectura de un software es independiente de la metodología que se utilice en el proyecto de desarrollo de software, y se compone de las siguientes etapas: Requerimientos, Diseño, Documentación y Evaluación. Así mismoBarraza ( n.d.) define las etapas del proceso de desarrollo de arquitectura de software en 3 etapas: Definición de requerimientos, Diseño de la arquitectura y Validación. A continuación se resumen en que consiste cada etapa:
• Definición de requerimientos.- Esta etapa se centra en la recopilación,
documentación y priorización de los requisitos o requerimientos que afecten a la arquitectura; estos requerimientos principalmente son los atributos de calidad del sistema. También los requisitos funcionales afectan a la arquitectura y se las toma en cuenta en esta fase así como las restricciones.
• Diseño de la arquitectura.- Esta etapa es la más complicada, porque es aquí donde
se definen las estructuras y responsabilidades de los componentes de la arquitectura, en base a patrones de diseños, técnicas de diseño y la selección de herramientas tecnológicas para el diseño arquitectónico; el diseño debe satisfacer los requerimientos identificados en la fase anterior.
• Documentación.- Al diseño arquitectónico anterior se lo debe documentar de forma
apropiada, ya que de esta depende que los demás interesados en el desarrollo la puedan entender. La documentación de la arquitectura se compone de la representación de las estructuras a través de distintas vistas. Las vistas por lo general están conformadas por diagramas con información adicional que apoya la compresión del diagrama.
• Evaluación o validación.- Se prueba o verifica el diseño con los requerimientos
12
el equipo de desarrollo implemente los componentes, conectores y configuración adecuada.
En base a lo expuesto anteriormente la base para la construcción de una buena arquitectura de software es la identificación de los requisitos que se deben resolver con el sistema, luego el diseño de una arquitectura en base a los requerimientos y finalmente la validación de la arquitectura diseñada. Sin dejar de lado que todo esto debe estar bien documentado para posibilitar la comunicación entre los interesados, y poder llevar un mejor monitoreo sobre el ciclo de desarrollo de la arquitectura de software.
1.2. Estilos Arquitectónicos
1.2.1. Definición
Según Camacho, Cardeso, & Nuñez (2004) define al estilo arquitectónico como un patrón que organiza estructuralmente los componentes, tipos de conectores y un conjunto de limitaciones o restricciones de cómo pueden ser usadas.
Buschmann, Meunie, Rohnert, Sommerlad, & Stal (2000) considera los estilos arquitectónicos como la base fundamental de la estructura de un sistema software, asociado de métodos que especifican la forma de implementarlo, cuando usarlo, sus especializaciones y las consecuencias de sus uso.
1.2.2. Tipos de estilos arquitectónicos
Los estilos arquitectónicos indican los tipos de componentes y conectores involucrados. A continuación se detallan algunos tipos de estilos arquitectónicos (Rivera Posso, 2004):
• Arquitecturas Centradas en Datos: Esta arquitectura sitúa en el centro un almacén de
13 Figura 1. Arquitectura Centrada en Datos
Fuente: (C. B. Reynoso, 2004) Elaboración: Autor
• Arquitecturas de Flujo de Datos: En esta arquitectura los datos de entrada son
[image:27.595.160.464.83.319.2]transformados a través de una serie de componentes en datos de salida. Está constituido por Filtros conectados por Tuberías que se encargan de transmitir los datos entre los componentes. Los filtros están diseñados para recibir los datos de entrada de una forma y producir la salida de otra forma. Como se muestra es la Figura 2:
Figura 2. Arquitectura Flujo de Datos
Fuente: (C. B. Reynoso, 2004) Elaboración: Autor
• Arquitecturas de Llamada y Retorno: Provee de estructuras de programas de fácil
cambio y escalabilidad. Es muy utilizado en sistemas de gran escala, y este estilo se divide en sub estilos: programa principal/subprograma, llamada de procedimiento remoto. Como se muestra en la Figura 3:
Base de Datos Fuente de Conocimiento
Fuente de Conocimiento
Fuente de Conocimiento
Fuente de Conocimiento
Filtro Filtro
Filtro
Filtro
Filtro
Filtro
Tubería
Tubería
Tubería
Tubería
Tubería
14 Figura 3. Arquitectura Llamada y Retorno
Fuente: (Sommerville, 2011) Elaboración: Autor
• Arquitectura Orientada a Objetos: Los datos y operaciones se encapsulan en los
componentes del sistema, para luego ser utilizados. La comunicación y coordinación entre los componentes es realizado por medio de envío de mensajes, como se muestra en la Figura 4:
Figura 4. Arquitectura Orientada a Objetos
Fuente: (Ahumada Ahumada, 2013) Elaboración: Autor
• Arquitectura Orientada a Servicios: Estilo SOA permite un diseño para la integración de
aplicaciones independientes a través de la red, disponiendo sus funcionalidades por medio de servicios. Los servicios web constituyen una base importante para la implementación de este estilo arquitectónico, se basa en estándares como SOAP, WDSL, UDDI, XML, etc.
Programa Principal
Rutina 1 Rutina 2 Rutina 3
Rutina 1.1 Rutina 1.2 Rutina 3.1 Rutina 3.2
EntryPoint
Obj eto
Obj eto Obj eto
Obj eto
15
SOA permite descomponer aplicaciones monolíticas en servicios independientemente de la plataforma en que estén construidas, e implementar estas funcionalidades en forma modular, Figura 5. El tema SOA será profundizado más adelante.
Figura 5. Arquitectura Orientada a Servicios
Fuente: (Sommerville, 2011) Elaboración: Autor
En un estilo arquitectónico se definen los componentes, conectores y las interfaces de la aplicación, se detallan cómo los componentes y los conectores pueden configurarse en un sistema de software. Así mismo los estilos arquitectónicos contienen un conjunto de las limitaciones que establecen las funciones de los componentes arquitectónicos y sus relaciones.
En resumen, la arquitectura de un sistema de software puede basarse en uno o en varios estilos arquitectónicos, los cuales describen:
• Un conjunto de componentes con sus responsabilidades. • Un conjunto de conectores entre componentes.
• Restricciones que definen como se integran los componentes. • Modelo de las propiedades del sistema.
SOA como tema principal del presente trabajo, será abordado a profundidad más adelante, donde se verá sus principios, características, elementos, capas, etc.
Registro de Servicios
Proveedor del Servicio Solicitante del
Servicio
Servicio Encontrar
Unir (SOAP)
16
1.3. Patrones
1.3.1. Patrones Arquitectónicos
Sommerville (2011) define los patrones arquitectónicos como:
Una descripción abstracta estilizada de buena práctica, que se ensayó y se puso a prueba en diferentes sistemas y entornos. De este modo, un patrón arquitectónico debe describir una organización de sistemas que han tenido éxito en sistemas previos. Debe incluir información sobre cuándo es y cuándo no es adecuado usar dicho patrón, así como las fortalezas y debilidades del patrón. (p. 156)
Para Venete (2011) los patrones arquitectónicos ofrecen soluciones a problemas de ingeniería de software especificando un conjunto de componentes con sus respectivas responsabilidades y recomendaciones de cómo organizar estos componentes.
Un patrón consta de 3 partes según Camacho et al., (2004):
• Contexto.- Situación de diseño en la que aparece un problema de diseño. • Problema.- Conjunto de fuerzas que aparecen repetidamente en el contexto. • Solución.- Configuración que equilibra estas fuerzas. Que abarca:
o Estructura de componentes y relaciones.
o Comportamiento a tiempo de ejecución: aspectos dinámicos de la solución, como
la colaboración entre componentes, la comunicación entre ellos, etc.
Los patrones arquitectónicos son medios para reutilizar el conocimiento sobre las arquitecturas de sistemas, describen la arquitectura definiendo la estructura básica del sistema; representa una plantilla de construcción que provee un conjunto de subsistemas con sus responsabilidades, que facilitan el diseño arquitectónico.
El diseño arquitectónico es la base fundamental de toda aplicación, porque en él se establecen los subsistemas y la comunicación entre ellos. Un buen diseño arquitectónico tiene como ventajas: una buena comunicación entre los actores del sistema, análisis del sistema y la reutilización.
Tipos de los Patrones Arquitectónicos.
17 • Modelo-Vista-Controlador.
• Capas. • Repositorio. • Cliente-Servidor.
• Arquitectura Tubería y Filtro.
Tabla 1. Patrones arquitectónicos
PATRON DESCRIPCION VENTAJAS DESVENTAJAS
Modelo Vista Controlador
Define el modelo de datos, la presentación y las acciones de la aplicación en tres capas distintas:
Modelo: Controla el acceso y comportamiento de los datos del dominio de aplicación.
Vista: Se encarga de la visualización de la información en el cliente.
Controlador: Define los eventos o acciones del usuario, invocando peticiones al modelo y envía la respuesta a la vista para la presentación.
Permite que los datos cambien de manera independiente de su representación y viceversa.
Soporta en diferentes formas la presentación de los mismos datos, y los cambios en una representación se muestran en todos ellos.
Puede implicar código adicional y complejidad de código cuando el modelo de datos y las interacciones son simples.
Capas
Se definen distintas capas en la aplicación de manera que sólo se comunican entre sí las capas adyacentes.
Favorece el bajo acoplamiento.
Este es el estilo arquitectónico empleado en las aplicaciones web convencionales.
Permite la sustitución de capas completas en tanto se conserve la interfaz.
Para aumentar la confiabilidad del sistema, en cada capa pueden incluirse facilidades redundantes (Autenticación).
Separación difícil entre capas, y es posible que una capa de nivel superior deba interactuar con una capa de nivel inferior.
Rendimiento suele ser un problema, debido a múltiples niveles de interpretación de una solicitud de servicio mientras se procesa en cada capa.
Repositorio
Todos los datos en un sistema se gestionan en un repositorio central, accesible a todos los componentes del sistema. Los componentes no interactúan directamente, sino tan sólo a través del repositorio.
Los componentes pueden ser independientes, no necesitan conocer la existencia de otros componentes. Los cambios hechos por un componente se pueden propagar hacia todos los componentes.
La totalidad de datos se puede gestionar de manera consistente, pues todos están en un lugar.
El repositorio es un punto de falla único, de modo que los problemas en el repositorio afectan a todo el sistema.
Es posible que haya ineficiencias al organizar toda la comunicación a través del repositorio.
Quizá sea difícil distribuir el repositorio por medio de varias computadoras.
Cliente - Servidor
La funcionalidad del sistema se organiza en servicios, y cada servicio lo entrega un servidor independiente. Los clientes son usuarios de dichos servicios y para utilizarlos ingresan a los servidores.
Los servidores se pueden distribuir a través de una red.
19
La funcionalidad general estaría disponible a todos los clientes, así que no necesitan implementarse en todos los servicios.
El rendimiento resultará impredecible porque depende de la red, así como del sistema.
Problemas administrativos cuando los servidores sean de propiedad de diferentes organizaciones.
Tubería y Filtro
Se aplica cuando los datos de entrada se han de transformar en datos de salida mediante una serie de operaciones.
Los componentes (filtros) van transmitiendo datos al siguiente por medio de tuberías.
Los filtros no necesitan saber el funcionamiento de los vecinos. Sólo se preocupan de su entrada y su salida.
Si hay una sola línea de transformaciones se denomina procesamiento por lotes secuencial (pipeline).
Fácil de entender y soporta reutilización de transformación.
La evolución al agregar transformaciones es directa.
Puede implementarse como un sistema secuencial o como uno concurrente.
El formato para la transferencia de datos debe acordarse entre las transformaciones que se comunican.
Cada transformación debe analizar sus entradas y sintetizar sus salidas al formato acordado.
Carga aumentada del sistema, lo que hace imposible reutilizar transformaciones funcionales que usen estructuras de datos incompatibles.
Los patrones arquitectónicos ofrecen soluciones a problemas de arquitectura de software en ingeniería de software. Proveen una descripción de los elementos y el tipo de relación que tienen con un conjunto de restricciones sobre cómo pueden ser usados, representando un esquema estructural y fundamental del sistema software y sus elementos.
1.3.2. Patrones de Diseño.
“El patrón de diseño es una descripción del problema y la esencia de su solución, de modo que la solución puede reutilizarse en diferentes configuraciones; no es una especificación detallada” (Sommerville, 2011). Los patrones representan una forma de describir las mejores prácticas de diseño para poderlos reutilizar, así mismo detallan aspectos relacionados con el diseño de los subsistemas, centrándose en aspectos más específicos de la aplicación; los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y para el diseño de interfaces.
Sommerville (2011) presenta 4 elementos que conforman los patrones de diseño: • Nombre significativo.
• Descripción del área problemática.
• Descripción de la solución, relaciones y responsabilidades.
• Estado de las consecuencias, resultados y negociaciones al aplicar el patrón.
Características de los Patrones de Diseño.
Los patrones de diseño ayudan a un diseñador a lograr un buen diseño más rápidamente, haciendo que sean más fáciles reutilizar diseños y arquitecturas, utilizando técnicas que ya han sido probadas anteriormente. Cada patrón de diseño se centra en un problema concreto, describiendo cuando y como utilizarlo. Las principales características de los patrones de diseño son:
• Ser efectivo para resolver problemas similares. • Reutilizable.
• Aplicable a diferentes problemas de diseño en distintas circunstancias
• Proporcionar catálogos de elementos reusables en el diseño de sistemas software. • Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y
solucionados anteriormente.
• Formalizar un vocabulario común entre diseñadores. • Estandarizar el modo en que se realiza el diseño.
21
Los patrones de diseño son soluciones bien pensadas a problemas conocidos de la programación, ya que abstraen el comportamiento de un determinado problema en una configuración de componentes y están clasificados de acuerdo con el nivel de abstracción que tenga cada patrón.
Tipos de Patrones de Diseño.
Un patrón de diseño puede considerarse como un documento que define una estructura de clases que aborda una situación particular. Los patrones de diseño se dividen en tres grupos principales (Tedeschi, 2014):
• Patrones Creacionales: se encargan de la inicialización, configuración de objetos y
creación de instancias. Resuelven problemas relacionados con la creación de instancias de objetos.
• Patrones Estructurales: Se encargan de aislar la interfaz de la implementación, es
decir, definen como las clases y objetos se asocian para formar estructuras más complejas.
• Patrones de Comportamiento: Se encargan de la descripción de las clases y objetos
y la comunicación e interacción entre ellos en tiempo de ejecución.
Tabla 2. Patrones de diseño
PATRON DESCRIPCIÓN SE USA CUANDO
Abstract Factory (Creacional)
Crea familias de objetos relacionados o dependientes sin necesidad de especificar su clase concretamente
* Ser independiente de cómo se crean, se componen y se representan sus productos.
* Debería ser configurado mediante una de las múltiples familias de productos posibles.
* Se diseña una familia de objetos relacionados que deben ser usados en conjunto.
* Proveer una librería de una clase de productos y es necesario revelar simplemente sus interfaces, pero ocultar sus implementaciones.
Builder (Creacional)
Separa el proceso de construcción de un objeto complejo de su representación, para que el mismo proceso de construcción pueda crear diferentes representaciones
* El algoritmo para crear objetos complejos debe ser independiente de las partes que constituyen el objeto y la forma en que son ensamblados.
* La construcción de procesos debe permitir diferentes representaciones para el objeto que se construye.
Prototype (Creacional)
Crea objetos nuevos copiándolos, clonando una instancia creada previamente
* Las clases a instanciar son especificadas en tiempo de ejecución
* Para evitar la construcción de una jerarquía de la clase de fábricas que se asemeja a la jerarquía de la clase de productos
* Cuando instancias de una clase pueden tener una de las combinaciones de diferentes estados.
* Cuando es necesario la creación de distintas variantes de un objeto. Entonces, el código que utilizan esos objetos solicitará una copia del objeto que necesite, una copia significa otra instancia del objeto. El único requisito que debe cumplir el objeto es la posibilidad de clonarse.
Adapter (Estructural)
Sirve para convertir una interfaz de una clase en otra, haciendo que una clase a la que le fuera imposible utilizar la primera interface, haga uso de ella por medio de la segunda. Es decir, permite que éstas trabajen juntas, lo que de otra forma sería incompatible
* Es necesario el uso de una clase existente, y su interfaz es distinta a la que se necesita.
23 Bridge (Estructural)
Mediante el patrón Bridge es posible desacoplar una
abstracción de su
implementación, de forma que ambas puedan modificarse de manera independiente sin necesidad de alterar por ello la otra.
* Se desea evitar una vinculación permanente entre la abstracción y su implementación. Este puede ser el caso en que la implementación debe ser seleccionada o modificada en tiempo de ejecución.
* Las abstracciones y sus implementaciones deben ser extensibles a través de subclases. En este caso, el patrón Bridge permite combinar diferentes abstracciones e implementaciones y extenderlas en forma independiente.
* Los clientes no deben tener que recompilar el código cuando se lleven a cabo modificaciones en la implementación de una abstracción.
* Se desea ocultar completamente la implementación de una abstracción a los clientes.
* Se necesita compartir una implementación entre varios objetos, y este hecho debe ocultarse a los clientes.
Composite (Estructural)
Admite construir objetos complejos por medio de la composición recursiva de objetos similares u otros más simples en una estructura en forma de árbol. Además permite que dichos objetos sean tratados de manera semejante, sin hacer distinciones entre ellos.
* Es necesario representar la jerarquía completa de objetos.
* Se necesita que el cliente no note la diferencia entre una composición de objetos y un objeto individual, de esta forma el cliente tratará a todos los objetos en la composición de la estructura uniformemente.
Facade (Estructural)
Simplifica el acceso a un conjunto de clases proporcionando una única clase que todos utilizan para comunicarse con dicho conjunto de clases.
* Los clientes no necesitan conocer las clases que hay tras la clase Facade.
* Quiere proveer una interfaz única para un subsistema complejo. Esto ayuda a que un subsistema sea más reusable y fácil de adaptar.
* Hay muchas dependencias entre clientes y clases que implementan una abstracción. Con el patrón Facade se desacopla el cliente del subsistema, así como entre subsistemas; esto promueve subsistemas independientes y portables.
24 Data Access
Object (Estructural)
DAO define un interfaz con operaciones para insertar, borrar, actualizar y recuperar los objetos persistentes de un tipo.
* Para abstraer y encapsular todos los accesos a la fuente de datos.
* Desacoplar la lógica de negocio de la lógica de acceso a datos, de manera que se pueda cambiar la fuente de datos fácilmente.
* Para manejar la conexión con la base de datos y para manejar las operaciones CRUD.
* Poder seleccionar la fuente de datos durante la instalación o configuración de la aplicación.
Proxy (Estructural)
Se emplea como intermediario para acceder a un objeto, controlando el acceso a él.
* Un proxy remoto provee una representación local de un obj* Para abstraer eto ubicado en un espacio de dirección diferente.
* Un proxy virtual crea objetos de gran tamaño bajo demanda.
* Un proxy de protección controla el acceso al objeto original, controlando quien accede a cada método y otorgando los permisos basándose en el invocador.
* Una referencia elegante lleva a cabo acciones extras cuando se acceden a objetos referenciados.
Observer
(Comportamiento)
Define una dependencia del tipo uno-a-muchos entre objetos, de manera que cuando uno de los objetos cambia su estado, el observer se encarga de notificar este cambio a todos los otros objetos dependientes.
* Una abstracción tiene dos aspectos, uno dependiente del otro. Encapsulándolos en objetos separados se permite variarlos y reusarlos de forma independiente.
* Cuando un cambio en un objeto implica cambiar otros y no se conoce de antemano cuantos objetos deben actualizarse
* Cuando un objeto debe ser capaz de hacer notificaciones a otros sin hacer suposiciones de quiénes son, buscando un bajo acoplamiento.
Command (Comportamiento)
Permite solicitar una operación a un objeto sin conocer realmente el contenido de esta operación, ni el receptor real de la misma. Para ello se encapsula la petición como un objeto, facilitando la parametrización de los métodos. Al encapsular un mensaje como
* Facilitar la parametrización de las acciones a realizar
* Independizar el momento de petición del de ejecución
* Implementar CallBacks, especificando que órdenes se necesitan ejecutar en ciertas situaciones bajo otras órdenes. Es decir, un parámetro de una orden puede ser otra orden a ejecutar. .
25 un objeto, permite gestionar
colas o registros de mensajes, deshacer operaciones y restaurar el estado a partir de un momento dado.
* Desarrollar sistemas utilizando órdenes de alto nivel que se construyen con operaciones sencillas (primitivas).
State
(Comportamiento)
Permite que un objeto cambie en tiempo de ejecución su comportamiento cuando cambia su estado interno.
* El comportamiento de un objeto depende de su estado y este cambia con mucha frecuencia.
* Los métodos tienen largas y múltiples sentencias condicionales que dependen del estado del objeto. Estos estados generalmente son representados por constantes enumeradas y largas sentencias “switch/case” dentro de los métodos. El patrón State ubica cada rama del condicional en clases separadas.
Strategy
(Comportamiento)
Define una familia de algoritmos, encapsula cada uno y los hace intercambiables, permitiendo que el algoritmo varíe independientemente del cliente que haga uso de él.
* Se quiera ofrecer la posibilidad de configurar una clase con una gama de comportamientos disponibles.
* Se necesiten diferentes variantes de un algoritmo.
* Un algoritmo use datos que el cliente no tenga por qué conocer.
* Una clase defina varios comportamientos y estos aparezcan en forma condicional en sus operaciones.
En la Figura 6, se representa la relación que existe entre los estilos arquitectónicos, patrones arquitectónicos y los patrones de diseño, que propone el desarrollo de arquitecturas de software como un sistema de patrones, y distintos niveles de abstracción. Los estilos y patrones ayudan al arquitecto a definir la composición y el comportamiento del sistema de software, y una combinación adecuada de ellos permite alcanzar los requerimientos de calidad. Los patrones arquitectónicos en comparación con los patrones de diseño, los patrones arquitectónicos tienen un nivel de abstracción mayor.
Figura 6. Relación de abstracción entre estilos y patrones arquitectónicos
Fuente: (Camacho et al., 2004) Elaboración: Autor
En la Tabla 3, para tener una idea más clara se muestra las diferencias entre estilo arquitectónico y patrón arquitectónico:
Tabla 3. Diferencias entre estilos arquitectónicos y patrones arquitectónicos
ESTILOS ARQUITECTÓNICOS PATRÓN ARQUITECTÓNICO
Solo describe el esqueleto estructural y general de las aplicaciones.
Existen en varios rangos de escala, comenzando con patrones que definen la estructura básica de una aplicación.
Son independientes del contexto al que puedan ser aplicados.
27
Cada estilo es independiente de los otros. Depende de patrones más pequeños que contiene, patrones con los que interactúa, o de patrones que lo contengan.
Expresan técnicas de diseño desde una perspectiva que es independiente de la situación actual del diseño.
Expresa un problema recurrente de diseño muy específico, y presenta una solución para él, desde el punto de vista del contexto en el que se presenta.
Son una categorización de sistemas. Son soluciones generales a problemas comunes.
Fuente: (Camacho et al., 2004) Elaboración: Autor
El estilo y el patrón arquitectónico imponen una transformación en el diseño de una arquitectura, pero el alcance del patrón es menor que el del estilo, ya que el patrón se concentra en un solo aspecto en lugar de toda la aplicación. Los patrones arquitectónicos abarcan aspectos de comportamiento dentro del contexto de la arquitectura. El uso en conjunto de los estilos y los patrones sirven para determinar la forma de la estructura general de un sistema, y es muy importante evaluar si un patrón es apropiado para la aplicación y el estilo arquitectónico en general. Los servicios web proporcionan rutinas que pueden ser utilizadas por cualquier desarrollador y éstos pueden estar alojados en un servidor; además son una forma de implementar la arquitectura orientada a servicios y son independientes de la plataforma con la que SOA puede descomponer las aplicaciones. A continuación se profundizará el tema de servicios web.
1.4. Servicios web.
1.4.1. Definición
“Un servicio es un mecanismo que permite el acceso a una o más capacidades, donde se proporciona el acceso mediante un interfaz prescrito y se ejerce de conformidad con las limitaciones y las políticas como se especifica en la descripción del servicio”(N. Fernández, 2012). C. Reynoso & Kicillof (2004) menciona un concepto de servicio web que proporciona la W3C: es un software que permite la interacción entre diferentes máquinas conectadas por internet, posee una interfaz (WSDL) que se comunica con el cliente por medio de mensajes SOAP en formato XML, comúnmente transportados por medio del protocolo HTTP en conjunto con otros estándares de los servicios web.
28
Anaya Lopez (2011) menciona que los servicios web se describen así mismos como la lógica de negocio expuesto en la web como servicios por medio de interfaces y el uso de protocolos de internet, que pueden ser buscados, suscritos e invocados por otra aplicación.
Los servicios web son aplicaciones que están identificadas por un Uniform Resource Identiflier (URI) que tienen la capacidad de estar definidos, descritos, descubiertos e invocados mediante XML. Los servicios web interactúan en internet, intercambian información entre sí con el objetivo de ofrecer servicios, mediante la adopción de protocolos y estándares.
1.4.2. Estructura y características de los Servicios Web
Los servicios web proveen una funcionalidad a otros usuarios o a otros servicios, lo que determina servicios como Proveedores y servicios Consumidores, interactuando mediante mensajes. Gonzáles Quiroga (2011) menciona 3 elementos de los servicios:
• Contrato.- En el contrato se especifica la funcionalidad, propósito, restricciones y el modo de uso del mismo.
• Implementación.- La funcionalidad del servicio implementada bajo alguna tecnología • Interfaces.- Provee la forma de acceder a la funcionalidad de acuerdo al contrato. Estos componentes también forman parte de los elementos de una arquitectura orientada a servicios ya que los servicios lo son, y las características principales de los servicios web, según Aperador (2012) son las siguientes:
• Uso de estándares, para que los servicios web sean utilizados por sistemas heterogéneos existentes en la red es el empleo del protocolo de transferencia de datos HTTP utilizado por todos los navegadores web y XML.
• Basados en tecnologías de paso de mensajes, la interacción entre el cliente y el proveedor del servicio es empaquetada en unidades denominadas mensajes.
• Los servicios web presentan una funcionalidad de caja negra que puede ser reutilizada sin preocuparse de cómo es implementada y ello proporciona interfaces bien definidas. • Su contenido y funcionamientos es de fácil acceso.
• Permiten la composición de servicios más complejos mediante su combinación e integración
29
1.4.3. Especificaciones de los servicios web
Para Chase (2011) las especificaciones de los servicios web están clasificadas en dos grupos, Como se puede observar en la Figura 7:
• Especificaciones básicas:
o SOAP: Simple Object Access Protocol, detalla el formato de los mensajes y la
forma en que las aplicaciones utilizan el contenido del mensaje, como por ejemplo los elementos del header, body, lo que permite que el mensaje transite entre múltiples intermediarios hasta llegar a su destino.
o WSDL: Web Services Description Language, detalla una forma estándar de que
un servicio web basado en el protocolo SOAP pueda ser descrito, incluyendo la forma la forma de uso del mensaje, su ubicación, puertos, etc.
o UDDI: Universal Description, Discovery and Integration, permite una forma de
registrar los servicios web, es decir es como un directorio de servicios web en la cual se puede buscar los servicios que se desea utilizar.
• Especificaciones ampliadas
o WS-Security: Esta especificación provee de mecanismo de seguridad tales
como la autenticación, la autorización, el encriptado y el firmado digital, lo que permite la implementación de servicios web seguros, protegiendo la información.
o WS-Policy: Es una extensión de WS-Security, que permite detallar las
restricciones de uso del servicio web.
o WS-I: Proporciona un conjunto de estándares y prácticas para promoverla
interoperabilidad sobre cualquier plataforma basados en estándares XML.
o WS-BPEL: Es un lenguaje para la especificación de la composición de servicios
30 Figura 7. Especificaciones de los servicios web Fuente: (Arias & Fernández, 2009)
Elaboración: Autor
Los servicios web funcionan como aplicaciones independientes ya que se incluyen lógica de negocios, manejo de datos, procedimientos y políticas para la resolución de un problema específico. Los servicios web sirven de base para la implementación de SOA permitiendo la comunicación por medio de mensajes de diferentes sistemas independientemente del sistema operativo o lenguaje de programación utilizado. La comunicación entre los servicios web se basa en el estándar XML y mediante el protocolo SOAP.
Los servicios web hacen uso de una pila de estándares y especificaciones que permiten la interoperabilidad como: SOAP para el paso de mensajes, WSDL para la descripción de los servicios web, UDDI para el descubrimiento de los servicios web. Además como de otras especificaciones para la calidad y seguridad de los servicios web como: WS-Policy. WS-Security, WS-Addressing, etc.
Especificaciones Básicas Especificaciones Ampliadas
Integración
Calidad del Serv icio
Descubrimiento
Descripción
Mensaj ería
Transporte
WS-BPEL, WS-CDL, WS-Cordination, WS-Transaction
WS-Security, WS-Reliable, WS-Policy, WS-Interoperability
UDDI
WSDL
SOAP, XML
31
1.4.4. Ventajas y desventajas de los Servicios Web
En la Tabla 4, se listan las ventajas y desventajas que ofrecen los servicios web tomado de Ordóñez León (2010):
Tabla 4. Ventajas y desventajas de los servicios web
VENTAJAS DESVENTAJAS
Estandarización, los servicios web se basan en especificaciones, protocolos y estándares para el intercambio de datos, mensajes, búsqueda y descripción.
Problemas en el desempeño, los cuellos de botella son típicamente código que podría perfeccionarse, una necesidad para más servidores, o una necesidad para una conexión a Internet más rápida.
Fácil implementación, se apoya en HTTP que es un protocolo universal para el acceso en la web. Además para el desarrollo de servicios web existen herramientas que permiten su fácil implementación.
Inseguridad, al apoyarse en HTTP, se saltan la seguridad basada en firewall que auditan la comunicación entre programas a ambos lados de la barrera.
Integración, los servicios web que se encuentren en diferentes lugares geográficos pueden ser integrados y combinados para crear nuevos servicios web.
Rendimiento, en comparación con otros modelos de computación distribuida su rendimiento es bajo.
Interoperabilidad, los servicios web permiten la interoperabilidad de distintos sistemas por medio de la comunicación de estándares abiertos como XML y HTTP. Además permiten la interoperabilidad de diversos servicios web implementados en diferentes plataformas o lenguajes de programación.
Interdependencia, el servicio web agregado depende de para su funcionamiento apropiado de los servicios de web más pequeños.
Accesibilidad, los servicios web son completamente accesibles a través de la red por cualquier tipo de dispositivo con internet.
Software como servicio, los servicios web pueden ser publicados y accedidos desde cualquier plataforma web sin importar el lugar donde se encuentre o en que lenguaje esté desarrollado, ya que es accedido por protocolos y estándares abiertos.
Fuente: (Ordóñez León, 2010) Elaboración: Autor
32
reusabilidad y la independencia de plataformas. A continuación se procede a profundizar en la arquitectura orientada a servicios.
1.5. Arquitectura Orientada a Servicios.
1.5.1. Definición
SOA (Service Oriented Architecture, en sus siglas en inglés), tiene varios enfoques: de negocio, de tecnología y de organización. Desde el punto de vista de negocio, SOA permite a las organizaciones satisfacer los cambios en las necesidades de la empresa, mediante la implementación de servicios web. Desde el punto de vista tecnológico aumenta la flexibilidad simplificando a adaptación de los sistemas existentes, mejora la productividad de procesos y la usabilidad de las aplicaciones. Desde el punto de vista organizacional permite la consistencia en los procesos, ofrece rapidez de adaptación al cambio y mejora la cultura de servicio.
Lewis (2008) del SEI, menciona que arquitectura orientada a servicios es una forma de diseño, desarrollo, implementación y gestión de sistemas, en el cual:
• Los servicios proporcionan funcionalidad de negocio reutilizables.
• Los consumidores de servicios se construyen utilizando la funcionalidad de los servicios disponibles.
• Las definiciones de interfaz de servicio son artefactos de primera clase.
• Una infraestructura SOA permite el descubrimiento, la composición y la invocación de servicios.
• El intercambio de documentos basados en mensajes.
Serrano (2007) conceptualiza la arquitectura orientada a servicios en términos de servicios programables que ofrecen una funcionalidad encapsulada débilmente acoplados, proporcionados por aplicaciones nuevas o existentes, con la finalidad de poder ser reutilizados por aplicaciones finales u otros servicios.
33
[image:47.595.106.520.146.551.2]En la Figura 8 se observa la integración de SOA en una sola aplicación final de usuario, donde la aplicación final orquesta la ejecución de un conjunto de servicios, añade la lógica y la presenta a mediante un interfaz al usuario. La orquestación es un tema que se abordará más adelante.
Figura 8. Integración SOA
Fuente: (Enriquez Huaca & Caraguay, 2011) Elaboración: Autor
1.5.2. Principios de la Orientación a Servicios.
Para desarrollar aplicaciones orientadas a servicios, es conveniente tener en cuenta ciertos principios que nos ayudan a tener un buen diseño. Existen principios que permiten verificar si una aplicación sea realmente una aplicación SOA. Los principios que propone Thomas Erl en sus publicaciones sobre la orientación a servicios son:
• Ser reutilizables.- Los servicios deben ser diseñados para ser reutilizados dentro de la
misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio público.
Serv idor de Base de Datos
Mainframes y Microcomputadores
Serv idor de Correo Electrónico Sistema de
Mensaj ería Jav a, IBM
Serv idor de
Aplicaciones Cliente Mov ilServ idor ComercialServ idor Cliente 1
Bus de Serv icios Empresariales
Cliente 2 Cliente 3 Cliente 4
Node1
Servicio
Web ServicioWeb Servicio
Web ServicioWeb
Servicio Web
Servicio
Web Servicio
34
• Contrato formal.- Los servicios deben poseer un contrato formal en el cual debe
constar: nombre del servicio, forma de acceso, funcionalidades que ofrece, datos de entrada y salida de las funcionalidades. Mediante el contrato el consumidor accederá a éste, en los servicios se lo logra mediante WSDL.
• Bajo acoplamiento.- Los servicios deben ser independiente unos de otros, es decir
debe existir bajo acoplamiento entre el servicio que se va a ejecutar y el servicio que lo llama, logrando así su total reutilización.
• Permitir la composición.- Los servicios deben permitir construir servicios genéricos de
más alto nivel, el cual está constituido de servicios de más bajo nivel. Esto se logra mediante protocolos para orquestación (WS-BPEL) y coreografía (WS-CDL).
• Autonomía.-Todo servicio debe poseer su propio entorno de ejecución, de tal manera
que el servicio es independiente y reutilizable.
• Sin estado.- Un servicio no debe guardar ningún tipo de información, para poder ser
secuenciados (orquestados) para realizar la lógica del negocio y evitar problemas de inconsistencia; y que toda la información esté almacenada en algún tipo de sistema de información.
• Ser descubiertos.- Todo servicio debe ser descubierto de alguna forma para que
pueda ser utilizado, el descubrimiento de servicios web se lo realiza mediante interfaces de registros UDDI.
35 Figura 9. Interrelación entre los Principios SOA
Fuente: (Arsanjani, 2004) Elaboración: Autor
1.5.3. Características de un servicio web SOA
Un servicio es un elemento que encapsula una funcionalidad atómica, usado para soportar los servicios de negocio que la organización proporciona. En un ambiente SOA, los servicios son estructuras pequeñas utilizadas para la construcción de estructuras más complejas, para satisfacer una necesidad especifica.
Para ello, Gomez (2013) enumera algunas características que un servicio web SOA debe cumplir:
• Definido: El servicio debe definir lo que hace, sus procesos de negocio, su interfaz de
comunicación, su forma de invocación, los datos de entrada y salida y la forma en que debe ser manejado el servicio.
• Implementado: El servicio debe estar desarrollado, construido o implementado de
alguna forma con alguna herramienta.
• Desplegado: Debe estar disponible para su respectivo uso por otras aplicaciones
clientes. Reusabilidad Contrato Formal Descubrimiento Sin Estado Autonomía Composición Bajo Acoplamiento Evita duplicidades y se obtiene la
Ofrece mas oportunidades de
Independencia del entorno de ejecución consiguiendo la Proporciona la independencia de servicios por
ende la Minimiza las
dependencias consiguiendo la
