Xnoccio

Tras algunos meses de Milestones ya tenemos una versión estable de JBoss Rules 4.0. Para los que no conozcan JBoss Rules (antes llamado Drools ) es una plataforma que facilita la creación de sistemas expertos basados en conjuntos de reglas, siendo el núcleo de algunas de nuestras aplicaciones.

Aunque esta nueva versión llega un poco tarde para una de nuestras aplicaciones, en la que ya tenemos mas de 900 reglas definidas, en nuestra nueva plataforma de tramitación ya hemos realizado las modificaciones necesarias para que sus módulos de priorización, asignación de puntos y validación de expedientes utilicen las nuevas funcionalidades.

Las mejoras mas detectables son:

• Más velocidad y menor consumo de memoria que la versión 3.0, gracias a los nuevos concepto de memoria de trabajo stateful y stateless, y al nuevo sistema de evaluación y compilación.
• Un lenguaje de definición de expresiones mucho mas potente, que elimina algunas limitaciones muy serias que tenía la versión anterior. Destaca la potencia de MVEL y de las nuevas instrucciones from, fromAll, collect, accumulate.
• Un mejorado editor visual para Eclipse.
• Un nuevo repositorio de reglas basado en JackRabbit.

Antes reglas como la siguiente no podían ser definidas directamente sobre el motor de reglas y teníamos que recurrir a la manipulación de bytecodes utilizando CGlib para generar wrappers.

rule “Calculamos el total de presupuestos de todas las actividades”
when
expediente: DatoEntidad(name ==”Expediente”)
// Calculo del presupuesto total de todas las actividades del expediente
presupuestoTotal: Number() from accumulate( presupuesto: DatoNumerico(identificador ==”presupuesto”),sum(presupuesto.getValor()))
then
expediente.addProperty(new DatoNumerico(”presupuestoTotal”,presupuestoTotal));
end

El único inconveniente es la incompatibilidad con la versión anterior, ya que se han realizado profundos, aunque justificados, cambios en el API.

Podemos ver la lista completa de nuevas funcionalidades en http://blog.athico.com/2007/07/jboss-drools-40-released.htm.

Repositorio Maven en el que se encuentra: http://repository.jboss.com/maven2/org/drools/

Y no hablo del mosto señores. Hablo de un proyecto impensable para un pueblo de estas dimensiones, que comenzó hace no poco tiempo y ante el cuál más de uno éramos escépticos por motivos obvios: una obra demasiado grande para un pueblo pequeño.

Pero al final todo ha ido rodando y han cumplido, y el próximo 10 de Septiembre abre en Umbrete el complejo deportivo más grande de Sevilla, incluída la capital. Para que os hagaís una idea de las dimensiones de la obra consta de:

- Zona cardio-vascular y musculación 1040m2 (pedaaazo de gimnasio vaya).
- Salas de aeróbicos de 100m2 (las cintas de andar hasta con pantalla TFT).
- Saunas.
- Baños turcos.
- Piscina climatizada 25m.
- 2 piscinas para actividades.
- Sala de spinning.
- Pabellón polideportivo cubierto (y menudas canastas se gasta, colgadas del techo y con tablero de metacrilato).
- Pistas de Padel.
- Pista de Atletismo.
- Piscina exterior olímpica.
- Piscina infantil.
- Parking.
- Restaurante / Cafetería.
- Spa.
- Pistas de Tenis.
- Pistas polideportivas.
- Campos de Fútbol 7 con hierba artificial.
- Campo de Fútbol con hierba natural y gradas.

Por si fuera poco cuenta con un completo circuito termal que incluye:
- Circuito hidrotermal.
- Ducha de esencias.
- Hidromasaje.
- Pediluvio Compostela.
- Masajes.
- Saunas.
- Baños turcos.
- Chorro bitérmico.

Se organizarán no pocas actividades: Aerobic, Kinesis, Tonificación, Taichi…(así hasta 18) y habrá escuelas de Fútbol, Fútbol 7, Padel, Tenis, Baloncesto, Atletismo y Volleybol.

¿Quiere más? Contará con especialistas que te ayuden en tu entrenamiento tales como Monitores, Nutricionistas, Fisioterapeutas y un servicio médico.

Al darte de alta como socio te darán una llave electrónica codificada con los servicios contratados para tener acceso a las zonas oportunas y una taquilla donde dejar tus bártulos. El vestuario es prácticamente un campo de fútbol 7, y por supuesto cuenta con duchas individuales.

Existen muchas modalidades de suscripción, la más interesante sin duda la llamada “Tarifa Plana” que da acceso a todos los servicios a cualquier hora. Tiene por cierto un horario muy extenso, que incluye apertura Domingos y Festivos hasta las 15:00h.

