C

INSTITUTO TECNOLGICO DE VERACRUZ

TECNOLGICO NACIONAL DE MXICO

INGENIERA EN SISTEMAS COMPUTACIONALES

UNIDAD 3

ARQUITECTURA DE SOFTWARE

Investigacin

PARA LA MATERIA

INGENIERA DE SOFTWARE

GRUPO: 6J5
HORARIO: 17:00-18:00 HRS.

PRESENTAN ALUMNOS:
CASTILLO HUERTA BRENDA KAREN
FLORES VARGAS JOS FRANCISCO
JIMNEZ CORTS AARON
PREZ JORGE ALDO

PROFESOR DE LA MATERIA:

ING. VERDALET GUZMN FELIPE

VERACRUZ, VER. ABRIL, 2017

 NDICE
PG.
Introduccin 2

Evolucin de las arquitecturas. 3

Funciones de un arquitecto de Software. 6

Gestin de los requisitos no funcionales y definicin de

la Arquitectura de Software 6
Seleccin de la Tecnologa 7
Facilitador 7
Lder y Formador 8
Aseguramiento de la Calidad 8

Caractersticas de las diferentes arquitecturas de software, as

como todos los elementos que requieren unir para
desarrollarlo. 9

Descomposicin modular 9
Arquitectura Cliente-Servidor 12
Arquitectura de tres Niveles 18
Arquitectura Orientada a Servicios 20
Arquitectura en Pizarra 23
Modelo Vista-Controlador 24
Arquitectura de Microservicios 27

Conclusin 30

Bibliografa 31

1
 INTRODUCCIN
Desde el surgimiento de la informtica, la programacin se consideraba un arte
por lo compleja y complicada que era para la mayora de las personas. Pero poco
a poco se comenzaron a desarrollar metodologas para conseguir propsitos y
metas. Y a todas estas tcnicas se le llam Arquitectura de Software.
La Arquitectura de Software es tambin conocida como Arquitectura Lgica,
consiste en un conjunto de patrones y abstracciones relacionados entre s que
brindan el marco de referencia necesario para orientar y dirigir la lnea de
construccin del software para un sistema de informacin.
sta a la vez plantea los fundamentos para que analistas, diseadores y otros
roles trabajen conjuntamente en una misma lnea permitiendo alcanzar los
objetivos del sistema, garantizando todas las necesidades.

2
 EVOLUCIN DE LAS ARQUITECTURAS

Aunque el trmino arquitectura de software, tal y como lo concebimos ahora,

aparece en 1992 con el trabajo de Perry y Wolf1, sus antecedentes se remontan
al menos hasta finales de la dcada de los sesenta.
En 1968, Dijkstra habla de una estructuracin correcta de los sistemas de
software, aunque no la llama arquitectura como tal2.
Posteriormente, en 1969, P. I. Sharp, comentando las ideas de Dijkstra, ya usa
el trmino arquitectura de software al mencionar que quiz luego se hable de la
escuela de arquitectura de software de Dijkstra, y al mismo tiempo lamentar que
la industria de ese tiempo preste muy poca atencin a sta.
Durante la dcada de los setentas el concepto de arquitectura deambul por el
aire sin una semntica clara y carente de una expresin pragmtica. En esta
misma dcada, el diseo estructurado dio pie a la independencia entre el diseo
y la implementacin. Los trabajos de Parnas sobre tcnicas de modularizacin
en decisiones de diseo y familias de programas3, fueron, sin duda, aportaciones
esenciales y permanentes.
Las decisiones tempranas de diseo, arga Parnas, probablemente
permaneceran invariantes en el desarrollo de la solucin; estas ideas se
convierten luego en lo que hoy se conocen como decisiones arquitectnicas.
Rompiendo esquemas y acaparando la atencin en la dcada de los ochentas,
aparece el paradigma de la orientacin a objetos.

1
Dewayne E. Perry y Alexander Wolf. Foundations for the study of software architecture, ACM
SIGSOFT Software Engineering Notes, 17(4), pp. 40-52, octubre de 1992.
2
Edsger Dijkstra. Go-To statement considered harmful. ACM Communications of the ACM, 11(3), pp.
147-148, Marzo de 1968.
3
David Parnas, On the criteria for decomposing systems into modules Communications of the ACM
15(12), pp. 1053-1058, December 1972

3
En esta dcada aparecen dos trabajos importantes de Mary Shaw, que retoman
las abstracciones de alto nivel: Tcnicas de abstraccin en lenguajes modernos
de programacin4 y Los sistemas de gran escala requieren de abstracciones
de alto nivel5.
Hacia finales de los ochenta y principios de los noventa, comienza a gestarse de
manera ms clara la idea de que las aplicaciones tienen una morfologa, una
estructura.
El trabajo de Perry y Wolf de 1992 es el punto de partida para lo que hoy
conocemos como arquitectura de software. Por un lado, son los primeros que
proponen un modelo para la arquitectura de software; este modelo contempla a
la arquitectura formada por tres componentes: elementos, forma y razn.
Los elementos pueden ser de procesamiento, datos o conexin; la forma se
define de acuerdo a las propiedades de, y a las relaciones entre los elementos;
la razn se contempla en trminos de restricciones del sistema, que se derivan
de los requerimientos del sistema.
Perry y Wolf profetizaron que: la dcada de los noventas, creemos, ser la
dcada de la arquitectura de software, lo cual se convirti en realidad. A lo largo
de esa dcada, salieron a la luz varios trabajos con propuestas relevantes, entre
ellas, la programacin basada en componentes6, el surgimiento de los patrones
y estilos7, el modelo de 4+1 vistas8, y lenguajes de descripcin de arquitecturas
(ADLs)9 entre otras.
En la segunda mitad de los noventa aparecen los primeros libros de texto
dedicados a la arquitectura de software.
El ao 2000 cierra esta dcada con dos trabajos clave: el modelo REST
propuesto en la tesis de Roy Fielding que pone la atencin en Internet y los
modelos orientados a servicios10; y el trabajo de la IEEE, que genera una versin
definitiva de la recomendacin IEEE std 1471-200011.

