O que é o Eclipse MicroProfile?

Algumas (ótimas) mudanças estão acontecendo com o Java EE e é obrigação desse blog informar.

Para começar o Java EE agora vai ser "tocado" pela Eclipse Foundation, a Oracle não é mais quem toca a especificação, mas faz parte das empresas que ajudam a criar as JSRs .

Foi também criado o Eclipse MicroProfile, que é uma versão micro do java EE com mais algumas specs. Esse conjunto de APIs também é atualizado muito mais rápido do que o Java EE. Nesse momento o Eclipse MicroProfile está na versão 1.2, na sexta (dia 15/12) ele já estará na versão 1.3! Para entender como anda rápido, veja que a média de commits no projeto da especificação é aproximadamento 100 por mês, e essa é a média, chegando a mais de 200 em meses mais movimentados.

Número de commits nos últimos 12 meses

O MicroProfile é uma maravilha, pois é focado em MicroServices e contém um conjunto reduzido de APIs. O mais bacana: já temos empresas criando implementações e contribuindo, ou seja, você já pode usar com o seu vendor favorito.

Empresas que contribuiram com o projeto nos últimos 3 meses 

Quais APIs são parte do Microprofile

Atualmente o Eclipse MicroProfile está na versão 1.2 e em breve deve sair a versão 1.3, mas já há planos para a versão 2.0. Veja abaixo as APIs que farão parte de cada versão (há também um post em inglês bem detalhado, de onde peguei as imagens):

Acima vocês verão alguns nomes bem conhecidos que já abordamos aqui, como CDI, JAX-RS, JSON-P e JSON-B. As outras iremos abordar aos poucos por aqui.

Como crio projetos baseado nas APIs do Eclipse MicroProfile?

Cada instituição que decide implementar o MicroProfile terá sua forma, mas presumo que todos serão baseados em Maven. Nesse blog, no entanto, utilizamos os projetos da JBoss, principalmente o Wildfly Swarm.

Lembram quando fizemos um CRUD em 7 passos usando o Wildfly Swarm? Pois bem, você pode gerar um projeto usando o mesmo swarm para criar um projeto microprofile usando o generator.

Vamos parar por aqui, mas em breve teremos mais postagens com pequenos exemplos utilizando o Eclipse MicroProfile com o Wildfly Swarm. Até mais, pessoal!

O que são EJBs e como usá-los no Wildfly?

Java há muito tempo traz o conceito de beans, que  são classes serializaveis com atributos privados e métodos get e set para acesso a eles além de um construtor sem argumentos.

EJB, Enterprise Java Bean, é conceito do mundo JavaEE que categoriza certos tipos de classes gerenciadas pelo contâiner, terceirizando algumas tarefas "corriqueiras" e cotidianos do programador de aplicações "enterprise", tais como o ciclo de vida dos beans, transações de banco de dados, escalabilidade, segurança, etc. Assim, podemos focar no EJB em nossa lógica de negócio invés de "perder tempo" com outras particularidades.

 A vida do EJB depende do container(o wildfly, o tomee e outros), o container sabe a hora de criar e parar um EJB, podemos dar instruções para o container para executar alguns métodos, mas é o container quem manda. E é melhor assim, pois podemos fazer caquinhas - grandes poderes trazem grandes responsabilidades.

Nesse artigo vamos falar brevemente de EJBs e seus tipos, focando principalmente no tipo "Stateless", que já foram amplamente divulgados em outros posts. Vamos também nos basear na versão EJB 3.1, que é parte do JavaEE 6.

Não dá pra falar tudo, né pessoal, afinal, saiba que o livro mais famos sobre EJBs tem 560 fucking pages.

Livro sobre EJB com mais de 500 páginas.

Tipos de EJBs

 

Nossos "beans corporativos" são categorizados basicamente em session beans e message-driven beans.

• Os message-drive beans são para trabalhar com sistema de "mensagerias", onde podemos trocar mensagens para fazer uma comunicação assíncrona entre sistemas;
• Session beans são aqueles cujo ciclo de vida dos objetos(o período no qual o objetos são instanciados e então inutilizados) dependem de uma sessão HTTP ou não.

