Descrição da Arquitetura

1.                  Introdução

Este documento contém a descrição da arquitetura utilizada na construção do sistema Magazine Virtual.

 

 

2.                  Descrição

 

Funcionalidades / Use Cases

 

A arquitetura criada está atendendo aos seguintes use cases:

 

 

Requerimentos não funcionais

 

A arquitetura criada visa atender aos seguintes requisitos não funcionais (constantes no Documento de Visão):

 

 

Descrição curta da arquitetura

 

A solução baseia-se na especificação J2EE e na utilização de RDBMS para armazenamento dos dados.

A interface com usuário é através de páginas web geradas dinamicamente, porém a arquitetura suporta a implementação de diferentes interfaces com usuário para utilização do sistema. A camada de negócio é composta por EJBs do tipo session bean e entity bean.

 

3.                  Aspectos Functionais (Logical View)

 

Diagrama da arquitetura

 

 

 

 

 

 



Camadas

 

1.        Camada de apresentação

 

Na camada de apresentação foi utilizado Framework Struts. O Struts foi criado pelo projeto Jakarta, para facilitar a implementação dos padrões da camada de apresentação em aplicações JSP.

 

Este framework oferece:

 

2.        Camada de controle

 

Na camada de controle utilizamos Statelles Session Beans. Os Session Beans ficaram responsáveis pelo controle das transações e foram implementados usando o padrão facade.

 

3.        Camada de negócio

 

Na camada de negócio, encontram-se as entidades do sistema que estão implementadas através de EJB Entities do tipo CMP (persistência gerenciada pelo container). Conseqüentemente, as transações são CMT (transação gerenciada pelo container).

 

Como esta solução segue a especificação 2.0 do EJB, é possível configurar não só a persistência de forma descritiva, mas também o relacionamento entre as entidades e as queries de busca através de EJB-QL.

Nota: Queries não suportadas por EJB-QL podem ser escritas em Jboss QL.

 

Estes entidades são acessados por interfaces locais, em vez de interfaces remotas, para que haja aumento de performance, uma vez que as chamadas locais são mais rápidas que as remotas. Também para que os relacionamentos entre entities possam ser administrados pelo container, o que exige acesso local. A comunicação com clientes remotos é feita através dos sessions que possuem a interface apropriada.

 

                A especificação 2.0 do EJB não especifica o conceito de herança de componentes. Então, para a implementação da hierarquia presente no modelo, foram usados mecanismos de herança de interfaces e classes da linguagem Java, sem utilizar nenhum serviço específico do EJB Container.

 

Da forma representada abaixo, ou seja, a interface da classe filha herdando da interface da classe pai, pode-se utilizar o componente PagamentoBoleto como se fosse um Pagamento. As implementações dos métodos de negócio de Pagamento também podem ser aproveitadas pelo PagamentoBoleto, havendo override se necessário. As interfaces home não foram estendidas, deixando que cada componente tenha os seus próprios métodos de criação e recuperação.

 

O override dos métodos gets e sets dos atributos de Pagamento, em PagamentoBoleto, é necessário porque optou-se por criar uma tabela apenas com os campos da classe pai e uma tabela para cada classe filha com seus respectivos atributos. Desta forma, não é possível deixar que o bean PagamentoBoleto herde a abstração dos gets e sets de Pagamento, porque, assim, o container consideraria que a tabela PagamentoBoleto teria também os campos da tabela Pagamento. A implementação destes métodos em PagamentoBoleto faz uso do relacionamento entre os dois entities, pai e filho.

Padrões Utilizados

       

§       Centralizar o processamento de requisições em uma única fachada. Front Controller permite criar uma interface genérica para processamento de comandos.

§       Criar um componente de View a partir de Views menores para dividir as responsabilidades, simplificar a construção da interface e permitir o reuso de componentes da View.

§       Separar código e responsabilidades de formatação da interface do usuário do processamento de dados necessários à construção da View. Tipicamente implementados como JavaBeans e Custom Tags.

§       Combinar padrões de apresentação e encapsular lógica de navegação, que consiste em escolher uma View e  despachar a requisição para ela. Service To Worker realiza mais processamento antes de despachar a requisição.

§       Simplificar a interface do cliente de enterprise beans e controlar o acesso e a comunicação entre entity beans. Session Façade representa uma função ou várias funções exercidas por um sistema.

§       Isolar dos clientes de serviços de localização de recursos (JNDI) a lógica e informações relacionadas ao serviço oferecendo uma interface neutra. Service locator pode ser usado para abstrair todo uso de JNDI e ocultar as complexidades da criação de objetos.

§       "Garantir que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela." [GoF]

§       "Definir uma interface para criar um objeto mas deixar que subclasses decidam que classe instanciar. Factory Method permite que uma classe delegue a responsabilidade de instanciamento às subclasses." [GoF]

§       Reduzir a quantidade de requisições necessárias para recuperar um objeto. Value Object permite encapsular em um objeto um subconjunto de dados utilizável pelo cliente e utilizar apenas uma requisição para transferi-lo.

4.                  Aspectos Operacionais (Deployment View)

 

Os testes do sistema Magazine Virtual foram feitos em ambiente windows mas o sistema poderia ser usado em qualquer ambiente. Como infra-estrutura para os testes utilizamos os seguintes softwares:

 

 

5.                  Apêndice 1 – Referências

 

J2EE  –  http://java.sun.com/j2ee/

EJB  –  http://java.sun.com/products/ejb/

 

JBOSS – Application Server http://www.jboss.org/

 

MySQL – RDBMS http://www.mysql.com/

 

The Server Side – Padrões http://www.theserverside.com/patterns/index.jsp

 

Struts – http://jakarta.apache.org/struts