4
Mary Shaw, Abstraction techniques in modern programming languages IEEE Software, pp. 10-26,
October 1984.
5
Mary Shaw, Large scale systems require higher level abstraction, Proceedings of fifth international
workshop on software specification and design. IEEE Computer Society, pp. 143-146, 1989.
6
Paul Clements, Coming attractions in software architecture, Technical report, CMU/SEI-96-TR-008,
ESC-TR-96-008, jan. 1996.
7
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of reusable
object-oriented software. Reading, Addison-Wesley, 1995.
8
Philippe Krutchen, The 4+1 view model architecture, IEEE Software 12(6), pp. 42-50, nov. 1995.
9
Paul Clements, A survey of architecture descriptions languages Proceedings of the International
Workshop on Software Specification and Design, Germany, 1996.
10
Roy Thomas Fielding, Architecture styles and design of network-based software architectures PhD
Thesis, California University, Irvine 2000.
11
Software Engineering Standards Committee of the IEEE Computer Society, IEEE Recommended
practice for architecture description of software-intensive systems, IEEE Std 1471-2000, Approved 21
September 2000, IEEE-SA Standards Board, Print: ISBN 0-7381-2518-0 SH94869, PDF: ISBN 0-7381-2519-
9 SS94869, available at (http://standards.ieee.org/).

4
Tambin en este ao se abren nuevas perspectivas para la arquitectura de
software, aparecen las estrategias orientadas a lneas de productos y se procura
insertar la arquitectura de software dentro del ciclo de vida, obligando a redefinir
las metodologas referentes a l en trminos de arquitectura12.
Actualmente hay una cierta efervescencia alrededor de desarrollos centrados en
arquitectura, mtodos de anlisis y diseo de arquitecturas (dentro del ciclo de
vida), anlisis de arquitecturas de software basados en escenarios, modelos de
evaluacin de arquitecturas de software y modelos orientados por la arquitectura
entre algunos otros tpicos.

12
The open group architectural framework Versin 8, document number I911, dec. 2002.

5
 FUNCIONES DE UN ARQUITECTO DE SOFTWARE

Mientras en la industria el trmino Desarrollador de Software est bastante claro,

el trmino Arquitecto de Software sigue bastante difuso y muchas empresas se
preguntan si necesitan o no a alguien que desempee dicho rol.
El Arquitecto de Software debe ser una persona con amplios conocimientos
tcnicos, gran experiencia en programacin, liderazgo y que ejerza las siguientes
funciones:
Gestin de los requisitos no funcionales y definicin de la Arquitectura de
Software
Seleccin de la Tecnologa
Mejora continua de la Arquitectura
Facilitador
Lder y Formador
Aseguramiento de la Calidad

Gestin de los requisitos no funcionales y definicin de la Arquitectura de

Software
En muchos proyectos de software se suele preguntar a los usuarios qu
caractersticas desean en el producto a desarrollar, pero muchas veces se pasan
por alto los requisitos no funcionales, o cualidades del sistema, que se necesitan.
Los requerimientos no funcionales tienen que ser especficos, medibles,
alcanzables y comprobables, para poder satisfacerlos (no basta con algo
subjetivo como: el sistema debe ser rpido), y adems hay que saber
priorizarlos de manera que todos sean tomados en cuenta.
Caractersticas como el rendimiento, la escalabilidad, la disponibilidad, auditora,
etc., son requisitos no funcionales que deben ser definidos e incluso
cuestionados cuando se considere oportuno y es el Arquitecto de Software quien
debe asumir estas funciones.

6
Una vez obtenido el conjunto completo de requisitos no funcionales, el siguiente
paso es pensar en cmo se resolvern los problemas expuestos y definir la
arquitectura.
La definicin de la arquitectura se trata de la introduccin de la estructura,
directrices, principios y liderazgo de los aspectos tcnicos de un proyecto de
software. Por lo tanto, se requiere de una figura dedicada a pensar en estos
aspectos, es decir, alguien tiene que asumir la propiedad del proceso de
definicin de la arquitectura y esto es sin duda, parte de las competencias del
Arquitecto de Software.

Seleccin de la Tecnologa
La seleccin de la tecnologa suele ser un ejercicio con una serie de desafos
interesantes y en el cual se debe tomar en cuenta un universo de factores como
el coste, las licencias, la relacin con los proveedores, la estrategia de la
tecnologa, la compatibilidad e interoperabilidad, poltica de actualizaciones, etc.
Adicionalmente hay que conocer si las tecnologas funcionan realmente y se
adaptan o no a los requerimientos del software.
El Arquitecto de Software debe asumir la propiedad del proceso de seleccin de
la tecnologa y por tanto es responsable del riesgo tcnico.
Mejora continua de la Arquitectura
Hoy en da es imposible pensar en el desarrollo de software sin tomar en cuenta
procesos de evaluacin y feedback que permitan conocer si el software satisface
las expectativas del usuario.
De igual manera es necesario someter a la arquitectura de software a dichos
procesos, para demostrar que funciona, que efectivamente resuelve los
requisitos no funcionales y por tanto reducir el riesgo general de fracaso del
proyecto.
El Arquitecto de Software debe encargarse de la mejora continua de la
Arquitectura y a su vez estar abierto a modificarla utilizando las sugerencias o
feedback que se pueda obtener de otros miembros del equipo.

Facilitador
La arquitectura del software debe ser conocida y entendida no solo por el equipo
de desarrollo sino tambin por otras reas como seguridad informtica, base de
datos, operaciones, el equipo de mantenimiento, etc.
Es funcin del Arquitecto de Software servir de facilitador para la colaboracin
entre estos grupos de inters de manera de garantizar que la arquitectura se
integrar con xito en el entorno empresarial.

7
 Lder y Formador
El Arquitecto de Software debe asumir la direccin tcnica, para asegurar que
todos los aspectos de la arquitectura se estn implementando de manera
correcta.
De igual manera el Arquitecto de Software debe proporcionar orientacin tcnica
y dar apoyo al equipo de desarrollo; debe estar preparado para entrenar al
equipo en las tecnologas seleccionadas (Formador) y tambin debe estar
abierto a sugerencias.

Aseguramiento de la Calidad
Garantizar la calidad es parte fundamental del rol de un Arquitecto de Software,
el cual debe apoyarse en procesos de integracin continua que utilicen
herramientas automatizadas de anlisis de cdigo fuente, pruebas unitarias y
cobertura de cdigo, para asegurar el cumplimiento de las normas, polticas y
mejores prcticas establecidas.

8
 CARACTERSTICAS DE LAS DIFERENTES ARQUITECTURAS
DE SOFTWARE

DESCOMPOSICIN MODULAR
El modularidad es la capacidad que tiene un sistema de ser estudiado, visto o
entendido como la unin de varias partes que interactan entre s y que trabajan
para alcanzar un objetivo comn, realizando cada una de ellas una tarea
necesaria para la consecucin de dicho objetivo.
Cada una de esas partes en que se encuentre dividido el sistema recibe el
nombre de mdulo. Idealmente un mdulo debe poder cumplir las condiciones
de caja negra, es decir, ser independiente del resto de los mdulos y
comunicarse con ellos (con todos o slo con una parte) a travs de unas entradas
y salidas bien definidas.
La Descomposicin Modular o Modularizacin es el proceso de descomposicin
de un sistema en un conjunto de elementos con un ndice bajo acoplamiento
(independientes) y alto ndice de cohesin (con significado propio).

Ventajas:
o claridad,
o reduccin de costos y
o reutilizacin.
El diseo modular propone dividir el sistema en partes diferenciadas y definir sus
interfaces. Los pasos a seguir son:
Identificar los mdulos
Describir cada mdulo
Describir las relaciones entre mdulos

Caractersticas
Una descomposicin modular debe poseer ciertas cualidades mnimas para que
se pueda considerar suficiente validad.
Independencia funcional
Acoplamiento
Cohesin
Comprensibilidad
Adaptabilidad
Independencia funcional

Cada mdulo debe realizar una funcin concreta o un conjunto de funciones

afines. Es recomendable reducir las relaciones entre mdulos al mnimo.

9
Para medir la independencia funcional hay dos criterios: acoplamiento y
cohesin.
ACOPLAMIENTO
Es una medida de la interconexin entre mdulos en la estructura del programa.
Se puede graduara en un amplio espectro, pero por lo general se tiende a que
el acoplamiento sea lo menor posible, esto es a reducir las interconexiones entre
los distintos mdulos en que se estructure nuestra aplicacin. El grado de
acoplamiento mide la interrelacin entre dos mdulos, segn el tipo de conexin
y la complejidad de la interface:
Fuerte
Por contenido, cuando desde un mdulo se puede cambiar datos locales
de otro.
Comn, se emplea una zona comn de datos a la que tienen acceso
varios mdulos.
Moderado
De control, la zona comn es un dispositivo externo al que estn ligados
los mdulos, esto implica que un cambio en el formato de datos los afecta
a todos.
Por etiqueta, en intercambio de datos se realiza mediante una referencia
a la estructura completa de datos (vector, pila, rbol, grafo,)
Dbil
De datos, viene dado por los datos que intercambian los mdulos.
Es el mejor sin acoplamiento directo, es el acoplamiento que no existe.

COHESIN
Un mdulo coherente ejecuta una tarea sencilla en un procedimiento de sw y
requiere poca interaccin con procedimientos que se ejecutan en otras partes de
un programa. Podemos decir que un mdulo coherente es aquel que intenta
realizar solamente una cosa.
Para que n de mdulos no sea demasiado elevado y complique el diseo se
tratan de agrupar elementos afines y relacionados en un mismo mdulo.
ALTA
Cohesin abstraccional, se logra cuando se disea el mdulo como tipo
abstracto de datos o como una clase de objetos
Cohesin funcional, el mdulo realiza una funcin concreta y especfica
MEDIA
Cohesin secuencial, los elementos del mdulo trabajan de forma
secuencial
Cohesin de comunicacin, elementos que operan con el mismo conjunto
de datos de entrada o de salida

10
 Cohesin temporal, se agrupan elementos que se ejecutan en el mismo
momento. Ej. Arrancar o parar dispositivos
BAJA
Cohesin lgica, se agrupan elementos que realizan funciones similares.
Cohesin coincidental, es la peor y se produce cuando los elementos de
un mdulo no guardan relacin alguna
La descripcin del comportamiento de un mdulo permite establecer el grado de
cohesin:
Si es una frase compuesta y contiene ms de un verbo la cohesin ser MEDIA
Si contiene expresiones secuenciales (primero, entonces, cuando), ser
temporal o secuencial
Si la descripcin no se refiere a algo especfico (Ej. Todos los errores), cohesin
lgica
Si aparece inicializar, preparar, configurar, probablemente sea temporal.

COMPRENSIBILIDAD
Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es
necesario que cada uno sea comprensible de forma aislada. Para ello es bueno
que posea independencia funcional, pero adems es deseable:
1. Identificacin, el nombre debe ser adecuado y descriptivo
2. Documentacin, debe aclarar todos los detalles de diseo e
implementacin que no queden de manifiesto en el propio cdigo
3. Simplicidad, las soluciones sencillas son siempre las mejores

ADAPTABILIDAD
La adaptacin de un sistema resulta ms difcil cuando no hay independencia
funcional, es decir, con alto acoplamiento y baja cohesin, y cuando el diseo es
poco comprensible. Otros factores para facilitar la adaptabilidad:
Previsin, es necesario prever que aspectos del sistema pueden ser
susceptibles de cambios en el futuro, y poner estos elementos en mdulos
independientes, de manera que su modificacin afecte al menor nmero de
mdulos posibles.
Accesibilidad, debe resultar sencillo el acceso a los documentos de
especificacin, diseo, e implementacin para obtener un conocimiento
suficiente del sistema antes de proceder a su adaptacin.
Consistencia, despus de cualquier adaptacin se debe mantener la
consistencia del sistema, incluidos los documentos afectados.

11
ARQUITECTURA CLIENTE-SERVIDOR
Es una arquitectura que separa el procesamiento entre clientes y servidores en
una red.
Desde el punto de vista funcional, se puede definir la computacin
Cliente/Servidor como una arquitectura distribuida que permite a los usuarios
finales obtener acceso a la informacin en forma transparente an en entornos
multiplataforma.
En el modelo cliente servidor, el cliente enva un mensaje solicitando un
determinado servicio a un servidor (hace una peticin), y este enva uno o varios
mensajes con la respuesta (provee el servicio). En un sistema distribuido, cada
mquina puede cumplir el rol de servidor para algunas tareas y el rol de cliente
para otras.
La idea es tratar a una computadora como un instrumento, que por s sola pueda
realizar muchas tareas, pero con la consideracin de que realice aquellas que
son ms adecuadas a sus caractersticas. Si esto se aplica tanto a clientes como
servidores se entiende que la forma ms estndar de aplicacin y uso de
sistemas Cliente/Servidor es mediante la explotacin de las PCs a travs de
interfaces grficas de usuario; mientras que la administracin de datos y su
seguridad e integridad se deja a cargo de computadoras centrales tipo
mainframe.

Usualmente la mayora del trabajo pesado se hace en el proceso llamado

servidor y el o los procesos cliente slo se ocupan de la interaccin con el usuario
(aunque esto puede variar). En otras palabras, la arquitectura Cliente/Servidor
es una extensin de programacin modular en la que la base fundamental es
separar una gran pieza de software en mdulos con el fin de hacer ms fcil el
desarrollo y mejorar su mantenimiento.
Diversas aplicaciones se ejecutan en un entorno cliente/servidor. Esto significa
que los equipos clientes (equipos que forman parte de una red) contactan a un
servidor, un equipo generalmente muy potente en materia de capacidad de
entrada/salida, que proporciona servicios a los equipos clientes.

12
Estos servicios son programas que proporcionan datos como la hora, archivos,
una conexin, etc.
Los servicios son utilizados por programas denominados programas clientes que
se ejecutan en equipos clientes. Por eso se utiliza el trmino "cliente" (cliente
FTP, cliente de correo electrnico, etc.), cuando un programa que se ha diseado
para ejecutarse en un equipo cliente es capaz de procesar los datos recibidos de
un servidor (en el caso del cliente FTP se trata de archivos, mientras que para el
cliente de correo electrnico se trata de correo electrnico).

CLIENTE
Es el que inicia un requerimiento de servicio. El requerimiento inicial puede
convertirse en mltiples requerimientos de trabajo a travs de redes LAN o WAN.
La ubicacin de los datos o de las aplicaciones es totalmente transparente para
el cliente. En la arquitectura C/S el remitente de una solicitud es conocido como
cliente.
Caractersticas del cliente:
Es quien inicia solicitudes o
peticiones, tienen por tanto un papel
activo en la comunicacin (dispositivo
maestro o amo).
Espera y recibe las respuestas del
servidor.
Por lo general, puede conectarse a
varios servidores a la vez.
Normalmente interacta directamente con los usuarios finales mediante una
interfaz grfica de usuario.
Al contratar un servicio de redes, se tiene que tener en la velocidad de conexin
que le otorga al cliente y el tipo de cable que utiliza, por ejemplo: cable de cobre
ronda entre 1 ms y 50 ms.
Funciones:
El cliente es el proceso que permite al usuario formular los requerimientos y
pasarlos al servidor, se le conoce con el trmino front-end.
El Cliente normalmente maneja todas las funciones relacionadas con la
manipulacin y despliegue de datos, por lo que estn desarrollados sobre
plataformas que permiten construir interfaces grficas de usuario (GUI), adems
de acceder a los servicios distribuidos en cualquier parte de una red.
Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes
puntos:

13
 Administrar la interfaz de usuario.
Interactuar con el usuario.
Procesar la lgica de la aplicacin y hacer validaciones locales.
Generar requerimientos de bases de datos.
Recibir resultados del servidor.
Formatear resultados.

SERVIDOR
Es cualquier recurso de cmputo dedicado a responder a los requerimientos del
cliente. Los servidores pueden estar conectados a los clientes a travs de redes,
para proveer de mltiples servicios a los clientes y ciudadanos tales como
impresin, acceso a bases de datos, fax, procesamiento de imgenes, etc. Al
receptor de la solicitud enviada por cliente se conoce como servidor.
Caractersticas del servidor:
Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempean
entonces un papel pasivo en la comunicacin (dispositivo esclavo).
Tras la recepcin de una solicitud, la procesan y luego envan la respuesta al
cliente.
Por lo general, aceptan conexiones desde un gran nmero de clientes (en ciertos
casos el nmero mximo de peticiones puede estar limitado).
No es frecuente que interacten directamente con los usuarios finales.
Funciones:
Es el proceso encargado de atender a mltiples clientes que hacen peticiones
de algn recurso administrado por l. Al proceso servidor se le conoce con el
trmino back-end.
El servidor normalmente maneja todas las funciones relacionadas con la mayora
de las reglas del negocio y los recursos de datos.
Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes
puntos:
o Aceptar los requerimientos de bases de datos que hacen los clientes.
o Procesar requerimientos de bases de datos.
o Formatear datos para trasmitirlos a los clientes.
o Procesar la lgica de la aplicacin y realizar validaciones a nivel de bases
de datos.
Estructura
Los 3 componentes bsicos empleados que permiten articular esta arquitectura
son:
Clientes

14
 Servidores
Red: transporta requerimientos y posteriormente datos
Funcionamiento

Un sistema cliente/servidor funciona tal como se detalla en el siguiente diagrama:

El cliente enva una solicitud al servidor mediante su direccin IP y el puerto, que
est reservado para un servicio en particular que se ejecuta en el servidor.
El servidor recibe la solicitud y responde con la direccin IP del equipo cliente y
su puerto.
Este modelo es un prototipo de sistemas distribuidos que muestra como los datos
y el procesamiento se distribuye a lo largo de varios procesadores. Es una forma
de dividir las responsabilidades de un sistema de informacin separando la
interfaz del usuario de la gestin de la informacin.
Caractersticas
La capacidad de proceso est repartida entre los clientes y los servidores.
Se presenta centralizacin de la gestin de la informacin y separacin de
responsabilidades, facilitando y clarificando el diseo del sistema.
Combinacin de un cliente que interacta con el usuario, y un servidor que
interacta con los recursos compartidos. El proceso del cliente proporciona la
interfaz entre el usuario y el resto del sistema. El proceso del servidor acta como
un motor de software que maneja recursos compartidos tales como bases de
datos, impresoras, mdems, etc.
Las tareas del cliente y del servidor tienen diferentes requerimientos en cuanto
a recursos de cmputo como velocidad del procesador, memoria, velocidad,
capacidad del disco y dispositivos de entrada y salida.
Existe una clara distincin de funciones basada en el concepto de "servicio", que
se establece entre clientes y servidores.
Se establece una relacin entre procesos distintos, los cuales pueden ser
ejecutados en la misma mquina o en mquinas diferentes distribuidas a lo largo
de la red.
La relacin establecida puede ser de muchos a uno, en la que un servidor puede
dar servicio a muchos clientes, regulando su acceso a recursos compartidos.

15
Los clientes corresponden a procesos activos en cuanto a que son stos los que
hacen peticiones de servicios a los servidores. Estos ltimos tienen un carcter
pasivo ya que esperan las peticiones de los clientes.
No existe otra relacin entre clientes y servidores que no sea la que se establece
a travs del intercambio de mensajes entre ambos. El mensaje es el mecanismo
para la peticin y entrega de solicitudes de servicio.
El ambiente es heterogneo. La plataforma de hardware y el sistema operativo
del cliente y del servidor no son siempre la misma, es decir, se cuenta con la
posibilidad de conectar clientes y servidores independientemente de sus
plataformas.
El concepto de escalabilidad tanto horizontal como vertical es aplicable a
cualquier sistema Cliente/Servidor. La escalabilidad horizontal permite agregar
ms estaciones de trabajo activas sin afectar significativamente el rendimiento.
La escalabilidad vertical permite mejorar las caractersticas del servidor o
agregar mltiples servidores.
Transparencia de localizacin fsica de los servidores y clientes: el cliente no
tiene por qu saber dnde se encuentra situado el recurso que desea utilizar.
Encapsulamiento de servicios: Los detalles de la implementacin de un servicio
son transparentes al cliente.
Ventajas
La posibilidad de utilizar mquinas considerablemente ms baratas que las
requeridas por una solucin centralizada, basada en sistemas grandes.
Facilita la integracin entre sistemas diferentes y comparte informacin
permitiendo, que las mquinas ya existentes puedan ser utilizadas, pero
utilizando interfaces ms amigables al usuario.
En el uso de interfaces grficas para el usuario, el esquema Cliente/Servidor
presenta la ventaja, con respecto a uno centralizado, de que no es siempre
necesario transmitir informacin grfica por la red pues esta puede residir en el
cliente, lo cual permite aprovechar mejor el ancho de banda de la red.
Es ms rpido el mantenimiento y el desarrollo de aplicaciones, pues se pueden
emplear las herramientas existentes (por ejemplo, los servidores de SQL o las
herramientas de ms bajo nivel como los sockets o el RPC).
La estructura inherentemente modular facilita adems la integracin de nuevas
tecnologas y el crecimiento de la infraestructura computacional, favoreciendo
as la escalabilidad de las soluciones.
Desventajas
Se cuenta con muy escasas herramientas para la administracin y ajuste del
desempeo de los sistemas.

16
Es importante que los clientes y los servidores utilicen el mismo mecanismo (por
ejemplo, sockets o RPC), lo cual implica que se deben tener mecanismos
generales que existan en diferentes plataformas.
Hay que tener estrategias para el manejo de errores y para mantener la
consistencia de los datos.
La seguridad de un esquema Cliente/Servidor es otra preocupacin importante.
Por ejemplo, se deben hacer verificaciones en el cliente y en el servidor.
El desempeo es otro de los aspectos que se deben tener en cuenta en el
esquema Cliente/Servidor. Problemas de este estilo pueden presentarse por
congestin en la red, dificultad de trfico de datos, etc.

17
ARQUITECTURA DE TRES NIVELES
Especializacin de la arquitectura cliente-servidor donde la carga se divide en
tres partes (o capas) con un reparto claro de funciones: una capa para la
presentacin (interfaz de usuario), otra para el clculo (donde se encuentra
modelado el negocio) y otra para el almacenamiento (persistencia). Una capa
solamente tiene relacin con la siguiente.
Tambin conocida como arquitectura de tres capas, la arquitectura de tres capas,
define cmo organi-zar el modelo de diseo en capas, que pueden estar
fsicamente distribuidas, lo cual quiere decir que los componentes de una capa
slo pueden hacer referencia a componentes en capas inmediatamente
inferiores. Este patrn es importante porque simplifica la comprensin y la
organizacin del desarrollo de sistemas complejos, reduciendo las dependencias
de forma que las capas ms bajas no son conscientes de ningn detalle o interfaz
de las superiores. Adems, nos ayuda a identificar qu puede reutilizarse, y
proporciona una estructura que nos ayuda a tomar decisiones sobre qu partes
comprar y qu partes construir.
Para enfrentarse a estos temas, la comunidad de software desarroll la nocin
de una arquitectura de tres niveles. La aplicacin se divide en tres capas lgicas
distintas, cada una de ellas con un grupo de interfaces perfectamente definido.
La primera capa se denomina capa de presentacin y normalmente consiste en
una interfaz grfica de usuario de algn tipo.
La capa intermedia, o capa de empresa, consiste en la aplicacin o lgica de
empresa, y la tercera capa, la capa de datos, contiene los datos necesarios para
la aplicacin. La capa intermedia (lgica de aplicacin) es bsicamente el cdigo
al que recurre la capa de presentacin para recuperar los datos deseados. La
capa de presentacin recibe entonces los datos y los formatea para su
presentacin.
Esta separacin entre la lgica de aplicacin de la interfaz de usuario aade una
enorme flexibilidad al diseo de la aplicacin. Pueden construirse y desplegarse
mltiples interfaces de usuario sin cambiar en absoluto la lgica de aplicacin
siempre que est presente una interfaz claramente definida a la capa de
presentacin.
CAPAS O NIVELES
Capa de presentacin
Es la que se encarga de que el sistema interacte con el usuario y viceversa,
muestra el sistema al usuario, le presenta la informacin y obtiene la informacin
del usuario en un mnimo de proceso. En el mundo de la informtica es conocida
como interfaz grfica y debe tener la caracterstica de ser amigable, o sea,
entendible y fcil de usar para el usuario. Esta capa se comunica nicamente
con la capa intermedia o de negocio.

18
Capa de negocio
Es donde residen las funciones que se ejecutan, se reciben las peticiones del
usuario, se procesa la informacin y se envan las respuestas tras el proceso.
Se denomina capa de negocio o capa de lgica del negocio, porque es aqu
donde se establecen todas las reglas que deben cumplirse. Esta capa se
comunica con la de presentacin, para recibir las solicitudes y presentar los
resultados, y con la capa de acceso a datos, para solicitar al gestor de base de
datos almacenar o recuperar datos de l.

Capa de acceso a datos

Esta capa es la encargada de almacenar los datos del sistema y de los usuarios.
Su funcin es almacenar y devolver datos a la capa de negocio, aunque para
esto tambin es necesario en algunos casos, que tengan procedimientos
almacenados y funciones dentro de la capa. En una arquitectura de tres capas,
esta capa es la nica que puede acceder a los mismos. Est formada por uno o
varios sistemas gestores de bases de datos, localizados en un mismo servidor o
en varios.
Estas capas, pueden estar localizadas todas en un mismo ordenador, si el
programa o software informtico que se desarrolla es de baja complejidad,
porque si, por el contrario, fuera de gran complejidad tanto los datos como la
lgica de negocio, entonces cada una de las capas pudiera estar situada en
diferentes ordenadores, para mejorar la funcionalidad de las mismas, incluso, en
productos de gran complejidad, existen varios ordenadores para la capa de
acceso a datos, y varios ordenadores para la capa de negocio.

19
ARQUITECTURA ORIENTADA A SERVICIOS
La arquitectura orientada a servicios (SOA) es el nexo que une las metas de
negocio con el sistema de software. Su papel es el de aportar flexibilidad, desde
la automatizacin de las infraestructura y herramientas necesarias consiguiendo,
al mismo tiempo, reducir los costes de integracin. SOA se ocupa del diseo y
desarrollo de sistemas distribuidos y es un potente aliado a la hora de llevar a
cabo la gestin de grandes volmenes de datos, datos en la nube y jerarquas
de datos.
Sin embargo, pese a estar de actualidad, la arquitectura orientada a servicios no
es un concepto nuevo, ya que proviene de la dcada de los 90. Hoy presenta su
mejor cara, altamente eficiente, ms abierta e interoperable. SOA sirve de apoyo
a las organizaciones:
Ayudndolas a agilizar los procesos para que puedan hacer negocios de
manera ms eficiente.
Facilitando su adaptacin al cambio.
Habilitando la posibilidad de implementar nuevas estrategias, acordes con
el dinamismo de mercado.
La arquitectura orientada a servicios y sus ventajas para el negocio
SOA es un estilo arquitectnico para la construccin de aplicaciones de software
en base a servicios disponibles. Entre sus principales caractersticas destacan:
Su flexibilidad, que permite la reutilizacin.
Su versatilidad, que hace posible que los servicios puedan ser
consumidos por los clientes en aplicaciones o procesos de negocio
distintos.
Sus posibilidades, que optimizan el trabajo con datos y su coordinacin.
SOA permite la reutilizacin de activos existentes para nuevos servicios que se
pueden crear a partir de una infraestructura de TI que ya se haba diseado. De
esta forma, permite a las empresas optimizar la inversin por medio de la
reutilizacin que, adems, conlleva otra ventaja: la interoperabilidad entre las
aplicaciones y tecnologas heterogneas.
La arquitectura orientada a servicios es fuente de ventaja competitiva ya que, por
su configuracin:
Aumenta la eficiencia en los procesos.
Amortiza la inversin realizada en sistemas.
Reduce costes de mantenimiento.
Fomenta la innovacin orientada al desarrollo de servicios.
Simplifica el diseo, optimizando la capacidad de organizacin.

20
Los drivers de SOA
La arquitectura orientada a servicios es cambio en s misma y precisamente ste
es el motor que impulsa a las empresas a buscar beneficiarse de sus atributos
persiguiendo:
Integracin con los sistemas heredados.
Reordenamiento de responsabilidades a travs de reorganizaciones
empresariales.
Modernizacin de los sistemas obsoletos por razones econmicas,
funcionales o tcnicas.
Adquisicin o decomiso de productos de software.
Aunque tambin sucede, en muchos de los casos, que lo que se busca es la
adaptacin a los cambios del entorno de mercado, o se decide implementar SOA
como reaccin ante las acciones de la competencia, o como medida para
optimizar la inversin en IT y minimizar costes asociados.
La transicin a la arquitectura orientada a servicios
Para llevar a cabo el proceso de transicin a SOA sin problemas,
administradores y desarrolladores han de tener en cuenta que:
SOA no es algo nuevo, por lo que es necesario y posible adquirir el conocimiento
suficiente acerca de la arquitectura orientada a servicios y los Web Services
antes de poner el plan en marcha.
La arquitectura orientada a servicios es mucho ms que un software de
despliegue. Se requiere un anlisis de las tcnicas de diseo y desarrollo para
avanzar con garantas de xito desechando ineficiencias.
Este proceso de transicin hacia SOA ha de abordarse de forma gradual y
teniendo una cuenta que implica un cambio en la forma de trabajar.
Las organizaciones que ya trabajen con SOA pero busquen optimizar sus
resultados con Data Services, tendrn que observar las siguientes reglas:
Ser exigentes con la granularidad del servicio escogido, evitando extremos y
persiguiendo la coherencia.
Entender los servicios como algo limitado y no como una aplicacin completa.
Aplicar la mxima simplicidad a la hora de disear, al fin y al cabo, se trata de
representar acciones de negocio.
Garantizar la alta disponibilidad y escalabilidad de los servicios.
Esta optimizacin es la va ms indicada para superar las limitaciones que
adolecen a un proyecto SOA, a travs de la visualizacin de datos que ayuda a
evitar:
Falta de disponibilidad del servicio dependiente: que se da cuando este servicios
an no est implementado y resulta en tiempos de inactividad o en la
construccin de componentes redundantes.
21
 Falta de disponibilidad de recursos: puede suceder cuando los recursos se tiene
que compartir entre distintos equipos de desarrollo.
Restricciones de tiempo: la variable indefectiblemente asociada a todo proyecto
y que marca una de las limitaciones ms importantes.
Cambio de comportamiento del servicio dependiente: que, no slo invalida los
flujos de trabajo presentes, sino que tambin incide en la consistencia de los
datos.
Enfoques arquitectnicos de SOA
A pesar de que el enfoque tradicional a la hora de abordar el diseo de los
sistemas distribuidos se basaba en comunicaciones de red, seguridad, gestin
transaccional, glosario y ubicacin, con la arquitectura orientada a servicios es
distintos, las preocupaciones se centran en dos aspectos:
Comunicacin.
Integracin de servicios.
A la hora de evaluar la arquitectura construida hay que fijarse en:
Capacidad de modificacin.
Rendimiento.
Fiabilidad.
Disponibilidad.
Seguridad.
Sin embargo, ninguna de estas cuestiones resulta tan crtica como la
gobernabilidad, un aspecto que debe tomarse en consideracin mucho antes
que el propio diseo, de forma previa a la implementacin. Al tratarse de una
estrategia de arquitectura, SOA implica mucho ms que la simple construccin
de software.
La creacin de una arquitectura basada en una cartera de servicios requiere de
una metodologa de desarrollo centralizado y nica, de una buena
documentacin de servicios y de personal cualificado. Tambin hace falta la
motivacin suficiente por parte de la organizacin y quienes se encargan de la
toma de decisiones para que den va libre a la interaccin con los principales
procesos de negocio de la compaa. La comprensin de los procesos y la
disposicin son las claves de la transformacin de un negocio en base a SOA y
derivan de atributos de su gobernabilidad de los que no se puede prescindir para
tener xito en un proyecto de estas caractersticas.

22
ARQUITECTURA EN PIZARRA

La arquitectura software en pizarra es un modelo arquitectnico de software

habitualmente utilizado en sistemas expertos, sistemas multi-agente y, en
general, sistemas basados en el conocimiento.
La arquitectura en pizarra consta de mltiples elementos funcionales,
denominados agentes, y un instrumento de control denominado pizarra.
Los agentes suelen estar especializados en una tarea concreta o elemental.
Todos ellos cooperan para alcanzar una meta comn, si bien, sus objetivos
individuales no estn aparentemente coordinados.
El comportamiento bsico de cualquier agente consiste en examinar la pizarra,
realizar su tarea y escribir sus conclusiones en la misma pizarra. De esta manera,
otro agente puede trabajar sobre los resultados generados por otro.
La computacin termina cuando se alcanza alguna condicin deseada entre los
resultados escritos en la pizarra.
La pizarra tiene un doble papel. Por una parte, coordina a los distintos agentes
y, por otra, facilita su intercomunicacin. El estado inicial de la pizarra es una
descripcin del problema que resolver y el estado final ser la solucin del
problema.
Los resultados generados por los agentes deben responder a un lenguaje y
semntica comn. En general, se suelen utilizar formalismos lgicos o
matemticos, tales como expresiones lgicas de primer orden.
Ventajas e inconvenientes
Esta arquitectura es tremendamente til cuando el problema a resolver (o
algoritmo a implementar) es extremadamente complejo en trminos cognitivos.

23
Es decir, cuando el flujo de control del algoritmo es enrevesado, o simplemente,
no se tiene un conocimiento completo del problema a resolver.
Las desventajas de la arquitectura son bastante obvias a priori. Es importante no
generalizar en este aspecto, puesto que cada implementacin en particular
puede solventar estas desventajas en algn mbito limitado:
No existe garanta de que se alcanzar una solucin.
Es una arquitectura ineficiente, puesto que no existe una cota respecto al tiempo
de cmputo necesario para resolver el problema.
Es difcil obtener una traza de los pasos que llevaron a la solucin, es decir, no
ofrece explicaciones.
Desde un punto de vista ms filosfico, la arquitectura en pizarra ofrece un
interesante experimento de tipo social. Cada agente tiene sus propios objetivos,
desconoce los objetivos de los dems, y tampoco conoce el objetivo global (la
solucin del problema). Sin embargo, se produce una cooperacin inconsciente
entre ellos que lleva a una meta ms importante.

24
MODELOVISTACONTROLADOR
Modelovistacontrolador (MVC) es un patrn de arquitectura de software, que
separa los datos y la lgica de negocio de una aplicacin de la interfaz de usuario
y el mdulo encargado de gestionar los eventos y las comunicaciones. Para ello
MVC propone la construccin de tres componentes distintos que son el modelo,
la vista y el controlador, es decir,
por un lado, define componentes
para la representacin de la
informacin, y por otro lado para
la interaccin del usuario.1 2
Este patrn de arquitectura de
software se basa en las ideas de
reutilizacin de cdigo y la
separacin de conceptos, caractersticas que buscan facilitar la tarea de
desarrollo de aplicaciones y su posterior mantenimiento.
DESCRIPCIN DEL PATRN
De manera genrica, los componentes de MVC se podran definir como sigue:
El Modelo: Es la representacin de la informacin con la cual el sistema opera,
por lo tanto gestiona todos los accesos a dicha informacin, tanto consultas como
actualizaciones, implementando tambin los privilegios de acceso que se hayan
descrito en las especificaciones de la aplicacin (lgica de negocio). Enva a la
'vista' aquella parte de la informacin que en cada momento se le solicita para
que sea mostrada (tpicamente a un usuario). Las peticiones de acceso o
manipulacin de informacin llegan al 'modelo' a travs del 'controlador'.12
El Controlador: Responde a eventos (usualmente acciones del usuario) e
invoca peticiones al 'modelo' cuando se hace alguna solicitud sobre la
informacin (por ejemplo, editar un documento o un registro en una base de
datos). Tambin puede enviar comandos a su 'vista' asociada si se solicita un
cambio en la forma en que se presenta el 'modelo' (por ejemplo, desplazamiento
o scroll por un documento o por los diferentes registros de una base de datos),
por tanto se podra decir que el 'controlador' hace de intermediario entre la 'vista'
y el 'modelo' (vase Middleware).
La Vista: Presenta el 'modelo' (informacin y lgica de negocio) en un formato
adecuado para interactuar (usualmente la interfaz de usuario) por tanto requiere
de dicho 'modelo' la informacin que debe representar como salida.
Interaccin de los componentes
Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo de
control que se sigue generalmente es el siguiente:
a) El usuario interacta con la interfaz de usuario de alguna forma (por
ejemplo, el usuario pulsa un botn, enlace, etc.)
b) El controlador recibe (por parte de los objetos de la interfaz-vista) la
notificacin de la accin solicitada por el usuario. El controlador gestiona
25
 el evento que llega, frecuentemente a travs de un gestor de eventos