Pues nada señores, como veís todo un sueño para los amantes del deporte y el ejercicio que abrirá sus puertas en poco más de 1 mes. Ya estamos tardando en organizar un partido oficial Viavansi de baloncesto, Fútbol 7 o cualquier deporte colectivo. Ya puestos, y si reunimos 22 personas, ¿hace un partido de Fútbol real? :-).

P.D.: no, no cobro comisión, pero no me digaís que el proyecto no es la leche.

Acabas de estrenar portátil, instalas tu Ubuntu, todo perfecto y cuando decides escuchar música mientras programas…¡esto no suena! ¿Cómo es posible que suenen los altavoces pero no la salida de auriculares? ¿Estará defectuoso mi portátil?

Que no cunda el pánico. Parece un fallo habitual en el controlador de sonido que Ubuntu incorpora para determinadas placas Intel que utiliza un chipset de sonido Realtek. El fallo depende por tanto de la placa base, y puede afectar a no pocos portátiles.

¿Y qué hago, molesto a los demás? Pues no señores, los chicos de ubuntuforums muy aplicados ellos nos dan la solución en este hilo:

http://ubuntuforums.org/showthread.php?t=76307

No merece la pena explicarlo, ya que viene perfectamente descrito cada uno de los pasos. Básicamente, bajar nuevos drivers, compilarlos, instalarlos y configurarlos…¡y los auriculares sonarán!

Ya puedes deleitarte con las obras completas de Mojinos escocios sin molestar a los demás.

¿Para que queremos un repositorio propio?

• Para agilizar los tiempos de descarga, manteniendo una cache de las librerías utilizadas.
• Para reducir los conflictos entre librerías, controlando en todo momento las librerías disponibles.
• Mantener un repositorio central en el que localizar las librerías de la empresa.
• Un uso mas eficiente de ancho de banda.

¿ Que opciones tenemos?

Tenemos varias posibilidades, aunque la mas adecuada es crear un repositorio mixto, que por un lado almacene las librerías internas de la empresa, además de las librerías y drivers que no esten disponibles en los repositorios de públicos y por otro haga de proxy de las librerías de los repositorios centrales Maven.

De entres las diferentes alternativas:

• El estandar maven proxy (codehaus) y DSMP se descartan por ser demasiado simple, sin administrado, ni navegador visual.
• Artifactory de los que he probado es el mas completo, no es un mero proxy, sino que tiene funciones de backup y de búsqueda de librerías.

Proceso de instalación

La instalación es muy sencilla:

• Nos descargamos la última versión estable de http://www.jfrog.org/sites/artifactory/latest/ , actualmente la versión 1.2.1
• Descomprimimos el zip en el directorio base elegido, en adelante $ARTIFACTORY_HOME.
• Configuramos Artifactory, modificando el fichero $ARTIFACTORY_HOME/etc/artifactory.config.xml, dejando como están los repositorios y modificando en nuestro caso solamente el backup para que se realice todos los viernes

<backupCronExp>0 0 24 ? * FRI</backupCronExp>

• Desplegamos el $ARTIFACTORY_HOME/webapps/webapps/artifactory.war en el Tomcat 5+.
• Antes de iniciar el servidor es necesario declarar la variable de entorno artifactory.home, para que artifactory.war sepa donde localizar el directorio home.

en mi caso: export JAVA_OPTS=-Dartifactory.home=/home/felix/java/artifactory-1.2.1

• Arrancamos el servidor.

Configuración

• Accedemos a la aplicación http://localhost:8080/artifactory y accedemos al sistema por primera vez con el usuario “admin”, clave “password”.

• Lo primero que hacemos es configurar el usuario administrador, en el menú security/user seleccionamos el administrador y modificamos su password. También creamos un nuevo usuario deployer sin permisos de administración.

• Hacemos una carga inicial de todas las librerias que usamos y no se encuentran disponibles en ningun repositorio público. Tambien es posible importar un repositorio ya existente.

• Ya estamos listos para empezar a utilizar el nuevo repositorio, modificamos el pom de nuestros proyectos para que utilicen por defecto este repositorio.

<repositories>
<repository>
<id>Viavansi</id>
<name>Viavansi Repositorio</name>
<url>http://localhost:8080/artifactory/repo</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>Viavansi</id>
<url>http://localhost:8080/artifactory/repo</url>
</pluginRepository>
</pluginRepositories>

El resultado

Probamos a ejecutar cualquier comando sobre nuestro proyecto, por ejemplo mvn clean eclipse:eclipse y comprobamos que las dependencias son descargadas desde nuestro nuevo repositorio.

Downloading: http://localhost:8080/artifactory/repo/javax/activation/activation/1.1/activation-1.1.jar
61K downloaded

