Javi Sanromán

Como ya te habrás dado cuenta estoy bastante retrasado con esta colección de artículos, este lo tengo pendiente desde hace varias semanas, y el próximo no creo que llegue hasta finales de junio que finalizo el semestre en la uoc con 2 puñeteros exámenes. Ese fin de semana lo aprovecharé para disfrutar de un par de días sabáticos por A Coruña, que ya va haciendo falta, y volver cargado de energía.

Estoy planteándome desde hace un tiempo instalar un wiki en este espacio para dejar estos ejemplos y otra información inclasificable bien documentada, cualquier decisión será después de los famosos exámenes, también te tendré al tanto.

Struts ya era un conocido para mi, lo había utilizado en interacción, la última vez hace unos meses antes de irme, por eso que pocas cosas me sorprendieron en esas semanas.

Comenzamos con las explicaciones básicas, un framework que cumple el modelo MVC, que cuenta con una madurez y estabilidad muy valorada por todos, que ha sido de los primeros en aparecer y que ha sido el framework con mayor acogida en el mundo j2ee hasta la fecha. Ahora ya le han salido contrincantes.

Continuamos con los ejemplos básicos, struts-config.xml donde configuramos la navegación, definimos los formularios, definimos nuestro servlet que actúa como controller. Como segregar la configuración de nuestras acciones en diferentes xml. Ejemplos de internacionalización, en ficheros .properties o en .xml. Definición y uso de los filtros de preprocesado, el patrón frontcontroller. El patrón Facade. ActionForm para la definición de nuestros formularios. Uso de las propias librerías de struts para las validaciones. Las plantillas tiles en struts.

En estas semanas ya posteriores a struts estamos viendo spring (el cual hemos aprovechado para introducirnos en la programación orientada a aspectos AOP), y hemos hecho un par de ejemplos con appfuse y struts2.

Como ves da para mucho, y mi tiempo es escaso, asi que mientras sigo pensando en la idea del wiki y en como dejar documentada toda esta información voy a centrarme en mi asignatura de “análisis matemático” que se me está haciendo muy cuesta arriba. Paciencia, en un par de semanas tendrás noticias mías.

Nunca es tarde si el post llega.... bueno era algo así ¿no?. El caso es que después de bastante tiempo he aprovechado este puentecillo en el que tampoco tendremos curso para quitar este post atrasado.

En esta 5ª semana llegó el fin de los ejb's con un último ejemplo de ejb de mensaje (jms) que no voy a reproducir pues es muy parecido al ejemplo del post anterior. Y a continuación comenzamos con los servicios web, esa tecnología tan inmadura (por lo que cuidadín con las elecciones, cambios continuos y en general un jaleo de nombres, apis, versiones...) como de moda últimamente. Eso si!!, sin antes perder 3 horillas en una creo que inútil charla de igualdad de género a la que la xunta nos obliga en todos los cursos que financia, en fin, creo que los burros a esta edad seguirán siendo burros, y tampoco me parece el marco ideal para dar estas lecciones, opinión muy personal por supuesto.

Los servicios web son un conjunto de tecnologías (independientes de lenguaje y plataforma) que nos permiten el intercambio de datos entre diferentes máquinas conectadas a través de una red. Lo típico es utilizarlos bajo http (pues junto con su estándar son las dos grandes ventajas aportadas) y eliminar así los efectos de los firewalls (seguro que alguna vez habéis topado con uno). De todas formas os dejo un par de enlaces donde explican mucho mejor que yo:

http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
http://es.wikipedia.org/wiki/Servicio_Web

Un breve esquema (desde el w3c):

Vemos la aplicación cliente que se conecta con el servicio web, envía datos a través de mensajes SOAP según las reglas descritas en el "contrato" WDSL.

En java tenemos api's y herramientas que nos ayudan a crear y desplegar servicios web. JAX-WS (que forma parte del proyecto glassfish y agrupa entre otras a SOAP 1.2, WSDL 1.1, WSDL 2.0, JAXB 2.0) nos abstrae de las tareas básicas para crear un servicio web. Nos aporta 2 buenas utilidades wsgen y wsimport que nos permitirán generar de forma automática los artefactos necesarios para generar nuestro servicio y las clases proxy que representarán el servicio web en local para los clientes. Luego a través de anotaciones, como viene siendo habitual, indicaremos que clase representa nuestro servicio, que propiedades se corresponden con los tags de nuestros xml, etc:

Un par de sencillos pero útiles ejemplos:
http://java.sun.com/developer/technicalArticles/J2SE/jax_ws_2/
http://java.sun.com/developer/technicalArticles/J2SE/jax_ws_2_pt2/

