Reunião com os coordenadores

Servico de Replicação e Sincronização

Servico replicação e sincronização é apenas um serviço e vai ser chamado como REPOSITORIO DE DADOS (RD)e vai ser responsavel pela transparencia da localização dos dados independentemente do estado do cliente (online/offline).
Este serviço está disponivel localmente para ser possivel o funcionamento offline.

Servico de Localiza��o

Utilizar o UDDI dos web services para registo e localiza��o dos servi�os.
Criar um wrapper para que o servico de localiza��o para usar remoting ou web services , pensado na hipotese de que podemos ter acessos por remoting.

Servi�o de Presen�a

No servico de Presen�a o cliente deve comunicar com o servidor de x em x tempo a indicar q ainda esta vivo (heart beat).
Hipoteses para notifica��o de mudan�a de estado do cliente

.:IDEIA 1:.

Um porto UDP conhecido em escuta para o qual o servidor envia notifica��es de mudan�a de estado de um contacto. PROBLEMA: Seguran�a com a necessidade de abrir um porto na firewall .

.:IDEIA 2:.

Receber o estado dos clientes em piggy back na resposta ao heart beat, recebendo o estado actual dos contactos.

Como passar mensagens de um cliente para outro sabendo da existindo dos proxys.

Cada cliente estabelece a liga��o com o servidor central, essa liga��o � usada pelo servi�o de presen�as e para comunica��o de mensagens.

Requisitos minimos

Tentar minimizar os requisitos da instala��o da aplica��o na maquina do cliente.
Para cada servi�o tem que se especificar os requisitos minimos na maquina do cliente. Talvez fosse boa ideia criar um blog so para TASKS .

Como investiga��o para se conseguir desenhar a arquitectura do nosso sistema vai ser desenvolvido um web service de Presen�as em que cada cliente anuncia a sua entrada e a sua mudan�a de estado. Este trabalho vai ser servir tambem para concretizar ideias sobre o R.D. e quais as funcionalidades que este vai desempenhar.
Este teste vai permitir saber o desempenho dos web services em situa��es "normais" e de que forma vao se adequar aos requisitos da nossa aplica��o.

Em cada servi�o h� dados, comportamento do servico e interface.

// posted by Sergio @ Terça-feira, Outubro 28, 2003

Chegamos a uma brilhante conclus�o!!!!!!!!! (Weeeee!!!)

Reuni�es com o Eng. Lu�s Falc�o v�o ser apenas � TARDE!!!!

Prepara��o para a reuni�o com os profs coordenadores:

Pontos a discutir:
-Servico replica��o/Sincroniza��o
-Persistencia dos dados (existencia de apenas um ficheiro como BD)
-Servico de estado dos clientes (pooling do cliente ou do servidor)
-Apresentar a arquitectura candidata
-Discutir os use cases feitos

Teste de inser��o de uma imagem num post

Como escolher cores???

Z�zito estes links s�o para ti ;)

Temos muito a aprender com os decoradores de casas, finalmente a primeira flashada que serve para alguma coisa de jeito.

Este apartir de uma cor gera cores que acompanham a primeira de uma forma harmoniosa.

Como criar um gradiente em html??, � s� dar duas cores que esta aplica��o gera as cores interm�dias.

E dura, e dura,...

Mais um



Cores Felizes :D

Artigo sobre controlo de transa��es sem base de dados,

fornecido pelo Walter Viera.

O Z� chegou � conclus�o q � preciso um servi�o novo !!! weeeeeeeee :)

Separar o servi�o de estado do cliente em tr�s servi�os operacionais, um de informa��o estado, outro de subscri�ao e ainda outro de gest�o de clientes.

Servi�o de informa��o de estado

Permitir ao utilizador informar o seu estado.
Deve permitir obter o estado de outros utilizadores.

.:ideia 1:.

O utilizador faz pooling para se manter actualizado com o estado dos outros utilizadores.

.:ideia 2:.

O servidor notifica sempre que existe altera��o no estado de um dos clientes.

Estado

online/offline, dentro do online poder� existir estados que contenham outras informa��es

Servi�o de subscri��o

Realizar o registo de novos clientes e gerar os seus perfis.

Servi�o de gest�o de perfis

Permitir alterar dados do utilizador, assim como subscrever/"dessubscrever" servi�os funcionais.

Fase de analise de requisitos e use cases

