Core J2EE Patterns - Facade Session

Contexto
Enterprise beans encapsulam a lgica e os dados do negcio e expe suas interfaces e, assim, a
complexidade dos servios distribudos, para a nvel do cliente.
Problemas
Em uma Java 2 Plataform de mltiplos nveis, do ambiente de aplicao Enterprise Edition (J2EE), surgem
os seguintes problemas:
- Forte acoplamento, que leva a uma dependncia direta entre os clientes e os objetos de negcio;
- Muitas invocaes de mtodos entre cliente e servidor levam a problemas de performance de rede;
- A falta de uma estratgia uniforme de acesso do cliente, expe os objetos de negcio a usos indevidos.
Uma aplicao multicamadas J2EE tem inmeros objetos no lado do servidor, que so implementadas como
enterprise beans. Alm disso, alguns outros objetos arbitrrios devem prover servios, dados ou ambos,
lgica e dados do negcio. Esses objetos so coletivamente tratados como objetos de negcio, uma vez que
encapsulam os dados e a lgica do negcio.
Aplicaes J2EE implementam objetos de negcio que fornecem servios de processamento como session
beans. Objetos de negcio mais genricos (coarse-grained), que representam uma object view de
persistncia (persistent storage) e so compartilhados por vrios usurios so, geralmente, implementados
como entity beans.
Aplicaes cliente precisam acessar os objetos de negcio para cumprir suas responsabilidades e atender s
necessidades do usurio. Clientes podem interagir diretamente com estes objetos de negcio, porque eles
expe suas interfaces. Quando voc expe objetos de negcio para o cliente, o cliente deve compreender e
ser responsvel pelas relaes entre objetos de dados de negcio e devem ser capazes de lidar com o fluxo
de processo do negcio.
No entanto, a interao direta entre cliente e objetos de negcio leva a um alto nvel de acoplamento entre os
dois e tal nvel de acoplamento faz com que o cliente se torne diretamente dependente da implementao
dos objetos de negcio. Essa dependncia direta significa que o cliente deve representar e implementar as
interaes complexas relativas (regarding) s pesquisas e criaes dos objetos de negcio e devem gerenciar
os relacionamentos entre os objetos de negcio participantes, bem como compreender a responsabilidade de
demarcao da transao.
Como as requisies dos clientes aumentam, a complexidade da interao entre vrios objetos de negcio,
aumenta. O cliente cresce e se torna cada vez mais complexo para cumprir com essas exigncias e, assim,
torna-se muito sustetvel a mudanas na camada dos objetos de negcio. Alm disso, o cliente exposto,
desnecessariamente, complexidade do sistema subjacente.
Tambm ocorre o forte acoplamento quando objetos gerenciam suas relaes internamente. Frequentemente,
no fica claro onde a relao gerenciada. Isto leva a uma relao complexa entre objetos de negcio e e
rigidez na aplicao. Essa falta de flexibilidade torna a aplicao menos gerencivel quando mudanas se
tornam necessrias.
Ao acessar os enterprise beans, os clientes interagem com objetos remotos. Quando clientes interagem
diretamente com todos os objetos de negcio participantes, podem surgir problemas de desempenho de rede.

Ao chamar enterprise beans, cada invocao do cliente , potencialmente, uma chamada de mtodo remoto
(RMI). Cada acesso a um objeto de negcio se torna relativamente mais especfica (fine-grained). Como o
nmero de participantes aumenta neste cenrio, o nmero de chamadas para cada mtodo remoto tambm
aumenta. Como o nmero de mtodos remotos tende a aumentar, a conversao (chattiness) entre o cliente e
os objetos no lado do servidor, aumentam. Isto pode resultar na degradao do desempenho da rede para a
aplicao, porque o alto volume das chamadas de mtodo remoto aumentam a quantidade de interao
atravs da camada de rede.
Um problema tambm surge quando um cliente interage diretamente com os objetos de negcio. Uma vez
que os objetos de negcio so expostos diretamente aos cliente, no existe uma estratgia unificada para
acessar os objetos de negcio. Sem uma estratgia de acesso do cliente que seja uniforme, os objetos de
negcio so expostos aos cliente e podem reduzir a consistncia da utilizao.

