MHProject v2.0

El consorcio de empresas maat Media (maat Gknowledge, HyC, SDI-Digital y Multicanal del Cable), junto con las universidades Politécnica de Madrid y Jaume I de Castelló, presentan el 31 de Marzo el proyecto tractor IDE-MHP, consistente en un entorno de desarrollo que permite diseñar páginas web para su posterior visionado en Televisión Digital Interactiva.

Mediante dicho sistema, el desarrollo de aplicaciones MHP se ‘democratiza’ y se podrá empezar a ver aplicaciones desarrolladas por usuarios finales a través de plataformas de gestión de contenidos como, por ejemplo: blogs y redes sociales. Esto se consigue al abstraer por completo la complejidad técnológica que supone el standard MHP y permitir que, cualquier usuario con escasos conocimientos en HTML pueda desarrollar una aplicación para TvDi.

Dicho esto, vamos a pasar a ver un poco más en detalle cual es la arquitectura que se esconde detrás de este proyecto:

[Mas:]

Diseño de la arquitectura

Arquitectura general

El proceso de construcción de una aplicación MHP partiendo de un conjunto de páginas HTML conlleva el estudio y profundización en diferentes tecnologías cuyas arquitecturas fueron concebidas de maneras muy diferentes.

La Web
tiene una arquitectura cliente-servidor, donde la información se encuentra distribuida en diferentes servidores a los que los clientes acceden para recuperarla y visualizarla en sus terminales. En todo momento existe una comunicación bidireccional, lo que permite un procesamiento de datos de índole colaborativo y cooperativo.

Por su parte la interactividad en televisión digital a través del estándar MHP esta orientada a una arquitectura de difusión unidireccional. En este caso, la información que se transmite hasta los clientes se selecciona desde el punto de emisión y son los clientes los que seleccionan que información de la que tienen disponible quieren visualizar. En algunos casos los descodificadores MHP poseen canal de retorno que permite una personalización de los servicios a través de una comunicación bidireccional en una arquitectura cliente-servidor.

Debido a las diferencias existentes entre las arquitecturas de las tecnologías implicadas, se decidió optar por una arquitectura de difusión unidireccional con posibilidad de personalización de los servicios mediante una comunicación bidireccional a través de Internet. Como se puede apreciar en el gráfico inferior, en esta arquitectura se selecciona un conjunto de páginas HTML almacenadas en un servidor y que conforman el portal que se quiere difundir, estas páginas HTML tras un proceso de transformación se mapean en pantallas de una aplicación MHP que mantienen la misma navegabilidad y aspecto que la que poseen las páginas HTML originales. Estas pantallas se emiten unidireccionalmente hasta los hogares desde donde se visualiza el portal seleccionado.

La elección de esta arquitectura de difusión unidireccional permite asegurar la visualización del servicio en emisión por parte de los usuarios finales independientemente del decodificador MHP que dispongan, frente a otras arquitecturas planteadas cliente-servidor que exigieran a los usuarios disponer de canal de retorno conectado a Internet en el decodificador, desde donde se realizaran las peticiones a los servidores en Internet y posteriormente mostrar la información en la pantalla de la televisión.

Arquitectura del conversor HMTL – MHP

Arquitectura del conversor HTML – XHTML

La arquitectura del conversor HTML a XHTML consta solo del elemento conversor cuya entrada es el fichero HTML origen y su salida es un fichero equivalente al fichero original pero que cumple los requisitos del estándar XHTML. Esto garantiza:

• Los documentos XHTML se establecen en base a las reglas XML. Por tanto, pueden ser visualizados, editados y validados por cualquier herramienta estándar XML.
  
  
• Los documentos XHTML pueden contener aplicaciones (por ejemplo applets o scripts) que se basen en DOM y que modifiquen la propia estructura del documento XHTML.
  
  
• Permite insertar en el documento XHTML nuestras propias marcas que no tienen por qué estar definidas en el estándar general. Esto es lo que se llama modularización XHTML.
  
  

Arquitectura del conversor XHTML - MHP

