Web Service para consultar uma grande quantidade de registros

Sim, é possível. No meu projeto atual temos um webservice que processa algumas milhões de linhas e funciona tudo bem.

Viavel eh. Voce soh precisa tomar o cuidado de nao deixar esses dados trafegarem por alguma ferramenta que limite isso (sim, existem ferramentas que limitam o tamanho dos dados que voce pode trafegar). Alias, uma paginacao ia bem ai, né?

[]'s

Pessoal , muito obrifado pela ajuda.

Bom saber que tem WEB Service funcionando com milhões , a final oque são 18 mil perto de milões , hehehehehehehe.

A princípio , seria para buscar os 18 mil registros uma vez por semana , acredito que vai ser sábado ou domingo e carregar em outro servidor de banco de dados de outra rede os 18 mil registros.

Desculpa , não entendi a questão da paginação. Seria um filtro para retornar menos registros ?
Esses dados serão carregados para uma base e será gerado um excel.O cliente do WEB Service ficará agendado para rodar uma vez por semana.

Ah esqueci de falar , estamos pensando em usar axis2 , pela questão do axis já está a um bom tempo no mercado , documentação. O Servidor de aplicação é o Glassfish 2.1 , Sistema Gerenciador de Banco de dados Oracle 9i. Futuramente será migrado para oracle 11g e Web Logic.

cristiano.zanata:

Pessoal , muito obrifado pela ajuda.

Bom saber que tem WEB Service funcionando com milhões , a final oque são 18 mil perto de milões , hehehehehehehe.

A princípio , seria para buscar os 18 mil registros uma vez por semana , acredito que vai ser sábado ou domingo e carregar em outro servidor de banco de dados de outra rede os 18 mil registros.

Desculpa , não entendi a questão da paginação. Seria um filtro para retornar menos registros ?
Esses dados serão carregados para uma base e será gerado um excel.O cliente do WEB Service ficará agendado para rodar uma vez por semana.

O caso é que, hoje você tem um serviço que vai rodar uma vez por semana. Acontece que web services são muuuuuito chatos de serem alterados (especificamente falando do cliente, não do serviço em sí). E se, amanhã, essa consulta precisar ser feita uma vez por dia? E depois passar a ser duas vezes por dia? Lembrando que, quando você submete um processamento muito pesado para o BD, normalmente ele não processa mais nada além da sua requisição (apesar de me parecer uma consulta read-only apenas, ele precisa tratar toda a questão de locks para garantir que a consulta vai estar correta).

Então, a idéia é que você exponha no seu serviço um método a mais que retorne o número de páginas da consulta. Depois, você se encarrega de ir trazendo as páginas (lógico, balanceando bem o número retornado para também não passar a onerar a rede, que também é frágil.)

Aliás, por falar em frágil, é bastante pergigoso trafegar um volume muito grande de informações pela rede, pois você pode sofrer um timeout, também. Ou seja, paginação é uma boa.

[]´s

Só uma nota em termos de design:

Esse seu serviço obrigatoriamente teria que ser Assíncrono com Callback. Não dá pra esperar uma consulta de sei lá quantos mil registros e expor isso pra empresa consumir. Hoje pode levar 30 segundos, amanhã 2 minutos e seu SLA pode explodir.

Imagine a cereja do bolo, o Portal do Callcenter consumindo um serviço síncrono que leva 10 minutos ? Só mais um minuto senhor…mais um minuto, mais um minuto, mais um minuto …rss

Do ponto de vista técnico, você vai utilize o JAX-WS que é muito melhor que o Axis2. Ele vai cobrir tudo que você necessita, de uma maneira muito mais simples e faz parte da especificação. Se quiser realmente utilizar filtros, entre outras coisas, use o Apache CXF.

Seria interessante também você conhecer um pouco de JMS pra montar um sistema de Queue bacana, fazendo o que chamamos de Correlation ID.

Essa é a maneira correta de se projetar um serviço desse tipo :-), performático e sem lock no seu processo.

E neste caso que estará consumindo todos os registros, prestar atenção em como fazer a paginação. Já vi casos que na paginação ordenavam por data de alteração, e assim alguns registros acabavam não aparecendo, pq haviam justamente sido alterados entre as requisições.

Pegar este erro é bem chato depois, ainda mais num volume maior de registros

Pessoal , muito obrigado pela força.
Me ajudou bastante as informações nas reuniões do web service e serão muito úteis para o desenvolvimento.
Estou aguardando porque talvez vão optar pelo power center e tem outro profissional envolvido.

A colocação do Kenobi está correta,

Atualmente em um callcenter que trabalhei faz exatamente desta forma, o webservice envia uma mensagem e vai embora, o processamento é iniciado pelo serviço de mensageria assincronamente.

Abraços.

narciso.benigno:

A colocação do Kenobi está correta,

Atualmente em um callcenter que trabalhei faz exatamente desta forma, o webservice envia uma mensagem e vai embora, o processamento é iniciado pelo serviço de mensageria assincronamente.

Abraços.

Insisto que, mesmo que ele faça assincronamente, o que ele faz se um dia, ao invés de 18 mil registros ele retornar 18 milhões? Timeout na mesma hora, certo?

Acho que assíncrono é uma boa idéia, mas mesmo assim, teria que ter alguma forma de paginação. Porque trafegar uma quantidade absurda assim por uma rede não confiável (aliás, algum de vocês conhece uma rede que seja confiável?? Eu não!) é inviável, por problemas de timeout, locking de dispositivos de rede, largura de banda, mesmo, etc…

[]´s

Valeu d+ galera pelo apoio.

A solução que o pessoal adotou foi a disponibilização de arquivos no FTP mesmo e me parece que a carga será feita com um um tal de Power Center.

Não será mais desenvolvido o Web Service.