2ª edição

Daniel Adorno Gomes

Novatec
Copyright © 2010, 2014 da Novatec Editora Ltda.

Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998.

É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,
sem prévia autorização, por escrito, do autor e da Editora.

Editor: Rubens Prates

Editoração eletrônica: Carolina Kuwabata
Capa: Victor Bittow
Revisão gramatical: Marta Almeida de Sá

ISBN: 978-85-7522-356-7 MP20140929

Histórico de impressões:
Outubro/2014 Segunda edição
Junho/2013 Segunda reimpressão
Março/2011 Primeira reimpressão
Janeiro/2010 Primeira edição (ISBN: 978-85-7522-218-8)

Novatec Editora Ltda.

Rua Luís Antônio dos Santos 110
02460-000 – São Paulo, SP – Brasil
Tel.: +55 11 2959-6529
Email: novatec@novatec.com.br
Site: www.novatec.com.br
Twitter: twitter.com/novateceditora
Facebook: facebook.com/novatec
LinkedIn: linkedin.com/in/novatec
capítulo 1

Introdução aos web services

Passados quase cinco anos do lançamento da primeira edição deste livro,

os web services continuam sendo uma tecnologia em evidência, pois ainda
é o principal meio de integração entre sistemas, independentemente da
plataforma de hardware e software utilizados, e também pelo contexto da
mobilidade que vivemos atualmente. Em geral, a troca de informações entre
aplicativos móveis, desenvolvidos para smartphones e tablets, e servidores,
é realizada com a utilização de web services.
Neste capítulo, veremos as principais características dessa tecnologia, de
forma que, posteriormente, essa introdução possa servir de alicerce para os
demais capítulos, em que trabalharemos somente a prática.
Comecemos, então, por sua definição.

1.1 Afinal, o que são web services?

Os web services surgiram como uma evolução dos modelos de computação
distribuída, muito utilizados na segunda metade da década de 90. Entre
essas tecnologias podemos citar o RMI, o DCOM e o CORBA. No entanto
essas tecnologias tiveram sucesso na integração de softwares em ambientes
de redes locais e homogêneos. Quando a Internet avançou para o mercado
corporativo, surgiu também a necessidade de integrar aplicações além das
redes locais e, por consequência, em ambientes heterogêneos. É nesse con-
texto que surge a tecnologia que chamamos de web services, proveniente
de um consórcio formado por grandes empresas como IBM, Microsoft
e BEA, entre outras pertencentes ao W3C. Unindo as tecnologias para o
desenvolvimento de aplicações web disponíveis na época, como JSP, ASP e
PHP ao XML, elas criaram o padrão para o desenvolvimento de web services
denominado SOAP (Simple Object Access Protocol).

13
14 Web Services SOAP em Java

De forma bastante genérica, podemos dizer que os web services são

uma tecnologia de integração de sistemas empregada principalmente em
ambientes heterogêneos. Traduzindo: utilizando essa tecnologia, podemos
desenvolver softwares ou componentes de software capazes de interagir, seja
enviando ou recebendo informações, com outros softwares, não importando
a linguagem de programação em que estes foram desenvolvidos, o sistema
operacional em que rodam e o hardware que é utilizado. A única premissa
é que, para se comunicar com os web services SOAP, a troca de dados tem
de ser feita no formato XML.
Colocando a explicação anterior em termos práticos, imagine que você
está desenvolvendo uma aplicação web que corresponde a uma loja virtual.
Uma das exigências de seu cliente é que a aplicação seja desenvolvida em
Java, e outra é que os compradores possam consultar quanto terão de pagar
de frete mesmo antes de fecharem suas compras. Desenvolver a aplicação em
Java não será problema, mas como podemos calcular o frete? Sabendo que
todos os produtos vendidos por seu cliente são entregues via Sedex, sabemos
que essa informação deverá ser fornecida pelos Correios. Nesse caso, não
teremos problemas também, e sabe por quê? Os Correios disponibilizam
um web service para o cálculo do valor de serviço de entrega. Basta que os
desenvolvedores façam uma chamada ao web service, fornecendo alguns
parâmetros como CEP de origem, CEP de destino, tipo de serviço (Sedex) e
peso do produto. Essas informações devem ser passadas ao web service em
formato XML, e ele nos enviará a resposta, contendo o prazo de entrega e
o preço do frete, também no formato XML. Viu como é fácil?
Então um web service é uma espécie de método? Recebe valores na
forma de parâmetros, executa um determinado processamento com eles e
devolve um resultado? Basicamente, sim. Simplificando, essa é a maneira
como trabalharemos com os web services. Mais adiante, ainda neste capítulo,
nos aprofundaremos nessa explicação.
Agora, pensemos em outra questão prática. Imagine que outro
cliente solicite que você desenvolva uma aplicação desktop, utilizando
Microsoft .NET, que seja capaz de calcular o frete de entregas realizadas
via Sedex. O que você faria nesse caso? A mesma coisa que fez no problema
anterior: utilizaria o web service disponibilizado pelos Correios, fornecendo
as informações necessárias no formato XML e recebendo a resposta também
no mesmo formato.
Capítulo 1 ▪ Introdução aos web services 15

