A Estrutura de um Web Service

A Estrutura de um Web Service

Paulo Vitor Antonini Orlandin
paulovitor_e@hotmail.com

Resumo

Atualmente, o Serviço Web é a solução mais utilizada para integração entre
sistemas, pois apresenta vantagens como independência de plataforma, baixo
acoplamento e interoperabilidade entre aplicações. Além disso, é uma tecnologia
barata, pois se baseia em padrões abertos da Internet. Com base nisto este trabalho
apresenta a estrutura básica, tecnologias e a forma de funcionamento de um Serviço
Web. Também são apresentadas características positivas e negativas desta
tecnologia.

Palavras chave: Serviços Web. WSDL. UDDI. XML. Web Service. SOAP.

1. Introdução

Com a grande necessidade de integração entre sistemas computacionais que
na maioria das vezes são heterogêneos, e que normalmente não se comunicam por
falta de um padrão, surgiu o conceito de Serviços Web.
Para que seja possível a integração de sistemas e aplicações diferentes a
utilização do Simple Object Access Protocol (SOAP)1 se torna indispensável. Graças
a esta tecnologia a troca de informações entre novas e antigas aplicações se torna
possível, bem como integração entre aplicações desenvolvidas em plataformas
diferentes. Cada aplicação pode ter sua própria linguagem, que é traduzida para o
formato XML2, formato em que as mensagens são enviadas e recebidas (BOOTH et
al., 2004).

Um serviço que esteja disponível na Internet se comunicando de forma
padronizada utilizando XML, provendo interoperabilidade entre sistemas e apoiando-
se sobre os protocolos da Internet é um Serviço Web (BOOTH et al., 2004).

1
Service Oriented Architecture (SOA)
2
Disponível em <http://www.w3.org/XML/>. Acesso em: 25/02/2009.

1

As mensagens recebidas e enviadas são estruturadas como documentos
XML, que são encapsulados pelo protocolo SOAP3 e transportados via HTTP. A
linguagem WSDL4 é utilizada para descrever os serviços, que são: publicados,
procurados, descobertos e divulgados utilizando o protocolo UDDI5 (BOOTH et al.,
2004).

Atualmente o método mais utilizado por quem busca integrar suas aplicações
é uma arquitetura SOA baseada em Serviços Web. SOA é uma arquitetura de
software cujo princípio fundamental é que as funcionalidades implementadas pelas
aplicações devem ser disponibilizadas na forma de serviços. É um paradigma de
desenvolvimento de software cujos demais objetivos são: buscar por flexibilidade,
reutilização, fraco acoplamento e dinamismo na localização de serviços.

O modelo atual de arquitetura SOA é composto por três entidades:
Consumidor, Provedor, e Registrador de serviços.

• Provedor: Responsável pela descrição de um serviço.
Esta descrição é um documento WSDL que contém várias informações
do serviço, como por exemplo, informações sobre parâmetros, end
point, dados do criador. Também é encarregado de publicar os
serviços em uma entidade registradora.

• Consumidor: Responsável por obter o documento WSDL
do serviço desejado. Posteriormente, utilizar as informações fornecidas
por este documento fazer a ligação com o provedor, invocando um
Serviço Web.

• Registrador: Entidade responsável por armazenar as
informações disponibilizadas pelos provedores em um diretório. É
nesta entidade que o consumidor procura por um serviço.

Atualmente a maioria das empresas vem adotando os Serviços Web em
busca de interoperabilidade para suas aplicações. Além disso, os Serviços Web
podem trazer eficiência na comunicação interna de uma empresa e assim agilizando
os processos da mesma.

3
Disponível em < http://www.w3.org/TR/soap>. Acesso em: 25/02/2009.
4
Disponível em < http://www.w3.org/TR/wsdl>. Acesso em: 25/02/2009.
5
Disponível em < http://uddi.xml.org/>. Acesso em: 27/02/2009.

2

2. Serviços Web

Antes da criação da World Wide Web (WWW6) por Tim Berners-Lee no fim da
década de 80, um sistema distribuído integrava algumas dezenas, ou no máximo,
algumas centenas de computadores.

Com a criação da WWW aplicações distribuídas se popularizaram muito, mas
ainda havia um grande problema relacionado a comunicação entre sistemas
diferentes, que apenas se comunicavam através de uma ponte de software.

Uma solução para este problema foi a criação dos Serviços Web, pois utilizam
tecnologias padrões da Internet como por exemplo, HTTP7 e XML, para prover
comunicação entre um sistema e outro. Esta é a grande vantagem em se utilizar
Serviços Web em comparação com outras tecnologias de comunicação como
CORBA8, Java RMI9 e DCOM10, pois com estas há a necessidade em se utilizar
protocolos de comunicação e formatos de dados que ambos os sistemas entendam.

