View
2.281
Download
37
Category
Preview:
DESCRIPTION
Apostila de 2007 com diversas tecnologias da Spec Java EE 5
Citation preview
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
● Interface
– Contratado● Quem
implementa a interface
– Contratante● Quem usa a
interface
Interfaces
Uma Interface com várias implementações
Interfaces Java
● Javapublic interface DataAccesLayer {
public String [] read(int recNo);
public void update(int recNo, String [] data);
public void delete(int recNo);
}
Implementação da Interface
● Javapublic 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
Applet
Servlet
Midlet
EJB 2.1 – Session Bean
Servlets
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()
Ciclo de vida de um Servlet
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 Servletpublic class HelloWorld extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
PrintWriter out = response.getWriter();out.println("Hello World");
}
}
Servlets – Conteúdo bináriopublic 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 StreamsFileInputStream in = new FileInputStream(file);OutputStream out = response.getOutputStream();
// Copiar do Arquivo para o Responsebyte[] 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
CódigoTipo1XX Informação2XX Sucesso3XX Redirecionamento4XX Erro Cliente5XX Erro Servidor
response.sendError(HttpServletResponse.SC_NOT_FOUND)
SC_OK 200 OK SC_NO_CONTENT 204SC_MOVED_PERMANENTLY 301SC_MOVED_ TEMPORARILY 302SC_ UNAUTHORIZED 401SC_NOT_FOUND 404SC_SERVICE_UNAVAILABLE 503
Mnemonic Code Message
No ContentMoved Permanently Moved TemporarilyUnauthorized Not FoundService Unavailable
Redirect vs Request Dispatcher
ResquestDispatcher rd = request.getResquestDispatcher("Servlet2");
rd.forward(request, response);
response.sendRedirect(“Servlet2);
Lendo Parâmetrospublic 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>");}
}
Lendo Parâmetros
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 1String[] vetor = {"um", "dois", "tres"};HttpSession session = request.getSession();session.setAttribute("dados", vetor);
Requisição 2HttpSession 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-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>
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)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() {}}
JSP
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
<% String nome = request.getParameter("nome"); String idStr = request.getParameter("id"); int id = Integer.parseInt(idStr);%>
<p>Bom dia <%=nome %>! (cod: <%=id %>
http://servidor/programa.jsp?nome=Fulano&id=5
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:if test="${pessoa.idade >= 18}"><a href="adultos.html">Entrar</a>
</c:if>
– Expressões condicionais
<c:out value="${pessoa.nome}" />
<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.
JSF
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” />
JNDI
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:\temp\dados.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)
LDAP
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
Arquitetura JNDI
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 nomes1: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
● Adicionando ligações
Fruit fruit = new Fruit("orange");ctx.bind("favorite", fruit);
● Substituindo ligaçõesFruit fruit = new Fruit("lemon");ctx.rebind("favorite", fruit);
● Removendo ligações
ctx.unbind("favorite");
● Renomeando objetos
ctx.rename("report.txt", "old_report.txt");● Criando novos
contextosContext result = ctx.createSubcontext("new");
● Destruindo contextosctx.destroySubcontext("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.
JMS
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)
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
Messaging vs RPC vs e-Mail
Messaging vs RPC vs e-Mail
● 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
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)
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)
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!
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)
Arquitetura JMS
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
Escrevendo aplicações JMS
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á-laQueue 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-RIString 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
● Depois, pode consumir mensagens de forma síncrona (método é o mesmo para domínios PTP e pub/sub
QueueReceiver receiver = queueSession.createReceiver(fila);TopicSubscriber subscriber = topicSession.createSubscriber(canal);
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 é Stringsender.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());
}
JAAS
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)
Arquitetura do JAAS
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();
Revendo Arquitetura do JAAS
Classes de Autorização
● As classes de autorização não serão vistas● Autorização em ambiente corporativo deve
ser feito pelo Container
Pegando Autenticação na WEB
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
JCA
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
● Um Resource Adapter que se conecta a um sistema de processamento de transações
● Um Resource Adapter que se conecta a um 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
Contratos de Sistema
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
Ciclo de Vida do JCA
Deployment descriptor● ra.xml
● 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)
myCon.close();
JTA
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
begin()I nicia uma nova transação, que se associa ao thread atual.
commit()
Executa o protocolo de confirmação de duas fases em uma transação existente associada ao thread atual. Cada gerenciador de recursos tornará suas atualizações duráveis
getStatus()Recupera o status de transação associada a esse thread
Rollback()Força uma reversão da transação associada ao thread atual
setRollbackOnly()Chame-o para forçar a transação atual a reverter. Por fim, forçará a transação a abortar.
setTransactionTimeout (int)
O tempo limite da transação é o tempo máximo que uma transação pode executar antes de seu aborto. I sso é útil para evitar situações de impasse, em que recursos preciosos são retidos por uma transação que está sendo executada atualmente.
Método Descrição
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 EJBpublic 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çõesut.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>
Hibernate
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
conta correntista saldo
1 Gargantua 1370
2 Pantagruel 3450
3 Gargamel 800
4 Morticia 8200
String codigoString nomedouble saldo
instância:Conta
codigo="4"nome="Morticia"saldo=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 { private String userName; private String name; private String address; private Set billingDetails; // (get/set pairs), etc. ...}
public class BillingDetails { private String accountNumber; private String accountName; private String accountType; private User user; //methods, get/set pairs... }
create table USER ( USERNAME VARCHAR(15) NOT NULL PRIMARY KEY, NAME VARCHAR(50) NOT NULL, ADDRESS VARCHAR(100))
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)
Foreign key USERNAME realiza o relacionamento
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
● 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
● 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
Propriedades para Datasources JNDI
Propriedades para Conexões JDBC
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
● Objetos persistentes
DomesticCat cat = (DomesticCat) sess.load( Cat.class, new Long(69) );cat.setName("PK");sess.flush(); // Mudanças são automaticamente persistidas
Carregando objetos persistidos
● Via loadlong id = 1234;DomesticCat pk = (DomesticCat) sess.load( DomesticCat.class, new Long(id) );
● Via QueryList 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 posicionalQuery q = sess.createQuery("from DomesticCat cat where cat.name = ?");q.setString(0, "Izi");
//Lista de parâmetrosList 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();
JPA
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
Como funciona o EntityManager
Criando o EntityManager
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>
Testandopublic class Principal {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
@PersistenceContextEntityManager 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 Queriesfinal 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(); }
JBoss Application Server
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)
JBoss microkernel
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
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
Usando o JBoss
● Como instalar ?– Descompactar e usar
● Como executar– run.sh ou run.bat
● Como parar:– shutdown.sh ou shutdown.bat
Perfis JBoss
● O Jboss vem com 3 perfis:– Minimal
– Default
– All
● Para escolher entre eles, use o parâmetro “-c”– ./run.sh -c all
JBoss e Servidores corporativos
● Várias interfaces de rede (4 interfaces)● Muita memória (8GB)● Mas não é 64bits● Como aproveitar este hardware ?
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
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
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
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
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...)
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)
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
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!
Load Balancing
EJB 2.1
Assuntos
● Session Beans e EntityBeans● SB Stateful e Stateless● EB CMP e BMP● Message Driven Beans● Deployment descriptors● Empacotamento
Sistemas Corporativos são complexos
● Clusterização.
● Implantação dinâmica.
● Segurança.
● Gerência de recursos.
● Muitos, muitos outros.
● Balanceamento de carga.
● Recuperação em caso de falhas.
● Invocação remota de métodos.
● Integração com sistemas legados.
● Transações.
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.
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.
Reutilizando componente para Serviço Postal
Reutilizando componente para Revenda de Veículos
Reutilizando componente para Comércio Eletrônico
Arquiteturas de Componentes
● Importância do uso de interfaces
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.
Por que Java?
● Separação entre interface e implementação.
● Segurança.
● Executa em qualquer plataforma.
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
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.
JavaBeans X Enterprise JavaBeans
J2EE Big picture
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.
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.
Objetos Distribuídos: Base para EJB
● Componentes EJB são baseados em objetos distribuídos.
Objetos Distribuídos e Middleware
● Middleware Explícito.
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.
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
Objetos Distribuídos e Middleware
Middleware Explícito
Middleware Implícito
+
EJB
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
{
}
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.
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;
}
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.
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;
}
Que constitui um Enterprise Bean?
● As interfaces Home e Remote não oferecem bom desempenho, pois as chamadas são feitas via RMI.
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.
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;
}
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.
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.
Criando arquivo EJB-JAR
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;}
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();}
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;}
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.EJBLocalHome {
/** Cria o EJBObject para o Bean OlaMundo. */ OlaMundoLocal create() throws javax.ejb.CreateException;}
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().
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!"; }}
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>
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.
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(); }}
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.
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.
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.
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.
Características dos Entity Beans
● Entity Beans podem ser localizados– Métodos finder.
● Os dados dos Entity Beans podem ser modificados sem utilizar EJB.
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.
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.
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;
}
EJB 3
Assuntos
● Facilidades● Anotações● Session Beans● SB Stateful e Stateless● Sai deployment descriptor (opcional), Sai
interface home, sai Entity Bean
EJB3
Uma verdadeira revolução
● Princípio Pareto– “80% das consequências advém de 20% das
causas” Vilfredo Pareto
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
Como se sentia o desenvolvedor J2EE
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
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
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
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
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
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
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
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
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
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
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
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({})
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
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
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
@AroundInvokepublic Object someInterceptor(InvocationContext ctx){ Object retorno = null; try{ retorno = ctx.proceed(); }catch (Exception e) { // Trata erros } return retorno;}
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)
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
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
Webservices
Assuntos
● Arquitetura● Tecnologia e especificação● Expondo um Webservices com EJB3● Consumindo um Webservices
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?
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
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
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
Arquitetura de Web Services: papéis
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)
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>
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
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.
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>
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
Arquitetura de Web Services: revisão
Criando Web services com EJB3
@Stateless@WebServicepublic class MeuService implements MeuServiceRemote {
@WebMethod public Integer soma(int a, int b) { return a + b; }
}
E o cliente ?
● Eclipse Web Tools● Exemplo prático
Maven
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
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
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
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
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>
Estrutura de diretórios padrãomy-app|-- pom.xml`-- src |-- main | `-- java | `-- com | `-- digitel | `-- app | `-- App.java `-- test `-- java `-- com `-- digitel `-- app `-- AppTest.java
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] ----------------------------------------------------------------------------
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
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:\Test\Maven2\test\my-app\target\test-classes...[INFO] [surefire:test][INFO] Setting reports dir: C:\Test\Maven2\test\my-app\target/surefire-reports------------------------------------------------------- T E S T S-------------------------------------------------------[surefire] Running com.mycompany.app.AppTest[surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0 secResults :[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] ----------------------------------------------------------------------------
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
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>
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”
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
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
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
Dependências
<dependencies><dependencies> ...... <dependency><dependency> <groupId>com.mycompany.app</groupId><groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId><artifactId>my-app</artifactId> <version>1.0-SNAPSHOT</version><version>1.0-SNAPSHOT</version> <scope>compile</scope><scope>compile</scope> </dependency></dependency> </dependencies></dependencies>
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
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>
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>
JMX
Assuntos
● Monitoriamento vs Logging● Monitorando a JVM● Segurança● Criando um MBean
Monitoramento vs Logging
● Log
– Quem acessou a aplicação Y
– Quando a rotina X foi executada
– Quando o servidor foi iniciado
● Monitoramento
– Quantos usuários se autenticaram
– Quantas Thread da rotina X estão em execução
– Quando o servidor foi iniciado
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
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
Monitoramento da JVM
● Listar Processos: jps● Analisar um processo: jconsole● jconsole acha todas as aplicações no
localhost
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
JMX
● Jconsole também lista os MBeans
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...
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
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
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
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);
}
Implementação do MBeanpublic 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;}
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);
}
}
SPRING
Assuntos
● O que o Spring faz ?● IOC Container● Exemplo com XmlBeanFactory● Integração ORM● Transação● AOP● MVC
Java Web Start
Assuntos
● Facilidade de distribuição● Sandbox● Aplicação assinada● Exemplo
JBoss Seam
Assuntos
● Vantagens● Tecnologias (Facelets, EJB e JPA)● seam-gen● Contextos● Conversação● Outras funcionalidades (Remoting, Mail, PDF,
Rules, etc)
FIM
Recommended