(handler) o callback.
c) El controlador accede al modelo, actualizndolo, posiblemente
modificndolo de forma adecuada a la accin solicitada por el usuario (por
ejemplo, el controlador actualiza el carro de la compra del usuario). Los
controladores complejos estn a menudo estructurados usando un patrn
de comando que encapsula las acciones y simplifica su extensin.
d) El controlador delega a los objetos de la vista la tarea de desplegar la
interfaz de usuario. La vista obtiene sus datos del modelo para generar la
interfaz apropiada para el usuario donde se reflejan los cambios en el
modelo (por ejemplo, produce un listado del contenido del carro de la
compra). El modelo no debe tener conocimiento directo sobre la vista. Sin
embargo, se podra utilizar el patrn Observador para proveer cierta
indireccin entre el modelo y la vista, permitiendo al modelo notificar a los
interesados de cualquier cambio. Un objeto vista puede registrarse con el
modelo y esperar a los cambios, pero aun as el modelo en s mismo sigue
sin saber nada de la vista. Este uso del patrn Observador no es posible
en las aplicaciones Web puesto que las clases de la vista estn
desconectadas del modelo y del controlador. En general el controlador no
pasa objetos de dominio (el modelo) a la vista, aunque puede dar la orden
a la vista para que se actualice. Nota: En algunas implementaciones la
vista no tiene acceso directo al modelo, dejando que el controlador enve
los datos del modelo a la vista. Por ejemplo, en el MVC usado por Apple
en su framework Cocoa. Suele citarse como Modelo-Interface-Control,
una variacin del MVC ms puro
e) La interfaz de usuario espera nuevas interacciones del usuario,
comenzando el ciclo nuevamente....
MVC y bases de datos
Muchos sistemas informticos utilizan un Sistema de Gestin de Base de Datos
para gestionar los datos que debe utilizar la aplicacin; en lneas generales del
MVC dicha gestin corresponde al modelo. La unin entre capa de presentacin
y capa de negocio conocido en el paradigma de la Programacin por capas
representara la integracin entre la Vista y su correspondiente Controlador de
eventos y acceso a datos, MVC no pretende discriminar entre capa de negocio
y capa de presentacin pero si pretende separar la capa visual grfica de su
correspondiente programacin y acceso a datos, algo que mejora el desarrollo y
mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen
ciclos de vida muy distintos entre s.

