Sistemas WEB na área de engenharia civil

(1)

Universidade Federal de Santa Catarina

SERVIÇOS WEB NA ÁREA DA CONSTRUÇÃO CIVIL

(2)

Universidade Federal de Santa Catarina

SERVIÇOS WEB NA ÁREA DA CONSTRUÇÃO CIVIL

Diogo Ruviaro Viegas

(3)

Universidade Federal de Santa Catarina Departamento de Informática e Estatística Curso de Bacharelado em Ciências da Computação

SERVIÇOS WEB NA ÁREA DA CONSTRUÇÃO CIVIL

Autor Diogo Ruviaro Viegas Orientador João Bosco Mangueira Sobral Banca Examinadora João Carlos Matoso Alysson Neves

(4)

Lista de Siglas API – Application Program Interface

CORBA - Common Object Request Broker Architecture DCOM - Distributed Component Object Model

FTP – File Transfer Protocol

HTML - Hypertext Markup Language HTTP - Hyper Text Transfer Protocol J2EE – Java 2 Enterprise Edition JMS – Java Message Service JSP – Java Server Page LAN – Local Area Network PC – Personal Computer

RMI – Remote Method Invocation RPC - Remote Procedure Call

SGML - Standard Generalized Markup Language SOAP - Simple Object Access Protocol

TI – Tecnologia da Informação TCP – Transfer Control Protocol

UDDI - Universal Description, Discovery and Integration URI - Uniform Resource Identifiers

URL - Uniform Resource Locator XML - Extensible Markup Language XSL - Extensible Stylesheet Language WSDL - Web Service Description Language WWW – World Wide Web

(5)

Lista de Figuras

Figura 3.1 - Exemplo do protocolo SOAP... 21

Figura 3.2 - Exemplo de comunicação do protocolo SOAP... 26

Figura 6.0 - Funcionamento do Sistema... 41

Figura 7.1 - Tela de entrada... 44

Figura 7.2 - Tela de endereços das lojas... 45

Figura 7.3 - Tela lista produtos para consulta... 46

Figura 7.4 - Tela resultado da consulta de produtos... 47

Figura 7.5 - Tela resultado da consulta por menor preço... 48

Figura 7.6 - Tela de serviços ... 49

(6)

Sumário Resumo... xi Abstract ... xii 1 Introdução ... 8 1.1Objetivo Geral ... 9 1.2 Objetivo Específico ... 9 1.3 Justificativa ... 10 1.4 Metodologia ... 10 2 Serviços Web ... 11 2.1 Histórico ... 11

2.2 O que são serviços Web ... 11

2.3 Arquitetura dos serviços Web básicos ... ... 12

2.3.1 Funcionalidade comercial... 12

2.3.2 Sistema de serviços Web... .. 13

2.3.3 Servidor Web... ... 13

2.3.4 Cliente do serviço Web... 13

2.4 Segurança em serviços Web... 14

2.5- Interoperabilidade... 15

3 Arquitetura Serviços Web ... 17

3.1 XML ... 17 3.1.1 Linguagens de Marcação ... 17 3.1.2 Exemplo de XML ... 18 3.2 SOAP ... 20 3.2.1 O que é SOAP ... 20 3.2.2 RPC e o SOAP ... 21

3.2.3 Estrutura da Mensagem SOAP... 22

3.2.3.1 SOAP Header ... 23

3.2.3.2 SOAP Body ... 24

3.2.2.3 SOAP Fault ... 25

(7)

3.3 HTTP ... ... 26

3.4 WSDL ... 27

3.5 UDDI ... 33

3.5.1 Estrutura de Dados UDDI ... 34

3.6 API UDDI ... 35

4 Linguagens e Plataformas Utilizadas ... 37

4.1 Java ... ... 37

4.2 Servidor Web Apache ... 38

4.3 Servlet Container TomCat ... 38

5 Problema a ser resolvido ... 40

6 Principio de funcionamento do sistema ... 40

6.1 Recursos do sistema ... 42 6.2 Benefícios do sistema ... 43 7 Resultados Obtidos... 50 Conclusão ... 51 Referências ... 52 Anexo I – Artigo ... 54

(8)

Resumo

Este trabalho aborda a questão da consulta de preços e a elaboração de orçamentos para a área da construção civil. A indústria da construção civil em Santa Catarina emprega um volume considerável de recursos que circulam nesse contexto de mercado, mas evidenciando, ainda, a necessidade de se melhorar a qualidade do atendimento ao cliente, no que tange a disponibilidade dos recursos computacionais de uso da Internet/Web.

A indisponibilidade de tais recursos computacionais faz com que os clientes finais ou os profissionais que lidam com a preparação de orçamentos, levem mais tempo, tenham maior custo e se sujeitem aos argumentos dos vendedores, até que formalizem os seus orçamentos finais.

Como uma solução viável, para tais circunstâncias, este projeto final de curso, considera a existência de um número considerável de empresas fornecedoras de materiais, que precisam ser consultadas com relação aos seus preços. Esses fornecedores apresentam uma diversidade de sistemas de computação, envolvendo diferentes sistemas operacionais, linguagens de programação, bancos de dados, portanto, surge a necessidade de integrá-los no contexto da Web.

O problema de integração de aplicações distribuídas na Web é resolvido, sobre a Internet, através das tecnologias para a construção de sistemas com serviços na Web (Web Services). O presente trabalho constrói um protótipo utilizando a linguagem Java e ferramentas de livre utilização, tais como, j2se, Tomcat, Apache SOAP, o Emerging Tecnologies Toolkit (IBM), MySQL entre outras.

(9)

Abstract

This work approaches the question of the consultation of prices and the elaboration of budgets for the area of the civil construction. The industry of the civil construction in Santa Catarina uses a considerable volume of resources that circulate in this context of market, but evidencing, still, the necessity of if improving the quality of the attendance to the customer, in whom it refers to the availability of the computational resources of use of the Internet/Web.

The non-availability of such computational resources, makes with that the final customers or the professionals whom they deal with the preparation of budgets, take more time, they have greater cost and if subject to the arguments of the salesmen, until they legalize its final budgets

As a viable solution, for such circumstances, this final project of course, considers the existence of a considerable number of supplying companies of materials, that they need to be consulted with relation to its prices. These suppliers present a diversity of computer systems, involving different operational systems, programming languages, data bases, and therefore, the necessity appears to integrate them in the context of the Web.

The problem of integration of applications distributed in the Web is decided, on the InterNet, through the technologies for the construction of systems with services in the Web (Web Services). The present work constructs to an archetype using the Java language and tools of free use, such as, J2SE, Tomcat, Apache SOAP, the Emerging Tecnologies Toolkit (IBM), MySQL among others.

(10)

1 Introdução

Estudando o mercado da construção civil, que envolve empresas com os mesmos tipos de serviços e que se relacionam umas com as outras oferecendo sempre o melhor preço alienado a qualidade dos seus produtos, verificou-se a necessidade de se desenvolver um serviço através da Web que “amenizasse” o esforço do usuário final em realizar consultas ‘a estas empresas.

Ao longo do tempo percebe-se que poucas empresas do ramo de desenvolvimento de soluções tecnologias têm unido esforços para encontrar a mais adequada solução para este problema. Poucas já foram apresentadas ao mercado, algumas com menos e outras com mais problemas. Percebe-se ainda que geralmente as empresas que fornecem matérias de construção preocupam-se em “amenizar” o esforço de procura do usuário final implementando-se um Web Service.

Os serviços Web são essa tecnologia. Os serviços Web e suas evoluções tendem a ampliar as opções de desenvolvimento e implantação de sistemas distribuídos, pela internet ou simplesmente pela LAN de uma empresa.

(11)

1.1 Objetivo Geral

