Difus˜ao Selectiva de Pedidos ILU

Tal como nas anota¸c˜oes de desconex˜ao, e pelos motivos j´a referidos, o ILU servir´a de base ao modelo de invoca¸c˜ao de objectos replicados, mas agora com um pretexto adicional: a integra¸c˜ao do sistema de replica¸c˜ao de objectos com o sistema de suporte `a desconex˜ao.

Mecanismo de Invoca¸c˜ao do ILU

As aplica¸c˜oes distribu´ıdas desenvolvidas com base no ILU obrigam o servidor a registar objectos num servi¸co de direct´orio, de modo a que um cliente seja capaz de os localizar. O processo de registo de um objecto consiste basicamente na associa¸c˜ao do seu identificador a um endere¸co IP, juntamente com um porto. Neste porto, e na m´aquina identificada pelo endere¸co em causa, encontrar-se-´a `a escuta o processo que executa o c´odigo correspondente `a implementa¸c˜ao desse objecto (servidor ILU).

5

Quando um cliente interroga o servi¸co de direct´orio sobre um determinado objecto, obt´em como resultado o endere¸co IP e o porto da m´aquina onde se encontra a executar o processo com a concretiza¸c˜ao desse objecto. Nesse momento ´e criado um socket, atrav´es do qual se efectuar˜ao todas as trocas de informa¸c˜ao, entre o cliente e o servidor, que dizem respeito `a invoca¸c˜ao de m´etodos por parte do cliente. Note-se que um servidor pode disponibilizar v´arios objectos criando um ´unico socket para escuta. Neste caso, os stubs do cliente e do servidor encarregam-se de distinguir entre objectos que se encontrem associados ao mesmo ponto de comunica¸c˜ao.

Aquando da cria¸c˜ao do referido socket, efectua-se a seguinte interac¸c˜ao entre o cliente e o servidor:

• envio, por parte do cliente, de um pacote de ping, cujo conte´udo ´e independente do objecto, do servidor e do cliente em causa;

• resposta do servidor com um pacote de aceita¸c˜ao6

, tamb´em independente das enti- dades envolvidas7

.

Depois de estabelecida a conex˜ao entre o cliente e o servidor, para um dado objecto, todas as invoca¸c˜oes de m´etodos referentes a esse objecto s˜ao efectuadas atrav´es do socket criado para o efeito. A invoca¸c˜ao de um m´etodo de um objecto remoto, depois de estabelecida a liga¸c˜ao, compreende as seguintes fases:

• envio, por parte de cliente, de um pacote com os nomes do objecto e do m´etodo, juntamente com os parˆametros para a invoca¸c˜ao deste, mas sem nenhuma informa¸c˜ao relativa ao servidor ou ao cliente;

• resposta do servidor, ap´os a execu¸c˜ao do m´etodo, com os valores de retorno deste (m´etodos que n˜ao retornam quaisquer dados envolvem sempre o envio de um pacote para indicar a conclus˜ao da sua execu¸c˜ao).

Em suma, podemos dizer que o ILU n˜ao utiliza nenhum mecanismo de certifica¸c˜ao ou de seguran¸ca, o que possibilita a manipula¸c˜ao das mensagens trocadas entre clientes e servidores. Em particular, poder-se-˜ao interceptar as invoca¸c˜oes efectuadas pelos clientes, estrat´egia esta que servir´a de base ao modelo proposto.

6

Do inglˆes acknowledge.

7

Na verdade, estes pacotes est˜ao relacionados por um contador, ou seja, o n´umero de sequˆencia atribu´ıdo pelo cliente ao pacote de ping, e refira-se que o cliente numera todos os pacotes que envia, ´e devolvido na resposta do servidor.

Modelo de Interceptores

