INTEGRAÇÃO

DE
APLICAÇÕES

Jenifer Vieira Toledo

Cliente de web
service (JSP, PHP)
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

„„ Descrever o funcionamento de clientes para web service.

„„ Aplicar exemplos de clientes em web service.
„„ Validar o uso de clientes de web service com e sem Application Pro-
gramming Interfaces (APIs).

Introdução
Neste capítulo, você conhecerá os principais conceitos e termos utilizados
para o tratamento e a aplicação de web service. Além disso, conhecerá as
tecnologias XML, WSDL, SOAP, UDD, entre outras. Ainda, verá como obter
segurança na comunicação dos serviços e na integração de dados entre
diferentes sistemas. Por fim, verá como criar um web service e um cliente.

1 Principais conceitos de web service

Organizações das mais diversas áreas (p. ex., fabricantes, educadores, ban-
cários, serviços públicos e privados, comércio, indústrias, etc.) buscam cada
vez mais formas sistemáticas para identificar, gerenciar e integrar os dados
dos seus consumidores que estão disponíveis nos mais diversos meios de
comunicação. Com o surgimento de novos serviços web e a necessidade de
sistemas organizacionais, houve uma demanda por novas técnicas de comu-
nicação e integração de dados com web service (ABINADER; LINS, 2006;
CARDOSO, 2007).
2 Cliente de web service (JSP, PHP)

Um web service é um serviço com requisições e retornos de dados padro-

nizados utilizado para integrar aplicações baseadas na web por meio do uso de
XML (eXtensible Markup Language — Linguagem de Marcação Extensível,
em português), SOAP (Simple Object Access Protocol — Protocolo Simples de
Acesso a Objetos, em português), WSDL (Web Services Description Language
— Linguagem de Descrição de Serviços Web, em português) e padrões open
source, como UDDI (Universal Discovery Description and Integration —
Descrição, Localização e Integração Universais, em português). Ele possibilita
que novas aplicações possam ser integradas com sistemas e bases legadas ou
sistemas desenvolvidos em plataformas e linguagens diferentes (MCGOVERN
et al., 2003). A Figura 1, a seguir, apresenta a arquitetura de web service.

Sistema web Aplicação mobile iOS

legado

Banco de dados

Aplicação mobile
Android

Web service

Figura 1. Modelagem básica de comunicação entre sistemas multiplataformas.

 Cliente de web service (JSP, PHP) 3

Os web services trazem agilidade para os processos de desenvolvimento

de sistemas e eficiência na comunicação entre aplicações e serviços, além de
serem um serviço acessível a qualquer cliente com acesso à internet. Além
disso, eles permitem que toda e qualquer comunicação entre sistemas passe
a ser dinâmica e, principalmente, segura, podendo possuir camadas extras
de segurança, bem como ser independente de interação com os usuários
(CARDOSO, 2007).
Com a utilização de web service, uma aplicação pode requisitar outra para
efetuar tarefas simples ou complexas mesmo que as aplicações estejam em
servidores com SOs (sistemas operacionais) diferentes e tenham sido desen-
volvidas com linguagens de programação desiguais. Ou seja, os web services
tornam os seus recursos disponíveis, para que qualquer aplicação–cliente possa
operar e extrair os recursos fornecidos, garantindo uma grande flexibilidade
na integração entre várias aplicações.
Esses serviços são identificados por um endereço URI (Uniform Resource
Identifier — Identificador Universal de Recurso, em português), podendo ser
descritos e definidos usando XML. Um dos motivos que os tornam atrativos é
o fato de esse modelo ser baseado em tecnologias padronizadas, em particular
XML e HTTP (HyperText Transfer Protocol — Protocolo de Transferência de
Hipertexto, em português). Os web services são utilizados para disponibilizar
serviços interativos na web, podendo ser acessados por outras aplicações por
meio do uso do protocolo SOAP, por exemplo.
De modo geral, o objetivo dos web services é permitir a comunicação de
aplicações através da internet. Essa comunicação é realizada com a finali-
dade de facilitar a EAI (Enterprise Application Integration — Integração de
Aplicações Corporativas, em português), isto é, a integração das aplicações
de uma ou mais empresas (ABINADER; LINS, 2006). Desse modo, há uma
interoperabilidade entre a informação que circula em uma organização nas
diferentes aplicações, como, por exemplo, o comércio eletrônico com os seus
clientes e fornecedores de serviços.
Além da interoperabilidade entre as aplicações, a EAI permite definir um
workflow (fluxo de trabalho) entre as aplicações e pode constituir uma alter-
nativa aos ERP (Enterprise Resource Planning — Planejamento de Recursos
Empresariais, em português). Com um workflow, é possível otimizar e controlar
os processos e as tarefas de uma determinada organização, pois ele força a
padronização da troca de informações entre os sistemas que o utilizam, e todo
processo de escrita e leitura de dados passa pelo mesmo serviço. Mesmo com
todas essas facilidades, é possível também pensar em segurança nessa nova
camada de serviço.
4 Cliente de web service (JSP, PHP)

