Esta arquitectura establece un paradigma del software en la que los servicios o funcionalidades del sistema son ofrecidos por un elemento llamado Servidor, mientras que los usuarios solicitan estos servicios a través del componente llamado Cliente.

Es posible que un servidor pueda ser cliente de otros servidores, formando así una red de interconexión.

Arquitectura Cliente-Servidor. Tomado de Spamer, M. (2009). Client Server architecture pattern. Recuperado de http://www.spamer.me.uk/wiki/doku.php/client-server_architecture_patterns Sólo para fines educativos.

En el siguiente ejemplo se muestra la arquitectura Cliente/Servidor de un sistema de cajeros automáticos de un banco. En el diagrama se observa que pueden existir replicas de clientes (diferentes cajeros automáticos) y servidores (que pueden estar atendiendo a un grupo de cajeros de una zona o ciudades diferentes).

Observa que hay un proceso principal ATM que envía una solicitud de autorización sobre la operación (por ejemplo un retiro). El servidor de reconfiguración se conecta con el proceso que permite que un cajero active o desactive alguna función específica, por ejemplo, transferencias bancarias o pago de servicios. Cada cajero es controlado por personal de seguidad a través de los servidores de monitoreo. Si existe algún problema con el cajero, el servidor envía una alarma a las estaciones de trabajo del personal de seguridad.

Las siglas FTX se refieren a servidores “Fault Tolerance Unix”. Son servidores que ejecutan procesos de conexión a través del protocolo TCP.

Arquitectura Cliente-Servidor de un Sistema Bancario ATM. Tomado de Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Merson, P., Nord. R., Stafford, J. (2010). Documenting Software Architectures: Views and Beyond (2a ed.). EE. UU: Addison-Wesley Professional. Sólo para fines educativos.

• Es recomendable utilizar esta arquitectura cuando se desea compartir recursos entre un gran número de clientes, manteniendo el control de acceso y la calidad del servicio.
• Aquellos sistemas de información implementados en redes locales en los que los clientes corren la interfaz gráfica, mientras que la base de datos reside en el servidor.
• Las aplicaciones web pueden ser consideradas en una arquitectura cliente-servidor. Los navegadores son los clientes, mientras que los servidores se hacen cargo de ejecutar funciones críticas. Piensa por ejemplo, en sitios destinados a generar e-commerce.

• Tienen la ventaja de compartir recursos y aprovechar tiempos de ocio. Por ejemplo un servidor de impresión que permita compartir una impresora por varias personas de una misma área de la organización, permitiendo controlar el gasto de consumibles.
• Dado que la funcionalidad reside en un servidor, es sencillo controlar el acceso en clientes existentes, agregar nuevos clientes y poner a disposición de un gran número de usuarios funcionalidades nuevas.
• Permite controlar las versiones de software y los eventos en los que se requiere suspender el servicio por motivos de mantenimiento o corrección de errores.
• Es posible aumentar la escalabilidad y disponibilidad de los servicios en sistemas distribuidos con múltiples servidores.
• En configuraciones con varios servidores-replica, es posible balancear la carga de solicitudes de los clientes.

• El servidor puede ser un punto único de falla. Si este componente presenta alguna falla, degradación o saturación, afectará a los clientes que soliciten funcionalidades.
• Según Sommerville (2011), esta arquitectura es susceptible a ataques de seguridad de DoS (denial of service) o rechazo de servicios, y pueden surgir problemas administrativos cuando los servidores pertenecen a diferentes organizaciones.
• Esta arquitectura depende de factores como el medio de acceso y la capacidad del hardware para responder a todas las solicitudes (concurrentes o asíncronas).
• En opinión de Bass, Clements y Kazman (2012) cambiar de decisión sobre la ubicación de las funcionalidades (ya sea en el cliente o en el servidor) una vez implementado el sistema, suelen ser complejas y costosas.

Los clientes hacen solicitudes al servidor a través de conectores que enviarán mensajes del tipo request / response.

Es una arquitectura en la que cada nodo o terminal permite conectarse con otro nodo o terminal sin necesidad de servidores o clientes. Cada nodo es capaz de detectar otros nodos de forma autónoma.

En una arquitectura P2P descentralizada, los nodos de la red mantienen funciones de conmutación de datos entre los nodos.

Arquitectura P2P Puro.

En el siguiente ejemplo propuesto por Sommerville (2011), se muestra una arquitectura de un consorcio de investigadores. Los nodos comparten archivos, mientras cada uno de ellos mantiene su capacidad de almacenamiento independiente del resto. Si un nodo obtiene algún archivo de otro nodo, éste pone a disposición el mismo archivo al resto de los nodos.

La eficiencia de búsqueda de archivos está basada en revisar primero en los nodos locales antes de consultar nodos lejanos.

