ARQUITECTURA DE APLICACIONES WEB

Estilos de Arquitectura:

Son esquemas de organización general de un sistema que especifican una serie de subsistemas y sus responsabilidades. Incluyen reglas para organizar las relaciones entre ellos.

Estilos de Flujo de Datos
Tubería y filtros
Estilos Centrados en Datos
Arquitecturas de Pizarra o Repositorio
Estilos de Llamada y Retorno
Model-View-Controller (MVC)
Arquitecturas en Capas
Arquitecturas Orientadas a Objetos
Arquitecturas Basadas en Componentes
Estilos de Código Móvil
Arquitectura de Máquinas Virtuales
Estilos heterogéneos
Sistemas de control de procesos
Arquitecturas Basadas en Atributos
Estilos Peer-to-Peer
Arquitecturas Basadas en Eventos
Arquitecturas Orientadas a Servicios
Arquitecturas Basadas en Recursos

Arquitectura N-capas:

Cuando se escribe una aplicación, normalmente se diseñan y escogen los objetos comunicándolos a través de mensajes en código de alto nivel. Los protocolos que utilizan los objetos distribuidos manejan lo rudo, los detalles de bajo nivel, tales como los parámetros de ordenamiento, localización de objetos remotos, manejo de transacciones, etc.

En una arquitectura de n-capas se requiere diseñar objetos realmente reutilizables, que puedan usarse para proyectos futuros. Si los requisitos para un proyecto cambian es necesario reescribir el código; aún más importante es el hecho que, dejando la seguridad que proporciona una arquitectura por capas, se corre el riesgo de diseñar un sistema que sea más complejo que el pensado originalmente. Esto evita el avance, puesto que una decisión descuidada en el diseño puede tener aspectos no considerados. Sin embargo, la transmisión de aplicaciones de objetos distribuidos en CORBA no es tan rápida como aquellas diseñadas con protocolos de socket estándar; CORBA es lento por que necesita ser general, y su gran fortaleza es su mayor debilidad.

Revisión histórica:

Características e importancia:

• Permite el desarrollo en paralelo de cada capa 
• Permite el desarrollo de aplicaciones más robustas 
• El mantenimiento es más sencillo 
• Es más flexible se pueden añadir nuevos módulos para agregar mas funcionalidades. 
• Alta escalabilidad, puede manejar muchas peticiones con el mismo rendimiento simplemente añadiendo mas hardware 
• El crecimiento es lineal no es necesario añadir mas código para conseguir escalabilidad. 
• La separación de la presentación, lógica de negocio y datos es realizada en un número indefinido de capas lógicas 
• Su diseño permite que cada capa sea desarrollad, mejora, gestionada y desplegada de forma independiente. 
• La multicapa funciona consistentemente a lo largo de un variado conjunto de hardware.

Arquitectura distribuida

En arquitectura distribuida, los componentes se presentan en diferentes plataformas y varios componentes pueden cooperar uno con el otro a través de una red de comunicación con el fin de alcanzar un objetivo o meta específica.

Concepto de arquitectura distribuida

Un sistema distribuido se puede demostrar por la arquitectura cliente-servidor, que forma la base para las arquitecturas de múltiples niveles; las alternativas son la arquitectura de intermediario como CORBA, y la arquitectura orientada a servicios (SOA). En esta arquitectura, el procesamiento de información no se limita a una sola máquina sino que se distribuye en varios ordenadores independientes.


Hay varios marcos de tecnología para apoyar las arquitecturas distribuidas, incluyendo .NET, J2EE, CORBA, .NET servicios Web, servicios Web AXIS Java, y los servicios Globus Grid. El middleware es una infraestructura que soporte adecuadamente el desarrollo y ejecución de aplicaciones distribuidas. Proporciona una barrera entre las aplicaciones y la red.


Se encuentra en el medio del sistema y gestiona o apoya los diferentes componentes de un sistema distribuido. Ejemplos son monitores de transacción de procesamiento, convertidores de datos y los controladores de comunicación, etc.


Middleware como una infraestructura de sistema distribuido 

Base de la arquitectura distribuida

La base de una arquitectura distribuida es su transparencia, fiabilidad y disponibilidad.
Tiene las siguientes ventajas:

• El intercambio de recursos - Puesta en común de los recursos de hardware y software. 
• La apertura - Flexibilidad de la utilización de hardware y software de diferentes proveedores. 
• Concurrencia - El procesamiento simultáneo para mejorar el rendimiento. 
• Escalabilidad - el aumento del rendimiento mediante la adición de nuevos recursos. 
• 
  
• La tolerancia a fallos - La posibilidad de continuar en funcionamiento después de haberse producido un fallo. 

