ManualDesenvolvimentoJ2EE SJSAS8 v1.0.3

Manual de Desenvolvimento
J2EE
Sun Java System Application Server 8
Uso Interno SUN/Caixa Pgina 1

Verso 1.0.3 28/01/2008
ndice
Nota inicial............................................................................... 5
Histrico .................................................................................. 5
Objetivo ................................................................................... 5
Foco da Plataforma J2EE ....................................................... 7
Necessidade da Arquitetura de Sistemas J2EE ..................... 8
Padres de Arquitetura ........................................................... 9
Modelo de Aplicaes J2EE .............................................................................. 10
Arquitetura da Camada Client para WEB ........................................................ 14
Arquitetura da Camada Presentation para WEB ............................................. 16
Arquitetura da Camada Client/Presentation para aplicaes Stand-Alone ..... 18
Arquitetura da Camada Business.................................................................... 19
Arquitetura da Camada Integration ................................................................. 22
Arquitetura da Camada Resource ................................................................... 23
Boas Prticas Java/J2EE...................................................... 25

Boa prtica aplicada: Segurana Declarativa na J2EE......... 25
Boa prtica aplicada: Usando o JavaMail ............................. 32
Arquitetura da JavaMail API 1.3.2 ..................................................................... 33
Classes principais.............................................................................................. 34
Servio JavaMail na J2EE ................................................................................. 35
Enviando um e-mail usando a J2EE e a JavaMail API 1.3.2 ............................. 36
Obtendo o Inbox para ler e-mails, usando a J2EE e a JavaMail API 1.3.2........ 37
Configurando as aplicaes J2EE para usar um conector de e-mail................. 38
Registrando um conector de e-mail no Sun Application Server 8...................... 39
Boa prtica aplicada: Utilizando os recursos da J2SE 1.5.... 40

Generics ............................................................................................................ 40
For-Each Loop ................................................................................................... 40

Verso 1.0.3 28/01/2008
Annotations........................................................................................................ 40
Autoboxing/Unboxing......................................................................................... 40
Boa prtica aplicada: Mapeamento de JSP .......................... 41

Definies de HA ............................................................................................... 41
Critrios de mapeamento................................................................................... 41
Exemplos ........................................................................................................... 42
Mapeando um JSP ............................................................................................ 43
Boa prtica aplicada: Usando o Jakarta Struts 1.3 ............... 44

Implementando com o Jakarta Struts 1.3 para o Sun Application Server 8 ....... 45
Configuraes para o Jakarta Struts 1.3 para o SJSAS8 .................................. 45
Boas Prticas de Implementao ......................................... 49

Recomendaes para URLs.............................................................................. 49
Recomendaes para JSPs .............................................................................. 50
Recomendaes para Aplicaes Web ............................................................. 51
Recomendaes para DAOs (Data Access Objects)......................................... 52
Recomendaes para Delegates, Actions, Strategies, etc. ............................... 53
Recomendaes para EJBs (Enterprise JavaBeans) .................................... 54
Recomendaes para Web Services................................................................. 58
Recomendaes para Empacotamento das Aplicaes.................................... 59
Recomendaes para Deploy das Aplicaes................................................... 61
Recomendaes para Log das Aplicaes........................................................ 61
Recomendaes para Inspeo da Qualidade do Cdigo................................. 61
Recomendaes para Aplicaes Cliente ......................................................... 62
Recomendaes gerais ..................................................................................... 65
Filas de Mensagens (JMS Java Message Service) ........................................ 66
Componentes Corporativos .................................................. 67

Verses das principais bibliotecas no SJSAS8.................................................. 69
Problemas e BUGs em Frameworks de Mercado.............................................. 70
Referncias ........................................................................... 71

Verso 1.0.3 28/01/2008
Introduo

Verso 1.0.3 28/01/2008
Nota inicial
Verificar periodicamente a pgina do SIT para a ltima verso deste
documento.
Histrico
Desde a adoo da tecnologia Java/J2EE pela Caixa no fim do ano 2000,
muitos sistemas foram desenvolvidos e implantados sem seguir corretamente as
recomendaes da Sun Microsystems e JavaSoft para o desenvolvimento Java,
fazendo com que a sustentao desses sistemas seja extremamente onerosa do
ponto de vista humano e tecnolgico.
Objetivo
Atualmente, com a escassez de recursos tecnolgicos e o alto ndice de
turn-over de pessoal nas equipes de desenvolvimento, homologao e
sustentao, se faz altamente necessrio que a Caixa tenha um manual
tecnolgico de boas-prticas e padres para Java/J2EE, visando garantir a
qualidade do software e andamento dos processos de desenvolvimento,
homologao e implantao, previsto na MDS, e que a sustentao desses
sistemas seja mais fcil.
Este manual tem como objetivo reunir os documentos criados pela equipe
da Sun desde Maio/2004 que busca a padronizao de componentes de software
Java/J2EE, seguindo as boas prticas da tecnologia Java, da plataforma J2EE e
do ambiente de Servidores de Aplicao e Sun Java System Web Server, visando
garantir a implantao e sustentao de aplicaes J2EE.

Verso 1.0.3 28/01/2008
Arquitetura

Verso 1.0.3 28/01/2008
Foco da Plataforma J2EE
A plataforma J2EE foi criada inicialmente em 1998 e vem evoluindo desde
ento para suportar aplicaes de classe corporativa (enterprise) tendo em vista
a boa utilizao de recursos humanos e tecnolgicos.
Com o nascimento da plataforma J2EE, os grandes fornecedores

comearam a desenvolver os Servidores de Aplicaes, que so componentes de
software bem complexos e com foco em gerenciamento de recursos
computacionais.
Analogicamente ao ambiente MainFrame, o Servidor de Aplicaes pode

ser representado pelo CICS, e a plataforma J2EE pode ser representada pelas
tecnologias JCL, COBOL, e outras.
No desenvolvimento J2EE, cada camada de componentes tem sua

responsabilidade, somente assim, os sistemas J2EE podem ser idealizados,
desenvolvidos, homologados e suportados eficazmente.

Verso 1.0.3 28/01/2008
Necessidade da Arquitetura de Sistemas J2EE
Os motivos pelos quais uma aplicao J2EE tem problemas de
performance, segurana, escalabilidade, e outros, so os mesmo motivos pelos
quais aplicaes no ambiente Mainframe e Client/Server tem esses problemas, ou
seja, m definio da arquitetura de software geralmente espremida por prazos
absurdos de implantao e por falta de levantamento e refino de requisitos no
funcionais.
O ambiente J2EE por ser um pouco mais complexo que seus primos, exige
que aplicaes baseadas nessa plataforma tenham um processo de arquitetura
melhor elaborado e realizado, e que realmente suporte a qualidades no
funcionais de um software.
Pesquisas, estudos e a vivncia do mercado de desenvolvimento apontam

que uma implementao ruim no mximo prejudicar a performance e dificultar a
manuteno do sistema.
Entretanto, uma arquitetura mal concebida e mal elaborada prejudicar

cronicamente a performance, escalabilidade, estabilidade e confiabilidade.
O desenho abaixo mostra como a plataforma J2EE (Virtual Platform) deve

ser componentizada para quebrar a complexidade de construo, desde o Cliente
(Client Tier) at os Recursos de Dados (Resource Tier), visando garantir as
qualidades no-funcionais (segurana, confiabilidade, disponibilidade e
escalabilidade).

Verso 1.0.3 28/01/2008
Padres de Arquitetura
Uma aplicao ou sistema J2EE obrigatoriamente deve ser construdo em
n-camadas, e cada camada tem uma responsabilidade especfica.
Experincia de mercado com empresas de todos os segmentos como:

indstria, comrcio, financeiro, e-commerce, e outros, tem encontrado equilbrio
entre o custo, prazo e qualidade de aplicaes Java usando 5 camadas,
exatamente as camadas propostas e padronizadas dentro da plataforma J2EE.
A ordem de dependncia importante para garantir as qualidades

sistmicas no funcionais como: performance, confiabilidade, segurana,
flexibilidade, manuteno, gerenciamento, reuso e outras.
Para garantir que o modelo de arquitetura seja seguido e verificado, devem

ser adotados padres de semntica para os nomes de todos os componentes,
pacotes e classes, respeitando sua camada e responsabilidade.

Verso 1.0.3 28/01/2008
Modelo de Aplicaes J2EE
Para garantir as qualidades sistmicas e requisitos no-funcionais de um

sistema, a arquitetura ser o principal responsvel, para isso o modelo de
aplicaes J2EE presente no Java Blueprints deve ser seguido.
Seguindo esse modelo, e usando componentes j existentes na Caixa,

basicamente teremos os seguintes modelos de arquitetura:

Verso 1.0.3 28/01/2008
Internet: (Autenticao/Autorizao programtica quando necessrio)

Verso 1.0.3 28/01/2008
Intranet/Extranet: (Autenticao/Autorizao declarativa via JAAS)