Segurança
Antigamente, muitas empresas temiam prover funcionalidades na internet,
devido ao receio de expor seus dados. Todavia, com o advento dos web services,
as empresas passaram a publicar seus serviços de forma simples e isolada da
base de dados. As questões mais relevantes para a segurança dos web services
são listadas a seguir.

„„ Autenticidade: ter a certeza de que uma transação dos web services

ocorreu entre o servidor e o seu cliente.
„„ Privacidade: as mensagens trocadas entre o servidor e o cliente não
podem ser interceptadas por uma pessoa não autorizada.
„„ Integridade: as mensagens enviadas pelo servidor ao cliente e vice-
-versa devem permanecer inalteradas.

A seguir, serão apresentados os principais mecanismos de segurança que

viabilizam o atendimento das questões mencionadas.

Secure Socket Layer (SSL)

O padrão SSL (Secure Socket Layer — Camada de Soquete Segura, em portu-

guês) é aplicado a pequenos dispositivos, oferecendo autenticação, integridade
de dados e privacidade de serviços. O SSL torna possível enviar informações
confidenciais por meio de um mecanismo de segurança SSL sob HTTP, também
conhecido como HTTPS (HyperText Transfer Protocol Secure — Protocolo de
Transferência de Hipertexto Seguro, em português). Esse mecanismo protege
informações confidenciais e é fácil de ser configurado, pois é aplicado como
uma instalação de certificado em um servidor.
Contudo, o HTTPS tem como desvantagem ser mais lento do que as tran-
sações HTTP não cifradas, por não ser adequado para taxas de transferências
elevadas de dados. Em virtude de ser um mecanismo de proteção no nível
de transporte da camada de rede, ele apresenta restrições para ser aplicado
em aplicações web services, pois o SSL não permite a criptografia de parte
da informação, nem o uso de sessões seguras entre mais de duas partes, uma
vez que seu funcionamento se baseia em uma arquitetura de transporte fim a
fim, desde o início da transação na rede até a chegada ao cliente de destino.
 Cliente de web service (JSP, PHP) 5

XML Signature

A definição XML Signature (Assinatura XML) é uma iniciativa conjunta da

Internet Engineering Task Force (IETF) e do World Wide Web Consortium
(W3C) para especificar uma sintaxe XML e as regras de processamento para a
criação e a representação de assinatura digital. Ao contrário de outras normas
de assinaturas digitais, as vantagens na utilização da XML Signature estão
baseadas na independência da linguagem de programação, na fácil interpre-
tação humana e na independência do fabricante. Além disso, essa tecnologia
permite assinar digitalmente subconjuntos de um documento XML.

XML Encryption

A iniciativa XML Encryption (Criptografia XML) especifica um processo

para cifra de dados e sua representação em formato XML. Os dados podem
ser arbitrários (incluindo um documento XML), elementos XML ou conteúdos
de elementos XML. Um documento XML que utiliza a XML Encryption
pode ser visto por qualquer utilizador, mas apenas o proprietário da chave de
descodificação conseguirá compreender o conteúdo codificado.

Web Services Security (WS-Security)

O padrão WS-Security (Web Services Security — Segurança de Serviços

Web, em português) é uma iniciativa conjunta de empresas, como Microsoft,
IBM e Verisign, destinada ao uso da XML Signature e da XML Encryption
para fornecer segurança às mensagens SOAP. O WS-Security é um esforço
destinado a fazer os web services trabalharem melhor em um ambiente glo-
bal. Além disso, ele também inclui alguns importantes componentes, como
encaminhamento, confiança e tratamento de transações.

Security Assertion Markup Language (SAML)

