Tema 3: Las capas de negocio y de acceso a datos

3.1 Funciones de las capas

La capa de negocio implementa la "lógica de negocio", es decir, en ella se localiza el núcleo del procesamiento de datos que realiza la aplicación. Típicamente una aplicación J2EE usará en esta capa EJBs o clases Java arbitrarias para modelar objetos de negocio.

La capa de acceso a datos implementa la persistencia de la información, que se consigue casi siempre mediante una base de datos relacional. En caso de usar EJBs de entidad con persistencia manejada por el contenedor, la persistencia estará ya implementada en gran medida. En otro caso, esta persistencia se implementará mediante clases Java con JDBC para acceder a la base de datos.

3.2 Patrones J2EE para la capa de negocio

En el Sun Java Center se definen una serie de patrones J2EE orientados a la capa de negocio. La mayoría de ellos están diseñados para aplicaciones que hagan uso de EJBs. Algunos son:

• Business delegate: sirve de interfaz entre la capa de presentación y la de negocio. La capa de presentación no debe conocer cómo está implementada la de negocio (por ejemplo si ésta usa o no EJBs). Es el business delegate el que conoce estos detalles. Si se cambia la implementación de la capa de negocio, bastará con cambiar el business delegate para que todo funcione igual, siempre que éste mantenga el mismo interfaz con la capa de presentación. El business delegate no será más que una clase Java arbitraria.
• Session Facade: sirve de interfaz entre el business delegate y los beans de entidad de la aplicación. Cuando una operación implica el acceso a varios beans de entidad (por ejemplo, reservar varios vuelos de avión para un trayecto en el que no hay avión directo) hay que realizar varias llamadas a procedimientos remotos, lo que supone un coste considerable. El session facade puede implementarse como un bean de sesión (normalmente sin estado) que haga llamadas locales a cada uno de los beans de entidad. Además, se mejora la mantenibilidad del código, ya que la operación se realiza desde un solo objeto.
• Service Locator: para que un business delegate pueda llamar a un session facade, éste pueda llamar a un bean de entidad o para acceder a una base de datos, normalmente es necesario hacer llamadas a JNDI, que pueden ser bastante costosas. El service locator es una clase Java que actúa de cache, de manera que no es necesario obtener el interfaz home a un bean o el datasource de una base de datos más que una vez. Además, mejora la mantenibilidad del código al centralizar todas las llamadas a JNDI.
• Transfer object o Value object: la capa de negocio necesita intercambiar datos con la de presentación. Estos datos se modelan con un value object, que no será más que un bean de Java (no un EJB) que encapsule la información. La capa de presentación siempre utiliza estas clases, independientemente de que "por debajo" hayan o no EJBs. Aun en el caso de que la capa de negocio utilice EJBs, acceder directamente a ellos desde la capa de presentación es muy costoso si se accede individualmente a los campos del objeto.

3.3 Ejemplo de implementación de la capa de negocio

La aplicación amigosJ2EE implementa algunos patrones de la capa de negocio. Esta aplicación es el "esqueleto básico" de una mini-comunidad virtual en la que los usuarios pueden darse de alta, generando una página web con sus datos y pudiendo buscar a los demás usuarios de la comunidad según distintos criterios (edad, sexo, lugar de residencia,...).

3.3.1 Business delegate (clases UsuarioDelegate y UsuarioDelegateEJB)

Estas clases proporcionan una serie de servicios (métodos) que sirven para acceder a la capa de negocio. La diferencia es que la clase UsuarioDelegateEJB utiliza EJBs para implementar lógica de negocio y acceso a datos, mientras que la clase UsuarioDelegate implementa el acceso a datos mediante JDBC.

3.3.2 Session Facade (bean de sesión sin estado UsuarioFacade)

Este bean tiene únicamente un interfaz remoto, ya que su cliente (el business delegate) no tiene por qué estar en el contenedor EJB. Como ejemplo del tipo de métodos que contiene, se muestra el que permite obtener un value object con los datos de un usuario

public class UsuarioFacadeBean implements SessionBean {


(...)


 public UsuarioVO getUsuario(String login) {
   ServiceLocator locator;
   UsuarioLocalHome home;
   UsuarioLocal usuario;
   UsuarioVO uvo;
   
   //obtener el interfaz home local del bean de entidad
   //mediante los servicios de un ServiceLocator
   locator = ServiceLocator.getServiceLocator();
   try {
      home = (UsuarioLocalHome) locator.getEJBLocalHome(ServiceLocator.USUARIO_LOCAL,
                                                        UsuarioLocalHome.class);
      //obtener el usuario mediante su login (clave primaria del bean)
      usuario = home.findByPrimaryKey(login);
      //obtener el value object

      uvo = usuario.getUsuarioVO();
      return uvo;
   }
   catch(Exception e) {
      throw new EJBException(e);
   } 
}
 

El session facade accede mediante un interfaz local a los beans de entidad (aunque en este caso solo hay uno), para aumentar la eficiciencia. Se hace uso de un Service Locator para obtener este interfaz local. Los beans de entidad utilizan persistencia manejada por el contenedor.

3.3.3 Service Locator (clase ServiceLocator)

Esta clase realiza las llamadas JNDI necesarias para obtener los interfaces home de acceso a los beans de entidad. Una vez obtenido el interfaz home, se guarda en una caché (implementada en este caso mediante una HashTable), para que si se solicita otra vez, no sea necesario hacer otra llamada JNDI. Toda la aplicación comparte la misma instancia de ServiceLocator, por lo que esta clase implementa lo que se denomina el patrón singleton (una clase cuyo constructor no es público, sino que su única instancia se obtiene mediante un método estático. La propia clase se encarga de controlar que solo haya una instancia).

3.3.4 Value Object (clase UsuarioVO)

Esta clase no es más que un bean ordinario de Java que encapsula los datos de un usuario del sistema (login, edad, localidad, ....).

3.4 Patrones J2EE para la capa de acceso a datos

El patrón básico para la capa de acceso a datos es el Data Access Object, empleado cuando se accede a la base de datos con JDBC en lugar de utilizar persistencia manejada por el contenedor. Gracias a este patrón, la capa de negocio se independiza del almacén de datos empleado (que normalmente será una base de datos relacional pero podría ser incluso un fichero XML o de texto, para casos sencillos).

En la mini-aplicación amigosJ2EE, este patrón se implementa por ejemplo en la clase UsuarioDAO. Esta clase encapsula el código JDBC necesario para obtener, crear y buscar usuarios en la base de datos. Si se cambia la estructura o el motor de la base de datos, únicamente será necesario cambiar la clase UsuarioDAO, quedando igual que estaba la capa de negocio.