Monografia de Computação Móvel - PUC-Rio

stizzahaddockSoftware and s/w Development

Dec 14, 2013 (3 years and 10 months ago)

98 views

1

Introdução à Computação Móvel



















Tecnologia de Web Services
aplicada à Computação Móvel



















Otavio Rezende da Silva

Matrícula:0115636

2

Índice

1. Introdução

................................
................................
................................
.....................

3

2.
Arquitetura Conceitual de Web Services

................................
................................
......

4

3. Protocolos

................................
................................
................................
.....................

6

3.1

Introdução a X
ML

................................
................................
............................

7

3.2

Simple Object Access Protocol (SOAP)

................................
..........................

7

3.3

Web Services Description Language (WSDL)

................................
...............

10

3.4

Universal Description, Discovery and Integration (UDDI)

...........................

13

4. Ferramentas e Ambientes de Desenvolvimento de Web Services

.............................

14

4.1

Microsoft .NET

................................
................................
...............................

14

4.2

SunONE

................................
................................
................................
..........

14

4.3

HP e
-
Speak

................................
................................
................................
.....

15

4.4

IBM Web Services Toolkit

................................
................................
.............

15

4.5

IBM TSSuite

................................
................................
................................
...

15

5. Estudo de Caso


Serviço de Impressão para Clientes
Móveis

................................
..

15

6.
Trabalhos Relacionados

................................
................................
..............................

17

7. Conclusões

................................
................................
................................
..................

18

8. Refer
ências

................................
................................
................................
.................

18


3

1.

Introdução

Atualmente a web é utilizada principalmente para o acesso interativo a documentos e
aplicações. Na maioria dos casos, este acesso é feito através de web browsers, por
usuários humanos. No entanto, acre
dita
-
se que a partir do momento em que houver uma
forte integração entre diferentes aplicações na Internet, o uso da web poderá ser
maximizado .

Quando pensamos em computadores móveis, cuja capacidade de processamento,
armazenamento e transmissão de dados

é limitada, esta necessidade de integração é
ainda maior. Por exemplo, tendo acesso a diferentes aplicações distribuídas na web,
computadores móveis poderiam solicitar uma série de serviços que executam na rede
fixa, recebendo o resultado de seu processam
ento. Como exemplos podem ser citados
serviços de impressão de arquivos, armazenamento de documentos e conversão de
formatos.

No entanto, para que uma boa relação custo
-
benefício seja alcançada. é necessário que
esta integração entre aplicações seja efetu
ada de forma padronizada. Desta forma uma
vez desenvolvida a integração de uma aplicação, ela estará pronta para ser acessada por
qualquer outra, através de um padrão único. Sendo assim o desenvolvimento específico
e artesanal de integração de pares de apl
icações é evitado, gerando uma grande
economia de gastos no processo de integração como um todo.

É neste contexto que surge a tecnologia denominada
Web Services
. Esta nova tecnologia
permite que aplicações sejam integradas de maneira mais rápida, simples e

barata. A
chave para alcançar estes resultados está na utilização de um de um modelo comum de
comunicação entre programas baseado em padrões existentes e emergentes como HTTP
[Fielding 1997], XML [W3C 2000a] (eXtensible Markup Language), SOAP [W3C
2000b](
Simple Object Access Protocol), WSDL [W3C 2001] (Web Services
Description Language) e UDDI [McKee 2001] (Universal Description, Discovery and
Integration).

Um
Web Service

pode ser definido como uma aplicação de software ou um dispositivo
de hardware que po
de ser acessado ou utilizado através da web. Cada
Web Service
implementa uma ou mais interfaces de serviço descritas através de linguagens
específicas. Estas interfaces descrevem o conjunto de operações às quais o serviço dá
suporte, contendo toda a inform
ação necessária para interação com ele, incluindo o
formato das mensagens trocadas, o protocolo de transporte utilizado e sua localização.
Esta interface esconde os detalhes de implementação do serviço, permitindo sua
utilização independentemente da plataf
orma de hardware ou software na qual ele é
implementado ou da linguagem na qual ele é escrito.

Além da especificação de interfaces de descrição, a tecnologia de define um padrão
simples e específico para a descoberta de serviços específicos na web. Para
tanto é
utilizado um
broker
de serviços, que nada mais é que base de registro onde serviços
podem ser publicados e em seguida descobertos por clientes. Um cliente é uma
aplicação que usa um ou mais serviços. Em geral, um cliente utiliza um
broker

para
desc
obrir um serviço e recuperar informações específicas a ele e em seguida invoca
operações do serviço diretamente ou utilizando um intermediário. A figura 1 ilustra a
interação entre o serviço, o cliente e o
broker
.

Como já mencionado acima, a tecnologia de
Web Services

é baseada em padrões
abertos, “leves” e baseados em XML. Desta forma os processos de descoberta,
4

descrição, invocação e acesso a serviços também estão baseados nestes protocolos não
proprietários. No restante deste trabalho a arquitetura utili
zada na tecnologia de
Web
Services

será descrita (seção 2), os protocolos utilizados serão apresentados na seção 3,
na seção 4 será mostrada uma aplicação baseada para armazenamento e impressão de
arquivos utilizados por clientes móveis. Na seção 4 serão a
presentados de maneira
sucinta ambientes e ferramentas para o desenvolvimento de
Web Services
. Na seção 6
serão discutidas comparações com trabalhos relacionados e finalmente serão
apresentadas, na seção 7, algumas conclusões.

2.

Arquitetura Conceitual de We
b Services

A arquitetura padrão da tecnologia de
Web Services

pode ser descrita em diversas
camadas. Para as diferentes operações de publicação, descoberta e invocação de
serviços são necessárias diversas camadas que compõem a denominada “Pilha de Web
Serv
ices” [Kreger 2001], ilustrada na figura 2. As camadas superiores são construídas
utilizando funcionalidades disponibilizadas pelas camadas inferiores. As colunas no
lado direito da figura ilustram requisitos necessários em cada um dos níveis da pilha,
enq
uanto o texto da esquerda representa as tecnologias e padrões que são utilizados na
implementação de em cada uma das camadas.