Os session beans são subdividos da seguinte forma:

* Stateless: Não mantém estado nenhum e são usados quando uma requisição chega ao servidor. Esses tipos de Bean podem ficar em um "pool" com outros beans, ou seja, ficam armazenados juntos e prontos para uso. Notem que esse pool é configurável. Quando uma requisição chega, o servidor pega um bean do pool e usa ele, no final da requisição, o servidor coloca ele novamente no pool para uso em futuras requisições. Por esse motivo ele não deve guardar estado, pois ele não deve estar atrelado a nenhuma requisição;
* Stateful: Os beans to tipo stateful mantém estado. Ou seja, ele pode ficar mantendo informações de diversas requisições até que ele não é mais útil. Um exemplo clássico e prático de uso é carrinho de compras, onde o bean é mantido até você completar o carrinho ou cancelar ele. Mas não vamos focar nele, não vou falar dele nesse blog uma vez que esse tipo de EJB já não é tão famoso nos tipos de sistemas que vamos falar por aqui (no geral sem estado);
* Singleton: Esse é o mais simples de entender, pois um bean singleton só é instanciado uma vez e mantido até que você pare o servidor de aplicação(ou faça o undeploy de sua app), temos sempre uma instância do mesmo. Vamos fazer um exemplo de uso dele aqui, mas lembre que um recurso desse deve ser usado com precausão, pois Singletons são famosos por quase serem um "antipattern"(na verdade são considerados assim por muitos programadores) da programação orientada a objetos.

Exemplos práticos e testes

EJB Stateless

Como falei anteriormente, nosso foco maior é nos EJBs do tipo Stateless. Nesse blog não iremos mostrar aplicações que usem conceitos de manter estado no servidor, afinal quem vos escreve é um RESTfarian que abomina as práticas stateful, pois está em levíticos.

Um class simples dentro de uma aplicação do tipo WAR no Wildfly e com a anotação @javax.ejb.Stateless já é um EJB!

Vamos começar com um exemplo onde um EJB é também um recurso REST(observe as anotações JAX-RS). Esse EJB tem um método que retorna o toString padrão do objeto e também imprime no console:

Veja o resultado abaixo de 5 requisições disparadas e notem que a cada requisição temos um novo toString retornado, isso, de certa forma, indica que novos EJBs estão sendo usados a cada requisição.

org.aprendendojee.ejb.EJBSemEstado@485f82c7
org.aprendendojee.ejb.EJBSemEstado@5b5158
org.aprendendojee.ejb.EJBSemEstado@27c9659e
org.aprendendojee.ejb.EJBSemEstado@5d682c5b
org.aprendendojee.ejb.EJBSemEstado@2f1bf3db

Notem que interessante, nessa versão do Wildfly não temos pool de EJBs  e isso foi discutido no fórum do Wildfly. Há casos (ou de acordo com a configuração) em que os EJBs podem ficar em um pool, onde eles são recuperados do pool para reuso. Não vamos focar nisso aqui, talvez um dia no blog Aprendendo JBoss!


EJB Singleton


Vamos fazer o seguinte agora: vamos transformar nosso EJB em um Singleton e vamos fazer diversas requisiões e também retornar o toString, vejam que o mesmo valor é sempre retornado. Notem que para ser um EJB singleton, nós anotamos nosso Web Service JAX-RS com javax.ejb.Singleton.

Com 5 requisições para o método vai, vejam que legal, o EJB retorna sempre o mesmo toString!

org.aprendendojee.ejb.EJBSingleton@73aa1d06 
org.aprendendojee.ejb.EJBSingleton@73aa1d06 
org.aprendendojee.ejb.EJBSingleton@73aa1d06 
org.aprendendojee.ejb.EJBSingleton@73aa1d06 
org.aprendendojee.ejb.EJBSingleton@73aa1d06 

Já o método dominhoco responde de forma diferente: quando esse método receber a requisição e durante esse tempo fizermos uma nova requisição notem que cada requisição espera o retorno da outra! Afinal, como executar em paralelo se só temos uma instância do objeto, né

