segunda-feira, 20 de maio de 2019

Desenvolvendo com JBoss EAP 7 - Configurando Servidor

< EM CONSTRUÇÃO - Material sendo elaborado >
Introdução

Essa é a segunda parte da serie de posts que ensina a configurar o ambiente de desenvolvimento para a plataforma Java EE. As outras partes são:

1. Overview
2. Configurando o Servidor
3. Configurando a IDE
4. Validando o ambiente

Nesse post veremos o que é o JBoss EAP, como obter uma cópia para desenvolvimento e os conceitos utilizados pelo JBoss para gerenciar as configurações e como customizar um perfil para o desenvolvimento de nossas aplicações.

O que é o JBoss EAP

JBoss Enterprisee Application Platform é o nome de um servidor de aplicações que implementa a especificação Java EE. Ele é vendido pela RedHat baseado no modelo de subscrição juntamente com o suporte ao produto. Nesse modelo é cobrado o direito de uso do software, juntamente com um pacote de suporte que dá acesso a ajuda dos profissionais da RedHat para instalar, configurar e corrigir problemas no JBoss assim como na integração entre as aplicações e o servidor de aplicação.

Quanto Custa?

O custo da subscrição básica é de U$ 8.000,00 por ano, já a subscrição premium, que fornece um nível de suporte melhor sai por U$ 12.000,00. Os preços mais atuais podem ser conferidos direto no site da RedHa, no seguinte link: https://www.redhat.com/en/store. Um detalhe curioso sobre o preço anunciado no site da RedHat é que não fica claro qual a política comercial em relação a subscrição. Pesquisando um pouco consegui encontrar uma calculadora que compara a economia entre a subscrição do JBoss vs produtos da IBM e Oracle (https://www.redhat.com/pt-br/product-red-hat-jboss-eap-eap-calculator). Segundo os parâmetros da calculadora, podemos deduzir que o preço da licença do JBoss é calculado por core. Para que o preço anunciado de U$ 12.000,00 seja aplicado, é necessário uma configuração mínima de 16 cores.

Porque usar?

A grande vantagem de se pagar a subscrição da RedHat é contar com o apoio e conhecimento dos profissionais da empresa para enfrentar os desafios do mundo corporativo. A empresa conta com um grupo de profissinais capacitados para ajudar na resolução de problemas e na busca por soluções para desafios tecnológicos que os times de infraestrutura e desenvolvimento possam enfrentar durante o desenvolvimento de suluções Java EE.
No caso de um desenvolvedor independente, ou de empresas que tenham equipes treinadas e capacitadas para atuar de forma independente o ganho no uso da subscrição pode não ser tão significativo.

Quais alternativas?

O JBoss EAP é a versão comercial de um projeto OpenSource e Free chamado WildFly, também desenvolvido e patrocinado pela RedHat. O WildFly funciona como uma espécie de laboratório para a implementação de novos recursos e especificações que podem ser incorporados no JBoss EAP. Segundo descrito na seguinte página, os dois servidores tem, atualmente, o mesmo conjunto de funcionalidades: http://wildscribe.github.io/index.html.

Caso você ou sua empresa não tenham intenção de utilizar o JBoss EAP, o WildFly é uma alternativa viável, contanto que seu time seja capacitado suficiente para não depender do suporte da RedHat.

E para o desenvolvedor?

Para o desenvolvedor ou administrador de servidores querendo testar ou aprender a como utilizar o JBoss EAP, a RedHat disponibiliza uma versão gratúita. Para isso é necessário criar uma conta no site https://developers.redhat.com/ e fazer o download do software no seguinte link.



Faça o download do arquivo ZIP - Application Platform


Lembrando que não é permitido utilizar o software em produção com a licença de desenvolvedor.


Instalação

Para o ambiente proposto não utilizaremos o instalador do JBoss. Executaremos o servidor como uma aplicação Java padrão. Existe a opção de usarmos o JBoss como um serviço do Windows, porém, para manter o ambiente simples, não usaremos essa opção.

