Tema 16 Arquitectura cliente/servidor. Modelo de 2 capas. Modelo de 3 capas. Componentes y operación. Arquitectura Web.

Introducción al procesamiento cooperativo.

Sistemas distribuidos y procesamiento cooperativo

La arquitectura cliente/servidor. Tipología, componentes e Interoperabilidad.

La arquitectura cliente/servidor

Introducción al concepto de SOA (Service Oriented Architecture).

Arquitectura SOA

Tecnología de Servicios Web (Web Services).

SOA y la arquitectura de servicios web

Introducción a las arquitecturas de computación: centralizada, distribuída, cliente / servidor, etc.

Introducción a la arquitectura SOA y descripción de la arquitectura de servicios web .

A través del siguiente enlace, puedes acceder a una descripción teórica sobre los fundamientos de la arquitectura orientada a servicio. SOA es un concepto arquitectónico abstracto. Es una aproximación para construir sistemas software basados en componentes débilmente acoplados (los servicios), que han sido descritos de un modo estandarizado y uniforme, y que pueden ser descubiertos e invocados.

Descripción de la arquitectura SOA

En este otro enlace se realiza una breve introducción sobre la implementación que la ha puesto en el candelero: la arquitectura de servicios web, basada en dos estándares W3C: SOAP y WSDL.

Arquitectura de Web Services

Algunos conceptos clave de la arquitectura de servicios web son:

  • WSDL (Web Service Definition Language). Lenguaje, basado en XML, que permite describir semánticamente un servicio web: mensajes de petición, mensajes de respuesta, tipos y estructuras de datos empleados como parámetros y retorno.
  • SOAP (Simple Object Access Protocol). Protocolo de intercambio de mensajes de petición y respuesta, basado en XML, entre proveedores de servicio y clientes consumidores de servicios. Tanto WSDL como SOAP son estándares aprobados por el W3C Consortium. organismo de estandarización en materia del web.
  • UDDI (Universal Description Discovery and Integration). Es un estándar basado en XML para el registro y descubrimiento de servicios web a partir de su metainformación. Aunque UDDI inicialmente fue propuesto para formar parte de la pila de estándares de servicios web, no pasó a ser estándar del W3C. Actualmente es una iniciativa abierta patrocinada por OASIS.
  • OASIS es un consorcio internacional que dirije y coordina el desarrollo de estándares relacionados con el comercio electrónico y los servicios web. OASIS, en sus orígenes, se denominaba OpenSGML y se centraba en el desarrollo de estándares basados en SGML. Con la irrupción de XML, centró su atención en esta tecnología siendo el impulsor de algunos estándares de gran aceptación:
  • ebXML, familia de estándares básados en XML para el comercio electrónico.
    • formato Open Document para aplicaciones ofimáticas.
    • protocolo SAML para el intercambio de tokens de seguridad entre aplicaciones autenticadas.
    • UDDI.

De los estándares impulsados por OASIS, caben destacar los citados a continuación, que han sido aprobados por ISO como el estándar ISO 15000 "Lenguaje de marca extensible para el comercio electrónico":

  • ISO 15000-1: ebXML Collaborative Partner Profile Agreement
  • ISO 15000-2: ebXML Messaging Service Specification
  • ISO 15000-3: ebXML Registry Information Model
  • ISO 15000-4: ebXML Registry Services Specification
  • ISO 15000-5: ebXML Core Components Technical Specification, Version 2.01.

Aproximación REST a la arquitectura orientada a servicio.

Por REST (Representational State Transfer) se conoce a una arquitectura para el desarrollo de servicios web basada en el intercambio de mensajes HTTP empleando estructuras de datos XML, sin la semántica adicional de mensaje (también basada en XML) de protocolos como SOAP.

REST afirma que la web ha disfrutado de escalabilidad como resultado de una serie de diseños fundamentales clave:

  • Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la información necesaria para comprender la petición. Como resultado, ni el cliente ni el servidor necesitan recordar ningún estado de las comunicaciones entre mensajes. Sin embargo, en la práctica, muchas aplicaciones basadas en HTTP utilizan cookies y otros mecanismos para mantener el estado de la sesión (algunas de estas prácticas, como la reescritura de URLs, no son permitidas por REST)
  • Un conjunto de operaciones bien definidas que se aplican a todos los recursos de información: HTTP en sí define un conjunto pequeño de operaciones, las más importantes son POST, GET, PUT y DELETE. Con frecuencia estas operaciones se equiparan a las operaciones CRUD que se requieren para la persistencia de datos, aunque POST no encaja exactamente en este esquema.
  • Una sintaxis universal para identificar los recursos. En un sistema REST, cada recurso es direccionable únicamente a través de su URI

Es posible navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin requerir el uso de registros u otra infraestructura adicional.

Arquitectura de mashups o clientes embebibles: hacia la reutilización de la GUI en web.

Un paso más allá de reutilización, orientado a servicio, lo introduce el concepto de mashup, o aplicación web híbrida: sitio web o aplicación web que usa contenido de otras aplicaciones Web para crear un nuevo contenido completo, consumiendo servicios directamente siempre a través de protocolo http. El contenido usado en mashups es típicamente obtenido de otra fuente vía una interface pública o API (web services).

La arquitectura de los mashups está siempre compuesta de tres partes:

  • El proveedor de contenidos: fuente de los datos. Los datos están disponibles vía una API y diferentes protocolos web como RSS, REST y Web Service.
  • El sitio mashup: es la nueva aplicación web que provee un nuevo servicio utilizando diferente información y de la que no es dueña.
  • El navegador cliente: es la interface de usuario del mashup.

La difusión de aplicaciones mashup se ha visto favorecida gracias a la aparición de tecnologías conocidas como Web 2.0 (AJAX y Reverse AJAX o COMMET)

Bus de Servicios Empresariales.

Una arquitectura orientada a los servicios (SOA) es un método para construir una infraestructura de TI a partir de componentes acoplados de manera fl exible, denominados “servicios”, que desempeñan funciones específi cas. Las aplicaciones compuestas son un elemento clave de un entorno SOA. Estas aplicaciones se crean invocando y orquestando múltiples servicios, eventos y modelos de tal manera que colectivamente desempeñan una función empresarial de alto nivel. El principal problema es cómo resolver la escalabilidad de las conexiones punto a punto, lo que se conoce también como el “problema de conexión M*N”. Si tenemos múltiples aplicaciones orientadas a servicio, a la hora de diseñar como consumir los servicios unas de otras (siendo el número de combinaciones punto a punto exponencial), el problema se simplifica si todas las aplicaciones se conectan a un punto único y central de conexión: el bus de servicios empresariales.

ESB.PNG

De este modo, el bus sustituye toda comunicación directa entre dos aplicaciones, de forma que las comunicaciones entre las aplicaciones para consumir sus servicios se hace a través del bus. El bus, además de una arquitectura, es un sistema software de tipo middleware, que recibe peticiones de las aplicaciones clientes y, normalmente basándose en un sistema de mensajería y colas las reenvía a las aplicaciones proveedor de servicio.

Las soluciones ESB comerciales pueden seguir aproximaciones propietarias (normalmente las que han seguido sistemas de mensajería o EMQ como Tibco) o basarse en los estándares web del W3C: WS-*.

Referencias externas.

SOA en la wikipedia inglesa

| Bus de Servicios Empresariales en la wikipedia inglesa

"El papel de un bus de servicios empresariales en una arquitectura SOA. TIBCO Iberia"

Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License