Este documento fornece um resumo de 3 frases sobre tecnologias para desenvolvimento de software: 1) Apresenta um curso sobre diversas tecnologias Java como Servlets, JSP, JSF, EJB e Spring. 2) Fornece detalhes sobre o instrutor Rafael Benevides e sua experiência com Java. 3) A agenda inclui discussões sobre Servlets, JSP, Hibernate e outros temas ao longo de 9 dias.

1. Tecnologias para
Desenvolvimento
de Software

2. Licença
Esta obra está licenciada sob uma
Licença Creative Commons
http://creativecommons.org/licenses/by-nc-sa/2.0/br/

3. Instrutor
● Rafael Benevides
● Trabalha com Java desde 2001
● Possui as certificações Java: SCJA, SCJP,
SCWCD, SCBCD e SCEA.
● E não Java: SAP Netweaver e ITIL
● Atualmente desenvolve aplicações para o
Governo Federal usando as tecnologias que
serão apresentadas

4. Objetivo
● Visão geral das diversas tecnologias para
desenvolvimento de software corporativo

5. Agenda
● 31/07 – Servlets, JSP e JSF
● 01/08 – JNDI, JMS, JAAS, JCA e JTA
● 02/08 – Hibernate e JPA
● Livres por alguns dias ;)
● 07/08 – JBoss AS, EJB2.1, EJB3 e
Webservices
● 08/08 – Maven, JMX, Spring e JWS
● 09/09 – JBoss Seam

6. Apresentação da equipe
● Seu nome
● Atividade que executa
● Experiência
– Orientação a objetos
– Programação Java
– Modelagem/Projeto de Classes
Expectativas sobre o curso

7. JCP e as Especificações Java
● O que é uma especificação?
● Como nascem as especificações ?
● JCP - Java Community Proccess
● Quem participa: Apache, BEA, CA, Ebay, Eclipse, Google, HP,
IBM, LG, Mitsubishi, Motorola, Nokia, Novell, Oracle, Panasonic,
Philips, Red Hat, SAP, Siemens, Sony,
● A própria Sun
● E também: faculdades, comunidades (Soujava, etc) e pessoas

8. Programação por contratos
● Interoperabilidade
?

9. Contrato entre componentes
● Interoperabilidade só é atingida com:
● Padronização

10. Uma interface é um contrato entre
partes

11. Interface não é implementação
≠

12. Interfaces
● Elementos legais
– Contrato
– Contratado – Contratante
● Quem ● Quem usa a
● Interface
implementa a interface
interface

13. Interfaces

14. Uma Interface com várias
implementações

15. Interfaces Java
● Java
public interface DataAccesLayer {
public String [] read(int recNo);
public void update(int recNo, String [] data);
public void delete(int recNo);
}

16. Implementação da Interface
● Java
public class ArquivoBinario implements DataAccessLayer {
public String [] read(int recNo) {
//Codigo....
}
public void update(int recNo, String[] data) {
//Codigo....
}
public void delete(int recNo) {
//Codigo....
}
}

17. Frameworks
● Exemplo
– Auto atendimento do BRB
– Auto atendimento do BB
– Auto atendimento do Banco REAL

18. Frameworks
● Exemplo
– Auto atendimento do BRB
– Auto atendimento do BB
– Auto atendimento do Banco REAL
– Auto atendimento genérico

19. Framework genérico
● Aplicativo genérico
– Auto atendimento bancário
– Framework de auto atendimento bancário

20. Frameworks
● Esqueleto de uma aplicação
● Extensível
● Parametrizável
● Exemplos: Applet, Servlet, MIDlet, EJB, etc

21. Applet

22. Servlet

23. Midlet

24. EJB 2.1 – Session Bean

25. Servlets

26. Assuntos
● Servlets e o Web Container
● Escrevendo texto
● Escrevendo binário
● SendError e sendRedirect
● Parametros
● Contextos
● Sessão
● Servlet Config
● Mapeamento dos Servlets
● Filtros

27. Como nasceu o servlet
● Era uma vez o CGI...
● Mas o CGI não suporta Threads
● O CGI é dependente de plataforma
● E não escala!
● Mesmo assim as pessoas querem
desenvolver para Web
● Assim...

28. Nasceu o Servlet
● Foi pensado para aplicações do tipo Requisição e Resposta
(Request e Response)
● Precisa de um Container
● Para aplicações Web, foi definido classes específicas para lidar
com HTTP.

29. Vantagem do Servlet sobre CGI
● Eficiente: Nova Thread em vez de um novo Processo
● Conveniente: É Java!!! Não é necessário aprender Perl ou
outras linguagens
● Poderoso: De novo, é Java e possui todos seus benefícios,
além do benefício do Contêiner
● Portável:
– Entre Sistemas Operacionais - É Java
– Servidores: Faz parte de uma JSR
● É barato: Varias opções livres, incluindo o famoso e
poderoso Apache.

30. Ciclo de vida - Métodos
● Interface Servlet possui 3 métodos principais:
– init()
– service()
– destroy()
● Mais métodos auxiliares:
– getServletConfig()
– getServletInfo()
– GetServletContext()
– etc

31. Método service()
● A classe HttpServlet implementa o service()
para tratar uma requisição HTTP em um dos
métodos específicos:
– doGet()
– doHead()
– doDelete()
– doOptions()
– doPost()
– doTrace()

32. Ciclo de vida de um Servlet

33. Estrutura básica de um Servlet
public class AlgumServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
Use o “request para ler os cabeçalhos-HTTP (ex.:
cookies) e dados de formulários (ex.: dados
preenchidos pelo usuários e enviados)
Use o “response” para especificar respostas HTTP
(ex.: especificar tipo de conteúdo, criar cookies, etc)
PrintWriter out = response.getWriter();
// Use "out" para enviar conteúdo escrito (Writer)
para o cliente
}
}

34. Hello World em Servlet
public class HelloWorld extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
PrintWriter out = response.getWriter();
out.println("Hello World");
}
}

35. Servlets – Conteúdo binário
public class ImageServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("image/jpeg");
File file = new File("C:/algumaImagen.gif");
// Abrir os Streams
FileInputStream in = new FileInputStream(file);
OutputStream out = response.getOutputStream();
// Copiar do Arquivo para o Response
byte[] buf = new byte[1024];
int count = 0;
while ((count = in.read(buf)) >= 0) {
out.write(buf, 0, count);
}
in.close();
out.close();
}
}

36. Servlets e Http Response code
response.sendError(HttpServletResponse.SC_NOT_FOUND)
CódigoTipo
1XX Informação
2XX Sucesso
3XX Redirecionamento
4XX Erro Cliente
5XX Erro Servidor
Mnemonic Code Message
SC_OK 200 OK
SC_NO_CONTENT 204 No Content
SC_MOVED_PERMANENTLY 301 Moved Permanently
SC_MOVED_ TEMPORARILY 302 Moved Temporarily
SC_ UNAUTHORIZED 401 Unauthorized
SC_NOT_FOUND 404 Not Found
SC_SERVICE_UNAVAILABLE 503 Service Unavailable

37. Redirect vs Request Dispatcher
ResquestDispatcher rd = request.getResquestDispatcher("Servlet2");
rd.forward(request, response);
response.sendRedirect(“Servlet2);

38. Lendo Parâmetros
public class LerParametros extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<BODY>n"
+ "<UL>n"
+ " <LI>param1: " + request.getParameter("param1") + "n"
+ " <LI>param2: " + request.getParameter("param2") + "n"
+ " <LI>param3: " + request.getParameter("param3") + "n"
+ "</UL>n" + "</BODY></HTML>");
}
}

39. Lendo Parâmetros

40. Lendo Atributos
● Como o HTTP não mantém estado de sessão, são as
aplicações Web que precisam cuidar de mantê-lo
quando necessário
● Atributos != parâmetros
● Parâmetros estão na URL e Atributos estão na
container
● Atributos podem estar em um dos 3 contextos:
– Aplicação – javax.servlet.ServletContext
– Session – javax.servlet.http.HttpSession
– Request – javax.servlet.HttpServletRequest

41. Lendo atributos da sessão
● Sessões são representados por objetos HttpSession e são obtidas
a partir de uma requisição
● Dois métodos podem ser usados
– HttpSession session = request.getSession(false);
– HttpSession session = request.getSession();
Requisição 1
String[] vetor = {"um", "dois", "tres"};
HttpSession session = request.getSession();
session.setAttribute("dados", vetor);
Requisição 2
HttpSession session = request.getSession();
String[] dados = (String[])session.getAttribute("dados");

42. Configurando um Servlet
● javax.servlet.ServletConfig
● O ServletConfig pode ser obtido nos métodos:
– init(ServletConfig)
– getServletConfig()
● O método getInitParameter(“senhaBanco”) retorna o valor do
web.xml
<servlet>
<servlet-name>HelloWorld</servlet-name>
<servlet-class>com.digitel.servlet.HelloWorld</servlet-class>
<init-param>
<param-name>senhaBanco</param-name>
<param-value>123</param-value>
</init-param>
</servlet>

43. Mapeando um Servlet
<servlet>
<description></description>
<display-name>HelloWorld</display-name>
<servlet-name>HelloWorld</servlet-name>
<servlet-class>com.digitel.servlet.HelloWorld</servlet-class>
<init-param>
<param-name>senhaBanco</param-name>
<param-value>123</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>HelloWorld</servlet-name>
<url-pattern>/HelloWorld</url-pattern>
</servlet-mapping>
<servlet>

44. Filtros
● Um filtro é um componente Web que reside
no servidor
– Intercepta as requisições e respostas no seu caminho até
o servlet e de volta ao cliente
– Sua existência é ignorada por ambos. É totalmente
transparente tanto para o cliente quanto para o servlet
– Suportado desde a versão 2.3 da especificação de
Servlets
– Filtros permitem tomadas de decisões: Geralmente
usados para autêncicação

45. Criando um Filtro
● Implementar a interface Filter
● Cadastrar o filtro no web.xml
● Sintaxe lembra mapeamento do Servlet
<filter>
<filter-name>umFiltro</filter-name>
<filter-class>com.digetel.HelloFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>umFiltro</filter-name>
<url-pattern>/filtro</url-pattern>
</filter-mapping>

46. Filtro simples que substitui um
servlet
public class HelloFilter implements Filter {
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain filterChain)
throws ServletException, IOException {
PrintWriter out = response.getWriter();
out.println("<HTML><HEAD>[etc]..");
out.println("</TITLE></HEAD><BODY>");
out.println("<H1>Filter Response</H1>");
out.println("<P>" + texto);
out.println("</BODY></HTML>");
out.close();
}
public void destroy() {}
}

47. JSP

48. Assuntos
● JSP e Ciclo de vida
● Variáveis implícitas
● Diretivas (page, taglib, include)
● Scriptlets <% %>
● Expressão <%= %>
● Declaração <%! %>
● Comentário <%-- --%>
● Objetos implícitos
● Taglibs e JSTL
● EL

49. JSP
● Um JSP é um servlet durante a execução
● Em um servidor que suporta JSP, processamento de JSP
passa por uma camada adicional onde a página é
transformada (compilada) em um servlet
● Um JSP, depois de carregado, é tão veloz quando um
servlet
● Acesso via URL usa como localizador a própria página
● É mais fácil escrever e implantar, mas é mais difícil depurar

50. Por que JSP ?
● Servlets forçam o programador a embutir
código HTML dentro de código Java
– Desvantagem se a maior parte do que tem que ser gerado é
texto ou código HTML estático
– Mistura as coisas: programador tem que ser bom Web
Designer e se virar sem ferramentas de Web Design
HojeServlet.java
Date hoje = new Date();
out.println("<body>");
out.println("<p>A data de hoje é "+hoje+".</p>");
out.println("<body>");

51. JSP
● Solução do problema anterior usando
templates JSP
<body>
<p>A data de hoje é <%=new Date() %>.</p>
<body>
hoje.jsp
● Em um servidor que suporta JSP,
processamento de JSP passa por uma
camada adicional onde a página é
transformada (compilada) em um servlet
● Acesso via URL usa como localizador a
própria página

52. Criando uma JSP facilmente
● Mudar a extensão de um arquivo HTML
para .jsp
● Colocar o documento em um servidor que
suporte JSP
● Fazendo isto, a página será transformada em
um servlet
– A compilação é feita no primeiro acesso
– Nos acessos subseqüentes, a requisição é
redirecionada ao servlet que foi gerado a partir da
página

53. Criando uma JSP facilmente
● Transformado em um JSP, um arquivo HTML
pode conter blocos de código (scriptlets): <
% ... %> e expressões <%= ... %> que são os
elementos mais frequentemente usados
<p>Texto repetido:
<% for (int i = 0; i < 10; i++) { %>
<p>Esta é a linha <%=i %>
<% }%>

54. Sintaxe do JSP
● Podem ser usados em documentos de texto
(geralmente HTML ou XML)
● Todos são interpretados no servidor (jamais
chegam ao browser)
– diretivas: <%@ ... %>
– declarações: <%! ... %>
– expressões: <%= ... %>
– scriptlets: <% ... %>
– comentários: <%-- ... --%>
– ações: <jsp:ação ... />
– custom tags: <prefixo:elemento ... />

55. Diretivas JSP
● Contém informações necessárias ao processamento da classe do servlet
que gera a página JSP
● Sintaxe : <%@ diretiva atrib1 atrib2 ... %>
● Principais diretivas:
– page: atributos relacionados à página
– include: inclui outros arquivos na página
– taglib: declara biblioteca de custom tags usada no documento
Exemplos:
<%@ page import="java.net.*, java.io.*"
session="false" errorPage="/erro.jsp" %>
<%@ include file="navbar.jsp" %>

56. Declarações
● Dão acesso ao corpo da classe do servlet. Permitem a declaração de
variáveis e métodos em uma página
● Úteis para declarar:
– Variáveis e métodos de instância (pertencentes ao servlet)
– Variáveis e métodos estáticos (pertencentes à classe do servlet)
– Classes internas (estáticas e de instância), blocos static, etc.
● Sintaxe: <%! declaração %>
Exemplo:
<%!
public final static String[] meses =
{"jan", "fev", "mar", "abr", "mai", "jun"};
public static String getMes() {
Calendar cal = new GregorianCalendar();
return meses[cal.get(Calendar.MONTH)];
}
%>

57. Expressões
● Expressões: Quando processadas, retornam um valor que é
inserido na página no lugar da expressão
● Sintaxe: <%= expressão %>
● Equivale a out.print(expressão), portanto, não pode terminar em
ponto-e-vírgula
● Todos os valores resultantes das expressões são convertidos em
String antes de serem redirecionados à saída padrão