Vantagens (Forces)
- Fornecer uma interface mais simples para os clientes, ocultando todas as interaes complexas entre
componentes de negcio.
- Reduzir o nmero de objetos de negcio que so expostos para o cliente atravs da camada de servios da
rede.
- Esconder do cliente as interaes subjacentes e interdependncias entre os componentes de negcio. Isto
proporciona uma melhor capacidade de gerenciamento, a centralizao das interaes (responsabilidades),
maior flexibilidade e maior capacidade de lidar com as mudanas.
- Fornecer uma camada de servio uniforme mais genrica, para implementao de objetos de negcio,
separada da abstrao de servios de negcio.
- Evitar expor, diretamente para o cliente, os objetos de negcio subjacentes, reduzindo o acoplamento entre
camadas distintas ao mnimo possvel.

Soluo
Usar uma session bean como uma fachada (facade) para encapsular a complexidae das interaes entre os
objetos de negcio que participam de um fluxo de trabalho. A facade session gerencia os objetos de negcio
e fornece aos clientes uma camada de acesso uniforme mais genrica.

A Facade Session abstrai as interaes entre objetos de negcio subjacentes e fornece uma camada de
servio que expe apenas as interfaces necessrias. Assim, ela oculta do cliente as complexas interaes
entre os participantes. A Facade Session gerencia as interaes entre os objetos de dados e de servios de
negcio que participam do fluxo de trabalho e encapsula a lgica de negcio associada com as solicitaes
requeridas. Assim, o session bean (que representa uma Facade Session) gerencia as relaes entre objetos de
negcio. O session bean tambm gerencia o ciclo de vida desses participantes, criando, localizando (looking
up), modificando e excluindo-os, conforme exigido pelo fluxo de trabalho. Em uma aplicao complexa, a
Facade Session pode delegar essa gesto do ciclo/estilo de vida para um objeto separado. Por exemplo, para
gerenciar o ciclo/estilo de vida da participant session e entity beans, a Facade Session pode delegar o
trabalho para um objeto Service Locator (veja "Service Locator" na pgina 368).
importante examinar a relao entre os objetos de negcio. Algumas relaes entre objetos de negcio so
transitrias (transients), o que significa que a relao aplicvel apenas para aquela interao ou cenrio.
Outras relaes podem ser mais permanentes. Relaes transitrias (transient) melhor modeladas como
fluxo de trabalho em uma fachada, onde a fachada gerencia os relacionamentos entre os objetos de negcio.
Relaes permanentes entre dois objetos de negcio devem ser estudadas para determinar qual objeto de
negcio (se no ambos os objetos) mantm o relacionamento.
Casos de uso e Facade Sessions

Ento, como voc identifica as Facade Sessions atravs do estudo de casos de uso? Mapear cada caso de
uso a uma Facade Session ir resultar em muitas fachadas. Isto destri a inteno de ter menos session
beans genricos. Em vez disso, como voc deriva a Facade Session durante a modelagem, buscando
consolida-la no menor nmero de session beans baseadas em algum particionamento de lgica.
Por exemplo, para uma aplicao bancria, voc pode agrupar as interaes relacionadas ao gerenciamento
de uma conta em uma nica fachada. Os casos de uso 'Criar Nova Conta', 'Alterar Informaes de Conta',
Exibir Informaes de Conta' e, assim por diante, todo o negcio com a entity beans genrica 'conta'. Criar
uma fachada para cada caso de uso no recomendado. Assim, as funes necessrias para apoiar esses
casos de uso relacionados poderiam ser agrupadas em uma nica fachada, chamada AcountSessionFacade.
Neste caso, uma fachada ir tornar-se um controlador altamente genrico com mtodos de alto nvel, que
podem facilitar a cada interao (isto , createNewAccount, changeAccount, getAccount). Portanto,
recomendamos que voc projete uma fachada para agregar um grupo de interaes relacionadas em uma
nica session. Isso resulta em menos fachadas para a aplicao e aproveita os benefcios do padro Facade
Session.

Estrutura
A Figura 8.15 mostra o diagrama de classe que representa o padro Facade Session.

Figura 8.15 diagrama de classe da Facade Session

Participantes e Colaboraes
A Figura 8.16 contm o diagrama de sequncia que mostra as interaes de uma fachada com dois entity
beans, um session bean, e um DAO, todos atuando como participantes no cumprimento da solicitao do
cliente.

Figura 8.16 Sesso Fachada diagrama de sequncia