Discussão sobre a Replicação e Sincronizaçao:
Faz sentido existir um servico que acede aos dados sendo esse servico usado por todos os servicos?
Deverá existir um servico de acesso a dados para cada servico?
Existencia de 2 servicos: Replicação e Sincronização?

Replica��o:

.:IDEIA 1:.

Nao existencia do servico de replicação e é o servico o responsavel pela actualização do repositorio local e central. Tendo assim consciencia da existencia de replicação.

.:IDEIA 2:.

Replicação - Onde esta o servico existe um repositorio local conhecido e actualizado por este. O servico de replicação conhece a localização do repositorio central sendo responsavel pela sua actualização.

.:IDEIA 3:.

Replicação - Responsavel pela existencia de transparencia da localizacao do repositorio de dados, pelo que deve ser este o responsavel pela escrita nos locais necessarios

Sincronização

.:IDEIA 1:.

Questiona o repositorio de dados central sobre actualizaçães dentro de uma dada janela temporal.

.:IDEIA 2:.

O servico de sincronização faz cache das ultimas actualizaçães por utilizador/servico. Nao necessitando de questionar o repositorio de dados, no entanto tem que ser notificando por este quando existe alguma alteração.

Encadeamento Replicação/Sincronização

.:IDEIA 1:.

O servico de sincronização invocado pelo serviço, devolve as acções a serem tomadas para que o repositorio local e central de dados fiquem sincronizados. Deverá o serviço proceder a essa actualização

.:IDEIA 2:.

O servico de sincronização invocado pelo serviço, invoca o servico de replicação, caso seja necessário, para este sincronizar os repositorios de dados.

Nota: O forma de encadeamento está dependente dos compromissos assumidos nos pontos anteriores.

Hor�rio de trabalho do grupo

	Segunda	Ter�a	Quarta	Quinta	Sexta
9h30-11h	(Z,B,S)	(Z,S)
11h-12h30h	(Z,B,S)	(Z,S)
12h30h-14h	(Z,B,S)	(Z,B,S)		(B,S,Z,P,F)
14h-15h30		(Z,B,S)	(Z,B)	(B,S)
15h30-17h		(Z,B,S)	(Z,B)

Links uteis

CSS ZEN Garden
Weather Web Service

2� Reuni�o (Com os profs coordenadores) no dia 9 de Outubro de 2003 as 12h30

Plataforma de integracao de servicos com visualizacao grafica de cada servico (em web)
Cada servico tem o seu viewer.
Fazer um levantamento de requisitos.
Definir as interfaces para a plataforma e viewers.
Use cases para servico e para aplicacao no seu todo.
Componentes visuais, componentes que implementam a logica e o repositorio de dados.
Fazer analise dos Requisitos funcionais e operacionais
O viewer questiona o servico de localizacao para saber onde esta o servico. O servico de localizacao fornece um handler para o servico. Servico de pesquisa de servicos e localizacao.
O Servico pode estar em sitios diferentes.

No front end do Servico de Mail dever� bastar acrescentar a especializa��o para aceder a um webmail.

Servicos de Comunicacao e Servicos de suporte a aplica��o.

Servicos de suporte a aplica��o:

-Servico de Replica��o
-Servico de Localiza��o, Pesquisa e resolu��o de DNS.
-Tolerancia a falhas

proxima reuniao dia 23 de Outubro as 10h

1� Reuni�o 1 de Outubro de 2003 14h30

Plataforma versatil o suficiente que possa integrar novos servi�os. (Bruno)
Objectivos/Requisitos do Trabalho:
-a partida 3 servicos (Mail, Messenger, Agenda)
-Servi�os exportados por Web Service e Remoting
-Plug in de servicos
-Core comum para os varios servicos
-A aplica��o sem plug ins tem que ter algumas funcionalidades
-Replica��o de dados e acesso mesmo em offline
-Mini-Servidor pessoal
-Sistema de "quotas" de espa�o ocupado
-Alojamento de paginas web
-Servidor Central para MSN, Gestao Global, estado dos clientes, etc.
-No��o de grupo hierarquico existente no servidor central
-Blog
-P�gina Pessoal

Servico de MAIL

-deve ser cliente e servidor de MAIL para que possa distribuir
-Sincroniza��o de MAIL'S
-Sistema Regras para chegada de Mails
-Filtragem de conteudos

Servico InstaMsg

-Possibilidade de Grupo ("Multicast")

Agenda

-Notifica��es por varios meios
-Agendamento de eventos para um grupo local ou global
-V�rios tipo de notifica��o

Fim de Reuni�o as 15h30