O SAML (Security Assertion Markup Language — Linguagem de Marcação

para Autorização de Segurança, em português) é um padrão emergente para
a troca de informações sobre autenticação e autorização. Ele soluciona um
importante problema para as aplicações da próxima geração: a possibilidade
de os utilizadores transportarem seus direitos entre diferentes web services,
o que é importante para aplicações que tencionam integrar um número de web
services para formar uma aplicação unificada.
6 Cliente de web service (JSP, PHP)

Tecnologias utilizadas
Para a representação e a estruturação dos dados nas mensagens recebidas/
enviadas, utiliza-se o formato XML. As chamadas às operações, incluindo
os parâmetros de entrada/saída, são codificadas no protocolo SOAP (baseado
em XML). Os serviços (p. ex., operações, mensagens, parâmetros, etc.) são
descritos utilizando a linguagem WSDL, e o processo de publicação/pesquisa/
descoberta de web service utiliza o protocolo UDDI (HANSEN, 2007).

eXtensible Markup Language (XML)

O formato XML é a base em que os web services são construídos, pois fornece
a descrição, o armazenamento e o formato da transmissão para trocar os dados
através dos web services. A sintaxe de XML utilizada nas tecnologias dos web
services especifica como os dados são representados genericamente, definindo
como e com que qualidade de serviço esses dados são transmitidos, bem como
de que forma os serviços são publicados e descobertos.

Simple Object Access Protocol (SOAP)

O SOAP baseia-se em uma invocação remota de um método e, portanto, neces-

sita especificar o endereço do componente, o nome do método e os argumentos
para ele. Esses dados são formatados em XML, com determinadas regras, e
enviados normalmente por HTTP para o componente. Contudo, o SOAP 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. Esse aspecto é extremamente
importante, pois permite que tanto o serviço como o cliente que invoca o
serviço utilizem aplicações desenvolvidas sobre diferentes linguagens de
programação (KALIN, 2013).
Desse modo, o SOAP tornou-se uma norma aceita para se utilizar com
web service, uma tecnologia construída com base em XML e HTTP. Por meio
dele, pretende-se garantir a interoperabilidade e a 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, ele providencia o transporte de dados para os web services.
 Cliente de web service (JSP, PHP) 7

Em relação à web, o SOAP é um protocolo de RPC (Remote Procedure

Call — Chamada de Procedimento Remoto, em português) que funciona,
em geral, sob HTTP, 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 utilizar HTTP para
pedir uma página HTML para ser visualizada em um browser, o SOAP envia
uma mensagem de XML através do pedido HTTP e recebe uma resposta,
quando existir, através do HTTP. Para assegurar corretamente a transmissão
da mensagem de XML, o servidor de HTTP, como o Apache ou o IIS (Internet
Information Server — Servidor de Informação da Internet, em português) da
Microsoft, recebe mensagens SOAP e deve validar e compreender o formato
do documento XML, definido na especificação SOAP v1.1 (KALIN, 2013).

Web Services Description Language (WSDL)

O padrão WSDL é baseado em XML para descrever o serviço e traz os métodos

do web service. Ele funciona como uma espécie de “TypeLibrary” do web
service, além de ser utilizado para a validação das chamadas dos métodos.
O WSDL é uma especificação desenvolvida pelo W3C que permite descrever
os web services segundo um formato XML. Além disso, ele é 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 utilizados.
No entanto, é comum utilizar o MIME (Multipurpose Internet Mail Exten-
sions — Extensões Multifunção para Mensagens de Internet, em português)
e o HTTP via SOAP.
O WSDL também descreve os serviços disponibilizados à rede através
de uma semântica XML, providenciando a documentação necessária para se
chamar um sistema distribuído e o procedimento necessário para que essa
comunicação se estabeleça. Enquanto o SOAP especifica a comunicação
entre um cliente e um servidor, o WSDL descreve os serviços oferecidos
(HANSEN, 2007).

Universal Discovery Description and Integration (UDDI)

O UDDI é um protocolo desenvolvido para a organização e o registro de web

services (MCGOVERN et al., 2003).
8 Cliente de web service (JSP, PHP)

Web Services Interoperability (WS-I)

O consórcio WS-I (Web Services Interoperability — Interoperabilidade de

Serviços Web, em português) garante a integração entre os web services para
possibilitar que os web services possam “conversar entre si”.

JavaScript Object Notation (JSON)

