Acesso Remoto de um

Brao Eletrnico via Web

Service

Autor:
Marcelo Guilherme Khl

CENTRO FEDERAL DE EDUCAO TECNOLGICA DO PARAN

UNIDADE SUDOESTE
CAMPUS PATO BRANCO
ESPECIALIZAO EM INFORMTICA
DESENVOLVIMENTO EM AMBIENTE INTERNET

Acesso Remoto de um Brao Eletrnico via Web Service

MARCELO GUILHERME KUHL

PATO BRANCO - PR
2005

MARCELO GUILHERME KHL

Relatrio apresentado ao Centro Federal de

Educao Tecnolgica do Paran Unidade de
Pato Branco como requisito para a concluso do
curso

de

Especializao

em

Informtica

Desenvolvimento em ambiente Internet.

Orientador: Prof. Ademir Roberto Freddo, M. Sc.

PATO BRANCO - PR
2005

O que importa no a vitria, mas o esforo,

no o talento, mas a vontade,
no quem voc ,
mas quem voc quer ser.

AGRADECIMENTOS

A Deus pela vida,

minha famlia, principalmente esposa e filhos, que souberam
suportar a minha espera em madrugadas e fins de semana,
quando da elaborao desse projeto,
A todos os professores, em
especial, ao Orientador Prof. Ademir Roberto Freddo.
Aos amigos e colegas,
A todos aqueles que contriburam, de uma forma ou outra, para
que este grande sonho se tornasse realidade.
Sinceros agradecimentos e que Deus abenoe a todos ns.

LISTA DE TABELAS
Tabela 1 Comparao entre formatos e protocolos SOA ................................................ 16
Tabela 2 Cdigo de Falhas Genricos................................................................................ 30

LISTA DE FIGURAS

Figura 1 Estrutura SOA ..................................................................................................... 16

Figura 2 Estrutura Web Service ........................................................................................ 18
Figura 3 Estrutura Web Service ........................................................................................ 21
Figura 4 Pilha de Protocolos............................................................................................... 22
Figura 5 Envelope SOAP .................................................................................................... 27
Figura 5 Tipos de Dados SOAP.......................................................................................... 33
Figura 6 Elementos WSDL ................................................................................................. 38
Figura 7 Registro Pblico ................................................................................................... 41
Figura 7 Registro Privado................................................................................................... 42
Figura 8 Funcionamento Registro UDDI .......................................................................... 44
Figura 9 Plataforma Java ................................................................................................... 49
Figura 10 Axis ..................................................................................................................... 50
Figura 11 Mecanismo Axis ................................................................................................ 51
Figura 12 Web Container Apache Tomcat[29] .................................................................. 53
Figura 13 Instalando J2SE ................................................................................................ 54
Figura 14 Varivel JAVA_HOME.................................................................................... 55
Figura 15 Varivel de Sistema PATH .............................................................................. 55
Figura 16 Testando javac................................................................................................... 56
Figura 17 Instalando Tomcat ............................................................................................ 56
Figura 18 Instalando Tomcat - Finalizao .................................................................... 57
Figura 19 Monitor do Tomcat
Figura 20 Tomcat Iniciado .................... 57
Figura 21 Iniciando do Tomcat pelo console ................................................................... 58
Figura 22 Tomcat Iniciado ................................................................................................ 58
Figura 23 Parando o Tomcat............................................................................................. 58
Figura 24 Servios sendo removidos................................................................................. 58
Figura 25 Pgina de configurao do Apache Tomcat ................................................... 59
Figura 26 Estrutura de Diretrio Tomcat - Axis ............................................................. 60
Figura 27 Varivel CLASSPATH - Axis ......................................................................... 60
Figura 28 Axis Iniciado ...................................................................................................... 61
Figura 29 Instalando Gel 1.0 ............................................................................................. 62
Figura 30 Configurando JDK no Gel 1.0 ......................................................................... 62
Figura 31 Configurando JDK no Gel 1.0 ......................................................................... 63
Figura 32 Executando Driver UserPort ........................................................................... 64
Figura 33 Servidor Original .............................................................................................. 65
Figura 34 Cliente Original ................................................................................................. 66
Figura 35 Brao Eletro-Mecnico ..................................................................................... 66
Figura 36 Gerando JWS .................................................................................................... 70
Figura 37 WS disponvel .................................................................................................... 71
Figura 38 WSDL2Java - Distribuio Personalizada ..................................................... 72
Figura 39 Cliente via HTTP .............................................................................................. 73
Figura 40 Cliente Java ....................................................................................................... 75

SUMRIO

LISTA DE FIGURAS............................................................................................................... 7
Resumo .................................................................................................................................... 10
Abstract ................................................................................................................................... 11
CAPTULO 1 - INTRODUO ........................................................................................... 12
1.1 PROBLEMA .................................................................................................................. 12
1.2 JUSTIFICATIVA .......................................................................................................... 12
1.3 OBJETIVOS .................................................................................................................. 13
1.3.1 Geral ............................................................................................................................. 13
1.3.2 Especficos.................................................................................................................... 13
1.4 ESTRUTURA DO TRABALHO.................................................................................. 14
CAPTULO 2 FUNDAMENTAO TERICA............................................................. 15
2.1 WEB SERVICES........................................................................................................... 15
2.1.1 Arquitetura.................................................................................................................... 15
2.1.1.1 Componentes (components): ..................................................................................... 19
2.1.1.2 Papis - funes (Roles) ............................................................................................ 20
2.1.1.3 - Operaes Operations ............................................................................................. 20
2.1.2 Estrutura de Comunicao - Protocolos ....................................................................... 21
2.1.2.1 Rede de Transporte - HTTP ...................................................................................... 23
2.1.2.2 XML Extensible Markup Language ....................................................................... 23
2.1.2.3 SOAP Simple Object Access Protocol ................................................................... 26
2.1.3.1 Elementos WSDL...................................................................................................... 34
2.1.5 Envio de Anexos com Web Services............................................................................ 44
2.2 JAVA .............................................................................................................................. 48
2.3 IMAGEM DO BRAO ................................................................................................. 49
2.4 AXIS Apache Extensible Interaction Software Foundation................................... 50
2.4.1 Arquitetura Axis ........................................................................................................... 50
2.5 TOMCAT ....................................................................................................................... 53
CAPTULO 3 DOMNIO DA APLICAO ................................................................... 54
3.1 Configurando Ambiente para o Desenvolvimento ..................................................... 54
3.1.1 Instalao e configurao do J2SE: ............................................................................. 54
3.1.2 Instalao e configurao do Tomcat 5.0.28 ................................................................ 56

3.1.3 Instalao e configurao do Axis 1.1.......................................................................... 59

3.1.4 Instalando e configurao do IDE Gel 1.0 ................................................................... 62
3.2 Desenvolvendo Aplicao Web Services...................................................................... 63
3.2.1 Pr-requisitos ................................................................................................................ 63
3.2.2 Rodando projeto original .............................................................................................. 65
3.2.3 Criando Servidor WS: Classe WebComando............................................................... 67
3.2.4 Transformando Classe WebComado em uma Classe WS .......................................... 70
3.2.5 Criando WSDL Distribuio Personalizada .............................................................. 71
3.3 Desenvolvendo Cliente - Consumindo Web Services ................................................. 72
3.3.1 Via HTTP : ................................................................................................................... 73
3.3.2 Acesso Direto: .............................................................................................................. 74
CAPTULO 4 - CONCLUSO ............................................................................................. 76
4.1 Resultados ...................................................................................................................... 76
4.2 Dificuldades Encontradas ............................................................................................. 76
4.3 Perspectivas futuras ...................................................................................................... 77
REFERNCIAS ..................................................................................................................... 78

Resumo
Com o advento da Internet e o passar do tempo surgiram tecnologias de comunicao
distribuda, a maior parte delas proprietrias; embutido nessas esto as linguagens de
programao e de scripts, alm de diversas plataformas de sistemas operacionais.
Inmeros so os aplicativos desenvolvidos a partir de combinaes dessas tecnologias,
cada um usando seu prprio padro, o que acarreta falhas de comunicao entre os mesmos.
Havia a necessidade da integrao das informaes, para que facilitasse a comunicao e
integrao entre as empresas, diminuindo a redundncia dos dados, utilizando-se um banco
de dados nico, que pudesse ser acessado por diversos clientes, ao invs de cada um ter o seu
assim aproveita-se as solues j existentes, no precisando adapt-las ou integr-las a
outras, e sim unir as existentes; no influindo em quais linguagens tais aplicativos tinham sido
desenvolvidas ou em que sistemas operacionais necessitavam rodar.
Nesse cenrio, carente de uma soluo urgente, culminou com apario dos Web
Services, que no seu incio tinham como finalidade o uso apenas na web em si,
disponibilizando meios de implementar aplicaes que o mundo do desenvolvimento de
aplicaes necessitava: integrao e interoperabilidade. Realizando a comunicao atravs de
um protocolo comum de comunicao, o HTTP, com uma linguagem de troca de dados
comum, o XML, realizando o envio de mensagens atravs de um protocolo que negocia a
troca das mensagens, o qual roda sobre o HTTP, o SOAP.
Para demonstrar os conceitos de Web Services, desenvolveu-se uma aplicao a partir
de um sistema pronto, desenvolvido em Java pelo autor ROCHA, Rubens1[1]; o qual manipula
um brao eletro-mecnico pela porta paralela. Assim disponibiliza-se esse aplicativo na Web,
para que qualquer programa-cliente, possa acess-lo; independente da linguagem de
programao ou plataforma que esteja rodando esse programa.

Trabalho realizado pelo autor como projeto final de concluso da graduao.

Abstract
With the advent of the InterNet and passing of the time technologies had appeared of
distributed communication, most of them proprietors; inlaid in these they are the scripts and
programming languages, beyond diverse platforms of operational systems.
Innumerable the applicatory ones developed from combinations of these technologies
are, each one using its proper standard, what it causes imperfections of communication
between the same ones. It had the necessity of the integration of the information, so that it
facilitated to the communication and integration between the companies, diminishing the
redundancy of the data, - using an only data base, who could be had access by diverse
customers, instead of each one to have its - thus uses to advantage the existing solutions
already, not needing to adapt them or to integrate them it others, and yes to join the existing
ones; influencing in which languages such applicatory ones they had not been developed or
where operational systems needed to twirl.
In this scene, devoid of a urgent solution, it culminated with appearance of the Web
Services, that in its beginning had as purpose the use only in web in itself, to become
available half to implement applications that the world of the development of applications
needed: integration and interchange. Carrying through communication through a common
protocol of communication, the HTTP, with a language of common exchange of data, the
XML, carrying through the sending of messages through a protocol that negotiates the
exchange of the messages, which wheel on the HTTP, the SOAP.
To demonstrate the concepts of Web Services, an application from a ready system was
developed, developed in Java for the author ROCK, Rubens

[1]

; which manipulates an

electromechanical arm for the parallel door. Thus available this applicatory one in the Web,
so that any program-customer, can have access it; independent of the platform or
programming language that is writing this program.

12

CAPTULO 1 - INTRODUO
Um Web Service, doravante WS, uma tecnologia que aproveita a flexibilidade da
Internet para realizar negcios na WWW2 (VENETIENER)[2], tornando assim possvel uma
comunicao transparente entre aplicaes distintas.
A aplicao de WS, vem a suprir muitas das necessidades dos desenvolvedores de
softwares, pois consegue-se integrar sistemas computacionais de diferentes fornecedores,
tanto de plataforma como de linguagens, disponibilizando assim servios, que qualquer
sistema cliente pode acessar. Para demonstrar esta utilizao de servios, demonstra-se nesse
trabalho o acesso via Internet, de um dispositivo eletro-mecnico ligado na porta paralela que
est localizado remotamente em outro computador (servidor). Esse acesso ser feito atravs
de um programa que poder ser feito em qualquer linguagem, rodando em qualquer
plataforma.

1.1 PROBLEMA
A necessidade de demonstrar como a tecnologia de WS pode solucionar a dificuldade
existente de integrao entre as diversas solues de softwares, desenvolvidos pelas mais
variadas linguagens de programao, bem como as diferentes plataformas sob os quais os
mesmos rodam.
Alm disso, esses servios vem sendo cada vez mais utilizados e exigidos no mundo
dos negcios. Segundo artigo publicado na FonteMdia Comunicao[4] em 14/07/2005, a
empresa que quiser vender para grandes compradores, como montadoras de automveis,
aeronutica, indstria petroqumica, alimentos e de outros setores, e no tiver WS
permanentemente atualizados pode ficar fora do mercado. Fatos como estes, alavancam o
aprendizado neste quesito.

