Programação Para eb

2016

Programação Para Web IIProf. Cristiano Roberto Franco

Copyright © UNIASSELVI 2016

Elaboração:

Prof. Cristiano Roberto Franco

Revisão, Diagramação e Produção:

Centro Universitário Leonardo da Vinci – UNIASSELVI

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

UNIASSELVI – Indaial.

Impresso por:

005.276 F825p Franco, Cristiano Roberto

Programação Web II / Cristiano Roberto Franco. Indaial : UNIASSELVI, 2016.

192 p. : il.

ISBN 978-85-7830-950-3 1.Programação para internet.

I. Centro Universitário Leonardo Da Vinci.

III

aPresentaçãoO mundo mudou! Enquanto você lê esse texto, muito provavelmente

na tela de seu computador desktop, notebook ou dispositivo móvel, milhões de pessoas ao redor do globo estão trafegando dados digitalmente transformados na autoestrada da informação conhecida como internet. Você não usa mais essa autoestrada somente para estudar e trabalhar, você a usa para comprar, viajar, ouvir música, ver TV, filmes e seriados, fazer operações bancárias, pagar contas, falar com amigos e familiares distantes, namorar e até mesmo para compartilhar com o mundo que você fez uma omelete no café da manhã. E você quer poder fazer tudo isso a qualquer hora e de qualquer lugar.

Tamanha conectividade é possível, mas não vem de graça. Ela cobra um preço caro. Além de antenas, redes, roteadores e demais dispositivos físicos (que não são o objeto desta disciplina e por isso não serão abordados), você precisa de software que possa atender a essa demanda voraz por informação. E não é qualquer software... conforme a lei de Moore vai chegando ao seu limite, decidimos por outras estratégias para ampliar o desempenho dos computadores e consequentemente do software que executa neles. Processadores multicores, virtualização, computação em grid e cloud são apenas alguns dos artifícios que usamos para garantir o desempenho das aplicações. Porque no final das contas, sempre que você compra, viaja, ouve música, vê TV, filmes e seriados e compartilha com o mundo que fez uma omelete no café da manhã, você o faz através de uma aplicação.

É nesse contexto que atua a tecnologia que estudaremos nesta disciplina. A plataforma Java nos apresenta o Java Enterprise Edition (JEE), especialmente desenvolvido e planejado para ambientes com grande demanda por desempenho e robustez. É a mesma tecnologia que dá vazão a alguns dos serviços mais conhecidos e utilizados da internet, como Twitter, Linkedin e Netflix. Destaque especial para o fato de que, em momentos de pico, o Netflix concentra 37% de todo o tráfego de internet da América do Norte (TODD, 2015).

Conforme Evans et al. (2011), os desenvolvedores de software reconhecem cada vez mais a necessidade de aplicações que sejam distribuídas, transacionais, portáveis e que permitam alavancar o desempenho, segurança e confiabilidade das tecnologias server-side. Para atender à crescente demanda, as tecnologias devem permitir que estas aplicações sejam projetadas e construídas mais rapidamente, com menos recursos computacionais e menor custo. Parece inacreditável, mas não... é simplesmente a evolução de uma tecnologia aberta que já existe há aproximadamente 20 anos e que conta com o feedback intenso do Java Community Process para definir seus rumos e roadmap.

IV

Apesar de o JEE ter como um dos focos principais a facilidade de desenvolvimento, a complexidade intrínseca do ambiente para o qual foi projetado e o número de tecnologias envolvidas o tornam relativamente denso. Tenha em mente que você não está estudando uma tecnologia para fazer um “sitezinho para seu tio que tem uma quitanda”, mas sim para construir aplicações distribuídas, robustas, portáveis e seguras.

Lembre-se de que você não está sozinho nesta jornada. O meu trabalho ao longo deste caderno é tentar facilitar ao máximo a compreensão das tecnologias envolvidas no JEE. Para atingir tal objetivo, farei uso de exemplos pequenos e simples na demonstração de cada tecnologia, combinando-os em um exemplo maior e mais complexo como autoatividade no final de cada seção. Tal metodologia de ensino e aprendizagem é sugerida por Nicholas Negroponte do MIT Media Lab, em seu artigo Learning by Doing: Don´t dissect the frog. Built it (NEGROPONTE, 2004).

Aproveito esse momento para destacar que os exercícios NÃO SÃO OPCIONAIS. O objetivo de cada exercício deste caderno é a fixação de determinado conceito através da prática. É aí que reside a importância da realização de todos. Sugerimos fortemente que em caso de dúvida em algum exercício você entre em contato com seu tutor externo ou com a tutoria da Uniasselvi e que não passe para o exercício seguinte enquanto o atual não estiver completamente compreendido. Aprender a programar utilizando a tecnologia JEE sem exercitar os conceitos de forma prática, somente com a leitura do caderno, é equivalente a ir a um restaurante e tentar matar a fome lendo o cardápio. Instruções detalhadas de como preparar o ambiente para a resolução dos exercícios em seu computador são mostrados na Unidade 1.

Você precisará de muita determinação e força de vontade, pois o conteúdo abordado neste caderno não é fácil e você levará mais do que um semestre para compreendê-lo totalmente, entretanto, aqui forneceremos um início sólido e consistente. Desta forma, passe por esse período de estudos com muita dedicação, pois você que hoje é acadêmico(a), amanhã será um profissional de Tecnologia da Informação com o compromisso de construir uma nação melhor.

Lembre-se de que o encantamento com a programação deriva do seu entendimento; a beleza desta área do conhecimento é a compreensão da lógica envolvida na construção de programas. Por isso, bons programadores são apaixonados por linguagens de programação e ambientes de desenvolvimento e estão sempre buscando novos conhecimentos. Como disse Drew Houston, criador do DropBox: “Programar é a coisa mais parecida que temos com superpoderes”.

Bons códigos!

Prof. Cristiano Roberto Franco

V

Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novidades em nosso material.

Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um formato mais prático, que cabe na bolsa e facilita a leitura.

O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagramação no texto, aproveitando ao máximo o espaço da página, o que também contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.

Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade de estudá-lo com versatilidade nas telas do celular, tablet ou computador. Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto em questão.

Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa continuar seus estudos com um material de qualidade.

Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de Desempenho de Estudantes – ENADE. Bons estudos!

NOTA

VI

VII

UNIDADE 1 – INTRODUÇÃO AO JAVA ENTERPRISE EDITION ............................................... 1

TÓPICO 1 – INTRODUÇÃO AO JAVA ENTERPRISE EDITION E PRINCIPAIS TECNOLOGIAS ................................................................................................................ 3

1 INTRODUÇÃO ..................................................................................................................................... 32 PRINCIPAIS TECNOLOGIAS ........................................................................................................... 7

2.1 A ARQUITETURA DOS CONTAINERS ...................................................................................... 9RESUMO DO TÓPICO 1........................................................................................................................ 11AUTOATIVIDADE ................................................................................................................................. 12

TÓPICO 2 – CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT .... 131 INTRODUÇÃO ..................................................................................................................................... 13

1.1 INSTALAÇÃO DO SERVIDOR DE APLICAÇÃO – WILDFLY ................................................ 132 INSTALAÇÃO DO NETBEANS ........................................................................................................ 193 INTEGRAÇÃO WILDFLY-MYSQL ................................................................................................... 224 INTEGRAÇÃO GLASSFISH-MYSQL ............................................................................................... 26RESUMO DO TÓPICO 2........................................................................................................................ 34AUTOATIVIDADE ................................................................................................................................. 35

TÓPICO 3 – JAVA SERVER FACES (JSF) ........................................................................................... 371 INTRODUÇÃO ..................................................................................................................................... 372 CRIAÇÃO DA PRIMEIRA APLICAÇÃO ........................................................................................ 393 CICLO DE VIDA E ESCOPOS DO JSF ............................................................................................ 46LEITURA COMPLEMENTAR ............................................................................................................... 53RESUMO DO TÓPICO 3........................................................................................................................ 57AUTOATIVIDADE ................................................................................................................................. 58

UNIDADE 2 – COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API ....................................................................................................... 59

TÓPICO 1 – COMPONENTES GRÁFICOS DO JAVA SERVER FACES ....................................... 611 INTRODUÇÃO ..................................................................................................................................... 612 COMPONENTES DE FORMULÁRIO ............................................................................................. 613 TABELAS ................................................................................................................................................ 734 SUPORTE NATIVO A AJAX .............................................................................................................. 785 ADICIONANDO UMA BIBLIOTECA EXTERNA DE COMPONENTES VISUAIS .............. 80RESUMO DO TÓPICO 1........................................................................................................................ 90AUTOATIVIDADE ................................................................................................................................. 91

TÓPICO 2 – JAVA PERSISTENCE API ............................................................................................... 931 INTRODUÇÃO ..................................................................................................................................... 932 MAPEAMENTO OBJETO RELACIONAL ...................................................................................... 94

2.1 ARQUITETURA DO DATA ACCESS OBJECT ............................................................................ 96

sumárIo

VIII

3 JAVA PERSISTENCE API (JPA) ......................................................................................................... 984 CONCEITOS E INTERFACES DO JPA ............................................................................................ 99

4.1 MAPEAMENTO DE ENTIDADES .............................................................................................1004.2 RELACIONAMENTOS ENTRE ENTIDADES ..........................................................................111

LEITURA COMPLEMENTAR .............................................................................................................114RESUMO DO TÓPICO 2......................................................................................................................125AUTOATIVIDADE ...............................................................................................................................127

UNIDADE 3 – ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI) ........................................................................................................129

TÓPICO 1 – STATELESS SESSION BEANS ....................................................................................1311 INTRODUÇÃO ...................................................................................................................................1312 STATELESS SESSION BEANS ...........................................................................................................132

2.1 EJB 3.0 ..............................................................................................................................................1322.2 EJB 3.1 ..............................................................................................................................................1342.3 TESTANDO O EJB .........................................................................................................................1352.4 CICLO DE VIDA ............................................................................................................................1382.5 ESCALABILIDADE, POOL E CALL-BACKS .............................................................................1392.6 MÉTODOS ASSÍNCRONOS ........................................................................................................140

RESUMO DO TÓPICO 1......................................................................................................................142AUTOATIVIDADE ...............................................................................................................................143

TÓPICO 2 – STATEFUL SESSION BEAN E SINGLETON SESSION BEANS ..............................1451 INTRODUÇÃO ...................................................................................................................................1452 STATEFULL SESSION BEANS 3.0 ....................................................................................................1463 STATEFULL SESSION BEANS 3.1 ..................................................................................................147

3.1 CICLO DE VIDA DOS STATEFULL SESSION BEANS ............................................................1473.2 CALLBACKS....................................................................................................................................150

4 SINGLETON SESSION BEANS ........................................................................................................1504.1 CICLO DE VIDA ............................................................................................................................152

RESUMO DO TÓPICO 2......................................................................................................................154AUTOATIVIDADE ...............................................................................................................................155

TÓPICO 3 – CONTEXT AND DEPENDENCY INJECTION ...........................................................1571 INTRODUÇÃO ...................................................................................................................................1572 PRODUCER METHODS E ATTRIBUTES .......................................................................................1583 EXPRESSION LANGUAGE (EL) NAME .........................................................................................1594 ESCOPOS E CONTEXTOS ...............................................................................................................160RESUMO DO TÓPICO 3......................................................................................................................162AUTOATIVIDADE ...............................................................................................................................163

TÓPICO 4 – JAVA MESSAGE SERVICE (JMS)............................................................................... 1651 INTRODUÇÃO ...................................................................................................................................1652 FILAS E TÓPICOS ..............................................................................................................................1653 MODOS DE RECEBIMENTO .....................................................................................................169LEITURA COMPLEMENTAR .............................................................................................................173RESUMO DO TÓPICO 4......................................................................................................................183AUTOATIVIDADE ...............................................................................................................................184

REFERÊNCIAS .......................................................................................................................................185

1

UNIDADE 1

INTRODUÇÃO AO JAVAENTERPRISE EDITION

OBJETIVOS DE APRENDIZAGEM

PLANO DE ESTUDOS

Ao final desta unidade, você será capaz de:

• identificar e descrever algumas das tecnologias que fazem parte da especificação JEE;

• identificar quais tipos de situações e ambientes são mais adequados para a utilização de tais tecnologias;

• montar um ambiente de desenvolvimento e deployment de aplicações JEE usando a IDE Eclipse e o Servidor de Aplicações WildFly.

Esta unidade de ensino está dividida em três tópicos, sendo que no final de cada um deles, você encontrará atividades que contribuirão para a apropriação dos conteúdos.

TÓPICO 1 – INTRODUÇÃO AO JAVA ENTERPRISE EDITION E PRINCIPAIS TECNOLOGIAS

TÓPICO 2 – CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E DEPLOYMENT

TÓPICO 3 – JAVA SERVER FACES (JSF)

2

3

TÓPICO 1UNIDADE 1

INTRODUÇÃO AO JAVA ENTERPRISE EDITIONE PRINCIPAIS TECNOLOGIAS

1 INTRODUÇÃOO Java Enterprise Edition (JEE) inicialmente evoluiu como uma plataforma

de desenvolvimento para aplicações enterprise que focava em robustez, webservices e facilidade. Continuamente moldado através do feedback fornecido pelo Java Community Process (JCP), o JEE hoje representa um padrão universal para TI empresarial, facilitando o desenvolvimento, instalação e gerenciamento de aplicações multi-tier e server-centric. O sucesso na adoção da plataforma é inegável. Em maio de 2013, os componentes JEE6 da Oracle e outros fornecedores já contabilizavam 50 milhões de downloads (ORACLE, 2014).

O JCP é o mecanismo através do qual são definidas as especificações técnicas para a tecnologia Java. Ele é aberto para a participação de qualquer pessoa. Maiores detalhes em: <https://www.jcp.org/>.

IMPORTANTE

Conforme Evans et al. (2011), o modelo de aplicação do JEE começa com a linguagem de programação Java e a Java Virtual Machine. A já conhecida e comprovada portabilidade, segurança e produtividade no desenvolvimento que ela oferece formam a base deste modelo.

A plataforma JEE é projetada para suportar aplicações que possuem elevado grau de complexidade, acessando dados das mais variadas fontes e atendendo a um grande número de clientes e requisições. Sua arquitetura facilita o gerenciamento da escalabilidade, pré-requisito para ambientes corporativos de alto desempenho. Esta arquitetura divide o trabalho em duas partes:

1) A lógica de negócio e apresentação: implementadas pelo desenvolvedor.2) Os serviços-padrão que tais aplicações necessitam: ofertadas pela plataforma

JEE através do servidor de aplicações.

UNIDADE 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION

4

A Figura 1 apresenta uma arquitetura JEE típica:

FIGURA 1 - ARQUITURA JEE TÍPICA

FONTE: Evans et al. (2011)

Para compreender a figura, inicialmente é necessária a compreensão do conceito de tier (camada lógica) e de layer (camada física). Tanto a tier quanto a layer podem ser definidas como um conjunto de tecnologias que representa um conceito que faz parte da aplicação. A tier é sempre composta por software, ou seja, é lógica. A layer é sempre composta por hardware, ou seja, é física. No caso da figura, temos quatro tiers e três layers:

1) Client Tier: representa a camada cliente, ou seja, o que os usuários efetivamente acessam da aplicação. Perceba que a figura a define com duas tecnologias: a aplicação cliente, normalmente uma aplicação desktop desenvolvida com Swing ou JavaFX, e as páginas web, acessadas através de um navegador. Ambas as tecnologias estão no layer representado pela máquina do usuário, ou seja, o computador onde ele acessa a aplicação.

2) Web Tier: representa a camada responsável por fazer a ligação entre as páginas web e a lógica de negócio, representada aqui pela tecnologia Java Server Faces (JSF). Em alguns casos, esta camada é dispensável. Perceba que na figura, as aplicações clientes acessam a lógica de negócio diretamente, sem esse intermédio. Esta camada poderia ainda ser representada por tecnologias como

TÓPICO 1 | INTRODUÇÃO AO JAVA ENTERPRISE EDITION E PRINCIPAIS TECNOLOGIAS

5

Servlets e Java Server Pages, que não fazem parte do escopo deste caderno. Se considerarmos a layer, esta parte fica alocada no JEEServer.

3) Business Tier: representa a lógica de negócios da aplicação, aqui implementada em Enterprise Beans individuais para a aplicação cliente e para as páginas web. Em termos de layer, ainda estamos no JEEServer.

4) Enterprise Information Server (EIS) Tier: representa as fontes de dados que as aplicações acessam através da business tier, normalmente um SGBDR. Esta fonte de dados também pode ser alguma aplicação legada já existente no ambiente corporativo. Agora estamos na layer Database Server.

É importante mencionar alguns detalhes a respeito destas definições. A Web Tier pode ser implementada em Servlet Containers, que são uma espécie de “mini” servidores de aplicação mais leves e ágeis, entretanto não disponibilizam todos os serviços dos servidores de aplicação. O Apache Tomcat é um exemplo de Servlet Container. Em muitas situações, é mais produtivo desenvolver aplicações somente com Servlet Containers, colocando a lógica de negócio em Plain Old Java Objects (POJOs) do que acrescentar o peso de um servidor de aplicação com Enterprise Beans. É por este motivo que a layer JEEServer é dividida em Web Tier e Business Tier. Cada caso é um caso e deve ser avaliado pesando os prós e contras de cada tecnologia. É o eterno tradeoff da arquitetura de software.

Outro detalhe importante é que as layers, com exceção da Client Machine, podem ser todas implementadas em uma única camada física. É possível colocar o JEEServer (com ou sem Web Tier) e o DataBase Server em um único computador, embora isso não seja recomendado.

A grande premissa por trás do JEE é que o desenvolvedor pode confiar na plataforma para facilitar a implementação destes serviços-padrão, normalmente representados por requisitos não funcionais. Como tudo na plataforma Java, o JEE é simplesmente uma especificação, ou seja, definições e documentos descrevendo como a tecnologia deve se comportar, além de padrões que devem ser obedecidos no desenvolvimento, definidos através do JCP.

No caso do JEE, um dos componentes principais (se não o principal) é o servidor de aplicação. É este servidor de aplicação que encapsulará internamente os serviços que a plataforma oferece. Cabe ao desenvolvedor utilizá-los através das tecnologias definidas para tal. Como exemplos de implementações desta especificação podemos citar o Jboss, o WildFly e o GlassFish.

O Swing e o JavaFX são tecnologias definidas pela Oracle para a criação de interfaces em aplicações Desktop. Maiores detalhes podem ser encontrados em: <http://docs.oracle.com/javase/8/javase-clienttechnologies.htm>.

IMPORTANTE


6

Mas que serviços são estes? Com o advento e popularização da internet e das tecnologias móveis, o número de usuários aumentou exponencialmente. Para atender à estas demandas, diversos requisitos não funcionais passaram a ter uma importância ainda maior para estas aplicações. Termos como escalabilidade, segurança, gerenciamento do ciclo de vida de objetos, remotabilidade, controle de transações, entre outros, vieram a fazer parte do dia a dia dos desenvolvedores. Ou seja, se transformaram em preocupações para os desenvolvedores, que agora não escrevem código somente para lidar com a lógica de negócios e os requisitos funcionais.

Algumas das tecnologias disponibilizadas pelo JEE permitem que o desenvolvedor simplesmente sinalize em seu código aspectos relacionados à segurança, remotabilidade, transações etc., e o servidor de aplicações faz todo o resto. Isto libera o desenvolvedor para fazer mais o que realmente é importante: escrever código relacionado às necessidades do usuário e a lógica do negócio.

De acordo com ORACLE (2013), o modelo simplificado de programação do JEE faz com que os descritores de deployment em XML sejam opcionais. Ao invés disso, o desenvolvedor pode colocar uma informação diretamente no código fonte através das annotations e o servidor irá configurar o componente em tempo de execução. Estas annotations em geral servem para embutir no programa dados que serial de outra forma fornecidos em um deployment descriptor. Com as annotations, você pode colocar a especificação do serviço do servidor ao lado do código que será afetado por ele.

Abaixo estão listados alguns dos serviços disponibilizados pelas tecnologias envolvidas na plataforma K19 (2013).

• Transações: A arquitetura Enterprise Java Beans (EJB) define um suporte sofisticado para utilização de transações. Esse suporte é integrado com a Java Transaction API (JTA) e oferece inclusive a possibilidade de realizar transações distribuídas.

• Segurança: Suporte para realizar autenticação e autorização de forma transparente. Os desenvolvedores das aplicações não precisam implementar a lógica de segurança, pois ela faz parte da arquitetura JEE.

• Remotabilidade: Aplicações JEE podem ser acessadas remotamente através de diversos protocolos de comunicação. Consequentemente, é possível desenvolver aplicações clientes de diversos tipos. Por exemplo, aplicações EJB podem ser acessadas como Web Services.

• Multithreading e Concorrência: A arquitetura JEE permite que as aplicações sejam acessadas por múltiplos usuários simultaneamente de maneira controlada para evitar problemas de concorrência.

• Persistência: Facilidades para utilizar os serviços dos provedores de persistência que seguem a especificação JPA.

• Gerenciamento de Objetos: Mecanismos de injeção de dependências e controle de ciclo de vida são oferecidos aos objetos de uma aplicação JEE. O mecanismo de controle de ciclo de vida pode garantir a escalabilidade de uma aplicação.


7

• Integração: A arquitetura EJB é fortemente integrada com os componentes da plataforma Java EE. Podemos, por exemplo, facilmente integrar os recursos do JSF em uma aplicação EJB.

Os enterprise java beans, conhecidos como EJBs fazem parte da especificação JEE e fornecem boa parte dos serviços da plataforma. Estudaremos detalhadamente esta tecnologia na Unidade 3 deste Caderno de Estudos.

IMPORTANTE

2 PRINCIPAIS TECNOLOGIASComo descrevemos anteriormente, o servidor de aplicação JEE tem

como principal característica o oferecimento de serviços para as aplicações nele instalados. Serviços estes geralmente relacionados com requisitos não funcionais como escalabilidade, remotabilidade etc. Para cada um destes serviços existe uma ou mais tecnologias que, trabalhando individualmente ou em conjunto, abstraem o desenvolvedor de detalhes específicos da implementação do mesmo.

A seguir faremos uma rápida introdução às principais tecnologias que compõem o JEE, conforme definido em ORACLE (2014), destacando as que serão abordadas neste Caderno de Estudos.

Componentes JEE: As aplicações JEE são feitas de componentes. Estes componentes são unidades encapsuladas de software funcionais que fazem parte das aplicações. Cada componente possui suas próprias classes e arquivos e se comunica com outros componentes. A especificação JEE define os seguintes componentes:

• Aplicação cliente e applets que executam no cliente.• Servlets, Java Server Faces e Java Server Pages como componentes que executam

no servidor.• Enterprise Java Beans, como componentes de negócio que executam no servidor.

Todos estes componentes são escritos na linguagem de programação Java e compilados da mesma forma como qualquer outro programa. A diferença é que estes componentes são “embutidos” dentro de aplicações que obedecem às especificações JEE e são, portanto, gerenciadas pelo servidor de aplicação.


8

Java Server Faces (JSF): É um framework para a construção de aplicações web. Permite a utilização de classes Java como implementações de componentes HTML. Oferece validação de entrada, gerenciamento de eventos, conversão de dados entre componentes e objetos de domínio, configuração de navegação, controle do ciclo de vida dos objetos e a expression language (EL), que permite que componentes da interface gráfica conversem diretamente com o controlador.

Java Persistence API (JPA): Apresenta uma solução para a persistência de objetos em ambientes relacionais, usando uma estratégia de mapeamento objeto relacional. A JPA também pode ser utilizada em aplicações não JEE fora do ambiente do servidor. Consiste de uma api de persistência, uma linguagem de query e metadados para mapeamento objeto relacional.

Java Transaction API (JTA): Oferece uma inferface-padrão para a demarcação de transações. A arquitetura JEE possui auto commit como default para gerenciar commits e rollbacks dentro de transações. Isso significa que qualquer aplicação que está visualizando um dado que está sendo alterado verá o mesmo atualizado depois de cada operação de leitura ou escrita. Entretanto, caso sua aplicação realize duas operações de acesso a dados em bases diferentes que dependem uma da outra, você pode utilizar a JTA API para demarcar onde a transação inteira começa, termina ou mesmo execute um rollback.

Nas tecnologias de bancos de dados, um rollback significa que o banco de dados pode voltar a determinado estado anterior, evitando que um erro seja propagado e mantido no mesmo.

IMPORTANTE

Context and Dependency Injection for Java EE (CDI): Define um conjunto de serviços do JEE acessíveis via contexto. Projetado para uso com objetos que possuam estado, o CDI tem aplicações diversas, pois representa a injeção de recursos em uma classe através de annotations, garantindo a flexibilidade e o baixo acoplamento no desenvolvimento.

Java Message Service API (JMS): Define um padrão de mensageria que permite que os componentes das aplicações JEE criem, enviem, recebam e leiam mensagens. Permite a comunicação distribuída de forma desacoplada, confiável e assíncrona.

Java Authentication and Authorization Service (JAAS): É o serviço que permite a autenticação e autorização de um usuário específico ou de um grupo de usuários. Oferece uma maneira desacoplada para a definição de aspectos de


9

segurança em uma aplicação JEE. O modelo do JEE permite que as restrições de segurança sejam definidas em tempo de deployment e torna as aplicações portáveis para uma vasta gama de implementações de diferentes fornecedores. As regras de controle de acesso são declarativas e definidas pelo desenvolvedor. Estas regras são interpretadas quando a aplicação é instalada no servidor, protegendo os desenvolvedores da complexidade da implementação de requisitos de segurança. O JEE permite ainda a utilização de mecanismos de segurança externos, como Active Directory e LDAP, por exemplo. A mesma aplicação pode fazer uso de diversos mecanismos de segurança sem nenhuma alteração no código fonte da mesma.

Enterprise Java Beans (EJB): São componentes que possuem atributos e métodos para implementar lógica de negócios. Você pode pensar neles como um bloco de construção que pode ser utilizado individualmente ou em conjunto com outros beans para executar lógica de negócios na aplicação JEE. Os Enterprise Beans podem ser de dois tipos:

• Session beans: representa uma conversação transiente com o cliente. Quando o cliente encerra a execução, o bean e seus dados são perdidos.

• Message driven beans: combina características de um session bean e um ouvinte de mensagens, permitindo que um componente de negócios receba mensagens de forma assíncrona.

2.1 A ARQUITETURA DOS CONTAINERS

Uma das vantagens do JEE é a possibilidade de utilizá-lo em aplicações de praticamente qualquer porte. Seu modelo desacoplado e flexível facilita a utilização somente dos componentes que fazem sentido para a aplicação. Para entender esta arquitetura, é importante entender de que forma o servidor de aplicação está dividido em containers. A figura a seguir ilustra o relacionamento entre os containers JEE.

FIGURA 2 - RELACIONAMENTO ENTRE CONTAINERS

FONTE: Oracle (2014)


10

Perceba que o JEE Server possui dois containers, o Web Container e o EJB Container. A compreensão do funcionamento destes dois containers é fundamental para que se faça bom uso dos serviços do servidor de aplicação e da plataforma JEE.

Dentro do Web Container podemos perceber as tecnologias Java Server Faces e Servlet. Uma figura mais completa conteria ainda as Java Server Pages (JSP). Estas tecnologias representam uma forma de disponibilizar a aplicação através de um navegador web. Sem um webcontainer não é possível publicar páginas html, xhtml e outras, o que impede a criação de aplicações web. Caso sua aplicação seja mandatoriamente acessada através de um navegador, você precisará de um webcontainer.

Já o EJB Container é responsável pelo gerenciamento dos Enterprise Java Beans. A maioria dos serviços referentes a requisitos não funcionais ficam sob encargo deste container. Em geral, o acesso aos dados é feito através dele, visto que a JTA não está disponível no Webcontainer. Já dissemos aqui que nada impede a colocação de regras de negócio em POJOs dentro do Webcontainer e mesmo de acessar dados através dele, é simplesmente uma questão de analisar os prós e os contras. No modelo da figura, os componentes Web interagem com os componentes EJB para a lógica de negócios e o acesso aos dados.

Na figura, ainda existe o que é chamado de Client System, composto pelo Browser e pelo Application Client Container. Este componente representa a interface da aplicação com o cliente, seja pelo navegador, seja por uma aplicação Swing, JavaFX ou mesmo console. Perceba que o application client acessa os EJBs sem intermédio do Webcontainer.

Chegando ao final deste tópico, onde fizemos a introdução da plataforma Java Enterprise Edition e das principais tecnologias que a compõem, você deve pensar “é muita coisa para estudar”. E realmente, você tem razão, se considerarmos todo o conjunto das tecnologias que compõem o JEE, o volume de APIs é imenso. Entretanto, analisando o escopo de nossa disciplina e deste caderno, nos concentraremos nas tecnologias mais importantes e que impactarão diretamente sua produtividade como desenvolvedor. Nosso objetivo não é esgotar o tema, e sim colocar você produzindo aplicações JEE com as principais tecnologias que a plataforma disponibiliza. Seu sucesso dependerá diretamente de seus estudos futuros, entretanto, aqui forneceremos um embasamento sólido.

E então...que tal pôr nossas mãos à obra? Como disse Linus Torvalds, criador do sistema operacional Linux: “Talk is cheap... show me the code”. No próximo tópico aprenderemos como configurar e preparar o ambiente que dará suporte ao desenvolvimento JEE.

Bons estudos!

11

Neste tópico você viu que:

• O Java Enterprise Edition (JEE) inicialmente evoluiu como uma plataforma de desenvolvimento para aplicações enterprise que focava em robustez, webservices e facilidade.

• A plataforma JEE é projetada para suportar aplicações que possuem elevado grau de complexidade, acessando dados das mais variadas fontes e atendendo a um grande número de clientes e requisições.

• A tier é sempre composta por software, ou seja, é lógica. A layer é sempre composta por hardware, ou seja, é física.

• A Web Tier pode ser implementada em Servlet Containers, que são uma espécie de “mini” servidores de aplicação mais leves e ágeis, entretanto não disponibilizam todos os serviços dos servidores de aplicação.

• A grande premissa por trás do JEE é que o desenvolvedor pode confiar na plataforma para facilitar a implementação destes serviços padrão, normalmente representados por requisitos não funcionais.

• Para cada um destes serviços existe uma ou mais tecnologias que, trabalhando individualmente ou em conjunto, abstraem o desenvolvedor de detalhes específicos da implementação do mesmo.

• Algumas das tecnologias disponibilizadas pelo JEE permitem que o desenvolvedor simplesmente sinalize em seu código aspectos relacionados à segurança, remotabilidade, transações etc., e o servidor de aplicações faz todo o resto.

• Uma das vantagens do JEE é a possibilidade de utilizá-lo em aplicações de praticamente qualquer porte. Seu modelo desacoplado e flexível facilita a utilização somente dos componentes que fazem sentido para a aplicação.

RESUMO DO TÓPICO 1

12

1 Diferencie um servidor de aplicação de um Servlet Container.

2 Explique detalhadamente e exemplifique a diferença entre uma layer e uma tier, no contexto de arquitetura de software.

3 Uma das vantagens da utilização de um AS que obedeça às especificações JEE é a disponibilização de serviços que antes eram implementados anualmente pelos desenvolvedores. Neste contexto, avalie a lista de serviços abaixo:

I- Segurança através do JAAS.II- Mensageria através do JMS.III- Remotabilidade.IV- Componentização através do JTA.

Agora assinale a alternativa que apresenta as sentenças CORRETAS:a) ( ) I, II e III.b) ( ) II e III.c) ( ) I e III.d) ( ) II e IV.

4 A plataforma Java possui vários frameworks, os quais possuem suas próprias vantagens para equipes de desenvolvimento. Além disso, aplicações JEE são construídas por componentes, os quais são unidades encapsuladas de software. Através da plataforma Java, é possível desenvolver aplicações robustas, e realizar persistência em bancos relacionais através do JPA. Neste sentido, disserte sobre o JPA.