Verso 1.0.3 28/01/2008
Stand-Alone Client via IIOP: (Autenticao/Autorizao programtica, quando
necessrio).

Verso 1.0.3 28/01/2008
Arquitetura da Camada Client para WEB
O Client, ou mquina cliente da aplicao, no deve ter muita inteligncia,

pois o foco dela exibir informaes, validar basicamente a entrada de dados e
enviar para a aplicao Web J2EE esses dados.
Atualmente para a plataforma Web as tecnologias presentes e que devem

ser utilizadas so o HTML e suas tecnologias correlacionadas, como: JavaScript e
CSS.
Recomenda-se utilizar o mnimo possvel tecnologia JavaScript devido

falta de padres no suporte mesma, especialmente no caso de funes
avanadas.
A validao de dados de entrada jamais pode ser feita somente em
JavaScript. Utilizar sempre validao no lado do servidor e, redundantemente em
JavaScript quando necessrio.
Referncias para as principais tecnologias:
HTML: http://www.w3.org/MarkUp/
CSS: http://www.w3.org/Style/CSS/
JavaScript: http://www.w3schools.com/js/ - http://javascript-reference.info/ -
http://www.mozilla.org/js/language
Para mais tecnologias relacionadas: http://www.w3.org
imprescindvel que a aplicao funcione corretamente nos principais Web