Aprofundando um estudo mais detalhado dos serviços Web, este trabalho tem como característica principal integrar um sistema de consulta a preços e geração de orçamentos do segmento da construção Civil, no qual realiza consultas a diferentes empresas e retorna ao cliente as informações necessárias para o que ele deseja fazer. Este trabalho visa explicar serviços Web, como funcionam, por que eles não serão a resposta para todos os problemas de tecnologia e quais as responsabilidades de um executivo ao moldar os planos de serviços Web de uma empresa principalmente na área de construção civil. Um dos aspectos mais confusos dos serviços Web é o próprio termo. A palavra serviços invoca visões de pessoas pagando e recebendo algo em troca. No nível mais básico, porém, serviços na Web são apenas uma nova variante de tecnologia de software baseada em padrões que permite que os programadores combinem sistemas existentes de maneiras novas, via Internet, dentro de uma empresa ou envolvendo várias. Serviços na Web possibilitam que as empresas criem uma ponte de comunicação entre software escrito em linguagens de programação diferentes, desenvolvido por companhias diferentes ou que sejam usados sobre sistemas operacionais diferentes.

1.2 Objetivos específicos

Com a realização deste trabalho procurou-se estudar e dar ênfase a alguns objetivos específicos, tais como:

?? Descrever o que são os serviços Web.

?? Apresentar o modelo de arquitetura dos serviços Web. ?? Utilizar XML, SOAP, UDDI e WSDL.

(12)

1.3 Justificativa

A Necessidade de desenvolver-se sistemas Web voltados para a área da construção civil principalmente relacionados a consulta de preços e pesquisa orçamentária somados a tecnologia de Web Services formaram o embasamento deste trabalho na busca de uma solução altamente aplicável aos dias de hoje.

1.4 Metodologia

Como se trata de um projeto com dimensões consideráveis, foi utilizado a UML para modelar no desenvolvimento de um projeto orientado ao objeto e organizado. Realizamos estudos para aprendizagem das técnicas e linguagens utilizadas.

Para simulação dos sistemas distribuídos, fez-se uso de um PC, onde cada empresa hospedada era tratada como um servidor WEB.

(13)

2- Serviços Web

2.1- Histórico

O termo “Web services” (serviços Web) apareceu para denominar uma nova estrutura para arquitetura de sistemas voltados para a Internet, com especificação inicial pertencente a Microsoft, mas vem crescendo e sendo usada como sinônimo para denominar serviços disponíveis na internet, capazes de interagir entre si trocando informações de forma padronizada sem requerer para isso a intervenção humana.

Na década de 90, existiam idéias e técnicas que permitiam a integração de diferentes aplicações distribuídas, como RPC (Remote Procedure Call), DCOM (Distributed Component Object Model), CORBA (Common Object Request Broker Architecture) e MSMQ (Microsoft Message Queuing), porém todas elas possuem a comum deficiência de somente funcionarem de um sistema similar para outro, ou seja, CORBA só consegue se comunicar com CORBA, um cliente DCOM somente com um servidor DCOM e assim por diante. Outros problemas comuns nestas técnicas são a falta de interoperabilidade, independência de plataforma e dificuldade para atravessar firewalls (SKONNARD, 2002).

2.2- O que são serviços Web

Os serviços Web são o que há de mais recente em desenvolvimento de aplicações, e vem atraindo o interesse de desenvolvedores que trabalham em todas as plataformas. O conceito fundamental é simples – os serviços Web nos permitem compor as RPCs (Remote Procedure Calls ou chamadas de procedimento remoto) de um objeto pela Internet ou por uma rede. Os serviços Web não são a primeira tecnologia a nos permitir isto, mas são diferentes tecnologias existentes, pois o fato de usarem padrões neutros de plataforma como HTTP e XML, nos permite ocultar os detalhes

(14)

relativos à implementação inteiramente provenientes do cliente. O cliente precisa conhecer o URL do serviço, e os tipos de dados usados para as chamadas do método, mas não precisa saber se o serviço foi construído em Java e se está sendo executado em Linux, ou se é um serviço Web ASP. NET que é executado no Windows.

Podemos redefinir serviços Web, como uma forma de softwares de uma máquina acessar software de outra máquina, ou mesmo de outro hardware, como um Pocket PC ou até mesmo um celular. Isto poderia ser dado através de chamas de procedimentos remotos ou RPC. Porém, pelo fato dos serviços Web serem totalmente baseados em XML, e estes dados serem facilmente transportados pelo protocolo padrão da Web, o HTTP (Hyper Text Transfer Protocol), através do empacotamento via protocolo SOAP (Simple Object Access Protocol), resolvem-se vários problemas do RPC tradicional, como um importante exemplo, a interoperabilidade. São ainda utilizados outros padrões, como WSDL, UDDI.

2.3 Arquitetura dos serviços Web básicos

2.3.1 – Funcionalidade comercial

Esta é a funcionalidade que é apresentada pelo provedor de serviço Web, como um serviço Web. É importante entender que as empresas comerciais que fornecem serviços Web, não aproveitarão suas aplicações existentes baseadas na tecnologia J2EE, por exemplo, para demonstrar os seus EJBs como serviços Web. Sabemos que isso seja tecnicamente possível com os que existem hoje no mercado no ramo de plataformas e ferramentas de serviços Web. O detalhe principal é que os negócios não apresentam chamadas de métodos em alguns componentes, isso pode resultar em uma resposta imediata de volta para o consumidor do serviço, podendo também ser executada durante alguns dias.

(15)

2.3.2 – Sistemas de serviços Web

O Sistema de serviço Web é muito parecido ao conceito de container no J2EE, disponibilizando um ambiente de tempo de execução para a execução dos serviços Web. O Sistema de serviços Web contém um ambiente de serviços Web de tempo de execução que obtém solicitações de SOAP e as mapeia para o componente do Java apropriado, ou seja, a classe Java ou o EJB que participa da funcionalidade comercial, junto, pode ser responsável pela coleta de todos os resultados do processo de negócio, e por seu encapsulamento dentro de uma resposta do SOAP, que é enviado de volta ao cliente.

2.3.3 – Servidor Web

Um servido Web é o principal gateway para solicitações do SOAP, um servidor Web utiliza o protocolo HTTP e geralmente está ligado à porta 80. Com isso, ele se ajusta às camadas de mensagens e camada de transporte do XML, pois a mensagem SOAP precisa ser enviada através do protocolo HTTP. Teremos que dar importância ao fato é que o arquivo WSDL está localizado no servidor Web, o motivo é que ele fornece um mecanismo acessível globalmente aos consumidores do serviço, para que façam referência à especificação WSDL. Por fim, se fornecido uma referência ao arquivo WSDL como um URL no registro do UDDI, os consumidores poderão localizar com certa facilidade o WSDL através da URL, fazendo o

download do WSDL, e interpretando-o, para determinar os serviços

suportados pela empresa.

2.3.4 – Cliente do serviço Web

O Cliente do serviço Web é um consumidor do serviço Web. Um cliente escrito em qualquer uma das linguagens de programação pode invocar um serviço Web. O primeiro passo de um cliente de serviço Web faz

(16)

uma referência a uma informação de UDDI para o negócio que fornece o serviço Web no qual ele está interessado, a partir da informação enviada pelo UDDI, recupera-se a referência do URL para o WSDL, assim sendo o documento WSDL é carregado a partir do URL.

2.4 – Segurança em serviços Web

A segurança é um dos problemas mais importantes a serem considerados, sempre que for necessário realizar alguma transação comercial. Sempre que é apresentada uma nova tecnologia a uma empresa, uma das áreas de maior interesse será a segurança. Sem um sólido modelo de segurança na aplicação, ela não será aceita por nenhum negócio destinado a realizar negócios na Internet. O mesmo se aplica para serviços Web.

A segurança se aplica a 3 áreas basicamente:

?? Privacidade: A criptografia é a palavra-chave deste item, de maneira que ninguém possa saber o que esta sendo conversado entre o cliente e o serviço.

?? Autenticação: Necessita-se a confirmação de identidade entre o cliente e o serviço Web, para que se possa cobrar pelo serviço.

?? Não-repúdio: É importante que o serviço mantenha um registro de chamamentos de maneira que seja não seja possível o cliente negar o envio de mensagem.

Os serviços Web podem abranger a segurança em dois níveis:

?? Segurança no transporte: Já esta disponível hoje no mercado na forma de HTTPS (HTTP Secure), mas devemos salientar que quando existem intermediários passa a existir a necessidade de segurança na mensagem.

?? Segurança na mensagem: Os intermediários estão presentes entre o cliente e o servidor Web. Os intermediários permitem diminuir de maneira mais eficaz a carga que esta sob o servidor principal, por isso necessita-se que haja uma segurança para as mensagens que estão sendo transmitidas.

(17)

As mensagens confiáveis são um importante componente de qualquer sistema de e-business, garantindo que a mensagem foi encaminhada e entregue corretamente ao destinatário, caso a mensagem não seja entregue deve-se tratar. Estas mensagens confiáveis devem ser criadas tanto na camada de transporte como na de rede e na camada de mensagem da pilha de serviços Web, por isso utiliza-se o protocolo primário HTTP como protocolo de transporte.

2.5- Interoperabilidade

Interoperabilidade é hoje uma das maiores e mais importantes preocupações das organizações, pois temos um grande número de sistemas operacionais e de desenvolvimento de software (linguagens de programação) necessitando comunicar entre estas plataformas. Existem umas áreas onde interoperabilidade é um ponto muito importante e relevante para este trabalho: Enterprise Application Integration (EAI). EAI representa um desafio que as empresas se defrontam na integração de suas várias aplicações umas com as outras. Estes vários sistemas certamente precisarão se comunicar e trocar informações para servir as necessidades da empresa. Realizar isto eficientemente sempre foi um desafio, como formas alternativas sempre contaram com impressoras e fax como parte de suas estratégias de integração.

Uma vez servidores Web e browsers tornaram-se disponíveis pela maioria das plataformas, interoperabilidade finalmente tornou-se uma realidade.

Em diferentes ambientes de arquiteturas orientadas a serviços, existem vários recursos que não necessitam saber como os outros funcionam, mas necessita-se haver uma padronização em comum para troca de mensagens de forma confiável sem erros e sem desentendimentos. Portanto, interoperabilidade é quando serviços podem interagir uns com os outros sem que haja falha de comunicação, independentemente de linguagem. Os serviços Web por serem baseados

(18)

em XML, uma linguagem de marcação que independe de linguagem de programação e plataforma, fazem da interoperabilidade um dos motivos de maior sucesso.

(19)

3- Arquitetura de serviços Web

3.1- XML

Extensible Markup Language é uma linguagem padronizada de

Marcação, como explicado nos sub-tópicos abaixo:

3.1.1- Linguagens de Marcação

Com a constante evolução da Internet nota-se a importância das linguagens na marcação, demonstrando uma enorme facilidade na exibição de dados. A grande facilidade de uso aliada a sua simplicidade tornou muito rapidamente esta linguagem um padrão utilizado para a divulgação na

World Wide Web

As linguagens de marcação têm como característica utilizar tags para estruturar seus dados e informações, desta maneira outra aplicação pode executar estas informações e apresenta-las ao cliente. As tags HTML são processadas na maioria das vezes por navegadores (browsers) que são aplicações que interpretam estes documentos e exibem no monitor do usuário o conteúdo do documento.

O HTML teve sua origem no SGML (Standard Generalized Markup

Language), surgido na década de 70, como linguagem para representar

documentos. Ao contrário do que se pensa do HTML o SGML não é uma linguagem, e sim uma metalinguagem que serve como sustentação e exemplo para o surgimento de linguagens de marcação. Na prática podemos ter metalinguagens e vocabulários.

Metalinguagens são as linguagens que servem como base para formar os vocabulários, exemplos de metalinguagens: XML e SGML. Os vocabulários são formados a partir das metalinguagens, exemplo: HTML

(20)

Na década de 90 surgiu o XML que é uma metalinguagem, mas na verdade é um conjunto menor que o SGML, sendo assim mais simples e com uso facilitado para internet.

O XML apareceu para desenvolver uma série de soluções para as aplicações que, em geral, o HTML, por ser um conjunto fixo de tags. Cada aplicação pode elaborar suas próprias tags, tendo assim uma flexibilidade muito maior na elaboração dos documentos tornando possível que o documento seja processado automaticamente (por aplicações diferentes), ultrapassando assim o fundamento do HTML que é exibir dados de maneira apresentável ao usuário (W3C, 2003).

3.1.2- Exemplo de um arquivo XML

Um documento XML tem semelhança com um documento HTML, pois ambos possuem tags. Tags ou marcas são palavras precedidas do símbolo “<“ e finalizadas com “>”. As tags do XML podem ser criadas pelos usuários, já as tags do HTML já são definidas.

<?xml version="1.0"?> <ROOT>

<ID_CADASTRO>1</ID_CADASTRO> <NOME>Diogo Ruviaro Viegas</NOME> <EMAIL>diogo@xml.com.br</EMAIL> <URL>www.xml.com.br</URL> <TECNOLOGIA>XML</TECNOLOGIA> </CADASTRO> <CADASTRO> <ID_CADASTRO>2</ID_CADASTRO> <NOME>André Cinha</NOME> <EMAIL>andre@bigfoot.com</EMAIL> <URL>www.tecnologies.com</URL> <TECNOLOGIA>SAP</TECNOLOGIA> </CADASTRO> <CADASTRO> <ID_CADASTRO>3</ID_CADASTRO> <NOME>Andrea Salvador</NOME> <EMAIL>andrea@hotmail.com</EMAIL> <URL>www.xmlpkd.com</URL> <TECNOLOGIA>XML</TECNOLOGIA> </CADASTRO> </ROOT>

(21)

Observando a estrutura XML, faremos uma analogia com a tabela cadastro:

?? root é a raiz da estrutura XML, é ela quem marca o início e o fim dos dados;

?? cadastro é o nome da tabela (neste caso), mas para a visão do XML é uma subraíz;

?? id_cadastro, nome, email, url e tecnologia são os campos da tabela nesse caso, mas na estrutura XML são apenas os nós; Dentro das tags estão armazenados os valores, como nos campos da tabela.

É possível entender agora o porquê das afirmações: "armazenar dados e padronizar dados". No caso da tabela cadastro há uma padronização no armazenamento dos dados, mas em um formato padrão isolado, ou seja, só é válido para este banco de dados, conseqüentemente apenas para plataformas que sejam compatíveis com o mesmo. A modelagem da estrutura XML é livre como a modelagem de uma tabela em um software de banco de dados. Da mesma forma que é definido nomes para as tabelas e campos são definidos nomes para as tags, por isso a modelagem da estrutura XML é tão importante quanto à de uma base de dados. Como o XML é escrito em formato texto, o raio de ação da tecnologia é universal, ou seja, os dados estão armazenados e padronizados de forma independente de plataforma ou software, sendo válido para qualquer utilização.

(22)

3.2 SOAP

3.2.1 O que é SOAP

O Simple Object Access Protocol (SOAP) é um protocolo de computação superficial distribuído que permite trocar de informações em um ambiente descentralizado e distribuído. A especificação SOAP define um

framework para a transmissão de mensagens entre sistemas distribuídos.

Entretanto o SOAP não define a semântica das mensagens, fornece apenas o framework.

O SOAP utiliza o protocolo XML baseado em texto, para se comunicar

com ambientes distribuídos em vez de formato binário usado por outros protocolos de comunicação, como o CORBA, RMI e o DCOM. Essa característica torna o SOAP altamente utilizável por várias plataformas de hardware, sistemas operacionais, linguagens de programação e plataformas de hardware de rede.