5 A linguagem de programação Java permite o desenvolvimento de aplicações simples e robustas, para os mais variados tipos de dispositivos, como notebooks, desktops ou aplicativos de celulares. O JEE oferece vários serviços que facilitam o desenvolvimento de aplicações. Analise as afirmativas a seguir sobre o JEE:

I- Enterprise Java Beans são componentes de negócio que executam no servidor.II- Java Server Pages são componentes que executam no servidor.III- JTA oferece uma interface-padrão para transações.IV- CDI representa resolução para o problema do mapeamento objeto relacional.

Agora assinale a alternativa referente ao JEE:a) ( ) I, II e III.b) ( ) II e III.c) ( ) I e III.d) ( ) II e IV.

AUTOATIVIDADE

13

TÓPICO 2

CONSTRUÇÃO DO AMBIENTE DEDESENVOLVIMENTO E EPLOYMENT

UNIDADE 1

1 INTRODUÇÃO

1.1 INSTALAÇÃO DO SERVIDOR DE APLICAÇÃO – WILDFLY

Conforme vimos nos tópicos anteriores, para podermos desenvolver, implantar e testar aplicações que utilizem as tecnologias que fazem parte da especificação JEE, precisamos de um servidor de aplicação – application server (AS).

Utilizaremos, neste caderno, o WildFly Application Server, conhecido anteriomente como JBoss. A Red Hat, empresa que desenvolve o AS, justifica a mudança dizendo que o nome WildFly representa melhor o software na atualidade, pois lembra leveza, agilidade e liberdade. A figura a seguir mostra o website do projeto.

O projeto WildFly pode ser acessado através da URL: <http://wildfly.org>.

NOTA

Apesar de você poder fazer o download do software pelo website e instalação separadamente através do arquivo, utilizaremos aqui uma abordagem diferente: instalaremos através da própria Integrated Development Environment (IDE) Eclipse.


14

FIGURA 3 - WEBSITE DO SERVIDOR DE APLICAÇÃO WILDFLY

FONTE: O autor

Inicialmente precisaremos fazer com que o Eclipse mostre a aba dos servidores, visto que passaremos a utilizá-la com bastante frequência. Na figura a seguir mostramos a aba dos servidores na IDE.

FIGURA 4 - ABA SERVIDORES NO ECLIPSE

FONTE: O autor

Caso a aba não esteja aparecendo para você, é possível adicioná-la através da seleção do menu Window -> Show View -> Other. Você deve digitar a palavra server, de modo que esta opção fique acessível para seleção, conforme a figura a seguir.

TÓPICO 2 | CONSTRUÇÃO DO AMBIENTE DE DESENVOLVIMENTO E EPLOYMENT

15

FIGURA 5 - SELEÇÃO DA ABA SERVERS NO ECLIPSE

FONTE: O autor

FONTE: O autor

Uma vez que a aba está disponível, devemos clicar com o botão direito do mouse e selecionar a opção New - > Server. Esta ação abrirá um novo diálogo, onde devemos selecionar a opção destacada na Figura 6.

A próxima tela traz os servidores disponíveis para instalação no Eclipse. Devemos selecionar a opção JbossAS Tools, confirmar todas as licenças e prosseguir com a instalação, conforme a Figura 7. Ao longo da instalação, algumas mensagens de aviso serão mostradas e ao final, você será solicitado para reiniciar a IDE. Finalize o procedimento e aguarde a reinicialização do Eclipse.

FIGURA 6 - DEFINIÇÃO DE UM NOVO SERVER


16

FIGURA 7 - SELEÇÃO DO JBOSSAS TOOLS

FONTE: O autor

Ao concluir a instalação e reinicialização da IDE, na aba Servers, clique com o botão direito do mouse e selecione a opção New -> Server. No momento em que este caderno foi escrito, somente tínhamos a versão 8 do WildFly para instalar. Caso a versão 9 ou posteriores aparecem para você, selecione a última versão que for compatível com a o JEE 7. Esta informação está disponível no website do WildFly.

Você deverá criar um novo runtime para o servidor, através das telas mostradas nas figuras 8 e 9. Você deve deixar a configuração exatamente como mostrado nas figuras, com exceção do Execution Environment, que deverá respeitar a versão do Java utilizada por você na IDE, e do caminho de instalação do servidor, ambas na Figura 9.


17

FONTE: O autor

FONTE: O autor

FIGURA 8 - INSTALAÇÃO DO WILDFLY

Ao final, pressione Finish e estaremos prontos para testar a instalação de nosso servidor de aplicação. Na aba Server do Eclipse, deverá aparecer o servidor que acabamos de instalar. Clique com o botão direito no mouse no servidor e selecione a opção Start. O tempo necessário para a inicialização do WildFly dependerá diretamente do desempenho de seu computador. Automaticamente, o Eclipse seleciona a aba Console e várias mensagens geradas pelo WildFly aparecerão na tela. É vital que você se habitue a observar atentamente o console quando for testar suas aplicações, pois as mensagens de erro aparecem nesta aba.

FIGURA 9 - INSTALAÇÃO DO WILDFLY


18

Quando a inicialização do servidor encerrar, você deverá ver uma mensagem semelhante à destacada na Figura 10, indicando que o processo foi bem-sucedido. As mensagens acima da mensagem destacada e inclusive a versão e codinome do servidor podem variar, de acordo com o que foi selecionado e instalado nas etapas anteriores.

FIGURA 10 - INICIALIZAÇÃO DO WILDFLY

FONTE: O autor

FONTE: O autor

FIGURA 11 - PÁGINA INICIAL DO WILDFLY EXECUTANDO EM LOCALHOST

Por fim, para testarmos se a instalação foi bem-sucedida, devemos digitar a seguinte URL no navegador: <http://localhost:8080>. O navegador deverá mostrar a seguinte página, que é a página inicial do WildFly, que está executando localmente na porta 8080, conforme a Figura 11.

Caso você prefira utilizar uma IDE que já tenha o ambiente de Desenvolvimento completo embutido, pode utilizar o NetBeans, que já vem com uma implementação de referência da especificação JEE 7, conhecida como GlassFish. O procedimento para instalação do NetBeans será demonstrado a seguir.


19

FONTE: O autor

2 INSTALAÇÃO DO NETBEANS

O NetBeans é uma IDE desenvolvida pela Oracle que permite que você desenvolva aplicações desktop, web e mobile em Java, bem como aplicações com HTML5, JavaScript e CSS. A IDE possui ainda uma vasta gama de ferramentas para desenvolvedores PHP e C/C++. É gratuita, open source e tem uma grande comunidade de usuários e desenvolvedores ao redor do mundo (NETBEANS, 2015).

Ela pode ser obtida através do endereço <https://netbeans.org/downloads/index.html>, conforme a Figura 12. Neste endereço existem diversas versões para download, para diversos sistemas operacionais e em diversos idiomas. Você deve selecionar a opção destacada.

FIGURA 12 - DOWNLOAD DO NETBEANS

Essa versão possui diversas ferramentas embutidas, o que praticamente elimina a necessidade de configuração, além de dois servidores, o GlassFish e o Tomcat. Em nossa disciplina precisaremos do GlassFish, visto que o Tomcat não é um Application Server, mas sim um servlet container.

Uma vez feito o download, podemos proceder com a instalação do NetBeans. O instalador da ferramenta é bem simples e, embora demore um pouco para concluir todo o processo, exige pouca interação por parte do usuário. Na Figura 13 podemos perceber uma janela informando quais softwares serão instalados em seu computador.


20

FIGURA 13 - TELA DO INSTALADOR

FONTE: O autor

Caso deseje personalizar a instalação, retirando ou colocando itens, basta selecionar a opção “Personalizar”. Esta opção leva para a tela de configuração mostrada na Figura 14. Recomendamos que você mantenha todas as funcionalidades, com exceção do PHP e C/C++, que são completamente opcionais. O Tomcat deve ser selecionado pois, caso sua aplicação não utilize funcionalidades específicas de servidores de aplicação, ele representa uma opção mais leve e performática. Aprenderemos que funcionalidades específicas são essas ao longo do caderno.

A última tela antes da instalação propriamente dita é mostrada na Figura 15. Basta selecionar a opção onde você diz que aceita os termos da licença e clicar em finalizar. O instalador procederá automaticamente com a cópia, descompactação e download dos arquivos necessários ao NetBeans. Lembramos que a versão da ferramenta poderá variar, dependendo de quando você fará a leitura do caderno e download da mesma. O importante é sempre manter-se em versões superiores à utilizada aqui, aumentando a probabilidade de compatibilidade.


21

FIGURA 14 - CONFIGURAÇÃO DO INSTALADOR

FONTE: O autor

FIGURA 15 - CONTRATO DE LICENÇA

FONTE: O autor

Uma vez que a instalação foi concluída, ao abrir a IDE nos deparamos com a tela mostrada na Figura 16. Não é objetivo deste caderno a explicação das funcionalidades do NetBeans, visto que inclusive utilizaremos o Eclipse para o desenvolvimento de nossos exemplos. O Eclipse é melhor em algumas atividades e o NetBeans em outras. Com o tempo e a utilização, você elegerá a sua favorita.


22

FIGURA 16 - INTERFACE DO NETBEANS

FONTE: O autor

Tutoriais sobre o NetBeans podem ser acessados gratuitamente no endereço:<https://netbeans.org/kb/docs/java/quickstart-gui.html>.

ATENCAO

Para o desenvolvimento das aplicações, precisaremos estabelecer conexão com bancos de dados relacionais. A plataforma Java, através do JDBC e mais recentemente do JPA, permite a conexão com os principais players do mercado. Para facilitar o aprendizado e reduzir a configuração, trabalharemos com o banco de dados MySQL, que já foi utilizado por você em disciplinas anteriores.

3 INTEGRAÇÃO WILDFLY-MYSQL

Conforme K19 (2013), aplicações Java se comunicam com banco de dados através de conexões JDBC. Para estabelecer uma conexão JDBC, algumas informações como usuário, senha e base de dados são necessárias. As configurações relativas às conexões JDBC podem ser definidas nas aplicações ou nos servidores de aplicação. Em um servidor de aplicação, as configurações JDBC são definidas em componentes chamados Data Sources. Os Data Sources permitem que uma única configuração JDBC seja utilizada por diversas aplicações. Eles


23

também permitem que outros tipos de configurações sejam compartilhadas, como por exemplo, a configuração de um Connection Pool. Além disso, através de Data Sources podemos utilizar facilmente o serviço de transações dos servidores de aplicação. Esse serviço é definido pela especificação Java Transaction API (JTA), que será abordada na Unidade 3 deste Caderno de Estudos.

Inicialmente devemos fazer o download do driver jdbc para o MySQL, disponível em <http://dev.mysql.com/downloads/connector/j/>, conforme a Figura 17. É recomendável fazer o download do driver independente de plataforma, visto que ele funciona em qualquer sistema operacional.

Uma vez que o download foi concluído, passamos para a integração do driver com o WildFly. Lembramos que a função do driver JDBC é estabelecer a comunicação entre o Sistema Gerenciador de Banco de Dados Relacional (SGBDR) e a plataforma Java, neste caso, representado pelo servidor de aplicações.

FIGURA 17 - DRIVER JDBC

FONTE: O autor

O próximo passo consiste em copiar o driver para o diretório adequado dentro da instalação do WildFly. Inicialmente localize o diretório onde o WildFly está instalado e lá dentro, localize o diretório modules/com. Agora crie um diretório chamado mysql e, dentro deste, outro diretório chamado main. O driver MySQL deverá ser copiado para esta pasta recém criada. Crie também neste diretório um arquivo vazio chamado module.xml.


24

FIGURA 18 - LOCAL DO DRIVER JDBC

FONTE: O autor

FONTE: O autor

O conteúdo deste arquivo deverá ser igual ao da imagem abaixo, respeitando o nome do arquivo que você copiou para dentro da pasta após o atributo path, na linha 4. Este arquivo representará a instalação de um módulo adicional no WildFly. Ao encerrar, verifique o código fonte escrito com cuidado, salve e feche o arquivo.

FIGURA 19 - ARQUIVO MODULE.XML

A próxima (e última) etapa consiste na configuração do arquivo standalone.xml, disponível no caminho /standalone/configuration, no diretório de instalação do WildFly. Dentro deste arquivo, encontre a tag <datasources> e insira a configuração de um novo datasource e um novo driver, conforme mostrado na Figura 20. Caso já existam configurações para outros datasources e drivers, você não precisa excluí-los, uma vez que eles em geral servem como exemplo e o WildFly pode trabalhar com múltiplos datasources.


25

Na Figura 20 podemos ainda perceber o nome de nosso datasource (java:/MYSQL_DS), representado pelo número 1 e também o nome do módulo que instalamos no arquivo module.xml, representado pelo número 2. Outros aspectos importantes a serem destacados são o usuário e senha dentro da tag <security> e a url de conexão, dentro da tag <connection-url>. Estes valores deverão refletir a condição de seu SGBD. No caso deste exemplo, o usuário e senha do banco de dados são “root” e o nome da base de dados é JEE7. Faça as alterações de acordo com as configurações do MySQL instalado em seu computador. Ao encerrar, verifique o código fonte escrito com cuidado, salve e feche o arquivo.

FIGURA 20 - CRIAÇÃO DO DATASOURCE

FONTE: O autor

FONTE: O autor

Para podermos realizar os testes da configuração que acabamos de fazer, verifique se o MySQL está funcionando corretamente em seu computador, de outra forma, não podemos nos conectar com ele através do WildFly. Feita esta verificação, abra o Eclipse e encontre o WildFly na aba Servers, iniciando-o. Diversas mensagens aparecerão no console, sendo que ao final devemos encontrar a mesma mensagem que mostramos na Figura 10 desta unidade, o que demonstra que o servidor iniciou sem erros. A garantia de que o datasource foi configurado corretamente vem através de uma mensagem no console que mostra o nome de todos os datasources configurados para aquela instância do servidor de aplicação. No nosso caso, devemos buscar pelo nome java:/MYSQL_DS, conforme mostra a Figura 21.

FIGURA 21 - CONFIGURAÇÃO DEMONSTRADA NO CONSOLE


26

4 INTEGRAÇÃO GLASSFISH-MYSQL

Neste tópico, demonstraremos de que forma fazer a integração entre o MySQL e o Servidor de aplicações Glassfish através do NetBeans.

Em nossos exemplos, o Netbeans está configurado para o idioma inglês, ao invés do português que é instalado automaticamente. Caso deseja trocar o idioma, o procedimento é demonstrado em: <http://www.frameworksystem.com/blog/alterando-a-linguagem-no-netbeans/>.

ATENCAO

Inicialmente, acesse a aba Services, demonstrada na Figura 22. Nesta aba, clique com o botão direito no mouse na opção Databases, selecionando New Connection. Selecionando esta opção, aparecerá uma janela que permitirá selecionar a qual banco de dados nos conectaremos. Selecione a opção MySQL e o próprio Netbeans sugerirá um driver, conforme a Figura 23.

FIGURA 22 - INTEGRAÇÃO GLASSFISH-MYSQL

FONTE: O autor


27

FIGURA 23 - MYSQL JDBC DRIVER

FONTE: O autor

Pressione o botão Next e preencha as configurações mostradas na Figura 24 de acordo com as configurações do MySQL instalado em seu computador. Ao finalizar as configurações, pressione o botão Test Connection e aguarde pela mensagem Conection Succeeded, indicando que o Netbeans encontrou o banco de dados e conseguiu se conectar.

Antes de realizar o procedimento de teste da conexão, certifique-se de que o MySQL está funcionando corretamente em seu computador e de que o mesmo foi inicializado.

ATENCAO


28

FIGURA 24 - CONFIGURAÇÃO DO MYSQL

FONTE: O autor

Existem algumas configurações adicionais, mas com o objetivo de simplificar o processo de configuração, podemos pressionar o botão Finish e aguardar o resultado demonstrado na Figura 25. O número 1 mostra a nova conexão com o banco MySQL através de sua adição às databases. O número 2 indica os Schemas ou databases disponíveis no banco de dados com o qual nos conectamos. Em seu computador, o número dois trará Schemas diferentes dos mostrados na Figura.

Em nosso exemplo, a conexão foi renomeada para MYSQL_DS, selecionando a mesma com o botão direito e clicando na opção renomear. Este passo é opcional e não interferirá diretamente com o resto do procedimento. O importante é você conseguir encontrar a conexão que criou dentro do Netbeans.

Seguindo este procedimento, você configurou uma nova conexão com o banco de dados MySQL diretamente através do Netbeans. Para fazer a configuração do datasource e do pool de conexões, devemos acessar a interface de administrador do Glassfish, disponível na url <http://localhost:4848>, sem esquecer de antes inicializar o servidor dentro do Netbeans.


29

FIGURA 25 - CONEXÃO COM O MYSQL

FONTE: O autor

Para inicializar o Glassfish, basta ir até a aba Services e escolher a opção Server. Dentre os servidores listados, clique com o botão direito do mouse no Glassfish e em seguinda na opção Start, conforme a Figura 26. Quando o servidor terminar seu processo de inicialização, você pode ir até o navegador web e digitar a URL supracitada.

Pronto! Você agora está na interface de administração do Glassfish (Figura 27). Da mesma forma que no WildFly, existem inúmeras configurações que podem ser feitas para otimizar o desempenho e performance do servidor de aplicação, mas como este não é o objetivo desta disciplina, faremos as configurações mínimas necessárias para o funcionamento dos exemplos que utilizaremos.


30

FIGURA 26 - INICIALIZAÇÃO DO GLASSFISH

FONTE: O autor

FONTE: O autor

FIGURA 27 - INTERFACE DE ADMINISTRAÇÃO DO GLASSFISH


31

FONTE: O autor

Uma vez na interface de administração, selecione a opção JDBC/JDBC Connection Pools, onde criaremos o pool de conexões para nosso datasource. Um pool de conexões é uma espécie de cache de conexões com o banco de dados, mantidas de forma que possam ser reutilizadas quando futuras requisições forem feitas, otimizando recursos computacionais. A próxima tela lista todos os pools já existentes e, para criar um novo pool, clique no botão New. A Figura 28 mostra as configurações do primeiro passo para a criação do pool. Após preencher estas configurações, clique em Next.

FIGURA 28 - CONFIGURAÇÃO DO POOL DE CONEXÕES

Na tela seguinte existem vários campos que permitem configuração, mas para nossa finalidade, devemos alterar somente as propriedades adicionais listadas na Tabela 1:

TABELA 1 - PROPRIEDADES DO POOL DE CONEXÕES

FONTE: O autor

Propriedade Valoruser <usuário do seu banco de dados MySQL>

ServerName localhostDatabaseName jee7

Password <senha do seu banco de dados MySQL>Url jdbc:mysql://localhost:3306/jee7

URL jdbc:mysql://localhost:3306/jee7

Para concluir o processo, clique em Finish e aguarde a criação do novo pool de conexões. Ao final, o Glassfish exibirá todos os pools de conexão disponíveis, entre os quais deverá estar o que você acabou de criar (Figura 29).


32

FIGURA 29 - LISTAGEM DOS POOLS DE CONEXÃO

FONTE: O autor

Ao clicar no pool recém criado, você será levado a uma tela que permite o teste do mesmo através do botão Ping. Se o pool estiver funcionando, haverá uma mensagem informando que o ping foi bem sucedido (Figura 30).

FIGURA 30 - TESTE DO POOL DE CONEXÕES

FONTE: O autor

Como último passo do processo, precisaremos criar o datasource propriamente dito. Ainda na interface de administração do Glassfish, selecione a opção JDBC/JDBC Resources. Nesta tela estão listados todos os datasources disponíveis no Glassfish. Para criar um novo, clique no botão New e preencha as configurações da tela seguinte conforme demonstrado na Figura 31.


33

FIGURA 31 - CONFIGURAÇÃO DO DATASOURCE

FONTE: O autor

JNDI é o acrônimo de Java Naming and Directory Interface, cujo objetivo é permitir a busca de objetos de forma distribuída simplesmente através de um nome. Com essa tecnologia, o cliente abstrai totalmente os detalhes referentes à implementação do recurso que está sendo buscado. Maiores detalhes sobre o JNDI podem ser obtidos em: <http://docs.oracle.com/javase/tutorial/jndi/overview/>.

ATENCAO

Assim encerramos o processo de criação dos DataSources nos servidores de aplicação e IDEs que você poderá utilizar ao longo da disciplina. Agora estamos prontos para efetivamente pôr a “mão na massa” e começar a fazer os exercícios e criar nossas próprias aplicações utilizando JEE 7 e os servidores de aplicação WildFly e Glassfish. Caso você queira utilizar o Glassfish com o Eclipse ou o WildFly com o Netbeans, basta configurá-los da forma como demonstramos ao longo deste tópico.

34

RESUMO DO TÓPICO 2


• De modo a podermos desenvolver, implantar e testar aplicações que utilizem as tecnologias que fazem parte da especificação JEE, precisamos de um servidor de aplicação - application server (AS).

• Entre as principais opções estão o Wildfly Application Server, disponibilizado pela Red Hat e o GlassFish Application Server, disponibilizado pela Oracle.

• Para desenvolver aplicações corporativas podemos utilizar o Netbeans ou o Eclipse, bastando configurá-lo para acessar o AS.

• O servidor de aplicação disponibiliza serviços de persistência através de JDBC, JPA e JTA, havendo necessidade de configuração de fontes de dados (Datasources) para que os serviços funcionem.

35

1 Com a IDE Eclipse já instalada, apresente os passos para adicionar o WildFly ao Eclipse?

2 Configure mais um datasource para cada servidor de aplicação, preferencialmente utilizando um banco de dados diferente do MySQL:

3 Encontre e descreva pelo menos mais três implementações de Servidores de Aplicação compatíveis com a especificação JEE 7. Estes servidores de aplicação podem ser tanto proprietários como open source.

4 A linguagem de programação Java possui vários frameworks de desenvolvimento, cada um com sua vantagem. Neste contexto, o JSF é um deles, e seu funcionamento é baseado em objetos. Referente ao framework JSF, analise as afirmativas a seguir:

I- O JSF é baseado em objetos que são mantidos em memória no servidor.II- O JSF é baseado em objetos que são responsáveis pela geração do HTML

enviado ao navegador.III- Os objetos em que o JSF se baseia, não possuem a capacidade de manter valores

em seu estado, não permitindo sua recuperação após várias requisições.IV- A interface da aplicação em JSF é implementada em um arquivo xHTML.

Agora assinale a alternative CORRETA:a) ( ) I, II e IVb) ( ) II e IIIc) ( ) I, II e IIId) ( ) II, III e IV

5 Existem várias tecnologias que fazem parte da especificação JEE, porém para implementar e testar aplicações web JEE, é necessário um servidor de aplicação. Referente especificações JEE e servidores de aplicação, analise as afirmativas a seguir:

I- O WildFly Application Server, conhecido anteriomente como JBoss.II- Na IDE Eclipse, servidores de aplicação são disponibilizados na guia

“Servers”.III- Caso as configurações do WildFly estejam originais, a aplicação é acessível

no navegador de internet pela URL “http://localhost:8080”.IV- A IDE NetBeans não possui o servidor de aplicação GlassFish embutido.

Agora assinale a alternativa que apresenta as sentenças CORRETAS:a) ( ) I, II e IIIb) ( ) II e IIIc) ( ) I, II e IVd) ( ) II, III e IV

AUTOATIVIDADE

36

37

TÓPICO 3

JAVA SERVER FACES (JSF)

UNIDADE 1

1 INTRODUÇÃO

O Java Server Faces (JSF) é o framework padrão da plataforma Java para a construção de aplicações web com JEE. Ele define e implementa um modelo de componentes visuais para WEB, utilizando uma arquitetura MVC (model-view-controller). Esta arquitetura propõe a divisão das responsabilidades de uma aplicação em três camadas distintas (Figura 32):

1. View: responsável pela renderização da interface gráfica da aplicação.2. Controller: responsável por receber e tratar os eventos da View.3. Model: responsável pela implementação da lógica de negócios.

FIGURA 32 - ARQUITETURA MVC

FONTE: Disponível em: <https://bit.ly/3R7jWzK>. Acesso em: 20 set. 2015.

Da mesma forma que as demais tecnologias que fazem parte da plataforma Java, o JSF é definido por uma especificação mantida pelo JCP através de JSRs. Ele define uma API padrão e extensível através de classes e interfaces, simplificando o desenvolvimento e aumentando a produtividade de aplicações em Java para Web.

As principais funcionalidades que o JSF traz para uma aplicação web incluem (SOFTPLAN, 2015):

38


FIGURA 33 - ARQUITETURA DO JSF

FONTE: SOFTPLAN, 2015

• Gerenciamento do ciclo de vida dos componentes visuais e a responsabilidade na geração do HTML a partir deles.

• Disponibilização de uma biblioteca de componentes visuais básicos análogos aos componentes HTML.

• Suporte à templates de tela para reuso de estruturas de interfaces Web;• Desenvolvimento de componentes visuais personalizados;• Suporte embutido à ajax.• Validação, conversão e formatação de dados de formulários.• Tratamento de eventos entre telas Web.• Gerenciamento da navegabilidade da aplicação.

O JSF funciona baseado em objetos que são mantidos em memória no servidor e que ficam responsáveis pela geração do HTML que será enviado ao navegador. Esta estratégia permite que os valores contidos nos componentes mantenham seu estado, permitindo sua recuperação mesmo após várias requisições. O objetivo desta arquitetura é a limitação imposta pela característica stateless do HTTP.

A Figura 33, retirada de SOFTPLAN (2015), exemplifica o funcionamento do JSF. Imagine um cliente que faz uma primeira requisição para uma aplicação web em um AS. O JSF utiliza um arquivo no formato xHTML para descrever uma interface da aplicação. Quando o recurso representado por esse arquivo é solicitado, uma árvore de componentes é gerada no servidor e um HTML é enviado ao cliente. Para as próximas requisições a este recurso pelo mesmo cliente, o servidor utiliza a árvore já em memória para montar o HTML. Este processo faz parte do ciclo de vida do JSF.

2 CRIAÇÃO DA PRIMEIRA APLICAÇÃOVamos agora demonstrar como criar uma pequena aplicação utilizando as

capacidades básicas do JSF. Abra o Eclipse e selecione um projeto do tipo Dynamic Web Project, conforme a Figura 34.

TÓPICO 3 | JAVA SERVER FACES (JSF)

39

FIGURA 34 - CRIAÇÃO DO PROJETO NO ECLIPSE

FONTE: O autor.

A próxima etapa consiste em configurar o projeto de forma que ele permita a utilização das tecnologias que veremos ao longo do caderno. A Figura 35 ilustra a interface de configuração deste tipo de projeto. Os números 1, 2 e 3 destacam o nome do projeto, o AS que utilizaremos e quais APIs farão parte do projeto, respectivamente.

Para o nome do projeto, você pode colocar o que achar mais adequado. O Servidor de Aplicação que utilizaremos será o mesmo que instalamos no tópico anterior, o WildFly. A configuração, entretanto, exige um pouco mais de cuidado. Clicando no botão modify, a imagem da Figura 36 permite que selecionemos somente as APIs que utilizaremos no projeto. Para o nosso projeto, selecione as mesmas APIs da figura e clique no botão OK.

FIGURA 35 - CONFIGURAÇÃO DO PROJETO

FONTE: O autor.

40


De volta a tela principal de configuração, prossiga clicando no botão Next até encontrar a tela mostrada na Figura 37. Esta é a tela de configuração da implementação para o JPA. Sugerimos configurar exatamente como mostrado na figura, pois embora não iremos utilizar JPA no primeiro exemplo, a configuração do mesmo neste momento nos poupará esforço futuro. Não se esqueça de configurar também a conexão com o MySQL.

FIGURA 36 - APIS UTILIZADAS

FONTE: O autor.

FIGURA 37 - CONFIGURAÇÃO DO JPA

FONTE: O autor.


41

Prossiga pressionando o botão Next até se deparar com a tela mostrada na Figura 38. Esta tela configura a geração automática do arquivo beans.xml, necessário para se utilizar CDI. Mantenha a configuração como na figura e pressione o botão Finish.

FIGURA 38 - CONFIGURAÇÃO DO CDI

FONTE: O autor

FONTE: O autor

Pronto! A partir de agora utilizaremos este projeto para nossos exemplos. Para conferir se a criação foi feita corretamente, basta expandir o projeto recém-criado no Eclipse. A estrutura de diretórios deve ficar semelhante à mostrada na Figura 39.

FIGURA 39 - ESTRUTURA DO PROJETO

Para criar nosso primeiro JSF, clique com o botão direito do mouse no diretório WebContent e selecione a opção New XHTML Page. Dê o nome formulario.xhtml para a mesma e clique no botão Next. Na tela apresentada a seguir, mantenha a configuração mostrada na Figura a seguir e clique em Finish. Isso criará um template XHTML vazio para nossa aplicação.

42


FIGURA 40 - CONFIGURAÇÃO DO TEMPLATE XHTML

FONTE: O autor

O Eclipse gera um template vazio para uma página XHTML, entretanto, a importação das bibliotecas que contém os componentes visuais já está feita. Na Figura 41 podemos perceber a existência destas bibliotecas e sua efetiva utilização.

Entre as linhas 2 e 5 são referenciadas URLs através dos prefixos ui, f e h. Estes prefixos servirão para utilizar os componentes visuais, de acordo com sua natureza. Isto pode ser percebido através do componente head que aqui ele é <h:head>, o que indica que a importação ocorrerá através da URL referenciado no prefixo h.

O exemplo contendo o código fonte completo pode ser visualizado na Figura 42. A linha 1 foi removida para simplificar o exemplo. Da mesma forma que no HTML, os componentes visíveis ficam dentro da tag <body>. Na linha 11 criamos um formulário que contém um Label, um InputText e um Button, todos componentes visuais do JSF. O InputText é mapeado diretamente para um atributo do formularioMB e o Button é mapeado diretamente para um método do mesmo arquivo. No exemplo em questão, não faremos a criação do model e utilizaremos o controller para simular esta função.


43

Note que este mapeamento de um componente de formulário diretamente para um atributo e de um botão diretamente para um método aumenta muito a produtividade no desenvolvimento. Em algumas IDEs, é possível inclusive gerar Views e Controllers automaticamente a partir de classes de domínio.

FIGURA 41 - IMPORTAÇÃO DAS BIBLIOTECAS

FONTE: O autor

FIGURA 42 - CÓDIGO FONTE DO ARQUIVO JSF

FONTE: O autor

Mas o que é o formularioMB? O JSF funciona através de uma arquitetura MVC, o que exige a presença de um intermediário entre o model e a view. Este intermediário é o controller, que no caso do JSF é chamado de Managed Bean (MB). Cabe ao MB mapear os componentes para o model, instanciar os objetos no lado do servidor e também reagir aos eventos gerados na view.

O MB sempre é uma classe serializável com métodos getters e setters para permitir o acesso aos componentes visuais. A figura a seguir mostra o código-fonte de um MB. Inicialmente, a anotação named permite que o MB seja visualizado dentro dos arquivos XHTML. É por causa desta anotação que conseguimos referenciar métodos públicos e atributos do MB. A anotação @RequestScoped indica que o escopo do MB é de request, ou seja, os valores da árvore de objetos devem ser mantidos somente durante o request.

44


FIGURA 43 – CÓDIGO-FONTE DO MB

FONTE: O autor

Para este exemplo utilizamos uma String como o objeto de domínio, para fins de simplificação. Na verdade, o MB segue a convenção Java Bean: métodos getters e setters para todos os atributos, um construtor vazio e a implementação da interface Serializable. O método executar serve simplesmente para ilustrarmos o funcionamento do botão.

Para criar esta classe, expanda o diretório Java Resources de seu projeto e clique com o botão direito do mouse no diretório src. Selecione a opção Java Class e copie o código-fonte contido na imagem do MB. Atenção para o nome do pacote, pois o utilizaremos nos exemplos posteriores. Uma vez que a classe esteja pronta, clique com o botão direito do mouse no arquivo formulario.xhml e selecione a opção Run on Server.


45

FIGURA 44 - DEPLOYMENT E EXECUÇÃO DO PROJETO

