disparadores de eventos baseado em timer

votos
10

Atualmente, estou trabalhando em um projeto com requisitos específicos. Uma breve visão geral estes são os seguintes:

  • Os dados são recuperados a partir de serviços web externos
  • Os dados são armazenados no SQL 2005
  • Os dados são manipulados por meio de uma interface gráfica web
  • O serviço do Windows que se comunica com os serviços da web não tem acoplamento com a nossa interface web interna, exceto através do banco de dados.
  • A comunicação com os serviços web precisa ser ambos baseados em tempo, e desencadeou via intervenção do usuário na interface web.

O modelo atual (pré-pré-produção) para comunicação de serviço web desencadeando é através de uma tabela de banco de dados que armazena desencadear pedidos gerados a partir da intervenção manual. Eu realmente não quero ter vários mecanismos de gatilho, mas gostaria de ser capaz de preencher a tabela de banco de dados com gatilhos baseados na hora da chamada. A meu ver, há duas maneiras de conseguir isso.

1) Adaptar tabela de gatilho para armazenar dois parâmetros extras. Um ser não é baseada em tempo ou manualmente adicionado? e um campo anulável para armazenar os detalhes de temporização (exata formatar a ser determinado). Se é um gatilho manaully criado, marcá-lo como processado quando o gatilho foi acionado, mas não se isso é um gatilho cronometrado.
ou
2) Criar um segundo serviço de janelas que cria os gatilhos on-the-fly em intervalos de tempo.

A segunda opção parece ser uma fudge para mim, mas a gestão da opção 1 poderia facilmente se transformar em um pesadelo de programação (como você sabe se a última pesquisa da tabela devolveu o evento que precisa de fogo, e como você depois pará-lo re-desencadear na próxima sondagem)

Eu apreciaria se alguém poderia poupar alguns minutos para me ajudar a decidir qual o caminho (um dos dois, ou possivelmente uma terceira, uma não listado) para tomar.

Publicado 06/08/2008 em 11:43
fonte usuário
Em outras línguas...                            


3 respostas

votos
1

Por que não usar um trabalho SQL em vez do serviço do Windows? Você pode encapsular todos vocês db código "gatilho" em procedimentos armazenados. Em seguida, sua interface e SQL Job pode chamar os mesmos procedimentos armazenados e criar gatilhos da mesma forma se é manualmente ou em um intervalo de tempo.

Respondeu 07/08/2008 em 19:24
fonte usuário

votos
0

@Vaibhav

Infelizmente, a arquitetura física da solução não vai permitir que qualquer comunicação direta entre os componentes, com excepção Web UI para banco de dados e banco de dados para o serviço (que pode, em seguida, chamar aos serviços web). Eu, entretanto, concordam que re-uso das classes de comunicação seria o ideal aqui - eu simplesmente não pode fazê-lo dentro dos limites de nosso negócio *

* Nem sempre é a maneira que uma solução tecnicamente "melhor" é impedido por fatores externos?

Respondeu 06/08/2008 em 12:03
fonte usuário

votos
0

A maneira que eu vejo é este.

Você tem um serviço do Windows, que está jogando o papel de um programador e nele existem algumas classes que simplesmente chamar os webservices e colocar os dados em seus bancos de dados.

Assim, você pode usar essas classes diretamente a partir do WebUI bem e importar os dados com base no gatilho WebUI.

Eu não gosto da idéia de armazenar um usuário ação gerado como uma bandeira (trigger) no banco de dados onde algum serviço irá pesquisar lo (em um intervalo que não está sob o controle do usuário) para executar essa ação.

Você pode até mesmo converter todo o código em um exe que você pode então agendar usando o Agendador do Windows. E chamar o mesmo exe sempre que o usuário aciona a ação a partir da interface Web.

Respondeu 06/08/2008 em 11:53
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more