Gatilhos de eventos baseados em temporizador

Question

Atualmente estou trabalhando em um projeto com requisitos específicos.Uma breve visão geral deles é a seguinte:

• Os dados são recuperados de webservices externos
• Os dados são armazenados no SQL 2005
• Os dados são manipulados por meio de uma interface web
• O serviço do Windows que se comunica com os serviços da web não tem acoplamento com nossa UI interna da web, exceto por meio do banco de dados.
• A comunicação com os serviços da web precisa ser baseada no tempo e acionada por meio da intervenção do usuário na interface da web.

O modelo atual (pré-pré-produção) para acionamento de comunicação de serviços web é através de uma tabela de banco de dados que armazena solicitações de acionamento geradas a partir da intervenção manual.Na verdade, não quero ter vários mecanismos de gatilho, mas gostaria de poder preencher a tabela do banco de dados com gatilhos baseados no horário da chamada.A meu ver, existem duas maneiras de conseguir isso.

1) Adapte a tabela de trigger para armazenar dois parâmetros extras.Um sendo "Este é baseado no tempo ou adicionado manualmente?" e um campo anulável para armazenar os detalhes de tempo (formato exato a ser determinado).Se for um gatilho criado manualmente, marque-o como processado quando o gatilho for disparado, mas não se for um gatilho cronometrado.
ou
2) Crie um segundo serviço do Windows que crie os gatilhos dinamicamente em intervalos cronometrados.

A segunda opção me parece uma farsa, mas o gerenciamento da opção 1 pode facilmente se transformar em um pesadelo de programação (como saber se a última enquete da tabela retornou o evento que precisa ser disparado e como você pode interrompê-lo reativando na próxima enquete)

Eu apreciaria se alguém pudesse reservar alguns minutos para me ajudar a decidir qual caminho (um desses dois, ou possivelmente um terceiro, não listado) seguir.

Answer 1

Por que não usar um trabalho SQL em vez do serviço do Windows?Você pode encapsular todo o código "trigger" do banco de dados em procedimentos armazenados.Em seguida, sua UI e seu trabalho SQL podem chamar os mesmos procedimentos armazenados e criar os gatilhos da mesma maneira, seja manualmente ou em um intervalo de tempo.

Answer 2

Do jeito que eu vejo é isso.

Você tem um Serviço Windows, que faz o papel de um agendador e nele existem algumas classes que simplesmente chamam os webservices e colocam os dados em seus bancos de dados.

Portanto, você também pode usar essas classes diretamente do WebUI e importar os dados com base no gatilho do WebUI.

Não gosto da ideia de armazenar uma ação gerada pelo usuário como um sinalizador (gatilho) no banco de dados onde algum serviço irá pesquisá-la (em um intervalo que não está sob o controle do usuário) para executar essa ação.

Você pode até converter todo o código em um exe que pode ser agendado usando o Windows Scheduler.E chame o mesmo exe sempre que o usuário acionar a ação na interface da Web.

Answer 3

@Vaibhav

Infelizmente, a arquitetura física da solução não permitirá qualquer comunicação direta entre os componentes, além da UI da Web para o banco de dados, e do banco de dados para o serviço (que pode então chamar os serviços da Web).No entanto, concordo que a reutilização das classes de comunicação seria o ideal aqui - simplesmente não posso fazê-lo dentro dos limites do nosso negócio*

*Não é sempre assim que uma solução tecnicamente “melhor” é frustrada por fatores externos?