Mark C. Little Arjuna Technologies Ltd., Newcastle upon Tyne, UK

Apresentação em tema: "Mark C. Little Arjuna Technologies Ltd., Newcastle upon Tyne, UK"— Transcrição da apresentação:

1 Mark C. Little Arjuna Technologies Ltd., Newcastle upon Tyne, UK
Component Replication in Distributed Systems: a Case study using Enterprise Java Beans A.I.Kistijantoro, Graham Morgan, Santosh K. Shrivastava School of Computing Science, Newcsatle University, UK Mark C. Little Arjuna Technologies Ltd., Newcastle upon Tyne, UK 22th SRDS – Italia Fábio Favarim 28/01/2004

2 LCMI/DAS/UFSC Introdução Nova tendência - extensão middleware orientado a objetos (MOO) p/orientado a componentes (MOC) MOC - o programador precisa se preocupar com a lógica, assim como os serviços utilizados. POC - Maior vantagem o programador se preocupa somente com a parte lógica da aplicação serviços são de responsabilidade dos containers serviços necessários são específicados de maneira declarativa. Enterprise Java Beans (EJB) e CORBA Component Model (CCM) 28/01/2004

3 LCMI/DAS/UFSC Introdução Fornecer suporte para replicação de componentes para fornecer alta disponibilidade Estudo de Caso em EJB, provavelmente aplicável p/CCM Maior disponibilidade de implementações Considera consistência estrita entre as réplicas Objetivo não é inventar novas técnicas de replicação, mas investigar como as técnicas existentes podem ser migradas para componentes. Delegar a responsabilidade do gerenciamento da replicação para o container. 28/01/2004

4 LCMI/DAS/UFSC Introdução São considerados três abordagens de replicação, iniciando com uma abordagem simples na qual são incorporadas mais sofisticação: 1. Replicação de estado com um único servidor de aplicação 2. Replicação de estado com cluster de servidores de aplicação 3. Replicação de estado e computação com cluster de servidores de aplicação 28/01/2004

5 Introdução Solução transparente para o middleware. Isso impõe:
LCMI/DAS/UFSC Introdução Solução transparente para o middleware. Isso impõe: Sem modificações na API entre cliente e componente; Sem modificaçõe na API entre EJB e container; Sem modificações nos serviços e APIs existentes. Possível somente para as aborgens 1 e 2 Para a abordagem 3 é preciso que a ultima restrição seja quebrada 28/01/2004

6 EJB e Servidores de Aplicação
LCMI/DAS/UFSC EJB e Servidores de Aplicação Três tipos: Entidade Sessão – com estado e sem estado Message driven beans O container é responsável por “hospedar” os componentes e assegurar que os serviços estejam disponíveis em tempo de execução. Os serviços fornecidos podem ou não ser gerenciados pelo container. O container é fica hospedado em um servidor de aplicação. 28/01/2004

7 Aplicações EJB com transação
LCMI/DAS/UFSC Aplicações EJB com transação Um dos muitos serviços fornecidos pelo servidor de aplicação para o container é o Serviço de transação. Um gerenciador de transação é hospedado por um servidor de aplicação e é responsável pelo gerenciamento das transações. Não necessariamente precisa ficar dentro do servidor de aplicação Necessário pelo menos um resource manager (meio de armazenamento persistente) para manter o estado do entity bean 28/01/2004

8 Aplicações EJB com transação
LCMI/DAS/UFSC Aplicações EJB com transação Resource Manager = RDBMS Resource Adaptor = JDBC e XAResource XAResource interface – interface entre transaction manager e resource manager 28/01/2004

9 Exemplo de Transação Session bean recebe invocação do cliente
LCMI/DAS/UFSC Exemplo de Transação Session bean recebe invocação do cliente Resulta no session bean iniciando uma transação (T1) envolvendo os 2 componentes (X e Y) Session bean ativa X e Y (pega o estado do RDMS) Isso faz com faça um lock na linha da tabela, para evitar que outra transação use o mesmo recurso – propriedade da serialização de transações. XAa e XAb registram-se no gerenciador de transação. Quando a transação termina, tenta executar um protocolo em duas fases para assegurar q todos os participantes commit ou rollback T1. 28/01/2004

10 Disponibilidade nos servidores de aplicação atuais
LCMI/DAS/UFSC Disponibilidade nos servidores de aplicação atuais Servidores de aplicação comerciais implantados em um cluster de máquinas hardware específico para rotear as requisições de modo a mascarar as falhas  NAT (Network Address Translation) mecanismos de replicação de dados proprietários. Stateless session beans – OK Statefull session beans – problema Uso de session beans stateless p/contornar esse problema Uso de session beans statefull p/serialização e de-serialização Falha na serialização não é tratada. Transação não é suportada – o mesmo servidor deve ser usado sempre 28/01/2004

11 Replicação de Componentes – Caso 1
LCMI/DAS/UFSC Replicação de Componentes – Caso 1 Replicação de estado com um único servidor de aplicação Uso de “available copies” para replicação de dados Leitura de qualquer um e gravação em todos Uso de proxies para o JDBC e para XAResource Os proxies re-transmite as invocações vindas do transaction manager e dos beans para os resource adaptors 28/01/2004

12 Replicação de Componentes – Caso 1
LCMI/DAS/UFSC Replicação de Componentes – Caso 1 28/01/2004

13 Replicação de Componentes – Caso 2
LCMI/DAS/UFSC Replicação de Componentes – Caso 2 Replicação de estado com cluster de servidores de aplicação Usa o esquema anterior para fornecer replicação de estado 28/01/2004

14 Replicação de Componentes – Caso 2
LCMI/DAS/UFSC Replicação de Componentes – Caso 2 28/01/2004

15 Replicação de Componentes – Caso 2
LCMI/DAS/UFSC Replicação de Componentes – Caso 2 A possibilidade de multiplas transações aumenta a dificuldade em manter os resource managers consistentes. T1 lendo do RDBMSA1 e T2 lendo RDBMSA2 Pode quebrar a propriedade da serialização de transações Ter um RDBMS primário Os proxies dos diferentes servidores devem concordar no resource manager primário. Uso de um protocolo de consenso entre os proxies Consistência RDBMS - operação de gravação em todas os RDBMS 28/01/2004

16 Replicação de Componentes – Caso 3
LCMI/DAS/UFSC Replicação de Componentes – Caso 3 Replicação de estado e computação com cluster de servidores de aplicação Usa o esquema anterior para fornecer replicação de estado para um cluster de servidores Necessário então mascarar as falhas dos servidores de aplicação. Para isso: replicar os containers em servidores de aplicação distintos Assegurar a consistência dos estados dos EJBs nos containers Consistência entre os estados das transações nos transaction managers Uso da replicação passiva e ativa. Ideal -> tirar uma foto do SA e reproduzir em outro lugar É dificil -> não há padronização para transferência de estado de containers e servidores de aplicação. 28/01/2004

17 LCMI/DAS/UFSC Perguntas? 28/01/2004