Cliente
Representa o cliente de uma fachada, que precisa de acesso aos servios do negcio. Este cliente pode ser
outro session bean (Facade Session) na mesma camada de negcio ou um negcio delegado (consulte
"Business Delegate" na pgina 248) em outra camada.
SessionFacade
O SessionFacade implementado como um session bean. O SessionFacade gerencia as relaes entre os
vrios BusinessObjects e proporciona um alto nvel de abstrao para o cliente. O SessionFacade oferece
acesso genrico ao BusinessObject participantes representados pela invocao Invoke de uma session bean.
BusinessObject
O BusinessObject um role objet que facilita a aplicao de estratgias diferentes, tais como session beans,
entity beans e um DAO (consulte a prxima seo, "Estratgias"). O BusinessObject fornece dados e/ou
algum servio no diagrama de classes. O SessionFacade interage com vrias instncias de businessObject
para prestar o servio.

Estratgias
A Facade Session um objeto controlador da camada de negcio que controla as interaes entre o cliente e
os dados e objetos de servios do negcio que participam do atendimento da requisio. Em uma aplicao
complexa, pode haver numerosos fachadas, que podem intermediar clientes e estes objectos. Voc pode
identificar onde uma fachada pode ser til ao estudar os requisitos do cliente e interaes, tipicamente
documentadas em casos de uso e cenrios. Esta anlise permite identificar um controlador layer-composed

da Facade Session - que pode atuar como fachada para esses cenrios.
Esta seo explica diferentes estratgias para a implementao de uma Facade Session.

Estratgias para Facade Session

Estratgia Stateless (sem estado)
Ao implementar uma fachada, voc deve primeiro decidir se o session bean da fachada stateful (com
estado) ou um session bean sem estado (stateless). Baseando esta deciso no processo de negcio que a
fachada est modelando.
Um processo de negcio que precisa de apenas uma chamada de mtodo para completar o servio um
processo de negcio no-conversational. Tais processos so adequadamente implementados utilizando um
session bean sem estado.
Um estudo cuidadoso dos casos de uso e cenrios permite determinar as definies da fachada. Se o caso de
uso no-conversational, o cliente inicia o caso de uso usando um nico mtodo da Fachada. Quando o
mtodo for concludo, o caso de uso tambm termina. No h necessidade de salvar o estado da conversao
entre uma invocao de mtodo e a prxima. Neste cenrio, a fachada pode ser implementada como uma
session bean sem estado (stateless).
Estratgia Stateful (com estado)
Um processo de negcio que precisa de vrias chamadas de mtodo para concluir o servio um processo
de negcio de conversao. O estado da conversao deve ser salvo entre cada invocao de mtodo pelo
cliente. Neste cenrio, um session bean com informaes de estado pode ser uma abordagem mais adequada
para a execuo do Facade Session.
Em ambas as estratgias para uma fachada, o papel dos objetos de negcio pode ser cumprido de diferentes
maneiras, como explicado a seguir.

Estratgias para Business Objects

Voc pode implementar um objeto de negcio como um session bean, entity bean, DAO ou um objeto Java
regular. As estratgias a seguir discutem cada uma dessas escolhas.
Estratgia Session Bean
O objeto de negcio pode ser implementado como um session bean. O session bean normalmente fornece
um servio de negcio e, em alguns casos, tambm pode fornecer dados de negcio. Quando tal session
bean precisa de acesso a dados, pode usar um DAO para manipular os dados. A fachada pode envolver uma
ou mais sesses orientadas a servios ou orientadas a dados, tais beans atuando como objetos de negcio.
Estratgia Entity Bean
Representar o objeto de negcio por um entity bean o uso mais comum em uma fachada. Quando vrios
entity beans participam do caso de uso, no necessrio expor todos os entity beans para os clientes. Em
vez disso, a fachada pode envolver esses entity beans e fornecer um mtodo genrico para executar a funo
de negcio necessria, escondendo assim a complexidade das interaes entre as entity beans.
Estratgia Data Access Object

