Arquitetura Hexagonal

Arquitetura Hexagonal

Crie uma solução para funcionar sem uma interface gráfica de usuário e/ou um banco de dados, podendo então executar testes de regressão automatizados, trabalhar quando o banco de dados ficar indisponível e evoluir aplicativos sem nenhum envolvimento do usuário.

Intenção

Permitir que uma solução seja igualmente orientada por usuários, programas, testes automatizados ou scripts em lote, e que seja desenvolvido e testado isoladamente de seus dispositivos e bancos de dados de tempo de execução eventuais. À medida que os eventos chegam do mundo externo a uma porta, um adaptador específico de tecnologia o converte em uma chamada ou mensagem de procedimento utilizável e a transmite para o produto. O aplicativo ignora a natureza do dispositivo de entrada. Quando o aplicativo tem algo a enviar, ele o envia por uma porta para um adaptador, que cria os sinais apropriados necessários pela tecnologia de recebimento (humana ou automatizada). A solução tem uma interação de som semanticamente com os adaptadores em todos os lados dele, sem realmente saber a natureza das coisas do outro lado dos adaptadores.

Motivação

Um dos grandes problemas dos softwares ao longo dos anos tem sido a infiltração da lógica de negócios no código na camada de interface do usuário ou no banco de dados e a complexidade ocasionada pela mistura de ambos. O problema que isso causa é triplo: primeiro, o sistema não pode ser testado com suítes de testes automatizadas, porque parte da lógica que precisa ser testada depende de detalhes visuais que mudam constantemente, como tamanho de campo e colocação de botões; Pela mesma razão, torna-se impossível mudar de um uso do sistema conduzido pelo homem para um sistema de execução em testes em lote; Ainda pela mesma razão, torna-se difícil ou impossível permitir que o programa seja conduzido por outro programa quando isso se torna necessário.

A tentativa de resolver isso, repetida em muitas organizações, é criar uma camada adicional na arquitetura, com a promessa de que desta vez, real e verdadeiramente, nenhuma lógica de negócios será colocada na nova camada. No entanto, não tendo nenhum mecanismo para detectar quando ocorre uma violação dessa promessa, a organização descobre, alguns anos depois, que a nova camada está cheia de lógica de negócios e o antigo problema reapareceu.

Imagine agora que cada funcionalidade oferecida pelo aplicativo estava disponível por meio de uma API (interface programada do aplicativo) ou chamada de função. Nessa situação, o departamento de teste ou QA pode executar scripts de teste automatizados no aplicativo para detectar quando qualquer nova codificação quebra uma função que estava funcionando anteriormente. Os especialistas em negócios podem criar casos de teste automatizados, antes que os detalhes da GUI sejam finalizados, informando aos programadores quando eles realizaram o trabalho corretamente (e esses testes se tornam os executados pelo departamento de teste). O aplicativo pode ser implantado no modo “sem cabeça”, de modo que somente a API está disponível e outros programas podem fazer uso de sua funcionalidade – isso simplifica o design geral de conjuntos de aplicativos complexos e permite que aplicativos de serviços business-to-business usem uns aos outros sem intervenção humana na web. Por fim, os testes de regressão de função automatizada detectam qualquer violação da promessa de manter a lógica de negócios fora da camada de apresentação. A organização pode detectar e corrigir o vazamento de lógica.

Um problema semelhante interessante existe no que normalmente é considerado “o outro lado” do aplicativo, onde a lógica do aplicativo fica vinculada a um banco de dados externo ou outro serviço. Quando o servidor de banco de dados fica inativo ou sofre retrabalho ou substituição significativos, os programadores não podem trabalhar porque seu trabalho está vinculado à presença do banco de dados. Isso causa atrasos nos custos e, muitas vezes, sentimentos ruins entre as pessoas. Não é óbvio que os dois problemas estejam relacionados, mas existe uma simetria entre eles que se manifesta na natureza da solução.

Natura da Solução

Os problemas do lado do usuário e do lado do servidor, na verdade, são causados pelo mesmo erro no projeto e na programação – o entrelaçamento entre a lógica de negócios e a interação com entidades externas. A assimetria a explorar não é aquela entre os lados esquerdo e direito da aplicação, mas entre dentro e fora da aplicação. A regra a ser obedecida é que o código pertencente à parte interna não deve vazar para a parte externa.

