Conceitos: Visão Geral do J2EE (Java 2 Platform Enterprise Edition)
Tópicos
Introdução
No mundo atual de e-business acelerado com aplicativos distribuídos complexos,
é crítico que seus aplicativos corporativos sejam trazidos ao mercado rapidamente.
Isso significa que sua equipe de projetos não pode perder tempo no desenvolvimento de serviços em nível
de sistema, como gerenciamento de conectividade remota, nomenclatura, persistência, segurança ou
transação. Ela precisa desenvolver e utilizar componentes portáveis e
reutilizáveis; você não quer perder tempo reinventando arquiteturas testadas e reais.
O J2EE™ (Java™ 2 Platform, Enterprise Edition) trata dessa
necessidade, fornecendo uma estrutura bem documentada, com base em padrões, para o desenvolvimento
e execução de aplicativos Java distribuídos, multicamada, com base no componente. Essa
estrutura manipula boa parte da complexidade de nível inferior do aplicativo, como
gerenciamento de conectividade remota, nomenclatura, persistência, segurança ou transação,
deixando os desenvolvedores livres para concentrar-se na lógica de negócios do aplicativo.
A plataforma J2EE consiste em:
- Um conjunto de padrões para componentes J2EE e na plataforma J2EE na qual os
componentes são executados.
- Uma cópia de projeto para o desenvolvimento de aplicativos que descreve a plataforma J2EE
em detalhes, fornecendo informações de poder industrial com as boas práticas sobre como
desenvolver aplicativos J2EE.
- Uma implementação de referência da plataforma J2EE fornecida pela Sun Microsystems
Inc. como um padrão em relação à qual é possível medir os produtos J2EE comerciais.
A implementação de referência inclui aplicativos de amostra totalmente desenvolvidos.
- Um conjunto de teste de compatibilidade para testar e avaliar as implementações comerciais do J2EE
em relação aos padrões J2EE.
A plataforma J2EE é semelhante aos serviços fornecidos pelo sistema operacional
do computador. Utilizando ferramentas de programação, o sistema operacional fornece
serviços padrão sobre os quais é possível desenvolver e executar aplicativos
sem preocupar-se com o gerenciamento de nível inferior de acesso ao disco, memória, saída de
vídeo, sistema em rede, etc. O que conta são os detalhes de seu
aplicativo, não os detalhes do sistema de base. A Plataforma J2EE fornece
um sistema operacional sofisticado para aplicativos corporativos.
Com a plataforma J2EE, a tentativa de desenvolvimento é simplificada, permitindo à
equipe de projeto focar sua energia na lógica de negócios real do aplicativo,
em vez de gastar tempo de desenvolvimento crítico na solução de questões em nível de sistema. Uma
equipe de projeto cujo foco está no que o aplicativo faz e não em
como entregar todos os serviços subjacentes necessários pelo aplicativo,
provavelmente entregará um sistema adequado, sem erros, que atende aos requisitos
do usuário.
Para obter informações adicionais, consulte a visão geral da Plataforma J2EE da Sun em http://java.sun.com/. Siga os links para Products
& APIs > Java™ 2 Platform, Enterprise Edition (J2EE™) >
Overview.
Desenvolvimento do J2EE em Resumo
De uma perspectiva do desenvolvedor de aplicativos:
- Você compra uma plataforma J2EE comercial na forma de um servidor que esteja em conformidade
com o J2EE. O comportamento do servidor J2EE é especificado pelo padrão J2EE.
- Você desenvolve ou compra componentes J2EE diretamente da loja.
- Você implementa e executa os componentes J2EE no servidor que esteja em conformidade
com o J2EE, o qual fornece todos os serviços necessários pelos componentes J2EE.
Exemplo

