Middleware dotcms. Sara Estellés. José M. Gómez. Universidad de Alicante. Informe Técnico LegoLangUAge 02/2013

Transcripción

1 Informe Técnico LegoLangUAge 02/2013 Middleware dotcms Sara Estellés José M. Gómez Universidad de Alicante Grupo de Investigación en Procesamiento del Lenguaje Natural y Sistemas de Información

2 Contenido Contenido...2 Definición...3 Funcionalidad y Diseño General...3 Entradas y salidas...4 Funcionalidad y diseño de cada uno de los módulos...9 Base de datos...9 Proyecto Java middleware...9 dotcms...10 Dynamic Plugins...10 Instalación dotcms...11 Requisitos funcionales...13 Requisitos no funcionales...13 Informe Técnico LEGOLangUAge 02/2013 2

3 Definición Middleware dotcms es una plataforma Web que permite gestionar usuarios, parámetros y licencias de uso sobre distintos servicios. Ha sido desarrollada con el sistema de gestión de contenidos (CMS) dotcms ya que es la mejor alternativa en cuanto a CMS escritos en lenguaje Java. Esta aplicación permite gestionar los servicios creados por la empresa y así tener un catalogo online mediante el cual los clientes pueden solicitar licencias de uso sobre los servicios que les interese. Facilita al administrador el control de la expedición de licencias, gestión de permisos y restricciones. Una vez se haya proporcionado acceso al cliente el middleware se encargará de proporcionarle el código necesario para hacer uso de los servicios contratados, además cuando el cliente haga uso de éstos se encargará de realizar las transformaciones necesarias y comprobaciones para asegurar un uso lícito. La motivación de este proyecto reside en que actualmente cada servicio tiene su panel de administración, lo que implica descentralización y dificulta su control. El objetivo de Middleware dotcms es centrar toda esta gestión en una única plataforma Web. El proyecto ha sido desarrollado por el Grupo de Investigación en Procesamiento del Lenguaje Natural y Sistemas de Información (GPLSI), grupo de investigación de la Universidad de Alicante. Funcionalidad y Diseño General El esquema general del middleware se puede observar en Figura 1. Figura 1: Estructura general del middleware 1. El cliente mediante un código JavaScript público, que deberá haber insertado en su web con anterioridad, hará una petición al servlet getjavascript que dependiendo del código hash identificador del widget le devolverá otro código JavaScript personalizado según la implementación (código del widget del servicio seleccionado en una tecnología concreta) y según su licencia. Informe Técnico LEGOLangUAge 02/2013 3

4 2. Es por esto que se debe consultar a la base de datos la relación entre ese código identificador del widget, la implementación y la licencia. 3. Tras realizar las operaciones de sustitución de variables (señalizadas mediante $nombrevar$) personalizando la plantilla de script de implementación, se devolverá al cliente dicho código que realizará todas las operaciones de inicialización y creación de la vista. 4. Este código debe hacer peticiones a nuestro servidor para obtener los datos a mostrar en la vista, este es el propósito del servlet callservice. 5. Antes de hacer la llamada a los web Services que proporcionarán los datos a devolver al cliente, se deberán consultar los parámetros de configuración (ej.: parámetros a solicitar, restricciones de uso) además de las URL de los web Services y el nombre del wrapper que se comunicará con éstos. 6. Una vez obtenida toda la información se hará una llamada al wrapper concreto con los parámetros necesarios. 7. El wrapper se encargará de hacer la llamada correctamente a los web Services y de transformar el resultado a formato JSon. 8. Se devolverá el resultado al servlet callservice en formato JSon. 9. Se devolverá el resultado al usuario en formato y el script que generó la vista lo procesará para mostrar los datos en un formato entendible por el usuario. Entradas y salidas Ciclo de vida de un servicio Hemos hablado de hash, widget, códigos de implementación, licencias... pero para poder obtener todos estos datos primero deberemos añadirlos a la base de datos de nuestro CMS. Ese es el proceso que se explicará a continuación: DotCMS nos proporciona una gestión de usuarios que se darán de alta utilizando el enlace login de la pantalla principal: Informe Técnico LEGOLangUAge 02/2013 4

5 En esta intranet deberá aparecer un listado con los distintos servicios ofrecidos. Para contratar uno el usuario lo elegirá y se mandará una solicitud al GPLSI que preparará todo lo necesario para poder ofrecer dicho servicio (en un futuro deberá ser automático). Esta lista de servicios se gestionará a través del panel de administración de dotcms, al que accederemos agregando al final de la URL /admin. 1. Dar de alta la empresa y departamento del usuario. 2. Haremos lo mismo con 'Department'. 2. Relacionar al usuario con los datos anteriores. 3. Crear la licencia con sus restricciones Informe Técnico LEGOLangUAge 02/2013 5