Uma vez baixado o arquivo jboss-eap-7.2.0.zip precisamos descompactá-lo em um diretório qualquer do sistema operacional.

Antes de executar o servidor é necessário garantir que a variável de ambiente JAVA_HOME esteja apontando para o SDK escolhido. Para o ambiente que está sendo configurado recomendo o uso do OpenJDK 1.8 - Hotspot distribuído pelo site AdoptOpenJDK.

estrutura de diretório do JBoss 7.2


Iniciando o servidor

O JBoss tem dois modos de execução: Standalone ou Dominio. O modo Dominio é apropriado para configurações onde o JBoss será executado de forma clusterizada, ou seja, com diversas instâncias rodando em diferentes máquinas se comportando como um único servidor. No modo standalone são utilizadas configurações que assumem o servidor sendo executado em uma única máquina sem comunicação com outros servidores JBoss.

Para o ambiente de desenvolvimento será utilizada a configuração Standalone. Para subir o servidor nesse modo, basta executarmos o arquivo standalone.bat que fica no diretório /bin/standalone.bat. 



Esse utilitário irá fazer as verificações básicas do ambiente e iniciar uma instância baseada nas configurações encontradas no seguinte diretorio: /standalone/configuration/standalone.xml



O servidor irá iniciar, por padrão, utilizando a porta 8080 para o servidor web (undertow) e na porta 9990 para o console de administração.


Para testar a instalação, podemos acessar o console no seguinte URL: http://localhost:9990/console/index.html

No primeiro acesso será mostrado um aviso, dizendo que nenhum usuário de administração foi configurado.

Para obtermos acesso ao console de administração, precisamos executar o script add-user.bat que está na pasta /bin/add-user.bat 

O script iniciará um utilitário interativo onde você deverá preencher algumas informações referente ao usuário a ser criado:

Tipo do usuário: Digite a letra "a" e pressione ENTER;
Username: Digite o nome escolhido para o usuario de administração. O JBoss não aceita o usuário com nome de 'admin' portanto seja criativo e escolha outro nome;
Password/Confirmação: As senhas podem ter: letras e números (a-z, A-Z, 0-9); traços (-), pontos (.), virgula(,), arroba (@), barra invertida (\) e sinal de igual (=);
Grupos: Deixe em branco e pressione ENTER;
Confirmação dos dados: digite 'yes' e pressione ENTER;
O usuário vai ser utilizado para conectar em outro application server (AS): digite 'no' e pressione enter;

A saída será parecida com a seguinte:


Uma vez adicionado o usuário basta acessar novamente o URL: http://localhost:9990/console/index.html e um popup requisitando as credenciais do usuário administrativo será exibida. Basta preencher com o usuario/senha que acabamos de adicionar e teremos acesso ao console de administração.

Console de administração do JBoss 7.2



Habilitando JMS através do ActiveMQ.

Por padrão a configuração Standalone não habilita o serviço de mensageria JMS, porém, como é comum que aplicações distribuidas utilizem troca de mensagem, vamos habilitar esse módulo antes de inicar nosso servidor.