Removendo qualquer assimetria esquerda-direita ou cima-baixo por um momento, vemos que o aplicativo se comunica através de portas para agências externas. A palavra “porta” deve evocar pensamentos de portas em um sistema operacional, onde qualquer dispositivo que adira aos protocolos de uma porta pode ser conectado a ele; e portas em dispositivos eletrônicos, onde, novamente, qualquer dispositivo que se encaixe nos protocolos mecânicos e elétricos pode ser conectado. O protocolo para uma porta é fornecido pelo propósito da conversa entre os dois dispositivos. O protocolo assume a forma de uma interface de programa de aplicativo (API).

Para cada dispositivo externo, existe um adaptador que converte a definição da API nos sinais necessários para esse dispositivo e vice-versa. Uma interface gráfica do usuário ou GUI é um exemplo de um adaptador que mapeia os movimentos de uma pessoa para a API da porta. Outros adaptadores que se encaixam na mesma porta são os suítes de teste automatizados, os arquivos em lote e qualquer outro código necessário para a comunicação entre aplicativos em toda a empresa ou na rede.

No outro lado, o aplicativo se comunica com uma entidade externa para obter dados. O protocolo é tipicamente um protocolo de banco de dados. Do ponto de vista do aplicativo, se o banco de dados for movido de um banco de dados SQL para um arquivo simples ou qualquer outro tipo de banco de dados, a conversação na API não deve ser alterada. Adaptadores adicionais para a mesma porta incluem um adaptador SQL, um adaptador de arquivo simples e, o mais importante, um adaptador para um banco de dados “simulado”, que fica na memória e não depende da presença do banco de dados real

Muitos aplicativos têm apenas duas portas: o diálogo do lado do usuário e o diálogo do lado do banco de dados. Isso lhes dá uma aparência assimétrica, o que faz parecer natural construir o aplicativo em uma arquitetura empilhada unidimensional, de três, quatro ou cinco camadas.

Existem dois problemas com esses desenhos. Primeiro e pior, as pessoas tendem a não levar a sério as “linhas” no desenho em camadas. Eles permitem que a lógica do aplicativo vaze pelos limites da camada, causando os problemas mencionados acima. Em segundo lugar, pode haver mais de duas portas para o aplicativo, para que a arquitetura não se encaixe no desenho de camada unidimensional.

A arquitetura hexagonal, ou portas e adaptadores, resolve esses problemas observando a simetria da situação: existe uma aplicação no interior comunicando-se sobre um certo número de portas com coisas do lado de fora. Os itens fora do aplicativo podem ser tratados simetricamente.

O hexágono destina-se a destacar visualmente:

  • a assimetria interior-exterior e a natureza similar dos portos, para fugir da imagem em camadas unidimensional e tudo o que evoca.
  • a presença de um número definido de portas diferentes – dois, três ou quatro (quatro é mais que eu encontrei até o momento).

O hexágono não é um hexágono porque o número seis é importante, mas permite que as pessoas que estão fazendo o desenho tenham espaço para inserir portas e adaptadores conforme necessário, não sendo restringidos por um desenho em camadas unidimensional. O termo arquitetura hexagonal vem desse efeito visual.

O termo “porta e adaptadores” retoma as finalidades das partes do desenho. Uma porta identifica uma conversa intencional. Normalmente haverá vários adaptadores para qualquer porta, para várias tecnologias que podem se conectar a essa porta. Normalmente, eles podem incluir uma secretária eletrônica, uma voz humana, um telefone de discagem por tom, uma interface gráfica humana, um equipamento de teste, um driver em lote, uma interface http, uma interface direta entre programas, um simulado (em -memória), um banco de dados real talvez bancos de dados diferentes para desenvolvimento, teste e uso real.

Nas Notas de Aplicação, a assimetria esquerda-direita será ativada novamente. No entanto, o objetivo principal desse padrão é focar na assimetria interna e externa, fingindo brevemente que todos os itens externos são idênticos do ponto de vista da aplicação.

