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.
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.
0 Comments:
Enviar um comentário
<< Home