É importante observar uma questão. Nos exemplos anteriores, os

Correios é que desenvolveram o web service. E nós seríamos responsáveis
pelo desenvolvimento do software cliente, o qual iria utilizar ou fazer cha-
madas ao web service dos Correios.
Nos exemplos do livro, seremos responsáveis pelo desenvolvimento de
ambas as partes, tanto dos web services quanto dos clientes que irão utilizá-los.

1.2 Padrões para o desenvolvimento de web services

Atualmente, existem dois padrões para o desenvolvimento de web services.
O padrão SOAP, citado no início do capítulo, e o padrão REST ou RESTfull.
O livro abordará somente o desenvolvimento de web services com a utili-
zação do padrão SOAP.

1.3 Web services SOAP

A figura 1.1 mostra os componentes envolvidos e a sequência em que ocorre
uma chamada a um web service SOAP. Veja:

Figura 1.1 – Arquitetura para web services SOAP criada pelo W3C.
16 Web Services SOAP em Java

Inicialmente, vejamos os componentes exibidos no esquema anterior:

• SOAP (Simple Object Access Protocol): é o protocolo-padrão para transmis-
são de dados dentro da arquitetura de web services proposta pelo
W3C. O SOAP é um protocolo baseado no XML e segue o modelo
“REQUEST-RESPONSE” do HTTP.
• WSDL (Web Services Description Language): é um arquivo do tipo XML, cuja
finalidade é descrever detalhadamente um web service. Essa des-
crição especifica as operações que compõem o web service e define
de forma clara como deve ser o formato de entrada e saída de cada
operação. Veja na figura 1.1 que o WSDL pode ficar armazenado tanto
no “Provedor de web services” quanto no UDDI.

Listagem 1.1 – Trecho de um arquivo WSDL

<message name="adicionarProdutoResponse">
<part name="parameters" element="tns:adicionarProdutoResponse"/>
</message>
<message name="excluirProduto">
<part name="parameters" element="tns:excluirProduto"/>
</message>
<message name="excluirProdutoResponse">
<part name="parameters" element="tns:excluirProdutoResponse"/>
</message>
<message name="atualizarProduto">
<part name="parameters" element="tns:atualizarProduto"/>
</message>
<message name="atualizarProdutoResponse">
<part name="parameters" element="tns:atualizarProdutoResponse"/>
</message>
<message name="listarProdutos">
<part name="parameters" element="tns:listarProdutos"/>
</message>
<message name="listarProdutosResponse">
<part name="parameters" element="tns:listarProdutosResponse"/>
</message>
<message name="localizarProduto">
<part name="parameters" element="tns:localizarProduto"/>
</message>
<message name="localizarProdutoResponse">
Capítulo 1 ▪ Introdução aos web services 17

<part name="parameters" element="tns:localizarProdutoResponse"/>

</message>
<portType name="CadastrarProdWs">
<operation name="adicionarProduto">
<input message="tns:adicionarProduto"/>
<output message="tns:adicionarProdutoResponse"/>
</operation>
<operation name="excluirProduto">
<input message="tns:excluirProduto"/>
<output message="tns:excluirProdutoResponse"/>
</operation>
<operation name="atualizarProduto">
<input message="tns:atualizarProduto"/>
<output message="tns:atualizarProdutoResponse"/>
</operation>
<operation name="listarProdutos">
<input message="tns:listarProdutos"/>
<output message="tns:listarProdutosResponse"/>
</operation>
<operation name="localizarProduto">
<input message="tns:localizarProduto"/>
<output message="tns:localizarProdutoResponse"/>
</operation>
</portType>

• UDDI (Universal Description, Discovery and Integration): o UDDI é um mecanismo

que visa atender tanto o cliente de web services quanto o provedor.
Ele tem de fornecer ao provedor de web services meios para que os
web services sejam registrados e publicados. Isso permitirá que os
web services sejam pesquisados e localizados pelos clientes. Outra
finalidade do UDDI é o armazenamento de arquivos WSDL.
• Cliente: é um software que consumirá web services, ou seja, utilizará
as operações disponibilizadas por determinado web service. No en-
tanto é importante que se deixe claro que, na figura 1.1, o cliente está
sendo representado em várias etapas de seu ciclo de vida. Ali, vemos
desde sua preexistência, quando um determinado desenvolvedor
obtém o arquivo WSDL, até o momento em que o software já está
em operação, fazendo solicitações e recebendo os resultados dos web
services, ambos no formato XML.
18 Web Services SOAP em Java

• Provedor de web services: esse componente corresponde a um servidor