Um exemplo simples de aplicativo J2EE é um site de e-commerce, no qual um cliente
(usuário) utiliza um navegador da Web para acessar remotamente um servidor J2EE. O servidor J2EE
fornece serviços na camada da Web e na camada de
negócios, além de interagir com uma camada do Enterprise Information
Systems (backend) que fornece acesso ao RDBMS.
Por que Utilizar o J2EE?
A plataforma J2EE poderá ser utilizada para desenvolvimento dos aplicativos de e-commerce ou
Corporativos Java, se um desses objetivos se aplicar:
Cada um desses pontos é discutido detalhadamente no restante desta seção.
Estrutura Padronizada Testada pelo
Segmento de Mercado
Os componentes J2EE são executados em contêineres J2EE,
fornecidos normalmente como parte de um servidor que esteja em conformidade com o J2EE. Esses contêineres fornecem
um conjunto de serviços padrão (APIs) utilizados pelos componentes J2EE. As APIs são:
- J2SE 1.4
- JDBC
- Java IDL
- RMI-IIOP (Remote Method Invocation with Internet Inter-ORB Protocol do CORBA)
- JNDI (Java Naming and Directory Interface)
- JAAS (Java Authentication and Authorization Service)
- JTA (Java Transaction API)
- JavaMail
- JMS (Java Message Service).
Para obter informações adicionais sobre o JMS, consulte Conceitos: Java Messaging Service.
- JAF (JavaBeans Activation Framework)
- EJB (Enterprise JavaBeans)
- Java Servlet
- JAXP (Java API for XML Processing)
- Java Connector (Nota: não suportada antes do J2EE 1.3)
- JSP (JavaServer Pages)
- Web Services para J2EE (Nota: não suportada
antes do J2EE 1.4)
- JAX-RPC (Java API for XML-based RPC) (Nota:
não suportada antes do J2EE 1.4)
- SAAJ (SOAP with attachments API for Java) (Nota:
não suportada antes do J2EE 1.4)
- JAXR (Java API for XML Registries) (Nota: não
suportada antes do J2EE 1.4)
- J2EE Management (Nota: não suportada antes
do J2EE 1.4)
- JMX (Java Management Extensions) (Nota: não
suportada antes do J2EE 1.4)
- J2EE Deployment (Nota: não suportada antes
do J2EE 1.4)
- JACC (Java Authorization Service Provider Contract for
Containers) (Nota: não suportada antes do J2EE 1.4)
Os componentes e aplicativos J2EE são portáveis entre os servidores que estejam em conformidade com o J2EE,
sem a necessidade de modificações no código, para permitir a implementação de aplicativos
no servidor de sua escolha que esteja em conformidade com o J2EE, simplesmente pela atualização das informações de
implementação específicas do servidor contidas nos arquivos XML (eXtended Markup Language) do descritor de implementação.
A padronização da especificação J2EE tem levado à competição no segmento de mercado - você
tem opções de servidores que estejam em conformidade com o J2EE, de acordo com suas necessidades e orçamento.
Componentes Reutilizáveis
Por serem compatíveis com o padrão J2EE, os componentes J2EE podem ser comprados diretamente da loja
e conectados ao aplicativo J2EE conforme necessário, poupando tentativa de desenvolvimento (especialmente
na depuração e teste).
Se você desenvolver um componente, poderá reutilizá-lo em outro aplicativo ou implementá-lo
em servidores diferentes que estejam em conformidade com o J2EE, conforme necessário.
Padrões de Arquitetura
e Design Testados e Reais
A plataforma J2EE define uma arquitetura de aplicativo com multicamadas bem estruturada. Alavancando
fora da arquitetura J2EE, seus desenvolvedores podem continuar rapidamente a
desenvolver a lógica de negócios real do aplicativo.
A documentação do J2EE inclui:
- Uma cópia de projeto para o desenvolvimento de aplicativos que descreve a plataforma J2EE
em detalhes, fornecendo informações com as boas práticas sobre como desenvolver aplicativos J2EE.
- Padrões J2EE bem documentados com as boas práticas do segmento de mercado que descrevem
soluções para problemas de arquitetura e design comuns do J2EE.
Para obter informações adicionais sobre a Plataforma J2EE, consulte http://java.sun.com/.
Siga os links para J2EE > Blueprints.
Escalabilidade
O J2EE suporta escalabilidade para aumentar o desempenho ou para atender ao aumento nos carregamentos
de várias maneiras:
- Recursos de aperfeiçoamento de desempenho no contêiner J2EE - esses
recursos incluem um conjunto de recursos (pool de conexão com o banco de dados, conjunto de
instâncias do bean de sessão e conjunto de encadeamentos), transmissão de mensagens assíncronas e gerenciamento
eficiente do ciclo de vida do componente. Por exemplo, a abertura de uma conexão com o banco de dados
é lenta. Além disso, as conexões com o banco de dados poderiam ser um recurso incomum em razão, por exemplo,
das restrições de licença. Isso é gerenciado pela plataforma J2EE utilizando o pool de
conexão com o banco de dados - o contêiner J2EE mantém um conjunto de conexões abertas
que podem ser designadas a um componente conforme necessário, resultando em conexões rápidas e
eficientes.
- O equilíbrio de carga pode ser alcançado pelo armazenamento em cluster - implementando os
mesmos componentes para vários servidores em máquinas diferentes. O carregamento para cada
um dos servidores pode então ser compensado conforme necessário; por exemplo, de acordo com
um algoritmo round-robin ou de acordo com o carregamento do servidor. A especificação da plataforma J2EE
não requer o recurso de equilíbrio de carga em um servidor J2EE, mas sugere
que um servidor high-end o tenha. Os fornecedores do servidor J2EE oferecem várias soluções de
equilíbrio de carga.
- Particionamento de aplicativo - partes de um aplicativo distintas logicamente
podem ser implementadas para servidores diferentes; por exemplo, implementar subsistemas
de inventário e contabilidade do aplicativo de pedido de correio on-line para servidores separados.
Ferramentas de Desenvolvimento e
Implementação
Os fornecedores têm respondido à necessidade de ferramentas J2EE, fornecendo suporte excelente
para o desenvolvimento de J2EE em seus IDEs (Integrated Development Environments) Java,
incluindo:
- Assistentes para a criação de servlets
- Assistentes e diálogos para a criação e manutenção de EJBs
- Geração e manutenção do descritor de implementação
- Mapeamento de objetos EJB para bancos de dados (incluindo a geração de informações do descritor
de implementação para relacionamentos gerenciados por contêiner)
- Integração com um contêiner de Web para testar serviços da Web
- Implementação, depuração e teste de EJBs perfeitas no IDE pela integração com
um contêiner EJB do J2EE e suas ferramentas de implementação
- Geração automática de clientes de teste do J2EE
- Integração com ferramentas de modelagem da UML
Integração de Backend
O backend refere-se à camada do EIS (Enterprise Information System) do
aplicativo. Os sistemas de backend podem ser, por exemplo, RDBMS, sistemas legados ou
ERPs (Enterprise Resource Planning Systems).
O J2EE suporta acesso transacional aos EISs do RDBMS utilizando as APIs JDBC e JTA.
Além disso, os contêineres EJB suportam a persistência gerenciada por contêiner, na qual
a conexão e o acesso transacionais do RDBMS são manipulados automaticamente pelo contêiner.
O J2EE Connector Architecture SPI (Service Provider Interface) define um padrão
para a conexão de recursos não RDBMS do EIS a um contêiner J2EE. Um adaptador de recursos
específico do EIS (fornecido pelo fornecedor do EIS) é conectado ao contêiner J2EE,
estendendo o contêiner para que forneça suporte transacional seguro para
esse EIS. Os componentes no contêiner podem então acessar o EIS por meio do J2EE
Connector Architecture SPI.
Nota: O J2EE Connector Architecture SPI não é suportado antes do J2EE
1.3.
Segurança
O J2EE fornece recursos de segurança simples e eficazes. As informações de segurança para
componentes J2EE são definidas em seus descritores de implementação. Essas informações
definem quais funções de segurança têm autorização para acessar um determinado URL
e/ou métodos de um componente. Uma função de segurança é simplesmente um nome lógico para
um agrupamento de usuários; por exemplo, os membros da equipe de gerenciamento de uma organização
poderiam ser designados com uma função denominada "managers".
Como as informações de segurança são declaradas no descritor de implementação, o
comportamento de segurança pode ser alterado sem um ciclo caro de atualização-depuração-teste
de código.
Arquitetura Multicamada
O J2EE é uma arquitetura de aplicativos distribuída multicamada que consiste em
uma camada de cliente, uma camada central e
uma camada do EIS ou de backend.
A Figura 1 mostra a arquitetura multicamada da plataforma J2EE, assim como
os vários contêineres J2EE que suportam os componentes J2EE.

