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!

Continue

JEE, o que é Java EE

Acho que uma das coisas mais chatas quando estamos desenvolvendo um sistema comercial de grande porte é termos que nos preocupar em escrever lógica de serviço de infra estrutura (Leia-se LOG, Conexão com Banco de dados, Cache, etc) e de nos preocupar com aspectos do desenvolvimento que são repetitivos e genericos.

Esse tipo de preocupação, além de provavelmente não fazer parte do negócio para o qual estamos desenvolvendo o sistema, na maioria das vezes não agrega valor ao nosso sistema e é uma tarefa repetitiva ao longo do desenvolvimento, o que pode ser um esforço mal direcionado.
Pensando em resolver esses problemas, diversas empresas desenvolveram o que chamamos de Frameworks, que seriam “plataformas” de desenvolvimento que já implementam toda essa lógica repetitiva que não gostamos de implementar! Cada fabricante e cada Framework é focada em um determinado conjunto de regras de infra estrutura que resolve uma quantidade de detalhes de implementação.

Meu objetivo aqui é falar sobre a Plataforma Java Enterprise da Sun, que é um conjunto de especificação de frameworks que podem ser utilizadas juntas (ou não) para facilitar o desenvolvimento de nossos softwares coorporativos.

Especificação? Sim!

A Sun, em conjunto com o JCP (Java Community Process) desenvolve as especificações para a plataforma JEE (Java Enterprise Edition), e essa especificação é “aberta”, portanto qualquer empresa que se interesse pode desenvovler seus produtos (OpenSource ou não) seguindo essa especificação criada pelo JCP. Isso garante a portabilidade das aplicações desenvolvidas para a plataforma Java Enterprise. Então, você pode criar seu software de “locadora de videos” baseado em uma plataforma JEE e escolher de quem você vai comprar o servidor de aplicação, tendo a “certeza” de que sua aplicação vai ser portável entre os servidores.

Poxa, quer dizer então que a Sun não desenvolve a plataforma JEE?

Na verdade a Sun inventa a plataforma (em conjunto com o JCP) e atualmente ela tem liberado uma “implementação de referência” para cada especificação criada. Antigamente, quando a Sun lançou a JPE (Java Plataform for Enterprise, a predecessora da J2EE que é predecessora da JEE) em Abril de 1997, ela apenas produzia a especificação. No entanto, não existia uma maneira sólida de testar se os produtos criados por outros vendedores (ex. Oracle, BEA, etc) seguiam a especificação “à risca”.

Atualmente, quando sai uma especificação nova de alguma tecnologia que faz parte da JEE (discutirei essas tecnologias mais a fundo nos próximos posts) a Sun lança uma “implementação de referência”, que é um software implementando todas as funcionalidades que a especificação tras. Resumindo, se você desenvolver um software usando uma das tecnologias JEE e ele funcionar na implementação de referência, ele deve funcionar em um servidor comercial, se não funcionar é porque o vendedor daquele produto não está seguindo a especificação.
Outro problema que a JPE enfrentou foi a não sincronia das tecnologias especificadas.
Como assim?

Bom, a JPE inicialmente trazia a especificação para as seguintes tecnologias:
- EJB – Enterprise Java beans
- Servlet – Geradores de páginas HTML
- JNDI – Java Namming Directory
- (outras mais)

Imagine que, a equipe que desenvolveu a especificação do JNDI comece aprimorar essa especificação e criam um serviço de nomes muito mais estável e robusto, enquanto o pessoal que é responsável pelo EJB vai tirar ferias e esquece de pensar em melhorar a especificação. Qual seria o resultado? Teriamos uma especificação JNDI que poderia se tornar imcompatível com EJB. Uma outra plataforma que sofreu com problemas semelhantes foi a plataforma Eclipse. Antes do lançamento do projeto Europa, os plugins do eclipse evoluiam separadamente, e como existe muita dependência entre os plugins, eles acabavam se tornando imcompatíveis.

Atualmente, para cada distribuição do eclipse, é feito um controle dos plugins disponíveis para garantir essa compatibilidade e evitar muita dor de cabeça ao usuário. A Sun tomou essa mesma postura, e a partir da especificação J2EE já implementou um controle de versão e sincronia das tecnologias que fazem parte da plataforma Java Enterprise.

A plataforma JEE é uma plataforma que já tem 11 anos de história, e 11 anos de evolução contínua. Cabe lembrar que ela também não é proprietária, ou seja, não é a Sun que inventa as especificações ao seu “bel prazer”, existe um “consórcio” de empresas (o JCP) que decidem juntos as especificações, e disponibilizam essas especificações para quem quizer desenvolver.

