Abandono do Formato XML + XSD das mensagens de Eventos

Ao implementar o indicado nos posts anteriores verifiquei o seguinte:

Vantagens

Elevado grau de dinamismo no formato da mensagem
Campos opcionais não ocupavam tráfego de rede
Formato da mensagem configurável mudando o XSD de verificação, e o XML da notificação template a gerar
Substitui a implementação de estruturas de dados "hard coded".

Desvantagens

Overhead para validação da mensagem, se usarmos uma estrutura para comunicação de dados a validação é nos dada de graça
Obtenção de dados pouco trivial

Objectivos não atingidos
Um dos principais objectivos passava por tornar estas mensagens o mais independentes de código implementado possivel, fazendo um mapeamento directo entre a mensagem XML de evento e a mensagem XML de notificação template. Verificou-se que a personalização da mensagem template de notificação apenas poderia ser "hard coded", ou seja para indicar um simples parabens 'xpto' tiveste positivfa é necessário procurar na mensagem de evento por um campo de nome especifico (nota), o qual tem obrigatóriamente de existir, este e outros compromissos inviabilizaram a genericidade da transformação pretendida (men. evento -> men. notificação).

Formato das mensagens do GE de notas

Formato das mensagens
Os Geradores de Notas devem enviar mensagens para o metodo processarEventoNotaAtribuida do GN (Gerador de Notificações) do SNE, com o formato indicado abaixo:


XML enventoNotas

Campos opcionais

• maisInformacaoURL


• data

Campos obrigatórios

• eventoSNE


• geradorURI


• topico (e todos os sub-campos)


• aluno (e todos os sub-campos)(1...*)

Validação das Mensagens
As mensagens geradas pelo GE de notas são validadas pelo pelo metodo indicando abaixo através da seguinte XSD.


XSD enventoNotas

Com este tipo de mensagens pretende-se criar um dinamismo na contrução das mensagens, evitando que campos não necessários para a gerçãode notificação sejam transmitidos.


Nota: Porque usar XSD em deterimento de DTD? A principal razão deve-se as DTD's não suportarem indicar o tipo dos elementos (int, bool, etc...) algo que precisamos na validação

Nova B.D. do SNE

Já que a comunicação SNE -> PISNA será feita à custa de documentos XML, é necessário guardar as notificações geradas pelo SNE num repositório temporário até que estas sejam encaminhadas para a PISNA.

Dado que os documentos XML têm campos opcionais, é difícil mapear estes directamente em tuplos na BD, e usar outro tipo de repositório (disco, etc...) é de evitar visto que já temos um repositório.

Como solução optámos por alterar a tabela notificação da BD do SNE colocando um novo campo notifcacaoPISNA, para o qual é seriada a notificação a enviar para a PISNA. Existem alguns campos da notificacao que se repetem no documento seriado (notifcacaoPISNA) estes foram retirados, e agora apenas constam no documento.

Comunicação entre Geradores de Eventos e SNE (mais XML?)

Antes de perceber como enviar notificações para a PISNA (assunto do post anterior), é necessário pensar em como receber eventos dos Geradores de Eventos (GE's) e dai extrair->armazenar->distribuir através da PISNA.
Uma das coisas que já considerei como facto concreto é ter de existir um Gerador de Notificações(GN) específico para cada tipo de GE (de notas, estado na tesouraria, informação genérica, etc).
Outro facto é a necessidade de ter armazenados templates de cada tipo de notificação guardados em XML popular estes com valores dos eventos criando assim a notificação a enviar para a PISNA.
Estes dois factos facilitam a resolução da comunicação GE's -> SNE.
Seguindo o raciocínio do blog anterior no que respeita à interacção SNE -> PISNA, podemos fazer o mesmo para GE's -> SNE. Uma das razões principais que me leva a pensar na mesma solução é o facto dos pares (campo/valor) que os GE's podem passar para o GN poder variar em número, pois podem existir campos opcionais tais como maisInfoURL. Em baixo encontram-se alguns factos e dúvidas que estou a ter nesta implementação.

Factos

• Existe uma diversidade de geradores de eventos


• Um WebService para receber esses eventos


• Um método por tipo de GE diferente


• Um GN + notificação template por tipo de GE diferente


• Possivel autorização ao nivel do método para apenas permitir aos GE's os métodos de GN lhes pertencem


• Campos gerados pelos eventos podem ser opcionais


• Necessidade de divulgar os XML referidos em (1) através dos webServices(ou outra forma) para que geradores os possam saber como usar (ou colocar o formato na documentação do SNE)

Dúvidas

• Como divulgar o tipo de campos que se esperam existir no XML de cada tipo de evento
• 
  
• Como divulgar os formatos xml no webservice (faz sentido fazer isso?)


• A ideia é boa....como se faz?

Notas

• Se verificar que os campos para cada tipo de GE são sempre obrigatórios mais vale ter estruturas (que já posso anunciar no WSDL) para comunicar entre os GE's e o SNE

Gerar Notificações (o dilema...)

Estou actualmente a implementar o GeradorDeNotificacoes(dos SN) e deparei-me com um grande dilema.

Funcionamento do GeradorDeNotificacoes
O gerador de notificações têm como objectivo receber eventos das mais variadas fontes (atribuição de notas, notícias sobre um determinado curso, etc...), e gerar uma notificação, caso exista alguém subscrito para receber esse tipo de informação.
Para já o gerador de notificações apenas têm um método public bool criarNotificacao(string[] campos,int topico), o qual recebe um conjunto de informação na forma nome=valor, e o nº do tópico ao qual a informação está associada.

Formulação do Dilema
Sabendo que as notifiçaões a enviar para a PISNA devem ser "user friendly", e que os geradores de eventos apenas devem enviar campos/valores que podem ou não gerar notificações, como é que se transforma uma coisa noutra?

Quem e como gerar notificações?
Atendendo à deversidade de geradores de eventos que pode existir, como é possível transformar CCD=14 em
"Parabéns , tiveste 14 valores a CCD"
ou
LEIC="Re-estruturação do curso aprovada hoje, entra em vigor dia 1 de Setembro de 2004" & MaisInfo="http://www.deetc.isel.ipl.pt/leic/"
em
"Novidades sobre o LEIC! Re-estruturação do curso aprovada hoje, entra em vigor dia 1 de Setembro de 2004. Vai a http://www.deetc.isel.ipl.pt/leic/ para saberes mais!"

...pois...??????

Pois é! O Gerador de notificações é suposto conseguir fazer isto, mas e algoritmo que o faça?
Não me parece nada trivial, é só exceppções à regra, o principal problema prende-se com o facto de apenas existir um gerador de notificações para vários tipos de geradores de notificações.

Possiveis Soluções

• Um gerador para cada tipo de notificação (geradorDeNotificacoesDeNoticias, um geradorDeNotificacoesDeNotas, etc)


• Um algoritmo de geração de notificações que consuante o tópico gera notificações diferentes.

Por enquanto só tenho estas como possíveis soluções (caso alguém conheça outras formas de resolver isto, p.f. coloquem nos comentários)
A segunda parece-me a mais eficiente, sobretudo aliada ao facto de podermos utilizar templates de geração notificação para cada tipo de tópico.
Vou investigar mais um pouco esta possivel solução...

Que tal alguém fazer uns comentários?! Hein...? ;).

