Al principio optamos por una solución sencilla, la transacción de Hibernate englobará a la transacción de JackRabbit de la siguiente manera:

hibernateSession.beginTransaction()
try{
    // Bloque operaciones Hibernate
    jackrabbitSession.beginTransaction()
    // Bloque operaciones Jackrabbit
    jackrabbitSession.commit()
    hibernateSession.commit()
}catch(Exception){
    hibernateSession.rollbackTransaction()
}

El código parece bueno pero es muy poco escalable. ¿Que sucedería si jackrabbit se nos queda pequeño y necesitamos utilizar otro JCR como puede ser Alfresco?, muy simple, aparte de cambiar la arquitectura de la aplicación deberíamos de cambiar todos los DAOs lo que nos llevaría a resignarnos y continuar con la implementación actual. Esta solución fue descartada por su escasa escalabilidad.

“Si la solución no es buena, ¿Qué hacemos?”

La solución pasa por la propagación de las transacciones de ambos sistemas utilizando un manejador de transacciones que hable el mismo idioma (JTA) y un framework que nos proporcione una cómoda integración (spring).

En el caso que nos ocupaba, nuestro servicio de negocio realiza el salvado de una nueva entidad en la BBDD y en el gestor de contenidos utilizando dos transacciones separadas, con lo cual ninguna de ellas conoce el estado de la otra y si en algún caso alguna de ellas realiza un rollback la otra no sería consciente de ello. Este problema puede resultar bastante traumático debido a que puede crear inconsistencias entre los datos almacenados en la BBDD y el gestor de contenidos.

Es por ello necesario englobar las dos transacciones en una y así poder controlar el estado de éstas y realizar las operaciones oportunas si alguna de ellas falla.

Seam posee un módulo de integración con spring bastante bueno y muy fácil de utilizar.
Para realizar la integración necesitamos los paquetes:

• jboss-seam-ioc: Modulo de integración entre los frameworks seam y spring
• spring: Framework spring completo
• aspectjweaver: Modulo de aspectj para la configuración de aspectos en spring (tx-advise)
• cglib-nodep: Modulo de generación de código en tiempo de ejecución utilizado por spring en la creación de los proxis que envuelven las clases.

El primer paso para configurar la integración de seam con spring es incluir el contexto de spring en el de seam añadiendo las siguientes líneas en el archivo components.xml:

<spring:context-loader config-locations="/WEB-INF/applicationContext.xml">
</spring:context-loader>
 
<transaction:no-transaction />

En el primer nodo declaramos la localización del fichero de configuración de spring y en el segundo delegamos el control de las transacciones a spring al deshabilitarlas en seam.

El siguiente paso es realizar la configuración de spring creando el archivo xml “applicationContext.xml”:
Espacios de nombres utilizados:

<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:seam="http://jboss.com/products/seam/spring-seam"
 
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
http://jboss.com/products/seam/spring-seam http://jboss.com/products/seam/spring-seam-2.1.xsd">

El único a destacar es xmlns:seam el cual se utilizará para declarar un bean de spring como componente seam y poderlo inyectar en los demas componentes de la aplicación.

Para poder englobar las transacciones que ocurran en nuestra aplicación en la transacción controlada por Jboss es necesaria la creación de conectores JCA compatibles con Jboss. Estos conectores serán expuestos por el servidor de aplicaciones para ser utilizados desde nuestro entorno mediante la búsqueda por el nombre JNDI.
Jboss 5.1 posee un “desplegador” de fuentes de datos, solamente debemos de crear archivos *-ds.xml utilizando el dtd http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd y dejarlos en el directorio de despliegue. Este dtd posee la definición para configurar la transaccion a utilizar en nuestra fuente de datos.

Los archivos de configuración de fuentes de datos para Jboss serían:
JDBC:

<datasources>
 <local-tx-datasource>
  <jndi-name>myJdbcDS</jndi-name>
  <driver-class>org.postgresql.Driver</driver-class>
  <connection-url>jdbc:postgresql://localhost:myPsqlPort/myDDBB</connection-url>
  <user-name>myUser</user-name>
  <password>myPwd</password>
  <transaction-isolation>TRANSACTION_SERIALIZABLE</transaction-isolation>
 </local-tx-datasource>
