A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

28/01/20041 Component Replication in Distributed Systems: a Case study using Enterprise Java Beans Mark C. Little Arjuna Technologies Ltd., Newcastle upon.

Apresentações semelhantes


Apresentação em tema: "28/01/20041 Component Replication in Distributed Systems: a Case study using Enterprise Java Beans Mark C. Little Arjuna Technologies Ltd., Newcastle upon."— Transcrição da apresentação:

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

2 LCMI/DAS/UFSC 28/01/ 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)

3 LCMI/DAS/UFSC 28/01/ 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.

4 LCMI/DAS/UFSC 28/01/ 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

5 LCMI/DAS/UFSC 28/01/ 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

6 LCMI/DAS/UFSC 28/01/ 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.

7 LCMI/DAS/UFSC 28/01/ 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 Aplicações EJB com transação

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

9 LCMI/DAS/UFSC 28/01/ 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. Exemplo de Transação

10 LCMI/DAS/UFSC 28/01/ 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 Disponibilidade nos servidores de aplicação atuais

11 LCMI/DAS/UFSC 28/01/ 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

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

13 LCMI/DAS/UFSC 28/01/ 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

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

15 LCMI/DAS/UFSC 28/01/ Replicação de Componentes – Caso 2 A possibilidade de multiplas transações aumenta a dificuldade em manter os resource managers consistentes. T1 lendo do RDBMS A1 e T2 lendo RDBMS A2 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

16 LCMI/DAS/UFSC 28/01/ 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.

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


Carregar ppt "28/01/20041 Component Replication in Distributed Systems: a Case study using Enterprise Java Beans Mark C. Little Arjuna Technologies Ltd., Newcastle upon."

Apresentações semelhantes


Anúncios Google