Para que Web Services possam ser invocados por um cliente remoto, eles devem ser
acessíveis através da rede. Desta forma, na base
da pilha está a camada de rede,. Na
maioria das vezes é interessante que os serviços sejam acessados através da Internet,
sendo então necessária a utilização de protocolos amplamente difundidos na grande
rede. Devido a sua onipresença o protocolo HTTP é o
principal protocolo no nível de
rede utilizado na implementação de
Web Services
. No entanto, outros protocolos
também podem ser utilizados como, por exemplo, SMTP ou FTP. Em caso de
implementação de
Web Services

em redes locais, serviços confiáveis de troc
as de
mensagens como, por exemplo, IBM MQSeries [IBM 2001a] também podem ser
utilizados.

A segunda camada é a de troca de mensagens baseadas em XML. O protocolo SOAP
[W3C 2000b] é o escolhido para esta camada devido principalmente ao seu mecanismo
padroniz
ado de envelope de mensagens centradas em documentos ou chamada remota

Figura
1

Componentes da Arquitetura de Web Services


5

de procedimentos (RPC). Além disso, o protocolo possui uma maneira padronizada de
codificação, isto é, de transformação de tipos de dados específicos a diferentes
linguagens de programa
ção aos dados necessários para a mensagem. Maiores detalhes
sobre o protocolo SOAP serão fornecidos na próxima seção.

A próxima camada da pilha é a de descrição de serviços. Nesta camada o padrão
utilizado é o chamado WSDL. Este padrão é necessário para
que se possa interoperar
Web Services
. WSDL define a interface de comunicação com o serviço assim como a
dinâmica de interação com este. Na próxima seção, o padrão WSDL será discutido com
maiores detalhes.

Uma arquitetura composta por estas três primeiras
camadas é o mínimo necessário para
possibilitar a utilização de qualquer
Web Service
. Enquanto estas camadas apresentam
as tecnologias de interoperabilidade entre serviços, as duas próximas camadas, de
publicação e de descoberta de serviços, podem ser impl
ementadas através de uma gama
variada de soluções.

Qualquer ação que torna um documento WSDL disponível para um cliente, em qualquer
estágio do ciclo de vida deste, é qualificada como a
publicação de um serviço
. O
exemplo mais simples e estático de implem
entação desta camada é o envio de um
documento WSDL diretamente ao cliente. Esta forma de publicação, chamada de
publicação
direta, pode simplesmente utilizar o e
-
mail como veículo de comunicação. O
mecanismo de publicação direta é bastante útil para apli
cações que são ligadas
estaticamente a serviços. De maneira alternativa, o provedor do serviço pode publicar o
documento WSDL em um
broker

que poderá ser acessado posteriormente por clientes.
Neste
broker
, a principal tecnologia utilizada é o UDDI, que pod
e ser visto como o
padrão para registrar, descrever e localizar
Web Services

utilizando uma base de registro
compartilhada entre os diferentes clientes.

Figura
2

Pilha de protocolos da arquitetura de
Web Services


6

Uma vez que serviços não podem ser descobertos sem terem sido publicados, a camada
de descoberta de ser
viços depende da camada de publicação. Assim como acontece para
a publicação, um grande número de abordagens pode ser utilizado nesta camada.
Qualquer mecanismo que permite que o cliente tenha acesso a descrição do
Web Service

e a torna disponível para a a
plicação desejada em tempo de execução, pode ser
qualificado como um mecanismo de descoberta de serviços. O exemplo mais simples e
estático de descoberta é aquele no qual o cliente recupera o documento WSDL a partir
de um arquivo local. No entanto, um
Web
Service

pode ser descoberto em tempo de
projeto ou de execução, através da busca em uma base de registro comum ou
broker
.

A criação e gerência desta base de registro e descoberta, compartilhada entre os diversos
clientes, são alguns dos pontos críticos do

projeto de
Web Services
. Isto se deve à
necessidade de acesso a esta base por diferentes clientes com capacidades de hardware e
software diferentes. Desta forma, o protocolo UDDI vem sendo utilizado como
tecnologia para a implementação desta base, princip
almente por ser baseado em padrões
abertos e ubíquos. O protocolo UDDI será apresentado com maiores detalhes na
próxima seção.

A implementação de um
Web Service

pode ser encarada como a de um componente de
software. Desta forma, é natural construir novos s
erviços compondo serviços pré
-
existentes. Composições de serviços podem desempenhar diferentes papéis. Dentro de
um provedor de serviços, diferentes
Web Services

podem colaborar de forma a
apresentar uma interface única para o público. Da mesma forma, dife
rentes serviços de
diferentes provedores podem colaborar de forma a oferecer serviços mais completos ou
implementar tarefas de integração. De forma alternativa um gerenciador de workflow
pode ser utilizado chamando cada
Web Service

que participa de um proc
esso específico.
A camada mais alta da pilha, denominada
camada de fluxo entre serviços
, é a
responsável por esta tarefa, descrevendo como comunicações entre serviços,
colaboração e fluxo de dados são implementados. A tecnologia emergente para a
especifica
ção e implementação desta camada está baseada na linguagem WSFL (
Web
Services

Flow Language) [Leymann 2001]. Neste trabalho esta linguagem não será
discutida com maiores detalhes, uma vez que esta é, dentre todas as tecnologias
utilizadas na implementação
de
Web Services
, a menos estabelecida e validada.

Para que
Web Services
possam ser utilizados em aplicações reais e escaláveis alguns
requisitos de infra
-
estrutura devem ser oferecidos por cada uma das camadas da pilha.
Dentre estes podemos citar segurança
, gerenciamento e qualidade de serviço. As
soluções adotadas em cada uma das camadas podem seguir abordagens diferentes, e
atualmente não existem padrões específicos que possam ser utilizados para que estes
requisitos sejam alcançados. Acredita
-
se que, com

o passar do tempo e conseqüente
maturidade da tecnologia de
Web Services
, venham a surgir novos padrões para a
implementação destes requisitos.

3.

Protocolos

Na seção anterior foi apresentada a arquitetura conceitual de
Web Services
, baseada em
uma pilha de
protocolos já estabelecidos ou emergentes. Nesta seção os principais
protocolos das camadas de troca de mensagens baseadas em XML (SOAP), descrição
de serviços (WSDL), publicação e descoberta de serviços (UDDI) serão apresentados
com maiores detalhes. Será

