PISNA

Enviar Notificações

2004-08-06T10:35:00.000+01:00

Ontem depois de testar toda a DataLibrary e de realizar a Lógica de Pesquisas, começamos então a tratar do problema do envio de Notificações aos interessados. O Kinjas que está encarregue de realizar um serviço teste, disse-nos uma possível mensagem template no formato XML que poderia ser usada, depois de a analisarmos começamos a discutir a forma de a trabalhar. Discutimos a questão, e a melhor forma que arranjámos foi, em primeiro lugar realizar uma validação a essa mensagem, sendo que essa tarefa irá ser realizada posteriormente, para já vamos admitir que a mensagem é bem formada.
Hoje em principio vamos processar a mensagem e enviar aos interessados.

Lógica de pesquisas

2004-08-06T10:29:00.000+01:00

Esta questão da lógica de pesquisas foi ontem discutida e implementada, o que resolvemos fazer foi o seguinte:
Temos uma classe que representa uma expressão, podendo essa expressão ser, ou uma expressão simples, ou uma expressão complexa.
Dessa classe derivámos uma expressão binária e uma expressão constante, uma expressão binária tem um lado esquerdo e um lado direito, cada um desses lados é uma outra expressão, a expressão constante apenas retorna um valor. Da expressão binária derivámos as expressões que vão ser utilizadas na lógica de pesquisas, sendo elas OrExpression, AndExpression, EqualExpression, LessExpression, LessEqualExpression, .....
Assim nos webservices o que tivémos que fazer foi colocar a tag [XMLInclude(....)] com todos os tipos de expressões possíveis, pois quem ia chamar o método apenas conhecia o objecto Expression, com a tag XMLInclude, quem chama o método conhece todos os objectos que derivam de expression, pois foram postos dentro da Tag.
O UML correspondente irá ser colocado aqui no post um dia destes.

Diagrama UML

2004-08-05T12:10:00.000+01:00

Este é outro problema do qual hoje queria discutir com o Kinjas e com o Rui, daí colocar aqui para não me esquecer.

Tratamento de Exepções

2004-08-05T10:21:00.000+01:00

Depois de uma discussão saúdavel, decidiu-se implementar um mecanismo de excepções simples, mas coerente para a plataforma.
As excepções são apanhadas desde a camada DataLibrary, em que são guardadas, não só a informação detalhada da excepção que ocorreu mas também uma "friendly message". A camada acima faz throw dessa excepção e acrescenta informação da sua camada. Por fim na camada dos WebServices é guardado num ficheiro de log todo o encapsulamento das excepções, contudo a informação enviada ao utilizador final é uma "friendly message", ou seja, algo do género, erro ao tentar registar o Serviço XPTO, claro que no log está descrita toda a exepção para o administrador verificar se é uma excepção prevista, ou se é necessário corrigir algum problema.
Hoje vamos actualizar o Serviço de Negócios colocando a classe que dá suporte as subscrições dos utilizadores num dado serviço. De seguida logo se vê....... Em todo o caso NÃO VAMOS DESANIMAR COM O QUE FALTA, MAS SIM DIZER PARA NÓS PRÓPRIOS QUE JÁ FALTOU MAIS.......
Temos de pensar positivamente. :)

Testar toda a DataLibrary

2004-07-30T10:25:00.000+01:00

É importante que se realize um teste exaustivo a todo o Projecto da DataLibrary, desde a criação de por exemplo um ServiceProvider, até a tentativa de criação de um objecto que não seja válido, por forma a verificar tanto a criação de objectos válidos bem como os inválidos. Pois quanto mais tarde detetarmos os erros pior é.

Lógica de pesquisas

2004-07-30T10:23:00.000+01:00

Por forma a implementar a lógica de pesquisas foi discutida uma possível solução, passando essa pela criação de uma classe que pudesse representar a expressão a avaliar, isto porque podem aparecer pesquisas de qualquer tipo a avaliar, dois exemplos são os seguintes:

1- select * from X where z= 2 and y='provider1' or f!=3
2- select * from X where z= 2 and y='provider1' and f = 3

Ou seja, nada garante que só por exemplo expressões de lógica iguais em toda a expressão sejam válidas, conforme os dois exemplos anteriores, o utilizador tanto pode fazer pesquisas do tipo 1 como do tipo 2.

