Reuni�o com os professores coordenadores

Discuss�o sobre efici�ncia da solu��o de notifica��o ass�ncrona do servidor para o cliente usando apenas o protocolo HTTP.

Explicar bem no relatorio esta op��o e indicar todas as vantagens e desvantagens, justificando muito bem a op��o que tomamos. Tendo em conta que se trata de um risco muito grande dever� ser justificado com os resultados dos testes de carga, mesmo que esses testes n�o sejam os mais satisfat�rios.

Ficou decidido em reuni�o continuar com esta solucao.

Foi feito pelo Bruno uma implementa��o teste de notifica��o assincrona de mensagens para o servi�o Messaging. Na reuni�o foi discutida esta implementa��o e a sua viabilidade. Esta implementa��o � baseada em 2 aplications webs em ASPX em que uma era a recep��o de mensagens, outra o envio de mensagens e um web service de messaging.

Testes a fazer:
- Juntar as duas aplica��o web numa s� e testar com o mozilla firebird.
- Realizar testes de carga.
- Programa a fazer log para os testes de carga

.:IDEIA 1:.

Criar um componente .net no lado do cliente para aceder ao web service em substituicao de ser a ASPX a aceder ao web service. Esta solu��o resolve o poblema dos limites do browser IE6. E uma applet java para os cliente n�o .net.
Desvantagem: O Cliente tem que suportar a framework .net ou ter a java VM
SO ESTAMOS A TENTAR RESOLVER O PROBLEMAS MAIS COMPLICADO DA WEB!!!!!!!!! (notifica��o assincrona do cliente atraves de HTTP)

.:IDEIA 2:.

Ter um web server no lado do cliente.
Desvantagens: o cliente tem que ter um ip publico.

Uma pagina que tem frames e um user control que faz rendering enviando uma applet ou envia script de cliente consoante o tipo de cliente.

No lado servidor apenas se tem web services para aquilo que se quer publicar para o exterior, nos outros casos vai se usar remoting.

Comunica��o assincrona (testes)

Testada a 2� ideia verificou-se que:
- � necess�rio a exist�ncia de um servidor Web com capacidade para manter liga��es abertas, pelo menos uma por cliente.
- � necess�rio a existencia do servi�o de suporte para encaminhamento de call-back�s para o cliente.
- Defini��o de um protocolo de comunica��o, para mensagens de call-back.

Comunica��o assincrona servidor/cliente e cliente/cliente

.: IDEIA 1 :.

Atribuir um porto no qual o receptor se encontra � escuta de mensagens.
- Vantagem: a possibilidade de comunica��o directa entre cada dois intervenientes.
- Desvantagem: necessidade de configura��o das firewall�s para permitir o acesso ao porto.

.: IDEIA 2 :.

Utilizar o porto 80 (firewall friendly) para a recep��o de mensagens assincronas (call-back).
Esta solu��o obriga � existencia de um servi�o de encaminhamento, que tem por objectivo distribuir as mensagens recebidas, pela componente cliente do servi�o correspondente.
- Vantagem: a possibilidade de funcionar em qualquer rede, mesmo que protegida por firewall sem a necessidade da sua configura��o.
- Desvantagem: A utiliza��o do servidor como distribuidor, o que aumenta a necessidade de recursos (liga��es permanentes) entre cliente e servidor.