apresentada também uma breve introdução a XML uma vez
que os diversos protocolos acima são baseados em XML.

7

3.1

Introdução a XML

A linguagem XML (
eXtensible Markup Language
) [W3C 2000a] foi desenvolvida pelo
W3C (
World Wide Web Consortium
) como um
profile

de

SGML (
Standard General
Markup Language
) designado principalmente para aplicações Web. A partir dessa
linguagem, é possível definir criar extensões para linguagens de marcação, através do
uso de novas tags. Dados disponíveis em documentos XML são represent
ados de
maneira semelhante à de uma fonte semi
-
estruturada. A flexibilidade oferecida pela
linguagem através da definição de novas tags e aninhamento de elementos e a facilidade
na troca de informação entre fontes distintas a credenciam como o novo padrão
para
estruturação, integração e troca de documentos na Internet.

A diferença fundamental entre um documento HTML e um documento XML é a
possibilidade de associação de um DTD (
Document Type Definition
) ao segundo. Esse
DTD define a estrutura do documento e

o conteúdo associado a cada elemento
específico, permitindo que consultas digam respeito não somente aos dados mas
também à estrutura, através de linguagens específicas para consultas sobre fontes de
dados semi
-
estruturadas. Ainda, permite que diversas fo
ntes distintas de informação
sejam facilmente integradas. Além disso, enquanto tags HTML servem para descrever a
forma na qual os dados são apresentados, tags XML servem para descrever a semântica
dos dados. Um exemplo simples de documento XML é ilustrado
na figura 3.

Uma característica importante em documentos XML é a utilização de
namespaces
.
XML

Namespaces

são uma forma simples e direta de qualificar nomes de elementos e
atributos usados em documentos XML associando
-
os através de seus prefixos a espaços
de nomes

identificados por algum URI (
Universal

Resource

Identifier
), URL (
Uniform
Resource Locator
), ou URN (
Uniform Resource Number
). Não há garantias de que
XML N
amespaces

apontem para um recurso real, na prática isso geralmente não
acontece. O uso de U
RIs se dá simplesmente porque elas são globalmente únicas na
Internet. Através de namespaces pode
-
se então diferenciar nomes iguais utilizados para
elementos que possuem semânticas diferentes.

3.2

Simple Object Access Protocol (SOAP)

SOAP [W3C 2000b] é um meca
nismo simples e “leve” (
lightweight
), baseado em
XML, utilizado para trocar dados de forma estruturada entre aplicações. Uma
mensagem SOAP é composta por três partes:

<?xml version="1.0" encoding="UTF
-
8"?>

