Generalidade

No contexto desta disserta¸c˜ao, um arcabou¸co para o desenvolvimento de software ´e t˜ao mais gen´erico quanto maiores forem as diferen¸cas poss´ıveis entre suas instˆancias. A generalidade de um sistema de middleware, por sua vez, de acordo com este mesmo conceito, pode ser medida pela quantidade de cen´arios diferentes com os quais ele pode lidar. Nesse sentido CORBA apresenta maior generalidade que Java RMI, pois aquela plataforma pode suportar aplica¸c˜oes escritas em diferentes linguagens, ao passo que o sistema da Sun est´a restrito `a linguagem Java. Arcademis foi proposto com o objetivo primordial de facilitar a implementa¸c˜ao de sistemas de middleware baseados em invoca¸c˜ao remota de m´etodos, por´em este arcabou¸co tamb´em pode ser utilizado no desenvolvimento de plataformas baseadas em outros paradigmas, diferentes do orientado por objetos. A fim de ilustrar tal possibilidade, esta se¸c˜ao mostra como Arcademis pode ser usado no desenvolvimento de uma implementa¸c˜ao de PeerSpaces [VBBP02]. Este sistema ´e um middleware voltado para a coordena¸c˜ao de aplica¸c˜oes em redes m´oveis ad-hoc, que baseia-se em uma estrutura de dados denominada espa¸co de tuplas.

Espa¸cos de tuplas, introduzidos por David Gelernter na especifica¸c˜ao da linguagem Linda [Gel85], s˜ao estruturas de dados presentes em cada um dos nodos que integram uma rede em PeerSpaces, e onde podem ser disponibilizados servi¸cos e informa¸c˜oes. Tuplas s˜ao listas ordena- das de campos, cada campo possuindo um tipo bem definido, como int ou java.lang.String, por exemplo. Diversos nodos podem interagir procurando, lendo, escrevendo e consumindo in- forma¸c˜oes em seus pr´oprios espa¸cos ou em reposit´orios de seus vizinhos, o que ´e feito por meio de opera¸c˜oes b´asicas. Tais opera¸c˜oes s˜ao descritas por um conjunto de quatro primitivas: in, out, rd e find. A primeira opera¸c˜ao remove e a segunda insere dados no espa¸co de tuplas. O comando rd realiza a leitura de dados e a primitiva find permite realizar opera¸c˜oes de busca na rede de computadores.

Uma implementa¸c˜ao de PeerSpaces baseada em Arcademis pode valer-se do modelo de obje- tos distribu´ıdos utilizado pelo arcabou¸co. Cada host, isto ´e, cada entidade que det´em o controle de um espa¸co de tuplas, seria implementado como um objeto remoto, cujos m´etodos s˜ao as qua- tro primitivas definidas em PeerSpaces. Como cada stub possuiria somente quatro opera¸c˜oes, o c´odigo destes componentes poderia ser otimizado a fim de obter benef´ıcio de algumas particulari- dades de cada primitiva. Por exemplo, segundo a especifica¸c˜ao de Arcademis, chamadas remotas possuem identificadores. Estes poderiam ser usados para evitar ciclos durante a propaga¸c˜ao de buscas na rede via o comando find.

Como ´e poss´ıvel notar, embora Arcademis tenha sido projeto a fim de permitir a instancia¸c˜ao de sistemas de middleware orientados por objetos, ele pode ser utilizado no desenvolvimento de plataformas que obedecem paradigmas diferentes. Outro elemento que vem contribuir para demonstrar a generalidade deste Arcabou¸co ´e o fato de ele poder ser utilizado em J2ME, uma distribui¸c˜ao da linguagem Java diferente de J2SE, a vers˜ao em que foi desenvolvido Java RMI. A fim de alcan¸car tal objetivo, a implementa¸c˜ao de Arcademis utiliza somente tipos primitivos, interfaces e classes que s˜ao comuns a todas as distribui¸c˜oes de Java. Assim, nenhum dentre os componentes de Arcademis utiliza tipos como float ou double, uma vez que eles n˜ao se encontram dispon´ıveis para Java Micro Edition.

Contudo, Arcademis ainda est´a restrito `a linguagem Java, muito embora este arcabou¸co possa ser utilizado no desenvolvimento de diferentes tipos de middleware e nas trˆes diferentes edi¸c˜oes desta linguagem de programa¸c˜ao: J2ME, J2SE e J2EE. Assim, sistemas de middleware derivados de Arcademis s˜ao implementados em Java e aplica¸c˜oes distribu´ıdas que s˜ao executadas sobre tais plataformas tamb´em devem ser implementadas nesta linguagem. Esta ´ultima restri¸c˜ao n˜ao se aplica a CORBA ou .NET, por exemplo, pois tais plataformas suportam objetos implementados em diferentes linguagens de programa¸c˜ao, desde que estas possuam um mapeamento para a linguagem de defini¸c˜ao de interfaces fornecida por cada modelo.

Esta restri¸c˜ao de Arcademis, embora uma desvantagem, em termos de generalidade, apre- senta alguns pontos positivos. Em primeiro lugar, sendo um sistema voltado exclusivamente para a linguagem Java, Arcademis pode tirar proveito de todos os recursos mais importantes desta linguagem, como a resolu¸c˜ao de tipos e o carregamento de classes em tempo de execu¸c˜ao, por exemplo. A fim de melhor ilustrar tal vantagem, pode-se considerar a implementa¸c˜ao de RMI derivada de Quarterware. Conforme discutido na Se¸c˜ao 2.5.2, nesta plataforma, apenas objetos cujo tipo ´e conhecido em tempo de compila¸c˜ao podem ser serializados. Esta limita¸c˜ao se deve ao fato de Quarterware ter sido implementado em C++, n˜ao havendo nesta linguagem carregadores dinˆamicos de classes, os quais permitiriam que um cliente pudesse ter acesso aos bytecodes de uma classe localizada em outro host.

Outra vantagem que adv´em do fato de instˆancias de Arcademis apenas precisarem lidar com aplica¸c˜oes implementadas em Java ´e a simplicidade das mesmas, pois n˜ao ´e preciso que tais plataformas de middleware interajam com linguagens de defini¸c˜ao de interface, como IDL de

CORBA. Tal fato evita a necessidade de serem desenvolvidos tradutores e torna mais simples o acoplamento entre as aplica¸c˜oes distribu´ıdas e o middleware subjacente.