O JSON (JavaScript Object Notation — Notação de Objetos JavaScript, em

português) é um formato leve para intercâmbio de dados computacionais.
Apesar do seu nome, ele não requer o uso de JavaScript exclusivamente.
A simplicidade do JSON tem resultado em seu uso difundido, princi-
palmente como uma alternativa para XML em AJAX. Nesse contexto, uma
das vantagens reivindicadas do JSON sobre o XML como um formato para
intercâmbio de dados é o fato de ser mais fácil escrever em um analisador
JSON. Em JavaScript, o JSON pode ser analisado trivialmente utilizando-se
a função eval(). Isso foi importante para a aceitação do JSON dentro da
comunidade AJAX, devido à presença desse recurso de JavaScript em todos
os navegadores web atuais.
Em geral, o JSON é utilizado em ambientes em que o tamanho do fluxo
de dados entre o cliente e o servidor é de suma importância (daí seu uso por
Google, Yahoo!, etc., os quais servem milhões de usuários), em que a fonte
dos dados pode ser explicitamente confiável e em que a perda dos recursos
de processamento XSLT (eXtensible Stylesheet Language Transformations —
Linguagem de Folhas de Estilo Extensível para Transformações, em português)
no lado cliente para a manipulação de dados ou a geração da interface não é
uma consideração.
Embora o JSON seja frequentemente posicionado em confronto com o
XML, não é incomum ver tanto o JSON como o XML sendo utilizados na
mesma aplicação. Por exemplo, uma aplicação no lado cliente, a qual integra
dados do Google Maps com dados atmosféricos através de SOAP, requer
suporte para ambos os formatos de dados.
Existe um crescente suporte para o JSON por meio do uso de pequenos
pacotes de terceiros. A lista de linguagens suportadas inclui ActionScript,
C/C++, C#, ColdFusion, Java, JavaScript, OCaml, Perl, PHP, ASP 3.0, Python,
Rebol, Ruby e Lua.
 Cliente de web service (JSP, PHP) 9

2 Criação e utilização de web service

Dada a criação e a publicação de um web service, tem-se a necessidade de
testá-lo, por meio de aplicações–cliente genéricas já desenvolvidas ou com a
criação de um próprio serviço de teste.
Agora, veremos como ocorre a construção de um web service e um cliente
para poder testá-lo. Para isso, utilizaremos a linguagem PHP nativa em sua
versão 7. Primeiro, é preciso implementar o serviço:

<?php
/* Criamos a instância do Servidor SOAP.
* A opção uri indica o namespace do web service no servidor.
*/
$options = array('uri' => 'http://localhost/soap/server/');
/*
*O primeiro parâmetro null indica que estamos trabalhando com
um web service no modo não WSDL.
*/
$server = new SoapServer(null, $options);
/*
* Informamos a classe em que o web service irá se basear.
* Podemos usar também o método addFunction() para adicionar
* funções em nosso web service.
*/
$server->setClass('ServidorSoapTeste');
/*
* O método handle() processa a requisição SOAP e envia uma
resposta
* para o cliente.
*/
$server->handle();
/*
* A classe ServidorSoapTeste será disponibilizada em nosso
* web service. Portanto, temos disponíveis no web service
os métodos
* RetornaMensagem e SomaValores.
*/
10 Cliente de web service (JSP, PHP)

class ServidorSoapTeste {
public function RetornaMensagem($nome)
{
return "Boas Vindas, $nome !";
}
public function SomaValores($a, $b)
{
return "O valor da soma é: " + $a + $b;
}
}
?>

Com a implementação do serviço, é preciso possuir um cliente para po-

der testar e consumir os métodos implementados. Com isso, criaremos uma
aplicação web também em PHP para poder testar:

<?php
/*
* Essa é a instância de nosso cliente para consumo do web
service.
* Definimos a localização e o namespace do servidor de web
service.
* Passando null no primeiro parâmetro do construtor indicamos
que o web service irá trabalhar no modo não WSDL.
*/
$options = array(
'location' => 'http://localhost/soap/server/WebServer.php',
'uri' => 'http://localhost/soap/server/'
);
$client = new SoapClient(null, $options);
// No Objeto $client podemos usar os métodos da classe
ServidorSoapTeste
// É esperado um retorno semelhante a "Boas Vindas, Novo Aluno!".
echo $client->mensagem('Novo Aluno') . "<br />";
// Deverá retornar "O valor da soma é: 8"
echo $client->soma(3, 5) . "<br />";
?>
 Cliente de web service (JSP, PHP) 11

Essa implementação em PHP foi feita de maneira simplificada para de-

