Introdução ao JavaEE

Hoje falaremos sobre o que é - Java EE: em que consiste, quais são as características da arquitetura das aplicações Java EE, e forneceremos descrições das diversas tecnologias desta plataforma. O tema em si é extenso, mas não vamos parar no básico. Ao final faremos uma pequena comparação do Java EE com o Spring Framework e responderemos a pergunta: “o que é melhor aprender” (spoiler: claro, você precisa aprender tudo =)) Vamos começar pelo básico.

Java EE - o que é isso?

Java EE é uma plataforma construída sobre Java SE que fornece uma API e um ambiente de tempo de execução para desenvolver e executar aplicativos de rede em larga escala, multicamadas, escaláveis, confiáveis ​​e seguros. Esses aplicativos são chamados de aplicativos corporativos porque resolvem problemas enfrentados por grandes empresas. No entanto, não são apenas as grandes corporações e agências governamentais que podem se beneficiar desses tipos de aplicativos e dos benefícios que o Java EE oferece. As soluções que a plataforma Java EE oferece são úteis, e às vezes simplesmente necessárias, para desenvolvedores individuais e pequenas organizações.

Desenvolvimento JavaEE

Java EE é desenvolvido através do Java Community Process (JCP), formado em 1998. Ele permite que as partes interessadas participem na definição de versões futuras das especificações da plataforma da linguagem Java. A base deste processo é o JSR (Java Specification Request), documentos formais que descrevem as especificações e tecnologias que se propõem a serem adicionadas à plataforma Java. Tais solicitações são feitas por membros da comunidade - desenvolvedores e empresas comuns. Estes últimos incluem Oracle, Red Hat, IBM, Apache e muitos outros. Aqueles. os caras propõem novos recursos e novidades para consideração que gostariam de incluir em Java. E então eles realizam uma votação, com base na qual é tomada uma decisão sobre o que incluir na próxima versão. O histórico da versão do Java EE é assim:

• J2EE 1.2 (dezembro de 1999)
• J2EE 1.3 (setembro de 2001)
• J2EE 1.4 (novembro de 2003)
• Java EE 5 (maio de 2006)
• Java EE 6 (dezembro de 2009)
• Java EE 7 (maio)
• Java EE 8 (agosto de 2017)
• Jacarta EE 8 (setembro de 2019)

Em 2017, ocorreu um novo marco no desenvolvimento da plataforma: a Oracle transferiu o controle do desenvolvimento do Java EE para a Eclipse Foundation. E em abril de 2018, o Java EE foi renomeado para Jakarta EE, que é totalmente compatível com o Java EE 8.

Arquitetura de aplicativos Java EE

Uma breve introdução. Para facilitar o entendimento, vamos falar sobre a estrutura das aplicações Java EE e alguns dos termos que utilizaremos mais adiante. Os aplicativos Java EE possuem uma estrutura que possui duas qualidades principais:

• Em primeiro lugar, multinível. Os aplicativos Java EE são multicamadas e falaremos sobre isso com mais detalhes;
• em segundo lugar, aninhamento. Existe um servidor Java EE (ou servidor de aplicativos), com contêineres de componentes localizados dentro dele. Esses contêineres abrigam (bingo!) componentes.

Para explicar a arquitetura das aplicações Java EE, vamos primeiro falar sobre camadas. Quais são os níveis? Quais tecnologias Java EE são usadas em diferentes níveis? A seguir, discutiremos como os servidores de aplicativos, os contêineres de componentes e os próprios componentes estão interconectados. Mas tenha em mente que todas essas são visões de diferentes ângulos da mesma coisa, e a ordem não é tão importante aqui.

Níveis de aplicação

Aplicativos multicamadas são aplicativos divididos de acordo com princípios funcionais em módulos isolados (níveis, camadas). Normalmente (inclusive no contexto do desenvolvimento Java EE), os aplicativos corporativos são divididos em três níveis:

• cliente;
• nível médio;
• nível de acesso aos dados.

1. A camada cliente é uma aplicação que solicita dados do servidor Java EE (camada intermediária). O servidor, por sua vez, processa a solicitação do cliente e retorna uma resposta a ela. O aplicativo cliente pode ser um navegador, um aplicativo independente (móvel ou desktop) ou outros aplicativos de servidor sem interface gráfica.

