A partir desta fase optámos por designar os clientes como Service Requesters e os serviços como Service Providers.

Parente as adversidades de efectuar as notificações directamente entre os Service Requesters(SR) e os Service Providers(SP), optámos por não efectuar este tipo de notificações, entre outras indicamos as seguintes razões:

-- Os SP deveriam ter a nossão do que eram os clientes de como localizá-los e como notificá-los, isto não só são mais funcionalidades que em muito contribuem para um menor desempenho dos serviços como são funcionalidades que pela sua generalidade não teriam de ser necessariamente implementadas no serviço;
-- Os SP teriam de comunicar periodicamente com a plataforma, de forma a obter informações actualizadas sobre os seus clientes, pois tornar-se-ia inconsistente manter a informação no serviço e na plataforma;
-- Os SR deveriam poder comunicar directamente com os serviços de forma a aceder a alguma funcionalidade mais especifica destes (a tal nossão do cliente gordo);
-- As comunicações dos clientes com a plataforma e com o serviço poderiam inviabilizadas caso estes se encontram por detrás de firewalls.



Vantagens de notificar apenas através da Plataforma.

-- O efeito acaba por ser o mesmo que efectuando a notificação através do serviço;
-- Maior facilidade em ultrapassar firewalls visto que apenas existem comunicações entre o cliente e a plataforma;
-- Maior coesão do modelo de dados;
-- Menor esforço de implementação dos serviços;
-- Transparência aos serviço dos pormenores de notificação.

Desvantagens

-- Funcionalidades acrescidas a  plataforma e centralização de acções, podendo originar congestionamentos de rede, facilmente resolvidos através de balanceamento de carga.



O que o SP deve Fazer:

-- Detectar casos que justificam efectuar uma notificação
-- Delegar a uma entidade a notificação


Conclusões

Tanto os clientes como os serviçoes perdem algumas funcionalidades, mas ganha-se em desempenho mantendo as funcionalidades essenciais.

Este .PDF, no capitulo 3, pag 29 (35 no acrobat) tem um exemplo porreiro...

http://www.shellysaunders.co.uk/Work/Architecture/Enterprise%20Notification%20Reference%20Architecture.pdf

Isto é uma duvida que já tive e da qual já falamos.
Imagine-se um parque natural (i.e. Gerês), onde se pretende detectar inícios de incêndios. O mais natural será existirem vários pontos no parque onde são efectuadas leituras, podemos chamar-lhe células, caso se pretenda criar um serviço para integrar na nossa plataforma ele deverá ser um único, que gere os eventos das várias células e efectua as notificações como entender , aos clientes(i.e. Corporações de bombeiros associadas), ou à plataforma.

Vantagens
-- Clientes têm acesso a funções, especificas ao tipo de serviço, que não estão acessíveis através da plataforma.

Desvantagens
-- Serviços têm também eles que gerir clientes, quem se pode registar, quem têm acesso e a quem notificar;
-- Serviços têm de definir regras a obedecer pelos clientes que pretendem ter acesso directo.
-- Clientes têm de saber comunicar directamente com os serviços;

Serviço de Autenticação
O serviço de autenticação a implementar não interfere com as outras funcionalidades da plataforma, nem dos serviços a implementar, este deve ser considerado como um extra, ou como um preâmbulo em todas as comunicações, que pode ou não existir. Assim não existe obrigatoriedade de existência de um serviço de autenticação, o que torna toda a plataforma mais flexível neste aspecto, e não diminui de qualquer forma o nível de segurança da plataforma.
Ficou ponto assente que o serviço de autenticação é bastante relevante neste projecto mas não deve constar das nossas preocupações nesta fase do projecto.

Definição da Plataforma
Da plataforma devem constar regras base de implementação dos serviços de notificação, muito provavelmente sob a forma de interfaces. O mesmo acontece no que toca aos clientes.
As notificações dos vários serviços devem poder ser feitas através da plataforma, o que deixa a cargo desta a noção de lógica de localização e comunicação com os serviços.

