Xnoccio

Con el título de este post poco más hay que explicar :-)

En la URL http://twitter.com/viavansi tenéis ya disponible el Twitter corporativo de VIAVANSI. A través de los tweets pondremos a disposición de todos noticias informales del día a día de nuestra empresa, el sector TIC, etc.

Invitamos a todos nuestros lectores a ser followers!

Namasté.

Aunque pueda parecer sorprendente, una de las principales novedades de la próxima versión 2.2 de Viafirma, que va a ser liberada en pocos días, es su integración con la plataforma @Firma v5.

Para el lector que no conozca @Firma (también conocido como aFirma), se trata de una plataforma de similares características funcionales a Viafirma, teniendo como principales responsabilidades el facilitar a terceras aplicaciones (que se integran con @Firma a través de un API cliente) el soporte de autenticación y firma digital con certificados digitales. Su desarrollo fue dirigido por la Junta de Andalucía, donde es la plataforma corporativa de autenticación y firma digital, y también así ha sido escogida por el MAP (Ministerio de Administraciones Públicas) como su herramienta base para este tipo de funcionalidades, cediendo su uso a cualquier de Administración Pública española. Hablamos por ello sin ninguna duda de una plataforma con una gran relevancia en el mercado y un más que importante número de implantaciones.

¿Por qué comentamos que “puede parecer sorprendente” esta nueva funcionalidad de Viafirma?  Pues porque, como el lector habrá advertido, en principio Viafirma y @Firma “se dedican a lo mismo”, es decir, a facilitar a aplicaciones el soporte de autenticación y firma electrónica. Entonces, ¿para qué integrar ambas plataformas?

La idea de su integración surge de la posibilidad de aislar responsabilidades dentro del proceso de autenticación y firma digital, haciendo que ambas plataformas interoperen en un ambiente SOA y se encarguen cada una de las funcionalidades en las que destacan. En nuestra empresa, VIAVANSI, hemos desarrollado una gran multitud de aplicaciones que se integran con @Firma para la Junta de Andalucía. Quizás podríamos destacar algunas debilidades que bajo nuestro punto de vista hemos advertido en esta plataforma:

• Su matriz de compatibilidad (a día de hoy la última es consultable en este enlace del portal Pluton de la Junta de Andalucía) es relativamente reducida para la Administración Pública, que busca poder dar servicio al 100% de la ciudadanía. Se quedan por ejemplo fuera de ella usuarios de Mac (como el que escribe), hemos observado problemas en función de las versiones de JRE, no hay actualmente soporte de Firefox 3, etc.
• La apariencia (look&feel) del cliente es mejorable.
• Cada aplicación que se integre con @Firma debe disponer en sus librerías del cliente de @Firma, y desarrollar código para utilizar dicho cliente. Ello implica que, cada vez que hay una actualización de este cliente de @Firma, hay que realizar un esfuerzo bastante importante de mantenimiento de aplicaciones para introducir el nuevo cliente, realizar los cambios que sean necesarios, probar y desplegar de nuevo las aplicaciones, etc.

Precisamente, esas debilidades son de hecho puntos fuertes de Viafirma, que la hacen sin duda destacar. Tal vez por ser una plataforma de desarrollo más reciente, Viafirma dispone de una enorme matriz de compatibilidad, pudiendo operar en prácticamente cualquier combinación de sistema operativo / navegador / versión de Java Runtime Environment (JRE) / autoridad de certificación / disposición del certificado (software, tarjeta -DNIe-, token)… Por ejemplo, firma en Mac sin problemas :-) Como ejemplo, en las dos primeras semanas de funcionamiento en la aplicación de “Acciones formativas de las Empresas” de la Fundación Tripartita para la Formación en el Empleo se superaron las 300.000 operaciones de autenticación y firma digital sin apenas incidencias. De hecho, el sistema “Acciones formativas de las Empresas” es probablemente, junto a las aplicaciones de Renta de la Agencia Tributaria, la aplicación pública con más operaciones de firma digital de España, ya que prácticamente cualquier empresa española puede ser usuaria del sistema.

