Implementação de um Web Service para uma Locadora de Veiculos

LUIZ WAGNER ARAÚJO NUNES
IMPLEMENTAÇÃO DE UM WEB SERVICE PARA UMA LOCADORA
DE VEÍCULOS - RELAÇÃO B2B
Palmas
2006.1
LUIZ WAGNER ARAÚJO NUNES
IMPLEMENTAÇÃO DE UM WEB SERVICE PARA UMA LOCADORA
DE VEÍCULOS - RELAÇÃO B2B
“Trabalho apresentado ao curso de
Sistemas de Informação do Centro
Universitário Luterano de Palmas como
requisito parcial da disciplina de Trabalho
de Conclusão de Curso em Sistemas de
Informação, orientado pela professora
Madianita Bogo”
Palmas
2006.1
LUIZ WAGNER ARAÚJO NUNES
IMPLEMENTAÇÃO DE UM WEB SERVICE PARA UMA LOCADORA
DE VEÍCULOS - RELAÇÃO B2B
“Trabalho apresentado ao curso de
Sistemas de Informação do Centro
Universitário Luterano de Palmas como
requisito parcial da disciplina de Trabalho
de Conclusão de Curso em Sistemas de
Informação, orientado pela professora
Madianita Bogo”
BANCA EXAMINADORA
_______________________________________
Profª. M.Sc. Madianita Bogo
Centro Universitário Luterano de Palmas
_______________________________________
Fabiana Ferreira Cardoso
Centro Universitário Luterano de Palmas
_______________________________________
Prof. M.Sc. Ricardo Marx Costa Soares de Jesus
Centro Universitário Luterano de Palmas
4
SUMÁRIO
1.
INTRODUÇÃO.......................................................................................................... 10
2.
REVISÃO DE LITERATURA ................................................................................. 12
2.1. Sistemas Distribuídos .......................................................................................... 12
2.1.1.
Modelo Cliente/Servidor ................................................................................. 13
2.2. RMI...................................................................................................................... 14
2.3. CORBA ............................................................................................................... 15
2.4. Web Service ......................................................................................................... 17
2.4.1.
WSDL.............................................................................................................. 18
2.4.2.
UDDI ............................................................................................................... 22
2.4.3.
JWSDP ............................................................................................................ 25
2.4.3.1.
JAX-RPC..................................................................................................... 25
2.4.3.1.1. Desenvolvimento do Servidor ..................................................................... 26
2.4.3.1.2. Desenvolvimento do Cliente ....................................................................... 31
2.5. B2B...................................................................................................................... 33
2.6. Web Services em B2B.......................................................................................... 34
3. MATERIAL E MÉTODOS ...................................................................................... 36
3.1. Material................................................................................................................ 36
3.1.1.
Hardware......................................................................................................... 36
3.1.2.
Software........................................................................................................... 37
3.2. Métodos ............................................................................................................... 38
4. RESULTADOS E DISCUSSÃO............................................................................... 39
4.1. Domínio ............................................................................................................... 39
4.2. Comunicação das Aplicações .............................................................................. 40
4.3. Modelagem do Web Service ................................................................................ 42
4.3.1.
Funcionalidades do Web Service ..................................................................... 42
4.3.2.
Diagrama de Classes........................................................................................ 43
4.4. Considerações sobre o serviço............................................................................. 45
4.4.1.
Questão Legal do Serviço ................................................................................ 46
4.5. Implementação do Serviço .................................................................................. 47
4.6. Implementação do Cliente ................................................................................... 49
5. CONSIDERAÇÕES FINAIS .................................................................................... 53
6.
REFERÊNCIAS BIBLIOGRÁFICAS..................................................................... 55
ANEXOS ......................................................................................................................... 57
ANEXO I: MODELAGEM DO WEB SERVICE ............................................................ 58
ANEXO II: IMPLEMENTAÇÃO DO WEB SERVICE .................................................. 77
ANEXO III: IMPLEMENTAÇÃO DA APLICAÇÃO CLIENTE................................ 100
5
LISTA DE FIGURAS
Figura 1 - Estrutura do modelo Cliente/Servidor – adaptada de Horstmann (2003). .......... 13
Figura 2 - Estrutura de comunicação do padrão CORBA, modificada de Riccioni (2000). 15
Figura 3 – Exemplo de um documento WSDL. .................................................................. 20
Figura 4 – Exemplo de Interface de um Web Service com JAX-RPC. ............................... 27
Figura 5 – Exemplo de Classe de Implementação de um Web Service com JAX-RPC. .... 28
Figura 6 – Documento XML utilizado pelo aplicativo wscompile. .................................... 29
Figura 7 – Documento XML utilizado pelo aplicativo jar. ................................................. 30
Figura 8 – Documento XML utilizado pelo aplicativo wsdeploy. ...................................... 30
Figura 9 – Exemplo de Classe de Implementação de um Cliente JAX-RPC. ..................... 32
Figura 10 - Arquitetura de Comunicação da Aplicação Cliente com o Web Service .......... 41
Figura 11 – Diagrama de Casos de Uso............................................................................... 43
Figura 12 – Diagrama de Classes do Web Service............................................................... 44
Figura 13 – Implementação da Interface do Web Service.................................................... 48
Figura 14 – Fragmento de Código do Arquivo veiculos.php. ............................................. 50
6
LISTA DE TABELAS
Tabela 1: Pilha Básica de Web Services – disponível em Hendricks (2002)....................... 17
7
LISTA DE ABREVIATURAS
API
Application Programming Interface
B2B
Business-to-business
CORBA
Common Object Request Broker Architecture
ebXML
Eletronic Business Extensible Markup Language
FTP
File Transfer Protocol
HTTP
HyperText Transfer Protocol
HTTPS
HyperText Transfer Protocol Secure
IDL
Interface Definition Language
ISO
International Organization for Standardization
JWSDP
Java Web Service Developer Pack
NAICS
North American Industry Classification System
8
ORB
Object Request Broker
RPC
Remote Procedure Call
SMTP
Simple Mail Transfer Protocol
SOAP
Simple Object Access Protocol
TCP/IP
Transfer Control Protocol/Internet Protocol
UDDI
Universal Description, Discovery and Integration
W3C
World Wide Web Consortium
WSDL
Web Service Description Language
XML
Extensible Markup Language
9
RESUMO
A crescente demanda na utilização da Internet para a comunicação entre empresas fez
surgir uma nova modalidade de comércio eletrônico, denominada Business-to-business
(B2B), na qual as empresas integram suas aplicações com o intuito de intercambiar as
informações, possibilitando a realização dos processos de negócio. A tecnologia de Web
Services surgiu com a promessa de permitir que aplicações desenvolvidas em plataformas e
linguagens de programação distintas possam se integrar, garantindo a interoperabilidade
entre as aplicações, o que é interessante quando se fala em comunicação entre aplicações
de empresas distintas. O objetivo deste trabalho é realizar um estudo da tecnologia de Web
Services analisando a sua utilização na modalidade de comércio eletrônico Business-tobusiness, realizando um estudo teórico dos conceitos relacionados ao tema e testes práticos
da integração de aplicações desenvolvidas em linguagens distintas.
10
1. INTRODUÇÃO
A Internet tem sido utilizada principalmente para o relacionamento entre pessoas e para o
comércio eletrônico, em que as pessoas passaram a se relacionar com as empresas surgindo
esta nova modalidade de comércio. Nos últimos anos, é notável também uma crescente
utilização da Internet para a troca de informações entre empresas, as quais são tidas como
parceiras comerciais, buscando a integração de suas aplicações para a manutenção desta
forma de comunicação.
Da parceria entre empresas surgiu a modalidade de comércio eletrônico denominada
Business-to-business (B2B), definindo o comércio entre empresas realizado através da
troca de informações pela Internet. Várias tecnologias surgiram para aprimorar e permitir
mais facilidade na comunicação entre as aplicações das empresas, dentre elas o padrão
RMI, o CORBA e a tecnologia de Web Services.
A tecnologia de Web Services traz a promessa de permitir e facilitar a comunicação entre
aplicações desenvolvidas em linguagens de programação e plataformas distintas,
prometendo também possibilitar interoperabilidade entre tais aplicações, o que é
interessante quando se fala em comunicação entre aplicações de empresas distintas.
Com base neste cenário, em que é crescente a demanda pela integração de aplicações dado
o surgimento desta nova modalidade de comércio eletrônico, pensou-se em desenvolver um
estudo da tecnologia de Web Services e sua relação com o Business-to-business, uma vez
que foi notado que é um assunto pouco discutido.
O objetivo deste trabalho é estudar a tecnologia de Web Services, buscando levantar suas
características, fazendo um breve estudo das demais tecnologias a fim de possibilitar um
11
melhor entendimento. É parte também deste trabalho o estudo das características da
modalidade comércio eletrônico Business-to-business, buscando principalmente relacionála com a tecnologia de Web Services, fazendo um levantamento teórico e a implementação
de um exemplo prático nesta avaliação.
Este trabalho está estruturado da seguinte forma: a seção 2 apresenta um levantamento das
características das aplicações distribuídas, mencionando os modelos e as tecnologias
existentes, buscando maior destaque das características da tecnologia de Web Services,
sobretudo da API JAX-RPC, que integra o JWSDP, descrevendo os passos básicos para a
criação de uma aplicação Servidora e uma aplicação Cliente. Exibe também um
levantamento a respeito do Business-to-business, buscando relacioná-lo com a tecnologia
de Web Services. A seção 3 contém a relação do material empregado e descreve os métodos
utilizados no desenvolvimento do trabalho. A seção 4 mostra os resultados e uma discussão
a respeito do que foi encontrado na literatura e dos testes práticos realizados, quando
possível, fazendo uma relação entre os mesmos. A seção 5 expõe as considerações finais,
descrevendo as conclusões a respeito do estudo realizado, apontando a utilização em
trabalhos futuros.
12
2. REVISÃO DE LITERATURA
2.1. Sistemas Distribuídos
Um sistema distribuído pode ser definido como um conjunto de computadores
interconectados em rede com o objetivo principal de compartilhar recursos de hardware e
software. Para Casetti (1993) “um sistema distribuído constitui-se de processadores
autônomos conectados através de um subsistema de comunicação, que cooperam-se através
de troca de mensagens.”
Uma das vantagens advindas da utilização de um sistema distribuído é o compartilhamento
de recursos. Assim, os recursos mantidos por uma estação servidora poderão ser utilizados
por estações clientes, que solicitam os recursos através de uma rede de comunicação.
Como proteção à ocorrência de falhas, sistemas distribuídos podem ser implantados com
grande vantagem sobre os sistemas centralizados. A redundância de recursos de hardware
e de software pode imprimir mais confiabilidade ao sistema como um todo: caso partes do
sistema venham a falhar, o restante do sistema é capaz de continuar o processamento, ao
contrário de um sistema centralizado em que uma falha comprometeria todo o sistema.
Por fim, como um sistema distribuído está disseminado em uma rede, sua abrangência é
uma grande vantagem sobre um sistema centralizado, uma vez que pode atingir grandes
distâncias geográficas.
Tanenbaum (1992) menciona a capacidade de crescimento incremental dos sistemas
distribuídos. A escalabilidade permite que novas unidades processadoras possam ser
adicionadas, visando aumentar o poder de processamento do conjunto, sem que sejam
13
necessárias alterações na configuração do sistema e interrupções no funcionamento no
momento das alterações.
Um dos modelos de sistemas distribuídos mais difundidos e citados na literatura é o
modelo Cliente/Servidor. A seção 2.1.1 apresenta o conceito e descreve o funcionamento
deste modelo.
2.1.1. Modelo Cliente/Servidor
Segundo Riccioni (2000), o modelo Cliente/Servidor de computação distribuída é um
modelo de gerenciamento de informação que divide o processamento entre um computador
que requer um serviço e outro que devolve o serviço.
Como em sistemas distribuídos não existe região de memória compartilhada, os processos
se comunicam através de mecanismos de troca de mensagens. A programação de socket e
a chamada de procedimento remoto (RPC – Remote Procedure Call) são mecanismos
utilizados nas trocas de mensagens. A Figura 1 ilustra a transmissão de mensagens no
modelo Cliente/Servidor.
Cliente
Servidor
solicitação
resposta
Figura 1 - Estrutura do modelo Cliente/Servidor – adaptada de Horstmann (2003).
Na estrutura apresentada na Figura 1, os retângulos identificados como Cliente e Servidor
representam as aplicações Cliente e Servidor, respectivamente, dentro do modelo
14
Cliente/Servidor. De uma maneira simplificada, o Cliente envia uma mensagem de
solicitação para o Servidor, que realiza o processamento e retorna uma mensagem de
resposta para o Cliente.
Com o advento do paradigma de orientação a objetos, foram idealizados objetos
colaborativos localizados em ambientes remotos, capazes de interagir através de
mecanismos de troca de mensagens. Com isso, surgiram os padrões RMI (Remote Method
Invocation – Invocação de Método Remoto) e CORBA (Common Object Request Broker
Architecture – Arquitetura de Agentes de Requisição de Objetos Comum). Esses padrões
serão discutidos nas seções 2.2 e 2.3.
2.2. RMI
O padrão RMI foi uma iniciativa da empresa Sun Microsystems. Escrito na linguagem de
programação Java, esse padrão possibilita a comunicação entre objetos residentes em
máquinas virtuais java (JVM – Java Virtual Machine), que podem estar localizadas em
computadores distintos ou não.
Com o RMI, a invocação de métodos de um objeto remoto parece simples para o
desenvolvedor. Os detalhes de comunicação ficam ocultos. Assim, o desenvolvedor tem a
impressão de que está realizando a chamada de métodos de um objeto local.
“Ao invocar um método sobre um objeto remoto, o cliente RMI atua, na realidade, sobre
um objeto local que se faz passar pelo objeto remoto. Esse objeto local é chamado stub. O
stub age como um proxy do objeto remoto e esconde do cliente o uso dos serviços providos
pelos protocolos de transporte. Por serem gerados por um compilador chamado rmic, os
desenvolvedores de um programa RMI não têm que se preocupar em codificar os stubs”
(ALBUQUERQUE, 2001).
Os serviços oferecidos pelo Servidor são descritos através de um arquivo Java que
implementa uma interface. A interface contém a assinatura dos métodos disponibilizados
pelo Servidor. Desta forma, o Cliente descobre os métodos analizando a interface do
Serviço.
15
Apesar de escrito em Java, uma linguagem prometida para ser “quase perfeita” em termos
de portabilidade, como leciona Riccioni (2000), o RMI é limitado exatamente em sistemas
heterogêneos no tocante à interação com objetos desenvolvidos em outras linguagens. Ao
contrário disto, o padrão CORBA promete possibilitar a integração entre aplicações
heterogêneas. O padrão CORBA será discutido na seção seguinte.
2.3. CORBA
Conforme citado por Horstmann (2003), “o padrão CORBA permite a comunicação entre
objetos escritos em diferentes linguagens de programação. (...) Ele define um mecanismo
comum para troca de dados e descoberta de serviços”.
A especificação CORBA tem sido implementada por diversas linguagens de programação.
Os programas Cliente e Servidor podem ser desenvolvidos em linguagens de programação
distintas, como Java e C++, por exemplo.
A especificação CORBA define um Agente de Requisição de Objetos (ORB – Object
Request Broker) que é responsável por intermediar a comunicação entre objetos remotos.
“O ORB é responsável pela localização do objeto ao qual se destina a requisição, assim
como o envio dos parâmetros da requisição no formato aceito por este objeto. (...) Também
é função do ORB, o retorno de parâmetros de saída da requisição para o cliente, se assim
houver” (RICCIONI, 2000). A Figura 2 apresenta a estrutura da comunicação do padrão
CORBA.
Cliente
Servidor
ORB
Rede
ORB
Figura 2 - Estrutura de comunicação do padrão CORBA, modificada de Riccioni (2000).
A estrutura de comunicação apresentada na Figura 2 pode ser entendida da seguinte forma:
primeiramente o Cliente obtém uma referência ao objeto remoto, através do ORB, e então
16
faz a invocação de um método do objeto remoto. Em seguida, O ORB converte os
parâmetros do método em um formato independente de plataforma, e envia-os através da
rede ao ORB do Servidor. O ORB do Servidor recebe os parâmetros e decodifica-os,
repassando a chamada do método ao Servidor. Após o processamento da chamada, o
Servidor envia a resposta com os parâmetros ao ORB, que faz a codificação e envia ao
ORB do Cliente. Por fim, o ORB do Cliente decodifica os parâmetros de saída e repassa-os
ao Cliente.
A padronização do protocolo de comunicação e do formato das mensagens em um sistema
distribuído é um ponto importante para a interação entre objetos distribuídos,
principalmente na interação entre objetos heterogêneos. O formato e o modo de
transmissão das mensagens devem possibilitar que o objeto do Cliente possa enviar as
mensagens de forma que o objeto do Servidor possa recebê-las e processá-las. A definição
do formato das mensagens e dados para a comunicação entre ORB’s é papel do Protocolo
Inter-ORB Geral (GIOP). A forma de transmissão das mensagens numa rede TCP/IP é
papel do Protocolo Inter-ORB Internet (IIOP).
A descrição do objeto Servidor, que atenderá às requisições dos objetos Clientes, está
contida em um documento que apresenta a assinatura dos métodos disponibilizados pelo
objeto Servidor e os tipos de dados que podem ser enviados e recebidos através das
mensagens. A linguagem utilizada para desenvolvimento deste documento é a linguagem
de definição de interface (IDL – Interface Definition Language). Um documento IDL é
bem semelhante a uma interface definida na linguagem de programação Java, e possui a
extensão .idl.
No tocante à interação entre aplicações comerciais na Internet, visando a integração de
parceiros comerciais, uma nova tecnologia surgiu buscando proporcionar maior
interoperabilidade entre as aplicações. A tecnologia de Web Services têm recebido muitos
incentivos por parte de grandes empresas como Microsoft e IBM. Na seção 2.4 será
apresentada a tecnologia de Web Services.
17
2.4. Web Service
Um Web Service representa uma aplicação auto-descritiva que é capaz de responder a
solicitações de outras aplicações, independentemente da linguagem e da plataforma em que
estas foram desenvolvidas, fazendo uso de tecnologias padrão, tais como os protocolos da
Internet, como HTTP, e a linguagem XML. Além da capacidade de responder a
solicitações, um Web Service também pode fazer solicitações a outros Web Services,
exercendo assim o papel de aplicação cliente ou consumidora.
Conceitualmente, a estrutura de um Web Service pode ser representada na forma de uma
pilha. De acorco com Hendricks (2002), a pilha é formada por 4 camadas. A tabela 1
apresenta as camadas associando-as às respectivas tecnologias.
Tabela 1: Pilha Básica de Web Services – disponível em Hendricks (2002).
Publicação e Descoberta do Serviço
UDDI
(Service Publication/Discovery)
Descrição do Serviço (Service
WSDL
Description)
Troca de Mensagens XML – SOAP (XML SOAP
Messaging)
Rede de Transporte (Transport Network)
HTTP, SMTP, FTP, HTTPS over TCP/IP
Um Web Service pode ter seus dados publicados em um registro de negócios, tais como o
registro UDDI (Universal Description, Discovery and Integration – Descrição, Descoberta
e Integração Universais). A especificação UDDI padroniza um modelo de repositório de
registro de Web Services públicos e dos negócios que os representam. Através do registro
clientes e parceiros de negócios podem integrar suas aplicações buscando as descrições dos
Web Services registrados.
Além da especificação UDDI, mencionada por Hendricks (2002), a especificação ebXML
também padroniza um modelo de repositório. Mais abrangente do que a especificação
UDDI, ela é dirigida a registros de negócios, cujas empresas podem possuir Web Services
implementados. A especificação UDDI será apresentada com maior profundidade na seção
2.4.2.
18
Um diferencial importante dos Web Services sobre as demais tecnologias de sistemas
distribuídos é a forma de descrição. A descrição de um Web Service apresenta os métodos
disponibilizados, os parâmetros de entrada e saída e a localização e o nome do serviço.
Para a descrição é utilizado um documento escrito na Linguagem de Descrição de Web
Services (WSDL – Web Services Description Language). Este documento é um documento
XML cujo esquema segue as regras da WSDL. A WSDL será discutida com mais detalhes
na seção 2.4.1.
As mensagens trocadas entre o Web Service e os Clientes são convertidas nos formatos
definidos pelo protocolo escolhido para a comunicação. Dentre os protocolos está o
protocolo SOAP (Simple Object Access Protocol – Protocolo Simples de Acesso ao
Objeto), o qual acondiciona a mensagem em um documento XML. O protocolo SOAP
pode ser utilizado no mecanismo de troca de mensagens baseado em RPC ou baseado em
troca de documentos.
Por fim, as mensagens são transportadas fazendo uso de um dos protocolos de Internet,
como por exemplo, HTTP, SMTP etc. Segundo Hendricks (2002), o mais utilizado é o
protocolo HTTP (Hypertext Transfer Protocol – Protocolo de Transferência de
Hipertexto). O uso destes protocolos, e principalmente do HTTP, é devido ao fato de que
os mesmos geralmente são utilizados por várias aplicações e, além disso, comumente estão
habilitados nos firewalls, o que facilita a utilização da tecnologia de Web Services. Neste
trabalho, o Web Service desenvolvido utiliza a API JAX-RPC, integrante do JWSDP, a
qual utiliza o protocolo SOAP para troca de mensagens e o protocolo HTTP para o
transporte.
2.4.1. WSDL
A sigla WSDL é utilizada para referenciar o documento que descreve um Web Service. Este
documento, que é um documento XML, tem por finalidade apresentar os detalhes do Web
Service. Ao contrário do que é utilizado nos padrões RMI e CORBA, o documento WSDL
é mais complexo devido aos detalhes que especifica, como endereço real do serviço,
definição da estrutura das mensagens de solicitação e resposta de cada uma das operações
19
disponibilizadas pelo Web Service etc. A sua estrutura é constituída de 5 elementos
básicos: types, message, portType, binding e service (TODD, 2003).
A escrita de um documento WSDL pode ser uma tarefa bastante complexa, a depender da
quantidade de operações disponibilizadas pelo Web Service, dos parâmetros de entrada e
saída, e dos tipos de dados utilizados nas mensagens. Normalmente, os aplicativos que
possibilitam o desenvolvimento de Web Services disponibilizam ferramentas capazes de
gerar este documento com base na interface desenvolvida e na localização e no nome que
referencia o serviço. A Figura 3 apresenta um exemplo de um documento WSDL.
20
1. <?xml version="1.0" encoding="UTF-8" ?>
2. <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="urn:Foo"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" name="Hello"
targetNamespace="urn:Foo">
3. <types />
4. <message name="HelloIF_sayHello">
5. <part name="String_1" type="xsd:string" />
6. </message>
7. <message name="HelloIF_sayHelloResponse">
8. <part name="result" type="xsd:string" />
9. </message>
10. <portType name="HelloIF">
11. <operation name="sayHello" parameterOrder="String_1">
12. <input message="tns:HelloIF_sayHello" />
13. <output message="tns:HelloIF_sayHelloResponse" />
14. </operation>
15. </portType>
16. <binding name="HelloIFBinding" type="tns:HelloIF">
17. <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc" />
18. <operation name="sayHello">
19. <soap:operation soapAction="" />
20. <input>
21. <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="encoded"
namespace="urn:Foo" />
22. </input>
23. <output>
24. <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="encoded"
namespace="urn:Foo" />
25. </output>
26. </operation>
27. </binding>
28. <service name="Hello">
29. <port name="HelloIFPort" binding="tns:HelloIFBinding">
30. <soap:address location="http://localhost:8080/Hello/hello"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" />
31. </port>
32. </service>
33. </definitions>
Figura 3 – Exemplo de um documento WSDL.
O documento apresentado na Figura 3 foi gerado com o aplicativo wscompile, o qual
integra a API JAX-RPC. Para isso, foram utilizados como base um arquivo XML de
configuração e o arquivo de interface do serviço compilado. O documento representa a
descrição do Web Service denominado Hello, o qual possui apenas uma operação
denominada sayHello, que recebe um parâmetro do tipo String e retorna uma String como
resposta.
21
De acordo com W3C (2001), o elemento raiz do documento WSDL é o elemento
definitions. O elemento types contém as definições dos tipos de dados que serão enviados e
recebidos através das mensagens processadas pelo Web Service. Este elemento é
especificado quando é preciso utilizar tipos de dados complexos, definidos pelo
desenvolvedor. Quando são utilizados somente tipos de dados padronizados pelo W3C,
este elemento não precisa ser especificado. No exemplo apresentado na Figura 4, o
elemento types não contém valor declarado, o que indica que os dados contidos nas
mensagens de solicitação e de resposta conterão somente valores padrão definidos.
O elemento message define, para cada mensagem, qual o tipo de dado de cada parâmetro
ou retorno. Para cada operação disponibilizada pelo Web Service, devem ser criados dois
elementos message, um para a mensagem de requisição e outro para a respectiva
mensagem de resposta. O tipo de dado pode ser um valor padrão ou qualquer tipo definido
no elemento types.
No exemplo da Figura 3, o elemento message cujo atributo name contém o valor
“HelloIF_sayHello” representa a mensagem de solicitação do método “sayHello(String
nome)”. O sub-elemento part define o tipo de dado do parâmetro e a ordem em que
aparecerá, que neste caso é o primeiro parâmetro de entrada, e é do tipo String. O valor
“String_1” do atributo name do elemento part denota o tipo de dado e a ordem do
parâmetro. O valor “xsd:string” do atributo type do elemento part define que o tipo de dado
do
parâmetro
é
o
tipo
“string”
definido
no
namespace
“http://www.w3.org/2001/XMLSchema”.
O elemento message cujo atributo name contém o valor “HelloIF_sayHelloResponse”
define a mensagem de resposta do método “sayHello(String nome)”. O valor do atributo
name do sub-elemento part agora contém o valor “result”, o que completa o sentido de que
a mensagem é de resposta, conduzindo o resultado da operação processada pelo método do
Web Service. O valor “xsd:string” do atributo type do elemento part define que o tipo de
dado
da
resposta
é
o
tipo
“http://www.w3.org/2001/XMLSchema”.
“string”
definido
no
namespace
22
O elemento portType descreve os métodos que serão disponibilizados pelo Web Service. A
finalidade básica deste elemento é indicar, para cada método do Web Service, qual
elemento message definirá o formato da mensagem de solicitação e qual definirá o formato
da mensagem de resposta. O sub-elemento operation indica a operação que está sendo
definida. O sub-elemento input, do elemento operation, referencia o elemento message que
descreverá o formato da mensagem de solicitação, e o sub-elemento output referencia o
elemento message que descreverá o formato da mensagem de resposta.
O elemento binding apresenta a informação do protocolo que será utilizado no transporte
das mensagens. Pelo menos um elemento binding é requerido. De acordo com WSDL
(2001), a linguagem WSDL é extensível a ponto de permitir a adoção de outros formatos
de mensagem e protocolos de rede, além de SOAP 1.1, HTTP GET/POST e MIME, por
exemplo. O protocolo SOAP é mais utilizado com o protocolo HTTP. No entanto, podem
ser utilizados vários outros protocolos, como SMTP, FTP etc.
A API JAX-RPC adota o protocolo SOAP como padrão para definição do formato das
mensagens e HTTP para o transporte. No documento da Figura 4, o protocolo de transporte
é indicado pelo atributo transport do sub-elemento soap:binding, que contém o valor
“http://schemas.xmlsoap.org/soap/http”. De acordo com W3c (2002), o SOAP pode utilizar
mensagens orientadas a documento ou orientadas a procedimentos (RPC), o que é definido
através do atributo style do elemento soap:binding, sendo que o valores podem ser “rpc”
ou “document”. O valor é opcional, mas, quando não indicado, será considerado o valor
“document”.
De acordo com Todd (2003), o elemento service contém o endereço real do Web Service.
Assim, para cada elemento binding haverá a indicação de um endereço real através do
elemento service.
2.4.2. UDDI
W3C (2002) afirma que a tarefa de publicação e descrição de Web Services é essencial
dentro da arquitetura básica de Web Services. Neste contexto, o padrão UDDI merece
destaque por ser o mais utilizado. Oasis (2004) declara que o objetivo da especificação é
23
definir um conjunto de serviços com suporte à descrição e descoberta de negócios,
organizações, e outros fornecedores de Web Services, dos Web Services que eles
disponibilizam e das interfaces técnicas que podem ser utilizadas para acessar estes
Serviços.
A estrutura de armazenamento objetiva facilitar a localização das informações. De acordo
com Todd (2003), UDDI permite realizar buscas por negócios e serviços de diferentes
maneiras, tais como: localização de negócios por tipo de negócio (Yellow Pages – Páginas
Amarelas); localização de negócios por nomes, endereços, entre outras informações (White
Pages – Páginas Brancas); e localização de informações sobre os serviços que um negócio
oferece (Green Pages – Páginas Verdes).
Ainda segundo Todd (2003), UDDI define não somente uma estrutura para organização de
informações, mas também um XML Schema para definição da estrutura de armazenamento,
uma API com métodos que permitem publicar serviços e métodos para acessar serviços,
uma especificação para replicação de informações entre registros e uma especificação para
operadores de registro definindo, dentre outras, questões como segurança.
As informações que são submetidas a um registro UDDI são armazenadas na forma de um
documento XML, o qual segue o XML Schema descrito pela especificação. De acordo com
Chappell (2002), o XML Schema define os seguintes elementos básicos:
•
businessEntity: é o elemento que contém as informações que definem um
determinado negócio. Dentre estas, estão informações de contato e nome do
negócio. Este elemento contém também sub-elementos que armazenam
informações referentes aos serviços oferecidos pelo negócio.
•
businessService: é o elemento que contém a definição de um determinado serviço,
contendo informações como nome, descrição e mais informações, como ponto de
acesso, por exemplo, armazenadas em seus sub-elementos.
•
bindingTemplate: este elemento contém a informação do endereço real do serviço,
a qual está armazenada no sub-elemento accessPoint.
24
•
tModel: este elemento é um dos sub-elementos do elemento bindingTemplate, que
representa uma especificação técnica dentro do contexto de um registro UDDI. A
informação contida neste elemento poderia auxiliar companhias a determinar se um
Web Service é compatível com seus requisitos de negócio.
•
categoryBag: este elemento contém informações de categorização para o serviço.
Dentre as várias categorizações citadas estão a NAICS – North American Industry
Classification System – Sistema de Classificação da Indústria Norte Americana e
ISO 3166, que é um sistema de classificação geográfica padronizado pela
International Organization for Standardization – Organização de Padronização
Internacional.
•
publisherAssertion: este elemento contém informação sobre relacionamento de
elementos businessEntity.
As APIs para publicação e descoberta de serviços, definidas pela especificação UDDI,
permitem que empresas possam publicar informações sobre seus negócios e serviços, e que
clientes e parceiros possam localizar estas informações. A API de consulta referencia um
URL de um determinado registro de negócios e não necessita de acesso autenticado para
sua utilização. Ao contrário, a API de publicação utiliza o protocolo HTTPS e requer que o
negócio utilize um nome de usuário e uma senha para as operações de inserção, alteração e
remoção de informações.
No pacote de APIs Java para desenvolvimento de Web Services – JWSDP (Java Web
Service Developer Pack), a API JAX-R permite a manipulação de registros XML,
permitindo a realização de operações de gerenciamento e consulta. A API JAX-RPC
permite a construção de Web Services e clientes que usam chamadas de procedimento
remoto (RPC) e XML. A versão mais recente do JWSDP é a versão 2.0, a qual apresenta a
API JAX-WS em substituição à API JAX-RPC. O JWSDP será apresentado em mais
detalhes na seção 2.4.3.
25
2.4.3. JWSDP
O JWSDP é formado por um conjunto de APIs de código fonte aberto, desenvolvidas na
linguagem Java, permitindo a construção, teste e publicação de Web Services e aplicações,
utilizando a pilha de protocolos apresentada na Seção 2.4.
No desenvolvimento deste trabalho foi utilizada a versão 1.6 do JWSDP. Nele estão
contidas APIs para desenvolvimento de Web Services, aplicações Web, dentre outras
aplicações. Destacam-se neste pacote as APIs JAXB (Java Architecture for XML Binding –
Arquitetura Java para Mapeamento XML), JAXP (Java API for XML Processing – API
Java para Processamento de XML), JAX-RPC (Java API for XML-based RPC – API Java
para RPC baseado em XML) e JAXR (Java API for XML Registries – API Java para
Registros XML).
O JWSDP é mantido em contínua evolução, e recentemente, no decorrer deste trabalho, foi
publicada a versão 2.0. Nesta nova versão, a API JAX-RPC foi renomeada para API JAXWS (Java API for XML Web Services – API Java para Web Services em XML). A API
JAX-RPC será apresentada em mais detalhes na Seção 2.4.3.1.
2.4.3.1.
JAX-RPC
JAX-RPC é uma API para construção de Web Services e clientes usando mecanismos de
RPC baseados em XML. Sun (2003) destaca que a API é independente do protocolo usado
na representação das mensagens de requisição e de resposta às chamadas de procedimento
remoto, suportando protocolos baseados em XML. No entanto, apesar de especificar a
independência quanto ao protocolo de representação das mensagens, o projeto da API foi
direcionado para o protocolo SOAP, implementando o suporte ao mesmo no pacote
javax.xml.rpc.soap. O protocolo SOAP é um protocolo para intercâmbio de informação em
ambiente descentralizado e distribuído, baseado em XML. Como mecanismo de transporte,
JAX-RPC utiliza o protocolo HTTP. Para a descrição das informações do Serviço, a API
utiliza a linguagem WSDL.
Simplicidade e Interoperabilidade são características destacadas na especificação da API. A
simplicidade está relacionada à maneira de como o desenvolvedor realiza a codificação do
26
Cliente ou do Servidor para a realização da comunicação. Os detalhes de como as
mensagens são codificadas, transmitidas e recebidas não são motivo de preocupação, já que
isto fica transparente ao desenvolvedor.
A interoperabilidade relaciona-se com a capacidade atribuída ao Cliente e ao Servidor de
realizar comunicação independentemente da linguagem ou plataforma que utilizem. A
restrição a esta característica é que as partes envolvidas na comunicação devem utilizar
mecanismos de RPC baseados em XML.
O Serviço em JAX-RPC é desenvolvido e publicado em container de servlet. O JWSDP
1.6 dá suporte aos produtos Sun Java System Application Server Platform Edition 8.1 e
Tomcat 5.0 para Java WSDP. A especificação da API declara somente este modelo de
desenvolvimento do Serviço. Na seção 2.4.3.1.1 serão apresentados os passos básicos para
o desenvolvimento do Servidor.
Será apresentado nas Seções 2.4.3.1.1 e 2.4.3.1.2 a implementação de um Web Service
denominado “Ola” e de um Cliente, utilizando a API JAX-RPC, com a finalidade de
demonstrar os passos básicos para a utilização da API e demonstrar a forma de
comunicação realizada entre as aplicações.
2.4.3.1.1.
Desenvolvimento do Servidor
JAX-RPC possibilita o desenvolvimento do Servidor de duas formas. Na primeira forma,
pode-se desenvolver o Servidor partindo-se de um documento WSDL existente e utilizando
uma ferramenta para realizar o mapeamento da WSDL para Java. O aplicativo wscompile,
que integra a API JAX-RPC, possibilita a realização da tarefa de mapeamento e geração
das classes do Servidor a partir da WSDL. É a forma mais complexa, já que a codificação
da WSDL não é uma ação simples, como foi descrito na Seção 2.4.1.
A segunda forma, que será descrita nessa seção, é codificando a interface e a classe que
implementa a interface. JAX-RPC é bastante semelhante ao RMI no tocante à
implementação do Servidor. Além disso, as chamadas aos métodos do Serviço pelo cliente
são realizadas como se o Cliente estivesse executando métodos de um objeto local,
facilitando o desenvolvimento.
27
Nessa aplicação o Serviço resume-se a um método que retorna ao cliente a mensagem “Olá
<nome >”, sendo que o nome é o parâmetro passado pelo cliente na chamada do método. O
primeiro passo para o desenvolvimento do servidor é criar a interface com a assinatura do
método. A Figura 4 apresenta a interface de um Web Service, desenvolvido a partir dos
exemplos contidos em Sun (2005).
1.
2.
3.
4.
5.
6.
7.
8.
package ola;
import java.rmi.*;
java.util.*;
public interface OlaIF extends Remote{
public String dizerOla(String nome) throws RemoteException;
}
Figura 4 – Exemplo de Interface de um Web Service com JAX-RPC.
A interface apresentada na Figura 4 contém a assinatura do método denominado dizerOla,
o qual recebe um parâmetro do tipo String e retorna uma String como resultado. A
interface deve estender a interface Remote do pacote java.rmi e os métodos precisam
declarar que podem lançar uma exceção remota do tipo RemoteException, quando a
chamada a um método falhar. Os parâmetros dos métodos e o tipos de dados de retorno
devem respeitar os tipos de dados suportados pela API, conforme apresentados em Sun
(2003).
A implementação do Servidor é realizada como uma classe comum, implementando a
interface do Serviço. A classe deve implementar os métodos declarados na interface e deve
possuir um construtor padrão, como mostra o trecho em negrito, na figura 5 . Além disso,
atributos e métodos de acesso local podem ser adicionados ao código da classe, a critério
do desenvolvedor.
O Servidor pode implementar ainda a interface ServiceLifecycle, que possibilita a
realização de operações de gerenciamento de sessão. A Figura 5 contém um exemplo de
uma classe que implementa a interface apresentada na Figura 4.
28
1. package ola;
2. import java.rmi.*;
3. import java.util.*;
4. import javax.xml.rpc.*;
5.
6. public class OlaImpl implements OlaIF{
7. public OlaImpl(){}
8. public String dizerOla(String nome){
9.
return “Olá “+nome;
10. }
11. }
Figura 5 – Exemplo de Classe de Implementação de um Web Service com JAX-RPC.
A classe OlaImpl, apresentada na Figura 5, implementa o método remoto dizerOla
declarado na interface OlaIF, mostrado na figura 4, e um construtor padrão. Além do
pacote java.rmi a classe deve importar o pacote javax.xml.rpc que contém as classes
necessárias para a implementação do Servidor. Como pode ser notado, esta classe não
implementa a interface ServiceLifecycle.
Um ponto importante a ser analisado no momento da criação do Servidor é quanto aos
tipos de dados dos parâmetros e dos dados de retorno dos métodos remotos. Como já
mencionado, os tipos de dados devem ser os tipos declarados pela especificação da API.
No entanto, podem ser utilizados tipos definidos pelo desenvolvedor, que são
implementados em classes cujos atributos, parâmetros e retorno de métodos devem ser
declarados com tipos dentre os definidos na especificação.
A API, através do aplicativo wscompile, realiza o mapeamento dos tipos de dados do
Servidor para os tipos definidos pela especificação da linguagem WSDL, criando o arquivo
WSDL referente ao Serviço, visando a padronização e assim permitindo a
interoperabilidade entre as aplicações Clientes e o Servidor.
Para que o Serviço seja publicado e assim disponibilizado aos Clientes, é necessário criar a
WSDL e os arquivos WAR. Estas tarefas são utilizadas através dos aplicativos wscompile,
jar e wsdeploy, sendo que estes aplicativos necessitam de documentos XML que devem
29
conter uma estrutura específica para cada aplicativo. A Figura 6 apresenta um documento
XML utilizado pelo aplicativo wscompile.
1.
2.
3.
4.
5.
6.
7.
<?xml version="1.0" encoding="UTF-8"?>
<configuration xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
<service name="Teste" targetNamespace="urn:Foo" typeNamespace="urn:Foo"
packageName="ola">
<interface name="ola.OlaIF"/>
</service>
</configuration>
Figura 6 – Documento XML utilizado pelo aplicativo wscompile.
No documento XML apresentado na Figura 6, o atributo packageName do elemento
service contém o nome do pacote onde estão as classes compiladas do Servidor. O atributo
name do elemento interface contém o nome da interface. Além de criar a WSDL para o
Serviço, o aplicativo também gera um arquivo modelo que contém o mapeamento dos tipos
de dados do Serviço para os tipos de dados suportados pela API. Este arquivo modelo será
utilizado pelo aplicativo jar.
Para a geração do arquivo com a extensão .war, é necessário inicialmente executar o
aplicativo jar, o qual utiliza um documento XML denominado jaxrpc-ri. A Figura 7
apresenta um documento XML utilizado pelo aplicativo jar.
30
1. <?xml version="1.0" encoding="UTF-8"?>
2. <webServices xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/dd" version="1.0"
3.
targetNamespaceBase="urn:Foo" typeNamespaceBase="urn:Foo"
4.
urlPatternBase="/ws">
5.
<endpoint name="Ola" display-name="Servico Web Ola"
6.
description="Web Service usando JAX-RPC."
7.
interface="ola.OlaIF" model="/WEB-INF/model.gz"
8.
implementation="ola.OlaImpl"/>
9.
<endpointMapping endpointName="Ola" urlPattern="/ola"/>
10. </webServices>
Figura 7 – Documento XML utilizado pelo aplicativo jar.
No documento XML apresentado na Figura 7, o atributo name do elemento endpoint
contém o nome do Serviço, o qual é referenciado pelo atributo endpointName do elemento
endpointMapping. O atributo interface do elemento endpoint contém o nome do pacote e
da interface, e o atributo implementation contém o nome do pacote e da classe que
implementa o Servidor. O atributo urlPattern do elemento endpointMapping especifica a
String que será incorporada ao url gerado pelo container Web.
Para a tarefa final de criação do arquivo .war para publicação no container Web, é utilizado
o aplicativo wsdeploy, o qual necessita de um documento XML denominado web que
contenha os dados que serão publicados. A Figura 8 apresenta um documento XML
utilizado pelo aplicativo.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
2.3//EN" "http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">
<web-app>
<display-name>Servico Web Ola</display-name>
<description>Web Service usando JAX-RPC.</description>
<session-config>
<session-timeout>60</session-timeout>
</session-config>
</web-app>
Figura 8 – Documento XML utilizado pelo aplicativo wsdeploy.
31
No documento XML apresentado na Figura 8, o elemento display-name contém o nome
que será apresentado na tela de visualização das aplicações do container Web. O elemento
description contém a descrição.
Os aplicativos devem ser executados seqüencialmente, começando pelo wscompile, e em
seguida o aplicativo jar e depois wsdeploy. Mais detalhes da execução destes aplicativos e
dos comandos podem ser encontrados em Nunes (2005). Uma vez que o Serviço esteja
publicado, é possível criar aplicações Clientes. Na seção seguinte serão apresentados os
passos básicos para a criação de um programa Cliente.
2.4.3.1.2.
Desenvolvimento do Cliente
Segundo Sun (2005), existem várias formas de se desenvolver um Cliente JAX-RPC.
Dentre elas podemos citar o Cliente de Stub Estático, o Cliente de Proxy Dinâmico, o
Cliente de Interface de Invocação Dinâmica e o Cliente de Aplicação. A diferença básica
entre cada um dos métodos de desenvolvimento consiste no momento em que são obtidos
os objetos que referenciam o Serviço. Sun (2005) apresenta detalhes da criação destes
modelos, sendo que nesse trabalho é abordado o modelo mais simples, o Cliente de Stub
Estático, o qual será apresentado nesta Seção.
Neste modelo a referência ao Serviço é uma classe Stub que é obtida em tempo de
desenvolvimento através do aplicativo wscompile, o qual constrói também arquivos
serializadores e tipos de valores. Para criar as classes utilizadas na aplicação cliente é
necessário, apenas, que se tenha a localização da WSDL do servidor.
O objeto Stub que contém a referência age como um proxy para o Serviço remoto. Assim,
as chamadas ao Serviço são realizadas através do objeto local, utilizando o objeto Stub. A
Figura 9 apresenta um exemplo de Cliente de Stub Estático para o Servidor definido na
Seção 2.4.3.1.1.
32
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
import javax.xml.rpc.Stub;
import ola.*;
public class ClienteOla{
public ClienteOla(String endereco){
try{
Stub stub = (Stub) (new Ola_Impl().getOlaIFPort());
String prop = javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY;
stub.setProperty(prop,endereco);
OlaIF ola = (OlaIF) stub;
System.out.println(ola.dizerOla(“Luiz”));
}catch(Exception ex){
ex.printStackTrace();
}
}
public static void main(String args[]){
if (args[0] != null){
ClienteOla clienteOla = new ClienteOla(args[0]);
}
System.exit(0);
}
}
Figura 9 – Exemplo de Classe de Implementação de um Cliente JAX-RPC.
A classe ClienteOla, apresentada na Figura 9, implementa um Cliente JAX-RPC do
Serviço apresentado na Figura 5. Os trechos relacionados à comunicação com o servidor
estão em negrito no código. A classe deve importar o pacote javax.xml.rpc.Stub, a fim de
poder instanciar um objeto Stub, definido no pacote. Como se trata de um Cliente de Stub
Estático, ele deve importar também o pacote que contém as classes compiladas com base
na especificação do Servidor.
Dentre as classes que o aplicativo wscompile gera está a classe Ola que é uma interface que
estende a interface Service do pacote javax.xml.rpc. A classe Ola_Impl implementa a
interface Ola, que contém o método getOlaIFPort, que retorna um objeto Stub que
referencia o Serviço.
Após
a
obtenção
do
Stub,
é
necessário
configurar
a
propriedade
ENDPOINT_ADDRESS_PROPERTY, a qual armazenará o endereço do Serviço, através
do método _setProperty do objeto Stub. Por fim, é necessário converter o objeto Stub para
33
um objeto do tipo da interface do Servidor, através de uma operação de casting, permitindo
a chamada de métodos remotos. A linha 10 do exemplo apresentado na Figura 5 demonstra
esta operação.
Como é possível notar, o aplicativo wscompile adota uma nomenclatura na geração das
classes. Para interface que extende a interface Service é atribuído um nome com a
nomenclatura <nome_do_serviço>. Para a classe que a implementa é atribuído um nome na
forma <nome_do_serviço>_Impl, e para o método que retorna um objeto Stub a forma é
get<nome_do_serviço>IFPort.
Como já foi comentado, as tarefas de desenvolvimento do Serviço e do Cliente não
correspondem apenas às tarefas descritas nesta Seção. A API JAX-RPC faz uso dos
aplicativos wscompile, wsdeploy e jar para concluir as tarefas mencionadas, os quais fazem
uso de arquivos XML para obter os dados de configuração necessários à execução dos
aplicativos. Além dos arquivos XML apresentados nas Figuras 6, 7 e 8, para compilação do
cliente é utilizado também o arquivo apresentado na Figura 9. Mais detalhes sobre a
utilização dos aplicativos podem ser encontrados em Nunes (2005) e na Seção 4.5.
2.5. B2B
A sigla B2B, derivada da expressão Business-to-Business (Negócio-a-Negócio), representa
a modalidade de negócio eletrônico realizado entre empresas, tidas como parceiras
comerciais umas das outras. Uma definição para o termo é apresentada por Silvestre
(2004): “nesse modelo as partes são duas organizações que interligam-se, geralmente em
uma relação de fornecedor ou usuário de produtos, serviços ou informação.” A interligação
de empresas, nessa modalidade negócio eletrônico, permite a troca de informações, muitas
vezes confidenciais, onde apenas o suficiente para a realização de negócios é
disponibilizado.
Amor (2000) enumera várias justificativas para a adoção do negócio eletrônico, tais como:
a busca pela expansão do alcance de mercado; tornar-se mais visível ao mercado alvo;
entregar resposta mais rapidamente aos clientes e parceiros; disponibilizar novos serviços;
34
fortalecer o relacionamento entre parceiros comerciais; e reduzir custos nas operações e,
conseqüentemente em produtos e serviços.
O surgimento da tecnologia de Web Services proporcionou que empresas com diferentes
sistemas informatizados pudessem interligá-los, obtendo mais agilidade na realização de
processos de negócios e reduzindo custos das operações, antes realizadas de forma manual,
envolvendo métodos de comunicação muitas vezes ultrapassados e consumindo os valiosos
recursos humanos. Na seção 2.6 serão apresentados mais detalhes relativos à tecnologia de
Web Services e o B2B.
2.6. Web Services em B2B
A adoção de padrões da Internet pela tecnologia de Web Services possibilita a integração de
aplicações heterogêneas permitindo que empresas possam ampliar seus serviços. Sistemas
que anteriormente não poderiam ser integrados devido a questões tecnológicas ou de custos
agora, interligados, permitem que empresas possam intercambiar informações formando
um modelo de negócio eletrônico vantajoso para ambos. Com isso fica fortalecida a
parceria entre as empresas, que antes tinham que realizar suas interações de outras formas.
Os processos de negócios agora podem (e até devem) ser repensados com o intuito de
avaliar as vantagens da informatização. Processos de negócios que antes eram realizados da
forma tradicional, consumindo recursos humanos e meios de comunicação dispendiosos,
agora podem ser conduzidos de forma ágil, com menor probabilidade de erros e com baixo
custo.
Pode-se citar como exemplo o serviço de reserva de veículos oferecido por uma locadora
de veículos, o qual seria realizado através da integração do sistema informatizado da
locadora com o de um hotel. No ato da realização de uma reserva junto ao hotel, um
hóspede poderia solicitar a reserva de um veículo, o que seria realizado automaticamente
pelo funcionário na interface do sistema do hotel, facilitando a manipulação pelo
funcionário, agilizando o processo de reserva, prestando um serviço de maior qualidade ao
hóspede, e economizando recursos e tempo na realização da transação.
35
Nesta negociação, a integração dos sistemas e a parceria entre as empresas ficariam
transparentes para o hóspede, que conduziria as negociações com o hotel. Posteriormente,
de acordo com as questões contratuais mantidas pelas empresas parceiras, os acertos seriam
realizados, quando o hotel repassaria os valores referentes à locação do veículo à locadora.
Nota-se, nesta rápida exposição, que a integração dos sistemas proporciona a expansão dos
serviços prestados pelo hotel aos seus clientes, sem significar aumento nos preços. Quanto
à locadora, a parceria representa uma expansão de mercado.
No tocante ao aspecto tecnológico, outros padrões como RMI e CORBA também poderiam
ser empregados, observando-se as limitações de cada um, a depender das características
dos sistemas a serem interligados, tais como plataformas, linguagens em que foram
desenvolvidos e custos envolvidos na operação de integração, como contratação de uma
equipe de desenvolvimento e treinamento de pessoal.
Neste contexto, a tecnologia de Web Services não parece ter surgido para substituir as
tecnologias existentes, mas sim proporcionar um maior poder de escolha por parte das
empresas no momento da integração dos sistemas. Observando o que foi citado logo acima,
o que vai determinar que uma tecnologia seja utilizada em contrapartida a outra são as
características de cada um dos sistemas.
36
3. MATERIAL E MÉTODOS
3.1. Material
O material utilizado compreende equipamentos de hardware e softwares, além do material
bibliográfico discriminado no capítulo referente às referências bibliográficas. Os
equipamentos de hardware serão apresentados na Seção 3.1.1. Os softwares utilizados
serão discriminados na Seção 3.1.2.
3.1.1. Hardware
O trabalho não necessitou de equipamentos de hardware especiais para o desenvolvimento.
Os equipamentos compreendem dois microcomputadores, cujas configurações serão a
seguir discriminadas:
•
Microcomputador tipo desktop, com processador Pentiun III com freqüência de 1.0
Gigahertz, com 256 MB de memória RAM, com disco rígido de 20 GB, com
unidade leitora/gravadora de CD/DVD, com unidade leitora/gravadora de disquetes
de 1.44 MB. O acesso à internet foi realizado através de conexão banda larga,
utilizando um modem D-Link 500G. Este conjunto de hardware foi utilizado na
fase de desenvolvimento e testes das aplicações e, principalmente, no
desenvolvimento
desta
Revisão
de
Literatura,
apresentando
desempenho
satisfatório na execução das atividades, sem a necessidade de quaisquer adaptações
ou substituições de peças e equipamentos.
37
•
Microcomputador tipo desktop, com processador Pentiun III com freqüência de 1.0
Gigahertz, com 256 MB de memória RAM, com disco rígido de 20 GB, com
unidade leitora de CD, com unidade leitora/gravadora de disquetes de 1.44 MB, nas
dependências do complexo de informática do CEULP/ULBRA. Este conjunto de
hardware foi utilizado principalmente para a realização de pesquisas na Internet,
auxiliando no desenvolvimento desta Revisão de Literatura, e apresentou também
desempenho satisfatório na execução das atividades, sem a necessidade de
quaisquer adaptações ou substituições de peças e equipamentos.
3.1.2. Software
Os equipamentos de hardware discriminados na Seção 3.1.1 utilizaram a plataforma
Windows, o primeiro com o Sistema Operacional Windows XP Professional Service Pack
2, e o segundo com o Sistema Operacional Windows 2000 Professional.
Para o desenvolvimento desta Revisão de Literatura, foi utilizado o aplicativo Microsoft
Word 2003 como editor de texto, e o Adobe Acrobat Reader 7.0 para leitura de
documentos diversos.
O navegador Web Microsoft Internet Explorer Versão 6.0 foi utilizado para a realização de
buscas na Internet, leitura de documentos e tutoriais, e no desenvolvimento e testes das
aplicações.
O desenvolvimento da modelagem do Web Service foi realizado com o auxílio do
aplicativo Rational Rose versão 2003.
Na edição das classes Java e dos arquivos XML foram utilizados o Jcreator LE versão
3.5.013, cuja versão é freeware, e o Bloco de Notas versão 5.1. Para as tarefas de
compilação e execução foi utilizado o JDK 5.0 (Java 2 Platform Standard Edition
Development Kit 5.0 Update 5), associado ao JWSDP versão 1.6. O container Web
utilizado foi o Tomcat 5.0 para JWSDP para a publicação do Serviço.
Na edição da aplicação Cliente foi utilizada a Linguagem PHP, cuja instalação foi realizada
com pacote da versão 5.1.4. Como editor das páginas PHP foi utilizado o Macromedia
Dreamweaver 8. Como servidor Web foi utilizado o Internet Information Services versão 5.
38
Como sistema gerenciador de banco de dados foi utilizado o MySQL versão 4, auxiliado
pelo aplicativo de consulta MySQL Query Browser versão 1.1.20 para Windows, utilizados
tanto no desenvolvimento do Servidor quanto na aplicação Cliente.
3.2. Métodos
A fase inicial do trabalho constituiu-se de buscas e leituras de textos, tutoriais e
documentos na Internet e consultando livros diversos, os quais são citados no capítulo de
referências bibliográficas, buscando o entendimento dos conceitos da tecnologia de Web
Services, da API JAX-RPC e dos aplicativos necessários para o desenvolvimento das
aplicações. O estudo da especificação técnica da API JAX-RPC foi de extrema importância
para o desenvolvimento do trabalho, destacando-se como o principal documento de
referência.
Passada a fase inicial, passou-se a definição do domínio e à modelagem do Web Service.
Posteriormente, iniciou-se a codificação das classes Java, acompanhando rigorosamente a
modelagem desenvolvida.
Para a definição da aplicação Cliente, buscou-se levantar as linguagens que oferecessem
suporte à tecnologia de Web Services, destacando-se a linguagem PHP devido à quantidade
de material de referência e tutoriais encontrados com extrema facilidade na Internet. Foi
escolhida uma linguagem distinta da implementação do servidor para mostrar a
interoperabilidade.
Terminadas as etapas de desenvolvimento das aplicações, passou-se à fase de testes, na
qual foi possível constatar o funcionamento das aplicações. Questionamentos surgiram a
respeito do real destaque da tecnologia de Web Services na integração de aplicações.
Por fim, passou-se à conclusão deste relatório, já com as devidas conclusões a respeito do
tema proposto, anotando-se as dificuldades encontradas e os pontos positivos e negativos
da utilização da tecnologia empregada.
39
4. RESULTADOS E DISCUSSÃO
4.1. Domínio
Na definição do domínio buscou-se colocar em discussão um tema que refletisse mais
adequadamente o assunto proposto neste estudo, que é a relação entre B2B e Web Services,
e não apenas um exemplo comum como os encontrados nos diversos tutoriais e
documentos sobre a tecnologia de Web Services, que, na maioria das vezes, não reflete as
situações do mundo real. Também se buscou um tema de acordo com as características da
modalidade de negócio eletrônico B2B, tentando levantar e discutir questões a respeito das
vantagens e desvantagens da integração de aplicações entre parceiros comerciais.
Neste trabalho foi desenvolvido um Web Service de uma locadora de veículos, onde é
possível receber solicitação de reservas de veículos, além de operações como alteração e
cancelamento de reserva, busca de veículos disponíveis para reserva e busca das reservas
realizadas pelos Clientes, neste caso, empresas parceiras.
A definição de um Web Service disponibilizado por uma locadora de veículos foi devido ao
fato deste ramo comercial oferecer um tipo de serviço que é utilizado por vários segmentos,
sendo viável buscar parcerias através da utilização da tecnologia de Web Services. As
operações relativas à reserva de veículos foram tidas como as mais relevantes, por isso
foram disponibilizadas pelo Web Service implementado aos seus parceiros comerciais.
Não foram desenvolvidas funcionalidades de gerenciamento de usuários e tampouco de
veículos, sendo que os dados necessários às operações de reserva foram inseridos
40
manualmente no banco de dados. Isso se deve ao fato do trabalho enfocar a comunicação
entre aplicações de empresas distintas.
Os clientes do serviço podem ser aplicações Web, aplicativos Desktop, ou outro Web
Service. Neste trabalho, para a aplicação Cliente foi idealizada uma aplicação Web de um
hotel que realizaria o papel de parceiro comercial, porém, vários outros segmentos
poderiam usar esse serviço, como, por exemplo, uma empresa de turismo. A aplicação Web
do hotel é integrada ao Web Service da locadora, buscando disponibilizar aos seus
hóspedes um serviço diferenciado, facilitando a realização do processo de negócio entre as
empresas parceiras, proporcionando aos funcionários mais facilidade na realização de suas
atividades. As reservas de veículos seriam integradas à aplicação Web do hotel.
Para a implementação do Servidor foi utilizada a API JAX-RPC, que integra o JWSDP. A
utilização da linguagem Java deve-se ao fato de ser uma linguagem portável e devido ao
fato de existirem estudos anteriores sobre o desenvolvimento de Web Services em Java.
A linguagem utilizada para a implementação do cliente foi a PHP e não o Java, que é a
linguagem do servidor, visando demonstrar a interoperabilidade dos Web Services, sendo
que foi comprovado que existe independência de plataforma e de linguagem de
programação. A linguagem PHP gratuita foi escolhida por ser simples, no tocante à
instalação e configuração, e por oferecer uma vasta bibliografia em português, não tendo
sido realizados testes comparativos com outras linguagens para essa escolha.
Neste trabalho não foram levadas em consideração questões relacionadas à segurança na
comunicação das aplicações, haja vista que se notou que o trabalho se estenderia a um
nível bastante elevado, e que o tempo disponível não proporcionaria a obtenção de
resultados satisfatórios. Porém, é importante mencionar que para colocar o serviço em uso,
seria interessante acrescentar a segurança na comunicação.
4.2. Comunicação das Aplicações
A comunicação da aplicação cliente com o Web Service é realizada de forma transparante
para o usuário da aplicação do hotel. A Figura 10 apresenta os detalhes da comunicação.
41
Figura 10 - Arquitetura de Comunicação
da Aplicação Cliente com o Web Service
Como pode ser visto na Figura 10, o usuário interage com a aplicação do hotel através do
navegador, que realiza uma requisição HTTP para o servidor Web, no caso o IIS. Quando a
página solicitada necessita realizar uma chamada ao Web Service, o Cliente PHP solicita o
documento WSDL, que é devolvido pelo Servidor. De posse do documento WSDL, o
Cliente PHP realiza um chamada a um método do Web Service, que processa a chamada e
envia o retorno. A comunicação nas chamadas e retorno de métodos do Web Service são
realizadas através do protocolo SOAP sobre HTTP. Ao final da realização das operações
solicitadas pelo usuário, uma resposta HTTP é enviada ao navegador e o resultado é
exibido ao usuário.
42
4.3. Modelagem do Web Service
A modelagem apresentada neste trabalho compreende apenas às funcionalidades
desenvolvidas no Web Service, no tocante à locadora de veículos, não sendo realizada a
modelagem das funcionalidades do hotel, já que esta foi implementada apenas para
demonstrar a utilização do serviço. Nas Seções 4.3.1 e 4.3.2 são apresentados e discutidos
apenas os principais diagramas da modelagem, sendo que a modelagem completa está
disponível no Anexo I.
4.3.1. Funcionalidades do Web Service
As funcionalidades modeladas são relacionadas às reservas de veículos, as quais seriam
disponibilizadas aos funcionários do hotel através da aplicação Web do hotel. São elas:
•
Buscar Veículos: buscar a relação dos veículos disponíveis para reserva;
•
Reservar Veículo: permitir a reserva de um veículo por um determinado cliente;
•
Buscar Reservas: buscar os dados das reservas, de acordo com os parâmetros
desejados, tais como: identificador do cliente, senha, lista com os identificadores
das reservas, período de realização das reservas (data inicial e data final do período)
e status;
•
Alterar Reserva: permitir a alteração da data de retirada e de devolução do veículo;
•
Cancelar Reserva: permitir o cancelamento de uma determinada reserva.
A Figura 11 apresenta o diagrama de casos de uso. Como pode ser observado na Figura 10,
em todas as funcionalidades o ator representa a empresa Cliente.
43
Reservar Veiculos
Buscar Veiculos
Cliente
Buscar Reservas
Alterar Reserva
Cancelar Reserva
Figura 11 – Diagrama de Casos de Uso.
4.3.2. Diagrama de Classes
Com base no diagrama de caso de uso, apresentado na Figura 10, e no desenvolvimento de
cada uma das funcionalidades, foram definidas as classes necessárias à implementação do
Web Service. A Figura 12 apresenta o diagrama de classes do Web Service.
44
Reserva
idReserva : int
dataReserva : java.util.Date
dataRetirada : java.util.Date
dataPrevDevolucao : java.util.Date
dataDevolucao : java.util.Date
quilometragemRetirada : int
quilometragemDevolucao : int
status : String
valorQuilometro : float
valorDiaria : float
idVeiculo : int
idCliente : int
criarReserva()
adicionarReserva()
buscarReservas()
buscarReserva()
alterarReserva()
cancelarReserva()
0..*
possui
0..*
possui
1
Veiculo
idVeiculo : int
modelo : String
marca : String
cor : String
ano : int
numPortas : int
numPassageiros : int
categHabilitacao : char
quilometragemAtual : int
valorQuilometro : float
valorDiaria : float
status : String
buscarVeiculos()
alterarVeiculo()
Veiculo()
Veiculos
buscarVeiculos()
alterarVeiculo()
1
Reservas
Cliente
(from Use Case View)
idCliente : int
senha : String
nome : String
responsavel : String
status : String
reservarVeiculo()
buscarReservas()
alterarReserva()
cancelarReserva()
Clientes
buscarCliente()
buscarCliente()
Figura 12 – Diagrama de Classes do Web Service.
No diagrama apresentado na Figura 12, a classe Cliente representa a empresa Cliente, a
qual foi definida como o ator no diagrama de casos de uso apresentado na Figura 10. A
classe Veiculo define os dados de cada veículo que serão armazenados no sistema, e que
são relevantes no conjunto das operações. A classe Reserva define os dados das reservas
45
realizadas e que também são relevantes no conjunto das atividades. Além dos dados,
representados pelos atributos das classes, são definidos também os métodos de cada classe,
necessários na realização das operações. Não foram representados neste diagrama os
métodos de acesso aos atributos das classes devido à quantidade de atributos existentes.
Além das classes que definem as entidades do sistema, foram representadas também as
classes que, no desenvolvimento da modelagem, tornaram-se necessárias. As classes
Clientes, Veiculos e Reservas definem classes com métodos estáticos que servem de
classes controladoras e que, desta forma, ficam isoladas no diagrama. Na Seção 4.5 será
descrita a implementação do Serviço.
4.4. Considerações sobre o serviço
No serviço implementado, em cada solicitação ao Web Service deve ser realizada a
autenticação do Cliente, necessitando assim que os dados de identificação da empresa
Cliente sejam encaminhados juntos com os demais dados de cada solicitação.
Devido às características da aplicação, a operação de autenticação dos Clientes deve ficar
transparente aos usuários das aplicações Clientes. Como o código da aplicação não fica à
vista do usuário, os dados de autenticação podem ficar embutidos no código. Além disso,
observou-se que o reenvio destes dados em cada solicitação não acarreta aumento
significativo no tempo de execução da solicitação.
Em uma situação em que o Servidor atendesse a um número maior de solicitações, a
manutenção de sessões poderia sobrecarregar a memória do Servidor. Uma alternativa para
esta situação seria a adoção do monitoramento de sessão com a definição de sessões com
tempo reduzido, e sempre com o reenvio dos dados de identificação do Cliente. A
manutenção de sessões permitiria maior agilidade na execução da funcionalidade, evitando
que a toda solicitação fosse realizada a verificação dos dados do Cliente na base de dados
do sistema. O reenvio dos dados permitirá a verificação imediata dos dados no caso de
tempo de sessão expirado. De qualquer forma, ficou definido neste trabalho não adotar o
gerenciamento de sessão por esta ser a maneira mais complexa de ser implementada.
46
Na modelagem, ficou definido que deveria existir um status relacionado ao cliente: ativo,
para o cliente que está em dia com as suas obrigações; e inativo, para os clientes que
possuem alguma pendência. Em todas as funcionalidades, com exceção da ação de busca
de reservas, o cliente deve estar com status definido como ativo, proporcionando à
locadora de veículos que somente esses possam solicitar a execução das funcionalidades.
Quanto à funcionalidade de busca de reservas, ela ficaria ativa até mesmo aos Clientes com
status definido como inativo, proporcionando aos mesmos que solicitassem ao sistema,
através desta funcionalidade, os dados relativos às reservas realizadas, possibilitando um
acompanhamento completo.
Neste trabalho, a locadora de veículos não tem a responsabilidade de armazenar os dados
pessoais dos condutores dos veículos, ficando esta tarefa a cargo de cada Cliente. Dentro
de um contexto do mundo real, por questões contratuais, inclusive a respeito da
necessidade de realização de seguros dos veículos, poderia ser necessária a manutenção
pela locadora dos dados dos condutores, o que significaria a necessidade de envio destes
dados no ato da solicitação da reserva, o que alteraria a estrutura do Web Service.
Não foi implementada uma funcionalidade para confirmação de reservas, uma vez que se
buscou analisar apenas questões de comunicação, e não o desenvolvimento completo de
um sistema para uma locadora de veículos.
Finalizada a modelagem do Web Service, passou-se à fase de codificação das classes da
interface e da implementação do Serviço, que é apresentada na seção 4.5. Por fim, foi
implementado um cliente para testar o serviço, um trecho do código é apresentado na seção
4.6. O código completo do cliente será apresentado no Anexo III.
4.4.1. Questão Legal do Serviço
O trabalho desenvolvido buscou abordar questões tecnológicas para a modalidade de
comércio eletrônico business-to-business, não fazendo parte do foco abordar questões
legais a respeito, uma vez que envolve vários fatores. Além disso, no que diz respeito a
legislação, não existe uma definição em relação aos B2B no Brasil, nem a respeito de
empresas do mesmo país nem em relação a empresas atuando em países distintos, o que
47
complicaria um pouco mais a questão legal. No entanto, passou-se a uma rápida análise
desse assunto em relação ao comércio eletrônico, que foi descrita baseada em leituras em
grupos de discussão e em sites de economia, sem grande relevância científica.
As funcionalidades disponibilizadas pela locadora de veículos às empresas Clientes através
do Web Service não configura comercialização de produto ou serviço através de meio
eletrônico. O que se entende é que é apenas uma forma de comunicação e solicitação de
serviço, tal como ocorre com o telefone ou outro meio de comunicação. O serviço prestado
pela locadora às empresas Clientes não ocorre de fato no meio eletrônico, ficando este
meio apenas como forma de solicitação, no qual a entrega do veículo se dá pessoalmente.
Passando-se a analisar a situação em que a contratação ocorreria de forma virtual, em que
as empresas Clientes contratariam com a locadora de veículos através de contrato
disponibilizado por meio eletrônico, e não pessoalmente, é necessário buscar uma análise
para o assunto no tocante a questões legais quanto ao contrato firmado. A busca por ambas
as partes em exigir o cumprimento do contrato pode ser uma tarefa difícil, principalmente
quando se tratar de empresas situadas em países distintos.
Por fim, mesmo quando o contrato é firmado pessoalmente, observa-se que a confirmação
de uma determinada reserva poderia ser um dos pontos mais relevantes nesta discussão
caso não seja adotado um sistema confiável de confirmação de reserva, seja qual for o meio
de comunicação.
4.5. Implementação do Serviço
Conforme mencionado na Seção 2.4.3.1.1, o Servidor pode ser implementado de duas
formas. Neste trabalho, a implementação foi realizada codificando-se a interface e a classe
de implementação do Servidor. A interface do Serviço define os métodos que serão
disponibilizados às aplicações Clientes. A Figura 13 apresenta o código da interface do
Serviço.
48
1.
package locadora;
2.
3.
4.
import java.rmi.*;
import java.rmi.RemoteException;
import java.util.*;
5.
public interface LocadoraIF extends Remote{
6.
public Object[] buscarVeiculos(int idCliente, String senha) throws
RemoteException;
7.
8.
public boolean reservarVeiculo(int idCliente, String senha, int idVeiculo, Date
dataRetirada, Date dataPrevDevolucao) throws RemoteException;
9.
10.
public Object[] buscarReservas(int idCliente, String senha, Object[] listIdReservas,
Date dataInicialReservas, Date dataFinalReservas, String status) throws RemoteException;
11.
12.
public boolean alterarReserva(int idCliente, String senha, int idReserva, Date
dataRetirada, Date dataPrevDevolucao) throws RemoteException;
13.
14.
public boolean cancelarReserva(int idCliente, String senha, int idReserva) throws
RemoteException;
15. }
Figura 13 – Implementação da Interface do Web Service.
A codificação da interface apresentada na Figura 13 segue a especificação das
funcionalidades do sistema. Considerando-se as características da aplicação, em todos os
métodos definidos na interface, o identificador e a senha do Cliente são obrigatórios, com o
intuito de permitir a autenticação do Cliente em cada solicitação às funcionalidades do Web
Service.
Através do método buscarVeiculos o Cliente solicita a lista dos veículos disponíveis para
reserva. O método tem como parâmetros apenas os dados de identificação do Cliente. A
lista é um array de objetos da classe Veiculo definida na modelagem.
Com o método reservarVeiculo o Cliente pode solicitar a reserva de um determinado
veículo, informando, além dos dados de identificação, o identificador do veículo, a data
pretendida para retirada e a data provável para devolução. Caso a operação seja realizada
com sucesso, o método retornará o identificador da reserva, para controle do Cliente. Caso
ocorra falha na operação será retornado o valor -1.
49
O método buscarReservas possibilita que o Cliente possa obter relatórios de suas reservas,
através de uma lista de reservas que é retornada. Como parâmetros o método possui os
dados de identificação do Cliente, uma lista de identificadores de reservas especificados
através do parâmetro listIdReservas, um intervalo de datas de realização das reservas
especificado através dos parâmetros dataInicialReservas e dataFinalReservas. O último
parâmetro é o status das reservas. Assim, o Cliente pode buscar as reservas que realizou
tendo como base uma lista de identificadores de reservas, ou tendo como base um intervalo
de datas da realização das reservas e o status.
O método alterarReserva possibilita que o Cliente possa alterar a data de retirada e a data
de devolução de uma determinada reserva. Além dos dados de identificação do Cliente, o
método possui como parâmetros o identificador da reserva a ser alterada, a nova data de
retirada e a nova data de devolução do veículo. Como resultado o método retorna um valor
booleano especificando o valor verdadeiro (true) no caso de sucesso e o valor falso (false)
para o caso de falha.
O método cancelarReserva possibilita que o Cliente possa cancelar uma determinada
reserva. Como resultado o método retorna um valor booleano especificando o valor
verdadeiro (true) no caso de sucesso e o valor falso (false) para o caso de falha.
4.6. Implementação do Cliente
Conforme foi mencionado na Seção 4.1, o cliente foi desenvolvido na linguagem PHP, a
fim de demonstrar a interoperabilidade da tecnologia de Web Services. A implementação
do Cliente corresponde a uma aplicação Web de um hotel, em que está disponível aos
funcionários as funcionalidades para a realização de reserva de veículos aos hóspedes,
fazendo uso das funcionalidades do Web Service.
Foram implementadas somente as funcionalidades da aplicação Cliente que utilizam os
métodos do Web Service, porém, em um caso real essa funcionalidade seria parte do
sistema de gerenciamento do Hotel. Assim como no servidor, os dados necessários à
realização das operações foram inseridos manualmente no banco de dados, para simplificar
a implementação e deixar o foco do trabalho na comunicação entre as aplicações.
50
Na linguagem PHP, versão 5, a biblioteca de funções necessária para a criação de
aplicações Clientes de Web Services e Servidores já está incorporada, necessitando apenas
que seja feita a habilitação da biblioteca. Mais detalhes de configuração podem ser
encontados em Php (2006).
A implementação de um Cliente de um Web Service baseado em SOAP na linguagem PHP
é bastante simplificada. Uma vez que se tenha habilitado a biblioteca php_soap.dll no
arquivo de configuração php.ini, no diretório de instalação da linguagem, é possível
instanciar um objeto da classe SoapClient, necessitando saber apenas a localização da
WSDL do Serviço. A Figura 14 apresenta um trecho de código do arquivo veiculos.php,
através do qual é realizada a busca dos veículos da locadora que estão disponíveis para
reserva.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
<?php
$client = new SoapClient("http://localhost:8080/Locadora/locadora?WSDL");
$veiculos = ($client->buscarVeiculos(1,"senha1"));
if (count($veiculos)<=0){
echo("Não existem veículos disponíveis para reserva!");
}else{
//apresenta um formulário para fornecimento dos dados para a reserve.
//trecho omitido devido à extensão do código
}
?>
Figura 14 – Fragmento de Código do Arquivo veiculos.php.
Na Figura 14 foi apresentado somente um fragmento do código do arquivo veículos.php
devido à sua extensão. O arquivo na íntegra pode ser encontrado no Anexo III. Neste
fragmento, observa-se que à variável $client é atribuído o objeto da classe SoapClient
obtido através da instanciação da classe, tendo como parâmetro o endereço da WSDL do
Serviço. Após a instanciação do objeto, é possível realizar chamadas a qualquer método
implementado pelo Web Service. O código em negrito representa estas operações.
A chamada ao método buscarVeiculos do Web Service, apresentada na linha 3 do
fragmento de código da Figura 14, tem como parâmetros o identificador do Cliente, neste
51
caso a empresa parceira, e a senha. Como retorno, será atribuído à variável $veiculos um
array com os dados dos veículos que estão disponíveis para reserva.
Analisando o trecho apresentado nota-se a facilidade da codificação de um Cliente de um
Web Service baseado em RPC, no qual as chamadas aos métodos remotos são realizadas da
mesma forma que seriam feitas às chamadas aos métodos de um objeto local.
No entanto, dificuldades podem ser observadas a respeito dos tipos de dados dos
parâmetros e dos métodos de retorno. Apesar de todo o estudo da especificação da API
JAX-RPC a respeito do mapeamento de dados, e da realização de testes com pequenas
aplicações, foi observado que as diferenças entre as linguagens pode dificultar a integração
das aplicações.
Ainda a respeito do mapeamento de dados, pode-se citar como exemplo a dificuldade
encontrada neste trabalho a respeito dos dados do tipo Data, onde a adoção das classes
java.util.Date e java.sql.Date dificultou o desenvolvimento do trabalho, não permitindo que
tanto um Cliente na própria linguagem java como o Cliente na linguagem PHP pudessem
realizar chamadas aos métodos remotos. Assim, foi definido que os dados do tipo Data
seriam representados como String no Servidor, com a forma “AAAA-MM-DD” para
facilitar a inserção no banco de dados. Na busca por alternativas para o problema, foram
realizadas consultas a diversos fóruns de discussão sobre o assunto, além de um exaustivo
estudo da especificação da API da documentação das classes, sendo que a alternativa
adotada foi a mais fácil de ser implementada, senão a única encontrada, uma vez que testes
com outras alternativas não obtiveram êxito.
Além da dificuldade nos tipos de dados que representam Data, foi notada também uma
dificuldade na adoção dos tipos dos parâmetros e dos dados de retorno dos métodos
remotos do Web Service. A utilização de classes definidas no desenvolvimento para estes
dados não foi possível, embora a API defina que classes que não integram a API possam
ser empregadas, desde que atendidos os requisitos quanto aos tipos de dados dos atributos,
dos parâmetros e dos dados de retorno dos métodos. No caso dos métodos remotos
buscarVeiculos e buscarReservas, são retornados arrays de objetos da classe
java.util.Object, uma vez que as classes Veiculo e Reserva não puderam ser empregadas.
52
Feitas as adequações para sanar as dificuldades acima citadas, observou-se, no entanto, que
deste ponto em diante a implementação do cliente foi realizada com certa facilidade,
especialmente na linguagem PHP.
Ressalte-se também que o fato da linguagem PHP disponibilizar funções nativas, tanto para
criação de Web Services e Clientes quanto para acesso ao Sistema Gerenciador de Banco de
Dados MySQL possibilitou otimizar o desenvolvimento da aplicação.
53
5. CONSIDERAÇÕES FINAIS
O desenvolvimento do trabalho permitiu o levantamento das características da tecnologia
de Web Services bem como da modalidade de comércio eletrônico Business-to-business
(B2B), possibilitando uma avaliação mais concisa a respeito das tecnologias atuais
utilizadas na integração de aplicações, bem como o levantamento das vantagens advindas
da utilização do comércio eletrônico, sobretudo naquela modalidade.
Foi possível notar a importância do emprego da tecnologia de Web Services na realização
de processos de negócio. A informatização das empresas, associada à redução nos custos
dos equipamentos, permitiu a automatização dos processos de negócio, tornando mais ágil,
mais eficiente e menos dispendiosa a sua execução. Nota-se também a importância da
utilização da tecnologia pelas empresas com a finalidade de expandir seus mercados
consumidores, abrangendo regiões geográficas e faixas de mercado antes inatingíveis.
Uma questão que não pode deixar de ser citada é a respeito da importância da busca de
padronização no desenvolvimento de tecnologias, sobretudo a respeito da integração de
aplicações desenvolvidas em plataformas e linguagens de programação diferentes. O
padrão XML facilita o trabalho de padronização, possibilitando a criação de novos padrões,
como é o caso, por exemplo, da linguagem WSDL e do protocolo SOAP.
Em relação a B2B é importante citar que existem poucas informações no que diz respeito à
legislação, sendo que nesse trabalho não foi abordada a relação legal entre as empresas.
Desta forma, esse trabalho apontou a viabilidade em se utilizar os Web Services na ligação
entre aplicações de empresas distintas e mostrou que, realmente, existe portabilidade na
54
utilização dessa tecnologia, já que cliente e servidor foram implementados em linguagens
diferentes.
No que diz respeito à comunicação entre aplicações cliente e servidor implementados em
linguagens distintas, vale ressaltar que, apesar da portabilidade ser garantida pelas
características dos Web Services, podem existir alguns problemas relacionados às
características próprias das linguagens, como, por exemplo, os tipos de dados manipulados
pelas mesmas.
Baseando-se nos estudos realizados nesse trabalho uma questão que não pode ser definida é
qual a melhor tecnologia de comunicação, RMI, CORBA ou Web Services, já que a escolha
depende muito do problema que se quer resolver e, nesse trabalho, foi analisada apenas
uma situação, não sendo realizado um estudo comparativo entre as mesmas. Para a situação
apresentada, a princípio, a melhor escolha é o Web Service, por dois motivos: a facilidade
da implementação do cliente, já que só é necessário conhecer a localização da WSDL; e a
troca de dados XML. Em relação ao RMI, pode-se acrescentar, ainda, que a
interoperabilidade é mais uma vantagem de se utilizar Web Services.
Individualmente, é perceptível o grande valor trazido pelo desenvolvimento deste trabalho,
evidenciando um notável aprendizado a respeito da tecnologia e dos aspectos relativos ao
comércio eletrônico, o qual seguramente pode ser empregado no desenvolvimento de
outros estudos e servir de base para outros trabalhos.
Como trabalhos futuros, pode-se pensar o estudo de aspectos relativos à segurança de Web
Services, uma vez que esta é uma questão essencial, principalmente quando se está
abordando questões comerciais, como é o caso do Business-to-business.
55
6. REFERÊNCIAS BIBLIOGRÁFICAS
(ALBUQUERQUE, 2001)
ALBUQUERQUE, Fernando. TCP/IP – Internet
Programação de Sistemas Distribuídos HTML,
JavaScript e Java. Rio de Janeiro: Axcel Books, 2001.
(AMOR, 2000)
AMOR, Daniel. A ®Evolução do E-Business: Vivendo e
Trabalhando em um Mundo Interconectado. São Paulo:
Makron Books, 2000.
(CASETTI, 1993)
CASETTI, Orestes et al. Paradigmas para Construção de
Sistemas Distribuídos. Brasília: 1993. Disponível em
http://www.serpro.gov.br/publicacao/tematec/1993/ttec13.
Acesso em 29/04/2006.
CHAPPELL, David A. et al. Java Web Services. California:
O’Reilly & Associates, 2002.
(CHAPPELL, 2002)
(COULOURIS, 2001)
(HENDRICKS, 2002)
COULOURIS, George et al. Distributed Systems –
Concepts and Design, 3ª Edição, 2001. Adison Wesley,
Pearson Education.
HENDRICKS, Mack et al. Profissional Java Web Services.
Rio de Janeiro: Alta Books, 2002.
(HORSTMANN, 2003)
HORSTMANN, Cay S. et al. Core Java 2 – Volume II –
Recursos Avançados. São Paulo: Pearson Education do
Brasil, 2003.
(NUNES, 2005)
NUNES, Luiz W. A. Análise da Utilização da API JAX-R
para Acesso a Registros XML. 2005. 95 f. Trabalho de
Estágio (Estágio Supervisionado como Requisito Parcial da
Disciplina de Sistemas de Informação I) – Centro
Universitário Luterano de Palmas, Universidade Luterana do
Brasil, Palmas, 2005.
56
(OASIS, 2004)
OASIS, Organization for the Advancement of Structured
Information Standards. UDDI Spec TC. Disponível em
<http://uddi.org/pubs/uddi-v3.0.2-20041019.htm>. Acesso
em: 30 jun. 2006.
(PHP, 2006)
PHP, Linguagem PHP. Manual do PHP. Disponível em
<http://www.php.net/manual/pt_BR/>. Acesso em: 03 jul.
2006.
(RICCIONI, 2000)
RICCIONI, Paulo Roberto. Introdução a
Distribuídos com CORBA, Visual Books: 2000.
(SILBERSCHATZ, 2004)
SILBERSCHATZ, Abraham et al. Sistemas Operacionais
com Java, 6ª Edição. Rio de Janeiro: Campus, 2004.
(SILVESTRE, 2004)
SILVESTRE, Larissa Jácome Barros. A Utilização do
Padrão XML no Gerenciamento de Processos de
Negócios. 2004. 91 f. Monografia (Pós-Graduação em
Gestão em Novas Tecnologias) – Centro Universitário
Luterano de Palmas, Universidade Luterana do Brasil,
Palmas, 2004.
(SUN, 2003)
SUN, Sun Microsystems. Java API for XML-Based RPC
Specification 1.1. Califórnia, 2003. Disponível em
<http://java.sun.com/xml/downloads/jaxrpc.html>. Acesso
em 30 jun. 2006.
(SUN,2005)
SUN, Sun Microsystems. J2EE 1.4 Tutorial. Disponível em
<http://java.sun.com/j2ee/1.4/docs/tutorial/doc/>. Acesso em
30 jun. 2006.
(TODD, 2003)
TODD, Nick et al. Java Server Pages – O Guia do
Desenvolvedor. Rio de Janeiro: Campus, 2003.
(W3C, 2001)
W3C, World Wide Web Consortium. Web Services
Description
Language.
Disponível
em
<http://www.w3.org/TR/wsdl>. Acesso em: 31 jul. 2006.
(W3C, 2002)
W3C, World Wide Web Consortium. Web Services
Architecture.
Disponível
em
<http://www.w3.org/TR/2002/WD-ws-arch20021114/#whatisws>. Acesso em: 30 jun. 2006.
Objetos
57
ANEXOS
58
ANEXO I: MODELAGEM DO WEB SERVICE
CASOS DE USO EXPANDIDO
Caso de Uso:
Atores:
Finalidade:
Buscar Veículos
Cliente
Buscar a relação de veículos disponíveis
para reserva.
O cliente solicita a relação de veículos
Visão Geral:
disponíveis.
Primário
Tipo:
O cliente deve possuir status “ativo”.
Pré-condições:
Não tem.
Pós-condições:
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa quando o
2. O sistema verifica o status do
cliente solicita os veículos
cliente, busca e retorna uma lista
disponíveis para reserva.
com os dados dos veículos.
2. O sistema retorna mensagem de
Seqüências Alternativas:
erro informando que o status do
cliente está “inativo”.
2. O sistema retorna mensagem de
erro informando a inexistência de
veículos disponíveis para reserva.
59
Caso de Uso:
Atores:
Finalidade:
Visão Geral:
Tipo:
Pré-condições:
Pós-condições:
Reservar Veículo
Cliente
Permitir a reserva de um veículo por um
determinado cliente.
O cliente identifica o veículo, informa a
data de retirada e a data de devolução.
Primário
O cliente deve possuir status “ativo”. O
veículo deve estar disponível para reserva.
É criado um objeto do conceito Reserva
associado ao objeto do conceito Cliente e
ao objeto do conceito Veículo. O atributo
status do objeto do conceito Veículo é
configurado como “reservado”.
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa quando o
2. O sistema verifica o status do
cliente identifica o veículo,
cliente, confirma a disponibilidade
informa o período desejado para
do veículo e retorna mensagem de
locação, e confirma a operação.
confirmação,
contendo
o
identificador da Reserva.
2. O sistema retorna mensagem de
Seqüências Alternativas:
erro informando que o status do
cliente está “inativo”.
2. O sistema retorna mensagem de
erro informando que o veículo está
indisponível para reserva.
60
Caso de Uso:
Atores:
Finalidade:
Buscar Reservas
Cliente
Permitir a busca dos dados das reservas,
de acordo com os parâmetros desejados.
O cliente solicita as reservas de acordo
Visão Geral:
com
os
seguintes
parâmetros:
identificador
do
cliente,
senha,
identificadores das reservas, período da
realização das reservas (data inicial e data
final do período) e status.
Primário
Tipo:
Não tem.
Pré-condições:
Não tem.
Pós-condições:
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa quando o
2. O sistema identifica o cliente,
cliente informa os parâmetros
busca e retorna os dados das
desejados e confirma a operação.
reservas de acordo com os
parâmetros.
2. O sistema retorna mensagem de
Seqüências Alternativas:
erro, informando que o cliente não
foi identificado.
2. O sistema retorna mensagem de
erro informando que não foram
encontradas ocorrências de acordo
com os parâmetros informados.
61
Caso de Uso:
Atores:
Finalidade:
Alterar Reserva
Cliente
Permitir alteração em uma determinada
reserva.
O cliente identifica a reserva e informa o
Visão Geral:
novo período da locação.
Primário
Tipo:
A reserva deve estar com status “a retirar”
Pré-condições:
e o cliente deve estar com status “ativo”.
É alterado o período desejado para
Pós-condições:
locação.
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
1. O cliente informa o novo período e
2. O sistema verifica o status do
solicita alteração.
cliente, realiza a alteração e retorna
mensagem de confirmação.
2. O sistema retorna mensagem de
Seqüências Alternativas:
erro informando que o status do
cliente está “inativo”.
2. O sistema retorna mensagem de
erro informando que a reserva não
existe.
2. O sistema retorna mensagem de
erro informando que a reserva não
permite alteração.
62
Caso de Uso:
Atores:
Finalidade:
Visão Geral:
Tipo:
Pré-condições:
Pós-condições:
Cancelar Reserva
Cliente
Permitir o cancelamento de uma
determinada reserva.
O cliente identifica a reserva e solicita o
cancelamento.
Primário
A reserva deve estar com status “a retirar”
e o cliente deve possuir com status
“ativo”.
O status da reserva é configurado para
“cancelada”. O atributo status do objeto
do conceito Veículo é definido como
“disponível”.
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa quando o
2. O sistema verifica o status do
cliente solicita o cancelamento de
cliente, confere o status da reserva
uma determinada reserva.
e altera para “cancelada”.
2. O sistema retorna mensagem de
Seqüências Alternativas:
erro informando que o status do
cliente está “inativo”.
2. O sistema retorna mensagem de
erro informando que a reserva não
existe.
2. O sistema retorna mensagem de
erro informando que a reserva não
pode ser cancelada.
63
DIAGRAMAS DE CASOS DE USO
Reservar Veiculos
Buscar Veiculos
Cliente
Buscar Reservas
Alterar Reserva
Cancelar Reserva
64
MODELO CONCEITUAL
Veiculo
idVeiculo
modelo
marca
cor
ano
numPortas
numPassageiros
categHabilitacao
quilometragemAtual
valorQuilometro
valorDiaria
status
possui
1
0..*
Reserva
idReserva
dataReserva
dataRetirada
dataPrevDevolucao
dataDevolucao
quilometragemRetirada
quilometragemDevolucao
status
valorQuilometro
valorDiaria
idVeiculo
idCliente
possui
1
0..*
Cliente
(from Use Case View)
idCliente
senha
nome
responsavel
status
65
DIAGRAMAS DE SEQÜÊNCIAS
Buscar Veículos
: Cliente
buscarVeiculos(idCliente,senha)
Sistema
Reservar Veículo
: Cliente
Sistema
reservarVeiculo(idCliente,senha,idVeiculo,dataRetirada,dataPrevDevolucao)
66
Buscar Reservas
: Cliente
Sistema
buscarReservas(dadosDeBusca)
dadosDeBusca: idCliente, senha, listIdReservas,
dataInicialReservas, dataFinalReservas, status.
Alterar Reserva
: Cliente
alterarReserva(idCliente,senha,idReserva,dataRetirada,dataPrevDevolucao)
Sistema
67
Cancelar Reserva
Sistema
: Cliente
cancelarReserva(idCliente,senha,idReserva)
68
CONTRATOS
Buscar Veículos
Contrato:
Nome:
Parâmetros:
Responsabilidades:
Exceções:
Saída:
Pré-condições:
Pós-condições:
Buscar Veículos
buscarVeiculos(parâmetros)
Cliente:
• idCliente
• senha
Buscar os dados dos veículos cujo status é
“disponível”.
Cliente com status “inativo”.
Não tem.
Não tem.
Não tem.
Reservar Veículo
Contrato:
Nome:
Parâmetros:
Responsabilidades:
Exceções:
Saída:
Pré-condições:
Pós-condições:
Reservar Veículo
reservarVeiculo(parâmetros)
Cliente:
• idCliente
• senha
Veiculo:
• idVeiculo
Reserva:
• dataRetirada
• dataPrevDevolucao
Realizar a reserva de um determinado
veículo.
Veículo já reservado.
Não tem.
O cliente deve possuir status “ativo”.
É criado um objeto do conceito Reserva
relacionado ao objeto do conceito Veículo
e ao objeto do conceito Cliente. O atributo
status do objeto do conceito Veículo é
configurado como “reservado”.
69
Buscar Reservas
Contrato:
Nome:
Parâmetros:
Responsabilidades:
Exceções:
Saída:
Pré-condições:
Pós-condições:
Buscar Reservas
buscarReservas(parâmetros)
Cliente:
• idCliente
• senha
Reservas:
• listIdReservas (lista com valores
para o atributo idReserva das
reservas a consultar)
• dataInicialReservas
• dataFinalReservas
• status
Buscar os dados das reservas realizadas,
de acordo com os critérios desejados.
Não tem.
Não tem.
O cliente deve ser identificado.
Não tem.
Alterar Reserva
Contrato:
Nome:
Parâmetros:
Responsabilidades:
Exceções:
Saída:
Pré-condições:
Pós-condições:
Alterar Reserva
alterarReserva(parâmetros)
Cliente:
• idCliente
• senha
Reserva:
• idReserva
• dataRetirada
• dataPrevDevolucao
Alterar a data de retirada e/ou a data de
previsão para devolução de uma
determinada reserva.
Reserva com status “retirado”.
Não tem.
O cliente deve possuir status “ativo”.
São alterados os valores dos atributos
dataRetirada e dataPrevDevolucao do
objeto do conceito Reserva.
70
Cancelar Reserva
Contrato:
Nome:
Parâmetros:
Responsabilidades:
Exceções:
Saída:
Pré-condições:
Pós-condições:
Cancelar Reserva
cancelarReserva(parâmetros)
Cliente:
• idCliente
• senha
Reserva:
• idReserva
Permitir o cancelamento de uma
determinada reserva.
Reserva com status diferente de “a
retirar”.
Não tem.
O cliente deve possuir status “ativo”.
O valor do atributo status do objeto do
conceito Reserva é definido como
“cancelada”. O valor do atributo status do
objeto do conceito Veículo é definido
como “disponível”.
71
DIAGRAMAS DE COLABORAÇÃO
Buscar Veículos
3: cliente := buscarCliente(idCliente,senha)
Cliente
Clientes
2: cliente := buscarCliente(idCliente,senha)
1: buscarVeiculos(idCliente,senha)
Sistema
: Cliente
4: [cliente.getStatus() == "ativo"] listaVeiculos := buscarVeiculos()
Veiculo
Veiculos
5: listaVeiculos := buscarVeiculos()
72
Reservar Veículo
6: [veiculo.getStatus() == "disponivel"] alterarVeiculo(status)
Veiculo
Veiculos
Cliente
5: veiculo := buscarVeiculo(idVeiculo)
4: [cliente.getStatus() == "ativo"] alterarVeiculo(idVeiculo,status)
3: cliente := buscarCliente(idCliente,senha)
1: reservarVeiculo(idCliente,senha,idVeiculo,dataRetirada,dataPrevDevolucao)
2: cliente := buscarCliente(idCliente,senha)
Sistema
Clientes
: Cliente
7: reservarVeiculo(idCliente,idVeiculo,dataRetirada,dataPrevDevolucao)
9: [reserva != null] idReserva := adicionarReserva(reserva)
8: criarReserva(idCliente,idVeiculo,dataRetirada,dataPrevDevolucao)
reserva:
Reserva
Reservas
Reserva
73
Buscar Reservas
Cliente
Clientes
3: cliente := buscarCliente(idCliente,senha)
2: cliente := buscarCliente(idCliente,senha)
1: buscarReservas(idCliente,senha,listIdReservas,dataInicialReservas,dataFinalReservas,status)
Sistema
: Cliente
4: [cliente != null] reservas := buscarReservas(idCliente,listIdReservas,dataInicialReservas,dataFinalReservas,status)
5: reservas := buscarReservas(idCliente,listIdReservas,dataInicialReservas,dataFinalReservas,status)
Reserva
Reservas
74
Alterar Reserva
Cliente
Clientes
3: cliente := buscarCliente(idCliente,senha)
2: cliente := buscarCliente(idCliente,senha)
1: alterarReserva(idCliente,senha,idReserva,dataRetirada,dataPrevDevolucao)
Sistema
: Cliente
4: [cliente.getStatus() == "ativo"] alterarReserva(idCliente,idReserva,dataRetirada,dataPrevDevolucao)
5: reserva := buscarReserva(idReserva)
Reserva
Reservas
6: [reserva.getStatus() == "a retirar" && reserva.getIdCliente() == idCliente] alterarReserva(idReserva,dataRetirada,dataPrevDevolucao)
75
Cancelar Reserva
Clientes
Cliente
Veiculo
3: cliente := buscarCliente(idCliente,senha)
8: alterarVeiculo(reserva.getIdVeiculo(),status)
2: cliente := buscarCliente(idCliente,senha)
7: alterarVeiculo(reserva.getIdVeiculo(),status)
1: cancelarReserva(idCliente,senha,idReserva)
Sistema
Veiculos
: Cliente
4: [cliente.getStatus() == "ativo] reserva:= cancelarReserva(idCliente,idReserva)
5: reserva := buscarReserva(idReserva)
Reserva
Reservas
6: [reserva.getStatus() == "a retirar" && reserva.getIdCliente() == idCliente] cancelarReserva(idReserva)
76
DIAGRAMA DE CLASSES
Reserva
idReserva : int
dataReserva : java.util.Date
dataRetirada : java.util.Date
dataPrevDevolucao : java.util.Date
dataDevolucao : java.util.Date
quilometragemRetirada : int
quilometragemDevolucao : int
status : String
valorQuilometro : float
valorDiaria : float
idVeiculo : int
idCliente : int
criarReserva()
adicionarReserva()
buscarReservas()
buscarReserva()
alterarReserva()
cancelarReserva()
0..*
possui
0..*
possui
1
Veiculo
idVeiculo : int
modelo : String
marca : String
cor : String
ano : int
numPortas : int
numPassageiros : int
categHabilitacao : char
quilometragemAtual : int
valorQuilometro : float
valorDiaria : float
status : String
buscarVeiculos()
alterarVeiculo()
Veiculo()
Veiculos
buscarVeiculos()
alterarVeiculo()
1
Reservas
Cliente
(from Use Case View)
idCliente : int
senha : String
nome : String
responsavel : String
status : String
buscarCliente()
reservarVeiculo()
buscarReservas()
alterarReserva()
cancelarReserva()
Clientes
buscarCliente()
77
ANEXO II: IMPLEMENTAÇÃO DO WEB SERVICE
CLASSE CLIENTE
package locadora;
import java.sql.*;
import java.sql.SQLException;
public class Cliente{
public Cliente(){}
public void setIdCliente(int idCliente){
this.idCliente = idCliente;
}
public int getIdCliente(){
return this.idCliente;
}
public void setSenha(String senha){
this.senha = senha;
}
public String getSenha(){
return this.senha;
}
public void setNome(String nome){
this.nome = nome;
}
public String getNome(){
return this.nome;
}
public void setResponsavel(String responsavel){
this.responsavel = responsavel;
}
public String getResponsavel(){
return this.responsavel;
}
78
public void setStatus(String status){
this.status = status;
}
public String getStatus(){
return this.status;
}
public Cliente buscarCliente(int idCliente, String senha){
this.conexao = new Conexao();
try{
if (this.conexao.conecta()){
this.resultSet = conexao.consulta("SELECT * FROM
cliente WHERE idCliente = "+idCliente+" AND senha = '"+senha+"';");
if (this.resultSet != null){
if (this.resultSet.next()){
this.setIdCliente(this.resultSet.getInt(1));
this.setSenha(this.resultSet.getString(2));
this.setNome(this.resultSet.getString(3));
this.setResponsavel(this.resultSet.getString(4));
this.setStatus(this.resultSet.getString(5));
this.conexao.desconecta();
this.conexao = null;
return this;
}
}
}
return null;
}catch(SQLException ex){
return null;
}
}
}
private int idCliente;
private Conexao conexao;
private ResultSet resultSet;
private String senha, nome, responsavel, status;
79
CLASSE VEICULO
package locadora;
import java.util.*;
import java.sql.*;
import java.sql.SQLException;
public class Veiculo{
public Veiculo(){}
public void setIdVeiculo (int idVeiculo){
this.idVeiculo = idVeiculo;
}
public int getIdVeiculo(){
return this.idVeiculo;
}
public void setAno(int ano){
this.ano = ano;
}
public int getAno(){
return this.ano;
}
public void setNumPortas(int numPortas){
this.numPortas = numPortas;
}
public int getNumPortas(){
return this.numPortas;
}
public void setNumPassageiros(int numPassageiros){
this.numPassageiros = numPassageiros;
}
public int getNumPassageiros(){
return this.numPassageiros;
}
public void setQuilometragemAtual(int quilometragemAtual){
this.quilometragemAtual = quilometragemAtual;
}
80
public int getQuilometragemAtual(){
return this.quilometragemAtual;
}
public void setModelo(String modelo){
this.modelo = modelo;
}
public String getModelo(){
return this.modelo;
}
public void setMarca(String marca){
this.marca = marca;
}
public String getMarca(){
return this.marca;
}
public void setCor(String cor){
this.cor = cor;
}
public String getCor(){
return this.cor;
}
public void setStatus(String status){
this.status = status;
}
public String getStatus(){
return this.status;
}
public void setCategHabilitacao(String categHabilitacao){
this.categHabilitacao = categHabilitacao;
}
public String getCategHabilitacao(){
return this.categHabilitacao;
}
public void setValorQuilometro(float valorQuilometro){
81
}
this.valorQuilometro = valorQuilometro;
public float getValorQuilometro(){
return this.valorQuilometro;
}
public void setValorDiaria(float valorDiaria){
this.valorDiaria = valorDiaria;
}
public float getValorDiaria(){
return this.valorDiaria;
}
public ArrayList buscarVeiculos(){
this.conexao = new Conexao();
try{
if (this.conexao.conecta()){
this.resultSet = this.conexao.consulta("SELECT * FROM
veiculo WHERE status = 'disponivel';");
if (this.resultSet != null){
ArrayList veiculos = new ArrayList();
while (this.resultSet.next()){
veiculos.add(this.resultSet.getInt(1));
veiculos.add(this.resultSet.getString(2));
veiculos.add(this.resultSet.getString(3));
veiculos.add(this.resultSet.getString(4));
veiculos.add(this.resultSet.getInt(5));
veiculos.add(this.resultSet.getInt(6));
veiculos.add(this.resultSet.getInt(7));
veiculos.add(this.resultSet.getString(8));
veiculos.add(this.resultSet.getInt(9));
veiculos.add(this.resultSet.getFloat(10));
veiculos.add(this.resultSet.getString(11));
veiculos.add(this.resultSet.getFloat(12));
}
this.conexao.desconecta();
this.conexao = null;
return veiculos;
}
}
return null;
}catch(SQLException ex){
return null;
}
82
}
public boolean alterarVeiculo(int idVeiculo, String status){
this.conexao = new Conexao();
if (this.conexao.conecta()){
boolean result = this.conexao.atualiza("UPDATE veiculo SET
status = '"+status+"' WHERE idVeiculo = "+idVeiculo+";");
this.conexao.desconecta();
this.conexao = null;
return result;
}
return false;
}
}
private int idVeiculo, ano, numPortas, numPassageiros, quilometragemAtual;
private String modelo, marca, cor, status, categHabilitacao;
private float valorQuilometro, valorDiaria;
private ResultSet resultSet;
private Conexao conexao;
83
CLASSE RESERVA
package locadora;
import java.util.*;
import java.util.StringTokenizer;
import java.sql.*;
import java.sql.SQLException;
public class Reserva{
public Reserva(){}
public Reserva(int idCliente, int idVeiculo, String dataRetirada, String
dataPrevDevolucao){
this.idCliente = idCliente;
this.idVeiculo = idVeiculo;
this.dataRetirada = dataRetirada;
this.dataPrevDevolucao = dataPrevDevolucao;
}
public void setIdReserva(int idReserva){
this.idReserva = idReserva;
}
public int getIdReserva(){
return this.idReserva;
}
public void setQuilometragemRetirada(int quilometragemRetirada){
this.quilometragemRetirada = quilometragemRetirada;
}
public int getQuilometragemRetirada(){
return this.quilometragemRetirada;
}
public void setQuilometragemDevolucao(int quilometragemDevolucao){
this.quilometragemDevolucao = quilometragemDevolucao;
}
public int getQuilometragemDevolucao(){
return this.quilometragemDevolucao;
}
public void setIdVeiculo(int idVeiculo){
this.idVeiculo = idVeiculo;
84
}
public int getIdVeiculo(){
return this.idVeiculo;
}
public void setIdCliente(int idCliente){
this.idCliente = idCliente;
}
public int getIdCliente(){
return this.idCliente;
}
public void setDataReserva(String dataReserva){
this.dataReserva = dataReserva;
}
public String getDataReserva(){
return this.dataReserva;
}
public void setDataRetirada(String dataRetirada){
this.dataRetirada = dataRetirada;
}
public String getDataRetirada(){
return this.dataRetirada;
}
public void setDataPrevDevolucao(String dataPrevDevolucao){
this.dataPrevDevolucao = dataPrevDevolucao;
}
public String getDataPrevDevolucao(){
return this.dataPrevDevolucao;
}
public void setDataDevolucao(String dataDevolucao){
this.dataDevolucao = dataDevolucao;
}
public String getDataDevolucao(){
return this.dataDevolucao;
}
85
public void setStatus(String status){
this.status = status;
}
public String getStatus(){
return this.status;
}
public void setValorQuilometro(float valorQuilometro){
this.valorQuilometro = valorQuilometro;
}
public float getValorQuilometro(){
return this.valorQuilometro;
}
public void setValorDiaria(float valorDiaria){
this.valorDiaria = valorDiaria;
}
public float getValorDiaria(){
return this.valorDiaria;
}
public int adicionarReserva(Reserva reserva){
this.conexao = new Conexao();
String sql = "INSERT INTO reserva
(dataReserva,dataRetirada,dataPrevDevolucao,status,valorQuilometro,valorDiaria,id
Veiculo,idCliente) ";
sql += " VALUES
(NOW(),'"+reserva.getDataRetirada()+"','"+reserva.getDataPrevDevolucao()+"','a
retirar',2.0,100.00,"+reserva.getIdVeiculo()+","+reserva.getIdCliente()+");";
if (this.conexao.conecta()){
boolean result = this.conexao.atualiza(sql);
this.conexao.desconecta();
}
Reserva r =
this.buscarReserva(0,reserva.getIdCliente(),reserva.getIdVeiculo(),reserva.getDataRe
tirada(),reserva.getDataPrevDevolucao());
if (r != null){
return r.getIdReserva();
}
return -1;
}
86
public ArrayList buscarReservas(int idCliente,int idReservaBusca, String
dataInicialReservas, String dataFinalReservas, String status){
this.conexao = new Conexao();
String sql = "";
if (idReservaBusca<=0){
sql += "SELECT * FROM reserva WHERE idCliente =
"+idCliente+" AND dataReserva >= '"+dataInicialReservas+"'";
sql += " AND dataReserva <= '"+dataFinalReservas+"' AND
status = '"+status+"';";
}else{
sql = "SELECT * FROM reserva WHERE idCliente =
"+idCliente+" AND idReserva = "+idReservaBusca+";";
}
if (this.conexao.conecta()){
this.resultSet = this.conexao.consulta(sql);
try{
if (this.resultSet != null){
ArrayList reservas = new ArrayList();
while (this.resultSet.next()){
reservas.add(this.resultSet.getInt(1));
java.sql.Date aux =
this.resultSet.getDate(2);
if (aux!=null){
reservas.add(aux.toString());
}else{
reservas.add("0000-00-00");
}
aux = this.resultSet.getDate(3);
if (aux!=null){
reservas.add(aux.toString());
}else{
reservas.add("0000-00-00");
}
aux = this.resultSet.getDate(4);
if (aux!=null){
reservas.add(aux.toString());
}else{
reservas.add("0000-00-00");
}
aux = this.resultSet.getDate(5);
if (aux!=null){
reservas.add(aux.toString());
}else{
reservas.add("0000-00-00");
}
87
reservas.add(this.resultSet.getInt(6));
reservas.add(this.resultSet.getInt(7));
reservas.add(this.resultSet.getString(8));
reservas.add(this.resultSet.getFloat(9));
reservas.add(this.resultSet.getFloat(10));
reservas.add(this.resultSet.getInt(11));
reservas.add(this.resultSet.getInt(12));
}
this.conexao.desconecta();
return reservas;
}
return null;
}catch(SQLException ex){
ex.printStackTrace();
return null;
}
}
}
return null;
public Reserva buscarReserva(int idReserva, int idCliente, int idVeiculo,
String dataRetirada, String dataPrevDevolucao){
this.conexao = new Conexao();
if (this.conexao.conecta()){
if (idReserva >0){
this.resultSet = this.conexao.consulta("SELECT * FROM
reserva WHERE idReserva = "+idReserva+";");
}else{
this.resultSet = this.conexao.consulta("SELECT * FROM
reserva WHERE idCliente = "+idCliente+" and idVeiculo = "+idVeiculo+" and
dataRetirada = '"+dataRetirada+"' and dataPrevDevolucao =
'"+dataPrevDevolucao+"' and status = 'a retirar';");
}
try{
this.resultSet.getDate(2);
if (this.resultSet != null){
if (this.resultSet.next()){
this.setIdReserva(this.resultSet.getInt(1));
java.sql.Date aux =
if (aux!=null){
this.setDataReserva(aux.toString());
}else{
this.setDataReserva("0000-00-00");
}
88
aux = this.resultSet.getDate(3);
if (aux!=null){
this.setDataRetirada(aux.toString());
}else{
this.setDataRetirada("0000-00-00");
}
aux = this.resultSet.getDate(4);
if (aux!=null){
this.setDataPrevDevolucao(aux.toString());
}else{
this.setDataPrevDevolucao("000000-00");
}
aux = this.resultSet.getDate(5);
if (aux!=null){
this.setDataDevolucao(aux.toString());
}else{
00");
this.setDataDevolucao("0000-00-
}
this.setQuilometragemRetirada(this.resultSet.getInt(6));
this.setQuilometragemDevolucao(this.resultSet.getInt(7));
this.setStatus(this.resultSet.getString(8));
this.setValorQuilometro(this.resultSet.getFloat(9));
this.setValorDiaria(this.resultSet.getFloat(10));
this.setIdVeiculo(this.resultSet.getInt(11));
this.setIdCliente(this.resultSet.getInt(12));
this.conexao.desconecta();
this.conexao = null;
return this;
}
}
return null;
}catch(SQLException ex){
return null;
}
}
return null;
}
89
public boolean alterarReserva(int idReserva, String dataRetirada, String
dataPrevDevolucao){
this.conexao = new Conexao();
if (this.conexao.conecta()){
boolean result = this.conexao.atualiza("UPDATE reserva SET
dataRetirada = '"+dataRetirada+"', dataPrevDevolucao = '"+dataPrevDevolucao+"'
WHERE idReserva = "+idReserva+";");
this.conexao.desconecta();
this.conexao = null;
return result;
}
return false;
}
public boolean cancelarReserva(int idReserva){
this.conexao = new Conexao();
if (this.conexao.conecta()){
boolean result = this.conexao.atualiza("UPDATE reserva SET
status = 'cancelada' WHERE idReserva = "+idReserva+";");
this.conexao.desconecta();
this.conexao = null;
return result;
}
return false;
}
private int idReserva, quilometragemRetirada, quilometragemDevolucao,
idVeiculo, idCliente;
private String dataReserva, dataRetirada, dataPrevDevolucao,
dataDevolucao;
private String status;
private float valorQuilometro, valorDiaria;
private Conexao conexao;
private ResultSet resultSet;
/*public static void main(String args[]){
try{
Reserva r = new Reserva();
ArrayList result = r.buscarReservas(1,null,"2006-05-30","200606-30","a retirar");
if (result!=null){
Object[] resultado = result.toArray();
for (int i=0;i<resultado.length;i++){
System.out.println(resultado[i]);
90
}else{
}
}*/
}
System.out.println("Erro");
}
}catch(Exception ex){
ex.printStackTrace();
}
91
CLASSE CLIENTES
package locadora;
public class Clientes{
public static Cliente buscarCliente(int idCliente, String senha){
Cliente cliente = new Cliente();
return cliente.buscarCliente(idCliente,senha);
}
}
CLASSE VEICULOS
package locadora;
import java.util.*;
public class Veiculos{
public static ArrayList buscarVeiculos(){
Veiculo veiculo = new Veiculo();
return veiculo.buscarVeiculos();
}
}
public static boolean alterarVeiculo(int idVeiculo, String status){
Veiculo veiculo = new Veiculo();
return veiculo.alterarVeiculo(idVeiculo,status);
}
92
CLASSE RESERVAS
package locadora;
import java.util.*;
public class Reservas{
public static int reservarVeiculo(int idCliente, int idVeiculo, String
dataRetirada, String dataPrevDevolucao){
Reserva reserva = new
Reserva(idCliente,idVeiculo,dataRetirada,dataPrevDevolucao);
return reserva.adicionarReserva(reserva);
}
public static ArrayList buscarReservas(int idCliente, int idReserva, String
dataInicialReservas, String dataFinalReservas, String status){
Reserva reserva = new Reserva();
return
reserva.buscarReservas(idCliente,idReserva,dataInicialReservas,dataFinalReservas,s
tatus);
}
public static boolean alterarReserva(int idCliente, int idReserva, String
dataRetirada, String dataPrevDevolucao){
Reserva reserva = new Reserva();
reserva.buscarReserva(idReserva,0,0,"","");
if (reserva.getStatus().equals("a retirar") && (reserva.getIdCliente()
== idCliente)){
return
reserva.alterarReserva(idReserva,dataRetirada,dataPrevDevolucao);
}
return false;
}
public static Reserva cancelarReserva(int idCliente, int idReserva){
Reserva reserva = new Reserva();
reserva.buscarReserva(idReserva,0,0,"","");
if (reserva.getStatus().equals("a retirar") && (reserva.getIdCliente()
== idCliente)){
reserva.cancelarReserva(idReserva);
return reserva;
}
return null;
}
}
93
CLASSE CONEXAO
package locadora;
import java.sql.*;
import java.sql.SQLException;
public class Conexao{
private String driver = "sun.jdbc.odbc.JdbcOdbcDriver";
private String url = "jdbc:odbc:";
private String userName;
private String password;
private Connection con;
private Statement st;
private boolean conectado = false;
public Conexao(){
this.url = this.url + "locadora";
this.userName = "webservice";
this.password = "webservicelocadora";
}
public boolean conecta(){
if (!this.conectado){
try{
Class.forName(driver);
this.con =
DriverManager.getConnection(url,userName,password);
this.st = this.con.createStatement();
this.conectado = true;
}
catch(Exception ex){
return false;
}
}
return true;
}
public boolean desconecta(){
if (this.conectado){
try{
this.st.close();
this.con.close();
this.conectado = false;
}
catch(SQLException ex){
94
}
}
return false;
}
return true;
public boolean atualiza(String q){
try{
this.st.executeUpdate(q);
return true;
}
catch(SQLException ex){
return false;
}
}
}
public ResultSet consulta(String q){
try{
return this.st.executeQuery(q);
}
catch(SQLException ex){
return null;
}
}
95
INTERFACE LOCADORAIF
package locadora;
import java.rmi.*;
import java.rmi.RemoteException;
import java.util.*;
public interface LocadoraIF extends Remote{
public Object[] buscarVeiculos(int idCliente, String senha) throws
RemoteException;
public int reservarVeiculo(int idCliente, String senha, int idVeiculo, String
dataRetirada, String dataPrevDevolucao) throws RemoteException;
public Object[] buscarReservas(int idCliente, String senha, int idReserva,
String dataInicialReservas, String dataFinalReservas, String status) throws
RemoteException;
public boolean alterarReserva(int idCliente, String senha, int idReserva,
String dataRetirada, String dataPrevDevolucao) throws RemoteException;
public boolean cancelarReserva(int idCliente, String senha, int idReserva)
throws RemoteException;
}
96
CLASSE LOCADORAIMPL
package locadora;
import java.rmi.*;
import java.rmi.RemoteException;
import java.util.*;
public class LocadoraImpl implements LocadoraIF{
public LocadoraImpl(){
}
public Object[] buscarVeiculos(int idCliente, String senha) throws
RemoteException{
Cliente cliente = Clientes.buscarCliente(idCliente,senha);
if (cliente != null){
if (cliente.getStatus().equals("ativo")){
return Veiculos.buscarVeiculos().toArray();
}
}
return null;
}
public int reservarVeiculo(int idCliente, String senha, int idVeiculo, String
dataRetirada, String dataPrevDevolucao) throws RemoteException{
Cliente cliente = Clientes.buscarCliente(idCliente,senha);
if (cliente != null){
if (cliente.getStatus().equals("ativo")){
if (Veiculos.alterarVeiculo(idVeiculo,"reservado")){
return
Reservas.reservarVeiculo(idCliente,idVeiculo,dataRetirada,dataPrevDevolucao);
}
}
}
return -1;
}
public Object[] buscarReservas(int idCliente, String senha, int idReserva,
String dataInicialReservas, String dataFinalReservas, String status) throws
RemoteException{
Cliente cliente = Clientes.buscarCliente(idCliente,senha);
if (cliente != null){
return
Reservas.buscarReservas(idCliente,idReserva,dataInicialReservas,dataFinalReservas
,status).toArray();
}
return null;
}
97
public boolean alterarReserva(int idCliente, String senha, int idReserva,
String dataRetirada, String dataPrevDevolucao) throws RemoteException{
Cliente cliente = Clientes.buscarCliente(idCliente,senha);
if (cliente != null){
if (cliente.getStatus().equals("ativo")){
return
Reservas.alterarReserva(idCliente,idReserva,dataRetirada,dataPrevDevolucao);
}
}
return false;
}
public boolean cancelarReserva(int idCliente, String senha, int idReserva)
throws RemoteException{
Cliente cliente = Clientes.buscarCliente(idCliente,senha);
if (cliente != null){
if (cliente.getStatus().equals("ativo")){
Reserva reserva =
Reservas.cancelarReserva(idCliente,idReserva);
if (reserva != null){
return
Veiculos.alterarVeiculo(reserva.getIdVeiculo(),"disponível");
}
}
}
return false;
}
}
98
ARQUIVOS XML UTILIZADOS PELOS APLICATIVOS WSCOMPILE, JAR E
WSDEPLOY
Config-interface.xml
1. <?xml version="1.0" encoding="UTF-8"?>
2. <configuration xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
3. <service
name="Locadora"
targetNamespace="urn:Foo"
typeNamespace="urn:Foo"
4. packageName="locadora">
5. <interface name="locadora.LocadoraIF"/>
6. </service>
7. </configuration>
Jaxrpc-ri.xml
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
<?xml version="1.0" encoding="UTF-8"?>
<webServices
xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/dd"
version="1.0"
targetNamespaceBase="urn:Foo"
typeNamespaceBase="urn:Foo"
urlPatternBase="/ws">
<endpoint
name="Locadora"
display-name="Servico Locadora"
description="Web Service de uma Locadora de Veiculos usando JAX-RPC."
interface="locadora.LocadoraIF"
model="/WEB-INF/model.gz"
implementation="locadora.LocadoraImpl"/>
<endpointMapping
endpointName="Locadora"
urlPattern="/locadora"/>
</webServices>
99
Web.xml
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">
<web-app>
<display-name>Servico Locadora</display-name>
<description>Web Service de uma Locadora de Veiculos usando
JAX-RPC.</description>
<session-config>
<session-timeout>60</session-timeout>
</session-config>
</web-app>
100
ANEXO III: IMPLEMENTAÇÃO DA APLICAÇÃO CLIENTE
INDEX.PHP
<html>
<head>
<title>HOTEL - Página Inicial</title>
</head>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136">
<table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a
href="reserva_hospedagem.php?flag=hospedagem">Reservar Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a
href="reserva_veiculo.php?flag=veiculo">Reservar Veículo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_apto.php?flag=buscaa">Buscar Reserva Apto</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_veiculo.php?flag=buscav">Buscar Reserva Veiculo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="cadastrar_cliente.php?flag=cliente">Cadastrar Cliente</a></h5></td>
</tr>
</table>
</td>
<td width="645"> </td>
</tr>
</table>
</center>
</body>
</html>
RESERVA_HOSPEDAGEM.PHP
101
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>HOTEL - Reservar Hospedagem</title>
<style type="text/css">
<!-.style1 {font-family: Verdana, Arial, Helvetica, sans-serif}
-->
</style>
</head>
<body>
<center>
<table width="791" height="550" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136">
<table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a
href="reserva_hospedagem.php?flag=hospedagem">Reservar Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a
href="reserva_veiculo.php?flag=veiculo">Reservar Veículo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_apto.php?flag=buscaa">Buscar Reserva Apto</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_veiculo.php?flag=buscav">Buscar Reserva Veiculo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="cadastrar_cliente.php?flag=cliente">Cadastrar Cliente</a></h5></td>
</tr>
</table>
<td width="645">
<h2 align="center">RESERVA DE HOSPEDAGEM</h2><br><br>
<form id="form1" name="form1" method="post"
action="buscar_idcliente.php?flag=hospedagem">
<label>CPF do Cliente:
102
<input type="text" name="cpf" tabindex="0" />
</label>
<label>Localizar
<input type="submit" name="Submit" value="Submit" tabindex="1" />
</label>
</form>
<p align="center"><a href="cadastrar_cliente.php?flag=cliente">Cliente Não Cadastrado?
Cadastrar</a></p>
</td>
</tr>
</table>
</center>
</body>
</html>
103
BUSCAR_IDCLIENTE.PHP
<?php
$host="localhost";
$user="aplicacaoweb";
$password="aplicacaowebhotel";
$database="hotel";
mysql_connect($host,$user,$password);
mysql_select_db($database);
$sql=stripSlashes("select idCliente from cliente where cpf = \"".$_POST['cpf']."\"");
$result=mysql_query($sql);
if (!$result){
echo("<a href=\"javascript:window.location='index.php'\">Página
Inicial</a>");
}else{
$quantLinhas = mysql_num_rows($result);
if ($quantLinhas>0){
$id=mysql_result($result,0);
$id=(int)$id;
$flag=$_GET['flag'];
if (!strcmp($flag,"hospedagem")){
?>
<script language="javascript">
<?php
echo("window.location=\"inserir_reserva_hospedagem.php?idCliente=".$id."\"");
?>
</script>
<?php
}else{
if (!strcmp($flag,"veiculo")){
?>
<script language="javascript"> <?php
echo("window.location=\"veiculos.php?idCliente=".$id."\"");
?>
</script>
<?php
}else{
if (!strcmp($flag,"buscaa")){
?>
<script language="javascript"> <?php
echo("window.location=\"reservasa.php?idCliente=".$id."\"");
?>
</script>
<?php
}else{
if (!strcmp($flag,"buscav")){
?>
104
<script language="javascript"> <?php
echo("window.location=\"reservasv.php?idCliente=".$id."\"");
?>
</script>
<?php
}else{
?>
<script language="javascript"> <?php
echo("window.location=\"index.php\"");
}else{
?>
}
}
}
?>
</script>
<?php
}
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><center><h2>HOTEL</h2></center></td>
</tr>
<tr>
<td width="136"><table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a href="reserva_hospedagem.php">Reserva de
Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a href="reserva_veiculo.php">Reserva de
Veículos</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="buscar_reserva.php?flag=busca">Buscar
Reserva</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="cadastrar_cliente.php">Cadastrar
Cliente</a></h5></td>
</tr>
</table></td>
<td width="645"><?php
105
echo("<center><h2>RESERVA DE
HOSPEDAGEM</h2></center><br>");
echo("<center>Cliente não cadastrado!</center><br>");
echo("<center><a
href=\"javascript:window.location='cadastrar_cliente.php?flag=cliente'\">Cadastrar
Cliente</a></center>");
?></td>
</tr>
</table>
</center>
</body> <?php
}
}
?>
106
INSERIR_RESERVA_HOSPEDAGEM.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>HOTEL - Página Inicial</title>
<style type="text/css">
<!-.style1 {font-family: Verdana, Arial, Helvetica, sans-serif}
-->
</style>
</head>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136">
<table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a
href="reserva_hospedagem.php?flag=hospedagem">Reservar Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a
href="reserva_veiculo.php?flag=veiculo">Reservar Veículo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_apto.php?flag=buscaa">Buscar Reserva Apto</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_veiculo.php?flag=buscav">Buscar Reserva Veiculo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="cadastrar_cliente.php?flag=cliente">Cadastrar Cliente</a></h5></td>
</tr>
</table>
</td>
<td width="645">
<form id="form1" name="form1" method="post"
action="inserir_hospedagem.php?idCliente=<?php echo ($_GET['idCliente']); ?>">
107
<table border="1"><tr><td><p align="left"><label>Data de
Chegada:</label></p></td><td><p align="left"><input type="text" name="dataChegada"
tabindex="0" /></p></td></tr>
<tr><td><p align="left"><label>Data de Saída:</label></p></td><td><p
align="left"><label><input type="text" name="dataSaida" tabindex="1" /></td></tr>
<tr><td><p align="left"><label>Quantidade de
Adultos:</label></p></td><td><p align="left"><label><input type="text"
name="numAdultos" tabindex="2" /></td></tr>
<tr><td><p align="left"><label>Quantidade de Crianças (< 2
anos):</label></p></td><td><p align="left"><label><input type="text"
name="numCriancas" tabindex="3" /></td></tr>
<tr><td><p align="center"><label><input name="tipoApartamento"
type="radio" value="1" /></label></p></td><td><p align="left"><label>Suíte de Luxo Ideal para 2 Adultos</label></p></td></tr>
<tr><td><p align="center"><label><input name="tipoApartamento"
type="radio" value="2" /></label></p></td><td><p align="left"><label>Suíte de Luxo Ideal para Casal</label></p></td></tr>
<tr><td><p align="center"><label><input name="tipoApartamento"
type="radio" value="3" tabindex="4" /></label></p></td><td><p
align="left"><label>Suíte de Luxo - Ideal para Casal e 1 Criança (< 2
anos)</label></td></tr>
<tr><td><p align="center"><label><input name="tipoApartamento"
type="radio" value="4" tabindex="5" /></label></p></td><td><p
align="left"><label>Suíte de Luxo - Ideal para Casal e 1 Criança (> 2 anos)</label>
</td></tr>
<tr><td><p align="center"><label><input name="tipoApartamento"
type="radio" value="5" /></label></p></td><td><p align="left"><label>Suíte Standard Ideal para 2 Adultos</label></td></tr>
<tr><td><p align="center"><label><input name="tipoApartamento"
type="radio" value="6" /></label></p></td><td><p align="left"><label>Suíde Standard Ideal para Casal</label></td></tr>
<tr><td><p align="center"><label><input name="tipoApartamento"
type="radio" value="7" tabindex="6" /></label></p></td><td><p
align="left"><label>Suíte Standard - Ideal para 2 Adultos e 1 Crinça (< 2
anos)</label></td></tr>
<tr><td><p align="center"><label><input name="tipoApartamento"
type="radio" value="8" /></label></p></td><td><p align="left"><label>Suíte Standard Ideal para 2 Adultos e 1 Criança (> 2 anos)</label></td></tr>
<tr><td> </td><td><input type="submit" name="Submit"
value="Concluir" /></td><tr>
</form>
</td>
</tr>
</table>
</center>
</body>
</html>
108
INSERIR_HOSPEDAGEM.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled Document</title>
</head>
<body>
<?php
$host="localhost";
$user="aplicacaoweb";
$password="aplicacaowebhotel";
$database="hotel";
$idHost=mysql_connect($host,$user,$password);
if ($idHost){
$idDb=mysql_select_db($database,$idHost);
}
$sql=stripSlashes("insert into reservaapto values
(null,".$_GET['idCliente'].",\"".$_POST['tipoApartamento']."\",NOW(),\"".$_POST['data
Chegada']."\",\"".$_POST['dataSaida']."\",150,".$_POST['numAdultos'].",".$_POST['num
Criancas'].",'reservada')");
$result=mysql_query($sql);
if ($result>0){
echo "<h3>Reserva realizada!</h3>";
}else{
echo ("<h3>Reserva não realizada!</h3>");
echo(mysql_error($idHost));
}
?>
</body>
</html>
109
RESERVA_VEICULO.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>HOTEL - Reserva de Veículo</title>
<style type="text/css">
<!-.style1 {font-family: Verdana, Arial, Helvetica, sans-serif}
-->
</style>
</head>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136">
<table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a
href="reserva_hospedagem.php?flag=hospedagem">Reservar Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a
href="reserva_veiculo.php?flag=veiculo">Reservar Veículo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_apto.php?flag=buscaa">Buscar Reserva Apto</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_veiculo.php?flag=buscav">Buscar Reserva Veiculo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="cadastrar_cliente.php?flag=cliente">Cadastrar Cliente</a></h5></td>
</tr>
</table>
<td width="645">
<h2 align="center">RESERVA DE VEÍCULO</h2><br><br>
<form id="form1" name="form1" method="post"
action="buscar_idcliente.php?flag=veiculo">
110
<label>CPF do Cliente:
<input type="text" name="cpf" tabindex="0" />
</label>
<label>Localizar
<input type="submit" name="Submit" value="Submit" tabindex="1" />
</label>
</form>
<p align="center"><a href="cadastrar_cliente.php?flag=cliente">Cliente Não Cadastrado?
Cadastrar</a></p>
</td>
</tr>
</table>
<center>
</body>
</html>
111
VEICULOS.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled Document</title>
</head>
<body>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136"><table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a href="reserva_hospedagem.php">Reserva de
Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a href="reserva_veiculo.php">Reserva de
Veículos</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="buscar_reserva.php?flag=busca">Buscar
Reserva</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="cadastrar_cliente.php">Cadastrar
Cliente</a></h5></td>
</tr>
</table></td>
<td width="645">
<?php
$client = new SoapClient("http://localhost:8080/Locadora/locadora?WSDL");
$veiculos = ($client->buscarVeiculos(1,"senha1"));
if (count($veiculos)<=0){
echo("Não existem veículos disponíveis para reserva!");
}else{
echo("<form id='form1' name='form1' method='post'
action='inserir_reserva_veiculo.php?idCliente=".$_GET['idCliente']."'>");
echo("<table border='1'><tr><td></td><td></td></tr>");
112
echo("<tr><td>Data de Chegada:</td><td><input type='text'
name='dataRetirada' tabindex='0' /></td></tr>");
echo("<tr><td>Data de Saída:</td><td><input type='text'
name='dataPrevDevolucao' tabindex='1' /></td></tr>");
for ($i=0;$i<count($veiculos);$i=$i+12){
echo("<tr><td><input name='idVeiculo' type='radio'
value='".$veiculos[0]."'/></td><td>");
echo("<table><tr><td><p align='left'>Modelo:</p></td><td><p
align='left'>".$veiculos[$i+1]."</p></td></tr>");
echo("<tr><td><p align='left'>Marca:</p></td><td><p
align='left'>".$veiculos[$i+2]."</p></td></tr>");
echo("<tr><td><p align='left'>Cor:</p></td><td><p
align='left'>".$veiculos[$i+3]."</p></td></tr>");
echo("<tr><td><p align='left'>Ano:</p></td><td><p
align='left'>".$veiculos[$i+4]."</p></td></tr>");
echo("<tr><td><p align='left'>Portas:</p></td><td><p
align='left'>".$veiculos[$i+5]."</p></td></tr>");
echo("<tr><td><p align='left'>Passageiros:</p></td><td><p
align='left'>".$veiculos[$i+6]."</p></td></tr>");
echo("<tr><td><p align='left'>Habilitação:</p></td><td><p
align='left'>".$veiculos[$i+7]."</p></td></tr>");
echo("<tr><td><p align='left'>Valor Quilômetro
Adicional:</p></td><td><p align='left'>".$veiculos[$i+9]."</p></td></tr>");
echo("<tr><td><p align='left'>Valor Diária:</p></td><td><p
align='left'>".$veiculos[$i+11]."</p></td></tr></table></td></tr>");
}
echo("<tr><td> </td><td><input type='submit' name='Submit'
value='Concluir' /></td></tr></table></form>");
}
?>
</td>
</tr>
</table>
</center>
</body>
</body>
</html>
113
INSERIR_RESERVA_VEICULO.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>HOTEL - Página Inicial</title>
<style type="text/css">
<!-.style1 {font-family: Verdana, Arial, Helvetica, sans-serif}
-->
</style>
</head>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136"><table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a
href="reserva_hospedagem.php?flag=hospedagem">Reservar Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a href="reserva_veiculo.php?flag=veiculo">Reservar
Veículo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="buscar_reserva.php?flag=busca">Buscar
Reserva</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="cadastrar_cliente.php?flag=cliente">Cadastrar
Cliente</a></h5></td>
</tr>
</table></td>
<td width="645">
<?php
$client = new SoapClient("http://localhost:8080/Locadora/locadora?WSDL");
$aux = (int) $_POST['idVeiculo'];
$reserva = $client>reservarVeiculo(1,"senha1",$aux,$_POST['dataRetirada'],$_POST['dataPrevDevolucao']);
114
if ($reserva>0){
echo("Reserva Realizada!");
$host="localhost";
$user="aplicacaoweb";
$password="aplicacaowebhotel";
$database="hotel";
$idHost=mysql_connect($host,$user,$password);
if ($idHost){
$idDb=mysql_select_db($database,$idHost);
}
$reserva = (int) $reserva;
$id = $_GET['idCliente'];
$id = (int) $id;
$insercao = "insert into reservaauto values (".$reserva.",".$id.",'a retirar')";
$query = mysql_query($insercao,$idHost);
if ($query>0){
echo "<br>Banco de dados do cliente ok.";
}else{
echo "<br>Banco de dados do cliente não atualizado. Erro:
".mysql_error($idHost);
}
}else{
echo("Reserva Não Realizada!");
}
?>
</td>
</tr>
</table>
</center>
</body>
</html>
115
BUSCAR_RESERVA_APTO.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>HOTEL - Reserva de Veículo</title>
<style type="text/css">
<!-.style1 {font-family: Verdana, Arial, Helvetica, sans-serif}
-->
</style>
</head>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136">
<table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a
href="reserva_hospedagem.php?flag=hospedagem">Reservar Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a
href="reserva_veiculo.php?flag=veiculo">Reservar Veículo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_apto.php?flag=buscaa">Buscar Reserva Apto</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_veiculo.php?flag=buscav">Buscar Reserva Veiculo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="cadastrar_cliente.php?flag=cliente">Cadastrar Cliente</a></h5></td>
</tr>
</table>
<td width="645">
<h2 align="center">BUSCA DE RESERVA DE APARTAMENTO</h2><br><br>
<form id="form1" name="form1" method="post"
action="buscar_idcliente.php?flag=buscaa">
116
<label>CPF do Cliente:
<input type="text" name="cpf" tabindex="0" />
</label>
<label>Localizar
<input type="submit" name="Submit" value="Submit" tabindex="1" />
</label>
</form>
<p align="center"><a href="cadastrar_cliente.php?flag=cliente">Cliente Não Cadastrado?
Cadastrar</a></p>
</td>
</tr>
</table>
<center>
</body>
</html>
117
RESERVASA.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled Document</title>
</head>
<body>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136"><table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a href="reserva_hospedagem.php">Reserva de
Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a href="reserva_veiculo.php">Reserva de
Veículos</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="buscar_reserva.php?flag=busca">Buscar
Reserva</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="cadastrar_cliente.php">Cadastrar
Cliente</a></h5></td>
</tr>
</table></td>
<td width="645">
<?php
$host="localhost";
$user="aplicacaoweb";
$password="aplicacaowebhotel";
$database="hotel";
mysql_connect($host,$user,$password);
mysql_select_db($database);
$consulta_reserva_apto="select cliente.nome, tipoapartamento.descricao,
reservaapto.dataReserva, reservaapto.dataChegada, reservaapto.dataSaida,
reservaapto.valorDiaria, reservaapto.numAdultos, reservaapto.numCriancas from cliente,
118
reservaapto, tipoapartamento where cliente.idCliente=".$_GET['idCliente']." and
cliente.idCliente = reservaapto.idCliente and reservaapto.idTipoApto =
tipoapartamento.idTipo and (not reservaapto.status='finalizada')";
$sql=stripSlashes($consulta_reserva_apto);
$result=mysql_query($sql);
if (!$result){
echo("Erro na consulta!");
echo("<a href=\"javascript:window.location='index.php'\">Página
Inicial</a>");
}else{
$quantLinhas = mysql_num_rows($result);
if ($quantLinhas>0){
$id=mysql_fetch_row($result);
echo("<form id='form1' name='form1' method='post' action=''>");
echo("<table
border='1'><tr> <td></td><td><center><h3>Reservas
Localizadas</h3></center></td></tr>");
while ($id){
echo("<tr><td>Nome:</td><td>".$id[0]."</td></tr>");
echo("<tr><td>Apartamento:</td><td>".$id[1]."</td></tr>");
echo("<tr><td>Data da
Reserva:</td><td>".$id[2]."</td></tr>");
echo("<tr><td>Data de
Chegada:</td><td>".$id[3]."</td></tr>");
echo("<tr><td>Data de
Saída:</td><td>".$id[4]."</td></tr>");
echo("<tr><td>Valor da
Diária:</td><td>".$id[5]."</td></tr>");
echo("<tr><td>Número de
Adultos:</td><td>".$id[6]."</td></tr>");
echo("<tr><td>Número de
Crianças:</td><td>".$id[7]."</td></tr>");
$id=mysql_fetch_row($result);
}
echo("<tr><td> </td><td><input type='submit'
name='Submit' value='Concluir' /></td></tr></table></form>");
}else{
echo("Nenhuma reserva encontrada!");
}
}
?>
</td>
</tr>
</table>
</center>
</body>
</body>
</html>
119
BUSCAR_RESERVA_VEICULO.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>HOTEL - Reserva de Veículo</title>
<style type="text/css">
<!-.style1 {font-family: Verdana, Arial, Helvetica, sans-serif}
-->
</style>
</head>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136">
<table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a
href="reserva_hospedagem.php?flag=hospedagem">Reservar Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a
href="reserva_veiculo.php?flag=veiculo">Reservar Veículo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_apto.php?flag=buscaa">Buscar Reserva Apto</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_veiculo.php?flag=buscav">Buscar Reserva Veiculo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="cadastrar_cliente.php?flag=cliente">Cadastrar Cliente</a></h5></td>
</tr>
</table>
<td width="645">
<h2 align="center">BUSCA DE RESERVA DE VEÍCULO</h2><br><br>
<form id="form1" name="form1" method="post"
action="buscar_idcliente.php?flag=buscav">
120
<label>CPF do Cliente:
<input type="text" name="cpf" tabindex="0" />
</label>
<label>Localizar
<input type="submit" name="Submit" value="Submit" tabindex="1" />
</label>
</form>
<p align="center"><a href="cadastrar_cliente.php?flag=cliente">Cliente Não Cadastrado?
Cadastrar</a></p>
</td>
</tr>
</table>
<center>
</body>
</html>
121
RESERVASV.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled Document</title>
</head>
<body>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136"><table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a href="reserva_hospedagem.php">Reserva de
Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a href="reserva_veiculo.php">Reserva de
Veículos</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="buscar_reserva.php?flag=busca">Buscar
Reserva</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="cadastrar_cliente.php">Cadastrar
Cliente</a></h5></td>
</tr>
</table></td>
<td width="645">
<?php
$host="localhost";
$user="aplicacaoweb";
$password="aplicacaowebhotel";
$database="hotel";
mysql_connect($host,$user,$password);
mysql_select_db($database);
$consulta_reserva_auto="select idReservaAuto from reservaauto where idCliente
=".$_GET['idCliente']." and status='a retirar'";
$sql=stripSlashes($consulta_reserva_auto);
122
$result=mysql_query($sql);
if (!$result){
echo("Erro na consulta!");
echo("<a href=\"javascript:window.location='index.php'\">Página
Inicial</a>");
}else{
$quantLinhas = mysql_num_rows($result);
if ($quantLinhas>0){
$id=mysql_fetch_row($result);
while($id){
$client = new
SoapClient("http://localhost:8080/Locadora/locadora?WSDL");
$reservas = ($client>buscarReservas(1,"senha1",$id[0],"","","a retirar"));
if (count($reservas)<=0){
echo("Não existem reservas a retirar!");
}else{
echo("<table
border='1'><tr> <td></td><td><center><h3>Reservas de Veículos
Localizadas</h3></center></td></tr>");
for ($i=0;$i<count($reservas);$i+=12){
$idReserva=$reservas[$i];
echo("<tr><td>Data da
Reserva:</td><td>".$reservas[$i+1]."</td></tr>");
$dataRetirada=$reservas[$i+2];
echo("<tr><td>Data
Retirada:</td><td>".$dataRetirada."</td></tr>");
$dataPrevDevolucao=$reservas[$i+3];
echo("<tr><td>Data Prevista para
Devolução:</td><td>".$dataPrevDevolucao."</td></tr>");
echo("<tr><td>Data de
Devolução:</td><td>".$reservas[$i+4]."</td></tr>");
echo("<tr><td>Quilometragem
Retirada:</td><td>".$reservas[$i+5]."</td></tr>");
echo("<tr><td>Quilometragem
Devolução:</td><td>".$reservas[$i+6]."</td></tr>");
echo("<tr><td>Status:</td><td>".$reservas[$i+7]."</td></tr>");
echo("<tr><td>Valor do
Quilometro:</td><td>".$reservas[$i+8]."</td></tr>");
echo("<tr><td>Valor da
Diária:</td><td>".$reservas[$i+9]."</td></tr>");
echo("<tr><td>Identificador do
Veículo:</td><td>".$reservas[$i+10]."</td></tr>");
echo("<tr><td>Identificador do
Cliente:</td><td>".$reservas[$i+11]."</td></tr>");
echo("<tr><td><a
href='cancelar_reserva.php?idReserva=".$idReserva."'>Cancelar</a></td><td><a
href='alterar_reserva.php?idReserva=".$idReserva."&dataRetirada=".$dataRetirada."&da
taPrevDevolucao=".$dataPrevDevolucao."'>Alterar</a></td></tr>");
123
}
}else{
?>
}
}
}
echo("</table>");
}
$id=mysql_fetch_row($result);
echo("Nenhuma reserva encontrada!");
</td>
</tr>
</table>
</center>
</body>
</body>
</html><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled Document</title>
</head>
<body>
</body>
</html>
124
CANCELAR_RESERVA.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled Document</title>
</head>
<body>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136"><table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a href="reserva_hospedagem.php">Reserva de
Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a href="reserva_veiculo.php">Reserva de
Veículos</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="buscar_reserva.php?flag=busca">Buscar
Reserva</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="cadastrar_cliente.php">Cadastrar
Cliente</a></h5></td>
</tr>
</table></td>
<td width="645">
?>
<?php
$client = new SoapClient("http://localhost:8080/Locadora/locadora?WSDL");
$cancelar = ($client->cancelarReserva(1,"senha1",$_GET['idReserva']));
if (!$cancelar){
echo("Não foi possível cancelar a reserva!");
}else{
echo("Reserva cancelada!");
}
125
</td>
</tr>
</table>
</center>
</body>
</body>
</html>
126
ALTERAR_RESERVA.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled Document</title>
</head>
<body>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136"><table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a href="reserva_hospedagem.php">Reserva de
Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a href="reserva_veiculo.php">Reserva de
Veículos</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="buscar_reserva.php?flag=busca">Buscar
Reserva</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="cadastrar_cliente.php">Cadastrar
Cliente</a></h5></td>
</tr>
</table></td>
<td width="645">
<form name="form1" method="post"
action="alterar_reserva_ws.php?idReserva=<?php echo($_GET['idReserva'])?>">
<label>Data de Retirada: </label><input type="text" name="dataRetirada"
value=<?php echo($_GET['dataRetirada'])?> />
<label>Data Prevista Para Devolução: </label><input type="text"
name="dataPrevDevolucao" value=<?php echo($_GET['dataPrevDevolucao'])?> />
<input type="submit" name="Submit" value="Alterar"/>
</form>
</td>
</tr>
</table>
127
</center>
</body>
</body>
</html>
128
ALTERAR_RESERVA_WS.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled Document</title>
</head>
<body>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136"><table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a href="reserva_hospedagem.php">Reserva de
Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a href="reserva_veiculo.php">Reserva de
Veículos</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="buscar_reserva.php?flag=busca">Buscar
Reserva</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a href="cadastrar_cliente.php">Cadastrar
Cliente</a></h5></td>
</tr>
</table></td>
<td width="645">
<?php
$client = new SoapClient("http://localhost:8080/Locadora/locadora?WSDL");
$alterar = ($client>alterarReserva(1,"senha1",$_GET['idReserva'],$_POST['dataRetirada'],$_POST['dataPre
vDevolucao']));
if (!$alterar){
echo("Não foi possível alterar a reserva!");
}else{
echo("Reserva alterada!");
}
129
?>
</td>
</tr>
</table>
</center>
</body>
</body>
</html>
130
CADASTRAR_CLIENTE.PHP
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>HOTEL - Cadastrar Cliente</title>
<style type="text/css">
<!-.style1 {font-family: Verdana, Arial, Helvetica, sans-serif}
-->
</style>
</head>
<body>
<center>
<table width="791" height="587" border="0">
<tr>
<td colspan="2"><h3><h2>HOTEL</h3></td>
</tr>
<tr>
<td width="136">
<table width="137" height="222" border="0">
<tr>
<td height="48"><h5><a
href="reserva_hospedagem.php?flag=hospedagem">Reservar Hospedagem</a></h5></td>
</tr>
<tr>
<td height="43"><h5><a
href="reserva_veiculo.php?flag=veiculo">Reservar Veículo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_apto.php?flag=busca">Buscar Reserva Apto</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="buscar_reserva_veiculo.php?flag=busca">Buscar Reserva Veiculo</a></h5></td>
</tr>
<tr>
<td height="42"><h5><a
href="cadastrar_cliente.php?flag=cliente">Cadastrar Cliente</a></h5></td>
</tr>
</table>
<td width="645">
<h2>CADASTRO DE CLIENTE</h2><br><br>
<form id="form1" name="form1" method="post" action="">
<table>
131
/></td></tr>
/></td></tr>
/></td></tr>
<tr><td>CPF:</td><td><input type="text" name="cpf" tabindex="0"
<tr><td>Nome:</td><td><input type="text" name="nome" tabindex="1"
<tr><td>E-mail:</td><td><input type="text" name="email" tabindex="3"
<tr><td>Endereço:</td><td><input type="text" name="endereco"
tabindex="4" /></td></tr>
<tr><td>Complemento:</td><td><input type="text" name="complemento"
tabindex="5" /></td></tr>
<tr><td>Cidade:</td><td><input type="text" name="cidade" tabindex="6"
/></td></tr>
<tr><td>UF:</td><td><input type="text" name="uf" tabindex="7"
/></td></tr>
<tr><td>CEP:</td><td><input type="text" name="cep" tabindex="8"
/></td></tr>
<tr><td>Bairro:</td><td><input type="text" name="bairro" tabindex="9"
/></td></tr>
<tr><td>Telefone:</td><td><input type="text" name="telefone"
tabindex="10" /></td></tr>
<tr><td> </td><td><input type="submit" name="submit"
value="Confirmar" tabindex="11" /></td></tr>
</table>
</form>
</td>
</tr>
</table>
</center>
</body>
</html>