Estrutura

A Figura acima mostra um aplicativo com várias portas ativas e vários adaptadores para cada porta. As portas são o lado controlador de aplicativos e o lado de recuperação de dados. Esse desenho mostra que o aplicativo pode ser igualmente orientado por um conjunto de testes de regressão automatizado no nível do sistema, por um usuário humano, por um aplicativo http remoto ou por outro aplicativo local. No lado dos dados, o aplicativo pode ser configurado para ser executado desacoplado de bancos de dados externos usando uma substituição de banco de dados oracle ou mock na memória; ou pode ser executado no banco de dados de teste ou em tempo de execução. A especificação funcional da aplicação, talvez em casos de uso, é feita contra a interface do hexágono interno e não contra qualquer uma das tecnologias externas que podem ser usadas.

A figura acima mostra o mesmo aplicativo mapeado para um desenho arquitetônico de três camadas. Para simplificar o desenho, apenas dois adaptadores são mostrados para cada porta. Este desenho destina-se a mostrar como vários adaptadores se encaixam nas camadas superior e inferior e a sequência na qual os vários adaptadores são usados durante o desenvolvimento do sistema. As setas numeradas mostram a ordem em que uma equipe pode desenvolver e usar o aplicativo:

  1. Com um equipamento de teste conduzindo o aplicativo e usando o banco de dados mock (in-memory) substituindo o banco de dados real;
  2. Adicionando uma GUI ao aplicativo, ainda executando o banco de dados simulado;
  3. No teste de integração, com scripts de teste automatizados (por exemplo, do Cruise Control), direcionando o aplicativo para um banco de dados real contendo dados de teste;
  4. Em uso real, com uma pessoa usando o aplicativo para acessar um banco de dados ao vivo.

Assimetria Esquerda/Direita

O padrão de portas e adaptadores é deliberadamente escrito, fingindo que todas as portas são fundamentalmente semelhantes. Essa pretensão é útil no nível arquitetônico. Na implementação, os ports e adaptadores aparecem em dois tipos, que eu chamarei de primários e secundários, por razões óbvias de ser óbvio. Eles também podem ser chamados de adaptadores de acionamento e adaptadores acionados.

A camada de GUI pode ser usado nas portas do lado esquerdo e nas simulações à direita. Na arquitetura de três camadas, o GUI fica na camada superior e o mock fica na camada inferior. Mas podem ser considerados fisicamente no desenho da arquitetura como qualquer lado de adaptação.

Isso está relacionado à ideia de casos de uso de “atores primários” e “atores secundários”. Um ator primário é um ator que dirige o aplicativo (retira-o do estado inativo para executar uma de suas funções anunciadas). Um ator secundário é aquele que o aplicativo dirige, seja para obter respostas de ou simplesmente notificar. A distinção entre primário e secundário está em quem desencadeia ou está no comando da conversa.

O adaptador de teste natural para substituir um ator primário, uma vez que essa estrutura é projetada para ler um script e direcionar o aplicativo. O adaptador de teste natural para substituir um ator secundário, como um banco de dados, é uma simulação, já que foi projetado para responder a consultas ou registrar eventos do aplicativo.

Essas observações nos levam a seguir o desenho abaixo e desenhar as portas primárias e os adaptadores primários no lado esquerdo (ou superior) do hexágono e as portas secundárias e adaptadores secundários no lado direito (ou inferior) do hexágono.

A relação entre portas / adaptadores primários e secundários e suas respectivas implementações em GUI e mocks é útil ter em mente, mas deve ser usada como consequência do uso da arquitetura de portas e adaptadores, e não de curto-circuito. O benefício final de uma implementação de portas e adaptadores é a capacidade de executar o aplicativo em um modo totalmente isolado.

Caso de Uso e os Limites de Aplicação

É útil usar o padrão de arquitetura hexagonal para reforçar a maneira preferida de escrever casos de uso. Um erro comum é escrever casos de uso para conter conhecimento íntimo da tecnologia situada fora de cada porta. Esses casos de uso ganharam um nome justificadamente ruim na indústria por serem longos, difíceis de ler, chatos, quebradiços e caros de manter.

