Vivemos em um mundo onde muito se fala em arquitetura de microsserviços e de fato, tem se mostrado uma solução muito rica de computação distribuída. A adoção vem crescendo cada vez mais e com isso vem se observando no mercado alguns padrões para construir esse tipo de arquitetura.

E dessa forma um grupo de empresas e grupos de usuários foram aos poucos iniciando a discussão sobre essas boas práticas e sobre ferramentas até que em 2016 nasce o projeto MicroProfile e logo ganha um lugar dentro da Eclipse Foundation sendo assim: Eclipse MicroProfile.

Lista de participantes na construção e manutenção do projeto:

• IBM
• Microsoft
• Red Hat
• Tomitribe
• SouJava(Sociedade de Usuários Java)
• LJC(London Java Community)
• Payara
• Hazelcast
• Fujitsu
• KumuluzEE
• Hammock
• Oracle
• Lightbend
• Eclipse Foundation

Grande a lista não? E claro, é um projeto open source, sinta-se livre para contribuir, existem diversas maneiras que estão descritas aqui.

Bem, mas e ai, como funciona?

O projeto MicroProfile é a junção de 12 especificações e mais 4 projetos fora do guarda-chuva que juntos garantem o desenvolvimento de microsserviços resilientes e manuteníveis. Vamos entender melhor:

Open Tracing 1.3

• Não sofreu alterações do MicroProfile 3.2 para o 3.3
• O tracing distribuído ou rastreamento distribuído, é uma técnica que permite rastrear o fluxo das requisições entre os serviços e dentro de um ambiente de microsserviços isso é extremamente útil para que você consiga desenhar todo o caminho da requisição e com isso fazer diversos tipos de análises, resolução de problemas e etc…

Open API 1.1

• Não sofreu alterações do MicroProfile 3.2 para o 3.3
• A exposição de APIs é sem dúvida uma das coisas mais importantes no desenvolvimento de qualquer aplicação moderna e para construção das APIs hoje temos as famosas RESTful APIs, que por definição podem transformar qualquer tipo de aplicação em serviços independentes.
• E para tornar esse serviço conectável, é necessário que haja um contrato semelhante ao que representa o WSDL para WebServices mais antigos. A especificação Open API é um conjunto de interfaces e modelos para construção de contratos a partir de um serviço RESTful.

Rest Client 1.4

• Sofreu alterações do MicroProfile 3.2 para o 3.3 que podem ser visualizadas aqui.
• A especificação Rest Client fornece uma abordagem type-safe para chamada de serviços RESTful via HTTP e é fortemente apoiada nas APIs JAX-RS 2.0 para garantir consistência e também reusabilidade.

Config 1.4

• Sofreu alterações do MicroProfile 3.2 para o 3.3 que podem ser visualizadas aqui.
• Na maioria das aplicações do mundo atual, é necessário que as configurações sejam armazenadas e aplicadas de acordo com um ambiente específico(Produção, Homologação e etc). A especificação Config permite essa flexibilidade e a proteção dos dados de configuração.

Fault Tolerance 2.1

• Sofreu alterações do MicroProfile 3.2 para o 3.3 que podem ser visualizadas aqui.
• Uma necessidade de qualquer aplicação é a de manter algum nível de resiliência e uma das maneiras de garantir isso é com alguma estratégia de tolerância a falhas. Que basicamente consiste em levantar alguma estratégia para orientar o fluxo de execução do serviço em caso de queda por exemplo políticas de retry, circuit breakers e etc…

Metrics 2.3

• Sofreu alterações do MicroProfile 3.2 para o 3.3 que podem ser visualizadas aqui.
• As métricas são dados coletados dos seus serviços que te permitem avaliar diversas coisas, como por exemplo volume de tráfego das APIs, saúde e etc. A especificação Metrics provê uma maneira unificada para os servidores de MicroProfile exportarem e também exporem dados de monitoramento.

JWT Propagation 1.1

• Não sofreu alterações do MicroProfile 3.2 para o 3.3
• Geralmente para fazer a segurança das APIs RESTful, é normal se utilizar os padrões OpenIS Connect(OICD), OAuth2 ou JSON Web Token(JWT). Esta especificação descreve como os tokens JWT assinados e emitidos pelo OICD e outros fornecedores confiáveis podem ser verificados e suas reivindicações usadas para controle de acesso baseado em função (RBAC) de endpoints de microsserviços.