Por otro lado, Viafirma incluye un concepto “push” de su cliente de firma, lo cual es una ventaja crucial para la estrategia de mantenimiento de aplicaciones. La librería cliente reside en un único nodo central (servidor de Viafirma), de forma que cuando se libera una nueva versión de dicha librería, sólo se debe realizarse la actualización en ese nodo. Todas las aplicaciones que utilicen el cliente quedan en ese momento automáticamente actualizadas, reduciéndose así enormemente el impacto de los nuevos desarrollos. Sin duda se evitan así fallos de actualización difícilmente controlables, redundando finalmente todas estas ventajas en la ciudadanía, que en todo caso es -somos- los usuarios de estos sistemas.

Esta nueva característica de Viafirma 2.2 permite utilizar la plataforma para las operaciones más relacionadas con el usuario de la aplicación (la detección y lectura de certificados,  y la operación de firma digital en local). Viafirma se comunica con los API’s Web Services nativos de @Firma para el resto de operaciones de núcleo: la validación de certificados con las CRL’s o servicios OCSP de las diversas autoridades de certificación, la custodia de los documentos firmados, etc.

De esta forma, se consigue una integración rápida y no intrusiva en “modo bridge”. Se podría decir que Viafirma se encarga de la “capa de cliente” del proceso, interactuando con el usuario y su almacén de certificados, y @Firma se encarga de la “capa de servidor”, responsabilizándose de la conexión con las diversas CA’s, la custodia de las firmas (opcionalmente), etc.

Las ventajas de este escenario son así muchas:

• Las instituciones disponen de un cliente de firma universal, que soporta prácticamente cualquier combinación de sistema operativo (Windows, incluyendo incluso la beta de Windows 7, Linux, Mac OS), navegador (Internet Explorer -6, 7 e incluso a nueva versión 8…-, Firefox-incluyendo la versión 3-, Safari, Google Chrome…), versión de JRE (5, 6, etc.), CA’s (FNMT, DNI-e, Camerfirma, ANCERT, Izenpe, Firma Profesional, ANF-AC, etc.), disposiciones (software, tarjeta incluyendo DNI-e, token, etc.)… La matriz de compatibilidad se ve ampliada en una gran magnitud, resultando principalmente favorecida la ciudadanía.
• El cliente de firma de Viafirma soporta incluso la utilización de un certificado exportado en formato P12 (formato de exportación usual en Linux o Mac) o PFX (este último típico de Windows), sin necesidad de importarlo en el almacén de certificados del sistema operativo o navegador. Un típico caso de uso sería, por ejemplo, que tengamos nuestro certificado personal exportado en un pendrive USB y queramos realizar una operación de autenticación o firma digital en un ciber-café, donde tal vez no tengamos permisos para instalar el certificado (o simplemente no lo deseemos por motivos de seguridad). El usuario puede escoger la ubicación del fichero P12 o PFX de una ruta local (como por ejemplo en ese pendrive), y utilizarlo así como si el certificado estuviese instalado en la máquina.
• Se reduce enormemente el coste de mantenimiento de aplicaciones, ya que como se ha comentado anteriormente el cliente de firma sólo reside en un nodo central y la actualización de versiones del cliente se realiza de forma automática en las aplicaciones.
• La institución mantiene su instalación de @Firma plenamente operativa, y en ella reside precisamente la responsabilidad de ejecutar operaciones críticas como la validación de los certificados (revocados, caducados, conexión a CRL’s y servicios OCSP, etc.), custodia de los documentos firmados, y en general, toda la lógica de servidor. Eso sí, la custodia podría ser opcional si se desea que los ficheros y/o sus firmas digitales sean custodiados por la aplicación o incluso por Viafirma, que soporta custodia en sistemas NFS, en ECM’s como Alfresco, y incluso en campos de base de datos tipo LOB.
• Se crea una disposición plenamente coherente con una política de interoperabilidad entre plataformas basadas en arquitecturas SOA, aprovechando los puntos fuertes de cada una de ellas, dispuestos a modo de servicio.

La nueva versión 2.2 de Viafirma además soporta el formato CMS y el formato 3.1 de factura-e e incluye otras actualizaciones menores.