Tambien podemos probar a buscar una dependencia concreta, como por ejemplo de búsqueda, buscamos el artifac myfaces y vemos sus dependencias:

Y lo mas importante, tenemos todas las dependencias de nuestros proyectos perfectamente organizadas y localizables.

Algunos problemas

En nuestro caso, ya teníamos en Viavansi un repositorio interno Maven que gestionábamos manualmente y que mantenia desde hace casi un año cientos de librerias congeladas, esto nos ha causado muchos problemas ya que TODOS los proyectos que han empezado a utilizar el nuevo repositorio han requerido algún tipo de modificación, ya sea por cambios en las dependencias transitivas, por nuevas versiones de librerías, o por librerías que hemos tenido que volver a desplegar. En resumen, aunque la instalación de Artifactory es muy sencilla, dependiendo de cantidad de proyectos, la adaptación al nuevo repositorio puede ser compleja, en nuestro caso fueron dos duros días solucionando dependencias.

Mas información en la faq de Artifactory y articulo en Ingles en Theserverside.com.

Hasta ahora el soporte de Web services de Java, aunque muy potente era muy rudimentario y complejo de configurar, requiriendo como podemos comprobar en el manual de Axis multitud de pasos y conocimientos. La nueva especificación jsr-181 que se ha añadido a Java 6 (JAX-WS 2.0) simplifica el desarrollo de servicios web, pero para los que se encuentren, como es mi caso atrapados aún en Java 5, XFire ofrece una implementación de dicha especificación, permitiéndonos simplificar el proceso dramaticamente.

A continuación un mecanismo sencillo para implementar un servicio Webservice gracias a Xfire y usando las anotaciones @WebServices, @WebMethod, @WebParam, @WebResult.

Configuración del sistema

• En primer lugar, declaramos en Maven las dependencias que necesitamos:

<dependency>
    <groupId>org.codehaus.xfire</groupId>
    <artifactId>xfire-java5</artifactId>
    <version>1.2.6</version>
</dependency>

• Modificamos el web.xml para declarar el servlet encargado de manejar las peticiones SOAP.

<servlet>
    <servlet-name>XFire</servlet-name>
    <display-name>XFire Servlet</display-name>
    <servlet-class>
        org.codehaus.xfire.transport.http.XFireConfigurableServlet
    </servlet-class>
  </servlet>

  <servlet-mapping>
    <servlet-name>XFire</servlet-name>
    <url-pattern>/servlet/XFireServlet/*</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>XFire</servlet-name>
    <url-pattern>/services/*</url-pattern>
  </servlet-mapping>

• Creamos el fichero de configuracion XFire localizado por defecto en /META-INF/xfire/services.xml, para indicar que clases Java van a ofrecer una interfaz webservice:

<beans	xmlns="http://xfire.codehaus.org/config/1.0">
	<service>
		<serviceClass>
com.viavansi.motorformularios.handler.MotorFormularioRemoteApi
		</serviceClass>
		<serviceFactory>jsr181</serviceFactory>
	</service>
</beans>

• Utilizamos anotaciones sobre la clase o interfaz que tiene los métodos que deseamos publicar como servicios web.

@WebService( name= “MotorFormularios”)
public interface MotorFormularioRemoteApi extends Remote {
@WebMethod(operationName=”execute”, action=”urn:ExecuteRequest”)
@WebResult(name=”response” )
public Response execute(@WebParam Request request) throws RemoteException;

• Arrancamos el servidor y comprobamos que efectivamente el servicio esta publicado y funciona correctamente accediendo a WSDL http://localhost:8080/services/MotorFormularios?WSDL

• Una vez publicado el servicio web, y suponiendo que tenemos las interfaces Java, ya no se requiere crear las clases proxy webservice. El mecanismo que podemos utilizar en el cliente es muy similar al utilizado con RMI, nos basta con conocer la interfaz java y la url del servicio web.

// utilizamos el conector WebServices.
Service serviceModel = new ObjectServiceFactory().create(MotorFormularioRemoteApi.class);

// recuperamos la interfaz webservice.
MotorFormularioRemoteApi rmiApi = (MotorFormularioRemoteApi) new XFireProxyFactory().create(serviceModel, url);

• Algunos problemas o limitaciones de esta solución:

La principal limitación de esta solución es que las peticiones codificadas como RPC no estan soportadas por XFire, por lo que para poder integrar con clientes Axis es necesario modificar el tipo de petición de RPC/Encoded a WRAPPED/Literal.

El control de errores en XFire es en ocasiones demasiado criptico, como ejemplo, en el caso de que el SOAP no se pueda procesar debido al problema comentado antes la excepción que se produce es: {http://xml.apache.org/axis/}stackTrace:Index: 1, Size: 1

Actualmente XFire aún no pasa el test de compatibilidad JSR 181 1.0 TCK.