Catálogo de Patrones de Diseño J2EE. Y II: Capas de Negocio y de Integración

Los Beans Enterprise encapsulan l�gica y datos de negocio y exponen sus interfaces, y con ellos la complejidad de los servicios distribuidos, a la capa de cliente.

.�Problema

En un entorno de la aplicaciones multicapa de la Plataforma Java 2, se pueden encontrar los siguientes problemas:

  • Acoplamiento fuerte, que provoca la dependencia directa entre los clientes y los objetos de negocio.
  • Demasiadas llamadas a m�todos entre el cliente y el servidor, abocando a problemas de rendimiento de la red.
  • Falta de una estrategia de acceso uniforme de los clientes, exponiendo los objetos de negocio a una mala utilizaci�n.

Una aplicaci�n J2EE multicapa tiene numerosos objetos del lado del servidor que se implementan como beans enterprise. Adem�s, otros objetos arbitrarios podr�an proporcionar servicios, datos o las dos cosas. A estos objetos los conocemos colectivamente como objetos de negocio, ya que encapsulan datos y l�gica de negocio.

Las aplicaciones J2EE implementan objetos de negocio que proporcionan servicios de procesamiento como beans de sesi�n. Los objetos de negocio gen�ricos que representan una vista de un objeto de almacenamiento persistente y que es compartido por varios usuarios, normalmente se implementan como beans de entidad.

Los clientes de la aplicaci�n necesitan acceder a los objetos de negocio para cumplir sus responsabilidades y para cumplir los requerimientos del usuario. Los clientes pueden interact�ar directamente con estos objetos de negocio porque �stos exponen sus interfaces. Cuando exponemos nuestros objetos de negocio al cliente, el cliente debe entender y ser responsable de las relaciones con los objetos de datos de negocio, y debe poder manejar el flujo del proceso de negocio.

Sin embargo, la interacci�n directa entre el cliente y los objetos de negocio implica un acoplamiento fuerte entre los dos, y dicho acoplamiento hace que el cliente dependa de la implementaci�n de los objetos de negocio. Dependencia directa significa que el cliente debe representar e implementar las interacciones complejas teniendo en cuenta la b�squeda y creaci�n de objetos, y debe manejar la relaci�n entre los objetos de negocio participantes as� como entender la responsabilidad de la demarcaci�n de transaciones.

Seg�n se van incrementando los requerimientos del cliente, tambi�n se incrementa la complejidad de las interacciones entre los distintos objetos de negocio. El cliente se hace de mayor tama�o y m�s complejo para cumplir esos requerimientos. El cliente se vuelve muy susceptible a los cambios en la capa de objetos de negocio; adem�s, exponemos inncesariamente el cliente a las complejidades subyacentes del sistema.

El acoplamiento fuerte entre objetos tambi�n se obtiene cuando los objetos manejan sus relaciones entre ellos mismos. Fruecuentemente, no est� claro donde se manejan las relaciones. Esto provoca la complejidad de las relaciones entre los objetos de negocio y la rigidez en la aplicaci�n. Esta falta de flexibilidad hace las aplicaciones menos manejables cuando se necesita hacer cambios.

Cuando acceden a beans enterprise, los clientes interact�an con objetos remotos. Se podr�an producir problemas de rendimiento de red si el cliente interact�a directamente con todos los objetos de negocio participantes. Cuando se invoca a beans enterprise, cada llamada del cliente potencialmente es una llamada a un m�todo remoto. Seg�n se incrementa el n�mero de participantes en un escenario, se incrementa el n�mero de estas llamadas remotas. Y seg�n aumentan las llamadas remotas, tambi�n se incrementa "el parloteo" entre el cliente y los objetos de negocio del lado del servidor . Esto podr�a resultar en una degradaci�n del rendimiento de la red, porque el gran volumen de llamadas a m�todos remotos incrementa la cantidad de interacciones sobre la capa de red.

Aparece otro problema cuando un cliente interact�a directamente con los objetos de negocio. Como los objetos de negocio se exponen directamente a los clientes, no hay una estrategia unificada para acceder a ellos. Sin dicha estrategia uniforme de acceso por parte del cliente, los objetos de negocio se ven expuestos a los clientes y se podr�a reducir su utilizaci�n consistente.