A fachada pode usar um ou mais DAOs diretamente, para representar os dados de negcio. Isso feito
quando o aplicativo to simples que no requer entity beans, ou quando a arquitetura do aplicativo
baseado apenas em session beans e no utiliza entity beans. Usar DAOs dentro do session beans simula
parcialmente a natureza persistente (persistent nature) dos entity beans.
A aplicao pode precisar dos servios prestados por um objeto Java arbitrrio (ou seja, um objeto que no
um enterprise bean ou de um DAO, embora um DAO possa ser visto como um tipo de objeto Java
arbitrrio). Em tais casos, a fachada acessa esse objeto Java arbitrrio para fornecer a funcionalidade
necessria.

Consequncias
Introduz uma camada que controla a camada de negcio
Sesso Fachadas pode representar uma camada de controle entre clientes e a camada de negcio, conforme
identificado por meio da modelagem de anlise. Uma fachada abrange as interaes entre o cliente e os
componentes de negcio. Em uma aplicao sofisticada, voc pode identificar inmeras Fachadas sesso
que podem intermedirio entre o cliente e os participantes objetos da camada de negcio. Para aplicaes
mais simples, pode-se sentir que uma fachada no est acrescentando muito valor, como pode agir para a
maioria de proxy as solicitaes do cliente para um nico componente de negcio. No entanto, como
aplicativos se tornam mais complexos ao longo do tempo, usando uma fachada na frente vai dar benefcio
numa fase posterior.
Expe interfaces uniformes
As interaes subjacentes entre os componentes de negcio podem ser muito complexas. Um padro Facade
Session abstrai esta complexidade e apresenta ao cliente uma interface mais simples, que fcil de entender
e usar. Ao aplicar uma fachada, voc pode criar uma camada de servio que expe interfaces mais simples
para o sistema como um todo. Assim, uma fachada fornece uma camada de acesso uniforme genrica a
todos os tipos de clientes e pode proteger e esconder os componentes de negcio subjacentes participantes.
Reduz o acoplamento, aumenta a capacidade de gerenciamento
Usar Facade Session separa os objetos de negcio dos clientes, reduzindo o acoplamento e a dependncia do
cliente sobre os objetos de negcio. melhor usar uma fachada para gerir o fluxo de trabalho entre os
objetos de negcio, ao invs de fazer os objetos de negcio cientes um do outro. Um objeto de negcio s
deve ser responsvel pela sua prpria gesto (lgica de dados). Interaes entre objetos inter-negcios
podem ser captadas em um fluxo de trabalho por uma fachada. Isto proporciona uma melhor capacidade de
gerenciamento, a centralizao das interaes (responsabilidade e workflow), maior flexibilidade e maior
capacidade de lidar com as mudanas.
A separao do fluxo de trabalho em uma fachada elimina a dependncia direta do cliente sobre os objetos
participantes e promove a flexibilidade de design. Embora as mudanas para os participantes podem exigir
mudanas na fachada, centralizando o fluxo de trabalho na fachada, estas mudanas sero mais manejveis.
Voc muda apenas a sesso de fachada, em vez de ter que mudar todos os clientes. Cdigo cliente tambm
fica mais simples, porque agora delega a responsabilidade do fluxo de trabalho para uma fachada. O cliente
j no administra as interaes complexas do fluxo de trabalho entre objetos de negcio, nem o cliente
ciente das interdependncias entre objetos de negcio.
Melhora o desempenho, reduz mtodos especficos
A Fachada tambm impacta no desempenho. Uma fachada reduz a sobrecarga de rede entre o cliente e o

