Distribuição

Em um ambiente distribuído, as funcionalidades de instalação, localização e comunicação remota são interesses fundamentais. A Figura 3.3 mostra o modelo de referência para a distri- buição.

Figura 3.3: Modelo de referência para o interesse distribuição

A instalação é o processo de colocação de componentes na topologia de um middleware. Ela é fortemente relacionada a arquitetura da aplicação, desde que a arquitetura descreva quais os componentes existem e como eles se relacionam uns com os outros. Em ambientes baseados em componentes, geralmente, utiliza-se de linguagens de definição arquitetural para descrever espe- cificações abstratas da arquitetura da aplicação, as quais são utilizadas para validar e coordenar

o processo de instalação de componentes. Essas linguagens de definição arquitetural são conhe- cidas na literatura como ADLs (Architecture Definition Language). O interesse de localização fornece facilidades para que os componentes possam localizar e acessar uns aos outros.

Os bindings estáticos são muito restritivos para um ambiente distribuído, assim a localização é feita sob demanda e em tempo de execução. Quando a procura termina, o componente recebe uma referência remota para o componente requisitado. O protocolo para acessar essa referência é dependente de plataforma de middleware. Esse interesse de distribuição pode interagir com outros interesses como segurança, transporte, mobilidade e escalabilidade, além de interagir com conceitos de alto nível como espaços de nomes, grupos, controle de acesso dentre outros.

Finalmente, a comunicação remota provê uma camada de distribuição que permite que um componente cliente comunique-se com um servidor remoto. Em geral, a infra-estrutura de dis- tribuição utiliza proxies (stubs e skeletons) que podem ser acessados pelos componentes do cliente como objetos comuns. Assim os stubs e os skeletons abstraem o substrato do mid- dleware, apresentando-o como uma facilidade de programação nativa para o usuário da aplicação [CORBA, 1999]. Um stub é uma função do cliente que realiza uma invocação remota via uma chamada de função local. Similarmente, um Skeleton é uma função que permite que uma invo- cação remota recebida pelo servidor seja despachada para o servant apropriado, tornando-a uma invocação local [Henning and Vinoski, 1999].

A instalação e a localização são funcionalidades associadas, pois ambas ocorrem em tempo de execução e são tipicamente parametrizadas por arquivos de configuração. Em geral, um com- ponente centralizado conhecido por todos é utilizado para realizar a instalação e a localização de novos componentes. Do lado do cliente, um componente que precisa localizar outro pode fazer uso de uma fábrica de componentes. Essa fábrica torna transparente para o cliente a localização e a instalação dos componentes. Ela deve oferecer operações: resolve e create. A primeira permite a criação de componentes proxy para o atual componente servidor. A finalidade dessa função é permitir a criação de vários tipos de proxies que suportam diferentes tipos de protocolos de comunicação. A segunda permite ao cliente criar um novo componente e obter um instância do componente proxy para a interface requisitada. Inicialmente, o cliente tem uma associação local com a fábrica, ao invocar o método resolve da fábrica, o cliente será associado a um proxy para o componente servidor.

A Figura 3.4 mostra o estado de um cliente antes e após a invocação da operação resolve. Inicialmente o cliente possui apenas a associação com a fábrica de componentes, Figura 3.4(a). Quando o cliente invoca a função resolve da fábrica, os bindings apropriados são criados. No caso da Figura 3.4(b), uma associação entre o cliente e o proxy do servidor é criada.

Figura 3.4: (a) Estado inicial do componente. (b) Estado final do componente

Para modularizar o interesse de localização, aspectos podem ser aplicados sobre a fábrica de componentes durante a instanciação, evitando a codificação de protocolos de resolução dentro dela. Uma definição de uma expressão de ponto de junção para tal aspecto pode ser a sugerida na equação 3.4.

∀i ∈ I, ∀o1, o2,∈ O, i.category ∈ {i.required}

∧(o1.signature= F actory.resolve(...) : Interface) (3.4)

∨(o2.signature= F actory.create(...) : Interface)

A equação 3.4 descreve uma expressão de ponto de junção que intercepta os métodos resolve e create da fábrica. A expressão contida na equação 3.4 diz que: selecione todos os pontos de junção para operações cuja a assinatura case com Factory.resolve(...): Interface ou (∨) com

Factory.create(...) : Interface e (∧) que pertençam a uma interface do tipo Required.

Através da interceptação desses métodos é possível implementar, via aspectos, diversos pro- tocolos e mecanismos que endereçam o problema da localização e do acesso de componentes distribuídos.

O interesse de comunicação também pode ser melhor modularizado através de aspectos. Os aspectos podem atuar durante as invocações realizadas sobre os proxies ou stubs, permitindo a implementação de diversos protocolos como broadcasting, time-stamping dentre outros. A Figura 3.5 compara as abordagens tradicional e a aspectual para modelar o conceito de comu- nicação. A arquitetura tradicional do conceito de distribuição é apresentada na Figura 3.5(a). Note que o proxy tem a responsabilidade de implementar os protocolo de comunicação, o que não ocorre na versão aspectizada exibida na 3.5(b).

Por fim, o mapeamento do interesse distribuição para o microkernel revelou que as operações

bind e unbind são diretamente afetadas por tal interesse, uma vez que o estabelecimento de

(a) Arquitetura tradicional do conceito de distribui- ção

(b) Aspectização do conceito de comunicação

Figura 3.5: Conceito de distribuição

Nos sistemas em que o interesse distribuição atua, as referências para os componentes fontes e alvo devem ser remotas, ou seja, as referências não são meras referências. Entretanto, a forma real dessas referências é dependente da plataforma de middleware. A arquitetura de referência assume que essas referências são URL’s.

Dessa maneira, o bind e o unbind devem ter a competência de estabelecer e encerrar caminhos de comunicação entre os componentes. As outras operações do microkernel também podem sofrer alterações, pois elas podem necessitar de associações distribuídas entre o microkernel e os componentes que requisitam essas operações.