</datasources>

JackRabbit:

<connection-factories>
 <tx-connection-factory>
  <jndi-name>myJcrRepo</jndi-name>
  <xa-transaction />
  <rar-name>jackrabbit-jca-1.5.6.rar</rar-name>
  <connection-definition>javax.jcr.Repository</connection-definition>
  <config-property name="homeDir" type="java.lang.String">myRepoLocation
  </config-property>
  <config-property name="configFile" type="java.lang.String">myRepo.xml
  </config-property>
  <config-property name="bindSessionToTransaction" type="java.lang.Boolean">true</config-property>
  <application-managed-security/>
 </tx-connection-factory>
</connection-factories>

Al no ser un conector común, debemos decirle a Jboss que paquete “.rar” utilizar y la clase que lo implementa “javax.jcr.Repository”. El paquete jackrabbit-jca-1.5.6.rar lo pondremos dentro de la carpeta de despliegue.

Antes de arrancar el servidor de aplicaciones y ver que nuestros conectores están accesibles, es necesario copiar las librerias de jackrabbit y sus dependencias dentro del directorio “lib” del servidor que vamos a utilizar (comúnmente $JBOSS_HOME/server/default/lib)

Configuraremos Hibernate utilizando spring y obtendremos la fuente de datos utilizando JNDI. La configuración completa quedaría:

<bean id="jdbcXaDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
 <property name="jndiName" value="java:myJdbcDs" />
</bean>
 
<bean id="hibernateSession" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
 <property name="dataSource" ref="jdbcXaDataSource" />
 <property name="mappingResources">
  <list>
   <value>hbm/myFile.hbm.xml</value>
  </list>
 </property>
 <property name="hibernateProperties">
  <value>hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
  </value>
 </property>
</bean>

Para poder configurar el repositorio de JackRabbit desde spring, es necesario utilizar la librería springmodules-jcr. Como en el caso de Hibernate, la fuente de datos la obtendremos por JNDI desde el servidor de aplicaciones. La configuración quedaría:

<bean id="repositoryCFB" class="org.springframework.jndi.JndiObjectFactoryBean">
 <property name="jndiName" value="java:myJcrRepo" />
</bean>
 
<bean id="jcrCredentials" class="javax.jcr.SimpleCredentials">
 <constructor-arg index="0" value="admin" />
 <constructor-arg index="1">
  <bean factory-bean="jcrCredentialsPassword" factory-method="toCharArray" />
 </constructor-arg>
</bean>
<bean id="jcrCredentialsPassword" class="java.lang.String">
 <constructor-arg index="0" value="password" />
</bean>
 
<bean id="jcrSessionFactory" class="org.springmodules.jcr.JcrSessionFactory">
 <property name="repository" ref="repositoryCFB" />
 <property name="credentials" ref="jcrCredentials" />
 <property name="sessionHolderProviderManager">
 <bean>
  <property name="providers">
   <list>
    <bean class="org.springmodules.jcr.jackrabbit.support.JackRabbitSessionHolderProvider"/>
   </list>
   </property>
  </bean>
 </property>
 
 <seam:component />
</bean>

Como las sesiones las va a manejar spring, es muy recomendable el uso de la plantilla JCR que nos proporciona el módulo de spring y así delegar en ella el control de las sesiones de nuestro repositorio y evitar posibles problemas a la hora de sincronizarlas.

<bean id="jcrTemplate" class="org.springmodules.jcr.JcrTemplate">
 <property name="sessionFactory" ref="jcrSessionFactory" />
 <property name="allowCreate" value="true" />
</bean>

Ya tenemos configurados los orígenes de datos, y ahora ¿cómo gestionamos ambas transacciones? Spring nos permite configurar manejadores de transacciones de manera trasparente a las fuentes de datos y será el encargado de englobarlas en un mismo entorno. Este entorno transaccional será el que nos aporta nuestro servidor de aplicaciones (para el cual hemos definido las fuentes de datos correspondientes), lo obtendremos creando el siguiente bean dentro del contexto de spring:

<bean id="jtaTransactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">
 <property name="transactionManagerName">
  <value>java:/TransactionManager</value>
 </property>
</bean>

La configuración del aspecto que nos manejará las transacciones que ocurran en nuestra aplicación será:

<tx:advice id="txAdvice" transaction-manager="jtaTransactionManager">
 <tx:attributes>
  <tx:method name="*" />
  <tx:method name="get*" read-only="true"/>
 </tx:attributes>
</tx:advice>

El último paso es definir qué clases/métodos queremos que sean transaccionales mediante el uso de puntos de ruptura:

<aop:config proxy-target-class="true">
 <aop:pointcut expression="execution(* com.s2grupo.sample..*(..))" id="txServicePointCut" />
 <aop:advisor advice-ref="txAdvice" pointcut-ref="txServicePointCut" />
</aop:config>

Para que los puntos de ruptura sean efectivos es necesario agregar las clases afectadas al contexto de spring. Como estas clases son utilizadas dentro del contexto de seam añadiremos el nodo <seam:component/> dentro de cada una de ellas. La configuración quedará:

<!-- Service -->
<bean id="repositoryService">
 <property name="repositoryManager" ref="repositoryManager"></property>
 <seam:component name="repositoryService" intercept="false" />
</bean>
 
<bean id="repositoryManager" class="com.s2grupo.sample.RepositoryManager"
 init-method="create" destroy-method="close">
 <property name="repositoryConfiguration" ref="repositoryConfiguration"></property>
 <property name="jcrTemplate" ref="jcrTemplate"></property>
 <seam:component name="repositoryManager" />
</bean>
 
<bean id="repositoryConfiguration" class="com.s2grupo.sample.RepositoryConfiguration"
 init-method="create" destroy-method="close">
 <property name="jcrTemplate" ref="jcrTemplate"></property>
 <seam:component name="repositoryConfiguration" />
</bean>
 
<bean id="myService" class="com.s2grupo.sample.MyService">
 <property name="myDao" ref="myDao"></property>
 <seam:component name="myService" />
</bean>
 
<!-- Data -->
<bean id="abstractDao" abstract="true">
 <property name="hibernateSessionFactory" ref="hibernateSession"></property>
</bean>
 
<bean id="myDao" parent="abstractDao">
 <seam:component name="myDao" />
</bean>

Y con esto tendríamos todas las transacciones controladas y no perderíamos así la integridad de los datos de nuestra aplicación.

Espero que esta entrada os sea tan útil como lo fue para mí. Y ahora ... comentarios!!!

La máxima del patrón MVVM es la separación de las capas de presentación y negocio. Esto se consigue con el nuevo lenguaje declarativo llamado XAML que permite establecer el binding entre los elementos visuales y los elementos del dominio, en nuestro caso las propiedades de las clases. Así, imaginemos que queremos enlazar un atributo de la clase que represente el nombre del empleado con la caja de texto que al iniciar la aplicación se muestre el nombre. En Windows Forms deberíamos crear el manejador de evento de carga del formulario, declarar la instancia de nuestra clase Empleado, e inicializar el valor de la propiedad Text de la caja de texto. Sin embargo en WPF, basta con escribir una instrucción en XAML que enlace nuestra caja de texto con el atributo. Lo mejor de todo es que al modificar el valor del texto, también se actualizará el valor del atributo que representa el nombre del empleado, y al revés.

Las siglas MVVM vienen de Model-View-ViewModel, donde como su propio nombre indica, Model representa el dominio de nuestro sistema, View los elementos que componen la interfaz y ViewModel se encargará de comunicar las vistas con el modelo.

La vista nunca interactuará directamente con el modelo, sino a través de los ViewModels.

Los desarrolladores familiarizados con ASP.NET pueden establecer un símil con WPF. Las páginas en ASP.NET disponen del código HTML y del code behind escrito en C# o Visual Basic. De manera similar, en WPF tenemos los archivos .xaml, y detrás de cada vista código en nuestro lenguaje de programación favorito como VB o C#. Con MVVM conseguiremos que la cantidad de código en code behind sea la mínima posible.

Después de esta breve introducción teórica veamos como llevar a cabo la implementación básica del patrón MVVM en nuestra aplicación. Debido que muchos de los ViewModels necesitan la misma información, empezaremos creando la clase base ViewModelBase que heredarán nuestros ViewModels. Para organizarnos mejor, es buena práctica crear dentro de nuestro proyecto tres carpetas:

• ViewModels donde iremos alojando nuestro ViewModels
• Models para almacenar nuestros modelos
• Views para las vistas

public abstract class ViewModelBase : INotifyPropertyChanged {
///
/// Evento que se ejecuta cuando se cambia la propiedad del componente.
///
 public event PropertyChangedEventHandler PropertyChanged;
 protected void NotifyPropertyChanged(String sData) {
  if (PropertyChanged != null) {
   PropertyChanged(this, new   PropertyChangedEventArgs(sData));
  }
 }
}

Como vemos debe implementar la interfaz INotifyPropertyChanged, concretamente el miembro NotifyPropertyChanged, que notificará al sistema de binding de WPF cuando la propiedad en el ViewModel disponga de nuevo valor, para actualizar en consecuencia todos los controles enlazados.

Para que WPF se de cuenta de que propiedad ha cambiado, al disparar el evento PropertyChanged, hemos de pasarle en el constructor de la clase PropertyChangedEventArgs el nombre completo de la propiedad.

A partir de ahora podemos empezar a definir nuestros ViewModels. Para el caso de estudio vamos a definir uno trivial que invoque los métodos del modelo añadiendo la cadena que se le pasa a la lista, eliminándola o obteniendo todas las cadenas disponibles.

public class ExampleViewModel : ViewModelBase
{
 private ExampleModel exampleModel = new ExampleModel();
 private ObservableCollection lDummyStrings = new ObservableCollection ();
 
 private void doDummyAdd(String sDummy) {
  exampleModel.addDummy(sDummy);
 }
 
 private void doDummyDel(String sDummy) {
  exampleModel.delDummy(sDummy);
 }
 
 private ObservableCollection getDummies() {
  return exampleModel.getDummies();
 }
}

En una aplicación del mundo real el modelo se compondría de operaciones mucho más complejas, como el acceso a bases de datos. Anteriormente habíamos mencionado que el objetivo del MVVM es desacoplar el código correspondiente a la vista, pero si queremos saber cuándo el usuario aprieta un determinado botón o elige una valor de la lista, deberíamos instalar manejadores de eventos fuertemente acoplados a la vista. Por suerte, WPF incorpora un sistema de comandos mediante los cuales podemos llevar la lógica correspondiente de los manejadores de eventos a los ViewModels.

En primer lugar implementamos el patrón del comando genérico. Como vemos contiene dos delegados que podemos interpretar como, si la condición (el delegado CanExecuteDelegate) del comando se cumple entonces podemos ejecutamos la acción (ExecuteDelegate).

///
/// El comando génerico para ejecutar los métodos
/// de la interfaz ICommand.
///
public class GenericCommand : ICommand
{
public Predicate 
 
public Action
 
 ///
 /// Indica si el comando se puede ejecutar.
 ///
 public bool CanExecute(Object param) {
  if (CanExecuteDelegate != null)
   return CanExecuteDelegate(param);
  return true;
 }
 
 ///
 /// Se dispara cuando cambia la condición de ejecución del
 ///	comando.
 ///
 public event EventHandler CanExecuteChanged
 {
  add {
   CommandManager.RequerySuggested += value;
  }
  remove{
   CommandManager.RequerySuggested -= value;
  }
 }
 ///
 /// Ejecutará el método del comando.
 ///
 public void Execute(Object param) {
  if (ExecuteDelegate != null)
   ExecuteDelegate(param);
 }
}

Declaramos el comando que nos permitirá insertar la cadena que se le pase como parámetro en la colección:

private ICommand addDummyStringCommand;

Inicializamos los delegados del comando. Para ello vamos a usar una nueva estructura de .NET 3.0 denominada expresiones lambda, que de manera mucho más limpia nos permiten hacer lo que en la versión anterior del framework se hacía mediante delegados anónimos:

private void doInitCommand() {
 this.addDummyStringCommand = new GenericCommand(){
  CanExecuteDelegate = c => c != null,
  ExecuteDelegate = c => doDummyAdd((String) c )};
}
public ICommand AddDummyStringCommand{
 get {return this.addDummyStringCommand;}
 set{
  this.addDummyStringCommand = value;
  NotifyPropertyChanged("AddDummyStringCommand");
 }
}