Isso traz uma garantia para o desenvolvedor de que ele não vai ficar na “mão” de um único fabricante, nem amarrado a um software específico (ou seja, se o servidor de aplicação da oracle for muito caro, voce pode comprar o da RedHat, ou usar a “implementação de referência” da Sun, que é gratis e open source), o que pode ser uma grande vantagem para os “executivos” das empresas que escolhem adotar o Java como tecnologia de desenvolvimento. Para o Desenvolvedor a vantagem é enorme, já que ele tem uma plataforma padronizada e não precisa ficar se preocupando de quem a empresa vai comprar os servidores, além de ja poder usar um kit de ferramentas que implementam a maior parte da lógica de infra estrutura, ou seja, podem se focar apenas nos pontos importantes do software que estão desenvolvendo!

Nos próximos posts iniciarei uma discussão sobre a plataforma JEE atual, falando de uma maneira mais técnica sobre cada uma de suas tecnologias.

Abraços e até lá!
Giuliano Bortolassi

Continue

Reformulando

Caros,

fiz um curso de EJB3 recentemente. Aprendi muitas coisas, e finalmente consegui entender certinho como esse tal de EJB funciona e como fazer o deploy, acessar, e tudo mais! Agora sim vou conseguir agregar mais informações ao BLOG!!

Nessa semana estarei reformulando, tanto o layout do blog quanto o conteudo. Vou dar uma editada nos posts antigos, e já vou adicionar material sobre como fazer o deploy dos EJBs!!

É tudo muito mais simples do que parecia!!
:)

Peço que, se não encontraram o que queriam aqui, voltem em breve (semana que vem) que provavelmente terá conteudo interessante!

Abraços!
Giuliano Bortolassi


Querem saber sobre JEE? Gerencia de Projetos? meu Profile? Acessem http://giulianobortolassi.blogspot.com

Continue

Java Beans - Mais teoria

Antes de postar o exemplo prático, vou explicar algumas coisas, para o próximo post colocarmos des de o começo a mão na massa.
Segundo o tutorial oficial da Sun sobre jEE, Enterprise Java Beans (vou chama-los apenas de Beans até o final desse post) são componentes do lado do servidor que encapsulam a lógica da aplicação. Existem dois tipos principais de Beans, os beans de sessão e os beans orientados a mensagens.


Beans de Sessão

---

O que são Beans de Sessão?
Beans de sessão são componentes que estão ligados as chamadas de um usuário específico, ou seja, estão ligados a uma "conexão" com o servidor, conhecendo que é o usuário que está requisitando seus serviços.

Os benas de sessão podem ser divididos em dois tipos, Statefull e Statelless.

Stateful Bean: Esse tipo de bean, fica alocado para uma determinada sessão do cliente até que ela seja terminada. É um tipo de bean util para quando precisamos guardar o estado da seção, ou seja, quando a "operação" realizada pelo bean não termina em apenas uma chamada. Um exemplo prático disso seria um "wizzard" que vai executando ações passo a passo, ou mesmo um carrinho de compras.

Stateless Bean: Esse bean tem acesso aos dados da sessão de usuário que o está chamando, no entanto, esse estado é perdido quando sua "operação" terminar. O Stateless Bean não fica vinculado a uma seção específica, ele pode ser reaproveitado por outro usuário, sendo assim menos oneroso para o servidor. Em uma aplicação convencional, a maioria dos Beans são stateless, mas cabe a cada desenvolvedor determinar quando usar Stateful ou Stateless.


Beans Orientados a Mensagem (Message-Driven Beans)

---

Esses beans funcionam como listeners para serviços de mensagens, como a JMS (Java Message API). Não vou entrar em detalhes sobre serviços de mensagens agora, pois pretendo mais para frente, depois que já estivemos dominando os Session Beans dedicar um tempo apenas para falar sobre Mensagens.



Arquitetura de um EJB

---

Um EJB é composto por:

• Interface Remota
• Implementação do Bean

Interface Remota (Business Interface): A interface remota é uma Interface (considerando a definição de interface da linguagem java) que será a visualização que o cliente tem do nosso Bean. Somente os metodos definidos nessa interface estarão disponíveis para o cliente. A interface remota é desenvolvida seguindo os padrões de RMI, implementando a interface EJBObject (que por sua vez implementa a interface Remote do RMI).


