Advertisement

Aula 07 - Web Services com manutenção de estado (WSDL-SOAP)



1-              Introdução


Compreendemos nas aulas anteriores que é possível criar serviços capazes de serem consumidos por aplicações. Nessa aula iremos discutir um pouco mais sobre Web Services, porém, iremos fazer uma distinção entre eles: com manutenção de estado e sem manutenção de estado.
O objetivo dessa aula é explicar e exemplificar como funcionam os WS com manutenção de estado. Para isso iremos detalhar componentes desse tipo de serviço e ao final veremos um exemplo de como construir um Web Service usando SOAP/XML.

2-              SOAP


O SOAP (Simple Object Access Protocol) baseia-se numa invocação remota de um método e para tal necessita especificar o endereço do componente, o nome do método e os argumentos para esse método. Estes dados são formatados em XML com determinadas regras e enviados normalmente por HTTP para esse componente. Não define ou impõe qualquer semântica, quer seja o modelo de programação, quer seja a semântica específica da implementação. Este aspecto é extremamente importante, pois permite que quer o serviço, quer o cliente que invoca o serviço, sejam aplicações desenvolvidas sobre diferentes linguagens de programação. Por esta razão, o SOAP tornou-se uma norma aceita para se utilizar com Web Services, uma tecnologia construída com base em XML e HTTP.
Desta forma, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização da linguagem XML e do mecanismo de transporte HTTP ou outro como, por exemplo, SMTP. O SOAP permite que os documentos XML de envio e de recepção sobre a Web suportem um protocolo comum de transferência de dados para uma comunicação de rede eficaz, ou seja, o SOAP providencia o transporte de dados para os Web Services.
Em relação a Web, o SOAP é um protocolo de RPC que funciona sobre HTTP (ou SMTP, ou outro) de forma a ultrapassar as restrições de segurança/firewalls normalmente impostas aos sistemas clássicos de RPC (RMI, DCOM, CORBA/IIOP) suportando mensagens XML. Em vez de usar HTTP para pedir uma página HTML para ser visualizada num browser, o SOAP envia uma mensagem de XML através do pedido HTTP e recebe uma resposta, se existir, através da resposta do HTTP. Para assegurar corretamente a transmissão da mensagem de XML, o servidor de HTTP (Apache ou Microsoft Internet Information Server), recebe mensagens SOAP e deve validar e compreender o formato do documento XML definido na especificação SOAP v1.1.

3-              WSDL


É a sigla de Web Services Description Language, padrão baseado em XML para descrever o serviço como no COM, onde ele traz os métodos do Web Service. Funciona como uma espécie de "TypeLibrary" do Web Service, além de ser usado para a validação das chamadas dos métodos.
O WSDL é uma especificação desenvolvida pelo W3C e também é extensível para permitir a descrição dos serviços e suas mensagens, independentemente dos formatos de mensagem e dos protocolos de rede que sejam usados. No entanto, é comum usar-se o MIME (Multipurpose Internet Mail Extensions) e o HTTP://SOAP.

O WSDL descreve os serviços disponibilizados à rede através de uma semântica XML, este providencia a documentação necessária para se chamar um sistema distribuído e o procedimento necessário para que esta comunicação se estabeleça. Enquanto que o SOAP especifica a comunicação entre um cliente e um servidor, o WSDL descreve os serviços oferecidos.
A versão atual é 2.0; a versão 1.1 não foi endossada pelo W3C. A WSDL 1.2 foi renomeada para 2.0 e aceita todos os métodos de requisição HTTP (não apenas GET e POST).

4-              UDDI


Protocolo desenvolvido para a organização e registro de Web Services. O UDDI (Universal Description Discovery and Integration) é uma iniciativa em desenvolvimento no âmbito do consórcio industrial UDDI promovido originalmente pela IBM, Microsoft e Arriba, com objetivo de acelerar a interoperabilidade e utilização dos Web Services, pela proposta de um serviço de registro de nomes de organizações e de descrição do serviço. UDDI nada mais é do que um serviço de diretório onde empresas podem registrar (publicar) e buscar (descobrir) por serviços Web (Web Services).

