Lycka Bonita

Interesante conferencia de Anne Thomas Manes de 2012 en InfoQ sobre SOA en la nube, más concretamente sobre construir tus servicios de tal forma que sean “Cloud Aware” y una migración de tu aplicación desde tu CPD hacia la nube sea suave, se adapte fácilmente al nuevo entorno y puedas sacar el máximo partido de la nube y evitar los problemas que conlleva.

• Qué es un servicio “Cloud Aware” y por qué tus servicios deben serlo?
  • Elasticidad y Escalabilidad: si tu app no es escalable en tu CPD, tampoco lo será en la nube.
  • Se basa en una arquitectura compartida y dinámica
  • On demand (self service)
  • Métricas
• Principios arquitectónicos en la nube.
  • Cada decisión arquitectónica se traduce automáticamente en un coste.
  • Muchos patrones antiguos se consideran antipatrones en este nuevo entorno (por ejemplo ACID)
  • 7 principios: Latency Aware, Instrumented, Failure Aware, Event Driven, Parallelizable, Automated, Consumption Aware.
• Dónde implementarlos (IaaS, PaaS o en tu código)?
  • Balance entre tu código y la infraestructura.

Relacionado con:

• Transacciones ACID vs BASE

La especificación JPA 2.0 no soporta recuperar datos de un procedimiento almacenado [Ver nota 1], pero JPA 2.1 sí (JSR 338) [Ver nota 2]. De hecho JPA 2.1 extiende la especificación para cubrir más lagunas con los procedimientos almacenados como por ejemplo utilizar Arrays como parámetros, funcionalidad tampoco soportada en la especificación 2.0.

The Java Persistence 2.1 specification adds support for schema generation, type conversion methods, use of entity graphs in queries and find operations, unsynchronized persistence contexts, stored procedure invocation, and injection into entity listener classes. It also includes enhancements to the Java Persistence query language, the Criteria API, and to the mapping of native queries.

Implementaciones

• EclipseLink v2.4 que implementa JPA 2.0, EclipseLink v2.5 (released 28/05/2013) sí implementa JPA 2.1 [Ver nota 3].

Si estás utilizando JPA 2.0 y necesitases recuperar los datos de un procedimiento almacenado podrías utilizar JDBC en paralelo con JPA, o extender tú mismo la implementación de la especificación, o lo lógico, que sería migrar a una implementación de la especificación JPA 2.1.

Notas

NOTA 1
http://stackoverflow.com/questions/3572626/calling-stored-procedure-from-java-jpa

If you’re a big fan of SQL, you may be willing to exploit the power of database stored procedures. Unfortunately, JPA doesn’t support stored procedures, and you have to depend on a proprietary feature of your persistence provider. However, you can use simple stored functions (without out parameters) with a native SQL query.

NOTA 2:
http://en.wikibooks.org/wiki/Java_Persistence/Advanced_Topics#Stored_Procedures
https://blogs.oracle.com/arungupta/entry/jpa_2_1_early_draft

NOTA 3:
http://wiki.eclipse.org/EclipseLink/Release/2.5/JPA21#Stored_Procedures

Acabo de enterarme de que Struts 1 ha llegado al final de su camino, que arrancó en el año 2000, lo cual me entristece y me llena de morriña.

Para alguien que ha programado en BASIC, luego en Turbo Pascal, y luego con Java Servlets, Struts 1 supuso una gran revolución en cuanto a productividad y mantenimiento en la comunicación entre el servidor y el cliente, tanto por su implementación del patrón de diseño Modelo-Vista-Controlador como por sus frameworks de Validación y Tiles. De hecho la mayor revolución IMHO.

Desde aquí mi más profundo agradecimiento a cada persona que ha dedicado un minuto de su tiempo a este framework, así como el reconocimiento de mi deuda con ellos.

Gracias.

• Apache Struts 1 End-Of-Life (EOL) Press Release.
• Apache Struts 1 End-Of-Life (EOL) Announcement.

La etiqueta (taglib) de JSF convertDateTime aplica por defecto la zona horaria en la que se está ejecutando, por lo que cuando es ejecutada en España (que ahora estamos en la zona horaria GMT+2) lo que hace es restar 2 horas a la hora  que le es informada.

Es decir, ejecutando el siguiente código en España e informando user.createdOn como “01/01/2013 12:00:00″ :

1
2
3

<h:outputText value="#{user.createdOn}">
    <f:convertDateTime pattern="dd/MM/yyyy HH:mm:ss" type="both" />
</h:outputText>

se pintará en pantalla “01/01/2013 10:00:00″. Pero lo que es peor, en Portugal (está en la zona horaria GMT+1) pintaría “01/01/2013 11:00:00″ (creo, no me he desplazado a Portugal para probarlo ).

Y lo que es peor, si estás desarrollando en España y finalmente tu código se despliega y ejecuta en otro país, el resultado será….

Para solucionar esto (ñapa) en España podemos poner la zona horaria en el código:

1
2
3

<h:outputText value="#{user.createdOn}">
    <f:convertDateTime timeZone="GMT+2" pattern="dd/MM/yyyy HH:mm:ss" type="both" />
</h:outputText>

Aunque lo suyo sería que timeZone fuera una variable más a informar desde el servidor, porque sino cuando por ejemplo registremos un evento en el servidor persistiendo new Date(), al visualizar esa fecha se visualizará incorrectamente en clientes que no estén en la misma zona horaria que el servidor, complicando (innecesariamente) una lógica tan habitual como formatear una fecha.

¿Por qué no me gustará ningún código de Sun? ¿Por qué no respetaré las certificaciones de Sun?

Todo evoluciona, hasta tomar pantallazos del contenido de tu navegador, se acabó el “Imprimir Pantalla” e ir luego al MS Paint a retocar, poner flechitas y recortar la imagen.

Awesome ScreenShot es una extensión gratuita tanto para Firefox como para Chrome y Safari para tomar pantallazos del contenido de tu navegador de una forma sencilla, elegante y potente.

Sin duda es una herramienta que mejorará la comunicación entre los usuarios (es que no me funciona cuando pincho el botón!) y los desarrolladores.