26
ARQUITECTURA DE MICROSERVICIOS
La Arquitectura de microservicios, conocido por las siglas MSA (del ingls
MicroServices Architecture) es una aproximacin para el desarrollo software que
consiste en construir una aplicacin como un conjunto de pequeos servicios,
los cuales se ejecutan en su propio proceso y se comunican con mecanismos
ligeros (normalmente una API de recursos HTTP). Cada servicio se encarga de
implementar una funcionalidad completa del negocio. Cada servicio es
desplegado de forma independiente y puede estar programado en distintos
lenguajes y usar diferentes tecnologas de almacenamiento de datos.
Se suele considerar la arquitectura de microservicios como una forma especfica
de realizar una arquitectura SOA.
CARACTERSTICAS
En el mundo real no todas las implementaciones de este estilo de arquitecturas
siguen las mismas caractersticas, pero la mayor parte de las arquitecturas de
microservicios tienen la mayor parte de las siguientes caractersticas:
Los componentes son servicios. La principal manera de crear componentes
(unidad de software independientemente reemplazable y actualizable) es
mediante la descomposicin en servicios en lugar de libreras. Los servicios son
componentes separados que se comunican mediante mecanismos como los
servicios web o los RPC en lugar de usar llamadas a funciones en memoria como
hacen las libreras.
Organizada en torno a las funcionalidades del negocio. El sistema se divide
en distintos servicios donde cada uno est organizado en torno a una capacidad
del negocio. Es muy importante limitar la responsabilidad de cada servicio. Cada
servicio implementa toda la funcionalidad del negocio que agrupa desde la
interfaz de usuario, la persistencia en el almacenamiento y cualquiera de las
colaboraciones externas.
Productos no proyectos. En esta arquitectura normalmente se sigue la idea de
que un equipo debe estar a cargo de un componente (servicio) durante todo el
ciclo de vida del mismo, desde la etapa de diseo y construccin, la fase de
produccin y hasta la de mantenimiento. Esta mentalidad se acopla bien a con
la vinculacin a una capacidad del negocio. En lugar de ver el software como un
conjunto de funcionalidades terminadas se ve como una relacin continua,
donde la pregunta es cmo puede el software ayudar a sus usuarios a mejorar
la funcionalidad del negocio que implementa. Esto es facilitado por el bajo nivel
de granularidad que ofrecen los microservicios.
Extremos inteligentes tuberas bobas. Las aplicaciones creadas desde
microservicios pretender ser tan disociadas y cohesivas como sea posible, ellas
poseen su propia lgica de dominio y actan como filtros en el clsico sentido
UNIX: recibe una solicitud, aplica la lgica apropiada y produce una respuesta.
Estos pasos son coreografiados usando protocolos simples (tpicamente HTTP

27
con REST o mensajera liviana como RabbitMQ o ZeroMQ) en lugar de
protocolos complejos como WS-BPEL.
Tener gobierno descentralizado permite usar tecnologas que se adapten
mejor a cada funcionalidad. Con el sistema con mltiples servicios colaborativos,
podemos decidir utilizar diferentes lenguajes de programacin y tecnologas
dentro de cada servicio. De esta forma podemos elegir la herramienta adecuada
para cada tipo de trabajo en lugar de tener una estandarizada. Por ejemplo, si
una parte del sistema necesita mejorar su rendimiento es posible usar una
tecnologa, quizs ms complicada, que permita alcanzar el nivel de rendimiento
requerido. Otro ejemplo sera usar para ciertas cosas (reflejar interacciones entre
usuarios) una base de datos orientada a grafos, y usar para otra base de datos
orientadas a documentos. la arquitectura de microservicios permite adoptar
nuevas tecnologas ms rpido y en aquello lugares donde se puede aprovechar
su potencial ya que se acota el impacto.
Gestin de datos descentralizada. Los microservicios prefieren dejar a cada
servicio que gestione su propia base de datos, sean estas diferentes instancias
de la misma tecnologa de base de datos o sistemas de base de datos
completamente diferentes. Por ejemplo, podramos tener Redis para sesiones
de usuarios (base de datos en memoria), MySQL (relacional) para los datos de
pago, MongoDB (orientada a documentos) para el catlogo de productos, Neo4j
(orientada a grafos) para las recomendaciones y Apache Cassandra (orientado
a clave-valor) para el anlisis de logs y analticas. El estilo de microservicios tiene
implicaciones en el manejo de las actualizaciones las cuales tradicionalmente
han usado transacciones para garantizar la consistencia. la transaccin impone
un acoplamiento temporal lo que se vuelve problemtico cuando hay varios
servicios. Como las transacciones distribuidas son mucho ms difciles de
implementar, las arquitecturas de microservicios promueven la coordinacin no
transaccional entre servicios, con el reconocimiento explcito que la consistencia
puede ser una consistencia eventual y los problemas son compensados
operativamente. El sistema merece la pena siempre y cuando el costo de
solucionar los errores sea menor que el costo de perder negocios por una mayor
consistencia. Los microservicios no obligan a tener distintas tecnologas de
almacenamiento, solo lo permiten.
Diseo pensado en las fallas. Las aplicaciones necesitan ser diseadas de
modo que puedan tolerar las fallas de los distintos servicios. Cualquier llamada
de servicio puede fallar y el cliente tiene que responder a esto con la mayor
facilidad posible. Patrones ms importantes para conseguir estabilidad que se
usan en la arquitectura de microservicios:
a) Usar tiempos de espera mximos. Es un mecanismo simple que permite
dejar de seguir esperando por una respuesta que consideramos que ya
no vendr. Asociado al vencimiento de un tiempo de espera es frecuente
que aparezcan:
Reintento. Consiste en repetir una operacin para el cual finaliz su
tiempo de espera