1.2 JUSTIFICATIVA
Quando se disponibiliza o acesso remoto de um dispositivo, tem-se um leque
abrangente de opes de aplicaes, sejam elas:

Acionamento de linhas de produo;

World Wide Web Rede Mundial de Computadores

13

Controle de processos e manipulao de insumos nas indstrias; obtendo-se

segurana nos meios de produo e de funcionrios;

Acompanhamento tcnico de um qualquer processo crtico ou que gere perigo ao

ser humano: desligamento de bombas explosivas, entre outros.

1.3 OBJETIVOS

1.3.1 Geral
O objetivo desse trabalho disponibilizar um WS, para prover a comunicao entre
uma aplicao desenvolvida em qualquer linguagem de programao, que esteja instalado em
computadores, rodando diferentes sistemas operacionais; para acessar o dispositivo de um
brao eletrnico (aplicao servidora j existente). Demonstrando assim como podemos
utilizar WS para promover a interoperabilidade entre aplicaes rodando em plataformas ou
linguagens heterogneas.
Dessa maneira, utiliza-se na prtica, os conhecimentos adquiridos ao longo das
disciplinas da especializao.
1.3.2 Especficos
A implementao da aplicao, para que possa demonstrar as metas lanadas,
implicar no:

Desenvolvimento do WS em uma linguagem de programao, nesse caso em Java,

utilizando-se do sistema do brao eletrnico, desenvolvido pelo autor ROCHA,
Rubens[1].

Desenvolvimento de um aplicativo cliente, o qual ir realizar as chamadas ao WS,

e demonstrar o resultado retornado por ele para o usurio.

Adaptao de uma cmera de vdeo no brao eletrnico, para que se possa

disponibilizar para o aplicativo remoto (cliente) em tempo real - a posio dos
movimentos do mesmo.

14

1.4 ESTRUTURA DO TRABALHO

Este trabalho est dividido em quatro captulos. Neste primeiro captulo est uma
introduo do assunto, a justificativa do seu desenvolvimento e os objetivos pretendidos. A
seguir a estrutura dos captulos:
Captulo

2:

traz

fundamentao

terica

das

tecnologias

utilizadas

no

desenvolvimento do WS, e uma abordagem sobre os materiais e mtodos utilizados no

desenvolvimento.
Captulo 3: Descreve os Recursos Utilizados para o desenvolvimento do sistema, a
instalao e configurao desses, bem como os detalhes do Web Service desenvolvido, tanto
no lado cliente como no lado servidor.
Captulo 4: demonstra as concluses obtidas, problemas e dificuldades encontradas e
alternativas alcanadas pela realizao deste trabalho. Alm de expressar os trabalhos futuros
que se abriram como novas perspectivas.
E por fim os dados de referncia do projeto.

15

CAPTULO 2 FUNDAMENTAO TERICA

Este captulo apresenta as concepes tericas das tecnologias utilizadas como
embasamento para o desenvolvimento do sistema.
O enfoque do projeto est em desenvolver um WS que acesse remotamente um
dispositivo - brao eletrnico. Dessa forma tornou-se indispensvel um aprofundamento no
aprendizado das relaes existentes entre as tecnologias que envolvem o WS. Ressaltando,
que no faz parte do escopo deste, o detalhamento de cada uma das tecnologias, mas sim um
relato sucinto das mesmas.

2.1 WEB SERVICES

Um WS pode ser considerado como um servio disponvel3 na WEB, o qual:

est localizado em um determinado servidor;

utiliza chamadas remotas a procedimentos RPC4 - e retornos destes, no formato

padro XML5, rodando sobre o protocolo SOAP6.

permite que diferentes empresas (clientes), mesmo utilizando tecnologias e

plataformas distintas, possam conectar-se de forma transparente, caracterstica
chamada de interoperabilidade. Isto feito atravs do entendimento da assinatura
do servio web, a qual est descrita num arquivo XML e de acordo com a
linguagem WSDL7.

utiliza-se do protocolo j existente da Internet: o HTTP. (Web Services in Java)[3]

Segue abaixo toda a estrutura tecnolgica necessria, para tornar possvel um WS,
baseado nas informaes da SISTINET[5] como tambm em HENDRICKS[7].

2.1.1 Arquitetura
Uma arquitetura de WS ocupa, dentro de uma relao, vrios componentes e
tecnologias que compreendem uma pilha de WS ou implementaes completamente

Por servio disponvel, entende-se como qualquer aplicao de software.

Remote Procedure Calls
(Chamada Remota a Procedimentos)
5
Extensible Markup Language
(Linguagem de Marcao Extensvel)
6
Simple Object Access Protocol
( Protocolo de Acesso a Objetos Simples)
7
Web Service Description Language
(Linguagem de Descrio de Servio Web)
4

16
funcionais. Componentes e tecnologias que estendem a arquitetura bsica so representadas
dentro da arquitetura estendida.
WS est baseada na arquitetura bsica SOA8, ilustrado na figura 1 e inclui tecnologias
capazes de trocar mensagens, descrever WS, publicar e descobrir WS.

Registro do
Servico

Consumidor
do Servico

Provedor do
Servico

Figura 1 Estrutura SOA

Muitas tecnologias de sistemas distribudos utilizam a arquitetura SOA, cada uma
delas com seus mecanismos prprios, o que limita ou muitas vezes, impede a troca de dados
entre os aplicativos dessas tecnologias; como mostra a tabela 1.

Mecanismo de
Invocao
Formato
de Datos
Formato troca
de informaes
Protocolo de
Transferncia
Interface de
Descrio
Mecanismo de
Publicao

Java RMI

CORBA

DCE

Web Services

Java RMI

CORBA RMI

RPC

JAX-RPC,
.NET, AXIS

Java Serializado

CDR

NDR

XML

Stream

GIOP

PDU

SOAP

JRMP

IIOP

RPC CO

HTTP, SMTP

Java Interface

CORBA IDL

DCE IDL

Java Registry

COS naming

CDS

Tabela 1 Comparao entre formatos e protocolos SOA

Service-Oriented Architeture:

(Servio Orientado a Arquitetura)

WSDL
UDDI

17
O fundamento da arquitetura WS define uma interao entre agentes ou entidades de
software, como um trocador de mensagens entre servios requisitados e provedores de
servios.
Os requisitantes so softwares agentes que requisitam a execuo do servio.
Provedores so agentes de software que provem um servio. Agentes podem ser ambos,
requisitantes e provedores. Provedores so responsveis por publicar a descrio do servio
que ele esta disponibilizando / provendo. Requisitantes devem ser capazes de encontrar as
descries dos servios. A interao entre: o provedor de servio, a agncia de servio de
publicao e requisio do servio envolve publicao, localizao e operao de unio.
Num cenrio tpico, um provedor de servio hospeda um exemplo de uma rede
acessvel atravs de agente de software. O provedor do servio precisa fazer duas aes
importantes para ter acesso a todo o potencial de um servio Web:

definir a descrio do servio para o WS em um formato padro, que seja

compreensvel por qualquer empresa que possa usar esse servio Web

para alcanar um grande pblico deve publicar a descrio para um requisitante ou

para um agente de publicao (registro central) que esteja publicamente disponvel
para todos os interessados

O requisitante do servio usa uma funo de procura (find) para recuperar a

localizao do servio localmente ou para descobrir uma agncia de publicao (ex: registro
ou repositrio) e usa o servio de descrio para ligar o WS com o provedor e invocar ou
interagir com a implementao do WS. O provedor de servio e a funo de requisitante so
desenvolvidas e um servio deve exibir caractersticas de ambas.
O uso de WS veio da necessidade da crescente comunicao de aplicativo para
aplicativo com grande interoperabilidade, e a excitao encima desta tecnologia baseada no
potencial para uma combinao de: especificaes de XML, a Internet, o SOAP e o WSDL, e
na definio de protocolos de endereamento de tarefas, muitos dos problemas dessas
tecnologias foram encontradas.
As populares tecnologias Web Service SOAP 1.1 e WSDL 1.1 foram originariamente
desenvolvidas fora do W3C, porem, seus sucessores esto agora sendo desenvolvidos dentro
das atividades do Web Service W3C9. Estas especificaes esto sendo usadas como a base
para a criao de uma arquitetura de mensagens extensvel (SOAP 1.2) e a definio de uma
interface de linguagem (WSDL 1.2).
9

Word Wide Web Consortium

(Comit Internacional de Normas para Web)

18
A figura 2 ilustra a arquitetura bsica do Web Service, na qual um requisitante de
servio e um provedor interagem, baseados no servio descrio da informao publicada
pelo provedor e descoberta pelo requisitante atravs de algumas formas de descobrimento da
agncia. O servio requisitado e os provedores interagem trocando mensagens, as quais
devem ser agregadas para o formulrio MEPs10, especificados na W3C [6].

Figura 2 Estrutura Web Service

Na figura 1, os ns do tringulo representam as funes ou papis, e as extremidades
representam as operaes. Um ou mais mediadores devem existir no caminho entre um
requisitante e um provedor. Mediadores, onde presentes, no podem interferir com o MEP.
Mediadores devem realizar certas funes associadas com a mensagem assim como rotinas,
segurana, gerenciamento, ou outras operaes. Exemplos de MEPs incluem unilateralmente,
requisies/respostas, publicao/aprovao, e transmisso.
Arquitetura de componentes bsica de WS so tipicamente definidas usando
aplicaes XML, usando definies XML, tipos de mensagens e estruturao, e usando para
transporte o http. Componentes de arquitetura estendida em WS so tipicamente definidas
usando extenses para conduzir aplicaes XML e transport-la, incluindo alternativas para o
http.
Uma mensagem definida como uma combinao que pode incluir zeros ou mais
cabealhos em adio para dados. No cabealho de uma mensagem pode incluir informao
10

Message Exchange Patterns

(padres de troca de mensagens)

19
pertinente para estender as funcionalidades, como segurana, contextos de transao,
informao de orquestrao, ou informao para roteamento de mensagens. O dado da parte
da mensagem contm um contedo de mensagem ou dados.
Um WS descrito usando um padro, uma notao formal XML, chama-se isso de
descrio do servio, que prov todos os detalhes necessrios para interagir com o servio,
incluindo formato de mensagens, transporte de protocolos, e localizao. As naturezas das
interfaces escondem os detalhes da implementao do servio ento isso pode ser usado
independentemente da plataforma de hardware ou software na qual implementada e
independentemente da linguagem em que foi escrita.
WS pode ser usado sozinho ou em conjunto com outros WS para atingir uma
agregao complexa ou uma transao de negcios.
A figura 1 ilustra a relao entre requisitantes, provedores, servios, descries, e
descobridores de servio no caso, agentes que fazem o papel de requisitantes e provedores. O
provedor de publicao, publica um arquivo WSDL que contm a descrio da mensagem e o
ponto final da informao para permitir ao requisitante gerar a mensagem SOAP e envi-la
para o destino correto.
Para implantar um MEP comum da requisio/resposta, por exemplo, uma
implementao WS prov agentes de software que funcionam ao mesmo tempo como
requisitantes e provedores. O requisitante do servio envia uma mensagem em forma de uma
requisio de informao, ou para realizar uma operao, e receber uma mensagem do
provedor do servio que conter um resultado para a requisio ou operao. O provedor do
servio recebe a requisio, processa a mensagem e envia uma resposta. A tecnologia
tipicamente usada para esse tipo de interao WS inclui SOAP, WSDL, e HTTP.
As sees seguintes provem mais definies para: os componentes, suas funes e
operaes na arquitetura WS.

2.1.1.1 Componentes (components):

Servio: considerando que um WS uma interface descrita por uma descrio de
servio, esta implementao o servio. Um servio um modulo de software desenvolvido
em plataformas de rede acessveis providos por provedores de servio. E existe para ser
chamado ou interagir com um requisitante do servio. Isto deve ser funcional tambm como
um requisitante, usando outros WS nessa implementao.

20
Descrio do servio: As descries do servio contem detalhes da interface e
implementao do servio. Isso inclui seus tipos de dados, operaes, informaes de
ligaes, e localizao de rede, poderiam tambm incluir categorizao e outros meta dados
para descobrir facilidades e utilizao pelos requisitantes. A descrio completa deve ser
realizada como um conjunto de descries de documentos XML. A descrio do servio deve
ser publicada para um requisitante diretamente ou para uma agencia descobridora.