58. Scriptlets
● Scriptlets: Blocos de código que são executados sempre que uma página
JSP é processada
● Correspondem a inserção de seqüências de instruções no método
_jspService() do servlet gerado
● Sintaxe: <% instruções Java; %>
<HTML>
<BODY>
<%
// Este scriptlet declara e inicializa "date"
System.out.println( "Pegando a data do sistema" );
java.util.Date date = new java.util.Date();
%>
Hello! A data/hora agora é
<%
out.println( date );
out.println( "<BR>Seu IP é " );
out.println( request.getRemoteHost());
%>
</BODY>
</HTML>

59. Objetos implícitos
● Objetos do Servlet
– page
– config
● Objetos Contextuais
– session
– application
– pageContext
● Entrada e saída
– request
– response
– out
● Controle de Exceção
– exception

60. Exemplo de objetos implicitos
http://servidor/programa.jsp?nome=Fulano&id=5
<%
String nome = request.getParameter("nome");
String idStr = request.getParameter("id");
int id = Integer.parseInt(idStr);
%>
<p>Bom dia <%=nome %>! (cod: <%=id %>

61. Taglibs e JSTL
● Designers não se dão bem com scriptlets
● Para isto a JSP suporta Taglibs
Taglibs são declaradas no início de cada página
<%@taglib uri="http://abc.com/ex" prefix="exemplo"%>
... e usadas em qualquer lugar
<exemplo:dataHoje />
produz → Thursday, Agosto 31, 2008 13:13:13 GMT-03

62. JSTL – Java Standard Tag Library
● Esforço de padronização do JCP: JSR-152
● Oferece dois recursos:
– Conjunto padrão de tags básicos (Core, XML, banco de dados
e internacionalização)
– Linguagem de expressões do JSP 1.3
● Oferece mais controle ao autor de páginas
sem necessariamente aumentar a
complexidade
– Controle sobre dados sem precisar escrever scripts
– Estimula a separação da apresentação e lógica
– Estimula o investimento em soluções MVC

63. JSTL – 4 bibliotecas
● Core – loops, condições, url, etc
– <%@ taglib uri="http://java.sun.com/jstl/ea/core" prefix="c" />
– Exemplo: <c:if test="...">...</c:if>
● XML – processamento de XML
– <%@ taglib uri="http://java.sun.com/jstl/ea/xml" prefix="x" />
– Exemplo: <x:parse>...</x:parse>
● I18n – Internacionalização
– <%@ taglib uri="http://java.sun.com/jstl/ea/fmt" prefix="fmt" />
– Exemplo: <fmt:message key="..." />
● SQL – Manipulação de Banco de Dados
– <%@ taglib uri="http://java.sun.com/jstl/ea/sql" prefix="sql" />
– Exemplo: <sql:update>...</sql:update>

64. EL – Expression Language
● Permite embutir em atributos expressões dentro de delimitadores $
{...}
● Em vez de request.getAttribute("nome"):${nome}
● Em vez de bean.getPessoa().getNome():${bean.pessoa.nome}
● Suporta operadores aritméticos, relacionais e binários: and, or, eq,
not eq, not empty, le, ge, lt, le

65. Principais ações
● Suporte à impressão da linguagem
expressões
<c:out value="${pessoa.nome}" />
– Expressões condicionais
<c:if test="${pessoa.idade &gt;= 18}">
<a href="adultos.html">Entrar</a>
</c:if>
<c:choose>
<c:when test="${dia.hora == 13}">
<c:out value="${mensagemEspecial}" />
</c:when>
<c:otherwise>
<c:out value="${mensagemPadrao}" />
</c:otherwise>
</c:choose>

66. Principais ações
● Iteração
<c:forEach items="${pessoas}" var="p" varStatus="s">
<c:out value="${s.count}"/>. <c:out value="${p}"/>
</c:forEach>
● Operação com Banco de Dados
<sql:query dataSource="${dsn}">SELECT...</sql:query>
<sql:transaction>, <sql:update>, etc.

67. JSF

68. Assuntos
● Por quê JSF ?
● Managed Beans
● Navegação
● Tags
● Tabela
● Conversão e Validação

69. O que é JSF
● Mais que um framework para desenvolver
aplicações web de forma ágil, JSF foi
incorporado ao especificação J2EE
● O que JSF trás de bom?
– MVC para aplicações web
– "fácil" de usar
– Boa demanda do mecado e conseqüentemente
dos desenvolvedores

70. Managed Beans
● São classes simples, não herdam de ninguém nem são obrigados
a implementar nenhuma interface
● Possuem nossos famosos getter e setters seguindo a convenção
JavaBean
<h:inputText id="nome" value="#{meuBean.nome}"
size="25" maxlength="125" />
Devem ser cadastrados no faces-config.xml
<managed-bean>
<managed-bean-name>meuBean</managed-bean-name>
<managed-bean-class>br.com.digitel.MeuBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>

71. Navegação
● Navegação fácil (faces-config.xml)
<navigation-rule>
<from-view-id>/greeting.jsp</from-view-id>
<navigation-case>
<from-outcome>success</from-outcome>
<to-view-id>/response.jsp</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>fail</from-outcome>
<to-view-id>/fail.jsp</to-view-id>
</navigation-case>
</navigation-rule>

72. Tags
● Dois tipos:
● H (html) e F (faces)
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>

73. Tags HTML
● <h:form> - É a declaração de um formulário comum, o detalhe é que ele é
declarado aqui sem nenhuma ação, isso vai ser feito mais na frente no
botão de submissão
● <h:outputText value="Login"/> - Tag que imprime na tela um valor fixo,
como o caso acima, mas pode imprimir valores de JavaBeans ou de um
arquivo de bundle por exemplo.
● <h:inputText id="login" binding="#{cadastroBean.loginComponente}"
required="true"/> <h:message for="login"/> - Nessa tag temos uma input
comum, o detalhe é que ela está "amarrada" a propriedade que está no
meu bean

74. Tags HTML
● <h:inputSecret id="senha" value="#{cadastroBean.senha}"
required="true"/> <h:message for="senha"/> - Input como a
explicada acima com a entrada escondida
● <h:commandButton
action="#{cadastroBean.cadastraUsuarioAction}" value="Enviar
Dados"/> - Aqui vai acontecer a submissão do formulário, no
atributo action diz que ação tomar quando o formulário for
submetido

75. Tags faces
● <f:view> - É o nodo inicial, uma espécie de saco que vai
guardar todos os componentes, validadores, conversores etc
● <f:convertXXXX> - Para usar conversores – Converte entre
String e Objetos
● <f:validateXXX> - Para usar validadores – Valida se os
dados são válidos
● <f:facet > - Adiciona um “facet” (ou atributo) para um
componente.
● <f:seletItem(s) > - Para valores de combos

76. Tabelas
● Usa-se o componente <h:dataTable>
● O Backing bean deve retornar um DataModel
● Existem algumas implementações de DataModel:
ArrayDataModel, ListDataModel, ResultDataModel,
ResultSetDataModel, ScalarDataModel

77. Tabelas
<h:dataTable var="usuario"
value="#{cadastroBean.usuariosCadastrados}" border="1">
<h:column>
<f:facet name="header">
<h:outputText value="Login"/>
</f:facet>
<h:outputText value="#{usuario.login}" />
<f:facet name="footer">
<h:outputText value="Login"/>
</f:facet>
</h:column>
</h:dataTable>

78. Conversores
● JSF tem seus alguns conversores implementados, mas é possível criar
seus próprios conversores
– BigDecimalConverter
– BigIntegerConverter
– BooleanConverter
– ByteConverter
– CharacterConverter
– DateTimeConverter
– DoubleConverter
– FloatConverter
– IntegerConverter
– LongConverter
– NumberConverter
– ShortConverter

79. Conversor não padrão
● Implementar a interface Converter
● Cadastrar no faces-config.xml
● Usar em conjunto com a tag
– <f:converter id=”meuConverter” />

80. Validadores
● JSF tem seus alguns validadores implementados, mas é possível criar
seus próprios conversores
– ValidateLenght
– ValidateLongRange
– ValidateDoubleRange
● Para criar seu próprio validador
– Implementar a interface Validator
– Cadastrar no faces-config.xml
– Usar em conjunto com a tag
● <f:validator id=”meuValidador” />

81. JNDI

82. Assuntos
● Introdução ao JNDI
– Conceitos básicos sobre nomes e diretórios
– Classes e pacotes da API JNDI
● Operações com nomes
– Contexto inicial
– Localização (lookup) de objetos
– Contextos
– Ligações (bindings)
● Operações com diretórios
– Atributos
– Pesquisas
● Registro de objetos

83. Conceitos fundamentais
● Conceitos relativos a sistema de nomes
– Serviço de nomes
– Ligação (binding)
– Convenções de nomenclatura
– Contextos e subcontextos
● Conceitos relativos a sistemas de diretórios
– Diretórios e serviços de diretórios
– Atributos
– Pesquisas e filtros
– LDAP

84. Serviço de Nomes
● A principal função de um serviço de nomes é permitir a associação
de um nome (ou uma outra representação alternativa mais
simples) a recursos computacionais como
– endereços de memória, de rede, de serviços
– objetos e referências
– códigos em geral
● Exemplos:
– Sistema de arquivos: liga caminho a bloco(s) de memória:
c:tempdados.txt → 16A0:0C00
– Sistema DNS: liga nome de domínio a endereço IP:
www.digitel.com.br → 200.198.105.35

85. Ligação ou Binding
● É a associação de um nome com um objeto
(ou com um localizador do objeto)
● Exemplos:
– Nome de arquivo no DOS está ligado a um bloco
de memória
– Nome de máquina na internet está ligado a
endereço IP
– Nome de objeto em ORB está ligado a uma
instância remota do objeto
– UmNome → Objeto

86. Convenções de nomeclatura
● Todo sistema de nomes obedece a uma
determinada convenção que determina sua
sintaxe
● Exemplos:
– DOS: C:Windows
– Linux: /home/rafael/Documentos
– DNS: www.digitel.com.br
– LDAP: tel=61-133, uf=RS, pais=55

87. Contextos e subcontextos
● Um contexto é um conjunto de ligações nome-objeto
● Se o objeto (referência) contido no contexto for também um
contexto ele é um subcontexto
● Exemplos de contextos e subcontextos:
● /usr/bin/java/ → usr é o contexto; bin é subcontexto de usr, ...
● www.abc.com.br → br é o contexto, com é subcontexto de br, ...

88. Serviço de diretórios
● Um serviço de diretório é oferece operações para criar, remover,
modificar e principalmente pesquisar atributos associados a
objetos em um diretório
● Diretório = tipo de banco de dados acessível via rede
● Projetado para ser mais eficientes na recuperação de dados que
na gravação ou alteração
● Atualizações são simples, sem transações e envolvendo pequena
quantidade de dados

89. Atributos
● Descrevem objeto associado a um objeto de diretório
● Um atributo possui
– Um identificador de atributo: permite que o atributo seja
localizado e utilizado
– Conjunto de valores de atributo: as informações (dados) que
estão associadas com o atributo
– Um tipo: restringe os dados que um atributo pode receber
● Atributos fazem parte do contexto do objeto

90. LDAP
● Lightweight Directory Access Protocol
● Protocolo leve para acesso a diretórios (padrão aberto)
● Armazena objetos em uma árvore
● Define vários atributos, tipos e sintaxes padrão baseados no X.500
● Extensível (pode-se criar novos tipos, atributos, etc.)
● Diretórios baseados em LDAP suportam:
– qualquer tipo de dados
– várias formas de segurança (criptografia, autenticação,
integridade)

91. LDAP

92. JNDI
● Java Naming and Directory Interface é uma ponte sobre os
diversos serviços de nomes e diretórios diferentes
● Vantagens
– Só é preciso aprender uma única API para acessar vários tipos
de informação de serviços de diretório
– Isola a aplicação dos detalhes específicos do protocolo
– Pode ser usada para ler objetos Java (serializados) que
estejam armazenados em um diretório

93. Arquitetura JNDI

94. Uso do JNDI
● Para usar JNDI é preciso ter
– As classes e interfaces do JNDI (pacotes javax.naming.*)
– Pelo menos um provedor de serviços JNDI (driver)
● O Java 2 SDK inclui provedores de serviço (SPs) para
– LDAP - Lightweight Directory Access Protocol
– CORBA - Common ORB Architecture e COS name service
– Java RMI Registry

95. Exemplo 1 – Sistemas de nomes
1:import javax.naming.Context;
2:import javax.naming.InitialContext;
3:import javax.naming.NamingException;
4:import java.util.Properties;
5:
6:class Lookup {
7: public static void main(String[] args) {
8: Properties env = System.getProperties();
9: env.put(Context.INITIAL_CONTEXT_FACTORY,
10: "com.sun.jndi.fscontext.RefFSContextFactory");
11: try {
12: Context ctx = new InitialContext(env);
13: Object obj = ctx.lookup(args[0]);
14: System.out.println(args[0]+" esta ligado a: " + obj);
15: ctx.close();
16: } catch (NamingException e) {
17: System.err.println("Não achei "+args[0]+": "+e);
18: }
19: }
20:}

96. Contexto inicial
Precisa ser obtido antes de qualquer operação. Passos:
● 1: selecionar o provedor de serviços
Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"classe.do.ProvedorDeServicos");
● 2: Configurar o acesso ao serviço
env.put(Context.PROVIDER_URL, "ldap://xyz.com:389");
env.put(Context.OUTRA_PROPRIEDADE, "valor"); (...)
● 3: criar um objeto para representar o contexto
Context ctx = new InitialContext(env);

97. Recuperação de objeto (lookup)
● Para obter a referência para um objeto de um contexto usa-se o
método lookup()
● Para usar o objeto retornado é preciso conhecer o seu tipo e fazer
o cast (ou narrow, se objeto remoto) para promover a referência
● Se o objeto for um contexto, lookup() age como um método para
mudar de contexto (como o chdir, em Unix)

98. Exemplo de lookup
● O método lookup() usando com o provedor de serviço fscontext
retorna um java.io.File pelo nome de arquivo
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.fscontext.RefFSContextFactory");
env.put(Context.PROVIDER_URL, "file:/cap02/lab/filesys");
Context ctx = new InitialContext(env);
File f = (File)ctx.lookup("report.txt");

99. Modificando o Bind
● Substituindo ligações
● Adicionando ligações Fruit fruit = new Fruit("lemon");
ctx.rebind("favorite", fruit);
Fruit fruit = new Fruit("orange");
ctx.bind("favorite", fruit);
● Removendo ● Renomeando
ligações objetos
ctx.unbind("favorite");
ctx.rename("report.txt",
"old_report.txt");
● Criando novos
contextos ● Destruindo contextos
Context result =
ctx.destroySubcontext("new");
ctx.createSubcontext("new");

