Arquitectura distribuida
En la arquitectura distribuida, los componentes se presentan en diferentes plataformas y varios componentes pueden cooperar entre sí a través de una red de comunicación para lograr un objetivo u objetivo específico.
En esta arquitectura, el procesamiento de la información no se limita a una sola máquina, sino que se distribuye en varias computadoras independientes.
Un sistema distribuido puede demostrarse mediante la arquitectura cliente-servidor que forma la base de las arquitecturas de varios niveles; Las alternativas son la arquitectura de intermediarios como CORBA y la Arquitectura orientada a servicios (SOA).
Hay varios marcos de tecnología para admitir arquitecturas distribuidas, incluidos los servicios web .NET, J2EE, CORBA, .NET, los servicios web AXIS Java y los servicios Globus Grid.
Middleware es una infraestructura que soporta adecuadamente el desarrollo y ejecución de aplicaciones distribuidas. Proporciona un búfer entre las aplicaciones y la red.
Se encuentra en el medio del sistema y administra o da soporte a los diferentes componentes de un sistema distribuido. Algunos ejemplos son monitores de procesamiento de transacciones, convertidores de datos y controladores de comunicaciones, etc.
Middleware como infraestructura para sistema distribuido
La base de una arquitectura distribuida es su transparencia, confiabilidad y disponibilidad.
La siguiente tabla enumera las diferentes formas de transparencia en un sistema distribuido:
| No Señor. | Transparencia y descripción |
|---|---|
| 1 | Access Oculta la forma en que se accede a los recursos y las diferencias en la plataforma de datos. |
| 2 | Location Se esconde donde se encuentran los recursos. |
| 3 | Technology Oculta al usuario diferentes tecnologías, como el lenguaje de programación y el sistema operativo. |
| 4 | Migration / Relocation Ocultar los recursos que se pueden mover a otra ubicación que están en uso. |
| 5 | Replication Oculte los recursos que pueden copiarse en varias ubicaciones. |
| 6 | Concurrency Ocultar recursos que puedan compartirse con otros usuarios. |
| 7 | Failure Oculta la falla y la recuperación de recursos del usuario. |
| 8 | Persistence Oculta si un recurso (software) está en la memoria o en el disco. |
Ventajas
Resource sharing - Compartir recursos de hardware y software.
Openness - Flexibilidad de uso de hardware y software de diferentes proveedores.
Concurrency - Procesamiento concurrente para mejorar el rendimiento.
Scalability - Mayor rendimiento al agregar nuevos recursos.
Fault tolerance - La capacidad de continuar en funcionamiento después de que haya ocurrido una falla.
Desventajas
Complexity - Son más complejos que los sistemas centralizados.
Security - Más susceptible al ataque externo.
Manageability - Se requiere más esfuerzo para la gestión del sistema.
Unpredictability - Respuestas impredecibles según la organización del sistema y la carga de la red.
Sistema centralizado frente a sistema distribuido
| Criterios | Sistema centralizado | Sistema distribuido |
|---|---|---|
| Ciencias económicas | Bajo | Alto |
| Disponibilidad | Bajo | Alto |
| Complejidad | Bajo | Alto |
| Consistencia | Simple | Alto |
| Escalabilidad | Pobre | Bueno |
| Tecnología | Homogéneo | Heterogéneo |
| Seguridad | Alto | Bajo |
Arquitectura cliente-servidor
La arquitectura cliente-servidor es la arquitectura de sistema distribuido más común que descompone el sistema en dos subsistemas principales o procesos lógicos:
Client - Este es el primer proceso que envía una solicitud al segundo proceso, es decir, el servidor.
Server - Este es el segundo proceso que recibe la solicitud, la ejecuta y envía una respuesta al cliente.
En esta arquitectura, la aplicación se modela como un conjunto de servicios que son proporcionados por 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, y la asignación de procesadores a procesos no es necesariamente 1: 1
La arquitectura cliente-servidor se puede clasificar en dos modelos según la funcionalidad del cliente:
Modelo de cliente ligero
En el modelo de cliente ligero, todo el procesamiento de la aplicación y la gestión de datos lo realiza el servidor. El cliente es simplemente responsable de ejecutar el software de presentación.
Se utiliza cuando los sistemas heredados se migran a arquitecturas de servidor cliente en las que el sistema heredado actúa como un servidor por derecho propio con una interfaz gráfica implementada en un cliente.
Una desventaja importante es que coloca una gran carga de procesamiento tanto en el servidor como en la red.
Modelo de cliente grueso / gordo
En el modelo de cliente pesado, el servidor solo se encarga de la gestión de datos. El software del cliente implementa la lógica de la aplicación y las interacciones con el usuario del sistema.
Más apropiado para nuevos sistemas C / S donde las capacidades del sistema cliente se conocen de antemano
Más complejo que un modelo de cliente ligero, especialmente para la gestión. Se deben instalar nuevas versiones de la aplicación en todos los clientes.
Ventajas
Separación de responsabilidades como la presentación de la interfaz de usuario y el procesamiento de la lógica empresarial.
Reutilización de los componentes del servidor y potencial de simultaneidad
Simplifica el diseño y desarrollo de aplicaciones distribuidas
Facilita la migración o integración de aplicaciones existentes en un entorno distribuido.
También hace un uso eficaz de los recursos cuando una gran cantidad de clientes acceden a un servidor de alto rendimiento.
Desventajas
Falta de infraestructura heterogénea para hacer frente a los cambios de requisitos.
Complicaciones de seguridad.
Disponibilidad y confiabilidad limitadas del servidor.
Capacidad de prueba y escalabilidad limitadas.
Clientes gordos con presentación y lógica de negocios juntas.
Arquitectura de varios niveles (arquitectura de n niveles)
La arquitectura de varios niveles es una arquitectura cliente-servidor en la que las funciones como la presentación, el procesamiento de aplicaciones y la gestión de datos están separadas físicamente. Al separar una aplicación en niveles, los desarrolladores obtienen la opción de cambiar o agregar una capa específica, en lugar de reelaborar toda la aplicación. Proporciona un modelo mediante el cual los desarrolladores pueden crear aplicaciones flexibles y reutilizables.
El uso más generalizado de la arquitectura de varios niveles es la arquitectura de tres niveles. Una arquitectura de tres niveles generalmente se compone de un nivel de presentación, un nivel de aplicación y un nivel de almacenamiento de datos y puede ejecutarse en un procesador separado.
Nivel de presentación
La capa de presentación es el nivel superior de la aplicación mediante el cual los usuarios pueden acceder directamente, como una página web o una GUI (interfaz gráfica de usuario) del sistema operativo. La función principal de esta capa es traducir las tareas y los resultados a algo que el usuario pueda comprender. Se comunica con otros niveles para que coloque los resultados en el nivel de navegador / cliente y en todos los demás niveles de la red.
Nivel de aplicación (lógica empresarial, nivel lógico o nivel medio)
El nivel de aplicación coordina la aplicación, procesa los comandos, toma decisiones lógicas, evalúa y realiza cálculos. Controla la funcionalidad de una aplicación realizando un procesamiento detallado. También mueve y procesa datos entre las dos capas circundantes.
Nivel de datos
En esta capa, la información se almacena y se recupera de la base de datos o del sistema de archivos. Luego, la información se devuelve para su procesamiento y luego al usuario. Incluye los mecanismos de persistencia de datos (servidores de bases de datos, archivos compartidos, etc.) y proporciona API (Interfaz de programación de aplicaciones) al nivel de la aplicación que proporciona métodos para administrar los datos almacenados.
Advantages
Mejor rendimiento que un enfoque de cliente ligero y es más sencillo de administrar que un enfoque de cliente pesado.
Mejora la reutilización y la escalabilidad: a medida que aumentan las demandas, se pueden agregar servidores adicionales.
Proporciona compatibilidad con subprocesos múltiples y también reduce el tráfico de red.
Proporciona facilidad de mantenimiento y flexibilidad
Disadvantages
Probabilidad insatisfactoria debido a la falta de herramientas de prueba.
Más fiabilidad y disponibilidad del servidor.
Estilo arquitectónico del corredor
Broker Architectural Style es una arquitectura de middleware utilizada en computación distribuida para coordinar y habilitar la comunicación entre servidores y clientes registrados. Aquí, la comunicación de objetos se lleva a cabo a través de un sistema de middleware llamado intermediario de solicitud de objetos (bus de software).
El cliente y el servidor no interactúan entre sí directamente. El cliente y el servidor tienen una conexión directa a su proxy que se comunica con el mediador-corredor.
Un servidor proporciona servicios mediante el registro y la publicación de sus interfaces con el corredor y los clientes pueden solicitar los servicios del corredor de forma estática o dinámica mediante búsqueda.
CORBA (Common Object Request Broker Architecture) es un buen ejemplo de implementación de la arquitectura de intermediario.
Componentes del estilo arquitectónico del corredor
Los componentes del estilo arquitectónico del corredor se analizan a través de los siguientes encabezados:
Broker
El corredor es responsable de coordinar la comunicación, como reenviar y enviar los resultados y las excepciones. Puede ser un servicio orientado a la invocación, un documento o un intermediario orientado a mensajes al que los clientes envían un mensaje.
Es responsable de gestionar las solicitudes de servicio, ubicar un servidor adecuado, transmitir solicitudes y enviar respuestas a los clientes.
Conserva la información de registro de los servidores, incluida su funcionalidad y servicios, así como la información de ubicación.
Proporciona API para que los clientes las soliciten, los servidores respondan, registren o cancelen el registro de componentes del servidor, transfieran mensajes y localicen servidores.
Stub
Los stubs se generan en el momento de la compilación estática y luego se implementan en el lado del cliente, que se utiliza como proxy para el cliente. El proxy del lado del cliente actúa como mediador entre el cliente y el corredor y proporciona transparencia adicional entre ellos y el cliente; un objeto remoto aparece como uno local.
El proxy oculta el IPC (comunicación entre procesos) a nivel de protocolo y realiza la clasificación de los valores de los parámetros y la eliminación de la clasificación de los resultados del servidor.
Skeleton
El esqueleto se genera mediante la compilación de la interfaz de servicio y luego se implementa en el lado del servidor, que se utiliza como proxy para el servidor. El proxy del lado del servidor encapsula las funciones de red específicas del sistema de bajo nivel y proporciona API de alto nivel para mediar entre el servidor y el intermediario.
Recibe las solicitudes, descomprime las solicitudes, descompone los argumentos del método, llama al servicio adecuado y también clasifica el resultado antes de devolverlo al cliente.
Bridge
Un puente puede conectar dos redes diferentes basadas en diferentes protocolos de comunicación. Actúa como mediador de diferentes corredores, incluidos DCOM, .NET remoto y corredores Java CORBA.
Los puentes son un componente opcional, que oculta los detalles de implementación cuando dos intermediarios interoperan y toman solicitudes y parámetros en un formato y los traducen a otro formato.
Broker implementation in CORBA
CORBA es un estándar internacional para Object Request Broker, un middleware para administrar las comunicaciones entre objetos distribuidos definidos por OMG (grupo de administración de objetos).
Arquitectura orientada a servicios (SOA)
Un servicio es un componente de la funcionalidad empresarial que está bien definido, es autónomo, independiente, está publicado y está disponible para su uso a través de una interfaz de programación estándar. Las conexiones entre servicios se llevan a cabo mediante protocolos orientados a mensajes comunes y universales, como el protocolo de servicio web SOAP, que puede entregar solicitudes y respuestas entre servicios de manera flexible.
La arquitectura orientada a servicios es un diseño de cliente / servidor que admite un enfoque de TI impulsado por el negocio en el que una aplicación consta de servicios de software y consumidores de servicios de software (también conocidos como clientes o solicitantes de servicios).
Características de SOA
Una arquitectura orientada a servicios proporciona las siguientes características:
Distributed Deployment - Exponga los datos empresariales y la lógica empresarial como unidades de funcionalidad sin estado, poco estrictas, acopladas, detectables, estructuradas, basadas en estándares, de grano grueso, llamadas servicios.
Composability - Ensamblar nuevos procesos a partir de servicios existentes que se exponen con la granularidad deseada a través de interfaces de quejas estándar, bien definidas y publicadas.
Interoperability - Comparta capacidades y reutilice servicios compartidos en una red independientemente de los protocolos subyacentes o la tecnología de implementación.
Reusability - Elija un proveedor de servicios y acceda a los recursos existentes expuestos como servicios.
Operación SOA
La siguiente figura ilustra cómo funciona SOA:
Advantages
El acoplamiento flexible de la orientación al servicio proporciona una gran flexibilidad para que las empresas hagan uso de todos los recursos de servicio disponibles, independientemente de las restricciones de plataforma y tecnología.
Cada componente de servicio es independiente de otros servicios debido a la característica de servicio sin estado.
La implementación de un servicio no afectará la aplicación del servicio mientras no se cambie la interfaz expuesta.
Un cliente o cualquier servicio puede acceder a otros servicios independientemente de su plataforma, tecnología, proveedores o implementaciones de idioma.
Reutilización de activos y servicios ya que los clientes de un servicio solo necesitan conocer sus interfaces públicas, composición del servicio.
El desarrollo de aplicaciones comerciales basadas en SOA es mucho más eficiente en términos de tiempo y costo.
Mejora la escalabilidad y proporciona una conexión estándar entre sistemas.
Uso eficiente y eficaz de los 'Servicios comerciales'.
La integración se vuelve mucho más fácil y mejora la interoperabilidad intrínseca.
Resuma la complejidad para los desarrolladores y dinamice los procesos comerciales más cerca de los usuarios finales.