.�Causas

  • Proporcionar a los clientes un interface sencillo que oculte todas interacciones complejas entre los componentes de negocio.
  • Reducir el n�mero de objetos de negocio que se exponen al cliente a trav�s de la capa de servicio sobre la red.
  • Ocultar al cliente las interacciones y las interdependencias entre los componentes de negocio. Esto proporciona una mejor manejabilidad, centralizaci�n de interacciones (responsabilidades), mayor flexibilidad, y mayor habilidad para soportar los cambios.
  • Proporcionar una capa de servicio uniforme para separar la implementaci�n de los objetos de negocio de la abstracci�n del servicio de negocio.
  • Evitar la exposici�n directa de los objetos de negocio a los clientes para mantener el acoplamiento entre las dos capas al m�nimo.

.�Soluci�n

Usar un bean de sesi�n como una fachada (facade) para encapsular la complejidad de las interacciones entre los objetos de negocio participantes en un flujo de trabajo. El Session Facade maneja los objetos de negocio y proporciona un servicio de acceso uniforme a los clientes.

Session Facade abstrae las interacciones de los objetos de negocio y proporciona una capa de servicio que expone s�lo los interfaces requeridos. As�, oculta a la vista de los clientes las interacciones complejas entre los participantes. El Session Facade controla las interacciones entre los datos de negocio y los objetos de servicio de negocio que participan en el flujo de trabajo, y encapsula la l�gica de negocio asociada con los requerimientos, As�, el bean de sesi�n (representando al Session Facade) maneja las relaciones entre los objetos de negocio. El bean de sesi�n tambi�n maneja el ciclo de vida de los participantes creando, localizando (buscando), modificando, y borr�ndolos seg�n lo requiera el flujo de trabajo. En una aplicaci�n compleja, el Session Facade podr�a delegar este control del estilo de vida en un objeto separado. Por ejemplo, para controlar el estilo de vida de los beans de sesi�n e identidad participantes, Session Facade podr�a delegar este trabajo a un objeto Service Locator.

Es importante examinar las relaciones entre los objetos de negocio. Algunas de estas relaciones son temporales, lo que significa que la relaci�n es aplicable s�lo a esa interacci�n o escenario. Otras relaciones podr�an ser m�s permanentes. Las relaciones temporales se modelan mejor como flujos de trabajo en una fachada, donde la fachada maneja las relaciones entre los objetos de negocio. Las relaciones permanentes entre dos objetos de negocio deber�an estudiarse para determinar qu� objeto de negocio (si no �mbos) mantiene la relaci�n.

Casos de Utilizaci�n y Session Facades

Entonces, �c�mo podemos identificar el Session Facades estudiando casos de uso? Mapear cada caso a un Session Facade resultar� en demasiados Session Facades. Esto derrota la intenci�n de tener menos beans de sesi�n gen�ricos. En su lugar,cuando derivemos los Session Facades durante nuestro modelado, debemos consolidarlos dentro de un menor n�mero de beans de sesi�n bas�ndonos en alg�n particionamiento l�gico.

Por ejmplo, para una aplicaci�n de banca, podr�amos agrupar las interacciones relacionadas parar manejar una cuenta en una sola fachada. Los casos de utilizaci�n Crear una Nueva Cuenta, Cambiar Informaci�n de la Cuenta, Ver informaci�n de la Cuente, etc. tratar�n con un objeto de entidad gen�rico llamado Account. No se recomienda crear una fachada para cada caso de utilizaci�n. As�, las funciones requeridas para soportar estos usos relacionados se podr�an agrupar en un s�lo Session Facade llamado AccountSessionFacade.

En este caso, el Session Facade se convertir� en un controlador gen�rico con m�todos de alto nivel que puede facilitar cada interacci�n (es decir, createNewAccount, changeAccount, getAccount). Por lo tanto, recomendamos que dise�es los Session Facades para agregar un grupo de interacciones relacionadas en un s�lo Session Facade. Esto resulta en menos Session Facades para la aplicaci�n, y aprovecha los beneficios del patr�n Session Facade.

.�Estructura

La siguiente figura representa el diagrama de clases del patr�n Session Facade.

.�Participantes y Colaboraciones

La siguiente figura contiene el diagrama de secuencia que muestra las interacciones de un Session Facade con dos beans de entidad, un bean de sesi�n y un DAO, todos actuando como participantes en el cumplimiento de la petici�n del cliente.