2.1.1.2 Papis - funes (Roles)

Provedor de servio: De uma perspectiva de servio, este o proprietrio do servio.
De uma perspectiva de arquitetura a plataforma que hospeda o acesso para o servio.
Tambm sendo referenciado como um ambiente de execuo do servio ou um
compartimento do servio. Esse papel no padro de troca de mensagens aquele de um
servidor.
Requisitante do servio: de uma perspectiva de um negcio uma tarefa que requer
certas funes para ser satisfeita. De uma perspectiva de arquitetura esse a aplicao que
esta olhando para uma invocao ou inicializando uma interao com um servio. O papel de
requisitante pode ser feito por um browser dirigido para uma pessoa ou um programa sem
uma interface de usurio.
Agncia descobridora: Esta uma localizadora padro de descrio de servios onde
os provedores do servio publicam suas descries de servio. O servio de agencia
descobridora pode ser centralizada ou distribuda. A agencia descobridora pode suportar
ambos os padres onde tenha que enviar descries e onde possa ativamente inspecionar,
procurar por provedores de descries de servios. Requisitantes de servios devem localizar
servios e obter ligaes de informaes durante o desenvolvimento de ligaes estticas, ou
durante a execuo de ligaes dinmicas.

2.1.1.3 - Operaes Operations

Para uma aplicao tomar vantagens do WS, trs maneiras devem tomar lugar:
publicao das descries dos servios, localizao e recuperao das descries dos servios,
e ligaes ou invocao dos servios baseados nos servios de descrio. Essas maneiras
podem ocorrer s ou interativamente com qualquer cardinalmente entre os papis.
Em detalhes, essas operaes so:

21
Publicao: para ser acessvel, um servio precisa publicar suas descries assim
como o requisitante pode subseqentemente localiz-las.
Localizao: Na operao de localizao, o requisitante do servio recupera uma
descrio do servio diretamente ou perguntando pelo registro do servio requerido. A
operao de localizao deve ser envolvida em duas fases de ciclos de vida para o requisitante
do servio: no tempo de construo para recuperar a interface da descrio do programa
desenvolvido, e na hora de execuo para recuperar a ligao do servio e descrio da
localizao para invocao.
Interao: eventualmente, um servio necessita ser invocado. A operao de interao
do requisitante do servio invoca ou inicializa uma interao com o servio na hora de
execuo usando os detalhes da descrio da ligao para localizao, contatar, e inovar o
servio.
A figura 3 ilustra todos os componentes da tecnologia, bem como os protocolos, que
sero visto na prxima seo.

Figura 3 Estrutura Web Service

2.1.2 Estrutura de Comunicao - Protocolos
Para que ocorra a interoperabilidade entre as operaes descritas na seo anterior, so
necessrios padres para cada uma delas e para o provedor de servios, visando descrever seu

22
servio Web, sem considerar a linguagem em que ele foi escrito. Assim temos as regras ou
protocolos para que toda a troca de informaes entre aplicaes possa ocorrer,
independentemente do sistema operacional, da linguagem de programao ou do modelo do
objeto.
A implementao de WS baseada em uma pilha11 de protocolos ilustrada na figura 4;
bem com em linguagens padres da Web, dentre eles destaca-se:

HyperText Transfer Protocol (HTTP),

Simple Object Access Protocol (SOAP),

Web Service Description Language (WSDL),

Universal Description, Discover, and Integration (UDDI )

O formato XML a base de troca de informaes entre os trs ltimos padres.

Figura 4 Pilha de Protocolos

direita do diagrama da figura 4, encontram-se os blocos em camadas. Esses blocos
so conceituais, enquanto os rtulos mostrados esquerda de cada um dos blocos
correspondem s tecnologias reais (protocolos) que esto presentes em cada camada. Cada um
dos blocos construdo sobre o bloco abaixo dele.
De uma maneira geral, o protocolo SOAP define o formato que as mensagens
transportadas na rede devem ter para encaminhar requisies a servios Web. Este protocolo
tambm define o formato das mensagens de resposta s requisies. J o WSDL consiste em

11

Pilha, neste caso, significa o conjunto de todos os protocolos utilizados num sistema.

23
uma linguagem XML para a descrio de interfaces de servios, visando tornar essa descrio
inteligvel para programas que iro interagir com esses servios.

2.1.2.1 Rede de Transporte - HTTP

Essa camada da pilha de WS responsvel pela disponibilizao dos servios Web,
tornando-os acessveis por intermdio de algum dos protocolos de transporte, como: HTTP12,
SMTP13 e FTP14 entre outros descritos por TANENBAUN[9]. Como os WS so construdos
com base em padres de comunicao existentes, torna-os independentes do transporte. No
cenrio atual, o HTTP o protocolo de comunicao mais amplamente utilizado na Internet e
a maioria dos navegadores suporta HTTP.
importante observar que os WS podem ser distribudos tanto pela Internet quanto
numa rede interna, ou seja, dentro de uma empresa. Caso forem implementados para acessos
pela Internet, recomendado escolher o HTTP como o principal protocolo de rede.
Este protocolo baseia-se no paradigma requisio/resposta. Um usurio agente,
estabelece uma conexo com um servidor e envia um pedido ao servidor, o qual o analisa e
responde. A conexo deve ser estabelecida antes de cada pedido de cliente e encerrada aps a
resposta.
Quando da realizao desse trabalho, esse protocolo estava na verso HTTP/1.1, de
acordo com a W3C.

2.1.2.2 XML Extensible Markup Language

A prxima camada na pilha bsica de WS a troca de mensagens XML. Essa camada
define o formato de mensagem usado na comunicao entre aplicaes. O padro usado com
regularidade pelos servios WS o SOAP, um protocolo com base em XML para a troca de
informaes entre aplicaes, independentemente do sistema operacional, do ambiente de
programao e do modelo do objeto.
Para FURGERI[8], XML uma linguagem padronizada para troca de informaes
entre multiplataformas, no sendo apenas mais uma linguagem de marcao como o HTML e
sim uma evoluo da mesma.

12
13
14

Hipe Text Transfer Protocol

Send Message Transport Protocol
File Transport Protocol

(Protocolo de Transferncia de Hiper Texto)

( Protocolo de Transporte de Envio de Mensagens)
( Protocolo de Transporte de Arquivos)

24
Entre as diversas vantagens do XML sobre HTML, destaca-se a que est intimamente
relacionada com o escopo desse trabalho, ou seja, com WS; seja ela:
Aplicaes padronizadas para XML possibilitam que diferentes aplicativos trabalhem
em

conjunto,

trocando

informaes

entre

documento,

proporcionando

maior

interoperabilidade. Assim uma empresa que tem um sistema, desenvolvido em uma

linguagem de programao qualquer (como Delphi, Visual Basic, etc) pode disponibilizar
seus dados15 em um arquivo XML, para que outra empresa, tendo um sistema em outra
linguagem, instalado num computador com outro sistema operacional; possa acessar esse
contedo de maneira transparente.
Um documento XML contm caractersticas especiais que permitem descrever o
documento de forma inteligente, tornando o significado de seu contedo mais compreensvel
tanto para os seres humanos como para os computadores. Basicamente, este documento XML,
composto de trs elementos distintos:

Contedo dos dados: so as informaes armazenadas entre as tags16

Estrutura: a organizao dos elementos dentro do documento, que pode possuir

diversos tipos de formato, como um memorando, um contrato, de acordo com as
necessidades de marcao da informao.

Apresentao: a forma como as informaes sero apresentadas ao leitor do

documento, que pode ser de diferentes maneiras.

Segue abaixo um exemplo de um documento XML, com sua descrio e sintaxe

prpria:

15

Isto realizado atravs de ferramentas que convertem os dados que esto num formato especfico, para o
formato XML.
16
Usa-se o smbolo < >.

25
Algumas regras de um documento XML:

Todos os elementos devem estar entre as tags <nome_do_elemento> e aninhadas17

corretamente e seus nomes no devem conter caracteres especiais como e acento;

Na 1 linha do documento tem-se:

o Version (obrigatria): o valor deve ser 1.0
o Encoding (opcional): o valor deve ser uma codificao de caractere legal,
como UTF-818 ([10]), UTF-1619 ([11])ou ISO-8859-120 ([12]), no caso da
lngua portuguesa usa-se esse ltimo;
o Standalone(opcional):

o valor deve ser yes ou no; onde yes

significa que todas as declaraes de entidade necessrias esto contidas no

prprio documento, e no significa que um arquivo DTD externo
necessrio.

Na 2 linha tem-se um comentrio;

Na 3 linha tem-se o elemento raiz <monografia> sendo que essa tag fechada no
final do documento 13 linha;

Na 4 e 10 linhas tem-se elementos filhos com atributos: <autor sexo=M> e

<orientador titulao=Msc>, esses atributos devem estar entre aspas duplas ou
simples.

Entre as tags de qualquer elemento deve estar seu valor.

- XML Namespaces:
So usados para garantir que os nomes dos elementos dos seus documentos XML
sejam nicos.(SILVA)[13]. Como esses nomes podem ser inventados, existe a possibilidade
de que outro desenvolvedor possa estar usando nomes iguais aos seus elementos. Para isto
usa-se uma palavra reservada xmlns, tornando todos os elementos declarados nicos, pois o
namespace aponta para um endereo de Internet que no pode ser duplicado. Isto est
demonstrado na 3 linha do exemplo supracitado.

17

O termo aninhada refere-se ao alinhamento vertical entre as tags, ou tabulao.

Unicode Transformation Format-8 Formato 8 bits (octeto) de transformao unicode.
19
Unicode Transformation Format-16 Formato 16 bits (sistema hexadecimal de transformao unicode)
20
International Organization for Standardization - Organizao Internacional para Padronizao.
O ISO-8859-1 tambm conhecido como Latin-1, pois uma referncia a este alfabeto.
18

26
- XML Schema:
usado para definir como determinado conjunto de um ou mais documentos XML
devem ser construdos, quais os elementos eles podem conter e em que ordem. Como poder
ser o contedo desses elementos e quais os atributos eles podem conter (TESH)[14]. Quando
queremos validar um documento XML atravs de um XML schema necessrio referenciar
no cabealho daquele documento onde se localiza o arquivo de tal esquema21, como abaixo
demonstrado:

onde: tem-se a primeira declarao, xmlns:xsi, definindo um namespace para o documento, e

a seguir, atravs da declarao xsi:schemaLocation, indicada a localizao do esquema que
valida (verifica as regras) o documento XML.

2.1.2.3 SOAP Simple Object Access Protocol

Este o protocolo baseado em XML, utilizado para a troca de informaes entre as
aplicaes Web Services. A especificao SOAP, definida pela W3C, define um framework
para: a transmisso das mensagens, das chamadas e respostas de procedimentos remotos;
todas codificadas em XML. Toda mensagem SOAP empacotada num documento XML,
chamado envelope e transportada sob o protocolo HTTP, como visto na figura 4.

- Gramtica SOAP:
O envelope SOAP segue uma gramtica prpria para a sua formatao:

Partes Obrigatrias:
o Envelope: designado em uma mensagem SOAP pelo elemento
<Envelope>;
o Corpo (body): contm a carga til22 da XML, que codifica a chamada do
procedimento, as respostas da chamada do procedimento, ou o relatrio de
falhas.

21
22

Todo arquivo esquema tem seu nome com extenso .xsd

As informaes propriamente dito

27

Parte Opcional:
o Cabealho (header): pode se usado para adicionar recursos como
autenticao, gerenciamento de transao de servios. No obrigatrio,
mas, se for usado, dever vir imediatamente depois do elemento envelope
SOAP

Uma mensagem SOAP deve incluir os namespaces caractersticos da XML em

todos os elementos e atributos definidos pelo SOAP. Desta maneira os elementos
que definimos no entraro em conflito com os elementos do SOAP padro.
Assim, todas as tags XML associadas ao SOAP possuem o prefixo com o
idendificador de namespace SOAP-ENV, que est associado ao namespace
http://schemas.xmlsoap.org/soap/envelope.
o SOAP-ENV:Envelope
o SOAP-ENV:Header
o SOAP-ENV:Body

Podemos visualizar a representao grfica de um envelope SOAP na figura 5.

Transporte (HTTP)
Envelope SOAP
Cabealho SOAP
<Bloco SOAP>
...

<Bloco SOAP>

Corpo SOAP
<Bloco SOAP>
...

<Bloco SOAP>

Figura 5 Envelope SOAP