El conversor XHTML-MHP debe ser capaz de generar una aplicación MHP partiendo de un conjunto de ficheros HTML, para conseguir esto se ha creado una arquitectura de conversor como la que se aprecia en el gráfico de esta sección. Los componentes de esta arquitectura son los siguientes:

• Páginas Web : Conjunto de páginas que compondrán la aplicación a transformar en MHP para ser ejecutada en un Set Top Box (STB), de tal forma que el usuario que esté visualizando el canal asociado a dicha aplicación interactiva, pueda visualizarla y ejecutar las acciones pertinentes sobre ella. Dichas páginas estarán codificadas siguiendo la especificación XHTML, esto es importante ya que vamos a trabajar no sobre HTML sino sobre XHTML con el objeto de acercarnos más a XML y evitar la ambigüedad que HTML tiene en alguna de sus etiquetas. XHTML es mucho más estricto y nos permitirá definir con más claridad la entrada a nuestra aplicación. Esta especificación definirá con claridad la familia de etiquetas soportadas por el microbrowser que se ejecutará en el STB. Finalmente otro de los atractivos de utilizar XHTML es la posibilidad de utilizar elementos como RDF en las etiquetas, que abre la puerta de la solución presentada hacia los conceptos de la web semántica. Este conjunto de páginas Web o aplicaciones Web vendrán dados por una serie de ejemplos prácticos, sobre los que nos apoyaremos para llevar a cabo la funcionalidad de este microbrowser.
• Parseador XHTML: Este componente sirve como entrada al sistema de todos los ficheros XHTML del microsite que se va a migrar. Una vez que los ficheros HTML entran al sistema el parseador realiza las correspondientes validaciones con el fin de comprobar que los XHTML estén correctamente formados. Tras comprobar que los documentos están bien formados la funcionalidad de este componente es la de extraer de los atributos y elementos del XHTML toda la información de la página (colores, posiciones, tipos de elementos, textos…) para posteriormente generar pantallas MHP con la misma funcionalidad y aspecto que las que tenían las páginas HTML originales. Una vez que el parseador ha extraido toda la información de la página HTML es cuando debe convertir los elementos HTML extraidos a elementos MHP para lo cual se hace uso de la librería gráfica de componente Havi perteneciente al estandar MHP, cada elemento HTML se convierte en un componente Havi y los atributos de los elementos HTML modifican los atributos de los distintos componentes con el fin de darle el mismo aspecto visual tanto a los contenidos HTML como a la aplicación MHP.
  
  
• Diccionario HTML: El diccionario es uno de los componentes más importantes de la arquitectura ya que permite que la traducción de componentes HTML a componentes MHP sea correcta y por tanto el resultado visual obtenido sea idéntico. La funcionalidad del diccionario se puede dividir en tres grandes bloques:
  
  
• Gestión Elementos HTML: Debe existir una relación uno a uno entre todos los posibles elementos HTML de entrada y las clase HAVI de manera que cada elemento de la página Web tenga su análogo en la pantalla MHP. Existen ciertas condiciones en los que los componentes  HTML no tienen su equivalente en componentes HAVI, por lo que se hace necesario la creación de nuevos componentes extendiendo de los componentes HAVI. Un ejemplo de esta funcionalidad sería la de relacionar un elemento <p> HTML con un componente HText de la librería HAVI.
  
  
• Manejo de atributos HTML: En la funcionalidad anterior se relaciona un elemento HTML con un componente HAVI, sin embargo para que el aspecto visual entre aplicaciones sea el mismo, no es suficiente con esta relación. Para ello se deben analizar los atributos y valores de estos elementos HTML para plasmar la misma información en la aplicación MHP. En este sentido se deben definir las relaciones entre los atributos que condicionan el aspecto del elemento HTML y los métodos del componente HAVI que permiten modificar el aspecto y contenido del mismo. En este sentido y siguiendo con el ejemplo anterior del elemento párrafo (<p>), si el color del párrafo lo queremos poner en rojo deberemos relacionar el atributo color con el método de cambio de color de texto del propio componente HAVI.
  
  
• Clases Java: Estas clases son generadas por el parseador XHTML, para cada página HTML se genera una clase, que representa una pantalla, y que contiene todos los componentes HAVI que han sido mapeados por el parseador. Por tanto para cada aplicación habrá un conjunto de clases java diferentes generadas por el parseador de acorde a las páginas HTML de entrada. Todas estas clases comparten un modelo común que permite tratarlas homogéneamente por el Runtime.
  
  
• Runtime: Una vez realizada la conversión de las páginas HTML a clases Java que a su vez contienen componentes HAVI, estos componentes y las pantallas que forman deben coordinarse dentro de una aplicación completa. El Runtime esta compuesto por un conjunto de clases comunes a todas las aplicaciones y hace las funciones del kernel de todas las aplicaciones interactivas, sus funcionalidades principales son:
  
  
• Inicializar la aplicación MHP: El Runtime se encarga de inicializar la aplicación en el momento en el que el Application Manager carga el Xlet en memoria. Es en ese momento donde el Runtime se encarga de cargar e inicializar todas aquellas estructuras que va a utilizar durante el ciclo de vida de la aplicación
• Controlar el ciclo de vida de la aplicación: Es necesario que se gestionen bien el cambio entre los diferentes estados del ciclo de vida del Xlet, guardando el estado y liberando los recursos necesarios para que otra aplicación pueda ejecutarse en caso de que la aplicación se deba pausar, o recuperando el estado anterior si la aplicación viene de un estado de pausa. Por último y en caso de que la aplicación se destruya el Runtime debe liberar todos los recursos del STB que ha utilizado durante el ciclo de vida de este.