Figura 1: Arquitetura Multicamada
do J2EE
Camada de Cliente
Os componentes da camada de cliente são executados em contêineres do cliente. A camada de cliente pode ser implementada
assim:
- Aplicativos Java Independentes - geralmente
uma GUI (também conhecida como "cliente espesso"). Esse aplicativo Java
deve ser instalado em todas as máquinas clientes. Um aplicativo Java pode acessar a
camada do EIS ou a camada central por meio de APIs, como JDBC.
- Páginas HTML estáticas - fornecem uma GUI limitada
para um aplicativo.
- HTML dinâmico - gerado por páginas JSP ou servlets.
- Applets - executados em um navegador da Web. Os applets são
incorporados em uma página HTML e normalmente utilizados para fornecer uma GUI.
Camada Central
A camada central consiste na camada da Web e na camada de negócios. Os componentes da camada da Web são executados em um servidor da Web
do J2EE que fornece um contêiner de Web. Os componentes
da camada de negócios são executados em um servidor de aplicativos J2EE
que fornece um contêiner EJB.
Camada da Web 
Os componentes da camada da Web incluem servlets e páginas JSP que gerenciam a interação com a
camada de cliente, isolando os clientes das camadas de negócios e do EIS. Os clientes
fazem pedidos da camada da Web, o que processa os pedidos e retorna os
resultados para o cliente. Os pedidos do cliente para componentes na camada da Web geralmente
resultam em pedidos da camada da Web para componentes na camada de negócios que, por sua vez,
podem resultar em pedidos para a camada do EIS.
Camada de Negócios 
Os componentes da camada de negócios são os EJBs.
- Eles contêm a lógica de negócios do aplicativo.
- Eles fazem pedidos para a camada do EIS de acordo com a lógica de negócios, normalmente
em resposta a um pedido da camada da Web.
Camada do EIS
A camada do EIS representa os dados armazenados do aplicativo, freqüentemente na forma de
um RDBMS. Ela também pode consistir em sistemas legados ou ERPs, acessados
por meio da API J2EE Connector Architecture.
Para obter informações adicionais sobre a API J2EE Connector Architecture, consulte http://java.sun.com/. Siga os links para
Products & Technologies > J2EE > J2EE
Connector Architecture.
Para obter informações adicionais sobre as configurações de implementação padrão do J2EE, consulte Conceitos: Configurações de Implementação do J2EE.
Servidores J2EE 
Os servidores J2EE são produtos comerciais que implementam a plataforma J2EE. Exemplos
de servidores J2EE comerciais são BEA WebLogic, Borland Enterprise Server, IBM
WebSphere e iPlanet.
O uso da terminologia "servidor J2EE" é um pouco vaga. Geralmente,
o que se quer dizer é "um servidor J2EE que suporta um contêiner de Web e um
contêiner EJB". Utilizando uma terminologia mais rígida, um servidor da Web do J2EE (como o
Tomcat de implementação do servidor da Web de referência do J2EE) suporta um contêiner de Web; um
servidor de aplicativos J2EE (ou EJB) suporta um contêiner EJB.
Contêineres J2EE 
Os componentes J2EE são executados ou hospedados pelos contêineres
J2EE geralmente fornecidos como parte de um servidor J2EE comercial. Os contêineres
fornecem um ambiente de tempo de execução e um conjunto padrão de serviços
(APIs) para os componentes J2EE executados no contêiner, além de suportar
as APIs do J2SE padrão.
O J2EE define os seguintes tipos de contêineres:
Contêiner do Cliente Aplicativo
Um cliente aplicativo J2EE
é executado em um contêiner do cliente aplicativo que suporta estas APIs do J2EE: JDBC,
JMS, JAXP, JAAS, JavaMail, JAF, JSR, JAX-RPC, SAAJ, J2EE Management e JMX.
De fato, os contêineres do cliente aplicativo consistem na
instalação do J2SE padrão. O contêiner do cliente aplicativo deve suportar
a interface de rotina de tratamento de retorno de chamada JAAS para atender as limitações de segurança do
restante do aplicativo corporativo nos contêineres de Web e EJB.
Contêiner do Applet
Um applet é executado em um contêiner do applet,
que suporta o modelo de programação do applet e as APIs do J2SE padrão.
De fato, os contêineres do applet são fornecidos como o plug-in Java para um navegador da Web.
Contêiner de Web
Os componentes da Web (páginas
JSP e servlets) são executados em um contêiner de Web
fornecido como parte de um servidor J2EE ou fornecido como um servidor da Web independente do J2EE.
Um contêiner de Web suporta as seguintes APIs e pacotes do J2EE: JDBC, JMS, JAXP,
JAX-RPC, JAXR, JAAS, Java Mail, JAF, J2EE Connector Architecture, JTA, JSR,
SAAJ, J2EE Management, Java Servlet e JSP.
Contêiner EJB
Os componentes EJB são executados em um contêiner EJB,
que é fornecido como parte de um servidor J2EE.
Um contêiner EJB suporta as seguintes APIs e tecnologias
do J2EE: EJB, JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, Java Mail, JAF, JTA,
JSR, SAAJ, J2EE Management e J2EE Connector Architecture.
As subseções a seguir resumem a funcionalidade-chave suportada pelos
contêineres EJB:
Comunicações Remotas

Os contêineres EJB ocultam a complexidade das comunicações remotas dos desenvolvedores,
utilizando classes fornecidas pelo contêiner (geradas por ferramentas do contêiner quando o EJB
é compilado, juntamente com classes de stub do RMI para a utilização de clientes) que implementam
as interfaces EJB. Essas classes de implementação são objetos Java remotos que
um cliente pode acessar utilizando Java RMI. Da perspectiva do cliente, ele
simplesmente chama métodos na interface EJB, sem considerar as comunicações
remotas.
Coincidência

Os contêineres EJB gerenciam de forma transparente os pedidos coincidentes de vários clientes.
Os clientes podem agir como se tivessem acesso exclusivo ao EJB. Por exemplo, se
dois clientes solicitarem o mesmo EJB de entidade, o contêiner fornecerá a cada um deles
sua própria instância e gerenciará a sincronização internamente sem o conhecimento do
cliente.
Nomenclatura

O contêiner EJB fornece um espaço de nome JNDI para localizar os EJBs implementados no
contêiner. Os clientes EJB podem procurar EJBs para obter uma interface Home. A
interface Home de um EJB fornece métodos para localizar e criar instâncias EJB.
Enquanto o contexto de nomenclatura JNDI estiver disponível em seu local, os clientes
poderão acessar os EJBs.
Persistência