monstrar o desenvolvimento e como funciona a estrutura da implementação,
mas isso não quer dizer que não existam outras formas de exemplificar.

3 Conceito e uso de web service e APIs

A API (Application Programming Interface — Interface de Programação de
Aplicações, em português) é definida como uma coleção de rotinas e padrões
estabelecidos por um sistema, fornecendo acesso externo às suas funciona-
lidades, não necessariamente por meio de acesso à implementação, mas de
maneira abstrata, independente de programação.
De modo geral, a API é definida como uma biblioteca que fornece um
conjunto de funções para sistemas utilizadores. Na prática, um bom exemplo
de API é o funcionamento de um SO de dispositivo móvel, como Android ou
iOS. Dentro da sua implementação, tem-se funções internas (p. ex., acesso ao
hardware de câmera, acelerômetro, sensor de brilho, áudio, etc.), bem como
outras chamadas mais interativas com o usuário (p. ex., chamada de um atalho
para abrir um aplicativo, alterar o brilho da tela, reproduzir mídias, etc.).
No entanto, as APIs mais comuns são os chamados plugins de aplicações.
Por exemplo, ao desenvolver um sistema baseado em componentes, utilizam-se
bibliotecas já com validação de dados, formatação de valores, entre outros,
constituindo exemplos práticos de utilização de API.

Web service e API

É possível considerar um web service como uma API, contudo, nem toda API
é considerada um web service. O web service é uma coleção de protocolos
e padrões de código aberto utilizada para a troca de dados entre sistemas ou
aplicativos na internet. Em contrapartida, a API é uma interface de software
que permite que dois aplicativos interajam entre si sem o envolvimento do
usuário e de maneira independente da internet. O Quadro 1, a seguir, apresenta
algumas semelhanças e diferenças entre web service e APIs.
12 Cliente de web service (JSP, PHP)

Quadro 1. Principais diferenças no funcionamento de web service e APIs.

Web service API

Interação entre duas ou mais máquinas Interação entre duas ou mais

em uma rede. aplicações.

Utiliza SOAP, REST e XML-RPC como um Pode usar qualquer meio de

meio de comunicação. comunicação.

Envolve a chamada do sistema. Pode renderizar o formulário em

uma linha, em elementos um por
um, elemento OU decorador OU
erro separadamente.

Pode não conter um conjunto completo Consiste em um conjunto com-

de especificações e, às vezes, pode não pleto de regras e especificações
ser capaz de executar todas as tarefas que um programa de software deve
possíveis a partir de uma API completa. seguir, a fim de facilitar a interação.

Os web services são serviços disponíveis
na internet. Você pode ligar para esses
serviços e obter informações em seu
aplicativo sem saber como ele funciona.
Por exemplo, os web services meteoro-
lógicos fornecem informações sobre o
clima de uma cidade.
Uma API é uma coleção de classes
que fornece algumas funcionali-
dades, como a API do Google, que
fornece pesquisa nesse mecanismo
de busca.

Portanto, pode-se dizer que os modelos de web services e APIs são distintos,
mas podem se complementar, dependendo dos seus cenários de aplicação.

É possível dizer que um web service de consulta de CEP para cadastramento de um

endereço em um formulário é uma API, pois se caracteriza como tal e está publicado
na internet. Em contrapartida, na mesma aplicação, ao clicar em um campo de data,
é aberta uma janela com o calendário. Ou seja, o campo possui uma API de um plugin
que fornece esse serviço, porém é uma chamada interna da própria programação do
formulário, por isso não pode ser considerada um web service.
 Cliente de web service (JSP, PHP) 13

ABINADER, J. A.; LINS, R. D. Web services em Java. Rio de Janeiro: Brasport, 2006. 288 p.
CARDOSO, J. Semantic web services: theory, tools and applications. Hershey: IGI Global,
2007. 372 p.
HANSEN, M. D. SOA using Java™ web services. Upper Saddle River: Pearson Education,
2007. 574 p.
KALIN, M. Java web services: up and running. 2. ed. Sebastopol: O’Reilly, 2013. 360 p.

Leituras recomendadas
LECHETA, R. R. Web services RESTful: aprenda a criar web services RESTful em Java na
nuvem do Google. São Paulo: Novatec, 2015. 432 p.
SAUDATE, A. SOA aplicado: integrando com web services e além. São Paulo: Casa do
Código, 2014. 326 p.