Como implementar acoplamento fraco com uma arquitetura SOA

Question

Tenho feito muitas pesquisas ultimamente sobre SOA e ESB, etc.

Estou trabalhando no redesenho de alguns sistemas legados em funcionamento agora e gostaria de construí-los com uma arquitetura mais SOA do que a atual.Usamos esses serviços em cerca de 5 de nossos sites e um dos maiores problemas que temos agora com nosso sistema legado é que quase sempre que fazemos correções de bugs ou atualizações, precisamos reimplantar nossos 5 sites, o que pode ser um processo bastante demorado.

Meu objetivo é tornar as interfaces entre os serviços fracamente acopladas, para que as alterações possam ser feitas sem a necessidade de reimplantar todos os serviços e sites dependentes.

Preciso estender uma interface de serviço já existente sem interromper ou atualizar nenhuma de suas dependências.Algum de vocês já encontrou esse problema antes?Como você resolveu isso?

Answer 1

Sugiro olhar para um estilo de serviços diferentes do que você já fez até agora. Considere serviços que colaboram uns com os outros usando eventos, em vez de solicitar/resposta. Eu uso essa abordagem há muitos anos com clientes em várias verticais com muito sucesso. Eu escrevi bastante sobre esses tópicos nos últimos 4 anos. Aqui está um lugar onde você pode começar:

http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-compponents-in-soa/

Espero que ajude.

Answer 2

Existem algumas abordagens que você pode adotar.Nossa arquitetura SOA envolve mensagens XML enviadas de e para os serviços.Uma maneira de conseguirmos o que você descreve é ​​evitando o uso de uma biblioteca de ligação de dados ao nosso esquema XML e usando um analisador XML genérico para obter apenas os nós de dados que você deseja, ignorando aqueles nos quais você não está interessado.Dessa forma, o serviço pode adicionar novos nós adicionais à mensagem sem interromper ninguém que esteja usando-o atualmente.Normalmente só fazemos isso quando precisamos de apenas uma ou duas informações de uma estrutura de esquema maior.

Alternativamente, a outra solução (preferencial) que usamos é o versionamento.Uma versão de um serviço adere a um esquema/interface específico.Quando o esquema muda (por exemplo, a interface é estendida ou modificada), criamos uma nova versão do serviço.A qualquer momento podemos ter 2 ou 3 versões em movimento ao mesmo tempo.Com o tempo, descontinuamos e removemos versões mais antigas, ao mesmo tempo que migramos o código dependente para versões mais recentes.Desta forma, aqueles que dependem do serviço podem continuar usando a versão existente do serviço, enquanto alguma dependência específica pode 'atualizar' para a nova versão.Quais versões de um serviço são chamadas são definidas em um arquivo de configuração para o código dependente.Observe que não é apenas o esquema que recebe controle de versão, mas também todo o código de implementação subjacente.

Espero que isto ajude.

Answer 3

O que você está perguntando não é um tópico fácil. Existem muitas maneiras de fazer sua arquitetura orientada a serviços vagamente acoplada.

Eu sugiro conferir Thomas Erl's SOA LIVRO SERIES. Explica tudo de maneira clara e aprofundada.

Answer 4

Existem algumas práticas comuns para obter um acoplamento frouxo para serviços.

1. Use o estilo DOC/literal dos serviços da Web, pense em dados (o formato do fio) em vez do RPC, evite a ligação de dados baseada em esquema.

2. Respeitar estritamente o contrato ao enviar dados, mas mantenha poucas suposições processando dados recebidos, o XPath é uma boa ferramenta para isso (solto, com força)

3. Use o ESB e evite qualquer comunicação diretamente para apontar entre os serviços.

Answer 5

Aqui está uma lista de verificação aproximada para avaliar se sua SOA implementa Loose Coupling:

• Localização do sistema chamado (seu endereço físico): O seu aplicativo usa URLs diretos para acessar sistemas ou o aplicativo é dissociado por meio de uma camada de abstração responsável por manter as conexões entre os sistemas?O Registro de Serviços e o Paradigma do Grupo de Serviços usados ​​no SAP NetWeaver CE são bons exemplos de como essa abstração pode ser.Usar um barramento de serviço corporativo (ESB) é outro exemplo.O ponto é que o aplicativo não deve codificar o endereço físico do sistema chamado para ser realmente considerado pouco acoplado.

• Número de receptores: O aplicativo especifica quais sistemas são os receptores de uma chamada de serviço?Um composto vagamente acoplado não especificará sistemas específicos, mas deixará a entrega de suas mensagens a uma camada de implementação do contrato de serviço.Um aplicativo bem acoplado chamará explicitamente os sistemas de recebimento em ordem;Um aplicativo vagamente acoplado simplesmente faz chamadas para a interface de serviço e permite que a camada de implementação do contrato de serviço cuide dos detalhes da entrega de mensagens nos sistemas certos.

• Disponibilidade de sistemas: O seu aplicativo exige que todos os sistemas que você esteja conectando para estar em funcionamento o tempo todo?Obviamente, esse é um requisito muito difícil, especialmente se você deseja se conectar a sistemas externos que não estão sob seu controle.Se a resposta é que todos os sistemas devem estar em execução o tempo todo, o aplicativo será fortemente acoplado a esse respeito.

• Formato de dados: O aplicativo reutiliza os formatos de dados fornecidos pelos sistemas de back -end ou você está usando um sistema de tipo de dados canônico que é independente dos sistemas de tipo usados ​​nos aplicativos chamados?Se você estiver reutilizando os tipos de dados dos sistemas de back -end, provavelmente precisará lutar com conversões de tipo de dados em seu aplicativo, e essa não é uma abordagem muito pouco acoplada.

• Tempo de resposta: O aplicativo exige sistemas chamados para responder dentro de um determinado prazo ou é aceitável para que o aplicativo receba uma resposta de minutos, horas ou até dias depois?