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.