Enterprise JavaBeans
Componentes para o
Desenvolvimento de Sistemas
Distribuídos Corporativos
Jacques P. Sauvé
[email protected]
1
Uma afirmação recente ...
• “A chegada de software baseado em
componentes pode ser a novidade mais
importante da indústria de software
desde a introdução de linguagens de
programação de alto nível”
• Uau! Mesmo que for exagero, temos
que examinar a questão ...
2
Pressões do Negócio no IT
• “Competing on Internet time” (Jobs)
• Migração para Intranet/Extranet/Internet
• Sistemas que dão um business
advantage
• Fusões e aquisições
• Resultado: Tem muito mais software a
fazer, muito mais rapidamente
3
Pressões Tecnológicas no IT
• Client/Server is dead!
– Não tem escala (conexões de BD)
– Não aguentamos a manutenção
– Não suporta Thin Clients
• Arquiteturas distribuídas
– Para ter escala na Internet
– Para acessar sistemas legados e novos
• Complexidade crescente
– Quem sabe programar transações
distribuídas, por exemplo?
4
Qual é o Custo do
Status Quo?
• A mudança tecnológica é cara!
• Será que não podemos fingir de morto
e fazer nada?
• Fazer nada pode custar caro também!
– Perda de competitividade
– Perda de clientes
• O que custa menos?
5
O que Queremos?
• Melhor flexibilidade
– Possibilitando satisfazer novos requisitos
do negócio (=funcionalidade) rapidamente
• Melhor adaptabilidade
– Possibilitando customizar uma aplicação
para vários usuários, usando várias
alternativas de delivery dos serviços da
alicação com impacto mínimo ao núcleo da
aplicação
6
O que Queremos?
• Melhor manutenabilidade
– Possibilitando atualizar uma aplicação mas
minimizando o impacto da maioria das
mudanças
• Melhor reusabilidade
– Possibilitando rapidamente montar
aplicações únicas e dinâmicas
7
O que Queremos?
• Melhor aproveitamento do legado
– Possibilitando reusar a funcionalidade de
sistemas legados em novas aplicações
• Melhor interoperabilidade
– Possibilitando integrar 2 aplicações
executando em plataformas diferentes
• Melhor escalabilidade
– Possibilitando distribuir a execução da
aplicação para satisfazer vários volumes
de transação
8
O que Queremos?
• Menor tempo de desenvolvimento
– Possibilitando viver em "Internet time" e
com baixo orçamento
• Melhor robustez
– Possibilitando ter soluções de missãocrítica
• Menor risco
– Possibilitando tudo que falamos acima e
ainda não se arriscar a ter projetos
fracassados
9
Soluções: Evolução
arquitetural
•
•
•
•
<1985:Arquitetura centralizada
>1985:Arquitetura cliente-servidor 2-tier
>1990:Arquitetura cliente-servidor 3-tier
>1995:Arquitetura cliente-servidor 3-tier,
Web-based
• >2000: como acima mas com thin
clients e larguíssima escala e robustez
10
Arquiteturas Multi-Tier
Legado
Business Services Tier
User Services Tier
(Middle Tier)
Data Services Tier
11
Por que Multi-Tier?
• Para fugir de Client/Server 2-tier
– Enormes problemas de suporte
– Queremos Very Thin Clients
(Smartcards,...)
– Não tem escala (conexões de BD)
• Altos volumes de transação na Internet
• Para integrar sistemas heterogêneos
– Legado (CICS, 3270, SGBDR, ...)
– Fontes de dados heterodoxas (Internet
data feed, ...)
12
Serviços do Middle Tier?
– Serviço de páginas Web
– Persistência de componentes e acesso a
dados
– Gerência de transações distribuídas
– Directory/Naming
– Segurança
– Tolerância a falha com Failover
– Balanceamento de carga
– Resource pooling
– Monitoring, logging, ...
13
Problema!
• Como escrever aplicações para obter
todos esses serviços e ainda se
concentrar no Business Logic?
– A chave será o uso de componentes
14
Soluções Arquiteturais para a
Reusabilidade
• Frameworks
– Para melhorar a reusabilidade de Análise,
Design, Código, Testes
• Componentes
– Em busca da reusabilidade total com
software “Plugável”
15
Component-Based
Development
• Usa idéias de mercados maduros
– Componentes pré-fabricados
– Carros, circuitos integrados, ...
• Buy, don’t make!
• Muda a ênfase da programação
(construção) para a composição
(montagem ou assembly)
16
Component-Based
Development
• Deve haver forma simples de
– Configurar componentes
– Ligar componentes entre si
• Se for feito com ferramenta visual,
temos “Programação sem codificação”
– Como em VB/Delphi
– “Design time”
– Mas componentes vão muito mais longe!
17
Definição de Componente
– "Um componente é uma unidade de
composição com interfaces especificadas
contratualmente e com dependências de
contexto explícitas apenas. Um
componente de software pode ser
implantado [deployed] de forma
independente e está sujeito à composição
por terceiros"
18
Característica de Componente
• Construção de aplicações por
montagem
– Composição de pedaços existentes
– Os “terceiros” não têm o código fonte, nem
sabem detalhes internos
– Uso de “Programação Declarativa” para
configurar o componente
– Normalmente através de “Visual
Programming”
19
Característica de Componente
• Um componente explicita suas
interfaces
– Interfaces padronizadas para ser “PlugReplaceable”
– Interfaces devem ser auto-descritivas para
permitir que um ambiente visual conecte
componentes entre si
20
Característica de Componente
• Um componente é uma unidade de
packaging e deployment
– Packaging: O componente contêm tudo
que ele precisa e é independente
• Descrição de interfaces, código, imagens,
recursos, mensagens configuráveis, etc.
– Deployment: Um objeto não é implantado
parcialmente. Ele é uma unidade de
implantação.
• Configuração durante o deployment
21
Categorias de Componentes
• Objetivo: domínio vs tecnologia
• Abstração: horizontal (muitos domínios)
vs vertical
• Granularidade: fina vs grossa
– Fina: Widget de GUI
– Grossa: Shopping Cart (Business Object)
• Localização: cliente vs servidor
22
Server Components
• Precisamos de serviços de
componentes no Middle Tier para que
programadores mortais possam se
concentrar no Business Logic
• Os serviços do Middle Tier têm que ser
oferecidos automaticamente, sem
programação
– Não queremos API!
23
Enterprise JavaBeans
• Arquitetura de Server Components
• Componentes escritos em Java
• Aplicações podem ser escritas em
outras linguagens
• EJB é apenas uma especificação
– Vários fornecedores têm “Java Application
Servers” nos quais componentes EJB
podem rodar
24
– Nada tem a ver com JavaBeans
Quem apoia EJB?
• Todos fora Microsoft apoiam EJB como
arquitetura de Server Components
– IBM
– Oracle
– Netscape
– BEA Systems
– Sun Microsystems
– Sybase
– etc.
25
EJB: As 2 Idéias principais
• Programação declarativa
– Eu digo o que quero, sem programar
– Usando ferramenta visual para editar um
Deployment Descriptor
• Serviços automáticos
26
EJB: Serviços Automáticos
• Coisas que componentes (Beans) não
precisam fazer
• Gerência de Lifecycle
– Alocação de processos, gerência de
thread, ativação de objetos, destruição de
objetos
• Gerência de estado
– Estado é mantido pelo container, mesmo
entre chamadas
27
EJB: Serviços Automáticos
• Segurança
– Autenticação e autorização de usuários
• Transações
– Não precisa de código demarcando
transações para participar de transações
distribuídas
• Persistência
– Mapeamento automático para BD
28
A Arquitetura EJB
29
A Arquitetura EJB
• O Container intercepta as chamadas
dos clientes e insere os serviços
automáticos
• O EJB Server permite rodar Containers
e oferece outros serviços
– Naming
– Segurança
– Transações
30
Novos Papeis, Novo Processo
31
EJB: As Interfaces e Objetos
32
EJB: As Interfaces
• Home Interface é a interface para uma
Factory que permite criar ou localizar
Beans
– Implementada pelo Home Object, criado
automaticamente
• Remote Interface especifica os
Business Methods do Bean
– Implementada pelo EJBObject , criado
automaticamente
33
EJB: Tipos de Componentes
• Componente de sessão com estado
– Para controlar sessão entre cliente e
middle tier
– Sem persistência automática entre
chamadas
• Componente de sessão sem estado
– Como acima, mas dão maior escala pois
são muito mais rápidos
– São intercambiáveis e pode haver um pool
34
deles
EJB: Tipos de Componentes
• Componentes de Entidade
– Têm persistência automaticamente tratada
pelo middle tier
– Servem para representar dados presentes
em um banco de dados
– O mapeamento pode ser simples (atributo
= colunas) ou mais complexo usando
ferramenta de mapeamento ObjetoRelacional, etc.
35
Serviço: Gerência de Lifecycle
• Container trata de
– Alocação de processos
– Threads
– Instanciação do Bean
– Liberação de memória
– Remoção do Bean
36
Serviço: Gerência de Estado
• Para liberar recursos temporariamente,
um Bean pode ser “passivado” e
“ativado” depois
• O Container se encarrega de salvar e
recuperar o estado conversacional
• Não é necessário para Stateless
Session Bean
– Não têm estado
– Mais escala
37
Serviço: Gerência de
Persistência
• Para Entity Beans
• Dão uma visão OO dos dados
• Pode ser feito pelo Bean ou pelo
Container
38
Serviço: Gerência de
Persistência
• Alternativas de implementação de
persistência
– Serialização
– Mapeamento para colunas de uma tabela
– Mapeamento para colunas de uma View
– Ferramenta de mapeamento ObjectRelational
– Uso de SGBDOO
39
Serviço: Gerência de
Transações
• Usando Deployment Descriptor,
escolhe-se uma alternativa:
– TX_NOT_SUPPORTED
– TX_BEAN_MANAGED
– TX_REQUIRED
– TX_SUPPORTS
– TX_REQUIRES_NEW
– TX_MANDATORY
• O resto é automático
40
Serviço: Gerência de
Concorrência
• Alternativas de nível de isolamento
– TRANSACTION_READ_UNCOMMITTED
– TRANSACTION_READ_COMMITTED
– TRANSACTION_REPEATABLE_READ
– TRANSACTION_SERIALIZABLE
• Escolhido de forma declarativa no
Deployment Descriptor
41
Serviço: Segurança
• Tudo via Deployment Descriptor
– Pode establecer "roles"
– Pode associar usuários a roles
– Pode executar certos métodos com
privilégios especiais
– Autorização com Access Control Lists
• Cada método pode ter uma lista de usuários
que podem chamá-lo
42
EJB: Deployment
• O responsável pelo deployment do
componente num servidor EJB
configura os componentes de forma
declarativa (visualmente)
– Níveis de segurança
– Mapeamento para bancos de dados
– Contexto transacional desejado
– Transaction Isolation Level
• Read Uncommitted, Read Committed,
Repeatable Read, Serializable
– etc.
43
EJB: Tipos de Aplicações
Cliente
44
Exemplo: E-Commerce
45
EJB: Produtos
• Produtos que podem ser EJB Servers
– TP Monitors (CICS, IBM TX, Tuxedo)
– Transaction Servers (Sybase Jaguar CTS)
– Sistemas CORBA (IBM WebSphere)
– SGBDR (DB2, Oracle, Sybase, Informix)
– SGBDOO (GemStone/J)
– Sistemas Object/Relational (Persistence
PowerTier, Secant Extreme)
– Servidores de aplicações Web (BEA
Weblogic, Netscape Application Server,
Oracle Application Server)
46
EJB Servers Grátis
• http://ejbhome.iona.com/
• http://www.ewavecommerce.com/
47
Concorrência: MTS/COM+
• Microsoft Transaction Server
– Agora se chama COM+
– É o run-time environment para Server
Components, como um Container
– Disponível com Windows 2000
48
Vantagem COM+ sobre EJB
• Load Balancing (prometido para 2000)
• Message Queue (processamento
assíncrono)
• Não precisa desenvolver em Java
– Muitos programadores ainda não sabem
OO!
• Desempenho (?)
• Mais maduro
49
Vantagens de EJB sobre
COM+
• COM+ só roda com Windows 2000
• Não permite Very Thin Clients
– Cliente COM é pesado e requer PC
•
•
•
•
Portabilidade para vários ambientes
Vários fornecedores
Persistência
Stateful Beans com gerência de estado
50
Obrigado.
51