MAS (Morfeo Application Server)

Introducción

El contenedor de servicios MAS, define un modelo de desarrollo y despliegue de servicios independiente de la tecnología distribuida utilizada. De esta forma, permitiría que un servicio sea accesible desde distintas tecnologías de servicios distribuidos actuales, como WebService, CORBA, Java RMI o .Net.

El contar con este contenedor representa una ventaja frente a otros servidores de aplicaciones (como por ejemplo los contenedores J2EE) donde se deben cubrir todos los aspectos relativos a su arquitectura de referencia (un contenedor completamente conforme a J2EE cubre otros muchos aspectos). Este contenedor ligero puede tener gran aplicación no sólo para reducir el coste de instalar y administrar un servidor de aplicaciones completo (cuando en realidad sólo se piensa emplear las funcionalidades de soporte a la implementación de servicios que éste ofrece) sino que también puede ser utilizado en entornos empotrados, movilidad, etc.

El desarrollo de este contenedor implica participar activamente en los organismos relacionados con las tecnologías de Web Service, como son W3C, WS-i, OASIS y OMG.

Modelo de Servicios

Según la arquitectura SOA, un servicio es una función autocontenida y sin estado que acepta una o varias peticiones y devuelve una o varias respuestas a través de una interfaz de operaciones definida en un lenguaje determinado bien definido.

Aunque se ha adoptado WSDL como lenguaje de definición de servicios, la arquitectura SOA permite otros lenguajes de definición. Además, existen estándares para la conversión entre lenguajes de definición de interfaces. De esta forma, el modelo de desarrollo de MAS, permite implementar un servicios SOA, independientemente del lenguaje de definición de interfaces utilizado, y a su vez, que éste servicio sea accesible mediante distintas tecnologías distribuidas (Web Service, CORBA, RMI,.Net, …) automáticamente sin variar su implementación.

El patrón de desarrollo y despliegue de servicios seguido por el contenedor es el siguiente:

  • Definición IDL (Interface Definition Language) de la interfaz de servicio (WSDL, OMG IDL, JavaRMI, .Net C#, etc)
  • Compilación de la IDL generando stubs, skeletons, y definiciones en el lenguaje de programación determinado (como C++, Java, C#, etc.)
  • Implementación del servicio: desarrollo de una clase (Java o C#) que exporte las operaciones asociadas a las declaradas en la interfaz IDL o una clase que maneje dinámicamente las invocaciones de dichas operaciones.
  • Despliegue del servicio asociando al tipo de servicio (definido por la IDL) la correspondiente implementación, el puerto de servicio y las tecnologías utilizadas.

Hay que remarcar, que con este planteamiento un servicio se implementa una vez, y automáticamente, en tiempo de despliegue, se puede configurar para qué tecnologías es accesible.

Arquitectura

Para garantiza la independencia entre implementación de servicio y tecnología utilizada, se ha diseñado una arquitectura de contenedor estructurada en niveles:

  • Nivel de servicio: alberga los objetos que implementan las funcionalidades de servicio
  • Núcleo del contenedor: gestiona mediante un modelo abstracto el envío y recepción de mensajes, y proporciona los recursos necesarios para localización de servicios y la atención de peticiones (colas de peticiones, pool de threads, etc.)
  • Nivel de protocolo: se encarga de dirigir el intercambio de mensajes siguiendo un protocolo determinado y traducirlos al formato del núcleo de contenedor

A nivel de protocolo, el contenedor se ha diseñado definiendo una arquitectura extensible de capas de comunicaciones (plugins) que permitan aceptar distintos tipos protocolos de comunicaciones (SOAP/HTTP, IIOP, RMI/IIOP. Net, etc). Así mismo, a nivel de servicio, aunque el contenedor define un modelo de implementación de servicios, existe la posibilidad de desplegar implementaciones de servicio asociadas a una tecnología particular (CORBA, EJB, etc.).

El desarrollo de MAS, se ha realizado tomando como base el contenedor CORBA TIDorb. Ya existen experiencias para utilizar un ORB como base para desarrollar servidores de aplicaciones, por ejemplo, contenedores de EJBs. Esto es así gracias a que un ORB no es sólo una librería que implementa un protocolo de comunicaciones como es IIOP, sino que es un completo entorno de ejecución, que puede controlar aspectos como encolado y atención de peticiones, gestión racional de recursos del sistema como threads o memoria, etc.

Actualmente, existen productos que permiten el despliegue de servicios siguiendo el paradigma particular de desarrollo impuesto por cada tecnología, pero existe un notable problema de integración entre distintas tecnologías.

Por tanto, el contenedor para garantizar la integración de estas tecnologías:

  • Debe contar con una serie de herramientas que permitan traducir definiciones en un IDL determinado a otros (por ejemplo de WSDL a IDL)
  • Cada capa de comunicaciones debe ser capaz de traducir mensajes y datos a los distintos formatos asociados a cada tecnología

Líneas de evolución

Actualmente, se encuentra liberada la versión 0.2 de MAS para Java, que cuenta con soporte para tecnologías Web Service (WSDL 1.0) y CORBA 2.6, utilizando los siguientes protocolos:

  • SOAP/HTML (SOAP 1.1 y 1.2)
  • IIOP

Junto al contenedor se ha desarrollado la herramienta AsGen para el despliegue de servicios y el compilador de WSDL a IDL TIDWsdlc.

Como líneas futuras se plantea:

  • Desarrollo de plugin para Eclipse para el desarrollo y despliegue de servicios
  • Interfaz Web de administración del contenedor basada en la especificación JMX
  • Portado a C#
  • Soporte a WSDL 2.0
  • Capa de comunicaciones SOAP/MoM

Proyectos relacionados

Herramientas WS

En el contexto de esta línea de trabajo, se abordará todo lo relativo a la caracterización de Web Services y de relaciones entre Web Services mediante ontologías. Dentro de la caracterización de las relaciones entre Web Services se contemplará la especificación (en lenguaje BPEL4WS o similar) de la lógica de orquestación de servicios que permite hacer uso combinado de varios Web Services para un mismo fin, por ejemplo, la reserva de un billete ida y vuelta en avión hacia un determinado destino con la reserva de alojamiento las noches intermedias en un hotel situado en destino.

Se desarrollarán herramientas que permitan especificar la información semántica asociada a páginas web que incorporen datos que puedan traducirse en la invocación de Web Services por parte del usuario final.

También se abordará el desarrollo de herramientas de búsqueda basadas en ontologías. Se seleccionará un buscador ya existente y se definirá una interfaz estándar basada en Web Services para la invocación de búsquedas.

Por último, se desarrollará una serie de de plug-ins de navegación que, por un lado, fueran capaces de detectar e interpretar información semántica asociada a Web Services en las páginas accedidas y, por otro lado, fueran capaces de orquestar desde el navegador la lógica de orquestación de Web Services relacionados.

Esto último implica desarrollar un plug-in capaz de interpretar y ejecutar lógica de orquestación basada en un lenguaje como pueda ser BPEL4WS desde el navegador del usuario final.