28
 Encolar para reintentar la operacin para ser realizada ms tarde
b) Disyuntores. Funcionan de forma similar a los interruptores automticos
accionados por sobrecargas que hay en las instalaciones elctricas. En el
software existen para permitir que un subsistema ante una falla no
destruya el sistema entero por sobrecarga y una vez que el peligro ha
pasado pueda reestablecerse. Este mecanismo se suele usar para
envolver operaciones peligrosas con un componente y as poder esquivar
las llamadas cuando el sistema no est operativo. Si el disyuntor detecta
que las fallas superan una frecuencia umbral el disyuntor salta abrindose
y las llamadas fallan sin realizan ningn intento de ejecutar una operacin
real. Despus de esperar un tiempo adecuado se decide que la operacin
tiene una oportunidad y pasa a un estado de semiabierto en el que la
prxima llamada es permitida, si tiene xito entonces el disyuntor se
vuelve a cerrar y todo vuelve a funcionar normalmente, si falla el disyuntor
se vuelve a abrir y se vuelve a esperar el tiempo adecuado para intentar.
c) Compartimentos estancos para contencin de daos mantenindolos
aislados. La forma ms comn de tenerlos es usando redundancia fsica
teniendo por ejemplo varios servidores y dentro de cada servidor varias
instancias. A gran escala podramos tener varias granjas de servidores.
Automatizacin de la infraestructura. La mayora de los productos y sistemas
desarrollados con el enfoque de microservicios han sido construidos por equipo
que usan entrega continua y su precursor la integracin continua. Para conseguir
esto es necesario:
Automatizar todo el proceso, desde el chequeo del cdigo, pruebas, despliegue,
...
Control de versiones y gestin de configuracin. Todo el software tiene que
estar versionado y poder gestionar las distintas configuraciones para conseguir
la entrega continua.
Arquitectura adecuada. La arquitectura tiene que permitir realizar cambios sin
que afecten al resto del sistema. La arquitectura de microservicios lo hace
posible.
Diseo evolutivo. Cuando se divide el sistema en servicios hay que tener en
cuenta que cada uno tiene que poder ser reemplazado o actualizado de forma
independiente. Es decir, tiene que permitir una fcil evolucin. El diseo del
servicio tiene que ser de tal forma que evite en lo posible que la evolucin de los
servicios afecte a sus consumidores.

