4.3 OppkjØp og fusjoner som vekststrategi
4.4.1 Fører uvennlige og lånefinansierte oppkjØp til økt verdiskaping? 60
São de seguida descritas com maior detalhe a semântica operacional e a realização das primitivas oferecidas pelo modelo e que são definidas como métodos que permitem
ARQUITECTURA DE SUPORTE AO MODELO
representar o comportamento das entidades, no que se refere à sua gestão própria e enquanto elementos dinâmicos do sistema.
São inicialmente apresentadas as primitivas que efectuam a manipulação de enti- dades elementares enquanto membros do grupo universal, efectuando a sua gestão e a sua identificação única, como membros do sistema. Finalmente são apresentadas as primitivas que permitem efectuar a gestão de entidades dentro da estrutura de grupos.
• Registo de entidades no sistema - register()
Esta primitiva regista a entrada de entidades no sistema. Podem verificar-se duas situações distintas:
– tratar-se de uma entidade "nova", tem que ser garantida a atribuição de um
identificador único e estabelecido o seu "espaço" de comunicação no grupo universal;
– tratar-se de uma entidade já pertencer ao sistema, tem que se proceder a uma
reatribuição de endereços e efectuar a respectiva actualização nas estruturas de suporte do sistema.
No primeiro caso a entidade não possui ainda um registo, ou seja, é a sua pri- meira interacção com o sistema (ver figura 5.9):
– desencadeia o pedido de acesso, comunica com o servidor GU, através de
RMI (Remote Method Invocation), chamando métodos do servidor para criar uma entrada, nas estruturas e no SI, para a nova entidade, sendo-lhe retor- nado o identificador atribuído;
– cria objecto (JGroupSpace) e filia-se no grupo universal ("GroupU" é o iden-
tificador atribuído ao grupo universal) através da primitiva disponível na plataforma de suporte (JGroupSpace); desta forma, passa a ter acesso aos mecanismos de interacção definidos para este tipo de objecto;
– comunica, ao servidor GU, os dados referentes à sua filiação (endereço uni-
versal), através do mecanismo de comunicação directa.
No segundo caso, a entidade já pertence ao sistema (ou seja, já tinha efectuado uma acção prévia de registo), trata-se de efectuar uma operação de "login", isto é iniciar uma nova "sessão". Nesta situação tem que se proceder a uma actualização do mapeamento de endereços, ao nível do servidor de endereços, para cada um dos grupos em que se encontra filiada.
– cria objecto (JGroupSpace) e obtém novo endereço na plataforma14;
14Os endereços atribuídos na plataforma JGroupSpace não são fixos, sendo atribuído um novo ende-
ARQUITECTURA DE SUPORTE AO MODELO
Figura 5.9:Sequência de acções desencadeada pela invocação da primitiva register()
– actualiza o mapeamento deste endereço no servidor de endereços
(setMGAddress());
– percorre a sua estrutura de grupos e desencadeia o processo de criação e
junção nos seus grupos, e respectiva actualização de endereços no servidor de endereços. Este processo é distinto do de filiação, pois a entidade não é novamente sujeita a um processo de admissão, procedendo somente a uma actualização do mapeamento dos endereços lógicos no servidor de endere- ços.
Na fase de registo da entidade foi também utilizado o campo validação, por ques- tões operacionais, como forma de efectuar uma validação de acessos autorizados. A existência deste campo foi motivada pela necessidade de diferenciar as situa- ções de entrada no sistema e a de reentrada (tipo login). Ao entrar no sistema foi definido um identificador único para a entidade e um endereço através do qual esta pode ser contactada no grupo universal (login) e foi definido também um campo de validação que actua como chave de acesso do sistema.
A sequência de operações que é desencadeada (utilizando o campo validação), no caso de entrada de elemento no sistema e na situação em que o identificador da entidade já existe, ou seja, existe um elemento na lista de entidades registadas, com o identificador indicado, quando do login da entidade:
– verifica o valor do campo "validação" (que funciona como um chave de
acesso):
∗ se o valor não foi definido (valor "vazio"), significa que se trata de uma nova entidade e que esta tem que se registar no sistema, procedendo ao registo normal no sistema;
ARQUITECTURA DE SUPORTE AO MODELO
∗ se o valor se encontra já definido (ou seja, não "vazio"), significa que se trata de uma entidade já registada no sistema; nessa situação tem-se os seguintes casos:
· o valor do campo de validação não coincide com o valor introduzido quando da nova entrada ("login" no sistema), nesse caso o acesso da entidade ao sistema é recusado;
· o valor do campo de validação coincide com o valor introduzido quando da nova entrada, nesse caso o acesso da entidade ao sistema é autorizado, sendo efectuada a actualização do mapeamento de en- dereços ao nível do servidor de endereços
• Remoção de entidades do sistema - unregister()
Ao invocar esta primitiva, a entidade efectua uma comunicação directa com o servidor de GU, sinalizando a sua intenção de saída do sistema. Ao receber este pedido de saída, o servidor remove a entrada da entidade da sua estrutura de suporte de entidades, remove do sistema de informação, os dados associados à entidade15 e seguidamente, desencadeia o processo de saída da entidade dos vários grupos a que pertence, percorrendo a sua lista de grupo e desencadeando a acção de leave para cada um deles, ou seja, efectua uma saída explícita de grupo. • Criação de grupos - create()
Esta é a primitiva de criação de grupo, cuja operação é desencadeada por uma entidade registada no sistema. O conjunto de acções desencadeadas por esta primitiva inicia-se, tal como no processo de registo de uma nova entidade, com a comunicação com o servidor de grupo universal (GU), para a obtenção de um identificador único para o novo grupo. Do lado do servidor GU, ao receber o pedido de criação de grupo, informa o servidor de grupos de que deve proceder ao "lançamento" do representante de grupo.
O conjunto de acções desencadeadas pelo representante, já anteriormente descri- tas, consiste da criação do objecto de comunicação do grupo universal e do novo grupo e sua associação a ambos. Procede de seguida à configuração do grupo, de acordo com os dados que foram passados como argumentos na invocação da pri- mitiva tais como: o tipo de acesso e o número máximo de elementos admitidos. A sequência de interacções e os elementos envolvidos na criação de um grupo podem ser observados na figura 5.10.
• Destruição de grupo - destroy()
O processo de destruição de um grupo é desencadeado por uma entidade per- tencente a este, que comunica directamente com o representante do grupo. O re-
15Esta remoção pode ser somente uma sinalização, ao nível do sistema de informação, de que a enti-
ARQUITECTURA DE SUPORTE AO MODELO
Figura 5.10: Sequência de acções desencadeadas pela invocação da primitiva create()
presentante, ao receber o pedido da entidade, executa o processo de destruição, de acordo com a política indicada. Foram definidos três tipos distintos, que estão relacionados com a forma como o representante do grupo procede à notificação de destruição aos membros do grupo:
– NO_NOTIFICATION:
∗ inibe a difusão de eventos associados ao grupo;
∗ comunica directamente com o servidor GU, para que este proceda à re- moção do grupo das estruturas de suporte de grupo;
∗ destrói o processo do representante do grupo.
– NOTIFICATION:
∗ publica o evento de destruição do grupo, não sendo exigido nenhum comportamento específico por parte dos membros (por exemplo, invo- car primitiva leave());
∗ inibe a difusão de eventos associados ao grupo;
∗ comunica directamente com o servidor GU, para que este proceda à re- moção do grupo, nas estruturas de suporte de grupo;
∗ destrói o processo do representante do grupo; ∗ termina a execução.
– NOTIFICATION_ACK:
∗ publica o evento de destruição do grupo com informação referente a este facto. Os membros do grupo, ao receberem esta notificação, devem proceder à saída explícita do grupo, através da invocação da primitiva leave();
ARQUITECTURA DE SUPORTE AO MODELO
∗ inibe a notificação de novos eventos associados ao grupo;
∗ aguarda, até que a primitiva de membership() retorne uma lista vazia (ou o tempo de espera seja excedido);
∗ comunica directamente com o servidor GU, para que este proceda à re- moção do grupo, nas estruturas internas de suporte de grupo;
∗ destrói o processo do representante do grupo.
As entidades possuem métodos de atendimento para este tipo de evento, que lhes permite executar o comportamento pretendido, pela aplicação.
• Filiação num grupo - join()
A filiação de uma entidade num grupo é executada pela primitiva join(), invo- cada pela entidade, que desencadeia a seguinte sequência de acções (figura 5.11):
– com base no identificador do grupo, consulta o servidor GU, para obtenção
do endereço universal do grupo, ou seja, do endereço do seu representante no GU;
– comunica directamente com o representante de grupo, através do endereço
universal, enviando uma mensagem de pedido de filiação;
– aguarda resposta por parte do representante, sendo da responsabilidade
deste desencadear o processo de admissão do candidato, de acordo com a política de filiação configurada para o grupo (tipo de acesso). As políticas de filiação permitidas foram já anteriormente descritas na subsecção 5.5.3;
– se a resposta é negativa:
∗ a filiação falha;
– se a resposta é positiva:
∗ cria objecto de comunicação para o novo grupo;
∗ torna efectiva a junção ao grupo, por chamada do correspondente mé- todo da plataforma intermédia, JGroupSpace;
∗ obtém endereço lógico através do servidor de endereços; ∗ activa a recepção de eventos do grupo ("handler");
∗ comunica o seu endereço no novo grupo ao representante, para que este proceda à actualização da sua constituição;
∗ preenche estruturas de dados de suporte ao nível da entidade.
• Saída de grupo - leave()
Esta primitiva trata da remoção de uma entidade, de um grupo do qual é mem- bro, através da seguinte sequência de acções (figura 5.12):
ARQUITECTURA DE SUPORTE AO MODELO
Figura 5.11: Sequência de acções desencadeada pela invocação da primitiva join()
– com base no identificador do grupo, consulta o servidor GU, para obtenção
do endereço universal do grupo;
– comunica directamente com o representante de grupo através do endereço
universal, enviando uma mensagem de pedido de remoção;
– aguarda resposta do representante; – se a resposta é negativa:
∗ a remoção falha, por exemplo, por o membro não pertencer ao grupo;
– se a resposta é positiva, o representante remove o membro da sua estrutura
de membros:
∗ efectua a chamada da primitiva (leave()) disponibilizada pelo JGroupS- pace, que efectiva a remoção do elemento do espaço do grupo;
∗ actualiza as estruturas de suporte da entidade, removendo a informação referente ao grupo.
• Obtenção dos membros de um grupo - membership()
A chamada desta primitiva retorna a lista de participantes do grupo e o seu es- tado (modo), no momento da chamada:
– a entidade comunica directamente com o representante de grupo, através do
seu endereço absoluto, enviando uma mensagem de consulta de membros;
– aguarda uma mensagem, no espaço do grupo universal, por parte do repre-
sentante;
– a lista enviada pelo representante retorna uma lista de elementos do tipo:
ARQUITECTURA DE SUPORTE AO MODELO
Figura 5.12: Sequência de acções desencadeada pela invocação da primitiva leave()
Do lado do representante de grupo, esta acção desencadeia o processo de con- sulta e comunicação directa com a entidade, através do seu endereço universal. • Alteração de estado de entidade num grupo - set_mode()
Esta função permite alterar o estado de actividade da uma entidade no grupo. Foram definidos dois estados possíveis para as entidades nos grupos a que per- tencem e que representam a sua acessibilidade no interior do grupo: ligado (ON- LINE); e desligado (OFFLINE).
Ao filiar-se num novo grupo, a entidade é colocada no modo ONLINE, podendo posteriormente este estado ser alterado.
A primitiva desencadeia a publicação de um evento de modificação de estado so- bre o espaço do grupo, sendo este evento tratado pelo representante do grupo, o que tem como única função modificar o estado associado à entidade na estrutura de membros do grupo. Na mensagem do evento, é enviado o identificador da entidade e o seu estado (modo).