.�Client

Representa al cliente del Session Facade, que necesita acceder al servicio de negocio. Este cliente puede ser otro bean de sesi�n (Session Facade) en la misma capa de negocio o un Business Delegate en otra capa.

.�SessionFacade

El SessionFacade se implementa como un bean de sesi�n. Maneja la relaciones entre varios objetos de negocio y proporciona una abstracci�n de alto nivel para el cliente. El SessionFacade ofrece acceso gen�rico a los BusinessObject participantes representados por la llamada Invoke en el bean de sesi�n.

.�BusinessObject

BusinessObject es un objeto de rol que facilita la aplicaci�n de diferentes estraegias, como beans de sesi�n, de entidad o DAO. Un BusinessObject proporciona datos y/o alg�n servicio del diagrama de clases. El SessionFacade interact�a con varios ejemplares de BusinessObject para proporcionar el servicio.

.�Estrategias

Session Facade es un objeto controlador de la capa de negocio que controla las interacciones entre el cliente y los datos de negocio y los objetos de servicio de negocio. En una aplicaci�n compleja, podr�a haber numerosos Session Facades que pueden intermediar entre el cliente y esos objetos. Podemos identificar d�nde podr�a ser �til un Session Facade estudiando los requerimientos e interacciones del cliente que normalmente se documentan en casos de utilizaci�n y escenarios. Este an�lisis nos permite identificar una capa controladora -- compuesta de Session Facades -- que puede actuar como fachadas para estos escenarios.

.�Stateless Session Facade

Cuando se implemente Session Facade, primero debemos decidir si el bean del Facade Session va a ser un bean de sesi�n con o sin estado. Basamos esta decesi�n en los procesos de negocio que el Session Facade est� modelando.

Un proceso de negocio que s�lo necesita una llamada a un m�todo para completar el servicio es un proceso de negocio no conversacional. Dichos procesos son ideales para implementarlos utilizando beans de sesi�n sin estado.

Un estudio cuidadoso de estos casos de utilizaci�n y escenarios nos permite determinar las definiciones del Session Facade. Si el caso de utilizaci�n no es conversacional, los clientes inician la utilizaci�n con un �nico m�todo en el Session Facade. Cuando el m�todo se completa, el caso de utilizaci�n tambi�n se completa. No hay necesidad de grabar el estado conversacional entre una llamada al m�todo y la siguiente. En este escenario, el Session Facade se puede implementar como un bean de sesi�n sin estado.

.�Stateful Session Facade

Un proceso de negocio que necesita varias llamadas a m�todos para completar el servicio es un proceso de negocio conversacional. El estado conversacional debe grabarse entre cada invocaci�n del m�todo por parte del cliente. En este escenario, ser�a una mejor aproximaci�n utilizar un bean de sesi�n con estado para implementar el Session Facade.

En las dos estrategias anteriores, el rol del objeto de negocio se puede cumplir de diferentes formas, como se explica m�s abajo.

.�Estrategias para Objetos de Negocio

Podemos implementar un objeto de negocio como un bean de sesi�n, un bean de entidad, DAO, o un objeto normal Java. Las siguientes estrategias discuten todas estas opciones:

.�Session Bean

El objeto de negocio se puede implementar como un bean de sesi�n. El bean de sesi�n normalmente proporciona un servicio de negocio y, en algunos casos, tambi�n podr�a proporcionar datos de negocio. Cuando dicho bean de sesi�n necesite acceder a los datos, podr�a utilizar un DAO para manipularlos. El Session Facade puede envolver uno o m�s beans de sesi�n orientados a servicio u orientados a datos actuando como objetos de negocio.

.�Entity Bean

Representar el objeto de negocio mediante un bean de entidad es el uso m�s com�n de Session Facade. Cuando varios beans de entidad participan en el caso de utilizaci�n, no es necesario exponerlos todos al cliente. En su lugar, el Session Facade puede envolver estos beans de entidad y proporcionar m�todos gen�ricos para realizar las funciones de negocio requeridas, y as� ocultar la complejidad de las interacciones de beans de entidad.

.�Data Access Object (DAO)

El Session Facade puede utilizar directamente uno o m�s DAOs para representar los datos de negocio. Esto se hace cuando la aplicaci�n es tan simple que no requiere beans de entidad, o cuando la arquitectura de la aplicaci�n est� basada s�lo en beans de sesi�n y no utiliza beans de entidad. Utilizando DAOs dentro de beans de sesi�n se simula parcialmente la naturaleza persistente de los beans de entidad.