29
 CONCLUSIN
La arquitectura de software es de especial importancia ya que la manera en que
se estructura un sistema tiene un impacto directo sobre la capacidad de este
para satisfacer lo que se conoce como los atributos de calidad del sistema.
Ejemplos de atributos de calidad son el desempeo, que tiene que ver con el
tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad,
que tiene que ver con qu tan sencillo les resulta a los usuarios realizar
operaciones con el sistema, o bien la modificabilidad, que tiene que ver con qu
tan simple resulta introducir cambios en el sistema. Los atributos de calidad son
parte de los requerimientos (no funcionales) del sistema y son caractersticas
que deben expresarse de forma cuantitativa. No tiene sentido, por ejemplo, decir
que el sistema debe devolver una peticin de manera rpida, o presentar una
pgina ligera, ya que no es posible evaluar objetivamente si el sistema cubre o
no esos requerimientos.
La manera en que se estructura un sistema permitir o impedir que se
satisfagan los atributos de calidad. Por ejemplo, un sistema estructurado de tal
manera que una peticin deba transitar por muchos componentes antes de que
se devuelva una respuesta podra tener un desempeo pobre. Por otro lado, un
sistema estructurado de tal manera que los componentes estn altamente
acoplados entre ellos limitar severamente la modificabilidad. Curiosamente, la
estructuracin tiene un impacto mucho menor respecto a los requerimientos
funcionales del sistema. Por ejemplo, un sistema difcil de modificar puede
satisfacer plenamente los requerimientos funcionales que se le imponen.

