SOA (Service Oriented Architecture) es un término que puede tener varios significados para diferentes audiencias. Podemos encontrar muchos artículos que describen la ambigüedad de los términos, la necesidad de separar SOA de sus implementaciones y varios debates recurrentes sobre estos temas. Según Jason Bloomberg, tenemos que hacer una clara distinción entre SOA y las especificaciones de Servicios Web - a veces se confunden. SOA es una arquitectura de computación distribuida que trata al software como servicios disponibles a través de la red, mientras que la especificación de servicios Web define una plataforma interoperable que ofrece soporte para SOA. En ese sentido, este artículo se describe un nuevo enfoque para la implementación de SOA a través de la prestación de servicios Jini y JavaSpaces.
Arquitectura orientada a servicios
En términos generales, podemos decir que SOA es una arquitectura para computación distribuida que trata al software como servicios disponibles a través de la red. SOA no es completamente nuevo, CORBA y DCOM son ejemplos de orientación a servicios. Algunos aspectos de la arquitectura orientada a servicios se han utilizado durante bastante tiempo. Por ejemplo, las empresas utilizan la tecnología de intercambio de mensajes durante décadas para integrar aplicaciones. Se podría decir que SOA es una arquitectura de sistemas distribuidos que se caracteriza por las siguientes propiedades:
- Visión Lógica: El servicio es una visión abstracta y lógica de los programas, bases de datos, procesos de negocio, entre otros, definido en términos de lo que hace, normalmente ejecutando una operación de negocio.
- Orientación al mensaje: el servicio es formalmente definido en términos de los mensajes intercambiados entre los proveedores y los consumidores. La estructura interna y la implementación son ajenos a propósito. Usando SOA, un usuario no puede y no necesitaría saber
los detalles de la implementación de un servicio. - Orientación a la descripción: un servicio es descrito por meta-datos procesables por máquinas. Sólo los detalles expuestos al público que son importantes para utilizar el servicio deben ser descritos. La semántica del servicio debe ser documentada, directa o indirectamente, por su descripción.
- Granularidad: los servicios tienden a utilizar un número reducido de operaciones con una complejidad relativamente grande en las operaciones llevadas a cabo.
- Orientación a la red: se pueden utilizar los servicios a través de una red, pero no es obligatorio.
- Neutralidad de la plataforma: los mensajes se envían en un formato normalizado independiente de la plataforma a través de las interfaces. XML es el formato más obvio que atiende a esa restricción.
SOA con Jini y JavaSpaces
Espacio de tupla es un paradigma de computación distribuida propuesto por David Gelernter a mediados de los años 80 basado en el concepto de DSM (Memoria compartida distribuida). En este modelo, el espacio de tupla se describe como una abstracción de un entorno informático basado en el concepto de una única memoria virtual compartida, responsable por el almacenamiento de las tuplas a ser procesadas. La principal característica del espacio de tupla es el desacoplamiento entre los procesos. Cuando dos procesos necesitan comunicarse, ellos no intercambian mensajes o comparten variables, en vez de eso, el proceso productor agrega una tupla en el espacio y el proceso consumidor consume la tupla del espacio. Varios años después de proponer el modelo basado en el espacio de tupla, Sun Microsystems lanzó JavaSpaces. La especificación de JavaSpaces fue creada como parte del proyecto Jini. A diferencia de los tradicionales modelos de programación distribuida basados en un intercambio de mensajes, el modelo JavaSpaces utiliza una colección de procesos que cooperan a través de los flujos de objetos que son insertados o retirados de una o más espacios de tupla. Así como la especificación original del modelo basado en el espacio de tupla, los procesos en JavaSpaces interactuan con el espacio a través de cuatro operaciones simples: write(), inserta objetos en el espacio; take(), recupera objetos desde el espacio, read(), lee objetos en el espacio, sin eliminarlo. Además, la especificación JavaSpaces implementa un modelo de eventos basado en la notificación, a través de la operación notify(). Una implementación comercial cuyo middleware se basa en JavaSpaces es el servidor de aplicaciones Gigaspaces XAP. Su arquitectura basada en espacios de tupla está totalmente orientada a servicios. Un cliente que ejecute en diferentes plataformas puede acceder al espacio de tuplas directamente a través de las operaciones descritas anteriormente o servicios bien definidos. En este caso, la plataforma Gigaspaces se encarga de transformar las llamadas en tuplas de una manera transparente.
Jini ™ es una tecnología con una arquitectura orientada a servicios que define un modelo de programación que explora y extiende la tecnología Java ™ para permitir la construcción de sistemas distribuidos seguros, que consiste de federaciones de redes de servicios bien definidas y clientes. La tecnología Jini se puede utilizar para construir sistemas de red adaptables, flexibles y escalables, que pueden ser gradualmente evolucionados, soportando los requisitos de entornos informáticos dinámicos. Un aspecto importante de Jini es el entendimiento de que, inevitablemente, habrá algunas fallas en la red, o en clientes, o incluso en los servicios ofrecidos. Por definición, Jini proporciona portabilidad de plataforma, movilidad de código y seguridad. Puede ser utilizado en aplicaciones con acceso pleno al ambiente de ejecución de la plataforma JSE o dispositivos pequeños, sistemas empotrados e incluso en aplicaciones escritas en otros lenguajes. Contrariamente a la propaganda hecha por Sun Microsystems hace unos años, Jini va mucho más allá de hacer que aplicaciones para refrigeradores y tostadores intercambien información.
Jini y JavaSpaces se han utilizado en varios proyectos de gran escala. La conjunción de estas dos tecnologías soporta las características de la arquitectura SOA descriptas anteriormente de la siguiente manera:
- Visión lógica: en Jini, el contrato entre el consumidor y el proveedor de un servicio se garantiza a través de una interfaz Java bien determinada. Una interfaz puede representar una base de datos, un dispositivo cualquiera o abstraer del acceso a otros servicios.
- Orientación al mensaje y descripción: un servicio abstrae completamente su implementación. Una implementación de un servicio puede ser un script, un Web Service, un servidor de aplicaciones JEE o un simple POJO. Mientras tanto, los servicios tienen una interface Java que los define y atributos que pueden utilizarse para la descripción de sus funcionalidades y características y búsqueda. Es posible que en una red existan varias implementaciones del mismo servicio, sin embargo, con caracteristicas completamente diferentes.
- Granularidad: los servicios pueden ser implementados de muchas diferentes formas, desde una simple POJO que será ejecutado en la JVM
del cliente como un proxy que permite acceder a un EJB. La complejidad y el flujo de la información no están pre-definidas por la tecnología, sino más bien son determinados por el proyecto. - Orientación a la red: Jini fue diseñado para trabajar bien en un entorno crítico, sujeto a fallas y lentitud: las redes de computadoras. Además, los servicios como soporte a transacción, activación y el intercambio de mensajes que son la base para la mayoría de las aplicaciones también están sujetos a fallas y eso está previsto en la arquitectura y el diseño de Jini.
- Neutralidad de Plataforma: Jini realmente no define ningún protocolo específico para el intercambio de mensajes entre clientes y proveedores de servicios. SOAP, raw XML, sockets entre otros pueden sernaturalmente utilizados.
Al igual que con Web Services, paa que un cliente haga uso del servicio, debe primero hacer una búsqueda usando uno o más servicios de
búsqueda que forman parte de la tecnología. Sin embargo, a diferencia de los web Services, el cliente puede, en tiempo de ejecución, hacer un "download" automático del servicio en la máquina virtual y ejecutarlo localmente o utilizar un proxy para un servicio que se ejecutará en otra máquina virtual.