Browsers disponveis no mercado, no podendo ser atrelada a um nico Web
Browser. Para isso, devem ser seguidos os padres definidos nos sites
relacionados acima. O cdigo no deve verificar o Browser do cliente e com base
nisto executar cdigos especficos.
Sugesto: Utilizar o Web Browser Firefox (http://www.getfirefox.com) com

o plugin Tidy HTML Validator (https://addons.mozilla.org/firefox/249) para maior
praticidade na validao das pginas.

Verso 1.0.3 28/01/2008
A camada Client deve depender exclusivamente da camada de
apresentao (Presentation) e tem poucas responsabilidades visto que a
plataforma Web tem como premissa atingir o maior nmero e tipos de mquinas
na Internet ou numa Intranet.

Verso 1.0.3 28/01/2008
Arquitetura da Camada Presentation para WEB
Esta camada coordena o fluxo da camada Client, ou seja, o que deve ser
recebido, direcionado e exibido a cada transao do usurio com o sistema. (J2EE
Core Design Patterns)
Responsabilidade principal: validar

dados enviados e direcionar a execuo para
um dos processos na camada de negcio
business atravs dos Actions e Delegates.
Os Delegates que ligam os Actions

aos Componentes de Servios de Negcio,
aps executarem as transaes, devolvem
instncias de Componentes de Negcio, que
representam as entidades de dados do
sistema.

Verso 1.0.3 28/01/2008
Na figura abaixo, vemos no detalhe como esses componentes se comunicam.
Obs: Deve-se utilizar TagLibs para a construo dos JSPs. A Caixa no mais
valida sistemas que utilizem scriptlets.

Verso 1.0.3 28/01/2008
Arquitetura da Camada Client/Presentation para aplicaes
Stand-Alone
No caso de uma aplicao Java Stand-Alone, este tipo de Client, por estar
suportado pela plataforma J2SE, pode incorporar um grande conjunto de
funcionalidades e inteligncia.
Atualmente para a esta plataforma, o padro JavaSoft de interface grfica

o Java SWING usando o modelo MVC e o protocolo de comunicao com o
Servidor de Aplicaes pode ser o HTTP(S) ou RMI-IIOP.
Responsabilidade principal: validar dados

enviados e direcionar a execuo para um dos
processos na camada de negcio business
atravs de um Servlet via HTTP ou atravs de
um EJB via RMI-IIOP.
Os Delegates ligados ao Model esto

ligados aos Componentes de Servios de
Negcio e aps executarem as transaes,
devolvem instncias de Componentes de
Negcio, que representam as entidades de
dados do sistema.

Verso 1.0.3 28/01/2008
Arquitetura da Camada Business
Esta camada representa o negcio propriamente dito, e tem como

responsabilidade fornecer servios de negcio atravs de uma interface de
mtodos otimizada para realizar a execuo dos processos de negcio
propriamente ditos.
Na figura abaixo vemos como esta camada utilizada e quais servios ela
usa:

Verso 1.0.3 28/01/2008
Colocada entre a camada de lgica de apresentao e a de persistncia, a
camada de negcio deve ser orientada pelos Java Blueprints e os Core J2EE
Design Patterns para garantir as qualidades sistmicas de escalabilidade,
performance e robustez.
Todo e qualquer acesso camada de negcio deve ser feita pelos

Delegates, e todo e qualquer acesso a Persistncia deve ser feita pela camada
de Negcio.
Os Business Objects representam as entidades de negcio do sistema e

trafegam a partir dos Actions, passando por toda a camada de negcio at
chegar aos DAOs (Data Access Objects).
Na figura abaixo, vemos um diagrama mais detalhado dessa camada.

Verso 1.0.3 28/01/2008
Verso 1.0.3 28/01/2008
Arquitetura da Camada Integration
Esta camada deve fornecer o acesso aos recursos computacionais

existentes para suportar as funcionalidades de negcio. Basicamente ela fornece
uma abstrao mais simples, um acesso inteligente e um gerenciamento eficaz
desses recursos.
Os tipos de recursos podem ser: RDBMS, LDAP, EMAIL, URL, JMS, e

outros.
No caso especfico da Caixa, Regional SP, existem dois componentes

importantes de integrao com aplicaes legadas, o SirotCon e o SIICO.

Verso 1.0.3 28/01/2008
Arquitetura da Camada Resource
Esta camada representa os recursos computacionais que esto fora da

fronteira coberta pela plataforma J2EE. Nesta camada encontram-se os servidores
de bancos de dados, LDAP, Message Brokers, servidores de e-mail, aplicaes
legadas, e etc.
Para cada um dos recursos, existem configuraes especficas e boas

prticas que refletem nos requisitos no-funcionais, entretanto, esse documento
no abordar tais configuraes e boas prticas.

Verso 1.0.3 28/01/2008
Boas Prticas

Verso 1.0.3 28/01/2008
Boas Prticas Java/J2EE
Est consolidada nos tpicos a seguir, uma srie de recomendaes, boas
prticas e pequenos manuais que abordam os padres J2EE e as particularidades
da Caixa.
Boa prtica aplicada: Segurana Declarativa na J2EE

Na plataforma J2EE, podemos definir a segurana em dois nveis:
autenticao e autorizao.
Autenticao: processo pelo qual se valida a credencial (identificao e

senha) de um usurio.
Autorizao: processo que verifica quais funcionalidades um usurio

autenticado tem permisso de executar dentro do sistema.
Podemos implementar esses dois nveis de segurana de forma declarativa ou

programtica:
Forma declarativa: aquela que no requer codificao de nenhum

mecanismo para executar a autenticao e autorizao, ficando servidor de
aplicaes e de diretrio com essas responsabilidades.
Forma programtica: aquela que requer codificao de componentes

para suportar a autenticao e autorizao.
O permissionamento de acesso segue o modelo RBAC (Role-Based Access

Control), onde um determinado usurio tem como nvel de acesso ao sistema, a
somatria das permisses dos grupos dos quais ele faz parte.
Desta forma, cada conjunto de funcionalidades da aplicao deve estar

associada a um Papel (Role) e esse Papel tm uma de lista de recursos de
aplicao ao qual tem permisses de acesso.
Um Papel (Role) obrigatoriamente ser representado por um Grupo de

usurios armazenados no Diretrio LDAP.
O uso deste mecanismo altamente eficiente, pois elimina o esforo de

codificao e extremamente seguro.
Para suportar este mecanismo, devemos configurar os descritores de

deploy de aplicao para pacotes .ear (application.xml, sun-application.xml,

Verso 1.0.3 28/01/2008
web.xml e sun-web.xml), informando quais componentes WEB (JSP, Servlet ou
HTML) tem permisses de acesso.
No application.xml definimos:
1 - Nomes das ROLES (Papis) definidos na Aplicao.
Exemplo para aplicao com DOIS PAPIS (ROLES):
<?xml version="1.0"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE

Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">
<application>
<description>Application description</description>
<display-name>estore</display-name>
<module>
<ejb>estoreEjb.jar</ejb>
</module>
<module>
<web>
<web-uri>estore.war</web-uri>
<context-root>estore</context-root>
</web>
</module>


<security-role>
<description>Site Admin</description>
<role-name>ADMIN</role-name>
</security-role>
<security-role>
<description>Sales Manager</description>
<role-name>SALES_MANAGER</role-name>
</security-role>
</application>

Verso 1.0.3 28/01/2008
No sun-application.xml definimos:
1 Nomes das ROLES (Papis) definidos na Aplicao.
Exemplo para aplicao com DOIS PAPIS (ROLES):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-application PUBLIC

"-//Sun Microsystems, Inc.//DTD Sun Application Server 8.1 J2EE
Application 1.4//EN"
"http://www.sun.com/software/sunone/appserver/dtds/sun-application_1_4-
1.dtd">
<sun-application>
<web>
<web-uri>estore.war</web-uri>
<context-root>estore</context-root>
</web>
<pass-by-reference>true</pass-by-reference>
<unique-id>-1</unique-id>
<security-role-mapping>
<group-name>LDAP_ADMIN</group-name>
</security-role-mapping>
<group-name>LDAP_SALES</group-name>
</sun-application>

Verso 1.0.3 28/01/2008
No web.xml definimos:
1 - Colees de recursos protegidos: quais componentes WEB esto protegidos e

quais grupos tm acesso a esses recursos;
2 - Forma de autenticao: FORM (padro adotado pela Caixa);
3 - Nomes das ROLES (Papis);
Estrutura do WEB.XML (ordem das tags):
<!ELEMENT web-app (icon?, display-name?, description?, distributable?,

context-param*, filter*, filter-mapping*, listener*, servlet*,
servlet-mapping*, session-config?, mime-mapping*, welcome-file-list?,
error-page*, taglib*, resource-env-ref*, resource-ref*, security-
constraint*, login-config?, security-role*, env-entry*, ejb-ref*, ejb-
local-ref*)>
Exemplo do WEB.XML para aplicao com DOIS PAPIS (ROLES):

<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<distributable/>
<servlet>
<servlet-name>AdminServlet</servlet-name>
<servlet-class>samples.AdminServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>SalesServlet</servlet-name>
<servlet-class>samples.SalesServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>AdminServlet</servlet-name>
<url-pattern>/admin</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>SalesServlet</servlet-name>
<url-pattern>/sales</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

Verso 1.0.3 28/01/2008
<-- JAAS Security Definition -->
<security-constraint>
<web-resource-collection>
<web-resource-name>Admin Protected Area</web-resource-name>
<url-pattern>/admin/*.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
</auth-constraint>
<user-data-constraint>
<description>no description</description>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<web-resource-name>Sales Protected Area</web-resource-name>
<url-pattern>/sales/*.jsp</url-pattern>
<auth-constraint>
</auth-constraint>

<login-config>
<auth-method>FORM</auth-method>

<realm-name>ldapRealm</realm-name>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>

<security-role>
<description>the site admin role</description>
</security-role>
<security-role>
<description>the sales manager</description>
</security-role>
</web-app>

Verso 1.0.3 28/01/2008
No sun-web.xml definimos:
1 Mapeamento das ROLES (Papis) definidos na Aplicao em relao

aos grupos em LDAP.
Exemplo do SUN-WEB.XML para aplicao com DOIS PAPIS (ROLES):
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application

Server 8.1 Servlet 2.4//EN"
"http://www.sun.com/software/appserver/dtds/sun-web-app_2_4-1.dtd">
<sun-web-app>
<role-name> ADMIN </role-name>
<group-name> LDAP_ADMIN </group-name>
<role-name> SALES_MANAGER </role-name>
<group-name> LDAP_SALES </group-name>
<cache max-entries="4096" timeout-in-seconds="30" enabled="true">
<default-helper/>
</cache>
<jsp-config/>
</sun-web-app>
Para autenticao via FORM, devemos usar um POST de HTTP os seguintes

campos na pgina de LOGIN:
1 Definio do FORM HTML da pgina de LOGIN para autenticao via

FORM usando o JAAS.
Exemplo da pgina login.jsp
<form method="POST" action="j_security_check">

<input type="text" name="j_username">
<input type="password" name="j_password">
<input type="submit" name="login" value="Login">
</form>

Verso 1.0.3 28/01/2008
Obtendo o nome do usurio na Servlet API
1 Uma vez autenticado, o username setado pelo SJSAS8 no objeto

javax.servlet.http.HttpServletRequest toda vez que um request executado e
a sesso validada.
Para obter o username usado no processo de autenticao:
Exemplo:
request.getRemoteUser(); // retorna uma String com o nome do

// usurio logado. Se no estiver
// logado retorna null.
Notas:
1 As Roles definidas no application.xml e no web.xml devem ser

obrigatoriamente mapeadas em ao menos um grupo do LDAP via os
descritores sun-application.xml e sun-web.xml.
2 Para controlar a visualizao de determinado contedo ou

programaticamente obter o perfil de um determinado usurio, existe um
componente corporativo especialmente construdo para a Caixa chamado
ComponenteLDAP.

Verso 1.0.3 28/01/2008
Boa prtica aplicada: Usando o JavaMail
O objetivo deste documento demonstrar a implementao, publicao e
testes de aplicaes que desejem usar a JavaMail API 1.3.2 dentro da J2EE 1.4,
com o intuito de manter a aderncia a especificao da J2EE e evitar problemas
durante a passagem das aplicaes nos ambientes de desenvolvimento,
homologao e produo.
A JavaMail API 1.3.2 foi abstrada e desenhada com o objetivo de facilitar a

implementao de componentes que usem os servios de e-mail (correio
eletrnico), baseados nos protocolos SMTP, POP3 e IMAP.
Pacotes da JavaMail API 1.3.2:
API que contm as classes padronizadas pelo JCP (Java

javax.mail Community Process) e o Provider de Servios (Classes de
Implementao) padro da SUN MicroSystems.
Pacote que contm as classes de eventos usadas para

javax.mail.event
facilitar o tratamento dos eventos das mensagens.
Pacote que abstraiu as funcionalidades dos envios e

javax.mail.internet tratamentos das mensagens de Internet (e-mail, etc)
padronizadas pelo W3C.
Pacote que contm classes que facilitam a pesquisa de

javax.mail.search
dados e mensagens.

Verso 1.0.3 28/01/2008
Arquitetura da JavaMail API 1.3.2
O JCP (Java Community Process) criou um conjunto de classes padro

para facilitar a implementao dos servios de envio e recebimento de
mensagens, e assim, flexibilizou a criao dos provedores destes servios.
Os servios atualmente utilizados para troca de e-mails so: SMTP, POP3 e

IMAP.
O SMTP o servio responsvel pelo envio das mensagens, o POP3 o

servio responsvel pelo armazenamento das mensagens e o IMAP uma
evoluo para um modelo de sincronismo e aglutinao dos servios de envio e
armazenamento.
A JavaSoft e outros fabricantes criaram as suas implementaes (Provider)

destes servios, ou seja, criaram classes que seguem a especificao da
JavaSoft.
O Provedor de Servios JavaMail mais usado o da prpria JavaSoft.

Verso 1.0.3 28/01/2008
Classes principais
javax.mail.Store tem a responsabilidade de representar o armazenamento

das mensagens, no dependendo do servio utilizado.
javax.mail.Transport tem a responsabilidade de representar o envio das

mensagens, no dependendo do servio utilizado.
javax.mail.Session representa a implementao do Provider utilizado para

a obteno dos objetos e seus servios.
javax.mail.Service a superclasse que abstraiu a funcionalidade geral

para controle de conexo e gerenciamento dos eventos dos sistemas de envio e
recebimento de mensagens.
javax.mail.Message a superclasse que representa os objetos e os tipos

de mensagens padronizadas pelo W3C.

Verso 1.0.3 28/01/2008
Servio JavaMail na J2EE
Como o objetivo da Java2 Enterprise Edition de facilitar o

desenvolvimento, suporte e produo de aplicaes em larga escala, foi
padronizada a forma de como os componentes de aplicao devem usar o servio
de e-mail presente no servidor de aplicaes.
O Sun Application Server 8, disponibiliza na sua infra-estrutura de servios
um conector 100% compatvel com a especificao J2EE 1.4.
Este conector gerencia as conexes e sesses feitas pela aplicao com os
servios de SMTP, POP3 ou IMAP, evitando que a aplicao cause problemas de
sobrecarga ou mau uso de recursos da infra-estrutura.
Este conector representa o componente javax.mail.Session presente na
JavaMail API 1.3.2.

Verso 1.0.3 28/01/2008
Enviando um e-mail usando a J2EE e a JavaMail API 1.3.2
O trecho de cdigo abaixo mostra como as aplicaes baseadas no modelo

J2EE devem obter o objeto de sesso de e-mail (javax.mail.Session) a partir dos
servios da J2EE, e a partir dele obter o objeto de envio SMTP.
public void send(String jndiName, Message message)

throws NamingException, MessagingException {
// Obtendo o Contexto do J2EE

Context jndi = new InitialContext();
// Obtendo o Conector do JavaMail

Session session = (Session) jndi.lookup( jndiName );
// Fechando conexo com o contexto JNDI

jndi.close();
// Obtendo o Objeto que representa o SMTP

Transport transport = session.getTransport( smtp );
// Conectando com o SMTP, usando autenticao do Container

transport.connect();
// Enviando uma mensagem

Transport.send( message );
// Fechando a conexo e sesso.

transport.close();
}
Esta implementao ilustra somente como devemos obter o objeto

javax.mail.Session a partir do contexto JNDI da J2EE.
O exemplo acima no deve ser usado como base de implementao para

envio de e-mails.
Nos casos reais, deve-se desenhar um componente que seja capaz de
enviar e-mails um a um ou em massa.

Verso 1.0.3 28/01/2008
Obtendo o Inbox para ler e-mails, usando a J2EE e a JavaMail API
1.3.2
O trecho de cdigo abaixo mostra como as aplicaes baseadas no modelo

J2EE devem obter o objeto de sesso de e-mail (javax.mail.Session) a partir dos
servios da J2EE, e a partir dele obter o objeto de armazenamento POP.
public Folder read(String jndiName)

throws NamingException, MessagingException {
// Obtendo o Contexto do J2EE

Context jndi = new InitialContext();
// Obtendo o Conector do JavaMail

Session session = (Session) jndi.lookup( jndiName );
// Fechando conexo com o contexto JNDI

jndi.close();
// Obtendo o Objeto que representa o SMTP

Store store = session.getStore( pop3 );
// Conectando com o POP, usando autenticao do Container

store.connect();
// Enviando uma mensagem

Folder inbox = store.getFolder( INBOX );
// Fechando a conexo e sesso.

store.close();
// Retorna objeto folder.

return inbox;
}
Esta implementao ilustra somente como devemos obter o objeto

javax.mail.Session a partir do contexto JNDI da J2EE.
O exemplo acima no deve ser usado como base de implementao para

leitura de e-mails.
Nos casos reais, deve-se desenhar um componente que seja capaz de
consultar as pastas da caixa de correio, bem como recuperar as mensagens sob
demanda.
Exemplo de jndiName para busca:

java:comp/env/mail/ApplicationMailSession

Verso 1.0.3 28/01/2008
Configurando as aplicaes J2EE para usar um conector de e-
mail.
Toda aplicao J2EE possui os descritores de deploy (DD) que descrevem

quais recursos do servidor de aplicaes seus componentes utilizam.
Para a aplicao web, existe o web.xml, e quando uma aplicao web no

padro J2EE utilizar um ou mais conectores de e-mail, no web.xml dever conter a
tag <resource-ref> para cada conector de e-mail que os componentes web usem.
// web.xml (presente no arquivo .war)

<web-app>
<resource-ref>
<description>Mail Connector Name</description>
<res-ref-name>mail/ApplicationMailSession</res-ref-name>
<res-type>javax.mail.Session</res-type>
<res-auth>Container</res-auth>
</resource-ref>
<web-app>
Para os EJBs, existe o ejb-jar.xml, e quando um EJB no padro J2EE

utilizar um ou mais conectores de e-mail, no ejb-jar.xml dever conter a tag
<resource-ref> para cada conector.
// ejb-jar.xml (presente no arquivo .jar)

<enterprise-beans>
<session>
<description>Descrio do EJB</description>
<display-name>Nome de Exibio</display-name>
<ejb-name>EJBName</ejb-name>
<home>homeInterface</home>
<remote>remoteInterface</remote>
<ejb-class>beanClass</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<resource-ref>
<res-ref-name>mail/ApplicationMailSession</res-ref-name>
<res-type>javax.mail.Session</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</session>
</enterprise-beans>

Verso 1.0.3 28/01/2008
Registrando um conector de e-mail no Sun Application Server 8
A configurao pode ser feita via a Console Administrativa Web ou via

Linha de comando (asadmin).
So necessrias as seguintes informaes:

Nome do JNDI: mail/ApplicationMailSession
Nome do HOST: mail.hostname.domainname
Nome do USER: mail.user.name
Endereo de Retorno: application@domainname.com
Como todo recurso J2EE, o conector de e-mail deve ter um nome nico
<jndi-name>, pois ele poder ser usado e compartilhado por mais de uma
aplicao. O <jndi-name> usado pelas aplicaes para localizar o servio de e-
mail.
O uso de servios da JNDI permite que a infra-estrutura faa alteraes nas

configuraes do servidor de e-mail ou de aplicaes, sem que a aplicao
precise ser alterada.
Usando e publicando um conector de e-mail no SJSAS8:
http://docs.sun.com/source/819-0215/javamail.html

Verso 1.0.3 28/01/2008
Boa prtica aplicada: Utilizando os recursos da J2SE 1.5
Generics
Um dos principais recursos introduzidos na J2SE 1.5 o Generics, que

permite a definio de collections tipadas. altamente recomendada a
utilizao deste tipo de construo uma vez que reduz a probabilidade de
falhas na aplicao.
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
For-Each Loop
Em conjunto com as collections tipadas possvel utilizar a construo for-

each que simplifica drasticamente a construo deste tipo de loop.
http://java.sun.com/j2se/1.5.0/docs/guide/language/foreach.html
Annotations
O uso de Annotations simplifica definies e configuraes de uma

aplicao, eliminando em muitos casos a necessidade de arquivos de
configurao e/ou uso de ferramentas para gerao dos mesmos.
http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html
Autoboxing/Unboxing
Este recurso permite utilizao de tipos primitivos em pontos onde

definido o objeto Wrapper deste tipo e vice-versa. Faz converso
automtica de e para tipos primitivos e objetos.
http://java.sun.com/j2se/1.5.0/docs/guide/language/autoboxing.html
Para a lista completa de novas construes da J2SE 1.5 consulte o endereo:
http://java.sun.com/j2se/1.5.0/docs/guide/language/index.html

Verso 1.0.3 28/01/2008
Boa prtica aplicada: Mapeamento de JSP
Definir os critrios para decidir quais JSPs devem ser registrados como um
Servlet e ter mapeamentos de URL no ambiente do SJSAS8.
Definies de HA
O ambiente do SJSAS8 foi desenhado e projetado para suportar HA (High

Availability), ou seja, Alta Disponibilidade das aplicaes.
Para isso, o Web Container J2EE SJSAS8, suporta a distribuio de

sesses e do contexto Web.
A definio de quais aplicaes utilizam ou no HA fica a critrio da equipe
de operaes. Para que isto seja possvel, o arquivo sun-web.xml no deve
conter a tag <session-config>.
Os JSPs que acessam objetos na sesso (session) ou no contexto Web

(context) devem estar mapeados para que, caso a equipe de operaes assim
defina, usufruam da infra-estrutura de HA do SJSAS8.
Quando um JSP est registrado e mapeado no descritor de deploy Web

(WEB-INF/web.xml) ele ser registrado no SJSAS8 como um Servlet e ter todos
os benefcios do Cluster.
Critrios de mapeamento
Levando em conta como o SJSAS8 trata a distribuio de sesso e contexto
para as aplicaes Web, um JSP tem a necessidade de estar mapeado se e
somente se:
1 O JSP usar ao menos uma TagLib que manipule a sesso Web

(HttpSession);
2 O JSP usar ao menos uma TagLib que manipule o contexto Web

(ServletContext ou PageContext); Obs: Lembramos que todo JSP que no
tiver uma diretiva negativa de sesso explcita ter sesso como true, e
manipular a sesso Web. Por isso sugerimos que antes de aplicar os
critrios de mapeamento, todo o JSP que no utiliza a sesso Web, insira
a diretiva:
<%@ page session=false %>

Verso 1.0.3 28/01/2008
Exemplos
Ex1:
File: teste.jsp
<%@ page session=true %>
Este JSP DEVE estar registrado e mapeado no descritor de deploy Web.
Ex2:
File: teste2.jsp
Este JSP NO DEVE estar registrado e mapeado no descritor de deploy Web.
Ex3:
File: teste3.jsp
<% Object obj = context.getAttribute( attr ); %>
Ex4:
File: teste4.jsp
<%@ page session=true %>
<% Object obj = context.getAttribute( attr ); %>

Verso 1.0.3 28/01/2008
Mapeando um JSP
Seguindo os critrios acima, caso o JSP necessite ser mapeado, ele deve
ser includo no web.xml como um Servlet, seguindo a seguinte estrutura:
<servlet>
<servlet-name> login </servlet-name>
<jsp-file> login.jsp </jsp-file>
<load-on-startup>0</load-on-startup>
</servlet>
E deve estar associado ao seu registro de Servlet, ao menos um mapeamento de

URL:
<servlet-mapping>
<servlet-name> login </servlet-name>
<url-pattern> /login.jsp </url-pattern>
</servlet-mapping >

Verso 1.0.3 28/01/2008
Boa prtica aplicada: Usando o Jakarta Struts 1.3
O Jakarta Struts um conjunto de componentes de uma implementao
muito usada no mercado como framework para o modelo MVC (Model-View-
Controller) para aplicaes WEB J2EE.
O principal objetivo de uso deste framework agilizar o processo de

construo de aplicaes WEB, usando um conjunto de componentes que
facilitam a criao de controles de processo de visualizao, a criao de
elementos que representam a ao do usurio e componentes para exibio dos
dados, provenientes do resultado da execuo dos processos de um sistema.
A ltima verso do Struts homologada na Caixa a 1.2.9, porm

recomendada a utilizao da 1.3.5 que dever ser homologada em breve,
segue URL:
http://struts.apache.org/1.3.5/index.html
Neste link existem referncias de implementao e documentao:
http://struts.apache.org/1.3.5/userGuide/index.html

Verso 1.0.3 28/01/2008
Implementando com o Jakarta Struts 1.3 para o Sun Application
Server 8
O Struts 1.3 totalmente compatvel com o SJSAS8, ento sua

implementao semelhante implementao da referncia da J2EE 1.4 que
do Web Container do Tomcat 5.X.
Recomendamos o uso do Framework Tiles do Struts para maiores
flexibilidade e facilidade de manuteno do layout da aplicao.
Configuraes para o Jakarta Struts 1.3 para o SJSAS8
Definindo os descritores de deploy da J2EE 1.4, do SJSAS8 e o Struts-

Config.
Definindo o WEB.XML:
OBS:
No mnimo deve conter esta estrutura.
Usar o ActionServlet do Struts.
Ateno para o arquivo sun-web.xml. Para Struts 1.3 ou superior
o atributo class-loader delegate deve estar como false.
<web-app version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>
org.apache.struts.action.ActionServlet
</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>3</param-value>
</init-param>
<init-param>
<param-name>detail</param-name>
<param-value>3</param-value>
</init-param>
<load-on-startup>0</load-on-startup>

Verso 1.0.3 28/01/2008
</servlet>
<servlet-mapping>
<servlet-name>action</servlet-name>

<url-pattern>*.do</url-pattern>
</servlet-mapping>
<-- Exemplo de Struts com JAAS -->

<web-resource-name> Protected Area</web-resource-name>

<url-pattern>/sales/manage.do</url-pattern>
<url-pattern>/sales/update.do</url-pattern>
<url-pattern>/sales/*.jsp</url-pattern>
<auth-constraint>
</auth-constraint>

<login-config>
<auth-method>FORM</auth-method>

<realm-name>ldapRealm</realm-name>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>

<security-role>
<description>the site admin role</description>
</security-role>
<security-role>
<description>the sales manager</description>
</security-role>
</web-app>

Verso 1.0.3 28/01/2008
Definindo o SUN-WEB.XML:

<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application
Server 8.1 Servlet 2.4//EN"
"http://www.sun.com/software/appserver/dtds/sun-web-app_2_4-1.dtd">
<sun-web-app>
<class-loader>
<delegate>false</delegate>
</class-loader>
<role-name> ADMIN </role-name>
<group-name> LDAP_ADMIN </group-name>
<role-name> SALES_MANAGER </role-name>
<group-name> LDAP_SALES </group-name>
<cache max-entries="4096" timeout-in-seconds="30" enabled="true">
<default-helper/>
</cache>
<jsp-config/>
</sun-web-app>

Verso 1.0.3 28/01/2008
Definindo o STRUTS-CONFIG.XML:
OBS:
No mnimo deve conter essa estrutura.
Utilizar o Request Processor do Tiles.
<!DOCTYPE struts-config PUBLIC

"-//Apache Software Foundation//DTD Struts Configuration 1.3//EN"
"http://jakarta.apache.org/struts/dtds/struts-config_1_3.dtd">
<struts-config>
<global-forwards type="org.apache.struts.action.ActionForward">
<forward name="myForward"
path="/any.jsp"
redirect="true"/>
</global-forwards>
<action-mappings>
<action
input="/index.jsp"
path="/sales/manage.do"
type="br.gov.caixa.action.ManageAction"
scope="request"
validate="false">
</action>
<action
input="/index.jsp"
path="/sales/update.do"
type="br.gov.caixa.action.UpdateAction"
scope="request"
validate="false">
</action>
</action-mappings>
<controller
processorClass="org.apache.struts.tiles.TilesRequestProcessor"/>
</struts-config>

Verso 1.0.3 28/01/2008
Boas Prticas de Implementao
Foram coletados durante a anlise em vrios sistemas da Caixa, dados
estatsticos de como as aplicaes J2EE esto sendo construdas, e dessa forma
enumeramos uma srie de recomendaes:
Recomendaes para URLs
Devido a particularidades dos ambientes de Web Server e Application

Server de DES, HMP e PRD da Caixa, se faz necessrio padronizao da
codificao das URLs HTTP dentro dos componentes das aplicaes Web:
Uso de URLs relativas, para referenciar todos os componentes WEB

facilitando a implantao das aplicaes nos ambientes Caixa:
Exemplos para elementos estticos:
Imagem: /aplicacaostatic/imagens/imagem.gif
Scripts: /aplicacaostatic/scripts/script.js
Link Html: /aplicacaostatic/pagina.html
Exemplos para elementos dinmicos:
Action: /aplicacao/action.do
Action: /aplicacao/pagina.jsp
Action: /aplicao/AplicacaoControl

Verso 1.0.3 28/01/2008
Recomendaes para JSPs
Cada JSP de qualquer sistema da Caixa deve conter no mnimo a seguinte

diretiva:
<% @page session = valor %>

valor =true para pgina que acessa a sesso ou contexto;
valor = false para pgina que no acessa sesso ou contexto;

Verso 1.0.3 28/01/2008
Recomendaes para Aplicaes Web
Uma aplicao Web Java/J2EE tem quatro objetos principais, Session,

Request, Response e Context. Para estes objetos observar:
1. Request e Response representam a recepo de dados do usurio

e devoluo de dados ao usurio respectivamente:
a. Usamos o Request para ler ou inserir parmetros entre

componentes sem onerar a infra-estrutura de alta
disponibilidade;
b. Usamos o Response para enviar dados ao usurio;
2. Session: Representa a sesso Web, associada a um nico usurio e

pode armazenar informaes durante as requisies:
a. Por motivos de performance, a quantidade de dados na

Sesso Web no deve exceder 7KB no SJSAS8.
Referncia: http://docs.sun.com/source/819-0084/index.html
b. Devemos armazenar somente informaes que sabidamente

devem ter seu estado mantido entre duas ou mais requisies
subseqentes do usurio com o sistema.
3. Context: Representa a aplicao Web e compartilhada entre todas

as sesses de usurios de um mdulo WAR e pode armazenar
informaes com estado entre as transaes dos usurios com o
sistema:
a. Devemos armazenar somente informaes que sabidamente

devem ter seu estado mantido entre duas ou mais requisies
subseqentes de um ou mais usurios dentro do sistema.

Verso 1.0.3 28/01/2008
Recomendaes para DAOs (Data Access Objects)
1. Abandonar a gerao de SQL dinmico dentro da aplicao Java,

substituindo por comandos SQL estticos dentro das classes de DAO.
2. A camada de DAO responsvel por gerenciar as conexes de Bancos

de Dados e somente esta camada deve conter os comandos SQL.
3. Sempre que acessar o banco de dados via JDBC, no usar objetos

java.sql.Statement, deve-ser usar o
java.sql.PreparedStatement para SQL Embedded e
java.sql.CallableStatement para execuo das Stored
Procedures, e nesses dois casos sempre usar Bind de parmetros ao
invs de concatenar comandos SQL.
4. No manipular em hiptese alguma o estado de COMMIT/ROLLBACK

da conexo JDBC, ou seja, no usar os mtodos commit() e
rollback() presentes no objeto java.sql.Connection. Usar o
JTA/JTS da J2EE (ver recomendaes dos EJBs).
5. Dimensionar adequadamente o nmero de linhas para cada uma das

referncias do objeto java.sql.ResultSet o FETCHSIZE, atravs do
mtodo setFetchSize(int) antes de fazer a pesquisa dos registro
pelo mtodo next();
6. Em alguns casos, quando o tamanho do ResultSet muito grande ou

no ser pesquisado no sentido inverso, devemos setar a direo de
pesquisa para FETCH_FORWARD usando o mtodo
setFetchDirection(int) antes de fazer a pesquisa pelo mtodo
next();
7. Dever ser sempre utilizada a construo abaixo para manipulao de

conexes, lembrando que o ideal utilizar uma conexo por request,
fechando-a no final do processamento. Este apenas um exemplo, na
aplicao real o tratamento pode estar em uma classe utilitria.
try {
// obter e utilizar conexo
} catch (SqlException se) {
// tratar exceo de banco
} catch (Exception e)
// tratar exceo genrica (caso aplicvel)
} finally {
// fechar statements, resultsets e conexo
}

Verso 1.0.3 28/01/2008
Recomendaes para Delegates, Actions, Strategies, etc.
1. A camada de Delegate deve ter uma interface simples fornecendo a

integrao com a camada de negcio, e evitar mltiplas chamadas, tendo
uma interface mais granular.
2. O nmero de Actions ou Strategies est relacionado com o nmero de

transaes de usurio (aes do usurio ao sistema) e deve-se aplicar o
bom senso no desenho dessas classes, existem funcionalidades que
podem ser aglutinadas em uma nica Action ou Strategy, e existem casos
que cada ao do usurio deve ter sua Action ou Strategy.
3. No caso de usar o Struts como framework MVC, deve-se ponderar que um

conjunto de funcionalidades agrupadas por subsistema de negcio, deve ter
seu Controller, ou seja, uma aplicao no ter somente um Controller, e
sim, um conjunto deles, agrupado por subsistema.
4. Os Delegates devem usar um ServiceLocator para localizar e cachear

recursos locais ou remotos da Aplicao (Ex. EJBs) e do Servidor (Ex.
DataSource), e dessa forma evitar que um excessivo acesso a JNDI seja
feito, degradando a performance da aplicao.

Verso 1.0.3 28/01/2008
Recomendaes para EJBs (Enterprise JavaBeans)
1. Usar a camada EJB como camada de servios de negcio, e essa camada

acessa os recursos para as aplicaes, como Banco de Dados e etc.
2. As boas prticas de mercado indicam para NO se usar herana em EJBs,

em hiptese alguma, pois aumenta em muito o overhead de controle do
EJB Container devido a Serializao / Deserializao, Reflexo e
Introspeco.
3. Dependendo do tamanho em memria dos objetos armazenados num

Stateful Session Bean, pode haver degradao de performance por gerar
Overhead na camada de Cluster do SJSAS8. O limite de tamanho dos
dados que deve ser armazenado nos Stateful Session Beans de 7Kbytes.
4. Recomenda-se utilizar o mnimo possvel Stateful Session Beans. Prefira

utilizar Stateless Session Beans, pois estes demandam um processamento
bem menor, melhorando muito a performance da aplicao.
5. No recomendado que aplicaes Java manipulem arquivos e/ou faam

processamento Batch a no ser que haja prvio consenso entre equipe, SIT
e REROP de que esta a melhor soluo para o caso.
6. Efetuar conexes de rede usando java.net.Socket dentro dos EJBs deve

ser evitado, pois violam os mecanismos de controle do EJBContainer.
Deve-se fazer conexes de servio atravs de recurso J2EE java.net.URL
http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Resources5.html#63140
7. Usar sempre o monitor transacional do Continer EJB J2EE, e dessa forma

permitir que o servidor de aplicaes coordene a gerncia de recursos,
evitando que programador insira falhas ao mecanismo transacional.
http://java.sun.com/j2ee/1.4/docs/tutorial-
update6/doc/Transaction.html#wp79663
a. Transao Declarativa no EJB Container.

update6/doc/Transaction3.html#wp79725
b. Transao Programtica no EJB Container:

update6/doc/Transaction4.html#wp79940
OBS: recomendado utilizar transao declarativa uma vez que esta

gera maior flexibilidade para a aplicao e ambiente.

Verso 1.0.3 28/01/2008
8. Os mtodos de negcio dos EJBs (SessionBeans e EntityBeans) presentes
nas interfaces EJBObject e EJBLocalObject devem ser definidos com
Checked Exceptions, ou seja, filhas de java.lang.Exception.
//ExcecaoNegocio.java
public class ExcecaoNegocio extends java.lang.Exception {
...
}
// Servico.java
public interface Servico extends javax.ejb.EJBObject {
public void metodoNegocio()

throws ExcecaoNegocio , java.rmi.RemoteException;
// ServicoLocal.java
public interface ServicoLocal extends javax.ejb.EJBLocalObject {
public void metodoNegocio() throws ExcecaoNegocio;

Verso 1.0.3 28/01/2008
9. Os mtodos de ciclo de vida dos EJBs (SessionBeans e EntityBeans)
presentes nas interface EJBHome e EJBLocalHome devem ser adequados
ao mtodo usado:
Interfaces Remotas:
a. create(....) throws CreateException, RemoteException;
b. findXXX(....) throws FinderException, RemoteException;
c. remove(.....) throws RemoveException, RemoteException;
Interfaces Locais:
d. create(....) throws CreateException;

e. findXXX(....) throws FinderException;
f. remove(.....) throws RemoveException;
// ServicoHome.java
public interface ServicoHome extends javax.ejb.EJBHome {
public Servico create()

throws javax.ejb.CreateException, java.rmi.RemoteException;
// ServicoLocalHome.java
public interface ServicoLocalHome extends javax.ejb.EJBLocalHome {
public Servico create() throws javax.ejb.CreateException;

Verso 1.0.3 28/01/2008
10. Os mtodos de negcio e de ciclo de vida definidos na classe de
implementao dos EJBs (SessionBeans e EntityBeans) presentes nas
interfaces EJBHome, EJBObject, EJBLocalObject e EJBLocalHome devem
ser adequados ao mtodo usado:
// ServicoEJB.java
public class ServicoEJB implements javax.ejb.SessionBean {
public void metodoNegocio() throws ExcecaoNegocio {
try {
// algum codigo que gera exececao
} catch (SQLException e) {
// anula a transacao e gera uma excecao de
negocio
throw new ExcecaoNegocio (e);
} catch (NullPointerException e) {
// anula a transacao e gera uma excecao de
negocio
throw new ExcecaoNegocio (e);
}
...
public void setSessionContext(javax.ejb.SessionContext sc)

throws javax.ejb.EJBException, java.rmi.RemoteException {
public void ejbActivate()

public void ejbPassivate()

public void ejbRemove()

public void ejbCreate() throws javax.ejb.CreateException {
...

Verso 1.0.3 28/01/2008
Recomendaes para Web Services
Um Web Service um aplicativo Servidor que disponibiliza um ou mais

servios para seus clientes, de maneira fracamente acoplada. No ambiente J2EE,
Web Services podem ser implementados como Servlets ou EJBs.
Para se comunicar com um Web Service, devemos desenvolver um
consumer, com graus variados de acoplamento e dificuldade de programao. O
JAX-RPC nos proporciona a criao dos consumers baseados nos stubs, dynamic
proxies e dynamic invocation interface. Pelo fato do cdigo do cliente ser mais
complexo que o cdigo do Web Service, recomendamos a ferramenta Java Web
Services Developer Pack (JWSDP) para gerao das classes utilitrias. O Java
Web Services Development Kit a principal ferramenta Java da Sun para
construo de aplicaes distribudas que se comunicam atravs de Web Service.
Deve-se ter em mente que Web Services no tm boa performance, pois
usam um protocolo no otimizado HTTP(S) e estruturas de dados em XML. Esta
troca de mensagens necessita de marshalling e unmarshalling (converso entre o
formato de transmisso e objetos Java), e mais lento do que outras tecnologias,
como Servlets, Corba, RMI/IIOP, etc. Seu grande ganho esta na
interoperabilidade. Porm alertamos que poucas aplicaes necessitam realmente
utilizar Web Services, e que, caso possvel, devem utilizar uma tecnologia mais
performtica para a comunicao entre mdulos/aplicaes.
recomendada a leitura dos seguintes links:
http://jcp.org/en/jsr/detail?id=172
http://www.brics.dk/~amoeller/WWW/webservices/
http://java.sun.com/webservices/jwsdp/index.jsp

Verso 1.0.3 28/01/2008
Recomendaes para Empacotamento das Aplicaes
As aplicaes devem empacotar as bibliotecas das quais dependem, no

ser permitida a incluso de bibliotecas no classpath da instncia.
No classpath da instncia apenas as bibliotecas de acesso banco de
dados (ojdbc14.jar) e bibliotecas que fazem acesso nativo (crypto.jar) estaro
disponveis.
Os motivos para empacotamento com a aplicao so os que seguem:
Segurana - No deve ser permitida a uma aplicao, ter acesso a

classes que no utiliza. Um pacote no classpath est disponvel a todas
as aplicaes de uma instncia.
Evoluo - Em caso de evoluo do componente, com quebra de

interface, uma aplicao que utilize a evoluo pode empacotar com a
nova verso sem afetar outras aplicaes.
Caso esteja no classpath a tendncia no evoluir componentes devido
urgente demanda de alterao de aplicaes.
Atomicidade - Quando empacotados com a aplicao, a equipe garante

que o sistema funciona com as verses dos componentes empacotados.
Diminui a probabilidade de erros devido a configuraes incorretas da
instncia.
Independncia - Uma aplicao que empacota todas as suas

dependncias pode ser movida de uma instncia para outra sem
necessidade de prvia adequao da nova instncia.
D mais independncia equipe de operao para utilizao de
recursos e facilita o teste da aplicao em outros ambientes.
Regras para empacotamento conforme padres da CEF
Pacote EAR: No deve conter bibliotecas de dependncia em qualquer de

seus subdiretrios.
Mdulo EJB: Incluir os JARs na raiz do mdulo. O arquivo MANIFEST.MF

do diretrio META-INF no deve conter a diretiva Class-Path.
Mdulo WAR: Incluir os JARs no diretrio WEB-INF/lib do mdulo.

Verso 1.0.3 28/01/2008
As classes e bibliotecas carregadas pelo mdulo EJB so visveis por
ambos EJB e WAR, portanto estas devem estar apenas no mdulo EJB. No
mdulo WAR devem estar presentes apenas as classes e bibliotecas que
so de uso exclusivo deste.
Ateno: Caso exista uma classe com o mesmo nome em ambos EJB e
WAR, ser utilizada a que est no mdulo EJB, independente de serem
verses iguais ou distintas.
importante entender a hierarquia de classloaders do Sun Application Server 8.
http://docs.sun.com/source/819-0217/dgdeploy.html
http://developers.sun.com/prodtech/javatools/jsenterprise/reference/techart/jse7/cla
ssloading-pkg.html

Verso 1.0.3 28/01/2008
Recomendaes para Deploy das Aplicaes
O SIT/SP definiu uma rea para armazenamento dos cdigos fontes,

juntamente com um script que faz o deploy a partir dos fontes armazenados. S
possvel fazer deploy a partir deste processo, portanto recomendamos que as
equipes estudem o processo e em caso de dvidas entrem em contato com a
equipe do SIT.
Este processo facilita a busca e correo de erros quando ocorrem, pois
garante que o sistema que est rodando compatvel com os fontes que esto
armazenados.
Referncia: Manual do ANT em: http://desenv.coresp.caixa/SIT
Recomendaes para Log das Aplicaes
As aplicaes da Caixa devem conter um mecanismo de LOG que prev

nveis de informao para as operaes. Todas as aplicaes da Caixa devem
usar o Log4J como mecanismo de log.
No seguinte endereo encontra-se o manual para uso do Log4J nos

padres da Caixa:
http://desenv.coresp.caixa/SIT/documentos/Padrao_LOG.zip
Recomendaes para Inspeo da Qualidade do Cdigo
O SIT personalizou a ferramenta PMD, adequando suas regras e relatrios

de acordo com as necessidades da CEF. A ferramenta simples de usar, gerando
relatrios bastante claros quanto aos pontos no aderentes as melhores prticas.
A ferramenta no analisa aspectos arquiteturais e de design dos sistemas,
portanto, um relatrio com poucos pontos de no-aderncia, no significa
necessariamente que um sistema esteja livre de problemas estruturais.
Nas inspees de cdigo, o SIT analisa tambm aspectos no cobertos
pela ferramenta.
essencial, que alm do uso da ferramenta, sejam seguidos os J2EE Core
Patterns e as melhores prticas descritas nos links no final deste documento.
Mais informaes sobre o PMD: http://pmd.sourceforge.net/
A verso que deve ser usada do PMD se encontra na pgina do SIT:

http://desenv.coresp.caixa/SIT/

Verso 1.0.3 28/01/2008
Recomendaes para Aplicaes Cliente
As aplicaes cliente so aquelas que rodam fora do servidor de

aplicaes, porm utilizam recursos que se encontram dentro do servidor.
Para criar uma aplicao cliente necessrio criar um JAR com a seguinte
estrutura (exemplo):
\gov
\caixa
\aplicacao
\SuaClasse.class
\META-INF
\MANIFEST.MF
\application-client.xml
\sun-application-client.xml
O arquivo MANIFEST.MF deve ter em seu contedo a indicao da classe que

contm o mtodo main da aplicao cliente, exemplo:
Main-Class: gov.caixa.aplicacao.SuaClasse
No SJSAS8 os arquivos application-client.xml e sun-application-client.xml

devem ter o contedo conforme exemplos abaixo:
<application-client xmlns="http://java.sun.com/xml/ns/j2ee" version="1.4"

http://java.sun.com/xml/ns/j2ee/application-client_1_4.xsd">
<display-name>ConverterClient</display-name>
<ejb-ref>
<ejb-ref-name>ejb/SimpleConverter</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>converter.ConverterHome</home>
<remote>converter.Converter</remote>
</ejb-ref>
</application-client>
--
<!DOCTYPE sun-application-client PUBLIC "-//Sun Microsystems, Inc.//DTD
Application Server 8.0 Application Client 1.4//EN"
"http://www.sun.com/software/appserver/dtds/sun-application-client_1_4-
0.dtd">
<sun-application-client>
<ejb-ref>
<jndi-name>ConverterBean</jndi-name>

Verso 1.0.3 28/01/2008
</ejb-ref>
</sun-application-client>
No SUNONE7 os arquivos application-client.xml e sun-application-

client.xml devem ter o contedo conforme exemplos abaixo (note que a nica
diferena para o SJSAS8 o cabealho dos arquivos):
<!DOCTYPE application-client PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE

Application Client 1.3//EN' 'http://java.sun.com/dtd/application-
client_1_3.dtd'>
<application-client>
<display-name>ConverterClient</display-name>
<ejb-ref>
<ejb-ref-type>Session</ejb-ref-type>
<home>converter.ConverterHome</home>
<remote>converter.Converter</remote>
</ejb-ref>
</application-client>
--
<!DOCTYPE sun-application-client PUBLIC '-//Sun Microsystems, Inc.//DTD

Sun ONE Application Server 7.0 Application Client 1.3//EN'
'http://www.sun.com/software/sunone/appserver/dtds/sun-application-
client_1_3-0.dtd'>
<sun-application-client>
<ejb-ref>
<jndi-name>ConverterBean</jndi-name>
</ejb-ref>
</sun-application-client>

Verso 1.0.3 28/01/2008
Para acessar os EJBs dentro de uma aplicao cliente, fazer conforme exemplo
abaixo:
InitialContext initialcontext = new InitialContext();

Context context = (Context)initialcontext.lookup("java:comp/env");
Object obj = context.lookup("ejb/SimpleConverter");
ConverterHome converterhome =
(ConverterHome)PortableRemoteObject.narrow(obj,
converter.ConverterHome.class);
Para rodar a aplicao cliente utilizar o seguinte comando:
{diretrio do application server}/bin/appclient client {caminho do seu

jar} xml {caminho da instncia}/config/sun-acc.xml
Ateno: O arquivo sun-acc.xml contm o endereo e porta do servidor que a

aplicao cliente ir utilizar, portanto no devem ser mantidos em arquivos de
configurao da aplicao endereos e portas fixos.
Mais detalhes sobre as aplicaes cliente em:
http://docs.sun.com/source/819-0079/dgacc.html

Verso 1.0.3 28/01/2008
Recomendaes gerais
1. Escolher e dimensionar adequadamente cada uma das instncias das

classes de Collections dentro da aplicao e dessa forma otimizar o
balano entre consumo de CPU e memria. Para cada tipo de estrutura que
um sistema usa, a Java API tem uma Collection especfica. Ver Core Java
Volume II, tpico de Collections.
2. O uso de Java Reflection (Reflexo) est sujeito aprovao do SIT

conforme necessidade. A princpio no ser permitido o uso a menos que
exista uma justificativa tcnica fundamental. Solicitar permisso antes do
desenvolvimento para evitar retrabalho.
3. As aplicaes J2EE obrigatoriamente devem conter um ServiceLocator

(Core J2EE Design Patterns) com cache de referncias de objetos
distribudos (EJBHome, DataSource, MailSession, URL, etc) a fim de evitar
consultas excessivas a JNDI e degradar a performance. Este componente
deve ser usado na camada Web para acesso aos EJBs e recursos, e dever
usado tambm na camada de negcio (EJBs) quando qualquer objeto
necessitar dessas referncias.
4. Evitar inserir nas aplicaes Java/J2EE blocos ou mtodos sincronizados,

ou seja, antes de inserir tais controles, verificar a real necessidade deles,
principalmente nos componentes que so acessados por vrias requisies
simultneas.
5. Nas Factories (Para DAOs, Delegates, etc) usar a tcnica da Object

Cloning para diminuir os tempos de processamento na criao de objetos a
partir do operador new.
Referncia:
http://java.sun.com/developer/JDCTechTips/2001/tt0306.html#cloning
6. Uma aplicao Web J2EE pode facilmente gerar uma tabela e export-la no
padro do MS-Excel. Para isso devemos criar uma JSP que formata uma
tabela de dados. Nesta JSP, colocar uma declarativa content-type
especfica para o MS-Excel.
<%@ page contentType="application/vnd.ms-excel" %>
Referncia:
http://www.theserverside.com/discussions/thread.tss?thread_id=33400#166
890

Verso 1.0.3 28/01/2008
Filas de Mensagens (JMS Java Message Service)
JMS Java Message Service uma API Java utilizada para criar, enviar,
receber e ler mensagens, esta API foi incorporada na especificao J2EE a partir
da verso 1.3.
Pode ser utilizada a forma de envio P2P Point to Point (um envia, um
recebe) ou Publisher/Subscriber (um envia, vrios recebem), o seu consumo pode
ser realizado de forma sncrona com um programa esperando atravs do mtodo
receive at que a mensagem chegue ou termine por timeout ou de forma
assncrono com um programa se registrando como Listener, que ao receber uma
mensagem o evento onMessage executado.
Na Caixa Econmica Federal utilizado o IBM MQ Series para interfacear
com rotinas orientadas a mensagens no Mainframe.
Links recomendados:
http://www.javasoft.com/products/jms/docs.html
http://java.sun.com/products/jms/

Verso 1.0.3 28/01/2008
Componentes Corporativos
Visando maior qualidade e produtividade a Caixa disponibiliza cinco

componentes para facilitar o desenvolvimento das aplicaes J2EE. Estes
componentes foram projetados e implementados para que possam ser reutilizados
por vrios sistemas no ambiente da Caixa Econmica Federal.
Componente SIROTCon - verso 2 - Componente responsvel pela

conexo com o SIROT/Mainframe utilizando-se de mensagens no formato ISO.
Utilizado no mbito da Caixa So Paulo.
http://desenv.coresp.caixa/ajudadoc/topicos/sistemas/sirot2/index.html
ComponenteLdap Componente responsvel pelo mdulo genrico de

acesso as informaes do LDAP, estabelece a conexo com o LDAP, a partir de
um determinado ldapLoginName e ldapPassword.
Siico Componente para consulta de informaes corporativas. Obtm

dados do Mainframe atravs do componente SIROTCon.
Crypto O componente crypto.jar uma soluo para as aplicaes que

migraram do IAS 6.5 para SJSAS 7 e 8. Como no IAS 6.5 era necessrio parar e
reiniciar as instncias do servidor de aplicao todas as vezes que se fizesse
deploy, o problema das chamadas JNI que fazem uso dos recursos de bibliotecas
nativas no ocorria. As instncias estticas das bibliotecas nativas de criptografia
tambm eram removidas e recriadas com o undeploy e deploy, respectivamente.
No SJSAS 7 e 8 o deploy feito sem a necessidade de parada das

instncias do servidor de aplicao, o que representa uma grande vantagem, pois
no se causa impacto nas demais aplicaes da instncia. Mas com isso, surge o
problema de conflito de carga de instncias de bibliotecas nativas, j que a carga
feita no primeiro deploy e no mais removida, a no ser que se pare e se
reinicie a instncia do servidor de aplicao. Por este motivo o crypto, assim como
qualquer biblioteca que faa chamada via JNI, deve estar no classpath da
instncia, sendo carregado no start da instncia e no sendo afetado por
undeploy/deploy de aplicaes.
O SIT-SP tem trabalhado para centralizar todas as chamadas JNI no

componente crypto.jar que tem como objetivo ser um componente reutilizvel para
as aplicaes que fazem uso das bibliotecas nativas de criptografia. Atualmente o

Verso 1.0.3 28/01/2008
componente crypto.jar contm chamadas nativas as bibliotecas
libCriptografiaSiwin.so, libcripta.so, libSenhasSIIBC.so, libSiranCrypto.so. O
componente crypto.jar est setado no classpath do SJSAS 7 e 8.
Nota:
Futuramente as chamadas JNI devero ser substitudas por componentes

similares implementados puramente em Java.

Verso 1.0.3 28/01/2008
Verses das principais bibliotecas no SJSAS8
J2EE 1.4 JDK 1.5
Servlet 2.4 EJB 2.1
JSP 2.0 JDBC 3.0
JavaMail 1.3 JMS 1.1
SOAP with API attachments API for Java 1.2 Java API for XML Processing (JAXP) 1.2
J2EE Connector Architecture (JCA) 1.5 Java Web Services Developer Pack 1.5
Java API for XML-based RPCs (JAX-RPC) 1.1 WS-I Basic Profile 1.0
J2EE Deployment 1.1 J2EE Management 1.0

Java Authorization Contract for Containers
Java Management Extensions (JMX) 1.2
(JACC) 1.0
JSP TagLib 1.1

Verso 1.0.3 28/01/2008
Problemas e BUGs em Frameworks de Mercado
1. Foi identificado um BUG com relao insero de JSPs usando os

mecanismos da InsertTag do Tiles presente nas distribuies do Struts at
a verso 1.2.9, tendo sido corrigido para a partir da verso 1.3.
Esse BUG afeta todo e qualquer servidor de aplicaes.
Desta forma, recomendamos usar uma verso igual ou superior a 1.3 do

Struts para uso do Tiles.
Referncia: http://issues.apache.org/bugzilla/show_bug.cgi?id=21972

Verso 1.0.3 28/01/2008
Referncias
Sun Java System Application Server 8
Developer Guide:
http://docs.sun.com/app/docs/doc/819-0217
Performance Guide:
http://docs.sun.com/app/docs/doc/819-0084
Padres das aplicaes J2EE:

http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/
Limitaes dos EJBs:

http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html
Core J2EE Design Patterns

http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
Documentao da J2EE 1.4

http://java.sun.com/j2ee/1.4/docs/index.html
Tutorial J2EE 1.4

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html
O que h de no novo na J2EE 1.4

http://www.theserverside.com/tt/articles/article.tss?l=EvolvingJ2EE
Core Java Series, Volume I e II

Sun PRESS, Makron Books.
Core Servlets and JSP

Sun PRESS, Makron Books
http://pdf.coreservlets.com/
Jakarta Struts Cookbook

http://www.temporeal.com.br/produtos.php?id=169822
Handling EJB Exceptions (IBM Developer Works)

http://www-128.ibm.com/developerworks/java/library/j-ejbexcept.html

Verso 1.0.3 28/01/2008

ManualDesenvolvimentoJ2EE SJSAS8 v1.0.3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ManualDesenvolvimentoJ2EE SJSAS8 v1.0.3

Uploaded by

Copyright:

Available Formats

Manual de Desenvolvimento

Sun Java System Application Server 8

Uso Interno SUN/Caixa Pgina 1

Boas Prticas Java/J2EE...................................................... 25

Boa prtica aplicada: Utilizando os recursos da J2SE 1.5.... 40

Uso Interno SUN/Caixa Pgina 2

Boa prtica aplicada: Mapeamento de JSP .......................... 41

Boa prtica aplicada: Usando o Jakarta Struts 1.3 ............... 44

Boas Prticas de Implementao ......................................... 49

Componentes Corporativos .................................................. 67

Uso Interno SUN/Caixa Pgina 3

Uso Interno SUN/Caixa Pgina 4

Uso Interno SUN/Caixa Pgina 5

Uso Interno SUN/Caixa Pgina 6

Com o nascimento da plataforma J2EE, os grandes fornecedores

Analogicamente ao ambiente MainFrame, o Servidor de Aplicaes pode

No desenvolvimento J2EE, cada camada de componentes tem sua

Uso Interno SUN/Caixa Pgina 7

Pesquisas, estudos e a vivncia do mercado de desenvolvimento apontam

Entretanto, uma arquitetura mal concebida e mal elaborada prejudicar

O desenho abaixo mostra como a plataforma J2EE (Virtual Platform) deve

Uso Interno SUN/Caixa Pgina 8

Experincia de mercado com empresas de todos os segmentos como:

A ordem de dependncia importante para garantir as qualidades

Para garantir que o modelo de arquitetura seja seguido e verificado, devem

Uso Interno SUN/Caixa Pgina 9

Para garantir as qualidades sistmicas e requisitos no-funcionais de um

Seguindo esse modelo, e usando componentes j existentes na Caixa,

Uso Interno SUN/Caixa Pgina 10

Uso Interno SUN/Caixa Pgina 11

Uso Interno SUN/Caixa Pgina 12

Uso Interno SUN/Caixa Pgina 13

O Client, ou mquina cliente da aplicao, no deve ter muita inteligncia,

Atualmente para a plataforma Web as tecnologias presentes e que devem

Recomenda-se utilizar o mnimo possvel tecnologia JavaScript devido

Referncias para as principais tecnologias:

Para mais tecnologias relacionadas: http://www.w3.org

imprescindvel que a aplicao funcione corretamente nos principais Web

Sugesto: Utilizar o Web Browser Firefox (http://www.getfirefox.com) com

Uso Interno SUN/Caixa Pgina 14

Uso Interno SUN/Caixa Pgina 15

Responsabilidade principal: validar

Os Delegates que ligam os Actions

Uso Interno SUN/Caixa Pgina 16

Uso Interno SUN/Caixa Pgina 17

Atualmente para a esta plataforma, o padro JavaSoft de interface grfica

Responsabilidade principal: validar dados

Os Delegates ligados ao Model esto

Uso Interno SUN/Caixa Pgina 18

Esta camada representa o negcio propriamente dito, e tem como

Uso Interno SUN/Caixa Pgina 19

Todo e qualquer acesso camada de negcio deve ser feita pelos

Os Business Objects representam as entidades de negcio do sistema e

Na figura abaixo, vemos um diagrama mais detalhado dessa camada.

Uso Interno SUN/Caixa Pgina 20

Esta camada deve fornecer o acesso aos recursos computacionais

Os tipos de recursos podem ser: RDBMS, LDAP, EMAIL, URL, JMS, e

No caso especfico da Caixa, Regional SP, existem dois componentes

Uso Interno SUN/Caixa Pgina 22

Esta camada representa os recursos computacionais que esto fora da

Para cada um dos recursos, existem configuraes especficas e boas

Uso Interno SUN/Caixa Pgina 23

Uso Interno SUN/Caixa Pgina 24

Boa prtica aplicada: Segurana Declarativa na J2EE