Ponto da Situação

Feito:

• Base de Dados


• Serviços de Acesso a Dados (SAD)

Em Progresso:

• Serviços de Negócios

GestorDeSubscricoes (faltam metodos de obtenção de dados da PISNA)(90% feito)
GestorDeEventos (10% feito)

Por Fazer:

• Gerador de eventos de Notas de exames
• Teste de Interoperabilidade com PISNA
• Documentar requesitos de interoperabilidade com a PISNA (a fazer em conjunto com os ouros elementps do grupo)
• Serviço Notificações Bancárias (SNB)
• Relatório Sobre os Serviços
• Guardar em log as excepções apanhadas pelo WEbSite (apenas mostrar mensagens "User Friendly") (opcional)
• Certificados X.509 entre SNE/SNB e PISNA (opcional)

Camada de Negócios - Serviços de Acesso a Dados

Base de Dados

SNE - Num modelo de 3 Camadas

Tal como a PISNA, o SNE está implementado num modelo de três camadas.


SNE - Modelo de 3 camadas

Documentação para SN’s

Um dos principais objectivos do SNE é criar documentação que indique de uma forma estruturada as acções necessárias para que um SN possa se integrar na PISNA, assim como definir alguns conselhos de implementação.

A Documentação necessária apenas terá a sua versão final com a conclusão do projecto, no entanto, abaixo está um draft dos conselhos e passos de implementação que podemos concluir através do desenvolvimento do SNE:

Passos:

Obrigatórios:
Obter do website da PISNA:
SDK para SN’s (serviços de notificação)
• Documentação
• API para usar pelos Serviços
Criar proxies para os seguintes WebServices da Pisna(1):
• SM(Services Manager) – Registar-se/Gerir registo(2).
• NM(Notifications Manager) – Enviar notificações(3) para que sejam distribuidas pela PISNA.
• SSM( ServiceRequestors & Subscriptions Manager)
– Gerir (indicar/actualizar/remover/obter) subscrições efectuadas pelos clientes(4) no SN.
– Obter os dispositivos associados a cada ServiceRequester para que este possa escolher um por pretende receber as notificações.


Aconselhados:
Manter persistência de:
• Clientes
• Subscrições
• Notificações
Escolher quais os tópicos que o serviço terá (se algum)


(1)
Os links para os WebServices são temporários, puderam não estar disponiveis

(2)
Também possível no website da PISNA

(3)
O formato das notificações é standard, para que os vários SN’s e a PISNA se possam entender(5). O formato da notificação e a obrigatoriedade de alguns campos já foi definido e será divulgado noutro post. (4)

(4)
Designados na PISNA como SR's - Service Requestors

(5)
Determinado tipo de informação, como p.e. ‘cliente destino’, é vital para que a PISNA possa identificar e distribuir a notificação, como tal a própria notificação deve ter esse tipo de informação, a informação deste género considera-se obrigatória e imprescindível. Existem outros campos, que definem na prática o corpo da mensagem a enviar ao cliente e permitem construir a mensagem de acordo com o dispositivo destino. Estes campos na sua maioria não são obrigatórios.

O SNE por alto…

Metas a atingir:

• 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.


O que Faz:

Serve como ponto de ligação entre as aplicações cliente, que geram eventos(potenciais notificações), e o Serviço de Distribuição de mensagens da PISNA.
Mantêm persistência das subscrições, notificações, tópicos e alunos através de um repositório de dados próprio, implementado em SQL server 2000.
Apresenta, através de uma série de interfaces gráficas(todas em aspx), um misto de informação obtida através dos WebServices da PISNA e o seu repositório dados. Através destas interfaces é possível gerir subscrições e visualizar de forma detalhada notificações já enviadas.

O que Não Faz:

Não têm um mecanismo de geração de Eventos automatizado.
Parte-se do princípio que já existem serviços da escola, de divulgação de notas, eventos etc, os quais devem para gerar estes eventos.

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

SNE em Desenvolvimento...

Bem Vindos a mais um bolg relacionado com o Projecto PISNA.
Este blog têm como objectivo mostrar o progresso e ideias fundamentais que vão aparecendo ao longo do desenvolvimento do SNE.

Mais noticias em breve...