Cliente

Conforme ilustra a Figura 14, o Cliente pode realizar Requisições Síncronas, Requisições Assíncronas e cancelar Requisições assíncronas. Estes casos de uso são descritos nas subseções seguintes.

a) Cliente registra-se no QoMonitor

Esse caso de uso descreve o registro de clientes no QoMonitor. O registro do Cliente é necessário para que o cliente possa utilizar os serviços do QoMonitor. O registro guarda informações do Cliente como nome, endereço IP, porta, lista de parâmetros de entrada e a lista de parâmetros de qualidade do serviço que o cliente deseja que sejam monitorados.

Atores Envolvidos: Cliente.

Pré-condição: Cliente e QoMonitor e estão online e cliente ainda não se registrou.

Pós-condição: Informações do cliente (IP, nome,...etc.) estão armazenadas no QoMonitor. Fluxo:

(i) Nas requisições síncronas, o Cliente registra-se no QoMonitor ao chamar o método getServiceQuality. O registro é realizado conforme descrito na seção 3.3.2.1., subitem (a), (Registro de Cliente no QoMonitor).

(ii) Nas requisições assíncronas o Cliente se registra no QoMonitor ao chamar o método subscribeServiceQuality. O registro é realizado conforme descrito na seção 3.3.2.1., subitem (b), (Registro de Cliente no QoMonitor).

b) Cliente realiza requisição síncrona

Esse caso de uso descreve a ação do Cliente (uma aplicação ou Middeware) para realizar uma requisição síncrona ao QoMonitor, buscando recuperar os dados dos parâmetros de QoS/QoC requisitados pelo cliente.

Atores envolvidos: Cliente, serviço

Pré-condição: Cliente, QoMonitor e serviço estão online

Pós-condição: Cliente recebe os dados dos parâmetros (metadados) que ele requisitou.

Fluxo:

(i) O Cliente chama o método getServiceQuality solicitando que a Fachada Cliente obtenha e retorne os parâmetros de qualidade (metadados) especificados, que deverão ser enviados sincronamente.

(ii) A Fachada Cliente não possui a referência ao objeto serviço, necessário para obter os metadados relativos ao serviço armazenados no Repositório de Metadados. Para tanto, a Fachada Cliente executa o caso de uso detalhado na seção 3.3.2.1.2. (Referenciar serviço registrado no Repositório de Serviços) para obter a referência ao objeto serviço nos dois casos: (a) O serviço já está registrado no Repositório de Serviços e o objeto

serviço armazenado neste repositório. (b) O serviço ainda não está registrado neste repositório, sendo registrado neste momento e o objeto serviço armazenado no mesmo. A seguir, a Fachada Cliente envia o objeto serviço para o Tratador de Requisições. (iii) O Tratador de Requisições envia a referência ao objeto serviço para o Tratador de

Requisições Síncronas, este para o Módulo de Ontologia e este, por sua vez, para o Repositório de Metadados.

(iv) No caso do serviço já está registrado no Repositório de Serviços, os metadados já estão sendo monitorados e aferidos e armazenados no Repositório de Metadados, estando, portanto disponíveis. A partir daí, tudo prossegue conforme descrito no ítem (vi).

(v) No caso do serviço não estar previamente registrado e, portanto, é realizado seu registro conforme descrito na seção 3.3.2.1., subitem (b) (Referenciar Serviço Registrado no Repositório de Serviços), este serviço não está sendo monitorado e os metadados ainda não estão sendo monitorados e aferidos, portanto, não estão disponíveis no Repositório de Metadados. Neste caso, são executados os casos de uso detalhados nas seções 3.3.2.2.1., subitem (a) (Blackboard Obtém Metadados dos Serviços Monitorados); 3.3.2.2.2., subitem (b) (Aferição dos Metadados pelos

Aferidores); 3.3.2.2.3., subitem (a) (Armazenamento dos Metadados Aferidos no Repositório de Metadados). A partir daí, tudo prossegue normalmente, como descrito

no subitem (vi) desta seção.

(vi) O Repositório de Metadados retorna para o Módulo de Ontologia os metadados relativos ao objeto serviço especificado, que os transfere no formato da ontologia para o Tratador de Requisições Síncronas, este para o Tratador de Requisições, que, por sua vez os transfere para a Fachada Cliente e, finalmente, esta entrega os metadados para o cliente solicitante.

