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

15

Um dos principais princípios de design de serviço SOA é o princípio da capacidade de composição do serviço ( link ).

A ideia é que, ao compor novos serviços usando os existentes como blocos de construção, pode desenvolver rapidamente novos serviços. De forma análoga à maneira como você chama métodos exising de objetos quando você implementa novos métodos. É aí que muito do aumento de produtividade da SOA deve vir.

Alguémrealmentefazissonaprática?Euviissorepetidoindefinidamenteemescritotexto,masnãoexperimenteiimplementarimplementaçõesdomundoreal.Amaioriadostextotambémomitequalquermençãodemanipulaçãodetransações,quemepareceseromaiorobstáculonarealizaçãodeserviçoscompostos.

Primeiro,vocêrealmenteprecisaresolveroproblemadetransaçõesantesdepodercomporqualquerserviçosnãotriviais.Claro,seoexemplotiverserviços"findCurrentTime ()" e "writeLogMessage ()" é fácil não se preocupar com transações, mas não quando se tem real exemplos do mundo, como "depositMoney ()" e "withdrawMoney ()".

Eu sei de duas opções:

  1. Implemente transações reais com transações WS-Atomic ou como
  2. Implementar 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 lote de complexidade, a maioria dos conselhos que eu encontrei apenas avisa "dor no rabo, não faça "
    • o suporte é limitado, por exemplo, se você usar ESBs de código aberto, principais alternativas ServiceMix, Mule ou WSO2 não suportam
  • compensações
    • implementar o manuseio de compensações parece muito complexo para mim. O que fazemos se o serviço A tem sucesso e nunca recebemos uma resposta do serviço B e não sabemos se falhou ou conseguiu? Manipular tal lógica manualmente (como implementador de serviços de composição) faz eu quero cortar meus pulsos - esse é o tipo de trabalho que uma ferramenta deve fazer por mim!
    • Eu também não vejo como você pode ter métodos de compensação em serviços não triviais. Dizer seu serviço A é "depositMoney ()" e isso é bem-sucedido, alguma outra ação rapidamente transfere o dinheiro para outro lugar, e então nós recebemos "compensateDepositMoney ()", o que nós fazemos agora? Parece uma grande lata de vermes.

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

    
por Janne Mattila 27.05.2013 / 10:17
fonte

3 respostas

0

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 middlewares (caros), como o Oracles WebLogic EAI ou o IBMsphere ESB.

    
por 27.05.2013 / 11:00
fonte
4

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 se tornou popular como uma forma 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 sorte o suficiente para começar um projeto de campo verde, outras abordagens devem ser consideradas antes de assumir que esse é o melhor caminho a ser seguido.

Para responder a algumas das 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 sendo executados em um único servidor de aplicativos, caso em que 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ços tem um sinalizador que pode controlar, que é limpo ao executar uma etapa do fluxo de trabalho na primeira vez, mas definido em chamadas subseqüentes? Como o possível sinalizador de reenvio no JMS. Então você pode usar o que é chamado de 1.5 phase commit, que basicamente significa ir em frente se o sinalizador estiver limpo, mas se o sinalizador estiver configurado, primeiro faça uma chamada para verificar se o estado já está atualizado e precisa ser feito uma segunda vez . Isso ainda requer tratamento manual de erros e pode ser complexo ou até mesmo impossível, conforme você aponta.

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

Esta é 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 muito problema.

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

Você pode usar o sistema de mensagens assíncrono 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. Serviços downstream podem remover mensagens e atualizar seu estado em um único Tx. Agora você está coordenando serviços em várias unidades de trabalho, mas cada um é atômico. Se algo falhar e precisar ser reiniciado, não há problema.

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

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

Mensagens assíncronas também podem ajudar a desacoplar sistemas, pois produtores e consumidores podem se tornar mais independentes uns dos outros, reduzindo a quantidade de acoplamentos no sistema geral e tornando-os mais flexíveis. Esse tipo de dissociação é essencial quando se trata de grandes organizações com muitos serviços diversos.

    
por 18.05.2015 / 11:42
fonte
-1

Não, é um mito. Isso é errado intenção de ter ao projetar a arquitetura de serviços. Existe um monte de problemas:

  1. acoplamento muito apertado. Se um serviço foi alterado, você precisa testar todo o sistema.
  2. Tais serviços são muito refinados, então há muita comunicação interna.
  3. Como resultado de ser refinado, há muitos serviços. O sistema está ficando difícil de entender, as consultas estão ficando mais difíceis de rastrear.
  4. Entity-services são mal encapsulados: nenhuma das regras de negócios é verificada lá, essa lógica está em serviços de operação. Portanto, qualquer serviço pode chamar qualquer serviço de entidade e atualizar seus dados com uma consulta de atualização comum que está presente em sua interface. Esse tipo de serviço de entidade é freqüentemente chamado de serviços centrados em dados - em oposição a serviços centrados em processos e centrados em comportamento.
  5. A natureza inata da comunicação entre esses serviços é síncrona. Então, as chances são de que o transporte escolhido seria http. Daí todas as suas desvantagens que vou falar daqui a pouco.

Existem ainda mais maneiras erradas de abordar a arquitetura de serviços . Então seja cauteloso.

    
por 15.11.2017 / 08:45
fonte