Acaba de salir publicada la nueva versión 2.1.0 de Maven. Se pueden consultar las modificaciones incluidas en las Release Notes de la versión.

Está calentito calentito; esta misma semana empezamos a trabajar con esta versión, e iremos comentando las novedades que vemos. De momento os puedo anticipar que por fin las contraseñas almacenadas en el settings.xml están ofuscadas :-)

Como muchos de nuestros lectores sabrán, el día 19/03/2009 a las 18h se vio publicada la nueva versión 8 del navegador de Microsoft, Internet Explorer.

Viafirma ya soporta la autenticación y firma digital con el nuevo Internet Explorer 8, del mismo modo que es 100% compatible con las versiones beta publicadas de Windows 7.

Adjuntamos una captura de pantalla con una operación satisfactoria de firma realizada sobre este navegador.

En VIAVANSI estamos de enhorabuena, ayer lunes 16/03/2009 entró en producción la Aplicación de gestión de las Acciones formativas de las empresas, de la Fundación Tripartita para la Formación en el Empleo (antiguo FORCEM). En esta institución han escogido Viafirma para introducir las funcionalidades de autenticación con certificados digitales con multitud de CA’s como DNI electrónico, FNMT, IZENPE, Camerfirma, ANCERT, Firma Profesional, etc.

(more…)

Reciéntemente he estado revisando la arquitectura técnica de un proyecto Java EE que estaba teniendo serios problemas de escalabilidad. En Desarrollo todo iba como un tiro, pero con un número importante pero no escandaloso de registros (apenas 100.000) nos encontrábamos con tiempos de respuesta de algunas de las operaciones online que se podían ir a los 5 minutos. Obviamente esos tiempos no son admisibles para una operación web, por lo que urgía detectar fuentes de problemas y optimizar los procesos.

Realmente no había ninguna parte del código culpable al 100%, sino que la funcionalidad implementada, excesivamente flexible para el usuario,  le permitía a éste realizar búsquedas y operaciones que finalmente implicaban una sucesión de consultas, filtrados, operaciones de unión/intersección de listas enormes, persistencia…

Para muchas de las listas que se manejaban, se podía garantizar su invariabilidad en un tiempo elevado. Datos, por ejemplo, relativos a provincias. Por ello daba la sensación de que implementar una caché de estas listas, y sobre todo de los resultados finales después de las mencionadas operaciones de unión/intersección, etc., podría ser oportuno. Es cierto que Hibernate permite caché de resultados (y de hecho utiliza Ehcache), pero en este caso hablamos de resultados post-procesados, por lo que no sería suficiente.

Cachear objetos en una aplicación Java EE es algo básicamente trivial: siempre disponemos de la opción de ubicar el objeto en contexto de aplicación (ServletContext) y recuperarlo cuando queramos. Sin embargo esta aproximación no deja de ser algo “de juguete”. Decidimos utilizar Ehcache en primer lugar porque sabíamos que Hibernate sacaba un buen provecho de él, pero sobre todo porque, con un desarrollo extremadamente sencillo, obtenemos importantes ventajas funcionales como:

• Gestión de caducidad del contenido. Pasado un tiempo determinado, la caché elimina el objeto cacheado y comienza a devolver NULL a las peticiones posteriores. Nos elimina la responsabilidad de persistir el tiempo de vida de un objeto cacheado.
• Configuración del máximo número de objetos a cachear en memoria. Podemos dimensionar la cantidad de objetos que deseamos cachear en memoria. Ehcache se encarga de serializar a disco todo lo que le sobra, y recuperarlo cuando sea necesario. Ni que decir tiene que todos los objetos a cachear deberán ser serializables.
• Posibilidad de despliegue en cluster.
• Eliminación de la caché durante el shutdown del servidor de aplicaciones.
• ¡No reinventar la rueda!

Al final desarrollamos una sencilla clase tipo Manager, implementando el patrón Singleton, que interactúa con Ehcache. Y en determinadas zonas de la aplicación, invocar a la cache para recuperar los objetos que anteriormente se generaban online.