Durante o ínicio da próxima semana acho que é importante esta classe ficar concluída com sucesso, pois existem muitas funcionalidades que poderão ficar mais facilmente realizadas com sucesso após a realização desta classe.

Dicas para Tratamento de Excepções

2004-07-11T10:43:00.000+01:00

About Unhandled Exceptions
The great thing about a good global exception handler is that it makes the rest of your code easier to read. Rather than cluttering up your code with Try..Catch blocks for every possible error condition, no matter how rare, you can simply rely on the solid, built-in global handler to deal with those oddball scenarios-- and to notify you when they happen!
So then the natural question that most developers ask is, "When should I catch exceptions"? And it's a very good question. Here are some guidelines that I have found useful.

Unless you have a very good reason to catch an exception, DON'T. Exceptions are supposed to be exceptional, just like the dictionary meaning: uncommon, unusual. When in doubt, let the calling routine, or the global exception handler, deal with it. This is the golden rule. The hardest kinds of exceptions to troubleshoot are the ones that don't even exist, because a developer upstream of you decided to consume it.

If you can correct the problem implied by the exception. For example, if you try to write to a file and it is read-only, try removing the read-only flag from the file. In this case you handled the exception and fixed the problem, so you should eat the exception. It doesn't exist, because you fixed it.

If you can provide additional information about the exception. For example, if you fail to connect via HTTP to a remote website, you can provide details about why the connection failed: was the DNS invalid? Did it time out? Was the connection closed? Did the site return 401 unauthorized, which implies that credentials are needed? In this case you want to catch the exception, and re-throw it as an inner exception with more information. This is a very good reason to catch an exception, but note that we are still re-throwing it!

Always try to catch specific exceptions. Avoid catching System.Exception whenever possible; try to catch just the specific errors that are specific to that block of code. Catch System.IO.FileNotFound instead.

There are, of course, times when you'll want to violate these rules for completely legitimate reasons-- but at least consider them before you do.

Nova versão da BD

2004-06-15T00:10:00.000+01:00

Com esta história das Roles dos utilizadores, foi necessário efectuar umas actualizações ao modelo de dados que tinhamos. Aqui fica a nova versão:

Permissões no acesso aos métodos "priveligiados"

2004-06-12T13:48:00.000+01:00

Este é mais um ponto de discussão da nossa plataforma. Existem métodos de determinadas classes que devem ser publicos (WebMethod's) mas só podem ser chamados por utilizadores autorizados. Por exemplo:
o método Notify(Message m), que tal como os outros métodos, tb está disponível para o mundo (WebMethod), não deve poder ser chamado por qq utilizador. Apenas por detentores de serviços de notificação. Caso contrário qq utilizador malicioso criava um proxy para para a plataforma e chamava o método Notify(...) fazendo-se passar, por exemplo, pelo serviço de notificação de incêndios...

Para isso vamos ter que inserir um novo conceito na plataforma, e começa por reflectir-se na BD, que é o conceito de Role

Existem vários tipos de Roles, como por exemplo, Administrator, Manager, Teller, ... , em que cada um terá permissões diferentes para executar determinados métodos.

Agenda para a próxima reunião (Sexta-feira dia 11 de Junho as 15:30)

2004-06-09T14:14:00.000+01:00

Pontos a focar na próxima reunião:

Tratamento de Excepções

Conclusões da reunião de ontem...

2004-06-09T14:08:00.000+01:00

Lógica de pesquisas PISNA

A lógica de pesquisas a implementar não invalida a necessidade de filtrar as expreções pré-pesquisa, para evitar situações de possivel abuso das funcionalidades disponibilisadas pelo SQL server (como comandos shell...).

schema para validar o formato das notificações dos SN

“schema” para actualização do diagrama de classes e script sql
schema + XML para mostrar info de cliente na altura da subscrição

Separação entre o que é info. Necessária para os SN e info. Necessário para a PISNA na altura da subcrição.

Blog do SNE...

2004-05-25T19:53:00.000+01:00

Já se encontra disponível mais um blog para o projecto. Lá estão todos os passos e discussões relativas a implementação do SNE(Serviço de Notificações Escolares), um Serviço de Notificações Escolares a integrar na PISNA.

Principais objectivos do SNE:
• Validar a implementação da PISNA
• Servir como exemplo de integração para futuros serviços
• Definir regras as seguir pelos SN(1)
• Criar Documentação e API a utilizar pelos SN’s.

(1)
SN – Serviço de Notificação

WebServices (Versão beta)

2004-05-25T19:11:00.000+01:00

Já estão disponiveis alguns dos WebServices que compõe a PISNA, eles são:

PISNAMessageProvider

PISNAServiceProvider

PISNAServiceRequester

PISNASubscriptions

Apresentação Intercalar do projecto

2004-05-25T17:20:00.000+01:00

Foi uma honra praticipar nas apresentações intercalares dos profectos finais dos cursos de LEIC e LESTE.
Um paço importante agora que o projecto está a entrar em velociadade cruzeiro.
Abaixo encontra-se a apresentação....

PISNA - Apresentação intercalar

Fachada da plataforma PISNA

2004-05-24T22:44:00.000+01:00

A plataforma PISNA tem já tem uma Fachada :)