FONTE: O autor

FONTE: O autor

Ao seguir este procedimento, a aplicação então é exibida no navegador interno do Eclipse. Ao testá-la, podemos ver mensagens sendo exibidas no console do AS.

3 CICLO DE VIDA E ESCOPOS DO JSFPara entendermos de que forma o JSF se comporta na questão da árvore

de objetos em memória, e consequentemente extrairmos o máximo da tecnologia, é essencial entender o ciclo de vida e os escopos do JSF.

FIGURA 45 - TESTE DA APLICAÇÃO JSF

46


Conforme SOFTPLAN (2015), o ciclo de vida do JSF é simplesmente a sequência dos passos que o Front Controller do JSF executa ao receber uma requisição de um cliente, conforme descrito a seguir:

1. O primeiro passo é a restauração da árvore de componentes. Caso seja o primeiro acesso daquele cliente, o JSF cria a árvore de acordo com a descrição do arquivo .xhtml. Caso não seja o primeiro acesso, a árvore é recuperada da memória no servidor.

2. O segundo passo é a extração dos valores de campos de formulários vindos com a requisição e atribuição dos mesmos aos respectivos componentes dentro da árvore, atualizando-os. Neste momento ocorre também a conversão dos dados.

3. O terceiro passo consiste na validação dos valores dos componentes que possuírem regras de validação associadas. Por exemplo, um campo obrigatório que é submetido sem nenhum valor ou um campo numérico que vem com um valor alfanumérico. Neste passo, caso alguma das validações não seja bem sucedida, o JSF interrompe seu ciclo de vida retornando para o navegador do usuário com uma mensagem de erro.

4. Caso a validação seja bem sucedida, o próximo passo é atualizar os valores dos campos dentro do Managed Bean. Neste momento, todos os métodos setters dentro do MB serão invocados.

5. Neste passo os métodos associados a ações de botões são executados dentro do MB.

6. Aqui o JSF gera o HTML a ser enviado para o usuário com base na árvore de componentes. Antes disso, os valores dos componentes são extraídos do MB, através da invocação de todos os métodos getters. Quando o processo encerra, o HTML é finalmente enviado ao navegador.

O Front Controller é um padrão de projeto relacionado a aplicações web. Consiste basicamente de um ponto central de entrada que gerencia as requisições de usuários. É o que ocorre com o JSF. Maiores detalhes podem ser obtidos em: <http://www.martinfowler.com/eaaCatalog/frontController.html>.

ATENCAO

Faremos a seguir algumas modificações em nosso exemplo anterior que permitirão a compreensão deste mecanismo. A primeira etapa já está pronta e consiste na impressão de uma mensagem no momento em que o construtor vazio do MB é invocado. Colocaremos mensagens ainda dentro do método getNome() e do método setNome(), conforme ilustrado na Figura 46.


47

Agora faremos novamente a publicação da aplicação, clicando com o botão direito do mouse sobre o arquivo formulario.xhtml e selecionando a opção Run As->Run On Server. Essa ação permitirá a visualização das alterações em nosso exemplo.

FIGURA 46 - O CICLO DE VIDA DO JSF

FONTE: O autor

Na Figura 47, podemos perceber que a aplicação carregou normalmente no navegador, mas o importante é conseguir observar as mensagens do console. Neste caso, o construtor do MB foi invocado e também o método getter. É possível ainda notar que duas instâncias do MB são criadas, ao invés de somente uma. O motivo para tal comportamento será explicado na Unidade 3 deste Caderno de Estudos.

Mas por que o valor de nome é igual a null? Isso ocorre devido ao próprio ciclo de vida do JSF, onde o MB é instanciado e, como esta é a primeira requisição, a árvore de componentes deve ser montada com base no arquivo xhtml e alocada na memória. O último passo antes de renderizar o HTML é atribuir os valores do MB aos componentes visuais. Como nosso MB não possui nenhum valor, o getNome aparece retornando null.

48


FONTE: O autor

FIGURA 47 - CICLO DE VIDA DO JSF

Mas o que acontece quando colocamos um valor para Nome e clicamos em executar? Faça o teste em sua aplicação que eu explicarei os resultados obtidos aqui. Depois da primeira requisição, ciclo de vida do JSF é executado sempre da mesma forma, como podemos avaliar observando a Figura 48.

Cada número indica um passo do ciclo de vida. A linha destacada pelo número 1 ilustra a criação de uma nova instância do MB, enquanto a linha 2 trata da busca da árvore dos componentes visuais e dos valores dos atributos do MB. Por enquanto o nome continua nulo. Na linha destacada pelo número 3, os métodos setters do MB são invocados e, como agora possuímos o valor “Catarina” no componente associado ao nome, o MB recebe este valor. O número 4 mostra as duas linhas que são impressas ao invocarmos o método executar. Lembre-se de que a ação que efetivamente faz essa invocação é o clique no botão. Por fim, o número 5 trata da renderização dos componentes em HTML para envio ao navegador. Neste passo, o valor dos componentes é atualizado com o valor existente no atributo do MB associado através da expression language.


49

FIGURA 48 - CONTINUAÇÃO DO CICLO DE VIDA JSF

FONTE: O autor

Cada vez que você clicar no botão Executar, uma nova instância de FormularioMB é criada e o getNome retornará null. Este comportamento é característico da annotation @RequestScoped, onde uma nova instância de FormularioMB é criada a cada requisição do usuário. Esta anotação define que o tempo de vida deste objeto é marcado pela requisição do usuário.

Outro escopo existente é o SessionScope, onde o tempo de vida do MB é marcado pela sessão do usuário. Caso nenhuma configuração adicional seja feita, o MB se mantém desde pressionarmos o botão até fecharmos o navegador. Este tipo de escopo é interessante para guardar uma sessão de login do usuário, garantindo que ele tenha passado por uma página e se identificado antes de acessar a parte protegida de uma aplicação. Você já deve ter visto aplicações web onde o tempo de sessão é definido em minutos, para aumentar a segurança. Em geral, este tipo de configuração é utilizado em aplicações de Home Banking e cartões de crédito.

Na figura a seguir demonstramos como alterar o escopo de nosso MB para Session. Basta alterar a annotation @RequestScoped para @SessionScoped. Perceba que o comportamento da primeira e segunda vez que executamos (1) é o mesmo do @RequestScoped, entretanto, no terceiro acesso (2), o método getNome busca o valor já existente no MB, agora persistente entre as requisições do usuário. No próximo passo, o método setter é invocado e o nome Catarina é substituído por Cecilia no MB (3). O método executar é invocado novamente (4) e, finalmente, o HTML é renderizado com o valor atualizado no componente, obtido através do método getNome (5).

50


FONTE: O autor

FIGURA 49 - MANAGED BEAN COM ESCOPO DE SESSÃO

Uma experiência interessante para comprovar o funcionamento deste escopo é pegar a URL do navegador interno do Eclipse, copiá-la e acessar a aplicação através de um navegador externo. Mas espere aí... os valores que eu coloquei não aparecem fora do Eclipse. Isto ocorre porque o AS trata este acesso como um segundo acesso feito por outro usuário. Se você observar os logs do servidor, perceberá que ele obedecerá o mesmo ciclo de vida. Mas e por que ele não cria uma nova instância do MB? Isto significa que os valores se confundirão entre os usuários? Vou responder a esta pergunta com outra. Você se lembra de quando acessamos nossa aplicação pela primeira vez e o servidor criou duas instâncias do FormularioMB? O segundo usuário está acessando nossa aplicação através daquela segunda instância, que o AS já criou para evitar o overhead de instanciação de um novo objeto e melhorar a performance da aplicação. Lembrando que esta característica é configurável.

A última experiência consiste em abrir uma instância da aplicação através de outro navegador (se você abriu o Chrome, tente acessar a aplicação do Firefox e, em último caso, do Internet Explorer). Observando o log no console, percebemos que o mesmo mostra a criação de uma nova instância do FormularioMB, pois para o servidor somos um novo usuário e nossas duas instâncias iniciais já estão ocupadas.


51

Existem outros escopos no JSF além do Request e Session. Para maiores detalhes acesse: http://uaihebert.com/jsf-mini-livro-dicas-conceitos-e-boas-praticas/

ATENCAO

Nesta unidade percorremos bastante conteúdo... entendemos o contexto onde são aplicadas as aplicações JEE, compreendemos a necessidade de um servidor de aplicação, criamos e configuramos um ambiente para a criação de aplicações enterprise e, por fim, introduzimos as Java Server Faces de forma prática, enfatizando a caracterização de sua arquitetura e seu ciclo de vida. Nas próximas unidades abordaremos aspectos avançados de JSF e demonstraremos o funcionamento de outras tecnologias chave que fazem parte da especificação JEE, como CDI e EJB. Novamente queremos destacar a necessidade de realização das autoatividades e de todas as implementações que são solicitadas no caderno. É somente através da prática que você alcançará a compreensão deste conteúco. Nos veremos na próxima unidade.

Até lá e bons estudos!

52


LEITURA COMPLEMENTAR

Artigo disponível em: <http://www.devmedia.com.br/introducao-ao-padrao-mvc/29308>.

INTRODUÇÃO AO PADRÃO DE PROJETO MODEL,VIEW, CONTROLLER

1 Introdução

Na fase de Projeto começamos a nos preocupar com a arquitetura da aplicação. Nesta fase damos realmente valor à tecnologia, diferente da fase de análise onde ainda estamos esboçando o problema a ser resolvido. Definimos a plataforma e como os componentes do sistema irão se organizar. Evidentemente que os requisitos ainda são importantes, pois, por exemplo, um sistema Web ou então uma aplicação de tempo real deverá influenciar na arquitetura.

Mesmo não possuindo uma definição consensual, afinal diversos livros, artigos ou autores definem o que é arquitetura da sua forma, a arquitetura de software de um sistema computacional pode ser definida como as suas estruturas, que são compostas de elementos de software, de propriedades externamente visíveis desses componentes, e do relacionamento entre eles. Ou seja, a arquitetura define os elementos de software e como eles interagem entre si.

Para realizar a arquitetura de uma aplicação não basta estar num dia inspirado ou acordar com bastante vontade de realizar uma arquitetura, muito pelo contrário, precisamos de bastante experiência em diferentes organizações, diferentes tipos de projetos, conhecimentos de diferentes arquiteturas etc. A experiência prática ainda é a melhor solução. O trabalho em equipe também é uma forma excelente de definir uma arquitetura. Muitas vezes, alguns programadores possuem outras experiências ou conhecimentos e a troca dessa experiência é sempre válida, mesmo quando temos um arquiteto bastante experiente na equipe.

A arquitetura de um sistema tem diversos elementos como: elementos utilitários, elementos de interação, elementos que fazem parte do domínio do problema, elementos de conexão, elementos de persistência etc. Dessa forma, na arquitetura sempre definimos os seus elementos que precisarão ser utilizados no software e como eles se conectam. Uma arquitetura complexa exige mais tempo para desenvolvimento, porém, através de geração automática de aplicações isso pode se tornar mais produtivo. Por isso algumas equipes definem um framework para uma determinada aplicação, assim podemos utilizar muitas coisas pré-prontas que facilitam o desenvolvimento.


53

No entanto, alguns padrões arquiteturais já foram pensados para resolver problemas corriqueiros. Alguns projetos ou organizações combinam esses padrões arquiteturais, pois atendem melhor às suas necessidades ou deram certo para o seu tipo de aplicação. Por isso é sempre interessante entender as características básicas de cada um dos estilos e escolher ou combinar aqueles que atendem melhor às necessidades de um projeto específico, isso tudo deve ser feito após uma análise do sistema a ser desenvolvido. Entre as arquiteturas existentes temos: Cliente-servidor, P2P - Peer to Peer, Dados compartilhados, Máquina virtual, Camadas, MVC e muitos outros.

No restante do artigo veremos mais sobre o padrão arquitetural MVC (Model-View-Controller) que é um dos mais antigos e mais utilizados atualmente.

2 Padrão Model-View-Controller

O padrão arquitetural Model-View-Controller (MVC) é uma forma de quebrar uma aplicação, ou até mesmo um pedaço da interface de uma aplicação, em três partes: o modelo, a visão e o controlador.

O MVC inicialmente foi desenvolvido no intuito de mapear o método tradicional de entrada, processamento, e saída que os diversos programas baseados em GUI utilizavam. No padrão MVC, teríamos então o mapeamento de cada uma dessas três partes para o padrão MVC conforme ilustra a imagem abaixo:

FIGURA 1: MAPEAMENTO DAS TRÊS PARTES DE UMA APLICAÇÃO PARA O MVC

A figura abaixo demonstra que a entrada do usuário, a modelagem do mundo externo e o feedback visual para o usuário são separados e gerenciados pelos objetos Modelo (Model), Visão (View) e Controlador (Controller).

FIGURA 2: OBJETOS UTILIZADOS NO MVC E SUAS INTERAÇÕES

54


Explicando cada um dos objetos do padrão MVC tem-se primeiramente o controlador (Controller) que interpreta as entradas do mouse ou do teclado enviado pelo usuário e mapeia essas ações do usuário em comandos que são enviados para o modelo (Model) e/ou para a janela de visualização (View) para efetuar a alteração apropriada. Por sua vez o modelo (Model) gerencia um ou mais elementos de dados, responde a perguntas sobre o seu estado e responde a instruções para mudar de estado. O modelo sabe o que o aplicativo quer fazer e é a principal estrutura computacional da arquitetura, pois é ele quem modela o problema que está se tentando resolver. Por fim, a visão (View) gerencia a área retangular do display e é responsável por apresentar as informações para o usuário através de uma combinação de gráficos e textos. A visão não sabe nada sobre o que a aplicação está atualmente fazendo, tudo que ela realmente faz é receber instruções do controle e informações do modelo e então exibir elas. A visão também se comunica de volta com o modelo e com o controlador para reportar o seu estado.

Tão importante quanto explicar cada um dos objetos do padrão arquitetural MVC é explicar como é o seu fluxo tipicamente. Primeiramente o usuário interage com a interface (por exemplo, pressionando um botão) e o controlador gerenciar esse evento de entrada da interface do usuário. A interface do usuário é exibida pela visão (view), mas controlada pelo controlador. O controlador não tem nenhum conhecimento direto da View, ele apenas envia mensagens quando ela precisa de algo na tela atualizado. O controlador acessa o modelo, possivelmente atualizando ela de forma apropriada para as ações do usuário (por exemplo, o controlador solicita ao modelo que o carrinho de compras seja atualizado pelo modelo, pois o usuário incluiu um novo item). Isto normalmente causa uma alteração no estado do modelo tanto quanto nas informações. Por fim, a visão usa o modelo para gerar uma interface com o usuário apropriada. A visão recebe as informações do modelo. O modelo não tem conhecimento direto da visão. Ele apenas responde a requisições por informações de quem quer que seja e requisita por transformações nas informações feitas pelo controlador. Após isso, o controlador, como um gerenciador da interface do usuário, aguarda por mais interações do usuário, onde inicia novamente todo o ciclo.

Portanto, a principal ideia do padrão arquitetural MVC é a separação dos conceitos - e do código. O MVC é como a clássica programação orientada a objetos, ou seja, criar objetos que escondem as suas informações e como elas são manipuladas e então apresentar apenas uma simples interface para o mundo. Entre as diversas vantagens do padrão MVC estão a possibilidade de reescrita da GUI ou do Controller sem alterar o nosso modelo, reutilização da GUI para diferentes aplicações com pouco esforço, facilidade na manutenção e adição de recursos, reaproveitamento de código, facilidade de manter o código sempre limpo etc.

3 Implementação do MVC

Existem diversos frameworks para Java que implementam o padrão MVC e são muito utilizados em diversos projetos. Entre eles temos o JSF, Struts 1 e Struts 2, Spring MVC, Play Framework, Tapestry, e diversos outros. Existem


55

diversos artigos e sites especializados que comparam as diferenças e vantagens entre esses diferentes frameworks. No entanto, o melhor é sempre verificar o que cada framework disponibiliza para os desenvolvedores e analisar se ele atende às nossas expectativas.

Outras linguagens/plataformas também possuem frameworks que aderem ao padrão arquitetural MVC. Isso não inviabiliza que uma equipe crie o seu próprio framework, mas é preciso lembrar que um desenvolvedor novo precisa de tempo para aprender a desenvolver em determinada arquitetura e caso a empresa/projeto já utilize um framework bastante popular a curva de aprendizado será bem menor ou praticamente nula. Isso inclusive ajuda na contratação de novos funcionários, onde a empresa já pode exigir como pré-requisito conhecimentos neste framework.

4 Conclusão

Neste artigo, vimos o que é a arquitetura de software, quais são seus elementos, o que são as suas interações. Também vimos mais detalhadamente o padrão de arquitetura de software MVC (Model-View-Controller) que é muito utilizado nos projetos de software. Analisamos os seus elementos e como eles interagem entre si e, além disso, vimos as principais vantagens de adotar um padrão como o MVC que se caracteriza pela facilidade na obtenção de múltiplas visões dos mesmos dados, desacoplar a interface da lógica da aplicação, entre outras vantagens. No entanto, vimos que definir a arquitetura de um software é ainda mais do que escolher o seu padrão arquitetural, precisamos definir a tecnologia (JEE ou .Net), linguagens a integrar, forma de persistência, interfaces com o usuário e muito mais. Dessa forma, devemos sempre reunir o máximo de pessoas experientes possíveis, conhecimentos, análise do projeto, todos os seus requisitos funcionais e não funcionais, a fim de definirmos a melhor arquitetura possível para o software que está sendo desenvolvido.

56

RESUMO DO TÓPICO 3

Neste tópico vimos que:

• O Java Server Faces (JSF) é o framework padrão da plataforma Java para a construção de aplicações web com JEE.

• Da mesma forma que as demais tecnologias que fazem parte da plataforma Java, o JSF é definido por uma especificação mantida pelo JCP através de JSRs.

• O JSF funciona baseado em objetos que são mantidos em memória no servidor e que ficam responsáveis pela geração do HTML que será enviado ao navegador.

• Note que este mapeamento de um componente de formulário diretamente para um atributo e de um botão diretamente para um método aumenta muito a produtividade no desenvolvimento.

• O JSF funciona através de uma arquitetura MVC, o que exige a presença de um intermediário entre o model e a view. Este intermediário é o controller, que no caso do JSF é chamado de Managed Bean (MB).

• Cabe ao MB mapear os componentes para o model, instanciar os objetos no lado do servidor e também reagir aos eventos gerados na view.

• O MB sempre é uma classe serializável com métodos getters e setters para permitir o acesso aos componentes visuais.

• No escopo marcado pela anotação @SessionScoped o tempo de vida do MB é marcado pela sessão do usuário. Caso nenhuma configuração adicional seja feita, o MB se mantém desde pressionarmos o botão até fecharmos o navegador. O escopo de Sessão é interessante para guardar uma sessão de login do usuário, garantindo que ele tenha passado por uma página e se identificado antes de acessar a parte protegida de uma aplicação.

57

1 O JSF é um framework da plataforma Java, cujo funcionamento é baseado em objetos, os quais são mantidos no servidor de aplicação. Referente ao framework JSF, analise as afirmativas a seguir:

I- O JSF funciona através da arquitetura MVC.II- O Managed Bean (MB) funciona como intermediário entre as camadas

Model e View.III- O Managed Bean (MB) não consegue instanciar objetos no lado do servidor,

porém reage a eventos da camada View.IV- A classe que implementa um Managed Bean (MB) não deve ser serializável,

o que permite o acesso aos componentes.

Agora assinale a alternativa que apresenta as afirmaticas CORRETAS:a) ( ) I e IIb) ( ) II e IIIc) ( ) I, II e IIId) ( ) II, III e IV

2 Diferencie e descreva a aplicabilidade das anotações @RequestScoped e @SessionScoped:

3 Implemente uma aplicação que contenha uma tela de login e senha utilizando o JSF. Deve existir um MB que verifica os valores para ver se são iguais a “admin” para o login e “admin” para a senha. Após a validação ou não dos valores, uma mensagem deverá ser exibida no console do AS.

4 A linguagem de programação Java permite o desenvolvimento de aplicações robustas, atendendo tanto pequenas quanto grandes empresas., disponibilizando a vários frameworks de desenvolvimento. Referente ao framework JSF (Java Server Faces), estudado nesta disciplina, analise as afirmativas a seguir:

I- O JSF permite o desenvolvimento de aplicações web.II- O JSF utiliza a arquitetura de desenvolvimento de componentes chamado

MVC (Model-View-Controller).III- O JSF não possui o gerenciamento do ciclo de vida dos componentes

visuais.IV- O JSF não possui suporte a funcionalidade ajax.

Agora assinale a alternative CORRETA:a) ( ) Apenas as afirmativas I e II estão corretasb) ( ) Apenas as afirmativas II e III estão corretasc) ( ) Apenas as afirmativas I, II e III estão corretasd) ( ) Apenas as afirmativas II, III e IV estão corretas

AUTOATIVIDADE

58

5 O framework JSF (Java Server Faces), permite o desenvolvimento de aplicações robustas e com vários recursos que facilitam o desenvolvimento. O JSF utiliza classes Managed Beans, as quais permitem o controle de formulários de páginas web dentro destas classes. Referente ao JSF e seus componentes, analise as afirmativas a seguir:

I- O Managed Bean permite que um método seu seja invocado pelo componente do tipo “commandButton”.

II- O Managed Bean funciona como intermediário entre as camadas model e view.

III- A anotação @RequestScoped possui a mesma funcionalidade da anotação @SessionScoped.

IV- A anotação @SessionScoped não pode ser utilizada em um Managed Bean.

Agora assinale a alternative CORRETA:a) ( ) Apenas as afirmativas I e II estão corretas.b) ( ) Apenas as afirmativas II e III estão corretas.c) ( ) Apenas as afirmativas I, II e III estão corretas.d) ( ) Apenas as afirmativas II, III e IV estão corretas.

59

UNIDADE 2

COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA

PERSISTENCE API


PLANO DE ESTUDOS

Ao final desta unidade você será capaz de:

• elaborar interfaces gráficas para web utilizando o Java Server Faces e seus componentes gráficos.

• identificar o componente adequado para cada situação, de forma a otimizar os recursos da tecnologia.

• persistir o estado de objetos em um banco de dados relacional através da Java Persistence API.

Esta unidade de ensino está dividida em três tópicos, sendo que no final de cada um deles, você encontrará atividades que contribuirão para a apropriação dos conteúdos.

TÓPICO 1 – COMPONENTES GRÁFICOS DO JAVA SERVER FACES

TÓPICO 2 – JAVA PERSISTENCE API (JPA)

60

61

TÓPICO 1

COMPONENTES GRÁFICOS DO JAVA SERVER FACES

UNIDADE 2

1 INTRODUÇÃOConforme já estudamos na unidade anterior, o Java Server Faces pode ser

definido como um framework de componentes de servidor para aplicações web que funciona de acordo com o padrão MVC. Suas principais características e funcionalidades são: api que representa componentes de interface gráfica e seu estado, gerenciamento de eventos, validação e conversão de dados no servidor, navegação entre páginas, internacionalização e extensibilidade para praticamente todos os componentes (ORACLE, 2010).

Nesta unidade daremos ênfase aos principais componentes de interface gráfica e sua utilização em aplicações web, demonstrando o relacionamento destes componentes com os Managed Beans e com as funcionalidades de validação e conversão no lado do servidor. Não é nossa intenção esgotar o tema, visto que o JSF é uma especificação bastante extensa, mas sim capacitar você, acadêmico, para a utilização prática destes componentes em aplicações web. Sempre que mais recursos sobre a tecnologia estiverem disponíveis, estes serão sinalizados para que você possa complementar nossos estudos.

2 COMPONENTES DE FORMULÁRIOPara demonstrar os componentes faremos a simulação de uma tela de

cadastro de pessoa, conforme a Figura 50. Esta mesma interface será utilizada posteriormente para o JPA no Tópico 2 desta unidade, persistindo estas informações em um banco de dados relacional.

UNIDADE 2 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES E JAVA PERSISTENCE API

62

FIGURA 50 - INTERFACE GRÁFICA PARA O CADASTRO DE PESSOA

FONTE: O autor

Na figura podemos observar que estão sendo utilizados diversos componentes gráficos, como campos de texto, áreas de texto, radio buttons e combo boxes. Cada um destes componentes que é renderizado como HTML é na verdade um componente do JSF que é criado no servidor e obedece ao ciclo de vida que vimos na Unidade 1.

Vamos começar pela entidade Pessoa, que é o objeto a ser gerenciado pelo JSF. Crie um novo Dynamic Web Project no Eclipse, exatamente da mesma forma como criamos na unidade anterior. A Figura 51 destaca quais as bibliotecas e frameworks que devem ser selecionados na configuração do projeto. Esta configuração é importante, pois dará suporte a diversas funcionalidades que utilizaremos na criação do protótipo.

Uma vez que o projeto esteja configurado corretamente, crie um pacote com o nome br.com.nead.model e dentro deste pacote uma classe Pessoa, com os atributos mostrados na Figura 52.

TÓPICO 1 | COMPONENTES GRÁFICOS DO JAVA SERVER FACES

63

FONTE: O autor

FIGURA 51 - CONFIGURAÇÃO DO PROJETO

Nossa classe Pessoa servirá como entidade para a tela de cadastro e para outras tecnologias que veremos ao longo deste caderno, portanto a implementaremos conforme o padrão Java Bean. Este padrão define que para ser considerada um Java Bean, uma classe deverá obedecer às seguintes restrições:

• Todos os atributos devem ser privados, com getters e setters.• Deve possuir no mínimo um construtor default vazio, embora possa ter mais

construtores e métodos auxiliares.• Deve implementar a interface Serializable.

A especificação Java Bean define um padrão para a criação de entidades na linguagem de programação Java. Atualmente, diversos framworks como JPA, EJB e JSF dependem desta especificação. Maiores detalhes sobre esta especificação podem ser obtidos em: <http://www.oracle.com/technetwork/java/javase/documentation/spec-136004.html>.

IMPORTANTE


64

FIGURA 52 - CLASSE PESSOA

FONTE: O autor

Um aspecto interessante é que, apesar de implementarmos a interface Serializable, não implementamos nenhum método. Este tipo de interface é conhecido como interface marcadora, onde a implementação implica que algo pode ser feito com a classe. Neste caso, indica que uma instância pode ser convertida em um array de bytes (serializada).

Note que existe uma discrepância entre a classe Pessoa e a interface gráfica que criamos para o cadastro desta pessoa. Descobriu? Olhe novamente que eu aguardo você aqui. Pois é, na tela de cadastro não existe o atributo id, presente na entidade. Este atributo servirá como chave primária do objeto, uma vez que este for persistido e faremos com que o JPA cuide da geração e gerenciamento deste, ocultando-o de quem for utilizar a aplicação. Demonstraremos esta funcionalidade com maiores detalhes na Unidade 3.

Não se esqueça de criar os getters e setters para todos os atributos em seu projeto. É recomendável, ainda, criar os métodos equals e hashcode pelo atributo id e um método toString. Lembre-se de que o Eclipse faz tudo isto automaticamente para você. Se quiser criar construtores adicionais, fique à vontade.

Para o funcionamento do JSF, é sempre necessária a criação de um Managed Bean, que funcionará como controlador entre a interface gráfica e a entidade. No exemplo da unidade anterior, nosso model era composto simplesmente por uma String e o managed bean fornecia acesso à mesma. Neste exemplo, o managed bean terá que fornecer acesso a uma instância inteira de pessoa. Vamos para a implementação? Acompanhe na Figura 53.


65

FONTE: O autor

FIGURA 53 - MANAGED BEAN

Novamente utilizamos as anotações para marcar a classe PessoaMB. A anotação de sessão pode ser substituída aqui por uma de request sem prejuízo momentâneo para nossa aplicação. Na linha 24 temos o atributo que representa a entidade pessoa. Como esta entidade é privada, precisamos novamente dos getters e setters. Estes getters e setters transformam pessoa em uma propriedade e, através dela, é possível acessar também todos os seus atributos. Note que esta classe também segue o padrão Java Bean. Mais adiante faremos nesta classe um método para validar o formato do e-mail e também para converter uma enumeração para um radio button.

Como última etapa, criaremos passo a passo a interface gráfica que será suportada por estas classes. Clique com o botão direito na pasta Web Content e selecione a opção New XHTML Page, chamando-a de cadastro. Parte do código fonte para esta página pode ser visto na Figura 54.


66

FIGURA 54 - PARTE DO CÓDIGO FONTE PARA A PÁGINA DE CADASTRO

FONTE: O autor

Até a linha 11, com exceção da mensagem de título, o código é gerado pelo Eclipse. Na linha 13 utilizamos o componente formulário, visto que o objetivo central desta página é exibir um formulário que permita o cadastro de dados de uma pessoa. Na linha 14, utilizamos um componente de mensagens. Este componente fará com que todas as mensagens de validação sejam exibidas neste local da página. Caso este componente não exista, cada mensagem será exibida próxima ao componente onde a validação não foi realizada com sucesso.

Para alinharmos os componentes da página em duas colunas, utilizamos o PanelGrid, que funciona determinando o número de colunas para cada linha de componentes. Neste caso, a cada dois componentes é feita uma quebra de linha. Na linha 16 utilizamos um componente do tipo facet conhecido como header. Este componente não segue as determinações do panelGrid e utiliza a linha inteira.

Nas linhas 20 e 21 estão os componentes que formarão a primeira linha de nossa tela de cadastro. O componente outputText simplesmente imprime a String “Nome” e é associado através do atributo for ao componente chamado de itNome. Na linha 20 é definido o componente inputText, com função análoga à do HTML. Algumas ressalvas são importantes aqui. O atributo name indica que o outputText anterior está associado a este campo de texto. O atributo required faz com que o preenchimento deste seja obrigatório, causando uma mensagem de erro caso o mesmo não seja preenchido. Caso o atributo requiredMessage não seja preenchido, a mensagem-padrão de erro é retornada em caso de erro. O atributo size define o tamanho do campo e o atributo value associa este campo de texto


67

automaticamente ao valor do atributo nome, da classe pessoa, acessada pelo managed bean. Esta associação acontece através da instrução “#{pessoaMB.pessoa.nome}”. Por padrão, o nome da instância do managed bean é o mesmo da classe, só que iniciando com letra minúscula. O mesmo ocorre para o objeto pessoa e seus atributos, acessados aqui como propriedades.

Na linha 25 começamos novamente com o outputText para a segunda linha do formulário. Os atributos de validação são semelhantes aos do componente anterior, mas neste componente fazemos uso de uma funcionalidade de conversão e outra de validação. Na linha 30 convertemos o valor do campo para um número (lembre-se de que tudo que vem de um formulário HTML é originalmente String) usando atributos para definir seu formato e locale (localização). Na linha 31 utilizamos um componente de validação de valores máximo e mínimo, definindo-os arbitrariamente.

Nas linhas 34 a 37 fazemos uso novamente do facet, colocando dois botões dentro deste. Os command buttons serão associados a métodos dentro do managed bean.

A Figura 55 mostra as mensagens de erro e a interface de cadastro até aqui. Perceba que a validação que colocamos não foi realizada com sucesso para os campos e as mensagens de texto foram exibidas agrupadas em um só local.

Tanto o Eclipse quanto o Netbeans permitem a criação automática de Managed Beans e interfaces através de classes de entidade. Nosso foco neste momento não é a produtividade, mas sim a compreensão e por este motivo estamos criando tudo manualmente.

IMPORTANTE

FIGURA 55 - MENSAGENS DE VALIDAÇÃO

FONTE: O autor


68

Dando continuidade ao formulário de cadastro, agora criaremos o componente de área de texto e dois inputs com estratégias distintas para validação. O código fonte para estes componentes pode ser visto na Figura 56. Este código fonte poderá ser digitado a partir da linha 33 do código mostrado na Figura 54.

FIGURA 56 - CONTINUAÇÃO DA INTERFACE DE CADASTRO

FONTE: O autor

