SOA se aplica aos grandes sistemas distribuídos. A escalabilidade e a tolerância a falhas são as chaves para a manutenibilidade desses sistemas. Adicionalmente é necessário minimizar o impacto das modificações e das falhas dentro do cenário do sistema como um todo. É por esta razão que o acoplamento fraco é um conceito chave de SOA.

 

A Necessidade de Tolerância a Falhas

O mercado demanda soluções rápidas, flexíveis e baratas, o que conflita com serem bem projetadas e robustas. Problemas irão ocorrer, mas é importante minimizar seus efeitos e consequências.

 

Formas de Acoplamento Fraco

O modo de obter acoplamento fraco é minimizar dependências. A introdução de acoplamento fraco deve ser feita na medida certa para satisfazer os requisitos de escalabilidade, flexibilidade e tolerância a falhas, uma vez que há um preço a ser pago em termos de complexidade (acarreta mais desenvolvimento e/ou esforços de manutenção).

 

	Acoplamento Forte	Acoplamento Fraco
Conexões físicas	Ponto a ponto	Via mediador
Estilo da comunicação	Síncrona	Assíncrona
Modelo de dados	Tipos complexos comuns	Apenas tipos comuns simples
Sistema de tipagem	Forte	Fraco
Padrão de interação	Navegação através de árvores de objetos complexas	Mensagens autocontidas centradadas em dados
Controle da lógica de processo	Controle central	Controle distribuído
Binding (ligação)	Estática	Dinâmica
Plataforma	Forte dependência	Independência
Transações	2PC (two-phase commit)	Compensação
Deployment	Simultâneo	Em tempos diferentes
Versioning (controle de versões)	Atualizações explícitas	Atualizações implícitas

 

Comunicação Assincrona

Significa que o remetente e o destinatário não estão sincronizados. Depois que um envia sua mensagem pode continuar seu trabalho enquanto espera resposta. O destinatário pode ou não estar disponível no momento do envio. Quando ele se conecta, a mensagem é recebida. Ele precisa processá-la e enviar sua resposta, se necessário. Quem aguarda a resposta não precisa estar disponível quando ela é enviada. Se uma resposta é requerida, longos tempos de resposta não bloqueiam o consumidor de serviço.

 

Tipos de Dados Heterogêneos

A harmonização de tipos de dados não é viável para grandes sistemas distribuídos, pois conduz à "paralisação da análise" (ao se tentar obter a perfeição, analisando todos os requisitos, o trabalho nunca termina). Uma das causas é que as visões e interesses envolvidos são variados demais. Outra causa fundamental é que sistemas diferentes se expandem de formas diferentes. Em suma, a harmonização é cara demais em termos de tempo e dinheiro.

 

Mediadores

Uma chamada de serviço do tipo ponto a ponto (tal como Web Service) introduz acoplamento forte, pois o consumidor precisa enviar sua requisição para um sistema físico específico usando seu endereço físico. Torna-se necessário haver um mediador para minimizar esta dependência.

 

Há dois tipos de mediadores:

• Um tipo de mediador que fornece o ponto de terminação (endpoint) do serviço antes de sua chamada ser feita. Este tipo de mediador é muito conhecido como broker ou como servidor de nomes. Pergunta-se ao broker por um nome de serviço simbólico e ele informa o endereço físico a ser utilizado para o envio da requisição.
• Um outro tipo de mediador que escolhe o ponto de terminação (endpoint) do serviço após sua chamada ser feita. A chamada é feita usando um nome simbólico e a infraestrutura entrega a requisição para o sistema apropriado usando regras de roteamento inteligentes.

 

Verificação Fraca de Tipos

Linguagens de programação fortemente tipadas favorecem a detecção precoce de erros, antecipando para o momento da compilação a identificação de problemas que de outra forma seriam detectados apenas em tempo de execução. Se este conceito fosse estendido aos tipos de dados das requisições de serviço, isto iria prejudicar o desempenho e criar forte acoplamento. A infraestrutura (ESB) iria precisar dispor dos arquivos de XML schema que definem todos os tipos utilizados e precisaria de um tempo extra para realizar validações de tipos para cada requisição e para cada resposta. Qualquer modificação nos tipos de dados não envolveria apenas fornecedores e consumidores, mas também a infraestrutura. O ideal é que as mudanças das interfaces afetem apenas aqueles que as utilizam por contrato e não aqueles que transferem os dados correspondentes. Por estas razões é necessário usar interfaces genéricas e deixar as validações à cargo apenas dos sistemas onde os dados forem processados.

 

Binding (ligações)

É uma forma de acoplamento fraco similar à verificação fraca de tipos. Binding é a tarefa de correlacionar símbolos de diferentes módulos ou unidades de tradução. Há a opção de binding anterior (cuja verificação é em tempo de compilação) e binding posterior (cuja a verificação é em tempo de execução).

 

Dependências de Plataforma

Uma forma de acoplamento forte consiste de soluções que apresentam restrições quanto a plataforma. Soluções independentes de plataforma aumentam a liberdade de escolha. Uma outra forma de dependência de plataforma tem a ver com padrões de interação.

 

Padrões de Interação

Os padrões de interação são os paradigmas de programação empregados para modelar as interfaces dos serviços (englobando os tipos de dados fundamentais e suas possíveis combinações). Quanto mais complexas as construções programáticas, maior será a abstração que poderá ser adotada na programação. No entanto, haverá problemas para mapear os dados para plataformas que não possuam suporte nativo para uma construção particular.

 

Compensação

É uma forma de acoplamento fraco, relacionada à segurança da transação. A compensação elimina o incoveniente do 2PC (two-phase commit; completamento em duas fases): o 2PC exige que todos os sistemas atualizados por uma transação estejam online e provendo recursos até que a atualização seja completada no último sistema. Isso pode levar a atrasos e a deadlocks. A compensação é uma abordagem para a qual as atualizações não precisam ser feitas em sincronia. Para manter consistência, na caso de falha em algum sistema é feita a reversão das modificações nos demais sistemas em que elas foram completadas com sucesso.

 

Controle da Lógica de Processo

Um controle de processos descentralizado e distribuído evita gargalos e permite que caso alguns sistemas falhem os demais ainda possam continuar trabalhando.

 

Deployment

Requerer atualizações simultâneas de sistemas cria acoplamento forte. Para minimizar dependências é necessário permitir que as migrações possam ocorrer gradualmente. Para tanto é necessário haver um controle de versões.

 

Controle de Versões

Com uma foma de controle de versões mais fracamente acoplada, o consumidor não terá que fazer nada enquanto as modificações feitas pelo fornecedor forem compatíveis com versões anteriores.

 

Lidar com Acoplamento Fraco

Existem diferentes formas de acoplamento fraco, mas qualquer uma delas tem suas desvantagens. É, portanto, necessário encontrar o equilíbrio correto entre acoplamento fraco e forte para cada contexto e projeto específicos.