Compreendendo a arquitetura de portas e adaptadores, podemos ver que os casos de uso devem geralmente ser colocados no limite do aplicativo (o hexágono interno), para especificar as funções e eventos suportados pelo aplicativo, independentemente da tecnologia externa. Esses casos de uso são mais curtos, mais fáceis de ler, menos caros de manter e mais estáveis ao longo do tempo.

Quantas Portas?

O que exatamente uma porta é e não é, em grande parte, é uma questão de gosto. Em um extremo, cada caso de uso poderia ter sua própria porta, produzindo centenas de portas para muitas operações. Alternativamente, pode-se imaginar a fusão de todas as portas primárias e todas as portas secundárias, de modo que haja apenas duas portas, um lado esquerdo e um lado direito. Nenhum extremo parece ótimo.

O sistema meteorológico descrito nos usos conhecidos padrões possui quatro portas naturais: o feed climático, o administrador, os assinantes notificados, o banco de dados do assinante. Um controlador de máquina de café possui quatro portas naturais: o usuário, o banco de dados contendo as receitas e os preços, os dispensadores e a caixa de moedas. Um sistema de medicação hospitalar pode ter três: um para o enfermeiro, um para o banco de dados de prescrição e outro para os dispensadores de medicamentos controlados pelo computador.

Não parece que haja algum dano específico na escolha do número “errado” de portas, de modo que isso continua sendo uma questão de intuição. Minha seleção tende a favorecer um pequeno número, dois, três ou quatro portas, conforme descrito acima e nos usos conhecidos.

A Figura 4 mostra um aplicativo com quatro portas e vários adaptadores em cada porta. Isso foi derivado de um aplicativo que ouviu alertas do serviço meteorológico nacional sobre terremotos, tornados, incêndios e inundações e notificou pessoas em seus telefones ou atendedores de chamadas telefônicas. Na época em que discutimos esse sistema, as interfaces do sistema foram identificadas e discutidas pela tecnologia, ligadas ao propósito. Havia uma interface para os dados do acionador que chegavam através de um feed, um para que os dados de notificação fossem enviados para as secretárias eletrônicas, uma interface administrativa implementada em uma GUI e uma interface de banco de dados para obter seus dados de assinante.

As pessoas estavam lutando porque precisavam adicionar uma interface http do serviço meteorológico, uma interface de e-mail para seus assinantes e tinham que encontrar uma maneira de agrupar e separar o crescente conjunto de aplicativos para diferentes preferências de compra do cliente. Eles temiam que estivessem encarando um pesadelo de manutenção e testes, pois precisavam implementar, testar e manter versões separadas para todas as combinações e permutações.

Sua mudança no design foi arquitetar as interfaces do sistema de propósito e não de tecnologia, e de ter as tecnologias substituíveis (por todos os lados) por adaptadores. Eles imediatamente conseguiram incluir o feed http e a notificação por e-mail (os novos adaptadores são mostrados no desenho com linhas tracejadas).

Ao tornar cada aplicativo executável no modo “sem cabeça” por meio de APIs, eles poderiam adicionar um adaptador de aplicativo para adicionar e separar o conjunto de aplicativos, conectando os sub-aplicativos sob demanda. Por fim, ao tornar cada executável do aplicativo completamente isolado, com os adaptadores de teste e simulação prontos, eles obtiveram a capacidade de testar seus aplicativos de regressão com scripts de teste automatizados independentes.

Separação do Desenvolvimento de GUI e Regra da Solução

O design da interface do usuário é instável, pois eles ainda não decidiram sobre uma tecnologia de direção ou uma metáfora. A arquitetura de serviços de back-end ainda não foi decidida e, de fato, provavelmente será alterada várias vezes nos próximos seis meses. No entanto, o projeto começou oficialmente e o tempo está passando. A equipe de aplicativos cria testes e simulações para isolar seus aplicativos e cria funcionalidades testáveis e demonstráveis para mostrar a seus usuários. Quando as decisões de serviços de interface de usuário e de back-end são finalmente atendidas, “deve ser simples” adicionar esses elementos ao aplicativo.

Objetos Mock