28
Segue abaixo uma mensagem SOAP e seus exclarecimentos:

Onde:

Nas linhas 1,2 e 3 tem-se o incio da mensagem SOAP que est sendo finalizada na
linha 17;

Na linha 4 inicia-se o cabealho (Header) com elemento de entrada

meuId:autenticao onde temos alm do namespace um atributo mustUnderstand
na linha 5, indicando uma entrada de cabealho obrigatria ou no. Um valor 1
indica que o receptor da

mensagem deve saber como processar o elemento

<autenticacao>. Pode-se utilizar tambm o atributo actor, sinalizando o documento

precisa visitar outros Web Services para ser processado. Na linha 10 encerra-se a
tag do elemento cabealho;

Nas linha 7 e 8 tem-se elementos filhos do cabealho: loginId e senha;

Na linha 12 tem-se a abertura do elemento corpo (Body), seguindo com elemento

de entrada checkAccountBalance

e com elemento filho accountNumber,

respectivamente nas linhas 13 e 14. O fechamento do elemento filho se d na linha

15 e do corpo se d na linha 16.
- Falhas do SOAP
Quando um programa cliente envia uma requisio a um WS, podem ocorrer falhas no
processamento da mesma. Assim o SOAP prov meios de tratamento dos erros, utilizando-se
do elemento ou tag <SOAP-ENV:Fault>, o qual aparece nas mensagens de resposta ao
programa cliente, e somente pode ocorrer uma nica vez dentro de uma mensagem SOAP.

29
Esse elemento a nica entrada de corpo definida na especificao SOAP, definindo
quatro sub-elementos, a seguir:

<faultcode>: nico elemento obrigatrio. Foi criado para proporcionar um

mecanismo fcil de identificao de uma falha. A especificao define alguns
valores gerais que devem ser usados quando ocorrer a falha. Esses valores so
definidos de maneira extensvel, para que possa permitir que um <faultcode> mais
especfico seja definido, enquanto mantm a compatibilidade com valores gerais.
A notao especfica :

GenericFaultCode.SpecificFaultCode.

Um ponto (.) usado como um separador de valores de <faultcode>, e indica

que aquilo que est esquerda do ponto um valor de falha mais geral do que o
valor direita. Um exemplo de um <faultcode> mais especfico:

<faultstring>: usado para fornecer uma explicao da falha que possa ser
entendida de forma clara. O exemplo abaixo usado em combinao com o
<faultcode> para descrever o problema exato que foi encontrado, nesta caso: um
nome de usurio ou senha esto invlidos.

<faultactor>: usado para informar qual foi o servio que causou a falha em uma
mensagem. til se uma mensagem SOAP passa atravs de vrias aplicaes
SOAP, antes de chegar a aplicao SOAP final. Assim identifica-se atravs do
<faultactor> qual das aplicaes gerou a falha.

<faultdetail>: um elemento flexvel, usado para informar qualquer mensagem

especfica de erro, como: dados fornecidos pelo cliente inexistentes ou incorretos.

30
- Cdigo de Falhas Genricos:
Na tabela 2 est a descrio e os tipos de <faultcode> genricos.
Nome do FaulCode

Significado

VersionMismatch

A parte relativa ao processamento encontrou um namespace

invlido para o elemento do envelope SOAP.
Um elemento filho imediato do elemento cabealho SOAP, que
no foi compreendido ou no foi obedecido pela parte relativa
A classe Client de erros indica que a mensagem foi formada
incorretamente, ou que no continha as informaes apropriadas,
para ser bem sucedida.
A classe Server de erros indica que a mensagem pode no ser
processada, por motivos no diretamente atribuveis ao contedo
da mensagem, propriamente dita, mas devido, mais
provavelmente, ao processamento da mensagem.

MustUnderstand
Client

Server

Tabela 2 Cdigo de Falhas Genricos

- Codificao e Tipos de Dados SOAP:

A especificao SOAP 1.1 define como os dados na carga til (body) da mensagem
podem ser codificados, adotando o sistema de tipos a partir da especificao XML Schema
Part2: Datatypes[16]. Esta define dois grupos de tipos de dados: tipos simples e tipos
complexos.
A diferena entre eles que os tipos simples no podem ter elementos filhos ou
atributos, enquanto os tipos complexos podem ter tanto elementos filhos como atributos.

Tipos Simples:

O exemplo a seguir mostra como os tipos string e int podem ser codificados numa
mensagem SOAP.

A carga til desta mensagem contm uma chamada RPC: processoReboot; cuja
finalidade reinicializar um computador remoto. Possui dois parmetros: ip e delay, que so
codificados usando os tipos de dados string e int.
Essa mesma carga til poder ser codificada da seguinte forma:

31

Onde os parmetros so especificados usando elementos que so definidos no

namespace SOAP-ENC, o qual declara um elemento para cada tipo de dados simples. O
atributo id usado para identificar somente um elemento, pois ao existir um parmetro com o
mesmo tipo no seria possvel distingu-los.
Para obter o valor especificado usa-se um acessor, que o nome do elemento que
circunda o valor do atributo id. No exemplo acima e no exemplo anterior (usando xsi:type), o
acessor para o endereo IP ip.
Existem dois tipos de valores que podem ser usados numa carga til do SOAP:

Referncia-nica: um valor acessado apenas por um acessor.

Multi-referncia: um ou mais acessores podem acessar um valor

Ao verificar o fragmento da mensagem abaixo:

Nota-se a incluso de outro parmetro, denominado requester, que usado para

especificar o endereo IP do computador onde a solicitao se originou. Neste caso, o
endereo de origem e o da mquina que ser reinicializada ser o mesmo. Para evitar
especificar o endereo IP duas vezes, transforma-se em um valor multi-referncia atravs do
atributo id. Portanto o valor do endereo IP pode ser acessado usando tanto o elemento <ip>
quanto o <requester>.

32
- Tipo Compostos:
Na definio existem dois tipos compostos:
1) Structs: So definidos como estruturas e podem ser multi-referncia, onde a
modularidade dos valores permite usar um valor mais de uma vez, como no exemplo abaixo,
onde o livro possui dois autores, ambos associados mesma informao de endereo
<Endereco-2>.

2) Arrays: So definidos como um tipo SOAP-ENV: Array ou um tipo derivado dele.

Os elementos dentro do array podem ser de qualquer tipo, inclusive arrays aninhados e
structs. No exemplo abaixo, temos a sintaxe de um exemplo de array (sua definio - onde
pode-se utilizar restries para os dados, como: tipos e valores aceitveis) e uma instncia do
mesmo. Os elementos dentro do array <meusNumerosFavoritos> so do tipo meuint, derivado
do tipo de dados int, usando o elemento restrio. O valor tambm est restrito pelo elemento
pattern23, definindo que um tipo meuint pode conter somente dois dgitos, onde o primeiro
deve ser 0 e o segundo deve ser um valor entre 0 e 9, validando os valores entre 00 e 09.

23

O valor de um elemento padro (pattern) uma expresso regular.

33
Na figura 6 temos a hierarquia de todos os tipos de dados SOAP, especificados no
XML Schema Part2: Datatypes; onde so definidos 44 tipos simples incorporados que
podem ser especificados usando o atributo xsi-type em um elemento.

Figura 5 Tipos de Dados SOAP

34
2.1.3 WSDL Web Service Description Language
Uma vez que WS permite que aplicaes se comuniquem umas com as outras atravs
de qualquer rede, usando linguagens diferentes; faz-se necessrio descrever esses servios
externos: a interface externa da aplicao ou do servio. Dessa forma outras aplicaes
conseguem adaptar-se dinamicamente aos servios oferecidos, permitindo que os programas
cliente encontrem os mtodos remotos.
A maneira padronizada para descrever os WS feita atravs de um documento que
utiliza o formato XML, chamado WSDL (Linguagem de Descrio de Web Service).
Basicamente, esse documento, define as seguintes funcionalidades do servio:

Operaes: Mtodos que esto presentes no servio Web;

Mensagem: Parmetros de entrada/sada para cada um dos mtodos;

Tipos: Tipos de dados (String, int, Object);

Tipos de Portas: Agrupamento lgico de operaes sintetizado num objeto;

Vnculo: Protocolo de transporte usado para acessar os mtodos de um objeto: as

nicas opes para o WSDL so: SOAP, HTTP e MINE24;

Endereo do Servio: URL da extremidade onde o WS ser hospedado, onde o

servio estar disponvel em um local previsvel e conhecido, assim o cliente ter
acesso de forma confivel.

Esse documento WSDL segue regras de especificao da W3C[17] , bem como criado
com uma gramtica XML especfica.

2.1.3.1 Elementos WSDL

Os elementos podem representar descries de 2 tipos:

a) Descries Concretas ou Funcionais:

<service> juntamente com o seu elemento filho <port>:

Incluem a localizao da implementao de um servio na rede; onde podem ser

especificadas diversas portas e cada uma delas especfica para o tipo de vnculo SOAP que
for descrito no elemento <binding>, assim a definio ser diferente para outros vnculos.
Dessa maneira, um WS pode ser acessvel de vrias portas, ao mesmo instante. Abaixo
segue o exemplo de um servidor Apache SOAP e uma porta separada para o vnculo do http.
24

Multipurpose Internet Mail Extensions Padro Internet para envio e recebimento de mensagens nos mais
variados formatos, alm do ASCII.[18]

35

<binding>:

Este o elemento mais complexo, pois permite inserir com uma certa liberdade, outros
elementos no seu contedo.
Este elemento descreve como um tipo de porta mapeado para um protocolo de
chamada de rede, ou seja, qual ser o mecanismo usado pelo servio para se comunicar com
um cliente, especificando como os tipos de porta sero chamados. Sendo, portanto, um
vnculo entre os elementos abstratos e concretos.
Os vnculos ou mecanismos, especificados no WSDL, podero ser o SOAP, HTTP e
MIME.
O elemento binding sempre ser seguido por um elemento especfico para o protocolo
que est usando. Se for um SOAP, o elemento <binding> ser seguido por um <soap:
binding>, o qual ter um atributo importante que o <style>, podendo ter o valor rpc ou, por
padro document. A diferena entre os dois valores a maneira de como ser a comunicao
com o servio; definindo como as mensagens individuais do SOAP so construdas:
style="rpc"

: todos os parmetros enviados para o servio sero empacotados num

elemento XML, que recebe seu nome aps a operao, definido no elemento <operation>.
Utiliza-se esse valor se o servio consistir em uma funo que utilize um conjunto de
parmetros e retornar um valor.
style="document"

: todas as mensagem so diretamente copiadas para o envelope,

sem usar mapeamento. Utiliza-se esse valor se o servio for baseado em mensagens e lidar
diretamente com documentos XML.
Abaixo segue um fragmento do documento WSDL, usado neste projeto,
exemplificando o exposto acima:

36
Outro atributo do <soap: binding> o transport, onde se define o protocolo de rede,
atravs da qual as mensagens sero enviadas, usando o namespace apropriado.
No elemento <soap: operation> est definido um atributo denominado soapAction
contendo o cabealho da ao do SOAP para o servio, que obrigatrio para solicitaes do
SOAP que so enviadas atravs de HTTP. Assim o destinatrio do envelope dessa solicitao,
usa esse campo para identificar o servio exato que invocado. Na implementao Apache
SOAP utiliza-se o atributo namespace do elemento <Body> para este fim, ignorando-se o
cabealho de ao. Neste caso, o cabealho deve estar presente contendo uma string vazia,
como no cdigo abaixo:

Tanto o elemento <input> quanto <output> contm um elemento <soap:body>,

definindo, atravs do atributo encodingStyle, como os envelopes de solicitao e reposta
sero codificados. No exemplo acima usa-se o esquema da codificao SOAP e especificados
pela mesma. Outra maneira seria XML.

b) Descries Abstratas ou No Funcionais:

<types>:

Contm a definio em XML, dos tipos de dados de entrada; que sero passados ou
retornados do WS. Estes dados devem ser passados ordenadamente ou de forma serializada,
ou seja, na ordem em que eles esto definidos no documento WSDL.

37

<message>:

Define as mensagens usadas pelo servio; os dados que podem ser trocados. A
mensagem pode ser composta de alguns argumentos: numa chamada de mtodos, todos os
parmetros deste so representados por uma nica mensagem. Este elemento <message>
possui um ou mais elementos <part> formando as partes reais da mensagem. Cada elemento
<part> refere-se a um tipo definido no elemento <types> do documento.
As referncias para os tipos das partes individuais so qualificadas por namespaces os
quais devem ser declarados no cabealho do documento XML. Abaixo segue fragmento do
cdigo WSDL deste projeto, onde temos quatro mensagens, onde as duas primeiras so do
tipo xsd: string que est declarada no cabealho:

<operation>:

Define as mensagens solicitao-resposta, usadas pelas funes individuais oferecidas

por um servio. Com as operaes obtm-se as mensagens conforme declaradas pelos
elementos <message>, em uma seqncia til. Existe quatro tipos de operaes:
1) Unidirecional: Define uma mensagem que enviada de um cliente para um
servio, sem que ocorra nenhuma resposta desse servio.
2) Solicitao-Resposta: a operao mais comum, onde um cliente envia uma
solicitao a um servio e recebe uma mensagem de resposta, como resultado dessa
solicitao. Essa operao semelhante a um RPC25. Onde temos uma chamada de funo
passando alguns parmetros e retorna um resultado.
3) Pedido-Resposta: Define uma mensagem enviada do servio para o cliente e deste
de volta para o servio.
4) Notificao: O servio envia uma mensagem ao cliente, por exemplo, uma
resposta de uma assinatura feita pelo cliente.
25

Remote Procedure call Chamada de Procedimento Remoto

38

<portType>:

Encapsula uma coleo de operaes (objeto) uma ou mais operaes.

No caso deste projeto, temos os dois elementos anteriormente descritos, representados
no cdigo abaixo:

Alm dos elementos descritos anteriormente, existem os seguintes elementos:

<definitions>: elemento raiz de cada documento WSDL, contendo todos os

atributos definindo os namespaces;

<import>: um elemento pode estar em outro arquivo fsico, normalmente utilizado

para reutilizao de definies padronizadas como interface ou tipo de dados.
Contendo dois atributos:
o namespace = definio;
o location = contm a localizao do documento importado;

A figura 6 resume os elementos de um WSDL:

Figura 6 Elementos WSDL

39
2.1.3.2 Namespaces
Sendo WSDL um documento XML, seus namespaces devem ser definidos no seu
interior, incluindo o padro que cada documento WSDL deve utilizar que :
http://schemas.xmlsoap.org/wsdl. Na tabela 3 temos os principais namespaces usados em
documentos WSDL bem como seus prefixos.

Prefixo
WSDL

http
Mime
Soapenc

Soapenv

Xsd

Descrio

Namespace de WSDL para

frameworks WSDL
Namespace WSDL para
http://schemas.xmlsoap.org/wsdl/soap
vnculo de SOAP deWSDL
Namespace de WSDL para
http://schemas.xmlsoap.org/wsdl/http
WSDL HTTP GET & vnculo
POST
Namespace WSDL para
http://schemas.xmlsoap.org/wsdl/mime
vnculo de MIME deWSDL
Namespace de codificao
http://schemas.xmlsoap.org/soap/encoding
conforme definido pelo SOAP
1.1
Namespace de envelope
http://schemas.xmlsoap.org/soap/envelope
conforme definido pelo SOAP
1.1
Namespace da instncia
http://w3.org/2001/XMLSchema-instance
conforme definido pelo
esquema XML
Namespace do esquema
http://w3.org/2001/XMLSchema
conforme definido pelo
esquema XML
Tabela 3 Namespaces WSDL

http://schemas.xmlsoap.org/wsdl/

Soap

Xsi

URI do namespace

Ser descrito na seo prximo 2.4, o uso de uma ferramenta para a gerao dinmica
de um documento WSDL.

40

2.1.4 UDDI Description Discover and Integration

A finalidade principal do UDDI publicar os WS construdos pelas empresas, afim de
que os consumidores possam localiz-los ou descobri-los. Isto feito atravs de um registro
UDDI (tambm chamado broker de servio, conforme visto na figura 1); o qual contm
informaes sobre os servios web existentes e quais as empresas que os oferecem; tornandose uma referncia para um WS disponvel. Portanto, atravs do registro UDDI que se
publica um web service e ao mesmo localiza-se um servio que se queira consumir.
Como visto na figura 4 - pilha de protocolos, na ltima camada aparece o UDDI, que
um padro para publicar ou localizar servios Web, sendo um registro universal do memso.
Este padro Universal de Descrever, Descobrir e Integrar (UDDI), permite que os provedores
de servios publiquem detalhes sobre suas empresas e os WS fornecidos em um registro
central. Esta a parte relativa descrio (Description) do UDDI.
Discovery o processo de localizar WS atravs de registros (registries). Registros de
WS so repositrios contendo documentos que descrevem dados de negcios. Registros,
tambm, proporcionam caractersticas tais como, capacidade de busca e acesso programtico
para aplicaes remotas. Usando um registro, uma organizao que deseja utilizar, por
exemplo, um servio para processar pagamentos de tickets de alimentao, pode localizar
todos os servios disponveis publicamente, que proporcionam a necessria funcionalidade. A
organizao pode comparar servios e ento decidir qual servio melhor se ajusta s
necessidades da organizao. Discovery pode ser caracterizado em:

Discovery direto:

o processo de obter dados a partir de um registro mantido por um provedor de

servio. Dados obtidos por Discovery direto so mais precisos e, portanto, confiveis, visto
que a organizao que prov a informao tambm opera o servio na Web.

Discovery indireto:

Com Discovery indireto, uma organizao obtm dados atravs de um terceiro

registro, cujos dados podem no ser precisos, porque provedores de servio poderiam no
atualizar as informaes nesse registro to freqentemente. Quando realiza-se Discovery
indireto, organizaes deve-se ter em mente as seguintes questes: registros de terceiros
interagem com provedores de servio para garantir que os dados so ainda precisos, com qual
frequncia? Embora Discovery indireto tenha seus inconvenientes, por no ser totalmente

41
confivel, ele ainda permite avaliar servios de vrios provedores antes do compromisso para
usar um servio particular.
2.1.4.1 Especificaes UDDI (Padres)
Criou-se uma comunidade, chamada uddi.org[19], para a criao de especificaes e
padres de como um registro UDDI armazena dados e como ele pode ser acessado. So
quatro as principais especificaes (HENDRICKS)[7]:

Estrutura de Dados: baseado em XML;

API do programador, que so de dois tipos:

o Funes de Publicao: criao e atualizao de entradas existentes no
registro; requer login e senha de usurio, que so fornecidos no ato do
registro UDDI.
o Funes de Pesquisa: permites a consulta (leitura) das entradas.

Replicao: informaes de como registros podem trocar informaes entre si;

Operador: Aqui esto as polticas de segurana, definindo login, usurio e

gerenciamento dos dados.

Atualmente, essas especificaes encontram-se na verso 3.0 Beta.

Na home page http://uddi.org encontra-se links para alguns registros pblicos como
da IBM, HP e Microsoft, onde pode-se fazer um cadastro e registrar um servio web, neste
caso, tem-se um registro pblico. Como exemplo deste tipo de registro, na figura 7 pode-se
visualizar um WS de um fornecedor, sendo descoberto por uma empresa X.

Figura 7 Registro Pblico

42
Alm do registro pblico, h as seguintes modalidades de registro:

Privado:

Usa-se essa modalidade para reaproveitamento de sistema-software, em empresas com

diversas subsidirias, ou departamentos. Para que se torne possvel essa reutilizao de
solues j prontas, as quais esto rodando em determinado ponto da empresa - necessrio
ultrapassar os limites de linguagem de programao e sistemas operacionais. Alm da
necessidade de um catlogo dessas aplicaes, para que se possa descobri-las facilmente.
Assim, busca-se a soluo em WS, onde: um documento WSDL fornece a descrio do
servio e um UDDI privado fornece o meio de descoberta para que outros funcionrios da
empresa, em outros departamentos ou filiais possam descobri-los.
Na figura 8 resume-se o exposto acima.

Figura 7 Registro Privado

Semi-privado:

Tambm pode ser conceituado como registro hbrido, onde um registro s pode ser
acessado com permisso de parceiros comerciais ou clientes, assim a empresa proprietria do
servio tem segurana em seus sistemas estratgicos ou vulnerveis em demais para serem
expostos ao pblico.

43
2.1.4.1 Arquitetura UDDI

Pode-se acessar todos os web services existentes a partir de apenas um dos domnios
pblicos; pois todos os diretrios UDDI pblicos duplicam as informaes publicadas em
qualquer outro domnio.
As informaes em um registro UDDI podem so compostas de trs tipos de entradas
(POTTS)[20] :

Pginas Brancas: Nelas encontram-se informaes legveis por humanos, ajudando

na avaliao do servio oferecido, como: nome e telefone para contato, alm do
Dun & Bradstreet D-U-N-S Number26.

Pginas Amarelas: contm classificaes usando vrios sistemas taxonmicos27;

facilitando sua localizao. Na verso 1 do UDDI, eram fornecidas trs
taxonomias, categorizao:
o Da indstria NAICS;
o De projeto e servio UNSPC;
o Geogrficas ISSO-3166-2.

Pginas Verdes: Contm detalhes de programao de um cliente que venha a

solicitar o servio; sendo uma espcie de dicionrio de dados para o servio.

2.1.4.2 Funcionamento e Programao com Registro UDDI

A figura 8 representa o funcionamento de um registro UDDI, que igual a qualquer

outro web service. As APIs na especificao UDDI, so definidas em XML, inseridas no
envelope SOAP e enviadas por HTTP. Quando as requisies de cliente que necessitar
alterao de dados, estas precisam ser protegidas e autenticadas.

26

Data Universal Numbering System (Sistema Universal de Numerao de Dados), mantido pela Dun &
Bradstreet. Esse cdigo de nove dgitos um identificador universal de empresas, reconhecido
internacionalmente junto ao EDI (Electronic Data Interchange), bem como as transaes de comrcio
internacional. Identifca e conecta mais de 72 milhes de empresas internacionais, sendo reconhecido,
recomendado ou exigido pelas mais importantes organizaes, indstrias e associaes do mercado
internacional.
27
Taxonomia uma cincia de classificao, que lida com a descrio, identificao e classificao dos
organismos, individualmente ou em grupo.

44

Figura 8 Funcionamento Registro UDDI

A estratgia de busca UDDI usa um modelo tcnico chamado tModel, onde tem-se
chamadas de mtodos padro, assim basta ao programador implement-lo para reunir
informaes do registro sobre WS. Abaixo segue alguns mtodos das APIs:

Mtodos de Chamada:
o Find_business(),

Find_service(),

Get_businessDetail(),

Find_binding(),

Get_serviceDetail(),

Find_tModel(),

Get_bindingDetail(),

Get_tModelDetail(), Get_registeredInfo();

Mtodos de Publicao:
o save_business(),

save_service(),

save_binding(),

save_tModel(),

delete_business(), delete_service(), delete_binding(), delete_tModel(), .

As chamadas so realizadas ao registro usando SOAP, exatamente como feito em

outro WS.

2.1.5 Envio de Anexos com Web Services

Uma das desvantagens dos WSs est relacionado com formato XML, pois ao se
converter tudo para caracteres, torna-se invivel a transmisso de certos tipos de dados como
imagens e cdigos executveis. A soluo para essa dificuldade encontra-se no envio desses
arquivos (imagens, fotos, executveis dados binrios) como anexo em uma mensagem
SOAP. Isso pode ser feito usando alguns mtodos como:

45

Codificao Base64

Converte dados binrios em caracteres que so entendidos pelo XML. Essa

codificao toma 3 bytes de dados binrios (cada byte contm 8 bits), e os combina em um
agrupamento de 24 bits; depois os recombina em grupos de 6 bits, armazenando-os como se
fossem caracteres ASCII, cada um desses 6 bits usado como ndice de caracteres no
alfabeto Base64. De modo que ser enviado para o WS um conjunto de 3 caracteres, os quais
no lado servidor, sero traduzidos (decodificados) mais uma vez.
O fato da codificao e decodificao dos dados implica em mais consumo de recursos
tanto do cliente como do servidor, alm de termos um aumento na mensagem enviada aps
sua codificao. Esses fatores podem ocasionam baixo desempenho em sistemas onde a
largura de banda pequena, como nos casos dos web services sem fio.

MIME (Multipurpose Internet Mail Extensions)