Paso a poner el código, que al final sin chicha esto se queda en nada :-) Eso sí, me gustaría recalcar que el proceso de 5 minutos al final, con un poco de cariño, ha pasado a responder en menos de 10 segundos. Una ganancia de un 3000%…

/*
* File: CacheUtil.java
*
* Created on march 2009
*
*
* Copyright 2006-2029 Javier Echeverría Usúa (javieu at gmail.com)
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*     http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
package com.viavansi.framework.core.cache;

import net.sf.ehcache.Cache;
import net.sf.ehcache.CacheManager;
import net.sf.ehcache.Element;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import com.viavansi.framework.core.persistencia.servicios.excepciones.ExcepcionServicio;


/**
* @author Javier Echeverria Usua (javieu at gmail.com)
* @author Felix Garcia Borrego (borrego at gmail.com)
* @author Alexis Castilla Armero (pencerval at gmail.com)
*/
public class CacheUtil {

public Object getCachedObject(String key) throws Exception{

if(minutosVidaDefault == 0)
minutosVidaDefault = MINUTOS_DEFAULT;

return getCachedObject(key, minutosVidaDefault);
}

public void putCachedObject(String key, Object info) throws Exception{

if(minutosVidaDefault == 0)
minutosVidaDefault = MINUTOS_DEFAULT;

putCachedObject(key, info, minutosVidaDefault);
}

public Object getCachedObject(String key, int minutosCache) throws Exception{

Cache cacheCustodia = getInstance(minutosCache);
Element element = cacheCustodia.get(key);
if(element != null){
return cacheCustodia.get(key).getValue();
}
else{
return null;
}
}

public void putCachedObject(String key, Object info, int minutosCache) throws Exception{

Cache cacheCustodia = getInstance(minutosCache);
cacheCustodia.put(new Element(key,info));
}

private Cache getInstance(int minutosCache) {
Cache cache = null;
//Todavía no existe
int timeTolife = minutosCache * 60;

CacheManager manager = CacheManager.getInstance();

String nombreCache = "viavansiCachedInfo" + minutosCache;

if (manager.cacheExists(nombreCache)) {
cache = manager.getCache(nombreCache);
} else {
// Configuramos el apagado en caso de Error de la JVM o parada inesperada.
System.setProperty("net.sf.ehcache.enableShutdownHook", "true");
manager.addCache(new Cache(nombreCache, 100, true, false, timeTolife, timeTolife));
cache = manager.getCache(nombreCache);
}

return cache;
}

public static void shutDown() {
CacheManager.getInstance().shutdown();
}

private int MINUTOS_DEFAULT = 60;

private static int minutosVidaDefault = 0;

protected CacheUtil(int minutosVida) {
minutosVidaDefault = minutosVida;
}

public static void init(int minutosVida) {
minutosVidaDefault = minutosVida;
}

/*
* Constructor y accesores
*/

// Patrón Singleton
private static CacheUtil singleton;

//Instancia de Commons Logging
private Log log = LogFactory.getFactory().getInstance(this.getClass().getName());

/**
* private constructor (solo una instancia).
* @return AmbitoBO
*/
protected CacheUtil() throws ExcepcionServicio {
super();
log.debug("Creando nueva instancia de CacheUtil");
}

/**
* Devuelve instancia activa de AmbitoBO.
* Típico método de implementación de patrón singleton
* @return AmbitoBO
* @throws ExcepcionServicio
*/
public static CacheUtil getCurrentInstance() throws ExcepcionServicio {
if (singleton == null) {
try {
singleton = new CacheUtil();
} catch (ExcepcionServicio e) {
throw e;
}
}
return singleton;
}

}

Un saludo a todos, y poned una caché en vuestros corazones :-P

Desde VIAVANSI, los redactores de Xnoccio os deseamos felices fiestas y que para el 2009 todo vaya bien o mejor. Gracias por vuestra fidelidad!

Este post no pretende ser más que una ayuda en castellano (encontrable vía Google) para aquellos que se encuentren con este problema en el futuro, ya que hemos encontrado bastantes referencias, pero pocas respuestas.

Los antecedentes