Um registro UDDI contém três tipos de informação:

  • Informações gerais de cada organização, tais como o nome, endereço e contatos;
  • Informações de organizações e serviços por categorias de negócios;
  • Informações técnicas sobre os serviços providenciados pelas organizações.


O UDDI providencia três funções principais, conhecidas como publicação, descoberta e ligação:

1) publicação: permite que uma organização divulgue o(s) seu(s) serviço(s);
2) descoberta: permite que o cliente do serviço procure e encontre um determinado serviço;
3) ligação (bind): permite que o cliente do serviço possa estabelecer a ligação e interagir com o serviço.

Um serviço de registro UDDI é um Web Service que gerencia informação sobre provedores, implementações e metadados de serviços. Provedores de serviços podem utilizar UDDI para publicar os serviços que eles oferecem. Usuários de serviços podem usar UDDI para descobrir serviços que lhes interessem e obter os metadados necessários para utilizar esses serviços, que podem ter três partes:


  • "páginas brancas" descrevem a companhia: nome, endereço, contatos, etc.
  • "páginas amarelas" incluem as categorias, baseada em taxonomias padrões.
  • "páginas verdes" descrevem a interface para o serviço em nível de detalhe suficiente para se escrever uma aplicação que use o Web Service.

A especificação UDDI define:


  • APIs SOAP utilizadas para publicar e obter informações de um registro UDDI;
  • Esquemas XML do modelo de dados do registro e do formato das mensagens SOAP;
  • Definições WSDL das APIs SOAP;
  • Definições de registro UDDI (modelos técnicos - tModels) de diversos sistemas de identificação e categorização, que podem ser utilizados para identificar e categorizar registros UDDI.


5-              Vantagens e desvantagens

Vantagens:
  • Integração entre aplicações construídas em diferentes tecnologias;
  • Inteligível para o ser humano, o que facilita o desenvolvimento de novos aplicativos utilizando esta tecnologia;
  • Intuitiva, pois é descrita em linguagem natural com termos próximos aos utilizadas pela aplicação;
  • Precisa, pois a WSDL e o Schema garantem conformidade com os padrões estabelecidos entre provedores e requisitantes.

Desvantagens:
  • Extremamente verbosa, o que a torna menos produtiva que outras propostas como aqueles que utilizam, por exemplo, JSON.
  • Performance de uma aplicação que consome muitos Web Services é tipicamente inferior;
  • Os custos de integração e construção de Web Services nem sempre são baixos.



6-              Exemplo


Para publicar um serviço capaz de fornecer o WSDL completo e também consumir esse serviço de forma eficiente, é muito comum utilizarmos bibliotecas prontas. Existem diversas bibliotecas implementadas para realizar essa tarefa em diversas linguagens.

Para o PHP temos uma biblioteca já escrita chamada NUsoap. Faça download dessa biblioteca aqui: https://sourceforge.net/projects/nusoap/



a)                Adicione a biblioteca via require:


require 'lib/nusoap.php';


b)                Crie uma função que torne os dados disponíveis


function get_price($name){
     $products = [
          "book"=>20,
          "pen"=>10,
          "pencil"=>5
     ];
    
     foreach($products as $product=>$price){
          if($product==$name){
               return $price;
               break;
          }
     }
}



c)                Instancie o servidor, configure e execute:

$server = new nusoap_server(); // Instancia o NUSOAP

$server->configureWSDL("Exemplo de SOAP","urn:exemplosoap"); // Configure WSDL file

$server->register(
     "get_price", // name of function
     array("name"=>"xsd:string"),  // inputs
     array("return"=>"xsd:integer")   // outputs
);

$server->service(file_get_contents("php://input"));

Nenhum comentário

Conta pra mim sua opinião!

Fale comigo