Um objeto mock é um objeto dublê usado para testar o comportamento de outros objetos. Primeiro, um objeto mock age como uma implementação falsa de uma interface ou classe que imita o comportamento externo de uma implementação verdadeira. Já um objeto simulado observa como outros objetos interagem com seus métodos e compara o comportamento real com as expectativas predefinidas. Quando ocorre uma discrepância, um objeto simulado pode interromper o teste e relatar a anomalia. Se a discrepância não puder ser notada durante o teste, um método de verificação chamado pelo testador garante que todas as expectativas foram atendidas ou falhas relatadas. ” – De http://MockObjects.com

Completamente multualizados de acordo com a agenda de objetos falsos, objetos simulados são usados ​​em todo o aplicativo, não apenas na interface externa. O impulso primário do movimento do objeto simulado é a conformidade com o protocolo especificado no indivíduo. classe e nível de objeto. Eu empresto a palavra “mock” como a melhor descrição curta de um substituto na memória para um ator secundário externo.

Inversão de Dependência

Princípio de Inversão de Dependência do SPRING Bob Martin (também chamado de Injeção de Dependência por Martin Fowler) afirma que “módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. Abstrações não devem depender de detalhes, detalhes devem depender de abstrações.” O padrão de Injeção de Dependência de Martin Fowler fornece algumas implementações. É com IoC que se pode criar adaptadores de ator secundário intercambiáveis, sem fazer a solução depender de recursos externos.

Gostaria de aprender tudo isso? Gostaria de implementar um exemplo completo usando Java?

Venha conferir meus dois cursos da udemy:

Tem dúvidas sobre o cursos? Gostaria de cupons de desconto? Entre em contato comigo no whatsapp (43) 98407-4007, estou a disposição 😉 .

“Ao SENHOR Deus pertencem o mundo e tudo o que nele existe; a terra e todos os seres vivos que nela vivem são dele.” Salmos 24:1

Promoção Arquitetura Hexagonal 20% + DataSource Grátis

Na compra dos 2 cursos de arquitetura hexagonal com 20% de desconto, você ganha totalmente grátis o curso de Jakarta EE DataSource . Faça a compra usando esses links:

Após a compra dos 2 cursos, entre em contato comigo que eu te enviarei o cupom grátis do Jakarta EE DataSource. Em caso de dúvida estou a disposição via WhatsApp (43) 98407-4007.

Bons estudos a todos 🙂 !

“Não deixem que o mal vença vocês, mas vençam o mal com o bem.” Romanos 12:21

Novo Curso Udemy – Arquitetura Hexagonal com Java – C2

Objetivo do Arquitetura Hexagonal com Java – C2 é dar continuidade ao conteúdo do curso 1 de Arquitetura Hexagonal com Java, fazendo novas remontagens  do hexágono para funcionar em diferentes ambientes e com diferentes estilos arquiteturais distribuídos, usando a plataforma Java e Node.js.

Nesse curso, daremos continuidade no projeto de estudo do caso desenvolvido no curso 1, apresentando várias remontagens arquiteturais diferentes, fazendo com que a solução exemplo possa ser executada como projeto web, web mobile, end-point rest e microservices.

O curso é finalizado com varias remontagens arquiteturais de tipos de clientes consumidores do back-end, consumindo a api do microservices, oferendo assim aos participantes um amplo repertório de conhecimentos teóricos e práticos a respeito de arquitetura hexagonal, estilos arquiteturais, microservices e afins.

Venha comigo provar na prática a flexibilidade, reuso e os ganhos de uso da arquitetura hexagonal.

Dúvidas ou cupons de descontos estou a disposição via WhatsApp (43) 98407-4007.

“Deem graças ao SENHOR porque ele é bom, e o seu amor dura para sempre.”1 Crônicas 16:34

Jakarta EE Community Update Janeiro 2020

Quinta-feira, 9 de janeiro de 2020 – 09:26 por Tanja Obradovic

Bem-vindo à nossa primeira atualização de 2020. Quando começamos o novo ano, desejo tudo de bom para você. Temos muito o que esperar em 2020, pois será o primeiro ano com vários lançamentos de Jakarta EE. Que maneira brilhante e otimista de começar um novo ano!