19:55:08,584 INFO  [stdout] (default task-43) Eu sou org.aprendendojee.ejb.EJBSingleton@7efdc496 e dorminhoco...
19:55:09,597 INFO  [stdout] (default task-44) Eu sou org.aprendendojee.ejb.EJBSingleton@7efdc496 e dorminhoco...
19:55:10,610 INFO  [stdout] (default task-45) Eu sou org.aprendendojee.ejb.EJBSingleton@7efdc496 e dorminhoco...
19:55:11,620 INFO  [stdout] (default task-46) Eu sou org.aprendendojee.ejb.EJBSingleton@7efdc496 e dorminhoco...
19:55:12,632 INFO  [stdout] (default task-47) Eu sou org.aprendendojee.ejb.EJBSingleton@7efdc496 e dorminhoco...
19:55:13,644 INFO  [stdout] (default task-48) Eu sou org.aprendendojee.ejb.EJBSingleton@7efdc496 e dorminhoco...

Agora imaginem o Thread.sleep como uma operação da vida real, como ir ao banco de dados... Estão percebendo o problema de se usar Singleton? Esse é, na verdade, só um problema.

EJBs: Do Wildfly para o mundo

Não dá pra ignorar que um monte de coisa estranha sai no log quando subimos nossa aplicação com EJB. O que são esses textos? Por exemplo, para os dois EJBs acima temos a seguinte saída:

JNDI bindings for session bean named EJBSingleton in deployment unit deployment "brincando-com-ejbs.war" are as follows:

java:global/brincando-com-ejbs/EJBSingleton!org.aprendendojee.ejb.EJBSingleton
java:app/brincando-com-ejbs/EJBSingleton!org.aprendendojee.ejb.EJBSingleton
java:module/EJBSingleton!org.aprendendojee.ejb.EJBSingleton
java:global/brincando-com-ejbs/EJBSingleton
java:app/brincando-com-ejbs/EJBSingleton
java:module/EJBSingleton

JNDI bindings for session bean named EJBSemEstado in deployment unit deployment "brincando-com-ejbs.war" are as follows:

java:global/brincando-com-ejbs/EJBSemEstado!org.aprendendojee.ejb.EJBSemEstado
java:app/brincando-com-ejbs/EJBSemEstado!org.aprendendojee.ejb.EJBSemEstado
java:module/EJBSemEstado!org.aprendendojee.ejb.EJBSemEstado
java:global/brincando-com-ejbs/EJBSemEstado
java:app/brincando-com-ejbs/EJBSemEstado
java:module/EJBSemEstado
Bem essas saídas indicam diversos nomes JNDI para acessar o EJB fazendo lookup. Você pode fazer o lookup:

* Dentro da própria aplicação
* De outras aplicações também instaladas no Wildfly
* De uma aplicação Java standalone acessando o EJB remotamente
* E até de aplicações feitas em outras plataformas! (usando coisas como IIOP)

Há vários JNDIs pois alguns seguem o padrão Java EE de JNDI, outros são específicos do Wildfly e uns nomes podem ser para uso do EJB somente de forma remota. Ok, mas não vamos a fundo nisso hoje. É importante saber que existe!

Notem que realizar um lookup é uma maneira de usar os EJBs, mas comumente usamos CDI ou a anotação javax.ejb.EJB. 

Mais sobre EJBs

Quem já conhece sabe que omitimos muitas, muitas coisas aqui! Esse mundo é gigante. Por exemplo,já falamos que o livro mais recente da série EJB 3 in Action tem mais de 500 páginas! Vamos com certeza voltar no tema para falar de anotações específicas e outros exemplos, mas por hoje é só!

>> Nosso código está on github <<

Mini Curso Java EE 7 com AngularJS no cliente

Essa semana tive o prazer de transmitir um pouquinho sobre Java EE para alguns alunos da FATEC de São José dos Campos. Apesar de diversos desafios com relação principalmente ao Windows, os alunos tiveram sucesso na criação da ideia básica de uma  aplicação Java EE.