Entre as linhas 34 e 39 colocamos um componente de área de texto, análogo ao componente do HTML. A diferença, neste caso é que tivemos que utilizar um componente chamado de panelGroup para podermos colocar mais de dois componentes em uma mesma linha. O panelGrid que mostramos anteriormente estabelece a utilização de somente dois componentes em uma só linha para todo o nosso formulário. Mas e se eu quiser colocar uma mensagem de auxílio ao usuário ao lado de alguns componentes? Esta é exatamente a situação demonstrada acima. Perceba que colocamos dois componentes outputText e um componente textArea, totalizando três componentes. Neste caso, colocamos dois ou mais componentes dentro de um panelGroup, pois este permite a colocação de quantos componentes você quiser ao mesmo tempo que é percebido pelo panelGrid externo como um componente único.

O componente de email (linhas 41 até 48) é um inputText como os demais, com a ressalva de que agora estabelecemos um validador personalizado e novamente usamos o panelGroup. Perceba que o atributo validador é relacionado com um método existente dentro de pessoaMB. Esta é uma característica importante do JSF: ele permite a criação de validadores personalizados para os componentes, colocando-os dentro do managed bean. E se eu tiver meus métodos de validação dentro da entidade? Basta você chamar a entidade referenciada pelo managed bean e invocar o método. A Figura 57 ilustra o código-fonte deste método, que deve ser colocado dentro da classe PessoaMB.


69

FONTE: O autor

FONTE: O autor

FIGURA 57 - MÉTODO PARA VALIDAÇÃO DE EMAIL

A assinatura do método de validação não muda, bastando a você escrever o código da validação e a mensagem de retorno. Neste caso a validação é bastante simples, perguntando somente se existe o símbolo “@” na String recebida. O detalhe é que esta implementação é adicionada ao ciclo de vida do JSF de forma transparente e será executada junto com as demais validações.

Por fim, utilizamos um inputText para registrar a data de nascimento da pessoa, convertendo automaticamente o valor do campo para um DateTime com o padrão descrito (dd/MM/yyyy). A Figura 58 mostra como fica a interface até o momento, ilustrando o email inválido colocado propositalmente.

FIGURA 58 - VALIDAÇÃO DO EMAIL

É possível criar classes específicas para a validação do valor de determinado componente. Uma implementação exemplo deste tipo de funcionalidade pode ser acessada em: <http://www.mkyong.com/jsf2/custom-validator-in-jsf-2-0/>.

IMPORTANTE


70

Para encerrar nosso cadastro de pessoa, colocaremos um campo do tipo combo box e um campo do tipo radio button, este último alimentado por um enum que representa o sexo da pessoa. O código-fonte para estes componentes está demonstrado na Figura 59, e deve ser inserido logo após o código da Figura 56.

FIGURA 59 - COMPONENTES COMBO BOX E RADIO BUTTON

FONTE: O autor

FONTE: O autor

Na linha 58 criamos o componente radio button, escolhendo aquele que somente permite a seleção de um valor para o sexo. Este valor está atrelado ao atributo sexo da classe Pessoa. É possível criar manualmente os valores e colocar um a um, mas neste caso fizemos uso de uma funcionalidade que alimenta o componente selectItems automaticamente de acordo com o enum. Isso significa que, em caso de alteração do enum, o radio button é automaticamente alterado. Para que o componente seja exibido corretamente, são necessários dois passos:

1) Criação do enum que representa o sexo (Figura 60).2) Implementação do método que permite a alimentação do componente de

forma automática (Figura 61) na classe PessoaMB.

FIGURA 60 - ENUMERAÇÃO PARA O SEXO


71

FONTE: O autor

FIGURA 61 - MÉTODO QUE FAZ O BINDING ENTRE O RADIO BUTTON E O ENUM

Perceba que o nome do método é getSexos, o que implica que o componente fará uma chamada através da instrução “#{pessoaMB.sexos}”, demonstrada na linha 59.

Para o Cargo, o ideal seria criar uma nova classe com um id e uma descrição. Por motivos de simplificação, deixaremos esta implementação para as autoatividades.

IMPORTANTE

Quanto ao componente combo box, optamos por fazer a inicialização manual do mesmo, embora um procedimento semelhante ao do radio button funcionaria da mesma forma. Entre as linhas 65 e 69 é feita a criação do componente, através do selectOneMenu e dos diversos selectItems, que representam os itens mostrados no comboBox. O atributo itemValue indica o que será enviado para o objeto pessoa, enquanto o atributo itemLabel representa o texto que será exibido para cada item.

Uma vez concluída a codificação, nossa interface para cadastro de usuário fica conforme está ilustrado na Figura 62. Os botões Salvar e Novo são componentes do tipo commandButton, ou seja, são associados a algum método da classe PessoaMB que reflita sua funcionalidade.

FIGURA 62 - CADASTRO DE PESSOA

FONTE: O autor


72

Criaremos um método para demonstrar o objeto que acabamos de salvar e outro para apagar o conteúdo dos campos preenchidos na tela e criar um novo objeto. O código fonte para estes métodos está demonstrado na Figura 63. Note que a implementação é simples para ambos os métodos com o objetivo único de demonstrar a associação.

FIGURA 63 - MÉTODOS DE AÇÃO DOS BOTÕES

FONTE: O autor

FONTE: O autor

A última etapa consiste em associar o atributo action dos commandButtons com os métodos respectivos, fazendo com que o usuário acione uma ação ao clicá-los. O código-fonte para esta associação está listado na Figura 64. Basta inserir a action no código-fonte já existente para os commandButtons.

FIGURA 64 - BINDING DOS MÉTODOS AOS BOTÕES

Para encerrar este tópico, faremos a demonstração de um objeto completo sendo salvo, com a mensagem escrita no console. Lembre-se de que para imprimir o objeto pessoa, há a necessidade de se criar o método toString dentro do mesmo, caso contrário imprimiremos somente o full qualified name do objeto e o endereço do mesmo. Nossa sugestão é de que você gere o toString através do Eclipse, colocando todos os atributos para verificar se a associação entre a tela, o managed bean e o objeto pessoa foi feita corretamente. Para testarmos a interface de cadastro, salvaremos os dados de uma pessoa (Figura 65) e mostraremos o resultado no console (Figura 66) ao pressionarmos o botão salvar. O id possui o valor null, pois ainda não foi feita a utilização do JPA para gerar este valor de forma automática, como uma chave surrogada e a data foi convertida para o formato DateTime do Java.


73

FONTE: O autor

FONTE: O autor

Uma chave surrogada é um campo que não existe na entidade modelada, servindo apenas como chave primária em uma tabela relacional, no sentido de facilitar relacionamentos com outras tabelas.

IMPORTANTE


FIGURA 66 - SAÍDA NO CONSOLE

3 TABELASUm dos componentes mais utilizados em interfaces web com JSF é o

DataTable. Sua função consiste em receber uma listagem de objetos, consumindo-a e montando um grid de dados, a partir do qual é possível editar ou mesmo remover objetos da listagem. Em nosso caso, esta interface complementará o cadastro da pessoa, permitindo a visualização, alteração e remoção dos mesmos.


74

Como ainda não dispomos de um mecanismo de persistência, simularemos uma listagem de pessoas diretamente na classe PessoaMB, local de onde o DataTable buscará suas informações. Futuramente, este método sofrerá uma alteração e fará acesso a uma fonte de dados. É importante criar este método de forma transparente para a view, ou seja, a alteração futura terá o mínimo de impacto para a aplicação como um todo.

Inicialmente faremos a criação de uma lista que supostamente trará objetos do tipo Pessoa dentro da classe PessoaMB. Criamos três objetos, você pode criar quantos quiser (Figura 67).

FIGURA 67 - SIMULAÇÃO DO MECANISMO DE PERSISTÊNCIA

FONTE: O autor

Agora, você deve criar um novo arquivo XHTM, dentro da pasta WebContent, chamado listagemDePessoas. Neste arquivo criaremos o código-fonte que será apresentado para o usuário, dividido em duas partes:

1) A DataTable propriamente dita.2) O formulário para alteração dos objetos do tipo Pessoa.

A Figura 68 mostra o código-fonte para a criação da DataTable, a partir do componente <h:body>. Lembre-se de que a parte inicial do arquivo é criada pelo template do Eclipse. Você perceberá que parte dos atributos do objeto e parte do código-fonte foram omitidos para fins de simplicidade.


75

FIGURA 68 - CÓDIGO FONTE PARA A CRIAÇÃO DO DATATABLE

FONTE: O autor

O componente DataTable foi colocado dentro de um componente <h:form> (linha 13), pois utilizaremos esses dados para alterar e remover objetos da lista. A criação do DataTable propriamente dita ocorre na linha 14. Note os atributos value e var. O primeiro remete à fonte de alimentação da tabela e o segundo remete ao tipo de objeto que populará cada linha da tabela. A única restrição é que o tipo de var deve ser igual ao tipo contido na lista que alimenta a tabela. No nosso caso, o método do managed bean retorna uma lista de Pessoas e cada pessoa é listada em uma linha da tabela, conforme a Figura 69. A variável pessoa representa o objeto e dá acesso às propriedades do mesmo.

O número de colunas é determinado pelos número de componentes <h:column> que é colocado dentro da DataTable. Perceba que criamos facets do tipo Header para cada atributo, com componentes outputText distintos para descrevê-los e para conter o valor do atributo de cada objeto. Na última coluna são colocados os botões para acionar os métodos que alteram ou excluem as pessoas da lista. Esta implementação será mostrada mais adiante.


76

FIGURA 69 - LISTAGEM DE PESSOAS

FONTE: O autor

FONTE: O autor

O botão remover simplesmente remove a pessoa da lista que alimenta a dataTable, enquanto o botão editar altera as informações do objeto selecionado. Para realizar esta alteração com um objeto, necessitamos de um formulário que permita a colocação de novos dados. Mas espere aí...nós já implementamos este formulário quando criamos o cadastro de pessoas e tudo que temos a fazer é reutilizá-lo.

Antes de sair abrindo o arquivo cadastro.xhtml para copiar e colar o código (argh!!!), vamos pensar um pouco. Em aplicações web é extremamente comum sermos redirecionados a uma nova página após completar alguma ação, como finalizar um cadastro ou fazer um pagamento. É exatamente este tipo de comportamento que precisamos aqui. Ao clicar no botão editar, precisamos “levar” o objeto para nossa interface de cadastro e lá fazer as alterações que desejamos.

Aqui é que entra uma das características do JSF que facilita o trabalho dos desenvolvedores. Em outras linguagens de programação, você precisaria colocar o objeto em uma variável de sessão (ou manter o estado dela de alguma forma) e então fazer o redirecionamento manual da página, o que é relativamente trabalhoso e entediante. Lembre-se de que o controlador do JSF é o managed bean, então, se conseguirmos colocar o objeto que está na tabela dentro da variável gerenciada por ele, já temos o que precisamos e precisaremos somente fazer o redirecionamento. Basta mudar a assinatura de nosso método editar e fazer com que ele retorne uma String com o nome do arquivo para onde queremos ir. Em nosso caso, a mudança está ilustrada na Figura 70.

FIGURA 70 - ALTERAÇÃO DO MÉTODO EDITAR


77

FONTE: O autor

Basta salvar e tentar acessar novamente o arquivo de listagem de pessoas. Ao clicar no botão editar em qualquer uma das linhas, os dados do objeto selecionado serão mostrados na interface de cadastro (Figura 71). Logicamente, ao alterarmos os dados nada acontece, pois, nosso sistema de persistência é somente simulado dentro do managed bean e não inclui a operação de salvamento.

FIGURA 71 - ALTERAÇÃO DE PESSOA

Nem sempre o simples salvamento do arquivo e novo acesso a URL traz as atualizações do código fonte no servidor. Caso isso aconteça, encontre a aba Servers no Eclipse, expanda seu servidor e clique com o botão direito do mouse no projeto. Ao selecionar a opção Full Publish, o contexto antigo é substituído pelo novo, garantindo que as mudanças estejam refletidas no servidor.

IMPORTANTE

Para deixar nosso CRUD mais completo, adicionaremos uma página inicial e links que permitam a navegação. O componente que funciona como link é chamado de outputLink e tem o comportamento similar ao dos links do HTML. Existe um outro tipo de link, conhecido como commandLink, mas este possui comportamento similar aos componentes do tipo commandButton.

Criaremos um novo arquivo XHTM, chamado de index.xhtml, cujo código fonte está na Figura 72. Os componentes outputLink possuem dentro um componente outputText, que contém o texto que descreve o link. Para exercitar, sugerimos que você coloque nos arquivos cadastro e listagemDePessoas um link que permita voltar à página inicial, conforme o exemplo mostrado na Figura 73.


78

FIGURA 72 - PÁGINA INICIAL

FONTE: O autor

FONTE: O autor

FIGURA 73 - LINK QUE PERMITE RETORNO À PÁGINA INICIAL

4 SUPORTE NATIVO A AJAXConforme SOFTPLAN (2015), AJAX é o acrônimo para asyncronous javascript

and XML, uma técnica utilizada para capturar eventos em uma página web e enviar requisições para o servidor sem a necessidade de submeter a página inteira. Na prática, isto significa que o ciclo request/response do servidor ocorre de forma mais transparente ao usuário, deixando a aplicação mais agradável de usar.

O JSF possui suporte nativo à AJAX desde a versão 2.0, o que facilita mais uma vez o trabalho dos desenvolvedores. Faremos uma alteração simples em nosso exemplo para demonstrar de que forma o JSF interage com o AJAX. Vamos supor que exista uma regra de negócio em nosso sistema que, caso a pessoa seja do sexo FEMININO, seu salário é aumentado em 10%. Para implementar esta funcionalidade, precisamos de duas alterações em nosso exemplo:

1) Colocar o código que faz o bind do AJAX com o componente (Figura 74).2) Escrever o método no managed bean para alterar o salário (Figura 75).


79

FONTE: O autor

FONTE: O autor

FIGURA 74 - AJAX

Conforme ilustrado na Figura 74, a alteração será feita no combo box que define o sexo da pessoa. Perceba que queremos ativar um método utilizando ajax sempre que o sexo for selecionado ou alterado (event=”change”). O atributo listener define qual método será ouvinte deste evento, enquanto os atributos render e execute informam qual o id do componente que será renderizado. O JSF permite a utilização de AJAX com métodos no managed bean para os seguintes eventos:

• Formulários: change, focus e blur.• Teclado: keydown, keyup e keypress.• Mouse: click, mousedown, mouseup, mouseover, mouseout e mousemove.

Na linha 99 utilizamos um componente do tipo UIInput para armazenar o objeto que deu origem ao evento, o combo box. Na linha 101, obtemos o valor deste componente e o convertemos para um enum. Na linha 103, definimos o valor do novo salário de acordo com o sexo selecionado e por fim, na linha 105, a pessoa recebe o novo salário. Nas linhas 101 e 103 utilizamos expressões ternárias para a atribuição.

FIGURA 75 - AJAX NO MANAGED BEAN

Uma expressão ternária é uma maneira mais simples de atribuir um valor a uma variável que depende de uma condição if else. Maiores detalhes podem ser obtidos em: http://www.guj.com.br/java/106380-operador-condicional-ternario

IMPORTANTE


80

Uma vez prontas as alterações, podemos proceder com o teste da funcionalidade. Basta reexecutar a aplicação e cadastrar uma nova pessoa do sexo Feminino e o salário dela será acrescido em 10% sem a necessidade de a página carregar totalmente (Figura 76).

FIGURA 76 - ALTERAÇÃO DO SALÁRIO VIA AJAX

FONTE: O autor

5 ADICIONANDO UMA BIBLIOTECA EXTERNA DE COMPONENTES VISUAIS

O JSF permite que você modifique o layout dos componentes da interface gráfica através de bibliotecas visuais de terceiros. Estas bibliotecas facilitam o trabalho de deixar a aplicação mais agradável para os usuários, pois eliminam o css e demais frameworks como o bootstrap.

Existem algumas bibliotecas de terceiros que são bastante conhecidas e utilizadas em JSF, com destaque para o ICE Faces, o Rich Faces e o Prime Faces. Neste tópico demonstraremos como alterar a interface de nossa aplicação para cadastro de pessoas através da adição de componentes do Prime Faces. O website do projeto pode ser visto na Figura 77.

A empresa que desenvolve o Prime Faces disponibiliza diversos layouts e temas pré-prontos, entretanto, a maioria deles é paga. Para observar a diversidade dos componentes oferecidos pela biblioteca, acesse a url: <http://www.primefaces.org/showcase/>. Neste endereço, você poderá ver demonstrações funcionais dos componentes, sempre com o código-fonte ao lado, ilustrando sua utilização.


81

FONTE: O autor

FIGURA 77 - WEBSITE DO PRIMEFACES

As Figuras 78, 79 e 80 mostram os componentes calendar, chart e accordion, respectivamente:

FIGURA 78 - COMPONENTE CALENDAR

FONTE: Disponível em: <http://www.primefaces.org/showcase/>.Acesso em: 30 out. 2015.


82

FIGURA 79 - COMPONENTE CALENDAR


FIGURA 80 - COMPONENTE ACCORDION


Para utilizar estes e outros componentes, a primeira etapa consiste em fazer o download da biblioteca do Prime Faces, disponível na URL: <http://mvnrepository.com/artifact/org.primefaces/primefaces/5.0>. Faça o download do arquivo .jar e o adicione ao projeto do Eclipse. Para adicioná-lo, basta copiar o arquivo para a pasta WEB-INF/lib de seu projeto, conforme a Figura 81.


83

FIGURA 81 - CONFIGURAÇÃO DO PRIME FACES

FONTE: O autor

FONTE: O autor

Conforme aprendemos no início do estudo sobre JSF, existem prefixos que devem ser informados no início de um arquivo xhtml e que permitem a utilização dos componentes, de acordo com a sua natureza. Com o Prime Faces não é diferente...para utilizar os componentes desta biblioteca, adicionaremos o prefixo p: em todos os arquivos xhtml que a utilizarão (Figura 82).

FIGURA 82 - PREFIXO P NO INÍCIO DAS PÁGINAS

Para ilustrar o funcionamento do Prime Faces, utilizaremos nossa interface de Cadastro de Pessoas e trocaremos três componentes padrão do JSF por componentes Prime Faces. O código fonte para a troca dos componentes é mostrado na Figura 83.

Neste exemplo utilizamos o componente inputText do Prime Faces (linha 46), alterando o prefixo para p:. Para os componentes que são similares aos do JSF, a única substituição a ser feita é esta. Note que o restante do código fonte permanece inalterado. A segunda alteração que fizemos foi a substituição do inputText do JSF pelo Calendar do Prime Faces (linha 55). Neste caso, como não possuímos componentes análogos no JSF, vale a pena observar os atributos. O atributo mode define o layout do calendário. Uma vez que você tiver feito o teste com estes componentes, substitua o valor “inline” por “popup” e perceba a diferença. Por fim, alteramos um componente do tipo selectOneMenu (linha 74), mantendo seus itens inalterados.


84

FIGURA 83 - ALTERAÇÃO DOS COMPONENTES

FONTE: O autor

Execute o arquivo index.xhtml e veja a diferença (Figura 84). Os inputs apresentam um tamanho de fonte maior, bordas arredondadas e são circulados em vermelho quando ganham o foco. O componente Calendar apresenta um calendário que permite a escolha da data, não havendo necessidade de digitá-la e o componente selectOneMenu apresenta uma estética mais elegante e apresenta a informação de forma mais destacada.

Sugerimos que você troque TODOS os componentes da interface gráfica pelos correspondentes no Prime Faces e inclusive coloque componentes adicionais, observando o seu comportamento. Somente desta forma você consolidará o aprendizado.

IMPORTANTE


85

FONTE: O autor

FIGURA 84 - ALTERAÇÃO DOS COMPONENTES

Mas as possibilidades não se esgotam aqui. O Prime Faces disponibiliza gratuitamente temas para seus componentes. Utilizaremos dois temas para esta demonstração, disponíveis na url: <http://repository.primefaces.org/org/primefaces/themes/>. Faremos o download dos temas vader e excite-bike. Estes temas são arquivos jar que você adiciona ao projeto e depois os referencia. A Figura 78 destaca o arquivo a fazer download para utilizar o tema vader. O procedimento é o mesmo para o tema excite-bike.


86

FIGURA 85 - DOWNLOAD DO TEMA VADER

FONTE: O autor

FONTE: O autor

Uma vez que o arquivo estiver em seu computador, faremos a configuração do projeto para que o mesmo passe a “enxergar” os temas do Prime Faces. Inicialmente copie os dois arquivos para o diretório WEB-INF/lib de sua aplicação, o mesmo onde o arquivo jar do Prime Faces foi copiado. A segunda configuração consiste na inserção de um trecho de código fonte dentro do arquivo web.xml, localizado dentro de WEB-INF. O código fonte está listado na Figura 86.

FIGURA 86 - CONFIGURAÇÃO DO WEB.XML


87

FONTE: O autor

O código que responde pelo tema do primefaces está entre as linhas 15 e 18. Na linha 16 fazemos a configuração geral, e na linha 17 selecionamos o tema. As alterações causadas pela utilização deste tema podem ser observadas na Figura 87.

FIGURA 87 - TEMA VADER

Agora que você fez a configuração inicial, basta adicionar o arquivo de tema ao diretório correspondente e fazer a alteração no arquivo web.xml que o novo tema está automaticamente instalado e refletirá em suas interfaces. Você pode inclusive criar seus próprios temas personalizados, embora existam muitos prontos para utilização (Figura 88).


88

FONTE: O autor

FONTE: O autor

FIGURA 88 - TEMAS GRATUITOS DO PRIME FACES

Para encerrar este tópico, faremos a listagem de pessoas através de um componente do Prime Faces com o tema excite-bike. Este mesmo componente poderia ser utilizado diretamente do JSF com o código abaixo, bastando para isso remover a configuração referente ao tema. A Figura 89 traz o código fonte necessário para esta alteração.

FIGURA 89 - COMPONENTE DATA TABLE

Observe que entre as linhas 16 e 20 está a declaração da tabela. Esta declaração ocorre logo após a declaração <h:form>. O atributo rows define quantas linhas serão mostradas na tela, enquanto o paginator define se a tabela terá paginação. A paginação é feita de forma automática, obedecendo ao template definido nos atributos paginatorTemplate e rowsPerPageTemplate. Este último define os intervalos de registros que o usuário pode selecionar na tabela. No código fonte acima, mostramos somente duas colunas, mas a alteração deverá ser feita em todas. A Figura 90 mostra de que forma ficou a tabela de pessoas com as alterações feitas. Não esqueça de alterar o arquivo web.xml.


89

FONTE: O autor

FIGURA 90 - DATATABLE COM O TEMA EXCITE-BIKE

A funcionalidade da tabela não mudou, entretanto, o usuário agora pode escolher quantos registros quer em tela. Um teste interessante é inserir mais valores na lista que alimenta a tabela e observar seu comportamento.

Pronto! Graças ao JSF e ao Prime Faces você virou um web designer em sete páginas e algumas horas de estudo. A facilidade de uso do Java Sever Faces é uma de suas principais vantagens. Perceba que o layout da página muda completamente simplesmente ao adicionarmos um novo tema, sem precisarmos de implementações adicionais de css, javascript, bootstrap etc. Como dissemos no início do tópico, JSF é uma especificação extensa e existe muito mais para aprender sobre o tema. Nossa intenção é fornecer uma introdução sólida, para que você possa continuar evoluindo por conta própria.

Na próxima unidade trabalharemos com o mapeamento objeto relacional e a Java Persistence API. Bons estudos e até lá!

90

RESUMO DO TÓPICO 1Caro acadêmico, neste tópico você viu que:

• O Java Server Faces pode ser definido como um framework de componentes de servidor para aplicações web que funciona de acordo com o padrão MVC.

• Suas principais características e funcionalidades são: api que representa componentes de interface gráfica e seu estado, gerenciamento de eventos, validação e conversão de dados no servidor, navegação entre páginas, internacionalização e extensibilidade.

• Para o funcionamento do JSF, é sempre necessária a criação de um Managed Bean, que funcionará como controlador entre a interface gráfica e a entidade.

• Um Java Bean é uma classe que implementa a interface Serializable, possui um construtor vazio e getters e setters para todos os atributos.

• O JSF implementa as tags do HTML como objetos java no servidor, mantendo o estado destes entre requisições.

• É possível criar classes específicas para a validação ou conversão do valor de componentes.

• O JSF possui suporte nativo à AJAX desde a versão 2.0, permitindo a utilização desta tecnologia em vários componentes.

• O JSF permite que você modifique o layout dos componentes da interface gráfica através de bibliotecas visuais de terceiros.

• Existem algumas bibliotecas de terceiros que são bastante conhecidas e utilizadas em JSF, com destaque para o ICE Faces, o Rich Faces e o Prime Faces.

91

AUTOATIVIDADE

1 Implemente um mecanismo de persistência completo para o exemplo deste tópico, associando-o com as ações da interface gráfica. Dica: Utilize um singleton com uma coleção (List, Map, Set) para armazenar os objetos.

2 O componente Calendar do JSF originalmente imprime os valores em inglês, conforme vimos no exemplo deste tópico. Através de buscas na Internet, descubra de que forma proceder com a alteração do idioma deste componente para o português.

3 Descreva detalhadamente o ciclo de vida do JSF, considerando a ação de executar a página listagemDePessoas.xhtml que foi implementada neste tópico.

92

93

TÓPICO 2

JAVA PERSISTENCE API

UNIDADE 2

1 INTRODUÇÃOConforme Franco (2014), a grande maioria das aplicações desenvolvidas

no mercado tem a necessidade de persistir suas informações em alguma espécie de repositório que permita a recuperação das mesmas em um momento posterior. Por exemplo, ao realizar uma venda para um cliente, é interessante que os dados desta e das próximas vendas sejam armazenados e posteriormente consultados, no sentido de determinar o perfil deste cliente.

Atualmente, o tipo de repositório mais utilizado para persistir essas informações é o banco de dados relacional. Provavelmente você já ouviu falar em Oracle, MySQL, SQLServer, DB2, PostgreeSQL, entre outros, pois são os bancos de dados mais comumente utilizados na atividade de desenvolvimento de software. O grande volume de utilização dos bancos de dados relacionais ocorre basicamente devido a duas razões básicas:

1) Os bancos de dados relacionais já estão no mercado por um longo período de tempo, portanto, possuem um grau de confiabilidade alto.

2) Os paradigmas que vieram antes do paradigma de programação orientada a objetos eram completamente compatíveis com os bancos de dados relacionais.

A linguagem de programação Java possui uma API projetada unicamente para se trabalhar com bancos de dados relacionais, conhecida como JDBC (Java Database Conectivity) e que dá suporte a um grande número de produtos existentes no mercado. O detalhe aqui é o seguinte: existe um grande problema ao utilizar a linguagem de programação Java (e qualquer outra linguagem de programação orientada a objetos) em combinação com os bancos de dados relacionais. Antes de demonstrarmos a utilização do JDBC, é importante ilustrar esse problema e fazer uma contextualização no conceito conhecido como mapeamento objeto relacional.


94

2 MAPEAMENTO OBJETO RELACIONALToda a teoria da programação orientada a objetos é baseada na teoria dos

grafos. Essencialmente, quando temos uma cadeia de objetos inter-relacionados, podemos vê-los na memória como um grafo direcionado e navegável.

Grafos são estruturas normalmente utilizadas para representar dados relacionados de forma não convencional. Um exemplo clássico desse tipo de representação são os mapas utilizados em serviços de GPS. Maiores detalhes sobre os grafos podem ser obtidos em: <http://www.ime.usp.br/~pf/teoriadosgrafos/>.

IMPORTANTE

Por outro lado, os bancos de dados relacionais são baseados na teoria dos conjuntos, o que pode ser facilmente comprovado quando se faz uma pesquisa buscando dados de mais de uma tabela através dos conectivos E e OU.

A verdade é que precisamos instanciar objetos em nossas aplicações e armazenar seus estados em algum mecanismo de persistência eficiente. Analisando friamente, os bancos de dados relacionais não são a resposta mais coerente para esse problema, entretanto, como dissemos antes, um grande número de aplicações legadas utiliza os bancos de dados relacionais há anos (se não décadas), o que os consolidou no mercado. A combinação de um modelo com forte base científica e a vasta disponibilidade de literatura e ferramentas fazem com que as bases relacionais sejam uma escolha sólida para a maioria das aplicações em desenvolvimento (CARDIM, 2010).

Existem alguns bancos de dados não relacionais e até mesmo orientados a objetos, mas a fatia de mercado ocupada por este tipo de mecanismo de persistência é, até o momento, praticamente insignificante. Faremos uma breve menção a estes bancos de dados ainda neste tópico.

Cardim (2010) afirma que objetos, relações e registros são conceitos de natureza fundamentalmente diferente, apesar de apresentarem algumas similaridades deceptivas. A navegação entre objetos ocorre através de ponteiros e referências, enquanto as relações são unidas através de produtos cartesianos e chaves estrangeiras, o que acaba levando a soluções de otimização diferentes para ambos os casos, além das próprias operações de acesso.

Ainda sobre o tema, Fowler (2012) coloca que o problema de mapeamento objeto relacional é um problema difícil de ser resolvido, pois o que se faz é sincronizar dois tipos completamente diferentes de representação de dados, um contido em uma base de dados relacional e outro na memória.

TÓPICO 2 | JAVA PERSISTENCE API

95

A Figura 91 (Martin Fowler) exemplifica uma tentativa de sincronização. Perceba que os objetos relacionados entre si, representados do lado esquerdo da figura, são mapeados para as tabelas do lado esquerdo. Enquanto os objetos possuem como única limitação a memória do computador, as tabelas precisam representar cada objeto em forma de um registro único, o que torna a tarefa complicada.

FIGURA 91 - MAPEAMENTO OBJETO RELACIONAL

FONTE: Adaptado de: FOWLER (2012)

Este problema é comumente conhecido como diferença de impedância e resolvido através de um conjunto de técnicas e ferramentas conhecido como mapeamento objeto relacional. Para entender a complexidade de tal problema, imagine uma estrutura de classes que represente parte do domínio de uma aplicação, conforme ilustrado na Figura 92.


96

FIGURA 92 - ESTRUTURA DE HERANÇA

FONTE: O autor

Aqui temos um relacionamento de herança envolvendo três classes. Lembre-se de que tanto FuncionarioComissionado quanto FuncionarioHorista compartilham os atributos de Funcionario (que é abstrato) e ainda possuem seus próprios atributos. Como faremos para armazenar objetos deste tipo em um banco de dados relacionais?

Existem diversas técnicas documentadas e exemplificadas na literatura e internet para o mapeamento do relacionamento de herança entre objetos para tabelas relacionais, entretanto, visando cumprir com os objetivos de aprendizado deste caderno, nos ateremos a mapeamentos menos complexos e de representação mais fácil.

2.1 ARQUITETURA DO DATA ACCESS OBJECT

Uma das soluções mais aplicadas para o problema do mapeamento objeto relacional é a utilização do padrão de projeto conhecido como DAO (data access object). Esse padrão consiste em implementar uma camada para fazer o mapeamento entre os objetos e as tabelas do banco de dados. Essa camada pode conter diversas classes e ser construída de forma manual ou até mesmo através da utilização de frameworks para automatizar o processo.


97

Um framework provê uma solução para uma família de problemas semelhantes, usando um conjunto de classes e interfaces que mostra como decompor a família de problemas e como objetos dessas classes colaboram para cumprir suas responsabilidades. O conjunto de classes deve ser flexível e extensível para permitir a construção de várias aplicações com pouco esforço, especificando apenas as particularidades de cada aplicação. Fonte: http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/oque.htm

NOTA

Essencialmente, o que o DAO propõe é a criação de um conjunto de classes onde cada classe representa um conceito de objeto mapeado para uma ou mais tabelas do banco de dados. Em geral, cada DAO possui operações que permitem a criação, leitura, atualização e busca de registros no banco de dados. A função primordial do DAO é fazer a tradução de objetos em registros e de registros em objetos. Quando a implementação é bem feita, algumas vantagens adicionais podem ser obtidas, tais como:

• Abstração completa do mecanismo de persistência: a aplicação em si não precisa conhecer absolutamente nada sobre o mecanismo de persistência, bastando conhecer somente a interface externa do DAO.

• Troca de mecanismo de persistência: caso o mecanismo de persistência deva ser trocado, basta trocar o DAO e todo o resto poderia continuar funcionando perfeitamente.

• Coesão: uma camada DAO bem implementada concentra TODAS as funções de persistência e configuração de banco, facilitando alterações futuras.

A Figura 93 ilustra a arquitetura de uma camada de mapeamento objeto relacional. Perceba que temos essencialmente três partes essenciais. O storage representa o banco de dados relacional, com suas tabelas e registros individuais. A data access layer é a camada de mapeamento entre os dois mundos. Atente para o fato de que existe uma classe DAO que é responsável pelas informações de conexão com o banco de dados e pela operação de buscar um estudante. Finalmente, a application é responsável por conter as classes que representam o domínio da área de negócios da aplicação. Através das setas podemos inferir que a camada de mapeamento atua nos dois sentidos das operações, convertendo objetos para registros e vice-versa.


98

FIGURA 93 - ARQUITETURA DO DAO

FONTE: Cardim (2010)

3 JAVA PERSISTENCE API (JPA)Para suplantar as limitações das estratégias de mapeamento objeto

relacional, surgiram diversos frameworks no mercado, sendo que o mais conhecido é o Hibernate. Este framework acabou tendo uma grande aceitação, principalmente devido à produtividade que trazia ao desenvolvedor, poupando-o de mapear as classes para tabelas manualmente. Observando a popularidade e a qualidade do framework, a Oracle resolveu, através do JCP, criar uma especificação para o mapeamento objeto relacional. Surgiu então o JPA, que é a api-padrão da plataforma Java para a persistência do estado de objetos em bancos de dados relacionais.

O JPA fornece um conjunto de interfaces e classes para serem utilizadas em aplicações Java, fazendo parte da especificação JEE desde a versão 5.0. Para entender a arquitetura de funcionamento do JPA, observe a Figura 94.

Imagine que uma aplicação escrita usando a linguagem de programação Java deseja armazenar e recuperar informações de um banco de dados relacional. A abordagem tradicional consistia em utilizar o JDBC para fazer esta comunicação, através de suas interfaces implementadas pelos drivers JDBC específicos para cada banco. A abordagem do JPA é semelhante, pois também consiste de um conjunto de classes e interfaces que são implementadas por um provedor JPA. Este provedor JPA interage diretamente com o JDBC, estabelecendo comunicação com o banco de dados desejado. Uma das principais vantagens desta abordagem é que nenhum código SQL fica na aplicação Java, ao contrário por exemplo, do padrão de projeto DAO. Perceba ainda que temos drivers JDBC para os bancos de dados específicos e vários provedores JPA, que podem ser utilizados independentemente do driver.


99

FIGURA 94 - ARQUITETURA DO JPA

FONTE: SOFTPLAN (2015)

4 CONCEITOS E INTERFACES DO JPAExistem alguns conceitos e interfaces que precisamos conhecer para poder

trabalhar com o JPA, conforme destacado a seguir:

• Unidade de Persistência (Persistency Unit): Arquivo que apresenta um conjunto de configurações utilizadas pelo JPA para se conectar com o banco de dados, como login, senha, e url de conexão. É possível ainda definir neste arquivo quais são os objetos que serão persistidos no banco. Uma aplicação pode ter mais de uma unidade de persistência, caso seja necessário utilizar mais de um banco de dados. Cada unidade de persistência é definida por um nome único, conforme a Figura 95, linha 3. Entre as linhas 7 e 10 estão colocadas as configurações específicas para acesso ao banco. A linha 12 traz configurações de criação e deleção (drop) de tabelas. As linhas 13 e 14 fazem com que o sql gerado pelo JPA seja visível no console, o que é muito útil para depuração de código.

FIGURA 95 - UNIDADE DE PERSISTÊNCIA

FONTE: O autor


100

• Gerenciador de persistência (EntityManager): Interface implementada pelo provedor JPA que disponibiliza métodos para realizar as operações de persistência (Figura 96). Representa um canal de comunicação com o banco de dados, embora internamente ainda faça uso do JDBC.

FIGURA 96 - INTERFACE ENTITY MANAGER


4.1 MAPEAMENTO DE ENTIDADES

O JPA permite a persistência do estado de qualquer classe Java, bastando para tal colocar as anotações obrigatórias. É recomendável que a classe siga as especificações JavaBeans e que tenha ou possa ter uma tabela associada, visto que, se a tabela não existir, o JPA faz a criação da mesma de acordo com o que foi mapeado nas classes. A Figura 97 traz um exemplo de mapeamento de classe para tabela. Observe que neste caso os nomes dos atributos se mantiveram iguais na classe e na tabela. Isto não é obrigatório, embora em casos de criação de tabelas seja a prática recomendada. O campo id está presente na classe e na tabela, pois de acordo com a especificação JPA, esta é uma boa prática para a definição de chaves primárias em tabelas. Os tipos de dados são convertidos automaticamente, de acordo com o provedor JPA e o banco de dados onde se estiver armazenando os objetos.


101

FIGURA 97 - MAPEAMENTO DE CLASSE PARA TABELA


Praticamente toda a configuração do mapeamento entre tabelas e classes é feita através de anotações. A seguir estão listadas as principais anotações do JPA:

• @Entity – Marca uma classe como entidade e tabela;• @Table – Referencia o nome da tabela. Esta anotação somente é necessária

quando o nome da tabela será diferente do nome da classe;• @Id – Marca um atributo como chave primária;• @Temporal – Marca um atributo como sendo do tipo datetime;• @GeneratedValue – utilizado em conjunto com a anotação @Id, determinando a

estratégia adotada para a geração deste valor;• @Column – Permite a definição de configurações para a coluna no banco de dados.

Um dos princípios do JPA é o da simplicidade. O conceito de Convention Over Configuration (Coc) permite que se trabalhe com uma configuração mínima, pois o resto é convenção e o JPA assume valores default. As únicas anotações obrigatórias são @Entity e @Id. Logicamente, nestes casos o nome da tabela é o mesmo da classe e os nomes das colunas coincidem com os atributos.

Para entender como o JPA funciona, demonstraremos as principais operações de persistência com a mesma entidade Pessoa que utilizamos no tópico anterior. O código fonte da entidade é demonstrado na Figura 98. Na linha 14 definimos a classe como uma Entidade, o que significa que ela poderá ser salva e gerará uma tabela. Sobre o atributo id, colocamos uma anotação definindo-o como chave primária e outra dizendo que a geração da chave é de responsabilidade do banco de dados. A notação @Temporal marca o atributo como sendo de um tipo relacionado a data e/ou hora. Em nosso caso, armazenaremos somente a data.


102

FIGURA 98 - ENTIDADE PESSOA

FONTE: O autor

FONTE: O autor

Nosso exemplo anterior simulava a existência de um banco de dados através da geração arbitrária de pessoas na classe PessoaMB. Já que agora trabalharemos com um sistema de banco de dados real, eliminaremos esse código da classe. Temporariamente, o método getPessoas() ficará como está demonstrado na Figura 99.

FIGURA 99 - MÉTODO PARA LISTAR PESSOAS

Para a configuração do arquivo que fará a conexão com o banco de dados, inicialmente precisamos criar o diretório que conterá este arquivo dentro do projeto. Clique com o botão direito do mouse dentro do diretório src e lá selecione a opção New Folder. O Eclipse exibirá um diálogo conforme o ilustrado na Figura 100. O nome deste diretório deve obrigatoriamente ser META-INF.

Apenas ressaltando que, para utilizar a classe List, é necessário realizar a sua importação, e para isso, na IDE Eclipse, clique com o botão esquerdo do mouse sobre o X em vermelho, o qual sinaliza erro de importação, sendo apresentado na frente do número da linha com erro, conforme ilustrado na figura a seguir.


103

Com este passo, é aberta uma lista de possíveis bibliotecas a serem importadas na classe PessoaMB, sendo que a importação necessária é a classe List do pacote “java.util”, conforme selecionado na tela ilustrada na figura a seguir.

O mesmo procedimento deve ser realizado para a classe ArrayList, sendo clicado com o botão direito do mouse sobre o indicador de erro da linha (X em vermelho), e então selecionar a opção ArrayList do pacote “java.util”, conforme ilustrado na figura a seguir.


104

FONTE: O autor

FIGURA 100 - DIRETÓRIO PARA O ARQUIVO DE CONFIGURAÇÃO PERSISTENCE.XML

Com isso, no início do código fonte da classe PessoaMB, devem ter as importações ilustradas no código fonte a seguir.

import java.io.Serializable;

import java.util.ArrayList;

import java.util.List;

import javax.enterprise.context.SessionScoped;

import javax.inject.Named;


105

Dentro deste arquivo, você deverá criar um novo arquivo xml, com o nome persistence.xml. O conteúdo deste arquivo deverá ser igual ao da Figura 101. Cada arquivo persistence.xml pode ter uma ou n unidades de persistência (definidas entre as linhas 3 e 14), sendo que cada unidade deve ser identificada com um nome único e acessar uma única base de dados. Desde que a conexão configurada no Wildfly esteja correta, uma aplicação pode se conectar com quantos bancos de dados quiser, um para cada unidade de persistência definida. Na linha 4 está declarado o tipo de transação. Neste caso utilizaremos Java Transaction API, disponível no AS. Na linha 5 está declarado o DataSource que criamos dentro do WildFly na Unidade I deste caderno, o que nos libera da definição de usuário, senha e até mesmo base de dados neste arquivo.

FIGURA 101 - PERSISTENCE.XML

FONTE: O autor

A Java Transaction API especifica interfaces padrão entre um gerenciador de transações e as partes envolvidas em um sistema de transações distribuídas. Para maiores informações acesse: http://www.oracle.com/technetwork/java/javaee/jta/index.html

NOTA

O próximo passo consiste na implementação da classe que fará a persistência propriamente dita do objeto. O JTA exige a existência de duas anotações na classe que utilizará o EntityManager, afinal ainda estamos trabalhando com o JPA.

Nesta implementação cabe um questionamento interessante: vale a pena ainda utilizar uma camada DAO para as operações de persistência? A resposta é que depende da implementação. O DAO tradicional trabalha de forma a encapsular as operações que envolvam SQL e mapeamento objeto relacional, enquanto aqui o DAO simplesmente chamaria a api JPA e receberia um objeto para persistência. Caso sua aplicação tenha como característica a utilização futura de outro tipo


106

FIGURA 102 - PESSOAMB

FONTE: O autor

Na linha 33 vemos a anotação @PersistenceContext, acima do atributo que representa o EntityManager. Note que em nenhum momento fizemos a instanciação do objeto manager. Mas como evitaremos o NullPointerException? Com essa anotação, solicitamos ao AS que faça o gerenciamento do ciclo de vida deste objeto. Não há necessidade de instanciá-lo ou mesmo de fechar a conexão. Tudo ficará a cargo do AS. Mas e a tabela no banco de dados? Preciso criá-la? A resposta é não... a criação das tabelas necessárias será feita pelo JPA (através do AS). A única coisa que você deve fazer é criar a database (schema) no banco de dados conforme o nome que foi dado na configuração do DataSource dentro do WildFly.

Na linha 35 temos a anotação @Resource. Esta anotação solicita que o AS faça a injeção de um recurso quando este for necessário na classe. A injeção implica que a instanciação e remoção do objeto ocorrerá de forma transparente em nosso código fonte.

de banco de dados relacional ou mesmo bancos de dados NoSQL (atente-se para a leitura complementar desta unidade), talvez valha a pena desacoplar a implementação do MB das operações do JPA. Contudo, esta estratégia acarretaria em mais uma camada entre as operações, o que notadamente reduz desempenho e aumenta o volume de manutenção. Novamente, todas as decisões arquiteturais envolvem um perde-ganha, mais conhecido como tradeoff. Na implementação exemplo deste tópico, não criaremos uma camada distinta DAO e as operações de persistência serão feitas diretamente no MB. A Figura 102 traz as alterações de código-fonte na classe PessoaMB.


107

A injeção de dependência é um padrão de projeto através do qual se diminui o acoplamento entre as classes, pois as dependências não ocorrem programaticamente e sim através da configuração de uma infraestrutura de software. Este conceito será visto em detalhes na Unidade 3 deste caderno.

NOTA

As linhas 69, 70 e 71 contém o código que faz a persistência do objeto pessoa no banco de dados. Como estamos em um MB, a persistência deve ocorrer em um contexto transacional, por isso devemos iniciar e encerrar a transação. Na Unidade 3 trabalharemos com os Enterprise Java Beans, onde não há essa exigência e o nível de configuração é maior. As Figuras 103 e 104 ilustram o cadastro de uma pessoa e o registro no banco de dados.

Continuando nossa funcionalidade CRUD, agora implementaremos a listagem de pessoas, obtida dos registros armazenados em nosso banco de dados (Figura 105). Sugerimos que você faça pelo menos dez cadastros de pessoas diferentes, pois para esta implementação, quanto mais registros melhor. Faremos uma única alteração na classe PessoaMB, dentro do método getPessoas(), conforme ilustrado na Figura 106.


FONTE: O autor


108

FONTE: O autor

FONTE: O autor

FONTE: O autor

FIGURA 104 - REGISTRO DA PESSOA NO BANCO DE DADOS

FIGURA 105 - LISTAGEM DE PESSOAS

Na linha 84 criamos o objeto que armazena a instrução JPAQL de busca, utilizando novamente o objeto manager. Na linha 86 obtemos uma lista de resultados do banco através da query e atribuímos este resultado para uma lista de pessoas.

FIGURA 106 - MÉTODO DE LISTAGEM DE PESSOAS

JPAQL é uma linguagem análoga ao SQL, utilizada para fazer busca de objetos que foram persistidos em bancos de dados. Para maiores informações acesse:http://docs.oracle.com/javaee/6/tutorial/doc/bnbtg.html

NOTA


109

Na implementação da operação de deleção de registros, o processo é semelhante, bastando alterar o método remover da classe PessoaMB. O código alterado é mostrado na Figura 106. Na linha 98, destacamos o método que faz efetivamente a remoção do objeto do banco de dados. Mas por que eu não posso simplesmente invocar o método remove enviando diretamente o objeto que eu pretendo excluir? O EntityManager não funciona assim. Ele não pode simplesmente alterar ou excluir um objeto recebido por parâmetro. Este objeto deve entrar no contexto do EntityManager, para que então possa ser removido. É isto que está acontecendo na linha destacada.

FIGURA 107 - MÉTODO PARA A EXCLUSÃO DE OBJETOS

FONTE: O autor

A Figura 107 ilustra o ciclo de vida de um objeto dentro do EntityManager. Note que um objeto só pode passar para o estado Removed se ele estiver dentro do estado Managed. Considere que um objeto qualquer, como aquele recebido no código fonte do método remover, está no estado Detached e precisa passar pelo método merge para entrar no estado Managed. Uma vez no estado Managed, ele pode simplesmente passar para o estado Removed.

FIGURA 108 - CICLO DE VIDA DO ENTITYMANAGER DENTRO DO JPA

FONTE: Adaptado de: <http://openjpa.apache.org/builds/1.2.3/apache-openjpa/docs/jpa_overview_em_lifecycle.html>. Acesso em: 20 out. 2015.


110

FONTE: O autor

No processo de alteração de algum dado do objeto, o mesmo princípio é adotado. O objeto precisa passar de DETACHED para MANAGED para somente então ser alterado. Este processo de alteração exige um pouco mais de implementação, pois utilizamos a mesma interface para o cadastro e para a alteração do objeto. O problema é o fato de nossa tela de cadastro não possuir o id do objeto. No caso do cadastro, isso não gera nenhum problema, pois o id é gerado pelo banco e na interface de listagem o objeto é mostrado com este atributo. Entretanto, ao clicarmos no botão Editar, somos levados para a mesma interface de cadastro, onde o botão Salvar chama o método salvar da classe PessoaMB. Este método não tem inteligência para decidir se o objeto deve ser criado ou atualizado no banco. Cabe a nós implementar esta inteligência através da alteração mostrada na Figura 109.

FIGURA 109 - MÉTODO SALVAR

Na linha destacada (70), questionamos se o objeto que está sendo utilizado pelo método possui ou não um valor para o id. A lógica por trás dessa implementação consiste no seguinte: caso o objeto venha de um cadastro pela primeira vez, o que implica que este objeto não existia anteriormente no banco de dados, seu id será igual a null. Caso o objeto venha da interface de listagem, existirá um id, pois o mesmo foi recuperado do banco de dados.

Contudo, ainda existe uma questão a ser solucionada... o objeto na tela de cadastro não possui o atributo id. Isso implica que nosso algoritmo falhará e em todas as situações persistirá um novo objeto no banco de dados. Como poderemos resolver isso? Pense na resposta por alguns minutos e somente então veja a resposta no parágrafo a seguir.

Criaremos um campo do tipo oculto dentro da interface de cadastro que conterá o id do objeto. Da mesma forma que existe um campo do tipo hidden no HTML, existe um campo hidden no JSF. A associação ao id do objeto não trará problemas quando se trata de cadastro, pois o atributo não é visível e não pode ser editado. Já na situação em que o objeto vem da interface de listagem, o id do mesmo estará lá e nosso algoritmo funcionará perfeitamente. A alteração do arquivo cadastro.xhtml é mostrada na figura a seguir:


111

FIGURA 110 - ALTERAÇÃO NA INTERFACE DE CADASTRO

FONTE: O autor

O campo oculto vem logo abaixo do texto do cabeçalho, o que o torna invisível dentro do formulário, ao mesmo tempo em que conterá o id do objeto e permitirá sua atualização ao invés de criar um novo objeto. Um aspecto importante a ser observado é que esta não é a única estratégia possível para lidar com este tipo de situação e que aqui a adotamos por entender que o aprendizado é maior.

4.2 RELACIONAMENTOS ENTRE ENTIDADES

No mundo real, dificilmente uma tabela existirá isolada das demais. Na orientação a objetos isto não ocorre de maneira diferente. Um objeto Pessoa, por exemplo, pode estar associado a um ou mais objetos Endereco. Um objeto NotaFiscal pode estar associado a uma coleção de objetos do tipo Item, onde cada Item possuirá ainda uma associação a um objeto do tipo Produto. O JPA trata este tipo de situação através de anotações específicas, onde é possível determinar o tipo de associação entre os objetos. As multiplicidades possíveis são as seguintes:

• Um para um (1:1) – mapeado por atributo simples e pela anotação @OneToOne;• Muitos para um (M:1) – mapeado por atributo simples e pela anotação @

ManyToOne;• Um para muitos (1:M) – mapeado por coleção e pela anotação @OneToMany;• Muitos para um (M:1) – mapeado por coleção e pela anotação @ManyToMany;

É possível ainda considerar a navegabilidade das associações na utilização das anotações. Na figura a seguir é possível observar dois exemplos distintos. No primeiro exemplo, o objeto Pedido está relacionado a um objeto do tipo Endereco de forma unidirecional, ou seja, a classe Pedido possui um atributo do tipo Endereco. Neste caso, dizemos que Pedido vê Endereco, mas Endereco não vê Pedido. No segundo exemplo, a navegabilidade é bidirecional, pois cada uma das classes possui um atributo do tipo ao qual está associada. Tanto Empresa quanto Pessoa conseguem ver o outro lado da associação.


112

FIGURA 111 - NAVEGABILIDADE DOS RELACIONAMENTOS



Exemplificaremos os relacionamentos através de um relacionamento @OneToMany, onde uma empresa possui uma coleção de objetos do tipo Pessoa. Quando o JPA cria as tabelas no banco de dados, ele automaticamente cria também os relacionamentos entre elas e as chaves estrangeiras de acordo com as anotações de associação e navegabilidade. Na figura a seguir é possível observar o exemplo.

FIGURA 112 - @ONETOMANY

Neste caso, a persistência dos objetos ocorreria de forma hierárquica. Um objeto Empresa seria criado, os objetos Pessoa seriam criados e adicionados na coleção para somente então o objeto Empresa ser persistido. Todos os objetos pessoa que estão dentro da coleção serão automaticamente inseridos no banco de dados.

Para exemplos completos de implementações das demais associações acesse http://cafe.algaworks.com/livro-jpa-e-hibernate/ e faça o download do livro digital sobre JPA e Hibernate.

NOTA


113

As anotações de associação aceitam um atributo chamado fetch. Através deste atributo, é possível configurar de que forma ocorrerá a recuperação dos objetos associados. Dois valores são possíveis:1) FetchType.EAGER: O atributo ou coleção de atributos é carregado quando a

classe principal é carregada.2) FetchType.LAZY: O atributo ou coleção de atributos é carregado somente

quando for acessado explicitamente via get na entidade principal.

A Figura 113 ilustra as duas utilizações:

FIGURA 113 - UTILIZAÇÃO DO ATRIBUTO FETCH

FONTE: SOFTPLAN (2015).

Com este exemplo encerramos esta unidade. Da mesma forma que o JSF, o JPA também é uma API extremamente rica e que possui muito mais conteúdo a ser visto. Neste tópico buscamos introduzir de forma sólida os principais conceitos e também implementar algumas funcionalidades simples, de forma que você tenha embasamento suficiente para continuar estudando. Na próxima unidade abordaremos o EJB e o CDI.

Bons estudos e até lá!


114


EXPLORE O MONGODB

Neste artigo, aprenderemos sobre o MongoDB, o sistema de gerenciamento de banco de dados de software livre e orientado a documentos, escrito em C++, que fornece recursos para a escalada de seus bancos de dados em um ambiente de produção. Descubra os benefícios que os bancos de dados orientados a documentos têm em relação aos tradicionais sistemas de gerenciamento de banco de dados relacionais (RDBMS). Instale o MongoDB e comece a criar bancos de dados, coleções e documentos. Examine os recursos de consulta dinâmica do Mongo, que fornecem eficiência de armazenamento de chave/valor de uma maneira familiar a administradores e desenvolvedores de bancos de dados RDBMS.

O que é o MongoDB?

Nos últimos anos, vimos um interesse crescente em sistemas de gerenciamento de bancos dados que diferem do modelo relacional tradicional. No centro disso está o conceito de NoSQL, um termo usado coletivamente para denotar software de banco de dados que não usa SQL (Structured Query Language) para interagir com o banco de dados. Um dos projetos NoSQL mais notáveis até o momento é o MongoDB, um banco de dados orientado a documentos e de software livre que armazena dados em coleções de documentos semelhantes a JSON. O que distingue o MongoDB de outros bancos de dados NoSQL é a sua poderosa linguagem de consulta baseada em documento, que torna a transição de um banco de dados relacional para o MongoDB fácil, porque as consultas são convertidas com bastante facilidade.

O MongoDB é escrito em C++. Ele armazena dados dentro de documentos semelhantes a JSON (usando BSON — uma versão binária de JSON), que retém os dados usando pares de chave/valor. Um recurso que diferencia o MongoDB de outros bancos de dados de documentos é que é muito simples converter instruções SQL em chamadas de função de consulta do MongoDB. Isso facilita a migração de organizações que atualmente usam bancos de dados relacionais fazerem a migração. Ele também é muito simples de instalar e usar, com binários e drivers disponíveis para os principais sistemas operacionais e linguagens de programação.

O MongoDB é um projeto de software livre, com o banco de dados em si licenciado sob a GNU AGPL (Affero General Public License) versão 3.0. Essa licença é uma versão modificada da GNU GPL que fecha uma brecha na qual as restrições de copyleft não se aplicam ao uso do software, mas apenas à sua distribuição. Isso, naturalmente, é importante em software armazenada na nuvem e geralmente não instalado em dispositivos cliente. Usar a GPL regular poderia resultar em alguém perceber que nenhuma distribuição de fato acontece e, portanto, potencialmente contornar os termos da licença.


115

A AGPL aplica-se apenas ao próprio aplicativo de banco de dados, e não a outros elementos do MongoDB. Os drivers oficiais que permitem que os desenvolvedores conectem o MongoDB a várias linguagens de programação são distribuídos sob a Licença Apache, Versão 2.0. A documentação do MongoDB está disponível sob a licença Creative Commons.

Bancos de dados orientados a documentos

Os bancos de dados orientados a documentos são bastante diferentes dos tradicionais bancos de dados relacionais. Em vez de armazenar dados em estruturas rígidas, como tabelas, eles os armazenam em documentos vagamente definidos. No caso de tabelas de sistemas de gerenciamento de bancos de dados relacionais (RDBMS), se for preciso acrescentar uma nova coluna, será necessário mudar a definição da própria tabela, que acrescentará aquela coluna a todos os registros existentes (embora potencialmente com valor nulo). Isso se deve ao estrito design baseado em esquema do RDBMS. No entanto, em documentos, é possível acrescentar novos atributos aos documentos individuais sem que outros sejam alterados. Isso porque o design de bancos de dados orientados a documentos costuma ser sem esquema.

Outra diferença fundamental é que bancos de dados orientados a documentos não fornecem relacionamentos estritos entre documentos, o que ajuda a manter seu design sem esquema. Isso difere muito de bancos de dados relacionais, que dependem fortemente de relacionamentos para normalizar o armazenamento de dados. Em vez de armazenar dados “relacionados” em uma área de armazenamento separada, em bancos de dados de documentos eles são integrados ao próprio documento. Isso é muito mais rápido do que armazenar uma referência a outro documento onde os dados relacionados são armazenados, visto que cada referência exigiria uma consulta adicional.

Isso funciona muito bem para muitos aplicativos nos quais faz sentido os dados ficarem autocontidos dentro de um documento pai. Um bom exemplo (encontrado também na documentação do MongoDB) são posts e comentários de blogs. Os comentários se aplicam somente a um único post, de modo que não faz sentido separá-los dele. No MongoDB, seu documento de post de blog teria um atributo comments para armazenar esses comentários referentes a esse post. Em um banco de dados relacional provavelmente haveria uma tabela de comentários com uma chave de ID primária, uma tabela de posts com uma chave de ID primária e uma tabela de mapeamento intermediária post_comments que definiria que comentários pertencem a qual post. Isso é muito complexo, desnecessariamente, para algo que deveria ser muito simples

Contudo, se for preciso armazenar dados relacionados em separado, é possível fazer isso facilmente no MongoDB usando uma coleção separada. Outro bom exemplo é armazenar informações de pedidos de clientes em documentos do MongoDB. Geralmente isso inclui informações sobre o cliente, o próprio pedido, itens de linha do pedido e informações sobre o produto.


116

Usando o MongoDB, provavelmente seriam armazenados os clientes, produtos e pedidos em coleções individuais, mas seriam integrados dados de itens de linha dentro do documento de pedido relevante. Seria então feito referência às coleções products e customers usando IDs em estilo de chave estrangeira, assim como faria em um banco de dados relacional. A simplicidade dessa abordagem híbrida faz do MongoDB uma escolha excelente para quem está acostumado a trabalhar com SQL. Isso posto, tire tempo e tome cuidado para decidir a abordagem que precisará ser usada em cada caso de uso individual, visto que os ganhos de desempenho podem ser significativos ao incorporar os dados dentro do documento, em vez de fazer referência a eles em outras coleções.

Visão rápida dos recursos

MongoDB é muito mais do que apenas um armazenamento básico de chaves/valores. Vamos dar uma breve olhada em algum de seus recursos:

• Binários oficiais disponíveis para Windows®, Mac OS X, Linux® e Solaris, distribuição de código de origem disponível para autoconstrução.

• Drivers oficiais disponíveis para C, C#, C++, Haskell, Java™, JavaScript, Perl, PHP, Python, Ruby e Scala, com uma ampla variedade de drivers suportados pela comunidade, disponíveis para outras linguagens.

• Consultas JavaScript ad-hoc que permitem localizar dados usando qualquer critério de qualquer atributo de documento. Essas consultas são um espelho da funcionalidade de consultas SQL, o que torna muito fácil para desenvolvedores SQL escreverem consultas em MongoDB.

• Suporte a expressões regulares em consultas.• Os resultados da consulta em MongoDB são armazenados em cursores

que fornecem muitas funções para filtragem, agregação e classificação, incluindo limit(), skip(), sort(), count(), distinct() e group().

• map/reduce -- implementação para agregação avançada• Armazenamento de arquivos grandes usando GridFS• Suporte a indexação de atributo semelhante a RDBMS, onde é possível criar

índices diretamente em atributos selecionados de um documento• Recursos de otimização de consulta usando dicas, planos de explicação e perfis• Replicação mestre/escravo similar ao MySQL• Armazenamento de objeto baseado em coleta, permitindo consulta referencial

onde forem necessários dados normalizados• Escalada horizontal com autosharding• Atualizações no local para simultaneidade de alto desempenho e livre de

disputas• Shell on-line que permite testar o MongoDB sem instalá-lo• Documentação detalhada, com vários livros publicados e outros sendo escritos


117

Instalando o MongoDB

Felizmente, o MongoDB é muito simples de instalar em uma grande variedade de plataformas. Estão disponíveis distribuições binárias para Windows, Mac OS X, Linux e Solaris, enquanto diversos gerenciadores de pacotes oferecem instalação fácil e opções de configuração para outros sistemas. Para quem é corajoso, é possível compilar o código de origem sozinho. Nesta seção, aprenderemos a instalar o MongoDB em Windows e Mac OS X, definindo o processo como serviço no Windows ou como daemon no OS X.

Instalando no Windows

A instalação do MongoDB no Windows é muito simples. No seu navegador da Web favorito, acesse http://www.mongodb.org/downloads e faça o download do mais recente release de produção estável para Windows. Recomendamos a versão de 64 bits, mas ela só pode ser usada se estivermos utilizando o sistema operacional Windows de 64 bits. Em caso de dúvida, basta usar a versão de 32 bits.

Extraia o arquivo zip na unidade C:\, o que criará uma nova pasta chamada mongodb-win32-i386-1.6.4, ou algo assim. Para facilitar a sua vida, renomeie essa pasta para mongo. Depois, é preciso criar um diretório de dados. No Windows Explorer, vá até a raiz da unidade C:\ e crie uma pasta chamada data. Dentro dela, crie outra pasta chamada db.

Agora é possível iniciar o servidor do MongoDB. Use o Windows Explorer para navegar até C:\mongo\bin e dê dois cliques em mongod.exe. Feche a janela de prompt de comando que aparece para parar o servidor do MongoDB. Ou seja, é mais conveniente configurar o servidor do MongoDB como um serviço que o Windows controle. Vamos fazer isso.

Abra uma janela de prompt de comando (Start>Run>, digite cmd e pressione OK) e dê os comandos da Listagem 1.

Listagem 1. Configuração do servidor do MongoDB como serviço> cd \mongo\bin> mongod --install --logpath c:\mongo\logs --logappend --bind_ip 127.0.0.1 --directoryperdb

É possível ver o resultado na Listagem 2.

Listagem 2. Serviço criado com êxitoall output going to c:\mongo\logsCreating service MongoDB.Service creation successful.Service can be started from the command line via ‘net start “MongoDB”’.

Com o Mongo instalado como serviço, é possível iniciá-lo com o seguinte comando: > net start “MongoDB”


118

É possível ver o resultado na Listagem 3.

Listagem 3. Mongo iniciado com êxitoThe Mongo DB service is starting.The Mongo DB service was started successfully.

Agora é possível executar o cliente de shell do MongoDB. Se a janela de prompt de comando estiver aberta, confirme se está na pasta c:\mongo\bin folder e digite o seguinte comando: > mongo.

Como opção, no Windows Explorer navegue até C:\mongo\bin e dê dois cliques em mongo.exe. Não importa sua opção para iniciar o shell, deve aparecer um prompt semelhante à Listagem 4.

Listagem 4. Iniciando o shellMongoDB shell version: 1.8.1connecting to: test>

Listagem 5. Iniciando o clienteMongoDB shell version: 1.8.1connecting to: test>

Na próxima seção, aprenderemos a usar o shell do MongoDB para criar bancos de dados, coleções, documentos, e assim por diante.

Guia de introdução para o uso do MongoDB

