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)