Desenvolvimento de Aplicações J2EE:

Papeis, Composição e Deployment

Desenvolvimento de Aplicações J2EE

• Para desenvolver aplicações J2EE, deve-se:
  • Desenvolver componentes de aplicação
  • Compor os componentes em módulos
    • Adicionando outros recursos e um Deployment Descriptor
  • Compor módulos em aplicações
  • Deployment da aplicação
    • Instalação e customização da aplicação, incluindo seus módulos
• Observe que o deployment de módulos é feito e não de componentes
  • Isso vai contra as definições normais de componente
  • Porém, pense num módulo como sendo um arquivo podendo conter mais de um componente
  • Exemplo: um módulo (arquivo) contendo vários EJBs

Papeis

• Devido à construção de aplicações com a composição de componentes, temos novos papeis a considerar

J2EE Server Provider

• Provê o Middleware contendo os serviços não automáticos (Naming usando JNDI, Transações usando JTS, ...)
• O J2EE Server deve ser capaz de aceitar vários EJB Containers e Web Containers
• J2EE Servers podem ser construídos em cima de
  • SGBDR
  • SGBDOO
  • Monitores de Transação
  • Web Application Servers
  • etc.
• Exemplos: IBM WebSphere, BEA WebLogic, Sun iPlanet, Oracle Application Server, JBoss
  • Devem ser especialistas em Gerência de Transações Distribuídas, Objetos Distribuídos, etc.

EJB/Web Container Provider

• Provê o software para receber componentes e fornecer os serviços automáticos
• Alguma ferramenta deve fornecer a geração automática dos Containers (que obedecem à interface dos Beans ou Web components, já que interceptam as chamadas)
  • No final das contas, um Container é um monte de classes em Java geradas automaticamente
• Deve também se registrar junto ao serviço de Naming para que os clientes possam achar objetos que obedeçam às interfaces desejadas
• Os containers rodam dentro do J2EE Server e/ou no servidor Web e/ou na máquina cliente
• Como não há (ainda) padronização de interface entre o J2EE Server e os Containers, quem é fornecedor de servidores também provê os Containers
• Exemplos: IBM, BEA, Sun, Oracle

Application Component Developer

• Um programador que produz EJBs e Web components
• EJBs capturam o Business Logic reutilizável da empresa
  • Sendo reutilizável, vale a pena colocar num Bean
• Pode ser um programador da empresa cliente ou de uma empresa especializada em construir EJBs

Deployer

• Faz tudo que tem a ver com o ambiente run-time final
• Um técnico da empresa cliente final
• Vai instalar os Beans e Web components no J2EE Server e configurá-los no ambiente run-time
  • Através do Deployment Descriptor
  • Usando Programação Declarativa
• Não precisa saber Java, nem o Business Logic
• Deve saber quais são os bancos de dados, os usuários, etc.
• O que é configurado:
  • O nome dos Beans, Web components
  • Os nomes das interfaces dos Beans, Web components
  • Valores de timeout de sessão
  • Lista de campos mantidos pelo container (persistência automática)
  • Access Control List para segurança
  • Controle de Transação (Not Supported, Supported, Required, Requires-New, Bean-Managed, ...)
    • Nem sempre o Deployer mexe com isso
  • Transaction Isolation Level (Serializable, Read Uncommitted, Read Committed, Repeatable Read)
    • Nem sempre o Deployer mexe com isso

Application Developer

• Junta todos os tiers para criar a aplicação final
• Escreve a aplicação usando Componentes prontos
• A aplicação pode envolver:
  • Aplicação console em Java
  • Applet
  • Servlet
  • Aplicação CORBA
  • Controle ActiveX (usando o bridge COM-CORBA)
• O desenvolvedor se preocupa mais com a funcionalidade de muito alto nível
  • Tipicamente Apresentação de Dados

System Administrator

• Gerencia o ambiente e faz o afinamento (fine tuning)
• Monitoração em tempo real de
  • Servidores de aplicação
  • Componentes
  • Containers
  • Clientes
• Pode definir o número concorrente de usuários que executam um cliente ou Container ou componente específico
• Pode ter visão instantânea ou histórica de eventos, cargas, etc.

Criação, composição e packaging de componentes

• Um módulo é uma unidade de empacotamento
• Empacota um ou mais componentes do mesmo tipo
• Há 3 tipos de módulos:

Web Modules

• Unidade instalável (deployable) contendo
  • Servlets
  • Páginas JSP
  • Bibliotecas de tags JSP
  • Arquivos JAR de biblioteca Java
  • Documentos HTML/XML
  • Outros recursos (imagens, arquivos de classes, applets, ...)
• O arquivo é chamado "Web ARchive file" (WAR file)
• WAR = arquivo JAR mas com diretório WEB-INF contendo um deployment descriptor num arquivo web.xml
  • O servidor J2EE examina o Deployment Descriptor para saber como tratar o componente ou aplicação

EJB Modules

• Unidade instalável (deployable) contendo
  • EJBs
  • Arquivos JAR de biblioteca Java
  • Outros recursos, etc.
• O arquivo é um arquivo JAR mas com deployment descriptor ejb-jar.xml no diretório META-INF

Java Modules

• Um grupo de classes clientes empacotados em arquivos JAR
• O deployment descriptor de um Java Module está num arquivo chamado application-client.xml

Criação, composição e packaging de aplicações

• Módulos podem ser agrupados em aplicações num pacote chamado "EAR file" (Enterprise ARchive)
• O deployment descriptor de uma aplicação está num arquivo chamado application.xml
• Observe que os vários deployment descriptors envolvidos permitem um melhor reuso dos módulos

Deployment de Aplicações

• Deployment é o processo de instalar e customizar módulos numa plataforma J2EE
• Envolve várias etapas:
  • Copiar o arquivo apropriado no servidor de aplicações
  • Configurar a aplicação através do deployment descriptor
    • O deployment descriptor contém informação que pode variar entre duas instalações
    • Exemplos: nomes de bancos de dados, de tabelas, de campos, papeis para segurança, etc.
  • Deixar o módulo sob controle de um container
    • Isso freqüentemente envolve a criação dinâmica de um container usando uma ferramenta especial
    • Isso é necessário quando o container está intimamente relacionado com os componentes do módulo (veremos exemplos adiante)

j2ee-2 programa