La aplicaci�n podr�a necesitar los servicios porporcionados por un objeto Java normal (es decir, un objeto que no es un bean enterprise ni un DAO, aunque un DAO se podr�a considerar un objeto Java normal). En dicho caso, el Session Facade accede a este objeto arbitrario para proporcionar las funcionalidades necesarias.

.�Consecuencias

  • Introduce la Capa Controladora para la Capa de Negocio
    Los Session Facades pueden representar una capa controladora entre los clientes y la capa de negocios, identificado en el an�lisis del modelo. Un Session Facade acompasa las interacciones entre el cliente y los componentes de negocio. En una aplicaci�n sofisticada, podemos identicar numerosos Session Facades que pueden intermediar entre el cliente y los objetos de la capa de negocio. Para aplicaciones m�s simples, se podr�a creer que un Session Facade no a�ade mucho valor, ya que act�a principalmente como un proxy entre las peticiones del cliente y un componente de negocio. Sin embargo, seg�n se van complicando las aplicaciones con el tiempo, utilizar un Session Facade desde el principio nos benficiar� en un estado posterior.
  • Expone un Interface Uniforme
    Las interacciones entre los componentes de negocio pueden ser muy complejas. Un patr�n Session Facade abstrae esta complejidad y le presenta al cliente un interface sencillo que es f�cil de entender y de utilizar. Aplicando un Session Facade, podemos dise�ar una capa de servicio que exponga interfaces sencillos al sistema como una totalidad. As� una fachada proporciona una capa de acceso uniforme para todos los tipos de clientes y puede proteger y ocultar los componentes de negocio participantes.
  • Reduce el Acoplamiento, Incrementa la Manejabilidad
    Utilizar un Session Facade desacopla los objetos de negocio de los clientes, y as� reduce el fuerte acoplamiento y la dependencia de los clientes de los objetos de negocio. Es mejor utilizar un Session Facade para manejar el flujo de trabajo entre los objetos de negocio, en vez de hacer que los objetos de negocio se preocupen unos de otros. Un objeto de negocio s�lo deber�a ser responsable de su propio control (datos y l�gica). Las interacciones de objetos de negocio se puede abstraer dentro de un flujo de trabajo en una fachada. Esto proporciona una mejor manejabilidad, centralizaci�n de interacciones (responsabilidad y flujo de trabajo), mayor flexibilidad, y mayor habilidad para soportar los cambios.
    Separar el flujo de trabajo en un Session Facade elimina la dependencia directa del cliente de los objetos participantes y promueve un dise�o flexible. Aunque los cambios en los participantes podr�an requerir cambios en el Session Facade, centralizar el flujo de trabajo en la fachada hace que dichos cambios sean m�s manejables. Podemos cambiar s�lo el Session Facade en vez de tener que cambiar todos los clientes. El c�digo de los clientes tambi�n se simplifica porque ahora delegan las responsabilidades del flujo de trabajo en el Session Facade. El cliente ya no maneja las interacciones complejas del flujo de trabajo entre los objetos de negocio, ni se preocupa de las interdependencias entre los objetos de negocio.
  • Mejora el Rendimiento, Reduce los M�todos Espec�ficos
    Session Facade tambi�n impacta en el rendimiento. Reduce la sobrecarga de la red entre el cliente y el servidor porque su uso elimina la interacci�n directa entre el cliente y los datos y objetos de negocio. En su lugar, todas las interacciones se enrutan mediante el Session Facade de manera gen�rica. El Session Facade y sus participantes se acercan unos a otros, haciendo m�s eficiente para la fachada el manejo de las interacciones entre los objetos participantes. Todas las trasferencias de datos y las llamadas a m�todos desde la fachada a los participantes se realizan presumiblemente sobre una red de relativa alta velocidad. El rendimiento de red se puede ajustar proporcionando una m�xima salida aplicando el patr�n Transfer Object donde se pueda aplicar a los objetos participantes.
  • Proporciona Acceso Gen�rico
    Session Facade se ha pensado para ser una abstraci�n gen�rica del flujo de trabajo. As�, no es deseable tener un Session Facade por cada interacci�n con un bean de entidad, que podr�a representar una abstracci�n espec�fica en vez de una gen�rica. Se debe analizar la interacci�n entre el cliente y los servicios de la aplicaci�n, utilizando casos de utilizaci�n y escenarios para determinar la bulgaridad de la fachada. Determinamos la especificidad �ptima del Session Facade para la aplicaci�n particionando la aplicaci�n en subsistemas l�gicos y proporcionando un Session Facade para cada subsistema. Sin embargo, proporcionar una s�la fachada para todo el sistema puede resultar en un Session Facade muy grande cuyos numerosos m�todos lo hagan ineficiente. Un s�lo Session Face podr�a ser suficiente para aplicaciones muy simples que no requieran subsistemas.
  • Centraliza el Control de Seguridad
    Las pol�ticas de seguridad de la aplicaci�n se pueden controlar al nivel del Session Facade, ya que �sta es la capa presentada a los clientes. Debido al acceso gen�rico del Session Facade, es m�s f�cil y m�s manejable definir pol�ticas de seguridad en este nivel que al nivel de los componentes de negocio. Los componentes de negocio ofrecen puntos de control espec�ficos. Es m�s f�cil manejar la seguidad mediante Session Facades que proporcionan acceso gen�rico, porque son relativamente pocos los m�todos gen�ricos que tenemos que manejar de forma segura.
  • Centraliza el Control de Transaciones
    Como el Session Facade representa el flujo de trabajo para los casos de utilizaci�n, es m�s l�gico aplicar el control de transaciones a nivel del Session Facade. El control de transaci�n centralizado tiene ventajas similares a las de la seguridad centralizada. La fachada ofrece un lugar central para manejar y definir el control de transaciones de un forma gen�rica. Hay mucho m�s trabajo que hacer cuando el control de transaci�n se individualiza para cada componentes de negocio, especialmene porque son m�s espec�ficos que la fachada. La no utilizaci�n de un Session Facade, adem�s de hacer que el cliente acceda directamente a los beans enterprise, pone los l�mites de la transaci�n en el lado de cliente y puede producir resultados no deseados.
  • Expone Menos Interfaces Remotos a los Clientes
    Los clientes que interact�an directamente con los datos y servicios de negocio causan un incremento de la charlataner�a entre el cliente y el servidor. Este incremento podr�a degradar el rendimiento de la red. Todos los accesos a los objetos de negocio se deben hacer mediante un alto nivel de abstracci�n representado en el fachada. Como la fachada presenta un mecanismo de acceso gen�rico a los componentes de negocio, se reduce el n�mero de componentes de negocio que se exponen al cliente. Por lo tanto, se reduce el �mbito para la degradaci�n del rendimiento de la aplicaci�n debido al n�mero limitado de interacciones entre los clientes y el Session Facade en comparaci�n a la interacci�n directa entre el cliente y los componentes de negocio individuales.

