Patrón Thin web client

Este patrón es el mas apropiado para aplicaciones basadas en Internet o para estos ambientes

en el cual el cliente tiene mínimo poder de computo o no hay control sobre esta configuración.

Donde toda la lógica de negocio se ejecuta en el servidor durante el cumplimiento a las

solicitudes de pagina que realiza el navegador del cliente.

Casos conocidos

La mayoría de las aplicaciones de e-commerce usan este patrón dado que no se pueden perder

clientes solo porque no tiene poder de computo.

Estructura

Sus principales componentes son:

 Cliente browser: solo tiene la capacidad de aceptar y retornar cookies y que todas las

interacciones con el sistema son a través del browser.

 Servidor web: todos los accesos al sistema por parte del cliente los hace a través del

servidor Web. El cual acepta solicitudes para paginas Web.

 Conexión http: Esta conexión es usada entre el cliente y el servidor para su

comunicación permitiéndole enviar y recibir información.

 Pagina cliente: Contiene texto explicativo, tal como información o formas de

entrada(HTML).

 Pagina servidor: Estas páginas son ejecutables por módulos que tienen

potencialmente tienen acceso a todos los recursos al lado del servidor incluyendo la

lógica del negocio, base de datos, sistemas herederos y cuentas del sistema.
  Servidor de aplicaciones: El servidor de aplicaciones es lógicamente un elemento

arquitectónico independiente, ya que sólo se refiere a la ejecución de lógica de

negocio y puede utilizar una tecnología completamente diferente desde el servidor

Web.

El punto clave del comportamiento dinámico de este patrón es que la lógica de negocio sólo

se invoca durante el proceso de una solicitud de página. Una vez que la solicitud de la página se

ha cumplido, el resultado es enviado de vuelta al cliente solicitante, y la conexión entre el cliente

y el servidor se termina. (Ortega, 2015)

Patrón Thick Web Client

El uso de secuencias de comandos (scripts) del lado del cliente y los objetos personalizados,

como los controles ActiveX y Applets de Java. El patrón Thick Web Client recibe el nombre de

que el cliente puede ejecutar alguna lógica de negocio del sistema y por lo tanto se convierte en

algo más que una interfaz de usuario contenedor generalizado.

Aplicabilidad

Visualizar y modificar modelos en varias dimensiones o para animar gráficas financieras. A

diferencia de la anterior es el rol que juega el browser en la lógica del negocio del cliente.

Los dos motivos fuertes para el uso de Thick Web Client son la capacidad de mejorar la

interfaz de usuario del cliente y la ejecución de lógica de negocio. Una sofisticada interfaz de

usuario podría ser utilizada para visualizar y modificar modelos tridimensionales, o animar un

gráfico financiero. (Alonso G, 2004)

 Por ejemplo, equipos para el cuidado de la salud que puede medir la presión arterial, el

recuento de azúcar, y otros signos vitales pueden ser utilizados por un organismo que debe

controlar a los pacientes geográficamente remotos sobre una base diaria, y ser capaz de reducir

las visitas personales a dos veces por semana.

Estructura

La comunicación entre el cliente y el servidor son hechos vía http en la que los objetos

controles ActiveX, Java Applet están limitados a interactuar con los objetos del cliente.

Utiliza ciertas capacidades del navegador, como los controles ActiveX o Applets de Java para

ejecutar la lógica de negocio en el cliente. Los controles ActiveX son compilados, programas

binarios ejecutables que se pueden descargar en el cliente a través de HTTP, e invocado por el

navegador.

Contiene los siguientes scripts clientes:

 Control ActiveX: Objeto COM que se puede hacer referencia en un script de cliente y

"descargar" al cliente si es necesario. Al igual que cualquier objeto COM, tiene pleno

acceso a los recursos del cliente.

 Applet de Java: Un autónomo y compilado componente que se ejecuta en el contexto de

un navegador. Por razones de seguridad tiene acceso limitado a los recursos del lado del

cliente. Applets de Java utiliza ambos elementos de la interfaz de usuario y procesadores

de documentos XML, o para encapsular la lógica de negocio complicada.

 Java Bean: Componente Java que implementa un determinado conjunto de interfaces

que le permitan ser fácilmente incorporados en grandes sistemas complejos.

Esta arquitectura las comunicaciones entre el servidor y el cliente se dan por una solicitud de una

página. La lógica del negocio puede ejecutarse en el cliente con scripts, controles o applets en la

que los scripts son usados para valida datos de entrada.

Patrón Web Delivery

El modelo de arquitectura Web Delivery se llama así porque la Web se utiliza principalmente

como un mecanismo de entrega de otro modo tradicional de objetos distribuidos sistema cliente-

servidor.

Aplicabilidad

Este patrón de arquitectura es el más apropiado cuando hay un control significativo sobre el

cliente y configuraciones de red. Este patrón no es especialmente adecuado para aplicaciones

basadas en Internet, donde no hay, o muy poco control sobre las configuraciones de cliente, o

cuando las comunicaciones de red no son confiables.

Las mayores fortalezas de esta arquitectura es su capacidad para aprovechar los objetos de

negocio existentes en el contexto de una aplicación Web Lo más importante de esta arquitectura

es apalancar la existencia de objetos de negocios en el contexto de una aplicación Web con

comunicación directa y persistente entre el cliente y el servidor, con esto se superan los

problemas mencionados anteriormente.

Estructura
 La diferencia más significativa entre Web Delivery y los patrones de arquitectura de

