Friday, July 01, 2005
Mais notas sobre utilizadores, contactos e afins:
Cada utilizador tem uma lista de contactos.
Cada contacto pode ou não ser um utilizador registado no PISCO.
Para ter acesso à informação de presença de um contacto é necessário que este seja utilizador registado do PISCO.
Para obter informação de presença sobre um utilizador do PISCO é necessário a existencia de uma relação de confiaça entre utilizadores.
É o utilizador que publica a sua disponibilidade, podendo altera-la a qualquer momento.
Para estabelecer uma relação de confiança entre utilizadores, é necessário que um utilizador responda afirmativamente a um convite de outro utilizador.
Depois de estabelecida a relação de confiança, os utilizadores passam a receber notificações com as alterações de disponibilidade dos seus contactos.
É também possivel estabelecer relações de confiança entre utilizadores e um grupo de utilizadores.
Existem dois tipos de grupo, livres e privados. Os primeiros são de acesso livre e os segundos funcionam à base de convite.
Cada utilizador pode definir a sua disponibilidade ao nivel do grupo, ou do utilizador.
Cada contacto pode ou não ser um utilizador registado no PISCO.
Para ter acesso à informação de presença de um contacto é necessário que este seja utilizador registado do PISCO.
Para obter informação de presença sobre um utilizador do PISCO é necessário a existencia de uma relação de confiaça entre utilizadores.
É o utilizador que publica a sua disponibilidade, podendo altera-la a qualquer momento.
Para estabelecer uma relação de confiança entre utilizadores, é necessário que um utilizador responda afirmativamente a um convite de outro utilizador.
Depois de estabelecida a relação de confiança, os utilizadores passam a receber notificações com as alterações de disponibilidade dos seus contactos.
É também possivel estabelecer relações de confiança entre utilizadores e um grupo de utilizadores.
Existem dois tipos de grupo, livres e privados. Os primeiros são de acesso livre e os segundos funcionam à base de convite.
Cada utilizador pode definir a sua disponibilidade ao nivel do grupo, ou do utilizador.
Thursday, June 30, 2005
Notas sobre grupos de utilizadores:
Podem ser publicos ou privados.
Toda a gente se pode inscrever num grupo publico.
Para pertencer ao um grupo privado é necessário obter autorização/ ser convidado.
Qualquer utilizador pode criar um grupo. Torna-se assim dono/administrador desse grupo.
Aplicando a noção de grupo ao serviço de presença levanta as seguintes questões?
Ser possivel bloquear a informação de presença a todo o grupo?
Dar acesso a todos os membros do grupo à informação de presença?
Subscrever a serviços de informação instantânea.
Exemplo: quero receber informações de transito sobre a 2ª circular.
Onde guardar informação sobre grupos. No serviço de users, contactos ou de presença ???
Toda a gente se pode inscrever num grupo publico.
Para pertencer ao um grupo privado é necessário obter autorização/ ser convidado.
Qualquer utilizador pode criar um grupo. Torna-se assim dono/administrador desse grupo.
Aplicando a noção de grupo ao serviço de presença levanta as seguintes questões?
Ser possivel bloquear a informação de presença a todo o grupo?
Dar acesso a todos os membros do grupo à informação de presença?
Subscrever a serviços de informação instantânea.
Exemplo: quero receber informações de transito sobre a 2ª circular.
Onde guardar informação sobre grupos. No serviço de users, contactos ou de presença ???
Serviço de Presença
Algumas caracteristicas de um serviço de presença
Restrições de acesso, ou seja, é necessário obter autorização para poder ter informação sobre a presença de um utilizador.
É o utilizador que publica o seu estado e que recursos estão disponiveis. Exemplos:
Dado a proximidade entre o serviço de presença e o serviço de notificações decidi investigar as necessidades do primeiro para decidir como implementar o segundo. Após uns dias de leitura eis as conclusões.
O que é um serviço de presença?
Um serviço de presença permite saber quais aos utilizadores que se encontram "presentes" num sistema, em qualquer instante.
Esta caracteristica de instantaneidade, permite melhorar as aplicações de colaboração online.
Hoje em dia, a aplicação mais comum, onde é encontrada a noção de presença, é nos serviços de mensagens instâneas.
Não é dificil encontrar outras aplicações onde a noção de presença traz uma mais valia na qualidade do serviço prestado. Seguem-se alguns exemplos.
O que é um serviço de presença?
Um serviço de presença permite saber quais aos utilizadores que se encontram "presentes" num sistema, em qualquer instante.
Esta caracteristica de instantaneidade, permite melhorar as aplicações de colaboração online.
Hoje em dia, a aplicação mais comum, onde é encontrada a noção de presença, é nos serviços de mensagens instâneas.
Não é dificil encontrar outras aplicações onde a noção de presença traz uma mais valia na qualidade do serviço prestado. Seguem-se alguns exemplos.
- Marcação de reuniões,
- recepção de notificações de trasito
- notificação de qualquer coisa,
- projectos de colaboração,
- etc.
Algumas caracteristicas de um serviço de presença
Restrições de acesso, ou seja, é necessário obter autorização para poder ter informação sobre a presença de um utilizador.
É o utilizador que publica o seu estado e que recursos estão disponiveis. Exemplos:
- Estou disponivel para o grupo dos meus amigos mas não dos meus patrões.
- Não quero receber notificações de trasito quando estou em casa.
- A minha agenda só está disponivel em horas de trabalho.
Para cumprir estes objectivos é necessário que o serviço de presença noção dos seguintes conceitos.
- Grupos de utilizadores,
- recursos/informação disponibilizada pelo utilizador (localização, mood, disponibilidade),
- controlo de acesso à informação de presença, ou de outra forma, quem tem acesso à minha informação de presença em determinado momento.
Funcionamento:
Quando o utilizador Xpto se liga, o serviço de presença notifica todos os seus contactos com autorização que que Xpto está online. Em intervalos regulares o utilizador envia uma mensagem de heartbeat ao serviço para mostrar que ainda de encontra online. Quando o utilizador não envia um heartbeat num periodo superior ao estipulado, o serviço assume que o utilizador está offline.
Quando o utilizador Xpto se liga, o serviço de presença notifica todos os seus contactos com autorização que que Xpto está online. Em intervalos regulares o utilizador envia uma mensagem de heartbeat ao serviço para mostrar que ainda de encontra online. Quando o utilizador não envia um heartbeat num periodo superior ao estipulado, o serviço assume que o utilizador está offline.
Wednesday, June 29, 2005
Thursday, June 09, 2005
Infraestrutura de notificações,
entidades presentes e suas responsabilidades.
entidades presentes e suas responsabilidades.
Serviço de notificação
- Onde os serviços registam as notificações que fornecem,
- publica as notificações existentes,
- onde os clientes subscrevem nas notificaçõe desejadas
- envia as notificações para a(s) postbox(s) correspondentes.
PostBox
- Para onde são enviadas as notificações,
- a sua localização deve ser conhecida ( ou dada a conhecer no momento da ligação ),
Channel
Virtualiza o canal de rede (HTTP, TCP:1234, etc) e a forma de comunicação.
Pode ser:
Virtualiza o canal de rede (HTTP, TCP:1234, etc) e a forma de comunicação.
Pode ser:
- Directa
- Resposta incompleta
- Polling
Relay
Permite a clientes com capacidades de comunicação limitada receberem notificações.
Considerações sobre notificações
Uma notificação é um aviso de que algo aconteceu.
Tipos de notificação
Permite a clientes com capacidades de comunicação limitada receberem notificações.
Considerações sobre notificações
Uma notificação é um aviso de que algo aconteceu.
Tipos de notificação
- Directa, entre utilizadores ( ex: mensagem instântanea, troca de ficheiros ).
- Sistema, entre o sistema e o utilizador ( ex: o utilizador x está online, you've got mail ).
- Grupo (multicast), notificações entre grupos de utilizadores.
Deve permitir o armazenamento de notificações.
Pode existir aviso(s) de recepção.
Permitir entrega de notificações de um modo diferido.
Pode existir aviso(s) de recepção.
Permitir entrega de notificações de um modo diferido.
Thursday, February 17, 2005
Tuesday, January 25, 2005
.NET Remoting, notas gerais
Existem dois tipos de objectos no mundo do Remoting, os objectos moveis e os objectos remotos.
Objectos Remotos
Na plataforma .NET entende-se por comunicação remota, comunicação entre appDomains.
Objectos Moveis
Estrutura geral de uma aplicação em .NET Remoting
Existem 3 componentes distintos:
Implementação do cliente
Os objectos remotos estão separados em duas categorias:
Server Activated Objects - SAO's
Existem dois tipos de objectos SAO, Singleton e SingleCall.
Se o objecto for criado como Singleton, no máximo,apenas existe uma instância desse objecto, que atende os pedidos de todos os clientes num cenário de concorrencia (é necessário tomar os cuidados correspondentes).
Estes objectos são stateful, ou seja existe manutenção do estado do objecto entre chamadas.
Nota: os objectos Singleton, são particularmente úteis quando se pretende partilhar um recurso entre vários clientes.
No modo SingleCall, é criado um objecto por chamada, que é destruido no final desta, não existindo assim manutenção de estado.
Uma razão para utilização deste tipo de objectos é a sua escalabilidade, que é consequencia destes objectos não necessitarem de manter estado, podendo assim estar espalhados por um conjunto de maquinas.
Publicação de objectos remotos
Por vezes é necessário que uma instância de um objecto já criada, esteja disponível remotamente. Para que isso seja possível é necessário publicar esse objecto da seguinte forma.
Client Activated Objects - CAO's
ainda tenho que estudar estes melhor :)
Tempo de vida dos objectos
Os objectos remotos na plataforma .NET são criados com um tempo de vida (TTL) (por omissão é 5m), que é incrementado por cada chamada efectuada ao objecto (por omissão é 2m).
Quando o TTL termina a plataforma procura por objectos sponsor associados ao objecto remoto. Se não existirem sponsors associados ao objecto, ou o sponsor decidir que o TTL não é para ser renovado, o objecto remoto é marcado para ser garbage collected.
Algum cliente que ainda possua uma referência para o objecto e efectue uma chamada, recebe uma excepção.
Nota: Só têm o campo TTL objectos Singleton ou objectos CAO.
Nota2: Tenho que estudar melhor os sponsors.
Tipos de Evocação
Existem três tipos de evocação:
Neste tipo de chamadas o cliente fica bloqueado até o servidor ter terminado a tarefa. Alguma excepção ocorrida do lado do servidor é lançada na linha de onde o método foi chamado.
Chamadas assincronas
São efectuadas em duas fases:
Chamadas assincronas one way
São iguais às chamadas assincronas, mas não permitem receber o retorno dos métodos.
Existem dois tipos de objectos no mundo do Remoting, os objectos moveis e os objectos remotos.
Objectos Remotos
- são objectos cujos métodos são executados num appDomain diferente daquele onde foi iniciada a chamada,
- permanecem sempre no servidor, sendo apenas passadas referencias para ele.
Na plataforma .NET entende-se por comunicação remota, comunicação entre appDomains.
Objectos Moveis
- são objectos seriáveis,
- são passados por cópia, sendo que as operações efectuadas sobre ele ocorrem sempre no appDomain do chamador,
- não existe troca de mensagens com o appDomain de onde o objecto é originário,
- é um objecto completamento distinto do original.
Estrutura geral de uma aplicação em .NET Remoting
Existem 3 componentes distintos:
- Servidor, onde residem os objectos remotos.
- Cliente, quem efectua os pedidos.
- um assembly conhecido quer pelo cliente quer pelo servidor, que contém as interfaces dos objectos remotos, bem como a implementação dos objectos moveis que são trocados entre o cliente e o servidor.
- definir a interface remota,
- definir quais os objectos a serem passados entre cliente e servidor.
- implementar a interface remota,
- derivar de MarshalByRefObject,
- criar um canal,
HttpChannel chnl = new HttpChannel(1234);
- registar o canal,
ChannelServices.RegisterChannel(chnl);
- registar a classe do objecto como WellKnownService,
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(RemoteObject),
"RemoteObject.soap",
WellKnownObjectMode.Singleton);
Implementação do cliente
- criar e registar um canal,
HttpChannel channel = new HttpChannel();
ChannelServices.RegisterChannel(channel); - criar um proxy para o objecto remoto,
ICustomerManager mgr = (IRemoteObject) Activator.GetObject(
typeof(IRemoteObject),
"http://localhost:1234/RemoteObject.soap");
Os objectos remotos estão separados em duas categorias:
- Server Activated Objects (SAO)
- Client Activated Objects (CAO)
Existem dois tipos de objectos SAO, Singleton e SingleCall.
Se o objecto for criado como Singleton, no máximo,apenas existe uma instância desse objecto, que atende os pedidos de todos os clientes num cenário de concorrencia (é necessário tomar os cuidados correspondentes).
Estes objectos são stateful, ou seja existe manutenção do estado do objecto entre chamadas.
Nota: os objectos Singleton, são particularmente úteis quando se pretende partilhar um recurso entre vários clientes.
No modo SingleCall, é criado um objecto por chamada, que é destruido no final desta, não existindo assim manutenção de estado.
Uma razão para utilização deste tipo de objectos é a sua escalabilidade, que é consequencia destes objectos não necessitarem de manter estado, podendo assim estar espalhados por um conjunto de maquinas.
Publicação de objectos remotos
Por vezes é necessário que uma instância de um objecto já criada, esteja disponível remotamente. Para que isso seja possível é necessário publicar esse objecto da seguinte forma.
YourObject obj = new YourObject(Objectos publicados comportam-se como objectos Singleton.);
RemotingServices.Marshal(obj,"YourUrl.soap");
Client Activated Objects - CAO's
ainda tenho que estudar estes melhor :)
Tempo de vida dos objectos
Os objectos remotos na plataforma .NET são criados com um tempo de vida (TTL) (por omissão é 5m), que é incrementado por cada chamada efectuada ao objecto (por omissão é 2m).
Quando o TTL termina a plataforma procura por objectos sponsor associados ao objecto remoto. Se não existirem sponsors associados ao objecto, ou o sponsor decidir que o TTL não é para ser renovado, o objecto remoto é marcado para ser garbage collected.
Algum cliente que ainda possua uma referência para o objecto e efectue uma chamada, recebe uma excepção.
Nota: Só têm o campo TTL objectos Singleton ou objectos CAO.
Nota2: Tenho que estudar melhor os sponsors.
Tipos de Evocação
Existem três tipos de evocação:
- sincrona,
- assincrona,
- assincrona One Way.
Neste tipo de chamadas o cliente fica bloqueado até o servidor ter terminado a tarefa. Alguma excepção ocorrida do lado do servidor é lançada na linha de onde o método foi chamado.
Chamadas assincronas
São efectuadas em duas fases:
- o cliente efectua a chamada, não ficando bloqueado à espera do resultado,
- se o cliente quiser receber o valor de retorno do método chamado, tem que chamar outro método, este já bloqueante.
Chamadas assincronas one way
São iguais às chamadas assincronas, mas não permitem receber o retorno dos métodos.
Thursday, January 06, 2005
Notas sobre o tipo de objectos existentes em .NET Remoting
SAO - Server Activated Objects
CAO - Client Activated Objects
Notas adicionais:
Pesquisando nos acetatos de FSD sobre remoting, encontrei lá uma tabela que achei interessante transcrever para aqui, pois mostra as diferenças entre os diferentes tipos de objectos.
|
| SAO Singleton | SAO Single Call | CAO |
| Manutenção de estado | Sim | Não | Sim |
| Tempo de vida do objecto | Controlado pelo lease manager | Duração da chamada ao método | Controlado pelo lease manager |
| Construtor
| Apenas sem parametros | Apenas sem parametros | Qualquer tipo de construtor |
SAO - Server Activated Objects
CAO - Client Activated Objects
Notas adicionais:
Para utilizar objectos CAO é necessário que o assembly com a implementação do objecto esteja do lado do cliente, em vez de conhecer apenas a interface como acontece nos objectos SAO, no entanto, esta limitação não é problematica no meu caso pois cada cliente, funciona ao mesmo tempo como servidor.
É possivel utilizar um soapsud (???) em vez do assembly. Tenho que investigar melhor se é vantajoso.
É necessário investigar como funciona o lease manager e quais são as suas opções de configuração.
É possivel utilizar um soapsud (???) em vez do assembly. Tenho que investigar melhor se é vantajoso.
É necessário investigar como funciona o lease manager e quais são as suas opções de configuração.
Notas para a implentação do protótipo do serviço de IM
Existem dois componentes:
- Um web service, onde a aplicação cliente efectua o login, e que tem conhecimento de quem está online e qual a sua localização.
- Um objecto remoto que está localizado na maquina do cliente, que funciona como caixa de mensagens.
A opção nesta altura é utilizar ligações directas entre os clientes, utilizando .net remoting com client activated objects (CAO).
Esta opção tem consequência serem utilizadas n ligações para conversar com n clientes diferentes, o que me parece razoavél pois não estão a ser gastos recursos de mais nenhum servidor.
Nota: ainda estou na duvida entre a utilização de objectos remotos CAO, ou server activated objects(SAO) em modo Singlecall. Pelo que percebi a diferença está na capacidade de manter estado e no tempo de vida do objecto.
Esta opção tem consequência serem utilizadas n ligações para conversar com n clientes diferentes, o que me parece razoavél pois não estão a ser gastos recursos de mais nenhum servidor.
Nota: ainda estou na duvida entre a utilização de objectos remotos CAO, ou server activated objects(SAO) em modo Singlecall. Pelo que percebi a diferença está na capacidade de manter estado e no tempo de vida do objecto.