.�C�digo de Ejemplo

.�Implementar el Session Facade

Considerando una Aplicaci�n de Servicios Profesionales (PSA), donde el flujo de trabajo relacionado con los beans de entidad (como Project, Resource) se encapsula en ProjectResourceManagerSession, implementado utilizando el patr�n Session Facade. El siguiente fragmento de c�digo muestra la interacci�n con los beans de entidad Resource y Project, as� como con otros componentes de negocio, como Value List Handlers y Transfer Object Assemblers.

 

package corepatterns.apps.psa.ejb;

import java.util.*;
import java.rmi.RemoteException;
import javax.ejb.*;
import javax.naming.*;
import corepatterns.apps.psa.core.*;
import corepatterns.util.ServiceLocator;
import corepatterns.util.ServiceLocatorException;

// Note: all try/catch details not shown for brevity.

public class ProjectResourceManagerSession
  implements SessionBean {

  private SessionContext context;

  // Remote references for the
  // entity Beans encapsulated by this facade
  private Resource resourceEntity = null;
  private Project projectEntity = null;
  ...

  // default create
  public void ejbCreate() 
  throws CreateException {
  }

  // create method to create this facade and to
  // establish connections to the required entity
  // beans
  // using primary key values
  public void ejbCreate(
    String resourceId, String projectId, ...)
  throws CreateException, ResourceException {

    try {
      // locate and connect to entity beans
      connectToEntities(resourceId, projectId, ...);
    } catch(...) {
      // Handle exceptions
    }
  }

  // method to connect the session facade to its 
  // entity beans using the primary key values
  private void connectToEntities (
    String resourceId, String projectId)
  throws ResourceException {
    resourceEntity = getResourceEntity(resourceId);
    projectEntity = getProjectEntity(projectId);
    ...
  }

  // method to reconnect the session facade to a
  // different set of entity beans using primary key
  // values
  public resetEntities(String resourceId,
    String projectId, ...)
  throws PSAException {

    connectToEntities(resourceId, projectId, ...);
  }

  // private method to get Home for Resource
  private ResourceHome getResourceHome()
  throws ServiceLocatorException {
    return ServiceLocator.      getInstance().getHome(
        "ResourceEntity", ResourceHome.class);
  }

  // private method to get Home for Project
  private ProjectHome getProjectHome()
  throws ServiceLocatorException {
    return ServiceLocator.      getInstance().getHome(
        "ProjectEntity", ProjectHome.class);  
  }

  // private method to get Resource entity
  private Resource getResourceEntity(
    String resourceId)   throws ResourceException {
    try {
      ResourceHome home = getResourceHome();
      return (Resource) 
        home.findByPrimaryKey(resourceId);
    } catch(...) {
      // Handle exceptions
    }
  }

  // private method to get Project entity
  private Project getProjectEntity(String projectId)
  throws ProjectException {
    // similar to getResourceEntity
    ...
  }

  // Method to encapsulate workflow related
  // to assigning a resource to a project.
  // It deals with Project and Resource Entity beans
  public void assignResourceToProject(int numHours)
  throws PSAException {

    try {
      if ((projectEntity == null) ||
          (resourceEntity == null)) {

        // SessionFacade not connected to entities
        throw new PSAException(...);
      }

      // Get Resource data
      ResourceTO resourceTO =
          resourceEntity.getResourceData();

      // Get Project data
      ProjectTO projectTO =
        projectEntity.getProjectData();
      // first add Resource to Project
      projectEntity.addResource(resourceTO);
      // Create a new Commitment for the Project
      CommitmentTO commitment = new
        CommitmentTO(  ...);

      // add the commitment to the Resource
      projectEntity.addCommitment(commitment);

    } catch(...) {
      // Handle exceptions
    }
  }

  // Similarly implement other business methods to
  // facilitate various use cases/interactions
  public void unassignResourceFromProject()
  throws PSAException {
    ...
  }

  // Methods working with ResourceEntity
  public ResourceTO getResourceData()
  throws ResourceException {
    ...
  }

  // Update Resource Entity Bean
  public void setResourceData(ResourceTO resource) 
  throws ResourceException {
    ...
  }

  // Create new Resource Entity bean
  public ResourceTO createNewResource(ResourceTO 
    resource)   throws ResourceException {
    ...
  }

  // Methods for managing resource's blockout time
  public void addBlockoutTime(Collection blockoutTime) 
  throws RemoteException,BlockoutTimeException {
    ...
  }
  
  public void updateBlockoutTime(
    Collection blockoutTime)   
  throws RemoteException, BlockoutTimeException {
    ...
  }
  
  public Collection getResourceCommitments() 
  throws RemoteException, ResourceException {
    ...
  }

  // Methods working with ProjectEntity
  public ProjectTO getProjectData()
  throws ProjectException {
    ...
  }

  // Update Project Entity Bean
  public void setProjectData(ProjectTO project) 
  throws ProjectException {
    ...
  }

  // Create new Project Entity bean
  public ProjectTO createNewProject(ProjectTO project)
  throws ProjectException {
    ...
  }

  ...

  // Other session facade method examples

  // This proxies a call to a Transfer Object Assembler
  // to obtain a composite Transfer Object.
  // See Transfer Object Assembler pattern
  public ProjectCTO getProjectDetailsData()
  throws PSAException {
    try {
      ProjectTOAHome projectTOAHome = (ProjectTOAHome)
        ServiceLocator.getInstance().getHome(
          "ProjectTOA", ProjectTOAHome.class);
      // Transfer Object Assembler session bean
      ProjectTOA projectTOA = 
          projectTOAHome.create(...);
      return projectTOA.getData(...);
    } catch (...) {
        // Handle / throw exceptions
    }
  }

  // These method proxies a call to a ValueListHandler
  // to get a list of projects. See Value List Handler 
  // pattern.
  public Collection getProjectsList(Date start, 
  Date end) throws PSAException {
    try {
      ProjectListHandlerHome projectVLHHome = 
        (ProjectVLHHome)
          ServiceLocator.getInstance().getHome(
            "ProjectListHandler",
            ProjectVLHHome.class);
      // Value List Handler session bean
      ProjectListHandler projectListHandler = 
        projectVLHHome.create();
      return projectListHandler.getProjects(
                    start, end);
    } catch (...) {
        // Handle / throw exceptions
    }
  }

  ...

  public void ejbActivate() {
    ...
  }

  public void ejbPassivate() {
    context = null;
  }

  public void setSessionContext(SessionContext ctx) {
       this.context = ctx;
  }

  public void ejbRemove() {
    ...
  }
}

