O padrão serviço/sessão de fachada

O padrão ``serviço (ou sessão) de fachada'' é bastante usado, em ambientes EJB, para evitar que clientes façam chamadas remotas a componentes tipo entidade. Nesse padrão de projeto, todos os acessos remotos aos dados das entidades devem ser mediados por componentes tipo serviço ou sessão residentes no mesmo servidor. Os componentes tipo serviço ou sessão recebem as chamadas remotas dos clientes e fazem chamadas locais a componentes tipo entidade. Tal arranjo tem o objetivo de minimizar o número de chamadas remotas e o tráfego de dados entre os clientes e o servidor.

No caso de componentes EJB, o padrão serviço/sessão de fachada é conhecido simplesmente como session facade, pois na terminologia EJB o nome session é usado tanto para componentes tipo serviço (stateless session beans) como para componentes tipo sessão (stateful session beans). Para mais informações sobre esse padrão de projeto no contexto de EJB, veja o livro EJB Design Patterns, de Floyd Marinescu (Wiley, 2002).

O arquivo VideoRental.idl, incluído ao final deste texto, mostra o uso de um serviço de fachada numa aplicação servidora voltada para vídeo-locadoras. Há três tipos de entidades no servidor da vídeo-locadora:

• filme (interfaces Movie e MovieHome),
• exemplar de filme (interfaces MovieCopy e MovieCopyHome) e
• usuário (interfaces Customer e CustomerHome).

O uso de tipos de entidades distintos para Movie e MovieCopy capturam a diferença entre um ``filme abstrato'' (o conteúdo de um DVD ou de uma fita VHS) e um exemplar (cópia física) de filme, em DVD ou VHS. O que você aluga e leva para casa é o exemplar, não o filme.

Veja, no arquivo VideoRental.idl, que há um relacionamento 1 para N entre Movie e MovieCopy (podem haver muitos exemplares de um filme). No lado Movie, esse relacionamento se manifesta através das operação getCopies. No lado do MovieCopy ele se manifesta através da operação getMovie.

Há também um relacionamento 1 para N entre Customer e MovieCopy (um usuário pode alugar muitos CDs ou fitas VHS). Note que a data de devolução de um ítem alugado é, conceitualmente, um atributo desse relacionamento. No lado do Customer, o relacionamento se manifesta através da operação getTakenMovieCopies e no lado do MovieCopy através das operações isRented, rentTo, unrent, getTaker e getReturnDate.

Um cliente remoto poderia desempenhar todas as suas tarefas (consultar as informações sobre um filme, alugar um exemplar de filme para um usuário, etc.) fazendo chamadas às operações dos objetos CORBA que representam as entidades acima descritas. Alternativamente, pode-se fazer com que o servidor disponibilize um ``serviço de fachada'' e escrever um cliente remoto que faça acesso apenas ao objeto CORBA que representa a fachada. O arquivo VideoRental.idl define também a interface RentalService, que provê o serviço de fachada. Note que esse serviço usa a estrutura auxiliar MovieInfo para passar ao cliente remoto, de uma só vez, todas as informações sobre um filme. O uso de estruturas auxiliares, que carregam um monte de informações de uma vez, tem o objetivo de reduzir o número de interações entre servidor e seus clientes remotos. Esse é outro padrão de projeto, conhecido como data transfer object (DTO) e bastante usado em sistemas distribuídos. O livro EJB Design Patterns (citado anteriormente) contém mais informações sobre esse padrão no contexto de EJB.