servidor, porque o seu uso elimina a interao direta entre o cliente e os objetos de dados de negcio e de
servios de negcio. Em vez disso, todas as interaes so encaminhadas atravs da fachada de modo
genrico. A fachada e seus participantes esto mais prximos uns dos outros, tornando-a mais eficiente para
gerir as interaes entre os objetos participantes. Todas as transferncias de dados e chamadas de mtodo da
fachada para os participantes so, presume-se, atravs de uma rede de velocidade relativamente alta. O
desempenho da rede pode ainda ser ajustado para proporcionar o mximo de rendimento, aplicando o
padro Transfer Object para os objetos participantes, onde aplicvel.
Fornece acesso genrico
Uma fachada pretende ser uma abstrao altamente genrica do fluxo de trabalho. Assim, no desejvel ter
uma Fachada por interao de entity bean, o que representaria uma abstrao especfica, em vez de genrica.
Analisa a interao entre o cliente e os servios de aplicao, usando casos de uso e cenrios para
determinar a possibilidade de generalizao da fachada. Determina a generalidade ideal da fachada para a
aplicao dividindo a aplicao em subsistemas lgicos e proporcionando uma fachada para cada
subsistema. No entanto, fornecer uma nica fachada para a totalidade do sistema pode resultar em uma
sesso de fachada muito grande, cujos numerosos mtodos se tornariam ineficientes. Uma nica fachada
pode ser suficiente para aplicaes muito simples que no justifiquem subsistemas.
Centraliza o gerenciamento de segurana
Polticas de segurana para a aplicao pode ser gerida a nvel Sesso Fachada, uma vez que este o nvel
apresentado aos clientes. Por causa do acesso de genrica da Sesso Fachada, mais fcil e mais gerencivel
para definir polticas de segurana a este nvel, em vez de no nvel do componente de negcio participantes.
Os componentes de negcio oferecem pontos de controle refinado. mais fcil de gerenciar a segurana de
Fachadas de sesso que fornecem acesso de genrica, porque h relativamente menos mtodos de genrica a
ser geridos de forma segura.
Centraliza o controle de transao
Como a fachada representa o fluxo de trabalho para os casos de uso, mais lgico aplicar o gerenciamento
de transaes no nvel Facade Session. Controle de transao centralizada tem vantagens semelhantes a
segurana centralizada. A fachada oferece um local central para o gerenciamento e definio de controle de
transao de uma forma genrica. muito mais trabalhoso fazer gerenciamento de transaes
individualmente nos componentes de negcio participantes, especialmente porque eles so mais especficos
do que a fachada. Alm disso, no usar uma fachada e dar ao cliente acesso s enterprise beans diretamente,
coloca o nus de demarcao da transao no cliente e pode produzir resultados indesejados.
Expe menos interfaces remotas a clientes
Clientes que interagem diretamente com os dados de negcio e objetos de servio de negcio causam um
aumento nas conversaes entre o cliente e o servidor. Este aumento pode degradar o desempenho da rede.
Todo o acesso aos objetos de negcio deve ser atravs do maior nvel de abstrao representado por uma
fachada. Uma vez que a fachada apresenta um mecanismo de acesso genrico para os componentes de
negcio, isto reduz o nmero de componentes de negcio que so expostos para o cliente. Desse modo, a
possibilidade de degradao do desempenho da aplicao reduzida devido o nmero limitado de interaes
entre os clientes e uma fachada, quando comparado com a interao direta do cliente com os componentes
de negcio individuais.

Cdigo de amostra
Implementando uma fachada
Considere uma aplicao de Servios Profissionais (PSA), onde o fluxo de trabalho relacionado com as
entity beans (como Project, Resource) encapsulado em ProjectResourceManagerSession, implementado
usando o padro Session Facade. O exemplo 8.15 mostra a interao com as entity beans Resource e
Project, bem como com outros componentes de negcios, como Value List Handlers (consulte "Value List
Handler" na pgina 354) e Transferncia de Objeto Assembler (ver "Transferncia de Objeto Assembler" na
pgina 340).
Exemplo 8.15 Implementando Session Facade - Session Bean
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() {

...
}
}
The remote interface for the Session Facade is listed in Example 8.16.
Example 8.16 Implementing Session Facade - Remote Interface
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 ;
...
}
The Home interface for the Session Facade is shown in Example 8.17.
Example 8.17 Implementing Session Facade - Home Interface
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;
}
Related Patterns
Facade [GoF]
The Session Facade is based on the Facade Design pattern.
Data Access Object
One of the strategies for the business component in the Session Facade pattern is to use the DAO. This
can be the case in simpler applications designed using session beans and DAOs instead of entity beans.

Service Locator
The Session Facade is a coarse-grained object that allows encapsulation of the workflow by managing
business data and business service objects interactions. Business data objects can be entity beans or DAOs,
and the business service objects can be session beans and other objects that provide service. The Session
Facade can use the Service Locator pattern to reduce the code complexity and to exploit the benefits offered
by the Service Locator.
Business Delegate
The Session Facade is used by the Business Delegate when the client requests access to business services.
The Business Delegate proxies or adapts the client request to a Session Facade that provides the requested
service.
Broker [POSA1]
The Session Facade performs the role of a broker to decouple the entity beans from their clients.
http://www.oracle.com/technetwork/java/sessionfacade-141285.html