de aplicações ou um web container, conforme o caso, em que o web
service ficará armazenado. Ele pode armazenar também os arquivos
WSDL, como mostra a figura 1.1.
Antes de avançarmos na explicação, é importante reforçar que toda essa
arquitetura tem como base a linguagem XML. Portanto todas as informações
que são trocadas entre qualquer uma das partes são enviadas e recebidas
por meio de mensagens no formato XML.
Continuando, vejamos agora como os componentes exibidos na figura
1.1 se integram. Os números referenciados na figura serão utilizados para
descrever a sequência das operações:
1. Registra e publica o web service: os web services ficam armazenados junto de
seus descritores, os arquivos WSDL, em provedores de web services.
Quando criamos um web service, o disponibilizamos para uso em
um provedor de web services. No entanto, para que esse web service
seja utilizado por algum cliente, ele e seu WSDL precisam ser localiza-
dos, ou seja, o cliente precisa obter o endereço do web service ou seu
URI (Uniform Resource Identifier), que é um endereço semelhante
ao já conhecido URL (Uniform Resource Locator). Assim, depois de
criarmos e armazenarmos um web service em um provedor, devemos
registrá-lo e publicá-lo em um diretório de registro de web services,
também conhecido como UDDI.
2. Obtém informações sobre o web service: quando um desenvolvedor de
software precisar utilizar um web service, inicialmente ele pesquisará
em diretórios de registro de web services (UDDI) pelo tipo de web
service que deseja. Por exemplo, um web service que efetue validação
de CPF ou um que retorne a cotação do dólar. A arquitetura do W3C
inclui recursos de pesquisa e de localização de web services, visando
à possibilidade de diversos web services, de diversos fornecedores de
software dispobilizarem a mesma operação. Dessa forma, o desen-
volvedor necessita primeiro obter a informação que dirá onde está
o web service desejado e seu respectivo arquivo WSDL. Em outras
palavras, o UDDI fornecerá ao desenvolvedor o endereço (URI) do
web service e de seu WSDL.
Capítulo 1 ▪ Introdução aos web services 19

3. Efetua download do WSDL: assim que o desenvolvedor obtém os URIs do

web service e de seu descritor (WSDL), ele pode efetuar o download
do arquivo WSDL e, em seguida, efetivamente utilizar o web service
desejado. É importante lembrarmos que o arquivo WSDL pode estar
disponível para download tanto no UDDI quanto no provedor de web
services. Obtidos o arquivo WSDL e o URI do web service, o desen-
volvedor poderá criar um software cliente que fará uma chamada ao
web service e obterá uma resposta, conforme o serviço solicitado.
4. Envia solicitação XML: o software cliente fará chamadas ao web service, por
meio de seu URI, enviando ao web service solicitações no formato XML.
5. Recebe resposta XML: o web service receberá a solicitação anterior, efetuará
um determinado tipo de processamento e produzirá um resultado.
O web service pode ou não enviar o resultado do processamento ao
software solicitante, como uma resposta, no formato XML.
A explicação dada anteriormente se baseia na especificação criada pelo
W3C. No entanto o funcionamento dos web services na prática não ocorre
exatamente como foi especificado, apesar de ser extremamente plausível.
Normalmente, a figura do UDDI não existe. Isso faz com que a comunicação
entre o cliente e o provedor de web services ocorra sem intermediações. Veja:

Figura 1.2 – Funcionamento prático dos web services SOAP.

Outra questão prática que não pode ser esquecida refere-se ao protocolo
sobre o qual as mensagens SOAP trafegam. A arquitetura projetada pelo
W3C especifica que as solicitações e respostas XML possam trafegar por
meio de qualquer protocolo como HTTP, FTP, SMTP, TCP puro etc. Mas
o que vemos na prática é a utilização do XML trafegando somente sobre
HTTP. Isso se deve ao fato de o HTTP ser um protocolo dominante na web
20 Web Services SOAP em Java

já há muito tempo. É suportado por praticamente todo tipo de plataforma

de software/hardware maduro, confiável e sem problemas com restrições
por firewalls.
Existem duas formas de envio de mensagens para que um cliente possa
efetuar solicitações a um web service:
• One-Way Messaging: essa é uma forma de envio de mensagens unilateral.
Nela o cliente envia a solicitação sem se preocupar com a resposta.
O web service executará o processamento solicitado e não enviará
resposta ao cliente.

Figura 1.3 – One-Way Messaging.

• Request-Response Messaging: nessa forma, o envio de mensagens é bilateral.

O cliente faz uma solicitação ao web service, que executa um proces-
samento qualquer, ao final do qual envia o resultado ao cliente. Nesse
caso, podemos trabalhar tanto de forma síncrona como assíncrona.

Figura 1.4 – Resquest-Response Messaging.

Ok! Chegamos ao fim do primeiro capítulo do livro.

Agora, vamos colocar a mão na massa e transformar os conceitos apre-
sentados aqui em software.
Espero que você goste do que veremos adiante.