Post on 07-Apr-2016
1
Enterprise JavaBeansComponentes para o
Desenvolvimento de Sistemas Distribuídos Corporativos
Jacques P. Sauvéjacques@dsc.ufpb.br
2
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 ...
3
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
4
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?
5
Qual é o Custo doStatus 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?
6
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
7
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
8
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
9
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ão-crítica
• Menor risco– Possibilitando tudo que falamos acima e ainda
não se arriscar a ter projetos fracassados
10
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
11
Arquiteturas Multi-Tier
User Services Tier
Business Services Tier
(Middle Tier) Data Services Tier
Legado
12
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, ...)
13
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, ...
14
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
15
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”
16
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)
17
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!
18
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"
19
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”
20
Característica de Componente
• Um componente explicita suas interfaces– Interfaces padronizadas para ser “Plug-
Replaceable”– Interfaces devem ser auto-descritivas para
permitir que um ambiente visual conecte componentes entre si
21
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
22
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
23
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!
24
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
– Nada tem a ver com JavaBeans
25
Quem apoia EJB?
• Todos fora Microsoft apoiam EJB como arquitetura de Server Components– IBM– Oracle– Netscape– BEA Systems– Sun Microsystems– Sybase– etc.
26
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
27
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
28
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
29
A Arquitetura EJB
30
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
31
Novos Papeis, Novo Processo
32
EJB: As Interfaces e Objetos
33
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
34
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
deles
35
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 Objeto-Relacional, etc.
36
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
37
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
38
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
39
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 Object-
Relational– Uso de SGBDOO
40
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
41
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
42
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
43
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.
44
EJB: Tipos de Aplicações Cliente
45
Exemplo: E-Commerce
46
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)
47
EJB Servers Grátis
• http://ejbhome.iona.com/• http://www.ewavecommerce.com/
48
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
49
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
50
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
51
Obrigado.