Artigo Java Magazine 71 - Acoplamento entre serviços SOA

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

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

[lead]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.[/lead]

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.

[subtitulo]O que é acoplamento?[/subtitulo]

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.

[subtitulo]Acoplamento, CORBA e RMI?[/subtitulo]

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 (IIOPInternet 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 ("

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?