Artigo Java Magazine 71 - Acoplamento entre serviços SOA

Acoplamento entre serviços SOA

SOA e a redução do acoplamento

Quais os benefícios da redução de acoplamento em web services para uma arquitetura orientada para serviços, e porque devemos buscá-la?

Glauco Reis

De que se trata o artigo:

Este artigo apresenta algumas das tecnologias utilizadas em projetos SOA e web services, e como tratam o acoplamento entre o cliente e o servidor. Também explora os barramentos de serviços e como podem ajudar a reduzir este acoplamento.

Para que serve:

Adotando boas práticas durante a definição da arquitetura podemos tornar os aplicativos mais flexíveis, e conhecendo os pontos de maior acoplamento podemos nos preparar para os ciclos evolutivos de construção.

Em que situação o tema é útil:

Em qualquer implementação que utilize web services, ESBs e SOA, e exista a preocupação em manter um grau de acoplamento adequado no sistema.

Acoplamento entre serviços SOA:

Quando criamos aplicativos SOA ou utilizando web services, um baixo acoplamento facilita a manutenção e promove o reaproveitamento. Neste artigo exploramos as tecnologias mais utilizadas para comunicação distribuída, utilizando web services, apontando seus impactos em termos de acoplamento entre os códigos gerados.

O baixo acoplamento é provavelmente um dos benefícios mais discutidos em TI, pois facilita a manutenção dos códigos e promove reutilização. Quando falamos sobre WebServices, este aspecto é mais importante ainda. 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 alterações nos serviços irão demandar manutenções 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 o desacoplamento total é algo 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 seu ciclo de vida.

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 ersos 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 necessária 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 (HTTP e XML), teve rápida resposta positiva por parte do mercado.

É bem verdade que a maioria dos problemas de comunicação entre os vários sistemas já estavam resolvidos com o IIOP, bem antes do advento do protocolo SOAP, haja vista que em 1995 o CORBA já era estável e o SOAP só foi criado por volta de 1999 (com a versão 1.1 lançada em 2001). Talvez a malfadada dificuldade de programação do CORBA tenha sido a principal causa de seu sepultamento, já que tecnicamente ele é muito superior ao SOAP atual e vários dos problemas que estão sendo endereçados agora estavam resolvidos de forma eficiente no CORBA (segurança e  transações, por exemplo).

Em termos de acoplamento, as tecnologias citadas anteriormente dependem de um código que é gerado a partir do serviço, normalmente chamado de “stub”. Este “stub” implementa o pattern Proxy do GOF, fazendo com que o cliente não tenha a real noção de onde o serviço está sendo executado, se na mesma máquina ou em qualquer lugar da rede. Esta é a chave para os serviços distribuídos. Se por um lado permite que o código esteja em qualquer lugar da rede, por outro força o cliente a agregar o stub, para fornecer esta transparência. É exatamente este stub que traz um maior grau de acoplamento entre o consumidor do serviço e o produtor, visto que parte da atividade de compilação dos stubs e skeletons é gerar os tipos de dados e parâmetros para comunicação. Mudança nos dados e parâmetros afetam os dois lados, o que aumenta o acoplamento.

ATENÇÃO! A exibição deste artigo foi interrompida.

  #Este é um post fechado

Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!