4 WEB SERVICE (WS)

4.1 INTRODUÇÃO

O desenvolvimento de normas para se poder definir formas de interação aplicação-

aplicação tem acontecido ao longo desses últimos anos. Essas normas proporcionam a
troca de mensagens entre aplicações em um ambiente heterogêneo [ARAÚJO, 2005].

Como exemplo desses padrões podemos citar o DCOM (Distributed Component

Model), CORBA (Commomm Object Resquest Broker) e o J2EE (Java 2 Plataform,
Enterprise Edition). No entanto as soluções citadas acima são proprietárias e caras, o que
num ambiente como a internet as tornas inadequadas. Já os web services aparecem
como uma plataforma independente para o suporte ao desenvolvimento de aplicações
utilizando internet, realizando o mesmo que as tecnologias citadas anteriormente
[CHUNG, apud ARAÚJO, 2005].

Pode-se dizer que um WS é uma interface localizada entre o código da aplicação e

o código do usuário, agindo como uma camada de abstração. Essa camada seria
responsável por separar detalhes de plataforma e de linguagens de programações
específicos da forma como o código da aplicação realmente é invocado. Isso quer dizer
que qualquer aplicação em qualquer plataforma com suporte a web services pode acessar
suas funcionalidades [SNELL, 2001].

Segundo [ROCHA, apud ARAÚJO, 2005] pode-se dividir a arquitetura de um web

service em três entidades distintas: o fornecedor, o catálogo ou serviço de registro e o
cliente.

O fornecedor publica no catálogo a existência de seus serviços. O cliente consulta

o catálogo que fornece a localização do fornecedor bem como sua descrição. O cliente,
tendo a localização do fornecedor passa então passa a requisitar seus serviços. Esse
esquema é demonstrado na figura abaixo, sendo os padrões usados na comunicação
SOAP, WSDL e UDDI são explicadas com mais detalhes nas seções 4.2, 4.3, 4.4
respectivamente.
 Comunicação

A padronização da comunicação é necessária, caso contrário seria preciso criar

uma outra aplicação para realizar a conversação para cada fornecedor, perdendo assim a
interoperabilidade da solução. Além disso, o cliente e o desenvolvedor, não são
obrigados a saber ler o XML para construir os dados necessário para a realização de
requisições e utilização das respostas.

Pensando nisso, ferramentas com capacidade de ler a especificação e retornar o

dado em uma abstração maior estão sendo implementadas ou já existem para a maioria
das linguagens.

O conjunto de normas seguidas atualmente pelos desenvolvedores de WS é

definida pela W3C (Word Wide Web Consourtium). Algumas dessas normas são:
● eXtensible Markup Language (XML). É uma metalinguagem para marcação de
documentos derivada da da SGML (Standard Generalized Markup Language).
Essa marcação segue a orientação do W3C, que defini a forma como essa deve
ser realizada. Por se tratar de uma metalinguagem é permitido que seja criada e
usado qualquer tipo de marcação, daí a sua extensibilidade, possuindo ainda uma
vantagem, por se apenas texto existe independência de plataforma [W3C, 2003].
● XML Namespaces é uma recomendação da W3C para evitar o conflito de nomes
dentro dos vários documentos XML, utilizando um conjunto de nomes, que são
identificados por uma referência URI (Universal Resource Identier) [W3C, 1999].
● O XML Schema provê meios de descrever a estrutura, o conteúdo, e a semântica
de de um documento XML, sendo ele próprio um documento XML [W3C, 2004].
● Simple Object Access Protocol (SOAP) é escrito baseado em XML servindo como
um protocolo de comunicação, permitindo assim a troca de mensagens dentro do
web service, de uma forma padronizada [SNELL, 2001].
 ● Web Service Definition Language (WSDL) é utilizado para descrever os WS como
um conjunto de operações, bem como especificar os parâmetros das operações e
tipos utilizados [W3C, 2001].
● Universal Description, Discovery and Integration (UDDI) é um serviço de registro,
descrição, descoberta e integração de WS existentes. [CERAMI, 2002].

4.2 SIMPLE OBJECT ACCESS PROTOCOL (SOAP)

SOAP é um documento baseado em XML, criado para permitir a troca de

mensagens entre dois computadores, sendo possível enviá-lo a partir de vários protocolos
de comunicação, sendo o utilizado nos WS o HTTP1 [CERAMI, 2002].

