A aplicação da arquitetura lógica descrita anteriormente é baseada em soluções que serão descritas aqui de maneira geral.

O IHM é formado pelo cliente simples na tecnologia Servlet/JSP padrão JEE. O framework Tiles deverá ser utilizado para facilitar a

criação e o reuso do layout das aplicações nesta tecnologia.

Mais precisamente, o IHM se apoia no framework Struts. Este framework é baseado no padrão de desenvolvimento MVC2

(Model View Controller).

Complementar ao framework Struts, deverá ser utilizado o framework Validator, para realizar os controles e validações necessários à camada

de apresentação.

Complementar ao framework Struts, poderá ser utilizado o framework DisplayTag que possui uma biblioteca de componentes gráficos que

respondem às necessidades freqüentes das aplicações e simplifica o desenvolvimento e a manutenção das JSP.

As entidades de negócio serão objetos simples do tipo JavaBeans, com suas propriedades com acesso de leitura e escrita

(getters e setters dos atributos). Atualmente com a utilização da JPA - Java Persistence API esta classe deverá ser anotada com a

annotation @Entity.

A persistência das entidades de negócio nas bases de dados será realizada através do framework Hibernate em conjunto com a

JPA - Java Persistence API. Em casos específicos, as operações na base de dados poderão ser realizadas diretamente via API JDBC padrão Java.

Os serviços de negócio serão objetos simples Java (POJO), com métodos correspondentes às funcionalidades propostas às camadas

superiores. No caso da camada de persistência, eles serão chamados DAO.

A utilização da tecnologia session EJB e JAX-WS deverá ser analisada para a escrita dos serviços, principalmente quando forem expostos

para outras aplicações e/ou para reutilização/componentização de regras de negócios específicas. Neste caso, os EJBs serão desenvolvidos

de acordo com as regras citadas para a camada enterprise.

Um log das execuções das aplicações deverá ser realizado e para isto deverá ser utilizado a API de Log Java ou framework Log4j.

Preferencialmente deverá ser logado para cada camada no nível DEBUG para possível redução/aumento do nível de log (WARN ou INFO)

quando em produção.

Os testes unitários deverão utilizar-se do framework JUnit para criação das classes de testes dos serviços das aplicações.

O framework Spring deverá ser utilizado para organizar, integrar e facilitar o desenvolvimento e reuso dos serviços desenvolvidos como

componentes. Seu papel não é substituir as soluções citadas aos outros frameworks complementares que serão úteis.
 

Contexto da Aplicação

A aplicação estará contida no contexto do framework Spring, ficando desta maneira independente do contexto utilizado para disponibilizá-la.

Desta maneira todos os beans de serviço disponíveis deverão ser solicitados ao framework Spring e para isto deverão estar configurados

de acordo com este framework. Neste arquivo web.xml é exemplificado a configuração da aplicação web utilizando este framework e os

outros propostos nesta documentação.

As partes principais são:

• configuração dos arquivos com os contextos da aplicação no parâmetro contextConfigLocation.

         ie.: /WEB-INF/classes/application-context.xml, /WEB-INF/classes/application-context-autz.xml

• configuração do filtro para abrir a sessão de manipulação dos dados pelo Hibernate OpenSessionInView a

         cada requisição para o(s) paths mapeados. ie.: *.do, *.report

• configuração do listener para carregar os contextos configurados org.springframework.web.context.ContextLoaderListener

        no parâmetro citado inicialmente.

• configurar o servlet org.springframework.web.servlet.DispatcherServlet do MVC do Spring para este fim utilizando o mapeamento

           default ou conforme configurado no arquivo report-servlet.xml para tratar esta requisição. ie.: *.report

• configurar o arquivo report-servlet injetando os serviços e parâmetros necessários para a geração dos relatórios como por exemplo

         o objeto sessionFactory para manipular dados no relatório com o framework Hibernate utilizando-se de HQL e o arquivo que irá

                    conter/resolver os templates dos       relatórios requisitados. ie.:report-views.xml

• configurar o arquivo report-views.xml com os templates dos relatórios que serão requisitados e parâmetros adicionais específicos

       para cada relatório.

Após estas configurações, para requisitar um relatório é necessário somente invocar uma URL com a extensão *.report

(ie.: beans.report) repassando os parâmetros: format com o formato desejado de saída (xls, rtf, html e pdf por padrão), report

com o nome do template do relatório configurado no arquivo *-views (ie.: exampleBeansReportGrayT) e outros parâmetros adicionais

esperados pelo template do relatório que será utilizado.

Contexto de testes da Aplicação

Um contexto adicional de testes deverá ser utilizado para a realização de testes conforme exemmplo no arquivo application-context-tests.xml.

Neste contexto podem ser adicionados/sobreescritos parâmetros e serviços para execução no contexto local dos testes, como por exemplo a

configuração de um datasource local é necessária para a execução dos testes de persistência da aplicação, visto que o datasource estará

presente somente no servidor utilizado. Outro exemplo seria configurar o acesso à serviços/componentes externos somente no ambiente de

desenvolvimento/integração para a realização dos testes.