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

ENVIAR A UN AMIGO
COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN GOOGLE +
ARTÍCULO ANTERIOR

¡SÉ EL PRIMERO EN COMENTAR!
Conéctate o Regístrate para dejar tu comentario.