ESTRATEGIA 2011-2015 SUBPROGRAMA COMPETITIVIDAD I+D PROYECTO SMART DESARROLLO SISTEMA GESTOR DE CONTENIDOS Y SERVIDOR DE ENTREGA DE CONTENIDOS DESCRIPCIÓN DE LA ARQUITECTURA
ÍNDICE 1 DESARROLLO SISTEMA GESTOR DE CONTENIDOS Y SERVIDOR DE ENTREGA DE CONTENIDOS.... 3 T2.1.- Desarrollo core gestor de contenidos.... 3 T.2.2.- HERRAMIENTA DE ADMINISTRACIÓN DE CONTENIDOS.... 6 T2.3.- DESARROLLO DE HERRAMIENTAS DE ADMINISTRACIÓN DE CONTENIDOS Y PLANTILLAS.... 8 Página 2 de 10
1 DESARROLLO SISTEMA GESTOR DE CONTENIDOS Y SERVIDOR DE ENTREGA DE CONTENIDOS. o Participantes: PROASUR/WILDBIT. o Duración: 01-01-2013/ 31-10-2013. Objetivos: o Desarrollo / Adaptación de un sistema gestor de contenidos adaptado a la entrega de contenidos culturales para móviles. o Desarrollo de protocolos de comunicación eficientes para conexiones 3G. o o o Desarrollo de herramientas de edición de contenidos. Desarrollo de herramientas para la edición de plantillas de maquetación de contenidos. Gestionar las cuestiones de propiedad industrial e intelectual en el consorcio y resolver posibles conflictos. Tareas: o T2.1: Desarrollo core gestor de contenidos. Soporte multi-idioma. Desarrollo de capa de almacenamiento. o o Gestión del ciclo de vida del contenido, un contenido puede ser permanente o temporal, en este último caso se puede indicar el tiempo en el que se publica y deja de ser público. Soporte de múltiples entornos (no existe limitación del número de entornos), por ejemplo: pre-publicación y publicación. Soporte de sistema de versionado de contenidos y backup. Operación sobre los contenidos a través de interfaz map-reduce, y API de consulta de contenidos sobre interfaz REST. Capacidad de adaptación dinámica de los metadatos. Soporte de contenidos georreferenciados. Sistema de caché de contenidos, la gestión de cache se realiza a nivel de consulta. Por defecto soporta la persistencia de la cache en sistema de fichero, pero es compatible con sistema de cache en memoria comerciales, como por ejemplo memcached. T2.2: Desarrollo módulos de entrega de contenidos optimizados para móviles. Desarrollo módulo de entrega de contenidos de aplicaciones en backend. T2.3: Desarrollo de herramientas de administración de contenidos y plantillas. Desarrollo de herramientas de edición y gestión de contenidos, con soporte para múltiples dispositivos, idiomas y entornos (desarrollo, preproducción, producción). Desarrollo de herramientas de edición de plantillas de maquetación de contenidos. T2.1.- DESARROLLO CORE GESTOR DE CONTENIDOS. Descripción general CMS El sistema gestor de contenidos es una plataforma que permite la administración de los contenidos de la aplicación. Su desarrollo está basado en una base de datos NoSQL del tipo orientada a documentos denominada ucms DB (microcms DB) que se ha implementado específicamente para este proyecto. Los módulos y el software de base que se ha utilizado para la implementación de la plataforma es el siguiente: MySQL 5.x. PHP 5.3. Smarty para la gestión de templates en la parte servidora. jquery / easyjqueryui para la gestión de componentes dinámicos de presentación. A continuación se incorpora un esquema gráfico de los diferentes bloques que componen la plataforma CMS: Página 3 de 10
Figura 1. Bloques de la plataforma CMS. Capa de almacenamiento (ucms DB) Esta base de organiza la información en esquemas, que se asemejan a lo que sería una tabla en un modelo relacional. Un esquema tiene un número ilimitado de instancias o documentos y cada instancia de documento tiene un identificador único y tiene un conjunto de campos variable. Esquemas de datos Como ayuda a la edición de contenidos se define un conjunto de campos de referencia para el objeto del esquema, de forma que sea posible la generación de formularios web para la creación, modificación y borrado de contenidos. En la siguiente imagen se describe un esquema de ejemplo compuesto por múltiples campos de información. Figura 2. Ejemplo de esquema de datos. Los tipos de datos pueden ser de múltiple naturaleza: Texto. Texto localizado, se trata de un objeto con versiones específicas en función de los locale dados de alta en la aplicación. Campos con valores múltiples. Campo referencia, actúan como punteros entre documentos. Constantes o valores inmutables. Enumeraciones o conjunto de opciones. Programa / código fuente Ecmascript. Internamente el diccionario se almacena en JSON, por ejemplo: { "id_application":"list:3@paper Zombie#5@DrawPets#6@MindSumo#8@FingerJones", "campaign":"input", "display_type":"list:a@alert type#w@web type", "start_time":"input", "end_time":"input", "target":"code:wblang:small", "on_click":"code:wblang", "on_view":"long_input", "alert_caption":"input", "alert_control":"input", "click_link":"long_input", "enable_log":"list:1@yes#0@no", "set_event_once":"list:1@yes#0@no", "mode":"list:p@push mode#e@e mode#c@client mode", "parent_campaign":"input", Página 4 de 10
"priority":"input", "event":"long_input", "segment":"input", "status":"list:a@active#i@inactive" } Por último, se pueden definir relaciones de jerarquía en los esquemas, de tal forma que es posible crear tipos / subtipos de documentos y relaciones entre objetos. Almacenamiento de los datos A nivel físico la representación y almacén de los datos se realiza en lenguaje JSON, codificado en UTF-8 y encriptado con un algoritmo propio. El almacenamiento recae sobre un esquema de base de datos: { "author : MTAx, "year : MTk5Nw==, "description : "SW5ramV0IHByaW50IGFuZCBoYW5kIGxldHRlcmluZyBvbiBjYW52YXMsPGJyPjc1IHggNjAgaW4u\, "path : aw1hz2vzlziwms5qcgc=, "mime_type : aw1hz2uvanbn, "location : czisihmxncwgcze1 } Consulta y proceso de información El core de ucms.db se ha desarrollado en PHP sobre un esquema de base de datos MySQL, también cuenta con un driver de a la base de datos basado en el lenguaje PHP. Adicionalmente cuenta con un API JSON/RESTful para que terceros sistemas puedan realizar las operaciones contra el esquema independientemente de la tecnología o plataforma sobre la que corran. Una de las aplicaciones de proceso de datos sobre la base de datos es el mecanismo de consulta y el proceso de datos basados en el patrón MAP (extensible a operaciones MAP- REDUCE). A continuación se adjunta un ejemplo de una operación de este tipo, que se conecta a una instancia de base de datos remota y sobre los datos de una aplicación aplicación y ejecuta un proceso de traducción sobre el esquema con identificador 15. /** MAP operation, executed for each and every record */ function process_record(&$doc) { $doc->data->question = json_decode($doc->data->question); $doc->data->question->en = GoogleTranslateUtil::translate('es','en',$doc->data->question->es); $doc->data->question->ca = GoogleTranslateUtil::translate('es','ca',$doc->data->question->es); $doc->data->question = json_encode($doc->data->question); $doc->data->body = json_decode($doc->data->body); $doc->data->body->en = GoogleTranslateUtil::translate('es','en',$doc->data->body->es); $doc->data->body->ca = GoogleTranslateUtil::translate('es','ca',$doc->data->body->es); $doc->data->body = json_encode($doc->data->body); $doc->title = 'Translated: '.$doc->title; } $type = 15; $id_app = 1; $manager = new RemoteMicroCMSManager($url_base,$id_app); $manager->map_select(process_record,$type); El pipeline del proceso se compone de la operación de filtro de datos, la ejecución de la operación registro por registo (map) y los resultados: Capa core microcms Figura 3. Pipeline del proceso. Página 5 de 10
El núcleo del gestor de contenidos microcms se compone de cuatro elementos: 1) Gestor de esquemas, que es el encargado de dar soporte al ciclo de vida del contenido, desde su creación hasta su destrucción. 2) Gestor de versiones (snapshots), proporciona la capacidad de guardar y recuperara fotos del modelo de datos y los esquemas en cualquier momento en el tiempo. 3) Módulo de gestión de usuarios, que permite realizar el control de acceso de usuarios. 4) Módulos de integración de datos, permiten la extracción, incorporación y manipulación datos por parte de terceras partes. Adicionalmente el sistema cuenta con mecanismos para la gestión de contenidos localizados / internacionalizados. T.2.2.- HERRAMIENTA DE ADMINISTRACIÓN DE CONTENIDOS. Módulo de delivery de contenidos Dentro de la arquitectura general incluida en la memoria del proyecto original, la interlocución entre la aplicación y el sistema de gestión de contenidos se realiza a través del módulo de delivery de contenidos: Figura 4. Módulo Delivery de contenidos. El delivery server es un módulo servidor que actúa como un servidor de aplicaciones distribuido en el que las aplicaciones finales (tanto web como móviles) se intercambian mensajes con los módulos del back-end. El sistema se ha diseñado para poder correr en una plataforma cloud, de cara a cubrir necesidades de escalado, contingencia ante problemas. También se ha diseñado para poder dar servicio a múltiples aplicaciones a la vez (multitenancy). Organización funcional del delivery server A nivel funcional la arquitectura principal está compuesta en capas en analogía con los modelos de red propuestos por OSI: Figura 5. Arquitectura funcional. La capa de transporte se encarga de la entrega y recepción de mensajes entre extremos, cuenta además con la capacidad de encriptación y compresión de las comunicaciones. Se basa en un protocolo no orientado a conexión sobre TCP, la estructura de los mensajes es la siguiente: Comando, Número de secuencia del mensaje y un payload con un conjunto variable de mensajes. Página 6 de 10
Figura 6. Capa de transporte. Un ejemplo de comando es el registro de una descarga sería el siguiente, dónde REG es el comando, 125 el código de secuencia del mensaje y AHGSHGAHSGASHGAS la clave con la que se registra la aplicación descargada. REG 125 AHGSHGAHSGASHGAS Este protocolo se puede utilizar para la comunicación entre cliente a servidor como la comunicación servidor a servidor, tal y como se indica en la imagen inferior Figura 7. Protocolo de comunicación. El módulo de transporte puede utilizar diferentes capas de presentación que gestionan la representación de la información la encriptación de la misma. Para la implementación desarrollada se ha utilizado un lenguaje de representación de texto simple para garantizar la eficiencia en el proceso de la información. El objeto de información que se envía en cada comunicación HTTP se llama MESSAGE_BUNDLE compuesto por una lista de MESSAGES. La sintaxis del mismo es en notación EBNF es: MESSAGE_BUNDLE :== MESSAGE ( > MESSAGE )* MESSAGE :== COMMAND SEQ_ID ( FIELD )* COMMAND :== STRING SEQ_ID :== INTEGER FIELD :== STRING Las capas de señalización, datos y framework contienen lógica básica para el funcionamiento general del sistema Diseño de arquitectura de componentes software del delivery Server La plataforma se ha desarrollado sobre los siguientes componentes de infraestructura: Apache PHP 5.x MySQL 5.x Se ha optado por esta tecnología tanto por los costes operativos del hosting de la plataforma, por ser un lenguaje de desarrollo de alta productividad, como por la disponibilidad de desarrolladores con experiencia en estos entornos. Los componentes del software se organizan según un patrón modelo vista controlador en múltiples niveles, existen controllers a nivel de la plataforma y controllers a nivel de aplicación que coexisten. Dichos controladores están asociados a las capas de gestión de las comunicaciones presentadas anteriormente. El sistema se entiende como un servidor de aplicaciones en el que existe una lógica básica dependiente de la carpeta src, un conjunto de recursos y lógica de aplicaciones: Figura 8. Carpte src. Esquema. La carpeta ext contiene la lógica de aplicación, dentro de ella se aloja los comportamientos específicos de la misma, por ejemplo para el caso de la aplicación TEST se han implementado tres extensiones a los controller de Señalización, Datos y Framework: Página 7 de 10
Figura 9. Carpeta ext. La carpeta ext contiene la lógica de aplicación, dentro de ella se aloja los comportamientos específicos de la misma, por ejemplo para el caso de la aplicación TEST se han implementado tres extensiones a los controller de Señalización, Datos y Framework. T2.3.- DESARROLLO DE HERRAMIENTAS DE ADMINISTRACIÓN DE CONTENIDOS Y PLANTILLAS. Capa Web de administración microcms La web principalmente cuenta con una herramienta web accesible a través de un navegador para que los usuarios puedan administrar o gestionar los contenidos compuesta por varios módulos: Módulo de administración del gestor de contenidos. Módulo de gestión de usuarios, que permite la asociación de permisos de acceso a usuarios, roles etc. Interfaz de usuario para la administración de contenido, edición de esquemas y gestión de snapshots. Sistema de gestión de versiones del esquema y datos (snapshots). Los contenidos se estructura en esquemas (schema), dentro de cada uno de ellos hay documentos. Los accesos a la herramienta de administración de contenidos se realizan a través de un conjunto de usuarios, que según su rol podrá realizar las operaciones que le correspondan a dicho rol. Figura 10. Roles de acceso. La aplicación tendrá una versión de datos en uso (llamada HEAD snaphot) y una lista de copias/versiones sobre las que se puede volver atrás en cualquier momento. La web de gestión de contenidos permite la edición, borrado y creación de los objetos de los esquemas y todas las funciones asociada con la gestión de usuarios gestión de versiones, y definición de esquemas: Página 8 de 10
Figura 11. Web de gestión de contenidos. El sistema de gestión versiones (snapshots) permite la creación de una versión y las operaciones del cambio a alguna de las versiones existentes. Una snapshot contiene una copia íntegra tanto de datos como de la definición de los esquemas en un punto dado en el tiempo. Las operaciones se pueden realizar desde la consola web de administración. Figura 12. Consola de administración. Existe una opción de administración de las aplicaciones que permite definir los parámetros propios de la aplicación, como por ejemplo los idiomas que soporta, cómo se almacena la información localizada, etc: Figura 13. Administración de aplicaciones. Capa de integración: API RESTful Congrega un conjunto de llamadas basadas en el protocolo RESTful para el manejo de los modelos de información alojados en ucms. Permite a su vez realizar operaciones de alteración de la información o sobre conjuntos de información a través del paradigma map / map-reduce. Página 9 de 10
El protocolo RESTful utiliza el formato JSON como lenguaje de representación de la información e incorpora primitivas para las siguientes operaciones: Autenticación de usuarios. Consulta de los esquemas de una aplicación. Operaciones de consulta sobre los datos. Operaciones sobre los datos basadas en operaciones MAP. Operaciones para la inserción y modificación de los datos. Exportación de datos en formatos JSON, CSV, SQL. Sistema de cache de contenidos. Sistema de gestión inteligente de la configuración La plataforma permite gestionar de forma dinámica la configuración de la aplicación pudiendo asociar atributos en función del segmento del usuario, idioma país o cualquier otra dimensión que permita clasificar a los usuarios. Figura 14. Configuración de la aplicación. Los atributos de configuración pueden contener cualquier elemento modificable dentro de la aplicación, como podría ser la frecuencia con la que se realizan recomendaciones. El tipo de contenidos que se muestran, etc. Las reglas indican si la regla está en vigor o no, para la evaluación de las reglas se ha desarrollado un mini-intérprete de reglas, con un conjunto de funciones de ayuda, a continuación se indican dos reglas de ejemplo que actúan sobre una variable de la aplicación denominada WB_INITIAL_CREDIT: Figura 15. Atributos de configuración. Página 10 de 10