Ex:

public interface HelloRemoteInterface extends EJBObject {

// Metodo que executa alguma coisa para o cliente
public String doSomething() throws RemoteException;

}

Com o uso de annotations ficou ainda mais simples implementarmos as interfaces remotas. Basta utilizarmos a annotation acima da interface:

Ex:

@Remote
public interface HelloRemoteInterface {

// Metodo que executa alguma coisa para o cliente
public String doSomething() throws RemoteException;

}

Implementação do Bean
A implementação do Bean nada mais é do que a lógica dos metodos definidos pela interface remota.
Pra criarmos o Bean, basta que implementemos a interface remota e criemos a logica pertinente a cada metodo. Tambem podemos usar Annotations para definir o Bean:

Ex.

@Stateless
public class HelloBean implements HelloRemoteInterface {

public String doSomething() {
return "Something done";
}

}

Bom.. essas são os dois componentes básicos de um JavaBean.

No próximo post já ensinarei como fazer o deploy de um bean no nosso servidor de aplicação, e tambem a criar os "descritores" do bean.


Até lá!

Continue

Instalando a Java Application Plataform

Após fazer o download de 160MB da plataforma de desenvolvimento da Sun, vamos tentar instala-la. Vou tomar como base a instalação do Windows, que, por acaso, deve ser o sistema operacional que a maioria usa.


Instalando o Servidor

---

A instalação básica é bem simples. O arquivo que baixamos é um instalador padrão do windows. Basta executarmos-o e ir seguindo os passos que são indicados, o famoso Next > Next > Next > Install. De qualquer forma, é interessante que prestemos atenção em alguns parametros que nos vão ser questionados:

Passo 1 – Usuário, senha e portas.

Usuario/Senha: Fique a vontade para alterar o usuário e senha da maneira que bem quizer, no entanto não esqueça esses dados, eles vão ser essenciais quando formos configurar detalhes do servidor!

Portas: Devemos prestar mais atenção aqui. Existem 3 portas a ser configuradas, a porta do administrador, dos serviços HTTP e HTTPS.

Administrador: é para essa porta que você deverá apontar seu brownser quando precisar acessar o painel administrativo do servidor. É nesse painel que mudamos configurações como o nome do domínio, drivers do banco de dados, fazemos o deploy de aplicações, etc.

HTTP Port: Essa é a porta por onde nossas aplicações web serão acessadas, é para ela que vamos apontar o brownser quando quizermos acessar nossas aplicações, algo mais ou menos assim: http://localhost:8080/minhaApplicacao/.

ATENÇÃO: Existem diversos servidores que por padrão vem configurados com a porta 8080 para serviços web. Um exemplo bom é o TOMCAT da apache.org. Caso o Tomcat já esteja instalado na sua máquina, pode ser que ocorram conflitos de porta. Recomendo que se for esse o caso, mudem o número da porta durante a instalação do appServer. Coloquem algo do tipo “9090”, “6666”, “7777” ou algo assim.

HTTPS port: Essa porta é utilizada quando nossas conexões tiverem que ser autenticadas via SSL. Acho que não vem ao caso explicar isso agora, não pretendo tratar de SSL tão cedo.

Passo2: Opcionais

No passo dois, recomendo que deixem apenas selecionado a opção “Add bin directory to PATH”. Isso nos economiza muita dor de cabeça, pois o sistema de instalação já seta no nosso PATH do windows o diretorio com todas as ferramentas que serão instaladas.

Passo3: Add-ons

Nessa etapa da instalação, aconselho que sejam selecionadas todas as opções diponíveis. São serviços extras que vamos instalar no nosso servidor. Pode ser que não os usemos agora, mas garanto que é muito mais difícil instalá-los caso um dia venhamos precisar deles do que já deixá-los instalados por precaução.

Agora clique em next, depois em install, e espere terminar a cópia dos arquivos. No final da instalação não clique em “Start Server”, vamos fazer isso manualmente.

Iniciando e Testando o Servidor

---

Depois de concluir a instalação, no windows, existe uma maneira bem simples de iniciar o servidor, basta irmos em “Iniciar -> Programas -> Sun Microsistems -> Application Server -> Start Default Server”.

A outra maneira, que é padrão para todas as plataformas, é iniciar o server por linha de comando. Para isso basta que executemos o comando:

> asadmin start-domain

No nosso caso, como estamos usando uma instalação padrão, e o nome do dominio padrão é “domain1” o comando ficaria assim:

> asadmin start-domain domain1