2. O nível médio é dividido, por sua vez, em nível web e nível de lógica de negócios.

   1. A camada web consiste em alguns componentes que fornecem interação entre os clientes e a camada lógica de negócios.

      As seguintes tecnologias Java EE são usadas no nível da web:

      • Tecnologia JavaServer Faces (JSF);
      • Páginas de Servidor Java (JSP);
      • Linguagem de Expressão (EL);
      • Servlets;
      • Contextos e injeção de dependência para Java EE (CDI).

   2. A camada de lógica de negócios consiste em componentes que implementam toda a lógica de negócios da aplicação. Lógica de negócios é um código que fornece funcionalidades que atendem às necessidades de alguma área de negócios específica (setor financeiro, bancário, comércio eletrônico). Este nível pode ser considerado o núcleo de todo o sistema.

      Tecnologias envolvidas neste nível:

      • Enterprise JavaBeans (EJB);
      • Serviços web RESTful JAX-RS;
      • Entidades da API de persistência Java;
      • Serviço de mensagens Java.

3. Nível de acesso aos dados. Este nível é às vezes chamado de nível de sistemas de informação empresarial (EIS). O EIS consiste em vários servidores de banco de dados, sistemas de planejamento de recursos empresariais ERP (Enterprise Resource Planning) e outras fontes de dados. A camada de lógica de negócios acessa essa camada para obter dados.

   Neste nível você pode encontrar tecnologias como:

   • API de conectividade de banco de dados Java (JDBC);
   • API de persistência Java;
   • Arquitetura do conector Java EE;
   • API de transação Java (JTA).

Servidores de aplicativos, contêineres, componentes

Vamos dar uma olhada na definição de Java EE da Wikipedia. Java EE é um conjunto de especificações e documentação relacionada para a linguagem Java, descrevendo a arquitetura da plataforma do servidor para tarefas de médias e grandes empresas. Para entender melhor o que significa “conjunto de especificações” neste contexto, vamos fazer uma analogia com uma interface Java. A própria interface Java é desprovida de funcionalidade. Simplesmente define algum contrato segundo o qual alguma funcionalidade é implementada. Mas outras classes implementam a interface. Além disso, uma interface pode ter várias implementações, cada uma das quais pode diferir uma da outra em alguns detalhes. A especificação é exatamente a mesma. Naked Java EE é apenas um conjunto de especificações. Estas especificações são implementadas por vários servidores Java EE. Um servidor Java EE é um aplicativo de servidor que implementa as APIs da plataforma Java EE e fornece serviços Java EE padrão. Os servidores Java EE às vezes são chamados de servidores de aplicativos. Os dados do servidor podem conter componentes de aplicativo, cada um correspondendo ao seu próprio nível em uma hierarquia multinível. O servidor Java EE fornece vários serviços para esses componentes na forma de um contêiner. Os contêineres são a interface entre os componentes que eles hospedam e a funcionalidade independente de plataforma de baixo nível que dá suporte ao componente. Os contêineres fornecem serviços específicos aos componentes que hospedam. Por exemplo, gerenciamento do ciclo de vida de desenvolvimento, injeção de dependência, simultaneidade, etc. Os contêineres escondem a complexidade técnica e aumentam a portabilidade. Existem quatro tipos diferentes de contêineres em Java EE :

1. Os contêineres de miniaplicativos são implementados pela maioria dos navegadores. Ao desenvolver miniaplicativos, você pode se concentrar no lado visual do aplicativo, enquanto o contêiner fornece um ambiente seguro.

2. O Application Client Container (ACC) contém um conjunto de classes Java, bibliotecas e outros arquivos necessários para implementar recursos como injeção, gerenciamento de segurança e serviços de nomenclatura em aplicativos Java SE.

3. O contêiner da web fornece os serviços principais para gerenciar e executar componentes da web (servlets, componentes EJB Lite, páginas JSP, filtros, listeners, páginas JSF e serviços da web). É responsável por instanciar, inicializar e invocar servlets e dar suporte aos protocolos HTTP e HTTPS. Este contêiner é usado para servir páginas da web para navegadores clientes.

4. O contêiner EJB (Enterprise Java Bean) é responsável por gerenciar e executar os componentes do modelo EJB que contêm a camada lógica de negócios da aplicação. Ele cria novas entidades de bean EJB, gerencia seu ciclo de vida e fornece serviços como transação, segurança, simultaneidade, distribuição, nomenclatura ou recursos de invocação assíncrona.

Também em Java EE existem quatro tipos de componentes que uma implementação da especificação Java EE deve suportar:

1. Applets são aplicativos de interface gráfica do usuário (GUI) executados em um navegador. Eles aproveitam a rica API Swing para produzir interfaces de usuário poderosas.

2. Aplicativos são programas executados no lado do cliente. Eles normalmente são interface gráfica do usuário (GUI) e usados ​​para processamento em lote.

3. Aplicativos Web (compostos por servlets e seus filtros, ouvintes de eventos da Web, páginas JSP e JSF) - são executados em um contêiner da Web e respondem a solicitações HTTP de clientes da Web. Os servlets também suportam terminais de serviço da web SOAP e RESTful.