100. Conclusões
● Sistemas de nomes e diretórios abstraem conceitos específicos a
um domínio de problema
– Maior facilidade do uso de recursos
– Maior desacoplamento
● JNDI fornece uma interface genérica para diversos sistemas de
nomes e diretórios diferentes
– Permite que recursos compartilhados, localizados através de
diferentes sistemas de nomes e diretórios possam ser
armazenados e localizados usando uma interface uniforme
– A mesma interface pode ser usada para interagir com sistemas
de arquivos, LDAP, registro do Windows, DNS, ORBs, RMI
Registry e outros repositórios de objetos, etc.

101. JMS

102. Assuntos
● Mensagem assíncrona
● Point-to-Point (Queue)
● Publish-Subscriber (Topic)
● Modelo de programação
● Exemplos

103. O que é Messaging
● Método de comunicação entre componentes ou aplicações
● Arquitetura peer-to-peer com serviço centralizado para repasse de
mensagens recebidas e enviadas
● Clientes e servidores enviam e recebem mensagens para canais
administrados por serviço central de mensagens (MOM)

104. Messaging vs RPC vs e-Mail
● Messaging
– Mensagens são representadas como eventos (que causam
numero limitado de ações por parte do MOM)
– Interface genérica (pode ser reutilizada para aplicações
diferentes)
– Arquitetura centralizada (tudo passa pelo MOM)
– Serviços de diretórios localizam canais de comunicação
(destinos)

105. Messaging vs RPC vs e-Mail
● RMI/RPC (Corba, Java RMI, etc.)
– Mensagens são representadas como chamadas para métodos
remotos (numero ilimitado de ações)
– Cada aplicação se comunica através de uma interface definida
– Pode ser descentralizado (rede de ORBs ligados por IIOP)
– Serviços de diretórios localizam objetos

106. Messaging vs RPC vs e-Mail

107. Messaging vs RPC vs e-Mail
● E-mail
– Uma ou ambas as partes podem ser usuários
humanos
● Messaging é sempre comunicação 100% B2B

108. Desvantagens dos MOMs
● Camada adicional para repasse de mensagens
● Centralização em único ponto introduz risco de falha de todo o
sistema caso o serviço de mensagens falhe
– Solução: replicação, clustering

109. Desvantagens genéricas dos MOMs
● Muito genérica: aplicações precisam decifrar as mensagens para
que possam operar; esconde a interface de programação remota
dentro das mensagens
● Comunicação assíncrona (geralmente): dificulta a criação de
aplicações que necessitam de comunicação síncrona.
● Não faz tratamento de representação de dados (data marshalling)
- MOM é apenas meio de transporte

110. Vantagens dos MOMs (1)
● Escalabilidade
– Para aumentar a capacidade servidora, basta
acrescentar mais servidores (não é preciso
mexer nos componentes)
– Novos clientes podem se conectar para usar
mensagens em outras aplicações
– Infraestrutura é reutilizada para novas aplicações

111. Vantagens dos MOMs (2)
● Comunicação assíncrona
– Componentes podem realizar outras tarefas
enquanto não estão ocupados lidando com
requisições
– Podem sondar o servidor em busca de novas
mensagens quando estiverem livres (PTP)
– Podem se cadastrar para, quando houver
mensagens novas, receber notificação (pub/sub)

112. Vantagens dos MOMs (3)
● Desacoplamento
– Maior modularidade, maior reuso
(substituibilidade), maior simplicidade, maior
robustez (falhas localizadas)
– Papéis bem definidos simplificam o
desenvolvimento: produtor, consumidor e serviço
tem unica interface, independente da aplicação
– Servidor de messaging é responsável pela
qualidade do serviço (não é preocupação dos
componentes)

113. Vantagens dos MOMs (4)
● Flexibilidade
– API definida pelo tipo das mensagens (e não por
interfaces)
– Meio comum é a mensagem: se componentes a
entendem, o resto (linguagens, plataformas, etc.)
não importa!

114. E quando usar MOM em vez de
RPC
● ... ou, quando decidir por acoplamento mais fraco?
– Quando a comunicação se baseia mais no formato de
mensagens que em interfaces rígidas (componentes não
dependem da interface de outros componentes)
– Quando a disponibilidade dos componentes é imprevisível,
mas sua aplicação precisa rodar mesmo que componentes não
estejam todos acessíveis
– Quando for preciso suportar comunicação assíncrona:
componente pode enviar informações para outro e continuar a
operar mesmo sem receber resposta imediata
Cenário comum em muitas aplicações B2B!

115. JMS
● Interface Java única para unir as MOMs
incompatíveis
● API que permite que aplicações criem,
enviem, recebam e leiam mensagens através
de um MOM
● API consiste principalmente de interfaces
(implementadas pelo fabricante do MOM)
● Parte integral da plataforma J2EE (acrescenta
possibilidade de comunicação assíncrona a
EJBs)

116. Metas do JMS
● Oferecer uma API simples, unificada e
compatível com aplicações existentes (não-
JMS)
● Suportar aplicações heterogêneas em
diferentes Sos, plataformas, arquiteturas e
linguagens
● Suportar mensagens contendo objetos
serializados Java e páginas XML

117. Principais características
● Modelo flexível de desenvolvimento baseado em dois domínios:
ponto-a-ponto e publish/subscribe
● Controle de persistência, tempo de vida, prioridades e durabilidade
associados a serviços e mensagens
● Suporte à comunicação síncrona e assíncrona
● Suporte a transações no envio e recebimento de mensagens
● Suportado por todos os servidores de aplicação J2EE
(implementam os dois domínios: PTP e pub/sub)

118. Arquitetura JMS

119. Domínio PTP-Point-to-Point
● Baseado no conceito de filas, remetentes e destinatários
● Um para um: cada mensagem é enviada para uma fila específica e
é consumida por um destinatário (que pode ou não estar
disponível no momento)
● Destinatário confirma que a mensagem foi recebida e processada
corretamente (acknowledgement)
● Filas retém mensagens até que sejam consumidas (ou expirem)

120. Domínio pub-sub (publica/inscreve)
● Baseado em canais (tópicos)
● Muitos para muitos: mensagens são enviadas
a um canal onde todos os assinantes do canal
podem retirá-la
● Assinantes recebem notificação

121. Consumo de mensagens
● Sistemas de messaging são sempre assíncronos no sentido de
que não há dependência quanto ao tempo de envio e recebimento
das mensagens
● JMS porém permite um tipo de sincronismo: Pode-se bloquear as
operações em um destinatário até que uma determinada
mensagem chegue
● A especificação JMS, portanto, define que mensagens podem ser
consumidas de duas formas:
– Síncrona: quando o destinatário envia uma chamada receive()
e fica a esperar pelo recebimento de mensagens
– Assíncrona: o cliente registra-se como ouvinte de mensagens
e é notificado quando elas chegam

122. Escrevendo aplicações JMS
● Obter um destino e uma fábrica de conexões via JNDI
● Usar a fábrica para obter uma conexão
● Usar a conexão para obter uma ou mais sessões
● Usar a sessão para criar uma mensagem
● Iniciar a sessão
● Com a sessão, pode-se:
– Enviar mensagens
– Receber mensagens
– Cadastrar ouvintes para receber mensagens automaticamente

123. Escrevendo aplicações JMS

124. Há dois tipos de destino JMS
● Filas (Queue)
– Retêm todas as mensagens que recebem até que sejam retiradas ou
expirem
– Para cada mensagem enviada, apenas um cliente pode retirá-la
Queue fila = (Queue) ctx.lookup("jms/Queue");
● Canais (Topic)
– Cada canal pode ter vários clientes assinantes
– Cada assinante recebe uma cópia das mensagens enviadas
– Para receber uma mensagem publicada em um canal, clientes precisam
já ser assinantes dele antes do envio.
Topic canal = (Topic) ctx.lookup("jms/Topic");

125. Fábricas de conexão
● Antes que se possa
– enviar uma mensagem para uma fila,
– publicar uma mensagem em um canal,
– consumir uma mensagem de uma fila ou
– fazer uma assinatura de um canal
● é preciso obter uma conexão ao provedor JMS
● Isto é feito através de uma fábrica de conexões. Há duas:
– TopicConnectionFactory - para conexões no domínio Topic
– QueueConnectionFactory - para conexões no domínio Queue

126. Fábricas de conexão
● É preciso conhecer o nome JNDI
String nomeJRI = "TopicConnectionFactory"; //default J2EE-RI
String nomeJBoss = "ConnectionFactory"; // JbossMQ
Context ctx = new InitialContext();
TopicConnectionFactory factory =
(TopicConnectionFactory) ctx.lookup(nomeJBoss);

127. Conexões
● Encapsulam uma conexão virtual com o
provedor JMS
– Suportam multiplas sessões (threads)
● Uma vez obtida uma fábrica de conexões,
pode-se obter uma conexão
QueueConnection queueCon =
queueConnectionFactory.createQueueConnection();
TopicConnection topicCon =
topicConnectionFactory.createTopicConnection();

128. Sessões
● Contexto onde se produz e se consome
mensagens
– Criam produtores, consumidores e mensagens
– Processam a execução de ouvintes
– Single-threaded
– Podem ser configuradas para definir: forma de
acknowledgement ,uso ou não de transações
TopicSession topicSession =
topicCon.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
QueueSession queueSession = queueCon.createQueueSession(true, 0);

129. Produtores de mensagens
● Objeto criado pela sessão e usado para enviar mensagens para
um destino
– QueueSender: domínio ponto-a-ponto
– TopicPublisher: domínio pub/sub
QueueSender sender = queueSession.createSender(fila);
TopicPublisher publisher = topicSession.createPublisher(canal);
● Uma vez criado o produtor, ele pode ser usado para enviar mensagens
sender.send( message ); publisher.publish( message );

