Openfire y OpenCms se conocen

28/04/2009

En el proyecto en el que actualmente estoy trabajando tiene la necesidad de incorporar un servicio de mensajería instantánea (IM), como punto de partida mi compañero Manu me recomendó que empezara estudiando la tecnología que había desarrollada alrededor del protocolo Jabber (protocolo libre IM basado en XML).

Alrededor de este protocolo hay toda una comunidad de software libre que se dedica al desarrollo tanto de servidores como de clientes XMPP. Entre todos los servidores que estuve evaluando me decanté por uno que por su extensibilidad, tecnología y comunidad me convenció, Openfire. Se trata de un servidor de código abierto basado en Java, extensible a través de plugins y desarrollado por la comunidad bajo licencia GPL.

Como comentaba antes en el proyecto existía la necesidad de integrar un servidor de mensajería instantánea, la integración de Openfire con Opencms, el CMS que estamos utilizando, consistía en la autenticación de los usuarios. Para conseguirlo hemos tenido que hacer dos cosas, una del lado de OpenCms y otra de Openfire.

OpenCms

Hemos desarrollado un módulo de OpenCms que ofrece un servicio web con dos operaciones para realizar la autenticación de usuario, a este servicio web solo hay que pasarle el usuario y la contraseña encriptada, él se encargará de comprobar que el usuario y la contraseña son correctos así como de chequear toda la lógica de negocio, devolviendo un objeto en el que se indica si el proceso ha sido correcto.

Openfire

En este caso hemos desarrollado un plugin que cuenta con un cliente para el servicio web y que es el encargado de hacer la petición. Para que Openfire realice la autenticación utilizando la clase que hemos desarrollado, y que ha de implementar la interfaz (AuthProvider), en el método de inicialización del plugin hemos de cambiar la propiedad provider.auth.className para indicarle que utilice nuestra clase, es sumamente importante que previo a este paso hayamos registrado en el classpath del plugin dicha clase.

Una vez hecho esto, OpenCms y Openfire ya se conocen ;-p

No hay lugares remotos. En virtud de los medios de comunicación actuales, todo es ahora. Herbert Marshall Mcluhan

Anuncios

Web Services sobre OpenCms

18/01/2009

En este post voy a explicar un tema muy específico: cómo generar un módulo de OpenCms 7.0.5 que despliegue un web service sobre mismo contexto de OpenCms 7.0.5.

Para ello me recomendaron que me basara en la arquitectura Axis2 de Apache.

Antes de comenzar es muy importante que se haya comprendido cómo se ha de trabajar con un módulo de OpenCms 7.0.5 y Maven, para ello me gustaría recomendaros el estupendo post que en su día escribió mi compañero Antonio Manuel Muñiz respecto a este tema.

El primer paso que debemos dar para poder desplegar servicios web sobre el contexto de OpenCms, a través de un módulo, es preparar la instancia de OpenCms para tal propósito, para ello crearemos dentro del directorio “WEB-INF” un nuevo directorio “services” tal y como se muestra en la siguiente ilustración:

Estructura de directorios

Estructura de directorios

A continuación deberemos modificar el fichero web.xml de OpenCms para declarar el servlet de Axis2 que se encargará de atender las peticiones a los servicios web que declaremos.

