Component Replication in Distributed Systems: a Case study using Enterprise Java Beans

1. 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 22th SRDS – 2003 - Italia Mark C. Little Arjuna Technologies Ltd., Newcastle upon Tyne, UK Fábio Favarim

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)

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.

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

5. 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

6. 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.

7. 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

8. 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

9. 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.

10. 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

11. 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

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

13. 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

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

15. 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

16. 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.

17. LCMI/DAS/UFSC Perguntas?