Notificações directas Serviço -> Cliente
Este tipo de notificações apesar de trabalhoso permite uma funcionalidade incontornável!
Para além das funções definidas pelas regras da plataforma, é muito natural que o serviço tenha outras funções, especificas ao seu tipo, as quais não estão acessíveis através da plataforma, neste caso exige-se uma comunicação directa entre o serviço e os clientes também eles específicos por forma a poderem interagir com o serviço.
Também os serviços têm de definir um conjunto de regras a seguir pelos clientes que os queiram aceder directamente.
Temos de identificar quais estas funções específicas e se são de tal forma relevantes para termos de permitir uma comunicação directa entre os serviços e os clientes.

Clientes
Relativamente ao tópico da conclusão anterior podemos ter a noção de clientes magros e de clientes gordos:
Cliente Magro:

-- Apenas sabe o que é a plataforma e como comunicar com ela;
-- A associação dos clientes aos serviços e o encaminhamento das notificações para os clientes são feitas através da plataforma.

Cliente Gordo:

-- Tem acesso à plataforma para pesquisar e localizar serviços;
-- Associa-se aos serviços através de comunicação directa com o próprio serviço;
-- Recebe notificações directamente através do serviço;
-- A estas funcionalidades acrescem as do cliente magro o que permite uma certa redundância de interacção (Ex1: O serviço não consegue enviar as notificações directamente para o cliente, envia essas notificações para ficarem armazenadas na plataforma e qual tenta notificar o cliente. Ex2: O cliente por alguma razão, p.e., firewall não consegue comunicar directamente com o serviço, utiliza as funcionalidades da plataforma para o fazer.)


Gestão de Clientes

1. Clientes registados na plataforma:

Ficou ponto assente que a plataforma deve não só armazenar os serviços que estão registados e sua descrição, mas também deve manter informação dos clientes registados e quais as suas permissões de acesso (ex.: acesso a que serviço(s)).

2. Clientes registados nos serviços para serem notificados:

Neste aspecto surge uma maior controvercia, dado que as notificações podem ser feitas tanto pela plataforma como pelos serviços directamente, aqui existe uma redundância no armazenamentos pois ambos devem ter acesso à lista de clientes a notificar, a plataforma com uma lista de clientes por serviço, e o serviço apenas com a lista de clientes que lhe correspondem.

Repositório de notificações

Deve existir um repositório onde são armazenadas todas as notificações ainda não entregues ao cliente.
Do meu ponto de vista faz mais sentido associar o repositório por cliente do que por serviço, pois existem duas formas que considero serem as mais correctas para entregar estas notificações, na primeira é a própria plataforma que se encarrega de localizar o cliente e lhe enviar as notificações, onde faz sentido armazenar as notificações por cliente, na segunda forma é o próprio cliente que se dirige à plataforma para obter as suas notificações, onde também faz sentido armazenar estas notificações por cliente.
Concluindo, a confirmar-se esta como a melhor opção deverá existir um repositório de notificações por cliente, onde a cada notificação está associado o serviço que efectuou essa notificação

Às regras já definidas para os serviços proponho acrescentarem-se as seguintes:

-- Modo de notificação(1);
-- Informação sobre as células de notificação existentes no Serviço(2).



Nota: É Preferível que para já nos preocupemos com as características mais gerais da plataforma, pondo de lado a autenticação e pormenores de implementação de clientes e serviços. Vamos seguir os diagramas UML religiosamente começando pela análise de requisitos que ainda não está feita.

(1)
Onde é descrito se o serviço efectua as suas notificações através da plataforma, ou por comunicação directa com os clientes a ele associados.

(2)
Num sentido mais laico as células correspondem aos sensores, caso existam que compõem os serviços, os quais podem estar localizados em pontos geográficos bem distintos.