4. Aplicativos corporativos (construídos com Enterprise Java Beans, Java Message Service, Java Transaction API, Chamadas Assíncronas, Time Services) são executados em um contêiner EJB. EJBs gerenciados por contêiner lidam com lógica de negócios transacional. Eles podem ser acessados ​​local ou remotamente via RMI (ou HTTP para serviços web SOAP e RESTful).

O diagrama abaixo mostra uma arquitetura típica de aplicativo Java EE:

Tecnologias

Então, resolvemos a arquitetura. A estrutura geral deve ser clara. No processo de descrição dos componentes arquitetônicos, abordamos algumas tecnologias Java EE, como EJB, JSP, etc. A tabela abaixo mostra as tecnologias utilizadas principalmente no nível do cliente: A tabela abaixo mostra as tecnologias utilizadas no nível da lógica de negócios: A tabela abaixo mostra as tecnologias utilizadas na camada de acesso a dados:

Java EE versus Primavera

O Spring Framework é considerado um concorrente do Java EE. Se você observar o desenvolvimento dessas duas plataformas, surge um quadro interessante. As primeiras versões do Java EE foram criadas com a participação da IBM. Eles acabaram sendo legais, mas desajeitados, pesados ​​e inconvenientes de usar. Os desenvolvedores tiveram dificuldades devido à necessidade de manter um grande número de arquivos de configuração e outros motivos que complicam o desenvolvimento. Ao mesmo tempo, nasceu o Spring IoC. Era uma biblioteca pequena, bonita e fácil de usar. Ele também usava um arquivo de configuração, mas diferentemente do Java EE, havia apenas um. A simplicidade do Spring fez com que quase todos passassem a utilizar esse framework em seus projetos. E então Spring e Java EE começaram seu caminho para a mesma coisa, mas de fins diferentes. A Pivotal Software, desenvolvedora do Spring, começou a lançar projeto após projeto para cobrir todas as necessidades possíveis e impossíveis dos desenvolvedores Java. Gradualmente, o que antes era chamado de Spring tornou-se primeiro um dos projetos e depois se fundiu completamente com vários outros projetos no Spring Core. Tudo isso levou à inevitável complicação do Spring em relação ao que era originalmente. Com o tempo, tornou-se muito difícil acompanhar todo o emaranhado de dependências do Spring, e surgiu a necessidade de uma biblioteca separada que carregasse e executasse tudo sozinha (agora o amado Spring Boot soluçou em algum lugar). Todo esse tempo, o JCP tem trabalhado em uma coisa - alcançar a simplificação máxima de tudo o que é possível dentro do Java EE. Como resultado, em um EJB moderno, para descrever um bean, basta especificar uma anotação acima da classe, o que dá ao desenvolvedor acesso a todo o poder da tecnologia Enterprise Java Beans. E simplificações semelhantes afetaram todas as especificações do Java EE. Como resultado, Spring e Java EE têm aproximadamente paridade em termos de funcionalidade. Algumas coisas são melhores, outras são piores, mas se olharmos globalmente, não há grandes diferenças. O mesmo se aplica à complexidade do trabalho. Tanto Spring quanto Java EE são ferramentas excelentes. Talvez o melhor que existe atualmente para construir aplicativos de rede corporativa em Java. No entanto, Java EE geralmente pode funcionar apenas dentro do Enterprise Application Server (o Tomcat não é um deles), e um aplicativo na pilha Spring pode ser executado em qualquer coisa (no mesmo Tomcat) e até mesmo sem um servidor (já que será executado dentro de si de forma independente). Isso torna o Spring uma ferramenta ideal para desenvolver pequenos aplicativos GUI front-end ou arquiteturas de microsserviços. Mas eliminar a dependência de servidores de aplicativos teve um impacto negativo na escalabilidade dos aplicativos Spring. E o Java EE é adequado para implementar um aplicativo de cluster monolítico escalável. Os desenvolvedores familiarizados com o Spring Framework são atualmente mais procurados no mercado de trabalho. Foi assim que aconteceu historicamente: numa época em que o Java EE era excessivamente complicado, o Spring “ganhou uma base de clientes”. E ainda assim, não há uma resposta clara para a questão de o que aprender Spring ou Java EE. Um iniciante pode receber os seguintes conselhos. Familiarize-se (pelo menos superficialmente) com ambas as plataformas. Escreva um pequeno projeto doméstico em Java EE e Spring. E então aprofunde-se na estrutura que será necessária no trabalho. Como resultado, alternar entre Spring e Java EE não será difícil.

Resultados

É claro que um tópico de grande escala não pode ser abordado em um artigo! Depois de vários termos novos, você provavelmente desejará “aplicar” esse conhecimento a um exemplo da vida real. Portanto, continuaremos estudando Java EE: você encontrará lições práticas sobre como configurar um ambiente local para desenvolvimento Java EE no próximo artigo.