EJB: Arquitetura

Introdução

Quais são os Serviços de Suporte (ou Middleware) da Camada de Aplicação?
- Persistência de componentes e acesso a dados
- Gerência de transações distribuídas
- Directory/Naming
  - Para achar serviços, componentes, etc.
- Segurança
- Tolerância a falha com Failover
- Prover escalabilidade com truques para aumentar a performance
  - Balanceamento de carga
  - Resource pooling
    - Exemplo: Conexões aos SGBDs
  - Multithreading
- Monitoring, logging
Mas todo isso tem que ser feito dentro de um paradigma de componentes
- Para maximizar a reusabilidade
- Server Components
Os problemas básicos que precisamos resolver no uso de Server Components são aqueles listados acima como Serviços de Suporte da Camada de Aplicação
- Help! Programadores normais não sabem como resolver essas questões (difíceis)
- E nem deveriam! Eu, como empresário, quero que meus programadores se concentrem no Business Logic, não em acertar transações distribuídas!
Server Component Model
- Precisamos de um modelo de componentes que simplifique o processo de mover Business Logic para o servidor
- Para tanto, o modelo deve implementar um conjunto de serviços automáticos para gerenciar os componentes
- Em outras palavras, queremos um framework que ofereça serviços automáticos e permita que o Business Logic seja plugado facilmente com componentes que obedeçam ao modelo

EJB não é um produto: é uma especificação
- Para ter suporte multifornecedor
- Sistemas Abertos continuam ...
O objetivo maior é deixar o programador se concentrar no Business Logic
Isso é feito de duas grandes formas:
- Programação Declarativa
- Serviços Automáticos

Cada Bean tem um Deployment Descriptor que permite configurá-lo visualmente durante a implantação
- Sem ter código fonte e sem programar

Container-Bean.gif (6553 bytes)

Lifecycle
- Bean não precisa se preocupar com criação de processos, threads, ativação ou destruição de objetos
Gerência de estado
- O estado conversacional de Beans (se houver) é gerenciado (salvo/recuperado) automaticamente
Segurança
- Beans não precisam autenticar os usuários ou verificar o nível de autorização
Transações
- Não precisa colocar código de demarcação de transações nos Beans para que possam participar de transações distribuídas
- O Container automaticamente gerencia o início, enrollment, commitment e rollback de transações
Persistência
- Beans não precisam se preocupar com sua persistência num Banco de Dados
Outros
- Outros serviços podem ser oferecidos dependendo do fornecedor (Fail-over, Load-Balancing, ...)

A implementação dessas idéias depende de 3 coisas:
- Uma arquitetura
- Um novo processo de desenvolvimento (para favorecer o reuso)
- Novos papéis para os desenvolvedores (que já vimos antes)

A Arquitetura se baseia num EJB Container que roda num EJB Server e intercepta as chamadas ao Bean feitas pelos clientes
- O cliente nunca acessa o Bean diretamente
- Vários "Wire Protocols" podem ser usados pelos clientes
  - Default: Remote Method Invocation (RMI)
O EJB Container implementa os Serviços Automáticos
- Em termos de Design Pattern, é uma combinação de:
  - Proxy (controla o acesso a um Bean, ex. segurança)
  - Decorador (adiciona funcionalidade a um Bean)
O EJB Server
- Permite que vários containers executem
- Implementa outros serviços (não transparentes) tais como:
  - Naming
  - Segurança (Cadastro de usuários, grupos, etc.)
  - Serviços de transação (chamados automaticamente pelo Container)
  - etc.

ejb1.gif (6860 bytes)

arquitetura programa