Informe Técnico LegoLangUAge 02-2013
Anuncio
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
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
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
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
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
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. Definir los widgets para ese servicio
8. Crear las implementaciones disponibles sobre cada tecnología.
Informe Técnico LEGOLangUAge 02/2013
7
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="http://servidor/application/gplsi/gplsi.js"></
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= 'http://servidor/app/getjavascript/?
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( "http://servidor/app/callservice/?
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
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
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:
http://felix.apache.org/site/index.html
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/2013
10
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:
https://github.com/dotCMS/dotCMS
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/2013
11
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="208.250.1.102"
port="8005" shutdown="SHUTDOWN" debug="0">
...
<Connector
address="208.250.1.102" port="80"
maxThreads="150" minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false"
redirectPort="8443" acceptCount="100"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true" />
...
6. 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/2013
12
> 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:
http://localhost[:port] (o la dirección IP donde se esté ejecutando Catalina)
y la consola de administración:
http://localhost[:port]/admin
por defecto las credenciales son:
user: [email protected]
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/2013
13
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/2013
14