Y para terminar necesitamos un servidor que soporte jax-ws, en realidad nos serviría el propio tomcat, pero yo sigo trabajando con jboss así que me tocó instalar el soporte jax-ws que nos provee el paquete jbossws:
1- Descargamos jbossws.
2- Descomprimimos y renombramos ant.properties.example por ant.properties.
2- Editamos ant.properties y modificamos la propiedad jboss422.home indicando el directorio de nuestro jboss.
3- Ejecutamos ant deploy-jboss42 (mi versión es la 4.2 sino la que toque).
4- Iniciamos jboss y comprobamos en la dirección http://localhost:8080/jbossws/ que se ha instalado el soporte jax-ws en nuestro jboss.

Con esto ya tendríamos jboss preparado para desplegar servicios web, ahora solo nos falta hacer unas pruebecillas, quizás en otro post...

Lo prometido es deuda y ahora q se me ha pasado la vagancia y además tenía un ratillo libre (combinación compleja donde las halla) os dejo un ejemplo de un ejb sin estado (stateless).

Yo he utilizado jboss en su última versión estable (4.2.2.GA) como contenedor del ejb, para utilizarlo solo teneis que descargaros una copia y arrancar ejecutando /bin/run.sh, ¿fácil verdad?. Podriamos haber utilizado glassfish, que en ubuntu se queda la instalación en un maravilloso apt-get install glassfish, pero si os parece eso lo dejamos para otro día.

Vamos con nuestro ejb.

Primero nos creamos el bean que encapsula toda nuestra lógica de negocio. En este caso tendremos solo 2 métodos, para sumar y restar 2 números (operaciones básicas de toda calculadora).

Destacar el uso de la anotación @Stateless para indicar el tipo de ejb que estamos creando.

A continuación creamos las interfaces CalculadoraLocal y CalculadoraRemote para indicar que métodos serán accesibles desde el propio contenedor o desde fuera y que serán implementadas por nuestro bean anterior.

En nuestro caso solo nos interesa acceder desde remoto pues haremos las pruebas desde un script fuera de nuestro contenedor.

Ya tenemos nuestro ejb creado, lo empaquetamos en un .jar (tareilla ant) y lo soltamos en jboss/server/default/deploy. Si nos fijamos en el log de jboss podremos averiguar si se ha producido algún error, pero para estar completamente seguros nos vamos a la jmx-console http://localhost:8080/jmx-console/ y comprobamos si se ha cargado nuestro ejb, en mi caso aparecen estas lineas que indican que está listo para ser utilizado:

# jar=ejb3_stateless_calculadora.jar,name=CalculadoraBean,service=EJB3
# module=ejb3_stateless_calculadora.jar,service=EJB3

Llegados a este punto tan solo nos queda desarrollar un sencillo cliente que haga uso del ejb recién creado. Con una simple clase que muestre el resultado por consola es suficiente para esta prueba:

Simplemente destacar la linea contexto.lookup(CalculadoraBean.RemoteJNDIName); causa de posibles rompederos de cabeza y que nos da acceso a nuestro ejb.

Ala y ahora a hacer pruebas con los diferentes ejb's, el ejb-ql, a probar desde otra máquina, y lo que se nos ocurra.

Como aventuraba en el anterior post de esta serie, esta semana hemos comenzado con ejb. Después de una introducción donde se repasaron las complejidades de ejb2 y su posterior evolución a ejb3, nos centramos únicamente en ejb3 y en desarrollar algún que otro ejemplo utilizando como contenedor a jboss.

EJB forma parte de j2ee desde su versión 1.1 y mediante su especificación se detalla cómo los servidores de aplicaciones proveen objetos desde el lado del servidor. Utilizando ejb creamos componentes que encapsulan lógica de empresa y estos pueden ser de 3 tipos: de entidad, de session (con estado y sin estado) y dirigidos por mensajes.

Los componentes desarrollados bajo la especificación ejb deben ser desplegados en un contenedor de ejb para su uso. Este contenedor no es mas que una aplicación que normalmente reside en el servidor de aplicaciones y que provee de servicios a nuestros componentes (persistencia, transacciones, seguridad, servicios de red, etc).

No debemos confundir Enterprise Java Beans con Java Beans. Mientras que los primeros son componentes que almacenan lógica de empresa y deben ser desplegados en un contenedor de ejb con el que se comunica para hacer uso de sus servicios, los segundos utilizan una arquitectura para desarrollar componentes con fines generales agrupando datos y funcionalidades comunes y pueden ser ejecutados en cualquier entorno java.

