Os serviços da Web são padrões definidos para troca de dados pela Web. Isto não quer dizer que os serviços web serão expostos à Internet, apenas que existe um conjunto acordado de “padrões web” que muitos produtos suportam. Ao decidir qual padrão adotar, a coisa mais importante a considerar é muitas vezes o aconselhamento da equipe técnica.
Eles podem recomendar a você, em ordem, um padrão que seja mais fácil de implementar, que tenha o suporte técnico mais amplo para o produto e que tenha maior probabilidade de funcionar bem em seu ambiente. Para ter uma implementação SOA bem-sucedida que resista ao teste do tempo e continue a crescer no futuro, todos esses três fatores são extremamente importantes.
WS-I
A Web Services Interoperability Organization (WS-I) é especializada no desenvolvimento de melhores práticas para padrões da Web para garantir a interoperabilidade entre diferentes sistemas operacionais, plataformas ou linguagens de programação. O WS-I é responsável por definir documentos de melhores práticas, como segurança de serviços da Web e especificações técnicas de processamento de serviços da Web. Esta documentação ajuda desenvolvedores e empresas a se adequarem às práticas que outros estão usando para garantir a operabilidade do usuário.
A WS-I também publica especificações técnicas, conjuntos de testes e exemplos sobre como implantar esses protocolos. Na verdade, o WS-I é um órgão governamental formado por muitas organizações como a Microsoft e a IBM, e sua missão é promover serviços Web interoperáveis.
Acordo de uso
Os serviços da Web dependem de protocolos para garantir que a comunicação seja significativa. O conteúdo dos dados enviados entre serviços deve ser previamente acordado para garantir que ambas as partes saibam qual conteúdo é recebido. SOAP é um exemplo do protocolo mais utilizado na troca de dados. SOAP usa a linguagem de programação XML, permitindo que ambas as partes decodifiquem o que está sendo enviado e formatem as informações enviadas e recebidas.
ilustrar
Abordaremos algumas arquiteturas em breve e também nos referiremos a alguns protocolos de serviços da web. É importante não confundir essas duas coisas. Então, vamos apresentá-lo brevemente abaixo.
Arquiteturas de software como REST e RPC não são protocolos. São métodos que especificam como o acordo será implementado.
WSDL (Web Services Description Language) é uma linguagem usada para descrever um serviço Web específico de forma formatada para que os aplicativos possam analisar o serviço. O próprio WSDL não fornece nenhuma funcionalidade na forma de interações de serviços da Web.
Os próprios protocolos, como SOAP, XML-RPC ou DCOM, definem exatamente como as mensagens são entregues e como um programa entende os dados que recebe.
Existem dois tipos principais de arquiteturas em SOA: a família de protocolos RPC e a abordagem Representational State Transfer (REST).
RPC
O método de chamada de procedimento remoto (RPC) permite que os programadores chamem recursos de um sistema remoto da mesma forma que "chamam" recursos locais ao programar em um sistema. A desvantagem dos serviços no estilo RPC é que as pessoas tendem a usá-los como se estivessem familiarizadas com a linguagem de programação da plataforma específica. É até fácil chamar um procedimento remoto se for igual ao procedimento local.
Esta lógica viola o conceito de “acoplamento fraco”. O conceito de acoplamento fraco, na verdade, significa que o processo remoto não deve depender de nenhum sistema operacional ou linguagem de programação específica.
SOAP é o protocolo sucessor do XML-RPC e é apenas uma chamada de procedimento remoto que contém suas informações em XML. SOAP usa o protocolo HTTP para enviar dados, o que é simples e agradável, porém tem algumas desvantagens. Apesar disso, a maioria dos serviços web atualmente ainda usa o protocolo HTTP para comunicação, uma vez que são construídos usando o protocolo SOAP.
DESCANSAR
A abordagem Representational State Transfer (REST) é fundamentalmente diferente das chamadas de procedimento remoto porque funciona em um nível diferente. Uma chamada REST se parece com qualquer outra solicitação da web no protocolo HTTP, enquanto uma chamada RPC se parece com uma chamada de função padrão. O foco do REST é operar com recursos estáveis em vez de mensagens individuais, resultando em uma forma de interação mais padronizada e amplamente compreendida, muito parecida com o próprio protocolo HTTP. REST lida com a transferência de blocos de dados simples, enquanto o RPC transfere processos complexos.
REST ou RPC devem ser usados?
A questão de usar REST é certamente boa. Parece o caminho do futuro. No entanto, seu SOA precisa ser integrado a cada software que você usa atualmente. A adoção do REST tem sido lenta, principalmente devido ao suporte a serviços web. Embora um sistema REST possa usar WSDL para descrever uma mensagem SOAP sobre HTTP, não há suporte suficiente para realmente usá-lo. Por exemplo, o Apache nem sequer suporta os métodos necessários para usar REST sem instalar o módulo plug-in.
Existem outros padrões que não fazem parte da família de serviços Web. Mas, como seria de esperar, esses padrões não têm amplo apoio. Jini, WCF e CORBA são alguns exemplos. Quando um fornecedor oferece um produto que suporta apenas uma das tecnologias acima, você quer fugir, não ir embora. Os serviços da Web agora são amplamente suportados. O uso de serviços Web só crescerá. A própria SOA é considerada nova, instável e arriscada. Entretanto, esses riscos podem ser amplamente mitigados quando você escolhe um padrão de serviços Web apropriado que tenha amplo suporte técnico.
Finalmente, aderir ao SOAP tradicional em vez de algum tipo de sistema estilo RPC é atualmente um mecanismo viável para construir SOA usando serviços Web. Se você fizer isso, reduzirá significativamente suas chances de dependência do fornecedor.