Health 2.2

• Sofreu alterações do MicroProfile 3.2 para o 3.3 que podem ser visualizadas aqui.
• Health checks são importantes para garantir a resiliência analisando a saúde dos serviços por exemplo verificando se dentro do cluster existe alguma unidade de computação, ou nó prejudicado e assim poder substituir por outro que esteja com a saúdemelhor. Essa especificação provê APIs para realizar esse tipo de verificação.

CDI 2.0

• Não sofreu alterações do MicroProfile 3.2 para o 3.3.
• CDI(Context and Dependency Injection) é sem dúvidas uma das especificações mais poderosas do ecossistema Java. Basicamente nos permite gerenciar o ciclo de vida dos componentes com estado através de contextos de ciclo de vida do domínio e também permite injetar componentes nos objetos cliente de maneira segura.

JSON-P 1.1

• Não sofreu alterações do MicroProfile 3.2 para o 3.3
• JSON-P(Java API for JSON Processing 1.1) é a especificação para processamento de JSON que é uma maneira bem comum de se transmitir dados entre RESTful APIs e por conta disso aparece no guarda-chuva do MicroProfile.

JAX-RS 2.1

• Não sofreu alterações do MicroProfile 3.2 para o 3.3
• JAX-RS(Java API for RESTful Web Services) é a especificação para serviços REST e de suma importância para qualquer aplicação seja web ou até mesmo microsserviços, pois ela provê uma série de APIs para a construção desses serviços e por conta disso também foi aproveitada no MicroProfile.

JSON-B 1.0

• Não sofreu mudanças do MicroProfile 3.2 para o 3.3
• JSON-B(Java API for JSON Binding) é a especificação responsável pela conversão de objetos Java para JSON e vice-versa, de extrema importầncia para a transmissão de dados e complementa as citadas anteriormente JAX-RS e JSON-P.

Especificações fora do guarda-chuva

GraphQL 1.0

• GraphQL é a novidade que entrou no MicroProfile 3.3 e não existia na versão anterior(3.2)
• O GraphQL é uma linguagem de manipulação e consulta de dados open-source para APIs em tempo de execução para atender a consultas com dados existentes. Ele fornece uma alternativa, embora não necessariamente uma substituição para o REST. O GraphQL foi desenvolvido internamente pelo Facebook em 2012, antes de ser lançado publicamente em 2015.

Context Propagation 1.0

• Não sofreu alterações do MicroProfile 3.2 para o 3.3
• Essa especificação possibilita que a propagação de contexto de threads seja feita com facilidade e de forma segura, mantendo um boilerplate mínimo e permitindo que a propagação seja feita automaticamente ao usar um CompletableFuture(uma feature muito interessante pensando em programação assíncrona que chegou no Java 8).

Reactive Streams Operators 1.0

• Não sofreu alterações do MicroProfile 3.2 para o 3.3
• O Reactive Streams é um SPI de integração e permite que duas bibliotecas diferentes que fornecem streaming assíncrono possam transmitir dados entre si. É importante mencionar que o Reactive Streams não foi projetado para ser usado de maneira direta pelos desenvolvedores. A semântica definida é muito rigorosa e não é trivial, especialmente na parte de segurança de threads pra ser implementada corretamente. Espera-se que se use bibliotecas de terceiros que forneçam as ferramentas pra manipular os fluxos. Bons exemplos são o RxJava, Reactor e o Akka Streams.

Reactive Messaging 1.0

• Não sofreu alterações do MicroProfile 3.2 para o 3.3
• Essa especificação fornece suporte a mensagens assíncronas com base no Reactive Stream citado acima.

Certo, e quais são as implementações de MicroProfile?

• Payara Micro
• Thorntail
• ApacheTomEE
• Fujitsu Launcher
• IBM Open Liberty
• Hammock
• KumuluzEE
• Oracle Helidon
• Quarkus

Grande o artigo não? Por enquanto chegamos ao fim, agora entendemos superficialmente do que se trata o projeto MicroProfile, em outros artigos entraremos com detalhes em cada uma das especificações e das implementações… =)