Dê o próximo passo e inicie sua carreira
Dê o próximo passo e inicie sua carreira agora mesmo
5 minutos de leitura
Autor(a)
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Parece que a nova buzzword é realmente Microservices. A definição do Adam Bien parece perfeita: é um serviço que tem máxima coesão e mínimo acoplamento. A palavra principal parece ser decomposição. Um serviço para tratar REST, outro para WSDL, JMS, JPA e assim por diante, ganhando assim uma melhor escalabilidade, manutenibilidade e tornando os serviços mais fáceis de serem gerenciados e atualizados. Relacionei serviços com especificações, mas obviamente pode ser algo referente ao seu domínio: pagamento, estoque, vendas, geração de e-books, autenticação, notificação, usuários, dentre outros.
Já discutimos sobre a diferença arquitetural entre microservices e serviços monolíticos. Martin Fowler também já resumiu os pré-requisitos para uma arquitetura microservice: monitoração (prometheus, icinga, pagerduty), provisionamento (mesos, aurora, kubernetes) e deploy (travis, jenkins, docker) . Além disso, o Philip Calçado contou a saga da migração de um sistema monolítico para microservices no SoundClound e mostrou o porquê do mercado se interessar tanto por esse "novo" estilo arquitetural.
As much as I keep repeating that the term microservices doesn’t mean much, the one thing you can be sure when somebody uses this word to describe their architecture is that there will be a lot of services.
De 2014 até o presente momento, o termo cresceu exponencialmente em pesquisas no google. Por quê? Porque desenvolvedor prefere trabalhar com unidades menores, commits menores e a probabilidade de gerar um bug será menor em um sistema menor. E a desvantagem? Bom, agora não existe apenas um sistema, é um ecossistema de aplicações que devem ser devidamente orquestradas. (Eu particularmente ando me perdendo bastante na quantidade de terminais abertos com repositórios gits e branches diferentes por projeto que tenho que lidar)
Então você optou por fazer uma arquitetura baseada em microservices, contudo, onde deployar? Em um application server JavaEE? Tomcat? Mas será mesmo que um war é necessário?
Bom, vou mostrar o que de interessante está acontecendo com as implementações no mundo Java relacionadas a esse tema. Busquei no mercado algumas opções para tentar avaliar vantagens e desvantagens, mas no geral todas são bem parecidas. São elas: SparkJava, SpringBoot, Vertx.IO e por fim o KulumuzEE.
Darei uma atenção especial a esse último pois aqui já entra um diferencial dele. Dentre os frameworks de mercado que estudei, ele é o primeiro voltado para o uso da API JavaEE. Portanto, implementamos nosso serviço em um container microservice utilizando especificações já conhecidas como JAX-RS, JPA, CDI. Além disso, ele foi o vencedor do Duke's Choice Award 2015. Há outros também, como por exemplo o Swarm e o RESTlet.
Não há muita dificuldade em fazer o HelloWorld dos frameworks, todos eles têm um exemplo na página do produto, além de serem mavenizados. Fiquei um pouco mais perdido na documentação do Vertx.IO, mas eles têm um GitHub com exemplos que ajuda bastante.
Muita gente boa já fez artigo sobre esses caras, então a intenção aqui é apresentar uma visão geral sobre cada um e o código está no meu GitHub. A ideia básica da maioria dos frameworks é ter uma classe com um main e conseguir executá-la. A partir daí, temos um servidor e uma aplicação "deployada".
O kumuluz possui uma documentação muito bem detalhada, trazendo diversos exemplos das API's, das quais irei focar em CDI, JPA e JAX-RS. A execução do Kumuluz é um pouco diferente dos outros pois temos que fazer o clean install da aplicação mavenizada e subir a aplicação por linha de comando
java -cp target/classes:target/dependency/\* com.kumuluz.ee.EeApplication
Tive uma dificuldade inicial em configurar o pom com as versões adequadas. No nosso projeto, como ele não gera um WAR ao final, as páginas HTML ficam dentro do src/main/resources/webapp. De resto, é tudo igual a uma aplicação JavaEE convencional, persistence.xml e beans.xml dentro do META-INF e pronto, temos a configuração base da aplicação.No meu código de exemplo usei o H2 como banco para facilitar os testes.
Dividi o projeto em três pacotes para facilitar o aprendizado: servlet, rest e jpa. Siga as instruções
Incrível não? Não tenho mais o que ensinar pois ele usa as principais especificações do JavaEE, facilitando muito o aprendizado. Ele não tem suporte ainda para EJB's, mas você pode usar o deltaspike para fazer alguns controles, como o transacional por exemplo.
Falarei mais sobre os outros em próximos posts...
Esses dias no trabalho fui surpreendido com a possibilidade do PostgreSQL expor os dados via REST. Isso deu um nó enorme na minha cabeça pensando se fazia sentido ou não (WTF, cadê meu JPA?). Há outros questionamentos também, estamos entrando em um mundo no qual o EAR já deixou de ser necessário e talvez agora o WAR. Diante disso, a tendência é que os applications servers mais robustos passem a ter sua utilização repensada também. O lema que muitos apontam "One JAR to rule them all" pode ser a nova "buzzphrase". Aguardem os próximos!!
Para usuários Windows, seguir este link para subir o projeto.
Avalie este artigo
