Artigo Java Magazine 71 - Acoplamento entre serviços SOA

O baixo acoplamento é provavelmente um dos benefícios mais discutidos em TI de uma forma geral, mas principalmente quando o assunto é web services, bem ao lado da reutilização de serviços. Hoje, após uma extensiva utilização dos princípios de SOA, será que podemos medir este desacoplamento? Ou, será que sabemos como aplicá-lo?

Vamos discutir neste artigo um pouco sobre o acoplamento, como as ferramentas atuais para implementação de SOA e BPM propiciam a criação de códigos pouco acoplados e alguns cuidados que devemos ter na seleção de nossa arquitetura de implementação.

O que é acoplamento?

De uma forma bastante ampla, o acoplamento mede o grau de dependência entre dois sistemas ou módulos. Este conceito pode ser aplicado de forma semelhante a serviços. Quanto maior é o acoplamento, maior é a dependência entre o serviço e o cliente que o acessa, e, portanto, alterações no serviço irão demandar manutenções em maior ou menor grau em outras partes do sistema. Isto pode ser traduzido em uma palavra: manutenção. Naturalmente, o desejável é que o serviço e seu cliente estejam o mais desacoplado possível, de forma que alterações no serviço causem o menor impacto no restante dos códigos em um sistema.

Parece óbvio que desacoplamento total parece impossível de se obter, já que para que o cliente tenha como acessar um serviço precisa no mínimo conhecê-lo, em termos de parâmetros passados e retornados. O acoplamento pode existir de outras formas também. Imagine duas rotinas que fazem uma determinada operação, com ligeiras diferenças. Por uma deficiência na implementação estes dois códigos foram criados de forma separada. Caso exista a necessidade de alteração em uma rotina, a outra deverá também ser alterada (para manter os processamentos idênticos). Este é um tipo de acoplamento que pode ser reduzido mantendo-se apenas um ponto de manutenção para um determinado código.

Como existem inúmeros conceitos onde o acoplamento pode ser aplicado, vamos discutir o acoplamento aplicado a web services e os clientes que os acessam, e naturalmente os desdobramentos que a evolução das tecnologias sofreram durante esta evolução.

Acoplamento, CORBA e RMI?

Em um mundo onde a internet convive com múltiplos sistemas operacionais, o termo acoplamento ganhou novas proporções. Diz-se que a necessidade de uma tecnologia em um ambiente para que seja possível acessar outro ambiente é um tipo de acoplamento. Por exemplo, termos o Windows instalado na máquina cliente para que possamos acessar um serviço DCOM em outra máquina é um tipo de acoplamento. Da mesma forma, a necessidade de uma JVM para acessar um serviço JRMP em outra máquina é um tipo de acoplamento. Já CORBA (Common Object Request Broker Architecture), como agregou um protocolo aberto para comunicação (IIOP – Internet InterOrb Protocol) tem um grau de acoplamento mais baixo em relação aos anteriores, visto que existem provedores CORBA para diversos sistemas operacionais e mesmo linguagens de programação existentes. Nesta escala de acoplamento, a DCOM ficaria em um extremo, ao passo que o CORBA em outro.

Com a popularização do XML como forma de representação de informações de objetos, foi até que natural a criação de um protocolo que utilizasse dados codificados em XML como forma de comunicação. Na realidade, quem acompanhou a criação do SOAP sabe que ele foi criado como forma de permitir interoperabilidade entre as plataformas Microsoft e Java. Um dos criadores do SOAP foi a própria Microsoft, permitindo que seus sistemas pudessem conversar de forma “neutra” com outras tecnologias como o Java. Como foi definido sobre padrões abertos em grande ascensão ( ...