Invoca¸c˜oes M´ ultiplas

A invoca¸c˜ao de procedimentos remotos, ou de acordo com os paradigmas actuais, a in- voca¸c˜ao de m´etodos sobre objectos distribu´ıdos, segue o tradicional modelo Cliente-Ser- vidor. Assim, as ferramentas para desenvolvimento de aplica¸c˜oes distribu´ıdas baseadas neste modelo permitem que um cliente invoque uma ´unica opera¸c˜ao sobre uma deter- minada concretiza¸c˜ao remota (objecto ou procedimento). No entanto, certas aplica¸c˜oes podem beneficiar da execu¸c˜ao da mesma opera¸c˜ao em v´arios servidores e em simultˆaneo, como acontece, por exemplo, na replica¸c˜ao de servidores. Neste caso, conv´em que uma ´

unica instru¸c˜ao num cliente (a invoca¸c˜ao da opera¸c˜ao remota) desencadeie execu¸c˜oes em v´arias m´aquinas. No que respeita ao ILU, a invoca¸c˜ao de um m´etodo de um objecto remoto dever´a activar a execu¸c˜ao desse m´etodo em mais do que uma implementa¸c˜ao do objecto em causa.

Solu¸c˜oes Existentes

Recentemente surgiram alguns trabalhos nesta ´area, dos quais se destacam o Electra e o Generic Remote Invocation Protocol (GRIP).

O Electra [54] adiciona ao CORBA a abstrac¸c˜ao de grupo de objectos aliada `a difus˜ao selectiva fi´avel. Fundamentalmente, trata-se de um ORB constru´ıdo de acordo com a especifica¸c˜ao CORBA e caracterizado pelo conceito de grupo.

O sistema Electra foi desenvolvido para operar sobre plataformas do g´enero do Horus [55] ou do Isis [56]. Estas plataformas baseiam-se em modelos que asseguram que decis˜oes re- lacionadas tomadas por processos distintos num sistema distribu´ıdo s˜ao mutuamente coe- rentes e que as ac¸c˜oes s˜ao correctas temporalmente, mesmo quando os v´arios componentes comunicam assincronamente. Estes modelos permitem que uma aplica¸c˜ao distribu´ıda te- nha um comportamento previs´ıvel apesar do mau funcionamento de alguns componentes e da natureza mutat´oria destes (entrada e sa´ıda de processos).

Presentemente, o Electra ´e constitu´ıdo por um compilador da IDL do CORBA, um DII, uma interface para o ORB desenvolvido2

, um BOA e adaptadores de objectos para o Horus e para o Isis.

O GRIP [57] tem como objectivo manter a transparˆencia do esquema de replica¸c˜ao de objectos. Este protocolo ´e independente do protocolo do servi¸co de replica¸c˜ao e n˜ao coloca restri¸c˜oes ao modelo de coerˆencia das r´eplicas.

2

Esta interface permite o acesso `as opera¸c˜oes que manipulam grupos de objectos, para al´em das opera¸c˜oes normais de um ORB.

O modelo de interac¸c˜ao oferecido pelo GRIP tem como base um servi¸co de comunica¸c˜ao em grupo com ordena¸c˜ao causal. Neste modelo, um cliente interage com um servidor atrav´es de um protocolo espec´ıfico – o Remote Access Protocol (RAP). Simplificadamente, do lado do cliente, este protocolo trata de obter a lista dos servidores dispon´ıveis num dado momento, efectuando de seguida sucessivas invoca¸c˜oes at´e que um dos servidores devolva uma resposta. Do lado do servidor, este protocolo encarrega-se de entregar o pedido recebido de um cliente, devolvendo o resultado associado, no final da execu¸c˜ao da opera¸c˜ao em causa. Um cliente pode ainda receber, atrav´es do RAP, informa¸c˜ao sobre o servidor mais aconselh´avel para uma determinada invoca¸c˜ao.

Por forma a garantir uma semˆantica do tipo quando-muito-uma-vez3

