Web Services
João Henrique da Rosa
Universidade do Vale dos Sinos
Unisinos 950, São Leopoldo, RS, Brasil
[email protected]
que existem algumas especificações e tecnologias
definidas para a construção e utilização de Web services, e
essas especificações e tecnologias atendem aos seguintes
requisitos: uma forma comum de representar dados, um
formato de mensagens comum e extensível, uma
linguagem de descrição dos serviços, um mecanismo para
localizar os serviços e um mecanismo para descobrir os
provedores de serviços.
Booth explica, que o XML, eXtensible Markup
Language, é a melhor escolha para a representação de
dados, e o XML Schema para representar os tipos de
dados. Para a troca de informações, o SOAP, Simple
Object Access Protocol, é um protocolo leve, o qual é
divido em duas partes, uma delas é composta por um
conjunto de regras de como utilizar o XML para
representar os dados, e a outra define as associações ao
protocolo HTTP e o formato das mensagens, ou seja, essa
parte é uma convenção de como representar as chamadas
de procedimentos remotos (RPCs). Partindo do pré
suposto que os serviços a serem chamados não são
conhecidos, é preciso que haja uma descrição deles. Para
fazer essa descrição, ou documentação das mensagens que
os Web services aceitam e geram, é usado o WSDL, Web
Service Description Languagem. Segundo Booth, esse
mecanismo padrão facilita a interpretação dos contratos
pelos desenvolvedores e ferramentas de desenvolvimento.
Nesse ponto já foram atendidas quase todas as
especificações, restando apenas duas, as quais são: um
mecanismo para localizar os serviços e um mecanismo
para descobrir os provedores de serviços. Para localização
dos serviços, Booth apresenta o protocolo Disco
(Discovery Protocol), o qual, segundo ele, define um
formato para um documento chamado Discovery, e um
protocolo para devolvê-lo. Assim, possibilitando a
localização dos serviços, em um Web site conhecido.
Para atender a especificação de um mecanismo para
descobrir os provedores de serviços, Booth apresenta o
UDDI (Univesal Description, Discovery, and Integration).
Ele explica que esse é um mecanismo para os
fornecedores anunciarem a existência dos seus serviços, e
para que os consumidores possam localizá-los.
Booth, resumidamente, define um XML Web service
como um serviço de software publicado na Web através
Resumo
Em meados dos anos 90, quando a Internet começou a
se popularizar, as tecnologias que haviam possibilitavam
você se conectar em um site e baixar o seu conteúdo. A
linguagem que, de fato, permitia a apresentação das
informações presentes na rede era o HTML (Hiper Text
Makup Language). Porém, nos últimos anos novas
tecnologias e frameworks de desenvolvimento estão
surgindo, possibilitando uma maior integração entre os
diversos aplicativos e serviços disponibilizados na
Internet. Essas novas tecnologias e frameworks devem
tratar tarefas complexas, como o gerenciamento de
transações, através da disponibilização de serviços
distribuídos que utilizem interfaces de acesso simples e
bem definidas. Esses serviços ou aplicativos distribuídos
são conhecidos como Web services.
Pelo fato dos Web services serem baseados em
tecnologias já padronizadas, tais como, a linguagem
XML e o protocolo HTTP, eles são extremamente
atrativos. Para entender-se a participação da linguagem
XML em um Web service, é útil pensar-se em um
documento escrito nessa linguagem, o qual pode possuir
várias formatações. Entretanto, existem algumas
formatações especiais de um documento desse tipo, as
quais definem padrões como o SOAP, WSDL e o UDDI.
Padrões esses que são utilizados para fazer a
comunicação, descrição e o descobrimento dos serviços.
Esse artigo apresenta os conceitos desses padrões e
finalizará com uma comparação entre os Web services e
o CORBA, o qual de certa forma pode ser considerado o
antecessor dos Web services.
Palavras Chaves: Web services, XML, XML Schema,
SOAP, WSDL, UDDI.
1. Introdução
Segundo Booth [1], um Web service é um
componente, ou uma unidade lógica de aplicações, as
quais são acessíveis através de protocolos de Internet. Ele
define como componentes, os serviços que possuem uma
funcionalidade, a qual pode ser reutilizada sem a
preocupação de com ela é implementada. Booth mostra
1
do SOAP, descrito com um arquivo WSDL e registrado
em UDDI.
Os Web services prometem ser capazes de tornar as
operações entre os serviços altamente distribuídos e
heterogêneos hospedados na Web, mais ricas, eficientes e
dinâmicas, como apresenta Hull [2]. Progressos
substanciais têm sido feito para atingir essa meta, alguns
exemplos são as padronizações emergentes mostradas,
SOAP, WSDL e UDDI. A indústria tecnológica também
tem se esforçado bastante para produzir ferramentas para
dar suporte a esses tipos de aplicações, algumas delas são:
IBM’s WebSphere Toolkit, Sun’s Open Net Environment
and JiniTM Network technology, Microsoft’s .Net and
Novell’s One Net initiatives, HP’s e-speak, BEA’s
WebLogic Integration. A academia, por sua vez, tem
empregado muita energia em pesquisas, que usam ou
acrescentam vantagens aos Web services. Mas mesmo
assim, segundo Hull, há um extenso caminho a se
percorrer, especialmente se dando o longo objetivo de
tornar possível o automatizado descobrimento,
composição, promulgação e monitoramento de coleções
de Web Services, quais estão trabalhando para alcançar
um específico objetivo.
Hull diz que os fundamentais desafios na composição
de Web services consistem do desenho, e da análise de
desenvolver técnicas e ferramentas necessárias para
manipular os aspectos inovadores do paradigma. Ele
também afirma que esses desafios levantam uma grande
variedade de questões, as quais são relevantes para a base
de dados da comunidade acadêmica. Algumas dessas
questões são: Qual o caminho certo para modelar Web
services e as suas composições? Qual é o caminho certo
para consultá-los tendo em vista de suportar as
composições autônomas e análises algorítmicas? E como
são possíveis os aspectos de gestão de dados dos serviços
compostos Web serem incorporados dentro de atuais
padrões de Web sevices?
A figura 1, qual foi retirada do trabalho de Hull,
mostra três dimensões que medem modelos de
descrição/composição de serviços Web. Hull explica que
a dimensão Complexity of component services
(complexidade de serviços de componentes) aponta a
capacidade de informação da linguagem e o módulo
representando o serviço. Ele analisa que nessa dimensão
OWL-S é baixo por ele descrever somente a entrada e
saída dos serviços. Ao contrário do que faz o WSDL, qual
pega abundantes estruturas de informações com o XML
Schema e usa mensagens para a entrada e saída. Ele ainda
verifica que os módulos BPEL, CSP, π-Calculus, Mealy,
Roman e BPML também modelam estados de serviços e
mensagens ou seqüências de atividades. Explicações dos
módulos com mais importância serão dadas mais adiante,
então não se preocupe em entendê-los agora.
Figura 1: Anatomia de composição de serviços Web.
Hull nos explica que a habilidade de montar serviços
que são individuais em um só, faz com que todos esses
módulos se elevem ao longo da dimensão Complexity of
glue language, essa dimensão descreve a capacidade de
cada módulo de conectar componentes de software. E a
terceira e última dimensão, de acordo com a explicação de
Hull, é a habilidade de descrever semânticas. Ele ainda
fala que o OWL-S pode descrever as propriedades sobre a
entrada e saída de uma operação e também especificar
como o serviço reage com um modelo abstrato do mundo
real, e ele conclui dizendo que é isso o distingue dos
outros modelos.
Esse artigo está divido em seis partes. Da segunda até
a quarta serão descritas, em detalhes, as principais
padronizações feitas, para fazer dos Web services uma
realidade. Na seção cinco os Web services são abordados
de um ponto de vista histórico, sendo assim, essa seção
não é de grande relevância para entender o funcionamento
e a composição dos Web services, nesse tópico procura-se
fazer uma comparação entre os Web services e o CORBA.
Na última seção é feita uma conclusão do estudo sobre
Web services.
2. SOAP (Simple Object Access Protocol)
Segundo Booth, SOAP é o protocolo de comunicação
entre os Web services. Ele diz que o SOAP é como uma
especificação que define o formato das mensagens XML.
Sendo assim, uma mensagem SOAP nada mais é que um
fragmento XML bem formatado e encapsulado por um
par de elementos SOAP.
Booth explica que existem outros módulos da
especificação SOAP que descrevem como representar os
dados do programa em XML e como se usa o SOAP para
fazer as chamadas de procedimentos remotos. Esses
módulos opcionais da padronização são usados para
implementar as aplicações no estilo RPC, onde a
mensagem SOAP, que contem a chamada e os parâmetros
2
da função, é enviada pelo cliente, e o servidor retorna uma
mensagem com os resultados da função que foi solicitada.
Booth ainda diz que as implementações recentes do
SOAP têm suporte para aplicações RPC, porque alguns
programadores estão habituados com as aplicações
CORBA ou COM, as quais têm a capacidade de aplicar
esse estilo muito bem. Porém, além de suportar chamadas
do tipo RPC, o SOAP também suporta aplicações no
estilo de documentos, onde as aplicações são apenas um
invólucro de um documento XML. Booth analisa, dizendo
que as aplicações no estilo de documentos são muito
flexíveis, pois alguns Web services usam elas, para
implementar serviços que seriam difíceis de se
desenvolver usando RPC.
O último módulo especifica como o SOAP estabelece
o formato de uma mensagem HTTP que possui uma
mensagem SOAP. Booth explica que a ligação com o
HTTP é opcional, mas a maioria das aplicações SOAP a
suportam, pelo fato de ser o único protocolo padronizado
para ele. Por a maioria das aplicações SOAP suportarem o
HTTP, criou-se uma incorreta concepção de que o SOAP
requer o HTTP. Exemplos de aplicações que suportam
protocolos diferentes do HTTP são: MSMQ, MQ Series,
SMTP e TCP/IP, mas quase todas as implementações de
Web services usam o HTTP, porque ele é altamente
difundido. Booth continua falando, que pelo fato do
HTTP ser o protocolo central da Web, muitas empresas
possuem um gerenciamento de redes que suportam o
HTTP e pessoas habilitadas a gerenciá-las.
muito diferentes. Booth explica que tentativas como essa
já foram feitas no passado, mas nenhumas delas tiveram o
mesmo sucesso do SOAP, pois ele é simples e a sua
implementação é fácil.
3. WSDL (Web Services Description
Language)
Segundo Zanuz [3], o WSDL é o mais importante
protocolo para a implementação de um Web service,
devido ao fato dos serviços serem descritos através de um
contrato do tipo WSDL. Zanuz continua explicando, que
uma descrição de serviços WSDL expõe o ponto do
contrato do serviço, o qual também é conhecido como
endpoint. Esse endpoint estabelece a localização física
dos serviços e disponibiliza uma descrição formal da sua
interface, assim possibilitando aos programadores que
querem se comunicar com os Web sevices saberem
exatamente como estruturar as mensagens de requisição
necessárias.
Como Erl [4] mostra, a descrição de serviços WSDL
pode ser separada em duas partes, a descrição abstrata e a
concreta. A descrição abstrata firma as características de
interface do Web service sem dar qualquer referência as
tecnologias empregadas para hospedar ou transferir os
dados. E a descrição concreta funda o protocolo de
transporte físico para possibilitar que a interface abstrata
possa se comunicar. O fato do WSDL ser dividido nessas
duas tipos de descrição, abstrato e concreto, possibilita a
preservação da integridade da descrição dos serviços,
independente das possíveis alterações que possam ocorrer
na plataforma tecnológica.
2.1. Kit de Ferramentas para SOAP
Segundo Booth, o fato de algumas implementações
diferirem das especificações do SOAP, é fonte de
confusão. Ele explica que isso acontece porque muitas
pessoas utilizam algum SOAP toolkit para criar e analisar
as mensagens do SOAP. Esses toolkits geralmente
traduzem chamadas de funções de alguma linguagem para
uma mensagem SOAP. Ele exemplifica mostrando o
Microsoft SOAP Toolkit 2.0, o qual transforma uma
chamada função COM para SOAP, e o Apache Toolkit,
que transforma uma chamada de função JAVA para
SOAP. Booth explica que os tipos de chamadas e de
parâmetros que são suportados podem variar dependendo
da implementação, dessa forma uma função que funciona
corretamente com um toolkit, pode não funcionar com
outro, porém, Booth deixa bem claro ao afirmar que essa
não é uma limitação do SOAP, mas sim da
implementação particular que está sendo usada.
4. UDDI (Universal Discovery Description
and Integration)
Até esse ponto foi visto que o SOAP transporta os
serviços e o WSDL os descreve, mas ainda é necessário
um mecanismo para encontrá-los. Segundo a definição de
Gunzer [5] sobre o UDDI, ele é um padrão desenvolvido
para fornecer um diretório de busca para os negócios e
seus serviços. Gunzer explica que o UDDI tem como
meta ser um mediador entre o serviço e o cliente, ou seja,
o seu objetivo é possibilitar que os clientes requisitantes
encontrem o fornecedor do serviço por eles procurado.
Muitos gostam de fazer uma analogia entre o UDDI e
uma lista telefônica, pelo fato dele ser divido em
“páginas” com três cores distintas, assim como é feito em
uma lista telefônica. Sendo assim, a cor branca contém a
informação sobre o nome, endereço e o número de
telefone dos fornecedores do serviço, além de outras
possíveis informações. As páginas amarelas contêm as
listagens comerciais baseadas nos tipos desses negócios,
de maneira organizada por categoria específica ou regiões
demográficas. E as páginas verdes são usadas para indicar
2.2 Vantagens
Segundo Booth o fato de o SOAP estar sendo
implementado em diversas plataformas, faz dele muito
funcional, pois isso possibilita a conexão de sistemas
3
os serviços disponibilizados por cada negócio, incluindo
as informações técnicas envolvidas na interação com o
serviço.
da Web”, pegam automaticamente o largo escopo da
Web, ao em vez de primeiramente pegar escopo das
aplicações orientadas a objetos como faz o CORBA.
5. Corba e Web Services
6. Conclusão
A introdução do paradigma de programação orientado
a objetos em 1980 prometia fazer dos componentes de
softwares reusáveis uma realidade. Apesar de certamente
haver alguns ganhos na reutilização de alguns
componentes dos softwares, como o da produtividade de
programação, a alteração não foi substancial. Na década
de 90 se viu tentativas para aumentar a reutilização dos
códigos, focadas na idéia de componentes estendidos
distribuidamente. Um notável esforço nessa área foi o
CORBA (Common Object Request Broker Architecture),
como mostra Tidwell [6]. Tidwell explica que o CORBA
permite que componentes de software escritos em
linguagens diferentes rodando sobre máquinas diferentes,
as quais usam sistemas operacionais diferentes, posam se
comunicar. Ele complementa afirmando que de certo
ponto de vista, os Web services representam uma
evolução do CORBA, e que eles são mais convenientes
para se usar.
Tidwell continua falando da dificuldade encontrada
em usar sistemas distribuídos como o Corba, pelo fato de
ter que lidar com as diversas linguagens. O que o CORBA
fez para eliminar esse problema, foi mover as linguagens
dentro de um background, definindo assim o IDL,
Interface Definition Language. Para se entender melhor o
que é o IDL deve voltar-se para o paradigma orientado a
objetos em ambientes distribuídos, onde temos classes,
objetos, distribuídos em servidores. Para acessar um
desses objetos, é necessário conhecer quais são os
serviços que ele oferece, e é isso que o IDL faz, ele
descreve os serviços oferecidos pelos objetos. Então,
antes de uma aplicação usar um objeto ela deve perguntar
a ele quais são os serviços oferecidos. Ele responderá
utilizando a linguagem IDL. Steve Vinoski [7] da mais
algumas explicações sobre o IDL, ele diz que o IDL é
uma linguagem declarativa com uma sintaxe muito
parecida com a do C++, e que ele oferece um conjunto
básico de tipos de dados, tais como: short, long, float,
double and boolean.
O fato de o IDL ter uma sintaxe muito parecida com a
do C++, faz, indiretamente, com que os usuários tenham
que conhecer linguagens vinculadas para usar o CORBA.
Tidwell mostra que, havia um caminho em que a
linguagem IDL poderia ser substituída por outra, com um
nível maior de especificação. Com essa linguagem a
comunicação poderia, certamente, ser feita de forma mais
simples, pois ela usaria mensagens com significados. Ele
ainda conclui que, felizmente os Web Services, os quais
fazem uso da linguagem XML, e são definidos como
“aplicações modulares auto contidas e auto descritivas
que podem ser publicadas, localizadas e invocadas através
Algumas das vantagens do protocolo SOAP
encontram-se na sua simplicidade e, na facilidade de
entendê-lo e implementá-lo. O SOAP comparado com as
abordagens anteriores é significativamente menos
complexo, facilitando assim a sua ampla aceitação por
parte dos desenvolvedores de softwares. Mais alguns
pontos significativos, é o fato de ele trabalhar com
protocolos padrões de Web, como XML, HTTP e TCP/IP,
e permitir que programas escritos em diferentes
linguagens, em diferentes plataformas, se comuniquem de
forma padronizada.
7. Referências
[1] David Booth, W3C Fellow / Hewlett-Packard Hugo Haas,
W3C Francis McCabe, Fujitsu Labs of America Eric Newcomer
(until October 2003), Iona Michael Champion (until March
2003), Software AG Chris Ferris (until March 2003), IBM
David Orchard (until March 2003), BEA Systems, “Web
Services Architecture”, W3C Working Group Note 11 February
2004.
[2] Richard Hull, “Tools for Composite Web Services: A Short
Overview.” Bell Labs Research. Lucent Technologies.
[3] Luciano Zanuz, Alexsandro S. Filippetto, Sergio Crespo,
“Service-Oriented Architecture: Teoria e Prática”, Programa de
Pós-Graduação em Computação Aplicada Universidade do Vale
do Rio dos Sinos
[4] Erl, T. (2007) “Defining the Web Service with WSDL”,
http://www.wsstandards.com/wsdl.asp.
[5] H. Gunzer, Introduction to Web Services, Março de 2002.
http://bdn.borland.com/java/webtech/0,1418,10018,00.html
[6] D. Tidwell, “Web Services—The Web’s Next
Revolution,” IBM tutorial, 29 Nov. 2000,
www-105.ibm.com/developerworks/
education.nsf/webservices-onlinecourse-bytitle/
BA84142372686CFB862569A400601C18?
OpenDocument.
[7] Steve Vinoski, “Distributed Object Computing with
CORBA”, July/August 1993 Report magazine
4