Se hace camino al andar…

Bueno, y digo yo: “Si Interface21 puede cambiar de imagen, ¿por qué no yo también?”

Powered by ScribeFire.

Los creadores del framework Spring acaban de cambiar su nombre de Interface21 a Spring Source. Como ellos mismos dicen en su web: “el nombre lo dice todo”.

Este cambio de nombre coincide con la liberación de la versión 2.5 del framework (que aparece con todos sus jars “osgificados”, es decir, listos para ser incorporados en un contenedor OSGi) y con la liberación de la primera “release candidate” de la versión 1.0 del proyecto Spring Dynamic Modules (aka Spring:OSGi).

Si alguien quiere un ejemplo ya cocinado para ver lo sencillo que resulta esto de pax-runner, que haga lo siguiente:

1. Descargar pax-runner y ponerlo en el PATH
2. Asegurarnos que el valor de JAVA_HOME es correcto
3. Ejecutar pax-run.sh o pax-run.bat

Veréis cómo “automágicamente” Pax Runner comienza a descargar un contenedor Apache Felix y lo ejecuta, dejando la consola de comandos lista para hacer, p.ej. “ps” y ver todos los bundles que ha descargado (apenas cinco) y que están en estado “ACTIVE”

C:\pax-runner-0.5.3\bin > pax-run

   ______  ________  __  __  / __  / /  __   / / / / / /  ___/ /  __   / _\ \ _//  /    /  / /  / / _\ \/__/    /__/ /__/ /_/ /_/

Pax Runner from OPS4J – http://www.ops4j.org
——————————————–

