Você está na página 1de 79

http:/ www.dawnchat.rg.com.

br/
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:
2

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 a 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

3 4

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)

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. Java RMI Mecanismo de Invocao Formato de Datos Formato troca de informaes Protocolo de Transferncia Interface de Descrio Mecanismo de Publicao Java RMI Java Serializado Stream JRMP Java Interface Java Registry CORBA CORBA RMI CDR GIOP IIOP CORBA IDL COS naming DCE RPC NDR PDU RPC CO DCE IDL CDS Web Services JAX-RPC, .NET, AXIS XML SOAP HTTP, SMTP WSDL UDDI

Tabela 1 Comparao entre formatos e protocolos SOA

Service-Oriented Architeture:

(Servio Orientado a Arquitetura)

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 o 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:

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

15

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 18

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.

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 VersionMismatch MustUnderstand Client Significado 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.
Tabela 2 Cdigo de Falhas Genricos

Server

- 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.
Multipurpose Internet Mail Extensions Padro Internet para envio e recebimento de mensagens nos mais variados formatos, alm do ASCII.[18]
24

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 Soap http Mime Soapenc

URI do namespace http://schemas.xmlsoap.org/wsdl/

Descrio

Soapenv

Xsi

Xsd

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

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.

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.

26

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(), Find_binding(), Find_tModel(),

Get_businessDetail(),

Get_serviceDetail(),

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:
29

aceitar e analisar sintaticamente mensagens do protocolo SOAP; chamar mtodos e funes apropriados no Web Service implementao de classes Java; 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 e parando todas na as classes bin do inicializadas. Tomcat. Ambos que os ao

encontram-se

pasta

Nota-se

32

Java Virtual Machine - Mquina Virtual Java

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), o 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. a

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 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.
26/08/05. http://www.oio.de/axis-soap.htm acessado dia

acessado

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.