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

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

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

Conhecendo o JEE - Part1

Um pouco de teoria

Hoje vou tentar explicar um pouco sobre o que é e como está organizada a plataforma JEE. Andei lendo um pouco a especificação da SUN sobre o JEE para não falar besteiras aqui, e claro, para aprender mais também. Caso alguem tenha vontade de ler a especificação, o link é o seguinte:

http://jcp.org/aboutJava/communityprocess/pr/jsr244/


Vou começar pela definição do próprio site da SUN:

Java Platform, Enterprise Edition (Java EE) is the industry standard for developing portable, robust, scalable and secure server-side Java applications. Building on the solid foundation of Java SE, Java EE provides web services, component model, management, and communications APIs that make it the industry standard for implementing enterprise class service-oriented architecture (SOA) and Web 2.0 applications. (Fonte: http://java.sun.com/javaee/ )

Como a Sun mesmo diz, o JEE é um "standard" ou seja, um padrão, uma especificação, uma "maneira de desenvolver", que deveria servir de modelo para o desenvolvimento de aplicações portáveis, robustas, escaláveis e seguras... (quanto ao "server-side" vou falar mais tarde).

O que seria esse padrão?

Todos ja devem ter ouvido falar dos "design patterns" e do "GoF" né? Se não ouviram, está na hora de estudar a respeito (veja links de referencia no final do post). Os Design Patterns são soluções para problemas cotidianos que foram elaboradas por "experts" em arquitetura de software e OO para serem o mais eficiente possíveis (des de que usadas corretamente), e assim poupar os demais desenvolvedores de "reinventar a roda" toda vez que se deparam com um problema.
Acredito que os "criadores" do JEE devem ter seguido uma linha de raciocínio semelhante. Com a demanda da criação de aplicações distribuidas, de grande porte e com necessidade de segurança/escalabilidade crescentes, cada grupo de empresas devia estar criando sua própria maneira de resolver esses problemas. Vendo isso, um grupo de desocupados (hehehe brincadeira) deve ter sentado e pensado nas situações mais relevantes nesse cenário coorporativo e criado "patterns" (soluções prontas) para resolve-los. Fizeram um documento por escrito, e bla bla bla até que surgiu a primeira especificação do JEE.

Não sei se foi assim mesmo, não fui pesquisar na história do Jee tão a fundo para saber quem teve a idéia de criar, ou como foi criado, mas não deve fugir muito dessa linha, o importante a ressaltar é que o JEE teve alguns problemas no inicio... era muito complicado (ou os caras que desenvolveram o JEE era muito inteligentes, ou o restante da comunidade java era muito burra ou preguiçosa para aprender JEE e usa-lo). Com o tempo a especificação veio mudando, mudando e hoje ela já se tornou bem "lightweight" (hehehe cansei de ler isso na internet, resolvi usar tambem).

Vem ai mais um trecho direto da fonte:

Características de uma aplicação JEE 5 segundo a especificação da JCP

•Highly available, to meet the needs of today’s global business environment.
•Secure, to protect the privacy of users and the integrity of the enterprise.
•Reliable and scalable, to ensure that business transactions are accurately and promptly processed. ( Fonte: JSR-000244 - Review: 8 August 2005 )

As características que essa versão da especificação prega são as citadas acima:

• Alta Disponibilidade: Aplicações para missões criticas, aplicações que não podem parar, serviços que tem que estar funcionando 24h/7dias por semana
• Segurança: Os dados devem estar muito bem protegidos, tanto em relação a privacidade dos usuarios quanto a segurança das informações do "negocio".
• Confiável: Confiável se enquadra no principio de ser SEGURA e DISPONIVEL, ou seja, uma aplicações que você pode confiar (pois ela sempre vai funcionar quando voce precisa e suas informações estarão seguras com ela)
• Escalável: Uma aplicação que cresce seguindo a demanda do seu negocio. Isso quer dizer que: teoricamente, você poderia começar com uma aplicação "pequena" e conforma a necessidade fosse surgindo, bastaria você adicionar mais "maquinas/recursos" para suportar a demanda.

Bonito né? imagina uma aplicação assim... seria algo perto do ideal... eu ainda estou muito longe de conseguir desenvolver algo do tipo, mas, um dia eu chego lá...


Não quero me demorar muito no post porque post grande ninguem lê, e se lê acaba ficando cansado. Vou só postar o diagrama da arquitetura JEE aqui para que voces possam dar uma olhada nas tecnologias envolvidas, e no próximo post eu explico um pouco sobre cada "camada" do JEE mostrada no diagrama.

(Diagrama tirado da especificação jsr-000244)

Se vocês clicaram na figura, verão uma coisa interessante, que confunde muita gente: JavaEE roda em cima de JSE. Ou seja, jEE não é uma tecnologia nova, e sim uma especificação de uso da já existente JSE. "This is the point!" Java Enterprise Edition é uma maneira de se utilizar a Java Standard Edition. E outra coisa, a respeito do "Server-Side"... esse diagrama me deixa confuso... também entra no diagrama camadas que rodam do lado do "cliente", como applets e o chamado "Application Client Container". Li na especificação que eles tem a intenção de, num futuro próximo, criar alguns "padrões" para desenvolver aplicações que rodam do lado do cliente, mas por enquanto isso não é enfatizado, mas já está em planos, por isso deixo essa característica do JEE (ser uma aplicação do lado do servidor) um pouco de lado.

É isso, jEE é uma tecnologia nova dentro do mundo Java, está começando a ser difundida e logo acredito que vai "virar padrão para todo mundo"... até lá, vamos estudando para não ficar para traz!!

Abraços! Até a próxima.


Referências

---

Sun - http://java.sun.com/javaee/
JCP (Java Community Process) - http://jcp.org/aboutJava/communityprocess/pr/jsr244/

Links sobre Design Patterns

---

Wikipedia - http://en.wikipedia.org/wiki/Design_pattern_(computer_science), http://en.wikipedia.org/wiki/Design_Patterns

Continue

Que diabo é isso de JEE?

A primeira vez que ouvi falar de "Java Enterprise" nem existia ainda o termo JEE.. lembro que na época o então existente J2EE estava começando a ficar maduro e ser difundido. Isso foi em meados de 2003 se não me engano, num evento que aconteceu na capital (São Paulo). Acho que era algum dos JavaOne, ou Java Tech Day, sinceramente não lembro. Mas me lembro bem que, ao ler o prospecto da palestra me interessei muito pelo assunto, mas, ao escutar meia hora de explanação do palestrante já desisti. Fiquei perdido com tantos "Beans"... "Entity Bean" pra lá, "Session Bean" pra cá, "Connectors", "Delegates" e n outras coisas que ouvi me assustaram um pouco e me fizeram sair correndo do auditorio.

Minha primeira impressão do J2EE então foi essa: "Complicado demais para os meus objetivos, nunca vou usar nada assim! Isso é coisa que apenas sistemas de BANCOS e/ou MULTINACIONAIS usam..."

Talvez fosse mesmo, naquela época, e talvez não fosse só eu que pensava assim... juro que tentei pesquisar mais a respeito do j2EE, mas era necessário tanto arquivo XML, tanta interface e classes para fazer um "insert" num banco de dados que desisti...

Recentemente, em meados do ano passado (2006) voltei a pesquisar sobre j2EE... vi que não existia mais. A especificação j2EE tinha evoluido, assim como o java evoluiu, e se transformado em jEE. Vi que eles modificaram muita coisa, quase não se usa mais XML... os XML foram trocados por "Annotations" do java, que por um lado facilitam muito a configuração dos Beans. Os containers jEE ficaram mais leves, sugiram mais containers que ficaram mais faceis de configurar. Resumindo... jEE está ficando mais acessível a simples mortais como eu.

Bom.. falei falei e não falei nada.

Esse, por ser o primeiro post, também não tem o objetivo de trazer muita informação... espero pelo menos ter dado uma pincelada sobre o que EU penso sobre o jEE (pode ter muita gente que discorda, e quem sabe alguem concorde com minhas opiniões).

Nos proximos posts, vou tentar discutir a respeito de "O que é o JEE", "Para que usar JEE", "Preciso mesmo de usar JEE", e coisas do tipo... talvez até entre em detalhes técnicos, mas não é esse meu objetivo.

O objetivo mesmo é dar um ponto de partida para quem nunca ouviu falar de jEE, para que diferente de mim, não percam anos se escondendo dessa tecnologia, para depois perceber o quão interessante ela é.

Bom.. até logo!

Continue