O JBoss 7.2 utiliza o servidor ActiveMQ Artemis (https://activemq.apache.org/components/artemis/) para gerenciar a troca de mensagens. Para habilitar esse módulo precisamos editar o arquivo de configuração \standalone\configuration\standalone.xml. Para isso vamos executar uma cópia desse arquivo e renomeá-la para standalone_jms.xml e salvar no mesmo diretório do arquivo original.




< EM CONSTRUÇÃO >








domingo, 19 de maio de 2019

Desenvolvendo com JBoss EAP 7 - Overview


Essa série de posts tem como objetivo orientar o leitor no setup do ambiente para desenvolvimento de aplicações Java EE utilizando o servidor de aplicação JBoss EAP ou o WildFly.

Está disponível no site da RedHat um guia de como configurar o ambiente de desenvolvimento que pode ser encontrado no seguinte link: https://developers.redhat.com/products/eap/hello-world/. O material da RedHat orienta o uso do Red Hat CodeReady Studio (antigamente chamado de JBoss Developer Studio), uma versão customizada do Eclipse com funcionalidades específicas para desenvolvimento com JBoss. CodeReady Studio é um produto da RedHat vendido nos mesmos padrões do JBoss, com uma subscrição anual. Também é possível baixar uma versão trial sem a necessidade de pagar licença.

Os próximos posts apresentam um setup minimalista, reduzindo a complexidade do ambiente para que o desenvolvedor possa focar sua atenção na escrita do código, evitando gastar tempo no troubleshooting de problemas do ambiente.

Os posts são divididos da seguinte forma:

1. Overview
2. Configurando o Servidor
3. Configurando a IDE
4. Validando o ambiente

Overview

O ambiente proposto é composto por:
  • Java Development Kit - OpenJDK 1.8
  • Servidor de Aplicação - JBoss EAP 7.2
  • Maven - 3.3
  • Banco de Dados - MySql Community Edition

Java Development Kit

Como discutido nesse post: Java vai ser pago! E agora? precisamos nos atentar para qual distribuição do Java vamos utilizar para criar nossas aplicações. Para usuários domésticos, utilizar a distribuição da Oracle ainda é uma opção, mas para usuários corporativos é necessário atenção no momento da escolha. Utilizei, para todos os passos desse material, a versão OpenJDK 8 - Hotspot distribuída através do site https://adoptopenjdk.net/.

Servidor de Aplicação

Utilizei o JBoss EAP 7.2 distribuido pela RedHat. É um servidor completo e confiável que já tem muitos anos de mercado. Apesar de ser um produto pago, é possível utiliza-lo em ambiente de desenvolvimento sem custos. Existe uma versão do JBoss EAP distribuída gratuitamente, o WildFly. Todas as instruções apresentadas aqui podem ser utilizadas com o WildFly, sem a necessidade de adaptações.

Maven 3.3

Para executar a compilação e organização do código independente da IDE, será utilizada a ferramenta Apache Maven (https://maven.apache.org). Dessa forma o projeto poderá ser uti
lizado na IDE de sua preferência, sem necessidade de alteração. Os proximos posts não tratarão dos conceitos básicos da Maven. Caso o leitor não tenha familiaridade com a ferramenta, recomendo o seguinte tutorial: Maven em 5 minutos.

Banco de Dados

Para testar a conexão com banco de dados será utilizado a versão gratuita do MySQL. Veja que a configuração da conexão com o banco é feita no servidor de aplicação, portanto, por mais que existam pequenas diferenças em como configurar a conexão com diferentes bancos de dados, essa diferença é tratada pelo servidor de aplicação. O código da aplicação não é afetado.

Requisitos do Sistema

O ambiente que será configurado utilizará a mesma máquina para executar todos os componentes. Temos que ter em mente que será necessário uma quantidade considerável de memória RAM e poder de processamento para podermos executar todos os componentes simultaneamente.

O mínimo recomendado para um computador com Windows 10 é 16GB RAM e um processador i5 de 3.0GHz ou melhor.

Computadores com menos RAM ou processadores mais lentos conseguirão rodar os componentes, porém, dependendo da quantidade de ferramentas (IDE, navegadores web, clientes de banco de dados, etc) que forem necessárias, a experiência pode não ser a melhor. Outro componente que faz bastante diferença para desenvolvimento Java é o disco. HD SSD costumam ajudar no tempo de boot do servidor de aplicação, assim como no uso das IDEs.


Parte 2 - Configurando o Servidor

domingo, 14 de abril de 2019

O Java vai ser pago! E agora?



No início de 2018 a Oracle anunciou que sua distribuição do Java deixaria de ser "free" a partir de janeiro de 2019. Isso gerou muitas dúvidas e preocupações na comunidade Java.

Como apenas no final de 2018 a Oracle liberou sua política de comercialização do Java, a comunidade de usuários passou por momentos de confusão e até desespero sem saber qual seria o futuro da plataforma.
Mesmo com o anúncio da nova política, os comunicados e documentos lançados pela Oracle, devido a sua grande complexidade, ainda deixam a comunidade insegura em relação ao uso do Java.
O objetivo desse post é tentar esclarecer, de forma breve, qual o cenário atual, e algumas das opções disponíveis para os usuários da plataforma Java.
Para entender o cenário atual precisamos, primeiro, analisar alguns pontos: OpenJDK e versões LTS. Logo em seguida são apresentadas algumas opções de distribuições da plataforma Java.

O OpenJDK

Em 2006 a Sun Microsystems anunciou que iria transformar o Java em uma plataforma OpenSource. No ano seguinte foi lançado o projeto OpenJDK, que tornava público o código da plataforma Java.
Após o anúncio da aquisição da Sun a Oracle assumiu o compromisso de manter o código do Java aberto e manteve o projeto OpenJDK. Atualmente o OpenJDK é a base para as demais distribuições Java disponíveis no mercado.

O código do Java está disponível no site do projeto, em https://openjdk.java.net/, e qualquer pessoa pode baixar, compilar, e produzir seus próprios binários do Java, sem custo algum!

Porém, para uma plataforma tão complexa quando o Java, baixar, compilar e manter o código é bastante trabalhoso, e a maioria dos usuários não está disposta a isso. Cada distribuição Java nada mais é do que uma versão do código do Java SDK, que foi baixado do repositório do projeto OpenJDK, compilada e distribuída por alguém.


Versões do Java

Com o lançamento do Java 9, em setembro de 2017, a Oracle declarou que será lançada uma nova versão do Java, através do projeto OpenJDK, a cada seis meses. Outra mudança importante foi em relação aos patches de segurança e correção de bugs. A partir da data de lançamento de uma nova versão do Java, os patches de segurança e correções de bugs não serão mais lançados para as versões anteriores.
Nesse cenário, para ter acesso aos updates do OpenJDK, o usuário deverá fazer o update para a versão mais recente do Java assim que ela for lançada.

Ciclo de vida das versões do Java, incluindo o tempo de suporte para cada versão. Imagem extraida de https://www.azul.com/think-moving-jdk-9-sometime-next-year-think/

Para o usuário doméstico, ou para o desenvolvedor casual, isso não parece ser um grande problema. Fazer o update a cada seis meses, de forma gratuita, ou mesmo ficar sem os patches de correção de bugs e/ou patches de segurança não seja tão crítico. Porém, para empresas que utilizam o Java em uma quantidade grande de máquinas ou são alvos de ataques constantes isso se torna uma grande dor de cabeça. É nesse contexto que entram as distribuições do Java.

Versões LTS vs non-LTS

As versões semestrais do projeto OpenJDK são classificadas como non-LTS (non-Long Term Suport / sem Suporte de Longo Prazo). Essas versões trarão a cada seis meses, novas funcionalidades para a linguagem e plataforma Java, permitindo que os desenvolvedores se familiarizem e utilizem os novos recursos assim que possível. A cada três anos a Oracle vai lançar uma versão LTS (com Suporte de Longo Prazo) a qual receberá correções de bug e patches de segurança por pelo menos cinco anos. Atualmente, o Java 9 e Java 10 são versões non-LTS, e o Java 11, lançado em setembro de 2018 é uma versão LTS. Dessa forma, o Java 11 receberá correções e patches de segurança até 2023. O importante a entender nesse ponto é: Oracle OpenJDK (grátis) somente terá versões non-LTS. Oracle Java (pago) somente terá versões LTS.
Outras distribuições, como a Zulu da Azul Systems, terão suas próprias políticas para as versões non-LTS e LTS.


Principais distribuições do Java

Oracle JDK ( Java SE )

Se você ou sua empresa usam Java, especialmente versões anteriores ao Java 9, existe grande probabilidade usar essa distribuição. O OracleJDK é uma versão do OpenJDK compilado e distribuído pela Oracle. Segundo a Oracle, existem apenas algumas bibliotecas de código proprietário que fazem parte da OracleJDK que não estão disponíveis para o projeto OpenJDK. A maioria das bibliotecas estão ligadas ao desenvolvimento de aplicações desktop, como drivers de som ou renderizadores de fonte. Existem alternativas para essas bibliotecas, e uma lista mais detalhada pode ser encontrada aqui.
Licenciamento: A partir de Janeiro de 2019 essa distribuição passou a ser vendida pelo modelo de subscrição. Portanto, para poder utilizar a distribuição da Oracle, para uso comercial ou não, o usuário deverá ter um contrato de subscrição com a Oracle.
Preço: Os dados mais recentes sobre a comercialização dessa versão podem ser encontrados em https://www.oracle.com/java/. Na data atual, segundo a lista de preços da Oracle para o Java SE o preço*, para servidores, é cobrado por core, e pode variar de U$25,00 mensais por core, para licenciamentos de 1 a 99 cores, até U$ 12.50 mensais para licenciamentos acima de 10.000 cores.
Vantagens: Com a subscrição da Oracle adquire-se o direito de uso, de suporte, e de patches de segurança e correções de bugs enquanto o contrato estiver vigente. Uma vez encerrado o contrato, o usuário é obrigado a desinstalar todas as versões do Oracle Java instalados nas máquinas.
A subscrição da Oracle não está atrelada a uma versão específica. Uma vez tendo um contrato vigente, o usuário tem direito a utilizar qualquer versão do Java ( 1.8, 9, 10, 11, ...) sem ter que pagar nenhum valor extra enquanto mantiver a quantidade de cores inalterada.
Plataformas Suportadas: Windows, Linux, Solaris, MacOS (veja a lista completa de plataformas suportadas).
* esse é o preço apresentado na lista global da Oracle. Esse preço pode variar de acordo com a relação comercial de cada empresa com a Oracle. Também podem existir mais descontos baseados nos tipos de processadores utilizados.

Oracle OpenJDK

A Oracle, além das versões do Oracle JDK, fornece binários de versões non-LTS no seguinte site: https://jdk.java.net/. Essas versões são distribuídas seguindo a licença GNU GPLv2. Em resumo elas são grátis para baixar e usar, porém, por serem non-LTS, terão patches de segurança e correções de bug apenas até o lançamento da próxima versão do Java.
Preço: Grátis
Plataformas Suportadas: Windows, Linux, MacOS (Lista de plataformas suportadas para o JDK 11)

AdoptOpenJdk

Em uma iniciativa conjunta, grandes empresas, como IBM, Microsoft, RedHat, Pivotal se uniram para produzir uma plataforma que disponibilizasse binários confiáveis do Java de forma gratuita para toda a comunidade. Detalhes, como a missão e os envolvidos na iniciativa podem ser encontrados aqui: https://adoptopenjdk.net/about.html.
Além dos binários semestrais, o projeto também disponibilizará versões LTS, seguindo a mesma cadência de três anos adotada pela Oracle. Na presente data, o projeto AdoptOpenJDK se compromete a suportar as versões OpenJDK 1.8 até 2023 e a versão OpenJDK 11 até, no mínimo 2022. No site o projeto menciona que os bugs reportados serão corrigidos o mais rápido possível e disponibilizados nas versões seguintes. Também é possível contratar suporte comercial (pago) para os binários distribuídos pelo projeto AdoptOpenJDK. Os parceiros informados no site são a IBM e a JClarity. Os detalhes do suporte podem ser vistos aqui: https://adoptopenjdk.net/support.html
Preço: Grátis (com opção de suporte pago)
Plataformas Suportadas: Windows, Linux, MacOS, AIX, Soalris (Lista de plataformas suportados)

Azul Zulu

Azul Systems é uma empresa focada no desenvolvimento de JVMs de alta performance. O Zulu, a JDK da azul, também é baseado no OpenJDK e tem uma versão gratuita, e uma versão paga, o Zulu Enterprise.
O chamariz para o Zulu Enterprise é, nesse contexto, o suporte para versões LTS por durante 8 anos (lembrando que a Oracle fornece suporte de cinco anos para LTS). Outro diferencial são as versões MTS (medium term suporte ou suporte de médio prazo). Essas versões anuais, normalmente lançadas em setembro de cada ano, para as quais a Azul se compromete a dar suporte por 2.5 anos.
Já a versão grátis do Zulu, pode ser usada para qualquer fim, comercial ou não, porém a Azul não se compromete com o suporte estendido para essas versões. Os detalhes do roadmap de suporte para o Zulu pode ser encontrado em: https://www.azul.com/products/azul_support_roadmap/

Preço*: Gratis, sem garantia de suporte, ou pago, usando a versão Zulu Enterprise. A Azul tem uma política de preços bem mais simples do que a Oracle. Os preços são baseados na quantidade de Zulu JDKs instalados, independente da quantidade de cores de cada máquina. Os preços variam de U$13.500,00 dólares anuais para até 25 instalações até um máximo de U$ 290.000,00 dólares anuais para instalações ilimitadas. Os detalhes da tabela de preços podem ser encontrados na página do produto em: https://www.azul.com/products/zulu-enterprise/.
Plataformas Suportadas: Windows, Linux, MacOS, Solaris. (Lista de plataformas suportadas)
* O preço mencionado é baseado no 'Standard Support'. Site consultado em 14/04/2019

RedHat OpenJDK

A RedHat é uma das grandes contribuidoras para o projeto OpenJDK e distribui junto com sua versão comercial do Linux, o RedHat Enterprise Linux (RHEL), sua distribuição do OpenJDK.
Para os clientes da RedHat que tenham um contrato de uso do RHEL, ou para os desenvolvedores com subscrição ao sistema operacional da RedHat, o acesso a OpenJDK, aos patches de segurança e correções de bug já está incluso no preço. Outra maneira de se obter o direto de uso do OpenJDK da RedHat é tendo um contrato de uso de algum dos middlewares fornecidos pela empresa que utilizem, como o JBoss EAP, o JBoss Web Server, JBoss Developer Studio ou algum outro produto. Nesse caso o cliente poderá utilizar o OpenJDK na mesma máquina onde o produto da RedHat foi instalado. Em dezembro de 2018 a RedHat lançou uma versão suportada o OpenJDK para a plataforma Windows.
Preço: Pago. Os detalhes de preço das subscrições da RedHat não estão disponíveis no site. É necessário entrar em contato com o setor de vendas para conseguir uma cotação.
Plataformas Suportadas: Windows e Linux - Para detalhes sobre o suporte do RedHat OpenJDK, assim como o Roadmap de suporte, consulte esse artigo da própria RedHat: OpenJDK Life Cycle and Support Policy

Conclusão

O Java deixou de ser grátis? A versão da Oracle sim! Porém isso é só uma parte da história.
Por muitos anos a comunidade Java se acostumou com o fato de existir uma distribuição predominante do JDK, o Oracle JDK. Anterior a 2018, a preocupação de escolher qual distribuição do Java usar raramente passou pela cabeça dos desenvolvedores ou administradores de sistema.
O que vemos acontecer é a mudança de política comercial da Oracle forçar a comunidade Java a olhar para outras alternativas disponíveis e começar a analisar outras versões de JDK.
No início houve muita confusão, e informações desencontradas, em grande parte por culpa da Oracle que mantém termos de uso confusos e fez anúncios parciais de suas políticas comerciais, e em parte por culpa da própria comunidade que, sem informações suficientes, acabou se desesperando.

Atualmente as informações estão mais claras, as políticas comerciais do Java estão declaradas e temos versões grátis ou pagas, dependendo do uso e da necessidade de atualizações.
Chegou o momento de decidir qual é sua estratégia para o futuro do Java na sua empresa ou nos seus projetos. Você já decidiu? Espero que esse material sirva de apoio, ou de ponto de partida para a criação de sua estratégia!

Caso queira discutir algum ponto, estou a disposição!

Att
Giuliano Bortolassi


Material de Referência
https://www.oracle.com/technetwork/java/javase/overview/index.html
https://openjdk.java.net/faq/ -
https://www.azul.com/products/zulu-enterprise/
https://medium.com/@javachampions/java-is-still-free-2-0
https://java.com/en/download/release_notice.jsp
https://blogs.oracle.com/java-platform-group/update-and-faq-on-the-java-se-release-cadence
https://developers.redhat.com/products/openjdk/overview/
https://access.redhat.com/articles/1299013?extIdCarryOver=true&sc_cid=701f2000001OH6kAAG - Consultado em 14/04/2019 - útimo update em 21/03/2019
https://access.redhat.com/articles/1299013?extIdCarryOver=true&sc_cid=701f2000001OH6kAAG
https://developers.redhat.com/products/openjdk/overview/

segunda-feira, 11 de agosto de 2008

Conversando sobre JEE parte 2

Como falei no artigo anterior (Conversando sobre JEE) a plataforma JEE da Sun já tem 11 anos de desenvolvimento e evolução. Hoje ela é uma plataforma robusta com uma especificação bem elaborada e com várias empresas que usam e investem na sua manutenção e criam produtos baseados na tecnologia JEE, como por exemplo a ORACLE, IBM, BEA que tem seus servidores de aplicação JEE.

O porque dessas empresas adotarem e apoiarem a plataforma JEE, provavelmente, deve-se ao fato de estarmos falando de uma plataforma aberta e robusta, com preocupação principal na compatibilidade entre os servidores e aplicações e as aplicações desenvolvidas para eles. Essa postura de “manter a compatibilidade” entre os softwares desenvolvidos para JEE torna a plataforma uma escolha agradável e acessível para os gerentes de TI, já que, optando pela plataforma JEE eles não ficam amarrados com nenhum vendedor em específico.

No entanto, para que essa compatibilidade, e essa robustez da plataforma fosse alcançada, a Sun e o JCP tiveram, e ainda tem, diversos desafios a vencer. Um deles foi criar a especificação para implementação da plataforma, o que aconteceu na época do lançamento do JPE. De lá para cá a especificação da plataforma tem crescido juntamente com as tecnologias que ela vem agregando ao seu kit de ferramentas. Outro desafio era testar se todas as empresas que usavam a especificação JEE estavam realmente seguindo à risca o que foi especificado. Para isso a Sun lançou sua “implementação de referencia” e o “Kit de testes de compatibilidade” que podem ser usados para assegurar a compatibilidade de um produto com a plataforma JEE de maneira relativamente rápida e fácil. Outro trabalho desenvolvido não só pela Sun, mas por toda comunidade, foi a criação do J2EE Blueprints, que é um catálogo de “boas maneiras” (padrões de projeto) para o desenvolvimento de aplicações JEE.

Especificação JEE
A especificação JEE é um conjunto de documentos que explica como os servidores de aplicação e as implementações de algumas tecnologias (como JSF por exemplo) devem ser desenvolvidas por empresas que o queiram fazer. Essas especificações chegam a nível de “métodos”, ou seja, existem documentos e “interfaces” Java publica que os “implementadores de JEE” devem seguir para que seus produtos sejam considerados compatíveis com JEE.
Esses documentos podem ser encontrados no site da Sun, mais especificamente no seguinte link: http://java.sun.com/javaee/reference/


Implementação de referencia
A Sun, juntamente com as especificações libera as “implementações de referencia”, que são bibliotecas que “concretas” que implementam as interfaces documentadas. Podemos encontrar as implementações de referencia no site da Sun, no seguinte link: http://java.sun.com/javaee/technologies/. Cada tecnologia listada tem sua implementação e os manuais de como utilizá-las. O Glassfish, que é o servidor de aplicação de “referencia” da Sun já traz, no seu download, a maioria das implementações de referencia das demais tecnologias.

Kit de testes de compatibilidade (CTS e AVK)
O CTS (Compatibility Test Suit) é um conjunto de aplicações que servem para testar se um Servidor de Aplicação é compatível com a especificação JEE atual. Se o conjunto de testes for bem sucedido quando executado em um determinado servidor de aplicação, esse servidor pode receber o selo de “J2EE Compatível”, sendo assim, as aplicações que usam as bibliotecas JEE funcionarão perfeitamente nesses servidores.

O AVK (Application Verification Kit) é um kit de testes, semelhantes ao CTS, mas para ser executados nas aplicações. Esse kit garante que a aplicação não tem nenhum código específico, ou seja, nenhum código que fuja da especificação JEE, garantindo assim que a aplicação desenvolvida seja portável entre todos os servidores que passem no teste CTS.
Até a versão 1.4 (J2EE) do AVK, as aplicações que passavam nessa bateria de testes poderiam fazer parte do programa “Java Powered for the Enterprise brand”, mas a partir da versão 1.5 ou 5.0 (JEE) esse programa será descontinuado. Para mais informações acesse: http://java.sun.com/j2ee/verified/program.html

Para saber detalhes de como os testes funcionam, e para baixar os kits de testes, acessem o seguinte link: http://java.sun.com/j2ee/verified/avk_enterprise.html

J2EE Blueprints
O J2EE Blueprints é um catalogo de “padrões de projeto” para o uso com a plataforma J2EE. Os padrões de projeto (design patterns) são soluções para problemas comuns que foram testadas, e, verificando-se sua eficiência e possibilidade de reuso, catalogadas e tomadas como “boas maneiras” para se desenvolver softwares.

Existem diversos “padrões do projetos”, muitos desenvolvidos pelo GoF (Gang of Four), mas o J2EE Blueprints trata de um conjunto de padrões específicos para aplicações J2EE. Esse catálogo pode ser encontrado em (http://java.sun.com/reference/blueprints/) . Existe também a versão impressa, o livro chama: Core J2EE Patterns: Best Practices and Design Strategies, existindo também uma versão em portugês. Na minha opinião, qualquer um que queira trabalhar profissionalmente com JEE deveria conhecer os padrões do livro, e estar atento para utiliza-los no projeto que irá/está desenvolvendo.


Podemos notar que os desenvolvedores da plataforma JEE preocupam-se em fazer algo que siga o principal objetivo do Java: Escreva uma vez, use sempre! Ou seja, Portabilidade! Não a portabilidade entre sistemas operacionais ou entre dispositivos diferentes, mas acima disso, a portabilidade entre servidores e aplicações!!
Quais os benefícios disso?
Pensando como gerente de TI: Utilizando a plataforma JEE podemos criar aplicações que sejam portáveis entre diversos servidores, e que possam se comunicar com outras aplicações de forma padronizada, diminuindo drasticamente o “custo” no que se diz respeito a testes numa possível troca de ambiente (servidores, etc) ou em testes de integração entre aplicações. Temos uma plataforma aberta, sem medo de que derrepente um fabricante suba o preço ou pare de dar suporte a algum produto do qual dependemos. Na pior das hipóteses, temos toda a “receita” de como criar nosso próprio servidor de aplicação.
Pensando como Programador: Temos uma plataforma completamente documentada, sem perigo de encontrar “armadilhas”. Podemos escolher qual servidor usar para desenvolver sem deixar nosso ambiente pesado (optar por desenvolver em servidores lightweight no ambiente de desenvolvimento), podemos compartilhar componentes com pessoas da comunidade JEE sem se preocupar com compatibilidade nem ter que ficar explicando nos mínimos detalhes como nosso componente funciona já que todos estarão falando a mesma linguagem!

Na sequencia da conversa vamos ver como é a estrutura de uma aplicação JEE e vamos entrar em detalhes mais técnicos!

Abraços!