aplicaciones Web es el método de comunicación entre el cliente y el servidor. En los otros

modelos el principal mecanismo fue HTTP, un protocolo sin conexión que limita severamente el

diseñador cuando se trata de la actividad interactiva entre el usuario y el servidor. Los elementos

arquitectónicos significativos de este patrón incluyen todos los que se especifican:

 DCOM: Es el protocolo de objetos distribuidos de Microsoft. Permite que los objetos

en una máquina interactúen e invoquen con métodos sobre los objetos en otro equipo.

 RMI (JRMP) : Invocación de métodos remotos de Java es la forma de interactuar con

los objetos en otras máquinas. JRMP (Java Remote Method Protocolo) es el protocolo

nativo de RMI.

 IIOP: Protocolo Internet Inter-ORB permite interactuar con objetos distribuidos o

cualquier red basada en TCP/IP

Una de las fortalezas es que el browser tiene la capacidad de descargar componentes del

servidor. Quiere decir que cualquier computador con un browser puede acceder a la aplicación,

sin necesidad de instalar un software especial manualmente. Este componente es bajado

guardado en el cliente y se conectan con los objetos del servidor.

Patrones Arquitectónicos de Software

Patrón cliente-servidor
 Este patrón consiste en dos partes; un servidor y múltiples clientes. El componente del

servidor proporcionará servicios a múltiples componentes del cliente. Los clientes solicitan

servicios del servidor y el servidor proporciona servicios relevantes a esos clientes. Además, el

servidor sigue escuchando las solicitudes de los clientes. (huaman, 2018)

Uso

Aplicaciones en línea como correo electrónico, uso compartido de documentos y banca.

Patrón de Pizarra (blackboard)

El patrón Blackboard es un modelo arquitectónico de software habitualmente utilizado en

sistemas expertos, multivalente y basados en el conocimiento.

Consta de múltiples elementos funcionales, denominados agentes y un instrumento de control

denominado pizarra. En la que los agentes están especializados en resolver una tarea concreta.

Son procesos independientes que corresponden a particiones del conocimiento del mundo y

del dominio dependientes de la aplicación

Todos ellos cooperan para alcanzar una meta común, en la cual sus objetivos individuales no

están aparentemente coordinados. Único medio por el cual las Fuentes de conocimiento

interactúan para llegar a la solución (aprendearquitecturasoftware, 2018)

Patrón de capas
 Este patrón se puede utilizar para estructurar programas que se pueden descomponer en

grupos de subtareas, cada una de las cuales se encuentra en un nivel particular de abstracción.

Cada capa proporciona servicios a la siguiente capa superior.

Las 4 capas más comúnmente encontradas de un sistema de información general son las

siguientes.

Capa de presentación

Conocida como capa UI es la interacción entre el usuario y el software. Su principal

responsabilidad es mostrar información al usuario, interpretar los comandos de este y realizar

algunas validaciones simples de los datos ingresados. (Lizardo, 2010)

Capa de lógica de negocios

Conocida como capa de dominio que contiene la funcionalidad que implementa la aplicación.

Involucra cálculos básicos en la información dada por el usuario y datos almacenados y

validaciones

Capa de acceso a datos

Llamada también capa de persistencia contiene lógica de comunicación con otros sistemas

que llevan a cabo tareas por la aplicación.

Uso

Aplicaciones de escritorio generales.

Aplicaciones web de comercio electrónico.

 Patrón de filtro de tubería

Este patrón se puede usar para estructurar sistemas que producen y procesan una secuencia de

datos. Cada paso de procesamiento se incluye dentro de un componente de filtro. Los datos que

se procesarán se pasan a través de las tuberías. Estas tuberías se pueden utilizar para el

almacenamiento en búfer o con fines de sincronización.

Tiene un grupo de componentes llamados filtros, conectados por tuberías que transmiten

datos de un componente al siguiente. El filtro está diseñado para recibir entrada de datos de una

forma y producir la salida de datos de una forma específica. Si el flujo de datos degenera en una

simple línea de transformadores se le llama Secuencial por Lotes. Cada filtro es independiente

del resto y no conocen la identidad de los filtros antes y después de él. (Pressman, 2016)

Ha prevalecido el nombre de tubería-filtros por más que se sabe muy bien que los llamados

filtros no realizan forzosamente tareas de filtrado, como ser eliminación de campos o registros,

sino que ejecutan formas variables de transformación, una de las cuales puede ser el filtrado.

Patrón de modelo-vista-controlador

El patrón de diseño de modelo-vista-controlador (MVC) especifica que una aplicación consta

de un modelo de datos, de información de presentación y de información de control. El patrón

requiere que cada uno de estos elementos esté separado en distintos objetos. (IBM, 2015)

Modelo: Contiene la funcionalidad y los datos básicos.

Vista: Muestra la información al usuario (se puede definir más de una vista).

Controlador: Maneja la entrada del usuario.

Esto se hace para separar las representaciones internas de información de las formas en que se

presenta y acepta la información del usuario. Desacopla los componentes y permite la

reutilización eficiente del código.

La mayoría de las aplicaciones hoy en día siguen este patrón, muchas con ligeras variaciones.

Por ejemplo, algunas aplicaciones combinan la vista y el controlador en una clase porque ya

están estrechamente unidos. Todas las variaciones recomiendan enérgicamente la separación de

los datos de su presentación. Esto no sólo simplifica la estructura de una aplicación sino que

también permite reutilizar el código.

Uso: Arquitectura para aplicaciones World Wide Web en los principales lenguajes de
programación.