Diario de Programación

Algo con lo que también ando liado últimamente. Ofrecemos Web Services sobre https y requerimos que el cliente que intente usarlos presente un certificado digital para poder acceder a ellos, pero no usando WS-Security, sino sobre el mismo protocolo https.

El montaje y la serie de artículos a lo que todo este trabajo ha dado lugar es el siguiente.

Por un lado, montar un Apache http server y un Apache Tomcat. El segundo es el que contiene el war con nuestros web services. El primero, el apache http server, únicamente redirige las entradas de los clientes hacia el tomcat, y también es el que tiene su certificado y acepta o rechaza los certificados de los clientes.

Una vez hecho este montaje, viene la parte de hacer el código de cliente del web service. Para ello uso la librería Apache CXF.y este es el código para conseguir que un cliente CXF pueda presentar su propio certificado de cliente al servidor y a su vez acepte o rechace el certificado del servidor. Y bueno, este ya es problema particular mío, pero también tuve que conseguir que el cliente CXF saliera a través de un proxy corporativo.

Y aparte de todo esto, un pequeño conjunto de artículos más básicos que han ido saliendo sobre web services.

En fin, cogidas por los pelos, pero he aprendido un montón de cosas.

Estamos instalando un jUDDI para ofrecer este servicio en nuestro proyecto y desde luego, la experiencia no está siendo demasiado buena. Funciona bien una vez instalado, pero la instalación es un pequeño infierno.

De primeras, de los descargables que nos ofrece, el war para tomcat no funciona, le faltan un montón de librerías. El siguiente, jUDDI con portal, tampoco va. Al final el que funciona es el "bundle" con portal, que es un tomcat completo listo para arrancar. Pero claro, yo tengo ya mi propio tomcat ….

Y luego viene el asunto de configurar los usuarios que tienen acceso, no desde el portal de jUDDI sino a los web services que ofrece, y la documentación parece muy clarita. La propiedad juddi.auth=org.apache.juddi.auth.JUDDIAuthentication hay que cambiarla por juddi.auth=org.apache.juddi.auth.XMLDocAuthentication, aparte de añadir otra propiedad con el fichero XML con los usuarios. Pues bien, esa clase org.apache.juddi.auth.XMLDocAuthentication NO existe. La clase correcta es org.apache.juddi.v3.auth.XMLDocAuthenticator, con un v3 por el medio y acabada en ator en vez de ation. La encuentras si montas todo en eclipse y buscas la clase XMLDOCAu… y dejas que te autocomplete.

Por cierto, ando liado en inglés con la gente de los otros países y se poco inglés, afortunadamente sólo es por correo. Y he aprendido que al empezar el correo, "Dear," o "Pedro," se usa con gente con la que se quiere mantener las formas, mientras que "Hi," o "Hello," es para gente con la que tienes confianza. Me chocaba eso de recibir "Dear" en todos los correos. Y nosotros usamos dos puntos detrás (Querido Federico: ), parece que en inglés se lleva poner coma.

Y lo mejor de todo es que ninguno de los de los correos es inglés, hay de todo, menos nativos en inglés.

 El proyecto en el que ando metido es un proyecto de lo más extraño. Son seis paises europeos, cada uno tiene que hacer un portal web y todos estos portales web deben compartir datos entre ellos. Debe ser distribuido, por lo que ninguno de los servidores es más importante que los demás ni tiene centralizada la información. Así que la forma que se ha pensado es que cada portal web vaya a su bola con su propia base de datos y sus propios usuarios, pero que todos ellos ofrezcan unos web services de forma que puedan consultarse datos entre ellos.

¿Y qué es lo extraño?. Pues nada especial, sólo lo de siempre. El portal es relativamente sencillo, no es nada que un "friky" que sepa no pueda hacer en su casa en uno o dos meses de trabajo … pero la coordinación de todo esto es un infierno. Seis cliente de seis países distintos cada uno con su propia empresa contratada. Cualquier decisión por pequeña que sea que afecte a la interfaz de intercambio requiere una lista interminable de correos o incluso esperar a ser decidida en alguna de las reuniones internacionales que se hacen de vez en cuando. Al final ya veo por qué muchos proyectos no son rentables, se paga excesiva gestión, excesivos gestores y demasiada reunión cara. Al final la historia del remero y los supervisores va a ser cierta.

Y así estamos, desarrollando nuestra parte del portal, pero medio bloqueados/jugando con la parte de los web services en espera de interfaz definitiva, protocolos de seguridad definitivos, etc.

Así que en eso es en lo que estoy ahora, jugando con los web services y distintos temas de seguridad: WS-Security, http basic authentication, SAML, etc. Y a resultas de eso y como me gusta escribir todos los "hola mundos" de prueba que hago, salen una serie de tutoriales de web services en la chuwiki.

Por cierto, jugando con metro y con CXF, al final me quedo con CXF. ¿Por qué?. Metro me ha dado un par de problemas extraños en un par de ocasiones. Uno por incompatibilidad de librerías que tiran de librerías que tiran de librerías y el otro no lo tengo muy claro por qué me ha dado el error, pero el mismo código/wsdl funciona sin problemas con CXF. Aparte, me gusta mucho más la documentación de CXF que la de metro.

Y la culpa es del remero.