Outro problema relacionado a essas tecnologias, é que sendo necessária a
comunicação entre dois sistemas distintos, será necessária a criação de pontes.
Ponte é um software que converte o protocolo e os dados da plataforma de partida
para um formato que a plataforma alvo entenda.

A tecnologia dos Serviços Web proporciona grandes benefícios como
independência de plataforma de hardware e software, baixo acoplamento e
interoperabilidade entre aplicações. Um computador X utilizando Windows rodando
uma aplicação A, consegue trocar informações com um computador Y utilizando
Linux rodando uma aplicação B, desde que estas aplicações sigam rigorosamente
as especificações de Serviços Web. Isso se deve pois os serviços são baseados no
protocolo HTTP e em especificações XML como WSDL e SOAP.

Devido as vantagens citadas anteriormente é que os Serviços Web vem se
consolidando como base das novas iniciativas de negócios eletrônicos em diversos
mercados.

6
Disponível em < http://www.w3.org/WWW/>Acesso em: 12/03/2009.
7
Hypertext Transfer Protocol.
8
Common Object Request Broker Architecture (CORBA).
9
Java Remote Method Invocation (RMI).
10
Distributed Component Object Model (DCOM).

3

Um Serviço Web é um software concebido para prover
interoperabilidade máquina-a-máquina através de uma rede. Tem
uma interface descrita em um formato processável por máquina
(especificamente WSDL). Outros sistemas interagem de uma forma
prescrita por sua descrição utilizando mensagens SOAP e
transmitidas utilizando HTTP com uma serialização XML (BOOTH et
al., 2004).

3. Service Oriented Architecture (SOA)
A arquitetura orientada a serviços (SOA) é uma filosofia cujo objetivo é propor
com que as funcionalidades implementadas pelas aplicações devem ser
disponibilizadas na forma de serviços. Portanto SOA não é um produto e nem um
objetivo final, é um conceito arquitetural com o objetivo de construir sistemas
fracamente acoplados.
O fraco acoplamento é devido à forma como as aplicações são integradas,
todas em nível de interface, e não em nível de implementação. Isso gera maior
flexibilidade, pois mudanças na implementação do serviço não podem afetar o
cliente.
Essa técnica permite com que um provedor de serviço disponibilize a
descrição e localização de um serviço, para que futuramente este serviço seja
encontrado por um consumidor, como apresenta a Figura 1.

Figura 1. Exemplo de Serviço Web utilizando conceito de SOA. Adaptado de Breitman (2005)

4

Atualmente o modelo da arquitetura SOA é composto por três entidades que
interagem entre si: Consumidor, Provedor e Registrador de serviços.
Provedor de serviços – Sua função é criar a descrição e publicá-la como um
serviço no registrador de serviços. Também descreve a forma como consumidor
deve invocar o serviço. Essas informações são representadas por um documento
XML escrito na linguagem padrão WSDL.
Consumidor de serviços – Responsável por procurar um serviço, obter sua
descrição e utilizar os descritores do serviço para se conectar a um provedor e
invocar o serviço desejado.
Registrador de serviços – Sua função é divulgar os descritores dos serviços
publicados pelos provedores. Também é de permitir que o consumidor busque
serviços em sua coleção de descrições. Utiliza o padrão UDDI para registrar
informações sobre os serviços.

4. Tecnologias dos Serviços Web
Para prover interoperabilidade entre plataformas distintas, são necessárias
algumas tecnologias básicas como XML, SOAP, HTTP, WSDL e UDDI.

4.1. Extensible Markup Language (XML)
XML é uma meta-linguagem que estabelece um conjunto de regras que
documentos em conformidade com XML devem obedecer. É uma linguagem
baseada em marcadores que descrevem as estruturas de dados. É mais simples
que a linguagem SGML, da qual se originou, e possui algumas alternativas não
fornecidas pela linguagem HTML.
XML por ser extensível e separar conteúdo de apresentação, proporciona ao
desenvolvedor a possibilidade de criar seus próprios elementos de acordo com sua
necessidade, preocupando-se apenas com a estruturação da informação.
Para que um documento XML possa ser interpretado corretamente por uma
aplicação ele deve seguir algumas regras, tornando-o assim um documento XML
bem formado. Abaixo um exemplo de XML bem formado.

5

1. <?xml version="1.0">
2. <note>
3. <to>Tove</to>
4. <from>Jani</from>
5. <heading>Reminder<heading>
6. <body>Don't forget me this weekend!</body>
7. </note>
Trecho de código 4.1. Exemplo de XML bem formado

