Apostilava Java EE 5 - 2007

Tecnologias para
Desenvolvimento
de Software

Licença

Esta obra está licenciada sob uma
Licença Creative Commons

http://creativecommons.org/licenses/by-nc-sa/2.0/br/

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

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

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

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

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

Programação por contratos

● Interoperabilidade

?

Contrato entre componentes

● Interoperabilidade só é atingida com:
● Padronização

Uma interface é um contrato entre
partes

Interface não é implementação

≠

Interfaces

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

Uma Interface com várias
implementações

Interfaces Java

● Java
public interface DataAccesLayer {

public String [] read(int recNo);

public void update(int recNo, String [] data);

public void delete(int recNo);
}

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....
}
}

Frameworks

● Exemplo
– Auto atendimento do BRB
– Auto atendimento do BB
– Auto atendimento do Banco REAL

Frameworks

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

Framework genérico

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

Frameworks

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

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

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...

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.

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.

Ciclo de vida - Métodos

● Interface Servlet possui 3 métodos principais:
– init()
– service()
– destroy()
● Mais métodos auxiliares:
– getServletConfig()
– getServletInfo()
– GetServletContext()
– etc

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()

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
}
}

Hello World em Servlet
public class HelloWorld extends HttpServlet {


out.println("Hello World");

}

}

Servlets – Conteúdo binário
public class ImageServlet extends HttpServlet {


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();
}
}

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

Redirect vs Request Dispatcher
ResquestDispatcher rd = request.getResquestDispatcher("Servlet2");

rd.forward(request, response);

response.sendRedirect(“Servlet2);

Lendo Parâmetros
public class LerParametros extends HttpServlet {

response.setContentType("text/html");
out.println("<BODY>n"
+ "<UL>n"
+ " <LI>param1: " + request.getParameter("param1") + "n"
+ "</UL>n" + "</BODY></HTML>");
}

}

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

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");

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>

Mapeando um Servlet
<servlet>
<description></description>
<display-name>HelloWorld</display-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>
<url-pattern>/HelloWorld</url-pattern>
</servlet-mapping>
<servlet>

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

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>

Filtro simples que substitui um
servlet
public class HelloFilter implements Filter {

public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain filterChain)

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() {}
}

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

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

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>");

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

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

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 %>
<% }%>

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 ... />

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" %>

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)];
}
%>

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

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>

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

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 %>

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

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

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>

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

Principais ações

● Suporte à impressão da linguagem
expressões
<c:out value="${pessoa.nome}" />

– Expressões condicionais
<c:if test="${pessoa.idade >= 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>

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.

Assuntos

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

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

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>

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>

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" %>

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

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

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

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

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>

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

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

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” />

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

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

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

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

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

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, ...

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

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

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)

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

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

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:}

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);

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)

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");

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");

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.

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

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)

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)


● 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


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

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

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

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


● 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)


● 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)


● 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!

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!

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)

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

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)

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)

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

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

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

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");

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

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);

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();

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);

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 );

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

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() )
}
}

MessageListener

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

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

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());
}

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.

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

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

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

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

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

Classes de Autênticação

● LoginContext
● LoginModule
● CallBack
● CallBackHandler

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

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();

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

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

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();

Classes de Autorização

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

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>

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

Assuntos

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

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 ?

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.

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

Exemplos de Resource Adapters

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

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

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.

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

● 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

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();

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)

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

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.

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

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

Modelos Transacionais

● Flat Transactions

● Nested Transactions

Flat Transactions

● Modelo commit/rollback.

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

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)

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

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

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.

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.

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());
}
}

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();

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>

Propagação de transação

● Facilmente resolvida com BMT
● E no CMT ?

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

Required

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

Supports

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

RequiresNew

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

NotSupported

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

Mandatory

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

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)

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()

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

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.

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)

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.

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>

Assuntos

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

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

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

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

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

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

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

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
)

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

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

}

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

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

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

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

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

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

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

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

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”);

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>

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();

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

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;
}
}

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");

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();

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

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();

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);

Query - Paginação

String hql = "from DomesticCat cat";
Query q = sess.createQuery(hql);
q.setFirstResult(20);
q.setMaxResults(10);
List cats = q.list();

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();

Assuntos

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

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

Provedor JPA

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

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

Ciclo de vida da Entidade

● Objetos podem existir sem o Banco de Dados
● Entra em cena o estado do objeto

Como é realizado o mapeamento ?

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

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
}

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>

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();
}
}
}

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);
}

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>();

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();

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();

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();
}

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

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

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

Arquitetura do Application Server

Usos possíveis do Application
Server

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)

Apostilava Java EE 5 - 2007

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (19)

Ähnlich wie Apostilava Java EE 5 - 2007

Ähnlich wie Apostilava Java EE 5 - 2007 (20)

Apostilava Java EE 5 - 2007