Sus desventajas son: 

• Complejidad - Son más complejos que los sistemas centralizados. 
• Seguridad - más susceptibles a ataques externos. 
• Manejabilidad - Más esfuerzo que se requiere para la gestión del sistema. 
• La imprevisibilidad - respuestas impredecibles, dependiendo de la organización del sistema y la carga de la red.

Arquitectura cliente-servidor
La arquitectura cliente-servidor es la arquitectura de sistema distribuido más común que se descompone el sistema en dos grandes subsistemas o procesos lógicos:


Client - Este es el primer proceso que emite una solicitud para el segundo proceso es decir, el servidor.
Servidor - Este es el segundo proceso que recibe la solicitud, lo lleva a cabo, y envía una respuesta al cliente.

En esta arquitectura, la aplicación se modela como un conjunto de servicios que están reguladas por los servidores y un conjunto de clientes que utilizan estos servicios. Los servidores no necesitan saber acerca de los clientes, pero los clientes deben conocer la identidad de los servidores.
Arquitectura cliente-servidor se puede clasificar en dos modelos en base a la funcionalidad del cliente:

Modelo de cliente ligero
En el modelo de cliente ligero, toda la gestión de la tramitación del expediente y los datos se realiza por el servidor. El cliente es simplemente responsable de ejecutar el software de interfaz gráfica de usuario. Se utiliza cuando los sistemas heredados se migran a las arquitecturas cliente-servidor en el que sistema heredado actúa como un servidor en su propio derecho, con una interfaz gráfica implementada en un cliente.

Sin embargo, una desventaja importante es que pone una carga de procesamiento en el servidor y la red.

Fat-cliente modelo de espesor /

En el modelo de espesor-cliente, el servidor está a cargo de la gestión de datos. El software en el cliente implementa la lógica de la aplicación y las interacciones con el usuario del sistema. Es más adecuado para los nuevos sistemas de cliente-servidor donde se sabe que las capacidades del sistema cliente con antelación.

Sin embargo, es más complejo que un modelo de cliente ligero especialmente para la gestión, ya que todos los clientes deben tener la misma copia / versión de la aplicación de software.

Arquitectura Cliente/Servidor de 2 niveles
La arquitectura en 2 niveles se utiliza para describir los sistemas cliente/servidor en donde el cliente solicita recursos y el servidor responde directamente a la solicitud, con sus propios recursos. Esto significa que el servidor no requiere otra aplicación para proporcionar parte del servicio.

Arquitectura Cliente/Servidor de 3 nivelesEn la arquitectura en 3 niveles, existe un nivel intermediario. Esto significa que la arquitectura generalmente está compartida por:
Un cliente, es decir, el equipo que solicita los recursos, equipado con una interfaz de usuario (generalmente un navegador web) para la presentación
El servidor de aplicaciones (también denominado software intermedio), cuya tarea es proporcionar los recursos solicitados, pero que requiere de otro servidor para hacerlo
El servidor de datos, que proporciona al servidor de aplicaciones los datos que requiere

Arquitectura Cliente/Servidor multinivel

En la arquitectura en 3 niveles, cada servidor (nivel 2 y 3) realiza una tarea especializada (un servicio). Por lo tanto, un servidor puede utilizar los servicios de otros servidores para proporcionar su propio servicio. Por consiguiente, la arquitectura en 3 niveles es potencialmente una arquitectura en N-niveles

Red Peer to Peer(P2P)

Forma coloquial de referirse a las denominadas redes entre iguales, redes entre pares o redes punto a punto. En estas redes no existen ni ordenadores cliente ni ordenadores que hagan de servidor. Las redes P2P permiten el intercambio directo de información, en cualquier formato, entre los ordenadores interconectados. El hecho de que sirvan para compartir e intercambiar información de forma directa entre dos o más usuarios ha propiciado que hayan sido, y estén siendo, utilizadas para intercambiar archivos cuyo contenido está sujeto a las leyes decopyright, lo que ha generado una gran polémica entre defensores y detractores de estos sistemas.

Las redes peer-to-peer aprovechan, administran y optimizan el uso del ancho de banda de los demás usuarios de la red por medio de la conectividad entre los mismos, obteniendo más rendimiento en las conexiones y transferencias que con algunos métodos centralizados convencionales, donde una cantidad relativamente pequeña de servidores provee el total del ancho de banda y recursos compartidos para un servicio o aplicación.