130. Consumidores de mensagens
● Objeto criado pela sessão e usado para receber mensagens
– QueueReceiver: domínio ponto-a-ponto
– TopicSubscriber: domínio pub/sub
QueueReceiver receiver = queueSession.createReceiver(fila);
TopicSubscriber subscriber = topicSession.createSubscriber(canal);
● Depois, pode consumir mensagens de forma síncrona (método é o
mesmo para domínios PTP e pub/sub
Message queueMsg = receiver.receive();
Message topicMsg = subscriber.receive(1000);
● Para consumir mensagens de forma assíncrona é preciso criar um
MessageListener

131. MessageListener
● Event handler que detecta o recebimento de mensagens
● Para usar, implemente MessageListener e seu método
onMessage():
● Método onMessage() não deve deixar escapar exceções (entre try-
catch)
public class MyListener implements MessageListener {
public void onMessage(Message msg) {
TextMessage txtMsg = (TextMessage) msg;
System.out.println( "Mensagem recebida: " +
txtMsg.getText() )
}
}

132. MessageListener
● Para que objeto seja notificado, é preciso
registrá-lo em um QueueReceiver ou
TopicSubscriber
subscriber.setMessageListener( new MyListener() );

133. Seis tipos de mensagens
● Message - Mensagem genérica sem corpo (contendo apenas
cabeçalho e possíveis propriedades)
● TextMessage - Objeto do tipo String (ex: conteúdo XML)
● MapMessage - Conjunto de pares nome/valor onde nomes são
Strings e valores são tipos primitivos
● BytesMessage - Stream de bytes não interpretados
● StreamMessage - Seqüência de tipos primitivos Java
● ObjectMessage - Objeto Java serializado

134. Criação de Mensagem
● Para cada tipo de mensagem, Session fornece método create():
createMessage(), createTextMessage(), createBytesMessage(),
createObjectMessage(), createMapMessage(),
createStreamMessage()
TextMessage message = queueSession.createTextMessage();
message.setText(msg_text); // msg_text é String
sender.send(message);
● Após receber uma mensagem, via receive() ou onMessage(), é preciso
fazer o cast para ter acesso aos métodos específicos de cada tipo de
mensagem
Message m = receiver.receive();
if (m instanceof TextMessage) {
TextMessage message = (TextMessage) m;
System.out.println("Recebido: " + message.getText());
}

135. JAAS

136. Assuntos
● API do JAAS
● Conceito de autenticação e autorização
● O Login Module
● Exemplo
● O JAAS no Servidor de aplicação
● Login Module do fornecedor
● Escrevendo seu Login Module.

137. JAAS
● Java Authentication and Authorization Service
● Implementação Java do PAM (Pluggable Authentication Module)

138. Arquitetura do JAAS

139. APIS do JAAS
● Classes Comuns
– Subject, Principal, Credential
● Classes e interfaces de autenticação
– LoginContext, LoginModule, CallbackHandler,
Callback
● Classes de autorização (J2SE)
– Policy, AuthPermission, PrivateCredentialPermission

140. Subject
● Para autorizar acesso a um recurso, as aplicações primeiramente
devem identificar a origem da requisição
● O termo Subject representa a origem da requisição
● Um Subject pode ser uma pessoa ou serviço
● Uma vez que o Subject autenticado é populado com vários
Principals e(ou) Credentials
● Um Subject pode ter vários principals: RG 1234 CPF 111,111,111-
11

141. Principals
● Principals são associados a um Subject quando são autenticados
com sucesso.
● Representam a identidade do Subject
● Devem implementar as interfaces:
– java.security.Principal and java.io.Serializable

142. Credentials
● São atributos de segurança que são plugáveis ao Subject
● Qualquer classe Java pode ser usada como uma Credential
● Exemplo: Senha, Certificado Digital, etc

143. Classes de Autênticação
● LoginContext
● LoginModule
● CallBack
● CallBackHandler

144. LoginContext
● Contexto (Senha do cartão e senha do
bankline)
● Consulta uma configuração para determinar
quais LoginsModules serão usados
● Obrigatoriamente precisa de um nome
● Cada LoginModule pode ser:
– Required, Requisite, Sufficient ou Optional

145. LoginModule
● É a interface (contrato) que dá ao desenvolvedor a possibilidade
de implementar diferentes mecanismos de autenticação
● O CallbackHandler é informado no initialize e deve ser chamado
para pegar os usuários e senha
Callback[] callbacks = new Callback[2];
callbacks[0] = new NameCallback("Login");
callbacks[1] = new PasswordCallback("Senha", false);
callbackHandler.handle(callbacks);
loginInformado = ((NameCallback) callbacks[0]).getName();
char[] tmpPassword = ((PasswordCallback) callbacks[1]).getPassword();

146. LoginModule
● Ciclo de Vida
– void initialize(Subject subject, CallbackHandler callbackHandler, Map
sharedState, Map options)
– boolean login() - Fase 1
– boolean commit() ou boolean abort() - Fase 2
– boolean logout

147. CallbackHandler
● Classe Responsável por receber os CallBacks e processa-los
● É quem faz a comunicação com o Usuário
● Não precisa ser criado em aplicações corporativos pois será usado
o CallBackHandler do servidor

148. Callback
● A Interface Callback possui várias implementações
● Cada implementação é responsável por obter uma informação
específica
● Algumas Implementações:
– ChoiceCallback
– ConfirmationCallback
– LanguageCallback
– NameCallback
– PasswordCallback
String loginInformado = ((NameCallback) callbacks[0]).getName();
char[] tmpPassword = ((PasswordCallback) callbacks[1]).getPassword();

149. Revendo Arquitetura do JAAS

150. Classes de Autorização
● As classes de autorização não serão vistas
● Autorização em ambiente corporativo deve
ser feito pelo Container

151. Pegando Autenticação na WEB

152. Formulário de Autenticação
<html>
<head>
<title>Jaas - Testes</title>
</head>
<body>
<center><h2>Jaas Login</h2></center>
<br />
Por favor, entre com sua senha
<br />
<form method="POST" action="j_security_check">
Usuário: <input type="text" name="j_username"/>
<br />
Senha: <input type="password" name="j_password"/>
<br />
<input type="submit" value="Entrar"/>
</form>
</body>
</html>

153. Resgatando informações do JAAS
HttpServletRequest.getUserPrincipal(); // retorna o User
HttpServletRequest.isUserInRole("ADM");
// retorna se o usuario possui a role informada
User user = (User) HttpServletRequest.getUserPrincipal();
user.getRoles(); // roles do usuario

154. JCA

155. Assuntos
● EAI
● Resource Adapter Overview
● Contratos
● Interfaces
● Ciclo de Vida
● Deployment descriptor
● Código de exemplo

156. EIS
● Enterprise Information Systems (EIS)
● Informações espalhadas em Banco de Dados,
ERPs, Mainframe, etc
● Mesmo assim a integração é cada vez mais
necessária
● Cada produto possui conectividade
diferenciada
● O que fazer ?

157. JCA
● J2EE Connector Architecture (JCA) define
uma arquitetura padrão para conectar
aplicações J2EE a sistemas heterogêneos
● Esta arquitetura pode ser usada para criar
Resource Adapters (Adaptadore de Recursos)
– Componentes J2EE que implementam JCA
para EIS específico.

158. O que são Resource Adapters ?
● Camada de conexão entre aplicações
corporativas ou servidores de aplicação e o
EIS
● Pode ser considerado um “Driver” a nível de
sistema para se conectar a um EIS
● Específico para um EIS
● Também chamado de Connector

159. Exemplos de Resource Adapters
● Um driver JDBC que se conecta a um Banco
de Dados
● Um Resource Adapter que se conecta a um
ERP
● Um Resource Adapter que se conecta a um
sistema de processamento de transações
● Um Resource Adapter que se conecta a um
Mainframe

160. Contratos JCA
● Contrato entre o cliente e o Resource Adapter
● Contratos de Sistema
– Pool de Conexões
– Transação
– Segurança
● Contratos de sistemas são gerenciados pelo
Servidor J2EE

161. Contratos de Sistema

162. Interfaces JCA
● ConnectionFactory: Repositório de conexões.
Implementado pelo resource adapter.
● ConnectionManager: Implementado pelo
servidor de aplicações para gerenciar as
conexões.
● ManagedConnectionFactory: Implementado
pelo resource adapter e usado para decidir a
conexão mais apropriada ao cliente.
● Connection: Implementado pelo resource
adapter, esta é a interface de acesso ao EIS.

163. Ciclo de vida do JCA
● Cliente faz lookup de um CF via JNDI
● Cliente chama método getConnection no CF
● CF repassa a requisição para o CM
● CM repassa a requisição para o MCF
● MCF verifica as conexões existentes no pool
(qual atende o cliente ?)
● Se não existe, uma nova conexão é criada e
colocada no pool.
● MCF retorna a conexão via CF

164. Ciclo de Vida do JCA

165. ● ra.xml Deployment descriptor
● Informações genéricas do adaptador
– Nome
– Tipo do EIS
– Nome do Fabricante
● Detalhes do ConnectionFactory
– Interface do ConnectionFactory
– Implementação do ConnectionFactory
– Interface da Connection
– Implementação da Connection
● Propriedades de Configuração
– Nome
– Tipo
– Valor
● Informações de Autenticação

166. Exemplo de código JCA
//ConnectionFactory interface javax.sql.DataSource;
//Connection Interface java.sql.Connection
Context ic = new InitialContext();
javax.sql.DataSource ds =
(javax.resource.DataSource)ic.lookup("myconnfact");
java.sql.Connection con = ds.getConnection();
con.doSomething();
//Finalmente fecha a conexão (volta para o pool)
con.close();

167. Exemplo para “meu” JCA
//ConnectionFactory interface com.digitel.SomeConnectionFactory;
//Connection Interface com.digitel.MyConnection
com.digitel.SomeConnectionFactory cf = (com.digitel.SomeConnectionFactory)
ic.lookup("myconnfact");
com.digitel.MyConnection myCon = cf.getConnection();
//Use o objeto Connection para acessar dados usando a API da interface Connection
myCon.doSomething();
//Finalmente feche a conexão (retorna para o pool)

168. JTA

169. Assuntos
● Transação
● Transação distribuída (XA)
● BMT, CMT e UserTransaction
● Políticas para transações CMT
● Destino de uma Transação
● Níveis de isolamento

170. Motivação para o uso de transações
● Operações Atômicas.
– Exemplo: aplicação bancária.
● Falha na rede.
● Acesso/modificação concorrente de dados.

171. Benefícios do uso de transações
● Uma transação é um conjunto de operações que executam de
forma atômica.
● Uma transação garante que todas as operações serão realizadas
ou que nenhuma delas será realizada.
● Propriedades ACID
– Atomicidade
– Consistência
– Isolamento
– Durabilidade

172. Transações são Ácidas!!!
● ACID - características essenciais : Atômica, Consistente, Isolada e Durável
● Atômica
– Garante que todas as operações sejam tratadas como uma unica
unidade de trabalho. Todas as tarefas de uma unidade transacional
devem funcionar sem erros ou todo o processo é revertido.
● Consistente
– O estado do sistema após uma transação deve manter-se consistente
(transações devem englobar processos de negócio completos)
● Isolada
– Transação deve poder executar sem interferência de outros
processos. Isto é possível utilizando sincronização.
● Durável
– Dados alterados durante a transações devem ser guardados em meio
persistente até que a transação complete com sucesso

173. Modelos Transacionais
● Flat Transactions
● Nested Transactions

174. Flat Transactions
● Modelo commit/rollback.

175. Nested Transactions
● Transações aninhadas podem ser vistas como uma árvore,
permitindo inserir grupos de operações atômicas dentro de
outros grupos.

176. Transações distribuídas
● Problema: e se conta1 e conta2 pertencerem a 2 bancos
diferentes?
● Solução: transações distribuídas
– transação T1 no BD do banco1 para sacar conta1
– transação T2 no BD do banco2 para depositar conta2
– coordenador de transações
●garante que ambas falham ou ambas sucedem
● Ou ainda:
– 1 transação global (TG)
– 2 transações locais (TL1 e TL2)

177. JTA
● Abreviação para Java Transaction API
● Especificação de Interfaces para o sistema de
transação
● Permite demarcar transações independente
da implementação do coordenador de
transação
● É controlada obrigatoriamente pelo Servidor
de aplicações
● Não suporta Nested Transactions

178. Usando o JTA
● Quem pode usar o JTA?
– Código cliente
– EJB (de duas maneiras)
● Declarativa
● Programática
● Exceto pela forma declarativa, a única
interface conhecida é:
– javax.transaction.UserTransaction

179. Interface UserTransaction
Método Descrição
Inicia uma nova transação, que se associa ao thread
begin() atual.
Executa o protocolo de confirmação de duas fases em
uma transação existente associada ao thread atual.
commit() Cada gerenciador de recursos tornará suas
atualizações duráveis
Recupera o status de transação associada a esse
getStatus() thread
Força uma reversão da transação associada ao thread
Rollback() atual
Chame-o para forçar a transação atual a reverter. Por
setRollbackOnly() fim, forçará a transação a abortar.
O tempo limite da transação é o tempo máximo que
uma transação pode executar antes de seu aborto.
setTransactionTimeout (int) Isso é útil para evitar situações de impasse, em que
recursos preciosos são retidos por uma transação que
está sendo executada atualmente.

180. JTA com EJB - BMT
● Bean Managed Transaction
● A API JTA é utilizada no controle
programático das transações.
– Inicia transação em um Bean.
– Chama outro Bean também envolvido em
transações.
– Controla commits e rollbacks.

181. Transações no EJB
public void withdrawCash(double amount) {
UserTransaction ut = sessionCtx.getUserTransaction();
try {
double mbState = machineBalance;
ut.begin();
machineBalance -= amount;
insertMachine(machineBalance);
ut.commit();
} catch (Exception ex) {
try {
ut.rollback();
} catch (SystemException syex) {
throw new EJBException
("Rollback failed: " + syex.getMessage());
}
throw new EJBException
("Transaction failed: " + ex.getMessage());
}
}

182. Transações iniciadas pelo Cliente
● O cliente pode iniciar transações usando as APIs JDBC e JMS
● Cliente pode ser standalone, servlet, outro bean (não EJB), etc.
● É necessário obter uma instância da classe UserTransaction
através de JNDI
● O container deve disponibilizar o JTA na localidade
java:comp/UserTransaction
Context ctx = new InitialContext();
UserTransaction ut = (javax.transaction.UserTransaction)
ctx.lookup("java:comp/UserTransaction");
ut.begin();
// realizar operações
ut.commit();

183. Transações declarativas - CMT
● Container Managed Transaction
● Controle de transações totalmente gerenciado pelo container
● Não permite o uso de métodos commit() e rollback() de
java.sql.Connection ou javax.jms.Session dentro do código
● No deployment descriptor, especifique o uso de CMT
<transaction-type>Container</transaction-type>

184. Propagação de transação
● Facilmente resolvida com BMT
● E no CMT ?

185. Políticas Transacionais
● Define como a transação irá reagir quando o
seu método for chamado por um cliente
dentro ou fora do contexto de uma transação
● Os valores suportados para este elemento:
– NotSupported
– Supports
– Required
– RequiresNew
– Mandatory
– Never

186. Required
● Indica que o método tem que ser chamado
dentro do escopo de uma transação

187. Supports
● Indica que o método suporta transações

188. RequiresNew
● Indica que uma nova transação, iniciada no
escopo do bean, é sempre criada

189. NotSupported
● Indica que o método não suporta transações

190. Mandatory
● Indica que o método só pode ser chamado no
escopo de uma transação do cliente

191. Never
● Indica que o método nunca pode ser
chamado no escopo de uma transação
– Se o cliente que chama o método for parte de
uma transação, o bean irá provocar um
RemoteException (ou EJBException em clientes
locais)

192. Destino de uma transação
● Apenas exceções do sistema (Runtime, Remote, EJBException)
provocam automaticamente o rollback de uma transação
– O container não tem como adivinhar que outras exceções
sejam graves o suficiente para causar rollback
● Pode-se condenar (doom) uma transação CMT usando o método
setRollbackOnly()
– O método aciona uma flag usado pelo container para monitorar
o estado de uma transação
– Pode-se saber o estado de uma transação usando
getRollbackOnly()

193. Qual estilo de demarcação usar?
● Vantagens da demarcação explícita (BMT)
– Maior controle: é possível extrapolar os limites dos métodos (em
Stateful Session Beans) ou agrupar conjuntos de instruções menores
no interior dos métodos
● Vantagens da demarcação implícita (CMT)
– Muito mais simples
– Mais seguro: evita a introdução de código que pode provocar deadlock
e outros problemas similares
– Controle fica com o bean assembler / deployer
– Mais eficiente: container gerencia melhor os recursos
● Transações iniciadas pelo cliente
– Vantagem: controle em relação a falhas de rede
– Desvantagem: transação muito longa - ineficiente

194. Problemas de falta de isolamento
● Dirty read
– É o mais grave dos problemas de isolamento. Ocorre quanto
uma transação lê valores não cometidos, gravados no banco
por uma transação que ainda não terminou. Se a primeira
transação falhar, a segunda estará com dados incorretos.
● Unrepeatable read
– Ocorre quando duas leituras consecutivas do mesmo registro
retorna valores diferentes, devido à alteração de dados por
outra transação.
● Phantom read
– Ocorre quando duas leituras consecutivas da mesma tabela
retorna valores diferentes, devido à inserção de dados por
outra transação.

195. Niveis de isolamento
● Read Uncommitted:
– Não oferece garantia de isolamento (aceita dirty
reads - cliente pode ler dados ainda não
cometidos) mas oferece a maior performance.
● Read Committed
– Resolve o os dirty reads mas não garante que
leituras consecutivas retornem os mesmos
resultados (aceita unrepeatable reads)

196. Níveis de isolamento
● Repeatable Read
– Bloqueia o acesso aos dados utilizados durante a
consulta impedindo unrepeatable reads, mas não
impede que novos dados apareçam no banco
durante a operação (aceita phantom reads)
● Serializable
– Bloqueia o acesso concorrente aos dados
(transações ocorrem em série) durante o uso
mas baixa a performance significativamente.

197. Como definir o nível de isolamento
● Use as ferramentas do seu servidor ou banco de dados
– Não há como especificar níveis de isolamento no DD
● No JBoss, o nível de isolamento default pode ser configurado no
arquivo *-ds.xml de cada data source instalada.
– Esse recurso depende de suporte por parte do gerenciador de
banco de dados e a sintaxe varia. Exemplo:
<transaction-isolation>
TRANSACTION_COMMITTED
</transaction-isolation>

198. Hibernate

199. Assuntos
● Conceitos de ORM
● Bootstraping e configuração
● Mapeamento via XML
● Operações da Session
● Queries e HQL
● Criteria

200. Hibernate
 Uma solução não invasiva para persistência de dados em
aplicações Java
 Não é preciso aderir a padrões de design específicos (como em
EJB) para que uma aplicação tenha os benefícios da
persistência
 Torna fácil adicionar persistência a objetos comuns de
aplicações existentes
 Uma das mais completas soluções de ORM
 Open-source

201. ORM
 Object-Relational Mapping
 Mapeamento Objeto-Relacional
 A solução mais bem-sucedida de persistência para objetos
 Tem como objetivo:
 Preservar as vantagens do paradigma relacional (robustez,
maturidade, facilidade de pesquisa, etc.) para a camada de
persistência
 Preservar as vantagens do paradigma orientado a objetos
(reuso, modularidade, herança, polimorfismo, etc.) para a
camada de negócios

202. Banco de Dados relacionais
 Sistemas de gerenciamento de bancos de dados relacionais têm interfaces
de programação baseadas em SQL
 SQL serve como linguagem de definição de dados (DDL) para criar e
alterar esquemas de dados (create table, etc.)
 Também funciona como linguagem de manipulação de dados (DML)
para interagir com os dados (select, insert. etc.)
 Para usar Hibernate eficientemente, SQL é um pré-requisito
 Hibernate gera código SQL e automatiza processos trabalhosos
 Para otimizar e mesmo para compreender bem o funcionamento do
Hibernate é preciso conhecer SQL
 HQL, linguagem de recuperação de dados, assemelha-se a SQL

203. Como funciona o ORM
 Classes são mapeadas em tabelas (schemas)
 Instâncias (objetos) são (automaticamente) mapeados em registros
String codigo
String nome
double saldo
conta correntista saldo
1 Gargantua 1370
instância:Conta
2 Pantagruel 3450
codigo="4"
3 Gargamel 800 nome="Morticia"
saldo=8200
4 Morticia 8200

204. Incompatibilidade do Paradigma
 Há vários pontos onde o modelo relacional é
incompatível com o modelo de objetos
 Granularidade
 Herança e polimorfismo
 Identidade
 Associações
 Navegação em grafos
 Uma boa solução ORM precisa lidar com
esses problemas eficientemente

205. Exemplo simples
 O exemplo abaixo não apresenta problemas de
descasamento de paradigma: é simples
 User: representa o usuário
 BillingDetails: representa detalhes da cobrança

206. Classes e Tabelas
 Neste exemplo, o descasamento entre o paradigma
objeto e relacional não aparece
public class User { public class BillingDetails {
private String userName; private String accountNumber;
private String name; private String accountName;
private String address; private String accountType;
private Set billingDetails; private User user;
// (get/set pairs), etc. ... //methods, get/set pairs...
} }
create table USER (
USERNAME VARCHAR(15) NOT NULL PRIMARY KEY, Foreign key USERNAME
NAME VARCHAR(50) NOT NULL,
realiza o
ADDRESS VARCHAR(100)
) relacionamento
create table BILLING_DETAILS (
ACCOUNT_NUMBER VARCHAR(10) NOT NULL PRIMARY Key,
ACCOUNT_NAME VARCHAR(50) NOT NULL,
ACCOUNT_TYPE VARCHAR(2) NOT NULL,
USERNAME VARCHAR(15) FOREIGN KEY REFERENCES USER
)

207. Hibernate
● Voltando ao hibernate...
● Hello World
 Esta aplicação simples consiste de
 uma classe
 um arquivo de mapeamento
 uma tabela de banco de dados
 O objetivo é armazenar mensagens em um
banco de dados e recuperá-las.
 Usaremos um ambiente standalone

208. O Objeto
package hello;
public class Message {
private Long id;
private String text;
private Message nextMessage;
public String getText() {
return text;
}
public void setText(String text) {
this.text = text;
}
// getters e setters e outros construtores
}

209. Nada mais é que um simples
objeto...
 Possui:
 Identificador da mensagem (id),
 Texto da mensagem (text)
 Referência para próxima mensagem (nextMessage)
 É um POJO
 Plain Old Java Object
Não tem nada a ver com o Hibernate
 Pode ser usado em qualquer aplicação Java.
 Segue as convenções usadas em JavaBeans

210. Arquitetura do Hibernate
• O Hibernate persiste objetos java comuns
(POJO)
• Usa reflexão para acessar as propriedades
persistentes de um objeto
• As classes persistentes são definidades
(descritas) em documentos de mapeamento
• Arquivos XML são usados para descrever
os campos, associações e subclasses
persistentes
• Os Mapeamentos são "compilados" na
inicialização da aplicação

211. Interfaces do Hibernate
 Cinco interfaces fundamentais são usadas em quase qualquer aplicação
 Servem para armazenar, remover, atualizar e recuperar objetos
persistentes e lidar com transações
 Estão listados abaixo na ordem em que (geralmente) são usadas
• Configuration: carrega dados de configuração
• SessionFactory: obtida de uma Configuration; permite criar sessões
de interação com a camada de persistência
• Session: principal objeto usado para ler, gravar, atualizar, etc.
• Transaction: camada sobre sistemas de transações nativo
• Query ou Criteria: realizam pesquisa no modelo de objetos

212. Session
 Principal interface usada em aplicações
Hibernate
 Todas as operações explícitas de persistência são
realizadas através de um objeto Session
 Objeto leve
 Fácil de criar
 Fácil de destruir
 Objetos Session não são threadsafe
 Devem ser usados em uma unica thread
 Para threads adicionais, crie sessions adicionais

213. SessionFactory
 Uma aplicação obtém uma Session a partir de
uma SessionFactory
 Objeto pesado; lento para inicializar e destruir
 Geralmente tem-se uma apenas para toda a
aplicação
 Deve-se ter uma SessionFactory para cada banco
de dados utilizado
 Realiza cache de comandos SQL e dados e
metadados usados em tempo de execução

214. Configuration
 É o ponto de partida para iniciar o Hibernate
 Inicializado com propriedades de configuração
do sistema
 Especifica a localização de dados e arquivos de
mapeamento, objetos, configuração do banco de
dados, pool de conexões, dialeto do SQL do
banco, etc.
 Geralmente obtém a configuração via arquivos
.properties, XML ou propriedades dinâmicas
 Cria a SessionFactory

215. Transaction
 Abstração da implementação de transações
usada no código
 A implementação real pode ser uma transação
JTA, JDBC, etc.
 Essencial para garantir a portabilidade de
aplicação entre diferentes ambientes e
containers
 Encapsula o objeto de transação nativo em
servidores de aplicação ou outros ambientes
controlados

216. Query e Criteria
 Permite a realização de consultas ao banco
 Consultas Query são escritas em HQL (Hibernate Query
Language) ou no SQL nativo do banco.
 Objetos Query são usados para
 Passar parâmetros para a consulta em HQL
 Filtrar resultados
 Executar os comandos da consulta
 Criteria é uma alternativa que faz a mesma coisa usando
métodos da API (em Java, em vez de HQL)
 Uma Query só pode ser usada dentro de sua sessão

217. 3 passos para usar o Hibernate
 1) Primeiro é preciso obter um objeto de sessão Session.