À medida que aceleramos nossas atividades para 2020, veja os destaques do Jakarta EE das últimas semanas de novembro e dezembro de 2019.

A retrospectiva do Jakarta EE 8 está concluída

Como mencionamos em nossa última atualização, o Comitê Diretivo de Jakarta EE solicitou à comunidade que fornecesse feedback sobre o lançamento do Jakarta EE 8 para que pudéssemos fazer melhorias no Jakarta EE 9 e em versões futuras.

Temos o prazer de informar que o feedback já foi coletado, analisado e resumido.

Para saber mais sobre os resultados da retrospectiva, fique de olho em uma postagem no blog sobre o tópico, mas também, junte-se a nós no dia 15 de janeiro às 11:00 EST, usando este ID da reunião, onde este tópico estará na Agenda .

O plano de lançamento do Jakarta EE 9 está pronto para revisão do comitê de especificação

A equipe do Projeto de Plataforma de Jakarta EE, liderada por Kevin Sutter e Steve Millidge, vem trabalhando duro para criar o plano de lançamento detalhado do Jakarta EE 9. Conforme prometido, o plano foi criado, apresentado e endossado pelo Comitê Diretor de Jacarta EE. O próximo passo é o Comitê de Especificação analisá-lo e votá-lo no início deste ano.

Você pode ler as atas das reuniões da equipe do Jakarta EE Platform Project aqui .

Para obter as atualizações mais recentes sobre o planejamento da versão do Jakarta EE 9, ouça a gravação da chamada de atualização do Jakarta EE de dezembro aqui .

Lembrete: precisamos da sua ajuda para obter especificações do Jakartify

Apenas um lembrete de que agora temos os direitos autorais de várias especificações do Java EE e precisamos que a comunidade as Jakartifique para que elas possam ser contribuídas para o Jakarta EE.

Para ajudar você a começar:

· O Comitê de Especificação criou um documento que explica como converter as especificações Java EE em Jakarta EE .

Ivar Grimstad fez uma demonstração durante a chamada da comunidade em outubro. Você pode vê-lo aqui .

E aqui está a lista de especificações prontas para a comunidade Jakartify.

• anotações de Jacarta

• Feijões Empresariais de Jacarta

• Idioma de expressão de Jacarta

• Segurança de Jacarta

• Faces de servidor em Jacarta

• Interceptores de Jacarta

• Autorização de Jacarta

• Ativação de Jacarta

• Feijões gerenciados em Jacarta

• Implantação de Jacarta

• RPC XML de Jacarta

• Autenticação em Jacarta

• Correio de Jacarta

• Ligação XML de Jacarta

• Serviços da Web RESTful em Jacarta

• Metadados dos Serviços da Web de Jacarta

• Serviços Web XML de Jacarta

• Conectores de Jacarta

• Persistência de Jacarta

• Vinculação JSON em Jacarta

• Processamento JSON em Jacarta

• Suporte à depuração de Jacarta para outros idiomas

• Páginas do servidor de Jacarta

• Transações de Jacarta

• Jakarta WebSocket

Finalizado o Plano de Marketing de Jakarta EE 2020

O Relatório de Operações de Marketing de Jacarta EE para o terceiro trimestre de 2019 foi apresentado durante a chamada do Comitê de Marketing de dezembro. O relatório inclui atividades e métricas de mercado para atividades planejadas versus atividades reais no terceiro trimestre e geralmente foi bem recebido pelo comitê.

Você pode ler a ata da reunião aqui .

próximos eventos

Aqui está uma breve olhada em dois próximos eventos de Jakarta EE para marcar em seu calendário:

· Transmissão ao vivo de JakartaOne – Japão, 26 de fevereiro

Com o sucesso do evento JakartaOne Livestream em setembro de 2019, estamos expandindo a iniciativa com mais conferências virtuais em mais idiomas. Nosso próximo evento é o JakartaOne Livestream – Japão marcado para 26 de fevereiro. Siga o evento no Twitter @JakartaOneJPN para obter todos os detalhes. As inscrições serão abertas em breve. Lembre-se de que todo este evento será apresentado em japonês .

· Dia do Cloud Native para Java (CN4J) no KubeCon Amsterdam, 30 de março

