Coordenação

No desenvolvimento baseado em componentes, a coordenação pode ser definida como um padrão de interação que governa a comunicação e a invocação de operações entre dois ou mais componentes [Loughran et al., 2005]. Nesse contexto, é altamente desejável que os componen- tes não imponham restrições sobre outros componentes que compõem com eles um sistema. Ou seja, os componentes, idealmente, não devem decidir por eles mesmos como o processo de composição deve ser feito, como ocorre na programação orientada a objetos tradicional.

A modelagem da coordenação como um aspecto permite separá-la do código dos compo- nentes. Conseqüentemente, diferentes protocolos de coordenação podem ser programados para controlar a coordenação de diferentes tipos de componentes.

Os protocolos de interação são encapsulados no aspecto de coordenação que descreve como e quando os componentes interagem. Dessa maneira, o chamando glue code é promovido a uma porção de software identificável e reutilizável [Arbab, 2005]. Glue code é a denominação

dada ao código responsável por realizar a conexão de componentes e coordenar a interação entre componentes. Em geral, esse tipo de código é feito utilizando linguagens de script.

A principal vantagem da implementação da coordenação como um aspecto é o alto grau de flexibilidade, uma vez que, sistemas diferentes podem ser arquitetados utilizando o mesmo conjunto de componentes, mas com diferentes regras de composição.

A separação do conceito coordenação inicia-se com a especificação da coordenação como parte da interface pública dos componentes. A partir desse momento, o desenvolvedor precisa conhecer não apenas a lista de operações das interfaces, mas também precisa conhecer o proto- colo de comunicação.

O interesse de coordenação possui diferentes utilidades em uma aplicação distribuída ba- seada em componentes, podendo ser usado, por exemplo, como um adapter ou binding. Nos casos em que as interfaces Provided e Required não são compatíveis, mas suas semânticas são complementares, o interesse de coordenação pode atuar como um adaptador entre as interfaces. A arquitetura de referência faz uso do interesse de coordenação através do conceito de Binding object. Dessa maneira, a coordenação é responsável pelo processo de binding entre diferentes componentes de acordo com um protocolo específico. Nesse modelo, os componentes interagem através de sinais dando origem ao modelo compound bind, bind composto, como mostra a Figura 3.6 extraída de [Loughran et al., 2005].

Figura 3.6: Bind composto

Um ambiente distribuído pode necessitar de vários modelos de coordenação para atingir seus objetivos. Cada modelo de coordenação tem suas peculiaridades, entretanto a separação des- ses modelos do código dos componentes evita o forte acoplamento da abordagem tradicional, na qual o modelo de coordenação é codificado dentro dos componentes. Os modelos publish- and-subscribe, shared data space e channel são exemplos de modelos de coordenação bastante

difundidos. Nos sistemas publish-and-subscribe, os publicadores, publisher, submetem infor- mações no sistema usando repositório de informações, tópicos ou assuntos. Os interessados em receber essas informações, subscribes, devem subscrever-se nesse repositório. Portanto, um componente pode notificar um conjunto de componentes interessados com uma única operação. No modelo shared data space, todos os componentes escrevem e lêem dados em um espaço de endereçamento compartilhado por todos. No modelo channel, um canal é uma conexão ponto- a-ponto entre dois componentes, um fonte e um consumidor. O fonte escreve dados no canal, enquanto que o consumidor lê dados do canal. Nesse modelo a comunicação flui em um único sentido: do componente fonte para o componente consumidor. Os canais podem ser síncronos, assíncronos, FIFOS, LIFOS e etc.

