A composição do serviço SOA realmente funciona na prática?

Um dos princípios principais de design de serviço SOA é o princípio de composição de serviço ( https://en.wikipedia.org/wiki/Service_composability_principle ).

A idéia é que, compondo novos serviços usando os existentes como blocos de construção, é possível desenvolver rapidamente novos serviços. Analogamente, como você chama métodos existentes de objetos quando implementa novos métodos. É aqui que parte do aumento da produtividade da SOA deve ocorrer.

Alguém realmente faz isso na prática? Eu tenho visto isso repetido infinitamente em texto escrito, mas não experimentei as implementações do mundo real. A maior parte do texto também omite qualquer menção à manipulação de transações , o que me parece ser o maior obstáculo na realização de serviços de composição.

Primeiro, você realmente precisa resolver o problema das transações antes de poder compor qualquer serviço não trivial. Claro, se o exemplo tiver os serviços "findCurrentTime ()" e "writeLogMessage ()", é fácil não se preocupar com transações, mas não com exemplos do mundo real, como "depositMoney ()" e "retiradaMoney ()".

Conheço duas opções:

1. Implementar transações reais com o WS-Atomic Transaction ou
2. Implemente uma solução baseada em remuneração que compensa a chamada para A com "cancelA ()" ou algo assim, se a chamada para B falhar

Ambos parecem muito problemáticos / quase inutilizáveis ​​para mim:

• Transação WS-Atomic
  • um monte de complexidade, a maioria dos conselhos que eu encontrei apenas adverte "pé no saco, não fazê-lo"
  • O suporte é limitado, por exemplo, se você usar ESBs de código aberto, as principais alternativas ServiceMix, Mule ou WSO2 não o suportam
• compensações
  • implementar o tratamento de compensações me parece muito complexo. O que fazemos se o serviço A for bem-sucedido e nunca recebermos uma resposta do serviço B e não soubermos se ele falhou ou teve êxito? Manipular essa lógica manualmente (como implementador de serviços de composição) me faz querer cortar meus pulsos - esse é o tipo de trabalho que uma ferramenta deve fazer por mim !.
  • Também não vejo como você pode ter métodos de compensação em serviços não triviais. Digamos que seu serviço A seja "depositMoney ()" e que tenha êxito, alguma outra ação transfira o dinheiro rapidamente para outro lugar e, em seguida, recebamos "compensateDepositMoney ()", o que fazemos agora? Parece uma grande lata de vermes.

Para mim, parece que a composição do serviço é um princípio SOA tão fundamental que você realmente não obtém os benefícios do SOA se não puder (convenientemente) compor serviços . Qual é a realidade? 90% dos usuários de SOA usam "SOA criptografado" sem concorrência real de serviço? Ou a maioria dos usuários de fato usa a composição do serviço e estou exagerando a dificuldade?

A resposta curta é sim!

Eu já vi isso em várias grandes organizações financeiras e funcionou bem.

Os problemas de transação são complexos, mas geralmente são tratados por middleware (caro), como o Oracles WebLogic EAI ou IBMs Websphere ESB.

Sim, pode ser feito para funcionar na prática. No entanto, pode não ser a melhor abordagem e talvez seja usada como a opção padrão mais do que deveria. Na minha opinião, a SOA tornou-se popular como uma maneira de integrar sistemas legados, à medida que as organizações desenvolviam sua TI para automatizar tarefas cada vez maiores. Pode ser muito confuso, mas possivelmente vale a pena se os sistemas legados puderem ser reutilizados. Se você tiver a sorte de iniciar um projeto de campo verde, outras abordagens devem ser consideradas antes de assumir que é o melhor caminho a percorrer.

Para responder a algumas de suas preocupações mais específicas ...

Você pode usar transações:

1. O WS-TX é um PITA e eu o evitaria.
2. Todos os seus serviços podem estar em execução em um único servidor de aplicativos; nesse caso, você pode abranger todos eles com uma transação XA. É por isso que coisas como servidores de aplicativos foram inventadas.

Considerando a abordagem baseada em remuneração:

Ações de compensação só precisam ser consideradas quando houver uma falha. A ferramenta de composição de serviço tem um sinalizador que pode controlar que é limpo ao executar uma etapa do fluxo de trabalho pela primeira vez, mas definido nas chamadas subseqüentes? Como o possível sinalizador de reenvio no JMS. Em seguida, você pode usar o que é chamado de confirmação de 1,5 fase, o que basicamente significa ir em frente se o sinalizador estiver limpo, mas se o sinalizador estiver definido, faça primeiro uma chamada para verificar se o estado já está atualizado e precisa ser feito pela segunda vez . Isso ainda requer tratamento manual de erros e pode ser complexo ou até impossível, como você indica.

Em algumas situações, não importa:

Essa é a abordagem eventualmente consistente. Suponha que um serviço envie um email. Se a composição do serviço falhar e for reiniciada, o email será enviado novamente. Isso é um pouco chato para o destinatário, mas eles provavelmente percebem que é uma duplicata e tudo pode continuar sem grandes problemas.

Você também pode manter um log de e-mails enviados e usá-lo para diminuir a duplicação quando o sinalizador estiver definido e, dessa forma, enviar o e-mail apenas uma vez.

Você pode usar as mensagens assíncronas para dividir as transações em partes menores:

Considere uma fila JMS que é transacional. Seu coordenador de serviço pode atualizar seu estado e postar uma mensagem na fila em um único Tx. Os serviços downstream podem retirar mensagens e atualizar seu estado em um único Tx. Agora você está coordenando serviços em várias unidades de trabalho, mas cada uma é atômica. Se algo falhar e tiver que ser reiniciado, não há problema.

Isso ainda significa que você está executando transações XA no banco de dados e em uma fila JMS, mas isso ainda pode ser eficiente usando o último recurso gambit para evitar a sobrecarga total do XA.

Como alternativa, você pode usar esse padrão, mas com uma confirmação de 1,5 fase no banco de dados e no JMS. OU você pode executar o JMS sem transações, mas torná-lo mais confiável em cluster.

As mensagens assíncronas também podem ajudar a dissociar os sistemas, pois produtores e consumidores podem se tornar mais independentes um do outro, reduzindo a quantidade de acoplamento no sistema geral e tornando-o mais flexível. Esse tipo de dissociação é praticamente essencial quando se trata de grandes organizações com muitos serviços diversos.

Não, é um mito. Essa é uma intenção errada ao projetar a arquitetura de serviço. Há muitos problemas:

1. Acoplamento muito apertado. Se um serviço foi alterado, você precisa testar todo o sistema.
2. Esses serviços são muito refinados, portanto há muita comunicação interna.
3. Como resultado de uma granulação fina, existem muitos serviços. O sistema está ficando difícil de entender, as consultas estão ficando mais difíceis de rastrear.
4. Os serviços de entidade estão mal encapsulados: nenhuma das regras de negócios é verificada lá, essa lógica está nos serviços de operação. Portanto, qualquer serviço pode chamar qualquer serviço de entidade e atualizar seus dados com a consulta de atualização comum presente em sua interface. Esse tipo de serviço de entidade é geralmente chamado de centralizado em dados - em oposição a centralizado em processo e centralizado em comportamento.
5. A natureza inata da comunicação entre esses serviços é síncrona. Portanto, as chances são de que o transporte escolhido seja http. Daí todas as suas desvantagens de que falarei um pouco mais tarde.

Existem maneiras ainda mais erradas de abordar a arquitetura de serviço . Portanto, seja cauteloso.