En el siguiente ejemplo podemos ver el interface remoto para el Session Facade:


package corepatterns.apps.psa.ejb;

import java.rmi.RemoteException;
import javax.ejb.*;
import corepatterns.apps.psa.core.*;

// Note: all try/catch details not shown for brevity.

public interface ProjectResourceManager
  extends EJBObject {

  public resetEntities(String resourceId,
  String projectId, ...)
  throws RemoteException, ResourceException ;

  public void assignResourceToProject(int numHours)
  throws RemoteException, ResourceException ;

  public void unassignResourceFromProject()
  throws RemoteException, ResourceException ;

  ...

  public ResourceTO getResourceData()
  throws RemoteException, ResourceException ;

  public void setResourceData(ResourceTO resource) 
  throws RemoteException, ResourceException ;

  public ResourceTO createNewResource(ResourceTO resource)
  throws ResourceException ;

  public void addBlockoutTime(Collection blockoutTime) 
  throws RemoteException,BlockoutTimeException ;
  
  public void updateBlockoutTime(Collection blockoutTime) 
  throws RemoteException,BlockoutTimeException ;
  
  public Collection getResourceCommitments()
  throws RemoteException, ResourceException;

  public ProjectTO getProjectData()
  throws RemoteException, ProjectException ;
  
  public void setProjectData(ProjectTO project) 
  throws RemoteException, ProjectException ;

  public ProjectTO createNewProject(ProjectTO project)
  throws RemoteException, ProjectException ;

  ...

  public ProjectCTO getProjectDetailsData()
  throws RemoteException, PSAException ;

  public Collection getProjectsList(Date start, 
  Date end) throws RemoteException, PSAException ;

  ...
}