A mensagem a ser transmitida pode ser qualquer coisa, desde uma simples frase
até uma lista de todos os produtos de uma loja, ou seja, é possível representar qualquer
tipo de dado necessário a uma aplicação.

No documento é especificado um envelope, que possui um conjunto de regras,

utilizadas para realizar a conversão de tipos de dados das plataformas e aplicações
especificas em uma representação em XML [SNELL, 2001].

Como se trata de um documento XML é independente de plataforma e linguagem e

assim como permite a transformação de dados em XML também permite a recuperação
do mesmo.

Segundo [ARAÚJO, 2005] o envelope é o principal elemento dentro de mensagem

SOAP, representando sua raíz. A figura abaixo mostrar seu esquema básico.
 Envelope SOAP
O cabeçalho (header) do envelope não é um componente obrigatório, sendo usado
normalmente para passar informações contextuais, como uma credencial de identificação.
Caso seja usado a cabeçalho deve ser o primeiro elemento do envelope e conter pelo
menos 1 HeaderEntry, podendo ter mais se necessário, aonde são guardadas as
informações [SNELL, 2001].

O corpo (body) da mensagem já é obrigatório dentro da mensagem. Ele pode

conter quantos filhos forem necessários, desde que sejam XMLs válidos. O corpo também
pode conter um elemento fault caso o resultado retorne erro. Os elementos comuns
dentro de um fault são: faultCode , faultString , faultActor e detail [CERAMI, 2002].

4.3 WEB SERVICE DEFINITION LANGUAGE (WSDL)

De acordo com [CERAMI, 2002] um WSDL permite a tradução do web service para
a linguagem XML, podendo ser dividido em quatro partes críticas:
● Informação sobre os métodos que serão publicados pelo serviço.
● Informação sobre o protocolo a ser utilizado para a chamar o serviço.
● Os tipos de dados de entrada necessários aos pedidos, e o tipo de resposta a
requisição.
● Endereço do serviço que deve ser utilizado pelo cliente para a invocação do
mesmo.
A figura abaixo apresenta os principais elementos de um WSDL segundo
[CHAPPEL AND JEWELL, apud ARAÚJO, 2005].
 Elementos do WSDL
As definições (definitions) são a raiz do documento. Nesse elemento estão as
propriedades que compõem o documento, como os namespaces que serão utilizados ao
longo do documento.

Os tipo (type) definem os tipos de dados que são utilizados pela comunicação
cliente-servidor. Por padrão é usado o o esquema básica de tipos da W3C, mas o
esquema pode estar vinculado a qualquer especificação. As mensagens usam a definição
do tipo dentro de suas mensagens.

A mensagem (message) define a estrutura lógica e tipificada dos dados

transmitidos em um sentido, ou seja, ou se trata de pedido ou de uma resposta, no
entanto, um documento WSDL pode conter um ou mais elementos deste tipo. Ele define o
nome da mensagem e se ela contém um ou mais elementos que podem ser os
parâmetros ou valores de resposta das funções.

Uma operação (operation) define uma operação suportada pelo serviço.

 Um portType é um conjunto de mensagens que juntos criam uma definição do fluxo
de operação. Por exemplo, se juntando uma mensagem de requisição com uma
mensagem de resposta forma-se uma mensagem de requisição/resposta ou operação.

O binding contém informações especificas do como o serviço está sendo

implementado na rede, bem como informações especificas do SOAP.

Uma porta (port) representa um ponto de destino na rede calculado baseado na

associação de um endereço binding e um ponto de rede.

O serviço (service) informa o endereço que devem ser usados para a invocação de
cada requisição especificamente.

Utilizando o WSDL um cliente pode localizar um web service na internet,

possibilitando a ele visualizar e invocar todos os métodos públicos permitidos por ele.

4.4 UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION (UDDI)

Lançado em maio de 2001 pela Microsft e a IBM, o UDDI permitia a qualquer

organização se registrar, bem como a seus serviços, além de permitir a busca por esses
dados.

Segundo [CERAMI, 2002] o núcleo do UDDI se divide em duas partes. A primeira é

uma especificação técnica para a construção de serviços de negócios distribuídos e web
services. Esses dados são armazenados em XML é o serviço fornece uma API para
busca e publicação. A segunda é o registro de negócios da UDDI, que representa
toda sua especificação operacional.

Pode-se dizer que o UDDI é uma listagem dos WS existentes, permitindo que seja
feita uma busca pelo serviço. Esses serviços podem ser categorizados facilitando a
busca, sendo possível sua invocação logo após [ARAÚJO, 2005].