Solamente cuando el parámetro sea distinto de null se podrá ejecutar el comando, es decir, el botón se habilitará.

Ahora veamos como enlazar nuestro comando con la vista desde el código XAML. Debemos inicializar la propiedad DataContext del elemento que participa en el data binding, en este caso la vista. Para ello en el constructor de la misma hacemos lo siguiente:

public partial class ExampleView
{
 private ExampleViewModel exampleViewModel = new ExampleViewModel();
 
 public ExampleView(){
  InitializeComponent();
  this.DataContext = exampleViewModel;
 }
}

Con esto hemos establecido la conexión entre la UI de la aplicación y nuestro ViewModel. Ahora seremos capaces desde el código XAML de referenciar las propiedades de nuestro ViewModel.

<Button Name="cmdAddDummyString" Command="{Binding Path=AddDummyStringCommand}" CommandParameter="{Binding ElementName=txtDummyString, Path=Text}"></Button>

Aquí la propiedad Command del botón la hemos enlazado con el comando de nuestro ViewModel y el parámetro será la cadena que se escribirá en la caja de texto. Todo queda limpio, sin necesidad de invocar las operaciones de la lógica de negocio desde los manejadores de eventos. Además, de esta forma estamos reutilizando el código; si quisiéramos incorporar a nuestra aplicación la misma funcionalidad pero desde, por ejemplo, el menú, simplemente asignaríamos el mismo comando al ítem del menú

Imaginad ahora que queremos listar todas la cadenas que se vayan añadiendo o eliminando de la colección, en un Listbox. Si volvemos a la definición de nuestro ViewModel, el atributo lDummyStrings de tipo ObservableCollection se comporta como una lista normal, excepto que podemos ser notificados cuando se eliminan o añaden elementos a la misma. Suponiendo que en el ViewModel hemos definido la propiedad para devolver la lista, veamos como enlazarla con el Listbox:

<ListBox Width="Auto" Height="Auto" ItemsSource="{Binding Path=BindableDummyStringCollection}"></Button>

Lo que en Windows Forms resultaría un proceso engorroso, en WPF mediante un par de líneas en XAML hemos enlazado el Listbox con la colección, y además a medida que se va modificando la colección el Listbox se actualiza automáticamente.

Hemos aprendido como llevar a cabo la implantación minimalista del patrón MVVM en nuestra aplicación mediante un ejemplo trivial, pero que sirve como el guía para desarrollar aplicaciones complejas. Actualmente, frameworks como Cinch o Calcium ofrecen muchas características que nos pueden ayudar a la hora de implementar el MVVM.

Sin duda alguna, se está convirtiendo en de facto para el desarrollo de aplicaciones WPF.

La primera versión de Spring fue escrita por Rod Jonhson, quien lo lanzó primero con la publicación de su libro "Expert One-on-One Java EE Design and Development", basado en las mejores prácticas aceptadas. Tras la publicación, sus lectores le solicitaron que el código que acompañaba al libro fuera liberado bajo una licencia Open Source. A raíz de eso, se formó un pequeño equipo de desarrolladores que esperaba trabajar en extender el framework, y se creó el primer proyecto en Sourceforge en febrero de 2003. Después de trabajar en su desarrollo durante más de un año, la primera versión (1.0) fue lanzada en marzo de 2004, momento a partir del cual Spring ganó mucha popularidad en la comunidad Java, debido en parte al uso de Javadoc y de una documentación de referencia por encima del promedio de un proyecto de código abierto.

Spring Framework hizo que aquellas técnicas que resultaban desconocidas para la mayoría de programadores se volvieran populares en un periodo muy corto de tiempo, cuyo ejemplo más notable fue la inversión de control. En el año 2004, Spring disfrutó de unas altísimas tasas de adopción y al ofrecer su propio framework de programación orientada a aspectos (aspect-oriented programming, AOP) consiguió hacer más popular su paradigma de programación en la comunidad Java. Actualmente springsource ha sido adquirido por el líder en soluciones de virtualización VMWare (+ info)

El principal objetivo del framework es FACILITAR EL DESARROLLO DE SOFTWARE (TANTO JAVA COMO .NET). A lo largo de todas las liberaciones del proyecto, se han ido añadiendo módulos: Mensajería (JMS), Integración (ESB), Acceso a Datos (JDBC, ADO .Net, Hibernate), todos ellos con el propósito de reducir complejidad al desarrollo, permitiendo así que los desarrolladores dediquen sus esfuerzos a lo que realmente es necesario y “no reinventen la rueda”.

