Se hace camino al andar... » sca

PAX : OSGi made easy

jmbeas — Fri, 19 Oct 2007 02:09:00 +0000

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.

Tuscany SCA + Spring

jmbeas — Thu, 13 Sep 2007 10:45:00 +0000

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.

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.
Botón derecho + “Enable Dependency Management” para habilitar el plugin de Maven.
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”.

Tocar el pom.xml:

Añadir el repositorio de snapshots de apache: http://people.apache.org/repo/m2-snapshot-repository

         apache.snapshot      http://people.apache.org/repo/m2-snapshot-repository

Eliminar el elemento “relativePath” del “parent”.
Cambiar todas las dependencias 1.1-incubating-SNAPSHOT por 1.0-incubating-SNAPSHOT.

(Es posible que tengáis que deshabilitar y volver a habilitar las dependencias de Maven para que pille estos cambios).
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.
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]

SCA

jmbeas — Sat, 04 Aug 2007 11:17:00 +0000

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…