O SOAP não é primeiro protocolo de comunicação distribuído, mas é o primeiro a receber um apoio sem precedentes, por parte da indústria, de todos os principais fornecedores de software e hardware. Isso nunca aconteceu com nenhum outro protocolo de computação distribuído, como o CORBA, o RMI ou o DCOM – o que levou a comunidade de desenvolvimento a fragmentar-se, com alguns desenvolvedores implementando sistemas distribuídos usando um protocolo, enquanto outros decidiram usar outro (HENDRICKS, 2002).

O SOAP pode ser transportado pelo http, o que permite que se beneficie dos investimentos em infra-estrutura, como servidores Web, servidores proxy e firewalls. SOAP é formado por três partes

(23)

?? Um envelope que define o que é a mensagem e como processá-la. ?? Um conjunto de regra (encoding rules) de controle para expressar instâncias de tipo de dados da aplicação.

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

Figura 3.2.1 – Exemplo do protocolo SOAP

3.2.2 – RPC e o SOAP

RPCs ou chamadas remotas de procedimentos, são chamadas locais a métodos de objetos (ou serviços) remotos. Portanto, podem-se acessar os serviços de um objeto localizado em um outro ponto da rede, através de uma chamada local a este objeto. Cada chamada ou requisição exige uma resposta.

Antes de serem enviadas pela rede, as chamadas de RPC (emitidas pela aplicação cliente) são encapsuladas (ou serializadas) segundo o padrão SOAP. O serviço remoto, ao receber a mensagem faz o processo contrário, desencapsulando-a e extraindo as chamadas de método. A aplicação servidora então processa esta chamada, e envia uma resposta ao cliente. O processo então se repete: a resposta é também serializada e enviada pela

(24)

rede. Na máquina cliente, esta resposta é desencapsulada e é repassada para aplicação do cliente.

A seguir tem-se um exemplo de uma RPC, usando HTTP para o transporte:

POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com

Content-Type: text/xml; charset=”utf-8” Content-Length: nnnn SOAPAction: “Some-URI” <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”> <SOAP-ENV:Header> <t:Transaction xmlns:t=”some-URI” SOAP-ENV:mustUnderstand=”1”> 5 <t:Transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:GetLastTradePrice> xmlns:m=”Some-URI”> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

3.2.3 Estrutura da mensagem SOAP

SOAP consiste em troca de mensagem entre emissores e receptores. As mensagens SOAP são documentos XML que possuem as informações de requisição de métodos e de respostas (W3C, 2003).

Uma mensagem SOAP é composta por (HENDRICK et al, 2002):

?? Envelope: que é o elemento raiz do documento XML que representa a mensagem.

?? Header: pode ser opcional e adicionar recursos para o receptor da mensagem realizar o tratamento da mensagem.

?? Body: é o conteúdo da mensagem e contem às informações que devem ser recebidas pelo receptor da mensagem.

As regras de gramática que definem uma mensagem SOAP válidas são descritas a seguir (HENDRICK et al, 2002):

(25)

1) Envelope

?? O nome do elemento do documento XML deve ser “envelope”.

?? O elemento deve estar presente na mensagem SOAP. ?? O elemento pode conter atributos adicionais.

2) Header

?? O nome do elemento é Header.

?? O elemento pode estar presente na mensagem SOAP.

Se estiver presente o elemento deve ser o primeiro filho elemento do elemento Envelope.

3) Body

?? O nome do elemento é body.

?? Se a mensagem possuir o elemento Header, Body deve seguir o elemento Header, caso contrário, Body deve ser o primeiro elemento filho do elemento Envelope.

3.2.3.1 SOAP Header

O cabeçalho SOAP é uma maneira flexível e geral de adicionar recursos como autenticação, gerencimento de transação e serviços de pagamento a uma mensagem SOAP. Um cabeçalho SOAP é especificado em uma mensagem SOAP, pelo elemento SOAP-ENV: Header. Um cabeçalho SOAP não é obrigatório, mas, se for usado, deverá vir imediatamente depois do elemento envelope SOAP. Um cabeçalho SOAP pode conter elementos filho, que são representados como entradas de cabeçalho dentro de especificação SOAP.

O exemplo abaixo mostra como um cabeçalho SOAP pode ser escrito.

<SOAP-ENV: Envelope

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

SOAP-ENV: encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”> <SOAP-ENV:Header>

(26)

xmlns:a=http://www.wrox.com/soap/authentication> <a:username>mlhendri</a:username> <a:password>courtney</a:password> <a/ authentication </SOAP-ENV:Header> <SOAP-ENV:Body> .... </SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 3.2.3.2 SOAP Body

O corpo SOAP contém a carga útil (informações) que deve ser recebida pelo receptor da mensagem. O corpo SOAP de uma mensagem é especificado usando o elemento <Body>. Na prática, a carga útil consiste, tipicamente, em uma chamada RPC, resposta RPC, ou relatório de erro. Porém, teoricamente, corpo SOAP pode conter qualquer tipo de informação. Caso um elemento de cabeçalho esteja presente, o elemento <Body> deve seguir imediatamente o elemento <Header>. Os exemplos a seguir mostram onde a carga útil residiria:

<SOAP-ENV: Envelope

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

SOAP-ENV: encodingStyle=http://schemas.xmlsoap.org/soap/encodign/> <SOAP-ENV:Header> <a:authentication xmlns:a=”http://www.wrox.com/soap/authentication” SOAP-ENV:mustUnderstand=”1”> <a: username>mlhendri</a:username> <a:password>courtney</a:password> </a>authentication> </SOAP-ENV:Header> <SOAP-ENV:Body> .... </SOAP-ENV:Body> </SOAP-ENV:Envelope>

(27)

3.2.3.3 SOAP Fault

O Elemento <Fault> do SOAP é usado para o tratamento de erros em uma aplicação SOAP. O elemento <Fault> pode ocorrer uma única vez dentro de uma mensagem SOAP. Não podemos ter vários elementos <Fault> do SOAP. Vale a pena notar que o elemento <Fault> do SOAP é a única entrada de corpo definida na especificação SOAP. O elemento <Fault> define os quatros sub-elementos a seguir: <faultcode>, <faultstring>, <faultactor> e <detail>.

A seguir podemos ver a tabela de faultcode (HENDRICK et al, 2002):

Descrição do FaultCode Explicação

VersionMismatch A parte responsável pelo

processamento encontrou um namespace inválido para o envelope SOAP.

MustUnderstand Um elemento com o valor

ustunderstand = 1 não foi

compreendido pela parte

responsável pelo processamento.

Client A classe de erros de cliente

indicou que a mensagem não possuía informações corretas, como por exemplo, valores para autenticação.

Server A classe de erros de servidor

indicou que a mensagem não pode ser interpretada não por erro da mensagem em si, mas por alguma falha no servidor, como por exemplo, o

processador ocupado.

3.2.4 Codificação do SOAP

A especificação SOAP define como os dados na carga úteis da mensagem SOAP podem ser codificados. Entretanto, o SOAP não define um

(28)

novo sistema de tipos, mas o adota a partir da especificação

