Modelos de Arquitectura de Software: Cliente/Servidor vs. SOA

Modelo Cliente/Servidor

Se establece sobre el paradigma de paso de mensajes.

Roles:

• Servidor
• Cliente

Requisitos:

• Mecanismos de concurrencia.
• Mantenimiento de la sesión.
• Mecanismos de escalabilidad.

Utilizado por la mayoría de protocolos de Internet (HTTP, DNS, FTP, SMTP, etc.).

Presenta un esfuerzo de implementación elevado.

Modelo SOA (Arquitectura Orientada a Servicios)

Este modelo presenta la gestión de recursos de un sistema distribuido como servicios de red que son publicados y descubiertos por los procesos clientes para su consumo (aplicaciones, ficheros, bases de datos, servidores, sistemas de información, dispositivos).

Elementos

• Proveedor: Se encarga de publicar la información en el servicio de directorio que permite localizar el servicio y acceder a él.
• Consumidor: Se conecta al servicio de directorio para localizar el servicio que ofrezca la funcionalidad que requiere y obtiene la información necesaria (descubrimiento) para acceder a un servicio concreto.
• Servicio de directorio (intermediario): Almacena la información necesaria sobre los servicios.

Principios

• Localización, descubrimiento, publicación: Existe la necesidad imprescindible de que nuestro Catálogo de Servicios SOA esté disponible, publicado, accesible e informado con una serie de metadatos que permitan lanzar búsquedas ricas para identificar los servicios que podamos reutilizar.
• Interoperabilidad: Todos los sistemas que participan en los procesos interpretan la información de la misma manera.
• Composición: Permiten, sin gran esfuerzo, diseñar aplicaciones complejas a partir de la composición de servicios heterogéneos.
• Autonomía y autocontención: Un servicio no puede contener lógica que dependa de nada externo al propio servicio, ya sea un modelo de datos, un sistema de información o cualquier otra cosa.
• Reusabilidad: Se fomenta la reutilización en todos los servicios, independientemente de si existen requisitos inmediatos para la reutilización. De esta forma, aumentan las posibilidades de, en un futuro, poder acomodar los requisitos con menos esfuerzos.
• Desacoplamiento: Se requiere que los servicios, a pesar de adquirir conocimientos entre ellos, sean absolutamente independientes entre sí; de esta manera, pueden hacer su trabajo completamente sin recurrir al otro.
• Contrato bien definido: Debe haber un contrato de servicio en el que se definan las partes básicas de una SOA. Estos proporcionan información semántica que explica cómo un servicio puede lograr una tarea específica. Esta información establece el acuerdo hecho por un proveedor de servicios y los solicitantes de servicio.
• Sin estado: Los servicios SOA no deben guardar información alguna sobre datos de sesión, ni sobre eventos previos, ni sobre resultados de servicios invocados previamente.