Dada a natureza do mecanismo de invoca¸c˜ao do ILU, ´e perfeitamente vi´avel inserir uma entidade entre o cliente e o servidor capaz de manipular os pedidos desencadeados pelos clientes. Desta forma, poder-se-´a fazer chegar um pacote de um cliente (pacote de ping ou pacote de invoca¸c˜ao) a v´arios servidores, mediante a utiliza¸c˜ao de um servi¸co de co- munica¸c˜ao em grupo, sem que estes se apercebam de que se trata da mesma invoca¸c˜ao e sem que o cliente detecte que o seu pedido foi multiplicado. Do lado dos servidores tudo se passa como se o cliente tivesse efectuado v´arias invoca¸c˜oes, ou seja, tivesse invocado explicitamente a mesma opera¸c˜ao em cada um dos servidores. Por outro lado, as v´arias respostas (uma por cada servidor dispon´ıvel) poder˜ao ser processadas, fazendo chegar apenas uma ao cliente.

O sistema de invoca¸c˜oes m´ultiplas obtido, e representado na figura 5.1, ´e constitu´ıdo pelos seguintes elementos: Agente ILU Interceptor Comunicação em Grupo Interceptor Cliente ILU Interceptor Cliente ILU Represen- tante Servidor ILU tante Represen- Servidor ILU Servidor ILU tante Represen- tante Represen- ILU Servidor Cliente ILU

• interceptor – Intercepta a comunica¸c˜ao entre o cliente e o servidor e envia cada pacote do cliente para um conjunto de servidores – grupo de objectos – fazendo uso de um servi¸co de comunica¸c˜ao em grupo (servi¸co de difus˜ao selectiva de mensagens).

`

A medida que os v´arios servidores v˜ao respondendo com pacotes de aceita¸c˜ao ou de resultados, conforme o pacote enviado pelo cliente, o interceptor tem ainda a seu cargo a tarefa de recolher todas essas respostas, entregando apenas uma ao cliente em causa.

• servi¸co de difus˜ao selectiva – Faz chegar um determinado pacote, enviado por um cliente, a um grupo de servidores. Pressup˜oe a cria¸c˜ao de grupos de objectos e a atribui¸c˜ao de um identificador a cada grupo.

Este servi¸co ser´a respons´avel por garantir uma evolu¸c˜ao coerente no estado das v´arias r´eplicas, conforme j´a referido.

• representantes – Recebem pedidos atrav´es do servi¸co de difus˜ao selectiva e entregam- -os ao respectivo servidor, devolvendo de igual forma os resultados associados `a opera¸c˜ao executada.

Os representantes s˜ao necess´arios, neste modelo, devido ao facto de os servidores, por si s´o, n˜ao serem destinat´arios v´alidos de um sistema de difus˜ao selectiva gen´erico, quer se trate de um grupo de servidores, quer se trate de um servidor em particular. Integra¸c˜ao com o Modelo CAS

A descri¸c˜ao at´e aqui efectuada, relativa ao modelo de interceptores, evidencia a adapta¸c˜ao de aplica¸c˜oes desenvolvidas segundo o modelo Cliente-Servidor. No entanto, nada ´e dito em rela¸c˜ao ao modelo CAS apresentado no cap´ıtulo 4. Note-se que, com a integra¸c˜ao destas duas abordagens, ter-se-ia um modelo de programa¸c˜ao com suporte para desconex˜ao e com a possibilidade de replicar servidores.

Dado que o agente do modelo CAS age como cliente na sua interac¸c˜ao com o servidor, o sistema de intercep¸c˜ao de pedidos ILU pode ser colocado entre estas duas entidades (agente e servidor). De referir que a hip´otese de interceptar pedidos do cliente e proceder ao seu encaminhamento para v´arios agentes n˜ao tem o m´ınimo interesse, pois o agente ´e uma entidade bastante ”pr´oxima” do cliente, sendo sempre poss´ıvel a comunica¸c˜ao entre estes.

As invoca¸c˜oes m´ultiplas permitem a migra¸c˜ao para o modelo Cliente-Servidores. Em con- jun¸c˜ao com a no¸c˜ao de Agente tem-se a arquitectura Cliente-Agente-Servidores (CASs), onde o sistema de invoca¸c˜oes m´ultiplas ´e colocado entre o agente e as r´eplicas dos servi- dores. Na figura 5.1 encontra-se representada a interac¸c˜ao de um cliente com um agente, cujos pacotes s˜ao processados por um interceptor que os faz chegar a trˆes r´eplicas.