Em 1992 foi lanado este padro para envio de anexos em e-mail, que poderiam conter
imagens, udio, vdeo, vrios anexos na mesma mensagem, alm de arquivos binrios.
Seu funcionamento inclui os seguintes cabealhos:
o Content-Type: especifica o tipo e o subtipo dos dados que esto sendo
enviados no anexo, podendo ser: texto, imagem, udio, vdeo, mensagem,
multiparte (combinao de outros tipos em uma nica mensagem) e
aplicao (dados binrios).
o MIME-Version: especifica a verso do MIME.
o Content-Transfer-Encoding: especifica o tipo de codificao, podendo ser o
Base64
o Content-ID: especifica referncias de um anexo para outro;
o Content-Description: mensagem descritiva do anexo.

DIME (Direct Internet Message Encapsulation)

um padro alternativo para ser usado no lugar do MIME, sendo menos flexvel que
este, pois baseado num formato de mensagem mais simples. Foi desenvolvido
especificadamente para ser usado junto com o SOAP, acrescentando anexos a mensagens de
WS. Seu cabealho contm poucas informaes sobre os anexos, pois seus detalhes esto no
corpo do SOAP.

46
Uma mensagem DIME pode ter um ou mais registros DIME, cada um deles contendo
informaes sobre seu prprio contedo, usando Content-Type e subtipos MIME para
identificao dos registros.
Antes de cada registro, so usados para identificao de seus dados, bits num formato
fixo, tornando o processamento muito mais rpido do que o formato livre do MIME. No
exemplo abaixo temos uma mensagem DIME.

Os bits das linhas 1, 2 e 3 do cdigo acima, identificam os seguinte dados:

o Version (5 bits) Verso da mensagem DIME;
o MB (1 bit) Indicador de primeiro registro;
o ME (1 bit) Indicador de ltimo registro;
o CF (1 bit) - Chunked Flag: Indica se um registro foi dividido em partes por
convenincia na transmisso do documento;
o TYPE_T (4 bits) Informaes de estrutura e formato do campo TYPE;
o OPTIONS_LENGTH (16 bits) O comprimento do campo OPTIONS.
o ID_LENGTH (16 bits) O comprimento do campo ID.
o TYPE_LENGTH (16 bits) O comprimento do campo TYPE.
o DATA_LENGTH (32 bits) O comprimento dos dados.
o OPTIONS Qualquer informao enviada pelo codificador DIME.
o ID- Um URI para identificar o payload.
o TYPE O URI de referncia de tipo ou o tipo e o subtipo MIME do
payload.
o DATA Os dados propriamente dito.

47
Atravs daqueles dados, um parser pode determinar exatamente o que so dados no
registro, onde eles comeam e terminam. Sendo que o primeiro registro contm a prpria
mensagem SOAP, os demais registros DIME viro a seguir, sempre usando o mesmo uuid,
assim o WS ter certeza da identidade do anexo.

SOAP 1.2 Attachment Feature (Funo de Anexo)

Definida como especificao pela W3C[21], nessa proposta de projeto o receptor SOAP
determina com base na mensagem SOAP principal, se deve ou no processar os anexos; tanto
o DIME quanto o MIME podem ser usado, definindo trs possibilidades para o envio dos
anexos:
o DIME: Mensagem principal SOAP e o anexo podem ser encapsulados em
uma nica mensagem DIME, enviados atravs dos protocolos TCP ou
HTTP;
o MIME: Mensagem principal SOAP e o anexo podem ser encapsulados em
uma nica mensagem DIME, enviados atravs do protocolo HTTP;
o A mensagem principal SOAP pode ser trocada usando a vinculao http
sem qualquer encapsulao, e a transmisso do anexo usar uma requisio
separada. Assim envia-se apenas os dados descrevendo o anexo juntamente
com instrues sobre como realizar a transferncia.

Esta especificao traz um alerta quanto a envio de mensagens com anexos do tipo
application/post-crip e do tipo mdia message/external-body, pois os mesmos podem
conter vrus.

48

2.2 JAVA
O Java foi criado como parte de um grande projeto da Sun Microsystems, Inc., cuja
misso era desenvolver aplicativos complexos e avanados para aplicao em pequenos
dispositivos eletrnicos. ao mesmo tempo um ambiente e uma linguagem de programao
fortemente orientada a objetos. Atualmente, utilizado nos mais diversos ambientes: como
internet, dispositivos mveis, sistemas distribudos (O QUE JAVA) [15]
Sendo uma linguagem totalmente orientada a objetos, todos os elementos dos
programas so tratados como se fossem objetos. Os objetos podem ser variveis, sub-rotinas
ou a prpria aplicao. A idia que existe por trs das linguagens orientadas a objetos que
um objeto pode incluir tanto dados quanto cdigo: um objeto "nmero", por exemplo, poderia
incluir o valor do nmero e o cdigo necessrio para apresent-lo.
Os aplicativos em Java so compilados em um cdigo de bytes independente de
arquitetura. Esse cdigo de bytes pode ento ser executado em qualquer plataforma que
suporte um interpretador Java. O Java requer somente uma fonte e um binrio e, mesmo
assim, capaz de funcionar em diversas plataformas, o que faz dele um sonho de todos os que
realizam manuteno em programas.
O Java compilado e independente de plataforma: Um programa escrito em Java
precisa ser compilado antes de ser executado. O compilador traduz o cdigo-fonte e gera
arquivos objeto chamados arquivos de classe. Cada programa Java consiste da implementao
de uma nica classe. Depois de compilado, pode ser executado em qualquer plataforma onde
exista um sistema de tempo de execuo Java (runtime).
Ao utilizar o compilador Java - javac, voc estar compilando cdigo-fonte Java em
cdigo de bytes. Esses cdigos de bytes contm instrues independentes de mquina. Em
seguida, o interpretador do Java, tambm chamado de Java, e parte do ambiente de execuo
do Java, interpreta esses cdigos de bytes. Ao criar uma unidade de compilao do Java, cada
um dever ter um sufixo .java. Existem ferramentas IDE28, de uso livre que fazem essa tarefa
automaticamente como o Gel, o qual foi utilizado neste trabalho.

28

IDE (Integrated Dvelopment Environment) - Ambiente Integrado de Desenvolvimento.

49
A linguagem Java pode ser considerada como uma plataforma de desenvolvimento,
uma vez que ela d suporte a trs diferentes reas de programao, conforme ilustrado na
figura 9 (Java 2 Software The Platforms) [22] :

Figura 9 Plataforma Java

J2EE (Java 2 Enterprise Edition): Plataforma Java, com ferramentas especficas

para o desenvolvimento de aplicaes corporativas distribudas e multicamadas.

J2SE (Java 2 Standart Edition): Plataforma especfica para construo e

desenvolvimento de aplicaes cliente. Possui boas ferramentas para o trabalho de
aplicaes WEB, intranets e comrcio eletrnico.

J2ME (Java 3 Micro Edition): Plataforma Java com ferramentas especficas para o
desenvolvimentos de aplicativos que rodam em pequenos dispositivos mveis,
como: celular, smart cards e pagers.

2.3 IMAGEM DO BRAO

Ao utilizar o WS proposto neste projeto, faz-se necessrio o uso de um aplicativo
instalado no servidor, que capture as imagens (atravs de uma cmera digital) dos
movimentos feitos pelo brao eletrnico em tempo real. Assim o usurio/cliente ao enviar
qualquer um dos parmetros necessrios para este servio, ter a viso da posio ou dos
movimentos aplicados no dispositivo.
Optou-se neste projeto, na utilizao de um software pronto para aquela finalidade.
Dentre alguns, utilizados e recomendados para a utilizao de videoconferncia[23], optou-se
pelo aplicativo da Microsoft MSN Mesenger verso 7. Uma vez instalado no computador do

50
cliente, basta rodar o programa e selecionar a opo udio/vdeo que est na aba aes, para
aceitar recebimento das imagens enviadas pelo servidor.

2.4 AXIS Apache Extensible Interaction Software Foundation

Axis um projeto de fonte aberta da Apache Software Foundation[24]. Esse projeto
uma ferramenta de desenvolvimento WS, tambm chamado de framework29, o mesmo deve
estar instalado como um novo contexto, dentro de um servidor web bsico. Neste projeto
utilizou-se do servidor Tomcat abordado na prxima sesso.

2.4.1 Arquitetura Axis

Esse framework (AXIS)[25] faz uma ligao entre o processador SOAP e a lgica
comercial que est rodando no servidor; pois a lgica comercial mantida separada da lgica
de processamento, como mostrado na figura 10.

Figura 10 Axis
A arquitetura do Apache Axis foi construda sobre o mecanismo SOAP, tanto para
servidores como para clientes, escrito com a linguagem Java, embora na verso recente 1.2 j
tenha uma implementao no lado cliente na linguagem C++.
Como mecanismo ou engine SOAP tem as seguintes funcionalidades principais:

aceitar e analisar sintaticamente mensagens do protocolo SOAP;

chamar mtodos e funes apropriados no Web Service implementao de

classes Java;

29

Utilizar containers JSP para disponibilizar os web services na rede.

Definido como um conjunto de suporte para projetos de softwares, podendo incluir bibliotecas de cdigos
binrios prontos, suporte a programas.

51

O mecanismo Axis constitudo de alguns subsistemas que esto detalhados na figura

11, os quais trabalham juntos para que ocorra todo o processamento das mensagens SOAP,
entre o cliente e o WS. Abaixo a descrio de cada um dos subsistemas:

Figura 11 Mecanismo Axis

Handlers (controladores):

uma sub-rotina de programa com uma tarefa especfica, sabe como responder a
determinados eventos, tornando-se controladores desses. No Axis um handler pode registrar a
mensagem, outro pode decriptograf-la, outro pode fazer as chamadas ao sistema legado. Os
handlers so chamados diretamente pelo Axis e no por um mtodo main().

Cadeias:

um tipo especial de handler que contm outros handlers, e estes podem ter outras
cadeias. A execuo das mesmas feita de forma ordenada (encadeamento dos componentes),
dessa forma o Axis tem o controle da mensagem entre cada componente do mecanismo. A
sequncia completa de handlers compreende trs cadeias: transporte, servio e global. Cada
uma com suas funes especficas. Como a cadeia de destino, que contm mais de um ponto

52
de entrada, tendo duas funes: receber e enviar mensagens atravs de um nico handler de
transporte (AXIS ARCHITECTURE GUIDE) [26].

Dispatcher (despachante):

o componente responsvel por chamar o servio web destino, que como j vimos,
pode ser implementado em qualquer linguagem de programao. O Axis descreve diferentes
dispatchers para vrios tipos de servios, os quais esto descritos numa estrutura XML
chamada de WSDD30. Utilizando o WSDD do Axis, a classe gerada ser um front-end para o
acesso, basta instanciar esta classe na aplicao cliente e chamar os mtodos pblicos do WS,
assim a aplicao cliente no precisar importar as bibliotecas do Axis.
Com o uso do WSDD, o dispatcher separa a lgica comercial da lgica do handler,
convertendo mensagens SOAP em objetos Java: determinando o mtodo a ser chamado e
verificando se os tipos dos argumentos de entrada codificados em XML combinam com os
tipos de parmetros solicitados do mtodo resultante e, depois, faz chamadas ao WS; isto
feito pelo componente RPCDispatcher.

Listener de Transporte:

Como mostrado na figura 10, entre o cliente e o Axis, tem-se o transporte o qual
possui duas cadeias: recepo e transmisso. Estas so servlets especiais que esto na espera
de uma mensagem SOAP e informam ao mecanismo o protocolo usado no transporte, como
abaixo especificado:
o Receptor de Transporte: Composto de uma cadeia com trs controladores:
Desserializador, Canonizador e Roteador. Essa cadeia recebe as mensagens
HTTP do cliente, e as prepara como uma fonte de entrada para anlise do
XML, este convertido num formato nativo de linguagem de programao,
no caso o Java, depois criado uma mensagem de sada para o dispatcher,
contendo informaes de onde e como retornar a mensagem de resposta.
o Remetente do Transporte: Essa cadeia consiste de apenas um controlador:
Serializador, o qual converte a mensagem num fluxo XML e encapsula os
detalhes do protocolo de rede, enviando as mensagens do http para a
camada de transporte da rede.

30

Web Services Deployment Descritor (Descritor de organizao de servios web)

53

2.5 TOMCAT
um projeto de software livre e cdigo aberto desenvolvido pela Fundao Apache,
dentro do projeto Apache Jakarta[27]

e oficialmente endossado pela Sun como a

