TenezacaLimaMiguelAlejandro

Vista previa del material en texto

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA 
La Universidad Católica de Loja 
 
Á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 
2016 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
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 
Septiembre, 2016 
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). ............................ 
Mgs. Daniel Alejandro Guamán Coronel 
CI: 1103777403 
 
 
 
 
 
 
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). ............................ 
Autor: Miguel Alejandro Tenezaca Lima 
Cédula: 0705705721 
 
 
 
 
 
 
 
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. 
A mis hermanos, que han sido una de mis motivaciones para mi superación personal y profesional. 
A mis familiares, amigos y compañeros, que siempre han estado pendientes de bienestar. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
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. 
A mi comité del tribunal por sus correcciones y aportaciones en el presente 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 
1.4. Servicios web. .................................................................................................................27 
 
 
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 
DISEÑO DE LA SOLUCIÓN ..........................................................................................................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 
RECOMENDACIONES ............................................................................................................... 105 
 
 
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 – Servicioweb. ........................................................... 115 
E. Configuración SAML con WSIT – Cliente del Servicio web. ............................................ 119 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
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 
Figura 21. Flujo de mensajes mediante WS-Security ................................................................... 59 
 
 
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 
Figura 44. Captura del tráfico con HTTP - Wireshark ................................................................... 96 
 
 
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 
Figura 66. Configuración SamlCallbackHandler – 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 
Tabla 13. Procedimientos almacenados utilizados ...................................................................... 112 
 
 
 
 
 
 
 
 
 
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, WS-
Security, XSS. 
 
 
 
 
 
 
 
 
 
 
 
 
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. 
Key words: Exposure of sensitive data, OWASP, SOA, SOAP, SQL Injection, WS-Security, XSS. 
 
 
 
 
 
 
 
 
 
 
 
 
 
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 
La finalidad del presente proyecto es utilizar la guía de OWASP para elaborar un prototipo bajo el 
estilo arquitectónico SOA, en el cual se expongan las consideraciones de código y diseño que 
permitan minimizar vulnerabilidades en aplicaciones web. 
 
 
 
 
 
 
 
 
 
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 
vulnerabilidadesexpuestos 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. 
Finalmente para la parte práctica se ha considerado desarrollar un prototipo base acorde al estilo 
arquitectónico SOA, en donde se muestre: el diseño arquitectónico, el patrón arquitectónico, los 
patrones de diseño seleccionados y consideraciones a nivel de escritura de código, que luego 
serán validados con herramientas y de forma manual. 
 
 
 
 
 
 
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 
a nivel de diseño arquitectónico y codificación recomendados por la guía de OWASP para 
minimizar aspectos de seguridad cuando se trabaja con SOA. 
 
 
 
 
 
 
 
 
 
 
 
 
 
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). 
SQL.- Estrutured Query Languaje (Lenguaje de Consulta Estructurado). 
 
 
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). 
XSS.- Cross Site Scripting (Secuencias de comandos en Sitios Cruzados). 
 
 
 
 
 
 
 
 
 
 
 
8 
 
 
 
 
 
 
 
 
 
 
CAPÍTULO I 
ESTADO DEL ARTE 
 
 
 
 
 
 
 
 
 
 
 
 
 
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 
responder a eventos específicos o a la cantidad de eventos procesados en un intervalo 
de tiempo dado. La arquitectura debe diseñarse para localizar operaciones críticas de 
un pequeño número de componentes desplegados en la misma computadora. 
 
 
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 sindetener 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 sof tware. 
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 Arquite cturas de software 
La arquitectura de software es un elemento base e importante para el desarrollo; y ha surgido como 
una disciplina de gran importancia dentro de la ingeniería de software. Una arquitectura adecuada 
es pieza clave para lograr tanto los requerimientos funcionales como no funcionales de un sistema. 
Como principales ventajas de la arquitectura de software se puede mencionar: permite la toma de 
decisiones tempranas antes de elaborar el diseño, permite la comunicación entre los integrantes 
 
 
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í 
mismo Barraza ( 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 
actuales y posibles nuevos requerimientos. Se lo puede hacer de forma manual o 
mediante prototipo. El diseño arquitectónico es la base para la codificación, por ende 
ésta se debe evaluar para identificar, corregir posibles errores y riesgos, y permitir que 
 
 
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 
datos que puede ser un documento o una base de datos, al que otros componentes pueden 
acceder para actualizar, agregar o eliminar datos a dicho almacén. Existen dos tipos de 
repositorios: Pasivo y Activo (pizarra). Como ventajas de este estilo arquitectónico brinda 
integridad, es decir si existen cambios en los componentes, estos no afectan a los otros 
componentes. Como se muestra en la Figura 1: 
 
 
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 
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
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óny 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
Objeto
Objeto
Objeto
Objeto
Gestores
 
 
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)
Transmitir
 
 
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. 
Los patrones arquitectónicos son plantillas que sirven para representar una arquitectura específica, 
y de acuerdo a las necesidades del sistema se elige la adopción de una en particular, algunos 
ejemplos de patrones arquitectónicos son: 
 
 
17 
 
• Modelo-Vista-Controlador. 
• Capas. 
• Repositorio. 
• Cliente-Servidor. 
• Arquitectura Tubería y Filtro. 
En la Tabla 1, se describen algunos de los patrones arquitectónicos más conocidos tomados de 
Sommerville (2011) y Almeida & Perez (2011): 
 
 
 
 
 
 
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. 
Cada servicio es un punto de falla, de modo 
que es susceptible a ataques de rechazo de 
servicio o a fallas del servidor. 
 
 
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 sehan 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. 
Fuente: (Almeida & Perez, 2011; Sommerville, 2011) 
Elaboración: Autor 
 
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. 
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando 
conocimiento ya existente. 
 
 
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. 
En la Tabla 2, se resumen los diferentes patrones de diseño de acuerdo a su clasificación de 
Almeida & Perez (2011): 
 
 
 
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. 
* Se requiere crear una clase reusable que coopere con clases no relacionadas, es decir, con clases que 
no necesariamente tienen interfaces compatibles. 
 
 
 
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 
similaresu 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. 
* Usted quiere dividir en capas su subsistema. 
 
 
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. . 
* Dar soporte para deshacer comandos, procesos de identificación y/o transacciones 
 
 
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. 
Fuente: (Almeida & Perez, 2011) 
Elaboración: Autor 
 
 
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. 
Partiendo de la definición de patrón, requieren de la 
especificación de un contexto del problema. 
 
 
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. 
Según Sommerville (2011), un servicio web es “una función ofrecida por una parte a otra. Aunque 
el proceso puede asociarse a un proceso físico, la función es esencialmente intangible y, por lo 
general, no da por resultado la propiedad de alguno de los factores de producción”. 
 
 
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 Servi cios 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 
• Pueden ser consumidas por cualquier tipo de aplicació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 
web. 
 
 
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
Mensajería
Transporte
WS-BPEL, WS-CDL, WS-Cordination, WS-Transaction
WS-Security, WS-Reliable, WS-Policy, WS-Interoperab ility
UDDI
WSDL
SOAP, XML
HTTP, SMTP
 
 
31 
 
1.4.4. Ventajas y desventajas de los Servicios W eb 
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,