Aparecerão algumas mensagens no console, e caso não apareça nenhum erro a seguinte mensagem deve ser a ultima a aparecer:

Domain listens on at least following ports for connections:
[8080 8181 4848 3700 3820 3920 8686 ]

Obs: se você selecionou a opção “add bin dir to path” na instalação, esses comandos poderão ser executados de qualquer lugar no seu micro (qualquer diretorio) caso contrário, basta que você execute os comandos da seguinte pasta:

“InstallDir/bin”.

Se você usou o diretório padrão do programa de instalação, então deve ser a seguinte pasta:

“C:\Sun\SDK\bin”

Pronto, o server está iniciado e rodando. Para testarmos, basta apontarmos nosso brownser para o seguinte endereço:

http://localhost:NumeroDaPorta/

Obs: essa porta, por padrão é a porta 8080, a que eu recomendei que fosse alterada na hora da instalação. Caso você não tenha alterado, o endereço é o seguinte:

http://localhost:8080/

A primeira chamada ao servidor é um pouco demorada, não se assuste. Depois de alguns minutos de espera você verá uma pagina dizendo que o servidor está rodando e pronto! ( Your server is up and running!)

Outra coisa importate. Como parar o servidor? Esse servidor é um pouco pesado, realmente, ele ocupa cerca de 200MB de memoria ram para rodar (isso sem estar com nenhuma aplicação em funcionamento). Provavelmente ele vai fazer uma diferença grande no desempenho de sua maquina quando você quizer utiliza-la para outras coisas (como por exemplo para jogar Half-Life, Need for Speed ou mesmo o World of Warcraft). Então, temos que dar um jeito de parar o servidor e liberar os recursos de nossa maquina quando quizermos. O comando para parar o servidor é bem semelhante ao comando que usamos para inicia-lo:

> asadmin stop-domain

no nosso caso:

> asadmin stop-domain domain1

Documentação Adicional

Caso você quiera mais detalhes sobre o processo de instalação, visite o guia oficial de instalação em:

http://docs.sun.com/app/docs/doc/819-3657

Depois de instalado o servidor, toda a documentação de apoio estará em “\docs” ou no nosso caso “C:\Sun\SDK\docs”

É isso ai. Já temos um ambiente mínimo para rodar nossas aplicações jEE. Agora aguardem que nos próximos posts trarei alguns exemplos práticos!

Até lá!

Continue

Nos preparando para por a mão na massa

Mas que dia... hoje o dia não foi dos melhores. Não consegui nem encontrar tempo direito para pensar e escrever algo.
Mas como não poderia deixar de postar, aqui vai uma rapidinha.

Estive pensando seriamente em como continuar a linha de raciocínio do blog. Um amigo me sugeriu que seria bem interessante ensinar o pessoal como configurar o ambiente de desenvolvimento. Também vi que só teoria acaba ficando massante. Muito mais funcional é ensinar já com exemplos práticos.

O problema com jEE é que fica complicado já sair para a prática sem construir uma base sólida sobre o que é essa tecnologia. Para que quem acompanha o blog não desanime, vou seguir a seguinte linha: Primeiro vou falar um pouco sobre uma determinada tecnologia (EJB, WEB, Desktop, Applet) e depois vou tentar mostrar alguma coisa prática a respeito.

No entanto, para isso, precisamos ter um ambiente configurado para podermos testar os exemplos. Que coisa né? praticamente um circulo vicioso.

Decidi que nos próximos posts vou falar então sobre a configuração do ambiente JEE, das bibliotecas necessárias, de onde baixa-las e de como faze-las funcionar. Acho que isso vai consumir alguns posts, pois são muitos detalhes. No entanto é imprescindível termos um ambiente mínimo para podermos rodar alguns exemplos.

No próximo post vou ensinar como instalar e configurar um servidor de aplicação JEE, o Glassfish, que é o servidor jEE da Sun.