Por ejemplo, si el n1 solicita un archivo que se encuentre el n13, el algoritmo de búsqueda empezará en los nodos más cercanos hasta detectar el archivo, creando un camino de regreso en una conexión punto a punto entre el n13 y el n1. Ahora n1 podrá ofrecer este mismo archivo al resto de los nodos.

Arquitectura P2P descentralizada. Tomado del libro de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson. Fig. 18.14. Sólo para fines educativos

En opinión de Sommerville (2011), esta arquitectura es ideal en dos escenarios principalmente:

1. Cuando el sistema exige un poder de procesamiento más intenso, pero a la vez es posible realizar procesamiento de datos en paralelo de forma independiente.
2. Cuando el sistema requiere de intercambiar información contenida en diversas computadoras sin necesidad de concentrarla en una sola fuente. Éste es el caso de las aplicaciones que comparten música, e-books, películas y otros archivos.

Esta arquitectura es utilizada cuando se requieren funcionalidades de e-business para el intercambio de información entre clientes y proveedores.

• Demuestra tener una alta tolerancia a las fallas de conexión, ya que la misma interconexión entre los nodos favorece el ruteo cuando alguno de sus nodos falla.
• Es redundante, porque replica su capacidad de ofrecer archivos que fueron encontrados con anterioridad por otros nodos.
• Son eficientes al utilizar la capacidad de la red, haciendo uso de balance de cargas y balanceo de tráfico, minimizando así la congestión.
• Son escalables y autoadministrables. Los nodos pueden fácilmente ser incorporados y detectados en la arquitectura.

• La misma redundancia es a la vez una desventaja, ya que es posible que llegar a tener escenarios donde un mismo archivo se encuentre en una gran cantidad de nodos, lo que provoca ineficiencia en la capacidad de almacenamiento.
• Son propensos a generar fallas de seguridad ya que mantienen abiertos puertos de comunicación que pueden aprovechar intrusos para sacar información sensible, o bien proliferar archivos maliciosos (spyware) que infecten al resto de los nodos.

• Para que la arquitectura P2P funcione, es imprescindible que los nodos se mantengan activos.
• La capacidad de transferencia de información depende del desempeño de la red de interconexión.

Permiten desarrollar sistemas distribuidos con componentes que ofrecen servicios de manera independiente con la facilidad de estar geográficamente distribuidos.

En una arquitectura basada en servicio, los proveedores ofrecen servicios a través de una o varias interfaces. Los programas que requieren de estos servicios ubican al proveedor a través de las especificaciones del servicio, establecen una conexión por medio de un protocolo de comunicación y hacen uso del servicio.

Arquitectura orientada a servicios. Tomado del libro de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson. Sólo para fines educativos.

En el siguiente ejemplo, Bass et al (2012), ofrecen la arquitectura SOA a través de un sistema llamado Adventure Builder.

Este sistema permite a los clientes elegir las actividades, alojamiento y transporte que requieren para vacacionar. Adventure Builder interactúa con proveedores de este tipo de servicios y con servicios de bancarios que les permite procesar el pago de sus clientes.

Observa en el siguiente diagrama, la existencia de una unidad central de procesamiento de órdenes llamada OPC, que coordina la interacción entre los consumidores y los proveedores (internos y externos) de los servicios que solicita el cliente. Es importante hacer notar que no importa el tipo de plataforma que utilicen los proveedores (Sistemas JAVA o .NET), cada uno de ellos utiliza un web service que permite la interoperabilidad necesaria para crear valor al cliente.

Ejemplo de la arquitectura SOA. Tomado del libro de Bass, L., Clements, P. y Kazman, R. (2012). Software Architecture in Practice. EE. UU.: Addison - Wesley Professional.

Cuando se requieren ejecutar servicios que se encuentran distribuidos en diferentes plataformas, implementados en diferentes lenguajes de programación y que son provistos por diferentes organizaciones.

• Los servicios son independientes de la plataforma y del lenguaje de implementación.
• Al utilizar un web service en una aplicación puedes hacer públicas sus funciones al resto del mundo.
• Es posible utilizar lenguajes estándares como XML, que utiliza etiquetas con notación flexible para definir datos que puedan ser enviados y recibidos dentro de la arquitectura SOA. Entre los estándares que se pueden utilizar son SOAP “Simple Object Access Protocol”, WSDL “Web Service Description Language” y WS-BPEL “Web Services –Business Process Execution Language”.

• En opinión de Bass, Clements y Kazman (2012), la construcción de los sistemas basados en esta arquitectura es compleja.
• Mantener el control de la evolución de los servicios independientes es complicado.
• Los servicios pueden experimientar cuellos de botella, por lo que no es posible garantizar su nivel de rendimiento.

Se requieren algunos componentes intermedios para utilizar servicios que ofrecen los proveedores.