Os desenvolvedores de EJB têm a opção de dois esquemas para o armazenamento dos dados
persistentes do EJB de entidade: CMP (Persistência Gerenciada por Contêiner) e BMP (Persistência Gerenciada por
Bean). O CMP delega a responsabilidade de implementação do código de acesso a dados
para o contêiner, enquanto que o BMP deixa o desenvolvedor de EJB responsável pela implementação
desse código. O CMP permite que o desenvolvedor de EJB utilize uma implementação padrão para
acesso ao armazenamento persistente simplesmente pela declaração de campos gerenciados por contêiner em
um descritor de implementação.
Gerenciamento da Transação 
Uma transação é uma seqüência de operações que são bem-sucedidas ou que falham atomicamente de forma que,
se alguma operação na seqüência falhar, não será feita nenhuma alteração no estado do
sistema. Por exemplo, digamos que você queira emitir passagens aéreas: você teria que validar
a conta do cartão de crédito do cliente, debitar essa conta e, em seguida, emitir as passagens.
Essa seqüência de operações deve ocorrer em uma única transação para que, se
alguma operação falhar, nenhuma alteração seja feita na conta do cartão de crédito do cliente
e nenhuma passagem seja emitida.
Os EJBs podem utilizar a demarcação de transação
gerenciada por bean ou a demarcação de transação gerenciada
por contêiner, que são descritas nos dois títulos a seguir.
Demarcação de Transação Gerenciada
por Bean
Nessa demarcação, você utiliza uma API simples para demarcar
os limites da transação. Essa é a JTA (Java Transaction API), que você utiliza
para controlar a demarcação de transação por meio de programação, por exemplo, chamando
os métodos begin() , commit() e rollback()
da interface JTA UserTransaction. O desenvolvedor é responsável por
codificar a lógica de rollback para condições de exceção de transação, uma vez que o contêiner
não as manipula automaticamente.
Nota: Os EJBs de entidade não podem utilizar a demarcação de transação gerenciada por bean; eles
só podem utilizar a demarcação de transação gerenciada por contêiner.
Demarcação de Transação
Gerenciada por Contêiner
Nessa demarcação, você não fornece código para começar
e terminar as transações. Em vez disso, você fornece informações do atributo de transação
no descritor de implementação do EJB para cada método do EJB. O atributo de
transação (um de Required, RequiresNew, NotSupported, Supports, Mandatory
ou Never) informa ao contêiner qual escopo de transação utilizar para o método.
Por exemplo, se um cliente estiver em execução em uma transação e chamar um método
do EJB para o qual o atributo de transação esteja definido como Required, o método será
então chamado dentro do escopo da transação existente.
Utilize a demarcação de transação gerenciada por contêiner em vez da demarcação de transação
gerenciada por bean sempre que possível, para que não seja necessário incluir, depurar e testar
o código de demarcação da transação em seu componente. Em vez disso, o comportamento da transação
de cada um dos métodos EJB será especificado na hora da implementação, no descritor de
implementação. Isso significa que o comportamento da transação pode ser alterado sem
um ciclo caro de atualização-depuração-teste de código.
Transações Distribuídas
Uma transação distribuída é aquela que deve ser coordenada entre
vários bancos de dados e/ou vários aplicativos. Isso é em comparação a uma transação
centralizada, como um único servidor de aplicativos J2EE consolidando transações
em um único banco de dados.
Uma consolidação em duas fases é necessária em transações distribuídas; por exemplo,
onde há mais de um banco de dados sendo atualizado. Alguns contêineres EJB (como
o BEA WebLogic Server 6.0) fornecem suporte para a consolidação em duas fases, utilizando o
protocolo XA do Open Group. O programador do aplicativo não precisa gravar nenhum código
para manipular a consolidação em duas fases; o contêiner EJB a gerencia.
Gerenciamento da Segurança 
A segurança do EJB é manipulada pelo contêiner EJB, utilizando as informações de segurança
do descritor de implementação. No descritor de implementação, você declara um conjunto de
funções e, para cada método EJB, você declara as funções que são autorizadas
a chamar o método.
No tempo de execução, cada cliente do EJB é designado com uma função e o contêiner EJB
gerencia o acesso aos métodos do EJB, verificando se a função do cliente está autorizada
a chamar esse método.
Como as informações de segurança são declaradas no descritor de implementação, o
comportamento de segurança pode ser alterado sem um ciclo caro de atualização-depuração-teste
de código.
Gerenciamento do Ciclo de Vida 
Os EJBs são movidos por meio de vários estados durante seu ciclo de vida em resposta a
pedidos de clientes. O contêiner EJB é responsável pelo gerenciamento desse ciclo de vida.
Na inicialização do contêiner, o contêiner cria um conjunto de instâncias EJB em um conjunto de
recursos (para poupar tempo de inicialização quando o recurso EJB é necessário). Quando um cliente EJB
solicita a criação de um EJB, uma instância é designada no conjunto. O
cliente pode agora fazer pedidos do EJB. Quando um cliente EJB solicita remoção
de um EJB, essa instância é retornada para o conjunto.
O contêiner notifica uma instância EJB de vários eventos no ciclo de vida do EJB,
utilizando um conjunto de métodos de retorno de chamada padrão, como:
ejbCreate() - chamado pelo contêiner após a criação da
instância EJB
ejbRemove() - chamado pelo contêiner quando a instância EJB
está prestes a ser excluída
ejbActivate() - chamado pelo contêiner depois que a
instância EJB é restaurada de um estado passivo
ejbPassivate() - chamado pelo contêiner quando a instância
EJB está prestes a ser passivada
ejbStore() - chamado pelo contêiner quando a instância EJB
está prestes a ser gravada em um banco de dados
ejbLoad() - chamado pelo contêiner depois que os campos da
instância EJB são carregados do banco de dados
Cada EJB é necessário para implementar esses retornos de chamada, embora a implementação do EJB
do método de retorno de chamada esteja sempre vazio. Por exemplo, o contêiner chama o
método ejbRemove() do EJB para notificar o EJB de que o EJB está prestes
a ser removido (há um pedido do cliente para remover o EJB). No método
ejbRemove() do EJB, você codificaria qualquer operação necessária antes
do EJB poder ser removido, como a liberação de qualquer recurso retido pelo EJB.
Os EJBs podem ser passivados - as informações de estado são salvas e a instância EJB
é liberada para utilização pelo conjunto de recursos - conforme necessário pelo contêiner.
Um EJB passivado será ativado - as informações de estado restauradas - pelo
contêiner se for recebido um pedido do cliente para esse objeto EJB específico.
Pool de Conexão com o Banco de Dados 
A abertura de uma conexão com o banco de dados é lenta. Além disso, as conexões com o banco de dados poderiam ser
um recurso incomum em razão, por exemplo, das restrições de licença. O contêiner EJB
gerencia esse custo utilizando o pool de conexão com o banco de dados - o contêiner
mantém um conjunto de conexões abertas que podem ser designadas ou não a um EJB,
conforme necessário, resultando em conexões rápidas e eficientes.
Para EJBs de entidade que utilizam o CMP, as conexões com o banco de dados são manipuladas automaticamente.
Não é necessário gravar nenhuma conexão ou código SQL - você simplesmente especifica o nome
JNDI da origem de dados JDBC no descritor de implementação do EJB e utiliza as ferramentas de implementação
específicas do contêiner para gerar as rotinas de conexão para você. O contêiner gerencia
o pool de conexão com o banco de dados.
Para EJBs de entidade que utilizam BMP ou para EJBs de sessão, é necessário gravar código
de conexão para conectar-se a uma origem de dados JDBC e gravar código SQL para acessar o banco de dados.
A origem de dados JDBC continua a ser gerenciada pelo contêiner - a origem de dados JDBC
realmente utiliza um pool de conexão com o banco de dados mantido pelo contêiner.
Sistema de Mensagens 
Os contêineres EJB são necessários para fornecer suporte ao
sistema de mensagens para a troca assíncrona de
mensagens. JMS ou outros tipos de sistema de mensagens, podem ser utilizados pelas mensagens entregues
pelo processo de EJBs orientados a mensagens. Em razão do envolvimento
do JMS com os EJBs, eles devem suportar o acesso transacional a partir dos componentes
do contêiner de Web e EJB, como servlets, páginas JSP e EJBs.
Componentes J2EE
A seção a seguir fornece uma breve discussão de todos os tipos de componentes
J2EE. Os componentes J2EE incluem applets, clientes aplicativos, componentes
da Web e Enterprise JavaBeans.
Os componentes J2EE são executados em contêineres J2EE.
Applets 
Os applets são pequenos programas que podem ser enviados juntamente com uma página da Web e serem executados
em um navegador da Web. Também é possível executá-los em outros ambientes que suportam
o modelo de programação do applet.
Os applets são utilizados principalmente para implementação de interfaces com o usuário e podem
estender muito os recursos de páginas HTML.
Clientes Aplicativos 
Os clientes aplicativos são aplicativos Java. Eles possuem acesso aos recursos
da camada central do J2EE e da camada do EIS. Eles são normalmente aplicativos de desktop
que fornecem uma interface com o usuário. É possível utilizá-los para implementar um "cliente
espesso", conforme descrito em Conceitos: Padrões de Distribuição.
Componentes da Web
Java Servlets 
A tecnologia Java Servlet permite a um servidor da Web manipular pedidos de um cliente Web
e fornecer respostas contendo conteúdo dinâmico. Um servlet Java pode interagir
com outros componentes da Web e EJB para produzir esse conteúdo dinâmico. O conteúdo
gerado pode tomar a forma de qualquer documento baseado em texto, incluindo HTML e XML.
O Java Servlet também pode ser utilizado como nó de extremidade de serviços da web em colaboração com
a API JAX-RPC.
Nota: O uso de Servlet como nó de extremidade de serviços da Web
é um novo recurso do J2EE 1.4 (JAX-RPC 1.1) e, assim, não é suportado em versões
anteriores.
Para obter informações adicionais sobre servlets do J2EE, consulte http://java.sun.com/.
Siga os links para J2EE > Blueprints.
JavaServer Pages 
A tecnologia JSP (JavaServer Pages) baseia-se em Java Servlets, tendo como base texto
e não código. Uma página JSP processa pedidos e gera respostas
como um servlet, mas sua lógica é principalmente orientada à apresentação. Uma página JSP contém
principalmente HTML estático que define o formato da apresentação dos dados
obtidos de outras origens, como JavaBeans e EJBs. Um desenvolvedor do componente da Web
pode criar bibliotecas de tags de personalização para estender JSP para incluir novos recursos.
Para obter informações adicionais sobre o JSP, consulte http://java.sun.com/.
Siga os links para J2EE > Blueprints.
Páginas HTML 
As páginas HTML podem ser utilizadas para suportar as interfaces com o usuário. Elas podem ser definidas como
páginas estáticas da Web ou poderiam ser geradas por servlets e páginas JSP. A
especificação J2EE requer que os clientes Web do J2EE forneçam suporte à exibição de páginas HTML.
JavaBeans 
A API JavaBeans define uma arquitetura para a criação de componentes reutilizáveis simples.
Esses componentes podem ser editados e montados utilizando as ferramentas do construtor de aplicativos.
O código Java comum é utilizado para implementar JavaBeans, para que a implementação
permaneça legível a outros programadores que desejarem utilizar esses componentes, assim como
para as ferramentas.
JavaBeans não é uma tecnologia J2EE, mas é utilizado pelas tecnologias J2EE. Por exemplo,
os EJBs podem utilizar JavaBeans como objetos de valor. Para obter as diferenças entre JavaBeans e
Enterprise JavaBeans, consulte a seção Comparando JavaBeans e EJBs.
Para obter informações adicionais sobre os JavaBeans, consulte Conceitos: JavaBeans.
Enterprise JavaBeans 
A especificação Enterprise JavaBeans determina uma arquitetura para o desenvolvimento
e implementação de aplicativos de negócios distribuídos transacionais, com base no componente.
Os componentes definidos pela especificação EJB são chamados de EJBs (Enterprise
JavaBeans). Os EJBs são componentes Java do lado do servidor nos quais você implementa as regras de
negócios de seu aplicativo.
Os EJBs são implementados e executados em um ambiente chamado contêiner EJB, descrito
anteriormente sob o título Contêiner EJB,
que fornece serviços, como gerenciamento de
transação, conectividade do banco de dados
e segurança. Fora essas complexidades,
a arquitetura EJB permite aos desenvolvedores de componentes focalizar a lógica de negócios.
Um EJB (Enterprise JavaBean) é uma colaboração de interfaces Java, uma classe de
implementação EJB e um descritor de implementação XML. As interfaces e a classe
de implementação EJB devem obedecer as regras definidas pela especificação EJB,
como a implementação de determinadas interfaces e o fornecimento de determinados métodos de retorno de chamada.
As interfaces EJB incluem interfaces home que fornecem métodos para localizar e
criar instâncias EJB e interfaces de componente que fornecem os métodos de negócios
para uma determinada instância EJB. Essas interfaces podem ser remotas, significando que
é possível chamá-las através da rede, ou podem ser interfaces locais, significando que o
responsável pela chamada deve estar no mesmo processo (ou mais precisamente, na mesma Java Virtual
Machine). As interfaces EJB são implementadas pelas classes do contêiner EJB que delegam
métodos para a classe de implementação EJB. Uma exceção é um método localizador de
um EJB de entidade gerenciado por contêiner, que é manipulado pela classe do contêiner.
Há três tipos de EJBs: beans de sessão,
beans de entidade e beans orientados
a mensagens.
Para obter informações adicionais sobre os EJBs, consulte http://java.sun.com/.
Siga os links para J2EE > Blueprints.
Beans de Sessão 
Um componente de bean de sessão fornece serviços que implementam lógica de negócios
específica do cliente. Um único cliente pode acessar cada instância de bean de sessão por meio de interfaces
locais ou remotas. Os beans de sessão podem salvar dados em um banco de dados mas, geralmente,
recorrem a beans de entidade representando objetos de negócios para salvar dados. As instâncias de bean de sessão
podem manter um estado conversacional transiente.
Um bean de sessão pode ter um método getAllCustomers() que retorna
uma coleta de todos os clientes no banco de dados. Esse bean obteria
suas informações do bean de entidade do Cliente e entregaria os resultados para o
cliente.
Os beans de sessão sem preservação de estado podem ser utilizados como nó de extremidade de serviços da Web,
conforme definido na especificação JSR e EJB.
Nota: O uso de beans de sessão sem preservação de estado como
serviços da Web é um novo recurso do J2EE 1.4 (JSR 109 e EJB 2.1) e, assim, não é suportado
em versões anteriores.
Para obter informações adicionais sobre os beans de sessão, consulte a Especificação
Enterprise JavaBeans, Versão 2.1, em http://java.sun.com/.
Siga os links para Products & Technologies > J2EE > Enterprise
JavaBeans.
Beans de Entidade 
Um componente de bean de entidade fornece serviços que implementam lógica de negócios
específica do objeto. Vários clientes podem acessar uma instância de bean de entidade coincidentemente, por meio
de interfaces locais ou remotas. Os beans de entidade salvam os dados de objeto de negócios em bancos de dados
e os dados persistidos podem sobreviver a travamentos do contêiner ou do cliente.
Um bean de entidade poderia representar um cliente, que poderia ser armazenando como uma linha
na tabela do cliente de um banco de dados relacional. O desenvolvedor do EJB escolhe o método
de persistência, nesse caso, um banco de dados relacional.
Há dois tipos de persistência de bean de entidade: BMP (persistência gerenciada por bean)
e CMP (persistência gerenciada por contêiner). Os beans de entidade BMP devem implementar o
código de acesso a dados, enquanto que os beans de entidade CMP possuem essa capacidade implementada pelo
contêiner. As implementações do contêiner CMP são geralmente fornecidas para a persistência
do banco de dados relacional, embora outros tipos de persistência (banco de dados de objetos,
persistência baseada em arquivo, etc.) também sejam possíveis.
Para obter informações adicionais sobre os beans de entidade, consulte a Especificação Enterprise JavaBeans,
Versão 2.1 em http://java.sun.com/.
Siga os links para Products
& Technologies > J2EE > Enterprise JavaBeans.
Beans Orientados a Mensagens 
Um componente de bean orientado a mensagens fornece um serviço que implementa lógica de
negócios específica do processamento de mensagens. Somente o contêiner
pode chamar esse serviço; o cliente não pode chamá-lo diretamente por meio
de interfaces remotas ou locais. Em vez disso, quando uma mensagem chega em um destino
ou nó de extremidade atendido pelo bean, o contêiner chama uma instância do bean orientado a
mensagens designada como MessageListener para o destino. As instâncias de beans orientados a mensagens
não mantêm um estado conversacional, mas podem manter variáveis de instâncias
com referências de recursos (por exemplo, conexão com o banco de dados) entre as chamadas de métodos.
Nota: Os beans orientados a mensagens não são suportados antes
do EJB 2.0. O suporte a tipos de sistemas de mensagens diferentes do JMS é um novo recurso
da especificação EJB 2.1 e, portanto, eles não são suportados na versão anterior.
Para obter informações adicionais sobre os beans orientados a mensagens, consulte a
Especificação Enterprise JavaBeans, Versão 2.0, em http://java.sun.com/.
Siga os links para Products & Technologies > J2EE > Enterprise
JavaBeans.
Comparando JavaBeans e EJBs 
Embora o nome seja semelhante, os EJBs são muito mais complexos que os JavaBeans comuns.
Ambos definem arquiteturas para componentes reutilizáveis, mas os EJBs incluem o suporte
necessário para a criação de serviços distribuídos multiusuário. Os dois tipos de
componentes podem ser montados utilizando as ferramentas do construtor de aplicativos, mas os EJBs precisam
ser implementados em um contêiner EJB para serem executados.
Os contêineres J2EE fornecem suporte a todas as APIs padrão do J2SE, assim como a um subconjunto
de APIs do J2EE, dependendo do tipo de contêiner. Os componentes de um contêiner
podem acessar esse subconjunto disponível. A tabela a seguir fornece uma breve descrição
de cada API e lista os contêineres J2EE nos quais encontram-se disponíveis.
Nome
|
Descrição
|
Contêineres J2EE
nos quais as APIs estão disponíveis |
EJB 2.1 |
A especificação EJB define
um modelo de componente para componentes da camada de negócios dos EJBs que suportam serviços
automaticamente, como comunicações remotas, gerenciamento de transação,
segurança e persistência.
Para obter informações adicionais sobre o EJB, visite http://java.sun.com/
e siga os links para Products & Technologies > J2EE >
Enterprise JavaBeans. |
EJB
Cliente aplicativo*
Web*
* somente API do cliente |
JAAS |
O JAAS (Java Authentication and Authorization
Service) fornece serviços para autenticação e autorização de usuários
para assegurar que eles tenham permissão para executar uma ação.
Para obter informações adicionais sobre o JAAS, visite http://java.sun.com/
e siga os links para Products
& Technologies > J2SE > Core Java >
Java Authentication and Authorization Service (JAAS). |
Cliente aplicativo
Web
EJB |
JAF 1.0 |
O JAF (JavaBeans Activation
Framework) fornece serviços para identificar dados e instanciar um JavaBean
para manipulação desses dados.
Para obter informações adicionais sobre o JAF, visite http://java.sun.com/
e siga os links para Products & Technologies > J2SE >
Desktop Java > JavaBeans > JavaBeans Activation Framework. |
Cliente aplicativo
Web
EJB |
JAXP
1.2 |
O JAXP (Java API for XML
Processing) fornece uma interface abstrata para o processamento de documentos
XML que pode ser utilizada com analisadores e transformadores em conformidade
que utilizam DOM SAX ou XSLT.
Para obter informações adicionais sobre o JAXP, visite http://java.sun.com/
e siga os links para Products & Technologies > J2EE
> Java API for XML Processing (JAXP). |
Cliente aplicativo
Web
EJB |
JAX-RPC
1.1 |
A especificação JAX-RPC
define APIs do cliente para acessar serviços da Web, assim
como técnicas para implementação de nós de extremidade de serviços da Web.
Para obter informações adicionais sobre o JAX-RPC, visite http://java.sun.com/
e siga os links para Products &
Technologies > J2EE > Java API for XML-based RPC
(JAX-RPC). |
Cliente aplicativo
Web
EJB |
Web
Services para J2EE 1.1 |
A especificação
Web Services para J2EE (JSR-109) define os recursos que
um servidor de aplicativos J2EE
deve suportar para a implementação de nós de extremidade de serviços da Web.
Para obter informações adicionais sobre os Web Services para J2EE,
visite http://jcp.org/aboutJava/communityprocess/final/jsr109/index.html |
Cliente
aplicativo
Web
EJB |
SAAJ
1.2 |
A API SSAJ fornece
a capacidade de manipular mensagens do SOAP.
Para obter informações adicionais sobre o JAXP, visite http://java.sun.com/
e siga os links para Products &
Technologies > J2EE > SOAP with Attachments API for
Java (SAAJ). |
Cliente aplicativo
Web
EJB |
JAXR
1.0 |
A especificação JAXR
define APIs para acesso do cliente aos registros com base em XML, como
registros ebXML e registros UDDI.
Para obter informações adicionais sobre o JAXP, visite http://java.sun.com/
e siga os links para Products & Technologies > J2EE
> Java API for XML Registries (JAXR). |
Cliente aplicativo
Web
EJB |
JavaMail 1.3 |
A API JavaMail fornece uma estrutura que
pode ser estendida para construir aplicativos de correio com base em Java.
Para obter informações adicionais sobre o JavaMail, visite http://java.sun.com/
e siga os links para Products & Technologies > J2EE
> JavaMail. |
Cliente aplicativo
Web
EJB |
JDBC 3.0 |
O JDBC (Java Database Connectivity) é uma
API para acessar origens de dados tabulares, como bancos de dados, planilhas
e arquivos simples SQL.
Para obter informações adicionais sobre o JDBC, visite http://java.sun.com/
e siga os links para Products
& Technologies > J2EE >
JDBC. |
Cliente aplicativo
Web
EJB
|
JMS 1.1 |
O JMS (Java Message Service) fornece serviços de sistema de
mensagens assíncronos para a transferência de dados e notificação de eventos.
Com ele, é possível utilizar os EJBs orientados a mensagens para processar
assincronicamente as mensagens entregues aos tópicos e filas do JMS.
Para obter informações adicionais sobre o JMS, visite http://java.sun.com/
e siga os links para Products &
Technologies > J2EE > Java Message Service. |
Cliente aplicativo
Web
EJB |
JNDI |
A especificação JNDI (Java Naming and Directory
Interface) fornece serviços de nomenclatura e diretório para registrar e consultar
componentes e recursos distribuídos. Os clientes só precisam saber o
nome JNDI registrado para o componente ou recurso sem precisar
conhecer seu local real na rede.
Exemplo: os EJBs são registrados no diretório corporativo na hora da
implementação, utilizando o campo ejb-name do descritor de implementação.
Os clientes J2EE consultam um EJB utilizando a consulta JNDI - todos os clientes
precisam saber com que nome o EJB foi registrado no diretório.
A consulta JNDI retorna uma referência para o objeto home do EJB.
Para obter informações adicionais sobre o JNDI, visite http://java.sun.com/
e siga os links para Products
& Technologies > J2SE >
Core Java > Java Naming and Directory Interface
(JNDI). |
Cliente aplicativo
Web
EJB |
JTA 1.0 |
O JTA (Java Transaction API) define interfaces
para gerenciar serviços de transações distribuídas entre o gerenciador de
transações, o gerenciador de recursos, o servidor de aplicativos e o aplicativo.
Para obter informações adicionais sobre o JTA, visite http://java.sun.com/
e siga os links para Products
& Technologies > J2EE >
Transactions. |
Web
EJB |
J2EE Connector
1.5 |
O J2EE Connector Architecture SPI (Service Provider
Interface) define um padrão para conectar recursos do EIS a
um contêiner J2EE - um adaptador de recursos específico do EIS (fornecido pelo
fornecedor do EIS) é conectado ao contêiner J2EE, estendendo o
contêiner para que ele forneça suporte transacional seguro para esse
EIS. Os componentes no contêiner podem então acessar o EIS por meio do J2EE
Connector Architecture SPI.
Para obter informações adicionais sobre os Conectores J2EE, visite http://java.sun.com/
e siga os links para Products
& Technologies > J2EE >
J2EE Connector Architecture. |
Web
EJB |
JSP 2.0 |
A tecnologia JavaServer Pages fornece aos desenvolvedores
da Web a capacidade de criar e manter páginas dinâmicas da Web.
As páginas JSP baseiam-se em texto e utilizam tags semelhantes a XML para executar lógica
de negócios e gerar conteúdo personalizado. A tecnologia JSP permite que a lógica de
negócios seja delegada a outros componentes para que apenas a lógica de apresentação
precise ser incorporada à página JSP.
Para obter informações adicionais sobre a JSP, visite http://java.sun.com/
e siga os links para Products
& Technologies > J2EE >
JavaServer Pages. |
Web |
Servlet 2.4 |
Os Java Servlets estendem os recursos do
servidor da Web para ajudar a construir aplicativos com base na Web. Os servlets são
sempre utilizados em aplicativos interativos da Web, nos quais o servidor da Web responde
a pedidos do usuário com conteúdo gerado dinamicamente obtido de
sistemas de negócios existentes.
Para obter informações adicionais sobre os Java Servlets, visite http://java.sun.com/
e siga os links para Products
& Technologies > J2EE >
Java Servlet. |
Web |
RMI-IIOP |
A tecnologia Remote Method Invocation executada
sobre Internet Inter-Orb Protocol (RMI-IIOP) permite que os componentes Java
se comuniquem com os componentes CORBA legados gravados em outros idiomas,
como C++ ou Smalltalk.
Para obter informações adicionais sobre o RMI-IIOP, visite http://java.sun.com/
e siga os links para Products and APIs > RMI-IIOP. |
Cliente aplicativo
Web
EJB |
J2EE
Management 1.0 |
A API J2EE Management
fornece APIs para que as ferramentas de gerenciamento consultem um
servidor de aplicativos J2EE para determinar seu status atual, os aplicativos
implementados, etc.
Para obter informações adicionais sobre o RMI-IIOP, visite http://java.sun.com/
e siga os links para Products
& Technologies > J2EE >
J2EE Management Specification. |
Cliente aplicativo
Web
EJB |
JMX
1.2 |
A API JMX é utilizada
pela API J2EE Management para fornecer algum do
suporte necessário para gerenciamento de um produto J2EE.
Para obter informações adicionais sobre o RMI-IIOP, visite http://java.sun.com/
e siga os links para Products
& Technologies > J2SE > Core Java
> Java Management Extensions (JMX). |
Cliente aplicativo
Web
EJB |
J2EE
Deployment 1.1 |
A API J2EE Deployment
define as interfaces entre o ambiente de tempo de execução
de uma ferramenta de implementação e os componentes de plug-in fornecidos por um
servidor de aplicativos J2EE.
Para obter informações adicionais sobre o J2EE Deployment, visite
http://java.sun.com/ e siga
os links para Products
& Technologies > J2EE >
J2EE Deployment Specification. |
|
JACC
1.0 |
A especificação JACC
define um contrato entre um servidor de aplicativos J2EE e um
provedor de política de autorização.
Para obter informações adicionais sobre o JACC, visite http://java.sun.com/
e siga os links para Products
& Technologies > J2EE >
Java Authorization Contract for Containers. |
Cliente aplicativo
Web
EJB |
Montagem e Implementação 
Os aplicativos J2EE são compostos do descritor de implementação do aplicativo (application.xml)
e de um ou mais módulos J2EE que constituem o aplicativo. Os módulos são componentes
portáveis reutilizáveis. Os aplicativos J2EE são compactados em archives .ear.
Descritores de Implementação 
Os descritores de implementação são arquivos XML utilizados em aplicativos e módulos J2EE.
Eles fornecem informações de configuração que são lidas pelo servidor J2EE na hora
da implementação. Essas informações de configuração permitem ao servidor personalizar
o aplicativo ou módulo J2EE declarativamente sem alterar o código fonte
ou as classes.
Há um tipo de descritor de implementação genérico para cada aplicativo ou
módulo J2EE. Os descritores de implementação genéricos, como o ejb-jar.xml do módulo EJB, definem
informações que se aplicam ao EJB, independentemente do servidor em que são
implementadas. Os descritores de implementação específicos do servidor especificam informações que são
significativas somente para um determinado servidor. Seus nomes
refletem o servidor para o qual se destinam.
Módulos J2EE 
Um módulo J2EE consiste em um descritor de implementação para o módulo e em vários
elementos que constituem o módulo, incluindo:
- Elementos não-Java implementados no servidor da Web (páginas JSP, arquivos de imagem, páginas
HTML estáticas); ou seja, elementos do diretório virtual
- Elementos Java implementados em um servidor da Web (servlets, JavaBeans, classes Java)
- Elementos implementados em um servidor EJB (EJBs e classes Java de suporte)
Há três tipos de módulos J2EE:
Cliente Aplicativo J2EE 
Os módulos do cliente aplicativo J2EE são compactados em archives .jar e contêm:
- Descritor de implementação application-client.xml
- Arquivos .class de implementação do cliente aplicativo
Componente da Web 
Os módulos do componente da Web são compactados em archives .war e contêm:
- Descritor de implementação web.xml e descritores de implementação específicos do servidor
- Páginas JSP
- Páginas HTML
- Imagens (por exemplo, .gif e .jpg)
- Arquivos de Classe de Servlet
Se o módulo for um serviço da Web, o archive .war conterá:
- Descritor de implementação webservices.xml
- Arquivos de Classe de Servlet
- Arquivos WSDL
Enterprise JavaBean 
Um único archive JAR Enterprise JavaBean pode conter vários EJBs, mas
suas informações de implementação são armazenadas em um conjunto de descritores de implementação
(ejb-jar.xml e qualquer descritor de implementação específico do servidor).
Um módulo Enterprise JavaBean padrão contém:
- Descritores de implementação ejb-jar.xml e específicos do servidor
- Arquivos de Classe de implementação EJB
Um módulo Enterprise JavaBean de Serviço da Web contém:
- Descritores de implementação webservices.xml
- Arquivos de Classe de implementação EJB
Para obter informações adicionais sobre compactação e implementação do J2EE, Consulte http://java.sun.com/.
Siga os links para Docs & Training > J2EE Platform, Enterprise Edition
> Java Blueprints Program.
Desenvolvimento de Aplicativos J2EE 
O processo de desenvolvimento de aplicativos J2EE define várias funções e estágios.
As seções a seguir definem as funções de
desenvolvimento fornecidas pela especificação J2EE e os estágios de desenvolvimento dos quais essas
funções participam.
Funções do Desenvolvimento de
Aplicativos J2EE 
As funções de desenvolvimento de aplicativos são resumidas nesta tabela.
Nome da Função |
Descrição |
Provedor de Produto J2EE
|
Fornecedor de uma implementação de plataforma J2EE,
também conhecida como produto J2EE. Os provedores de produtos J2EE incluem BEA, IBM
e Sun. Essas organizações normalmente utilizam toda sua energia
para entregar uma implementação da plataforma J2EE. Por exemplo, a
implementação BEA é construída sobre o altamente bem-sucedido monitor de
processamento de transações Tuxedo do BEA. Um provedor de produto J2EE também fornece as ferramentas
necessárias para suportar a implementação e gerenciamento do aplicativo.
|
Provedor de Componente de Aplicativo
|
Esse provedor realmente abrange várias
funções, como desenvolvedores de EJB e designers de documentos HTML. Essas funções
são responsáveis pela produção de componentes de aplicativos J2EE, utilizando
as ferramentas fornecidas.
|
Assembler de Aplicativos
|
Cria um aplicativo J2EE a partir de componentes de
aplicativos J2EE, utilizando as ferramentas fornecidas. O aplicativo J2EE é entregue
como um arquivo EAR (Enterprise Archive). O assembler de aplicativos também
descreve as dependências externas do aplicativo J2EE. O implementador
resolve essas dependências quando está realmente implementando o aplicativo J2EE.
|
Implementador
|
Responsável pela implementação de um aplicativo J2EE e dos
componentes do aplicativo a partir dos quais ele é composto no ambiente
operacional. O primeiro estágio de implementação é instalar os vários
componentes do aplicativo nos contêineres J2EE apropriados. O segundo
estágio da implementação é configurar as dependências externas que foram
declaradas para que possam ser solucionadas. Por exemplo, as funções de segurança
que foram definidas são mapeadas para os grupos de usuários e contas no
ambiente operacional. O terceiro estágio de implementação é executar
o novo aplicativo para que fique pronto para receber pedidos.
|
Administrador de Sistemas
|
Responsável pela infra-estrutura de tempo de execução,
que inclui qualquer aplicativo J2EE implementado. Essa função utiliza as ferramentas
apropriadas fornecidas pelo provedor de produtos J2EE para realizar essa tarefa.
|
Provedor de Ferramentas
|
Fornece ferramentas para o suporte de desenvolvimento e compactação
de componentes do aplicativo. Essas ferramentas sempre correspondem a diferentes
tipos de componentes de aplicativos produzidos, além de incluir IDEs, como o IBM
VisualAge para Java e o Borland JBuilder.
|
Provedor de Componente de Sistema
|
Fornece
diferentes componentes em nível de sistema, como adaptadores de
recursos ou provedores de política de autorização.
|
Essas funções não são exclusivas e uma única pessoa poderia assumir mais de uma
função, especialmente em pequenas equipes de desenvolvimento ou em uma situação que envolva protótipos.
Estágios de Desenvolvimento de
Aplicativos J2EE 
Esta seção descreve os diferentes estágios de desenvolvimento de aplicativos J2EE,
conforme estipulado na especificação J2EE. Os estágios de desenvolvimento são:
Um aplicativo J2EE deve conter pelo menos um módulo J2EE, portanto, pelo menos um dos
estágios de desenvolvimento do componente é necessário. Os dois estágios finais são sempre
necessários, uma vez que todos os aplicativos J2EE devem ser montados e implementados.
A tabela a seguir resume os estágios de desenvolvimento para aplicativos J2EE.
Estágio de Desenvolvimento do J2EE |
Tarefas
|
Executado por (Função do J2EE) |
Resultados em (Item a ser entregue) |
Criação do Cliente Aplicativo J2EE
|
- Grava código do cliente e compila classes
- Cria o descritor de implementação application-client.xml
- Cria um arquivo archive JAR contendo os arquivos Class e XML
|
Provedor de Componente de Aplicativo
(desenvolvedor de software)
|
Um arquivo JAR contendo o cliente aplicativo J2EE
|
Criação do Componente da Web
|
- Grava código de servlet e compila classes
- Grava páginas JSP e HTML
- Cria o descritor de implementação web.xml
- Cria um arquivo archive WAR (Web Application aRchive) contendo
os arquivos Class, .jsp, .html e XML
|
Provedor de Componente de Aplicativo
(desenvolvedor de software: servlets; designer da Web: páginas JSP, páginas HTML)
|
Um arquivo WAR contendo o componente da Web
|
Criação do Enterprise JavaBean
|
- Grava código EJB e compila classes
- Cria os descritores de implementação ejb-jar.xml e específico do servidor
- Cria um arquivo archive JAR contendo os arquivos Class e XML
|
Provedor de Componente de Aplicativo
(desenvolvedor de software)
|
Um arquivo JAR contendo o Enterprise JavaBean
|
Montagem do Aplicativo J2EE
|
- Cria o descritor de implementação application.xml
- Cria um arquivo archive EAR contendo os arquivos de EJBs (JAR),
de componentes da Web (WAR) e XML
|
Assembler de Aplicativos
|
Um arquivo EAR contendo o aplicativo J2EE
|
Implementação do Aplicativo J2EE
|
- Inclui o aplicativo J2EE (EAR) no ambiente do servidor J2EE
- Edita o descritor de implementação application.xml com configuração de
ambiente local
- Implementa o aplicativo J2EE no servidor J2EE
|
Implementador
|
Aplicativo J2EE instalado e configurado
|
Cada estágio do processo de desenvolvimento produz um item a ser entregue para ser utilizado no
estágio seguinte. Os componentes criados nos estágios de Desenvolvimento do Componente são
utilizados no estágio de Montagem do Aplicativo J2EE para produzir o archive EAR do
aplicativo J2EE. No estágio de Implementação do Aplicativo J2EE, o archive EAR é implementado
no servidor J2EE.
Os itens a serem entregues para cada estágio são portáveis e não precisam ser executados pelas
mesmas pessoas ou no mesmo ambiente, contanto que o ambiente atenda
aos requisitos da Plataforma J2EE.
Para obter informações adicionais sobre compactação e implementação do J2EE, Consulte http://java.sun.com/.
Siga os links para J2EE > Blueprints.
Informações Adicionais 
É possível localizar informações adicionais relativas ao J2EE no Sun J2EE Blueprints.
Ele pode ser acessado no endereço http://java.sun.com/.
Siga os links para J2EE > Blueprints > Guidelines: Designing Enterprise
Applications with the J2EE Platform, Second Edition.
Uma cópia desse documento também está incluída no Rational
Unified Process.
A tabela a seguir resume os capítulos do Sun J2EE Blueprints nos quais é possível obter informações
sobre os tópicos específicos.
Conceito do J2EE |
Capítulo do J2EE Blueprints |
Tecnologias da Plataforma J2EE
|
Capítulo 2
|
Enterprise JavaBeans
|
Capítulo 5
|
Transações
|
Capítulo 8
|
Segurança
|
Capítulo 9
|
Servlets
|
Capítulo 4
|
JavaServer Pages
|
Capítulo 4
|
Implementação e Compactação
|
Capítulo 7
|
|