O Glassfish pode ser encontrado para download no site da Sun (http://java.sun.com) e é gratúito.

O site não é muito "intuitivo" em relação a qual pacote você deve baixar. Recomendo que entrem nesse link:
http://java.sun.com/javaee/downloads/index.html

Escolham a opção "Java Application Platform SDK Update 2" - "Download with JDK", escolham a plataforma de acordo com o seu sistema operacional e façam o download... o download é meio pesado, cerca de 160MB mas compensa, ele tem quase tudo que vamos precisar.

Depois de configurado o ambiente vou abordar um pouco mais sobre EJBs (EJB3) e então poderemos fazer nosso primeiro EJB!

Até lá!

Continue

Conhecendo o JEE – Part2

Como prometido, o post de hoje será a respeito do diagrama estrutural do JEE mostrado no tópico anterior.

Segue ele aqui para refrescar a memória:

(clique na imagem para ve-la maior)

A especificação JEE define quatro tipos de “containers” ou “plataformas” ou simplesmente “componentes” ( como é citado na especificação ) que um produto JEE deve suportar.

Application Cliente

---

São programas, desenvolvidos em java, que rodam diretamente na máquina do usuário. Podem ser desenvolvidos com o SWING, AWT ou outra tecnologia desktop. Esses programas tem por característica proporcionar uma “user experience” semelhante a dos programas nativos da plataforma utilizada pelo usuário, mas com acesso a todas as facilidades da camada intermediária do JEE.

Applet

---

Applets, para quem não sabe, são pequenos aplicativos java que rodam, normalmente, dentro do brownser (existem outras aplicações, que não brownsers, que também dão suporte a applets). Eu fiquei um bom tempo sem ouvir falar de Applets. Sinceramente, é uma tecnologia que eu não costumo ouvir falar muito, no entanto, dizem por ai (a especificação JEE fala) que eles podem proporcionar uma interface com o usuário muito rica, muito mais rica que as páginas HTML convencionais. Particularmente, com o surgimento do Ajax, do DHTML e com o uso do FLASH, eu negaria essa afirmação. Tudo bem que com um Applet você consegue ter acesso as funcionalidades da linguagem java, utilizar objetos do JEE e tudo mais, mas eu não concordo com a parte da “interface rica”.

Web Container (Web Server)

---

É um servidor que fornece suporte as tecnologias JSP, Servlets, que utiliza conceitos como “filters” e web event listeners (como interceptors, etc), recursos esses chamados de “web components”.
Um servidor web, ou melhor, um Container Web bem conhecido é o Tomcat da Apache.org (http://tomcat.apache.org) que é um servidor “lightweight” (leve) com a maioria das funcionalidades que um dia você possa precisar.
Resumindo, um Web Container tem que ser capaz de aceitar requisições HTTP de um cliente web (pode ser um brownser ou qualquer outro cliente) interpretar essa requisição, fazer chamada aos “web components” configurados no container, e gerar uma resposta para o client web. Essa resposta pode ser uma pagina HTML ou até mesmo um WebService.

Enterprise Java Beans

---

Enterprise Java Beans, ou EJB como são mais conhecidos, são executados em um ambiente controlado (container EJB) e normalmente concentram a “lógica de negocio” de uma aplicação JEE. Esses objetos por si só, fornecem acesso a suas funcionalidades atravéz de WebService, utilizando o padrão SOA ou HTTP requests mesmo. EJB talvez seja a coisa mais útil e mais chata de se trabalhar quando falamos de JEE. Vou dedicar, logo logo, um tópico todo apenas para falar de EJB. Por enquanto, basta sabermos que eles são objetos que fornecem serviços e são auto-contidos. Com "auto-contidos" quero dizer que um EJB funciona independente de outros EJBs, fornecendo um serviço específico, como por exemplo: Envio de e-mails, consulta a um banco de “clientes”, geração de pedidos, etc. Também é interessante percebermos que todas as outras camadas do JEE podem fazer uso dos EJBs. Você pode ter uma aplicação desktop que instancie um EJB para gerar pedidos, ou ter uma aplicação web que utilize de um EJB para enviar e-mails de notificação aos administradores do site, etc.

Ainda no diagrama, vemos que existem setas apontando de um componente para outro. Essas setas indicam as chamadas que um componente faz ao outro. Por exemplo, no caso do “Client Application", ele pode utilizar (fazer chamadas) tanto a um Web Container, como a um EJB Container. Mas se você reparar, o EJB Container é o único que funciona independente de outros componentes. O EJB não utiliza nenhuma outra camada, ou componente JEE para funcionar, (no diagrama ele acessa apenas o Banco de Dados), ele é “auto-contido” como eu citei acima. Devido a essa independência, muitos autores dizem que EJB é a base de qualquer aplicação JEE.

Eu não concordo 100% com essa afirmação ( de que EJB é a base ), mas vou deixar isso para discutir logo logo.

Por enquanto é isso, espero ter dado uma visão geral dos quatro componentes básicos utilizados pelo jEE, volto logo com informações mais específicas sobre cada um deles.

Até Breve!

Continue