-> Using config [classpath:META-INF/runner.properties]
-> Protocol [mvn] handler started
-> Protocol [wrap] handler started
-> Scanner for schema [scan-bundle] started
-> Scanner for schema [scan-dir] started
-> Scanner for schema [scan-file] started
-> Scanner for schema [scan-pom] started
-> Provision from [.!/*.jar]
-> Provision from [scan-dir:.!/*.jar]
-> Installing bundle [{location=file:/C:/pax-runner-0.5.3/bin/./pax-runner-0.5.
3.jar,startlevel=null,shouldStart=true}]
-> Downloading bundles…
-> Execution environment [J2SE-1.5]
-> Starting platform [Felix 1.0.1]. Runner has succesfully finished his job!

Welcome to Felix.
=================

ps
-> START LEVEL 6
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (1.0.1)
[ 1] [Active ] [ 1] org.osgi.r4.compendium (1.0.0)
[ 2] [Active ] [ 1] Apache Felix Shell Service (1.0.0)
[ 3] [Active ] [ 1] Apache Felix Shell TUI (1.0.0)
[ 4] [Active ] [ 5] OPS4J Pax Runner – Core (0.5.3)
shutdown
-> ->
-> Shuting down platform…
-> Destroying platform process…

Si en vez de pax-run.sh (sin parámetros) ejecutamos pax-run.sh "--platform=equinox", lo que conseguimos es arrancar un contenedor Eclipse Equinox 3.2.1 y con un conjunto de bundles instalados ligeramente diferentes. (Por cierto, el comando para ver los bundles en la consola de Equinox es “ss” y para salir el comando es “close”).

Como Eclipse está basado en Equinox (un contenedor OSGi) y además es mi IDE preferido, he comenzado a hacer mis primeros pinitos y quería compartir estos primeros pasos.

Run > Open Run Dialog > OSGi Framework > OSGi Framework
Pulsamos en “Duplicates the currently selected launch configuration”, renombramos “OSGi Framework (1)” a un nombre con el que nos encontremos más cómodos, p.ej. “OSGi Framework (Degesys)”

En la pestaña “Bundles” veremos dos grupos de bundles (todos seleccionados): Workspace y Target Platform. Deseleccionemos “Target Platform”.

File > New Project > Plug-in Project
Project Name: hellobundle
This plug-in is targeted to run with: an OSGi framework (yo he elegido “standard”)

Next , Next

Create a plug-in using one of the templates: Hello OSGi Bundle

Next , Finish

Seleccionamos la raiz de nuestro proyecto recién creado “hellobundle” y pulsamos “Alt+Shift+X, O” y seleccionamos nuestra configuración “OSGi Framework (Degesys)”. Se abrirá la consola y aparecerá un mensaje como el siguiente:

osgi> Hello World!!

Ponemos el cursor en la consola y escribimos “close”.

¡¡Ya hemos ejecutado nuestro primer bundle!!

Estas últimas semanas tengo bastante abandonado este blog porque estamos comenzando un proyecto muy bonito a la vez que difícil (al menos para mi): estamos valorando la posibilidad de desarrollar nuestro framework SOA basándolo en OSGi y SCA. Para ello, mi compañero Sixto está montando Newton con Spring:OSGi y todo el entorno de desarrollo que nos permita construir y desplegar nuestras aplicaciones en este nuevo entorno. Y en este orden de cosas, hemos visto que hay un par de herramientas muy nuevas que nos van a permitir acelerar muchas tareas: se trata de pax-runner y pax-construct.

Aquellos que tengáis algo que ver con OSGi, no perdáis ni un momento en echar un vistazo a este proyecto PAX (dentro de otro proyecto más genérico, OPS4J) porque merece la pena: puedes configurar tu entorno de ejecución y lanzar el contenedor de tu elección (por defecto es Apache Felix) con extrema facilidad (un fichero txt). Y muy similar es el proceso de construir una aplicación, incluso puedes “osgificar” un jar sin más que ejecutar pax-construct.

Este proyecto es un gran reto para mi, pero también por eso mismo está siendo tan apasionante.

Powered by ScribeFire.

Después de algunas semanas evaluando diferentes opciones e incluso elaborando una PoC (prueba de concepto), en Degesys hemos llegado al convencimiento de que debemos desarrollar las interfaces de usuario para escritorio con Eclipse RCP.
Mis compañeros Pablo Navais y Sixto Cantolla han estado haciendo este trabajo, durante el cuál han evaluado fundamentalmente Eclipse RCP, NetBeans RCP, Spring RCP y Swing Application Framework (JSR-296) y en el estudio que han elaborado han concluído lo siguiente:

• Eclipse RCP es el más maduro, estable, completo y bien documentado del mercado. Además, al estar basado en SWT (e.d. componentes nativos) tiene un mejor rendimiento. Permite incorporar componentes Swing sin problemas. Tiene una curva de aprendizaje elevada, pero una vez pasada la barrera es muy productivo.
• NetBeans RCP no está mal, pero Eclipse RCP está mejor.
• Spring RCP se basa en independizarse del método de renderizado (usa Swing de momento) pero está aún un poco “verde”. Además, no tiene mucha documentación y tiene algunos defectos bastante llamativos. De todos modos, siempre podremos integrar Spring y Eclipse RCP.
• Y el que está verde del todo es Swing Application Framework, que no está aún concluída la especificación y tardará además en madurar (igual que le ocurre a cualquier framework). Sin embargo, por lo que se ha podido intuir, es una opción que en el futuro está llamada a jugar fuerte.
• JavaFX parece que tiene problemas de rendimiento de tal calibre que ni tan siquiera lo consideramos.

En breve comenzaremos a desarrollar nuestra primera aplicación de escritorio: una consola de administración para un servicio interno que ya tenemos desarrollado. No es algo muy ambicioso, pero es la mejor manera de aprender. Si trataramos de hacer una aplicación para un cliente directamente, lo más seguro es que nos pegáramos el batacazo del siglo… y no queremos eso…

Acabo de conseguir echar a andar uno de los ejemplos de Tuscany SCA en el que se muestra cómo usarlo con la extensión Spring. Está todo mavenizado pero hay que hacer algún “hack” porque hay dependencias SNAPSHOT que aún no han sido liberadas.

1. Hay que hacer checkout desde https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/simple-bigbank-spring. Yo lo he hecho desde mi Eclipse 3.3 con JDK 6 y con el plugin m2 para Maven. Así, en mi workspace tengo el proyecto “simple-bigbank-spring” pero ni compila ni nada.
2. Botón derecho + “Enable Dependency Management” para habilitar el plugin de Maven.
3. Botón derecho + “Properties” para revisar el classpath:
• Añadir la librería del JRE (yo he puesto la que tengo por defecto: JDK 6)
• Quitar el directorio raíz del proyecto como carpeta para el código fuente y seleccionar los estándar de Maven: src/main/java, src/main/resources y src/test/java.
• Cambiar el directorio destino de las clases compiladas de “bin” a “target/classes”.
• Pulsar “OK” y aceptar que se borre el contenido de “bin”.
4. Tocar el pom.xml:
• Añadir el repositorio de snapshots de apache: http://people.apache.org/repo/m2-snapshot-repository

•    <repository>      <id>apache.snapshot</id>      <url>http://people.apache.org/repo/m2-snapshot-repository</url>   </repository>

• Eliminar el elemento “relativePath” del “parent”.
• Cambiar todas las dependencias 1.1-incubating-SNAPSHOT por 1.0-incubating-SNAPSHOT.
5. (Es posible que tengáis que deshabilitar y volver a habilitar las dependencias de Maven para que pille estos cambios).
6. Ejecutar el goal “install” con Maven, lo cuál descargará bastantes librerías, y al final deberíais tener el proyecto perfectamente compilado y listo para ejecutar.
7. Ejecutad la única prueba en src/test/java/bigbank/BigBankTestCase (con botón derecho “Run As Junit Test”).

El resultado en la consola es:

log4j:WARN No appenders could be found for logger (org.apache.tuscany.sca.implementation.spring.SCAApplicationContext).
log4j:WARN Please initialize the log4j system properly.
Spring parent context – getBean called for name: stockQuoteService
Getting stock quote for: IBM, value: 104.73
Account summary: currency: USD, [ID:Foo_CHA12345, balance:1500.0, ID:Foo_SAA12345, balance:1500.0, ID:Foo_STA12345, symbol:IBM, quantity:100, balance:10473.0]

En ocasiones me siento muy identificado con artículos como éste , lo que pasa es que cuando veo el recibo mensual de la hipoteca me veo enfrentado a mis propios demonios que me piden dejar de trabajar en lo que me gusta y centrarme en ganar pasta y nada más…

Aristóteles era un tipo prudente (la prudencia es la madre de la sabiduría) y ya dijo:

La virtud está en el término medio.

Lo que pasa es que a veces resulta muy difícil ser virtuoso…

Ha costado pero ya está en el repositorio central de Maven la última versión de JUnit (4.4). Siento el ataque de vanidad, pero hoy ha sido la única alegría que he tenido y necesitaba una gotita de alegría…

He estado leyendo el libro “Service-Oriented Architecture (SOA): Concepts, Technology, and Design” de Thomas Erl y he llegado al convencimiento (entre otras muchas cosas) de que para hacer “verdadero SOA” son necesarios:

• una infraestructura que haga posible la localización y la colaboración (síncrona o asíncrona) entre servicios
• buscar un modelo a partir del cuál poder diseñar los servicios como componentes estándar (independientemente de la infraestructura en la que se desplieguen)

Respecto al segundo punto, leyendo, leyendo y navegando, navegando, he llegado a una serie de artículos de IBM sobre integración usando SOA. Tras leer varios de ellos (reconozco que no todos), he visto que SCA sería una posible solución. Para los que quieran una introducción rápida a SCA, creo que es mejor acudir a la fuente directamente. En la web de OpenSOA se define el modelo en UML, por si eso ayuda en algo a su comprensión. Lo mejor de todo es que ya hay incluso especificación para API Java y ejemplos de cómo usar JAX-WS para implementar un componente “SCA-enabled”.

SCA es una propuesta OASIS (por lo que se garantiza que Microsoft también participa y que, por tanto, está garantizado el éxito en la interoperabilidad). A mí, sin embargo, me queda la duda (y me gustaría mucho que alguien me lo explicara) sobre qué diferencia hay entre SCA y JBI y entre SCA y WSIT. Lo que pasa es que la gente de Glassfish parece un poco escéptica al respecto de adoptar SCA (al menos tal cual está ahora definida). Ya le pregunté “in person” a Eduard Pelegrí y me contestó que él veía más factible una convergencia a medio/largo plazo de JBI (Sun) y SCA (IBM).

De todos modos, vamos a ver, que yo sepa… SOA no sólo se puede implementar con .NET o con J2EE…