(http://www.w3.org/TR/xmlschema-2/).

Entretanto, o mecanismo de codificação do SOAP não deve ser usado, e nós podemos definir o nosso próprio – embora a especificação SAP estimule a utilização do mecanismo na especificação anteriormente mencionada.

A especificação se divide em dois grupos de tipos: Simples e complexos. A diferença entre eles é que os simples não podem ter filhos de elementos ou atributos enquanto os complexos podem.

Figura 3.2.5 – Exemplo de comunicação do protocolo SOAP

3.3 - HTTP

O HTTP (Hypertext transfer protocol) é o protocolo mais utilizado para transferência de documentos via WWW (World Wide Web).

O HTTP realiza trocas de mensagens via porta 80, mas podendo ser utilizada outras portas para essas trocas. A troca de mensagem se baseia em comando request e response que são enviados conforme se inicia a troca de mensagem. O comando request é enviado ao servidor que reponde com o response.

(29)

A utilização de HTTP, na sua grande maioria, pelo protocolo SOAP é dado pelo seu tráfego ser liberado pelos firewalls, que não checam a porta 80, já que são transmitidos apenas “textos”.

3.4 – WSDL

A WSDL (Service Web definition Language) define um sistema para a descrição de serviços, de maneira que uma aplicação possa se adequar dinamicamente a um serviço. Isso deve ser feito independentemente de qualquer plataforma ou linguagem de programação. É uma linguagem baseada em XML usada para definir Web Services (serviços Web) e descrever como acessá-los.

A WSDL foi definida em um esforço conjunto da IBM, Microsoft e Ariba, tendo sido submetida à organização W3C, para padronização.

Um documento WSDL representa a interface externa de um serviço Web. Em outras palavras, equivale, para serviços Web, ao que a Interface

Definition Language (IDL) corresponde no mundo do CORBA. Entretanto,

além de descrever a interface apresentada, um documento WSDL também contém a localização (ou ‘extremidade’ como a especificação se refere a ela) do serviço. O registro do serviço está disponível em um local previsível e bem conhecido, na rede, o que permite que o cliente contacte-o de uma maneira confiável. Isso significa, sem dúvida, um benefício adicional o da independência de local.

O mapeamento, pela estrutura de um documento WSDL, é feito da seguinte maneira:

?? O elemento <types> define os tipos de dados usados.

?? Os elementos <message> definem as mensagens que são usadas pelo serviço.

?? Os elementos <operation> definem mensagens solicitação-resposta, usadas pelas funções individuais oferecidas por um serviço.

(30)

?? O elemento <binding> descreve como um tipo de porta é mapeado, para um protocolo de rede.

?? O elemento <service> e seu elemento <port> contido incluem a localização da implementação de um serviço na rede.

O diagrama a seguir resume os principais elementos da WSDL. <definitions>

<types>

[XML Schem describing the used datatypes] </types> <message> [Description of message] </message> <portType> <operation>

[Reference to input and output messages] </operation>

</portType>

[Description of network protocol for invocation] </binding>

</service> <port>

[Reference to actual location of service] </port>

(31)

Elemento <definitions>

O elemento raiz de cada documento WSDL é o elemento <definitions>, que contém tipicamente atributos definido os namespaces usados no documento WSDL. Veja um exemplo:

<?xml version=”1.0” encoding=”UTF-8”?> <!- File: AddressBookService.wsdl -> <definitions name= “AddressBookService”

targeNamespace=http://localhost:8080/Wrox/wsdl/AddressBook-serivce.wsdl xmlns=http://schemas.xmlsoap.org/wsdl xmlns: tns=http://localhost:8080/wrox/wsdl/AddressBook-service.wsdl xmlns:binding= http://www.addressbook.com/definitions/AddressBookRemoteInterface xmlns: soap=http://schemas.xmlsoap.org/wsdl/soap/>

<!—conteúdo do arquivo entra aqui -> </definitions>

Elemento <import>

As informações sobre interface ou tipos de dados podem ser mantidas separadas das definições de extremidades concretas, o que permite a reutilização das definições de interface potencialmente padronizada a partir das implementações reais em um servidor que está sendo executado.

O elemento import aceita esta separação. Ele contém dois atributos,

um definindo a localização do documento importado, e outro definido seu namespace.

O exemplo abaixo mostra como este elemento é utlizado.

<?xml version=”1.0” encoding=”UTF-8”?> <!- File: AddressBookService.wsdl -> <definitions name= “AddressBookService”

targeNamespace=http://localhost:8080/Wrox/wsdl/AddressBook-serivce.wsdl xmlns=http://schemas.xmlsoap.org/wsdl xmlns: tns=http://localhost:8080/wrox/wsdl/AddressBook-service.wsdl xmlns:binding= http://www.addressbook.com/definitions/AddressBookRemoteInterface xmlns: soap=http://schemas.xmlsoap.org/wsdl/soap/>

(32)

<sopa:address location=” http://localhost:8080/Wrox/servlet/rpcrouter”/> <port>

</service> </definitions>

Elemento <types>

Qualquer serviço Web representativo lida com dados. Os dados devem ser passador ao serviço, retornados do serviço, ou ambos. Em aplicações distribuídas, esses objetos são passados, tipicamente, por uma rede, no formato binário. Em outras palavras, eles são ordenados ou serializados.

O elemento <types> contém a definição dos tipos de dados com os quais um serviço lida. Em quase todos os casos, esta é uma definição de XML. Caso ela não esteja presente, isso significa que um serviço esteja usando apenas tipos de dados básicos, como strings, inteiros e outros.

Segue abaixo um exemplo utilizando <types>

<types>

<xsd: schema xmlns:xsd=”http://www.w3.org/2001/XMLSchema”> <xsd:element name =”Address”>

<xsd:complexType> <xsd: sequence>

<xsd: element name=”street” type=”xsd:string”/> <xsd:element name=”city” type=”xsd:string”/> <xsd:element name=”zipcode” type=”xsd:string”/>

</xsd:sequence> </xsd: complexType> </xsd: element> </xsd:schema> </types> Elemento <message>

Uma mensagem pode ser composta de alguns argumentos, no caso de uma chamada de um método todos os parâmetros do método são representados por uma única mensagem. Cada elemento <message> contém um ou mais elementos <part> que formam as partes reais das mensagens. Cada elemento <part> se refere a um tipo definido no elemento <types> do documento.

(33)

</definitions>

Elementos <portType> e <operation>

O elemento <portType> define um grupo de operações. Por definição um elemento <portType> pode conter zero ou mais elementos

<operation>.

Cada elemento <operation> contém uma combinação de elementos “input” e “output”, sendo que quando há um elemento output pode haver outro elemento “fault”. A ordem desses elementos define a forma da troca de informações pela operação em questão.

Existem quatro tipos de troca de mensagens padrões (HENDRICK et al, 2002):

?? Operação unidirecional: É enviada uma mensagem de um cliente para um serviço, sem que haja resposta deste serviço.

?? Solicitação-Resposta: O serviço recebe uma mensagem e retorna outra mensagem como resposta ao solicitante. Este tipo é o mais comum de operação.

?? Pedido-Reposta: O serviço envia uma mensagem ao cliente e este, por sua vez, envia outra de resposta ao serviço. Este tipo não é muito utilizado em serviços Web.

?? Notificação: O serviço envia uma mensagem ao cliente de notificação.

Abaixo segue um exemplo de um tipo Solicitação-Resposta:

<portType name="WSCalculadoraSoap"> <operation name="Soma">

(34)

<documentation>Soma dois números</documentation> <input message="s0:SomaSoapIn" />

<output message="s0:SomaSoapOut" /> </operation>

<operation name="Subtrai">

<documentation>Subtrai dois números</documentation> <input message="s0:SubtraiSoapIn" />

<output message="s0:SubtraiSoapOut" /> </operation>

</portType>

Um elemento <portType> é considerado uma definição abstrata já que até aqui não é possível saber como suas mensagens são representadas na Web até que seja definido o elemento <binding>.

Elemento <binding>

O Elemento <binding> descreve o mecanismo usado por um serviço, para se comunicar com um cliente. Esse elemento é mais complexo do que os elementos anteriores, pois ele tem certo grau de liberdade, quanto ao que se pode incluir nele.

Esse elemento <binding> sempre é seguido por outro elemento, específico para o protocolo que está sendo usado, neste caso o SOAP. Em outras palavras, qualquer serviço Web que seja acessível através do SOAP possui um elemento <binding>, seguido por um elemento <soap:Binding> na sua definição de WSDL.

Exemplo abaixo:

<soap:binding style=”rpc” transport=http://schemas.xmlsoap.org/soap/http/> <operation name=”getAddress”> <soap:operation soapAction=”urn:Addressbook”;> <input> <soap:body encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ namespace=”urn:addressbook” use=”encoded”/> </input> <output> <soap:body encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ namespace=”urn:addressbook” use= “encoded”/> </output> </operation> </binding>

(35)

Elementos <service> e <port>

O elemento <service> define uma coleção de portas (<port>). Cada porta expõe um elemento <binding> por um endereço Web válido, podendo então que um serviço Web seja acessível através de várias portas, no mesmo instante (HENDRICK et al, 2002).

Exemplo abaixo:

<soap: address location=” http://www.abc.com/soap/servlet/rpcrouter”/> </port>

</port>

</service>

3.5 – UDDI

Depois de desenvolvido um serviço Web, necessita-se acessar em algum lugar na Web. Uma das maneiras que isso pode ser feito de uma forma estática, onde se conhece previamente a localização do serviço, sua URI. Porém, clientes podem não ter um conhecimento prévio da localização destes serviços, necessitando ser descoberto e posteriormente acessado, caracterizando a forma dinâmica. Isto é possível através de UDDI

(Universal Description, Discovery and. Integration).

A especificação UDDI faz com que clientes/empresas interajam mais rapidamente e dinamicamente. UDDI permite que empresas descrevam seus negócios e seus serviços, permite que descubra outras empresas que ofereçam serviços desejados e permite a integração entre as empresas, pelos seus serviços. O uso de UDDI pode ser feito uma analogia com o uso, pelas pessoas, de sites de pesquisa para encontrar Web Sites.

Enfim, UDDI é uma especificação técnica para descrever, descobrir e integrar serviços na Web.

(36)

3.5.1 Estrutura de dados UDDI

Um registro UDDI armazena informações sobre os negócios e os serviços oferecidos por eles. A forma de como esses serviços são estruturados assemelha-se com um catálogo telefônico, de maneira que números de telefone são armazenados e catalogados. As informações capturadas no contexto UDDI podem ser classificadas em três categorias (HENDRICK et al, 2002):

?? Páginas Brancas (White Pages): Possuem informações gerais sobre uma empresa em questão, como exemplo, nome, endereços, número de telefones, incluindo informações sobre os negócios.

?? Páginas Amarelas (Yellow Pages): Possuem listagem de negócios, classificadas por tipo de negócio ou pela indústria em que opera.

?? Páginas Verdes (Green Pages): Possuem informações técnicas sobre os serviços dos negócios, como exemplo, parâmetros, forma de utilização, dentre outros.

Desta forma, é possível obter informações sobre empresas, negócios, além dos serviços oferecidos. Para que seja possível fazer a publicação ou recuperação destes dados, o núcleo do UDDI utiliza-se de um XML Schema, com cinco principais elementos: publisherAssertion, businessEntity,

businessService, bindingTemplate e tModel. tModel

Um tModel representa uma especificação técnica em um registro UDDI. Essa especificação técnica pode descrever todos os tipos de coisas – por exemplo, um padrão para a troca de dados entre negócios ou a definição da interface de um determinado serviço Web.

Exemplo abaixo: <tModel authorizedName=”wstkDemo” operator=”ATOST/services/uddi” tModelKey=”UDDI:7C91BE10-EA7F-11D5-A6D4-9EABA21023”> <name>AddressBook tModel</name> <overviewDoc>

(37)

<overviewURL> http://localhost:8080/Wrox/wsdl/Addressbook-service.wsdl </overviewURL> </overviewDoc> </tModel> BusinessEntity

A entrada-raiz da hierarquia de dados do UDDI é o elemento <businessEntity>, que contém informações sobre um negócio – seu nome, seu endereço, seu número de telefone etc. Ele contém um <categoryBag> e um <identifierBag>. O que permite que a entrada seja categorizada, conforme descrito acima.

Exemplo abaixo:

</sequence>

</complexType> </element>

3.6 API UDDI

A API UDDI é neutra, no que se refere à linguagem de programação. De fato, todas as tecnologias que formam a arquitetura dos serviços Web são neutras nesse sentido. Essa é a única maneira de se garantir uma ampla utilização por parte dos desenvolvedores. Esse é o motivo pelos quais todas as especificações dos serviços Web promovem essa utilização estendida do XML para descrever seus formatos de dados. A XML permite que se criem tags em dados, o que facilita a sua interpretação.

A especificação da API UDDI não é diferente. Todas as interfaces são descritas como estruturas de dados de requisição e de resposta formatadas em XML. Portanto, o acesso a um registro UDDI significa o envio e

(38)

recebimento de dados XML. O protocolo que foi escolhido para fornecê-lo é o SOAP. O SOAP é a opção óbvia, pois define a chamada de uma função por meio de XML, e essa é uma especificação de serviço Web. De fato, isso resulta em um efeito colateral interessante. A API UDDI é descrita em XML, e chamada via SOAP, o que significa, automaticamente, que um servidor UDDI é, ele próprio, um serviço Web. Significa também que podemos criar um documento WSDL que defina as interfaces API UDDI e a ligação do SOAP para eles, bem como a definição da extremidade para um determinado registro.

Outra exigência definida na especificação é o uso de uma combinação de um ID de usuário e uma senha. Todas as funções de publicação precisam de credenciais para ser passadas com cada requisição, enquanto as funções de pesquisa estão abertas para todos. Isso é obtido pelo fornecimento de dois URLs de acesso, para os quais as requisições podem ser enviadas.

(39)

4 Linguagens e Plataformas Utilizadas.

Uma das características deste projeto é disponibilizar seu acesso através da Internet, além de disponibilizar serviços Web para serem consumidos por mais de um tipo de cliente, procuramos utilizar as melhores tecnologias (inclusive financeiramente) existentes no mercado e que atendam estas características, são elas:

?? Java

?? Apache (Servidor Web) ?? TomCat

Estas três tecnologias combinadas nos proporcionaram desenvolver este projeto com êxito, pois nos disponibilizaram todos os recursos necessários para desenvolver serviços Web confiáveis, seguros e robustos. Também foi possível desenvolver a aplicação cliente que consome os serviços Web.

4.1 Java

A linguagem Java foi utilizada neste projeto pelas facilidades oferecidas para o desenvolvimento de aplicações web e para a manipulação de documentos XML utilizados no desenvolvimento dos serviços Web, já que estes são aplicações web que utilizam padrões XML para trocar informações através da chamada de métodos de clientes.

A plataforma Java 2 Enterprise Edition (J2EE) disponibiliza as APIs e ferramentas necessárias que foram utilizadas para criar e disponibilizar serviços Web que apresentam completa interoperabilidade.

Adicionalmente foi utilizado o Java WSDP (Java Web Services

Developer Pack) que proporciona um fácil acesso às ultimas tecnologias de

XML, serviços Web e seus padrões. A tecnologia Java possui as seguintes subcategorias que para o desenvolvimento de serviços Web (SunMicrosystems,2003):

(40)

?? Java Web Services Developer Pack (Java WSDP) ?? Java API for XML-Based RPC (JAX-RPC)

?? Java API for XML Messaging (JAXM) ?? Java API for XML Registries (JAXR) ?? Java API for XML Processing (JAXP) ?? Java Architecture for XML Binding (JAXB) ?? SOAP with Attachments API for Java (SAAJ)

4.2 Servidor Web Apache

Por se tratar de um servidor web gratuito e com grande facilidade de uso e utilização difundida pelo mundo inteiro, utilizamos neste projeto o servidor Web Apache.

O servidor Web Apache é um projeto que possui o objetivo de desenvolvimento e manutenção de um servidor web open-source, para modernas operações incluindo servidores UNIX e Windows NT. Este projeto também possui o objetivo de disponibilizar um seguro, eficiente e extensível servidor que disponibiliza o serviço HTTP de acordo com os padrões atuais do protocolo HTTP.

O servidor Web “Apache” tem sido o servidor web mais popular na internet. O Netcraft Web Server Survey de outubro de 2003 encontrou mais do que 64% dos sites na Internet utilizando Apache, ou seja, tem sido mais utilizado do que todos os outros servidores combinados (APACHE.ORG).

4.3 Servlet Container Tomcat

O Servlet Container TomCat foi utilizados por se tratar de uma ferramenta com grande facilidade de uso e também com grande integração com o servidor Web “Apache”.

(41)

Tomcat é um Servlet container que utiliza a referencia oficial para

implementação das tecnologias Java Server Page (JSP) e Java Servlet.

Tomcat é desenvolvido em um ambiente participativo, aceitando

contribuições de desenvolvedores de todo o mundo, seguindo os padrões de desenvolvimento do Apache Software License (APACHE.ORG).

(42)

5 Problema a ser resolvido

O principal objetivo deste projeto é de consultar e mostrar os dados de “n” Web Services da área da construção civil. É válido ressaltar que estes Web Services são distribuídos pela cidade preferencialmente mas podendo ser expandindo por todo o estado. A seguir apresentaremos o funcionamento da aplicação implementada para resolver o problema de consultas.

6 Princípio de funcionamento do sistema

O sistema possui a característica de ser distribuído e sua arquitetura ser fundamentada em serviços Web. Para que o sistema funcionasse da maneira esperada, montou-se uma estrutura da seguinte forma:

?? Em Florianópolis existe um servidor Web. Este servidor possui a camada de Apresentação/Interface e consome os serviços Web que são disponibilizados ao cliente quando é efetivada a consulta, unificando as informações e apresentando de forma consolidada.

?? Como citado acima, cada loja que fornece dados nesta área disponibiliza seus serviços Web contendo as informações necessárias ao cliente do portal. Estes métodos serão invocados pela camada da interface.

?? Cada serviço Web presente nas lojas acessa os seus respectivos banco de dados. Por motivos de segurança, esta é a configuração mais confiável, pois assim impedimos que se o servidor de Apresentação/Interface sofra uma invasão os servidores que hospedam os serviços Web e acessam os bancos de dados da empresa estarão protegidos.

Na figura, a seguir, podemos visualizar a arquitetura básica do sistema:

(43)

Figura 6 – Funcionamento do sistema

Analisando o sistema, uma das características que percebemos é de identificar a vantagem que os serviços Web oferecem por utilizar o protocolo HTTP/SOAP. Esta forma torna possível bloquear as portas que não são utilizadas nos servidores que hospedam os serviços Web, deixando disponível somente a porta 80 (oitenta), utilizada pelo protocolo HTTP, diminuindo as possibilidades dos servidores que possuem acesso ao banco de dados sofram algum dano que possa ser causado por hackers .

Se a solução adotada fosse algo relacionado a sistemas distribuídos como CORBA, DCOM ou RMI, iríamos precisar fazer várias configurações especiais nos firewalls para que os dados ficassem seguros e que fosse possível implantar um sistema distribuído.

A camada de interface faz uma requisição (request) utilizando o protocolo SOAP indicando qual o método do serviço Web que ela deseja mostrar.

(44)

O serviço Web que esta sendo invocado neste momento recebe a mensagem SOAP e executa, ao executar ele analisa qual método esta sendo invocado (caso a mensagem esteja com falha ele retorna um erro). Ao descobrir qual método esta sendo invocado, o método é executado. Os métodos que realizam consultas em banco de dados e retornam o resultado para a camada de apresentação é um bom exemplo. Este resultado retorna à camada de aplicação em forma de XML.

Existe alguma seqüência de operações:

?? O cliente visita o site de orçamentos pela web e navega até a seção de consulta a Web services disponíveis na internet.

?? O cliente pode pesquisar por um servidor web específico, solicitar determinado produto, ou por preços promocionais de todos os servidores web disponíveis.

?? Quando o cliente solicita por determinado servidor web, ele deve receber uma lista de todos os produtos promocionais que estão cadastrados no banco de dados deste servidor. Isso significa que o site deve ter um mecanismo de comunicação com os sistemas de consultas e orçamentos

backend das lojas.

?? A partir da lista de produtos disponíveis, o cliente seleciona a lista de produtos enviada. O site envia essa solicitação ao sistema de orçamentos e consultas backend da loja e confirma o recebimento.

6.1 Recursos do sistema

Os principais recursos do sistema são:

?? Todas as lojas agora apresentam suas listas de produtos em promoção como um serviço web. Por isso, o site possui um mecanismo aberto e interoperável que abrange todos os sistemas das lojas, sem considerar os sistemas de consultas backend usados.

?? O site fornece uma interface web ao cliente. Essa interface fornece ao cliente diferentes informações relacionadas às lojas, mas também permite que o cliente escolha uma loja, tenha acesso a uma lista de lojas

(45)

disponíveis de lojas e envie a solicitação da consulta de produtos diretamente ao sistema de consultas de produtos da loja.

6.2 Benefícios do sistema

Ao usar tecnologias de serviço web padrão, como SOAP, cada sistema da loja pode agora ser acessado de uma maneira interoperável, o que remove a complexidade do projeto de integração. O site agora não se preocupa mais com o tipo de sistemas de consultas a produtos usados pelas lojas. À medida que forem oferecidas interfaces SOAP padrão, não ocorrerá mais problemas com a integração.

Caso uma loja queira fazer parte do sistema deve apenas expor seus sistemas como serviço web. Caso o serviço atenda aos requisitos do site a adição de um novo sistema da loja será quase contínua.

É claro que os custos aumentam quando começa a se acrescentar ao sistema, lojas com sistemas diferentes. Ao se usar tecnologias de serviços web abertas e intoperáveis, o site reduz o tempo necessário para o desenvolvimento e a manutenção de um sistema como esse.

(46)

7 Resultados Obtidos

Com o objetivo de demonstrar os resultados obtidos após o desenvolvimento da aplicação, mostraremos a seguir, execuções da mesma para obter dados das lojas que nos fornecem serviços web. As figuras a seguir representam a camada de apresentação (interface) utilizada pelos usuários.

7.1 Janela de Entrada

Figura 7.1 – Janela de entrada

Conforme mostra a figura acima o usuário quando entra na janela inicial se depara com 3 opções de navegação dentro do sistema. Ele pode escolher uma loja em específico, pode realizar a consulta sobre os produtos de todas as lojas que estão disponibilizando este serviço ao nosso sistema e para finaliza pode realizar uma consulta a serviços de construção civil que as lojas disponibilizam.

(47)

7.2 Janela Endereços das lojas

Figura 7.2- Janela de endereços das lojas

Nesta janela o usuário pode fazer uma consulta no estabelecimento mais próximo a sua residência se desejar ou na loja que já conhece por ser cliente, clicando sobre o nome da Loja o usuário será levado a pagina que lista os produtos que a loja específica disponibiliza para uma consulta. Neste momento é passado o ID da loja que se deseja consultar à página ConsultaLoja.jsp, no qual serve como parâmetro a fim de ajudar a essa página a acessar a lista de produtos dessa loja.

(48)

7.3 Janela de Produtos da Loja escolhida.

Figura 7.3 – Janela lista produtos para consulta

Nesta janela são mostrados os produtos que a Loja escolhida disponibiliza para consulta ao cliente. Neste instante o cliente tem a opção de escolher os produtos para consulta ou passar a página que oferece a lista com serviços fornecidos pela loja na área da construção civil.

(49)

7.4 Janela Consulta Realizada.

Figura 7.4 - Janela resultado da consulta de produtos

A Janela acima mostra o resultado da consulta feita pelo usuário a Loja desejada. Salientamos a atenção para o valor total do orçamento já descrito na página que irá facilitar o envio do orçamento a loja ou não de acordo com a opção do cliente.

No momento que o usuário efetiva a ação de consultar os valores dos produtos junto ao web service da loja, é invocado o método

retornaprodutos São informados como argumentos os produtos e enviados

(50)

7.5 Janela Menor Preço.

O sistema possui uma função que calcula o menor preço dos produtos pesquisados comparando em todas as lojas que ofereceram os seus serviços na web.

Após receber a lista com os produtos e os preços o sistema grava no banco de dados e realizada uma consulta fazendo comparações dos valores dos produtos e retornando ao usuário uma página informada a loja, o produto e o menor valor encontrado.

(51)

7.6 Janela de Serviços

Nesta janela a exemplo das anteriores é fornecida uma lista de serviços que as Lojas oferecem na área da construção civil, o cliente escolhe o serviço e o sistema passa como parâmetro para o objeto recebeservico que via mensagem SOAP retorna a lista com os valores e mais alguns dados importantes para a pesquisa.

(52)

7.7 Janela com resultados da consulta de serviços

Nesta janela são mostrados ao cliente todos os itens pesquisados, salientamos que a pesquisa sempre for feita em cima de dois serviços web de duas lojas.

(53)

Conclusão

Este projeto se dispôs a fornecer uma solução para integração de Web services voltadas para área da construção civil.

Os serviços podem ter uma manutenção precisa e de baixo risco, pois parte do sistema pode ser parado sem comprometer todo o sistema. É praticamente certo o desenvolvimento de sistemas de software atuais para que haja o mínimo possível de interrupção em todo o sistema por motivos de manutenção e conseqüente parada de uma parte dele; não é uma tarefa fácil e isso é feito quando várias empresas com sistemas diferentes de desenvolvimento de software e geralmente com drivers comerciais pagos tentam colaborar nos trabalhos de integração entre empresas.

Os detalhes do fornecedor são reunidos para os serviços principais, que podem ser gerenciados pelo fornecedor. O processo de tomar decisão é organizado para o cliente, podendo ser assistido através da otimização automatizada efetuada de acordo com o local da empresa de material de construção, usando detalhes do cliente ou conhecimento pertinente ao especialista no fornecimento de materiais de construção, tudo isso para mencionar apenas algumas possibilidades.

As tarefas de integração adicionais, desde que os primeiros projetos tenham sido feitos, podem ser realizadas rapidamente à medida que as empresas obtenham experiência no trabalho em conjunto e na obtenção de um único protocolo superficial e de uma arquitetura para a integração.

(54)

Referências

APACHE.ORG. Disponível em: <http://www.apache.org/>. Acesso em: 07 jan. 2004.

_____________. Disponível em:

<http://jakarta.apache.org/tomcat/tomcat-5.0-doc/index.html>. Acesso em: 11 jan. 2004.

HENDRICK, et al. Profissional Java Web Services. [S.I.]: Alta Books, 2002.

_____________. Understanding SOAP. Disponível em:

<http://msdn.microsoft.com/library/ default.asp?url=/library/en-us/ dnsoap/html/understandsoap.asp>. Acesso em 11 abr. 2004.

______________. Understanding WSDL. Disponível em: < http://msdn.microsoft.com/

webservices/understanding/webservicebasics/default.aspx?pull=/library/ en-us/ dnwebsrv/html/understandwsdl.asp.> Acesso em: 11 abr. 2004. OPENCONNECT. Bringing the Mainframe into the Web Services

World. Disponível em: <http://www.oc.com/solutions/xmlconnect.jsp>. Acesso em 18 mar. 2004.

_______________. Java Web Services. Disponível em:

<http://java.sun.com/ webservices/jwsdp/index.jsp>. Acesso em: 05 mar. 2004.

TIDWELL, D.; SNELL, J.; KULCHENKO, P. Programming Web Services with SOAP. [S.I.]: O'Reilly, 2002.

UDDI.ORG. UDDI Spec Technical Committee Specification.

Disponível em: <http://uddi.org/pubs/uddi-v3.0.1-20031014.htm>. Acesso em: 20 mai. 2004.

W3C. Web Services Glossary. Disponível em

<http://www.w3.org/TR/2003/WD-ws-gloss-20030808/>. Acesso em 15 mai. 2004.

W3C. XSL 1.0 Specification. Disponível em:

<http://www.w3.org/TR/xsl/> . Acesso em: 15 mai. 2004. W3C. Extensible Markup Language (XML). Disponível em: <http://www.w3.org/ XML/. Acesso em 16 fev. 2004.

(55)

W3C. SOAP Version 1.2 Part 1: Messaging Framework Disponível em:<http://www. w3.org/TR/SOAP/>. Acesso em 10 jan. 2004. W3C. HTTP - Hypertext Transfer Protocol, 2000. Disponível em:

(56)

Anexo I – Artigo

Serviços Web na área da Construção Civil

Diogo Ruviaro Viegas João Bosco Sobral Universidade Federal de Santa Catarina Departamento de Informática e Estatística diogo@inf.ufsc.br Universidade Federal de Santa Catarina Departamento de Informática e Estatística bosco@inf.ufsc.br

Resumo

A Indústria da Construção Civil pode ser considerada uma das maiores de Santa Catarina, tanto pôr usa visível presença em todo o Estado como pelo volume de recursos que circulam em sua função.

O mercado da Construção Civil passa pôr uma euforia, haja vista a quantidade de lançamentos de edifícios e novos negócios, desta maneira existem uma disputa acirrada em busca de compradores, aumentando a competitividade entre Empresas do Setor.

Diante deste quadro, acentua-se cada vez mais a necessidade de se melhorar a qualidade e a produtividade do Setor Industrial, notadamente na Construção Civil, onde o desperdício dos insumos é alarmante (as estatísticas mostram que aproximadamente 30% dos insumos são desperdiçados).

Em um grande número de empresas pode-se notar uma diversidade elevada de sistemas e a necessidade de integrá-los.

Este trabalho realiza o estudo da tecnologia de desenvolvimento de sistemas distribuídos denominada “Serviços Web” ou “Web Services”, abordando e explicando seus principais componentes: a linguagem XML, o protocolo de troca de mensagens SOAP, o protocolo de transporte

(57)

Abstract

The Industry of Civil Construction can considered one from bigger of Saint Catarine, as much to put all uses visible presence in the State as by bulky of resources that circulate in its function

The market of the Civil Construction passes to put an euphoria, has seen the amount of launchings of buildings and new businesses, in this way exists a dispute incited in search of purchasers, increasing the competitiveness between Companies of the Sector.

Ahead of this picture, each time is accented more the necessity of if improving the quality and the productivity of the Industrial Sector, eminent in the Civil Construction, where the wastefulness of the insumos is alarming (the statisticians show that approximately 30% of the insumos are wasted). In large enterprises one can realize a great diversity of existing systems and the need to integrate them.

The objective of this study is to explain and approach a technology for distributed systems development named “Web Services”, as well as its main components, the XML language, the SOAP messages exchange protocol, the HTTP transport protocol, and other features pertinent to this technology such as WSDL, UDDI.

1 Introdução

Estudando o mercado da construção civil, que envolve empresas com os mesmos tipos de serviços e que se relacionam umas com as outras oferecendo sempre o melhor preço alienado a qualidade dos seus produtos, verificou-se a necessidade de se desenvolver um serviço através da Web que “amenizasse” o esforço do usuário final em realizar consultas ‘a estas empresas.

Ao longo do tempo percebe-se que poucas empresas do ramo de desenvolvimento de soluções tecnologias têm unido esforços para encontrar a mais adequada solução para este problema. Poucas já foram