Nos encontrábamos en las instalaciones de un cliente, en un equipo Windows XP al cual le habíamos montado un kit de desarrollo completo: Eclipse (con diversos plugins), Maven, JDK, Tomcat’s de diversas versiones, etc., que tenía que integrarse con Hudson. En ese momento estábamos probando Maven sobre un sencillo proyecto de ejemplo; Maven debía descargar de un repositorio de librerías Artifactory recién descargado. Pero nos encontramos con efectos bastante raros:

• Al hacer un ‘mvn eclipse:eclipse’ en consola, observábamos que todos los JAR’s descargados daban un error de verificación de checksum.  Es decir, parecía ser que el contenido del JAR descargado no era exactamente el esperado. Y además no conseguíamos cargarnos la librería jline, una de las dependencias de las librerías de Plexus. Raro raro, porque nunca habíamos visto ese error. ¿Estaba pasando algo en algún repositorio público?
• Al hacer un’mvn clean’, algo mucho más raro todavía. Veíamos un log extrañísimo de repente saltaba un applet en pantalla que nos pedía confirmación de una operación. ¡Este plugin Maven nuevo!

Las pesquisas

Evidentemente aquí hay algo raro. En el log Maven aparecen mensajes que no habíamos visto hasta ahora:

Downloading: http://sanisidro:8080/artifactory/public/org/apache/maven/shared/ma
ven-shared-io/1.1/maven-shared-io-1.1.jar
116K downloaded
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'e67415a960
00a3110c7834caa325d965022491f6'; remote = '02e1d57be05ecac7dbe56a3c73b113e98f222
40f' - RETRYING
Downloading: http://sanisidro:8080/artifactory/public/org/apache/maven/shared/ma
ven-shared-io/1.1/maven-shared-io-1.1.jar
116K downloaded
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'e67415a960
00a3110c7834caa325d965022491f6'; remote = '02e1d57be05ecac7dbe56a3c73b113e98f222
40f' - IGNORING
[INFO] [clean:clean]
Current policy properties:
mmc.sess_pe_act.block_unsigned: false
window.num_max: 5
jscan.sess_applet_act.sig_trusted: pass
file.destructive.state: disabled
jscan.sess_applet_act.block_all: false
window.num_limited: true
jscan.sess_applet_act.unsigned: instrument
mmc.sess_pe_act.action: validate
jscan.session.daemon_protocol: http
file.read.state: disabled
mmc.sess_pe_act.block_invalid: true
mmc.sess_pe_act.block_blacklisted: false
net.bind_enable: false
jscan.session.policyname: TU1DIERlZmF1bHQgUG9saWN5
mmc.sess_cab_act.block_unsigned: false
file.nondestructive.state: disabled
jscan.session.origin_uri: http://repo1.maven.org/maven2/org/apache/maven
/shared/file-management/1.2/file-management-1.2.jar
mmc.sess_cab_act.action: validate
net.connect_other: false
jscan.session.user_ipaddr: 127.0.0.1
jscan.sess_applet_act.sig_invalid: block
mmc.sess_cab_act.block_invalid: true
thread.thread_num_max: 8
jscan.sess_applet_act.sig_blacklisted: block
net.connect_src: true
thread.thread_num_limited: true
jscan.sess_applet_act.stub_out_blocked_applet: true
mmc.sess_cab_act.block_blacklisted: true
jscan.session.user_name: 127.0.0.1
thread.threadgroup_create: false
file.write.state: disabled
-->> returning Frame NULL
BaseDialog: owner frame is a java.awt.Frame

Empezamos a pensar. Tras unos minutos de desconcierto, eso de jscan huele a antivirus. A ver si está haciendo algo, modificando los JAR’s al descargarlos, modificando alguna Java Policy, modificando la JDK, o incluso interactuando con las políticas de seguridad en runtime… efectivamente, buscando en Google nos lleva a comprobar que el culpable parece ser el antivirus de Trend Micro. Debe estar colocando el applet Java como medida de seguridad, interceptando el código original. El antivirus ha debido pensar que el JAR es un applet y, como hace operaciones de disco (un ‘mvn clean’ debe borrar ficheros), pide permiso. Pero, ¿qué y cómo lo está haciendo? Realizamos unas cuantas tareas:

• Paramos todos los servicios del antivirus. Probamos, sigue fallando. Este antivirus es un poco retorcido, ha debido modificar la JVM o alguna Java Policy.
• Restauramos la JVM, nos aseguramos de estar utilizando lo mismo. Sigue fallando, con el antivirus parado… ¿qué pasa aquí? ¿Dónde está la coleta de este Sansón de la seguridad?
• Probamos el applet de firma de Viafirma, que tampoco funciona. En la Java console observamos un error de un paquete com.trend (si al menos funcionara bien!)… El error era “Exception at com.trend.iwss.jscan.appscan.runtime …”. Nos bajamos el JAR de firma, lo descomprimimos y ¡voilá! Hay un buen conjunto de paquetes nuevos dentro de JAR. El antivirus modifica los JAR’s, lo cual explica todo: el misterioso applet del mvn clean, la rotura del applet de viafirma, los fallos de checksum… pero ¡el antivirus está apagado! ¿Cómo lo hace?

Las conclusiones

Si el antivirus en local no es culpable, debe haber un antivirus a nivel de red, junto al proxy. Efectivamente. El cliente, que por fortuna es técnico y de los que programan, no de los que sólo hablan, nos confirma que en muchas ocasiones ha tenido que utilizar otro proxy para descargarse JAR’s. El invento enemigo de los JAR’s no afecta sólo a Maven, obviamente, sino a cualquier JAR descargado por un proxy que disponga de este mecanismo de seguridad, y que realice determinadas operaciones. De hecho la librería JLine era parada por este producto llamado “Trend Micro InterScan Web Security Suite” que, de hecho, publicita este servicio tan majo y maligno a la vez.

Así que si en algún momento os encontráis este tipo de errores tan extraños, ya tenéis otra posibilidad latente.

El epílogo

Nos cambiamos de proxy y todo fue bien, previa limpieza del repositorio de librerías Maven.

El algoritmo Haversine sirve para calcular la distancia entre dos puntos de los que conocemos su longitud y latitud. A continuación incluimos un método Java que implementa esta fórmula devolviendo la distancia en metros:

    private static int calculateDistanceByHaversineFormula(double lon1, double lat1,
double lon2, double lat2) {

return (int)distanceInMeters;

}

En nuestro caso ha sido utilizado para evaluar la distancia a un establecimiento determinado desde nuestra posición actual (calculada mediante GPS).

De forma muy resumida, OpenSearch es una colección de formatos abiertos y estándares desarrollados por A9 (Amazon), que persiguen resolver 2 escenarios principalmente:

• Caso 1: Permitir a una aplicación publicar de una forma estándar resultados de búsqueda; estos resultados pueden ser consumidos posteriormente por una aplicación cliente. Se basa en un metamodelo estandarizado publicado bajo una fuente de sindicación estándar como RSS o Atom. Podemos ver un ejemplo de resultado de búsqueda en formato OpenSearch en esta URL de indeed.com.
• Caso 2: Describir (autodescribir) servicios de búsqueda. Es lo que utiliza por ejemplo Firefox 3 para ofrecernos búsquedas inteligentes.

En este post vamos a describir cómo leer resultados de búsqueda en formato OpenSearch (caso 1). Para el caso 2, recomendamos la lectura de un post de 11870.com que describe a la perfección cómo describir nuestro buscador.

Si nos fijamos en el código fuente de respuesta de la URL comentada de indeed, veremos que en este caso se está devolviendo sobre RSS una información general sobre la búsqueda más un conjunto de resultados de búsqueda (items), los cuales pueden ser incluso geolocalizados.

En Java, este RSS (o Atom) podría ser leído con cualquier intérprete de XML, o mejor con alguna librería específica de este tipo de feeds, como Rome o Apache Abdera, o mejor aún, con librerías específicas para OpenSearch. En nuestro caso, debíamos leer la respuesta del API de 11870.com, dentro de un proyecto en el cual deseábamos proponer establecimientos propuestos por los usuarios que estén cercanos a nuestra localización.