Arquitectura Orientada a Servicios
Un servicio es un componente de la funcionalidad de negocio que está bien definido, autónomo, independiente, publicó, y disponible para ser utilizado a través de una interfaz de programación estándar. Las conexiones entre los servicios se llevan a cabo mediante protocolos comunes y universales orientados a mensajes tales como el protocolo de servicios web SOAP, que puede entregar las solicitudes y respuestas entre los servicios sin apretar.

arquitectura orientada a servicios es un diseño cliente / servidor que apoyan el enfoque de TI alineada con el negocio en el que una aplicación se compone de servicios de software y los consumidores de servicios de software (también conocido como clientes o solicitantes de servicios).


Características de SOA

Una arquitectura orientada al servicio proporciona las siguientes características -

• Implementación distribuida - La exposición datos de la empresa y la lógica de negocio tan libremente, unido, detectable, estructurado, sin estado, unidades de la funcionalidad de los servicios de llamadas de grano grueso basado en estándares,.
• Compuestabilidad - Montar los nuevos procesos de servicios existentes que están expuestos a una granularidad deseada a través de bien definido, publicado y las interfaces normalizados de queja.
• Interoperabilidad - Acciones capacidades y servicios compartidos de reutilización a través de una red, independientemente de los protocolos subyacentes o la tecnología de aplicación.
• Reutilización - Elegir un proveedor de servicios y el acceso a los recursos existentes expuestas como servicios.

Arquitecturas para cloud computing

Elementos comunes de la arquitectura de cloud computing

Aunque las nubes varían ampliamente en cuanto a detalles de implementación, la arquitectura de cloud computing suele incluir estos elementos comunes:
Nivel de virtualización. La virtualización de los servidores y la virtualización del almacenamiento juegan un papel clave en la arquitectura de cloud computing, puesto que ofrecen una de las principales ventajas de la nube: la agilidad. Un nivel de virtualización permite a los proveedores aprovisionar o desaprovisionar rápidamente servidores en la nube para satisfacer las necesidades de los usuarios del servicio.
Almacenamiento escalable horizontalmente. La escalabilidad es otro rasgo distintivo de la arquitectura de cloud computing y desde el punto de vista del almacenamiento, se suele derivar de tecnologías que aprovechan grandes grupos de componentes de hardware de consumo que se pueden ampliar de manera sencilla y económica según crece la demanda de infraestructura y recursos de almacenamiento.
Mecanismos para admitir varios inquilinos. Un servicio de cloud computing debe permitir la segregación física o virtual de los datos almacenados según el inquilino y ser capaz de hacer un seguimiento del uso del servicio por inquilino. Es importante destacar que el uso de varios inquilinos es una característica integral incluso en nubes privadas: en este contexto, los inquilinos son los diferentes departamentos o grupos de trabajo dentro de la empresa.
API web. Otro elemento clave de la arquitectura de cloud computing es un conjunto de API web (con métodos estándar, como llamadas HTTP RESTful, XML y SOAP) a través de las cuales se puede llamar a los servicios en la nube. Esto permite que los servicios estén disponibles a través de un navegador web estándar o de otra aplicación cliente HTTP.
Arquitecturas para dispositivos móviles
A diferencia de las computadoras “tradicionales”, los dispositivos móviles tienen características particulares que incluyen:
Duración limitada de la batería.
Posible tamaño pequeño de la pantalla.
Conectividad intermitente.
Posibilidad de que el dispositivo se pierda fácilmente.
Posibilidad de realizar cálculos demandantes.
Variedad de sensores que permiten recolectar información.
Acceso a infraestructura que facilita la instalación y actualización de aplicaciones (mercados de apps).

Los puntos descritos previamente aunados al hecho de que los dispositivos móviles están siempre a la mano, ha dado lugar a distintos tipos de aplicaciones con drivers particulares. Recordemos que en el contexto de arquitectura de software, los drivers, se refieren a los requerimientos que influyen en el diseño de la arquitectura. Estos drivers generalmente incluyen requerimientos funcionales primarios, atributos de calidad y restricciones.

https://www.polibits.gelbukh.com/2006_34/Arquitecturas%20en%20n-Capas_%20Un%20Sistema%20Adaptivo.pdf
https://es.wikipedia.org/wiki/Programaci%C3%B3n_por_capas
download.microsoft.com/.../050608-Architect%20Academy%20Webcast%201.ppt

http://desarrollowebydesarrolloweb.blogspot.com.co/2015/02/descripcion-de-las-caracteristicas-los.html
http://www.w3ii.com/es/software_architecture_design/distributed_architecture.html
http://es.ccm.net/contents/147-redes-arquitectura-cliente-servidor-en-3-niveles
https://www.ecured.cu/Red_Peer_to_Peer
https://www.akamai.com/es/es/resources/cloud-computing-architecture.jsp