Implementao de Referncia (RI) para as tecnologias Java Servlet e Java Server Pages (JSP).
O Tomcat um servidor de aplicaes Java para web, ou um Container Web; fazendo parte da
plataforma Java 2EE, abrangendo as tecnologias Servlet e JSP, incluindo outras tecnologias
de apoio, como JDBC DataSources31. O Tomcat tem a capacidade de atuar tambm como
servidor web/HTTP, ou pode funcionar integrado a um servidor web dedicado como o
Apache httpd ou o Microsoft IIS.[28] . Neste projeto est instalado como um simples servidor
web, como representado na figura 12; num contexto Axis, o qual chamar arquivos com
extenso jws (Java web services), que so os arquivos com cdigo fonte da aplicao
servidora WS.

Figura 12 Web Container Apache Tomcat[29]

31

Drive para conexo de dados.

54

CAPTULO 3 DOMNIO DA APLICAO

Neste captulo iremos abordar a instalao das tecnologias anteriormente apresentadas,
configurando o ambiente para o desenvolvimento da aplicao WS para o brao eletrnico
(servidor da aplicao) e uma aplicao cliente para acessar esse WS.

3.1 Configurando Ambiente para o Desenvolvimento

Antes de instalar o servidor Tomcat e o Axis, que trabalham com a tecnologia Java,
deveremos ter no mnimo a verso Java2SE instalada na mquina. A seguir os links para fazer
o download das ferramentas:

J2SE 1.4.2.08: http://java.sun.com/j2se/1.4.2/download.html;

Tomcat 5.028: http://jakarta.apache.org/site/downloads/downloads_tomcat-5.cgi

Axis 1.1: http://ftp.pucpr.br/apache/ws/axis/1_1/axis-1_1.zip;

Gel 1.0: http://pucpr.tucows.com/files3/Gel86a.zip.

JAF 1.02: http://java.sun.com/products/javabeans/glasgow/jaf.html

3.1.1 Instalao e configurao do J2SE:

Uma vez feito o download do arquivo instalador do Java: j2sdk-1_4_2_08-windowsi586-p.exe, basta prosseguir com a instalao conforme figura 13.

Figura 13 Instalando J2SE

55
Depois de escolhida a pasta de instalao, deve-se criar uma varivel de ambiente
denominada JAVA_HOME com o caminho de referncia para a pasta onde est instalado o
J2SE, conforme ilustrado na figura 14.

Figura 14 Varivel JAVA_HOME

Deve-se inserir na varivel de sistema PATH, o caminho das pasta /bin e /lib do J2SE,
conforme figura 15.

Figura 15 Varivel de Sistema PATH

Para verificar se o caminho das duas variveis: JAVA_HOME e PATH, foram
configurados corretamente; dever aparecer a tela mostrada na figura 16, ao entrar no modo
prompt e executar o arquivo javac de qualquer pasta, pois este arquivo est no seguinte
caminho: C:\JDK1.4.2\BIN.

56

Figura 16 Testando javac

3.1.2 Instalao e configurao do Tomcat 5.0.28
Aps o download do arquivo jakarta-tomcat-5.0.28.exe, prossegue-se com a instalao
do mesmo, aceitando as configuraes sugeridas pelo instalador, ficando por padro a pasta
onde o mesmo ser instalado C:\Arquivos de programas\Apache Software Foundation\Tomcat
5.0; a porta de conexo para o protocolo HTTP (8080); o usurio Admin e a senha em branco,
como na figura 17.

Figura 17 Instalando Tomcat

57
Ao prosseguir clicando-se no boto Next, temos mais uma importante janela, pois o
instalador procura onde est instalado a verso da JVM32 do Java e automaticamente traz
para a janela, conforme figura 18. Por isso instala-se primeiro a verso do Java e depois o
Tomcat. A seguir clica-se no boto Install para terminar a instalao do Tomcat.

Figura 18 Instalando Tomcat - Finalizao

Existem algumas maneiras de iniciar o Tomcat:

Como processo via monitor: iniciando o monitor do Tomcat, atravs do boto

Iniciar do Windows Programas Apache Tomcat 5.0 Monitor Tomcat, quando
aparecer o cone do Tomcat localizado ao lado do relgio, na barra de tarefas no
canto inferior esquerdo do monitor, conforme figura 19. Clica-se com o boto
direito do mouse neste cone e escolhe-se Start Service para iniciar o servidor
Tomcat, notando-se que o cone torna-se verde, conforme figura 20.

Figura 19 Monitor do Tomcat

Figura 20 Tomcat Iniciado

Como processo via console: executando-se o arquivo startup.bat para

iniciar - figura 21; e shutdown.bat pra o processo - figura 23,
removendo
arquivos

32

parando

todas

encontram-se

Java Virtual Machine - Mquina Virtual Java

na

as

pasta

classes
bin

do

inicializadas.
Tomcat.

Ambos

Nota-se

que

os
ao

58
executar o comando abre-se uma segunda janela no console, onde so
carregados os servios do Tomcat, com data e hora de incio de
carregamento das vrias classes, na figura 22 tem-se apenas a
primeira classe e a informao final do estado do servidor; ou
finaliza-se os servios, conforme ilustrado na figura 24.

Figura 21 Iniciando do Tomcat pelo console

Figura 22 Tomcat Iniciado

Figura 23 Parando o Tomcat

Figura 24 Servios sendo removidos

59
Para certificar-se que o servio foi iniciado, abre-se o browser digitando a seguinte
URL: http://127.0.0.1:8080, dever ser exibida a tela da figura 25.

Figura 25 Pgina de configurao do Apache Tomcat

Tem-se nessa pgina alguns links para:

Administrao:
o Status: Permite monitorar o estado do servidor;
o Tomcat Administration: Permite criar, excluir e configurar Servios e seus
elementos internos do Servidor Tomcat, bem como Recursos e
Autorizaes.
o

Tomcat Manager: Permite gerenciar as aplicaes;

Documentao: Release Notes, Chang Log e Documentao do Tomcat;

3.1.3 Instalao e configurao do Axis 1.1

Aps o download do arquivo axis-1_1.zip, necessita-se fazer a descompactao do
mesmo para uma pasta sugestiva como C:\axis-1.1; e copiar toda a sub-pasta denominada axis

60
que est dentro da pasta weapps para dentro da pasta webapps do Tomcat, criando dessa
maneira um contexto web para o axis. A estrutura de diretrios deve ficar conforme figura 26.

Figura 26 Estrutura de Diretrio Tomcat - Axis

Deve-se incluir na varivel CLASSPATH, o caminho de todos os arquivos do Axis,

como ilustra a figura 27, sejam eles:

C:\axis-1_1\lib\axis-ant.jar;

C:\axis-1_1\lib\axis.jar;

C:\axis-1_1\lib\commons-discovery.jar;

C:\axis-1_1\lib\commons-logging.jar;

C:\axis-1_1\lib\jaxrpc.jar;

C:\axis-1_1\lib\log4j-1.2.8.jar;

C:\axis-1_1\lib\saaj.jar;

C:\axis-1_1\lib\wsdl4j.jar;.;

Figura 27 Varivel CLASSPATH - Axis

61
Agora o servidor Tomcat deve ser reiniciado para que o framework Axis seja iniciado.
Para testar esse contexto Axis, abre-se o browser digitando a seguinte URL:
http://127.0.0.1:8080/axis/, dever ser exibida a tela da figura 28.

Figura 28 Axis Iniciado

Esta pgina possui dois links importantes:

Validate: serve para validar a instalao: clicando nele ser apresentado uma lista
de componentes necessrios ("Needed Components"). Caso algum desses no seja
encontrado, ele ir solicitar a instalao; como por exemplo o componente JAF
1.02

(activation.jar),

qual

deve

ser

instalado

em:

C:\Arquivos

de

programas\Apache Software Foundation\Tomcat 5.0\webapps\axis\WEB-INF\lib

View: serve para visualizar os web services j instalados: clicando nele, sero
exibidos dois web services e, clicando no link (wsdl), voc ver o arquivo de
especificao de ambos. Se, ao clicar, no aparecer nenhuma informao, no se
preocupe, alguns navegadores no exibem XML, outros exibem como HTML,
sendo necessrio abrir o cdigo fonte da pgina para ver o seu contedo. Mas ele
estar l, e funcionando.

62
3.1.4 Instalando e configurao do IDE Gel 1.0
Aps o download do arquivo gel.exe, basta seguir os passos do arquivo instalador
como na figura 29:

Figura 29 Instalando Gel 1.0

Aps sua instalao, ser criado um cone no seu desktop, como atalho para o
programa, bastando dar um duplo clique com o mouse para que o mesmo seja aberto. Estando
pronto para edio de arquivos Java, html, jsp, servelts entre outros.
Para este projeto fez-se necessrio algumas configuraes - as quais foram feitas
atravs do menu ferramentas opes JDK, sejam elas:

Caminho onde est instalado o Java figura 30;

Figura 30 Configurando JDK no Gel 1.0

63
Na aba repositrio de classes figura 31:

Caminho onde esto instalados os pacotes .jar do Axis;

Caminho da biblioteca Paralellport.jar necessria para comunicao com a porta

paralela;

Figura 31 Configurando JDK no Gel 1.0

3.2 Desenvolvendo Aplicao Web Services

Como o propsito deste foi desenvolver um WS baseado num projeto para
movimentao de um brao eletro-mecnico, ligado na porta paralela do servidor. Fez-se
necessrio uma adaptao do cdigo fonte original do servidor, feito em Java; para
transform-lo numa aplicao WS; pois a classe principal do servido WS deve ter os seguintes
requisitos:

No pode ser abstrata;

No pode ser uma interface;

Deve ter mtodos pblicos no estticos.

3.2.1 Pr-requisitos
Primeiramente foi testado o projeto feito por Rubens da Rocha. O qual, para poder
rodar, tinha que ter as seguintes configuraes e instalaes:

64
1) Instalao Driver de Acesso da Porta Paralela:
Por questes de segurana as verses do windows NT/2000 e XP no permitem o
acesso direto ao hardware, necessrio um driver que "converse" com o ncleo (kernel) do
sistema operacional para ter acesso s portas fsicas do computador.
Nas verses do windows 95/Me e 98 no h restrio e o acesso pode ser direto,
portanto, no h necessidade do uso de drivers. Utilizou-se o driver Userport[30] que aps o
download s executar o arquivo userport.exe e clicar no boto start, aparecendo a janela da
figura 32:

Figura 32 Executando Driver UserPort

2) Instalao do Pacote ParallelPort
Esse pacote constitudo de classes Java, cdigos fontes e o arquivo parport.dll; que
habilita a leitura e escrita de bytes diretamente na porta paralela do computador[31] . Aps
feito seu download, o diretrio parport deve ser instalado no mesmo diretrio do projeto
lembrando que esse caminho foi configurado no Gel, figura 30. necessrio colocar uma
cpia do arquivo parport.dll no seguinte caminho: C:\WINDOWS\system32\drivers.

65
3.2.2 Rodando projeto original

Aps essas configuraes pode-se rodar o programa servidor figura 33, que fica
escutando a porta 7777 e aps o cliente fazer a conexo figura 34; tem-se a conexo aceita,
podendo ser aplicado os movimentos no brao figura 35, atravs dos botes (em verde). O
mesmo tem dois motores de passo, um para controle no eixo X com giro de aproximadamente
300 e outro para controle no eixo Y com giro completo de 360; ambos podendo ter inverso
de rotao.

Figura 33 Servidor Original

66

Figura 34 Cliente Original

Eixo Y

Eixo X

Figura 35 Brao Eletro-Mecnico

67
3.2.3 Criando Servidor WS: Classe WebComando

Para a criao do WS, fez-se uma adaptao do cdigo do servidor original, ficando da
seguinte maneira:

68
Nota-se na linha 38 o mtodo que ser chamado pela aplicao cliente: WebComando,
o qual receber um parmetro (comando), este mtodo abrir uma thread que ser inicializada
(t.start); na prxima linha chama-se o mtodo Movimento, passando o parmetro vindo do
cliente (ao). Este mtodo ir alterar as variveis index e Action, as quais sero usadas no
mtodo run da thread (linha 70), movimentando dessa maneira o brao eletrnico. Colocou-se
o comando return(comando) para que o comando executado seja retornado ao browser
(somente para teste).

69

70
Para que essa classe possa ser compilada corretamente, deve-se seguir as mesmas
configuraes do projeto original; tendo um diretrio como o mostrado na seo 3.2.1.
3.2.4 Transformando Classe WebComado em uma Classe WS
Distribuio Instantnea.
Uma vez criado a classe WebComando deve-se copiar o arquivo WebComando.java
(fonte), juntamente com o pacote ParallelPort e o arquivo parport.dll, para dentro do contexto
Axis que foi criado dentro do Tomcat. A estrutura de diretrio de arquivos ficar como
mostrado na figura 36.