A este respecto, cuando he hecho la búsqueda de librerías Java, personal he tenido una sensación agridulce. Si bien los desarrolladores Java solemos ser unos verdaderos privilegiados en cuanto a lo que se refiere a disposición de API’s, en ciertos casos relacionados con web semántica o API’s de web 2.0 tengo la sensación de que otras arquitecturas de desarrollo como PHP, Python o RoR a veces tienen cierta ventaja. En el caso de Java todo son versiones de incubadora, 0.X, etc.

En el caso de librerías Java, una rápida búsqueda nos llevó a decidirnos entre Rome (Sun) y Apache Abdera, escogiendo este último por disponer de mejores ejemplos de los que partir. Además dentro de los committers de Abdera está el supercrack David Calavera, desarrollador de la omnipresente 11870.com.

A continuación incluiremos unos pequeños recortes de código que muestran como leer la respuesta OpenSearch mediante Abdera. En primer lugar, necesitaremos disponer de las librerías. Para ello (en el caso de Maven) incluiremos estas dependencias en nuestro pom.xml:

<dependency>
<groupId>org.apache.abdera</groupId>
<artifactId>abdera-client</artifactId>
<version>0.4.0-incubating</version>
</dependency>

<dependency>
<groupId>org.apache.abdera</groupId>
<artifactId>abdera-extensions-opensearch</artifactId>
<version>0.4.0-incubating</version>
</dependency>

Para poder resolver estas dependencias incluiremos los repositorio Incubating y Snapshot de Apache dentro de <repositories>:

<repository>
<id>apache-incubating</id>
<name>Apache Incubating Repository</name>
<url>http://people.apache.org/repo/m2-incubating-repository/</url>
</repository>
<repository>
<id>apache-snapshots</id>
<name>Apache Snapshot Repository</name>
<url>http://people.apache.org/repo/m2-snapshot-repository/</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
</repository>

Dado una dirección URL (String urlQuery) donde esté publicada una consulta que responde OpenSearch, podremos invocarla con el siguente código:

Abdera abdera = new Abdera();
Parser parser = abdera.getParser();
URL url = new URL(urlQuery);
Document<Feed> doc = parser.parse(url.openStream(), urlQuery);
Feed feed = doc.getRoot();

Podemos recuperar ciertas propiedades de la respuesta de OpenSearch:

IntegerElement totalResults = feed.getExtension(OpenSearchConstants.TOTAL_RESULTS);
int resultados = totalResults.getValue();

Del mismo modo se pueden recuperar datos como el número de items por página (OpenSearchConstants.ITEMS_PER_PAGE) o el índice inicial de la respuesta, útil cuando hay paginación (OpenSearchConstants.START_INDEX. Es decir, podemos obtener datos OpenSearch del feed mediante feed.getExtension().

A continuación mostramos cómo iterar los items de respuesta del feed:

for (Entry entry : feed.getEntries()) {

    System.out.println(”Title: “+entry.getTitle());
    System.out.println(”Summary: “+entry.getSummary());
    System.out.println(”Id: “+entry.getId().toString());
    System.out.println(”Id: “+entry.getId().toString());

}

También podemos evaluar para cada item (resultado de búsqueda) el valor de extensiones a OpenSearch. Por ejemplo, podemos pretender recuperar los datos de geolocalización en formato GeoRss. Para ello utilizaríamos un código como el que sigue:

QName qnameWhere = new QName(”http://www.georss.org/georss/10″,”where”, “georss”);
Element where = entry.getExtension(qnameWhere);
try {
String geoPos = where.getFirstChild().getFirstChild()
.getText();
String[] posicion = geoPos.split(” “);
if (posicion.length == 2) {

System.out.println(”latitud: “+posicion[0]);
System.out.println(”longitud: “+posicion[1]);
}
} catch (Exception e) {
e.printStackTrace();
}

Es decir, podemos recuperar el valor de un parámetro de una extensión invocando a entry.getExtension, pasando como parámetro un objeto de tipo QName, instanciado como indicamos en el código anterior.

En definitiva, hemos hecho una breve introducción a OpenSearch y mostrado código de ejemplo para interactuar con una respuesta OpenSearch mediante Apache Abdera.