« ARTICLE 18 – DIRECTION GENERALE
III. Les demandes de la CRE
A seguir são apresentados dois cenários de interação baseada em serviços entre componentes fisicamente distribuídos. No primeiro cenário, demonstra-se a visão interna, enfatizando o re- lacionamento entre as entidades do arcabouço. No segundo cenário, exemplifica-se o nível de distribuição possível com a arquitetura, apresentando uma visão externa e física da interação entre componentes. O mesmo raciocínio da interação baseada em serviços pode ser aplicado à interação baseada em eventos.
Visão interna
Para exemplificar a interação entre os componentes de forma distribuída, foram definidos três cenários principais: composição de componente distribuído; requisição de serviço implementado por componente distribuído; e requisição de serviço requerido por componente distribuído.
Como apresentado anteriormente, a composição de componentes locais é realizada em dois passos: criação de referência do componente via instanciação e inserção da referência em um contêiner através de um método da classe Container. Por exemplo, utilizando o arcabouço JCF:
parent.addComponent(new MyComponent()), sendo parent o contêiner pai do componente.
Já na versão distribuída, a obtenção da referência e a adição no contêiner pai ocorre via re- gistro. Por exemplo, no JCF: ComponentRegistry.find("C", "193.165.5.12", parent), onde parent é a referência para o contêiner no qual o componente será inserido e para o qual será criado um representante na máquina onde se encontra o componente “C”, cujo endereço é “193.165.5.12”. O resultado deste processo é ilustrado na Figura 6.4.
parent
C
Rep. de parent 193.165.5.8 Rep. de C 193.165.5.12 referencia 193.165.5.8 referencia 193.165.5.12Máquina local Máquina remota
Figura 6.4: Composição de componentes distribuídos.
Uma vez estabelecida a arquitetura e definidas as referências remotas de contêineres e compo- nentes funcionais, pode-se ilustrar os cenários de interação. Na Figura 6.5, ilustra-se um cenário em que um componente distribuído (C) implementa um serviço requisitado por outro componente. De acordo com a CMS, a requisição do serviço por outro componente chegará ao componente
C apenas através do seu contêiner pai, neste caso, parent. A seqüência de passos da requisição do
serviço é ilustrada a seguir.
parent
C
Rep. de parent 193.165.5.8 Rep. de C 193.165.5.12Máquina local Máquina remota
4 3 1 6 5 2 testar “testar”
Figura 6.5: Cenário de interação: componente distribuído como provedor do serviço.
1. O contêiner parent recebe a requisição de execução do serviço “testar” que, de acordo com sua tabela de serviços, é provido por seu filho C.
2. A requisição é então encaminhada a Rep. de C, que funciona como representante de C, o que fica transparente ao contêiner parent.
3. Rep. de C requisita a execução do serviço ao componente distribuído C, que está localizado na máquina remota.
4. O componente C executa o serviço e retorna o resultado para o seu representante na máquina local - Rep. de C.
5. Rep. de C encaminha o resultado para o contêiner parent.
6. O contêiner parent então encaminha o resultado para o requisitante do serviço. Para parent, tratou-se de uma requisição local.
Na Figura 6.6, ilustra-se um cenário em que um componente distribuído (C) requisita um serviço implementado por outro componente. De acordo com a CMS, a requisição do serviço deve ser feita apenas ao contêiner pai de C, no caso, parent. A seqüência de passos da requisição do serviço é ilustrada a seguir.
parent
C
Rep. de parent 193.165.5.8 Rep. de C 193.165.5.12Máquina local Máquina remota
4 3 6 5 2 “salvar” 1
Figura 6.6: Cenário de interação: componente distribuído como requisitante do serviço.
1. O componente C requisita o serviço “salvar” ao seu contêiner pai, que na sua visão é parent. A requisição chega a Rep. de parent, que funciona como um representante de parent. Isto fica transparente ao componente C.
2. Rep. de parent requisita a execução do serviço ao contêiner real parent, que está localizado na máquina local (remota em relação a C).
3. O contêiner parent recebe a requisição e a encaminha ao seu pai - já que não possui outros componentes filhos que poderiam prover o serviço “salvar”. O provedor do serviço então será encontrado utilizando o mecanismo de interação definido na CMS .
5. O contêiner parent então encaminha o resultado para o seu representante na máquina re- mota (local em relação a C).
6. Por fim, Rep. de parent encaminha o resultado para o componente C. Para C, tratou-se de uma requisição local.
Visão externa
Na Figura 6.7, ilustra-se um cenário de requisição do serviço “teste”, feita por ComponenteA de acordo com a arquitetura de distribuição, ou seja, com a utilização de representantes. Na Figura 6.7(a), ilustra-se a estrutura em árvore e na Figura 6.7(b) a estrutura física. A seqüência de passos durante a requisição do serviço é apresentada a seguir.
“teste” 192.168.10.11 192.168.10.11 Contêiner 1 191.123.4.5 Contêiner 2 192.168.10.11 Contêiner 3 192.134.1.15 ComponenteA 150.142.3.4 ComponenteB 163.222.4.65 AdaptadorDeC 123.132.5.87 ComponenteC
Estrutura física em hierarquia Estrutura física real
163.222.4.65 192.134.1.15 191.123.4.5 192.168.10.11 1 3 4 5 6 7 2 3 4 5 8 1 2 6 7 8 teste (a) (b)
Figura 6.7: Invocação de serviço com representantes de componentes distribuídos.
1. ComponenteA requisita o serviço “teste” ao representante de seu contêiner pai (Contêi-
ner2). O representante repassa a requisição para Contêiner2 na máquina de endereço
191.123.4.5.
2. Contêiner2 recebe a requisição e verifica em sua tabela de serviços que nenhum dos seus filhos implementa o serviço “teste”.
3. Contêiner2 então repassa a requisição para o representante de seu contêiner pai (Contêi-
ner1). O representante encaminha a requisição para o Contêiner1 na máquina de endereço
4. Contêiner1 recebe a requisição e verifica em sua tabela de serviços que Contêiner3 imple- menta o serviço “teste”.
5. Contêiner1 então repassa a requisição para o representante do Contêiner3. O representante encaminha a requisição para o Contêiner3 na mesma máquina.
6. Contêiner3 recebe a requisição e verifica em sua tabela de serviços que AdaptadorDeC implementa o serviço “teste”, então repassa a requisição para o representante do adaptador. O representante encaminha a requisição para o AdaptadorDeC na máquina de endereço
163.222.4.5.
7. AdaptadorDeC recebe a requisição e repassa ao representante do componente cujos serviços foram adaptados (ComponenteC).
8. O representante encaminha a requisição para ComponenteC na máquina referente ao ende- reço 163.222.4.5. ComponenteC então executa o serviço.