, os v´arios servidores executam opcionalmente um outro protocolo – o Protocol for Repeated Invocation DEtec- tion (PRIDE). Note-se que, devido `a fiabilidade das liga¸c˜oes ponto-a-ponto, cada r´eplica executar´a quando muito uma vez cada pedido efectuado por um cliente. No entanto, dado o funcionamento do RAP, um cliente pode invocar a mesma opera¸c˜ao sobre v´arios servi- dores, e entre aqueles que recebem o pedido poder˜ao existir v´arios a executar a opera¸c˜ao em causa.

A coerˆencia das r´eplicas ´e garantida atrav´es da cria¸c˜ao de um grupo – grupo de servidores – onde ´e trocada informa¸c˜ao relacionada com a actualiza¸c˜ao individual de cada r´eplica. O protocolo usado entre as v´arias r´eplicas ´e totalmente independente do GRIP.

Invoca¸c˜oes Transparentes aos Clientes e Servidores

A invoca¸c˜ao simultˆanea de m´ultiplas concretiza¸c˜oes de um objecto n˜ao s´o tem interesse na replica¸c˜ao de servi¸cos como tamb´em pode ser de grande valor no desenvolvimento de aplica¸c˜oes cooperativas, onde colaboram mais que duas entidades, e de aplica¸c˜oes com necessidades de difus˜ao de informa¸c˜ao, onde uma entidade divulga determinada informa¸c˜ao para um conjunto de potenciais receptores.

No caso da replica¸c˜ao, o objectivo primordial ´e a tolerˆancia a faltas, que tamb´em constituiu a motiva¸c˜ao dos projectos Electra e GRIP. Para os outros casos, n˜ao se imp˜oe requisitos t˜ao fortes no que respeita `a sincroniza¸c˜ao de r´eplicas. Ali´as, o protocolo usado pelos servidores para garantir a coerˆencia das r´eplicas dever´a ser independente do mecanismo das invoca¸c˜oes e em alguns casos poder´a at´e haver interesse em replicar objectos cuja concretiza¸c˜ao original n˜ao inclui c´odigo para sincroniza¸c˜ao entre r´eplicas. Este pressuposto permitir´a desenvolver um mecanismo de invoca¸c˜ao m´ultipla mais simples, do ponto de vista da sua concep¸c˜ao e at´e no que respeita `a sua utiliza¸c˜ao.

Note-se que, na difus˜ao de informa¸c˜ao e nas aplica¸c˜oes cooperativas, os v´arios receptores

3

de uma mensagem – uma invoca¸c˜ao no modelo Cliente-Servidor – ser˜ao v´arios servidores que implementam um determinado objecto. Deste modo, tais receptores ser˜ao tamb´em r´eplicas do objecto em causa. Fundamentalmente, esta abordagem permite uma forma de comunica¸c˜ao em grupo, onde os v´arios membros trocam informa¸c˜ao atrav´es de invoca¸c˜oes de m´etodos, as quais constituem abstrac¸c˜oes para uma interac¸c˜ao a um n´ıvel mais elevado que a troca de mensagens oferecida pelos servi¸cos de comunica¸c˜ao em grupo.

Por outro lado, nem o Electra nem o GRIP permitem invoca¸c˜oes m´ultiplas de forma trans- parente aos clientes, ou seja, o despoletar de m´ultiplas execu¸c˜oes remotas com uma ´unica invoca¸c˜ao efectuada pelo cliente n˜ao ´e totalmente transparente para este. De facto, no Electra existem opera¸c˜oes espec´ıficas para interagir com o ORB, as quais s˜ao desencade- adas pelo cliente, enquanto que no GRIP, o cliente ´e obrigado a executar um protocolo especial – o RAP. No que respeita aos servidores, embora estes n˜ao tenham conhecimento dos restantes destinat´arios de um determinado pedido recebido, a n˜ao ser que o protocolo que usam para garantir a coerˆencia de r´eplicas a isso obrigue, imp˜oe-se que a sua con- cretiza¸c˜ao tenha em considera¸c˜ao o sistema usado para suportar as invoca¸c˜oes m´ultiplas. Deste modo, e contrariamente ao sistema aqui desenvolvido, ´e colocada de parte a hip´otese de construir servi¸cos replicados tendo como base aplica¸c˜oes j´a existentes e desenvolvidas segundo o modelo Cliente-Servidor.

Partindo do mecanismo de invoca¸c˜ao de m´etodos remotos oferecido pelo ILU – invoca¸c˜oes 1:14

– interessa portanto desenvolver um sistema que fa¸ca chegar uma c´opia de um pedido de um cliente a v´arios servidores – invoca¸c˜oes l:n – tendo em considera¸c˜ao os seguintes requisitos:

• dever´a ser poss´ıvel construir um sistema com servidores replicados, tomando como base um cliente e um servidor desenvolvidos para operar segundo o tradicional.modelo Cliente-Servidor, sem que seja necess´ario alterar os programas (cliente e servidor) j´a existentes;

• dever´a ser poss´ıvel definir grupos de objectos ILU e constituir identificadores que permitam tratar um conjunto de objectos como uma entidade ´unica;

• as implementa¸c˜oes dos v´arios objectos que constituem um grupo dever˜ao receber uma c´opia idˆentica do pedido efectuado pelo cliente;

• a execu¸c˜ao, por parte de um servidor, das opera¸c˜oes associadas a uma determinada invoca¸c˜ao dever´a ser independente do n´umero de servidores (objectos) que consti- tuem o grupo visado por tal invoca¸c˜ao;

4

• as m´ultiplas respostas a um determinado pedido, uma por cada r´eplica, dever˜ao ser filtradas de maneira a que ao cliente apenas chegue uma resposta5

;

• o mecanismo de entrega de pedidos aos v´arios elementos de um grupo dever´a assegu- rar a recep¸c˜ao do pedido por todos estes e dever´a garantir uma determinada ordem – total ou, pelo menos, causal – na entrega dos pedidos, por forma a possibilitar al- guma coerˆencia no estado das r´eplicas, mesmo quando estas n˜ao executam nenhum protocolo para o efeito;

• todo o sistema de suporte `as invoca¸c˜oes m´ultiplas dever´a ser independente do c´odigo dos clientes e dos servidores e n˜ao dever´a ser necess´ario introduzir quaisquer al- tera¸c˜oes aos stubs gerados pelas ferramentas do ILU.

De referir que o sistema a desenvolver, com base nestes requisitos, n˜ao ter´a em considera¸c˜ao o problema da duplica¸c˜ao desnecess´aria de interac¸c˜oes [58, 59]. Isto significa que, se um determinado pedido de um cliente chegar a v´arios servidores (uma c´opia a cada) e se estes servidores usarem servi¸cos de uma terceira entidade, replicada ou n˜ao, esta ´ultima receber´a indica¸c˜ao para efectuar v´arias vezes a mesma opera¸c˜ao. Por outras palavras, dado que n˜ao existe qualquer tipo de coordena¸c˜ao entre os servidores, cada um efectuar´a invoca¸c˜oes de forma independente. Se as opera¸c˜oes associadas a estas invoca¸c˜oes n˜ao forem idempotentes, ent˜ao um ´unico pedido de um cliente despoletar´a v´arias execu¸c˜oes, num mesmo servidor, que poder˜ao criar incoerˆencias. Este ´e um problema que fica em aberto no mecanismo de replica¸c˜ao de objectos aqui apresentado.