Actualmente la versión (java) estable del framework es la 2.5.6 y contiene los siguientes módulos:

Como primera aproximación al mundo de spring, explicaremos el corazón de Spring: La inversión de control (IoC). Según Wikipedia, la Definición de IoC es la siguiente:

Creo que tras esta definición toca un ejemplito que sirva para aclarar algunas dudas (que seguramente no son pocas):

Sean dos clases cada una con su interfaz independiente: classA, classB, interfaceA e interfaceB. En classB tenemos un campo del tipo classA. Desde la clase principal, mainClass, se accede al campo del tipo classA de la clase classB.

Utilizando el método de programación habitual tendríamos lo siguiente:

public class ClassA {public String do(){return "Hello World";}}
 
public class ClassB {
   public ClassA a;
   public ClassB(){
      this.a = new ClassA();
   }
}

La clase principal seria:

public class main{
   public static void main(String args[]){
      ClassB b = new ClassB();
      System.out.println(b.a.do());
   }
}

En la salida estándar obtenemos:

Analicemos el código del ejemplo. ¿Qué pasaría si las clases ClassA y ClassB pertenecieran a dos componentes totalmente distintos (p.ej. un conector JDBC y un cliente de servicios web)? ¿No estaríamos acoplando ambos componentes y haciendo que fueran totalmente dependientes uno del otro? ¿Que pasaría si decidiéramos cambiar un componente por otro distinto que en esencia tuviera la misma funcionalidad? ¿Tendríamos que cambiar ambos componentes? ¿Genera esto un código testeable unitariamente? Es decir, ¿podemos testear la clase ClassB sin testear la ClassA?

La respuesta a todas estas preguntas nos las puede dar el siguiente ejemplo:

public interface InterfaceA{String do();}
 
public interface InterfaceB{ InterfaceA getA();}
 
public class ClassA implements InterfaceA{public String do(){return "Hello World";}}
 
public class ClassB implements InterfaceB{
   private InterfaceA a;
 
   public void setA(InterfaceA a){this.a = a;}
   public InterfaceA getA(return this.a;)
}

La clase principal seria:

public class main{
   public static void main(String args[]){
      ClassB b = new ClassB();
      ClassA a = new ClassA();
      b.a = a;
      System.out.println(b.a.do());
   }
}

En este ejemplo no se están acoplando las clases ClassA y ClassB, con lo que conseguimos resolver todas las preguntas del ejemplo anterior. Hemos evitado el acoplamiento, ¿pero es cómodo? Si ahora necesito instanciar todas las clases y establecer sus campos, estoy mejorando la calidad de mi software, pero a un coste alto. Aquí es donde entra Spring:

public interface InterfaceA{String do();}
 
public interface InterfaceB{ InterfaceA getA();}
 
public class ClassA implements InterfaceA{public String do(){return "Hello World";}}
 
public class ClassB implements InterfaceB{
   private InterfaceA a;
   public void setA(InterfaceA a){this.a = a;}
   public InterfaceA getA(return this.a;)
}

Archivo de definición de beans (applicationContext.xml):

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
         http://www.springframework.org/schema/beans
         http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
<beans>
   <bean id="classA" />
   <bean id="classB">
      <property name="a" ref="classA"/>
   </bean>
</beans>

La clase principal seria:

public class main{
   public static void main(String args[]){
      ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext(
				new String[] { "applicationContext.xml" });
      InterfaceB b = ctx.getBean("classB");
      System.out.println(b.getA().do());
   }
}

La implementación anterior sería la más correcta posible: desde el método main se carga el contexto de Spring, que se encarga de instanciar todas las clases y de realizar la inyección de dependencias. Tras esta inicialización, obtenemos el "bean" desde el contexto a través del nombre, con lo que hemos diseñado una aplicación totalmente desacoplada y de una manera muy sencilla.

Sirva esto de rápida introducción a Spring. Y si no se han aclarado, utilicen los comentarios o sean pacientes; en poco tiempo le cogerán el gusto a este framework.