<!
DOCTYPE location [


<!ELEMENT location (lat, long, district)>


<!ATTLIST location


system CDATA #REQUIRED

>


<!ELEMENT lat (#PCDATA)>


<!ELEMENT long (#PCDATA)>


<!ELEMENT district (#PCDATA)>

]>

<
location

system
="
GPS
">


<
lat
>
20,53
</
lat
>


<
long
>
40,23
</
long
>


<
district
>
QS
-
110
</
district
>

</
location
>

Figura
3

Exemplo de documento XML

8



Um envelope que define um framework para descrever o conteúdo da
mensagem;



Um conjunto de

regras de codificação para expressar e converter instâncias de
tipos de dados definidos em aplicações;



Uma convenção utilizada para representar chamadas e respostas remotas de
procedimentos (RPC).

O requisito básico para que um nó da rede seja capaz de p
articipar como requisitante ou
provedor de computação distribuída baseada em mensagens SOAP é a capacidade de
construir e analisar uma mensagem SOAP bem como a habilidade de se comunicar
através da rede. A integração de aplicações pode se feita usando quat
ro passos básicos,
como ilustrado na figura 4:

1.

O cliente cria uma mensagem SOAP, que é a mensagem que invoca uma
operação específica do Web Service disponibilizada pelo provedor de
serviços. O documento XML no corpo da mensagem pode ser formatado
como uma
requisição em forma de RPC ou uma mensagem centrada em
documentos conforme indicado na descrição dos serviços publicada pelo
provedor. Junto com a mensagem, o cliente envia para a infra
-
estrutura
SOAP local o endereço na rede do provedor de serviço que,
co
nseqüentemente, interage com um protocolo de rede para enviar a
mensagem para o provedor do serviço.

2.

A infra
-
estrutura de rede entrega a mensagem para o servidor SOAP que
executa no provedor de serviços, que por sua vez a encaminha para a
aplicação que exe
cuta o Web Service responsável por ela. O servidor
SOAP é o responsável pela conversão do conteúdo da mensagem XML
em objetos ou tipos específicos da linguagem que implementa o serviço.
Esta conversão é feita utilizando os esquemas de codificação
especific
ados na mensagem SOAP.

Figura
4

Seqüência de passos necessária para a integração SOAP

9

3.

O Web Service processa a mensagem de requisição e formula sua
resposta que também é uma mensagem SOAP. A mensagem então é
enviada com o endereço do cliente como destinatário para o servidor
SOAP que se encarrega de enviá
-
la através d
a rede.

4.

A mensagem de resposta é então entregue à infra
-
estrutura SOAP local
ao cliente que a redireciona à aplicação que executou a requisição. Neste
redirecionamento a mensagem XML é convertida para os tipos e objetos
específicos da linguagem que implem
enta a aplicação cliente, que em
seguida pode processar a resposta.

Uma mensagem SOAP é um documento XML que contém obrigatoriamente um
elemento envelope (
SOAP
-
ENV:Envelope
)
, um elemento opcional de cabeçalho
(
SOAP
-
ENV:Header
) e um elemento obrigatório co
ntendo o corpo da mensagem
(
SOAP
-
ENV:Body)
. O elemento
envelope

é elemento inicial da mensagem (
top
element
), e é o resposnável pelo encapsulamento do conteúdo da mensagem. Este
elemento também possui um atributo que especifica regra global de codificação
de tipos
de dados utilizada na mensagem, maiores detalhes sobre as formas de codificação serão
fornecidos a seguir. O elemento envelope deve estar sempre associado ao
namespace
http://schemas.xmlsoap.
org/soap/evelope
. Na figura 5 um exemplo simples de
mensagem SOAP é ilustrado, onde é possível verificar a utilização do elemento
envelope.

O primeiro elemento pertencente ao envelope SOAP é o cabeçalho da mensagem. O
cabeçalho é um elemento opcional, que

em geral contém informações relativas ao
cliente que enviou a mensagem. Estas informações podem ser relativas a segurança
contendo uma chave compartilhada entre o cliente e servidor SOAP utilizada para
autenticação. Outro tipo de informação que pode estar

contida no cabeçalho é um
identificador seqüencial da mensagem em uma transação composta por um conjunto de
mensagens, como ilustrado na figura 5.

O elemento que contém o corpo da mensagem,
SOAP
-
ENV:Body
, provê um mecanismo
simples para a troca de informa
ções necessárias para o destinatário final da mensagem.
Dentro deste elemento estão contidas informações relativas à mensagem de requisição
ou de resposta. Em geral são utilizados elementos cujo nome é o da operação
requisitada, e cujos filhos são os parâm
etros da requisição ou os dados de resposta da
requisição, conforme ilustrado na figura 5. O corpo da mensagem pode possuir um
elemento especial para indicar falhas no processamento da mensagem:
SOAP
-
<
SOAP
-
ENV:Envelope


xmlns:SOAP
-
ENV
="
http://schemas.xmlsoap.org/soap/envelope
"


SOAP
-
ENV:encodingStyle
="
http://schemas.xmlsoap.org/soap/encoding
"/>


<
SOAP
-
ENV:Header
>



<
t:Transaction




xmlns:t
="
http://www.teccomm.les.inf.puc
-
rio.br/ns/t
"




SOAP
-
ENV:mustUnderstand
="
1
">




2



</
t:Transaction
>





</
SOAP
-
ENV:Header
>


<
SOAP
-
ENV:Body
>



<
m:GetLocation

xmlns:m
="
http://www.teccomm.les.inf.puc
-
rio.br/ns/
t
">




<
lat
>
20.45
</
lat
>




<
long
>
43.13
</
long
>



</
m:GetLocation
>


</
SOAP
-
ENV:Body
>

</
SOAP
-
ENV:Envelope
>

Figura
5

Mensagem SOAP básica

10

ENV:FAULT
. Este elemento possui como subelementos que ex
plicitam o código da
falha ocorrida, e detalhes sobre a falha ocorrida. Uma mensagem contendo um exemplo
de utilização deste elemento é ilustrada na figura 6. Maiores detalhes sobre a formatação
do elemento de falha podem ser encontrados em [W3C 2000b].

Um

ponto importante na especificação de mensagens SOAP é a codificação de tipos de
dados utilizada. O estilo de codificação SOAP é baseado em um sistema de tipos
simples que é uma generalização das características comuns encontradas em sistemas de
tipos, lin
guagens de programação, bancos de dados e dados semi
-
estruturados. Um tipo
pode ser simples ou composto, construído como uma composição de várias partes, cada
uma com um tipo. A codificação SOAP define um conjunto de regras para a
serialização de um grafo
de objetos em mensagens XML. Através das mesmas regras é
possível executar, no sentido contrário, a transformação (desserialização) de um
documento XML em um grafo de objetos. As regras de codificação SOAP suportam
além de tipos simples, tipos polimórficos

e compostos através de estruturas (
struct
) ou
arrays.

Na verdade a especificação do protocolo SOAP provê um conjunto de regras de
codificação, mas usuários do protocolo podem definir suas próprias regras para serem
utilizadas nas suas mensagens como um
todo ou em partes delas. A especificação do
estilo de codificação é especificada através do atributo
encodingStyle

presente em
diferentes trechos da mensagem. Maiores detalhes sobre o mecanismo de codificação
podem ser encontrados na versão 1.1 da especifi
cação do protocolo SOAP [W3C
2000b].

3.3

Web Services Description Language (WSDL)

Como já mencionado anteriormente, é através da descrição do Web Service que o
provedor de serviços publica as especificações necessárias para o cliente invocar um
serviço. A desc
rição do serviço é a chave para tornar a arquitetura de
Web Services

fracamente acoplada bem como reduzir a quantidade necessária de conhecimento
compartilhado entre o cliente e o provedor de serviços. Por exemplo, o cliente não
precisa estar ciente da pla
taforma de execução ou linguagem de programação em que o
provedor de serviços está baseado e vice
-
versa. A descrição do serviço em conjunto
<
SOAP
-
ENV:Envelope


xmlns:SOAP
-
ENV
="
http://schemas.xmlsoap.org/soap/envelope/
">


<
SOAP
-
ENV:Bo
dy
>


<
SOAP
-
ENV:Fault
>


<
faultcode
>
SOAP
-
ENV:Server
</
faultcode
>


<
faultstring
>
Server Error
</
faultstring
>


<
detail
>


<
e:myfaultdetails

xmlns:e
="
http://www.teccomm.les.inf.puc
-
rio.br/e
">


<
messa
ge
>


My application didn't work


</
message
>


<
errorcode
>


1001


</
errorcode
>


</
e:myfaultdetails
>


</
detail
>


</
SOAP
-
ENV:Fault
>


</
SOAP
-
ENV:
Body
>

</
SOAP
-
ENV:Envelope
>


Figura
6

Mensagem SOAP contendo indicação de falha no processamento

11

com a infra
-
estrutura SOAP adjacente encapsula de maneira apropriada estes tipos de
detalhes tanto do cliente quanto

do provedor.

A arquitetura usual de
Web Services

utiliza o padrão WSDL [W3C 2001] (Web Services
Description Language) como base para a descrição de serviços. Um documento WSDL
é um documento XML utilizado para descrever Web Services como um conjunto de
po
ntos de serviço (
endpoints
) que operam baseados em torças de mensagens. As
operações e mensagens relativas a um serviço são então descritas de forma abstrata e em
seguidas atreladas a protocolos de rede e formatos de mensagens concretos como o
objetivo de
definir um ponto de serviço. WSDL é uma linguagem extensível e permite a
descrição de pontos de serviço e suas mensagens independentemente de que formato de
mensagens ou protocolo de rede é utilizado na comunicação.

O uso de WSDL na arquitetura de Web Serv
ices é em geral dividido em duas partes.
São elas a interface do serviço e a implementação do serviço. Deste modo cada parte
pode ser definida de maneira independente e conseqüentemente reutilizada por outras
aplicações.

Uma especificação de interface de
serviço é uma descrição de serviço reutilizável que
pode ser instanciada e implementada por diferentes implementações de serviços. Este
tipo de especificação é análogo a definição em uma linguagem de programação de uma
interface abstrata que possui diferen
tes implementações concretas como acontece em
Java [Gosling 2000] ou IDL [Siegel 1996]. Os elementos que fazem parte da interface
de serviço são:



Tipos (
types
) que provêem definições de tipos de dados que são utilizadas para
descrever as mensagens trocadas
.



Mensagens (
message
) que representam uma definição abstrata dos dados que
serão transmitidos. Uma mensagem é composta por diferentes partes lógicas que
estão associadas com uma definição contida em um sistema de tipos.



Tipos de portos (
portType
) que são
conjuntos de operações abstratas, cada uma
contendo mensagens de entrada e saída.



Ligações (
binding
) que especificam protocolos concretos além de especificações
de formatação de dados para as operações e mensagens definidas em um tipo de
porto particular.

A definição de implementação de serviço é um documento WSDL que descreve como
uma interface particular é implementada por um determinado provedor de serviços. Os
elementos que fazem parte da implementação do serviço são:



Porto (port) que especifica um en
dereço para uma ligação, definindo então um
ponto de serviço único.



Serviço (service) que modela um Web Service agregando um conjunto de portos
relacionados entre si.

Na verdade as definições de interface e implementação de serviços podem fazer parte de
um

mesmo documento WSDL como ilustrado na figura 7.

12

Atualmente estão definidas ligações de especificações WSDL para os protocolos SOAP,
HTTP e MIME. A especificação detalhada de como estas ligações são implementadas
pode ser encontrada em [W3C 2001].

<?xml version="1.0"?>

<
definitions

name
="
StockQuote
"


targetNamespace
="
http://www.teccomm.les.inf.puc
-
rio.br/location.wsdl
"



xmlns:tns
="
http://www.teccomm.les.inf.puc
-
rio.br/locationwsdl
"


xmlns:xsd1
="
http://www.teccomm.les.inf.puc
-
rio.br/location.xsd
"


xmlns:soap
="
http://schemas.xmlsoap.org/wsdl/soap/
"


xmlns
="
http://schemas.xmlsoap.org/wsdl/
">


<
types
>


<
schema

targetNamespace
="

http://www.teccomm.les.inf.puc
-
rio.br/location.xsd

"


xmlns
="
http://www.w3.org/1999/XMLSchema
">


<
element

name
="
Coordinates
">


<
complexType
>


<
all
>



<
element

name
="
lat
"

type
="
float
"/>


<
element

name
="
long
"

type
="
float
"/>


</
all
>


</
complexType
>


</
element
>


<
element

name
="
Position
">


<
complexType
>



<
all
>


<
element

name
="
district
"

type
="
string
"/>


</
all
>


</
complexType
>


</
element
>


</
schema
>


</
types
>


<
message

name
="
GetLocationInput
">


<
part

name
="
body
"

element
="
xsd1:Coordinates
"/>


</
message
>


<
message

name
="
GetLocationOutput
">


<
part

name
="
body
"

element
="
xsd1:Position
"/>


</
message
>


<
portType

name
="
LocationPortType
">


<
operation

name
="
GetLocation
">


<
input

message
="
tns:GetLoc
ationInput
"/>


<
output

message
="
tns:GetLocationOutput
"/>


</
operation
>


</
portType
>


<
binding

name
="
LocationSoapBinding
"

type
="
tns:LocationPortType
">


<
soap:binding

style
="
document
"

transport
="
http://schemas.xmlsoap.org/soap/h
ttp
"/>


<
operation

name
="
GetLocation
">


<
soap:operation

soapAction
="
http://www.teccomm.les.inf.puc
-
rio.br/GetLocation
"/>


<
input
>


<
soap:body

use
="
literal
"

namespace
="
http://www.teccomm.les.inf.puc
-
rio.br/location.x
sd
"


encodingStyle
="
http://schemas.xmlsoap.org/soap/encoding/
"/>


</
input
>


<
output
>


<
soap:body

use
="
literal
"

namespace
="
http://www.teccomm.les.inf.puc
-
rio.br/location.xsd
"



encodingStyle
="
http://schemas.xmlsoap.org/soap/encoding/
"/>


</
output
>


</
operation
>


</
binding
>


<
service

name
="
LocationService
">


<
documentation
>
Location Service
</
documentation
>



<
port

name
="
LocationPort
"

binding
=
"
tns:LocationBinding
">


<
soap:address

location
="
http://www.teccomm.les.inf.puc
-
rio.br/location
"/>


</
port
>


</
service
>

</
definitions
>

Figura
7

Exemplo de documento WSDL

13

3.4

Unive
rsal Description, Discovery and Integration (UDDI)

A especificação do padrão Universal Description, Discovery and Integration (UDDI)
define uma maneira de publicar e descobrir informações relativas a Web Services. A
primeira vista o processo de descoberta

de Web Services pode parecer simples. Na
verdade, uma vez que se sabe qual o provedor de serviços que oferece um conjunto de
operações agrupadas em serviços, o que mais é preciso descobrir? No entanto, quando é
necessário descobrir quais provedores oferec
em os serviços desejados, a capacidade de
descobrir as respostas torna
-
se muito mais complicada.

Com a intenção de resolver este problema, UDDI usa uma abordagem baseada em uma
base de registros distribuídos de provedores de serviços e suas descrições de
serviços,
implementada utilizando um formato XML comum [McKee 2001]. Conceitualmente,a
informação que faz parte da base de registro UDDI consiste de três componentes:



Páginas brancas: contêm o endereço, pessoas de contato e outros identificadores
relativos

a um provedor de serviço;



Páginas amarelas: incluem categorizações industriais baseadas em taxonomias
padrão;



Páginas verdes: contêm informações específicas sobre serviços disponibilizados
pelo provedor.

Na maioria dos casos programas e desenvolvedores us
am a base de registros UDDI para
localizar informações sobre serviços. No caso específico de programadores a utilização
está focada na preparação de sistemas compatíveis com Web Services anunciados ou
para descrever seus próprios serviços que serão utiliza
dos por terceiros.

A especificação do UDDI descreve uma nuvem conceitual de Web Services e uma
interface programável que define um framework simples para a descrição de qualquer
tipo de serviço. Esta especificação consiste em um esquema XML para a estrutu
ra de
dados [Ehnebuske 2001] e um outro que contém uma API [McKee 2001] que define um
protocolo para registro e descoberta de serviços.

O esquema XML que representa os dados em um documento UDDI possui quatro tipos
de dados principais [Ehnebuske 2001], con
forme ilustrado na figura 8:



businessEntity: contém informações relativas à entidade que publica
informações sobre uma família de serviços;

Figura
8

Informação no esquema XML do UDDI


14



businessService: contém informações descritivas sobre um serviço particular;



bindingTemplate: contém informações téc
nicas sobre um serviço e
especificações relativa s a sua construção;



tModel: contém descrições a especificações para serviços ou taxonomias. Na
verdade, tModels são utilizados como interfaces que são implementadas por
bindingTemplates.

Um outro tipo de ele
mento que também faz parte do esquema UDDI é o
publisherAssertion que possui informações relativas a relacionamento entre duas
entidades provedoras de serviços. A especificação completa destes elementos pode ser
encontrada na UDDI Data Structure Specificti
on [Ehnebuske 2001].

Estes tipos de dados fazem parte das requisições e chamadas definidas na UDDI API
Schema. Esta API define aproximadamente 25 requisições e 15 respostas formatadas em
XML utilizadas na descoberta e publicação de serviços em bases de reg
istro UDDI.
Exemplos de requisições podem ser find_service, find_tModel, save_service ou
save_business. A especificação completa de todas as mensagens pertencentes à API
pode ser encontrada em [McKee 2001].

4.

Ferramentas e Ambientes de Desenvolvimento de Web

Services

Com a grande promessa de trazer o desenvolvimento de software baseado na Internet
para um novo nível, a tecnologia de
Web Services

atraiu atenção de diversos dos
principais integrantes do mercado de software mundial. Nesta seção serão apresentada
s
de maneira sucinta algumas das iniciativas de grandes empresas desenvolvedoras de
software para o desenvolvimento e manutenção de
Web Services
.

4.1

Microsoft .NET

Microsoft .NET [Platt 2001] é um framework e um conjunto de ferramentas
pertencentes ao Visual
Studio [Microsoft 2001a] que tem como objetivo principal o
desenvolvimento, manutenção e gerência de
Web Services
. Os diferentes componentes
do framework se comunicam utilizando o protocolo SOAP, enquanto o mecanismo de
troca de mensagens é implementado at
ravés do
Microsoft Message Queuing
(MSMQ).

Embora este framework e toolkit sejam ricos em funcionalidades, grande parte deles é
baseada em tecnologias proprietárias. Em sua primeira versão, .NET não oferece
suporte à descrição de serviços através de WSDL
nem à utilização de
brokers

UDDI.
Nesta versão
Web Services
são descritos utilizando SCL (Service Contract Language) e
a descoberta é tratada através da utilização do mecanismo baseado em arquivos
denominado DISCO [Microsoft 2001b]. Neste mecanismo, interf
ace e implementação
de serviços não são separadas, impedindo a busca por serviços que implementem uma
interface específica.

4.2

SunONE

SunONE [Sun 2001] (Sun Microsytems “Open Net Environment”) é um conjunto de
produtos que oferece suporte ao desenvolvimento d
e serviços compatíveis com UDDI,
XML, WSDL e SOAP. Um exemplo de produto baseado nesta tecnologia é o ambiente
de desenvolvimento Forte que pode ser visto como um concorrente do Microsoft .NET
ou do IBM Visual Age [Akerley 1999]. Utilizando suas ferramenta
s desenvolvedores
podem construir de maneira relativamente simples
Web Services
. No entanto ele não se
15

propõe a resolver os problemas ligados à manutenção, gerência ou implementação em
ambiente de produção (deployment) de Web

Services
.

4.3

HP e
-
Speak

Hewlett P
ackard’s e
-
Speak [HP 1999] é um framework e um conjunto de componentes
para o desenvolvimento de
Web Services
. O framework oferece suporte à criação,
implementação em ambiente de produção e descoberta de
Web Services
. Os
componentes que fazem parte do e
-
Sp
eak oferecem suporte de baixo nível a
Web
Services

implementando funcionalidades de segurança e roteamento de mensagens. O
framework possibilita a utilização de uma ampla gama de padrões de serviços como, por
exemplo, SOAP, XML, UDDI, .NET e o seu próprio
J
-
ESI (Java E
-
Service Interface).
No entanto e
-
Sepeak não provê um ambiente integrado de desenvolvimento de
Web
Services
.

4.4

IBM Web Services Toolkit

O Web Services Toolkit [IBM 2001b] (WSTK) desenvolvido pela IBM provê um
conjunto de ferramentas que colabora
m no desenvolvimento de Web Services. Ele é
compatível com os protocolos SOAP, UDDI e WSDL. Uma das principais
funcionalidades do WSTK é a automação da geração de serviços a partir de interfaces
descritas em WSDL e vice
-
versa. O WSTK também permite a busca

e publicações de
informações relativas a serviços em bases de registro UDDI. Entretanto, WSTK não
provê uma infra
-
estrutura para implementação em ambiente de produção, gerência e
monitoramento de
Web Services
.

4.5

IBM TSSuite

O IBM TSpaces Services Suite [Fon
toura 2001] (TSSuite) é uma infra
-
estrutura para a
implementação de
Web Services
. O TSSuite provê uma API para a criação,
implementação em ambiente de produção, invocação e configuração de
Web Services
.
Além da API também é disponibilizado pela infra
-
estru
tura um
broker
UDDI, além de
serviços de notificação e monitoramento de serviços. A infra
-
estrutura é baseada na
tecnologia TSpaces [Wyckoff 1998]. TSpaces pode ser visto como um
buffer

de
comunicação através da rede dotado de funcionalidades de bancos de
dados. Ele permite
comunicação entre aplicações e dispositivos em uma rede de computadores e sistemas
operacionais heterogêneos, utilizando o conceito de espaço compartilhado do modelo de
programação Linda [Gelernter 1985]. TSSuite pode ser utilizado em co
njunto com o
IBM WSTK e Visual Age provendo um ambiente integrado para o desenvolvimento de
Web Services
. Entretanto por estar baseado na tecnologia de TSpaces a ubiqüidade do
protocolo HTTP não é completamente aproveitada o que pode causar problemas na
in
teroperabilidade com outros serviços.

5.

Estudo de Caso


Serviço de Impressão para Clientes Móveis

Com o objetivo de exemplificar a utilização da tecnologia de Web Services por clientes
móveis será apresentado a seguir um serviço de impressão genérico para c
omputadores
móveis. O serviço apresentado é baseado na implementação dos serviços
Intelligent
Print
e
Print Near Me

cuja implementação detalhada é descrita em [Fontoura 2001].

O principal objetivo deste serviço é solucionar problemas relativos a diversidad
e de
clientes (laptops, palmtops, telefones celulares), sistemas operacionais (Linux,
Windows, Windows CE, Palm OS), formatos de arquivos (PostScript, PDF, HTML, MS
Word) e linguagens de impressão (PCL, PostScript). Além disso, a maioria dos
16

dispositivos
móveis do mercado não possui impressora, sendo então necessário executar
a impressão de arquivos em dispositivos de impressão ligados a alguma rede fixa. Um
dos problemas que o serviço apresentado visa solucionar é a descoberta e acesso a
impressoras dispo
nibilizadas na rede fixa.

Em sistemas operacionais Windows os usuários devem instalar
drivers

específicos para
cada uma das impressoras utilizadas. A principal vantagem desta abordagem é que o
usuário pode ter acesso a características específicas de cada

impressora. Já em sistemas
operacionais do tipo Unix, através do protocolo LDP/LPR a instalação de
drivers

não é
necessária na máquina do usuário, mas o acesso a atributos especiais do dispositivo de
impressão não é garantido. A utilização da tecnologia d
e Web Services para serviços de
impressão pode aproveitar o lado bom das duas abordagens. Por manter um
acoplamento fraco entre o cliente e a impressora não é necessário para o cliente a
instalação nenhum tipo de
driver

e quando novas impressoras são adici
onadas à rede de
serviços podem ser descobertas pelos clientes.

A figura 9 ilustra o serviço proposto. No passo 1 o usuário através de um computador
móvel executa uma busca em um servidor UDDI por um serviço de impressão
localizado próximo a ele especific
ando as características específicas desejadas. O
servidor UDDI retorna então as informações necessárias para que o cliente possa se
“ligar” (binding) ao serviço. A partir do momento da ligação (2) o cliente pode fazer
requisições diretas de impressão ao se
rviço utilizando troca de mensagens SOAP, sem
se preocupar com detalhes específicos de implementação como, por exemplo,
drivers

de
impressoras. A partir da requisição o serviço de impressão pode se conectar de maneira
transparente a outros serviços como po
r exemplo serviços de conversão de tipos de
arquivos (passo 3).

Uma outra abordagem possível é a utilização de um serviço de localização em conjunto
com o serviço de impressão. Esta abordagem, utilizada no serviço
Print Near Me
,
apesar de mais complexa, po
de ser implementada de maneira simples através da
composição de serviços, como ilustrado na figura 10. Nesta abordagem o cliente móvel
solicita a impressão do arquivo desejado a um serviço global de impressão (passo 1).
Este serviço global se conecta a um
serviço de localização passando informações
relativas ao hub através do qual o computador móvel está conectado à rede sem fio (2).
O serviço de localização responde então enviando informações sobre serviço de
impressão que contém a impressora mais próxima
do cliente. Através destas

Figura
9

Serviço de impressão


17

informações o serviço global se conecta ao serviço de impressão e solicita que o arquivo
enviado pelo cliente seja impresso (3). Também através de composição de serviços,
outros serviços mais sofisticados podem ser criados, por e
xemplo, a composição do
serviço de impressão com serviços que contenham repositórios remotos de arquivos.
Desta forma o computador móvel não precisaria conter localmente o arquivo que deseja
imprimir.

6.

Trabalhos Relacionados

Existem algumas tecnologias an
teriores à definição da arquitetura de Web Services que
se dispõem a resolver o mesmo conjunto de problemas relacionados à interoperabilidade
de serviços distribuídos. Jini [Arnold 1999], desenvolvido pela Sun Microsystems, foi
um dos primeiros
toolkits

pa
ra serviços distribuídos. Jini oferece suporte para
descoberta de serviços, invocação remota de métodos (RMI), segurança, transações e
eventos. Sua utilização simplifica o desenvolvimento e invocação de serviços e
aplicações Java distribuídas principalment
e em ambientes de redes locais. Uma vez que
um serviço Jini é descoberto a infra
-
estrutura Jini transmite sua interface sob a forma de
uma classe Java que posteriormente funciona como um proxy para o serviço. No
entanto, o desenvolvimento de Jini se deu an
tes do surgimento e aceitação dos padrões
abertos que fazem parte da arquitetura de Web Services e sendo assim ele não é baseado
em nenhum deles. Desta forma interoperabilidade de Jini com outros serviços torna
-
se
bastante reduzida.

No início dos anos 90,
antes mesmo do surgimento de Jini, surgiu a tecnologia
denominada CORBA [Siegel 1996] (Common Object Request Broker Architecture)
definida pelo Object Management Group (OMG). Esta tecnologia definiu uma
linguagem para definição de interfaces (IDL) e APIs q
ue possibilitam comunicações do
tipo cliente
-
servidor entre objetos utilizando implementações específicas de Object
Request Brokers (ORB) que funcionam como o
middleware

que estabelece as relações
entre os objetos distribuídos. Em sua versão 1.0 não havia
nenhum tipo de
interoperabilidade definida entre diferentes ORBs produzidos por diferentes fabricantes.

Com o desenvolvimento da especificação 2.0 de CORBA, foi criado o protocolo IIOP
(Inter
-
ORB Protocol) através do qual os ORBs podem interoperar. No ent
anto esta
interoperabilidade não é completa, uma vez que alguns ORBs possuem otimizações
específicas que são perdidas no processo de interoperabilidade, assim como serviços de

Figu
ra
10

Serviço de impressão combinado com serviços de localização


18

mais alto nível como controle de transações e segurança . Segurança é também um
ponto importante na comparação de CORBA como a tecnologia de Web Services. Uma
vez que CORBA é baseada em um protocolo diferente do HTTP, sua compatibilidade
com ferramentas de segurança usuais na Internet como, por exemplo, firewalls é mais
complicada. Ou
tro ponto relativo à segurança que pode ser questionado é o controle
praticamente total que o objeto cliente possui sobre o objeto servidor, o que não
acontece através da utilização de SOAP que é baseado exclusivamente em troca de
mensagens.

7.

Conclusões

A t
ecnologia de Web Services surgiu há poucos anos e vem se firmando como o padrão
da indústria para a interoperabilidade de serviços distribuídos. No entanto, ainda existe
pouca pesquisa no meio acadêmico relacionada a esta tecnologia. O principal fator para

a forte aceitação de Web Services pela indústria é o fato dele ser baseado em protocolos
abertos que utilizam tecnologias amplamente estabelecidas na Internet, como HTTP e
XML.

A interoperabilidade de
Web Services

é realizada em alto nível permitindo que

clientes e
serviços sejam fracamente acoplados, separando claramente a interface da
implementação. A utilização de
Web Services

em clientes móveis torna
-
se
especialmente interessante uma vez que grande parte dos serviços necessários a eles
pode ser locali
zada na rede fixa. Os clientes podem então fazer buscas dinâmicas por
serviços utilizando bases de registro UDDI, conectar
-
se a eles e em seguida fazer
solicitações utilizando o protocolo SOAP. Apesar destas vantagens e de muitas
promessas da indústria rel
ativas a
Web Services

específicos para acesso de
computadores móveis, atualmente não existem muitos serviços deste tipo
implementados.

8.

Referências

[Arnold 1999] K. Arnold, B. Osullivan, R. W. Scheifler, J. Waldo, A. Wollrath, and B.
O’Sullivan,
The Jini Sp
ecification,
Addison
-
Wesley Pub. Co., 1999.

[Akerley 1999] J. Akerley, N. Li, and A. Parlavecchia,
Programming with Visual Age
for Java 2,
Prentice Hall, 1999.

[Ehnebuske 2001] D. Ehnebuske, C. Riegen and D. Rogers (editors), “UDDI Version
2.0 Data Struct
ure Specification,” (
http://www.uddi.org/pubs/DataStructure
-
V2.00
-
Open
-
20010608.pdf
)

[Fielding 1997] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners
-
Lee,
Hypert
ext Transfer Protocol
--

HTTP/1.1

, RFC 2068, January 1997

[Fontoura 2001] M. Fontoura et al., TSpaces Services Suíte: Automating the
development and Managing of
Web Services
, (submetido para publicação)

[Gelernter 1985] D. Gelernter, “Generative Communica
tion in Linda,”
ACM
Transactions on Programming Languages and Applications
(TOPLAS), 7(1), 80
-
112,
1985.

[Gosling 2000] J. Gosling, B. Joy, G. Steele, G. Bracha,
The Java Language
Specification, Second Edition
, Addison Wesley, June 2000

[HP 1999] Hewlett
-
Packard Company, “Ten Ways to Think e
-
Speak,” 1999,
(
http://www.espeak.net/library/pdfs/ThinkEspeak.pdf
).

19

[IBM 2001a] Web Sphere MQ Familiy Web Site, (
http://www
-
4.ibm.com/software/ts/mqseries/
)

[IBM 2001b] IBM, “Web Service Toolkit,”
(
http://alphaworks.ibm.com/tech/webservicestoolkit
).

[Kreger 2001] H. Kreger,
Web

Services

Conceptual Architecture, May 2001,
(
http://www
-
4.ibm.com/software/solutions/webservices/pdf/WSCA.pdf
)

[Leymann 2001] F. Leymann, “Web Service Flow Language (WSFL 1.
0),” 2001,
(
http://www
-
4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf
).

[McKee 2001] B. McKee, D. Ehnebuske, and D. Rogers (editors), “UDDI Version 2.0
API Specificati
on,” (
http://www.uddi.org/pubs/ProgrammersAPI
-
V2.00
-
Open
-
20010608.pdf
)

[Microsoft 2001a] Microsoft, Visual Studio .NET,
(http://msdn.microsoft.com/vstudio/nextgen/default.asp
)

[Microsoft 2001b] Microsoft, “Enabling Discovery for a Web Service,”
(
http://msdn.microsoft.com/library/default.asp?url=
/library/enus/cpguidnf/html/cpconen
ablingdiscoveryforwebservice.asp
).

[Platt 2001] D. S. Platt,
Introducing Microsoft .NET
, Microsoft Press, 2001.

[Siegel 1996] J. Siegel et al.,
CORBA Fundamentals and Programming
, John Wiley &
Sons, 1996

[Sun 2001] Sun M
icrosystems, “Open Net Environment (ONE) Software
Architecture,”(
http://www.sun.com/sunone/
).

[Wyckoff 1998] P. Wyckoff, S. W. McLaughry, T. J. Lehman and D. A. Ford,
“TSpaces,”
IBM Systems Journal,
37(3), 454
-
47
4, 1998.

[W3C 2000a] Extensible Markup Language (XML) 1.0 (Second Edition),
W3C
Recommendation 6 October 2000, [online] (
http://www.w3.org/TR/2000/REC
-
xml
-
20001006
)

[W3C 2000b] Simple Object Acce
ss Protocol (SOAP) 1.1, W3C Note, May 2000
(
http://www.w3.org/TR/2000/NOTE
-
SOAP20000508/
)

[W3C 2001] W3C, “Web Services Description Language (WSDL) 1.1,” 2001
(
http://www.w3.org/TR/wsdl
).