O mapeamento do interesse de coordenação para o modelo de componentes da arquitetura de referência é simples. As interfaces Provided e Required são suficientes para realizar tal tarefa. As interfaces Required são as mesmas dos outros componentes do modelo, logo nenhuma alteração é necessária. Por sua vez, as interfaces Provided são descritas de acordo com o aspecto de coordenação, dependendo do tipo de uso do aspecto em questão e do modelo de coordenação empregado. No caso do aspecto ser utilizado como um adaptador ou um objeto binding para coordenar um conjunto de componentes conhecidos e com um conjunto de operações ou sinais conhecidos, a interface Provided deve ter a definição de um método para cada uma das operações ou sinais que o aspecto é capaz de interceptar.

No caso do aspecto ser utilizado para implementar um modelo de coordenação específico, a descrição das interfaces Provided mudam. No caso do modelo publish-and-subscribe, por exemplo, as interfaces Provided do aspecto de coordenação devem incluir as primitivas usuais utilizadas pelos componentes quando as interações ocorrem segundo esse modelo. Nesse caso específico, o aspecto iria conter uma operação para realizar a publicação, operação publish, e uma operação para realizar a inscrição no repositório de informações, operação subscribe. A Figura 3.7 mostra o modelo de componentes para o modelo de coordenação publish-and-susbcribe.

Figura 3.7: Modelo de componentes do aspecto de coordenação

O mapeamento para o microkernel demonstrou que as suas operações são afetadas por este aspecto. O aspecto de coordenação deve começar a atuar quando os componentes começam a se comunicar, e parar quando a aplicação terminar. Assim, as operações START e STOP são

afetadas por esse aspecto. Quando uma dessas operações é chamada, o aspecto deve tomar alguma atitude. O aspecto de coordenação faz parte da arquitetura da aplicação, assim quando a aplicação é carregada ou descarregada, ele também é carregado ou descarregado. Assim, as operações LOAD e UNLOAD também são afetadas por esse aspecto. Por sua vez, as operações

INSTANTIATE e DESTRUCT são afetadas pelo aspecto de coordenação, pois esse aspecto é

instanciado quando o aspecto de distribuição é carregado ou quando um componente envia um sinal, e é destruído quando o aspecto de distribuição é destruído. Por fim, a operação BIND deve gerenciar o processo de associação entre o aspecto de distribuição e o aspecto de coordenação, quando esse último estiver presente na aplicação.

O mapeamento do aspecto de coordenação para a APL também é bem simples. A definição utilizando a APL do aspecto de coordenação nos casos em que ele atua como um objeto binding ou um adaptador consiste em selecionar as interações entre dois componentes quaisquer, A e B. Por exemplo, a equação 3.5 exibe uma expressão que seleciona todas as invocações a operações localizadas nas interfaces Required do componente A, ponto de junção do tipo call, tendo como alvo o componente B. Similarmente, a Listagem 3.6 mostra uma expressão que seleciona todas as invocações a operações localizadas nas interfaces do tipo Required do componente B cujo alvo é o componente A.

∀c ∈ C, ∀i ∈ c.interf aces, ∀o ∈ o.operations

(c.name = A ∧ i.category ∈ {required}) ∧ (3.5)

(o.signature = “B. ∗ (?parameters) :?result)

∀c ∈ C, ∀i ∈ c.interf aces, ∀o ∈ o.operations

(c.name = B) ∧ (i.category ∈ {required}) ∧ (3.6)

(o.signature = “A. ∗ (?parameters) :?result)

Caso o aspecto empregue um modelo de coordenação, então ele deve capturar as chamadas às operações comuns de tal modelo. Por exemplo, se o aspecto implementa o modelo publish-and- subscribe, então essas operações devem ser interceptadas pela APL. A equação 3.7 exibe uma possível definição dessa expressão descrita utilizando a APL. Essa expressão seleciona todas as invocações aos métodos pusblish ou subscribe que ocorrem em interfaces de componentes do

tipo Required.

∀c ∈ C, ∀i ∈ c.interf aces, ∀o ∈ o.operations(i.category ∈ {required}) ∧ (3.7)

((o.signature = publish(?parametrs) ∨ o.signature = subscribe(?prameters))