É esta:

http://kimberlito.no-ip.com/pisnawebsite/index.aspx

Ainda está em fase de contrução, mas já dá para ver qq coisa!

eu quero o gmail!!!!!!!

2004-05-24T17:14:00.000+01:00

este post n temmto interesse! é só para ver se fico como gmail...

Divisão de Tarefas

2004-03-30T23:02:00.000+01:00

Já se encontra definida a divisão de tarefas do projecto PISNA, é a seguinte:
- Plataforma de Integração --> Rui Aires
- Serviço de autenticaçâo inerente a toda a plataforma --> Pedro Airó
- Serviços de Notificação(Student Grades + Bank Account Balance) --> Joaquim Lavos

TUDO SÃO WEB SERVICES....

2004-02-20T17:35:00.000Z

Uma coisa que é preciso não esquecer, e que pode causar alguma limitação, é que tudo tem que ser Web Services! Caso contrário não é possível a comunicação entre entidades!
Vejamos a seguinte imagem para esclarecer...

Plataforma PISNA

Noção de GRUPOS

2004-02-19T09:57:00.000Z

Em conversa com o Bruno, surgiu uma nova ideia - GRUPOS!

Em que consiste um grupo e para que serve?

A justificação para que seja introduzido o conceito de GRUPO é a seguinte:
Imaginemos um serviço de notificação de Fogos (SNF), Transito (SNT), etc. . Serviços destes só queremos ter um de cada uma vez que vários serviços de notificação de Fogos, Transito, etc. seriam IGUAIS!!! Sendo assim, como é que se distingue o SNF da floresta Amazónia com o SNF da serra de Sintra? É aqui que entra o conceito de GRUPO, ou seja, basta existir um SNF (ou rélpicas do mesmo serviço espalhadas por tudo o que seja florestas...) mas os Bombeios de Sintra e Algueirão p.ex. que se registam no SNF, escolhem o grupo "Serra de Sintra", que pertence ao SNF. O mesmo se passa para os outros serviços. Por exemplo os clientes que se registam no SNT, moradores na zona de sintra, inscrevem-se no grupo IC-19, IC-17, etc. ou seja, não existe um SNT para cada estrada!!!

Conclusões da Reunião de dia 16/02/2004

2004-02-18T14:53:00.000Z

Os serviços não precisam de conhecer os clientes, caso se adopte a seguinte estratégia:
Existe uma mensagem template na plataforma, definida por um exemplo Resumo, Descrição, Imagem, etc...
Consoante o tipo de dispositivo, a plataforma decide, baseando-se numa mensagem template, escolher que partes da mensagem enviar para os clientes.
Ficou assente estudar bem os Web Services , XML, Schemas....
Teremos também de mais para a frente estudar como podemos definir standards: autenticação, replicação e contextos transaccionais.

Como são feitas as notificações?

2004-02-16T14:38:00.000Z

Para que os serviços não tenham que personalizar as mensagens para cada cliente e para cada tipo de destino (mail, sms, etc...) (o que levaria a ter duplicação dos dados dos clientes na plataforma e nos serviços => serviços mto complexos) os serviços têm que disponibilizar uma mensagem que possa satisfazer a grande maioria dos dispositivos de recepção das notificações. P.Ex. Se a mensagem contiver um resumo, um corpo, e eventualmente outros objectos (imagens, audio, etc...), conseguiriamos fazer com que fosse a plataforma a tomar a desisão do envio da notificação para os clientes (que é o objectivo do PISNA!!!), facilitando assim bastante os serviços. Assim é a forma ideal, dado que os serviços só têm que representar aquilo que são, ou seja Serviços!