• Todo documento XML deve conter o elemento root.
• Valores de atributos devem vir entre “ ”.
• Elementos devem estar aninhados.
• Todos elementos precisam de tags de fechamento.
• XML é case sensitive.
Um documento XML também precisa ser validado. A validação é feita através
de um XML Schema ou um DTD. Abaixo um exemplo de DTD e XML Schema
relacionado ao trecho de código 4.1.

1. <!ELEMENT note (to, from, heading, body)>
2. <!ELEMENT to (#PCDATA)>
3. <!ELEMENT from (#PCDATA)>
4. <!ELEMENT heading (#PCDATA)>
5. <!ELEMENT body (#PCDATA)>
Trecho de código 4.2. Exemplo de DTD

6

1. xml version="1.0"?>
2. <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
3. targetNamespace="http://www.w3schools.com"
4. xmlns="http://www.w3schools.com"
5. elementFormDefault="qualified">

6. <xs:element name="note">
7. <xs:complexType>
8. <xs:sequence>
9. <xs:element name="to" type="xs:string"/>
10. <xs:element name="from" type="xs:string"/>
11. <xs:element name="heading" type="xs:string"/>
12. <xs:element name="body" type="xs:string"/>
13. </xs:sequence>
14. </xs:complexType>
15. </xs:element>
16. </xs:schema>
Trecho de código 4.3. Exemplo de XML Schema

4.2. Simple Object Access Protocol (SOAP)
Para troca de informações entre aplicações via Web, é necessário que haja
um padrão para que o destinatário entenda a mensagem. SOAP é o protocolo
especificado para Serviços Web, com a função de padronizar e estruturar
informações.
SOAP utiliza XML para estruturar as informações da aplicação, como por
exemplo, parâmetros de métodos, valores a serem retornados e nomes de métodos
a serem invocados. Também pode indicar o endpoint da mensagem e codificar
mensagens de erro caso ocorra alguma falha. Roda sobre o protocolo HTTP,
significando que a comunicação se dá através da porta 80, permitindo assim, com
que aplicações se comuniquem passando por firewall, evitando problemas de
compatibilidade e segurança.
O protocolo SOAP apresenta muitas vantagens como:
• Simples e de fácil implementação.
• Independente de sistema operacional.

7

• Pode ser usado de forma anônima ou
autenticado(nome/senha).
• Passa por firewalls e roteadores pois roda sobre HTTP.
• Protocolo robusto pois funções e dados são descritos em
XML.
A transmissão dos dados é feita via mensagem SOAP, que consiste
em elementos obrigatórios (Envelope e Body) e elementos opcionais (Header e
Fault), exemplificados pela Figura 2.

Figura 2. Principais elementos de uma mensagem SOAP. Adaptado de Cerami (2002)

Elemento Envelope – Elemento raiz obrigatório em uma mensagem SOAP,
onde são definidos os tipos de dados utilizados no documento e como processá-los.
Também deve conter associado a ele o namespace
http://www.w3.org/2001/12/soap-envelope. Caso o elemento Envelope possua outro
namespace a aplicação deve gerar um erro e descartar a mensagem. Pode possuir
o atributo encodingStyle que é utilizado para definir os tipos de dados usados no
documento.O código abaixo exemplifica a construção do elemento Envelope.

1. <soap:Envelope
2. xmlns:soap=”http://www.w3.org/2001/12/soap-envelope”
3. soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
4. ... Informação da mensagem ...
5. </soap:Envelope>
Trecho de código 4.4. Exemplo do elemento Envelope.

8

Elemento Body – Outro elemento obrigatório para todas as mensagens
SOAP. É dentro deste elemento que se encontra o conteúdo da mensagem como
processo de invocação e parâmetros necessários (CERAMI, 2002). O exemplo a
seguir mostra a estrutura de um elemento Body.

1. <soap:Body>
2. <x:GetSalario xmlns:x="http://www.exemplobody.com/salario">
3. <x:Codigo>
4. 5438
5. </x:Codigo>
6. </x:GetSalario>
7. </soap:Body>
Trecho de código 4.5. Exemplo do elemento Body.

Elemento Header – É um elemento opcional, que existindo deve ser o
primeiro filho do elemento Envelope. Pode ser utilizado para especificar uma
assinatura digital protegendo os serviços por senha, autenticação e localização do
serviço (CERAMI, 2002). Possui o atributo actor cujo objetivo é de endereçar o
elemento Header a um endpoint específico. Já o atributo mustUnderstand serve para
indicar se o elemento Header deve ser interpretado ou não. Por exemplo, se o
atributo mustUnderstand for igual a um o destinatário precisa reconhecer o
elemento. Caso o destinatário não reconheça, o processo deve falhar.

1. <soap:Header>
2. <x:Trans
3. xmlns:x="http://www.w3schools.com/transaction/"
4. soap:actor="http://www.w3schools.com/appml/">
5. <final> 149.103.220.193 </final>
6. </x:Trans>
7. </soap:Header>
Trecho de código 4.6. Exemplo do elemento Header

9

Elemento Fault – Responsável por tratar erros e informações de status da
mensagem SOAP. Caso ocorra alguma falha o elemento Fault será incluído como
filho do elemento Body. É composto por alguns sub-elementos: faultcode (identifica a
falha), faultstring (descreve a falha), faultactor (quem foi causador da falha) e o
elemento detail (informa o erro de aplicação relacionado ao elemento Body)
(CERAMI, 2002).

1. <soap:Fault>
2. <soap:faultcode> 01 </soap:faultcode>
3. <soap:faultstring> Serviço não encontrado </soap:faultstring>
4. <soap:faultactor> 143.107.220.129 </soap:faultactor>
5. <soap:detail> Falha na chamada da função getNome </soap:detail>
6. </soap:Fault>
Trecho de código 4.7. Exemplo do elemento Fault

4.3. Web Services Description Language (WSDL)
WSDL é uma linguagem de descrição escrita em XML que permite descrever
os serviços disponíveis em um Serviço Web. Este documento XML inclui
informações sobre a interface das aplicações, ou seja, possui informações sobre os
métodos ou operações que o serviço realiza e informações sobre o tipo de dado da
mensagem de requisição e resposta. Alem disso especifica a localização do serviço
desejado. Em suma, WSDL representa um contrato entre um serviço solicitante e o
provedor deste serviço (CERAMI, 2002).
Segundo Christensen (2001) WSDL separa descrições da funcionalidade
abstrata oferecida pelo serviço dos detalhes concretos da descrição do serviço.
Foi criado com a combinação de duas linguagens para descrever serviços:
NASSL (Network Application Service Specification Language) da IBM e SDL (Service
Description Language) da Microsoft.
Como visto anteriormente, um documento WSDL é uma gramática XML que
descreve serviços. Os principais elementos deste documento são: definitions, types,
message, portType, binding e service.
Elemento definitions – É o elemento raiz de um documento WSDL. Tem as
funções de definir o nome do serviço Web, declarar múltiplos namespaces e conter

10

todos os elementos de serviço descritos (CERAMI, 2002). A seguir um exemplo do
elemento definitions.

1. <definitions name =" Exemplo "
2. targetNamespace =" http: // www . paulovitor . com.br / wsdl / Exemplo . wsdl"
3. xmlns =" http: // schemas . xmlsoap .org/ wsdl /"
4. xmlns:soap =" http: // schemas . xmlsoap . org / wsdl / soap /"
5. xmlns:tns =" http http: // www . paulovitor . com.br / wsdl / Exemplo . wsdl "
6. xmlns:xsd =" http: // www.w3. org /2001/ XMLSchema ">
7. ...
8. </ definitions >
Trecho de código 4.8. Exemplo do elemento definitions

Elemento types – Define os tipos de dados que são utilizados pelo Serviço
Web. Não é vinculado exclusivamente a um determinado sistema para tipar dados,
mas utiliza o XML Schema como padrão para definição de tipos de dados (CERAMI,
2002).
Elemento message – Define elementos de dados de uma determinada
operação, separando mensagens de requisição de mensagens de resposta. A
mensagem de resposta pode conter os tipos de dados ou valores retornados. Já a
mensagem de requisição informa os parâmetros e os tipos dos dados, como
exemplificado abaixo.

1. <message name="multiplicacaoRequest">
2. <part name="x" type="xsd:float"/>
3. <part name="y" type="xsd:float"/>
4. </message>
5. <message name="multiplicacaoResponse">
6. <part name="multiplicacaoReturn" type="xsd:float"/>
7. </message>
Trecho de código 4.9. Exemplo do elemento message

11

Elemento portType – Elemento que define um Serviço Web, as operações
disponibilizadas pelo serviço e as mensagens envolvidas. Uma mensagem de
pedido e resposta pode ser combinada em uma única mensagem (CERAMI, 2002).

1. <portType name =" Exemplo">
2. <operation name="multiplicacao" parameterOrder="x y”>
3. <input message="impl:multiplicacaoRequest"
4. name="multiplicacaoRequest"/>
5. <output message="impl:multiplicacaoResponse"
6. name="multiplicacaoResponse"/>
7. </operation>
8. </portType >
Trecho de código 4.10. Exemplo do elemento portType

Elemento binding – Elemento que descreve a forma de acesso ao serviço
através do protocolo SOAP. O documento abaixo exemplifica a construção de um
elemento binding.

1. <binding name="Exemplo" type="impl:ExemploImpl">
2. <soap:binding style="rpc“ transport="http://schemas.xmlsoap.org/soap/http"/>
3. <operation name="multiplicacao">
4. <soap:operation soapAction=""/>
5. <input name="multiplicacaoRequest">
6. <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
7. namespace="http://DefaultNamespace" use="encoded"/>
8. </input>
9. <output name="multiplicacaoResponse">
10. <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
11. namespace="http://127.0.0.1:8080/arq/ExemploImpl.jws" use="encoded"/>
12. </output>
13. </operation>
14. </ binding >
Trecho de código 4.11. Exemplo do elemento binding

12

Elemento service – Elemento que define o endereço para invocar o serviço
especificado. Tem uma URL para invocar um serviço SOAP.

1. <service name="Exemplo">
2. <port binding="impl:Exemplo" name="ExemploImpl">
3. <soap:address location="http://127.0.0.1:8080/arq/ExemploServicoImpl.jws"/>
4. </port>
5. </service>
Trecho de código 4.12. Exemplo do elemento service

4.4. Universal Description, Discovery and Integration (UDDI)
É um protocolo utilizado para especificar mecanismos baseados em padrões
para classificar, catalogar e administrar serviços, fazendo com que eles sejam
descobertos por outras aplicações. Isso é possível pois os dados, que são
documentos XML, ficam armazenados em diretórios de serviços (CERAMI, 2002).
De maneira geral, o registro de serviços UDDI possui dois tipos de cliente. Um
é o provedor de serviços, que deseja publicar seus serviços e interfaces. O outro é o
consumidor de serviços, que deseja obter o serviço e se conectar a ele.
Segundo Cerami (2002), os dados armazenados dentro do UDDI são
divididos em três categorias:
Páginas brancas – Categoria que inclui informações gerais sobre uma
empresa específica, por exemplo, nome comercial, descrição e endereço.
Páginas amarelas – Classificam os dados do serviço oferecidos seguindo
normas taxonômicas.
Páginas verdes – Possui informações técnicas sobre um Serviço Web, como,
um ponteiro para uma especificação externa e um endereço para invocar o serviço.
Além de permitir a publicação de seus serviços, UDDI também permite a
publicação de especificações e taxonomias através de uma entidade chamada
tModel. É uma estrutura que representa de forma genérica um serviço registrado no
UDDI. Deve conter ponteiros para especificações externas.
Ao registrar um serviço como um tModel um identificador único será dado ao
tModel registrado. Através do identificador, um negócio pode especificar que um ou
vários de seus serviços estão em conformidade com a especificação do tModel. Um
tModel é composto por 8 elementos:

13

tModelKey – Chave obrigatória que identifica um tModel.
authorizedName – Contem o nome da pessoa que publicou o tModel.
operator – Contem o nome do operador que mantém a copia mestre do
tModel.
description – Descrição do tModel.
name – Nome do tModel.
overviewDoc – Referencia a descrição externa ao tModel, por exemplo, um
documento WSDL localizado no servidor do serviço.
identifierBag – Registram números de identificação para um tModel.
categoryBag – Associam taxonomias a tModels.

5. Conclusão
Podemos concluir que o Serviço Web é uma ótima solução para integração de
sistemas, pois apresenta vantagens como independência de plataforma, baixo
acoplamento e provê interoperabilidade entre aplicações. Outra vantagem desta
tecnologia é o seu baixo custo, pois se baseia em padrões abertos da Internet. Por
fim concluímos que apesar de todas estas vantagens ainda encontramos alguns
problemas como limitação na linguagem de descrição e atualização de links
quebrados.

Referências Bibliográficas

BRAY, T.; PAOLI, J.; MALER, E.; YERGEAU, F. Extensible Markup Language
(XML) 1.0 (Fourth Edition), Agosto 2006. Disponível em
http://www.w3.org/TR/2006/REC-xml-20060816/#sec-intro

BOOTH, D. et al. Web Services Architecture, Fevereiro 2004. Disponível em
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/

CERAMI, E. Web Services Essentials. Sebastopol, CA, USA: O’Reilly &
Associates,2002.

14

A Estrutura de um Web Service

Mais conteúdo relacionado

Mais procurados (20)

Destaque (16)

Semelhante a A Estrutura de um Web Service (20)

Último (20)

A Estrutura de um Web Service