c) Cliente realiza requisição assíncrona

Esse caso de uso descreve a ação do Cliente (uma aplicação ou Middeware) para realizar uma requisição assíncrona ao QoMonitor, buscando recuperar os dados dos parâmetros de QoS/QoC requisitados pelo Cliente, quando algum evento especificado pelo cliente acontece.

Atores Envolvidos: Cliente, serviço.

Pós-condição: Cliente recebe os dados dos parâmetros que ele requisitou.

Fluxo:

(i) O Cliente chama o método subscribeServiceQuality informando os dados do serviço a ser monitorado e os metadados que ele deseja recuperar assincronamente quando o evento (condição) especificado pelo cliente acontecer.

(ii) O Cliente e a Fachada Cliente já conhecem o ID de registro do Cliente no

QoMonitor, pois ao chamar o método subscribeServiceQuality, o cliente foi

registrado, conforme descrito na seção 3.3.1.1., (Cliente se registra no QoMonitor), subítem (ii). Porém, a Fachada Cliente não possui a referência ao objeto serviço, necessário para obter os metadados relativos ao serviço armazenados no

Repositório de Metadados. Para obtê-lo, Fachada Cliente executa o caso de uso

detalhado na seção 3.3.2.1., subitem (b) (Referenciar serviço registrado no

Repositório de Serviços) nos dois casos: (a) O serviço já está registrado no Repositório de Serviços e o objeto serviço armazenado neste repositório. (b) O

serviço ainda não está registrado neste repositório, sendo registrado neste momento e o objeto serviço armazenado no mesmo. A seguir, a Fachada Cliente envia a referência o objeto serviço para o Tratador de Requisições.

(iii) O Tratador de Requisições envia a referência ao objeto serviço para o Tratador de

Requisições Assíncronas, este para o Módulo de Ontologia e este, por sua vez,

para o Repositório de Metadados.

(iv) No caso do serviço já está registrado no Repositório de Serviços, os metadados já estão sendo monitorados e aferidos e armazenados no Repositório de Metadados, estando, portanto disponíveis. A partir daí, tudo prossegue conforme descrito no item (vi).

(v) No caso do serviço não está anteriormente registrado é realizado seu registro conforme descrito é executado o caso de uso descrito na seção 3.3.2.1., subitem (b) (Referenciar serviço registrado no Repositório de Serviços). Como ele não estava registrado, este serviço não está sendo monitorado e os metadados ainda não estão sendo monitorados e aferidos, portanto, não estão disponíveis no

Repositório de Metadados. Neste caso, são executados os casos de uso

detalhados nas seções 3.3.2.2.1., subítem (a) (Blackboard Obtém Metadados dos Serviços Monitorados); 3.3.2.2.2., subitem (b) (Aferição dos Metadados pelos Aferidores); 3.3.2.2.3., subitem (a) (Armazenamento dos Metadados

Aferidos no Repositório de Metadados). A partir daí, tudo prossegue normalmente, como descrito da seção (vi) desta seção.

(vi) O Repositório de Metadados retorna para o Módulo de Ontologia os metadados relativos ao objeto serviço especificado, que os transfere no formato da ontologia para o Tratador de Requisições Assíncronas. Este último,verifica continuamente se a condição de retorno (evento) ocorreu e caso tenha ocorrido, envia os metadados para o Módulo Publish/Subscribe publicá-los.

d) Cliente cancela requisição assíncrona

Esse caso de uso descreve como o Cliente cancela uma Requisição Assíncrona.

Atores Envolvidos: Cliente, serviço.

Pré-condição: Cliente realizou requisição assíncrona. Pós-condição: QoMonitor cancela requisição assíncrona. Fluxo:

Para cancelar uma Requisição Assíncrona, o Cliente chama o método

unsubscribeServiceQuality da API do QoMonitor, que requer como parâmetro o identificador

da subscrição (ID) recebido como resposta ao método subscribeServiceQuality. A Fachada

Cliente transfere o identificador para o Tratador de Requisições, e este, para o Tratador de Requisições Assíncronas, que remove a subscrição da lista de subscrições. Desta forma, a

requisição assíncrona está cancelada e o QoMonitor suspende o envio dos metadados de qualidade ao Cliente de forma assíncrona.