Incluído com a distribuição do MongoDB há um aplicativo de shell que permite o controle completo sobre seus bancos de dados. Usando o shell, é possível criar e gerenciar bancos de dados, coleções, documentos e índices usando funções JavaScript do lado do servidor. Isso facilita começar a usar o MongoDB rapidamente. Nesta seção, aprenderemos a iniciar o shell e verem os exemplos de alguns comandos básicos para fazer o armazenamento e a recuperação básicos de dados.

Shell do MongoDB

O aplicativo de shell do MongoDB está incluído na distribuição deste, na pasta bin. No Windows, está na forma do aplicativo mongo.exe. Dê dois cliques nesse programa no Windows Explorer para iniciar o shell. Em sistemas operacionais baseados em UNIX® (incluindo o Mac OS X) inicie o shell do MongoDB executando o comando mongo na janela de terminal (desde que tenham sido seguidas as instruções acima para acrescentar o diretório do MongoDB no seu caminho).

Quando o shell é aberto pela primeira vez, aparece a mensagem da Listagem 7.


119

Listagem 7. Mensagem após abrir o shellMongoDB shell version: 1.8.1connecting to: test>

A conexão com seu servidor MongoDB local estará pronta, em especial, com o banco de dados “test”. Na próxima seção, aprenderemos a criar bancos de dados, documentos e coleções. Se em qualquer momento for preciso obter ajuda, basta dar o comando “help” na linha de comando do shell do Mongo A Figura 1 mostra a saída típica de um comando de ajuda.

FIGURA 1 – SAÍDA DO COMANDO HELP DO SHELL DO MONGO

Se quiser ver o código de origem por trás de uma função do MongoDB, basta digitar o nome da função no shell, e ele imprimirá o código de origem em JavaScript. Por exemplo, digite connect e pressione a tecla Enter para ver o código de origem usado para se conectar a um banco de dados do MongoDB.

Criando bancos de dados, coleções e documentos

Por padrão, o shell do Mongo se conecta ao banco de dados "test". Para mudar para outro banco de dados, use o comando "use dbname". Se o banco de dados não existir, o MongoDB o criará assim que forem incluídos dados nele. Vamos mudar para o banco de dados "mymongo" com o seguinte comando: > use mymongo.

O shell deve apresentar a mensagem: switched to db mymongo.


120

Nesse ponto, o banco de dados ainda não existe, porque não contém dados. No MongoDB, os dados são armazenados em coleções, permitindo separar documentos, se necessário. Vamos criar um documento e armazená-lo em uma nova coleção chamada "colors": > db.colors.save({name:"red",value:"FF0000"});.

Vamos verificar se o documento foi armazenado procurando o banco de dados: > db.colors.find();.

Deve aparecer uma resposta similar à seguinte (o atributo _id é um identificador exclusivo e provavelmente será diferente no seu resultado): { "_id" : ObjectId("4cfa43ff528bad4e29beec57"), "name" : "red", "value" : "FF0000" }.

Os documentos no MongoDB são armazenados como BSON (JSON binário). Usando o shell do Mongo, podemos inserir dados utilizando uma sintaxe semelhante à JSON, na qual cada documento é um objeto de pares de chave/valor. Nesse exemplo, criamos um documento com dois atributos: name e valor, que têm os valores red e FF0000 (a representação hexadecimal da cor vermelha padrão), respectivamente.

Como talvez tenha notado, não é preciso predefinir a coleção colors ; isso é feito automaticamente ao inserir um item usando a função save.

Nesse exemplo, criamos um documento bem simples. Contudo, a sintaxe semelhante à JSON usada também pode ser utilizada para criar documentos mais complexos. Veja o seguinte documento JSON, que representa uma ordem de compra ou fatura (consulte a Listagem 8).

Listagem 8. Criando um documento simples{ order_id: 109384, order_date: new Date("12/04/2010"), customer: { name: "Joe Bloggs", company: "XYZ Inc.", phone: "(555) 123-4567" }, payment: { type: "Cash", amount: 4075.99, paid_in_full: true }, items: [ {


121

sku: "ABC1200", description: "A sample product", quantity: 1, price_per_unit: 75.99, }, { sku: "XYZ3400", description: "An expensive product", quantity: 2, price_per_unit: 2000 } ], cashier_id: 340582242}

Como se pode ver, esses documentos podem armazenar vários tipos de dados, incluindo cadeias de caractere, números inteiros, flutuantes, datas, objetos, arrays, e muito mais. Na Listagem 8, os itens do pedido foram integrados diretamente ao documento da ordem, agilizando a recuperação dessas informações ao consultar o documento posteriormente.

Visto que o shell do MongoDB usa JavaScript, é possível escrever construções regulares em JavaScript ao interagir com os bancos de dados. Veja a Listagem 9, que cria uma coleção de documentos de caracteres, cada um contendo a representação da cadeia de caractere do caractere e seu código ASCII associado.

Listagem 9. Criando uma coleção de documentos de caracteres> var chars = "abcdefghijklmnopqrstuvwxyz"> for(var i =0; i<chars.length; i++) { ... var char = chars.substr(i, 1); ... var doc = {char:char, code: char.charCodeAt(0)};... db.alphabet.save(doc);... }

Este loop criará 26 documentos, um para cada letra minúscula do alfabeto, cada documento contendo o caractere em si e seu código de caractere ASCII. Na próxima seção, veremos como recuperar esses dados de várias maneiras.

Recuperando dados

Na última seção, não só aprendemos a inserir dados em um banco de dados do MongoDB, mas também a usar a função mais básica de recuperação de dados, find. Vamos começar usando o comando find na coleção de alfabeto que criamos no final da seção anterior:db.alphabet.find();.

Isso deve gerar uma resposta semelhante à Listagem 10.


122

Listagem 10. Resposta gerada> db.alphabet.find(){ "_id" : ObjectId("4cfa4adf528bad4e29beec8c"), "char" : "a", "code" : 97 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec8d"), "char" : "b", "code" : 98 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec8e"), "char" : "c", "code" : 99 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec8f"), "char" : "d", "code" : 100 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec90"), "char" : "e", "code" : 101 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec91"), "char" : "f", "code" : 102 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec92"), "char" : "g", "code" : 103 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec93"), "char" : "h", "code" : 104 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec94"), "char" : "i", "code" : 105 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec95"), "char" : "j", "code" : 106 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec96"), "char" : "k", "code" : 107 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec97"), "char" : "l", "code" : 108 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec98"), "char" : "m", "code" : 109 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec99"), "char" : "n", "code" : 110 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec9a"), "char" : "o", "code" : 111 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec9b"), "char" : "p", "code" : 112 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec9c"), "char" : "q", "code" : 113 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec9d"), "char" : "r", "code" : 114 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec9e"), "char" : "s", "code" : 115 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec9f"), "char" : "t", "code" : 116 }has more>

Por padrão, a função find() recupera todos os documentos da coleção, mas exibe apenas os 20 primeiros documentos. O comando itrecuperará os 6 documentos restantes (veja a Listagem 11).

Listagem 11. Recuperando os 6 documentos restantes> it{ "_id" : ObjectId("4cfa4adf528bad4e29beeca0"), "char" : "u", "code" : 117 }{ "_id" : ObjectId("4cfa4adf528bad4e29beeca1"), "char" : "v", "code" : 118 }{ "_id" : ObjectId("4cfa4adf528bad4e29beeca2"), "char" : "w", "code" : 119 }{ "_id" : ObjectId("4cfa4adf528bad4e29beeca3"), "char" : "x", "code" : 120 }{ "_id" : ObjectId("4cfa4adf528bad4e29beeca4"), "char" : "y", "code" : 121 }{ "_id" : ObjectId("4cfa4adf528bad4e29beeca5"), "char" : "z", "code" : 122 }>

A função find() na verdade, retorna um cursor para o conjunto de resultados da consulta, nesse caso retrieve all documents. Quando isso não é atribuído a uma variável ou não são executadas outras funções, por padrão será impresso um conjunto de resultados de amostra na tela. Para exibir todo o conjunto de resultados, podemos usar o seguinte comando: > db.alphabet.find().forEach(printjson);.


123

Isso imprime todos os registros no conjunto de resultados, em vez de exibir um subconjunto. A seguir, veremos mais sobre como usar cursores e consultas para filtrar dados.

Consultando dados

Um dos maiores pontos fortes do MongoDB é seu suporte poderoso a consulta ad-hoc que funciona mais ou menos da mesma maneira que em bancos de dados relacionais tradicionais, embora filtre e retorne documentos BSON em vez de linhas da tabela. Essa abordagem o destaca em relação a outros armazenamentos de documentos, que muitas vezes são difíceis para que desenvolvedores SQL se familiarizem. Com o MongoDB, consultas SQL relativamente complexas podem ser facilmente convertidas em chamadas de função JavaScript. Nesta seção, aprenderemos as várias funções disponíveis que permitem consultar os dados no MongoDB, e como configurar índices para ajudar a otimizar suas consultas, como se faria de forma semelhante em DB2, MySQL ou Oracle.

Consultas básicas

Na seção anterior, aprendemos a usar a função find para recuperar todos os documentos. A função find aceita uma série de argumentos que permitem filtrar os resultados retornados. Por exemplo, na coleção de alfabeto que criamos anteriormente, é possível encontrar todos os registros em que o atributo "char" tem valor "q" com o seguinte comando: > db.alphabet.find({char: "o"});.

Isso retorna a seguinte resposta: { "_id" : ObjectId("4cfa4adf528bad4e29beec9a"), "char" : "o", "code" : 111 }.

Se quisermos retornar todos os caracteres com código menor ou igual a 100, podemos usar o seguinte comando: > db.alphabet.find({code:{$lte:100}});.

Isso retorna o resultado na Listagem 12, como é de esperar.

Listagem 12. Resultado{ "_id" : ObjectId("4cfa4adf528bad4e29beec8c"), "char" : "a", "code" : 97 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec8d"), "char" : "b", "code" : 98 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec8e"), "char" : "c", "code" : 99 }{ "_id" : ObjectId("4cfa4adf528bad4e29beec8f"), "char" : "d", "code" : 100 }

O MongoDB suporta uma variedade de operadores condicionais, incluindo:• $lt (menor que)• $lte (menor ou igual a)• $gt (maior que)• $gte (maior ou igual a)• $all (corresponder a todos os valores em um array)• $exists (verificar se um campo existe ou não)


124

• $mod (módulo)• $ne (não igual)• $in (corresponder a um ou mais valores em um array)• $nin (corresponder a valores zero em um array)• $or (corresponder uma consulta a outra)• $nor (não corresponder uma consulta nem outra)• $size (corresponder qualquer array com número definido de elementos)• $type (corresponder valores com tipo de dados BSON especificado)• $not (não igual a)

Para obter mais detalhes sobre todos esses operadores, consulte a documentação do MongoDB.

É possível restringir os campos que são retornados por suas consultas usando um segundo argumento na função find. Por exemplo, a seguinte consulta retornará apenas o atributo char para qualquer documento com valor de código entre 102 e 105: > db.alphabet.find({code:{$in:[102,103,104,105]}}, {char: 1});.

Isso deve produzir o resultado da Listagem 13.

Listagem 13. Resultado{ "_id" : ObjectId("4cfa4adf528bad4e29beec91"), "char" : "f" }{ "_id" : ObjectId("4cfa4adf528bad4e29beec92"), "char" : "g" }{ "_id" : ObjectId("4cfa4adf528bad4e29beec93"), "char" : "h" }{ "_id" : ObjectId("4cfa4adf528bad4e29beec94"), "char" : "i" }

Conclusão

Neste artigo, aprendemos sobre o sistema de gerenciamento de banco de dados MongoDB e por que é uma das opções que mais cresce na seção NoSQL popular do mercado de DBMS. Aprendemos por que escolher um banco de dados orientado a documentos em vez de um RDBMS tradicional, e os diversos recursos excelentes que o MongoDB tem a oferecer. Aprendemos a instalar e usar o MongoDB para armazenamento e recuperação de dados, e conhecemos as várias ferramentas e opções de escalabilidade que ele proporciona.

FONTE: Adaptado de: <https://www.ibm.com/developerworks/br/library/os-mongodb4/>. Acesso em: 20 out. 2015

125

RESUMO DO TÓPICO 2Neste tópico apresentamos:

De modo a podermos desenvolver, implantar e testar aplicações que utilizem as tecnologias que fazem parte da especificação JEE, precisamos de um servidor de aplicação – application server (AS).

O JSF é um framework baseado no padrão MVC, onde o model são as classes de entidade, a view são as interfaces desenvolvidas em JSF e o controller é representado pelos Managed Beans, também conhecidos como Backing Beans.

Para ser considerada um Java Bean, uma classe deverá obedecer às seguintes restrições:

• Todos os atributos devem ser privados, com getters e setters.• Deve possuir no mínimo um construtor default vazio, embora possa ter mais

construtores e métodos auxiliares.• Deve implementar a interface Serializable.

É possível implementar métodos de validação ou conversão de dados personalizados no JSF.

O JSF implementa em forma de componentes a maioria dos elementos HTML.

O JSF possui suporte nativo à AJAX desde a versão 2.0, o que facilita mais uma vez o trabalho dos desenvolvedores.

O JSF permite que você modifique o layout dos componentes da interface gráfica através de bibliotecas visuais de terceiros. Estas bibliotecas facilitam o trabalho de deixar a aplicação mais agradável para os usuários, pois eliminam o css e demais frameworks como o bootstrap.

A grande maioria das aplicações desenvolvidas no mercado tem a necessidade de persistir suas informações em alguma espécie de repositório que permita a recuperação das mesmas em um momento posterior.

A linguagem de programação Java possui uma API projetada unicamente para se trabalhar com bancos de dados relacionais, conhecida como JDBC (Java Database Conectivity) e que dá suporte a um grande número de produtos existentes no mercado.

O problema de mapeamento objeto relacional é um problema difícil de ser resolvido.

126

Observando a popularidade e a qualidade do Hibernate, a Oracle resolveu, através do JCP, criar uma especificação para o mapeamento objeto relacional.

O JPA fornece um conjunto de interfaces e classes para serem utilizadas em aplicações Java, fazendo parte da especificação JEE desde a versão 5.0.

O JPA permite a persistência do estado de qualquer classe Java, bastando para tal colocar as anotações obrigatórias

O JPA fica responsável pela criação das tabelas no banco de dados e posteriores operações de mapeamento objeto relacional.

127

AUTOATIVIDADE

1 Implemente uma funcionalidade de pesquisa de pessoas pelo nome, utilizando JPA e JSF. O resultado deverá ser uma lista de pessoas cujo nome seja igual ao nome digitado na pesquisa. Utilize o comando LIKE para atingir este resultado.

2 Configure e utilize outro datasource com um banco de dados diferente do MYSQL para fazer a persistência de objetos pessoa.

3 Implemente o CRUD de Pessoa utilizando pelo menos mais uma implementação da especificação JPA diferente do Hibernate. Você sentiu alguma diferença? Qual?

128

129

UNIDADE 3

ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY

INJECTION (CDI)


PLANO DE ESTUDOS

Ao final desta unidade você será capaz de:

• entender as características e o funcionamento dos EJB;

• identificar o componente adequado para cada situação, de forma a otimizar os recursos da tecnologia;

• utilizar os recursos de injeção de dependência nativos ao AS.

Esta unidade de ensino está dividida em quatro tópicos, sendo que no final de cada um deles, você encontrará atividades que contribuirão para a apropriação dos conteúdos.

TÓPICO 1 – STATELESS SESSION BEANS

TÓPICO 2 – STATEFULL SESSION BEANS E SINGLETON SESSION BEANS

TÓPICO 3 – CONTEXT AND DEPENDENCY INJECTION

TÓPICO 4 – JAVA MESSAGING SERVICES

130

131

TÓPICO 1

STATELESS SESSION BEANS

UNIDADE 3

1 INTRODUÇÃONas tecnologias da família EJB é que percebemos a verdadeira extensão

das capacidades do JAVAEE.

Conforme K19 (2015), muitos sistemas corporativos são desenvolvidos seguindo a arquitetura definida pelo padrão EJB. Ao utilizar esta arquitetura, alguns recursos são disponibilizados automaticamente pelo AS. Entre estes recursos, podemos destacar:

• Transações: A arquitetura EJB define um suporte para utilização de transações. Esse suporte é integrado com a Java Transaction API (JTA), incluindo a possibilidade de realizar transações distribuídas.

• Segurança: Suporte para realizar autenticação e autorização de forma declarativa. Os desenvolvedores das aplicações não precisam implementar a lógica de segurança pois ela faz parte da arquitetura.

• Remotabilidade: Aplicações EJB podem ser acessadas remotamente através de diversos protocolos de comunicação. Consequentemente, é possível desenvolver aplicações clientes de diversos tipos.

• Multithreading e Concorrência: A arquitetura EJB permite que as aplicações sejam acessadas por múltiplos usuários simultaneamente de maneira controlada. A concorrência é controlada pelo AS.

• Persistência: Persistência através da especificação JPA.

• Gerenciamento de Objetos: Mecanismos de injeção de dependências e controle de ciclo de vida são oferecidos aos objetos de uma aplicação EJB. A escalabilidade de uma aplicação é garantida através deste mecanismo.

• Integração: A arquitetura EJB é fortemente integrada com os componentes da plataforma Java EE.

UNIDADE 3 | ENTERPRISE JAVA BEANS (EJB) E CONTEXT AND DEPENDENCY INJECTION (CDI)

132

2 STATELESS SESSION BEANS

Um objeto é geralmente composto de estado e comportamento, entretanto, em muitas situações encontramos procedimentos, regras de negócio e fluxos que representam somente um comportamento e não precisam de estado. Você já está familiarizado com esse conceito ao utilizar algumas classes da plataforma Java que possuem métodos estáticos. Um exemplo é demonstrado na figura a seguir, onde se pode perceber que a classe Integer não precisa de instanciação e não possui estado. Ao solicitar que a String seja convertida para um inteiro, basta chamar o método estático que o mesmo retornará o resultado, sem que o objeto mantenha estado.

FIGURA 114 – MÉTODOS ESTÁTICOS

FONTE: O autor

Para exemplificar, vamos considerar um sistema bancário, onde os empréstimos, transferências, saques, depósitos, cobranças etc. são as regras de negócio. Cada aplicação possui suas próprias regras de negócio, consequência do ramo de atuação e do contexto da mesma.

Ao utilizar a arquitetura EJB para implementar estas regras de negócio, cada regra ou conjunto de regras é implementada em componentes específicos, conhecidos como stateless session beans, cuja principal característica é a não manutenção de estado conversacional.

2.1 EJB 3.0

Conforme K19 (2015), o primeiro passo para implementar um stateless session bean é definir os métodos de negócio através de uma interface. Considerando um componente para a realização de operações matemáticas, uma possível interface é demonstrada na figura a seguir.

TÓPICO 1 | STATELESS SESSION BEANS

133

FIGURA 115 – INTERFACE DE NEGÓCIOS

FONTE: Adaptado de K19 (2015)

Os métodos dentro desta interface são chamados de métodos de negócio. O próximo passo seria a implementação dos métodos de negócio propriamente ditos e a definição das características do stateless session bean através de annotations, conforme a figura que segue.

É importante perceber que nem toda a aplicação se beneficia destas facilidades oferecidas pelo AS. Remotabilidade, concorrência e transações distribuídas podem ser úteis em alguns cenários, mas a complexidade da configuração e definição destes serviços no AS pode não compensar sua utilização em cenários mais simples.

IMPORTANTE

FIGURA 116 – STATELESS SESSION BEAN



134

Como esta classe implementa a interface Calculadora, somos obrigados a fornecer implementação para todos os métodos que nela forem definidos, conforme pode ser observado nos métodos soma, subtrai, multiplica e divide (linhas 13 a 27). As anotações definidas nas linhas 10 e 11 é que caracterizam a classe como um stateless session bean. A anotação @Stateless especifica a característica de não manutenção de estado conversacional, enquanto a anotação @Local define que este é um EJB local que implementa os métodos de negócio de Calculadora.class. Um stateless session bean pode implementar várias interfaces, porém, apenas os métodos das interfaces que estiverem dentro da anotação são considerados como métodos de negócio.

Caso o stateless session bean deve ser utilizado também na forma remota, a anotação muda, conforme pode ser visto na figura a seguir. Ao marcá-lo desta forma, estamos permitindo que a aplicação possa ser colocada em instâncias diferentes do AS. Em termos práticos, essa prática auxilia a colocação de uma aplicação na nuvem, pois a escalabilidade é atingida de forma transparente para o desenvolvedor. Uma instância do AS pode ficar em uma máquina e ser responsável pela interface web e mobile em android ou html, enquanto outra instância mantém os ejb e uma terceira máquina poderia ser responsável pelo banco de dados.

FIGURA 117 – STATELESS SESSION BEAN REMOTO


2.2 EJB 3.1

Na versão 3.1, quando o acesso ao stateless session bean é local, não é mais necessário definir a interface nem utilizar a anotação @Local, bastando anotar uma classe com @Stateless, conforme a figura a seguir.


135

FIGURA 118 – STATELESS SESSION BEAN, VERSÃO 3.1


2.3 TESTANDO O EJB

Considerando que os stateless session beans são utilizados para a implementação das regras de negócio que não necessitam de estado conversacional, precisaremos de uma interface para testá-los.

Para simplificar o acesso ao EJB, faremos seu acesso através de servlets. Nosso stateless session bean pode ser injetado em um servlet através da anotação @EJB. A figura a seguir traz a implementação do servlet propriamente dito.

Apesar dos servlets não fazerem parte do escopo deste caderno, eles são extremamente importantes no ecossistema JAVAEE. Maiores detalhes sobre os servlets podem ser acessados em: <https://www.caelum.com.br/apostila-java-web/servlets/>.

IMPORTANTE


136

FIGURA 119 – MENSAGENS DE VALIDAÇÃO


Agora é hora de paramos um pouco para entender o que aconteceu. A linha 16 traz a anotação que define a URL de seu servlet, cuja função, essencialmente é receber dois doublés como parâmetro via request (a e b) para então exibir um html com o resultado da operação de soma. O detalhe interessante é que na linha 20 anotamos o tipo Calculadora como um EJB. Mas por que definimos como calculadora ao invés de calculadora Bean? Vou esperar 30 segundos para lhe dar a resposta. Vá em frente... pense e responda que eu aguardo.

É isso mesmo! Definimos como Calculadora porque a Calculadora Bean implementa a interface Calculadora e, esta é uma boa prática, como você já viu em disciplinas anteriores.

Voltando ao EJB, a anotação utilizada faz com que o ciclo de vida deste objeto seja completamente gerenciado pelo AS. Sua criação, utilização e destruição não é responsabilidade do desenvolvedor, que pode gastar seu tempo com coisas mais úteis, como por exemplo, implementar regras de negócio ou jogar Playstation 4. Uma característica bastante interessante é que, digamos que cada instância da calculadora pode atender a um usuário de cada vez e, ocorra que 11 usuários estejam tentando acessar seu importante serviço de cálculo ao mesmo tempo. O que acontece? O AS automaticamente instância um novo objeto para atender a estes 10 usuários. Isso pode ser configurado no AS, de forma que sua classe atenda mais ou menos do que 10 usuários simultâneos, bem como o número de instâncias que serão geradas.

Outra característica relevante é que tudo isto faz parte da especificação, ou seja, se você escolher GlassFish, Wildfly, WebLogic ou qualquer outro servidor de aplicação que obedeça à especificação EJB, esta característica de controle do ciclo de vida vem embutida. Se você achou isso legal, espere até chegarmos no CDI.


137

Os EJB são desconectados da interface gráfica e da persistência (afinal, podemos utilizar JPA), o que permite que ao invés de HTML puro com um servlet, criemos um JSF conectado a um Managed Bean que declara o EJB, conforme ilustrado na figura a seguir.

FIGURA 120 – MANAGED BEAN INJETANDO O EJB


Na linha 6 está a anotação @Named, que faz o bind entre o arquivo JSF e managed bean. Na linha 9, da mesma forma que no servlet, injetamos a calculadora com a anotação EJB. O restante do comportamento é o mesmo que foi exemplificado anteriormente.

Até agora trabalhamos somente com os stateless session beans sendo acessados localmente por aplicações web e através da anotação @EJB. Isso ocorre somente quando o EJB é instalado no mesmo AS onde seus acessos são feitos, ou seja, a aplicação que faz chamadas ao componente deve estar no mesmo AS.

Quando o acesso é remoto, em outro servidor de aplicação, não dispomos do recurso de injeção de dependência. Por este motivo, todo stateless session bean implantado em um servidor de aplicação deve receber um nome único, que é utilizado para se obter a referência remota a este componente.

Conforme K19 (2015), antes da versão 3.1, os nomes dos sessions beans não seguiam nenhum padrão, o que dificultava o desenvolvimento em servidores de aplicação distintos. A partir da versão 3.1 os nomes são padronizados e, portanto, portáveis entre os servidores de aplicação. Uma aplicação remota deve acessar o serviço de nomes (JNDI) do AS no qual o EJB que ela deseja utilizar está implantado, conforme a Figura 121. Uma vez com a referência do stateless session bean, o acesso remoto ocorre exatamente como o local, de forma transparente para a aplicação. Logicamente, como o acesso ocorre em outro servidor, o tempo de resposta geralmente é mais lento.


138

As regras para nomenclatura podem ser acessadas em: <https://jcp.org/en/jsr/detail?id=318>.

IMPORTANTE

FIGURA 121 – LOOKUP DO NOME DO EJB

FONTE: K19 (2015)

2.4 CICLO DE VIDA

As instâncias dos stateless session beans são administradas pelo EJB Container dentro do servidor de aplicação. Devemos entender o ciclo de vida desses objetos para utilizar corretamente a tecnologia EJB. Três aspectos fundamentais dos stateless session beans ajudam a entender o ciclo de vida das instâncias (K19, 2015).1. Uma única instância de um SLSB pode atender às chamadas de diversos

clientes.2. Uma instância de um SLSB não atende a duas chamadas ao mesmo tempo. 3. O EJB Container pode criar várias instâncias do mesmo SLSB para atender

mais rapidamente às chamadas dos clientes.

O ciclo de vida das instâncias de um stateless session bean possui apenas dois estados: NÃO EXISTE e PRONTO onde as variações de estado são as seguintes (K19, 2015):

NÃO EXISTE -> PRONTOAntes de ser criada, dizemos que uma instância de um SLSB se encontra

no estado NÃO EXISTE. Neste estado, uma instância não pode atender a chamadas dos clientes. De acordo com a quantidade de chamadas e critérios de cada servidor de aplicação, o EJB Container pode criar novas instâncias de um SLSB. Cada instância criada passa para o estado PRONTO, onde pode começar a receber chamadas.

PRONTO -> PRONTOQuando uma chamada é realizada, o EJB Container seleciona uma instância

entre as que estejam no estado PRONTO para realizar o atendimento. Enquanto uma instância está atendendo a uma chamada ela não pode atender a outras chamadas. Depois de finalizar o atendimento, a instância volta para o estado PRONTO podendo receber outras chamadas.


139

PRONTO -> NÃO EXISTENovamente, de acordo com a quantidade de chamadas e critérios de cada

servidor de aplicação, o EJB Container pode destruir instâncias que estejam no estado PRONTO, levando-as ao estado NÃO EXISTE.

2.5 ESCALABILIDADE, POOL E CALL-BACKS

K19 (2015) coloca que as características dos stateless session beans favorecem a escalabilidade da aplicação pois, de acordo com a demanda, o EJB Container cria novas instâncias e cada instância pode atender vários clientes.

O EJB Container administra as instâncias criadas através de um Pool. Cada servidor de aplicação oferece configurações específicas para melhorar a eficiência no atendimento das chamadas. Por exemplo, o Glassfish permite que uma quantidade máxima de instâncias de um determinado stateless session beans seja definida pela aplicação (K19, 2015).

Através dos call-backs podemos associar algoritmos nas transições de estado dos stateless session beans. Isso ocorre através de anotações definidas para esta finalidade, conforme demonstrado nas Figuras 122 e 123.

FIGURA 122 – ANOTAÇÃO @POSTCONSTRUCT



140

FIGURA 123 – ANOTAÇÃO @PREDESTROY


Na linha 15 da Figura 122, colocamos a anotação @PostConstruct. Como o nome indica, o objetivo desta anotação é fazer com que este método execute quando uma nova instância é criada. Já na linha 32 da Figura 123, o objetivo da anotação @PreDestroy é executar o que estiver definido no método logo antes da instância ser destruída pelo AS. Ambas as anotações somente podem ser colocadas antes de métodos.

2.6 MÉTODOS ASSÍNCRONOS

A partir da versão 3.1 dos EJBs, é possível definir métodos assíncronos. Tais métodos são utilizados para implementar tarefas longas que não podem bloquear o resto da aplicação até que sejam encerradas. Por exemplo, um processo de compra on-line possui alguns passos que não podem ser assíncronos como a seleção dos produtos, o fechamento da conta e o processo de pagamento. Já a comunicação do sistema de compra com a parte de logística não precisa ser síncrona. É possível, após a realização da compra de um produto, chamar um método assíncrono para agendar a entrega. Neste contexto, assíncrono significa que será atendido em algum momento próximo. Em geral, o servidor de aplicação coloca a execução destes métodos em pilhas e os executa em sequência. Observe que isto não significa um atraso de dias ou semanas na execução, mas sim de minutos.


141

Nem todas as operações podem ou devem ser colocadas para executar de forma assíncrona. O modelo de negócios deve ser avaliado para ver se permite este tipo de flexibilidade.

IMPORTANTE

Para utilizarmos os métodos assíncronos, basta anotar a classe ou o(s) método(s) que deve(m) ser definido(s) como assíncrono(s) através da anotação @Asynchronous (Figura 124). Podemos observar que o retorno dos métodos assíncronos é feito através da interface Future, pertencente ao pacote java.util.concurrent. Através desta interface é possível verificar se a tarefa já foi concluída pelo método isDone() e também recuperar o resultado através do método get().

FIGURA 124 – MÉTODOS ASSÍNCRONOS


142


• Muitos sistemas corporativos são desenvolvidos seguindo a arquitetura definida pelo padrão EJB. Ao utilizar esta arquitetura, alguns recursos são disponibilizados automaticamente pelo servidor de aplicação.

• Os dois principais tipos de EJB são os stateless session beans e os statefull session beans.

• Transações, segurança, remotabilidade e concorrência são alguns dos recursos disponibilizados automaticamente pelo servidor de aplicação.

• A principal característica dos stateless session beans é a não manutenção de estado conversacional.

• Os stateless session beans podem ser locais ou remotos.

• Os EJBs podem ser injetados em aplicações web, independentemente de se utilizar Servlets ou Managed Beans no back end.

RESUMO DO TÓPICO 1

143

1 Implemente uma interface web para a calculadora do exemplo utilizando html. A interface deve permitir a utilização de todas as operações.

2 Faça o mesmo que foi solicitado na questão 1, utilizando JSF. Você deve implementar a interface através de um xhtml e o managed bean que fará a interação com o stateless session bean.

3 Descreva detalhadamente o ciclo de vida de um stateless session bean.

AUTOATIVIDADE

144

145

TÓPICO 2

STATEFUL SESSION BEAN E SINGLETON SESSION BEANS

UNIDADE 3

1 INTRODUÇÃOEnquanto a ideia dos stateless session beans era representar um processo

ou uma regra de negócio através de um componente composto por uma ou mais classes e seus métodos, os stateful session bean trabalham de modo a representar um conceito da aplicação cujo estado deva ser mantido, como um cliente, um produto ou um carrinho de compras (Figura 125). Para resumir...um STATEFUL session bean tem por objetivo manter estado conversacional.

K19 (2015) coloca que existem duas necessidades fundamentais para serem observadas nos STATEFUL session bean:

1) Cada instância de CarrinhoBean pode atender somente a uma requisição. Imagine a confusão se os produtos de um cliente se misturassem com os produtos de outro.

