Os aplicativos de middleware são necessários para fazer a lógica de negócios?

Question

Suponhamos que eu tenha uma grande infraestrutura de middleware que media solicitações entre vários componentes de negócios (aplicativos de clientes, rede, pagamentos etc.). A pilha de middleware é responsável pela orquestração, roteamento, transformação e outras coisas (semelhante ao livro de padrões de integração corporativo de Gregor Hohpe).

Minha pergunta é: é um bom design colocar alguns logíca de negócios no middleware?

Digamos que meu aplicativo solicite alguns dados do cliente do middleware. Mas para obter esses dados, tenho que fornecer Identificação do Cliente e alguns outro parâmetro. A busca deste parâmetro deve ser feita pelo aplicativo solicitante ou é o middleware responsável por 'facilitar' e fornecer uma interface que recebe IDs de clientes e busca internamente o outro parâmetro?

Sei que essa não é uma pergunta simples (devido à definição de lógica de negócios), mas eu estava me perguntando se é uma abordagem geral ou algumas diretrizes.

Answer 1

Este é o padrão "Aplicativo composto"; O coração de uma arquitetura orientada a serviço. É isso que os fornecedores ESB estão vendendo: uma maneira de colocar adicional Lógica de negócios em algum lugar que cria um aplicativo composto a partir de aplicativos existentes.

Isso não é simples porque seu aplicativo composto não é apenas o roteamento. É uma nova transação composta adequada em camadas sobre o roteamento.

Dica. Olhe para conseguir um bom ESB antes de ir muito mais longe. Isso rapidamente fica fora de controle e ter algum suporte adicional é útil. Mesmo se você não comprar algo como o Sun Jcaps ou Aberta esb, você ficará feliz em aprender o que faz e como eles organizam aplicativos compostos complexos.

Answer 2

Além do roteamento, transformação e orquestração, o desempenho deve ser lembrado enquanto carrega o middleware com requisitos funcionais. O Middlware deve levar uma fração de todo o tempo de vida da transação de ponta a ponta. Isso pode ser alcançado apenas concentrando -se nas funcionalidades do núcleo do middleware, em vez de tentar complementar as funcionalidades do sistema host.

Answer 3

Orquestração, roteamento e transformação.

Você não faz nada disso por razões técnicas, aleatoriamente, ou apenas por diversão, faz isso porque tem algum requisito de negócios - o ergo há uma lógica de negócios envolvida.

A única coisa que você está faltando para um sistema de negócios completo é o cálculo e os relatórios (vamos assumir que você já possui segurança!).

Exceto por redes de nível muito baixo, o SO e o armazenamento emitem quase tudo o que compreende um sistema de computador está lá porque os usuários de negócios/governo/final desejam que ele esteja lá.

A escolha da 'lógica de negócios' como Terminoligy foi muito ruim e levou a inúmeras distorções de design e arquitetura.

O que a maioria dos bons designers/arquitetos significam pela lógica de negócios é cálculo e análise.

Se você "%s/lógica de negócios/cálculo/g", a maioria dos decretos arquitetônicos faz mais sentido.

Answer 4

O aplicativo de middleware deve fazê -lo. O sistema A não deve ter idéia de que o outro parâmetro exista e certamente não terá idéia de como obtê -lo.