Figura 36 Gerando JWS

Aps a cpia do arquivo fonte WebComando.java, altera-se sua extenso para

WebComando.jws, criando assim um arquivo Java Web Service, que o tipo mais simples de
organizao de servio web oferecido pelo framework Axis. Essa organizao exige que o
arquivo fonte esteja disponvel. Caso queira-se usar uma classe compilada deve-se usar a
outra opo de organizao de servio que usando o descritor de organizao, ou seja, o
wsdl.
O prximo passo ser inicializar o servidor Tomcat, e acessar o servio Axis que
estar disponvel, digitando-se em seguida no browser o seguinte endereo:

http://localhost:8080/axis/WebControle.jws

71
O Axis ir automaticamente localizar o arquivo WebControle.jws, compilar a classe e
converter as chamadas do SOAP para as chamadas Java da classe WebControle. Tem-se

figura 37 representando a pgina do browser aberta pelo servio.

Dessa foram, o WS est pronto para ser acessado por um programa cliente.

Figura 37 WS disponvel

3.2.5 Criando WSDL Distribuio Personalizada

Esse o segundo mtodo de organizao de servios do Axis: usando descritor wsdl.

Ao clicar no link Click to see the WSDL da figura 37, ter-se- a viso de todo o arquivo
WSDL, gerado automaticamente pelo Axis, conforme as regras vistas no Cap. 2. Portanto,
basta clicar com o boto direito do mouse neste link e solicitar para salvar destino como
numa pasta que pode ser C:/ClienteBraco, com a extenso wsdl; para o projeto denominou-se

72
WebControle.wsdl. Este ser o arquivo enviado ao cliente, para que o mesmo possa gerar os
descritores e criar a aplicao de acesso ao servio web.
Para gerar as classes Java a partir dos descritores usa-se uma ferramenta do Axis,
denominado Wsdl2java. Dessa maneira, o cliente do WS pode gerar, a partir do wsdl, as
classes de maneira dinmica. A figura 38 ilustra como deve ser feita a chamada de comando,
deve-se estar dentro da pasta que foi criado o arquivo WebControle.wsdl. Aps o comando
ser executado o Axis criou automaticamente a estrutura de diretrio WebComando, contendo
as classes Java, deploy e undeploy.wsdd.

Figura 38 WSDL2Java - Distribuio Personalizada

3.3 Desenvolvendo Cliente - Consumindo Web Services

Tem-se trs maneiras de um cliente acessar o WS desenvolvido anteriormente:

Via http;

Acesso direto;

Utilizando pacote.

Veremos no projeto somente a primeira e segunda opo.

73
3.3.1 Via HTTP :

Nesta opo, para acessar o servio web, basta digitar no browser:

URL do servio;
Mtodo a ser chamado;
Nome do parmetro;
Valor do parmetro.

A figura 39 mostra o acima exposto, nota-se que temos um valor retornado pelo WS,
pois o mesmo possui um mtodo que retorna o parmetro enviado pelo cliente. Neste caso, foi
enviado um parmetro = Cima, o qual far com que o WS envie um comando para o brao
eletro-mecnico, fazendo com que o mesmo execute um movimento no sentido horrio no seu
eixo Y, at que seja enviado um parmetro = Para.

Figura 39 Cliente via HTTP

74
3.3.2 Acesso Direto:

Nesta opo, para acessar o servio web, desenvolveu-se um cliente em Java, como
mostrado abaixo:

Deve-se importar os mtodos Call e Service da classe client do Axis, para poder
implementar a chamada ao servio WS (linha 14 instanciando um objeto call), setando: o
local do WS (linha 16), a funo a ser executada (linha 18) e o parmetro (linha 20). Para
passar o parmetro, antes de executar o aplicativo, abre-se no menu Compilar do Gel, escolhese a opo Parmetro, e aps a abertura da janela digita-se o mesmo. Esse parmetro ser
armazenado na varivel args[O], linha 20.
Na figura 40 temos o cliente executando, com o brao eletro-mecnico tendo um
movimento no sentido anti-horrio do seu eixo Y, pois foi passado o parmetro Baixo.

75

Figura 40 Cliente Java

76

CAPTULO 4 - CONCLUSO
4.1 Resultados
Nas experincias realizadas obteve-se xito na manipulao do brao eletro-mecnico,
tanto no acesso direto via http (browser) quanto no acesso via aplicao cliente (usando a
linguagem Java).
Algumas ressalvas foram encontradas quanto ao dispositivo fsico do brao eletromecnico, foi sua instabilidade quanto aos movimentos; pois quando enviado um comando
Cima pela aplicao cliente, tinha-se um movimento no eixo Y no sentido horrio. Caso
fosse enviado um comando Baixo logo em seguida, a agulha (fixa no eixo Y) ficava
oscilando, querendo ter um movimento no sentido anti-horrio (na teoria seria o movimento
correto), mas o mesmo no ocorria, dando a impresso que tinha-se dois comandos
simultneos a serem executados: sentido horrio e anti-horrio. Ou seja, aps uma comando
qualquer de movimentao tanto do eixo X como do eixo Y, deve ser aplicado somente o
comando Para, para depois aplicar um movimento no sentido contrrio ao primeiro.
O exposto no pargrafo anterior ocorreu tanto no acesso via browser, como tambm
no acesso da aplicao cliente feito em Java. Optou-se tambm em fazer uma aplicao
cliente na linguagem Delphi, e os resultados foram exatamente iguais.
Apesar dessa peculiaridade, o projeto deixou claro que essa recente tecnologia de Web
Service veio para permanecer, sendo uma alternativa para aplicaes distribudas, tendo
algumas vantagens como interoperabilidade de: sistemas operacionais, plataforma de hadware
e linguagem de programao.

4.2 Dificuldades Encontradas

Algumas dificuldades foram encontradas no decorrer do projeto. A primeira delas foi a
tentativa de criar um WSDL a partir do servidor original, simplesmente renomeando o
diretamente o arquivo servidor original .java para um arquivo .jws. Ao abrir o arquivo jws
pelo Axis, e solicitar a visualizao do arquivo WSDL, era mostrado uma pgina (browser)
em branca, e ao solicitar a criao do arquivo WSDL, o mesmo era criado porm o arquivo
criado ficava vazio. Desta forma foi alterado o servido original, como visto no Cap. 3.

77
Outra dificuldade e esta foi mais complicada de solucionar, pois aps o WS pronto, na
tentativa de enviar um comando tanto pelo browser (http) quanto pela aplicao cliente, o
dispositivo do brao eletro-mecnico, simplesmente no respondia a nenhum comando,
permanecendo esttico, sem nenhum movimento. Aps a checagem de todos os prrequisitos, como: o Userport ativado, servidor TomCat rodando, parmetros enviados
corretos, inclusive porque tinha-se o retorno do WS no browser, de qual foi o parmetro
enviado (return). Sendo que aparentemente estava tudo em ordem, resolveu-se verificar um
grande aliado para o programador: um arquivo de log gerado pelo Tomcat, (o mesmo
encontra-se no caminho C:\Arquivos de programas\Apache Software Foundation\Tomcat
5.0\logs); esse arquivo s gerado quando usa-se o Tomcat atravs do aplicativo Monitor
Tomcat. Observou-se uma mensagem de erro: O servidor Tomcat no estava achando a
biblioteca parport.dll, apesar do arquivo existir dentro do contexto Axis do Tomcat.
Utilizou-se o mtodo da tentativa-erro: gravou-se primeiramente o arquivo parport.dll
na pasta /bin do Tomcat (sem sucesso), depois na pasta /common/lib (sem sucesso) e ao ser
gravado na pasta /Server/lib, obteve-se o movimento no brao eletro-mecnico e no mais
apareceu a mensagem de erro no arquivo stdout.log.
A ltima dificuldade observou-se na tentativa de usar uma cmera digital para enviar
um vdeo, mostrando a movimentao do dispositivo, para a aplicao cliente. A cmera no
conseguia capturar a velocidade dos movimentos do brao. Neste caso, a soluo seria usar
uma cmera com captura de um nmero maior de frames por segundo.

4.3 Perspectivas futuras

Aprimorar o Web Service desenvolvido, pesquisando de uma forma mais aprofundada,

quais so os motivos das oscilaes ocasionadas no dispositivo. Principalmente no que se
refere na abertura de nova thread no servidor, a cada comando enviado pela aplicao
cliente.

Satisfazer a qualidade do envio de vdeo em tempo real, a partir do servidor para a

aplicao cliente.

78

REFERNCIAS

1. ROCHA, Rubens da. Sistema De Automao Remota Para Controle De Brao

Mecnico. Pato Branco - PR, Faculdade Mater Dei, 2004.
2. VENETIANER, T. HTML - Desmitificando a linguagem da Internet. Makron Books, 2a
edio, 1996.
3. WEB SERVICES IN JAVA. http://www.imasters.com.br/artigo.php?cn=1863&cc=2
acessado dia 14/07/2005.
4. FONTE MIDIA COMUNICAO http://www.fontemidia.com.br/article/articleview/465/
acessado dia 14/07/05.
5. SISTINET. http://www.webservices.org. acessado dia 14/07/2005.
6. WEB SERVIVES ARCHITECTURE. http://www.w3.org/TR/ws-arch/#mep acessado dia
15/07/05
7. HENDRICKS, Mack. Professional Java Web Services. Alta Books, srie WROX, 2002
Rio de Janeiro-RJ.
8. FURGERI, Srgio. Ensino Didtico da Linguagem XML. rica, 2001. So Paulo.
9. TANENBAUM, Andrew S. Rede de Computadores. Campus Editora, trad. da 4 edio
americana, 2003. So Paulo.
10. UTF-8. http://www.utf-8.com/ acessado dia 17/07/05.
11. UTF-15. http://en.wikipedia.org/wiki/UTF-16 acessado dia 17/07/05.
12. ISSO-8859-1. http://en.wikipedia.org/wiki/ISO-8859-1 acessado dia 17/05/.
13. SILVA, Osmar J. XML Aplicaes Prticas. rica, 2001. So Paulo.
14. TESH, Jos Roberto Jr. XML Schema. Visual Books, 2002. Florianpolis -SC.
15. O QUE JAVA.http://www.angelfire.com/de/mmedjava/OQue.html acessado dia
14/07/2005.
16. XMLCHEMA-2. http://www.w3.org./TR/xmlschema-2 acessado dia 24/07/2005.
17. WSDL. http://www.w3.org/TR/2001/NOTE-wsdl-20010315 acessado dia 29/07/05.
18. MIME. http://en.wikipedia.org/wiki/MIME acessado dia 03/08/05.
19. UDDI. http://www.uddi.org acessado dia 09/08/05.
20. POTTS, Stephen & MIKE,Kopack. Aprenda em 24 horas Web Services. Campus Editora,
2003. Rio de Janeiro.
21. SOAP 1.2 ATTACHMENT FEATURE. http://www.w3.org/TR/2002/WD-soap12-af20020814/ acessado dia 19/08/05.

79
22. JAVA 2 SOFTWARE THE PLATAFORMS. http://java.sun.com/java2/whatis/ acessado
dia 19/08/05.
23. VDEOCONFERNCIA
http://www.interdidactic.com.br/Produtos.php?Produto=4&GUID=5812c16c992878a278a
c608daa4174ee acessado dia 22/08/05.
24. APACHE. http://www.apache.org acessado dia 22/08/05.
25. AXIS. http://en.wikipedia.org/wiki/Framework acessado dia 22/08/05.
26. AXIS ARCHITECTURE GUIDE.
http://ws.apache.org/axis/java/architecture-guide.html#ArchitecturalOverview

acessado

dia 24/08/05.
27. APACHE TOMCAT. http://jakarta.apache.org/tomcat/ acessado dia 26/08/05.
28. TUTORIAL TOMCAT. http://www.mhavila.com.br/topicos/java/tomcat.html acessado
dia 26/08/05.
29. AXIS ENGINE IN WEB CONTAINER.

http://www.oio.de/axis-soap.htm acessado dia

26/08/05.

30. DRIVER PORTA PARALELA: USERPORT.

http://www.rogercom.com/pparalela/DriverNT_2000_XP.zip acessado dia 27/08/05.
31. PARPORT. http://www.geocities.com/Juanga69/parport/ acessado dia 08/09/05.