<servlet>
—-<servlet-name>AxisServlet</servlet-name>
—-<display-name>Apache-Axis Servlet</display-name>
—- <servlet-class>org.apache.axis2.transport.http.AxisServlet</servlet-class>
—-<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
—-<servlet-name>AxisServlet</servlet-name>
—-<url-pattern>/services/*</url-pattern>
</servlet-mapping>

Una vez hecho esto, crearemos un módulo de OpenCms y modificaremos las directivas “<exportpoint />” del fichero “manifest.xml” para que OpenCms copie en el directorio “/WEB-INF/services” los servicios web desplegados como ficheros .aar

<exportpoint uri=”/system/modules/com.test.webservice.regard/services/” destination=”WEB-INF/services/”/>

Lo que tenemos que hacer a continuación es generar el fichero pom.xml necesario para que realice dos tareas fundamentales: obtener las librerías necesarias para que los servicios web puedan funcionar sobre la instancia de OpenCms y para que genere el fichero .aar a partir de los fuentes que le indiquemos.

Una vez hecho todo lo anterior tendremos listo el módulo para poder generar servicios web que corran dentro del mismo contexto que el OpenCms sobre el que se despliegan y, por tanto, puedan acceder a su información, para ello lo último que tendremos que hacer será generar un Singleton o un método dentro de la propia clase que se encargue de iniciar un objeto de la clase CmsObject que será el objeto a partir del cual podremos realizar todas las operaciones necesarias. Para llevar a cabo el desarrollo del servicio web para Axis2 os recomiendo el siguiente post.

Una vez hecho todo lo anterior ya solo nos quedará desplegar el módulo OpenCms y probar el nuevo servicio web a través de algún programa de generación de clientes.

0021

Respuesta positiva

Respuesta negativa

Respuesta negativa

Aquí dejo el módulo por si os es de utilidad.


NetBeans PHP IDE vs EclipsePDT

22/11/2008

Hace ya algún tiempo leí un post en el que Justin Carmony hacía una comparación de dos IDE´s para trabajar con tecnología PHP, Zend Studio  y Eclipse PDT. Me gustaría seguir la tarea que comenzara Justin (como se puede observar por el título del post) haciendo una comparación entre dos IDE´s de desarrollo de software libre, Eclipse PDT y la que podría ser la estrella revelación de la temporada NetBeans IDE 6.5.

Ahora bien, qué factores podríamos evaluar sobre estos dos IDE´s, Justin nos propone 6, veáse: facilidad de instalación, refactoring, PHP Unit testing, debugging, editor y Zend Platform & Zend Framework. A mí me gustaría plantear los siguientes factores: code completion, code errors y project plan, aunque también comentaré algo sobre los primeros.

Debbuging.

Esta primera característica es una de las que Justin evalua en su post. Tras haber trabajado un tiempo con PHP PDT me he podido percatar que durante la depuración la profundidad de exploración no pasaba de 3, este problema no lo tenemos en NetBeans, como podemos ver en las imágenes.

Code completion.

Con este factor se evaluará la capacidad del IDE para completar el código, facilitando de esta manera la programación. Aunque tanto PDT como Netbeans poseen esta característica, la ejecutan de forma distinta, mientras que Netbeans completa el código tanto de las funciones y métodos que hemos definido, como de las funciones existentes en el core y extensiones de PHP, PDT lo hace tan solo de los métodos y funciones que están definidos en el proyecto actual.

Code errors.

Con este factor se evaluará la capacidad del IDE no sólo para mostrar los errores que se pueden producir durante la programación, sino también la claridad y completitud de los mismos. En este factor la diferencia es más clara, como podemos observar en las siguientes imágenes.

Project plan.

Con este factor se pretende evaluar el roadmap de ambos proyectos, ya que éste nos indica las líneas de trabajo que se están siguiendo e incluso podremos solicitar qué líneas de trabajo nos gustaría que se siguieran. En la wiki del proyecto Netbeans podemos ver cuáles son las características que se van a implementar en futuras releases del IDE e incluso ¡¡¡votar por las que más nos interesen!!!, entre ellas podemos encontrar algunas muy interesantes como PHP Unit Support, Support for Symfony, PHPDocumentor integration y otras muchas. En el roadmap de PDT IDE podemos encontrar cuál será el mantenimiento evolutivo del proyecto, de las características que están planeadas implementar llama la atención, personalmente: Code Template y Code Assit for Dynamic Variables.

La construcción exitosa de toda máquina depende de la perfección de las herramientas empleadas. Charles Babbage


Gestión de contenidos. OpenCms 7 y Drupal 6.

13/11/2008

Después de todo este tiempo sin escribir me gustaría hablar de dos gestores de contenidos con los que he estado trabajando durante este tiempo, OpenCms 7 y Drupal 6.

Alguien me enseñó que en los proyectos de gestión de contenidos a la hora de seleccionar el CMS con el que vamos a trabajar nos interesa tener en cuenta, entre otros, tres factores: comunidad que existe tras el producto, facilidad para modificar la funcionalidad que el CMS nos proporciona y facilidad para modificar su aspecto visual para adaptarlo a la entidad corporativa del cliente, analicemos estos factores para los dos gestores de contenido que nos ocupan.

OpenCms 7 es un gestor de contenidos open source desarrollado por la empresa Alkacon Software haciendo uso de Java y XML. Para su instalación necesita un contenedor de aplicaciones como Tomcat y un SGBD como MySQL. El proceso de instalación es fácil, ya que tras su despliegue en el contendor de aplicaciones tan solo es necesario seguir un gestor de instalación que nos irá solicitando los datos necesarios para llevar a cabo la instalación del CMS. La idea de OpenCms va un poco más allá, además de proporcionar el propio gestor de contenidos, este CMS intenta proporcionar un IDE a través del cual poder realizar nuestros desarrollos.

Drupal 6 es un gestor de contenidos open source que fue originalmente desarrollado por Dries Buytaert y es usado para impulsar los sitios web Debian Planet, Spread Firefox, Kernel Trap y más. Para su instalación necesita un servidor web como Apache y un SGBD como MySQL, al igual que ocurre con OpenCms, Drupal proporciona un gestor de instalación paso a paso.

Estos dos CMS tienen en común que proporcionan un marco de trabajo con una serie de funcionalidades básicas y la capacidad de extender dichas funcionalidades básicas a través del desarrollo de nuevos módulos, funcionales, de contenido y de visualización (skins), a partir de aquí todo es distinto, veámoslo:

Comunidad

Cuando empezamos a utilizar estos dos gestores de contenidos vemos, a la luz de las búsquedas, que existe una gran diferencia entre las comunidades de OpenCms y de Drupal, podríamos fijarnos en el número de módulos que la comunidad de Drupal a aportado y el número de módulos de la comunidad de OpenCms.

Extensión funcional

La extensión funcional de estos dos CMS´s se realiza a través de la creación de módulos, ya sean funcionales o de contenido. La creación de un tipo de contenido para OpenCms es, a priori, más ventajosa que la de Drupal, pero ahí está el matiz, a priori, si lo que queremos crear es un tipo de contenido nuevo simple, por ejemplo, una noticia, con validaciones simples, comprobar si los campos están rellenos, OpenCms nos lo pone más fácil que Drupal, pero esa facilidad es un arma de doble filo cuando queremos hacer algo más complicado, por ejemplo una validación que no se pueda realizar con expresiones regulares, por ejemplo, que la fecha de alta de la noticia no sea posterior al día actual, ahí es donde Drupal le saca ventaja a OpenCms, mientras que con OpenCms tendríamos que crear una clase que X’ que heredara de la clase X y que implementa la interfaz Y, con Drupal tan solo tendríamos que tomar el valor del campo en el correspondiente hook y realizar la validación mencionada, esto para tipos de contenidos, el caso más fácil, pero si complicamos el caso, por ejemplo con la creación de un módulo funcional de administración, empezaremos a tener problemas, incluso en el propio desarrollo. Me explico, la idea de OpenCms de proporcionar un marco desde el que poder implementar, ahora mismo la considero hilarante, teniendo en cuenta el estado actual del mercado de IDE´s, suponiendo que no vamos a usar OpenCms para desarrollar nos encontramos con el problema del versionado, ¿cómo lo hacemos?. Cuando tenemos un módulo de contenidos versionamos el módulo y listo, pero cuando desarrollamos un módulo funcional, mucho de los ficheros y estructura de directorios han de ubicarse en una carpeta específica del VFS, para solventar este problema, un posible solución pasaría por replicar en el módulo los directorios VFS y mantener el fichero manifest.xml para que al importar el módulo lo mapee correctamente. Con Drupal no nos encontramos con este problema, los módulos, ya sean de contenidos o funcionales tienen una ubicación específica y desde ahí pueden trabajar, no necesitan declarar ninguna propidad y el versionado es trivial.

Apariencia

En este apartado las cosas están más o menos igual. En OpenCms 7 tenemos el Workspace desde donde podremos crear los contenidos y administrarlos con una apariencia similar a la de un sistema operativo. Para generar la interfaz del portal, podemos, de manera opcional, instalar y usar el Template Two, configurando esta plantilla podremos generar, de forma ágil, el skin de nuestro portal. En el otro lado tenemos los themes de Drupal, con ellos podemos modificar, con unos pocos golpes de ratón, completamente la apariencia de nuestro portal, sin existir una ruptura abrupta en la interfaz como ocurre con OpenCms, además estos themes, al igual que el Template Two, son totalmente transparentes con otras características como las URL´s amigables. El problema existiria si decidiéramos hacer uso de nuestras propias templates, en ese caso tendremos que programas nosotros esas características.

Horizontalmente a estos existen otros problemas, como por ejemplo la necesidad de tener un OpenCms para poder generar los instalables de los módulos a partir de los fuentes del repositorio, por suerte, siempre hay quien se preocupa de poner remedio a este tipo de eventualidades.

Nada es verdad ni es mentira; todo es según el color del cristal con que se mira. Ramón de Campoamor.


Documentación de proyectos

16/09/2008

El proceso de documetación (históricamente vinculado al perfil del becario) de un proyecto aunque es en cierta medida un proceso automatizable, gracias a herramientas como PHPDoc, Javadoc, etc, es una tarea que se antoja tediosa y larga. Si a esta ecuación le añadimos variables como la extensión de la documentación, necesidad de distribuir la documentación en distintos formatos (html, pdf, etc), con distintos estilos y a través de distintos canales la cosa comienza a tomar un cariz oscuro.

Con este escenario en mente y sabiendo la relación 1 a 1 que existe entre las entidades Tiempo y Dinero es cuando comienza a tomar fuerza el uso de herramientas como Docbook, entre las ventajas que esta herramienta nos proporciona podemos citar algunas como:

  • Nos permite abstraernos del aspecto y centrarnos en el contenido.
  • Estilos personalizables.
  • Producción de contenidos en distintos formatos partiendo de un mismo fuente.

Por supuesto también tiene algunas desventajas, como:

  • Debemos superar la curva de aprendizaje que toda nueva tecnología nos impone.
  • Poca madurez en muchas de las herramientas libres.

A continuación presento un esquema que ilustra el funcionamiento de Docbook

Esquema de funcionamiento de docbook

Esquema de funcionamiento de docbook

La instalación de dockbook junto con los procesadores XSLT es sencilla, basta con seguir los siguientes pasos:

Instalamos los esquemas de docbook y las xsl

  1. apt-get install docbook-xml
  2. apt-get install docbook-xsl

Instalamos el procesador XSLT

  1. apt-get install xmlto

Instalamos el generador para pdf

  1. wget http://www.uniontransit.com/apache/xmlgraphics/fop/fop-0.94-bin-jdk1.4.tar.gz
  2. tar -xvzf fop-0.94-bin-jdk1.4.tar.gz
  3. mv fop-0.94 /opt
  4. ln -s fop-0.94 fop

Ahora si queremos, por ejemplo, generar un documento html,partiendo de un documento test.xml que sigue el formato docbook, haremos lo siguiente:

  1. xsltproc -o test.html /usr/share/xml/docbook/stylesheet/nwalsh/html/docbook.xsl test.xml

Si en vez de un documento html queremos generar un pdf haremos esto otro:

  1. xsltproc -o test.html /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl test.xml
  2. /opt/fop/fop test.fo -pdf test.pdf
Invertir en conocimientos produce siempre los mejores beneficios. Benjamin Franklin

Configuración de un entorno de depuración para PHP

26/08/2008

Con este primer post comenzaremos a sentar las bases necesarias para conseguir montar un entorno de desarrollo e integración continua para proyectos realizados con tecnología PHP.

Los elementos que vamos a necesitar serán los siguientes:

EclipsePDT, es un IDE Eclipse que trae instalado los plugins necesarios para desarrollar aplicaciones con tecnología PHP (necesitaremos tener instalado JRE1.5).

WampServer permite instalar PHP, Apache y MySQL sobre un sistema operativo Windows. A partir de la versión 2.0 WampServer ofrece, además, la posibilidad de cambiar las versiones de los distintos componentes.

Xdebug es una extensión PHP que permite la depuración de scripts PHP ofreciéndonos una gran cantidad de información útil.

Lee el resto de esta entrada »