2) Os produtos adicionados devem ser mantidos entre as chamadas dos métodos da classe, o que configura o estado conversacional.

FIGURA 125 – CARRINHOBEAN

FONTE: K19 (2015)

146


2 STATEFULL SESSION BEANS 3.0Da mesma forma que os stateless session beans, o primeiro passo é a

definição de sua interface. Considerando o exemplo de carrinho de compras, uma possível implementação da interface é mostrada na figura a seguir.

FIGURA 126 – INTERFACE PARA O BEAN

FONTE: K19 (2015)

Após a definição desta interface, agora, implementaremos a classe java que utiliza a Interface.

FIGURA 127 – CADASTRO DE PESSOA

FONTE: K19 (2015)

Para encerrar, precisaremos definir o tipo statefull para o session bean e se ele será acessado localmente ou remotamente. Ambas as configurações são feitas através de anotações, conforme demonstrado na figura a seguir. Podemos perceber as linhas 9 e 10 que fazem estas configurações.

TÓPICO 2 | STATEFUL SESSION BEAN E SINGLETON SESSION BEANS

147

FIGURA 128 – CONFIGURAÇÕES DO EJB

FONTE: K19 (2015)

É notório que os stateless e statefull session beans são configurados exatamente da mesma forma. O que muda é a característica do componente, que deve ser utilizado de acordo com o contexto de sua aplicação.

IMPORTANTE

3 STATEFULL SESSION BEANS 3.1Na versão 3.1 quando o acesso é local, não há mais necessidade de se

definir uma interface ou utilizar a anotação @Local, bastando anotar uma classe com @Stateful, conforme a Figura 129.

3.1 CICLO DE VIDA DOS STATEFULL SESSION BEANS

Todas as instâncias criadas pelo AS, mais especificamente pelo EJB Container, têm seu ciclo de vida administrado de forma transparente para o desenvolvedor. Um statefull session bean possui somente três estados: NÃO EXISTE, PRONTO, PASSIVADO.

148


FIGURA 129 – VERSÃO 3.1

FONTE: K19 (2015)

As transições de estado possíveis para um statefull session bean são demonstradas abaixo K19(2015):

NÃO EXISTE -> PRONTOAntes de ser criada, dizemos que uma instância de um statefull session

bean se encontra no estado NÃO EXISTE. Neste estado, uma instância não pode atender às chamadas do seu cliente. Quando um cliente recebe por injeção ou recupera por lookup um statefull session bean, o EJB Container cria uma nova instância desse componente para atender exclusivamente a esse cliente. Nesse instante, logo após ser criada, a instância se encontra no estado PRONTO e pode atender às chamadas do seu respectivo cliente.

PRONTO -> PASSIVADOUma instância de um statefull session bean fica ociosa enquanto não estiver

processando uma chamada do seu cliente. Para não consumir a memória do computador, depois de um certo tempo de ociosidade, o EJB Container pode transferir o conteúdo de uma instância ociosa para dispositivos secundários de armazenamento (hard disk), em um processo conhecido como passivação e deixa a instância no estado PASSIVADO. Outros fatores, além da ociosidade, podem levar o EJB Container decidir passivar instâncias dos SFSBs. Por exemplo, quando um certo limite de instâncias no estado PRONTO for atingido.

PASSIVADA -> PRONTOSe o cliente de uma instância passivada realizar uma chamada a ela, o

EJB Container realizará automaticamente o processo de ativação. Esse processo consiste na transferência do conteúdo da instância passivada para a memória principal novamente, deixando-a apta a atender chamadas no estado PRONTO.

PRONTO -> NÃO EXISTEEm determinadas situações, uma instância de um stateful session bean pode

não ser mais útil. Por exemplo, quando o cliente de um carrinho de compras finaliza a compra, a instância que representa o carrinho pode ser destruída. É possível ainda adicionar um método de negócio anotado com @Remove, declarando que após a execução desse método a instância não é mais necessária (Figura 130).


149

FIGURA 130 – MÉTODO REMOVE

FONTE: Adaptado de K19(2015)

PASSIVADO -> PRONTO -> NÃO EXISTE

Uma instância pode ser passivada porque ficou ociosa quando estava no estado PRONTO. Isto ocorre quando um cliente não realiza chamada durante um tempo. Quando uma instância passivada não é mais útil, o EJB Container a ativa e depois a destrói (Figura 131).

FIGURA 131 – MUDANÇA DE ESTADO

FONTE: K19 (2015)

150


3.2 CALLBACKS

Da mesma forma que nos stateless session beans, os stateful session beans permitem a associação de lógicas específicas nas transições de estado de seu ciclo de vida.

As anotações @PostConstruct e @PreDestroy estão disponíveis nos stateful session beans e, como existe um estado novo no ciclo de vida, foram adicionadas as anotações @PrePassivate e @PostActivate. Estas novas anotações permitem a adoção de lógica em métodos antes da passivação e logo depois da ativação. Todas estas anotações estão demonstradas na figura a seguir.

FIGURA 132 – ANOTAÇÕES DISPONÍVEIS NOS STATEFUL SESSION BEANS


4 SINGLETON SESSION BEANS

Surgido na versão 3.1 da especificação Enterprise Java Beans, a ideia fundamental deste tipo de componente é o compartilhamento de dados transientes entre todos os usuários de uma aplicação. Um exemplo típico seria um contador para o número de usuários conectados na aplicação cujo possível código está demonstrado na Figura 133.


151

Para que este código contabilize corretamente o número de usuários conectados, deve ser mantida uma única instância deste EJB.

FIGURA 133 – CÓDIGO FONTE PARA A CRIAÇÃO DO DATATABLE

FONTE: K19 (2015)

Este tipo de EJB é baseado no Padrão de Projeto conhecido como Singleton. Maiores detalhes sobre este padrão de projeto podem ser obtidos em: <http://www.devmedia.com.br/padrao-de-projeto-singleton-em-java/26392>.

IMPORTANTE

Para implementar um Singleton Session Bean, é uma boa prática definir uma interface com as assinaturas dos métodos de negócio (Figura 134). No exemplo abaixo criaremos um singleton session bean para implementar um sistema de chat.

FIGURA 134 – LISTAGEM DE PESSOAS

FONTE: K19 (2015)

152


Os próximos passos seriam a implementação dos métodos propriamente ditos dentro de uma classe java que serviria como o Singleton Session Bean, a definição de que o mesmo seria um singleton, através da anotação @Singleton e, finalmente, a especificação do tipo de acesso deste bean através da anotação @Local ou @Remote. Caso o acesso ao Singleton Session Bean seja local, basta anotá-lo com o @Singleton.

4.1 CICLO DE VIDA

De forma análoga aos session beans já estudados nesta unidade, os singleton session beans tem seu ciclo de vida gerenciado pelo EJB Container (parte integrante do AS... não esqueça). O singleton session bean possui dois estados: NÃO EXISTE e PRONTO.

As variações entre estes estados são descritas abaixo, conforme K19 (2015):

NÃO EXISTE -> PRONTOAntes de ser criada, dizemos que uma instância de um Singleton Session

Bean se encontra no estado NÃO EXISTE. Neste estado, uma instância não pode atender às chamadas dos clientes da aplicação. O EJB Container cria apenas uma instância para cada Singleton Session Bean. Por padrão, o EJB Container é quem decide quando a criação da instância de um Singleton Session Bean deve ser realizada, apesar de ser possível determinar que essa criação seja realizada na inicialização da aplicação através da anotação @Startup (Figura 135).

FIGURA 135 – ANOTAÇÃO @STARTUP

FONTE: O autor


153

PRONTO -> NÃO EXISTEQuando a aplicação é finalizada, o EJB Container destrói as instâncias

dos Singleton Session Beans, passando do estado PRONTO para o NÃO EXISTE (Figura 136).

FIGURA 136 – CICLO DE VIDA DOS SINGLETON SESSION BEANS

FONTE: K19 (2015)

Os callbacks @PostConstruct e @PreDestroy também estão disponíveis para os Singleton Session Beans através das anotações respectivas.

IMPORTANTE

154

Neste tópico você viu:

• Os statefull session beans possuem praticamente as mesmas funcionalidades dos stateless session beans, entretanto, são caracterizados pela manutenção do estado conversacional.

• Os singleton session beans são um terceiro tipo de session bean que permite a manutenção e compartilhamento de estado entre todos os usuários de uma aplicação.

• O conhecimento do ciclo de vida dos session beans permite sua utilização mais efetiva.

• Tanto os stateful quanto os singleton session beans permitem a utilização de métodos de callback que podem possuir lógica de negócios a ser realizada após a mudança de estado no ciclo de vida dos mesmos.

RESUMO DO TÓPICO 2

155

AUTOATIVIDADE

1 Implemente uma interface web para a loja virtual do exemplo de stateful session bean, utilizando

2 Faça uma implementação de singleton session bean, que permita contar o número de usuários simultâneos de sua loja virtual.

3 Descreva detalhadamente o ciclo de vida de um statefull session bean.

156

157

TÓPICO 3

CONTEXT AND DEPENDENCY INJECTION

UNIDADE 3

1 INTRODUÇÃOConforme K19 (2015), as aplicações corporativas trabalham mesclando o

container WEB para a camada de apresentação e o container EJB para a camada de negócios. A especificação JEE permite que a integração entre estes dois containers possa ser feita de forma mais fácil através da especificação Context and Dependency Injection (CDI). Os dois pontos que destacaremos na arquitetura CDI são o mecanismo de injeção de dependência e o gerenciamento do ciclo de vida dos objetos por contextos.

Conforme Thiago (2010), existem vantagens e desvantagens na utilização da injeção de dependência. Algumas das vantagens são:

1) Simplificação no código da aplicação. Com a injeção de dependência, os objetos da aplicação são liberados da tarefa de trazer suas próprias dependências (redução de código para inicialização e configuração de dependências); eles ficam livres para executar apenas suas regras negociais, pois, sabem que as suas dependências estarão lá quando necessárias.

2) Testabilidade. Se as dependências podem ser injetadas em um componente, torna-se possível injetar implementações mocks destas dependências.

3) Baixo acoplamento entre os objetos. O objeto conhece suas dependências apenas por sua interface pública (não por sua implementação, nem por como foram instanciadas). Assim, a dependência pode ser trocada por uma implementação diferente, sem que o objeto dependente conheça a diferença.

4) Flexibilidade no gerenciamento do ciclo de vida dos objetos. Objetos podem ser colocados em um cache, serem um singleton ou ter uma vida curta – tudo passa a ser controlado por meio de configurações e/ou pelo container.

Thiago (2010) também lista algumas desvantagens na injeção de dependência:

1) Dificuldade no acompanhamento do código. Você vê a existência de um método no código, você sabe que ele está sendo chamado por alguém para injetar um valor, mas não se tem certeza de quando isso irá acontecer ou qual o valor que é injetado, o que pode dificultar a rastreabilidade.


158

2) Quando se utiliza a DI baseada em propriedades (através de métodos), faz-se necessário marcar suas dependências como públicas. Para que se utilize uma injeção via setXxx(), por exemplo, esse método tem de ser tornado público. Desta forma devemos tomar cuidado para não quebrar o encapsulamento de nossos objetos.

3) A cadeia de objetos pode se tornar muito grande. Mesmo que seja necessário fazer apenas uma operação, todas as dependências são criadas e/ou precisam ser resolvidas.

O termo injeção de dependência foi criado por Martin Fowler. Maiores detalhes podem ser observados em: <http://martinfowler.com/articles/injection.html>.

IMPORTANTE

2 PRODUCER METHODS E ATTRIBUTES

Na especificação CDI, os seguintes tipos de objetos possuem suporte aos recursos do container:

• Managed beans e session beans;• Criados por producer methods ou producer fields;• Recursos em geral (Persistence Contexts, Persistence Units, EJBs locais ou remotos

e web services);

Os producer methods são métodos que produzem objetos a serem administrados pelo container CDI para serem injetados em outros objetos (K19, 2015). Um exemplo de método produtor pode ser visto na Figura 137. Na linha 1 está a anotação que define o método como um Producer Method.

FIGURA 137 – PRODUCER METHOD

FONTE: K19 (2015)

O funcionamento dos atributos é bastante semelhante, bastando marcar um atributo com a anotação @Produces para fazer com que o mesmo possa ser injetado e ter seu ciclo de vida gerenciado pelo container. Um exemplo de código fonte pode ser visto na Figura 138.

TÓPICO 3 | CONTEXT AND DEPENDENCY INJECTION

159

FIGURA 138 – CDI COM ATRIBUTOS

FONTE: K19 (2015)

3 EXPRESSION LANGUAGE (EL) NAME

Na arquitetura CDE, os objetos gerenciados pelo container podem ser acessados através de EL. Para que isso ocorra, devemos aplicar a anotação @Named aos objetos que possuirão um EL Name. Um exemplo de código fonte pode ser visto na Figura 139. Nas linhas 9 e 10 podemos perceber as anotações que definem que a classe é um stateless session bean, que pode ser injetada com o nome geradorDeApostas. Ainda nesta classe, definimos o atributo produtos como um objeto a ser gerenciado pelo container CDI, chamado pelo EL name produtos. O mesmo foi feito com os dois métodos entre as linhas 18 e 28.

FIGURA 139 – COMPONENTE DATA TABLE


Para que o CDI seja ativado no AS, é necessário fazer uma modificação nas configurações do mesmo através da adição de um arquivo chamado beans.xml no diretório src/main/resources/META-INF/. O conteúdo do arquivo está demonstrado na Figura 140.


160

FIGURA 140 – BEANS.XML

FONTE: CDI-SPEC (2015)

A funcionalidade da tabela não mudou, entretanto, o usuário agora pode escolher quantos registros quer em tela. Um teste interessante é inserir mais valores na lista que alimenta a tabela e observar seu comportamento.

Caso você queira se aprofundar na especificação CDI, sugerimos o material disponível no link: <http://www.cdi-spec.org/>.

IMPORTANTE

4 ESCOPOS E CONTEXTOSOs objetos administrados pelo container CDI são administrados em

contextos, que são coleções de objetos relacionados logicamente que devem perdurar durante um período de tempo (K19, 2015). Quatro tipos de contextos são definidos pela especificação:

1) Request: utilizado em aplicações web, onde a cada requisição http um novo contexto de request é criado pelo container e destruído no final do processamento.

2) Session: tem seu ciclo de vida associado a uma http session, onde o que acontece quando a http session acontece com o context session;

3) Application: existe apenas um application context por aplicação, que é criado quando a aplicação é inicializada e destruído quando a aplicação é finalizada.

4) Conversation: existe o transient, semelhante ao request e o long running, semelhante ao session. A diferença é que nos conversations context a criação e destruição dos contextos acontece através da chamada de métodos.

Para definir o escopo dos objetos, são utilizadas as anotações @rRequestScope, @SessionScoped, @ApplicationScoped e @ConversationScoped. A Figura 141 traz um exemplo de código fonte com a utilização das anotações.

TÓPICO 3 | CONTEXT AND DEPENDENCY INJECTION

161

FIGURA 141 – ANOTAÇÕES CDI


162

Neste tópico, vimos que:

• O context and dependency injection permite que se utilize injeção de dependência para integrar a camada de interface com a camada de negócios.

• Através da injeção de dependência, o ciclo de vida de alguns objetos passa a ser controlado por uma parte especial do AS conhecida como EJB Container.

• Os objetos utilizados no CDI podem ser atributos ou mesmo objetos criados em métodos, conhecidos como producers.

• Para utilizar CDI, um arquivo beans.xml deve ser criado em um diretório específico da aplicação.

• Existem basicamente quatro tipos de contextos onde os objetos administrados pelo container CDI são armazenados: Request, Session, Application e Conversation.

RESUMO DO TÓPICO 3

163

AUTOATIVIDADE

1 Implemente uma aplicação web utilizando JSF que faça uso do contexto CDI conhecido como SessionContext.

2 Descreva detalhadamente de que forma funciona a injeção de dependências dentro de uma aplicação JavaEE.

164

165

TÓPICO 4

JAVA MESSAGE SERVICE (JMS)

UNIDADE 3

1 INTRODUÇÃOConforme K9 (2015), os ambientes corporativos são geralmente compostos

por diversos sistemas para auxiliar o funcionamento dos processos. Em algum momento, tais sistemas deverão trocar informações entre si. Existem diversas abordagens para esta integração e a especificação JavaEE traz uma solução robusta através de um Middleware Orientado a Mensagens (MOM). Através do MOM é possível enviar mensagens para outros sistemas de forma assíncrona, além de permitir que essa transmissão aconteça de forma completamente desconectada, onde os sistemas conhecem o Middleware, mas não conhecem uns aos outros.

Todo servidor de aplicação que implemente a especificação JavaEE deve implementar um MOM de acordo com a arquitetura definida pela JMS, o que acaba por envolver outras tecnologias da especificação, como EJB por exemplo.

2 FILAS E TÓPICOSOs dois tipos de mensagens possíveis na arquitetura JMS são as filas ou os

tópicos, sendo que ambos devem estar previamente configurados no middleware.

Uma mensagem que for enviada para uma fila pode ser recebida por apenas um sistema, no que é conhecido como point-to-point, enquanto uma mensagem enviada para um tópico pode ser recebida por diversos sistemas no mecanismo conhecido como publish-and-subscribe (K19, 2015).

Para configurar uma fila e um tópico JMS no AS (em nosso caso consideramos o Wildfly) você deve alterar o arquivo de configuração standalone-full.xml disponível dentro da pasta de instalação do AS\standalone\configuration\ (Figura 142). Dentro deste arquivo procure pela tag <jms-destination> e lá faça as alterações conforme a Figura 142.


166

FIGURA 142 – ARQUIVO DE CONFIGURAÇÃO

FONTE: O autor

FIGURA 143 – ARQUIVO DE CONFIGURAÇÃO


Agora inicie o WildFly e procure pelas mensagens da Figura 143 no console. Estas mensagens indicam que a configuração foi feita com sucesso.

TÓPICO 4 | JAVA MESSAGE SERVICE (JMS)

167

FIGURA 144 – MENSAGENS DO CONSOLE

FONTE: K19 (2015)

Todo sistema que desejar trocar mensagens através de filas ou tópicos deve obter uma conexão JMS através das fábricas cadastradas no MOM. De acordo com a especificação, os provedores JMS em ambientes JavaEE devem ofertar uma fábrica de conexões-padrão, que pode ser obtida através do serviço JNDI executando um JNDI para o nome java:comp:DefaultJMSConnectionFactory (K19, 2015).

As fábricas de conexão, as filas e os tópicos são objetos administrados pelos provedores JMS e obtidos através de pesquisas ao serviço de nomes conforme definido pela especificação JNDI (Figura 145).

FIGURA 145 – SERVIÇO DE NOMES

FONTE: K19 (2015)

As aplicações JavaEE podem obter tópicos, fábricas de conexão e filas através de injeção de dependência, conforme pode ser visto na Figura 146. A anotação @Resource marca o Topic, o ConnectionFactory e a Queue como recursos gerenciados pelo AS, sendo que cada um faz um lookup para o endereço definido no atributo.

FIGURA 146 – INJEÇÃO DE DEPENDÊNCIA

FONTE: O autor


168

Os contextos são responsáveis pela criação dos produtores, consumidores e das mensagens propriamente ditas. Estes contextos, demonstrados na Figura 147, podem ser obtidos através de fábrica de conexões (linha 36) ou através de injeção de dependência (linhas 38 e 39).

FIGURA 147 – CONTEXTOS


Os produtores e consumidores podem ser criados já com um destino específico, seja uma fila ou um tópico, conforme demonstrado na Figura 148.

FIGURA 148 – PRODUTOR E CONSUMIDOR

FONTE: O autor.

FONTE: O autor.

As mensagens são produzidas através do tipo String e enviadas pelo método send de um objeto do tipo JmsProducer (Figura 149). Entre as linhas 51 e 53 podemos observar o envio de uma mensagem.

FIGURA 149 – ENVIO DE MENSAGEM

O consumo de mensagens pode ser feito através do método receiveBody() de um objeto JMSConsumer, conforme a Figura 150.

FIGURA 150 – CONSUMO DE MENSAGEM

FONTE: O autor


169

Na linha 54 é utilizado o parâmetro String.class, que utiliza a api de Reflection do Java. Para conhecer mais sobre esta importante api, acesse o site: <http://www.caelum.com.br/apostila-java-testes-xml-design-patterns/reflection-e-annotations/>.

IMPORTANTE

Para demonstrar o funcionamento destas tecnologias de modo integrado, criaremos um exemplo de uma classe que envia mensagens para a fila que registramos no WildFly. O código-fonte está demonstrado na Figura 151. É possível observar que fizemos o lookup para o nome que configuramos no arquivo de configuração do AS através do JNDI (linha 30).

FIGURA 151 – CLASSE PARA ENVIO DE MENSAGENS


3 MODOS DE RECEBIMENTOUm objeto do tipo JMSConsumer pode receber mensagens JMS de três

maneiras distintas: Não bloqueante, semibloqueante e bloqueante. Estas maneiras de recebimento dizem respeito à forma como o sistema se comporta em relação ao fato de as mensagens serem assíncronas. Um detalhamento de cada maneira está mostrado abaixo e o exemplo de código fonte pode ser observado na Figura 151:


170

1. Não bloqueante: a execução do sistema não é interrompida, caso a mensagem não seja recebida imediatamente.

2. Semibloqueante: a execução do sistema é bloqueada até que a mensagem seja recebida ou até o término de um período estipulado no método de recebimento da mensagem.

3. Bloqueante: a execução do sistema não continua até que a mensagem seja efetivamente recebida.

FIGURA 151 – MANEIRAS DE RECEBER MENSAGENS

FONTE: Adaptado de K19 (2015).

É possível percorrer as mensagens de uma fila sem removê-las da mesma, através de um objeto do tipo QueueBrowser, criado exclusivamente para esta finalidade. Uma demonstração da utilização do objeto QueueBrowser pode ser vista na Figura 152.

FIGURA 152 – PERCORRENDO UMA FILA DE MENSAGENS

FONTE: O autor


171

De modo a facilitar a busca de mensagens em uma fila, é possível anexar propriedades a estas mensagens. Estas propriedades podem ser utilizadas por todos os assinantes de determinado tópico para filtrar somente o conteúdo que realmente os interessa (Figura 153).

FIGURA 153 – ADICIONANDO PROPRIEDADES A MENSAGENS

FONTE: O autor.

Para simplificar seu aprendizado, em nossos exemplos estamos utilizando mensagens simples de texto. Em aplicações reais você pode criar mensagens de diversos tipos distintos. Os tipos de formato de mensagem disponibilizados pelo JMS são os seguintes:

TABELA 2 – TIPOS DE FORMATO DE MENSAGEM

Interface Tipo do corpo da mensagem

javax.jms.TextMessageUm bloco de texto, representado em java como uma String. Pode ser utilizado para representar uma mensagem como um arquivo XML ou JSON.

javax.jms.ObjectMessage

Um objeto java serializável, como por exemplo um Java Bean.

javax.jms.MapMessage Um objeto contendo diversos pares de chave/valor.

javax.jms.BytesMessage

Um bloco de dados binários representado em java como um array de bytes. Utilizado para interagir com sistemas de mensagens externos que possuem seus próprios protocolos binários de comunicação.

javax.jms.StreamMessage

Uma lista de valores primitivos do Java que pode ser utilizado para representar certos tipos de dados usados por sistemas de mensagem externos.

FONTE: Adaptado de: <https://docs.oracle.com/cd/E23095_01/Platform.93/ATGProgGuide/html/s1102jmsmessageformats01.html>. Acesso em: 12 fev. 2016.


172

JSON ou JavaScript Object Notation é um formato de transmissão de informações através de texto, muito utilizado para aplicações que trabalham com REST. Supostamente apresenta um desempenho maior do que os webservices criados através de SOAP e XML.

IMPORTANTE

O envio de mensagens JMS através de tópicos apresenta-se como uma alternativa interessante para sistemas que necessitem de funcionalidades assíncronas. Mas o que acontece se um ou mais assinantes não estiverem logados no sistema no momento do envio? Estas mensagens serão perdidas e não podem ser recuperadas. A especificação JMS apresenta um tipo especial de tópico que funciona armazenando as mensagens dos assinantes ATÉ QUE eles as recebam. Este tipo de tópico é conhecido como tópico durável. Por exemplo, se determinado assinante estiver desconectado no momento do envio de uma mensagem que este se escreveu para receber, o provedor JMS percebe que o tópico é do tipo durável e armazena a mensagem para envio quando o assinante se conectar novamente.

Para criar um tópico durável, é necessário liberar uma permissão no AS. No caso do WildFly, ela ocorre alterando o elemento <security-settings>, disponível no arquivo standalone-full.xml. A alteração necessária para que se possa criar tópicos duráveis via código é demonstrada na Figura 154.

FIGURA 154 – CONFIGURAÇÃO PARA TÓPICOS DURÁVEIS


Pronto! Graças ao JavaEE e sua vasta gama de tecnologias, você está pronto para desenvolver aplicações web mais robustas e com mais qualidade. Como dissemos no início do tópico, JavaEE é uma especificação extensa e existe muito mais para aprender sobre o tema. Nossa intenção é fornecer uma introdução sólida, para que você possa continuar evoluindo por conta própria.

Sugerimos fortemente que você não limite seus estudos a tecnologias da família Java. Estude frameworks novos como AngularJS, Node.js etc., afinal, a tecnologia evolui dia a dia e não podemos ficar para trás.

Bons estudos e até uma próxima oportunidade!


173


DA NECESSIDADE DE PRINCÍPIOS DE ARQUITETURA DA INFORMAÇÃO PARA A INTERNET DAS COISAS

Analisa-se neste artigo o cenário da Internet das Coisas (IdC) e seus impactos para a sociedade. Identifica-se a necessidade de uma abordagem humanista e sistêmica na área de Arquitetura da Informação, baseada essencialmente em princípios, que componha um arcabouço teórico transdisciplinar para lidar com questões tecnológicas, informacionais e sociais emergentes do fenômeno da IdC.

1 INTRODUÇÃO

O contexto da sociedade atual aponta para uma realidade de convergência, em que os limites entre concreto e digital se tornam cada vez mais tênues. Na trilogia “A Era da Informação: economia, sociedade e cultura”, Castells (1999) faz um amplo diagnóstico da revolução promovida pelas tecnologias da informação e da comunicação, analisando de que forma o advento da Internet redefiniu e continua estabelecendo novas formas de organização da sociedade.

Castells (2003) entende a Internet como “a base tecnológica para a forma organizacional da Era da Informação: a rede”. Este fato fica mais evidente na atual geração - caracterizada pela chamada Internet das Coisas (IdC): são sistemas, no sentido amplo, interligados entre si em diferentes escalas, formando ecossistemas com componentes biológicos, materiais, urbanos – tendo em comum a informação como substrato, que passa a fluir e estar presente literalmente em toda parte. Por isso, a IdC é conhecida também como Internet Ubíqua.

Na IdC, informações passam a se mover em sentido inverso do que ocorria na formação do chamado ciberespaço. O mundo físico é alimentado pelo digital, a realidade é aumentada por aplicações centradas no usuário que promovem consumo e produção de informações. É como se o ciberespaço, que antes era um universo paralelo, transbordasse (KUNIAVSKY, 2010; RESMINI; ROSATI, 2011).

O extraordinário potencial da IdC é o poder que confere aos objetos de uso cotidiano de capturar, processar, armazenar, transmitir e apresentar informações. Interligados em rede, os objetos são capazes de realizar ações de forma independente e gerar dados em quantidade e variedade exponenciais, como produto das interações. Nesse contexto, a informação passa a fazer parte do ambiente, e configuram-se novas formas de atuação das pessoas no mundo.

Considere-se ainda a abrangência, a perversidade e o crescimento expressivo das aplicações da IdC. A Internet conta atualmente com quase 3 bilhões de usuários conectados, conforme o “Global Internet Report” (KENDE, 2014). A previsão do Gartner (2014) é de que o número de dispositivos conectados seja


174

de 26 bilhões em 2020. Em uma análise mais otimista, a Cisco prevê 50 bilhões de objetos no mesmo período, movimentando um mercado de US$ 14,4 trilhões até 2022 (EVANS, 2011). Lucas, Ballay e McManus (2012) anunciam para breve a marca dos trilhões de nós conectados à Rede, número que utilizaram como título do livro dedicado ao tema. Os autores acreditam que a revolução promovida pela IdC representa o futuro da Era da Informação.

A IdC é compreendida, neste cenário, como um fenômeno complexo, observável a partir de múltiplos pontos de vista – social, cultural, econômico, organizacional, tecnológico, informacional – que tem como consequência direta a materialização de ambientes permeados por informação. O objetivo deste artigo é argumentar sobre a necessidade de uma Arquitetura da Informação baseada em princípios para lidar com as questões emergentes deste fenômeno.

2 INTERNET DAS COISAS (IdC)

O termo Internet of Things (Internet das Coisas) foi cunhado em 1999 por Kevin Ashton, cofundador do Auto-ID Center do Massachusetts Institute of Technology (MIT). Em recente artigo, Ashton (2009) afirmou que a ideia original da IdC previa a conexão de todos os objetos físicos à Internet, com capacidade de capturar informações por meio de identificação por radiofrequência (RFID) e tecnologias de sensoriamento – as quais os permitiriam observar, identificar e compreender o mundo independentemente das pessoas e suas limitações de tempo, atenção e precisão. Em 2005 a União Internacional de Telecomunicações (UIT) previu que a possibilidade de identificação única de itens, associada a tecnologias de sensores e a capacidade de interagir com o ambiente criaria uma Internet das Coisas (ITU-T, 2012).

Em abordagem didática, Davis (2008) define quatro estágios de evolução da Internet – Web 1.0, voltada para a conexão e obtenção de informações na Rede; Web 2.0 ou Web Social, caracterizada pela preocupação com a experiência do usuário e a colaboração por meio das redes sociais; Web 3.0 ou Web Semântica, com esforços concentrados na atribuição de significado e contexto às informações; e o estágio atual, a Web Ubíqua, constituída pela Internet das Coisas (IdC), fundamentada pela conectividade e interatividade entre pessoas, informações, processos e objetos, por meio de tecnologias que possibilitam acesso à rede por qualquer pessoa, de qualquer lugar, a qualquer tempo, utilizando quaisquer dispositivos, incluindo equipamentos multifuncionais com sensores inteligentes, tais como eletrodomésticos, automóveis, roupas etc., a partir de aplicações que se adaptam dinamicamente às necessidades dos usuários (DAVIS, 2008; W3C, 2010). Estamos, portanto, na era da computação embutida e distribuída pelo ambiente (KUNIAVSKY, 2010).

3 DESAFIOS E QUESTÕES EMERGENTES DA IDC

O mundo físico está se tornando um grande ecossistema de informação. Os objetos tanto podem sentir o ambiente como se comunicar independentemente de intervenções humanas. Tornam-se, portanto, participantes ativos nos


175

processos de negócio, e passam a ser reconhecidos e identificados em ambientes inteligentes, que recuperam dinamicamente informações na Internet, promovendo sua funcionalidade adaptativa e responsiva (CHUI; LÖFFLER; ROBERTS, 2010; WEBER, 2013).

A IdC afeta a humanidade em diferentes escalas. Envolve desde nanochips implantados em seres vivos a objetos de uso comum interconectados, equipados com sensores e identificados por RFID – capazes de trocar informações entre si, com as pessoas ou com o ambiente – até cidades inteiras sendo projetadas de maneira totalmente conectada e automatizada (as chamadas smart cities ou cidades inteligentes). As formas de manifestação da IdC são heterogêneas, incluindo dispositivos de múltiplos propósitos (celulares, tablets, relógios e óculos inteligentes) e dispositivos especializados (sensores de temperatura, dispositivos ativos e passivos etc.), suportados por uma variedade de plataformas de software e hardware. O desafio de projetar espaços na IdC é contemplar os diferentes níveis de granularidade de forma transparente, garantindo a interoperabilidade.