Ejb2 es complejo (múltiples descriptores de despliegue para un ejb, creación de múltiples interfaces, múltiples callbacks usualmente inutilizados). Ejb3 simplifica notablemente el desarrollo, ahora los ejb son POJOs, simplifica la configuración mediante el uso de anotaciones en lugar de descriptores de despliegue, soporte de inyección de dependencias, mejoras en el lenguaje de consultas EJB-QL, no necesitamos tener interfaces de componentes para los ejb's.

En la web de jboss tenemos una interesante colección de ejemplos ejb3.

Y en la misma web un completo manual sobre ejb3.

A ver si el próximo día dejo algún ejemplillo que hoy estoy un poco vago :-).

Comenzamos los dos días de esta semana con una pequeña introducción por las principales características de los principales frameworks de persistencia: EJB, JDO, Hibernate, JPA.

Pero una vez pasada esta breve introducción la chicha fué hibernate, que nos ocupó prácticamente los dos días completos.

Hibernate como todo ORM surge por la necesidad de solucionar la existencia de 2 paradigmas diferentes: Modelo de objetos - Modelo relacional. Hibernate es libre, lleva mucho tiempo en el mercado y ha alcanzado un gran estado de madurez, utiliza ficheros xml para mapear las relaciones entre BD y objetos aunque en su última versión 3.0 incluye el uso de anotaciones como alternativa. Hibernate nos ahorra escribir mucho código, emplea POJOS para leer y escribir de la BD y cuenta con un potente lenguaje de consultas "HQL" para aquellas situaciones mas particulares o complejas. Como principal inconveniente un rendimiento necesariamente más bajo que utilizando unas buenas consultas jdbc.


Para comenzar con hibernate necesitaremos el driver jdbc de nuestro motor de BD y el hibernate.jar. A partir de aquí creando los ficheros de configuración ya podemos comenzar a realizar ejemplos básicos.

Debemos saber que el fichero principal de configuración de hibernate es hibernate.cfg.xml que tendrá una estructura como esta, en la que por ejemplo especificamos los parametros de nuestra conexión:



La comunicación con el motor de Hibernate la haremos mediante un objeto Session, pero para obtenerlo utilizaremos 2 classes mas: SessionFactory (que contiene los metadatos e información de clases java), Configuration (para la configuración de hibernate: ficheros de mapeo, dialecto de bd..., también inicia hibernate y nos da el acceso al SessionFactory).



Un ejemplo muy sencillo:

Ahora que ya tenemos configurada la conexión con nuestro motor de BD a través de hibernate, nos toca crear nuestro modelo de objetos y mapear los xml para asociarlos al modelo de BD. Hibernate utiliza Java Reflection para acceder a las propiedades de nuestros objetos, por lo que cada propiedad debe tener sus correspondientes getters y setters, y cada clase de nuestro modelo su propio constructor vacío.Una vez tenemos nuestro modelo de objetos construido debemos crear un fichero xml por cada objeto (si mapeamos la relación con la BD a través de anotaciones no sería necesario) por convención lo llamaremos NombreObjetoAMapear.hbm.xml. En este enlace tenemos toda la información sobre la sintaxis necesaria en estos xml para poder mapear cualquier tipo de relación. No nos olvidemos de que todos estos xml de mapeo deben referenciarse en el hibernate.cfg.xml de la siguiente forma:

A partir de aquí ya podemos comenzar a investigar y hacer todas las pruebas necesarias para conocer hibernate mas a fondo: consultas de selección, actualizacion, insercción, eliminación, con HQL, components (misma fila BD a varios objetos; varias filas BD a un objeto), tipos de relaciones (many-to-one; one-to-many; one-to-one; many-to-many), el atributo cascade (save_update; all-delete-orphan), utilizar anotaciones en lugar de xml, etc.

Como conclusión comentar que me ha gustado trabajar con hibernate, me parece mucho mas productivo que la utilización de DAOS al ahorrarnos escribir una buena cantidad de código repetitivo, y la curva de aprendizaje para comenzar a obtener resultados es realmente baja. Para situaciones complejas siempre podemos utilizar su lenguaje de consultas HQL o el propio SQL.

Creo que la semana que entra le tocará a EJB, ya os contaré.

Este post será el primero de una serie dedicada a contaros lo que voy haciendo en este cursillo al que estoy asistiendo, como os comentaba hace 2 días.

