Internasjonalisering og regionalisering av økonomien. 20

Após uma análise dos diferentes mecanismos de interacção do modelo, observou-se que cada um deles possui efectivamente características e funcionalidades desejáveis para criar uma plataforma com as infraestruturas necessárias ao desenvolvimento de uma implementação do modelo MAGO. A opção tomada foi a de escolher uma plata- forma que tornasse disponível uma camada intermédia que cumprisse o maior número de requisitos de base do modelo. A escolha recaiu no sistema JGroupSpaces, um sis- tema desenvolvido no grupo [Cus08].

O JGroupSpace, que assenta no modelo GroupLog, tem disponível um conjunto de primitivas para a gestão dinâmica de grupos e para a interacção baseadas em troca de mensagens, espaço partilhado de tuplos e eventos (5.3). A concepção das funci- onalidades a integrar no JGroupSpace foi, ela própria, influenciada pelos requisitos da definição do modelo MAGO, em particular no que se refere às funcionalidades de suporte a eventos e a espaço de tuplos.

No sistema JGroupSpace um processo é uma entidade activa que executa um pro- grama Java e que, tendo acesso a uma biblioteca oferecida pelo sistema, pode integrar- se em grupos de processos [Cus08].

As funcionalidades estão disponibilizadas através de uma interface de programa- ção (API) em Java e estão separadas em quatro categorias principais:

• Acesso ao grupo: os grupos são criados de forma explícita quando um processo invoca a primitiva de filiação, os grupos são identificados por um identificador global. As primitivas que permitem a entrada, saída e obtenção da constituição de um grupo são:

ARQUITECTURA DE SUPORTE AO MODELO

Figura 5.3:Visão de um grupo no JGroupSpace [Cus08]

– JGSAddress join(String group_name)

Junta um processo a um grupo identificado por group_name; se o grupo ainda não existir é criado quando da filiação do primeiro membro;

– void leave()

O processo invocador sai do grupo;

– JGSMembership getMembership()

Depois de um processo se juntar a um grupo, é possível obter informação sobre a constituição deste, ou seja dos membros que actualmente se encon- tram filiados.

• Envio e recepção de mensagens: os processos presentes num grupo podem co- municar directamente com os outros membros através de mensagens. As primi- tivas para a comunicação por mensagens são:

– void send(JGSMessage msg)

Envia uma determinada mensagem no contexto do grupo. Na mensagem, são especificados, a mensagem, os endereços do emissor e do receptor, note- se que, caso não seja especificado o receptor, a mensagem é enviada para todo o grupo;

– JGSMessage receive(int timeout)

Recebe uma mensagem proveniente do grupo. Opcionalmente pode ser in- dicado um timeout, especificando o período de tempo que o processo deve aguardar pela recepção da mensagem. Caso esse timeout seja 0 e não exista nenhuma mensagem pendente para ser recebida, a primitiva bloqueia até receber uma mensagem.

• Envio e recepção de eventos: os processos presentes num grupo podem comu- nicar de forma assíncrona através de eventos. Os eventos são enviados por um

ARQUITECTURA DE SUPORTE AO MODELO

membro do grupo e têm como destino todos os membros do grupo, no entanto, serão somente notificados do evento, aqueles que tenham definido um handler;

– void setEventHandler(JGSEventHandler handler)

Permite definir um handler para o tratamento de eventos emitidos pelo grupo. Depois de definido, todos os eventos difundidos nesse grupo se- rão recebidos localmente no processo, através da chamada assíncrona do handler;

– JGSEventHandler getEventHandler()

Permite obter o handler definido para o tratamento de eventos emitidos pelo grupo;

– void sendEvent(java.io.Serializable obj)

Envia um evento com um determinado objecto (ob j) para o grupo.

• Espaço de tuplos partilhado: as primitivas para interacção através do espaço partilhado de tuplos associado ao grupo, são baseadas no modelo Linda:

– Tuple out(Tuple t)

Insere um dado tuplo no espaço partilhado do grupo, podendo o tuplo não se encontrar totalmente instanciado. Após esta operação o tuplo fica dispo- nível no espaço partilhado e acessível aos restantes membros;

– void in(Tuple t)

Remove um tuplo do espaço partilhado do grupo, esta primitiva devolve um tuplo existente no espaço compatível com o tuplo dado como argu- mento. Caso não exista nenhum tuplo compatível bloqueia até esse tuplo existir;

– Tuple inp(Tuple t)

Primitiva idêntica à anterior, mas não bloqueia, ou seja, retorna imediata- mente no caso de não existir um tuplo compatível;

– Tuple rd(Tuple t)

Lê um tuplo do espaço partilhado do grupo mas sem o remover. Tal como nas primitivas anteriores, devolve tuplo compatível com o tuplo passado como argumento. Caso não exista nenhum tuplo compatível, bloqueia até esse tuplo existir;

– Tuple rdp(Tuple t)

Versão não bloqueante da primitiva rd;

– Vector rdpall()

Devolve um vector com todos os tuplos que existem no espaço partilhado do grupo.

ARQUITECTURA DE SUPORTE AO MODELO

A representação de um processo Java, num grupo de processos é realizada através de um objecto da classe JGroupSpace, ou seja por cada grupo a que o processo se pre- tenda filiar, deve ser instanciado um objecto desse tipo. Na figura 5.4 pode observar-se como é modelada a situação em que um processo pertence a dois grupos distintos.

Figura 5.4: Exemplo de um processo Java que pertence a dois grupos [Cus08]

Cada grupo, no sistema JGroupSpace, é identificado por um nome (String) definido quando da operação de join. Como resultado desta operação é devolvido um objecto da classe JGSAddress, que permite identificar o processo dentro do grupo, essa classe constitui um encapsulamento de um endereço IP e de uma porta de ligação4.