As inovações que surgem no âmbito da IdC ampliam o potencial humano em diversas áreas - tais como planejamento urbano (cidades, edifícios e trânsito inteligentes), meio ambiente (energia, água), indústria, comércio, turismo, educação, saúde, trabalho, segurança, programas sociais, governo – com soluções capazes de promover desenvolvimento econômico, sustentabilidade e qualidade de vida.

O problema é que a velocidade com a qual a tecnologia se difunde na vida das pessoas é maior do que a possibilidade de previsão de seus impactos, sejam positivos ou negativos. E, dada a infinidade de aplicações e a abrangência da IdC, os efeitos negativos são temerários, considerando que o processo de mudança tem sido conduzido em grande medida por empresas privadas, com interesses nem sempre coincidentes com os da sociedade. Lucas, Ballay e McManus (2012), Greenfield e Kim (2013), Greenfield (2006), Norman (2009), e outros autores alertam para os riscos de definições impulsionadas essencialmente por forças de mercado moldarem o futuro.

O urbanista e crítico Adam Greenfield (2006) denomina o fenômeno da IdC de everyware, em alusão aos objetos conectados em toda parte. Ele acredita que a IdC deve ser cuidadosamente arquitetada no momento presente, pois trará cada vez mais implicações para a humanidade. Ressalta que everyware é inevitável, e toda a infraestrutura necessária para sua implantação já existe. Mas a forma que tomará ainda é passível de mudanças e a articulação de padrões essenciais para um desenvolvimento ético e responsável é urgente. A dificuldade está em compreender o significado das escolhas de futuros possíveis em um curto intervalo de tempo, e fazer opções conscientes, considerando os impactos de uma “vida colonizada pela tecnologia da informação”. Dependendo de como for definida, everyware pode ser uma questão imediata ou um “problema para cem anos [nas palavras de Gene Becker, da HP]: um desafio técnico, social, ético e político de extraordinária sutileza e dificuldade [...]. Mapear as necessidades e vontades de pessoas reais em qualquer situação está longe de ser tarefa óbvia”. (GREENFIELD, 2006, p. 179).


176

A questão do poder de atuação (ou agência) conferida aos objetos na IdC é um dos pontos mais críticos para discussão. Objetos tornam-se ativos, capazes de promover ações independentemente dos seres humanos. Santucci (2014) preocupa-se com a autonomia das pessoas em um mundo onde os objetos conectados inteligentes superam os humanos em uma proporção de pelo menos 1 a 10. Como observa Floridi (2013, min. 1:14), as pessoas podem simplesmente não querer interagir com entidades-robôs. “Quem vai se adaptar a quem?”, afirma.

Objetos ganham vida, passam a ser agentes, a perceber estímulos do ambiente, produzir informações e interagir com as pessoas e outros objetos. Mas a responsividade e a interatividade foram concebidas a partir de premissas, baseadas no modelo mental e nas motivações de quem as idealizou. É preciso investigar até que ponto as respostas inteligentes e decisões independentes dos objetos estão de acordo com as necessidades e vontades dos seres humanos que os utilizam. Um dos perigos apontados por Donald Norman (2009) é o de pessoas criativas e produtivas tornarem-se servos dos objetos, preocupando-se mais com seu funcionamento do que usufruindo de seus benefícios.

“Como mudar a forma de interação com nossas máquinas para obter melhores vantagens de suas virtudes e forças, ao mesmo tempo eliminando as ações inoportunas e perigosas?”, indaga Norman (2009, p. 8). A melhor maneira de promover a interação suave entre pessoas e dispositivos inteligentes é aumentando a coordenação e a cooperação entre ambos, sugere o autor. Afirma ainda que os produtos estão ficando mais espertos, inteligentes, exigentes e presunçosos. Passam a fazer parte de um ecossistema social, portanto, precisam de traquejo, habilidades comunicativas, e até mesmo emoções. O autor ressalta a dificuldade de ignorar um sistema que não conseguiu antecipar a necessidade de um usuário: “ele pode simplesmente ignorá-lo, se for possível ignorar uma casa que constantemente pisca sugestões sobre contadores, paredes e pisos”. McEwen e Cassimally (2013, p. 24) observam que este problema ganha dimensões mais amplas ao incluírem-se as centenas de novos serviços e aplicações espalhadas pelos objetos ao redor do mundo: “haverá uma cacofonia em busca de atenção”.

“Como pode uma máquina discernir o que é importante, se os contextos de importância variam?”, continua Norman (2009, p. 11). Para o autor, a falta de senso comum é a maior causa da inabilidade de comunicação entre pessoas e máquinas. O senso comum das máquinas é a medida do senso comum daqueles que as programaram, em um momento desprovido de contexto. O contexto é apenas inferido. Quando isso ocorre com uma pessoa, é esperado que utilize criatividade para a solução de problemas”. Nesse sentido, o autor indaga: “seriam estes sistemas realmente inteligentes” e afirma: “não, são apenas responsivos”. (NORMAN, 2009, p. 29). A inteligência está na mente daqueles que os projetaram, e que cuidadosamente tentam antecipar todas as condições e reações possíveis em cada situação, para programar respostas adequadas. Nessa linha, Floridi (2013, min. 00:43) concorda que os dispositivos sejam espertos (smart) – capazes de fazer coisas interessantes; mas não inteligentes.


177

Em geral, defende Norman (2009), as soluções são valiosas e úteis, mas ocorrem falhas, pois raramente é possível inferir o conjunto de informações contextuais e circunstanciais com a mesma acurácia e riqueza dos sensores próprios dos seres humanos, que além de tudo criam representações complexas do mundo e de suas ações, bem como expectativas precisas com base em uma longa história de interação. Ele acredita que o risco não significa que o melhor caminho seja “rejeitar a ajuda das máquinas inteligentes, pois podem ser verdadeiramente proveitosas; mas é preciso socializá-las, para que aprimorem a forma com a qual se comunicam e interagem com as pessoas”.

A questão da agência dos objetos traz ainda dificuldades na determinação da responsabilidade sobre os atos, notadamente em situações imprevistas que gerem dano, prejuízo ou consequências indesejáveis. É preciso haver uma espécie de contrato social entre pessoas e objetos, com as respectivas ramificações éticas. Em um exemplo concreto: deve haver maior preocupação com as bases éticas e consequências de delegar decisões para sistemas automotivos do que com as questões tecnológicas dos carros inteligentes (EUROPEAN COMMISSION, 2012). No caso de um acidente provocado pela ação de um automóvel smart, por exemplo, quem seria responsabilizado?

Em uma perspectiva mais ampla, Greenfield e Kim (2013, p. 519) questionam: “estariam os arquitetos das cidades inteligentes suscetíveis a responsabilização (accountability) democrática, considerando o nível de interferência que podem exercer na vida das pessoas no contexto atual?”. Decisões de arquitetos são atos políticos em âmbito urbano – do mesmo modo como a autoria de um algoritmo destinado a promover a distribuição de recursos cívicos em uma cidade.

Outro ponto é o problema do consentimento informado. Greenfield (2006, p. 66) alerta: “as pessoas podem entrar em everyware de forma inadvertida, inconsciente ou indesejada. A natureza passiva da exposição dos indivíduos a essa infraestrutura de rede pervasiva e os métodos de coleta de dados têm implicações sobre sua vida, saibam ou não, queiram ou não”. Nesses ambientes, a informação está sempre sendo coletada e utilizada como base para ação, arquivada e recuperada de maneira sutil. Os equipamentos operam em conjunto para produzir significado - mas “de que forma a parafernália tecnológica universal se adapta a práticas, atividades, leis e hábitos locais?”, questiona. (GREENFIELD, 2006, p. 29).

Greenfield (2006) indaga se as aplicações ubíquas cumprirão a promessa de uma “tecnologia calma” - conforme imaginado por Weiser e Brown (1996) – onde a sobrecarga cognitiva envolvida nas interações entre pessoas e objetos é reduzida, resultando em interfaces compreensíveis, úteis e usáveis. Ele acredita que as atuais práticas de desenvolvimento em tecnologia da informação (TI) aplicadas a everyware resultarão em experiências de uso inaceitavelmente ruins caso não sejam repensadas; e lembra que o design adequado para everyware é infinitamente mais complexo do que o design de websites ou aplicações desktop.


178

Em relatório do Gartner (2013), a IdC foi apontada como uma das dez tendências estratégicas mundiais de tecnologia de prestação de serviços eletrônicos. O tema tem sido tratado como prioritário pelo setor público de diversos países, especialmente os europeus e asiáticos, com programas de governo dedicados a identificar impactos e potenciais oportunidades trazidas pelas inovações. Nessa conjuntura, a preocupação com a governança da Internet, traduzida na capacidade de definir modelos de funcionamento da rede, torna-se fundamental para garantir seu desenvolvimento sustentável e o atendimento pleno aos interesses da sociedade.

Tecnologias e mercados não podem existir independentemente de princípios abrangentes de um sistema ético e social. A IdC terá um amplo impacto em muitos dos processos que caracterizam a vida cotidiana, portanto, é primordial que seu desenvolvimento seja fundamentado em estratégias orientadas a pessoas. Para isso, aqueles que as projetam devem estar próximos aos que irão utilizá-las (MENDES, 2011).

Numa das palestras de abertura do evento Internet of Things: Philosophy, que teve como mote examinar o que significa ser humano na Internet das Coisas, Gérald Santucci (2014) indagou: como a Internet das Coisas irá transformar-nos – e em quê? Segundo ele, se tivéssemos de escolher uma palavra para descrever o que é a IdC, certamente seria inteligente: objetos, cidades, redes, saúde e transporte inteligentes etc., mas o que inteligente implica em termos de desafios sociais? Quais as formas de governança necessárias em um ambiente inteligente? Como a IdC afeta e transforma a relação entre seres humanos e objetos? Que ética deve orientar a concepção e implementação de objetos inteligentes conectados? Não seriam objetos forçando os seres humanos a se comportarem de acordo com padrões que podem privá-los de sua autonomia ou liberdade?

O grupo de especialistas da Comissão Europeia (IoT Expert Group) identificou seis questões éticas fundamentais no âmbito da IdC: justiça social (combate à exclusão digital e de conhecimentos); confiabilidade (garantia de privacidade e segurança, proteção de dados); clareza sobre contextos (responsabilidades dos atores no ecossistema, privado versus público), clareza sobre metáforas (conveniência versus perigos das coisas inteligentes), clareza sobre agência de objetos (contrato entre pessoas e objetos) e autonomia dos indivíduos (consentimento informado sobre funcionalidades e ações dos objetos) (EUROPEAN COMMISSION, 2012). Estamos caminhando para “um mundo rico em informações, com novas possibilidades e problemas. Indivíduos e instituições obterão maior flexibilidade e produtividade. No entanto, teremos que lutar para equilibrar privacidade, liberdade, conveniência e segurança”. (MORVILLE, 2005, p. 3).

4 PRINCÍPIOS DE ARQUITETURA DA INFORMAÇÃO PARA A IDC

Informações estão sendo incorporadas em objetos de uso comum em toda parte. Isto muda fundamentalmente a maneira de compreender a Arquitetura da Informação, a forma de lidar com suas questões científicas e, definitivamente, a forma de praticá-la. (LACERDA; LIMA-MARQUES, 2014, p. 7).


179

Resmini e Rosati (2011, p. 681) preveem a “necessária adoção de uma visão abrangente para o design de espaços de informação” nessa realidade de convergência física e digital. No prefácio da obra de Resmini e Rosati (2011, p. 97), Peter Morville questiona: “como responder aos novos desafios de criação de caminhos e lugares que conectem espaços físicos, digitais e cognitivos?”

Em Digital Ground, McCullough (2004) parte de princípios arquitetônicos para abordar a modelagem de espaços onde ocorrem ações mediadas digitalmente. Observa que a computação pervasiva cria tais espaços, que subitamente reconfiguram-se de acordo com seus ocupantes, cujo uso pode causar paranoia ou satisfação, dependendo de quão inteligentemente são projetados. E coloca em pauta questões do tipo: “é preferível ser sujeito passivo de monitoramento ou precisar fornecer ativamente identificação?”. “Arquiteturas instanciam intenções, etiquetas e ações particulares”, conclui (MCCULLOUGH, 2004, p. 47).

A conferência “Internet of Things: Philosophy”, ocorrida em 2014, propôs um debate sobre as ramificações da IdC em um contexto filosófico. Dentre as questões levantadas no evento estão: influência da tecnologia sobre as emoções; autopercepção do ser humano e do modo como se relaciona com as coisas; aumento do potencial humano de ação e criação pela tecnologia; mudanças na forma de comunicação, e significado da comunicação homem-máquina e máquina-máquina.

A comunidade de Arquitetura da Informação está se movendo para a expansão das visões de mundo, de seu escopo de ação e de suas motivações, como demonstram os discursos de Morville (2012), Arango (2012), Resmini (2013), Hinton (2013), e Klyn (2013), entre outros. As discussões estão sendo realizadas em publicações, redes sociais e eventos, como as edições do IA Summit 2013, em Baltimore (EUA) e 2014 em San Diego, onde ocorreram mesas redondas sobre o tema Reframing Information Architecture (Reenquadrando a Arquitetura da Informação) (LACERDA; LIMA-MARQUES, 2014).

Chamar para uma renovação epistemológica significa pedir aos estudiosos da disciplina para elevarem-se ao meta-nível do sistema de investigação, a fim de questionar algumas das abordagens atuais. A produção de trabalho inovador duradouro sinaliza o advento de um novo paradigma, ou, pelo menos, a modificação do existente (VAN GIGCH, 1990, p. 127).

No livro “Pervasive Information Architecture”, Resmini e Rosati (2011) propõem o conceito de Arquitetura da Informação Pervasiva como uma abordagem voltada às questões relativas ao design de ecossistemas de informação em ecologias ubíquas. Pela definição dos autores:

Nós denominamos esses novos espaços estendidos de informação – nos quais interagimos tanto com entidades digitais quanto físicas – ecologias ubíquas: são sistemas que conectam pessoas, informações, processos, que estão em toda parte. São arquiteturas da informação pervasivas. São a camada estruturante que atravessa as diferentes mídias, canais e processos: na qual expressamos nosso eu expandido, socialmente. (RESMINI; ROSATI, 2011, p. 140).


180

Lucas, Ballay e McManus (2012, p. 171) buscam em sua obra identificar padrões de design e processos que possam ser utilizados na intersecção entre sistemas de informação e pessoas. O que eles chamam de “rede de trilhões de nós” irá requerer “a emergência de um estilo de Arquitetura da Informação”. “Em uma camada acima da arquitetura de sistemas (que trata de como os computadores em si são construídos), e abaixo da camada de interface de usuários (que é sobre como os sistemas se comunicam com usuários), a Arquitetura da Informação trata do design da informação em si. A rede de trilhões implica em um vasto e heterogêneo fluxo de informações. O único ponto em comum desse fluxo é a informação, e é onde devemos concentrar esforços de design se quisermos buscar integridade global”.

Hiroshi Ishii (2012), cientista e professor do Massachusetts Institute of Technology (MIT), acredita que a inovação tecnológica deve ser direcionada por uma visão (conceitos, princípios) que fundamente o desenvolvimento de aplicações para atender a necessidades de usuários, materializando-se em tecnologias (Figura 1). Proporcionalmente, e considerando a atual conjuntura, as tecnologias teriam a vida útil estimada em um ano, as aplicações atenderiam necessidades de usuários por aproximadamente dez anos, e os princípios perdurariam por mais de cem anos (Figura 2). Segundo Ishii (2012, p. 50), “princípios raramente mudam, mas práticas sempre dependem de contexto. Ao associar um método a uma coleção de princípios, é sempre possível criar novas práticas, desde que aderentes aos princípios”.

FIGURA 1 – FATORES DE INOVAÇÃO TECNOLÓGICA

Tecnologias

Necessidades(Aplicações)

Visão(Conceitos, Princípios)


181

FIGURA 2 – VIDA ÚTIL DOS FATORES DE INOVAÇÃO

Tecnologias - 1 ano

- 10 anos

- 100 anos

Necessidades(Aplicações)

Visão(Conceitos, Princípios)

Greenfield (2006, p. 257) defende que um conjunto explícito de princípios será extremamente útil tanto para desenvolvedores quanto para usuários em everyware. E alerta que "os princípios são necessários, mas não suficientes: constituem não um fim, mas um começo". Há que se construir um everyware que se adapte às pessoas, não o contrário. Mas não será trivial projetar sistemas ubíquos sofisticados o suficiente para capturar a riqueza de nuances da vida cotidiana (GREENFIELD, 2006).

Diretrizes serão claramente úteis para quem está adquirindo ou utilizando everyware, ainda que limitadas por serem contingentes, provisionais e incompletas. Se houver um conjunto de critérios compacto, objetivo, e amplamente acordado, haverá compatibilidade e interoperabilidade. Os princípios focam não em como alcançar uma quantidade de finalidades, mas em que finalidades devem ser perseguidas prioritariamente. É preciso desenvolver um arcabouço de conhecimentos, padrões e convenções, começando pelas interfaces pelas quais acessaremos everyware (GREENFIELD, 2006).

Desde que a Arquitetura da Informação é baseada em princípios que são amplamente independentes de qualquer mídia específica – afinal diz respeito à estruturação de espaços de informação tanto quanto a Arquitetura preocupa-se com a estruturação de espaços físicos – [a área] fornece um modelo conceitual flexível, porém sólido, para o design de experiências em múltiplos canais [cross-channel] e múltplos contextos [cross-context], que se estendem a diversas mídias e ambientes. (RESMINI; ROSATI, 2011, p. 1369).


182

Shin (2010) destaca que ainda são poucos os esforços de pesquisa concentrados nas imensas repercussões sociais, culturais e comportamentais da IdC, que tenham a finalidade de promover sua implantação, gestão e evolução na qualidade de inovação sociotécnica (BIJKER, 1997), que deve ser projetada e desenvolvida como um sistema centrado nos humanos. Lucas, Ballay e McManus (2012) projetos de sistemas de informação para a IdC devem considerar: métodos profundamente interdisciplinares; foco humanista; design de interação centrado em informações; e computação em contexto.

5 CONCLUSÃO

O cenário da IdC é multifacetado e vem sendo tratado na literatura sob perspectivas socioculturais, econômicas, filosóficas, mas predominantemente tecnológicas. As questões emergentes deste contexto são de natureza e proporções variadas – como privacidade, usabilidade, consentimento, para citar alguns – e afetam desde o domínio individual até o global, passando pelas esferas doméstica, social, urbanística, governamental.

A pesquisa voltada para aspectos tecnológicos é fundamental para o avanço da IdC. Entretanto, é necessário compreender os tipos de tarefas e padrões de interatividade que emergem no momento em que o usuário transcende o modelo de interação com computadores para interagir com interfaces que permeiam seu ambiente e aumentam suas capacidades individuais, mas que, ao mesmo tempo, conferem autonomia e poder de decisão aos objetos.

Há uma série de desafios tecnológicos e informacionais que devem ser tratados para viabilizar o funcionamento adequado da IdC. Mas está nos aspectos humanos e sociais a oportunidade de fazer a diferença em termos de projetos de ecossistemas de informação direcionados às necessidades das pessoas.

A questão central de interesse da Internet das Coisas para a Arquitetura da Informação, na qualidade de disciplina da Ciência da Informação, é a concretização de um mundo onde o processamento de informações estará em toda parte. São novos espaços de informação, com diferentes propriedades, que precisam ser compreendidas e arquitetadas. A Internet das Coisas requer de uma abordagem humanista e sistêmica, baseada essencialmente em princípios, com vistas a evitar soluções pautadas em valores comerciais ou tecnicistas. Indica-se, nesse sentido, a necessidade de estruturação de um arcabouço teórico transdisciplinar no âmbito da área de Arquitetura da Informação para lidar com as questões emergentes da IdC.

FONTE: Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1413-99362015000200158&lang=pt>. Acesso em: 12 fev. 2016.

183

Neste tópico, vimos que:

• O context and dependency injection permite que se utilize injeção de dependência para integrar a camada de interface com a camada de negócios.

• Através da injeção de dependência, o ciclo de vida de alguns objetos passa a ser controlado por uma parte especial do AS conhecida como EJB Container.

• Os objetos utilizados no CDI podem ser atributos ou mesmo objetos criados em métodos, conhecidos como producers.

• Para utilizar CDI, um arquivo beans.xml deve ser criado em um diretório específico da aplicação.

• Existem basicamente quatro tipos de contextos onde os objetos administrados pelo container CDI são armazenados: Request, Session, Application e Conversation.

RESUMO DO TÓPICO 4

184

AUTOATIVIDADE

1 Implemente uma aplicação web utilizando JSF que faça uso do contexto CDI conhecido como SessionContext.

2 Descreva detalhadamente de que forma funciona a injeção de dependências dentro de uma aplicação JavaEE.

185

REFERÊNCIAS

ARANGO, J. World information architecture day 2012. [S.l: s.n.], 2012. Disponível em: <http://www.youtube.com/watch?v=kY5CC2QfevE&feature=youtube_gdata_player>. Acesso em: 15 set. 2013.

ASHTON, K. That “Internet of Things” Thing. RFID Journal, 22 jun. 2009. Disponível em: <http://www.rfidjournal.com/articles/view?4986>. Acesso em: 31 ago. 2013.

BIJKER, W. E. Of bicycles, bakelites, and bulbs toward a theory of sociotechnical change. Cambridge Mass.: MIT Press, 1997.

CARDIM, Eder. Bancos de dados relacionais, orientação a objetos e DBIX-Class. 2010. Disponível em: <http://sao-paulo.pm.org/pub/bancos-de-dados-relacionais-orientacao-a-objetos-e-dbix-class>. Acesso em: 2 maio 2015.

CASTELLS, M. A galáxia internet: reflexões sobre a internet, negócios e a sociedade. Rio de Janeiro: Zahar, 2003.

CASTELLS, M. A sociedade em rede. São Paulo: Paz e Terra, 1999 v. 1. (A Era da Informação: economia, sociedade e cultura).

CDI-SPEC. Contexts and Dependency Injection for Java. 2015. Disponível em: <http://www.cdi-spec.org/>. Acesso em: 8 jan. 2015.

CHUI, M.; LÖFFLER, M.; ROBERTS, R. The internet of things. McKinsey Quarterly, v. 2, 2010 Disponível em: <http://scholar.google.com.br/scholar?cluster=4109556744406282630&hl=pt-BR&as_sdt=0,5>. Acesso em: 3 jan. 2013.

DAVIS, M. Semantic wave 2008 report: industry roadmap to Web 3.0 & Multibillion Dollar Market Opportunities. Executive Summary, 2008. Disponível em: <http://www.project10x.com>. Acesso em: 20 jul. 2010.

186

EUROPEAN COMMISSION. Conclusions of the Internet of Things public consultation, n. 9. Brussels: [s.n.], 12 abr. 2012. Disponível em: <ec.europa.eu//digital-agenda/en/news/conclusions-internet-things-public-consultation>. Acesso em: 1 jan. 2015.

EVANS, D. The internet of things: how the next evolution of the internet is changing everything. CISCO white paper, 2011, 11 p.

EVANS, Ian; GOLLAPUDI, Devika; HAASE, Kim; JENDROCK, Eric; SRIVATSHA, Chinmayee. The Java EE 6 Tutorial: Basic Concepts. 4ª Ed. Boston: Addison Wesley, 2011.

FLORIDI, L. Internet of things: atart of a revolution. [S.l: s.n.], 2013. Disponível em: <http://vimeo.com/77209992>. Acesso em: 14 jun. 2014.

FOWLER, Martin. ORM Hate. 2012. Disponível em: <http://martinfowler.com/bliki/OrmHate.html>. Acesso em: 8 maio 2014.

FRANCO, Cristiano Roberto. Programação orientada a objetos. Uniasselvi, Indaial. 2014;

GARTNER. Gartner identifies the top 10 strategic technology trends for 2013. [S.l: s.n.], mar. 2013. Disponível em: <http://www.gartner.com/it/page.jsp?id=2209615>. Acesso em: 1 jan. 2013.

GARTNER. Gartner Says the Internet of Things installed base will grow to 26 billion units by 2020. Disponível em: <http://www.gartner.com/newsroom/id/2636073>. Acesso em: 28 jul. 2014.

GREENFIELD, A. Everyware: the dawning age of ubiquitous computing. San Francisco: New Riders Publishing, 2006.

GREENFIELD, A.; KIM, N. Against the smart city: the city is here for you to use. [S.l.]: Do projects, 2013.

HINTON, A. A model for information environments: reframe IA. In: IA SUMMIT, abr. 2013, Baltimore, MD, USA Anais... Baltimore, MD, USA: [s.n.], abr. 2013 Disponível em: <http://www.slideshare.net/andrewhinton/a-model-for-information-environments-reframe-ia-workshop-2013>. Acesso em: 15 set. 2013.

187

INTERNET OF THINGS: Philosophy. 3 jul. 2014, York St John University, UK. Anais... York St John University, UK: [s.n.], 3 jul. 2014 Disponível em: <http://internetofthingsphilosophy.com/slides-proceedings-etc/>. Acesso em: 1 ago. 2014.

ISHII, H. Defy gravity: beyond tangible bits, toward radical atoms. In: DW/AD ‘12, 4 dez. 2012, Kyoto International Conference Center, Kyoto, Japan. Anais... Kyoto International Conference Center, Kyoto, Japan: [s.n.], 4 dez. 2012. Disponível em: <http://www.youtube.com/watch?v=SMdFus2nPyw&feature=youtube_gdata_player>. Acesso em: 20 abr. 2014.

K19. Desenvolvimento Web Avançado com JSF 2, EJB 3.1 e CDI. 2015. Disponível em: <http://www.k19.com.br/downloads/apostilas/java/k19-k22-desenvolvimento-web-avancado-com-jsf2-ejb3.1-e-cdi>. Acesso em: 15 jan. 2015.

K19. Desenvolvimento Web Avançado com JSF2, EJB 3.1 e CDI. 2013. Disponível em: <http://www.k19.com.br/downloads/apostilas/java/k19-k12-desenvolvimento-web-com-jsf2-e-jpa2>. Acesso em 14 ago. 2015.

KENDE, M. Global Internet report. Geneva: Internet Society, 2014. Disponível em: <http://www.internetsociety.org/doc/global-internet-report>. Acesso em: 28 jul. 2014.

KLYN, D. Dutch uncles, ducks and decorated sheds: reframing IA. Baltimore, MD, USA: [s.n.], 2013. Disponível em: <http://www.slideshare.net/danfnord/dutch-uncles-ducks-and-decorated-sheds-reframing-ia>. Acesso em: 18 set. 2013.

KUNIAVSKY, M. Smart things: ubiquitous computing user experience design: ubiquitous computing user experience design. [S.l.]: Elsevier, 2010.

LACERDA, F.; LIMA-MARQUES, M. Information architecture as a discipline: a methodological approach. In: RESMINI, A. (Org). Reframing Information Architecture. Human-Computer Interaction Series. Switzerland: Springer, 2014 Disponível em: <http://www.springer.com/computer/hci/book/978-3-319-06491-8>. Acesso em: 19 abr. 2014.

188

LUCAS, P.; BALLAY, J.; McMANUS, M. Trillions thriving in the emerging information ecology. Hoboken, N.J: Wiley, 2012.

McCULLOUGH, M. Digital ground: architecture, pervasive computing, and environmental knowing. Cambridge, Mass: MIT Press, 2004.

McEWEN, A.; CASSIMALLY, H. Designing the internet of things. 1 ed. Chichester: Wiley, 2013.

MENDES, P. Social-driven internet of connected objects. [S.l.]: Citeseer, 2011.

MORVILLE, P. Ambient findability: what we find changes who we become. Sebastopol: O’Reilly Media, 2005.

MORVILLE, P. Ubiquitous information architecture: cross-channel strategy. [S.l: s.n.], 2012. Disponível em: <http://www.slideshare.net/morville/ubiquitous-information-architecture-crosschannel-strategy>. Acesso em: 30 dez. 2012.

NEGROPONTE, Nicholas. Learning by Doing: Don’t Dissect the Frog, Build it. 2004. Disponível em: <http://archive.wired.com/wired/archive/2.07/negroponte_pr.html>. Acesso em: 8 ago. 2015.

NETBEANS. Netbeans IDE Features. Disponível em: <https://netbeans.org/features/index.html>. Acesso em: 4 ago. 2015.

NORMAN, D. The design of future things. New York: Basic Books, 2009. ORACLE. Introduction to Java Enterprise Edition 7. 2013. Disponível em: <http://www.oracle.com/technetwork/java/javaee/javaee7-whitepaper-1956203.pdf>. Acesso em: 2 ago. 2015. ORACLE. Java Platform, Enterprise Edition: The Java EE 5 Tutorial. 2010. Disponível em: <http://docs.oracle.com/javaee/5/tutorial/doc/bnaph.html>. Acesso em: 15 ago. 2015.

189

ORACLE. Java Platform, Enterprise Edition: The Java EE Tutorial. 2014. Disponível em: <https://docs.oracle.com/javaee/7/tutorial/>. Acesso em: 15 ago. 2015.

RESMINI, A. The poetics of information architecture. In: ASIS & T EUROIA, 2013, Edinburgh. Anais... Edinburgh: [s.n.], 2013. Disponível em: <http://pt.slideshare.net/resmini/the-poetics-of-information-architecture-26991604>. Acesso em: 3 ago. 2014.

RESMINI, A.; ROSATI, L. Pervasive information architecture: designing cross-channel user experiences. Boston: Morgan Kaufmann, 2011.

SANTUCCI, G. On the philosophy of the internet of things. In: INTERNET OF THINGS PHILOSOPHY, 3 jul. 2014, York St John University. Anais... York St John University: [s.n.], 3 jul. 2014. Disponível em: <http://www.theinternetofthings.eu/content/g%C3%A9rald-santucci-internet-things-window-our-future>. Acesso em: 2 fev. 2015.

SHIN, D.-H. A realization of pervasive computing: Ubiquitous city. In: TECHNOLOGY MANAGEMENT FOR GLOBAL ECONOMIC GROWTH (PICMET), 2010 PROCEEDINGS OF PICMET ‘10: jul. 2010. Proceedings... [S.l: s.n.], jul. 2010. p. 1 -10.

SOFTPLAN. Curso EAD JEE 6. Disponível em: <http://oncourse.softplan.com.br/pluginfile.php/109/mod_resource/content/2/jsf/pdf-slides/parte-2-slides.pdf >. Acesso em: 12 ago. 2015.

TELECOMMUNICATION STANDARDIZATION SECTOR (ITU-T). ITU-T Y.2060: overview of the internet of things. [S.l: s.n.]. Disponível em: <http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11559>. Acesso em: 20 set. 2014.

THIAGO, André. Vantagens e desvantagens da injeção de dependências. 2010. Disponível em: <http://andrethiago.com/2010/04/01/vantagens-e-desvantagens-da-injecao-de-dependencia/>. Acesso em: 2 jan. 2015.

190

TODD, Spangler. Netflix bandwidth usage climbs to nearly 37% of internet traffic on peak hours. Disponível em: <http://variety.com/2015/digital/news/netflix-bandwidth-usage-internet-traffic-1201507187/>. Acesso em: 2 ago. 2015.

VAN GIGCH, J. P. Systems science, the discipline of epistemological domains, contributes to the design of the intelligent global web. Behavioral Science, v. 35, n. 2, p. 122, 1990 Disponível em: <http://onlinelibrary.wiley.com/doi/10.1002/bs.3830350205/abstract>. Acesso em: 20 jul. 2010.

W3C. Ubiquitous Web Domain. W3C. [S.l: s.n.], 2010. Disponível em: <http://www.w3.org/UbiWeb/>. Acesso em: 20 jul. 2010 .

WEBER, R. H. Internet of things: governance quo vadis? Computer Law & Security Review, v. 29, n. 4, p. 341-347, ago 2013 Disponível em: <http://www.sciencedirect.com/science/article/pii/S0267364913001015>. Acesso em: 28 ago. 2013.

WEISER, M.; BROWN, J. S. The coming age of calm technology. Palo Alto: Xerox PARC, 1996.

191

ANOTAÇÕES

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

192

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

Documents

Programação Para eb