Como sabemos, Java EE é imenso, mas conseguimos no mini curso falar do básico sobre o Wildfly e Maven (conforme já abordamos aqui no blog) e exploramos JPA, falamos de EJBs, JAX-RS e CDI.

Para a primeira aula eu fiz um pequeno PDF com resumo do curso em si, subimos quickstarts e o jboss. No segundo dia falamos mais sobre os quickstarts e configuramos o ambiente e desenvolvemos um pouquinho. Já o terceiro dia foi bastante focado em código e na discussão de como o cliente Javascript se liga com a view.
Coloquei a aplicação no github, mas a mesma é um pouco mais elaborada e também adicionei AngularJS.

Veja a apresentação do primeiro dia:

Mini Curso Java EE de jesuinoPower

O código está no github e pronto para ser instalado no JBoss. A aplicação é simplesmente um gerenciador de cursos que permite a inscrição de alunos e um CRUD de cursos. As informação de alunos devem ser inseridas diretamente no banco de dados e só o usuário administrador poderá inscrever alunos nos cursos e apagar ou criar cursos. Para criar o usuário administrador de cursos, você deve seguir o que está na imagem abaixo no script do Wildfly bin/add-user.sh:

Para entender a segurança, vejam os arquivos jboss-web.xml e web.xml.

Na view do sistema usamos AngularJS para que se tenha uma ideia básica do uso - mas é complicado ficar falando de frontend quando o objetivo é abordar o servidor. Por isso nossa página ficou feiosa assim:

EM BREVE PRINT - EM DESENVOLVIMENTO

O sistema está com diversos pontos de melhorias. Cito alguns:

* A injeção das classes de Service poderia ser melhorada
* O sistema poderia ter mais segurança e área do aluno
* A camada REST assume sempre que nada de errado vai acontecer, poderia ter respostas mais elaboradas
* Faltam testes automatizados com Arquillian
* Muitas outras pequenas coisas

No entanto, não era o objetivo criar um "sistemão", mas sim falar do que há de mais usado no mundo Java EE e mesmo assim não cobrimos nem metade!

Convertendo objetos Java para JSON usando JSON-P

Falamos aqui na outra postagem sobre JAXB, a biblioteca padrão do Java para conversão de objetos para XML e vice versa. Hoje vamos falar sobre a conversão para JSON(um formato de dados famoso) usando JSON Processing.

Para um exemplo sobre uso de JSON com Android, veja esse artigo

API padrão do Java para JSON