Session session = ...;
 Através desse objeto é possível realizar operações de leitura e
gravação (mais sobre como obtê-lo adiante)
 2) Para gravar, crie um objeto da maneira usual e grave na sessão usando
save()
Message message = new Message();
message.setText(“Hello World!”);
session.save(message);
 3) Para ler todas as mensagens, envie um query via find()
List messages = session.find(“from Message”);

218. HBM - Mapeamento
 As informações sobre o mapeamento entre a tabela e a classe Message ficam em um arquivo
XML
• Guarde-o no mesmo pacote que a classe
• Chame-o de Message.hbm.xml
 No código abaixo, em vermelho as propriedades do objeto, em azul as colunas da tabela
mapeadas
<hibernate-mapping>
<class name="hello.Message" table="MESSAGE">
<id name="id" column="MESSAGE_ID">
<generator class="increment" />
</id>
<property name="text" column="MESSAGE_TEXT" />
<many-to-one name="nextMessage" cascade="all“
column="NEXT_MESSAGE_ID" />
</class>
</hibernate-mapping>

219. Manipulação do Objeto
 Leitura de uma mensagem específica
Message message = (Message) session.load(Message.class, new Long(1));
 Alteração da mensagem acima (sem usar Session)
message.setText("Greetings Earthling");
Message nextMessage =
new Message("Take me to your leader (please)");
message.setNextMessage( nextMessage );
 Leitura de várias mensagens do banco
Session newSession = getSessionFactory().openSession();
List messages = newSession .find("from Message");
System.out.println( messages.size() + " message(s) found:" );
for ( Iterator iter = messages.iterator(); iter.hasNext(); ) {
Message message = (Message) iter.next();
System.out.println( message.getText() );
}
newSession.close();

220. Propriedades
Propriedades para Conexões JDBC
● hibernate.connection.driver_class = org.postgresql.Driver
● hibernate.connection.url = jdbc:postgresql://localhost/mydatabase
● hibernate.connection.username = myuser
● hibernate.connection.password = secret
● hibernate.c3p0.min_size=5
● hibernate.c3p0.max_size=20
● hibernate.c3p0.timeout=1800
● hibernate.c3p0.max_statements=50
● hibernate.dialect = org.hibernate.dialect.PostgreSQLDialect
Propriedades para Datasources JNDI
● hibernate.connection.datasource = java:/comp/env/jdbc/test
● hibernate.transaction.factory_class = org.hibernate.transaction.JTATransactionFactory
● hibernate.transaction.manager_lookup_class = org.hibernate.transaction.JBossTransactionManagerLookup
● hibernate.dialect = org.hibernate.dialect.PostgreSQLDialect

221. Configuração via XML
package util;
import org.hibernate.*;
import org.hibernate.cfg.*;
public class HibernateUtil {
private static final SessionFactory sessionFactory;
static {
try {
// Create the SessionFactory from hibernate.cfg.xml
sessionFactory = new
Configuration().configure().buildSessionFactory();
} catch (Throwable ex) {
System.err.println("Initial SessionFactory creation failed." + ex);
throw new ExceptionInInitializerError(ex);
}
}
public static SessionFactory getSessionFactory() {
return sessionFactory;
}
}

222. Configuração programática
Configuration cfg = new Configuration()
.addClass(org.hibernate.auction.Item.class)
.addClass(org.hibernate.auction.Bid.class)
.setProperty("hibernate.dialect",
"org.hibernate.dialect.MySQLInnoDBDialect")
.setProperty("hibernate.connection.datasource",
"java:comp/env/jdbc/test")
.setProperty("hibernate.order_updates", "true");

223. Persistindo Objetos
Session session =
HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();

224. Operações da Session
DomesticCat cat = (DomesticCat) sess.load( Cat.class, new Long(69) );
cat.setName("PK");
sess.flush(); // Mudanças são automaticamente persistidas
● Objetos persistentes

