Problemas com Arquitetura

Pessoal,

Serei breve na explicação do meu problema. O cenário que possuo é composto por duas aplicações Enterprise que se comunicam através de WebServices. A primeira, é quem provê o serviço. Serviço esse que é um mecanismo de execução de testes síncronos e assíncronos. Para execução de testes assíncronos, é retornado ao usuário apenas um ID de execução, enquanto o teste fica num pool de testes gerenciado por outro componente. Toda vez que eu quiser saber se o teste terminou, envio outra requisição acessando o WS e pergunto qual o novo status do teste de ID=X. O teste, quando finalizado, tem seu resultado persistido em base no lado da aplicação 1, e toda vez que a aplicação 2 quiser ter acesso à esse resultado basta acessar novamente o WS fornecido utilizando o ID como chave para recuperação deste resultado.

Um problema que quero evitar é o enorme tráfego na rede, pois muitos usuários farão uso do sistema para execução de inúmeros testes. Acessos a resultados serão constantes e consequentemente o número de requisições ao WS será volumoso. O que pensei em fazer foi criar um mecanismo de persistência, no lado da aplicação 2, para armazenar esse resultado. As dúvidas são as seguintes:

1- Sendo o conteúdo da resposta do WS para consulta do resultado de um teste uma pequena qtd de KB, vale a pena realmente criar esse mecanismo e previnir uma reconsulta?
2- Qual implementação seria mais adequada ao mecanismo de persistência? Armazenar essa informação na sessão do usuário (em memória), ou desenvolver alguma estrutura na base de dados para fazer o trabalho e efetuar consultas em base local?

Estou usando Glassfish, JSF (MyFaces, RichFaces, Tomahawk), EJB3, MySQL.

Agradeço desde já a ajuda!
Abraço!

Pergunta: precisa mesmo de webservices? A aplicação servidor já está implementada assim?

Fala Raul…

Cara, a minha opiniao é a seguinte:

Pergunta 1: Sim, vale a pena.

Pergunta 2: Criar em memoria sempre é mais rapido. Por mais que a sua consulta
leve 0,5s pra ser concluida (chutando mto alto), imagine isso varias e varias vezes,
talvez ate em crescimento exponencial. Tendo em memoria, eh instantaneo.

Ok?

Abraco!

grava em arquivos XML.
melhor que ficar em memoria mantendo isso.
XTream gera XML apartir do objeto. é facio gravar e ler o arquivo
assim vc mantem os dados e nao “soca” a memoria

E se o sistema enviasse um email avisando o termino do teste para o usuário?

O que vcs acham?

flws

R: Sim Tchello, pois existem outras aplicações (além dessa que falei) que também precisam consumir recursos dessa primeira aplicação, e webservice é a maneira mais simples nesse caso. O cenário já está fechado em termos de protocolos de comunicação.

kenneth e mInEiRo, obrigado pelas respostas. Já havia me convencido dessa necessidade em evitar tráfego desnecessário na rede (mesmo sendo pouca informação trafegada). Sobre as sugestões de armazenar em memória ou em XML (já usamos Xtream em outro ponto :wink: ) acho que armazenar em memória está mais para a realidade, pois é uma informação que não preciso persistir além da sessão do usuário, e no caso de armazenar em XML, no disco, teriam operações de IO e de qualquer forma teria que me preocupar em limpar essas informações de tempos em tempos para não consumir recursos de máquina desnecessariamente. Mas não descarto a possibilidade, apenas daria um pouco mais de trabalho.

Obrigado pelas dicas, e se tiverem mais opiniões, ficarei agradecido em lê-las!

Abraço!

[quote=fantomas]E se o sistema enviasse um email avisando o termino do teste para o usuário?

O que vcs acham?

flws

[/quote]

Fantomas, dessa forma você adicionaria um terceiro componente pelo qual você não poderia garantir confiabilidade operacional. Além do serviço que a ferramenta irá oferecer, com certo nível de críticidade, que pode ter algum tipo de problema por falha na comunicação, o servidor de email que seria responsabilidade de outra equipe também poderia falhar, além de ser um recurso concorrido com qualquer besteira que alguém resolva enviar por email. O usuário também precisa de uma resposta rápida, se ele tivesse que ficar olhando email pra saber se um teste terminou, pode deixar um gap muito grande de ociosidade do operador.