6 4. Asociarle el servicio seleccionado por el usuario. 5. Estos servicios se relacionan con distintos webservices. 6. El servicio accede a una clase java del paquete 'wrappers' Informe Técnico LEGOLangUAge 02/2013 6

7 7. Definir los widgets para ese servicio 8. Crear las implementaciones disponibles sobre cada tecnología. Informe Técnico LEGOLangUAge 02/2013 7

8 El usuario deberá tener acceso al panel de control de personalización de ese servicio, donde personalizará sus widgets creándose automáticamente un widget asociado a ese usuario en concreto. A partir de ese momento tendrá disponible un código JavaScript que deberá incrustar en su web similar a este: <script type="text/javascript" src=" script > <div class ="gplsi-widget" data-gplsi-widget ="$hash$"> Nota: la variable $hash$ se traducirá por el hash real del widget personalizado El contenido de ese código JavaScript público es el siguiente: var tags; window.addeventlistener( "load", init, true); function init(e) { tags = $( "[class^='gplsi-widget']" ); var head= document.getelementsbytagname('head')[0]; $.each(tags, function (i, item){ var widgetcode = item.getattribute('data-gplsi-widget'); var script= document.createelement('script'); script. type= 'text/javascript'; script.src= ' widget=' +widgetcode; head.appendchild(script); }); } Como podemos ver obtiene las etiquetas HTML cuya clase empiece por gplsi-widget y añade un link a un fichero JavaScript en elemento head para obtener el código JavaScript asociado a ese código de widget llamando al servlet getjavascript. Este código obtenido podría ser similar a este: $.getjson( " hash=$hash$&text=" +texturi+ "&callback=?", function (result){ caras(result.resultado); resaltar(texto, result.docfeatureweights); }); Nota: Donde $hash$ sería el código identificador de la licencia del usuario. Como podemos ver obtenemos el resultado en formato JSON que podrá ser interpretado por otras funciones para añadir estos datos a la vista. La necesidad del uso de un parámetro callback viene dado por la política del mismo origen que no permite que se manipule el DOM de otra ubicación distinta a no ser que el código se ejecute con el mismo protocolo en el mismo host y puerto. Informe Técnico LEGOLangUAge 02/2013 8

9 Funcionalidad y diseño de cada uno de los módulos Base de datos Proyecto Java middleware Dentro del paquete es.ua.middleware tendremos: - wrappers Donde hay una clase Wrapper que es una clase abstracta que define los métodos que deben implementar todas las clases que se ubiquen en este paquete. - clients Clientes de servicios web a los que habrá que hacer las peticiones para obtener los datos que se mostrarán en el widget. - servlets Paquete donde se encuentran los dos servlets anteriormente descritos 'GetJavascript' y 'CallService' además de la clase 'Activator' que sirve para mapear dichos servicios a una URL en el servidor y crear el contexto inicial. Informe Técnico LEGOLangUAge 02/2013 9

10 En cuanto a la clase Wrapper esta tendrá un método llamado callservice que recibirá los parámetros necesarios y se encargará de llamar correctamente al servicio web asociado. La respuesta recibida la transformará a formato JSON antes de devolvérsela al servlet 'CallService'. Debido a que cada web service tiene un formato distinto de respuesta, deberemos crear un wrapper a medida de cada uno. dotcms DotCMS es un CMS extensible cuyo núcleo son las herramientas web de administración pero además ofrece la capacidad de extenderse y personalizarse mediante su arquitectura plugin. Dynamic Plugins El framework OSGI (Open Services Gateway Initiative) es un módulo del sistema y una plataforma de servicios para el lenguaje de programación Java. Aplicaciones y componentes pueden ser instaladas, iniciadas, paradas, actualizadas y desinstaladas remotamente sin requerir un reinicio del CMS. DotCMS implementa OSGI utilizando la librería Apache Felix: WEB-INF/felix/bundle: Incluye 6 jars, el runtime y el núcleo de OSGI. No deben eliminarse o modificarse. WEB-INF/felix/felix-cache: Almacena la caché y puede ser eliminada si se encuentran problemas al desplegar una nueva clase. WEB-INF/felix/load: aquí es donde deberemos añadir nuestros bundles (las clases Java implementadas). Al añadirlo será detectado por OSGI y desplegado automáticamente. Informe Técnico LEGOLangUAge 02/