Após a personalização de todas as mensagens, estas são enviadas para a plataforma, para os clientes serem notificados.

A notificação não é feita pelos serviços porque:

Se um serviço mudasse de localização, teriamos que avisar todos os clientes. Assim, basta notificar a plataforma sobre uma qq alteração dum serviço, a plataforma actualiza os seus dados e continua a "conversar" com os clientes, ou seja, a mudança de localização de um serviço (ou outra qualquer alteração) é TRANSPARENTE para os clientes!

A persistência (e garantia de entrega) das mensagens era mais uma das tarefas que os serviços teriam que suportar caso as notificações aos clientes fossem feitas pelos serviços, o que levaria a serviços complexos quando não há necessidade, ou seja, todas as tarefas comuns a todos os serviços, são disponibilizadas pela plataforma :)

A PISNA já está registada no UDDI (Na parte de testes disponibilizada pela Microsoft)

2004-02-08T17:14:00.000Z

A PISNA já está registada no UDDI (Na parte de testes disponibilizada pela Microsoft)!

Para chegar lá é só seguir isto https://test.uddi.microsoft.com/Default.aspx e depois fazer login com o Passport.

O provider já está registado (e chama-se PISNA).
Existe um serviço de teste que tb já está registado! É só procurar por "Serviço de teste - Hello World" (ou qq uma destas palavras...)

UDDI

2004-02-01T12:06:00.000Z

Após grande paragem (testes/exames/trabalhos) voltemos à carga! Temos que estudar o UDDI, saber para que serve, como funciona, etc.
Para isso aqui vai um link com as caracteristicas do UDDI v.3. É um texto muito longo, mas tem q ser...

http://uddi.org/pubs/uddi_v3.htm

Apenas a plataforma efectua notificações aos Clientes

2003-11-25T14:31:00.000Z

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.

Uma cena Fixeca, parecida com o q queremos fazer...

2003-11-19T18:21:00.000Z

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

Possivel arquitectura para a nossa aplicacao

2003-11-10T15:12:00.000Z

Servico de Comunicacao de Voz

Os Serviços não são Sensores!

2003-11-04T21:46:00.000Z

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.

Acesso directo Cliente <=> Serviço (Sumário)

2003-11-04T21:45:00.000Z

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;

Horário de Trabalhos do PISNA

2003-11-04T21:29:00.000Z

Algumas conclusões da Reunião de Ontem

2003-11-04T21:11:00.001Z

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.

Reunião com o Eng. Jorge Martins

2003-11-03T18:47:00.000Z

Hoje tivémos a 1ª reunião com o Eng. Jorge Martins, sendo discutidas nesta reunião todas as dúvidas que tinhamos até à altura.
Ficou também assente nesta reunião que deveriamos pensar num assunto de cada vez, por exemplo: começámos a pensar logo em como seria feita toda a questão de segurança e autenticação, sendo que o mais importante nesta fase do projecto, pensar por exemplo se a comunicação entre serviço e clientes será feita directamente, ou se passa pela própria plataforma.
Visto que o nosso projecto se parece em parte com o paradigma inerente ao PASSPORT da MICROSOFT, ficou também assente irmos estudar esse mesmo assunto.
A próxima reunião ficou agendada para dia 18 de Novembro de 2003, até lá temos muito que estudar.

Duvidas...duvidas...

2003-10-30T19:01:00.000Z

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.

A plataforma define regras a seguir pelos Serviços!!!

2003-10-30T18:59:00.000Z

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.

Cada acção de notificação exige autenticação por Parte do Serviço?

2003-10-30T18:18:00.000Z

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.

Use-Cases

2003-10-30T17:17:00.000Z

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

Blog do PISNA com nova fachada

2003-10-28T19:40:00.000Z

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.

2003-10-28T12:45:00.000Z

@ 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

2003-10-23T19:53:00.000+01:00

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.

2003-10-22T13:55:00.000+01:00

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.

2003-10-22T13:21:00.000+01:00

Documento relativo à questão da criptografia, existente no MSDN:

2003-10-20T08:23:00.000+01:00

Hoje demos ínicio ao trabalho final de curso - PISNA.
Foi realizada uma pesquisa na internet por documentos relacionados com Autenticação e Segurança.
Foram tabém discutidos por alto um ou dois use-cases.