Ainda agora estamos a começar e 90% do criado foram duvidas! Temos de marcar uma reunião, mais, temos de marcar reuniões semanais.

Cada serviço terá a sua especificidade, mas como a plataforma a implementar destina-se a integrar serviços de notificação, esta deve definir algumas regras/principios que definem o que um serviço de notificação deve disponibilizar, nomeadamente:

-- Descrição;
-- Localização;
-- Indicação de estado;
-- Meios permitidos para notificação.

Podemos definir uma interface "NotificationService" onde estas regras estão definidas, todos os serviços que se queiram associar à plataforma têm de ser um NotificationService.

Sempre que um serviço necessite de comunicar com a plataforma( ou um gestor de serviços), é necessário iniciar uma ligação segura entre os dois!

Criar uma ligação segura entre o serviço e a plataforma obriga ao processo de autenticação???

Pode-se admitir que a aceitação do registo do serviço permite apenas que este se autentique na plataforma, o que inicia uma ligação segura sempre que deseje efetuar notificações, ou qualquer outra acção que o obrigue a comunicar com a plataforma.

Qual delas faz mais sentido? Será estes os melhores compromissos entre a segurança e o chamado loose coupling.

Questões:

O serviço notifica directamente o cliente
Problemas:
- Cada serviço fica com complexidade acrescida, uma vez que, para além do serviço em si, tem que ter noção dos clientes
que nele estão registados e tem que se preocupar a notificar cada um dos clientes.
- Ficam informações replicadas dos clientes, uma vez q a plataforma tem conhecimento dos clientes e os serviços tambem
passam a ter essa informação (ou pelo menos parte dela - os clientes registados)


O serviço notifica a plataforma e a plataforma notifica o cliente?
Problemas:
- Pode haver perigo de congestionamento (se todos os serviços quiserem notificar todos os clientes no mesmo instante)

Os use-cases realizados são:
+ Use-Case Cliente
+ Use-Case Serviço

Tomei a liberdade de "pintar" a casa de fresco, acho que tá mais apelativo assim.

Guardei a "tinta" velha caso não gostem dele com está...

PS: Passem a por titulos nos posts.

@ Que estrategia usar para COMUNICACAO SEGURA ?
- Tipo Kerberos: 3 entidades -> cliente, KDC, Servidor
- Com certificados: 2 entidades -> cliente, servidor (para comunicacao sobre SSL)

@ Qual a forma mais correcta de comunicar com os servicos?
- O cliente fala com o servidor de servicos para obter um servico e comunica atraves do servidor .Vantagens
So' um nivel de autenticacao
So' um certificado
.Desvantagens
Comunicacao indirecta
- O cliente fala com o servidor de servicos para obter o servico, e apos isso fala directamente com o servico .Vantagens
Comunicacao directa
.Desvantagens
Um certificado por cada servico => 1000 servicos = 1000 certicados
"2" niveis de autenticacao

Chegamos à conclusão que o ideal para conseguir autenticação e comunicação segura, é utilizando HTTPS, ou seja, sobre SSL. Agora temos que investigar mais um bocado o modo de funcionamento deste protocolo.

Encontram-se realizados os primeiros diagramas UML - Use Case.
Estes são relativos à plataforma de integração e neles reflectem-se claramente os pressupostos enunciados, nos quais a plataforma deve conter mecanismos de autenticação implícitos assim como permitir o primeiro contacto com os serviços disponibilizados.