11 WEB-INF/felix/undeployed: Aquí es donde se almacenan los bundles que eliminemos desde la interfaz de usuario (backend). Esta sería la interfaz gráfica mediante la cual se pueden gestionar los plugins mediante la UI: Cabe destacar el menú superior derecho, ya que como vemos permite cargar plugins desde la interfaz, sin necesidad de copiar el.jar en la carpeta load. Por otro lado está la opción de paquetes exportados, muy importante cuando tenemos problemas de dependencias, ya que para resolverlas deben estar cargadas en el sistema. Cuando guardemos reiniciara el framework OSGI evitándonos así el reinicio de todo el CMS: Nota: Físicamente este fichero se encuentra en dotcms/web-inf/felix/osgi-extra.conf. Instalación dotcms Basándonos en las instrucciones de la página oficial de dotcms se explicarán los pasos de la instalación basada en la descarga de los fuentes desde el repositorio git: 1. Instalando Java, Ant, y el cliente de GIT 1. Descargamos e instalamos SUN Java JDK 1.6.0_23 o superior. 2. Nos aseguramos de que tenemos la variable de entorno JAVA_HOME apuntando al directorio raíz de la instalación del jdk. 3. Instalamos un cliente para descargar el contenido del repositorio. 2. Clonar dotcms Clonamos el proyecto de dotcms desde el repositorio git: 3. Ejecutar 'ant deploy' Ejecutamos y desplegamos en el directorio raíz de dotcms. Esto compilará el CMS y creará los ficheros SQL requeridos. Informe Técnico LEGOLangUAge 02/

12 4. Crear una base de datos vacía DotCMS puede ejecutarse sobre 4 tipos de bases de datos: Postgresql, MySQL, MSSQL y Oracle. Se necesita crear una nueva base de datos y dotar de permisos al usuario que utilizaremos para conectar a la base de datos. Creamos una nueva base de datos llamada dotcms con codificación de caracteres UTF-8 (ej. mysql): create database dotcms default character set = utf8 default collate = utf8_general_ci; Creamos un usuario que tenga acceso a dicha base de datos y permisos create all Configuramos el archivo 'conf/catalina/localhost/root.xml' (ej. mysql): <Resource name="jdbc/dotcmspool" auth="container" type="javax.sql.datasource" driverclassname="com.mysql.jdbc.driver" url="jdbc:mysql://localhost:3306/dotcms?characterencoding=utf-8" username="user" password="password" maxactive="60" maxidle="10" maxwait="60000" removeabandoned="true" removeabandonedtimeout="60" logabandoned="true" validationquery="select 1" testonborrow="true"/> En la puesta en marcha dotcms creará el esquema de la base de datos y los datos iniciales que necesita. 5. Configurando IP / puerto del servidor La especificaremos en./tomcat/conf/server.xml file. Editamos tanto la etiqueta server como connector: <Server address=" " port="8005" shutdown="shutdown" debug="0">... <Connector address=" " port="80" maxthreads="150" minsparethreads="25" maxsparethreads="75" enablelookups="false" redirectport="8443" acceptcount="100" debug="0" connectiontimeout="20000" disableuploadtimeout="true" /> Cambiar los permisos de los scripts Cambiamos los permisos de los scripts en los directorios /bin: > chmod 755./bin/*.sh Informe Técnico LEGOLangUAge 02/

13 > chmod 755./tomcat/bin/*.sh 8. Poner en marcha el servidor Utilizando el script bin/startup.sh y viendo los logs en tomcat/logs/dotcms.log 9. Intentar hacer login en el backend La página principal se ubicará en: (o la dirección IP donde se esté ejecutando Catalina) y la consola de administración: por defecto las credenciales son: user: admin@dotcms.com password: admin Requisitos funcionales Plataforma de centralización de servicios. Personalizar parámetros para cada servicio. Personalizar parámetros, restricciones y permisos de las licencias de uso. Interfaz para que el usuario pueda contratar servicios. Gestión de peticiones de licencias y expedición. Gestión de implementaciones y parámetros. Página web de acceso a la aplicación. Página web de gestión de usuarios. Página web de gestión de servicios. Documentación completa del API. Documentación completa de la BD. Documentación completa de la aplicación. Requisitos no funcionales Los requisitos no funcionales son: SO: 32 o 64 bit, Linux, Windows XP, 2000, Vista o 7, Solaris o Mac OS X Nota: JVMs de 32 bit están limitadas de ~1.5 a 2.0GB RAM. Como dotcms cachea objetos en la RAM esta limitación puede afectar negativamente al rendimiento. Hardware: Dual Core Pentium 2.0+, 4gb RAM (Shared), 100 GB HD JVM: Sun Java 1.6.0_23 o superior. Servidor de aplicaciones: Apache Tomcat 6+ Informe Técnico LEGOLangUAge 02/

14 Base de datos: PostgreSQL 8.4+ o MySQL 5.5+ No hay soporte para LDAP en la versión community. Informe Técnico LEGOLangUAge 02/