Principalmente me servirán a mi como referencia, por lo que dejaré bastantes enlaces sobre las herramientas que vamos utilizando, y posiblemente en ocasiones los pasos necesarios para realizar determinadas tareas o algún que otro ejemplo de código.

Estas 2 primeras semanas han sido de introducción al mundillo para ir entrando en materia y conocernos un poco, aunque ya se han visto herramientas interesantes:

Hemos comenzado a trabajar con el tomcat 5.5, ya sabeis no? las aplicaciones se recargan automáticamente en webapps sin dar de alta contextos ni ná, cuidadito con los jsp's y la caché almacenada en work, iniciamos/paramos en bin/startup bin/shutdown, mas adelante supongo que veremos como configurar los dominios virtuales, las variables de inicio en catalina.sh. Del tomcat creo que no mucho mas.

Hemos utilizado eclipse como IDE. Yo para trabajar con j2ee siempre me había sentido mas cómodo con netbeans pero ahora ya le estoy cogiendo el truquillo.

Vimos el ciclo de vida de todo servlet:

Probamos a cargar recursos para internacionalizar nuestras aplicaciones:

La sintaxis del web.xml.

En un principio compilamos los servlets desde la línea de comandos pasándole en el classpath la librería de servlets:

Luego hemos utilizado ant para automatizar un poquito mas esto y nos creamos un build.xml con una serie de tareas para crear directorios de proyecto, compilar, mover ficheros necesarios a proyecto tomcat, parar-arrancar tomcat, etc:

A continuación hemos hecho un breve repaso por la historia de los jsp's, como se diseñaron para separar la capa de presentación, los problemas que todavía persistían con la inclusión de los scriptles y la primera solución con los javabeans, posteriormente con la generación de tlds propios y el gran avance con las librerias de tld's jstl.

Ya para ir finalizando las 2 semanitas, nos contaron la historia de la persistencia en java y su evolución (a esta parte todavía le queda mucha chicha, supongo que esta semana nos tocará comenzar con algo de ejb, jdo, orm, hibernate, jpa).
Hablamos de los 4 tipos de drivers jdbc en java (Tipo 1 puente jdbc-odbc, Java binario, 100% java protocolo nativo, 100% java protocolo nativo independiente). Hemos hablado de patrones (DAOFactory, Façade) para hacer frente a la diversidad de servidores de BD con drivers diferentes, con tipos diferentes, con sintaxis sql diferente.

Y esto ha sido todo durante estas 2 intensas y productivas semanas. Esperemos que esta lo sea todavía mas, ya os contaré.

Uno de mis temores al comenzar con el teletrabajo era la pérdida de relación con la gente de mi profesión. Curioso, porque cuando trabajaba en oficina, la relación con mas informáticos o cuando menos las conversaciones sobre temas informáticos se reducían generalmente a las horas de oficina.

Ahora siento la necesidad de entablar relaciones con gente de mi misma profesión, bien sea compartiendo pequeños trabajillos o en charlas que normalmente giran en torno a mismo tema, nuestra profesión, programación en general, la web en particular, nuevas herramientas, nuevas tendencias, novedades ubunteras, estado de la industria tic, etc etc etc.

Esta semana pasada he comenzado un curso de J2EE Avanzado. Aunque haya trabajado durante mas de 2 años con struts, jasperreports, jsf y otras yerbas, por cierto ahora en los poquitos ratos que me quedan libres intento hacer pequeños experimentos con gwt intentaré dejar algún post en cuanto tenga algo contable, pues aunque haya trabajado en este entorno me apetecía asistir a este curso por muchas razones.

La primera y fundamental porque el temario es de lo más interesante, toca muchas de esas herramientas que tengo apuntadas en mi interminable lista TO-DO pero que al final nunca encuentro el momento justo para ponerme con ellas (hablo de ant, junit, spring, etc...).

Otra razón es que aunque la mayor parte de mis conocimientos aplicados a mi trabajo diario son autodidactas, me apetecía que alguien con sobrada experiencia me de diera explicaciones en viva voz, alguien a quien poder preguntar (que no sea el google) y con quien poder debatir y compartir conocimientos. A veces uno se cansa de aprender en solitario y entre la uoc y el teletrabajo esta es una oportunidad perfecta para volver a experimentar el aprendizaje en común.

Y otra de las razones viene al hilo de mis primeras impresiones en este post, conocer a gente de mi misma profesión, incluso de misma provincia, que al final somos 4 y poco a poco nos conocemos. Por lo pronto la persona que impartirá el curso ya es un viejo conocido.

Por eso que aunque el principal motivo de este curso sea aprender existen también motivos indirectos que me han animado a asistir.