Apostilava Java EE 5 - 2007

Tecnologias para Desenvolvimento

de Software

Licença

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

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

Instrutor

● Rafael Benevides● Trabalha com Java desde 2001● Possui as certificações Java: SCJA, SCJP,

SCWCD, SCBCD e SCEA.● E não Java: SAP Netweaver e ITIL● Atualmente desenvolve aplicações para o

Governo Federal usando as tecnologias que serão apresentadas

Objetivo

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

Agenda

● 31/07 – Servlets, JSP e JSF ● 01/08 – JNDI, JMS, JAAS, JCA e JTA● 02/08 – Hibernate e JPA● Livres por alguns dias ;)● 07/08 – JBoss AS, EJB2.1, EJB3 e

Webservices● 08/08 – Maven, JMX, Spring e JWS● 09/09 – JBoss Seam

Apresentação da equipe

● Seu nome● Atividade que executa● Experiência– Orientação a objetos

– Programação Java

– Modelagem/Projeto de Classes

Expectativas sobre o curso

JCP e as Especificações Java

● O que é uma especificação?

● Como nascem as especificações ?

● JCP - Java Community Proccess

● Quem participa: Apache, BEA, CA, Ebay, Eclipse, Google, HP, IBM, LG, Mitsubishi, Motorola, Nokia, Novell, Oracle, Panasonic, Philips, Red Hat, SAP, Siemens, Sony,

● A própria Sun

● E também: faculdades, comunidades (Soujava, etc) e pessoas

Programação por contratos

● Interoperabilidade

?

Contrato entre componentes

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

Uma interface é um contrato entre partes

Interface não é implementação

≠

Interfaces

● Elementos legais– Contrato

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

http://java.sun.com/jstl/ea/core

http://java.sun.com/jstl/ea/xml

http://java.sun.com/jstl/ea/fmt

http://java.sun.com/jstl/ea/sql

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

http://www.digitel.com.br/

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

http://www.digitel.com.br/

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

http://www.abc.com.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)


● RMI/RPC (Corba, Java RMI, etc.)– Mensagens são representadas como chamadas para métodos

remotos (numero ilimitado de ações)

– Cada aplicação se comunica através de uma interface definida

– Pode ser descentralizado (rede de ORBs ligados por IIOP)

– Serviços de diretórios localizam objetos



● E-mail– Uma ou ambas as partes podem ser usuários

humanos

● Messaging é sempre comunicação 100% B2B

Desvantagens dos MOMs

● Camada adicional para repasse de mensagens

● Centralização em único ponto introduz risco de falha de todo o sistema caso o serviço de mensagens falhe

– Solução: replicação, clustering

Desvantagens genéricas dos MOMs

● Muito genérica: aplicações precisam decifrar as mensagens para que possam operar; esconde a interface de programação remota dentro das mensagens

● Comunicação assíncrona (geralmente): dificulta a criação de aplicações que necessitam de comunicação síncrona.

● Não faz tratamento de representação de dados (data marshalling) - MOM é apenas meio de transporte

Vantagens dos MOMs (1)

● Escalabilidade– Para aumentar a capacidade servidora, basta

acrescentar mais servidores (não é preciso mexer nos componentes)

– Novos clientes podem se conectar para usar mensagens em outras aplicações

– Infraestrutura é reutilizada para novas aplicações


● Comunicação assíncrona– Componentes podem realizar outras tarefas

enquanto não estão ocupados lidando com requisições

– Podem sondar o servidor em busca de novas mensagens quando estiverem livres (PTP)

– Podem se cadastrar para, quando houver mensagens novas, receber notificação (pub/sub)


● Desacoplamento– Maior modularidade, maior reuso

(substituibilidade), maior simplicidade, maior robustez (falhas localizadas)

– Papéis bem definidos simplificam o desenvolvimento: produtor, consumidor e serviço tem unica interface, independente da aplicação

– Servidor de messaging é responsável pela qualidade do serviço (não é preocupação dos componentes)


● Flexibilidade– API definida pelo tipo das mensagens (e não por

interfaces)

– Meio comum é a mensagem: se componentes a entendem, o resto (linguagens, plataformas, etc.) não importa!

E quando usar MOM em vez de RPC

● ... ou, quando decidir por acoplamento mais fraco?

– Quando a comunicação se baseia mais no formato de mensagens que em interfaces rígidas (componentes não dependem da interface de outros componentes)

– Quando a disponibilidade dos componentes é imprevisível, mas sua aplicação precisa rodar mesmo que componentes não estejam todos acessíveis

– Quando for preciso suportar comunicação assíncrona: componente pode enviar informações para outro e continuar a operar mesmo sem receber resposta imediata

Cenário comum em muitas aplicações B2B!

JMS

● Interface Java única para unir as MOMs incompatíveis

● API que permite que aplicações criem, enviem, recebam e leiam mensagens através de um MOM

● API consiste principalmente de interfaces (implementadas pelo fabricante do MOM)

● Parte integral da plataforma J2EE (acrescenta possibilidade de comunicação assíncrona a EJBs)

Metas do JMS

● Oferecer uma API simples, unificada e compatível com aplicações existentes (não-JMS)

● Suportar aplicações heterogêneas em diferentes Sos, plataformas, arquiteturas e linguagens

● Suportar mensagens contendo objetos serializados Java e páginas XML

Principais características

● Modelo flexível de desenvolvimento baseado em dois domínios: ponto-a-ponto e publish/subscribe

● Controle de persistência, tempo de vida, prioridades e durabilidade associados a serviços e mensagens

● Suporte à comunicação síncrona e assíncrona

● Suporte a transações no envio e recebimento de mensagens

● Suportado por todos os servidores de aplicação J2EE (implementam os dois domínios: PTP e pub/sub)

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.


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.


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


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.


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


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

}


● As interfaces Home e Remote não oferecem bom desempenho, pois as chamadas são feitas via RMI.


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

}


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

http://java.sun.com/dtd/ejb-jar_2_0.dtd

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

http://repo1.maven.org/maven2/

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

Technology

Apostilava Java EE 5 - 2007