En el siguiente c�digo podemos ver el interface home para el Session Facade:


package corepatterns.apps.psa.ejb;

import javax.ejb.EJBHome;
import java.rmi.RemoteException;
import corepatterns.apps.psa.core.ResourceException;
import javax.ejb.*;

public interface ProjectResourceManagerHome 
extends EJBHome {
    
    public ProjectResourceManager create() 
            throws RemoteException,CreateException;
    public ProjectResourceManager create(String
        resourceId, String projectId, ...) 
            throws RemoteException,CreateException;
}

.�Patrones Relacionados

  • Facade [GoF]
    Session Facade est� basada en el patr�n de dise�o Facade.
  • Data Access Object
    Una de las estrategias para los componentes de negocio del patr�n Session Facade es utilizar el DAO. Este puede ser el caso de aplicaciones simples dise�adas utilizando beans de sesi�n y DAOs en lugar de beans de entidad.
  • Service Locator
    Session Facade es un objeto gen�rico que permite la encapsulaci�n del flujo de trabajo manejando datos de negocio y servicios de negocio. Los objetos de datos de negocio pueden ser beans de entidad o DAOs, y los servicios de negocio pueden ser beans de sesi�n u otros objetos que proporcionen servicios. Session Facade puede utilizar el patr�n Service Locator para reducir la complejidad del c�digo y explotar los beneficios ofrecidos por Service Locator.
  • Business Delegate
    Busines Delegate utiliza un Session Facade cuando el cliente solicita acceso a servicios de negocio. El Business Delegate hace de proxy o adapta la petici�n del cliente a un Session Facade que proporciona el servicio requerido.
  • Broker [POSA1]
    Session Facade realiza el rol de un broker para desacoplar los beans de entidad de sus clientes.

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP
ARTÍCULO ANTERIOR