O Java, por muitos anos, não tinha um padrão para a conversão de JSON, isso mudou com a JSR 353, que nos trouxe o JSON-P (JSON Processing).
Nessa especificação temos uma nova API para realizar transformação de JSON que é baseada em manipular a estrutura do JSON usando Java. Ou seja, não é uma API de binding, como mostrados para XML(onde podemos fazer a correspondência de um objeto Java para JSON ! Para isso temos a JSON-B(JSON binding), que ainda está em discussão e fará parte do Java EE 8, por enquanto podemos usar a API Jackson.

A API JSON Processing

Para utilizarmos JSON-P, temos que conhecer algumas classes importantes. Veja a tabela traduzida dessa página:

Principais classes e interfaces do pacote javax.json

Classe ou Interface	Descrição
Json	Contém métodos especifícicos para criar instâncias de parsers JSON, builders e fábricas para criar objetos.
JsonReader	Lê JSON de um Stream e cria objetos de modelo em memória. (objetos de modelo que representam o JSON)
JsonObjectBuilder JsonArrayBuilder	Cria um modelo de objeto ou um modelo de array na memória adicionando elementos da aplicação.
JsonWriter	Escreve um objeto da memória para um Stream.
JsonValue	Representa um elemento (como um objeto, um array ou um valor) em dados no formato JSON.
JsonStructure	Representa um objeto ou um array no formato JSON. É um subtipo do JsonValue.
JsonObject JsonArray	Representa um objeto ou um array no tipo JSON.Essas interfaces são subtipos de JsonStructure.
JsonString JsonNumber	Representam tipos de dados em JSON. Essas interfaces são subtipos de  JsonValue.
JsonException	Indicate que houve um error no processamento do JSON.

Principais classes e interfaces do pacto javax.json.stream

Classe ou interface	Descrição
JsonParser	Representa um parser baseado em JSON que pode ler dados JSON de um Stream ou de um objeto de modelo.
JsonGenerator	Escreve JSON para um Stream, um elemento por vez.

Se você leu ali em cima,vamos ao código para "digerir" a informação.

Uma aplicação de exemplo

Vamos utilizar o mesmo objeto do post passado, o Artigo. Como iremos usar maven, precisamos adicionar a API e a implementação. Abaixo você pode ver o código Java e o JSON usado. O método javaParaJson gera o JSON a partir de uma lista de artigos e o mesmo JSON gerado será lido no métódo jsonParaJava devidamente comentados.

Conclusão

Apresentamos JSON-P e falamos da conversão JSON para Java e vice versa. Embora Java ainda não tenha uma forma nativa de lidar com JSON, a API JSON-P é simples de ser usada e a nova API JSON-B promete a mesma facilidade do JAXB para JSON.

O projeto maven usado nessa postagem está on github!

O básico sobre segurança em aplicações WEB Java usando JAAS

Como vocês já perceberam em postagens anteriores, o servlet é uma classe java que responde a requisições. O HttpServlet responde a requisições HTTP.
Servlets não tem um main, isso por que instalamos os mesmos em um servidor Java WEB(um contêiner) e ele invoca os métodos do Servlet pra gente. Mais do que isso! O conteiner controla o ciclo de vida e faz o tratamento das requisições HTTP, transformando elas em objetos Java que você pode usar em seu código.
Uma das maiores vantagens de delegarmos as coisas para o contêiner é programar menos e deixar ele fazer as coisas para a gente. Por exemplo, injeção de dependência, controle de transação e segurança podem ser delegadas para o contêiner sendo que você pode focar no seu código Java. Outro ponto é a flexibilidade da sua aplicação, podemos configurar as coisas no contêiner invés de termos que modificar o código da app.
Nesse artigo vamos mostrar como delegar a tarefa de login para o Wildfly em poucos passos, não iremos mostrar a fundo diversas coisas, mas futuramente voltaremos a esse tópico.

Nosso "alvo"

Lembra do "Olá Mundo com Servlet"? Criamos uma versão com segurança onde um acesso ao servlet irá requerer autenticação. Vamos ser bem diretos no assunto, então é interessante que você tenha o Ola Servlet na sua máquina e todas as configurações feitas para executar o mesmo. Se tiver dúvidas, volte à postagem anterior.

Na nossa aplicação a execução do Olá Mundo só será possível se o usuário fornecer credenciais corretas.

Adicionando segurança à aplicação

1) Use web.xml para declarar a segurança que quer na sua aplicação. Nessa etapa falamos os contextos que irão sofrer segurança e o tipo de segurança aplicada(como autenticação BASIC);
2) Declare o security domain usado nesse aplicação usando o jboss-web.xml, um arquivo que deve ficar no diretório WEB-INF do seu WAR. Vejam abaixo o conteúdo dos arquivos web.xml e jboss-web.xml:

As modificações na nossa aplicação são só essas. Veja que a aplicação não sabe se as credenciais de segurança virão de um banco de dados, LDAP, arquivo de texto, etc. De fato, essa é a ideia: delegar a segurança para o servidor de aplicação. No nosso caso estamos usando um pronto que traz os dados de usuários e roles de arquivos gerenciados pelo Wilfly, o other. Vamos falar agora como poderíamos utilizar outras formas de autenticação no Widlfly 8.2.

3) Um outro passo seria alterar o arquivo standalone.xml do Wildfly para declarar como será feito a segurança; Esse arquivo fica em {INSTALAÇÃO WILDFLY}/standalone/configuration

A segurança pode ser feita através dos login modules. E nessa postagem usamos o security domain other, os que irão buscar as credenciais e irão checar roles em um arquivo de texto! Poderíamos utilizar outros Login Modules para acessar banco de dados, LDAP, etc, veja os login modules disponíveis.