30
 BIBLIOGRAFA
a) Mary Shaw, Abstraction techniques in modern programming languages
IEEE Software, pp. 10-26, October 1984.
b) Mary Shaw, Large scale systems require higher level abstraction,
Proceedings of fifth international workshop on software specification and
design. IEEE Computer Society, pp. 143-146, 1989.
c) Paul Clements, Coming attractions in software architecture, Technical
report, CMU/SEI-96-TR-008, ESC-TR-96-008, jan. 1996.
d) Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design
Patterns: Elements of reusable object-oriented software. Reading,
Addison-Wesley, 1995.
e) Philippe Krutchen, The 4+1 view model architecture, IEEE Software
12(6), pp. 42-50, nov. 1995.
f) Paul Clements, A survey of architecture descriptions languages
Proceedings of the International Workshop on Software Specification and
Design, Germany, 1996.
g) Roy Thomas Fielding, Architecture styles and design of network-based
software architectures PhD Thesis, California University, Irvine 2000.
h) Software Engineering Standards Committee of the IEEE Computer
Society, IEEE Recommended practice for architecture description of
software-intensive systems, IEEE Std 1471-2000, Approved 21
September 2000, IEEE-SA Standards Board, Print: ISBN 0-7381-2518-0
SH94869, PDF: ISBN 0-7381-2519-9 SS94869, available at
(http://standards.ieee.org/).
i) Dewayne E. Perry y Alexander Wolf. Foundations for the study of
software architecture, ACM SIGSOFT Software Engineering Notes,
17(4), pp. 40-52, octubre de 1992.
j) Edsger Dijkstra. Go-To statement considered harmful. ACM
Communications of the ACM, 11(3), pp. 147-148, Marzo de 1968.
k) David Parnas, On the criteria for decomposing systems into modules
Communications of the ACM 15(12), pp. 1053-1058, December 1972

31