225. Carregando objetos persistidos
● Via load
long id = 1234;
DomesticCat pk = (DomesticCat) sess.load( DomesticCat.class, new Long(id) );
● Via Query
List cats = session.createQuery(
"from Cat as cat where cat.birthdate < ?")
.setDate(0, date)
.list();
List mothers = session.createQuery(
"select mother from Cat as cat join cat.mother as mother where
cat.name = ?")
.setString(0, name)
.list();

226. Query – Parâmetros
//Parâmetro nomeado (preferido)
Query q = sess.createQuery("from DomesticCat cat where cat.name = :name");
q.setString("name", "Fritz");
//Parâmetro posicional
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
//Lista de parâmetros
List names = new ArrayList();
names.add("Izi");
names.add("Fritz");
String hql = "from DomesticCat cat where cat.name in (:namesList)";
Query q = sess.createQuery(hql);
q.setParameterList("namesList", names);

227. Query - Paginação
String hql = "from DomesticCat cat";
Query q = sess.createQuery(hql);
q.setFirstResult(20);
q.setMaxResults(10);
List cats = q.list();

228. Criteria
Criteria crit = sess.createCriteria(Cat.class);
crit.setMaxResults(50);
List cats = crit.list();
List cats = sess.createCriteria(Cat.class)
.add( Restrictions.like("name", "Fritz%") )
.add( Restrictions.between("weight", minWeight, maxWeight) )
.list();
List cats = sess.createCriteria(Cat.class)
.add( Restrictions.like("name", "Fritz%") )
.add( Restrictions.or(
Restrictions.eq( "age", new Integer(0) ),
Restrictions.isNull("age")
) )
.list();

229. JPA

230. Assuntos
● Anotações
● Facilidades
● Bootstraping J2SE e J2EE
● EntityManager
● JPQL

231. JPA
● JPA (Java Persistence API) é a especificação padrão para o
gerenciamento de persistência e mapeamento objeto relacional,
surgida na plataforma Java EE 5.0
● Introduzida no intuito de substituir os Entity Beans (que foram
descontinuados) e simplificar o desenvolvimento de aplicações
Java EE
● Pode ser usada com Java SE
● Configuração por anotações
● Baseada no Hibernate

232. Provedor JPA
● Existem diversas implementações de diversos
fabricantes
● Oracle Toplink
● Hibernate EntityManager
● Bea Kodo
● Apache JPA

233. Entidade
● Principal conceito do JPA
● É um objeto que pode ser persistido no Banco
de Dados
● Nada mais é que um POJO
● Possui um ciclo de vida gerenciado pelo JPA
● Basta possuir a anotação @Entity, ter um
construtor padrão, e uma chave primária

234. Ciclo de vida da Entidade
● Objetos podem existir sem o Banco de Dados
● Entra em cena o estado do objeto

235. Como é realizado o mapeamento ?
● Anotações são “metadados” das classes
– @Entity
– @Table(“tabela”)
– @Column(“coluna”)
– @Id
– @GeneratedValue
– @Transient
– @NamedQuery
– @Temporal
– @Enumeration

236. Como funciona o EntityManager

237. Criando o EntityManager

238. Exemplo Simples – Criando uma
Entidade
import javax.persistence.*;
@Entity
@Table (name=”aluno”)
public class Aluno {
@Id @GeneratedValue
private int id;
private int matricula;
private String nome;
//Getters e Setters
}

239. Persistence.xml
<persistence>
<persistence-unit name="exemplo" transaction-type="RESOURCE_LOCAL">
<properties>
<property name="hibernate.connection.driver_class"
value="org.hsqldb.jdbcDriver"/>
<property name="hibernate.connection.username"
value="sa"/>
<property name="hibernate.connection.password"
value=""/>
<property name="hibernate.connection.url"
value="jdbc:hsqldb:hsql://localhost"/>
<property name="hibernate.dialect"
value="org.hibernate.dialect.HSQLDialect"/>
</properties>
</persistence-unit>
</persistence>

240. public class Principal { Testando
public static void main(String[] args){
//Cria objeto que gerenciará persistência
EntityManagerFactory fabrica =
Persistence.createEntityManagerFactory("exemplo");
EntityManager em = fabrica.createEntityManager();
try {
EntityTransaction tx = gerenciador.getTransaction();
tx.begin(); //Inicia transação
Aluno a1 = new Aluno();
a1.setNome(“Pedro”);
a1.setMatricula(20009387);
em.persist(a1); //Persiste primeiro aluno
Aluno a2 = new Aluno();
a2.setNome(“Maria Eduarda”);
a2.setMatricula(20052347);
em.persist(a2); //Persiste segundo aluno
tx.commit(); //Finaliza transação
} catch (Exception ex) {
tx.rollback(); //Desfaz operações em caso de erro
} finally {
//Libera recursos
em.close();
fabrica.close();
}
}
}

241. Facilidades com EJB3
● JPA - Sempre é preciso ter uma transação ativa
● EJB é automático (Required)
● EntityManager pode ser injetado via anotação:
@PersistenceContext
@PersistenceContext
EntityManager em;
public void enterOrder(int custID, Order newOrder) {
Customer cust = em.find(Customer.class, custID);
cust.getOrders().add(newOrder);
newOrder.setCustomer(cust);
}

242. Relacionamentos
● @OneToMany
– Pessoa tem vários telefones
– List<Telefone> telefones = new ArrayList<Telefone>()
● @ManyToOne
– Telefone pertence a uma pessoa
– Pessoa pessoa;
● @OneToOne
– Pessoa possui uma Casa
– Casa casa;
● @ManyToMany
– Professor possui várias turmas e vice-versa
– List<Turma> turmas = new ArrayList<Turma>();

243. Queries
● Não existe Criteria – previsto para JPA 2.0
● JPQL – Java Persistence Query Language
● Um único método:
– createQuery(jpql);
● Dois retornos:
– getSingleResult();
– getResultList();

244. Exemplos de Queries
final List<Pessoa> list = em.createQuery("from
Pessoa where p.nome = ?1")
.setParameter(1, "Rafael").getResultList();
final Person pByWhere = (Person) em.createQuery(
"SELECT p from Person p where
firstName='Brett'")
.getSingleResult();

245. Named Query
@Entity
@Table(name = "produto")
@NamedQueries( {
@NamedQuery(
name = "Produto.findByDescricao",
query = "SELECT p FROM Produto p WHERE p.descricao = :descricao"),
@NamedQuery(
name = "Produto.findByPreco",
query = "SELECT p FROM Produto p WHERE p.preco = ?1")
})
public class Produto implements Serializable {
. . . // Implementação da entidade
}
Usando a Named Query:
public List<Produto> findByPreco(final BigDecimal preco) {
return manager.createNamedQuery("Produto.findByPreco").
setParameter(1, preco).getResultList();
}

246. JBoss Application Server

247. Assuntos
● Serviços disponíveis
● Configuração da JVM
● Bind e profiles (minimal, default e all)
● Configuração de Segurança
● Configuração de Logging
● Configuração e-mail
● Deploy, Deployment Scanner e Sorter
● Noções Cluster e Load Balance

248. Por quê usar um servidor de
aplicação?
● Ponto único para execução de aplicações
● Integrar vários serviços server-side
● Ponto único para acesso do cliente
● Aumento de performance para serviços locais

249. O que é um servidor de
aplicações ?
● Servidor de aplicações é uma plataforma de integração
● Age como um mediador na integração da arquitetura
● Facilita o uso de arquitetura de n camadas

250. Arquitetura do Application Server

251. Usos possíveis do Application
Server

252. E o JBoss AS ?
● Servidor certificado como J2EE 1.4
● Promove serviços além da especificação
– Alta Disponibilidade e Cluster
– Framework de segurança
– Integração com Apache (mod_jk)
● É construído usando micro-kernels
– Serviços são componentes individuais que
podem ser plugados (mesmo em tempo de
execução)

253. JBoss microkernel

254. JBoss microkernel
● Por quê esta arquitetura é importante para
administradores ?
– Arquitetura não monolítica
– Configuração segundo a necessidade da
aplicação
– Administração “por serviço” e não “por servidor”
– Maior flexibilidade

255. JBoss e a JVM
● A JVM é o motor do Jboss (Aplicação 100% Java)
● Configuração afeta totalmente o servidor
● Heap Inicial: -Xms256m
● Heap Máxima: -Xmx512m
● Existem parâmetros para:
– Regiões de memória
– Monitoração
– Garbage collector
– Etc
● VM 32bits tem limite de 2GB de ram

256. Usando o JBoss
● Como instalar ?
– Descompactar e usar
● Como executar
– run.sh ou run.bat
● Como parar:
– shutdown.sh ou shutdown.bat

257. Perfis JBoss
● O Jboss vem com 3 perfis:
– Minimal
– Default
– All
● Para escolher entre eles, use o parâmetro “-c”
– ./run.sh -c all

258. JBoss e Servidores corporativos
● Várias interfaces de rede (4 interfaces)
● Muita memória (8GB)
● Mas não é 64bits
● Como aproveitar este hardware ?

259. JBoss e Servidores corporativos
● Várias interfaces de rede (4 interfaces)
● Muita memória (8GB)
● Mas não é 64bits
● Como aproveitar este hardware ?
Usando mais de uma instância por máquina

260. Como usar mais de uma instância ?
● Parâmetro “-b” (bind)
● Combinar com um perfil
– ./run.sh -b 192.168.0.1 -c instancia1
– ./run.sh -b 192.168.0.2 -c instancia2

261. Deploy de aplicações
● Jboss possui Hot-deploy
● Colocar ou tirar arquivo do diretório
– (jboss/server/<perfil>/deploy)
● Quais tipos de arquivos básicos:
– Jar – Java Archive (libs ou ejbs)
– War – Web Archive (aplicações web)
– EAR – Enterprise Archive
– XML – Serviços

262. Analisando minha instância
● Log
– (/jboss/server/<perfil>/logs)
– Pode ser configurado jboss-log4j.xml
● JMX
– Permite todo o monitoramento do servidor
– Recomendável “fechar” o JMX em produção

263. Serviço de deploy
● Possui um microkernel para configuração
● Arquivo jboss-service.xml
● Serviço deployment scanner:
– Diretórios
– Intervalos
– Prefixo de arquivos
– Sufixo de arquivos (Extensões)
● Serviço deployment sorter:
– Default “sar", "service.xml", "rar", "jar", "war", "wsr", "ear", "zip",
"*"
– Prefixo (01..., 02..., A..., B...., n..., Z...)

264. Segurança
● Serviço de segurança integrado com o JAAS
● Cada política usa um LoginModule
● Configurado no arquivo login-config.xml
● É preciso dizer na aplicação qual política usar
(via descritor)

265. Serviço de e-mail
● Arquivo mail-service.xml
● Possui todas configurações típicas de e-mail
– SMTP
– POP
– Autênticação
● Pode ser usado:
– Pelo JavaMail
– Pelo Logging

266. Cluster e Load Balancing
● Cluster != Load Balancing
● Cluster só está disponível no perfil “all”
● Automático
● Nem sempre é a melhor solução!
● Nem sempre é o que queremos!

267. Load Balancing

268. EJB 2.1

269. Assuntos
● Session Beans e EntityBeans
● SB Stateful e Stateless
● EB CMP e BMP
● Message Driven Beans
● Deployment descriptors
● Empacotamento

270. Sistemas Corporativos são
complexos
● Balanceamento de carga.
● Clusterização.
● Recuperação em caso de falhas.
● Implantação dinâmica.
● Invocação remota de métodos.
● Segurança.
● Integração com sistemas legados.
● Gerência de recursos.
● Transações.
● Muitos, muitos outros.

271. Motivação para o padrão EJB
● Aplicações corporativas são naturalmente
distribuídas
– Exemplos: aplicações bancárias, comércio
eletrônico, folha de pagamentos.
● Necessidade de uma infraestrutura comum
Middleware com serviços complexos
Application Servers
● As organizações podem preocupar-se
apenas com a lógica de negócio.

272. Estratégia de Dividir e Conquistar
● Uma aplicação deve ser composta de
componentes.
● Um único componente pode ser reutilizado
em diversas aplicações.
● O mercado de componentes é um mito?
– Ainda falta maturidade.
– Em pouco tempo se tornará realidade.

273. Reutilizando componente para Serviço Postal

274. Reutilizando componente para Revenda de Veículos

275. Reutilizando componente para Comércio Eletrônico

276. Arquiteturas de Componentes
● Importância do uso de interfaces

277. Introdução a Enterprise Java Beans
Características:
● Portabilidade entre servidores de aplicação.
● Desenvolvimento acelerado.
● Padrão de mercado.
– Melhores Práticas
– “Train once, code anywhere”
Atenção! EJB não é apropriado para todos os
cenários.

278. Por que Java?
● Separação entre interface e implementação.
● Segurança.
● Executa em qualquer plataforma.

279. EJB como uma solução de negócio
Solução para problemas relacionados ao
negócio:
– Realiza lógica de negócio
– Acessa bancos de dados
– Acessa sistemas legados
Acesso a componentes EJB:
– Aplicações standalone
– Aplicações Web
– Web Services

280. Papéis no desenvolvimento EJB
● Há seis papéis especializados em cada uma
das etapas do desenvolvimento EJB.
Atenção! A divisão rígida em papéis pode
não ser apropriada para todos os sistemas.

281. JavaBeans X Enterprise JavaBeans

282. J2EE Big picture

283. EJBS
● Componentes que executam no lado
servidor.
● Seguem uma especificação.
● Servlets, applets ou mesmo outros Beans
podem ser clientes de um EJB.
– Exemplo: compra de um CD em uma loja.

284. Tipos de Beans
● Session Beans
– “Verbos”. Modelam processos de negócio, como
autorização de cartão de crédito, engine de
cálculo de preços, etc.
● Entity Beans
– “Substantivos”. Modelam dados como produto,
pedido, empregado.
● Message Driven Beans
– São semelhantes aos Session Beans,
entretanto são invocados apenas por meio de
mensagens.

285. Objetos Distribuídos: Base para EJB
● Componentes EJB são baseados em objetos
distribuídos.

286. Objetos Distribuídos e Middleware
● Middleware Explícito.

287. Objetos Distribuídos e Middleware
Transferir (Conta conta1, Conta conta2, long quantidade)
{
//1: chamar API para realizar verificação de segurança;
//2: chamar API para iniciar transação
//3: chamar API para carregar dados do banco de dados
//4: subtrair o saldo de uma conta e adicionar valor à outra
//5: chamar API para armazenar dados modificados no banco de dados
//6: chamar API para finalizar a transação
}
● Desvantagens:
– Difíceis de escrever.
– Difíceis de manter.

288. Objetos Distribuídos e Middleware
Transferir (Conta conta1, Conta conta2, long quantidade)
{
//1: subtrair o saldo de uma conta e adicionar valor à outra
}
● Vantagens:
– Fácil de escrever.
● Contém apenas lógica
de negócio
– Fácil de manter.
● Sintaxe declarativa

289. Objetos Distribuídos e Middleware
Middleware Explícito
+
Middleware Implícito
EJB

290. Que constitui um Enterprise Bean?
● 1 - Enterprise Bean Class.
– Contém lógica, a implementação propriamente dita.
– Todas as classes de implementação (session, entity ou
message-driven) devem implementar a interface
javax.ejb.EnterpriseBean.
public interface javax.ejb.EnterpriseBean extends
java.io.Serializable
{
}

291. EJB Object
● Um cliente NUNCA invoca os métodos de
um Bean diretamente.
● Um EJBObject intercepta as chamadas e as
delega para a instância do Bean.
● O EJBObject fornece serviços para a
gerência de transações, segurança,
persistência, gerência de recursos e outros.

292. Que constitui um Enterprise Bean?
● 2 – Interface Remota
– Especifica métodos de negócio.
– Estende de javax.ejb.EJBObject.
public interface javax.ejb.EJBObject extends java.rmi.Remote
{
public javax.ejb.EJBHome getEJBHome() throws java.rmi.RemoteException;
public java.lang.Object getPrimaryKey() throws java.rmi.RemoteException;
public void remove() throws java.rmi.RemoteException,
javax.ejb.RemoveException;
public javax.ejb.Handle getHandle() throws java.rmi.RemoteException;
public boolean isIdentical() throws java.rmi.RemoteException;
}

293. EJB Home Object
● Como os clientes obtêm referências para os EJBObjects?
● EJBHome funciona como uma fábrica.
● Responsabilidade:
– Criar objetos EJB.
– Encontrar objetos existentes (no caso de Entity Beans).
– Remover objetos EJB.

294. Que constitui um Enterprise Bean?
● 3 – Interface Home
– Define métodos para criação, remoção e pesquisa de
EJBObjects.
– Estende de javax.ejb.EJBHome
public interface javax.ejb.EJBHome extends java.rmi.Remote
{
public EJBMetaData getEJBMetaData() throws java.rmi.RemoteException;
public javax.ejb.HomeHandle getHomeHandle() throws java.rmi.RemoteException;
public void remove() throws java.rmi.RemoteException, javax.ejb.RemoveException;
public void remove(Object chavePrimaria) throws java.rmi.RemoteException,
javax.ejb.RemoveException;
}

295. Que constitui um Enterprise Bean?
● As interfaces Home e Remote não oferecem bom desempenho,
pois as chamadas são feitas via RMI.

296. Que constitui um Enterprise Bean?
● 4 – Interfaces Locais
– A partir da especificação 2.0 pode-se chamar os
LocalObjects ao invés dos EJBObjects.
– As interfaces locais são opcionais.
– As interfaces locais (home e remote) são similares às suas
correspondenes não-locais.
– São utilizadas nas chamadas entre Beans em um mesmo
Application Server.

297. Interfaces Locais
● A interface local estende de javax.ejb.EJBLocalObject e a Home
local estende de javax.ejb.EJBLocalHome.
public interface javax.ejb.EJBLocalObject {
public javax.ejb.EJBLocalHome getEJBLocalHome() throws javax.ejb.EJBException;
public java.lang.Object getPrimaryKey() throws javax.ejb.EJBException;
public boolean isIdentical(javax.ejb.EJBLocalObject obj) throws javax.ejb.EJBException;
public void remove() throws java.rmi.EJBException, javax.ejb.RemoveException;
}
public interface javax.ejb.EJBLocalHome {
public void remove(Object obj) throws java.rmi.EJBException, javax.ejb.RemoveException;
}

298. Que constitui um Enterprise Bean?
● 5 – Deployment Descriptors
– São arquivos XML, onde o Bean Provider especifica,
declarativamente, requisitos como:
● Persistência
● Ciclo de vida e gerência do Bean
● Segurança
● Transação
● 6 - Arquivos de Configuração Proprietários
– Cada servidor EJB tem seus próprios arquivos de
configuração.

299. EJB-JAR – Putting All Together
● O arquivo EJB-JAR empacota todos os
elementos de um Enterprise Bean.
● Arquivo comprimido no padrão .zip.
● Há diversas ferramentas para gerar os
arquivos EJB-JAR automaticamente.

300. Criando arquivo EJB-JAR

301. Interface Remota (OlaMundo.java)
● Código da Interface Remota do Primeiro Bean :
package digitel;
import java.rmi.RemoteException;
import javax.ejb.EJBObject;
/** Interface Remota do Bean */
public interface OlaMundo extends EJBObject
{
/** Obtém String com mensagem de teste. */
public String olaMundo() throws RemoteException;
}

302. Interface Local (OlaMundoLocal.java)
● Um cliente local pode utilizar a interface local ao invés da remota.
Há poucas diferenças entre as interfaces local e remota.
package digitel;
import javax.ejb.EJBLocalObject;
/** Interface Remota do Bean */
public interface OlaMundo extends EJBLocalObject
{
/** Obtém String com mensagem de teste. */
public String olaMundo();
}

303. Interface Home (OlaMundoHome.java)
● A interface Home tem métodos para criar e remover Beans.
package digitel;
/** Interface Home do Bean OlaMundo */
public interface OlaMundoHome extends javax.ejb.EJBHome
{
/** Cria o EJBObject para o Bean OlaMundo. */
OlaMundo create() throws java.rmi.RemoteException,
javax.ejb.CreateException;
}

304. Interface LocalHome (OlaMundoLocalHome.java)
● A interface LocalHome é usada por cliente locais e tem melhor
desempenho.
package digitel;
/** Interface Home local do Bean OlaMundo */
public interface OlaMundoLocalHome extends javax.ejb.EJBLocalHo
{
/** Cria o EJBObject para o Bean OlaMundo. */
OlaMundoLocal create() throws javax.ejb.CreateException;
}

305. Bean Class (OlaMundoBean.java)
● Implementa a interface javax.ejb.SessionBean
– A interface define métodos que devem ser implementados,
chamados de métodos de callback, usados pelo container para
notificar o ocorrência de eventos importantes.
● Possui um método ejbCreate() que corresponde ao método
create() da interface Home.
● Temos um único método de negócio, o método olaMundo().

306. Bean Class (OlaMundoBean.java)
package digitel;
import java.rmi.RemoteException;
import javax.ejb.*;
public class OlaMundoBean implements SessionBean {
public void setSessionContext(SessionContext ctx) {}
public void ejbRemove() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void ejbCreate() {
System.out.println("metodo ejbCreate() chamado!");
}
public String olaMundo() {
System.out.println("metodo olaMundo() chamado!");
return "Ola Mundo!";
}
}

307. deployment descriptor
<!DOCTYPE ejb-jar PUBLIC "
http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>OlaMundo</ejb-name>
<home>digitel.OlaMundoHome</home>
<remote>digitel.OlaMundo</remote>
<local-home>digitel.OlaMundoLocalHome</local-home>
<local>digitel.OlaMundoLocal</local>
<ejb-class>digitel.OlaMundoBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>

308. Como chamar um Enterprise Bean?
Um cliente EJB tipicamente realiza as seguintes tarefas:
• Busca-se o objeto Home (usaremos JNDI).
• O objeto Home é usado para criar um EJBObject.
• São efetuadas chamadas aos métodos de negócio do Bean.
• O objeto EJB é removido.

309. Código Cliente
(OlaMundoCliente.java)
package cap03;
import javax.naming.*;
import javax.rmi.PortableRemoteObject;
public class OlaMundoCliente
{
public static void main(String[] args) throws Exception
{
Context ctx = new InitialContext(System.getProperties());
Object obj = ctx.lookup("OlaMundo");
OlaMundoHome home = (OlaMundoHome) PortableRemoteObject.narrow
(obj, OlaMundoHome.class);
OlaMundo olaMundo = home.create();
System.out.print(olaMundo.olaMundo());
olaMundo.remove();
}
}

310. O que são Entity Beans
● São componentes persistentes que modelam
dados.
● Sabem como recuperar seus dados do
mecanismo de armazenamento e como fazer
o papel inverso.
● Exemplos: conta bancária, pedidos de uma
loja, informações de um cliente.

311. Características dos Entity Beans
● Sobrevivem a falhas.
● Representam uma visão do banco de dados. Os objetos em
memória e no banco de dados devem ser vistos como um único
EJB.
– Métodos ejbLoad e ejbStore.
– Os desenvolvedores não precisam se preocupar com a
sincronização de objetos no banco de dados.
● Vários Beans podem representar o mesmo dado.
– Maior performance.

312. Tipos de Entity Beans
● Bean-Managed Persistence
– O próprio bean mantém a inteligência relacionada
à persistência.
● Container-Managed Persistence:
– O Container é responsável pela persistência.

313. Criação e Remoção de Beans
● O método ejbCreate é responsável por criar o
dado no banco
public ContaPK ejbCreate (String idConta, String dono) ...
public Conta create (String idconta, String dono) ...
● O método ejbRemove é responsável por
remover os dados do banco.
– O cliente pode usar o remove() tanto a partir do
EJBObject quando da objeto Home.

314. Características dos Entity Beans
● Entity Beans podem ser localizados
– Métodos finder.
● Os dados dos Entity Beans podem ser
modificados sem utilizar EJB.

315. Que é um Message-Driven Beans ?
● Um Message-Driven Bean (MDB) é um componente EJB especial
que recebe mensagens JMS.
– Não podem ser acessados via interfaces, apenas por
mensagens.

316. Características dos Message-Driven
Beans
● MDBs não possuem interfaces (home, local, localHome e remote).
● MDBs têm um único método de negócio (onMessage()).
● MDBs não retornam valores nem tampouco lançam exceções aos
clientes.
● São stateless e podem ser duráveis ou não duráveis.

317. Desenvolvendo Message-Driven
Beans
Todo MDB deve implementar duas interfaces:
● javax.jms.MessageListener
public interface javax.jms.MessageListener
{
public void onMessage(Message mensagem)
}
● javax.ejb.MessageDrivenBean
public interface javax.ejb.MessageDrivenBean
{
public void ejbRemove() throws EJBException;
public void
setMessageDrivenContext(MessageDrivenContext
ctx) throws EJBException;
}

318. EJB 3

319. Assuntos
● Facilidades
● Anotações
● Session Beans
● SB Stateful e Stateless
● Sai deployment descriptor (opcional), Sai
interface home, sai Entity Bean

320. EJB3
Uma verdadeira revolução
● Princípio Pareto
– “80% das consequências advém de 20% das
causas” Vilfredo Pareto

321. Como era feito o EJB 2.1 ?
● Bem simples (risos...)
● Crie duas interfaces de Acesso, uma estende EJBObject outra
EJBLocalObject
● Crie duas interfaces para criar as interfaces acimas, uma extende
EJBHome outra estende EJBLocalHome
● Crie uma classe que implemente SessionBean, e deixe um monte
de métodos em branco
● Finalmente, crie um arquivo XML que pode se tornar do tamanho
do velho testamento

322. Como se sentia o desenvolvedor
J2EE

323. Problemas da arquitetura antiga
● Desenvolvedor perdia muito tempo em
artefatos, deixando o negócio de lado
● Imposição de uma hierarquia de classes
● Problemas graves de OO, não era comum o
● uso de um contrato forte
● Cliente tinha que lidar com criação de stubs
● e lookups
● Geração de anti-patterns para correção
deproblemas

324. Problemas (...)
● Problema do princípio do
consultor :“Complexidade é uma virtude que
nunca devemos considerar como pouca”
● Por quê ejbPassivate em um Stateless
SessionBean?
● Complexidade na hora de testar suas classes
de negócio
● Necessidade de se lidar com Exceções
desnecessárias

325. EJB3: A revolução
● Princípio de “configuration by exception”
● Totalmente orientado a Pojos, “qualquer”
classe pode ser um EJB
● Em 80% dos casos, ejb-jar.xml não é
necessário
● Adeus Home interface, adeus EJBObject,
adeus RemoteException
● Uso de anotações para definir aspectos do
bean

326. Eliminação do Home
● A primeira grande revolução é a eliminação
do objeto Home
● O desenvolvedor agora precisa apenas
anotar sua classe como sendo @Remote,
@Local ou ambos
● A interface de negócio não pode lançar
RemoteExceptions

327. Eliminação do EJBObject
● EJBObject existiam para permitir que o
container notificasse a classe “alvo” de alguns
eventos (aka callback)
● O problema é simples: E se o bean não quiser
ser notificado?
● Como as classes são anotadas, não é
maisnecessário o uso deste tipo de objeto

328. Desenvolvimento orientado a Pojos
● Qualquer classe pode ser um bean
● Uso de anotações:
– @Stateless
– @Statefull
– @Remote,@Local
– @MessageDriven
– @PreCreate,@PostCreate,@PrePassivate,@Destroy
– @Interceptors
– @AroundInvoke

329. Stateless Session Beans
● Bean sem estado de conversação, cada
chamada é tratada como um novo cliente
● Provê alta disponibilidade de acesso, uma vez
que ficam armazenado em um Pool
● Qualquer classe pode ser um SLSB bastando
apenas uma anotação @Stateless

330. Stateful Session Beans
● Retêm estado da conversação
● Existe um para cada cliente
● Container realiza um swap em disco do SFSB
quando o número de SFSBs ultrapassa um
determinado valor
● Qualquer classe pode ser um SFSB,
bastando apenas uma anotação do tipo
@Stateful

331. Interfaces Remotas/Locais
● Embora a interface Home tenha sido
removida, as interfaces que definem o
contrato do bean, ainda devem ser criadas.
● São declaradas através de @Remote e
@Local
● O desenvolvedor pode utilizar ambas caso
necessário

332. Métodos de Callback
● SFSB permitem que o desenvolvedor interaja
com o container através de métodos de
callback
● Estes métodos são utilizados para controlar o
ciclo de vida do bean.
– Criação do bean
– Ativação
– Passivação
– Remoção
– Atribuição do SessionContext

333. Métodos de CallBack
● Na versão 2.1 tinham nomes assustadores
como ejbPassivate, ejbActivate.
● A nova especificação, o programador define o
nome do método como lhe convir, e utiliza de
anotações para demarcar o método:
– @PrePassivate
– @PostActivate
– @PostConstruct
– @PreDestroy
– @Init

334. Classes de Callback
(Interceptadores)
● É possível separar os métodos de callback de
um bean de sua classe de implementação
● Isso torna sua classe de negócio mais
orientada a negócio
● É permitido o uso de várias classes de
callbacks
● Definidas através de @Interceptors({})

335. Definindo contexto de seu bean
● No EJB 2.x éramos obrigados a usar um
método public void setSessionContext
● Agora basta utilizarmos uma anotação
@Resource sobre nossa variável de
sessionContext
● Simples, rápido e intuitivo

336. Injeção de EJBs e Recursos
● O acesso a recursos externos (DataSources, ConnectionFactories)
é feito pela anotação @Resource
● Alguns recursos como SessionContext, MessageDrivenContext,
não necessitam de nenhum parâmetro para serem acessados
● Para injetar EJBs basta usar a anotação @EJB na variável
● O PersistenceContext possui uma anotação prórpria,
@PersistenceContext e deve ser usada para acessarmos nosso
EntityManager

337. AOP
● EJB 3.0 oferece recursos de AOP na caixa
● É possível criarmos “Arounds” definidos através de anotações
@AroundInvoke
● Aspectos serão disparados quando registrados para as classes através da
anotação @Interceptors
@AroundInvoke
public Object
someInterceptor(InvocationContext ctx){
Object retorno = null;
try{
retorno = ctx.proceed();
}catch (Exception e) {
// Trata erros
}
return retorno;
}

338. Transações
● Transações de um bean são definidas através
das anotações
● @TransactionManagement e
@TransactionAttribute
● Beans podem ser gerenciados pelo container
ou pelo desenvolvedor
● Existem 6 tipos de transações suportadas
(REQUIRED, REQUIRES_NEW,
MANDATORY, SUPPORTS, NEVER,
NOT_SUPPORTED)

339. E os Entity Beans ?
● Entity Beans não sofreram evolução
● Os servidores ainda são obrigados a
suportarem os Entity Beans 2.1
● JPA veio para “substituir” os Entity Beans

340. Message Driven Beans
● Ficam escutando uma Destination e
aguardando o recebimento de alguma
● mensagem
● A classe que deseja ser um MDB deve
implementar MessageListener e possuir a
anotação @MessageDriven
● É obrigatório a declaração do tipo de
destination e o local da mesma

341. Webservices

342. Assuntos
● Arquitetura
● Tecnologia e especificação
● Expondo um Webservices com EJB3
● Consumindo um Webservices

343. O que são Web Services
● Ambiente de computação distribuída (DCE) que utiliza XML em
todas as camadas
– No formato de dados usado na comunicação
– Na interface usada para descrever as operações suportadas
– Na aplicação usada para registrar e localizar serviços
● Serviços são transportados principalmente via HTTP
– Podem também utilizar outros protocolos populares
● Web Services visam comunicação entre máquinas
– Serviços podem ser implementados usando CGI (com C, Perl,
etc.), ASP, PHP, servlets, JSP, CFML, etc.
– Acesso é feito via clientes HTTP (ou de outros protocolos)
● Tudo isto já existia! Qual a novidade?

344. A novidade é a padronização!
● Todas as camadas em XML!
– Fácil de ler, transformar, converter
– Existe ainda um esforço para padronizar os esquemas que definem a
estrutura e vocabulário do XML usado
● Web Services dá nova vida ao RPC
– Agora com formato universal para os dados!
– Marshalling: converter dados em XML
– Unmarshalling: extrair dados de XML
● Principais características do RPC com Web Services
– Formato padrão de dados usados na comunicação é XML
– Interoperabilidade em todos os níveis
– Transporte é protocolo de larga aceitação: HTTP, SMTP, ...
– Transparência de localidade e neutralidade de linguagem

345. Arquitetura de Web Services:
camadas
● Camada de transporte
– Principais: HTTP (POST), FTP, SMTP
– Emergentes: JRMP (Java RMI), IIOP (CORBA, EJB), JMS,
● IMAP, POP, BEEP, JXTA, ...
– Camada de mensagens
● SOAP
● Camada dados ou serviços
– XML (formato de mensagens)
– XML-RPC
● Camada de descrição de serviços
– WSDL
● Camada de descoberta (registro)
– UDDI, ebXML

346. Arquitetura de Web Services: papéis
● Provedor de serviços
– Oferece serviços, alguns dos quais podem ser
Web Services
● Registro de serviços
– Catálogo de endereços: repositório central que
contém informações sobre web services
● Cliente de serviços
– Aplicação que descobre um web service,
implementa sua interface de comunicação e usa
o serviço

347. Arquitetura de Web Services: papéis

348. SOAP
● Simple Object Access Protocol
● Protocolo padrão baseado em XML para
trocar mensagens entre aplicações
– SOAP não é um protocolo RPC, mas um par de
mensagens
– Transporte pode ser HTTP, SMTP ou outro
– Mensagens podem conter qualquer coisa (texto,
bytes)
– É extensível (mecanismo de RPC, por exemplo, é
extensão)

349. SOAP
SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Header>
<t:Transaction
xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
5
<t:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetLastTradePrice> xmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

350. Descrição de um serviço RPC:
WSDL
● Para saber usar um Web Service, é preciso
– Saber o que um serviço faz (quais as operações?)
– Como chamar suas operações (parâmetros? tipos?)
– Como encontrar o serviço (onde ele está?)
● Web Services Description Language
– Documento XML de esquema padrão que contém todas as
informações necessárias para que um cliente possa utilizar um
Web Service
– Define informações básicas (operações, mapeamentos, tipos,
mensagens, serviço) e suporta extensões
– Tem basicamente mesmo papel que linguagens IDL usadas
em outros sistemas RPC
– Pode ser usada na geração automática de código

351. Interoperabilidade com WSDL
● WSDL serve apenas para descrever interfaces
– Não serve para ser executada
– Nenhuma aplicação precisa da WSDL (não faz parte da
implementação - é só descrição de interface)
● WSDL pode ser mapeada a linguagens (binding)
– Mapeamento: tipos de dados, estruturas, etc.
– Pode-se gerar código de cliente e servidor a partir de WSDL
(stubs & skeletons) em tempo de compilação ou execução
● WSDL facilita a interoperabilidade
– Viabiliza RPC via SOAP
– Pode-se gerar a parte do cliente em uma plataforma (ex: .NET)
e a parte do servidor em outra (ex: J2EE), viabilizando a
comunicação entre arquiteturas diferentes.

352. Exemplo WSDL
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="BookstoreService"
targetNamespace="http://mybooks.org/wsdl"
xmlns:tns="http://mybooks.org/wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<types>...</types>
<message name="BookstoreIF_getPrice">
<part name="String_1" type="xsd:string"/>
</message>
<message name="BookstoreIF_getPriceResponse">
<part name="result" type="xsd:decimal"/>
</message>
<portType name="BookstoreIF">
<operation name="getPrice" parameterOrder="String_1">
<input message="tns:BookstoreIF_getPrice"/>
<output message="tns:BookstoreIF_getPriceResponse"/>
</operation>
</portType>
<binding ... > ...</binding>
<service ... > ... </service>
</definitions>

353. Registro e localização do serviço:
UDDI
● Universal Discovery and Description Integration
– Registro global para Web Services: nuvem UDDI
– Esquema padrão (XML) para representar firmas,
serviços, pontos de acesso dos serviços,
relacionamentos, etc.
– Objetivo é permitir a maior automação no uso dos
serviços
– Registro UDDI acha e devolve URL do WSDL ou serviço
● Registro centralizado permite
– Independência de localização
– Facilidade para pesquisar e utilizar serviços existentes

354. Arquitetura de Web Services:
revisão

355. Criando Web services com EJB3
@Stateless
@WebService
public class MeuService implements
MeuServiceRemote {
@WebMethod
public Integer soma(int a, int b) {
return a + b;
}
}

356. E o cliente ?
● Eclipse Web Tools
● Exemplo prático

357. Maven

358. Assuntos
● O que é Maven ?
● Benefícios
● Archetype
● Conceitos de GroupID, ArtefactID e Version
● Compilando, testando e empacotando
● Plugins
● Alguns “Goals” e como aprender a usa-los
● Dependências
● Repositório e deploy

359. O que é o Maven ?
● A princípio se parece com várias coisas, mas
seu verdadeiro princípio é aplicar padrões
para a estrutura de “build” de um projeto
● Ferramenta para Build, Testes,
Documentação, Relatórios, Gerenciamento de
dependências, Versionamento, Releases e
Distribuição
● Facilita a integração contínua

360. Benefícios do Maven
● Padronização
– Dos diretórios
– Processo de Build
– Do nome dos artefatos
● Gerenciamento de dependências
– Dependências transitivas
– Grande quantidade de repositórios
● Facilita a distribuição
– Dependência são trazidas no build
● Melhora a qualidade do código
– Diversos relatórios de métrias
– Javadoc
● Fácil de aprender

361. Archetype
● Para criar um projeto Maven, usamos uma
funcionalidade chamada Archetype
● O Archetype é um template de projeto
● groupId e artifactId
mvn archetype:create
-DarchetypeGroupId=org.apache.maven.archetypes
-DgroupId=com.digitel.app -DartifactId=my-app

362. Template Gerado
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.digitel.app</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>Maven Quick Start Archetype</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>

363. Estrutura de diretórios padrão
my-app
|-- pom.xml
`-- src
|-- main
| `-- java
| `-- com
| `-- digitel
| `-- app
| `-- App.java
`-- test
`-- java
`-- com
`-- digitel
`-- app
`-- AppTest.java

364. Como eu compilo os fontes
● Bem simples:
– mvn compile
[INFO] ----------------------------------------------------------------------------
[INFO] Building Maven Quick Start Archetype
[INFO] task-segment: [compile]
[INFO] ----------------------------------------------------------------------------
[INFO] artifact org.apache.maven.plugins:maven-resources-plugin:
checking for updates from central
...
[INFO] artifact org.apache.maven.plugins:maven-compiler-plugin:
checking for updates from central
...
[INFO] [resources:resources]
...
[INFO] [compiler:compile]
Compiling 1 source file to <dir>/my-app/target/classes
[INFO] ----------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ----------------------------------------------------------------------------
[INFO] Total time: 3 minutes 54 seconds
[INFO] Finished at: Fri Sep 23 15:48:34 GMT-05:00 2005
[INFO] Final Memory: 2M/6M
[INFO] ----------------------------------------------------------------------------

365. Sobre a compilação
● O Maven irá verificar as dependências e irá
fazer o download do repositório central
● Não foi preciso informar onde estão os fontes
e nem o classpath
● Os testes não foram compilados
● As classes compiladas serão colocadas em $
{basedir}/target/classes que é padrão do
Maven

366. Como compilar e rodar os testes
● mvn test ou mvn test-compile (apenas compila)
INFO] ----------------------------------------------------------------------------
[INFO] Building Maven Quick Start Archetype
[INFO] task-segment: [test]
[INFO] ----------------------------------------------------------------------------
[INFO] artifact org.apache.maven.plugins:maven-surefire-plugin:
checking for updates from central
...
[INFO] [resources:resources]
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] [compiler:testCompile]
Compiling 1 source file to C:TestMaven2testmy-apptargettest-classes
...
[INFO] [surefire:test]
[INFO] Setting reports dir: C:TestMaven2testmy-apptarget/surefire-reports
-------------------------------------------------------
T E S T S
-------------------------------------------------------
[surefire] Running com.mycompany.app.AppTest
[surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0 sec
Results :
[surefire] Tests run: 1, Failures: 0, Errors: 0
[INFO] ----------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ----------------------------------------------------------------------------
[INFO] Total time: 15 seconds
[INFO] Finished at: Thu Oct 06 08:12:17 MDT 2005
[INFO] Final Memory: 2M/8M
[INFO] ----------------------------------------------------------------------------

367. Empacotamento e outros goals
● mvn package
– Empacotamento de acordo com packaging do
pom.xml
● mvn install - local
● mvn deploy - remoto
● mvn site
● mvn eclipse:eclipse
● mvn javadoc:javadoc

368. Como usar plugins
● Para personalizar o processo de build do Maven é preciso
configurar seus plugins
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.0.2</version>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
</build>

369. Plugins
● O uso de plugins se parece com uma
declaração de dependência
● Os plugins são obtidos (download) e usados
automaticamente de acordo com a versão
especificada
● Intercepta e adiciona funciona funcionalidade
aos “goals”
● Pode adicionar novos “goals”

370. O Ciclo de vida do Maven
● Baseado no conceito central de ciclo de vida
do build
● Para os usuários: Necessário aprender
apenas alguns poucos comandos
● Ciclos de vida para: Clean, Site e Build
● Clean: pre-clean, clean, post-clean
● Site: pre-site, site, post-site e site-deploy

371. Ciclo de vida de Build
● Validate – Valida se possui todas informações necessárias
● Compile – Compilas os códigos fontes
● Test – Executa os testes unitários
● Package – Empacota o projeto
● Install – Instala o projeto no repositório local para usar como
dependência para outros projetos locais
● Deploy – Copia o pacote para o repositório remoto para ser
compartilhado com os outros desenvolvedores

372. Dependências
● Existe uma seção no pom.xml que permite
declarar toda as dependências externas para
um determinado projeto
● Uma dependência pode ser usada em
compile-time, test-time, run time.
● Para cada dependência é necessário declarar
groupId, artifactId, version e scope
● O escopo pode ser: compile, test, runtime e
provided

373. Dependências
<dependencies>
...
<dependency>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
</dependencies>

374. Dependências e repositório
● Como é feito a referência quando declaramos
uma dependência?
– O Jar do repositório local é adicionado no
classpath.
● E como o projeto referencia um jar que não
está no repositório local ?
– O Maven fará o download de um repositório
remoto para um repositório local
– Por default: http://repo1.maven.org/maven2/
– É possível adicionar outros repositórios

375. Repositórios
● Um repositório pode ser usado para armazenar dependências
● 2 tipos: remoto e local
● O local é um cache para o repositório remoto
<project>
...
<repositories>
<repository>
<id>my-internal-site</id>
<url>http://myserver/repo</url>
</repository>
</repositories>
...
</project>

376. Como publicar artefatos no
repositório
● Além do nome de declarar o repositório é
preciso configurar a forma de acesso
<distributionManagement>
<repository>
<id>mycompany-repository</id>
<name>MyCompany Repository</name>
<url>scp://repository.mycompany.com/repository/maven2</url>
</repository>
</distributionManagement>

377. JMX

378. Assuntos
● Monitoriamento vs Logging
● Monitorando a JVM
● Segurança
● Criando um MBean

379. Monitoramento vs Logging
● Monitoramento
● Log
– Quantos usuários se
– Quem acessou a aplicação Y
autenticaram
– Quando a rotina X foi executada – Quantas Thread da
– Quando o servidor foi iniciado rotina X estão em
execução
– Quando o servidor foi
iniciado

380. Monitoramento
● Diferente do Log, o monitoramento pode sofrer operações
– Alterar nível de Log
– Alterar a programação de rotinas
– Iniciar / Parar operações
● O monitoramento pode guardar um “histórico” (somatório)
– Quantidade de usuários autenticados
– Transações processadas
– Quantidade de Erros

381. JMX
● JMX é uma tecnologia do mundo Java que permite fazer isso com
facilidade
● JDK 1.5 inclui uma console de gerência (jconsole)
– Mas você pode escrever sua própria console de gerência
● Muitas aplicações importantes são gerenciáveis via JMX
– JVM
– JBoss

382. Monitoramento da JVM
● Listar Processos: jps
● Analisar um processo: jconsole
● jconsole acha todas as aplicações no
localhost

383. jconsole
● jconsole dá um sumário de recursos da
aplicação
● Monitoração do uso de memória pela
aplicação
● Examinando a situação dos threads
● Monitorando o número de classes carregadas

384. JMX
● Jconsole também lista os MBeans

385. Habilitando o agente JMX
● Para Monitoramento Local:
– Passar a propriedade com.sun.management.jmxremote para a
JVM
-Dcom.sun.management.jmxremote
●
● Para Monitoramento Remoto:
● Passar as propiedades
– com.sun.management.jmxremote.ssl=false
– com.sun.management.jmxremote.port=portNum
– com.sun.management.jmxremote
– com.sun.management.jmxremote.authenticate=false
– (desabilita a senha) – Para usar a senha...

386. Habilitando senha para JMX remoto
● Diretório <java_home>/jdk/jre/lib/management
● Criar arquivo: jmxremote.password
● Importante: Arquivo deve estar Read Only
apenas para o Owner (chmod 600
jmxremote.password)
● A role também deve estar presente no arquivo
jmxremote.access

387. Arquitetura do JMX
● A entidade básica que expõe informação de
gerência é o Mbean
● Portanto o MBean é usado para instrumentar
um recurso que se quer gerenciar
– Um MBean expõe uma interface de gerência para
um recurso

388. Criando um MBeans
● Criar MBeans é muito simples, tão simples quanto beans normais
● Uso de nomes padronizados (get, set, ...)
● Portanto, não há grande investimento para poder deixar uma
aplicação gerenciável
● Define-se um MBean padrão definindo uma interface XptoMBean
● A implementação da interface chama-se Xpto
● Cada método define
– Um atributo de gerência que pode ser lido (set...) e/ou gravado
(set...); ou
– Um método de gerência que pode ser chamado

389. Interface MBean
public interface HelloMBean {
public void sayHello();
public int add(int x, int y);
public String getName();
public int getCacheSize();
public void setCacheSize(int size);
}

390. Implementação do MBean
public class Hello implements HelloMBean {
public void sayHello() {
System.out.println("hello, world");
}
public int add(int x, int y) {
return x + y;
}
public String getName() {
return this.name;
}
public int getCacheSize() {
return this.cacheSize;
}
public synchronized void setCacheSize(int size) {
this.cacheSize = size;
System.out.println("Cache size now " + this.cacheSize);
}
private final String name = "Reginald";
private int cacheSize = DEFAULT_CACHE_SIZE;
private static final int DEFAULT_CACHE_SIZE = 200;
}

391. Registrando o MBean
public class Teste {
public static void main(String[] args)
throws MalformedObjectNameException,
NullPointerException, InstanceAlreadyExistsException,
MBeanRegistrationException,
NotCompliantMBeanException,
InterruptedException {
MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
ObjectName name = new ObjectName("com.example.mbeans:type=Hello");
Hello mbean = new Hello();
mbs.registerMBean(mbean, name);
System.out.println("Waiting forever...");
Thread.sleep(Long.MAX_VALUE);
}
}

392. SPRING

393. Assuntos
● O que o Spring faz ?
● IOC Container
● Exemplo com XmlBeanFactory
● Integração ORM
● Transação
● AOP
● MVC

394. Java Web Start

395. Assuntos
● Facilidade de distribuição
● Sandbox
● Aplicação assinada
● Exemplo

396. JBoss Seam

397. Assuntos
● Vantagens
● Tecnologias (Facelets, EJB e JPA)
● seam-gen
● Contextos
● Conversação
● Outras funcionalidades (Remoting, Mail, PDF,
Rules, etc)

398. FIM