Usando o other (que na verdade é o security domain padrão), temos que adicionar usuários com o script add-user.sh(ou bat para os usuários do outro sistema) que fica em {INSTALAÇÃO WILDFLY}/bin. Veja abaixo como é feito esse processo de adicionar usuário com esse script no ApplicationRealm (que é o que devemos usar no nosso caso):

Após fazer isso, só podemos executar o servlet passando dados de usuário que configuramos com esse script, ou não estaremos autorizados. Lembrando que o other foi usado para teste, você pode configurar um security domain que poderá auxiliar você trazendo roles e usuários de um LDAP, banco de dados, etc...

Se você tiver a nossa aplicação de olá mundo e modificar ela seguindo os passos aqui, ao acessar a mesma você terá que entrar com usuário e senha que você adicionou usando o add-user.

Conclusão

Mostramos o básico sobre segurança de aplicações WEB no Wildfly e não abordamos autorização, só autenticação. Há, obviamente, muito a ser aprendido e muitos detalhes e dúvidas que irão surgir no momento que você for criar a sua aplicação, por esse motivo voltaremos a esse tópico futuramente!

Interagindo com repositórios usando JGIT e a aplicação Ciclovias SP

Essa é uma postagem super rápida para falar de uma ferramenta extraordinária que tive a oportunidade de trabalhar nessa semana, o JGit. Vamos também descrever brevemente a aplicação Ciclovias SP, criada com programadores do projeto Transparência SJC (ou Dados Abertos SJC).

O projeto transparência SJC reúne programadores da cidade de São José dos Campos em São Paulo que se interessam em explorar dados abertos

Sobre GIT

Criado pelo Linus Torvalds (sim, o criado do Linux) para uso de controle de código do Kernel do Linux, o GIT é atualmente muito popular por causa da rede social para programadores Github. 

Além de controlar versão de código, as pessoas costumar usar essa ferramenta espetacular para controlar repositórios em geral. Um grande exemplo são os projetos Kie da JBoss que usa git para armazenar e controlar versão dos arquivos relacionados a cada projeto (processos comerciais, regras, entre outros).

GIT a partir do seu código Java com JGIT

Basicamente GIT vai funcionar como um utilitário de linha de comando ou você pode usar a API HTTP do Github. JGit expande as possibilidades de uso trazendo para o código Java uma API completa para lidar com repositórios GIT. Não vou me estender nesse assunto, exemplos de código podem ser encontrados no cookbook(livro de receitas) do JGit que fica no Github (INCEPTION!).

Uso da API

Como mencionei no início dessa postagem, eu usei essa API e chorei de emoção achei muito útil. No meu caso eu a uso para o rápido projeto Ciclovias SP. Nele eu preciso pegar os dados das câmeras de ciclovias de São Paulo que usa reconhecimento de bicicletas passando na ciclovia. Esses dados ficam no github da LabProdam, uma iniciativa da prefeitura de São Paulo de fazer a cidade mais aberta (nada técnico aqui, mas temos que admitir que essa gestão está sendo espetacular para a cidade, quem acompanha sabe).Veja a câmera da ciclovia da famosa Faria Lima (em breve teremos também na Paulista):

O objetivo da aplicação é pegar esses dados todos os dias do github usando um EJB Timer, manter um "track" de arquivos que eu já li e carregar os novos (o gitihub com os dados é atualizado todo dia meia-noite e o EJB Timer é executado todo dia 1 da manhã)  e salvar no banco de dados H2 (padrão do Wildfly) usando JPA sempre. Em seguida eu tenho uma interface REST usando JAX-RS que "cospe" os dados em um formato interessante para mostrar um gráfico e MAGIC, tenho o gráfico em uma aplicação com os famigerados frameworks clientes (que consomem esse WS REST) bootstrap, angularjs e highcharts:

O código que usa o JGit em sí é muito simples. Eu simplesmente clono o repositório remote em um diretório local se não existir o mesmo, se existir eu faço um pull request e um fetch dos dados novos. Veja os códigos relevantes:

Código no GIST:

Conclusão

É muito simples lidar com repositórios GIT em uma aplicação Java usando o JGit.

O código completo de nossa aplicação está no github, sinta-se a vontade para contributir.