Eu quero projetar um aplicativo da Web baseado em banco de dados à prova de balas, tolerante a falhas e queria saber como arquitetá-lo.
o sistema terá uma interface do usuário asp.net, camada intermediária de serviços da web e back-end SQL2005. A interface do usuário e os serviços se comunicarão usando chamadas JSON.
Eu queria saber como garantir que as transações sejam confirmadas e se não for para qualquer erro aparecer e ser registrado. idealmente, a ação deve ser repetida algumas vezes após intervalos de 5 minutos, como faz um aplicativo de e-mail.
Eu estava planejando usar blocos try catch no SQL e queria saber como seria a interface (ou contrato, se preferir) entre os procedimentos armazenados do SQL e os serviços que os chamam. esta interface irá desempenhar 2 funções uma delas é passar parâmetros para que o proc funcione e retorne os resultados esperados. o próximo será para o proc retornar informações de erro. talvez algo como número de erro e mensagem de erro.
meu pântano é como estruturar isso de forma inteligente para que os serviços esperem e reajam de acordo com os dados e informações de erro retornados de procs e lidem com cada um de acordo?
existe uma estrutura para isso porque parece muito clichê?
É claro! Como a maioria dos problemas interessantes em aplicativos de missão crítica, isso foi realmente resolvido pela IBM na década de 1970, mas a indústria de TI está sempre perseguindo a novidade mais brilhante e não tem respeito pelos grandes engenheiros do passado. Refiro-me, é claro, ao middleware orientado a mensagens ou, como era conhecido na época, TPF . O princípio disso é realmente muito simples e foi comprovado repetidamente por bancos, companhias aéreas, empresas de telecomunicações, etc.
As operações fundamentais são colocar uma mensagem na fila e retirar uma mensagem da fila. Portanto, quando seu aplicativo precisa fazer algum trabalho, ele o empacota como uma mensagem e o coloca na fila para o próximo serviço. O TPM então desenfileira essa mensagem e tenta fazer o trabalho nela. Se isso falhar, a mensagem simplesmente volta para a fila para ser tentada novamente e, se continuar a falhar, é desviada para a fila que lida com falhas. O barramento de mensagens também lida com roteamento, balanceamento de carga e todas essas coisas boas. Você pode comprar esses recursos na prateleira: MQSeries e Tibco Rendezvous são os "sérios", mas existem muitos outros por aí, muitos dos quais são compatíveis com JMSportanto, você não está vinculado a um fornecedor (é claro que, se você for JMS, também estará vinculado ao menor denominador comum). Você especifica seu barramento de mensagens para ser ultraconfiável e tolerante a falhas, depois apenas pendura os serviços na parte de trás dele e coloca seu aplicativo na frente. SOA é outro exemplo de uma ideia antiga que foi reaquecida com novas palavras-chave...