• Gestionar el hardware compartido: Existen múltiples recursos hardware únicos que deben ser compartidos entre todas las aplicaciones que residen en el decodificador. El Runtime es el único responsable de la aplicación de reservar y usar estos recursos y liberarlos tras su utilización, esto permite que otras aplicaciones puedan utilizar ese recurso y evite que el Applicaction Manager pueda forzar la liberación de los recursos causando alguna inconsistencia en la aplicación.
• Manejar el canal de retorno: A pesar de no ser necesario la utilización del canal de retorno para la visualización de las páginas, si que las aplicaciones permiten la consulta y personalización de los servicios a través de votaciones, consultas de votaciones… Para ello el Runtime posee un módulo específico que gestiona el canal de retorno. Este módulo permite realizar peticiones HTTP a cualquier servidor, devolviendo a la aplicación el resultado obtenido de la petición. A parte de realizar peticiones HTTP a los diferentes servidores Web este módulo debe gestionar la reserva del recurso y configurarlo en función del tipo de canal de retorno que sea (telefónico, ethernet, GPRS…) y atender a los posibles fallos en la conexión y comunicación para solventarlos en caso necesario.
• Coordinación y navegación de las pantallas: Una de las funcionalidades de mayor importancia que debe realizar el Runtime es la de coordinar la navegación entre componentes dentro de una página, así como la navegación entre páginas. Para ello el Runtime maneja las clases Java generadas por el parser XHTML de una manera homogenea y transparente independientemente de los componentes de cada página, obligándoles a cumplir un interfaz de comunicación que facilitan todas estas labores.

Una vez descritos todos los componentes que forman parte de la arquitectura del conversor, pasamos a describir los procesos que se llevan a cabo en la arquitectura desde que entran los archivos HTML hasta que se obtiene la aplicación lista para emitirse por el aire. Para ello el primer paso que debemos tomar es el de seleccionar los ficheros HTML que van a servir de entrada al parseador XHTML y que definirán la aplicación resultante. Una vez que se comprueban que los ficheros HTML están bien formados y tienen estructura de XHTML estos ficheros son recogidos por el parseador XHTML que junto con el diccionario transforma para cada una de las páginas XHTML los elementos y atributos en clases Java con sus correspondientes componentes y las invocaciones necesarios a métodos de estos componentes para que el aspecto final sea el mismo. Una vez que las clases Java han sido generadas acorde a un interfaz común definido por el Runtime, se compilan junto con el propio Runtime dando lugar a la aplicación MHP que posteriormente se difundirá llegando a los usuarios finales.