Con las últimas liberaciones de Andago de proyectos cómo OpenCities Community o la ya casi inminente liberación de OpenLicita Community, así cómo todo el trabajo llevado a cabo por el Departamento de Arquitectura para paquetizar en formato Debian todos los proyectos y herramientas útiles que usamos a menudo internamente, hemos creado un repositorio de paquetes Debian público para que cualquiera que quiera pueda hacer uso de él. En este repositorio podéis encontrar Software Libre, paquetizada para Debian, con algunos desarrollos de Andago y otros de otras comunidades, que facilitan la instalación de los mismos. El repositorio lo hemos utilizado intensivamente de forma interna para facilitar las tareas de despliegue de aplicaciones, pero estoy seguro que también puede ser de interes para mucha gente dentro del ecosistema del Software Libre.
La mayoría de los paquetes son para Debian Lenny, pero también disponemos de algunos para Etch. Para acceder al repositorio debemos seguir los siguientes pasos:
Algunos paquetes que podemos encontrar a día de hoy en este repositorio son los siguientes:
Además seguiremos añadiendo y actualizando las versiones de los paquetes en el repositorio publico según vayan saliendo de nuestro repositorio interno y del repositorio experimental de Andago.
Gracias a una invitación de Google Android, la entrada más reducida son 600€, este año he asistido al Mobile World Congress 2010 en Barcelona, con el objetivo de asistir a las sesiones de labs de Android y ya allí, aprovechar para ver a todos los que se iban a dejar caer por allí.
El día, ayer, no defraudó. Tuve oportunidad de hablar con antiguos compañeros de trabajo que andan en sus respectivas aventuras en el mundo de los móviles, de las problemáticas que encontramos y del fenómeno Android, que ha revolucionado el mundo de la movilidad. En la feria se podían ver decenas de dispositivos ya con Android y muchas de las grandes marcas han apostado ya fuerte por Android. No en vano en Wired se habla de MWC 2010: The Year of the Android. Para Wired la batalla por quien será el Windows de los móviles está servida: Android vs Windows Phone. A iPhone le reservan el papel de siempre de Apple, para usuarios exquisitos con las interfaces y la usabilidad a costa de tener limitaciones.
A parte de Android, en el congreso estuve con mis amigos de GSyC/LibreSoft, que asistieron al grupo de trabajo de Realidad Aumentada del que pude disfrutar algo más de una hora y donde se reunió un nutrido grupo internacional intentando definir bases de colaboración para el desarrollo de estándares.
Durante la comida hablamos de las consecuencias de la fusión de Maemo y Moblin, de como GTK se está quedando fuera en el mundo de los móviles y sobre si apostar ya por Android y las consecuencias para empresas que vienen del mundo del software libre.
Para terminar el día, estuve en una plaza del congreso junto a la gente de LibreGeoSocial que mostraban LibreGeoSocial a personas de los cinco continentes. Quien sabe que habrán podido sembrar. Y ya de paso, hablamos de la formación de una comunidad para promover el software libre en Android.
En fin, un día intenso, interesante que justificó totalmente el esfuerzo de hacer el viaje.
Liferay se ha convertido en pieza clave dentro de los desarrollos de Andago gracias a su gran potencial cómo marco común para integrar otras aplicaciones web en un solo portal. Por otro lado Jboss se asienta cómo servidor de aplicaciones corporativo capaz de contener cualquier de las soluciones de Andago. Si unimos estos dos casos con las necesidades de alta disponibilidad de cualquier proyecto serio llegamos a la importancia de crear un cluster de Liferay dentro de Jboss, que vamos a presentar en las siguientes lineas.
A la hora de poner LIferay en Cluster debemos tener en cuenta 4 puntos fundamentales:
Con ello seríamos capaces de desplegar varios nodos de Jboss que trabajen de forma colaborativa. Hay varias formas de llevar a cabo cada uno de estos puntos, así que aquí va una aproximación, en la que se requiere tener ya configurado el cluster de jboss y disponer de algún medio de almacenamiento compartido, dos temas para los que hay abundante documentación en internet. Manos a la obra:
Cachés en cluster
Liferay disponde de distintas cachés que deben ser clusterizadas para su correcto funcionamiento:
* Persistence Cache * Multi VM Cache
Para poder usarlas en cluster haremos uso de EHCache que configuramos de la siguiente forma:Debemos extraer (copiar fuera, sin borrar) del portal-impl.jar de Liferay los siguientes ficheros: * liferay-multi-vm-clustered.xml * hibernate-clustered.xml Y los copiamos en un directorio que crearemos para ello en:liferay.war/WEB-INF/classes/myehcache/Añadimos a portal-ext.properties estas líneas de configuración:# Hibernate Cache en Clusternet.sf.ehcache.configurationResourceName=/myehcache/hibernate-clustered.xml# MultiVM Cache en Clusterehcache.multi.vm.config.location=/myehcache/liferay-multi-vm-clustered.xmlCon objetivo de depurar el cluster podemos añadir estas líneas a log4j.properties del servidor: (NO DEJAR EN PRODUCCIÓN)log4j.logger.net.sf.ehcache=INFOlog4j.logger.net.sf.ehcache.config=DEBUGlog4j.logger.net.sf.ehcache.distribution=DEBUG
* liferay-multi-vm-clustered.xml * hibernate-clustered.xml
liferay.war/WEB-INF/classes/myehcache/
# Hibernate Cache en Clusternet.sf.ehcache.configurationResourceName=/myehcache/hibernate-clustered.xml# MultiVM Cache en Clusterehcache.multi.vm.config.location=/myehcache/liferay-multi-vm-clustered.xml
log4j.logger.net.sf.ehcache=INFOlog4j.logger.net.sf.ehcache.config=DEBUGlog4j.logger.net.sf.ehcache.distribution=DEBUG
Repositorio de ficheros en ClusterPara que las aplicaciones de Liferay que hacen uso del repositorio de ficheros puedan operar correctamente en cluster necesitamos tener en el sistema de ficheros compartido el directorio:liferay/dataÍndices de lucene en ClusterDe los 4 métodos existentes para mantener los índices de Lucene en Cluster usaremos el basado en sistema de ficheros compartido siempre que este permita bloquear el acceso a los ficheros. En nuestro caso usaremos NFS por lo que garantiza esta situación. Cómo en el paso anterior requerimos que esté en el sistema de ficheros compartido el directorio:
liferay/data
liferay/dataReplicación de sesionesPara el mantenimiento de sesión utilizaremos el cluster de Jboss con sesiones sticky, también debería funcionar con non-sticky pero hemos detectado algunos casos en los que se produce perdida de sesión. Una vez configurado el cluster de jboss lo único que necesitamos es marcar el war de liferay cómo distributable mediante su configuración, así que modificamos el siguiente fichero entre los tags xml de web-app:liferay.war/WEB-INF/web.xml...<distributable/>...
liferay.war/WEB-INF/web.xml...<distributable/>...
Otras consideraciones
* Despliegue de plugins y temasSe ha de tener en cuenta que el despliegue de plugins y temas se debe de llevar a cabo en todos los nodos del cluster por lo que se recomienda se realice a través de la línea de comandos y del directorio deploy de liferay:liferay/deploy * Integración con CASAl parecer hay un problema con la integración con CAS y para que funcione se debe de realizar el siguiente cambio de librería:liferay.war/WEB-INF/lib/casclient.jarpor:liferay.war/WEB-INF/lib/casclient-2.2.0-M3.jar
liferay/deploy
liferay.war/WEB-INF/lib/casclient.jar
liferay.war/WEB-INF/lib/casclient-2.2.0-M3.jar
Javier Turégano
El pasado lunes 11 de Enero se estrenó el nuevo aula de formación de Andago, espacio destinado a ser un flujo constante de conocimiento y aprendizaje. El aula de formación, como punto de intercambio de conocimiento, parece destinada a convertirse en un punto importante para conseguir los objetivos que se ha marcado Andago para este 2010.
Por un lado es importante impulsar la mejora en los conocimientos de todo el personal, sobretodo trabajando en un sector cómo el IT que está sometido a un cambio vertiginoso, en el que estar al día será una de las máximas de todos los que integramos la compañía. El desarrollo de la plantilla dentro de la empresa es un factor ganador para las dos partes, la empresa consigue disponer de gente mejor preparada y a su vez la gente ve mejorado su conocimiento y su valía, y es algo a valorar muy seriamente.
Por el otro, va a facilitar de gran forma el poder dar a conocer nuestras soluciones y ofrecer formación en ella a todo el que lo requiera. Así que no tardaremos en ver los primeros cursos de OpenCities, OpenLicita u OpenCitizen para administraciones, partners y cualquiera que quiera acercarse a conocerlas.
Además el aula contará con sistema de grabación para poder difundir la formación a todos aquellos que no puedan estar presente en cualquiera de los cursos y charlas que se desarrollen en ella.
El primer curso que se llevó a cabo ha sido sobre "Introducción a ESB" (Enterprise Service Bus), tecnología que es clave dentro de nuestras soluciones y que es importante potenciar y conocer al máximo.
En Wired se puede leer el interesante artículo Will the Mobile Web Kill Off the App Store? (¿Acabará la la Web Móvil con las Tiendas de Aplicaciones?).
Ya hablábamos de ello hace poco, y en este artículo se muestra como tanto desde Firefox como desde Google apuestan por el desarrollo de aplicaciones totalmente web frente a las aplicaciones nativas. Pero también se apunta la opinión de un consultor que defiende la mezcla de ambas, aportando lo mejor de cada una.
Personalmente creo que las aplicaciones web nunca llegarán a explotar toda la potencia del hardware de los dispositivos, sobre todo cuando estos van a evolucionar y reinventarse a velocidad de vértigo. En un sector tan innovador y que se renueva tan rápido, a pesar de alternativas como HTML5 que parece que podrían mostrar como desarrollar aplicaciones web que utilizarán todo lo que ofrece el hardware de la máquina, será complicado llegar a homogeneizar. Y si no que se lo pregunten a Java y su intento muy en esta línea.
En cualquier caso, apasionante y revolucionaria la época que se acerca. Y por fin poco a poco alejándonos del yugo de Microsoft en los escritorios tradicionales. La diversidad creciente es de momento la norma predominante en las plataformas móviles. ¿Quién se llevará el gato al agua?
Hoy hemos tenido una reunión muy interesante en Ándago sobre como plantear el desarrollo de clientes en Android, interfaces que permitirán acceder a los servicios que se ofrecen desde las plataformas, a la vez que explotar las funcionalidades que ofrece Android, como geolocalización, acelerómetro, brújula, sonido ...
Desde las aplicaciones web se están desarrollando capas que permitan el acceso nativo a partes de la plataforma de Android. Por ejemplo, desde Google Gears se puede acceder a la geolocalización. Para acceder a otras funcionalidades existen tecnologías como PhoneGap o Bondi, aunque parece que todo ello podría ser sustituido por las nuevas funcionalidades de HTML5. Google Gears pasará a estar obsoleto con la llegada de HTML5.
Es curioso que Google, la compañía que potencia el llevar todo a la interfaz web, sea la que desarrolla aplicaciones nativas en Android para aplicaciones como el Correo.
Está claro que la respuesta a esta problemática, aplicaciones nativas frente a aplicaciones web, no tiene una única solución y aunque las aplicaciones web han ido ganando terreno, ¿se impondrán en las pantallas de los teléfonos móviles?
Hace ya tiempo que desde Andago tenemos claro que las redes Mesh son una de las soluciones más potentes a la hora de realizar un despliegue inalámbrico, cómo podemos comprobar en el apunte que realicé en su día en esta entrada de mi blog personal: enredando con el Mesh. Pero poco a poco la evolución que van teniendo productos cómo Meraki nos van dando la razón. Hace algún tiempo que Meraki lanzó su equipo mesh de altas prestaciones: el MR58 que nos va a permitir ampliar enormemente la cobertura y el ancho de banda gracias a su triple radio 802.11n. Así cómo otros modelos basados en 11n cómo el MR14 y el MR11 con dos y una intefaz de radio cada uno, uno de los temas del que se ha solido acusar de los Meraki que era la falta de equipos "profesionales" con varias interfaces de radio.
Todas estas opciones que vienen a unirse a la gama Meraki tanto indoor cómo outdoor, y no nos olvidemos del Meraki solar que nos facilita poder desplegarlo en cualquier parte dónde no tengamos conexión a red eléctrica, potencian en gran medida las posibilidades a la hora de crear nuestra red. Y por supuesto manteiniendo el concepto base de Meraki: Wireless Networks that simply works, es decir que añadir nodos a la red mesh puede hacerlo cualquiera ya que la gestión se lleva a cabo a través de una herramienta centralizada via web. Parece que el año que viene habrá mucho movimiento en el tema del wifi municipal y las soluciones basadas en Meraki nos aportan unas opciones realmente interesantes.
Para acabar con el tema Meraki os dejo un enlace dónde podemos ver un ejemplo claro de hasta dónde puede llegar una red basada en Meraki [en inglés]:
http://meraki.com/general/2009/12/09/does-it-scale%E2%80%A6-absolutely-blazing-fast-meraki-wireless-at-leweb-conference-in-paris/
En él podemos ver cómo con gran sencillez se puede construir una red con Meraki que albergue miles de usuarios concurrentes y cómo la red escala a la perfección para dar cobertura a todos ellos. Aquí abajo podéis ver el mapa de conexión entre los distintos dispositivos y de usuarios repartidos por estos:
Otra opción mesh, aunque esta va más allá, e implementa la idea de router inalámbrico multiprotocolo es el Meshlium que incluye los protocolos Wifi, ZigBee, GPRS, Bluetooth y GPS en un mismo dispositivo, además de poseer capacidades de router Mesh. Las posibilidades que se abren son enormes y saca el máximo provecho de cualquier tipo de comunicación inalámbrica.
Os recomiendo un paseo por la web de Libelium la empresa de zaragoza que creó este genial invento.
http://www.libelium.com/products/meshlium
Parece bastante claro que el Mesh ha dejado de ser una tecnología del futuro para ser cada día más una realidad del presente.
En una entrada anterior hablaba sobre diversos aspectos generales de la gestión del almacenamiento en nuestra empresa dejando para una entrada posterior (ésta) la descripción de nuestra solución elegida. En resumen, nuestras opciones eran las siguientes:
Teniendo en cuenta nuestras necesidades y factores limitantes, se ha optado por una solución AoE basada en cabinas Coraid debido a su buena relación coste/prestaciones al utilizar electrónica estándar Ethernet y discos SATA-II de 3.5".
La arquitectura general de la solución se muestra en la siguiente figura:
Vemos que se trata de una solución totalmente redundante con los siguientes elementos:
En conjunto, como he dicho, esta arquitectura permite establecer una solución sin ningún punto único de fallo con el apoyo de software de sistema. Como ejemplo, puede crearse un sistema RAID-1 por software utilizando dos particiones, cada una de ellas tomada de una cabina distinta:
La flexibilidad de la solución nos permite gestionar discreccionalmente el tipo de acceso en función de su utilización. Ejemplos de uso en nuestras instalaciones:
La solución AoE no está exenta de limitaciones. Veamos algunas y cómo las hemos gestionado:
En resumen, nuestra elección ha permitido dotarnos de una solución flexible, sostenible y con un coste adecuado (según nuestros cálculos, entre dos y cuatro veces más barata que otras opciones de características similares basadas en iSCSI o fibra óptica).
Llevo unos meses obsesionado con los usabilidad, los interfaces de usuario y el diseño de productos, desde el punto de vista del usuario.
He leido libros como el de Tom Peters sobre Diseño, donde se habla porque un usuario le gusta tanto un producto con respecto a otro, y esa es la razón principal de la compra. Cuenta anecdotas donde Steve Jobs dice que se reiterá en el diseño de sus productos hasta que la sensación de todo el grupo es que se ha llegado a algo "enfermizamente cachondo". Creo que es bueno preguntarse cuando estemos diseñando nuestras nuevas aplicaciones llegar a una experiencia de usuario que nos permita pensar "!que cachondo me pone este interfaz" ;-)
Buscando por Internet he encontrado este vídeo de Google:
He estado viendo esta charla, titulada “Don’t make me click“, de Aza Raskin en las GoogleTechTalks (charlas para empleados de Google que son grabadas y difundidas de forma gratuita…). donde se habla de conceptos sobre usabilidad, diseño e interacción.
Hay una frase que me ha gustado especialmente: “para el usuario, el interfaz es el producto”. Es decir, no importa cómo sean las “tripas” del producto, que si la forma de usarlo no está bien diseñada, el resultado será nefasto. Y afirma que “el mejor interfaz es el que no se nota”; aquél que nos permite hacer lo que queremos hacer sin tener que pensar “cómo se hará ésto, a qué menú tengo que ir, dónde tengo que pinchar…”.
Raskin parte del planteamiento de que cualquier web se sitúa en algún punto entre los extremos de “aburrida” (por tener pocas cosas) y “molesta” (por tener demasiadas cosas). Hay que encontrar el equilibrio justo que permita mostrar cosas útiles e interesantes pero sin sobrecargar.
Habla de algo que resulta ser cierto: “la seducción por la interacción”. La gente (los clientes, los usuarios) tienden a pensar que, para evitar ser “aburridos”, hay que poner muchas cosas: muchos botoncitos, muchos links, mucha interacción (hace un ejemplo bastante clarificador “complicando” la web de Google con ajax, iconos, etc.). Pero tanta interacción es un error. A mayor interacción, menos información, ergo menos contenido y menos usuarios.
Por lo tanto, hay que reducir la interacción (de ahí el título de la charla: “don’t make me click”). El lo llama ZIA (”Zen Internet Application”). A partir de ahí, expone algunos ejemplos de por dónde pueden ir los tiros (mostrar mucha información accesible a través de un simple zoom, formas de mostrar contenido a medida que se hace scrolling, introducción de datos prescindiendo de los típicos formularios, interfaces basados en el “lenguaje natural”…).
la charla da que pensar.
Una de las necesidades internas más imperiosas de una empresa tecnológica como Ándago es la disponibilidad de abundante espacio de almacenamiento razonablemente seguro, con suficiente disponibilidad y fácilmente gestionable para hacer frente a las necesidades operativas del negocio.
Para ello, se pueden distinguir tres tipos básicos de servicios de almacenamiento en función de su ubicación y modelo de acceso:
Cada uno de estos modelos posee características específicas que lo hacen adecuado en unas u otras circunstancias que, aunque más que interesantes, no entraremos a abordar ahora.
Baste decir que, en nuestro caso, la disponibilidad de una SAN nos permite ofrecer a los servidores de nuestra red el suficiente espacio de almacenamiento para sus necesidades de forma escalable, segura y gestionable. A la hora de seleccionar una tecnología para nuestra SAN, nuestros requerimientos fueron los siguientes:
En términos generales, nuestras opciones eran las siguientes:
En un primer término es fácil segregarnos entre las opciones NAS y SAN que responden a necesidades distintas y, de hecho, cualquiera que fuese nuestra solución SAN sería usada también como base para ofertar a la red servicios de NAS, por ejemplo, para acceso a datos comunes o los directorios particulares de los usuarios vía NFS y/o Samba (CIFS).
Por lo que respecta a las opciones SAN, cualquiera de ellas cumple nuestras necesidades minimas por lo que los factores determinantes habrán de estar relacionados con el coste en primer lugar y con la relación coste/caraterísticas en segundo.
En un próximo artículo entraré a "resolver el enigma" y describir cuál es la solución que hemos elegido para el despliegue de nuestra SAN.
Durante el desarrollo de aplicaciones, tarde o temprano se suele plantear la cuestión del rendimiento de dicha aplicación. Existen múltiples métricas que pueden ser tenidas en cuenta como unidad de medida de rendimiento de una aplicación, y en función de las objetivos del desarrollo es necesario conseguir unos resultados u otros, por ejemplo:
Para medir el rendimiento de una aplicación, inclyendo el número de peticiones que se responden y el tiempo necesario para responder las peticiones se suele utilizar herramientas que realizan tests de rendimiento o stress, como Apache Jmeter que permiten definir un conjunto de pruebas a realizar, y muestran estadísticas de los resultados.
Una vez que se ha medido el rendimiento de la aplicación, cuando se plantea la necesidad de la mejora del rendimiento de una aplicación, es posible seguir tres vías complementarias:
Mientras que la ampliación de hardware no tiene ningún misterio, y sobre arquitecturas de crecimiento horizontal ya hemos hablado en otros artículos, en este caso el artículo estará centrado en técnicas para la optimización de código.
El "profiling" es un técnica que permite inspeccionar el funcionamiento interno de una aplicación durante su tiempo de ejecución, lo que permite discernir el número de veces que están siendo usados cada uno de los componentes de la aplicación, y el tiempo que consume cada uno de esos componentes. El "profiling" puede ser realizado manualmente, incluyendo trazas en los componentes sobre los que se desean realizar mediciones, o se pueden utilizar herramientas preparadas para cada uno de los diferentes lenguajes de programación, llamadas profilers, que permiten o bien en tiempo de compilación incluyendo sobrecargas en el código, o bien en tiempo de ejecución interceptar las llamadas a cada uno de los componentes, que permite extraer durante la ejecución de la aplicación información sobre el número de veces que son ejecutadas y el tiempo consumido en cada ejecución.
Como prueba de concepto va a ser utilizado un servidor de aplicaciones Jboss, y una serie de aplicaciones desarrolladas en Java deplegadas en dicho servidor de aplicaciones. En el mercado actual existen múltiples "profilers", algunos de los cuales son software libre y otros software propietario. Por suerte la comunidad Jboss tiene su propio "profiler" llamado jboss-profiler, aplicación que debería ser suficiente para realizar una prueba de concepto de profiling.
1. En primer lugar se descarga el profiler, para ello se accede a http://labs.jboss.com/jbossprofiler/ y se descarga la última versión disponible, en este caso de prueba fue la versión "jboss-profiler-2.0.0.Beta5.zip". Y se descomprime en un directorio:
# cd /opt # unzip ~/jboss-profiler-2.0.0.Beta5.zip
2. Es necesario copiar ciertos ficheros al directorio de arranque de jboss "$JBOSS_HOME/bin", que se incluyen a continuación:
# cd jboss-profiler-2.0.0.Beta5 # cp jboss-profiler.jar $JBOSS_HOME/bin # cp jboss-profiler-plugins.jar $JBOSS_HOME/bin # cp jboss-profiler.properties $JBOSS_HOME/bin # cp javassist.jar $JBOSS_HOME/bin
3. Se modifica el fichero "$JBOSS_HOME/bin/run.conf" para incluir nuevas opciones en "JAVA_OPTS":
JAVA_OPTS="..... -javaagent:jboss-profiler.jar -Djboss- profiler.properties=jboss-profiler.properties"
4. Se modifica el fichero de configuración del jboss profiler, "$JBOSS_HOME/bin/jboss-profiler.properties", incluyendo que clases se quieren monitorizar y cuales se quieren excluir de la monitorización:
includes=com.andago.*|public,hero.*|public,org.postgres.*|public,fedora.*|public excludes=org.jboss.*,com.andago.opencities.model.*|public
Nota: En este caso se comprueban las clases desarrolladas por Ándago, las del motor de workflow Bonita, las del gestor documental Fedora, y las de acceso a la base de datos Postgresql. Se han excluidos parte de las desarrolladas por Ándago en la rama "com.andago.opencities.model", porque utilizan la clase "cglib" que parecen entrar en conflicto con el sistema de profiling.
5. Es necesario desplegar el profiler en el servidor de aplicaciones, realizando lo siguiente:
# cp jboss-profiler.sar $JBOSS_HOME/server/default/deploy/
Una vez realizados los cambios ya es posible re-arrancar el servidor de aplicaciones, viendo que el servicio de profiling ha arrancado en los logs de arranque:
2009-09-09 13:06:59,563 INFO [org.jboss.profiler.as.Profiler] JBoss Profiler: ProfilerMBean started 2009-09-09 13:06:59,563 INFO [org.jboss.profiler.as.Communicator] JBoss Profiler: Communicator for JBoss Profiler 2.0.0.Beta5 2009-09-09 13:06:59,581 INFO [org.jboss.profiler.as.Communicator] JBoss Profiler: Socket=0.0.0.0:5400 2009-09-09 13:06:59,631 INFO [org.jboss.remoting.transport.coyote.CoyoteInvoker] Using org.apache.coyote.http11.Http11AprProtocol for http (coyote) invoker protocol handler. 2009-09-09 13:06:59,735 INFO [org.apache.coyote.http11.Http11AprProtocol] Inicializando Coyote HTTP/1.1 en puerto http-0.0.0.0-5402 2009-09-09 13:06:59,781 INFO [org.apache.coyote.http11.Http11AprProtocol] Arrancando Coyote HTTP/1.1 en puerto http-0.0.0.0-5402 2009-09-09 13:06:59,781 INFO [org.jboss.profiler.as.Communicator] JBoss Profiler: Http=0.0.0.0:5402
Una vez en funcionamiento, es realmente sencillo realizar profiling del código. La aplicación de profiling incluye un cliente desde el que se puede realizar diferentes operaciones como pueden ser, arrancar el servicio de profiling, activarlo, salvar la información almacenada en el profiling, realizar un report, incluir nuevas clases a monitorizar y otras. Existe un manual incluido con la herramienta que explica todas las opciones "JBossProfiler2-UsersGuide.pdf".
La herramienta utiliza un sistema de "snapshots", que permiten descargar el contenido del profiling (que es almacenado en memoria o ficheros), permitiendo delimitar periodos de tiempo sobre los que se realiza el profiling. Por ello se recomienda seguir los siguientes pasos:
1. Se genera un snapshot para aislar las operaciones realizadas sobre la aplicación con anterioridad:
# cd jboss-profiler-2.0.0.Beta5 # java -Xmx512m -Djboss-profiler-client.properties=jboss-profiler-client.properties -jar jboss-profiler-client.jar snapshot
2. Se realizan las operaciones sobre las que se quiere realizar profiling. Se recomienda utilizar un sistema de pruebas automático, ya sea Apache Jmeter, o un script de seleniumhq.org/projects/ide/.
3. Se genera un snapshot+report final con los resultados de las pruebas.
# java -Xmx512m -Djboss-profiler-client.properties=jboss-profiler-client.properties -jar jboss-profiler-client.jar snapshot reportdirFinal
Con ello se genera un directorio llamado "reportdirFinal" en cuyo interior se incluye el report en varios ficheros "html", enlazados con un fichero "index.html", de modo que simplemente abriendo en un navegador el fichero "index.html" pueden verse los diferentes datos recogidos por la herramienta, incluyendo los threads, los métodos más usados, el número de veces utilizados, las clases cargadas:
JBoss Profiler 2.0.0.Beta5 Reports * Overview * Hotspots * Packages * Classes * Methods * Wait time
Cada una de la secciones permite acceder a diferente mediciones de datos, en la sección overview se puede ver (entre muchas otras cosas), los métodos que mayor tiempo consumen de ejecución, y el número de veces que se han llamado:
Most time Count Ms Avg % Method 34 5440,92 160,03 33,00 com.andago.opencities.services.database.DatabaseServiceImpl#loadObjectById(Class, java.io.Serializable, boolean) 26 3253,73 125,14 19,73 com.andago.opencities.services.database.DatabaseServiceImpl#loadObjectListByFilter(Class, com.andago.opencities.managers.database.common.Filter, boolean) 3 623,35 207,78 3,78 com.andago.opencities.services.repository.client.fedora.apiM.ManagementSoapBindingStub#addDatastream(String, String, String[], String, boolean, String, String, String, String, String, String, String, String)
Uno de los pilares fudamentales para poder dar soporte a una red es la monitorización, ya que es fundamental saber en todo momento cuál es el estado de los distintos elementos de nuestra red y qué problemas pueden estar ocurriendo. En el caso que os presento se trataba de monitorizar una red basada en tecnología inalambrica (mixta wimax-wifi) distribuida a los largo y ancho de una ciudad. En esta red disponemos de elementos tan diversos cómo pueden ser puntos de acceso wifi, dispositvos troncales Wimax, cámaras y servidores de videovigilancia, sensores, incluso dependencias conectadas de forma remota.
Para ello casi todos los fabricantes de hardware de red, ya sean inalambricos o no, disponen de soluciones orientadas a sus productos, que en muchas ocasiones no son adaptables a un despliegue tan heterogéneo cómo el mostrado o el coste de las mismas las hacen inviables. Por lo que nos hemos decantado por utilizar una de las estrellas de la monitorización dentro del software libre cómo es Nagios.
La ventaja de utilizar Nagios es que uno puede adaptar la monitorización de cada dispositivo a sus características y utilizar la mejor vía para obtener información de él, cómo por ejemplo para dispositivos en los que sólo necesitamos saber si son accesibles se puede usar el check ICMP pero podemos obtener información más interesante cómo el SNR (relación señal/ruido), número de usuarios conectados, estadísticas de acceso y tráfico, etc... a través de protocolos cómo SNMP o TELNET.
Una vez configurado podemos disponer de una bonita vista visual de la red, así cómo recibir las alertas via correo o SMS, mostrando de nuevo la flexibilidad que nos dá Nagios.
Algunos artículos relacionados:
Uno de los principales problemas en el desarrollo software, es la falta de metodología y procedimientos definidos por un departamento de calidad con experiencia, conocedor de las soluciones y problemáticas de la empresa.
En contra de lo que se pudiera pensar, el departamento de calidad no se compone de un conjunto de recursos realizando pruebas manuales e informando de anomalías en el software. En el departamento de calidad se establecen los pasos a seguir para conseguir un producto con las garantías mínimas establecidas por la empresa.
El propio centro de calidad tiene que estar autoregulado, de forma que se produzca una mejora continua. Así, se establecen plantillas, protocolos de comunicación entre los diferentes roles funcionales, metodologías de desarrollo, automatización de pruebas...
Si bien las plantillas, comunicación y metodologías se encuentran en un marco totalmente subjetivo de acuerdo a las pretensiones de calidad propias de la empresa, la automatización de las pruebas sobre el software adquiere una importancia máxima para minimizar incidencias (pruebas de validación funcional, rendimiento, concurrencia...) y la satisfacción del cliente (minimización de errores).
Uno de los sistemas de automatización de pruebas más extendido es Apache JMeter. Además de estar integrado en proyectos basados en la metodología MAVEN, permite la automatización de pruebas no sólo en el lado del servidor (caja blanca), sino directamente contra las propias URL's (caja negra). De esta forma, se engloba en una única herramienta todas las necesidades del plan de pruebas que requiere una aplicación profesional. Cabe destacar que, aunque se trata de una solución basada en JAVA, al permitir el uso de patrones, puede ser utilizado para definir el plan de pruebas de cualquier lenguaje de programación de aplicaciones web.
Otra de las herramientas más populares de automatización de pruebas es JUnit. Si bien existen multitud de plugins que permiten su incorporación en el desarrollo de los principales IDE's, su funcionalidad se encuentra centrada en la evaluación de aplicaciones JAVA siempre a nivel de caja blanca, es decir, estableciendo scripts de comprobación de la lógica funcional del sistema. Muy sencilla y fácil de utilizar, JUnit puede suponer una garantía en aquellos desarrollos JAVA que no necesiten una validación del interfaz. Pese a ello, se trata de una herramienta realmente potente.
Estos son sólo dos ejemplos de herramientas que permiten la realización de pruebas sobre aplicaciones, de forma que se automatice al máximo el plan de pruebas. Siempre hay nuevas y variadas soluciones de automatización de pruebas, y este puede ser un buen lugar en el que comentarlas.
Invertir en un buen sistema de calidad y dedicar esfuerzo a la automatización de pruebas supone un inversión muy enriquecedora a medio plazo. Lo que podría entenderse como un gasto a corto plazo, incide directamente en la mejora de la producción, incremento de beneficios y la reducción exponencial de los errores de los desarrollos.
Desde la creación del Departamento de Arquitectura en Andago, uno de nuestros mayores objetivos ha sido el de mejorar el proceso del paso de las aplicaciones de las manos de los desarrolladores a los entornos de producción. Este es un proceso delicado en el que se tienen que controlar temas importantes cómo compatibilidad de los distintos entornos (desarrollo, pre y pro) por ejemplo en cuanto a librerías, versión de la máquina virtual, del servidor de aplicaciones, control de las versiones instaladas y trazabilidad hacia las fuentes originales, etc...Investigando la forma de disponer de un repositorio de versiones de los paquetes instalables nos topamos con una idea más interesante y que además de cubrir nuestras necesidades mejoraba considerablemente el trabajo de desarrollo: la integración continua. Tras investigar un poco nos decidimos por implantar un servidor Hudson.
Este servidor nos permite realizar compilaciones periódicas de todos los proyectos de la compañía cuando se detectan modificaciones en los repositorios de fuentes (subversion) e incluso realizar pruebas automatizadas sobre el resultado de dicha compilación para comprobar que la nueva versión está lista para ser desplegada, en primer lugar en el entorno de pre-producción y posteriormente pasar a producción. En caso de fallar el proceso de compilación o las pruebas se notifica a la persona que ha realizado el commit que ha "roto" el proyecto, al jefe de proyecto responsable y al responsable de arquitectura. Otra de las ventajas de tener un punto unificado para la compilación es la de asegurarnos que todo el código ha sido subido al subversion correspondiente, no se depende de elementos que sólo están en el equipo del desarrollador y que disponemos de información del estado actual del proyecto y la posibilidad de que en caso de que falle la última versión encontrar una que si haya pasado los procesos de compilación y pruebas.Otro de los objetivos de nuestro departamento era el de proveer de entornos de desarrollo y pre-producción a todos los proyectos lo que elevaba en gran medida las necesidades de servidores. Desde hace bastante tiempo y con estas ideas de crecimiento en mente Andago siempre ha dado una gran importancia a la virtualización, comenzamos con VMWare, pasandonos rapidamente a entornos con qemu y actualmente contamos con una granja de 6 servidores con tecnología Xen desplegados por el Departamento de Sistemas que nos permiten tener al rededor de 50 máquinas virtuales en ejecución y una gran escalabilidad en caso de aumentar la demanda.
En este punto cuando un equipo nos pide que realicemos el despliegue de un determinado proyecto, los técnicos de arquitectura pueden ir al servidor de integración Hudson y recoger los desplegables listos para el despliegue. Cómo el proceso manual no era la mejor manera de realizar el paso a los entornos y dificultaba llevar un control de los elementos desplegados en cada entorno se le dió una nueva vuelta a la tortilla, empaquetar dichos entregables dentro de paquetes debian listos para instalar en los entornos. De esta forma nos evitamos estar tocando dentro de los servidores en caso de haber cambios en las aplicaciones y lo único que tenemos que hacer es modificar el contenido del paquete, actualizar su versión y el changelog y actualizarlo en el servidor de producción. Es más con este sistema y con un simple listado de los paquetes instalados podemos ver claramente que versión de la aplicación está desplegada.Al principio el proceso de paquetización era manual, una vez creado el paquete el resto de ocasiones sólo era necesario modificar su contenido con las nuevas versiones, pero poco a poco el trabajo que suponía estar modificando las versiones de los paquetes ocupaba una gran parte del tiempo disponible en el departamento nos lanzamos a la tarea de automatizar el proceso. El proyecto lo nombramos con el del divertido robot de pixar: Wall-e.
Wall-e son un conjunto de scripts y plantillas que una vez configurados para cada proyecto toma los distintos desplegables generados por Hudson y los coloca en su ubicación dentro del paquete, actualiza el changelog del paquete según las fuentes del subversion y la versión a partir de la revisión correspondiente de las fuentes. A continuación sube el paquete a su repositorio debian correspondiente, ya sea este uno de los internos de la compañía o los privados destinados a cliente.
De esta forma para instalar el paquete en el servidor correspondiente tan sólo tenemos que ejecutar:apt-get updateapt-get upgrade
Resumiendo, el proceso de paso de un proyecto a producción sería el siguiente:
Desde aquí mi enhorabuena a mis compañeros de Arquitectura: David, Gema y Carlos con los que hemos llevado a cabo este trabajo.Javier Turégano
Recientes noticias aparecidas en Slashdot, como ésta o esta otra nos obligan a reconsiderar cuáles son las condiciones mínimas que toda estrategia de copia de seguridad debe cumplir. Aquí está mi lista:
Otras consideraciones:
Los "Enterprise Service Bus" (ESBs para los amigos), ha sido una de las tecnologías que ha estado en boca de los responsables de los departamentos de IT de múltiples organizaciones en los últimos años. Llegaron como solución a los problemas de comunicación e integración de las distintas soluciones existentes (y por existir) usadas en las organizaciones, y poco a poco han ido encontrando su nicho de mercado. Dentro de las posibles soluciones existentes tanto propiertarias como libres, ServiceMix se ha ganado un hueco como posible solución ESBs a evaluar, gracias a estar bajo el abanico de soluciones aportadas por la red Apache. En este articulo se detallan instruciones para desplegar ServiceMix en un servidor JBoss.En principio en la web de "Servicemix" se incluye una página con instrucciones para tal instalación http://servicemix.apache.org/jboss-deployer.html pero como se ha podido comprobar en las nuevas versiones, generalmente las instruciones se quedan cortas.A continuación se muestran los pasos necesarios para realizar tal despliegue:1. Se descarga y construye en jboss-deployer de Servicemix (en el momento de crear el tutorial la versión disponible era la 3.3): # svn co http://svn.codehaus.org/servicemix/trunk/jboss-deployer # cd jboss-deployer # mvn install Lo cual genera un fichero "jboss-deployer/target/servicemix-jboss-deployer-3.3.jboss-sar" que después se desplegará en JBoss para permitir que se desplieguen los componentes y los futuros JBIs desarrollados,2. Se descarga el servicemix completo correspondientes a la versión que se ha creado del deployer en este caso la versión 3.3 y se descomprime: # mkdir servicemix # cd servicemix # wget -c http://apache.rediris.es/servicemix/servicemix-3/3.3/apache-servicemix-3.3.tar.gz # tar xvzf apache-servicemix-3.3.tar.gz En el interior del directorio se habrán descomprimido las librerias y los componentes en lib/ y hotdeploy/.3. Las instrucciones recomiendan copiar todas las librerías de servicemix en JBoss, pero como se ha podido ver en las pruebas no es necesario, y además es poco recomendable. En las pruebas sólo ha sido necesario copiar 1 librería: # cp apache-servicemix-3.3/lib/woden-1.0.0M6.jar $JBOSS_HOME/server/default/4. Servicemix está desarrollado mediante módulos (componentes) de modo que se recomienda desplegar sólo aquellos componentes que se vayan a necesitar en JBoss. En principio se recomiendan los siguientes: servicemix-bean-2008.01-installer.zip, servicemix-camel-2008.01-installer.zip, servicemix-drools-2008.01-installer.zip, servicemix-eip-2008.01-installer.zip ,servicemix-file-2008.01-installer.zip, servicemix-http-2008.01-installer.zip, servicemix-jms-2008.01-installer.zip, servicemix-jsr181-2008.01-installer.zip, servicemix-mail-2008.01-installer.zip, servicemix-quartz-2008.01-installer.zip, servicemix-saxon-2008.01-installer.zip, servicemix-shared-2008.01-installer.zip. Pero en JBoss existen varios problemas con los componentes que hay que tener en cuenta: * En Servicemix 3.3 cada uno de esos componentes lleva en su interior dos ficheros jbi.xml, de modo que al desplegarlos encontraremos errores indicando que se están desplegando dos veces los componentes y el segundo intento falla (aunque no afecta al funcionamiento los errores son molestos), el modo de solucionarlo es dentro de cada componente abrir el fichero "lib/servicemix-nombredecomponente-version.jar" y dentro de ese jar eliminar el fichero "META-INF/jbi.xml". Es decir por ejemplo en servicemix-bean-2008.01-installer.zip: META-INF/jbi.xml <- este NO borrarlo lib/servicemix-bean-2008.01.jar -> dentro del jar "META-INF/jbi.xml" este BORRARLO * Ciertos componentes puede entrar en conflicto entre si, por ello se ha encontrado que es necesario eliminar una de las librerías del componente servicemix-jsr181-2008.01-installer.zip, en concreto (para ello se abre el fichero .zip y se elimina del interior el fichero): lib/xbean-2.2.0.jar5. Una vez realizados los cambios en los componentes se despliegan los componentes y el deployer usando (NOTA: es necesario renombrar el deployer de "-sar" a ".sar" o no desplegará): # cp apache-servicemix-3.3/hotdeploy/servicemix-file-2008.01-installer.zip $JBOSS_HOME/server/default/deploy # cp apache-servicemix-3.3/hotdeploy/servicemix-drools-2008.01-installer.zip $JBOSS_HOME/server/default/deploy # cp apache-servicemix-3.3/hotdeploy/servicemix-eip-2008.01-installer.zip $JBOSS_HOME/server/default/deploy # cp apache-servicemix-3.3/hotdeploy/servicemix-file-2008.01-installer.zip $JBOSS_HOME/server/default/deploy # cp apache-servicemix-3.3/hotdeploy/servicemix-http-2008.01-installer.zip $JBOSS_HOME/server/default/deploy # cp apache-servicemix-3.3/hotdeploy/servicemix-jms-2008.01-installer.zip $JBOSS_HOME/server/default/deploy # cp apache-servicemix-3.3/hotdeploy/servicemix-jsr181-2008.01-installer.zip $JBOSS_HOME/server/default/deploy # cp apache-servicemix-3.3/hotdeploy/servicemix-mail-2008.01-installer.zip $JBOSS_HOME/server/default/deploy # cp apache-servicemix-3.3/hotdeploy/servicemix-quartz-2008.01-installer.zip $JBOSS_HOME/server/default/deploy # cp apache-servicemix-3.3/hotdeploy/servicemix-saxon-2008.01-installer.zip $JBOSS_HOME/server/default/deploy # cp apache-servicemix-3.3/hotdeploy/servicemix-shared-2008.01-installer.zip $JBOSS_HOME/server/default/deploy # cp jboss-deployer/target/servicemix-jboss-deployer-3.3.jboss-sar $JBOSS_HOME/server/default/deploy/jboss-deployer/target/servicemix-jboss-deployer-3.3.jboss.sarUna vez finalizados los pasos anteriores ya es posible desplegar los JBIs que se creen en el directorio deploy de JBoss.
Mucho estoy oyendo hablar estos días de preelecciones, de las conversaciones que están teniendo a 3 bandas, el gobierno, las sociedades de derechos de gestión y las TELCO, con el fin de poner coto a los intercambios de archivos (lógicamente las sociedades miran por su lado).
La última barbaridad que se comenta es que se va a llegar a un acuerdo para que aquel que descarge tantos gigas al mes, se le baje su velocidad de conexión como castigo a su irresponsabilidad , con esto quiero decir que en nuestra España, donde tenemos la Banda Ancha más lenta y cara de toda Europa, donde nuestro operador hace y deshace cuando le viene en gana y sin dar explicaciones, ahora además va a incumplir el contrato que tiene con sus usuarios, reduciendo su velocidad cuando crea o adivine que nos estamos descargando archivos (independientemente de si estoy bajando mis parches de seguridad o la última canción de cualquier grupo famoso) y digo adivine porque para saber exactamente que estoy descargando tendrán que tener o bien una orden judicial o bien romperán la ley que protege las comunicaciones.
Esto sólo nos lleva a dos caminos, cifrar aún más todas las comunicaciones desde nuestra red hacia Internet, bien darnos de baja de nuestro operador y desviarlo hacia otro que no acepte estas normas dictatoriales.
Con esto queda en entredicho la neutralidad de la red y el enésimo intento de poner vallas al campo para controlar un medio que por sí mismo es independiente y que no puede ser controlado por ningún agente, gobierno o entidad.
En cualquier caso llama la atención que un país cuyos últimos años haya intentado promover la Sociedad de la Información hacia y para sus ciudadanos , siquiera piense en este tipo de actuaciones que lo único en lo que redunda es no en una disminución de la brecha digital, sino que nos separamos aún más de aquellos países como Japón cuyas líneas, tecnologías y precios están a años luz de los nuestros.
¿Estamos llegando a nuestro propio declive digital? ¿Deberemos volver al modem de 56K con el que algunos empezamos nuestras andanzas con aquél ente que era Internet?
El mundo del correo electrónico ha estado dominado desde los inicios por soluciones basadas en Software Libre. En un principio casi un 90% de los servidores de correo utilizaban el tan amado y odiado Sendmail. Poco a poco la oferta se ha ido diversificando con la aparición de muchas más soluciones tanto procedentes del software libre (Postfix, Qmail, Exim, etc..) cómo del privativo, asi cómo con la aparición de los grandes proveedores de servicios gratuitos de correo cómo gmail, hotmail y demás.Pero en esta ocasión no vamos a hablar de una implementación completa de un sistema de correo con software libre, que las hay y muy potenntes, sino sólo de una de las partes que pueden formar parte de un sistema de correo mediano/grande: los servidores frontales. Llamaremos frontales a los servidores encargados de recibir el correo desde el exterior y reenviarlo a su servidor de buzones correspondiente, así cómo de enviar el correo de los usuarios hacia internet. Resumiendo, los frontales serán la puerta de entrada y salida del correo de nuestra organización.
Pero, ¿cuales son las ventajas que nos ofrece destinar servidores a realizar esta tarea en lugar de conectar directamente nuestros servidores finales con el usuario?
Otra de las grandes ventajas de utilizar este sistema basado en servidores frontales es que podemos tener varios sistemas de correo dentro de nuestra organización: por ejemplo, un sistema basado en software libre (postfix, courier, etc..), otro basado en las soluciones de Microsoft y otro en soluciones de SUN, y tener una única via de entrada unificada para todos ellos, ofreciendo al usuario un único punto de entrada.Para la implementación de los servicios smtp de los frontales Postfix será nuestra opción preferida, ya que nos ofrece una solución muy potente, flexible y confiable. Así de forma fácil podemos ofrecer los siguientes servicios en nuestros servidores frontales: envío smtp autenticado y/o basado en redes de confianza, smtps cifrado mediante SSL o TLS, filtrado antivirus y antispam combinandolo con amavis, spamassassin, clamav y/o cualquier antivirus No vamos a detallar la configuración de Postfix en este post, pero únicamente indicar que para implementar un frontal que trabaje con distinto servidores de buzón únicamente necesitaremos utilizar la tabla transport de Postfix y poder definir así de forma sencilla el servidor de destino de los mensajes. Esta tabla puede estar implementada a través de un servicio de usuarios central cómo puede ser ldap o una base de datos y nos da la flexibilidad de trabajar a nivel de dominio o de usuario concreto. Así por ejemplo podríamos enviar los mensajes de usuarios más prioritarios a un servidor de buzón dedicado para ellos, reenviar por dominio todos los mensajes de las listas de correo a un servidor dedicado para ello o simplemente enviar el correo de cada usuario al buzón que le corresponda.Por otro lado y de cara a que la lectura de buzones también se realizara a través de los frontales y así ofrecer ese punto único de cara al usuario, podríamos utilizar un proxy pop/imap cómo Perdition. Perdition nos permite también utilizar una fuente de datos externa, cómo ldap, para determinar sobre que servidor de buzón debe realizar la conexión teniendo en cuenta qué usuario está intentando realizar la conexión.Andago ha llevado a cabo la implementación de este sistema de frontales en todas sus soluciones de correo electrónico implantadas en aquellos clientes que han requerido de un sistema confiable y escalable de correo con un éxito bastante elevado.
Varios años para definir un estandar como DVB-T, y sobre todo del estándar MHP para el desarrollo de aplicaciones de TV interactiva, para que ni siquiera el 3% del parque de decodificadores TDT y nuevas TV con decodificado incluido soportan el estándar MHP, según la Asociación Española de Empresas de Televisión Interactiva AEDETI (a la que pertenece Ándago). Millones de euros en I+D y el estándar MHP, que en realidad sólo servía para construir superteletextos avanzados, va a ser pasado por la derecha y seguramente nunca llegará a formar parte de las futuras aplicaciones de TV interactivas.
Yahoo, Intel, junto con los 5 principales fabricantes de TV como Samsung, LG, Toshiba, ... implementarán en cualquier TV de más de 1000 euros, y eso de momento, la plataforma Internet TV Widgets de Yahoo, junto con hardware de Intel. Dicha plataforma permite el desarrollo de widgets o miniaplicaciones basadas en estándares de desarrollo web como xml, web services, html. Dichos widgets podrán descargarse de Internet conectando el TV a tu conexión de banda ancha. Entre los widgets podrán realizarse widgets de noticias, de tiempo, de alquiler de peliculas, de eadmin, de asistentes sociosanitarios, etc.
http://connectedtv.yahoo.com/
Si suponiendo que todas estas nuevas TV tendrán Internet TV, además de TDT sin MHP, creo que la potencia y el resultado es que el MHP ha muerto antes de nacer. Finalmente se quedará para pequeñas aplicaciones de TV por pago y algún teletexto avanzado; el resto de los desarrolladores y fabricantes del mundo desarrollarán clientes ricos con Yahoo Widgets basados en la Web.
Seguro que pronto las compañías que desarrollamos software para servicios a los ciudadanos comenzamos a crear aplicaciones para este nueva iniciativa y que interactuen con las diferentes plataformas actuales.
Si no al tiempo.
La arquitectura en capas para la tecnología de servidor de las soluciones web de Andago se encuentra dividida en los siguientes niveles: Acceso, Aplicación y Persistencia. La capa de aplicación, encargada de implenetar la lógica de negocio, estaba bastante definida desde el principio y la elección fué Jboss. Una vez determinada esta capa debíamos seleccionar la forma en que las peticiones web llegarían hasta las aplicaciones dentro de Jboss, es decir la capa de acceso, y para ello se fijaron unos criterios deseables: buen rendimiento, alta disponibilidad, balanceo de carga, flexibilidad, facilidad de integración con la infraestructura de cliente, etc... La conclusión a la que se llegó fué la de utilizar un servidor Apache para servir las peticiones web y que este se comunique con Jboss a través de mod_jk.
Pero, ¿porqué añadir otro software para esta tarea cuando Jboss ya dispone de su propio servidor web, que ha mejorado en gran medida en los últimos años, igualando prácticamente a Apache en su rendimiento? Aquí van algunas razones:
Con esta arquitectura, Apache se encargaría de escuchar las peticiones web en el puerto 80, procesarlas en caso de que tengamos algún tipo de filtros, y enviarlas a Jboss a través de mod_jk utilizando el protocolo AJP. Este reenvio usando AJP optimiza el reenvío entre los dos servidores frente a la opción de hacer una nueva petición HTTP entre ambos. Ahora bien, si no tenemos cuidado a la hora de configurar el enlace entre Apache y Jboss podemos convertir en una tremenda desventaja nuestra elección. Aquí vienen algunos consejos, a modo de ejemplo ya que podrían aplicarse muchos más, a tener en cuenta cuando configuramos el enlace a través de mod_jk, y más concretamente cuando usamos la versión de jboss4.2.3-GA:
Cómo hemos visto, Apache puede ser un gran aliado de cara a implementar la capa de acceso a nuestras aplicaciones, pero debemos ser cuidadosos y aplicar una buena optimización en dicho enlace.
Dentro de la política de todo departamento de explotación de soluciones suele cobrar especial importancia la homogeneidad de las plataformas de despliegue de aplicaciones. En el mundo del desarrollo J2EE existen un elevado número de servidores (contenedores) de aplicaciones de contrastada reputación y múltiples funcionalidades, a la vez que existe una innumerable cantidad de servicios desarrollados que pueden ser desplegados en dichos servidores de aplicaciones. Dada la elevada oferta de contenedores, los desarrolladores de servicios (salvo en las soluciones respaldadas por una amplia comunidad) no suelen tener la posibilidad de probar sus desarrollos en cada uno de estos contenedores, y suelen optar por distribuir sus desarrollos en una modalidad conocidad como "bundle" en la que se distribuye su desarrollo junto con un servidor de aplicaciones e incluso una base de datos, lo que permite a los posibles usuarios del producto poder evaluarlo con un esfuerzo de puesta en marcha muy bajo. Este tipo de distribución es válida para la evaluación e incluso para los etapas iniciales de desarrollo sobre dicho producto, pero para las fases avanzadas de desarrollo y por supuesto para la puesta en explotación de dichas soluciones se requiere la integración del producto en la arquitectura de explotación de la compañía. En este artículo se expone el despliegue del servicio Apache ODE en el servidor de aplicaciones JBOSS 4.2.3, utilizando como base de datos PostgreSQL 8.1. ODE es un motor de orquestación que se ajusta a la especificación WS-BPEL 2.0. Se asume que en el momento de instalación del software ya se dispone servidor de aplicaciones JBOSS 4.2.3 completamente operativo. Los pasos necesarios para el despliegue son los siguientes: 1. Se descarga la distribución de tipo WAR del software "Apache ODE 1.2", en concreto "WAR Distribution - apache-ode-war-1.2.zip", y se descomprime: # wget http://apache.rediris.es/ode/apache-ode-war-1.2.zip # unzip apache-ode-war-1.2.zip 2. Dentro del paquete descargado, hay un fichero "apache-ode-war-1.2/ode.war" que es el servicio que hay que desplegar en el servidor de aplicaciones, y un directorio "apache-ode-war-1.2/sql/" con los scripts de creación de la base de datos. Comenzaremos con la gestión de la base de datos, dado que se va a utilizar PostgreSQL 8.1, se asume que se tiene instalada dicha base de datos, y para facilitar la prueba, se ha habilitado al usuario "postgres" para acceder a la máquina desde "localhost" a cualquier base de datos sin contraseña. El paso siguiente es crear la base de datos: # su - postgres # createdb ODEDB # exit 3. En el directorio "apache-ode-war-1.2/sql/" se encuentran scripts de creación de la base de datos para mysql.sql, oracle.sql y derby.sql, no habiendo ningun para postgres.sql, de modo que habrá que generar uno nuevo. El más compatible parece ser el fichero "derby.sql", pero falta alguna tabla necesaria y alguno de los tipos no es totalmente compatible (en concreto CLOB y BLOB) de modo que esos tipos hay que transformarlos en (TEXT y OID), y además es necesario incluir una consulta nueva, de modo que o bien utilizando una herramienta para reemplazar texto como "replace" o "sed" o bien con un editor de texto habrá que reemplazar los tipos en el fichero, y añadir la consulta nueva, usando: # cp apache-ode-war-1.2/sql/derby.sql apache-ode-war-1.2/sql/postgres.sql # replace BLOB BYTEA -- apache-ode-war-1.2/sql/postgres.sql # replace CLOB TEXT -- apache-ode-war-1.2/sql/postgres.sql # replace blob(4096) OID -- apache-ode-war-1.2/sql/postgres.sql # echo -e "\ncreate table LARGE_DATA (ID int8 not null, BIN_DATA BYTEA, INSERT_TIME timestamp, MLOCK int4 not null, primary key (ID));\n" >> apache-ode-war-1.2/sql/postgres.sql 4. Una vez que se tiene el script de creación lo siguiente es cargarlo en la base de datos utilizando: # su - postgres # psql ODEDB < apache-ode-war-1.2/sql/postgres.sql # exit 5. Dado que se va a utilizar la base de datos postgreSQL, es necesario instalar el conector JDBC3 para dicha base de datos en JBOSS (en este caso la versión 8.1, en la página web de postgreSQL hay conectores para otras versiones), lo que se realiza con los siguientes pasos: # wget http://jdbc.postgresql.org/download/postgresql-8.1-413.jdbc3.jar # cp postgresql-8.1-413.jdbc3.jar $JBOSS_HOME/server/default/lib/ 6. El siguiente paso es desplegar el fichero "apache-ode-war-1.2/ode.war" en el servidor de aplicaciones. Dado que para su uso en JBOSS es necesario realizar algunas modificaciones y crear varios ficheros de configuración se recomienda o bien desplegar de momento con el servidor de aplicaciones parado, o bien realizar los cambios en directorio a partir y luego desplegarlo. En primer lugar es necesario descomprimir el fichero, y eliminar dos de las librerias "xercesImpl-2.9.0.jar" y "geronimo-jta_1.1_spec-1.1.jar" (no necesarias y no compatibles con JBOSS) con: # cd $JBOSS_HOME/server/default/deploy # mkdir ode.war # cd ode.war # unzip ~/apache-ode-war-1.2/ode.war # rm -rf WEB-INF/lib/xercesImpl-2.9.0.jar # rm -rf WEB-INF/lib/geronimo-jta_1.1_spec-1.1.jar 7. Lo siguiente es crear un fichero de configuración para la aplicación en "ode.war/WEB-INF/conf/ode-axis2.properties", en el que se le indicará que se va a utilizar una base de datos externa junto con hibernate, y que tiene que utilizar ciertas clases para axis proporcionadas por JBoss, con el siguiente contenido: ode-axis2.db.mode=EXTERNAL ode-axis2.db.ext.dataSource=java:jdbc/ODEDB ode.persistence=hibernate # # the default tx factory is geronimo. org.apache.ode.il.EmbeddedGeronimoFactory # change it with the JBoss one. # ode-axis2.tx.factory.class=org.apache.ode.axis2.util.JBossFactory #ode-axis2.dao.factory=org.apache.ode.daohib.bpel.BpelDAOConnectionFactoryImpl # # Hibernate configuration # http://www.hibernate.org/hib_docs/reference/en/html/configuration-optional.html # hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect hibernate.hbm2ddl.auto=update hibernate.show_sql=true hibernate.current_session_context_class=jta hibernate.transaction.manager_lookup_class=org.hibernate.transaction.JBossTransactionManagerLookup
Además el parámetro "ode.persistence=hibernate" parece que JBoss no es capaz de leerlo, de modo que es necesario arrancar el JBoss definiendo ese parámetro, por lo que se recomienda modificar "$JBOSS_HOME/bin/run.conf" y añadir a la variable "JAVA_OPTS", lo siguiente "(-Dode.persistence=hibernate)":
JAVA_OPTS="-server -Xms256m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000"
8. A continuación se le debe indicar a la aplicación que se va a utilizar un "DataSource" para el acceso a la base de datos para lo que hay que editar la parte final del fichero "ode.war/WEB-INF/web.xml", descomentando la sección "<resource-ref>", y incluyendo en los campos los siguientes contenidos: <resource-ref> <res-ref-name>jdbc/ODEDB</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref> 9. En JBOSS es necesario definir la "<resource-ref>" en un descriptor de aplicación de JBOSS, para lo que es necesario crear el fichero "ode.war/WEB-INF/jboss-web.xml", con el siguiente contenido: <?xml version="1.0" encoding="UTF-8"?> <jboss-web> <resource-ref> <res-ref-name>jdbc/ODEDB</res-ref-name> <res-type>javax.sql.DataSource</res-type> <jndi-name>jdbc/ODEDB</jndi-name> </resource-ref> </jboss-web> 10. El siguiente punto es crear el fichero "DataSource", y desplegarlo en JBOSS. En dicho fichero que se incluyen los parámetros de conexión a la base de datos, el fichero a crear el siguiente "$JBOSS_HOME/server/default/deploy/ODEDB-ds.xml", con el siguiente contenido: <datasources> <local-tx-datasource> <jndi-name>jdbc/ODEDB</jndi-name> <connection-url> jdbc:postgresql://localhost:5432/ODEDB </connection-url> <driver-class>org.postgresql.Driver</driver-class> <user-name>postgres</user-name> <password></password> <min-pool-size>0</min-pool-size> </local-tx-datasource> </datasources> Una vez finalizados los pasos anteriores ya es posible arrancar el servidor de aplicaciones y ver el despliegue del servicio ODE en los logs del servidor de aplicaciones: 13:15:28,084 INFO [TomcatDeployer] deploy, ctxPath=/ode, warUrl=.../deploy/ode.war/ 13:15:29,856 INFO [STDOUT] DEBUG - GeronimoLog.debug(66) | Loading properties 13:15:29,861 INFO [STDOUT] DEBUG - GeronimoLog.debug(66) | Initializing transaction manager 13:15:29,862 INFO [STDOUT] DEBUG - GeronimoLog.debug(66) | Initializing transaction manager using org.apache.ode.axis2.util.JBossFactory 13:15:29,865 INFO [STDOUT] DEBUG - GeronimoLog.debug(66) | Creating data source. 13:15:29,891 INFO [STDOUT] DEBUG - GeronimoLog.debug(66) | Starting DAO. 13:15:29,893 INFO [STDOUT] INFO - GeronimoLog.info(79) | Using DAO Connection Factory class org.apache.ode.daohib.bpel.BpelDAOConnectionFactoryImpl. 13:15:33,434 INFO [STDOUT] DEBUG - GeronimoLog.debug(66) | Initializing BPEL process store. 13:15:33,720 INFO [STDOUT] WARN - SessionFactoryImpl.buildCurrentSessionContext(994) | JTASessionContext being used with JDBCTransactionFactory; auto-flush will not operate correctly with getCurrentSession() 13:15:33,722 INFO [STDOUT] DEBUG - GeronimoLog.debug(66) | Initializing BPEL server. 13:15:33,724 INFO [STDOUT] DEBUG - GeronimoLog.debug(66) | ODE initializing 13:15:33,771 INFO [STDOUT] DEBUG - GeronimoLog.debug(66) | BPEL SERVER initializing 13:15:33,809 INFO [STDOUT] DEBUG - GeronimoLog.debug(66) | BPEL SERVER starting. 13:15:33,838 INFO [STDOUT] INFO - GeronimoLog.info(79) | BPEL Server Started. 13:15:35,118 INFO [STDOUT] Hibernate: select this_.NAME as NAME37_0_, this_.deployer as deployer37_0_, this_.DEPLOYDT as DEPLOYDT37_0_, this_.DIR as DIR37_0_ from STORE_DU this_ 13:15:35,130 INFO [STDOUT] DEBUG - GeronimoLog.debug(66) | Initializing JCA adapter. 13:15:35,191 INFO [STDOUT] INFO - GeronimoLog.info(79) | Poller started. 13:15:35,192 INFO [STDOUT] INFO - GeronimoLog.info(79) | Process deployment polling started on path /opt/jboss-4.2.3.GA/server/default/./deploy/ode.war/WEB-INF/processes. 13:15:35,194 INFO [STDOUT] INFO - GeronimoLog.info(79) | ODE Service Engine has been started.
Esta obra está bajo una
licencia de Creative Commons.
Esta obra está bajo una
licencia de Creative Commons.