O dia CN4J de 30 de março é um dia inteiro (9:00 – 17:00) de palestras, demonstrações e sessões instigantes de especialistas, focadas em aplicativos corporativos implementados usando Jakarta EE e Eclipse MicroProfile no Kubernetes. Este evento é uma ótima oportunidade para se reunir com líderes da indústria e da comunidade, para entender melhor os principais aspectos das tecnologias de Jakarta EE e MicroProfile e para compartilhar suas idéias com inovadores do ecossistema. Saiba mais sobre o evento aqui .

Participar de chamadas de atualização da comunidade

Todo mês, a comunidade de Jakarta EE realiza uma chamada da comunidade para todos na comunidade de Jakarta EE. Para datas futuras e detalhes de conexão, consulte o Calendário da comunidade de Jakarta EE .

Nossa próxima ligação é quarta-feira, 15 de janeiro, às 11h EST, usando este ID da reunião .

Sabemos que nem sempre é possível participar de chamadas em tempo real; portanto, aqui estão os links para as gravações e apresentações:

· A lista de reprodução completa .

· Chamada e apresentação em 11 de dezembro , com Steve Millage discutindo o planejamento de lançamentos do Jakarta EE 9, uma atualização das especificações de Jakartifying de Ivar Grimstad e uma chamada de ação para ajudar com o Plano do Programa EE 2020 de Jacarta e orçamento do presidente do Comitê Diretivo do EE de Jacarta, Will Lyons.

Resumo do Evento em novembro e dezembro

Encerramos um ano muito emocionante para o Jakarta EE participando de três grandes eventos:

· Devoxx BE

· KubeCon NA

· Java2Days

Tivemos membros apresentando nos três eventos e gostaríamos de agradecer sinceramente por seu tempo e esforço. Uma mensagem especial para o nosso advogado de desenvolvimento de Jakarta EE, Ivar Grimstad, que se apresentou várias vezes e participou de um painel de discussão no Java2Days.

Nossos membros também estavam presentes em nossos estandes na Devoxx BE e na KubeCon NA para compartilhar seus conhecimentos, fornecer demonstrações e se envolver com os participantes. Mais uma vez, um enorme obrigado a todos os envolvidos por sua participação entusiasmada. Seu envolvimento ajuda a impulsionar o sucesso de toda a comunidade de Jacarta EE.

Fique conectado com a comunidade Jakarta EE

A comunidade de Jakarta EE é muito ativa e existem vários canais para ajudá-lo a manter-se atualizado com todas as últimas e melhores notícias e informações. blog de Tanja Obradovic resume o plano de envolvimento da comunidade, que inclui:

• Mídias sociais: Twitter , Facebook , Grupo LinkedIn

• Listas de discussão: jakarta.ee-community@eclipse.org e jakarta.ee-wg@eclipse.org

• Boletins, blogs e e-mails: boletim informativo Eclipse , blogs de Jakarta EE , emails de atualização mensal para jakarta.ee-community@eclipse.org e blogs da comunidade sobre “como você está envolvido com o Jakarta EE”

• Reuniões: Jakarta Tech Talks , Jakarta EE Update , Jakarta Town Hall e eventos e conferências da Eclipse Foundation

Assine hoje mesmo seus canais preferidos. E participe do Jakarta EE Working Group para ajudar a moldar o futuro do Java nativo em nuvem de código aberto.

Para saber mais sobre os planos relacionados ao Jakarta EE e verificar a data do próximo Jakarta Tech Talk, certifique-se de marcar o Calendário da comunidade do Jakarta EE .

Fonte:  https://blogs.eclipse.org/post/tanja-obradovic/jakarta-ee-community-update-january-2020

Tradução Google Tradutor

Livro Grátis Lançado: Building an API Backend with MicroProfile

Semana passada, Hayri Cicek, um evangelizador de microprofile lançou a primeira versão do e-book sobre o assunto. Varias e varias dicas de como desenvolver e usar microprofile.

Leitura obrigatória para os desenvolvedores de microservices java.

“Com todo o meu coração, quero estar contigo de noite; com todo o meu ser, procuro conhecer a tua vontade.” Isaías 26:9