HackMDApostila Java Webdeveloper WEB 1
Apostila 2 - https://hackmd.io/@lucianamedeiros/rkh-U3doA
JavaServer Pages
JavaServer Pages (JSP) é uma tecnologia que ajuda os desenvolvedores de software a criarem páginas web geradas dinamicamente baseadas em HTML, XML ou outros tipos de documentos. Lançada em 1999 pela Sun Microsystems, JSP é similar ao PHP, mas usa a linguagem de programação Java.
Para implantar e executar JavaServer Pages, um servidor web compatível com um container servlet, como Apache Tomcat, Jetty ou Glassfish, é requerido. Por ser baseada na linguagem de programação Java, tem a vantagem da portabilidade de plataforma, que permite a sua execução em diversos sistemas operacionais, como oWindows da Microsoft, Unix e Linux.
Esta tecnologia permite ao desenvolvedor de páginas para Internet produzir aplicações que acessem o banco de dados, manipulem arquivos no formato texto, capturem informações a partir de formulários e captem informações sobre o visitante e sobre o servidor.
Uma página criada com a tecnologia JSP, após instalada em um servidor de aplicação compatível com a tecnologia Java EE, é transformada em um Servlet.
A arquitetura JSP
Arquitetonicamente, a JSP pode ser vista como uma abstração de alto nível de servlets Java. JSPs são traduzidas em servlets em tempo de execução. Cada servlet JSP é armazenado em cache e reutilizado até que a JSP original seja modificada.
JSP pode ser usada independentemente ou como o componente de visão de um projeto modelo-visão-controlador do lado do servidor, normalmente com JavaBeans como modelo e servlets Java (ou um framework como o Apache Struts) como o controlador. Este é um tipo de arquitetura Modelo 2.
JSP permite que o código Java e algumas ações pré-definidas sejam intercalados com conteúdo de marcação web estático, com a página resultante sendo compilada e executada no servidor que irá entregar um documento. As páginas compiladas, assim como as bibliotecas Java dependentes, utilizam o bytecode Java em vez de um formato de software nativo. Como qualquer outro programa Java, elas devem ser executadas em uma máquina virtual Java (JVM), que se integra com o sistema operacional do host servidor para fornecer um ambiente de plataforma neutra abstrato. JSPs são normalmente utilizadas para entregar documentos HTML e XML, mas através do uso de OutputStream, elas também podem proporcionar outros tipos de dados.
O recipiente web cria objetos JSP implícitos como pageContext, servletContext, session, request & response.
A linguagem
Em relação a arquitetura, JSP pode ser visto como uma abstração de alto nível dos Java servlets. Páginas JSP são carregadas dentro do servidor e processado a partir de uma estrutura especial do servidor Java, chamada Java EE Web Application, muitas vezes como um arquivo .war .ear.
JSP permite que código Java e certas ações pré-definidas sejam intercaladas com conteúdo de marcação estático, resultando na página sendo compilada e executada no servidor para ser entregue num documento HTML ou XML. As páginas compiladas e qualquer dependência de biblioteca Java usa os bytecodes primeiro que o formato nativo de software, e deve assim ser executado com uma JVM, a máquina virtual Java, integrada com o host do sistema operacional para prover um ambiente de abstração de plataforma.
A sintaxe de JSP é uma mistura de dois tipos básicos de conteúdo: scriptlet elements e markup. Markup é tipicamente um padrão HTML ou XML, enquanto os elementos scriptlet são blocos de código Java os quais podem ser unidos com o tipo de marcação, markup. Quando a página é requisitada o código Java é executado e sua saída é adicionada, in loco, com o ambiente de marcação para gerar a página final. Códigos JSP devem ser compiladas para criação das classes bytecodes antes de serem executadas, mas essa compilação é necessária apenas quando é feita uma mudança no código.
Sintaxe
Páginas JSP utilizam vários delimitadores para funções de script. A mais básica é <% … %>, que delimita um scriptlet JSP. Um scriptlet é um fragmento de código Java que é executado quando o usuário solicita uma página. Outros delimitadores comuns incluem <%= … %> para expressões, onde o valor da expressão é colocado na página entregue ao usuário, e diretivas, denotadas com <%@ … %>.
O código Java não é necessário ser completo ou auto-contido dentro de seu bloco de elemento scriptlet, mas pode abranger conteúdos de marcação fornecendo a página como um todo é sintaticamente correto. Por exemplo, quaisquer bloco Java if/for/while aberto em um elemento scriptlet deve ser corretamente fechado em um elemento posterior para que a página seja compilada com sucesso. A marcação que cai dentro de um bloco de código quebrado está sujeito aquele código, desta forma a marcação dentro do bloco ifaparecerá apenas na saída quando a condição if for avaliada como verdadeira (true). Do mesmo modo, a marcação dentro de uma construção de loop pode aparecer várias vezes na saída dependendo de quantas vezes o corpo do loop for executado.
Comentários JSP
O JSP tem um tipo de comentário próprio, por exemplo: <%– comentário –%>
Este comentário só aparece do lado do servidor, não aparecendo por isso no código-fonte do browser !!
Tags JSP
No JSP existem 5 tags:
1 - Declaration tag
Esta tag permite declarar variáveis e métodos. A sua sintaxe é: <%! …mais alguma coisa.. %> Um exemplo:
2 - Expression tag
Esta tag permite mostrar algum resultado. A sua sintaxe é: <%=..algo para mostrar…%> Por exemplo, para mostrar o valor da variável contador bastava apenas:
3 - Directive tag
Esta tag permite dar informação sobre a página ao motor JSP. Existe 3 tipos de directivas:
- Page - processa informação para esta página. Existem 11 atributos opcionais. Sintaxe:
- Include – arquivos para serem incluidos. Sintaxe:
- Taglib - Define uma biblioteca a ser usada. Precisa de um prefixo e de um url: Sintaxe:
4 - Scriptlet tag
Todo o código entre <% %> é chamado de scriptlet. Sintaxe:
5 - Action tag
Esta tag tem como principais funcionalidades:
- Acessar
- Para a inclusão de applets Java em páginas, independentemente e alterar propriedades de JavaBeans (jsp:useBean, jsp:getProperty e jsp:setProperty);
- Redirecionar a requisição para outra página JSP (jsp:forward);
- Uma única tag do browser cliente (jsp:plugin e jsp:fallback).
Servlet
Servlet (servidorzinho em tradução livre) é uma classe Java usada para estender as funcionalidades de um servidor. Apesar dos servlets poderem responder a quaisquer tipos de requisições, eles normalmente são usados para estender as aplicações hospedadas por servidores web, desta forma eles podem ser imaginados como Applets Java que rodam em servidores em vez de rodarem nosnavegadores web. Estes tipos de servlets são os equivalentes Java a outras tecnologias de conteúdo Web dinâmico, como PHP e ASP.NET.
Também pode ser definido como um componente semelhante um servidor, que gera dados HTML eXML para a camada de apresentação de uma aplicação Web. Ele processa dinamicamenterequisições e respostas.
Descrição
A API Java Servlet (do pacote javax.servlet) proporciona ao desenvolvedor a possibilidade de adicionar conteúdo dinâmico em um servidor web usando a plataforma Java. Esta tecnologia disponibiliza ao programador da linguagem Java uma interface para o servidor web (ou servidor de aplicação), através de uma API. As aplicações baseadas no Servlet geram conteúdo dinâmico (normalmente HTML) e interagem com os clientes, utilizando o modelo requisição-resposta. Os servlets normalmente utilizam o protocolo HTTP, apesar de não serem restritos a ele. Um Servlet necessita de um container Web para ser executado.
Eles são frequentemente usados para:
- Processar ou armazenar dados que foram submetidos de um formulário HTML
- Fornecer conteúdo dinâmico, como os resultados de uma consulta a um banco de dados
- Gerenciar a informação de estado que não existe no protocolo sem estado HTTP, como inserir/retirar os itens de uma cesta de compras de um cliente específico
Tecnicamente falando, um "servlet" é uma classe Java no Java EE que obedece à API Java Servlet, um protocolo pelo qual uma classe Java pode responder a requisições. Servlets podem, em princípio, se comunicar sobre qualquer protocolo cliente-servidor, mas eles são na maioria das vezes usados com o protocolo HTTP. Desta forma, "servlet" normalmente é usado como uma abreviação para "servlet HTTP". Assim, um desenvolvedor de software pode usar um servlet para adicionar conteúdo dinâmico para umservidor web usando a plataforma Java. O conteúdo gerado normalmente é HTML, mas pode ser outro dado como XML. Servlets podem manter estado em variáveis de sessãoatravés de muitas transações de servidores, usando cookies HTTP ou reescrita de URL.
DTO - Data Transfer Object
Objeto de Transferência de Dados
O próprio nome já diz muito: um objeto simples usado para transferir dados de um local a outro na aplicação, sem lógica de negócios em seus objetos e comumente associado à transferência de dados entre uma camada de visão (view layer) e outra de persistência dos dados (model layer). Muito frequentemente você verá esse padrão sendo usado em conjunto com um DAO. Um exemplo claro dessa representação e desse conjunto entre os dois padrões.
Esse padrão também é bastante usado quando não se deseja expor a camada de persistência, porém é preciso que sejam exibidos os mesmos dados na camada de apresentação. Por exemplo, considere uma tela de uma aplicação que necessite listar os dados de 10 pessoas cadastradas em uma tabela. Para acessar estes dados, a camada de persistência assim o faz com a listagem configurada em um ArrayList de 10 PO’s (vide padrão acima). Para passar esses valores à tela, a mesma lista antes tem de ser convertida para uma lista de DTO’s com mesmos atributos e métodos get’s/set’s. Tudo isso porque a mesma aplicação faz uso do JPA, por exemplo, ou Hibernate e os mesmos frameworks não permitem que os dados tidos como “lazy (preguiçosos)” perdurem até depois de a conexão ter sido fechada. Por tal razão a conversão se faz necessária e assim os dados poderão fazer o trajeto sem serem perdidos ou sem que nenhum erro de conexão venha a acontecer.
Observação: os padrões de projeto também não devem ser usados em detrimento do ambiente onde se está executando o mesmo projeto, a ideia é que eles sejam abstratos o suficiente para se adaptar, porém você será o autor principal disso, então não desconsidere o ambiente na hora de pensar em todos os cenários adaptáveis. É um padrão de projeto de software usado para transferir dados entre subsistemas de um software. DTOs são frequentemente usados em conjunção com objetos de acesso a dados para obter dados de um banco de dados.
A diferença entre objetos de transferência de dados e objetos de negócio ou objetos de acesso a dados é que um DTO não possui comportamento algum, exceto o de armazenamento e obtenção de seus próprios dados. DTOs são objetos simples que não contêm qualquer lógica de negócio que requeira testes.
Em uma arquitetura EJB tradicional, os DTOs servem para dois propósitos: primeiro, contornar o problema que entidades do EJB não são serializáveis; segundo, eles definem implicitamente uma fase de montagem onde todos os dados que serão usados para apresentação passam por marshalling antes de irem efetivamente para a camada de apresentação. Uma terceira razão para usar DTOs é que camadas não-adjacentes à camada de dados da aplicação não podem acessar estes objetos e modificá-los.
DTO (Martin Fowler)
DTOs são utilizados em várias situações:
- Transferência de Dados entre Camadas: DTOs são frequentemente usados para transportar dados entre diferentes camadas de um aplicativo, como a camada de apresentação e a camada de persistência.
- APIs e Serviços Web: Quando se desenvolve APIs RESTful ou serviços web, os DTOs são utilizados para definir a estrutura dos dados que serão enviados e recebidos através das requisições HTTP.
- Desempenho e Segurança: Ao usar DTOs, pode-se controlar exatamente quais dados serão transferidos, potencialmente melhorando o desempenho e evitando a exposição desnecessária de informações sensíveis.
Vantagens do Uso de DTOs
- Encapsulamento: DTOs encapsulam os dados que serão transferidos, permitindo controlar exatamente o que é exposto.
- Segurança: DTOs podem evitar a exposição de informações sensíveis.
- Desempenho: Transferir apenas os dados necessários pode melhorar o desempenho da aplicação.
- Manutenção: Facilita a manutenção e evolução da aplicação, pois mudanças na lógica de negócio não afetam diretamente os objetos de transferência de dados.
Desvantagens
- Sobrecarga Adicional: Pode introduzir sobrecarga adicional na criação e manutenção de classes DTO e na conversão entre entidades e DTOs.
- Duplicação de Código: Muitas vezes, pode haver duplicação de código entre entidades e DTOs.
- Conceitos Principais de DTO
- Propósito: DTOs são usados para transportar dados de um ponto a outro sem lógica de negócios ou comportamento associado. Eles são essencialmente "portadores de dados".
- Estrutura Simples: DTOs geralmente contêm apenas campos de dados e métodos de acesso (getters e setters). Não possuem métodos complexos ou lógica de negócios.
- Imutabilidade (opcional): Em muitos casos, os DTOs são projetados para ser imutáveis, ou seja, seus valores são definidos no momento da criação e não podem ser alterados depois. Isso pode ajudar a evitar problemas de concorrência e tornar o código mais seguro.
Exemplos de Uso:
- Camada de Apresentação e Persistência: DTOs são usados para transferir dados da camada de apresentação para a camada de persistência e vice-versa. Isso ajuda a separar as preocupações de cada camada e manter um design de código limpo e modular.
- APIs REST: Quando se trabalha com APIs REST, os DTOs são frequentemente usados para definir a estrutura dos dados que serão enviados e recebidos. Eles ajudam a garantir que a API seja clara e consistente.
- Redução de Sobrecarga: Transferir um objeto complexo com muitas dependências pode ser ineficiente. Um DTO pode agrupar apenas os dados necessários, reduzindo a quantidade de informação transferida e melhorando o desempenho.
.
.
.
Hibernate
O Hibernate é um framework para o mapeamento objeto-relacional escrito na linguagem Java, mas também é disponível em .Netcomo o nome NHibernate. Este framework facilita o mapeamento dos atributos entre uma base tradicional de dados relacionais e o modelo objeto de uma aplicação, mediante o uso de arquivos (XML) ou anotações Java (veja Annotation (java)).
Hibernate é um software livre de código aberto distribuído com a licença LGPL.
Características
O objetivo do Hibernate é diminuir a complexidade entre os programas Java, baseado no modelo orientado a objeto, que precisam trabalhar com um banco de dados do modelo relacional (presente na maioria dos SGBDs). Em especial, no desenvolvimento de consultas e atualizações dos dados.
Sua principal característica é a transformação das classes em Java para tabelas de dados (e dos tipos de dados Java para os da SQL). O Hibernate gera as chamadas SQL e libera o desenvolvedor do trabalho manual da conversão dos dados resultante, mantendo o programa portável para quaisquer bancos de dados SQL, porém causando um pequeno aumento no tempo de execução. Nas questões relacionadas para o gerenciamento de transações e na tecnologia de acesso à base de dados são de responsabilidade de outros elementos na infraestrutura do programa. Apesar de existirem API no Hibernate para possuir operações de controle transacional, ele simplesmente delegará estas funções para a infraestrutura na qual foi instalada.
No caso de aplicações construídas para serem executadas em servidores de aplicação, o gerenciamento das transações é realizado segundo o padrão JTA. Já nas aplicações standalone, o programa delega o tratamento transacional ao driver JDBC.
Hibernate pode ser utilizado em aplicações Java standalone ou em aplicações Java EE, utilizando servlet ou sessões Enterprise Java Beans.
História
Hibernate foi criado por desenvolvedores Java, espalhados ao redor do mundo, e liderado por Gavin King.
Posteriormente, JBoss Inc (empresa comprada pela Red Hat) contratou os principais desenvolvedores do programa para fazer o seu suporte. A atual versão do Hibernate é a 4.x, que incorporou características como a nova arquitetura Interceptor/Callback, filtros definidos pelo usuário e anotações JDK 5.0 (Metadados do Java), que substitui os arquivos XML. Hibernate 3 também se aproxima das especificações EJB 3.0 e atua como a espinha dorsal das implementações EJB 3.0 em JBoss.
HQL
A HQL (Hibernate Query Language) é um dialeto SQL para o Hibernate. Ela é uma poderosa linguagem de consulta que se parece muito com a SQL, mas a HQL é totalmente orientada a objeto, incluindo os paradigmas de herança, polimorfismo e encapsulamento. No Hibernate, você pode escolher tanto usar a SQL quanto a HQL. Escolhendo a HQL, você poderá executar os pedidos SQL sobre as classes de persistência do Java ao invés de tabelas no banco de dados.
Utilizando o HQL temos a vantagem de portabilidade de banco, ou seja, suponha que estamos utilizando um banco de dados A, ao trocarmos para um banco B o HQL automaticamente cria comandos referentes a cada banco de dados. Isso facilita, pois no SQL teríamos que rastreara alterar vários códigos no sistema.
Frameworks CSS
Frameworks CSS são bibliotecas pré-preparadas que se destinam a facilitar mais estilizações de páginas web compatíveis com os padrões usando a linguagem Cascading Style Sheets. Alguns exemplos notáveis e amplamente utilizados de frameworks são o Bootstrap ou Foundation.
Frameworks CSS oferecem diferentes módulos e ferramentas:
:arrow_right: Redefinição da folha de estilo
:arrow_right: Grid especialmente para o design responsivo
:arrow_right: Tipografia web
:arrow_right: Conjunto de ícones em sprites ou fontes de ícone
:arrow_right: Styling para tooltips, botões, elementos de formulários
:arrow_right: Partes de interfaces gráficas como o acordeão, guias, slideshow ou janelas modais (Luz)
:arrow_right: Equalizador para criar conteúdo de altura igual
Frameworks maiores usam intérpretes CSS como LESS ou SASS.
Bootstrap
Desenvolvido pela equipe do Twitter, o Bootstrap é um framework front-end de código aberto (opensource). Em palavras simples, é um conjunto de ferramentas criadas para facilitar o desenvolvimento de sites e sistemas web. Compatível com HTML5 e CSS3, o framework possibilita a criação de layouts responsivos e o uso de gris, permitindo que seu conteúdo seja organizado em até 12 colunas e que comporte-se de maneira diferente para cada resolução. Como qualquer outra ferramenta, possui suas vantagens e desvantagens. É importante conhecer e entender suas funcionalidades para saber os momentos certos de utilizá-lo.
Vantagens:
:thumbsup: Possui documentação detalhada e de fácil entendimento;
:thumbsup: É otimizado para o desenvolvimento de layouts responsivos;
:thumbsup: Possui componentes suficientes para o desenvolvimento de qualquer site ou sistema web com interface simples;
:thumbsup: Facilita a criação e edição de layouts por manter padrões;
:thumbsup: Funciona em todos os navegadores atuais (Chrome, Safari, Firefox, IE, Opera).
Desvantagens:
:-1: Seu código terá de seguir os “padrões de desenvolvimento Bootstrap”;
:-1: Tema padrão e comum do Bootstrap (caso não faça ajustes visuais, seu projeto se parecerá com outros que também utilizam o Bootstrap).
A estrutura é simples e seu pacote contém três tipos diferentes de arquivos (CSS, JavaScrpipt e Fonts), que vêm devidamente organizados em suas pastas. Montar um layout é simples e rápido utilizando sua documentação. Como toda a estrutura do CSS já vem definida, basta procurar o componente necessário e adicionar seu código. Em poucos minutos seu layout toma forma e está pronto para uso! E o mesmo acontece com o JavaScript.
Temas do Bootstrap
Bootswatch
Pode fazer o download das bibliotecas
Bootswatch online
Ou pode usar as bibliotecas online
Web service
Web service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web services são componentes que permitem às aplicações enviar e receber dados em formato XML. Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, um formato intermediário como XML, Json, CSV, etc.
Para as empresas, os Web services podem trazer agilidade para os processos e eficiência na comunicação entre cadeias de produção ou de logística. Toda e qualquer comunicação entre sistemas passa a ser dinâmica e principalmente segura, pois não há intervenção humana.
Essencialmente, o Web Service faz com que os recursos da aplicação do software estejam disponíveis sobre a rede de uma forma normalizada. Outras tecnologias fazem a mesma coisa, como por exemplo, os browsers da Internet acessam às páginas Web disponíveis usando por norma as tecnologias da Internet, HTTP e HTML. No entanto, estas tecnologias não são bem sucedidas na comunicação e integração de aplicações. Existe uma grande motivação sobre a tecnologia Web Service pois possibilita que diferentes aplicações comuniquem - se entre si e utilizem recursos diferentes.
Utilizando a tecnologia Web Service, uma aplicação pode invocar outra para efetuar tarefas simples ou complexas mesmo que as duas aplicações estejam em diferentes sistemas e escritas em linguagens diferentes. Por outras palavras, os Web Services fazem com que os seus recursos estejam disponíveis para que qualquer aplicação cliente possa operar e extrair os recursos fornecidos pelo Web Service.
Os Web Services são identificados por um URI (Uniform Resource Identifier), descritos e definidos usando XML (Extensible Markup Language). Um dos motivos que tornam os Web Services atractivos é o facto deste modelo ser baseado em tecnologias standards, em particular XML e HTTP (Hypertext Transfer Protocol). Os Web Services são utilizados para disponibilizar serviços interactivos na Web, podendo ser acessados por outras aplicações usando, por exemplo, o protocolo SOAP (Simple Object Access Protocol).
O objetivo dos Web Services é a comunicação de aplicações através da Internet. Esta comunicação é realizada com intuito de facilitar a EAI (Enterprise Application Integration) que significa a integração das aplicações de uma empresa, ou seja, interoperabilidade entre a informação que circula numa organização nas diferentes aplicações como, por exemplo, o comércio electrónico com os seus clientes e seus fornecedores. Esta interação constitui o sistema de informação de uma empresa. E para além da interoperabilidade entre as aplicações, a EAI permite definir um workflow entre as aplicações e pode constituir uma alternativa aos ERP (Enterprise Resource Planning). Com umworkflow é possível otimizar e controlar processos e tarefas de uma determinada organização.
Padrão
A W3C, OASIS são as instituições responsáveis pela padronização dos Web Services. Empresas como IBM e Microsoft, duas das maiores do setor de tecnologia, apoiam o desenvolvimento deste padrão.
Segundo o W3C (World Wide Web Consortium) um Web Service define-se como: um sistema de software projectado para suportar a interoperabilidade entre máquinas sobre rede.
Tem uma relação descritiva num formato machine-processable, especificamente WSDL (Webservice Description Language).
Outros sistemas interagem com o Web Service usando as mensagens SOAP, tipicamente sobre HTTP com XML na junção com outros standards da Web.
Tecnologias
As bases para a construção de um Web service são os padrões XML e SOAP. O transporte dos dados é realizado normalmente via protocolo HTTP ou HTTPS para conexões seguras (o padrão não determina o protocolo de transporte). Os dados são transferidos no formato XML, encapsulados pelo protocolo SOAP. Também é bastante comum usar o protocolo REST( Representational transfer protocol), para transferir o estado do dado para a aplicação.
Segurança
Muitas empresas temiam, no passado, prover funcionalidades na Internet devido ao medo de expor seus dados. Mas com advento dos Web Services elas podem publicar serviços de forma simples e que são totalmente isolados da base de dados. A segurança dos Web Services é um dos pontos fracos desta tecnologia. O problema não é a falta de mecanismos de segurança mas sim a falta de consenso em qual deve ser o mecanismo a ser adaptado pela tecnologia Web Service. As questões mais relevantes na segurança são as seguintes:
:arrow_right: Autenticidade (ter a certeza que uma transação do Web Service ocorreu entre o servidor e seu cliente;
:arrow_right: Privacidade (todas as mensagens trocadas entre o servidor e o cliente não são interceptadas por uma pessoa não autorizada);
:arrow_right: Integridade (as mensagens enviadas tanto pelo servidor ao cliente, como o contrário, devem permanecer inalteradas).
Integração de sistemas
Muitas pessoas consideram que os Web services corrigem um grande problema da informática: a falta de integração de sistemas. Os Web services permitem que a integração de sistemas seja realizada de maneira compreensível, reutilizável e padronizada. É uma tentativa de organizar um cenário cercado por uma grande variedade de diferentes aplicativos, fornecedores e plataformas.
Tecnologias Utilizadas
Para a representação e estruturação dos dados nas mensagens recebidas/enviadas é utilizado o XML . As chamadas às operações, incluindo os parâmetros de entrada/saída, são codificadas no protocolo SOAP. Os serviços (operações, mensagens, parâmetros, etc.) são descritos usando a linguagem WSDL. O processo de publicação/pesquisa/descoberta de Web Services utiliza o protocolo UDDI.
XML
Extensible Markup Language (XML) é a base em que os Web Services são construídos. O XML fornece a descrição, o armazenamento, o formato da transmissão para trocar os dados através dos Web Services e também para criar tecnologias Web Services para a troca dos dados. A sintaxe de XML usada nas tecnologias dos Web Services especifica como os dados são representados genericamente, define como e com que qualidades de serviço os dados são transmitidos, pormenoriza como os serviços são publicados e descobertos. Os Web Services decodificam as várias partes de XML para interagir com as várias aplicações.
SOAP
O SOAP (Simple Object Access Protocol) baseia-se numa invocação remota de um método e para tal necessita especificar o endereço do componente, o nome do método e os argumentos para esse método. Estes dados são formatados em XML com determinadas regras e enviados normalmente por HTTP para esse componente. Não define ou impõe qualquer semântica, quer seja o modelo de programação, quer seja a semântica específica da implementação. Este aspecto é extremamente importante, pois permite que quer o serviço, quer o cliente que invoca o serviço sejam aplicações desenvolvidas sobre diferentes linguagens de programação. Por esta razão, o SOAP tornou-se uma norma aceita para se utilizar com Web Services, uma tecnologia construída com base em XML e HTTP. Desta forma, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização da linguagem XML e do mecanismo de transporte HTTP ou outro como, por exemplo, SMTP. O SOAP permite que os documentos XML de envio e de recepção sobre a Web suportem um protocolo comum de transferência de dados para uma comunicação de rede eficaz, ou seja, o SOAP providencia o transporte de dados para os Web Services.
Em relação a Web, o SOAP é um protocolo de RPC que funciona sobre HTTP (ou SMTP, ou outro) de forma a ultrapassar as restrições de segurança/firewalls normalmente impostas aos sistemas clássicos de RPC (RMI, DCOM, CORBA/IIOP) suportando mensagens XML. Em vez de usar HTTP para pedir uma página HTML para ser visualizada num browser, o SOAP envia uma mensagem de XML através do pedido HTTP e recebe uma resposta, se existir, através da resposta do HTTP. Para assegurar corretamente a transmissão da mensagem de XML, o servidor de HTTP, tais como Apache ou IIS (Microsoft Internet Information Server), recebe mensagens SOAP e deve validar e compreender o formato do documento XML definido na especificação SOAP v1.1.
WSDL
É a sigla de Web Services Description Language, padrão baseado em XML para descrever o serviço como no COM, onde ele traz os métodos do Web Service. Funciona como uma espécie de "TypeLibrary" do Web Service, além de ser usado para a validação das chamadas dos métodos. O WSDL é uma especificação desenvolvida pelo W3C. O WSDL é extensível para permitir a descrição dos serviços e suas mensagens, independentemente dos formatos de mensagem e dos protocolos de rede que sejam usados. O WSDL descreve os serviços disponibilizados à rede através de uma semântica XML, este providencia a documentação necessária para se chamar um sistema distribuído e o procedimento necessário para que esta comunicação se estabeleça. Enquanto que o SOAP especifica a comunicação entre um cliente e um servidor, o WSDL descreve os serviços oferecidos.
RESTFULL
A quantidade de dispositivos que surgem e são utilizados por consumidores tem aumentado de forma significativa, e criar sistemas que possuem uma única interface gráfica (GUI) pode não fazer tanto sentido como um tempo atrás.As APIs RESTful nos permite desenvolver funcionalidades de forma desacoplada das nossas GUIs, o que nos deixa capazes de criar um mesmo conjunto de regras de negócios para vários dispositivos. Além disso, a quantidade de usuários que possuem acesso à Internet é cada vez maior, e por isso precisamos criar sistemas cada vez mais escaláveis. Pensando em algumas dessas motivações, neste post iremos discutir alguns conceitos primordiais e entender um pouco melhor sobre o que de fato é REST.
O que é REST?
REST é acrônimo de Representational State Transfer, e tem como objetivo primário a definição de características fundamentais para a construção de aplicações Web seguindo boas práticas. A Web como a conhecemos hoje, funciona seguindo práticas REST, e para entendermos melhor, vamos considerar o exemplo abaixo:
:arrow_right: Você entra com um endereço em seu navegador (Chrome, Firefox, Edge, etc).
:arrow_right: Seu navegador estabelece uma conexão TCP/IP com o servidor de destino e envia uma requisição GET HTTP com o endereço que você digitou.
:arrow_right: O servidor interpreta sua requisição e de acordo com o que foi solicitado, uma resposta HTTP é retornada ao seu navegador.
:arrow_right: A resposta retornada pode ser de sucesso, contendo alguma representação em formato HTML, ou pode ser algum erro, como por exemplo o famoso 404 Not Found, que indica que o endereço/recurso que você solicitou não pôde ser encontrado.
:arrow_right: Em caso de sucesso, o seu navegador interpreta o HTML e você consegue navegar pela página renderizada.
Todo esse processo é repetido enquanto você está navegando em alguma página Web. Cada link que você clica ou formulário que submete, efetua os passos que discutimos acima.
Esses elementos são responsáveis por permitirmos criar aplicações Web da forma que conhecemos hoje, e são esses elementos que vamos detalhar melhor abaixo.
Recursos
Um recurso é um elemento abstrato e que nos permite mapear qualquer coisa do mundo real como um elemento para acesso via Web. A partir desse endereço, estamos aptos a acessar algum recurso, que poderia ser por exemplo, cursos ou alunos.
Interfaces Uniforme
O HTTP nos fornece uma interface de operações padronizadas, permitindo que possamos criar, atualizar, pesquisar, remover e executar operações sob um determinado recurso. Além de operações padronizadas, o HTTP fornece um conjunto de respostas para que os clientes (navegadores, APIs, etc) possam saber, de forma adequada, como agir perante uma determinada resposta.
:arrow_right: GET
O método GET é utilizado quando existe a necessidade de se obter um recurso. Ao executar o método GET sob um recurso, uma representação será devolvida pelo servidor. Em aplicações Web, normalmente é retornado uma representação HTML.
:arrow_right: POST
Utilizamos o método POST quando desejamos criar algum recurso no servidor a partir de uma determinada representação. Exemplo disso é quando fazemos a submissão de algum formulário em uma página Web.
:arrow_right: DELETE
Como você já deve estar imaginando, o método DELETE é utilizado com o intuito de remover um recurso em um determinado servidor.
Respostas
Baseado nos métodos, o servidor deve processar cada uma das requisições e retornar uma resposta adequada. Veja um resumo de cada uma dessas respostas.
- 1XX – Informações Gerais
- 2XX – Sucesso
- 3XX – Redirecionamento
- 4XX – Erro no cliente
- 5XX – Erro no servidor
Para cada tipo que você pode ver, existe uma série de respostas relacionadas. Por exemplo, se o servidor retornar um “200 OK”, significa que o recurso pedido foi retornado com sucesso. Por outro lado, se o servidor retornar um “404 Not Found”, significa que o recurso que estamos pedindo não foi encontrado. Apesar de muitas aplicações Web não seguirem o uso adequado de métodos e respostas, devemos sempre que possível, construir nossas aplicações utilizando-as da maneira mais adequada possível.
Representações
Em aplicações Web, a representação mais utilizada é o HTML. Essa representação é utilizada como forma de encapsular as informações relacionadas a um determinado recurso. Além do HTML, podemos utilizar XML, JSON, ou algum outro formato que melhor atenda o cenário que estamos desenvolvendo. É importante citar que um recurso pode ter mais de uma representação, ou seja, podemos construir aplicações que para determinados cenários, retornem representações diferentes, baseado nas necessidades de cada cliente.
Hypermedia
Hypermedia é um dos conceitos mais importantes em aplicações que seguem o modelo REST. É essa característica que permite criarmos aplicações que possam evoluir de formas tão surpreendentes. Uma representação hypermedia trabalha basicamente como um motor de estado, permitindo que clientes naveguem nos mesmos. Cada estado é um documento (uma página HTML) e possui referências para futuros estados (a partir de links).
Sumario das anotações
| Anotações | Descrição |
|---|---|
| @Path | The @Path annotation's value is a relative URI path indicating where the Java class will be hosted: for example, /helloworld. You can also embed variables in the URIs to make a URI path template. For example, you could ask for the name of a user and pass it to the application as a variable in the URI: /helloworld/{username}. |
| @GET | The @GET annotation is a request method designator and corresponds to the similarly named HTTP method. The Java method annotated with this request method designator will process HTTP GET requests. The behavior of a resource is determined by the HTTP method to which the resource is responding. |
| @POST | The @POST annotation is a request method designator and corresponds to the similarly named HTTP method. The Java method annotated with this request method designator will process HTTP POST requests. The behavior of a resource is determined by the HTTP method to which the resource is responding. |
| @PUT | The @PUT annotation is a request method designator and corresponds to the similarly named HTTP method. The Java method annotated with this request method designator will process HTTP PUT requests. The behavior of a resource is determined by the HTTP method to which the resource is responding. |
| @DELETE | The @DELETE annotation is a request method designator and corresponds to the similarly named HTTP method. The Java method annotated with this request method designator will process HTTP DELETE requests. The behavior of a resource is determined by the HTTP method to which the resource is responding |
| @HEAD | The @HEAD annotation is a request method designator and corresponds to the similarly named HTTP method. The Java method annotated with this request method designator will process HTTP HEAD requests. The behavior of a resource is determined by the HTTP method to which the resource is responding. |
| @PathParam | The @PathParam annotation is a type of parameter that you can extract for use in your resource class. URI path parameters are extracted from the request URI, and the parameter names correspond to the URI path template variable names specified in the @Path class-level annotation |
| @QueryParam | The @QueryParam annotation is a type of parameter that you can extract for use in your resource class. Query parameters are extracted from the request URI query parameters |
| @Consumes | The @Consumes annotation is used to specify the MIME media types of representations a resource can consume that were sent by the client |
| @Produces | The @Produces annotation is used to specify the MIME media types of representations a resource can produce and send back to the client: for example, "text/plain" |
| @Provider | The @Provider annotation is used for anything that is of interest to the JAX-RS runtime, such as MessageBodyReader and MessageBodyWriter. For HTTP requests, the MessageBodyReader is used to map an HTTP request entity body to method parameters. On the response side, a return value is mapped to an HTTP response entity body by using a MessageBodyWriter. If the application needs to supply additional metadata, such as HTTP headers or a different status code, a method can return a Response that wraps the entity and that can be built using Response.ResponseBuilder |
| @ApplicationPath | The @ApplicationPath annotation is used to define the URL mapping for the application. The path specified by @ApplicationPath is the base URI for all resource URIs specified by @Path annotations in the resource class. You may only apply @ApplicationPath to a subclass of javax.ws.rs.core.Application |
 |
JavaServer Faces
JavaServer Faces (JSF) é uma especificação Java para a construção JavaServer Faces (JSF) é uma especificação Java para a construção de interfaces de usuário baseadas em componentes paraaplicações web. Possui um modelo de programação dirigido a eventos, abstraindo os detalhes da manipulação dos eventos e organização dos componentes, permitindo que o programador se concentre na lógica da aplicação.
Foi formalizada como um padrão através do Java Community Process e faz parte da Java Platform, Enterprise Edition. JSF 2 utiliza Facelets como seu sistema de template padrão. Outras tecnologias da camada de visão, como XUL também podem ser empregadas. Em contraste, JSF 1.x utiliza JavaServer Pages (JSP) como seu sistema de template padrão.
Histórico
O JavaServer Faces ganhou expressão na versão 1.1 quando implementado pela comunidade utilizando a especificação 127 do Java Community Process, evidenciando maturidade e segurança. Hoje ele está na versão 2.0 da especificação 252 do JCP. A fundação Apache vem realizando esforços na implementação da especificação através do projeto MyFaces. O reconhecimento do trabalho é visto por diversas empresas, tanto é que a Oracle doou os fontes do ADF Faces, conjunto de mais de 100 componentes JSF, para o projeto MyFaces que o denominará de Trinidad. O JSF é atualmente considerado pela comunidade Java como a última palavra em termos de desenvolvimento de aplicações Web utilizando Java, resultado da experiência e maturidade adquiridas com o JSP/Servlet (Model1), Model2 (MVC) e Struts.
Como trabalha
JavaServer Faces é baseada em um modelo de desenho de IU (interface de usuário) baseada em componentes, usando arquivos XML chamados de modelos de visão ouFacelets views. Os pedidos são processados pelo FacesServlet, que carrega o modelo de visão adequado, constrói uma árvore de componentes, processa os eventos e apresenta a resposta, normalmente na linguagem HTML, para o cliente. O estado de componentes de interface do usuário e outros objetos de interesse de escopo, é salvo no final de cada pedido em um processo chamado stateSaving (nota: transiente true) e restaurado na próxima criação desta visão. Objetos e estados podem ser salvos ou no cliente ou no servidor.
Características
:arrow_right: Permite que o desenvolvedor crie UIs através de um conjunto de componentes UIs pré-definidos;
:arrow_right: Fornece um conjunto de tags JSP para acessar os componentes;
:arrow_right: Reutiliza componentes da página;
:arrow_right: Associa os eventos do lado cliente com os manipuladores dos eventos do lado do servidor (os componentes de entrada possuem um valor local representando o estado no lado servidor);
:arrow_right: Fornece separação de funções que envolvem a construção de aplicações Web.
:arrow_right: Utiliza Ajax em alguns de seus componentes tornando alguns processos mais rápidos e eficientes.
Ciclo de vida
Diagrama mostrando o fluxo do ciclo de vida do JSF.
Ciclo de vida do JSF é o nome dado à sequência de processamento realizada na implementação JSF para a geração das visões. O JSF, diferente de outros frameworks, possui um processamento de requisição dividido em seis fases:
- Restauração da visão - o objetivo principal desta fase é construir a árvores de componentes.Ela utiliza o template e cria a árvore inicial através da análise da requisição. Após isto, ela salva o estado da árvore no objeto FacesContext. Nas requisições subsequentes, ela cria a árvore do estado e procede a execução do resto do ciclo de vida.
- Aplicação dos valores de requisição - o JSF pega cada componente da árvore começando com a raiz e a cria ou recupera do objeto FacesContext. Cada componente na árvore gerencia seus próprios valores e toma-os dos parâmetros, cookies e cabeçalhos da requisição HTTP.
- Validações de processo - o JSF realiza a conversão e validação sobre todos os componentes começando com o raiz. O valor submetido de cada componente é convertido em um objeto e validado chamando-se o validador registrado. O JSF salva o valor submetido. Se ocorrer um erro durante a conversão ou validação, o ciclo de vida escapa diretamente para a fase de "apresentação da resposta".
- Atualização de valores de modelo - durante esta fase, o valor do componente é passado para o modelo através da atualização das propriedades dos backing beans.
- Invocação da aplicação - a manipulação de evento para cada ação e ouvidor de ação é executada começando com o(s) ouvidor(es) de ação e então a chamada do método de ação.
Recursos visuais
O framework JSF permite a inserção, via IDE, de:
- Folhas de estilo (CSS);
- Comandos em JavaScript;
- Metodologia Ajax.
JSF inclui
- Suporte a internacionalização e acessibilidade;
- Um conjunto padrão de componentes de interface de usuário que possibilitam validação padronizada;
- Duas bibliotecas de etiqueta ("tag libraries") especiais do JavaServer Pages (JSP) para expressar a interface do JavaServer Faces dentro de uma página JSP;
- Um modelo de eventos do lado servidor ("server-side event model");
- Gerência de estados;
- Managed Beans;
- Linguagem de Expressão Unificada ("Unified Expression Language") para JSP 2.0 e JSF 1.2.
PrimeFaces
:arrow_right: Showcase do PrimeFaces
https://www.primefaces.org/showcase/
:arrow_right: Temas
https://www.primefaces.org/themes/
Para habilitar o JSF no projeto:
Clicar no projeto com o botão direito.
Clicar em “project facets” -> marcar “java server faces” -> clicar no link “futher configuration”
Clicar em type e selecionar “disable library”
Clicar em “url mapping” -> clicar em “remove”
Clicar em “add”
Escrever a “url pattern” -> ok
Clicar em “ok”
Clicar em “apply and close”
Maven
:point_right: https://maven.apache.org/
Ant / Maven –> Ant (Módulo antigo), arrastando jar, apontando para jar(set classpath (Eclipse), Ant Botar o Jar sempre no Seu Projeto… Projeto Fica Pesado Ao Extremo
Maven … (pom.xml) –> configuração dequal e de onde você irá trabalhar com o Java .
Apache Maven
Apache Maven, ou simplesmente Maven, é uma ferramenta de automação de compilação utilizada primariamente em projetos Java. Ela é similar à ferramenta Ant, mas é baseada em conceitos e trabalhos diferentes em um modo diferente. Também é utilizada para construir e gerenciar projetos escritos em C#, Ruby, Scala e outras linguagens. O projeto Maven é hospedado pela Apache Software Foundation, que fazia parte do antigo Projeto Jakarta.
O Maven utiliza um arquivo XML (POM) para descrever o projeto de software sendo construído, suas dependências sobre módulos e componentes externos, a ordem de compilação, diretórios e plug-ins necessários. Ele vem com objetivos pré-definidos para realizar certas tarefas bem definidas como compilação de código e seu empacotamento.
O Maven baixa bibliotecas Java e seus plug-ins dinamicamente de um ou mais repositórios, como o Maven 2 Central Repository, e armazena-os em uma área de cache local. Este cache local de artefatos baixados pode também ser atualizado com artefatos criados por projetos locais. Repositórios públicos podem também ser atualizados.
O Maven é construído utilizando uma arquitetura baseada em plugin, que permite que ele faça uso de qualquer aplicação controlável através da entrada padrão. Teoricamente, isto permitiria qualquer um escrever plugins para fazer interface com ferramentas de construção (compiladores, ferramentas de teste de unidade, etc.) para qualquer outra linguagem. De fato, o suporte e uso para linguagens diferentes de Java tem sido mínimas. Atualmente existe um plugin para o framework .NET e é mantido, e um plugin nativoC/C++ é mantido para o Maven 2.
POM
O que é um POM ?
Um Modelo de Objeto de Projeto ou POM é a unidade fundamental de trabalho no Maven. É um arquivo XML que contém informações sobre o projeto e detalhes de configuração usados pelo Maven para compilar o projeto. Ele contém valores padrão para a maioria dos projetos. Exemplos para isso é o diretório de construção, que é target; o diretório de origem, que é src/main/java; o diretório de origem do teste, que é src/test/java; e assim por diante. Ao executar uma tarefa ou objetivo, o Maven procura o POM no diretório atual. Ele lê o POM, obtém as informações de configuração necessárias e depois executa o objetivo.
Algumas das configurações que podem ser especificadas no POM são as dependências do projeto, os plug-ins ou objetivos que podem ser executados, os perfis de construção e assim por diante. Outras informações, como a versão do projeto, descrição, desenvolvedores, listas de discussão e outras, também podem ser especificadas.
No cabeçalho de um POM temos algumas tags básicas que definem qual versão do modelo de POM utilizado. O seu GroupId que seria algo como o prefixo da estrutura de pacotes do projeto. O ArtifactId que define qual é o nome o artefato final .war ou .jar terá quando empacotado. Version define a versão do projeto que irá complementar o nome do artefato. A tag Packaging por sua vez define qual tipo de empacotamento o projeto terá após o processo de build, no nosso caso será um .war. E a tag Name define o nome do projeto.
A tag Properties possibilita definir por exemplo a versão do Spring, ou do JSF adotada para o projeto. Se uma dependência for definida como no trecho de código abaixo ao mudarmos a versão do Spring, por exemplo, para 3.1 todas as dependências serão baixadas para a versão 3.1. Podemos definir o contêiner web no qual será feito o deploy da aplicação (Tomcat) e também o tipo de codificação utilizada pelo projeto, no nosso caso o UTF8.
A tag Repositories define a lista de repositórios que serão acessados pelo Maven para baixar nossas dependencias. Muitas vezes é necessário colocar um repositório prioritário no inicio do POM para que o Maven inicie a busca pelas dependências a partir dele.
A tag dependencies define quais serão as dependências utilizadas no projeto no trecho de código abaixo declaramos algumas das dependências necessárias para se trabalhar com JavaServer Faces.
Muitas vezes algumas dependências precisam ser excluídas. Isso acontece por vários motivos primeiro pode ser que o projeto já utilize uma versão diferente da mesma dependência. Um segundo motivo pode ser o fato da dependência em questão gerar conflitos com outras utilizadas no projeto. A sintaxe para remover uma dependência é como o trecho de código abaixo. Nele estamos declarando a dependência do DOM4J mas estamos dizendo ao Maven para não baixar a dependência da XML-APIS. Se tirarmos essa exclusão o Maven vai analizar o POM da DOM4J e verificará que ela possui uma dependência da XML-APIS e assim entenderá que o projeto necessita dela e irá baixá-la para nosso .m2.
Repositorio
:point_right: https://mvnrepository.com/
Para criar o projeto maven..
File -> new -> maven Project
Marcar create a simple Project -> next
Colocar nome no group id -> artifact id -> packing war -> finish
O projeto começará com erro. Precisa configurar. Clicar no projeto com o botão direito -> Properties
Clicar em Project Facets -> alterar Java para 1.8 -> Apply -> Dynamic Web Module para 3.1 -> Desmarcar Dynamic -> Apply -> Marcar Dynamic novamente -> Clicar em Futher Configuration -> Alterar Content Directory para src/main/webapp -> =Marcar generate web.xml -> ok
Clicar em Apply…
Marcar Java Server Faces -> Futher Configuration
Em Type, clicar em Disable Library -> URL Mapping Patterns -> Add -> *.jsf -> ok
Marcar JPA -> Futher Configuration
Em Type, clicar em Disable Library -> ok
Apply -> ok
Para baixar as dependencias do POM
Clicar no projeto com o botão direito -> Maven -> Update project
Marcar force update -> clicar em OK Aguardar baixar as dependências.
Ireport Jasper
Introdução ao iReport
Para que um relatório possa ser gerado é necessário uma fonte de dados (representada pela interface JRDataSource), os parâmetros que podem ser necessários ao relatório e que são passados dentro de um HashMap (veja o quadro “Parâmetros do JasperReports”) e o arquivo .jasper (o que é e como esse arquivo é criado será explicado logo mais).
O iReport é a principal ferramenta para criação visual dos arquivos .jrxml. Nestes arquivos encontramos as definições do relatório em formato XML. O arquivo .jasper é gerado automaticamente após a compilação do .jrxml pelo iReport.
É possível criar o arquivo .jrxml usando apenas um editor de texto como o bloco de notas, porém além da difícil tarefa de entender e escrever o XML no formato exigido pelo JasperReports, a dificuldade de posicionar os elementos de forma correta na página é muito grande.
Ao criar um relatório no iReport temos disponíveis várias seções, conhecidas também por band. Elas são divisões internas do relatório onde podemos inserir os elementos de texto e imagem. No iReport temos basicamente oito seções:
- Title: Título do relatório. Pode ser impresso em uma página separada;
- Page Header: Cabeçalho de cada página do relatório;
- Column Header: Seção exibida em cada página que contém uma seção Detail;
- Detail: Nesta seção será impresso todos os registros que o DataSource fornecer ao relatório. No nosso exemplo todos os pedidos da lista de JavaBeans serão mostrados aqui;
- Column Footer: Exibido em cada página que contém uma seção Detail;
- Page Footer: Rodapé de cada página;
- Summary: Seção exibida no fim do relatório. Pode ser impresso em uma página separada;
- No Data: Seção exibida quando não há registros;
- Background: Nesta seção é possível inserir uma imagem de fundo que será exibida em cada página do relatório.
Parâmetros do JasperReports
O JasperReports possui vários parâmetros pré-definidos que podem ser colocados no objeto Map passado como parâmetro no método fillReport() da classe JasperFillManager. Dessa forma substituímos os valores padrões quando necessitamos usar um valor customizado para a execução do relatório.
Um exemplo de uso desses parâmetros pré-definidos pode ser visto na Listagem 8, mais precisamente no método doProcess(), onde informamos no Map os parâmetros SUBREPORT_DIR, REPORT_RESOURCE_BUNDLE e REPORT_LOCALE. Veja na Tabela Q1 qual a utilidade de cada um deles e de mais alguns parâmetros.
| Nome (Chave no Map) | Descrição |
|---|---|
| REPORT_PARAMETERS_MAP | Inserir um objeto do tipo Map com os parâmetros utilizados para preencher o relatório. |
| REPORT_LOCALE | Inserir um objeto do tipo java.util.Locale. Este parâmetro é importante para que o JasperReports saiba corretamente qual o idioma utilizar no relatório. |
| REPORT_RESOURCE_BUNDLE | Inserir um objeto do tipo java.util.ResourceBundle contendo mensagens internacionalizadas. |
| REPORT_TIME_ZONE | Inserir um objeto do tipo java.util.TimeZone para formatar datas corretamente conforme o fuso horário. |
| REPORT_CONNECTION | Inserir um objeto do tipo java.sql.Connection caso seu relatório necessite de uma conexão com o banco de dados. |
| REPORT_FORMAT_FACTORY | Inserir um objeto do tipo FormatFactory para ser usado na formatação de campos data e número do relatório. Por exemplo, os números podem ser exibidos com o separador decimal ponto ou o separador vírgula, dependendo da localidade do usuário. |
| SUBREPORT_DIR | Informar neste parâmetro o diretório onde está(ão) armazenado(s) o(s) arquivo(s) jasper do(s) sub-relatório(s). |
O iReport é uma ferramenta que oferece ótima produtividade e flexibilidade para o desenvolvimento de relatórios bastante sofisticados. Ele aceita diversas fontes de dados para geração de relatórios que podem ser executados tanto em ambientes desktop quanto web.
O iReport é muito versátil, por isso não se limita apenas a criação de relatórios tradicionais como o do exemplo. Muitas empresas adotaram esta ferramenta para criação e emissão de segunda via de faturas, etiquetas, recibos e termos de contratos para que os próprios clientes possam obter estes documentos em PDF nos sites de autoatendimento.
O relatório desenvolvido terá um relatório principal para mostrar os pedidos e um relatório interno (sub-relatório) para listar os itens que estão em cada pedido. O sub-relatório é construído de forma idêntica ao relatório principal, porém é feito pensando que ele estará dentro de outro, geralmente sem as seções Title, Page header, Page footer e summary.
Para criar o relatório com IReport..
Arquivo -> New…
Escolher o tipo de relatorio -> open this template…
Dar um nome para o relatorio e indicar onde será salvo > Proximo..
Finalizar…
Clicar no banco para criar conexão…
Clicar em new…
Escolher database JDBC connection -> Next…
Colar um nome para a conexão -> alterar o JDBC Driver para Mysql -> Alterar a URL JDBC -> Username e Senha -> Clicar em save password -> Test
Conectou -> Close…
Close…
Clicar no database…
Escrever a Query -> verificar se trouxe os campos do banco -> ok…
Abrir na lateral o Fields
Arrastar os campos para Details e organizar…
Clicar em preview para visualizar…
MongoDB
MongoDB (do inglês humongous, "gigantesco") é uma aplicação de código aberto, de alta performance, sem esquemas, orientado a documentos. Foi escrito na linguagem de programação C++. Além de orientado a documentos, é formado por um conjunto de documentos JSON. Muitas aplicações podem, dessa forma, modelar informações de modo muito mais natural, pois os dados podem ser aninhados em hierarquias complexas e continuar a ser indexáveis e fáceis de buscar. O desenvolvimento de MongoDB começou em outubro de 2007 pela 10gen. A primeira versão pública foi lançada em fevereiro de 2009.
Mongo (É um em Banco de dados (3ª camada) em Javascript) / Quem Grava o Projeto tb é Javascript (JSON) Comandos do Json para trabalhar com o Banco … Velocidade, melhor desempenho, BIG DATA … Quantidade de Dados, Imagem … Variedades de Informações / e velocidade de Captura de Informações. NOSQL (Javascript) _ Banco sem sql … Comandos de Javascript …
Introdução
É fato de que a maior parte dos bancos de dados existentes no mercado hoje são do tipo modelo relacional. Mas fatores novos estão mudando essa história, pelo menos no que se refere ao crescimento intenso da quantidade de dados de certas organizações, e algumas limitações do modelo relacional têm ajudado para alternativas de banco de dados apareçam buscando sanar essas limitações. A alternativa que tem ganhado bastante espaço nas organizações são os banco de dados chamados de NoSQL. Neste artigo, são apresentadas as principais características desses bancos de dados e, em especial, veremos as características do Banco de Dados Orientado a Documento MongoDB.
SGBDS Relacionados
Surgido nos anos 70, os SGBDs (Sistemas Gerenciadores de Banco de Dados) relacionais tem recursos que são importantes para facilitar o processo de criação e manutenção de sistemas, alguns deles são: a verificação e garantias de integridade dos dados, o gerenciamento de concorrência, recuperação de falhas, processos de uso de validação, a segurança, a otimização de consultas, etc..
Os Sistemas Gerenciadores de Banco de Dados relacionais mais conhecidos são: SQL Server, Oracle, PostgreSQL, MySQL, etc. Usam uma linguagem de manipulação, consulta e definição chamada SQL (Structured Query Language), que foi criada são as relações (ou tabelas), as quais são compostas de linhas (ou tuplas) e colunas (ou atributos).
Graças ao intenso crescimento do número de aplicações, soluções, recursos e tudo o que se refere a sistemas computacionais nas últimas décadas, o volume de dados associados a tais tipos de sistemas também teve um ritmo de crescimento acelerado. É justamente aí, nesses lugares nos quais o grande volume de dados é o problema, esses bancos baseados no Modelo Relacional, não tem sido eficientes o bastante. E essa é a dificuldade real do uso do Modelo Relacional: a difícil tarefa de conciliar a demanda por escalabilidade cada vez mais intensa.
Banco de dados NoSql
É na Web que encontramos a maior inspiração para o desenvolvimento de novas tecnologias de Banco de Dados. Tudo por causa da necessidade que surge para suprir as aplicações web que cada vez mais tem um grande volume de dados e requisitos diferenciados, como o elevado grau de disponibilidade a escalabilidade sob demanda, surge então uma nova categoria de SGBDs, conhecida como NoSQL, abreviação de Not Only SQL (não apenas SQL), criada inicialmente para foi proposta com o objetivo de atender aos requisitos de gerenciamento de grandes volumes de dados, semi-estruturados ou não estruturados. Ou seja, sendo utilizado principalmente em casos em que o Modelo Relacional não apresentava performance adequada.
É importante deixar claro que o NoSQL não veio para substituir os bancos de dados relacionais. Os bancos de dados NoSQL servem para uma gama de problemas que nem sempre são os mesmos dos bancos de dados relacionais. E quando se fala em NoSQL sempre se fala das grandes vantagens em termos de escala em comparação aos SGBDs relacionais. Não é verdade que os bancos de dados relacionais não escalam. A verdade é que eles não escalam com facilidade. Abaixo um esquema básico de aplicação web:
Se o sistema acima passar a demanda de usuários aumentarem muito surgem na nossa aplicação problemas com a escalabilidade. O que se pode fazer é aumentar a capacidade do servidor, dando-lhe um upgrade no seu processador, no armazenamento e em sua memória.. Ou então, fazer crescer a quantidade das máquinas de servidores web:
E se a aplicação web continuar a crescer? Certamente o banco de dados não iria suportar atender a todas as requisições em um tempo hábil. E se colocássemos mais máquinas rodando o nosso banco de dados?
Com isso, agora devemos escalar nosso banco de dados através de múltiplas máquinas, o que é mais complicado do que com os nossos servidores web. Na maioria dos casos não podemos simplesmente ligar mais uma máquina rodando o banco e esperar que tudo funcione. Vamos precisar de uma série de configurações e alterações nas nossas aplicações para fazer tudo funcionar na nova arquitetura distribuída. Os bancos de dados NoSQL vem para tornar este processo que muitas vezes é trabalhoso e complicado em um processo mais simples e robusto.
Como exemplo de aplicações que necessitam de um gerenciamento eficaz de grandes quantidades de dados não estruturados estão às redes sociais, exemplos clássicos nós temos o Twitter, Facebook e outras redes, onde a quantidade de informação gerada pelos usuários possui um crescimento que as bases de dados relacionais não conseguem comportar. Tudo isso se deve o fato dos bancos de dados relacionais não serem eficazes nesse requisito.
Esses bancos de dados NoSQL são amplamente adotados em empresas como Facebook, Amazon e Google com o intuito de atender às suas demandas de escalabilidade, alta disponibilidade e dados não estruturados. E vale ressaltar que, atualmente, diversos bancos de dados NoSQL de código livre estão disponíveis, exemplos disso são o Cassandra, Hypertable, MongoDB, Redis, CouchDB e Dynamo.
As primeiras e mais importantes implementações de um sistema realmente não-relacional são:
- BigTable – do Google. Surgiu em 2004 como um banco de dados proprietário de alta performance que tinha como objetivo promover maior escalabilidade e disponibilidade.
- Dynamo – da Amazon. Surgiu em 2007, o sistema que tinha como característica básica ser um banco de dados não-relacional, de alta disponibilidade, utilizado pelos web services da Amazon.
- Cassandra, de 2008, projetado para ser um sistema de banco de dados distribuído e de alta disponibilidade, desenvolvido pelo site Facebook para lidar com grandes volumes de dados. No início de 2010, o Cassandra desbancou o MySQL como banco de dados do Twitter, demonstrando sua importância cada vez mais crescente.
- MongoDB, lançada em 2009, um banco de dados orientado a documentos, escalável, de alta performance e livre de esquemas. E é o grande foco do nosso estudo.
Antes de falarmos mais sobre as soluções NoSQL, mais precisamente do MongoDB, é importante lembrar que o propósito, portanto, não é substituir o Modelo Relacional como um todo, mas apenas em casos nos quais seja necessária uma maior flexibilidade da estruturação do banco.
Criado pelo ex-Fundador do DoubleClick e CTO Dwight Merriman e DoubleClick ex-engenheiro e fundador ShopWiki e Eliot CTO Horowitz. Eles se basearam as suas experiências em construção de grande escala, alta disponibilidade, sistemas robustos para criar um novo tipo de banco de dados. O próprio Eliot dá a definição:
O MongoDB não foi concebido em um laboratório. Nós construímos o MongoDB com base em nossas experiências na construção de sistemas robustos de grande escala e alta disponibilidade. Não começamos do zero, realmente tentamos descobrir o que estava quebrado, e combater isso. Assim, a maneira que eu penso sobre MongoDB é que se você pegar o MySql, e alterar o modelo de dados do relacional para orientado a documento, você ganha uma grande quantidade de recursos: documentos embarcados para velocidade, facilidade de gerenciamento, desenvolvimento ágil com bancos de dados sem “schema”, escalabilidade horizontal mais fácil, pois “joins” não são tão importantes. Há muitas coisas que funcionam muito bem nas bases de dados relacionais: índices, consultas dinâmicas e atualizações para citar alguns, e nós não mudamos muito neste ponto. Por exemplo, a maneira de projetar seus índices no MongoDB deve ser exatamente do jeito que você faz isso no MySQL ou Oracle, você só ganha a opção de indexar um campo embarcado.
– Eliot Horowitz, CTO 10gen e Co-fundador
Fazendo uma busca em literatura disponível, podemos resumir MongoDB nas características abaixo:
:arrow_right: Open Source;
:arrow_right: Alta Performance;
:arrow_right: Schema (Esquema) Aberto – para fácil evolução do esquema;
:arrow_right: Banco de Dados Orientado a Documento;
:arrow_right: Preparador para trabalhar na nuvem;
MongoDB é um banco de dados de documento, e isto quer dizer que podemos armazenar dados como documentos.
E o que são documentos? São as unidades básicas de armazenamento e estes não utilizam necessariamente qualquer tipo de estruturação pré-definida, como é o caso das tabelas do Modelo Relacional. Ou seja, o MongoDB armazena coleções de documentos. Um documento, em geral, é um objeto com um identificador único acrescido de um conjunto de campos, que podem ser strings, listas ou documentos aninhados. Neste modelo temos um conjunto de documentos e em cada documento temos um conjunto de campos (chaves) e o valor deste campo. Outra característica importante é que este modelo não depende de um esquema rígido, ou seja, não exige uma estrutura fixa como ocorre nos bancos tradicionais, os relacionais. Assim, é possível que ocorra uma atualização na estrutura do documento, com a adição de novos campos, por exemplo, sem causar problemas na estrutura do banco de dados. Esta flexibilidade é uma das grandes vantagens deste modelo.
O MongoDB é um destes bancos que utiliza o modelo de armazenamento orientado a documento que armazena documentos no estilo parecido JSON chamado BSON, como documentos com esquemas dinâmicos, quer dizer que eu não preciso ter a mesma estrutura em casa registro. O objetivo do MongoDB é preencher a lacuna entre valores/chave lojas (que são rápidos e escalonáveis) e bancos de dados relacionais (que têm a funcionalidade rica). Atualizações in-place rápidas, ou seja, uma transação atômica. Quem trabalha muito com Banco de Dados Relacionais o MongoDB é uma boa quebra de paradigma já que ele não possui schema – o que quer dizer que não é necessário estipular a estrutura dos dados ao criar o banco, basta adicionar o documento(JSON) contendo os campos desejados, inclusive um documento pode conter outros documentos.
Como o formato BSON pode ser estendido, é possível acrescentar outras informações ao objeto aluno, de maneira que ele incorpore mais informações no objeto criado, como um array de dados por exemplo. Para um maior entendimento das características do MongoDB, que são expressadas como objetos JSON. O quadro seguinte mostra exemplos da sintaxe SQL e da sintaxe da Linguagem de Consulta do Mongo.
Termos
Os bancos de dados NoSQL foram especialmente projetados para atender as características de: maior disponibilidade, menor tempo de resposta para consultas, paralelismo de atualização de dados e maior grau de concorrência. O MongoDB inclui um módulo de sharding automático que permite a construção de um cluster de banco de dados escalável horizontalmente projetado para incorporar novas máquinas de forma dinâmica .
Para instalar o MongoDB no Windows
Fazer o download
:point_right: https://www.mongodb.com/download-center/community
Estamos utilizando a Versão: 3.6 em aula
• Baixar o arquivo
• Descompactar o arquivo de instalação no “c:\”
• Renomear a pasta para “mongodb”
• Criar uma pasta chamada “data” e dentro dela criar uma pasta chamada “db”
Para abrir o mongo
• Abrir o promp de comando do DOS.
• Digitar “cd\” para voltar para o diretório raiz.
• Digitar o caminho de onde o mongo está descompactado: “cd mongodb/bin”.
• Digitar “mongod” para abrir o servidor.
• Abrir outro promp de comando do DOS.
• Digitar “cd\” para voltar para o diretório raiz.
• Digitar o caminho de onde o mongo está descompactado: “cd mongodb/bin”.
• Digitar “mongo” para abrir o banco.
JBoss Application Server
JBoss é um servidor de aplicação de código fonte aberto baseado na plataforma JEE e implementado completamente na linguagem de programação Java. Em virtude disso, ele pode ser usado em qualquer Sistema Operacional que suporte a referida linguagem. O JBoss Application Server 7, utiliza os arquivos: standalone.bat (ou standalone.sh) para prover a sua inicialização.
Os desenvolvedores responsáveis estão em uma empresa de serviços chamada "JBoss Inc." fundada por Marc Fleury, o criador da primeira versão do JBoss. O projeto é custeado por uma rede mundial de colaboradores. Em Abril de 2006, foi anunciada sua aquisição pela Red Hat.
A partir da versão 8 o JBoss passou a se chamar Wildfly, além da troca de nomes teve várias melhorias e mudanças como a troca do container que era o JBossWeb para o Undertow.
Como alternativa open-source ao JBoss, temos o GlassFish, que é a implementação de referência de toda a especificação Java EE.
O JBoss Application Server 7 é uma das primeiras plataformas de uma nova etapa de projetos da JBoss, que visam ambientes como Cloud, passando por pequenos dispositivos a grandes servidores. O JBoss AS 7 traz inúmeras inovações. Dentre elas podemos destacar uma incrível rapidez de aproximadamente 4 segundos na inicialização, baixíssimo consumo de recursos e serviços iniciados on-demand. Tudo isso é possível graças à nova arquitetura baseada em um kernel ainda mais modular, composto por JBoss Modules e o JBoss Modular Service Container (MSC).
Desde que a Red Hat adquiriu o JBoss em 2006, houve um grande avanço em relação a plataformas e projetos existentes na comunidade. O número de plataformas saltou de apenas uma, que representava o próprio application server, para oito, incluindo soluções para SOA, Portais, Regras e Cloud. Já o número de projetos cresceu de aproximadamente 20 para mais de 140 disponíveis na JBoss Community (www.jboss.org).
A Tecnologia da Informação mudou drasticamente nestes últimos anos. Se considerarmos hardware, por exemplo, é fato que existem muito mais celulares hoje em dia do que computadores. É possível encarar smartphones como computadores, pois sua capacidade de processamento e memória são incrivelmente altas. Hoje em dia é comum encontrarmos processadores em câmeras, Smartphones, Kindles, iPads, ou até mesmo em máquinas de café e geladeiras. Podemos dizer também que estes equipamentos são equivalentes a supercomputadores de 20 anos atrás, ou até mesmo desktops de 10 anos atrás, e ainda assim, muitos deles estão presentes em nossos bolsos. Estes tipos de dispositivos já estão aqui há algum tempo e vieram para ficar.
Quando a Apple criou um segmento de mercado completamente novo, o iPad, já existe mais de 20 milhões deles por aí e a utilização de smartphones vem crescendo ainda mais. Em nossas casas, mais e mais dispositivos estão se conectando e se comunicando, desde XBox ou PlayStation 3, até aparelhos de TV e home theaters. Atualmente é comum armazenarmos informações em Cloud, como simples scores de um videogame ou até mesmo documentos usando serviços do Google, e isto tudo ocorre de forma natural. Sem falar das redes sociais estourando em nosso cotidiano, é notável que interagir neste mundo que vivemos se tornou muito mais fácil.
O JBoss Application Server 7 é a primeira plataforma desta nova etapa, que traz inúmeras inovações, como rapidez na inicialização, baixíssimo consumo de recursos, serviços iniciando on-demand, entre tantas outras, pensando no que estamos vivendo hoje e o que poderá vir para amanhã, adaptando-se a ambientes nas nuvens com clusters elásticos ou até mesmo a dispositivos que cabem em nossos bolsos.
Vantagens:
Uma inicialização rápida e o baixo consumo de memória abrem diversas possibilidades, como executar o container Java EE em um teste unitário. Outra possibilidade seria utilizar apenas uma JVM com o Application Server por aplicação, tornando a manutenção de aplicações independente. Desta forma, caso seja necessário parar o servidor, teríamos impacto apenas em uma aplicação.
Outra vantagem é executar o JBoss AS 7 em diversos ambientes como cloud, pois caso surja uma grande demanda de acessos, um novo servidor poderá ser iniciado de forma extremamente rápida. Com o baixo consumo de memória, quem sabe até mesmo rodar o JBoss AS 7 em ambientes portáteis, como smartphones ou tablets. Já para ambientes comuns como de desenvolvimento, se for necessário parar o servidor por algum motivo qualquer, você poderá inicializá-lo em poucos segundos, aumentando sua produtividade.
Além de todas estas vantagens, ainda torna-se extremamente fácil rodar diversas instâncias em seu próprio laptop.
Estrutura de diretórios
A distribuição do AS 7 está organizada em uma estrutura de diretórios bem diferente das versões anteriores. A Figura 6mostra como essa nova estrutura é composta. Veja a seguir mais detalhes sobre cada um dos diretórios:
• appclient: contém a configuração de um Application Client Container – ACC. Trata-se de um container pré-configurado usado quando se deseja acessar recursos Java EE remotos (EJB, Filas JMS, etc.) a partir de aplicações standalone (aplicação Desktop Swing);
• bin: contém vários scripts para manutenção e gerenciamento da instalação do servidor de aplicação, que estão disponíveis para as plataformas Linux (.sh) e Windows (.bat). Também são fornecidos scripts utilitários, como por exemplo, para acesso à CLI;
• bundles: contém os bundles (serviços) OSGi que fazem parte do subsistema OSGi fornecido pelo AS 7. Como veremos mais adiante, o AS 7 fornece suporte ao deployment de bundles OSGi;
• docs: ao contrário do que parece, não contém a documentação do servidor de aplicação. A documentação oficial está disponível online no site do JBoss AS. Este diretório é dividido três subdiretórios:
• examples: contém alguns exemplos de configuração de profiles (conjunto de subsistemas) específicos;
• licenses: contém as licenças de todas as tecnologias que compõem o servidor de aplicação;
• schema: contém os arquivos XML Schema que definem os diversos descritores utilizados na configuração do servidor. Bastante útil tanto para referência como para uso em uma IDE.
• domain: contém os arquivos de configuração, bem como toda a estrutura necessária para execução do servidor em modo Domain. O diretório domain é composto por vários subdiretórios. O primeiro deles é o configuration, que armazena os descritores domain.xml e host.xml – veremos detalhes dessa configuração mais adiante, quando falarmos sobre domínios. Após a primeira inicialização temos o diretório content, que armazena os deployments realizados no domínio. O diretório log armazena os logs dos processos que compõem o domínio(process-controller e host-controller) – também veremos detalhes sobre estes processos em breve. O diretório servers hospeda a estrutura individual de cada instância do servidor (server nodes) configurada no host para fazer parte do domínio. Cada server node possui seu próprio log (diretório log), bem como seus próprios arquivos de dados (diretório data) e temporários (diretório tmp). Por último, temos o subdiretório tmp, que armazena alguns artefatos temporários gerados em tempo de execução pelos processos do domínio. Como veremos mais adiante, o modo Domain é uma das grandes novidades no AS 7;
• modules: contém todos os módulos e extensões que compõem o núcleo do AS 7, bem como os serviços fornecidos pelo servidor de aplicação. Como veremos mais adiante, o AS 7 é composto por diversos módulos;
• standalone: contém os arquivos de configuração necessários para executar o servidor em modo isolado. Esse diretório é semelhante aos profiles (all, default e minimal) encontrados em versões anteriores do JBoss AS. O diretório standalone também é composto por vários subdiretórios. O primeiro deles é o configuration, que armazena o descritor standalone.xml que define o conjunto de subsistemas (profile) a ser inicializado pela instância do servidor em modo standalone. O diretório deployments armazena os pacotes (WAR, EAR, JAR, SAR) implantados no servidor. O diretório lib é usado para armazenar bibliotecas e extensões do servidor de aplicação. Por fim, após a primeira inicialização, são criados os diretórios data, log e tmp, que armazenam, respectivamente, arquivos de dados, log de saída e arquivos temporários gerados em tempo de execução;
• welcome-content: contém a página de boas-vindas do AS 7. É o contexto raiz (http://localhost:8080/) do container web do servidor.
Após instalarmos o JBoss AS 7 e realizarmos um tour inicial em sua estrutura de diretórios, vamos conhecer alguns detalhes e novidades desta versão.
Modos de Operação
AS 7 possui dois modos de operação: Standalone e Domain. O que os diferencia basicamente é a execução e o gerenciamento. Como o próprio nome diz, Standalone significa uma única instância de execução. Já o modo Domain permite a execução distribuída e o gerenciamento centralizado de múltiplas instâncias.
Estes dois modos não existiam nas versões anteriores do JBoss AS, portanto, havia apenas uma única forma de iniciar uma nova instância do servidor, que se parecia muito com o modo Standalone do AS 7. Esta instância era baseada em um profile, que nada mais é do que um conjunto de recursos e serviços fornecidos pelo Servidor de Aplicação devidamente configurado e pronto para uso. Um profile define as características, bem como as capacidades oferecidas por uma instância de execução do servidor.
Como exemplo podemos citar um profile especializado na camada web, que oferece a configuração necessária para o deployment e execução de aplicações utilizando JSP, Servlet, JSF, CDI, JPA, etc. Outro exemplo seria um profile que traz todo o arsenal necessário para desenvolver qualquer aplicação Java EE, como suporte a objetos distribuídos, EJB, Remoting, JNDI, Mensageria, entre outras coisas que fazem parte desta especificação.
Modo Standalone
O modo Standalone é muito semelhante aos profiles default, all e minimal das versões anteriores. Ao utilizá-lo será iniciada apenas uma instância de AS 7 por script de inicialização (no caso, standalone.sh). Este modo pode pertencer a ambientes que necessitam de apenas uma instância do JBoss AS 7, ou em aplicações que não requeiram gerenciamento unificado.
Embora seja possível formar um cluster de alta disponibilidade utilizando várias instâncias em modo standalone, não será possível ter este ponto único de gerenciamento, portanto, a administração de cada nó é feita de forma isolada e repetitiva. O deploy de uma aplicação, por exemplo, deve ser feita em todos os nós do cluster.
No AS 7 os serviços são chamados de subsistemas, e no modo Standalone estes serviços estão configurados em um único arquivo denominado standalone.xml, localizado no diretório AS7_HOME/standalone/configuration. Desta forma, torna-se muito mais fácil qualquer tipo de manutenção ou configuração em qualquer um dos subsistemas. A Listagem 3 mostra a definição do subsistema de logging.
Diferente do esquema de configuração distribuída em vários arquivos, encontrado nas versões anteriores, standalone.xml (veja a Listagem 4) contém toda a configuração necessária para a inicialização do servidor: módulos, subsistemas, interfaces de gerenciamento, segurança, data sources, socket bindings, etc. Assim, quando quiser fazer qualquer tipo de alteração, basta olhar apenas este arquivo.
Modo Domain
Esta é sem dúvida umas das principais novidades do AS 7. A possibilidade de iniciar várias instâncias, bem como gerenciá-las de forma centralizada em um ponto único, traz benefícios notáveis para o administrador do Application Server.
Basicamente um domínio pode ser interpretado como uma unidade administrativa. Um conjunto de instâncias do servidor de aplicação que compartilham configurações comuns e que são coordenadas por um ponto central – o Domain Controller.
Em versões anteriores do JBoss AS, caso o administrador quisesse iniciar várias instâncias com exatamente as mesmas configurações, era necessário realizar cópias do diretório referente ao profile utilizado para cada instância. Por exemplo, caso fosse necessário iniciar três instâncias do profile default, era necessário copiar o diretório deste profile três vezes (default-1, default-2 e default-3) e iniciar três processos da JVM utilizando o script run.sh:
Também não era possível compartilhar e nem gerenciar as configurações das três instâncias de forma centralizada, dificultando a manutenção e criação de novas instâncias. Era preciso replicar a mesma configuração em vários pontos manualmente ou usando alguma ferramenta externa ao servidor de aplicação, como o RHQ ou sua versão Enterprise, chamada JBoss Operations Network (JON). Qualquer alteração feita em uma das instâncias teria que ser copiada para as outras, tornando a manutenção em grandes parques de servidores muito tediosa. É para lidar com esse tipo de situação que o modo Domain, implementado no AS 7, se aplica.
A melhor forma de compreender a estrutura lógica de um domínio é visualizar seus elementos como processos em execução. Estruturalmente, um domínio é composto por quatro elementos:
• Domain controller: é o ponto central de controle e mantém toda a política de gerenciamento do domínio. Ele hospeda a configuração do AS e a compartilha com todas as outras instâncias que fazem parte do mesmo domínio;
• Host controller: é responsável por coordenar, juntamente com o Domain Controller, todo o ciclo de vida (start/stop) das instâncias que fazem parte do domínio, além de executar o trabalho de distribuir os deploys em todas elas;
• Process controller: é responsável por criar as instâncias do servidor, inclusive a instância do host controller. É sua função também gerenciar os fluxos de entrada e saída das instâncias do servidor. O fato deste processo estar em uma JVM isolada permite que o host controller seja atualizado e, até mesmo, reiniciado sem impactar nas demais instâncias do domínio;
• Server nodes: são as instâncias propriamente ditas, onde as aplicações e serviços são implantadas. Cada server node terá seu próprio processo Java no sistema operacional.
Quando se inicia o AS em modo Domain no mínimo três processos Java (JVM) são criados no sistema operacional: um Host Controller (que também pode agir como Domain Controller no mesmo processo), um Process Controller e um Server Node. Relatamos no mínimo três porque dependendo da configuração definida o domínio pode possuir três ou mais processos executando em um mesmo host (físico ou virtual). A configuração padrão do modo Domain fornecida pelo AS 7 é composta pela topologia mostrada na Figura 9. Observe que nesta estrutura tanto o Host Controller quanto o Domain Controller executam em um mesmo processo Java.
Para habilitar o JSF e JPA
:pencil2: Clicar no projeto com o botão direito -> properties
:pencil2: Clicar em Project Facest -> Marcar JAVA SERVER FACES -> Clicar em Futher Configuration
:pencil2: Em TYPE, selecionar DISABLE LIBRARY CONFIGURATIONA.
Em URL MAPPING PATTERNS -> clicar em /FACES/* -> clicar em REMOVE
:pencil2: Clicar em ADD -> Digitar a URL: *.jsf -> clicar em OK
:pencil2: Clicar em OK
:pencil2: Clicar em APPLY
:pencil2: Clicar em JPA -> clicar em FUTHER CONFIGURATION
:pencil2: Em TYPE, selecionar DISABLE LIBRARY CONIGURATION -> clicar em OK
:pencil2: Clicar em APPLY AND CLOSE
:pencil2: Será gerado o diretório META-INF e será gerado o arquivo persistence.xml
Para colocar o Servidor JBOSS no worspace
:pencil2: Clicar no menu -> WINDOW -> PREFERENCES
:pencil2: Clicar em SERVER -> Clicar em RUNTIME ENVIRONMENTS -> clicar no botão ADD
:pencil2: Selecionar o RED HAT JBOSS MIDDLEWARE -> Clicar na versão 6.1 -> NEXT
:pencil2: Clicar em BROWSER -> selecionar o diretório onde se encontram os arquivos do JBOSS
:pencil2: Selecionar o diretório -> Clicar em OK
:pencil2: Em RUNTIME JRE, selecionar o JAVASE1.8 -> Clicar em FINISH
:pencil2: Selecionar APPLY AND CLOSE
Para adicionar o servidor para rodar
:pencil2: Clicar na aba SERVER -> Clicar no link para adicionar
:pencil2: Selecionar RED HAT JBOSS MIDDLEWARE -> Clicar na versão 6.1 -> clicar em NEXT
:pencil2: Clicar em NEXT
:pencil2: Clicar em FINISH
:pencil2: Clicar no JBOSS com o botão direito -> cliar em START
:pencil2: Aguardar iniciar. Projeto inciado
Para abrir o administrador do JBOSS
:pencil2: Digitar a URL: localhost:9990
Usuario: coti
Senha: coti@110
:pencil2: Na pagina principal
:pencil2: Clicar na aba DEPLOYMENTS
:pencil2: Clicar em ADD para adicionar o banco de dados
:pencil2: Escolher o driver do mysql 5.1.6
:pencil2: Clicar em NEXT
:pencil2: Clicar em ENABLE
:pencil2: Clicar na aba CONFIGURATION
:pencil2: Adicionar a conexão com o banco do projeto. Clicar em ADD
:pencil2: Digitar os dados de conexão.
Name: UPfolia
JNDI: java:/folia
Clicar em NEXT
:pencil2: Clicar no conector do MYSQL -> Clicar em NEXT
:pencil2: Digitar as informações -> clicar em TEST CONECTION
:pencil2: Conexão ok
:pencil2: Clicar em DONE
:pencil2: Clicar em ENABLE para habilitar a conexão
:pencil2: Clicar em CONFIRM
:pencil2: Conexão habilitada
PARA ADICIONAR O PROJETO AO SERVIDOR:
:pencil2: Clicar no servidor com o botão direito -> clicar em ADD AND REMOVE
:pencil2: Clicar no projeto -> Clicar em ADD -> Clicar em FINISH
:pencil2: Aguardar iniciar automaticamente. Projeto inciado
:pencil2: Ir no administrador do JBOSS no browser -> clicar na aba DEPLYMENTS.
O projeto já está lá pronto
Para rodar o projeto:
:pencil2: Clicar na pagina sistema.xhtml -> run on server
:pencil2: Selecionar o servidor Jboss-> FINISH
Apostila 2 - https://hackmd.io/@lucianamedeiros/rkh-U3doA
