Baixe o app para aproveitar ainda mais
Prévia do material em texto
UNIVERSIDADE DO PLANALTO CATARINENSE DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE INFORMÁTICA (BACHARELADO) REDE DE INTERCÂMBIO DE DADOS PARA ACERVOS BIBLIOGRÁFICOS BASEADA EM WEB SERVICES Relatório do Trabalho de Conclusão de Curso submetido à Universidade do Planalto Catarinense para obtenção dos créditos de disciplina com nome equivalente no curso de Informática - Bacharelado. ENIO BUENO LAGES, JUNHO DE 2003 UNIVERSIDADE DO PLANALTO CATARINENSE DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE INFORMÁTICA (BACHARELADO) REDE DE INTERCÂMBIO DE DADOS PARA ACERVOS BIBLIOGRÁFICOS BASEADA EM WEB SERVICES Relatório do Trabalho de Conclusão de Curso submetido à Universidade do Planalto Catarinense para obtenção dos créditos de disciplina com nome equivalente no curso de Informática - Bacharelado. ENIO BUENO Orientador : Prof M.Sc. Douglas Nazareno Debiazi Vargas LAGES, JUNHO DE 2003 iii REDE DE INTERCÂMBIO DE DADOS PARA ACERVOS BIBLIOGRÁFICOS BASEADA EM WEB SERVICES ENIO BUENO ESTE RELATÓRIO, DO TRABALHO DE CONCLUSÃO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS DA DISCIPLINA DE TRABALHO DE CONCLUSÃO DE CURSO DO VIII SEMESTRE, OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE: BACHAREL EM INFORMÁTICA Prof. Douglas Nazareno Debiazi Vargas, M.Sc. Orientador BANCA EXAMINADORA: Prof. Wilson Castello Branco Netto, M.Sc. UNIPLAC Prof. Alexandre Perin de Souza, M.Sc. UNIPLAC Prof. Angelo Augusto Frozza, Esp. Supervisor de TCC Prof. Alexandre Perin de Souza, M.Sc. Coordenador de Curso Lages, 26 de Junho de 2003 iv Dedico este trabalho aos meus pais (in memoriam), Rodolfo Bueno Filho e Araci Bueno. A meu pai pelos valiosos ensinamentos sempre presentes na minha vida. A minha mãe, a pessoa mais integra que conheci, por sempre me apoiar e estar ao meu lado. v Agradeço a minha esposa Daiane pela paciência e carinho. A minha filha Bruna, por ela existir e preencher minha vida. Ao meu orientador e amigo Douglas Nazareno Debiazi Vargas. Aos meus colegas de aula, aos meus amigos do núcleo de informática da UNIPLAC e da Método Informática. vi Se sempre seguirmos os caminhos que outros já seguiram, no máximo chegaremos onde outros chegaram. SUMÁRIO LISTA DE SIGLAS.................................................................................................IX LISTA DE ILUSTRAÇÕES....................................................................................XI RESUMO................................................................................................................XII ABSTRACT...........................................................................................................XIII 1. INTRODUÇÃO.............................................................................................................14 1.1. Apresentação..................................................................................................................14 1.2. Definição do problema....................................................................................................15 1.3. Justificativa.....................................................................................................................16 1.4. Objetivos........................................................................................................................16 1.4.1. Objetivo geral.............................................................................................................16 1.4.2. Objetivos específicos...................................................................................................16 1.5. Metodologia...................................................................................................................17 2. O FORMATO BIBLIOGRÁFICO USMARC...........................................................................18 2.1. Histórico.........................................................................................................................18 2.2. Elementos de um registro MARC...................................................................................19 2.2.1. Líder...........................................................................................................................19 2.2.2. Diretório.....................................................................................................................19 2.2.3. Campos variáveis........................................................................................................19 2.3. Exemplo de registro USMARC.......................................................................................19 2.4. Conclusão.......................................................................................................................21 3. XML - EXTENSIBLE MARKUP LANGUAGE...................................................................22 3.1. Histórico da XML...........................................................................................................22 3.1.1. O Surgimento da SGML..............................................................................................22 3.1.2. O Surgimento do HTML..............................................................................................23 3.2. O Nascimento da XML...................................................................................................23 3.2.1. Características da XML..............................................................................................24 3.2.2. Diferenças entre XML e HTML...................................................................................24 3.3. XML em acervos bibliográficos......................................................................................25 3.4. Conclusão.......................................................................................................................27 4. WEB SERVICES..........................................................................................................28 4.1. Objetos Distribuídos.......................................................................................................28 4.1.1. CORBA.......................................................................................................................29 4.1.2. Java RMI..................................................................................................................... 29 4.1.3. DCOM........................................................................................................................30 4.1.4. Considerações sobre as tecnologias............................................................................30 viii 4.2. Web Services..................................................................................................................30 4.2.1. Tecnologias que compõem os web services..................................................................31 4.3. Conclusão.......................................................................................................................34 5. ANÁLISE DA REDE DE ACERVOS BIBLIOGRÁFICOS............................................................35 5.1. Base de Dados................................................................................................................35 5.2. A Interação do web service com a base de dados............................................................36 5.3. Classes do sistema legado...............................................................................................37 5.4. Módulo de inclusão de dados..........................................................................................38 5.4.1. Dificuldades na inclusão dos dados............................................................................38 5.5. Conclusão.......................................................................................................................386. IMPLEMENTAÇÃO.......................................................................................................39 6.1. Ferramentas utilizadas.....................................................................................................39 6.1.1. Firebird.......................................................................................................................39 6.1.2. Delphi.........................................................................................................................39 6.2. Web Service....................................................................................................................39 6.2.1. Servidor....................................................................................................................... 41 6.2.2. Cliente.........................................................................................................................44 6.3. Conclusão.......................................................................................................................45 7. CONSIDERAÇÕES FINAIS..............................................................................................47 7.1. Sugestões para trabalhos futuros.....................................................................................48 REFERÊNCIAS BIBLIOGRÁFICAS....................................................................49 BIBLIOGRÁFICA COMPLEMENTAR................................................................50 APÊNDICES.............................................................................................................51 LISTA DE SIGLAS ASCII American Standard Code for Information Interchange - Código de informação padrão para letras e símbolos. BU Biblioteca Universitária. CORBA Common Object Request Broker Architecture - Arquitetura comum para agentes de requisições de objetos distribuídos. DCOM Distributed Component Object Model - Solução de objetos distribuídos criado pela Microsoft. GCA Graphic Communications Association. HTML Hyper Text Markup Language - Linguagem para publicar textos e imagens na Internet. HTTP Hyper Text Transfer Protocol - Protocolo de transferência de hipertexto, protocolo usado nas páginas WWW da Internet. ISO International Organization for Standardization - Organização Internacional de Padronização. OMG Object Management Group - Grupo de Gerência de Objetos, corporação de provedores de software que encorajam o uso de programas orientados a objetos distribuídos em aplicativos. RMI Remote Method Invocation - Solução de objetos distribuídos criado pela Sun Microsystems. RPC Remote Procedure Call - Chamada de procedimentos remotos. SGML Standard Generalized Markup Language - Padrão internacional de escrita de arquivos hipertexto na Internet (baseado na separação da forma da tela do seu conteúdo) . x SINBAC Sistema de Integração das Bibliotecas da ACAFE. SOAP Simple Object Access Protocol - Protocolo no qual são baseadas as mensagens dos web services. SQL Structured Query Language - Linguagem de Pesquisa Estruturada, que usa bases de dados na configuração de uma procura. UDDI Universal Distribution, Discovery and Interoperability - Serviço de diretórios que publica a localização de web services. URI Universal Resource Identifier. URL Uniform Resource Locator - Localizador Uniforme de Recursos, o esquema utilizado na web para localizar uma determinada página ou arquivo. USMARC Machine Readable Cataloging Format – Padrão internacional de catalogação. W3C World Wide Web Consortium - Organização que regula e orienta a normalização de tecnologias relacionadas com a Internet. WSDL Web Services Description Languague - Linguagem usada para descrever as interfaces dos web services. XML Extensible Markup Language - Versão mais simples do padrão SGML (padrão universal para a escrita de documentos de hipertexto) para a criação de documentos HTML (usada nos sites da Internet). LISTA DE ILUSTRAÇÕES FIGURA 1 - Obra no formato de ficha catalográfica.......................................... 20 FIGURA 2 - Obra no formato USMARC............................................................. 20 FIGURA 3 - Exemplo de representação de informações em HTML .................. 25 FIGURA 4 - Exemplo de representação de informações em XML ..................... 25 FIGURA 5 - Documento XML representando uma obra do acervo .................... 26 FIGURA 6 - Exemplo de mensagem SOAP ....................................................... 33 FIGURA 7 - Tabelas referentes ao cadastro de obras ......................................... 36 FIGURA 8 - Classes do sistema legado ............................................................. 37 FIGURA 9 - Troca de mensagens SOAP........................................................... 40 FIGURA 10 - Requisição de serviço no formato SOAP ....................................... 40 FIGURA 11 - Fragmento da resposta SOAP retornada pelo servidor.................... 41 FIGURA 12 - TWebModule do web service......................................................... 42 FIGURA 13 - Trecho da classe teb_ws_acervo..................................................... 43 FIGURA 14 - Cliente web service........................................................................ 44 FIGURA 15 - Módulo de inclusão de obras alimentado pelo web service............. 45 TABELA 1 - Estrutura XML baseada no formato Dublin Core .......................... 26 RESUMO A inclusão de uma obra em um acervo bibliográfico requer a atenção de um bibliotecário ou de um funcionário que possua conhecimentos em biblioteconomia, isto se faz necessário dada à diversidade das obras e a complexidade das normas que regem o processo de classificação ou catalogação de um acervo. Graças à informatização das bibliotecas e a expansão da Internet, surgiram vários acervos on line disponíveis para consulta, e é prática comum entre bibliotecas consultar outros acervos procurando por obras já cadastradas. No entanto, trocar efetivamente registros, classificados ou catalogados entre bibliotecas, implica em participar de redes dedicadas que exigem uma infra-estrutura robusta e geralmente envolvem altos custos. Isto dificulta o acesso à estas redes para bibliotecas de pequeno e médio porte, que são justamente as mais carentes de profissionais especializados. Este trabalho propõem-se a viabilizar a criação de uma rede de acervos bibliográficos baseada em web services, o objetivo principal é agilizar e baratear o processo de inclusão e manutenção de obras em um acervo de qualquer porte. Como os web services são baseados em tecnologias abertas e usam como protocolo de transporte o HTTP e a porta 80, qualquer biblioteca que tenha acesso a internet estará apta a participar da rede como cliente. Para hospedar o web service, disponibilizando as obras do seu acervo se faz necessária a instalação de um servidor web. A rede foi concebida para trocar dados entre os sistemas que estão em funcionamento na Biblioteca Universitária da UNIPLAC, Biblioteca Pública Municipal de Lages, Biblioteca Pública Municipal de Florianópolis e na empresa Método Informática Ltda. Atualmente, existem dois web services ativos, um hospedado na UNIPLAC e outro na Método Informática, portanto, as obras destes dois acervos já estão disponíveis para as outras bibliotecas. Palavras-chave: Biblioteca, Acervo Bibliográfico, Web Service, SOAP, Internet. ABSTRACT The inclusion of a book in a bibliographical collection requires the attention of a librarian or an employee with knowledge in librarianship, this makes necessary given to the diversity of the collection and the complexity of the norms that conduct the process of classification or tabulation of a collection. Thanks to the informatization of the libraries and the expansion of the Internet, on line collections for consultation had appeared,and is practical common among libraries to consult other collections looking for books already registered. However, to exchange records between libraries effectively, implies in participating of dedicated nets that demand a robust infrastructure and generally involve high costs. This makes it difficult the access to the these nets for small and medium libraries, that are exactly most devoid of specialized professionals. This work propose the creation of a net of bibliographical collections based in web services, the main objective is make more agile and to reduce costs the process of inclusion and maintenance of collections of any size. As web services are based on open technologies and use as transport protocol the HTTP and port 80, any library that has access the internet will be apt to participate of the net as customer, to house the web service, and make available your collection, makes necessary the installation of a web server. The net was designed to change data between the systems that are in functioning in the University Library of the UNIPLAC, Public Library of Lages, Public Library of Florianópolis and in the company Método Informática Ltda. Currently there are two web services active, one housed in the UNIPLAC and another one in the Método Informática, therefore, the collection of these two already are available for the other libraries. Key-words: Library, Bibliographical Collection, Web Service, SOAP, Internet. 1. INTRODUÇÃO 1.1. Apresentação Todo acervo bibliográfico, seja ele de uma biblioteca universitária, pública ou privada, é composto por dois elementos fundamentais: o primeiro são as obras que compõem o acervo físico em si; o segundo é a forma como estas são classificadas ou catalogadas. O primeiro elemento depende única e exclusivamente dos recursos e anseios da instituição ou empresa que o mantém. O segundo, a classificação ou catalogação das obras, diferente do primeiro, recebeu um incremento significativo em suas funcionalidades com a adoção de tecnologias voltadas à informação. Pode-se dizer que um grande acervo é de fato grande se possuir ferramentas que permitam explorá-lo adequadamente. As informações que compõem cada registro de um acervo são complexas e bastante diversificadas. Antes que uma informação seja inserida é necessário um processo de preparação dos dados. Este processo é feito por um bibliotecário ou por um funcionário com conhecimentos em biblioteconomia. Quando a gerência de uma biblioteca opta por um determinado sistema para gerir suas informações, o que faz desta adoção um sucesso ou um fracasso é o grau de importância e recursos destinados à alimentação da base de dados. Infelizmente, na maioria dos casos, a carga inicial de dados no sistema se dá por meio de importações de dados já existentes em sistemas legados, que normalmente não contemplam todos os aspectos tratados pelo novo sistema. Se, por um lado, os programadores evitam ao máximo o uso de importações, por saberem o risco de inserir dados inconsistentes, por outro, eles tem consciência do quão oneroso seria recadastrar um acervo inteiro a partir do zero. 2 Uma alternativa para evitar os custos de classificação ou catalogação dos acervos é a criação de redes entre bibliotecas. Estas redes visam o compartilhamento de informações bibliográficas acerca dos seus acervos. Existem hoje vários tipos de redes com muitas variações no que tange a sua abrangência e seus objetivos. As redes internacionais são uma imensa fonte de pesquisas, mas são as redes regionalizadas que mais atendem as particularidades de uma biblioteca. Este trabalho trás, no capítulo 2, um estudo sobre o formato bibliográfico USMARC, este formato foi concebido no início dos anos 60 com o intuito de padronizar e permitir o intercâmbio de informações bibliográficas. No capítulo 3 são apresentadas as principais características da linguagem de marcação XML, o capítulo destaca também as principais diferenças entre XML e HTML. O capítulo 4 trata dos web services, inicialmente são apresentadas as 3 tecnologias de objetos distribuídos mais aceitas no mercado. Após a apresentação destas tecnologias este capítulo trata dos conceitos e tecnologias que compõem os web services. O capítulo 5 apresenta aspectos do sistema legado que compõem o cenário em que o web service será aplicado. O capítulo 6 trata da implementação do servidor e mostra como o cliente recebe os dados e interage com o módulo de inclusão para inserir uma obra no acervo. 1.2. Definição do problema A primeira impressão que um observador casual teria ao observar as rotinas do cadastro de um acervo, seria de que o grande problema do processo está na digitação das informações. Mas é a obtenção destas informações que consome mais recursos da equipe técnica de uma biblioteca. A equipe técnica de uma biblioteca torna-se extremamente mais produtiva quando tem acesso a alguma rede, ou acervo on line, que compartilhe informações bibliográficas. Redes com este propósito já existem, no entanto, seu enfoque principal é o pesquisador e não a troca de dados entre os sistemas das bibliotecas. O ideal seria o uso de uma ferramenta que permitisse a inclusão do dado pesquisado automaticamente na base de dados da biblioteca que está fazendo a pesquisa, evitando assim a 3 necessidade de um funcionário re-digitar a informação pesquisada no seu acervo. Isto tornaria o processo mais ágil, menos oneroso e reduziria os problemas relacionados a erros de digitação e a falta de padronização dos dados. 1.3. Justificativa Quando uma biblioteca informatiza seu acervo, sua preocupação principal é o cadastro das suas obras. Nesta fase, surgem várias ferramentas voltadas ao cadastro e às transações de empréstimos e consultas do acervo. Quando o primeiro desafio é vencido e o acervo já usufrui destes benefícios, surge a necessidade da troca de dados com outras bibliotecas, para isto faz-se necessário o uso de ferramentas que agrupam e disponibilizam estas informações. Estas duas etapas se repetem em quase todos os processos de informatização de acervos. Sem dúvida seria bem mais eficiente e menos oneroso se ambas as etapas fossem tratadas juntas desde o início do cadastro. Isto possibilitaria que o cadastro se valesse dos dados já cadastrados por outras instituições, evitando os problemas futuros que surgem com a falta de padronização entre os dados de diferentes bibliotecas. 1.4. Objetivos 1.4.1. Objetivo geral Objetiva-se neste trabalho viabilizar a criação de uma rede de dados bibliográficos que vá além da disponibilização dos dados do acervo para uma simples consulta. Pretende-se que os dados compartilhados através da rede sejam também utilizados na entrada de dados do acervo, dispensando a digitação e evitando inconsistências. 1.4.2. Objetivos específicos Os objetivos específicos deste trabalho são: a) Estudar tecnologias que permitam troca de dados independente da plataforma e da linguagem de programação adotada pelas partes envolvidas. 4 b) Adicionar ao módulo de cadastro de obras, uma maneira mais ágil e padronizada de inclusão de dados. c) Propor um mecanismo de intercâmbio de dados que contemple totalmente a estrutura de dados do acervo, permitindo a inserção direta dos dados em cada um dos nós da rede. d) Reduzir os recursos disponibilizados pelo setor técnico da biblioteca na classificação das obras. 1.5. Metodologia O trabalho foi desenvolvido observando as seguintes etapas: a) Levantamento bibliográfico – Partindo do estudo das tecnologias de objetos distribuídos existentes, como CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) e Java RMI (Remote Method Invocation), chegando aos web services. Estudo de linguagens de marcação, como SGML(Standard Generalized Markup Language) e XML (Extensible Markup Language). Estudo do padrão USMARC (Machine Readable Cataloging). b) Especificação – Cada participante da rede poderá ser tanto um cliente como um servidor. A base de dados estará em um Servidor SQL Interbase/FireBird. c) Implementação – A implementação foi feita em Delphi/Kylix visando seu acesso nativo ao Servidor Interbase/FireBird e o suporte a tecnologia de web services. d) Testes – Os testes serão realizados na Biblioteca Universitária da UNIPLAC e na empresa Método Informática. e) Validação – Caso a rede aumente a produtividade e a qualidade dos serviços oferecidos pelos setores técnicos das bibliotecas envolvidas o sistema estará validado. 2. O FORMATO BIBLIOGRÁFICO USMARC Neste capítulo serão apresentas algumas das principais características do USMARC, ele é um formato bibliográfico largamente utilizado por bibliotecas do mundo todo. Por ser aceito universalmente, ele é ideal para a troca de informações entre sistemas distintos. 2.1. Histórico O formato bibliográfico USMARC – Machine Readable Cataloging, desenvolvido pela US Library of Congress (Biblioteca do Congresso Norte Americano), padroniza a representação descritiva automatizada dos acervos bibliográficos. Os campos de dados no USMARC são definidos para identificar os elementos de um registro bibliográfico como título, edição, assunto, etc., de modo a serem manipulados por computadores. Um registro USMARC, possui todas as informações de uma ficha catalográfica, além de outras destinadas ao processamento do registro na máquina. (FERREIRA [199-], p. 4). A Library of Congress, no princípio dos anos 60, foi a primeira instituição a se preocupar com a padronização e o intercâmbio de informação bibliográfica, tendo instituído inicialmente um programa de intercâmbio de fichas, e posteriormente integrado as facilidades da automação aos trabalhos de representação descritiva. Nascia então um projeto piloto denominado MARC (Machine Readable Cataloging) que iniciou a padronização conhecida como formato MARC de intercâmbio de registros bibliográficos em meio magnético. Esse formato às vezes chamado de USMARC ou LCMARC, tornou-se mundialmente conhecido apenas como padão USMARC. (FERREIRA [199-], p. 4). 6 2.2. Elementos de um registro MARC Um registro USMARC é composto por três elementos principais: líder, diretório e campos variáveis. 2.2.1. Líder Armazena informações necessárias ao processamento do registro. Contém códigos ou números identificados pela posição relativa do caracter. O líder possui o tamanho de 24 (00-23) caracteres e é o primeiro campo de um registro USMARC. 2.2.2. Diretório Um índice gerado por computador. Uma série de entradas que contém a localização e o tamanho de cada etiqueta (CAMPO) dentro de um registro bibliográfico. Cada notação possui 12 caracteres. No diretório, as notações para campos variáveis, aparecem primeiro, seguidas pelas etiquetas em ordem crescente. Em seguida entram os campos de dados variáveis, em ordem crescente, de acordo com o primeiro caracter da etiqueta. A seqüência de armazenamento dos campos de dados variáveis não corresponde necessariamente à ordem das entradas correspondentes no diretório. Campos duplicados são diferenciados apenas pela localização dos respectivos campos dentro do registro. O diretório termina com um caracter finalizador (ASCII 30). (FERREIRA [199-], p. 9). 2.2.3. Campos variáveis O conteúdo propriamente dito é armazenado em campos variáveis, os quais são identificados por tags compostas por três algarismos. Cada campo termina com um caracter delimitador de campo. O último campo variável num registro termina com um caracter delimitador de campo e um caracter delimitador de registro (ASCII 29). 2.3. Exemplo de registro USMARC O formato USMARC oferece 999 campos, que em muitos casos podem ser divididos em vários outros sub campos. Para exemplificar o padrão segue a baixo a figura 1, com o exemplo de uma obra no formato de ficha catalográfica e na figura 2 a 7 mesma obra no formato USMARC. FIGURA 1 - Obra no formato de ficha catalográfica (Fonte: BU1 da University of Delaware Library) FIGURA 2 - Obra no formato USMARC (Fonte: BU da University of Delaware Library) 1 BU – Biblioteca Universitária. 8 2.4. Conclusão Neste capítulo viu-se que o formato USMARC contempla vários aspectos referentes a padronização e ao intercâmbio de dados. Este padrão permite a catalogação desde simples obras literárias até obras cinematográficas com campos específicos para elenco e direção por exemplo. Esta abrangência do padrão, ao mesmo tempo é uma vantagem, pois, permite que virtualmente qualquer obra seja catalogada, e uma desvantagem, pois, torna o padrão excessivamente extenso e complexo. 3. XML - EXTENSIBLE MARKUP LANGUAGE Neste capítulo serão abordadas as principais características da linguagem de marcação XML e os motivos que levaram este padrão a ser largamente adotado para o intercâmbio de informações entre sistemas. Os web services, por exemplo, usam XML não só para a troca de mensagens, mas também para a descrição dos serviços oferecidos. Os acervos bibliográficos são especialmente agraciados por este padrão, pois, muitas das diretrizes que o regem, vão ao encontro das necessidades de armazenamento de um acervo. 3.1. Histórico da XML Armazenar e representar os dados de documentos, artigos e produções em geral é uma preocupação antiga. No final da década de 1960, a GCA (Graphic Communications Association) criou o projeto "GenCode". O projeto baseava-se no conceito de "codificação genérica", que se valia de tags descritivas para identificar as diferentes partes de um documento. Pouco depois, já na década de 1970, Charles Goldfard, Edward Mosher e Raymond Lorie projetaram, nos laboratórios da IBM, a GML (Generalized Markup Language). Ela surgiu com a missão de permitir que vários sub-sistemas pudessem pesquisar, editar e formatar os dados escritos nesta linguagem. A tecnologia foi validada pela própria IBM que passou a usar a linguagem como padrão para seus manuais e documentos impressos. (RAY 2001, p. 10). 3.1.1. O Surgimento da SGML Com o sucesso das linguagens GenCode e GML, um comitê especial da ANSI (American National Standards Institute), montou uma equipe com membros da 10 IBM e da GCA para desenvolver uma linguagem padrão de descrição de textos. Em 1983, a equipe publicou o SGML (Standard Generalized Markup Language), que foi rapidamente adotado como padrão por vários órgãos do governo Norte Americano, entre eles a Receita Federal. Em 1986 o padrão já tinha tomado conta da europa e a ISO (International Organization for Standardization) ratificou o padrão SGML. 3.1.2. O Surgimento do HTML A SGML cumpre a sua tarefa, é flexível o suficiente para representar todo o tipo de informação, mas ela é tão abrangente que, segundo RAY (2001, p. 11), "Ela é tão flexível que o software criado para processá-la é por demais complexo e caro, sendo sua utilidade limitada as grandes organizações". No início da década de 1990, Tim Berners-Lee e Anders Berglund desenvolveram, no laboratório europeu de física da partícula, o que conhecemos por HTML (Hypertext Markup Language), que se trata de uma versão compacta e eficiente da SGML para hipertextos. O padrão criado pelos dois possibilitou um meio tão simples de criar e editar documentos que literalmente dominou o mundo e mostrou a força das linguagens de marcação. (RAY, 2001, p. 11). Segundo FURGERI (2001, p. 34), "Apesar de a HTML ser chamada linguagem de programação pela maioria dos profissionais envolvidos na área, ela é apenas uma linguagem de marcação de texto que permite especificar como um texto será visualizadona tela do browser, definido os detalhes do documento com a utilização dos marcadores (tags)". 3.2. O Nascimento da XML Em nome da simplicidade o HTML abriu mão de muitos conceitos da codificação genérica. Ainda na década de 1990, o W3C (Word Wide Web Consortium), descontente com o HTML partiu para a criação de uma nova linguagem, o XML que combinaria a flexibilidade e robustez do SGML com a simplicidade do 11 HTML. (RAY, 2001, p. 11). 3.2.1. Características da XML As regras básicas que foram estabelecidas pelo comitê para a criação da XML, segundo FURGERI (2001, p. 42), foram as seguintes: • Criar uma linguagem simples, que possibilite a rápida construção de documentos para a implementação na web; • Fornecer suporte à criação de aplicações compatíveis com a abordagem da HTML; • Possibilitar o desenvolvimento de uma grande variedade de aplicativos, aproveitando-se de seus recursos; • Fornecer um mecanismo de apresentação genérico e poderoso, permitindo ao desenvolvedor criar a forma de apresentação que mais se adapte as suas necessidades; • Fornecer suporte para a criação de marcadores personalizados, definidos pelo desenvolvedor do documento web; • Permitir a criação de documentos que pudessem ser validados, isto é, que existisse uma forma de verificar a estrutura do documento, verificando se seus elementos eram válidos, da mesma forma que ocorria com a SGML; • Fornecer suporte para a criação de hiperlinks que fossem compatíveis com a especificação de endereços URL, de modo a criar ligações entre documentos; • Fornecer um mecanismo de folha de estilo genérico e poderoso, que possibilitase não apenas a formatação de documentos, como também sua manipulação. 3.2.2. Diferenças entre XML e HTML O HTML foi concebido para representar informações, já o XML além de representar, procura dar significado a estas informações. Para melhor exemplificar esta diferença, seguem abaixo dois exemplos, o primeiro na figura 3 apresentado em HTML e o segundo na figura 4 em XML, ambos com o objetivo de prover informações sobre um microcomputador. (FURGERI 2001, p. 45). 12 Em HTML: FIGURA 3 - Exemplo de representação de informações em HTML (Fonte: FURGERI 2001, p. 45) Em XML: FIGURA 4 - Exemplo de representação de informações em XML (Fonte: FURGERI 2001, p. 45) Analisando estes exemplos, percebem-se muitas semelhanças entre as linguagens, ambas são documentos de texto puro e ambas usam tags para manipular as informações. Porém a XML, destaca FURGERI (2001, p. 45), "torna o documento mais 'inteligente', criando uma estrutura que demonstra claramente qual o significado das informações". 3.3. XML em acervos bibliográficos A linguagem XML possui tantas afinidades com o estabelecimento de padrões, que praticamente todos os padrões usados pela biblioteconomia, como o USMARC, o Dublin Core e outros, possuem versões XML. A tabela 1 mostra uma estrutura baseada no formato Dublin Core, adotado pelas IES2 da ACAFE para integrar seus acervos bibliográficos, a figura 5 por sua vez é um documento XML baseado neste formato. 2 Instituição de ensino superior 13 Tag Dados Ocorrência <biblioteca> Root 1 <id_ies></id_ies> Código Identificador da IES 1 <obra> 1 .. n <titulo></titulo> Título : Sub Título 1 <autor Tipo=”xx”></autor> Sobre nome, Nome e Tipo (Principal, Secundário) 1 .. n <assunto></assunto> Assunto 1 .. n <colaborador></colaborador> Sobre nome, Nome 0 .. n <editor></editor> Local: Editor 0 .. n <data></data> Data Ano ou Mês/Ano 1 <tipo></tipo> Falta padronizar! 1 <formato></formato> Nº Pag + detalhes 0 .. 1 <identificador></identificador> ISBN/ISSN 0 .. 1 <idioma></idioma> Segundo Tabela a definida pelos Bibliotecários 0 .. n <edicao></edicao> Edição da Obra, caso exista 0 .. 1 <id_bibliodata><id_bibliodata> Id obra no Bibliodata 0 .. 1 <id_campus id_legado=”xx”></id_campus> Identificador do campus com o identificador da obra na Biblioteca Local 1 .. n <cod_mov></cod_mov> Tipo de Movimento (Inclusão, alteração, exclusão) 1 </obra> <biblioteca> TABELA 1 – Estrutura XML baseada no formato Dublin Core (Fonte: Comissão do SINBAC3) FIGURA 5 - Documento XML representando uma obra do acervo (Fonte: BU da Universidade do Planalto Catarinense) 3 Sistema de Integracao das Bibliotecas da ACAFE 14 3.4. Conclusão A linguagem de marcação XML veio para suprir a forte demanda de vários setores de informática por uma solução simples e eficiente para representar, manipular e trocar dados, seja em uma rede local, seja em pontos geograficamente distantes. Ela vem se tornando a base de vários protocolos que estão sendo desenvolvidos totalmente escritos em XML, os web services são um grande exemplo disto, sendo que todas as tecnologias que o compõem são escritas em XML. 4. WEB SERVICES Neste capítulo serão apresentadas as principais características e conceitos relacionados a web services, destacando os motivos que estão levando este framework à ser amplamente aceito pela comunidade de desenvolvedores. Antes porém serão apresentados aspectos relativos as principais tecnologias de objetos distribuídos, das quais os web services herdaram muitas características e funcionalidades. 4.1. Objetos Distribuídos As redes de computadores estão em franca expansão e desenvolvimento. Em decorrência do seu constante crescimento surgem novas tecnologias que se propõe a suprir suas necessidades. Em um primeiro momento houve uma grande adoção ao que se chamou de arquitetura de duas camadas, ou cliente-servidor, segundo CAMELO (2002, p. 2), "Esta tecnologia disponibilizou flexibilidade para o desenvolvimento de sistemas centralizados." A busca por melhor desempenho e redução de custos, aliada a exigência de uma maior escalabilidade em ambientes heterogêneos e maior tolerância a falhas, resultou no surgimento de uma terceira camada, denominada camada de negócios, que atua entre a interface cliente e o servidor de dados. Este novo paradigma, conhecido como middleware, possibilitou distribuir o processamento entre os componentes do sistema. Com o objetivo de possibilitar que clientes em diferentes plataformas possam executar uma mesma aplicação, surgiram middlewares baseados em RPC (Remote Procedure Call). Dentre os que mais se destacaram no mercado estão: CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) e Java RMI (Remote Method Invocation). Cada um com vantagens e 16 desvantagens que serão brevemente tratadas a seguir. 4.1.1. CORBA O CORBA, sigla de Common Object Request Broker Architecture foi desenvolvido pela OMG (Object Management Group), com o objetivo de propiciar um ambiente de desenvolvimento independente de plataforma e linguagem de programação, utilizando técnicas de programação orientada a objetos em redes heterogêneas. Segundo CAMELO (2002, p. 3), esta independência é possível graças ao alto nível de abstração conseguido através de um arquivo chamado IDL (Interface Definition Language), responsável pela definição das interfaces disponíveis aos objetos. Este arquivo possui o mapeamento dos métodos implementados no servidor, em uma linguagem específica. Os responsáveis pela comunicação entre os objetos na rede são os ORBs, (Object Request Brokers). Eles permitem a requisição e execução de métodos em objetos espalhados pela rede. A flexibilidade oferecida pelo CORBA implica em algumas restrições. Para garantir que aplicações em qualquer linguagem sejam compatíveis, os parâmetros a serem trocados pelas mensagens, devem ser somente de tipos primitivos, como inteiros, float, caracter e booleano. Outra desvantagem está no fato de que o ORB, necessário para a comunicação entre os objetos,consiste em uma camada a mais a ser instalada no cliente. 4.1.2. Java RMI A tecnologia Java Remote Method Invocation, é a tecnologia da Sun para a comunicação de objetos distribuídos. Segundo ALBUQUERQUE (2001, p. 360), "Os programas RMI apresentam uma arquitetura cliente-servidor em que os clientes invocam métodos que atuam sobre objetos nos servidores. Tanto os clientes RMI quanto os servidores RMI são codificados na linguagem Java. O RMI possui o serviço Registry, que tem como objetivo de identificar o objeto remoto associado ao método desejado. O Registry desempenha para o RMI a 17 função que o ORB desempenha para o CORBA A principal vantagem do Java RMI sobre o CORBA é a possibilidade de passagem de parâmetros complexos entre as requisições, ele permite, por exemplo, que uma imagem seja retornada por um método. Sua principal desvantagem é não ser independente de linguagem de programação, o cliente e o servidor obrigatoriamente devem ser escritos em Java. 4.1.3. DCOM DCOM ou Distributed Component Object Model, é a tecnologia da Microsoft para objetos distribuídos. O DCOM é na verdade a tecnologia COM, já usada nas plataformas Microsoft, acrescida da possibilidade de estar distribuída em diferentes pontos da rede. O protocolo utilizado para a comunicação entre os objetos é o ORPC, Object Remote Procedure Call. Este protocolo se vale do ping para manter contato com os objetos ativos na rede. (CAMELO 2002, p. 3) 4.1.4. Considerações sobre as tecnologias Tanto o CORBA, como o Java RMI e o DCOM, são baseados em RPC e possuem muitas características em comum. Todos criam stubs e skeletons e procuram manter a mesma nomenclatura. Ambas disponibilizam interfaces escritas em uma linguagem que permite a clientes e servidores trocarem informações. Além do que todos contam com algum mecanismo para encontrar seus objetos na rede. As três tecnologias são independentes de plataforma, porém, o Java RMI não é independente de linguagem de programação, diferente das outras duas tecnologias, para fazer uso de Java RMI, os servidores e os clientes devem ser desenvolvidos em Java. 4.2. Web Services Os web services, conforme definição da W3C, são sistemas de software identificados por uma URI (Universal Resource Identifier), que definem, publicam e descrevem suas interfaces e ligações usando XML. Um service é um componente capaz de executar uma determinada tarefa. Entende-se por componente um objeto de 18 software que encapsula certa funcionalidade, ou um conjunto de funcionalidades e é capaz de interagir com outros objetos. Os web services, possuem muitas características das tecnologias de objetos distribuídos já existentes, eles são independentes de linguagem de programação, como o CORBA e o DCOM e eles suportam a passagem de parâmetros complexos, como o Java RMI, e também são independentes de plataforma. Um dos motivos que encoraja o uso de web services é o fato de eles serem compostos exclusivamente por tecnologias padronizadas e abertas, a saber: UDDI, WSDL, SOAP e XML. Outra vantagem dos web services sobre as outras tecnologias é o fato deles terem sido concebidos para uso na Internet, eles utilizam o HTTP como protocolo de transporte e a porta 80. Isto os torna extremamente simples e disponíveis em qualquer lugar que tenha acesso a Internet, diferente das outras tecnologias que exigem uma camada de software a mais no cliente. Um web service é composto por três componentes básicos: • service provider: tem como função publicar os serviços para que um service broker possa encontrá-los. • service broker: responsável por encontrar o provedor de um determinado serviço, que por ventura um cliente esteja procurando. • requester: é o cliente propriamente dito, pois, solicita um serviço ao service broker, que encontra um service provider, que tenha o serviço disponível. (MENDES 2002, p. 29) 4.2.1. Tecnologias que compõem os web services Os web services são compostos basicamente por quatro tecnologias, todas baseadas em XML, que podem ser tratadas como quatro camadas pelas quais são trocadas as mensagens. São elas: o UDDI, o WSDL, o SOAP e o próprio XML. 4.2.1.1. UDDI – Universal Distribution, Discovery and Interoperability. Segundo DE LUCCA (2003, p. 32), pode-se comparar a UDDI com as páginas amarelas de um catálogo telefônico. Aqueles que desejarem oferecer serviços 19 podem registrar suas informações de contato. Ainda segundo ele, a estrutura UDDI define um modelo de dados em XML e também as interfaces de programação SOAP para registrar e descobrir informações. O UDDI funciona portanto, como um serviço de diretório, onde podem ser encontradas informações sobre os serviços disponíveis naquele UDDI server. 4.2.1.2. WSDL – Web Services Description Language. A WSDL pode ser considerada a IDL dos web services. E é em WSDL que as interfaces são descritas para serem interpretadas pelos clientes, que por ventura, queiram fazer uso de um determinado serviço. A WSDL é responsável por mapear, por exemplo, uma string pascal de um web service feito em Delphi para o tipo string suportado pela XML. Interpretando esta mesma definição WSDL um cliente Visual Basic, por exemplo, ao receber este parâmetro, mapearia a string XML para uma string terminada em nulo, sem a necessidade de saber que o servidor foi implementado em Delphi e muito menos que a string que ele esta recebendo no formato nativo da sua linguagem, era originalmente uma string pascal. 4.2.1.3. SOAP – Simple Object Access Protocol. O SOAP é o protocolo responsável pela troca de mensagens entre os servidores e clientes de um web services. Segundo DE LUCCA , (2003, p. 29), o protocolo SOAP é, basicamente, um modelo de comunicação que tem como função assegurar que uma mensagem coerente seja transferida de um remetente para o destinatário, incluindo ou não intermediários que poderão processar parte da mensagem ou acrescentar dados a mesma. Uma mensagem SOAP é composta basicamente por três elementos, um envelope, que contém um cabeçalho e o corpo da mensagem. A figura 6 é um exemplo de mensagem SOAP. 20 FIGURA 6 - Exemplo de mensagem SOAP (Fonte: http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.html#firstexample) A tag <env:Envelope> ... </env:Envelope> delimita o inicio e o fim da mensagem, contendo todos os elementos que a compõem. A tag <env:Header> ... </env:Header> exibe as informações de cabeçalho, no caso da figura 6, a prioridade e a data de expiração da mensagem. A tag <env:Body> ... </env:Body> traz os dados que estão sendo efetivamente transportados pela mensagem, no caso da figura 6, “Pick up Mary at school at 2pm”. 4.2.1.4. XML – Extensible Markup Language A linguagem XML é usada nos web services não só na troca de mensagem, mas também para definir e descrever os serviços disponibilizados. Todas as tecnologias que compõem os web services fazem uso da XML. Um ponto importante destacado por DE LUCCA (2003, p. 22), é o fato de que as tecnologias tradicionais de computação distribuída exigem um relacionamento de acoplamento muito mais restrito entre cliente e servidor e, portanto, não podem utilizar-se da web e de suas características de abertura (sem a adição de camadas extras em ambos os lados da comunicação). Por outro lado, os web services adotam o modelo público e aberto da web, e por isso é possível publicar um ponto de entrada sem que exista um cliente já definido para aquele ponto de entrada. Esta mudança de paradigma defende que os clientes possam desenvolver e 21 integrar-se mais tarde e que isto apresenta vantagens na busca pela solução do antigo problema de integração entre empresas. 4.3. Conclusão Os web services são a evolução natural das tecnologias de objetos distribuídosjá existentes. Eles tem a vantagem de terem sido concebidos para suprir as necessidades não atendidas por estas tecnologias. Os web services preservam as características esperadas em uma tecnologia de objetos distribuídos, como independência de plataforma e de linguagem de programação, e ainda adicionaram flexibilidade e simplicidade ao conectar seus objetos por meio do protocolo HTTP, presente em praticamente todos os ambientes de rede. 5. ANÁLISE DA REDE DE ACERVOS BIBLIOGRÁFICOS Neste capítulo serão estabelecidos os requisitos necessários para garantir que a rede de acervos bibliográficos baseada em web services seja funcional e viável. Serão analisados aspectos referentes a possibilidade do uso do web service, não só pelo sistema de gestão de bibliotecas já existente, como também, de uma forma genérica, por qualquer outro aplicativo que suporte a tecnologia de web services e queira dispor destes serviços como cliente do web service. 5.1. Base de Dados A rede de intercâmbio de dados apresentada neste trabalho foi projetada para que um cliente qualquer possa fazer uma solicitação de uma determinada obra ao web service, e este por sua vez, retorne os dados desta obra ao solicitante. Como o web service, que retorna estes dados, foi implementado sobre um sistema de gestão de bibliotecas já existente e que está rodando na Biblioteca Universitária da UNIPLAC, Biblioteca Pública Municipal de Lages, Biblioteca Pública Municipal de Florianópolis e na empresa Método Informática, nenhuma tabela foi acrescentada no banco de dados com o fim específico de prover o serviço. O referido sistema é composto por várias tabelas, que podem ser divididas em quatro grandes grupos: • cadastro de obras; • movimentação do acervo (empréstimos, reservas etc.); • estatísticas; • controle de usuários; A figura 7 mostra as principais tabelas que armazenam os dados relacionados ao cadastro de uma obra. 23 FIGURA 7 – Tabelas referentes ao cadastro de obras. O web service fará uso somente das tabelas que têm alguma relação com o cadastro das obras. A figura 7 ilustra as tabelas que compõem este grupo. Em amarelo está a tabela "ACERVO" que armazena as obras propriamente ditas. Em cinza escuro estão as tabelas que tem vínculo direto com a tabela acervo, por exemplo, na tabela acervo existe um campo chamado "ID_TIPO_DOCUMENTO", como uma obra só pode ser de um tipo (livro, folheto etc.), este campo contém uma chave estrangeira apontando para a tabela "TIPO_DOCUMENTO" em uma relação de N para um, ou seja, várias obras podem ser do tipo livro, mas uma obra só pode ser de um tipo. Em cinza claro estão as tabelas que permitem mais de uma ocorrência para uma mesma obra, é o caso da tabela "TITULO_SECUNDARIO", ela permite que uma obra possua vários títulos secundários em uma relação de um para N. 24 5.2. A Interação do web service com a base de dados Para oferecer um serviço que disponibilize todos os dados referentes a uma obra, o web service precisa acessar um grande número de tabelas. Como o sistema existente foi implementado baseado no paradigma de programação orientada a objetos, e as funcionalidades providas pelo web service já eram, de uma maneira ou de outra, contempladas pelas classes existentes, o web service irá dispor de uma classe, descendente de TRemotable4 que interagirá com as demais classes do sistema e será responsável pela aquisição dos dados oferecidos pelos serviços do web service. 5.3. Classes do sistema legado FIGURA 8 – Classes do sistema legado. 4 Classe base do Delphi usada para passar e receber parâmetros em web services. 25 O sistema em uso nas bibliotecas possui uma série de classes, ilustradas na figura 8, que são responsáveis pela manipulação dos informações na base de dados. Todas as classes são descendentes da classe eb_base, que é a responsável por inserir, alterar, deletar e buscar registros no SGDB. Estas classes possibilitam que o web service, sempre que necessitar, acesse os dados referentes a um autor, uma editora ou qualquer informação do sistema, simplesmente usando as funcionalidades providas por uma das classes já existentes, ao invés de fazer um acesso direto aos dados. 5.4. Módulo de inclusão de dados Como o objetivo principal deste trabalho é prover um mecanismo que possibilite a equipe técnica de um acervo incluir uma obra com mais agilidade e de uma forma mais padronizada, é no módulo de inclusão de dados que residirá o cliente do web service. 5.4.1. Dificuldades na inclusão dos dados O fato da base de dados do acervo ser bastante normalizada, implica em uma série de cuidados para possibilitar a inclusão de uma obra. Por exemplo, para incluir uma obra cujo autor seja "TANENBAUM, Andrew S.", antes de sugerir este autor é necessário verificar se ele já esta cadastrado na base local, caso esteja, é necessário descobrir qual o seu código (ID) na tabela autores da base local, caso não esteja cadastrado o módulo de inclusão deve perguntar ao digitador se ele deseja incluir o autor na tabela de autores. Isto irá ocorrer com todos os campos que ao invés de gravar o seu conteúdo diretamente na tabela acervo, fazem uma referência (chave estrangeira) a outra tabela. 5.5. Conclusão O trabalho de criação do web service foi particularmente facilitado pelo fato do sistema já existente ter sido baseado desde suas primeiras versões (em 1999) no paradigma de programação orientado a objetos. Isto permitiu que todo trabalho desenvolvido fosse canalizado no transporte dos dados, pois, a recuperação e inclusão dos mesmos já era provida pelas classes já existentes no sistema. 6. IMPLEMENTAÇÃO Neste capítulo serão apresentadas as ferramentas utilizadas na construção da rede de intercâmbio de dados para acervos bibliográficos e os principais aspectos da implementação e configuração do sistema. 6.1. Ferramentas utilizadas Dentre as ferramentas utilizadas para a implementação, cabe citar o SGDB e a ferramenta de desenvolvimento de aplicação. 6.1.1. Firebird O Firebird é o SGDB utilizado pelo sistema de gestão já existente e em uso pelas bibliotecas já citadas. A adoção de um SGDB robusto se faz necessária por existirem no sistema tabelas volumosas, algumas com aproximadamente meio milhão de registros e outras que possuem poucos registros, porém, estes registros são compostos de campos que comportam uma grande quantidade de informações. 6.1.2. Delphi O Delphi foi escolhido por suportar todas as tecnologias necessárias para o desenvolvimento do trabalho, ele permite acesso nativo ao SGDB Firebird, permite a criação de CGIs, suporta XML e todas as tecnologias relacionadas a web services. Ou seja, com ele é possivel usar uma única ferramenta para criar a aplicação desktop, a parte web, e o web service do sistema. 6.2. Web Service Para dar uma idéia geral do funcionamento do web service, a figura 9 ilustra 27 a seguinte situação: a aplicação cliente, na empresa Método Informática, dispara uma requisição, solicitando ao web service, que se encontra na UNIPLAC, as informações sobre a obra 33979. O web service recebe a mensagem SOAP, busca os dados referentes a obra e retorna uma resposta ao cliente. FIGURA 9 – Troca de mensagens SOAP No exemplo acima, a aplicação cliente envia a mensagem SOAP ilustrada na figura 10 para solicitar o serviço desejado. FIGURA 10 – Requisição de serviço no formato SOAP A mensagem de requisição acima informa ao servidor web service que o cliente deseja acessar o serviço get_obra que se encontra na interface Iacervo, passando como parâmetro o número inteiro 33979. 28 O servidor recebe esta requisição, invoca o método get da classe teb_acervo, passando como parâmetro o ID da obra desejado, no caso 33979, e envia a respostatambém no formato SOAP ao cliente. A figura 11 representa um fragmento da resposta enviada pelo servidor, para tornar o exemplo mais legível, alguns dos parâmetros retornados foram omitidos, apenas os campos referentes ao ID da obra local, ISBN, e título foram preservados. A mensagem completa pode ser encontrada no apêndice 2. FIGURA 11 – Fragmento da resposta SOAP retornada pelo servidor Esta resposta é interpretada pelo cliente web service que deve converter os parâmetros recebidos no padrão XML para os tipos equivalentes na linguagem de programação em que foi desenvolvido. No caso do Delphi, tomando como exemplo o parâmetro “titulo”, a informação "Ensino didático da linguagem XML" recebida no formato xsd:string é convertida para o formato string pascal. Nas seções seguintes serão apresentados os componentes do Delphi que foram utilizados para implementar estas funcionalidades. 6.2.1. Servidor Quando é criado um web service no Delphi, deve-se escolher o tipo de aplicação web no qual o servidor será baseado (CGI, ISAPI etc.), no caso deste 29 trabalho foi usado CGI. Após definido o tipo de servidor o Delphi cria automaticamente um TWebModule com três componentes. Estes três componentes se encarregam de prover as funcionalidades básicas do servidor e estão representados na figura 12. FIGURA 12 – TWebModule do web service • THTTPSoapDispatcher: é o responsável por receber e enviar as mensagens. Ele interage com objeto especificado na sua propriedade Dispatcher, no nosso caso o HTTPSoapPascalInvoker1. • THTTPSoapPascalInvoker: ele interpreta a requisição SOAP vinda de um THTTPSoapDispatcher e executa a interface correspondente. • TWSDLHTMLPublish: é o responsável por publicar uma lista de documentos WSDL que descrevem o web service. Estes três componentes em conjunto tornam transparente para o desenvolvedor todas as transformações XML que se fazem necessárias para a implementação de um web service. Após a definição do servidor, o passo seguinte é criar as interfaces que estarão disponiveis aos clientes. 6.2.1.1. A interface Iacervo As interfaces dos web services, no Delphi, devem ser descendentes de IInvokable. Quando criamos uma interface chamada "acervo", por exemplo, o Delphi cria uma unit "acervoIntf" e uma unit "acervoImpl". Como os nomes sugerem a interface e a implementação ficam em unit's diferentes, como ocorre nas tecnologias tradicionais de objetos distribuídos. Nesta interface está definida a classe teb_ws_acervo, que será retornada como parâmetro ao solicitante do serviço com todos os dados de uma obra. Segue 30 abaixo um trecho desta classe e do método get que a compõe, a classe e o método get completos podem ser encontrados nos apêndices 3 e 4 respectivamentese. Ele recebe como parâmetro uma string representando o código (ID) da obra na base onde está situado o servidor web service, alimenta todas as propriedades da classe e retorna um valor booleano informando se a operação foi realizada com sucesso. teb_ws_acervo = class(TRemotable) private ... fid : string; feventos_secundarios : string; ... public function get(id_: string) : boolean; published property id : string read fid write fid; property id_operador : string read fid_operador write fid_operador; end; function teb_ws_acervo.get(id_: string):boolean; var acervo : teb_acervo; //classe que manipula os dados do acervo begin acervo := teb_acervo.criar; acervo.origem := 'ACERVO'; //define a tabela onde os dados estão acervo.get(id_); //busca os dados referentes a obra desejada //seta as propriedades //as linhas abaixo transferem o conteudo das propriedades da classe //teb_acervo para a classe teb_ws_acervo id := acervo.id; data_cadastro := acervo.data_cadastro; id_operador := acervo.id_operador; ... end; FIGURA 13 – Trecho da classe teb_ws_acervo Para viabilizar a implementação do web service foi concebida uma interface, chamada Iacervo, que disponibiliza quatro serviços, são eles: • get_obra: é o principal serviço oferecido pelo web service, este serviço recebe como parâmetro o código (ID) da obra desejada, instancia um objeto do tipo teb_ws_acervo, usa o método get para alimentar suas propriedades e retorna a própria classe como resposta do serviço. • download: recebe uma string com o caminho da imagem desejada, carrega o 31 arquivo em um TFileStream, ajusta o tamanho do array dinâmico de bytes, que será retornado como resposta do serviço, para o tamanho do arquivo e escreve o conteúdo do TFileStream no array. • busca_obras_por_autor: recebe o nome de uma autor como parâmetro de entrada, instância um objeto do tipo teb_acervo e executa o método get_xml_por_autor e retorna uma string XML como resposta ao serviço. • busca_obras_por_titulo: recebe um título como parâmetro de entrada, instância um objeto do tipo teb_acervo e executa o método get_xml_por_titulo e retorna uma string XML como resposta ao serviço. A WSDL completa da interface IAcervo pode ser encontrada no apêndice 1. 6.2.2. Cliente O cliente web service, representado da figura 14, foi adicionado ao módulo de inclusão de dados do acervo é composto por três partes principais. FIGURA 14 – Cliente web service Na parte superior da tela estão todos os web services disponíveis na rede de intercâmbio de dados, o operador deve selecionar qual biblioteca ele deseja solicitar a obra. Na parte central estão as opções de busca por título e por autor. O resultado da busca, que na verdade é uma string XML retornada pelo método 32 busca_obras_por_titulo ou pelo método busca_obras_por_autor, é apresentado na parte inferior da tela no formato HTML. Ao clicar sobre uma obra ou digitar seu código (ID), uma chamada ao serviço get_obra é realizada, este serviço retorna um objeto do tipo teb_ws_acervo com as informações referentes a obra. O módulo de inclusão de obras, representado na figura 15, alimenta as propriedades de um objeto do tipo teb_acervo com as propriedades vindas do objeto retornado pelo web service, após todas as propriedades serem alimentadas o objeto aguarda que o usuário confirme a inclusão da obra no acervo. FIGURA 15 – Módulo de inclusão de obras alimentado pelo web service Neste ponto o registro ainda está editável, sendo passível de alterações, se necessárias antes da confirmação da inclusão da obra. 6.3. Conclusão O web service permitiu a passagem por parâmetro de strings, booleanos, 33 imagens serializadas e classes inteiras. Um ponto a se destacar foi a transparência propiciada pela ferramenta Delphi nos aspectos referentes as transformações XML necessárias para tratar o envio e recebimento destes parâmetros. 7. CONSIDERAÇÕES FINAIS A rede de intercâmbio de dados para acervos bibliográficos foi concebida com o intuito de ser uma ferramenta para auxiliar o setor técnico de uma biblioteca em uma das suas tarefas mais morosas, o cadastro de uma nova obra no acervo. O grande diferencial desta rede para as já existentes foi a adoção de web services para interligar os acervos. Um desafio constante na manutenção de um acervo é a padronização das informações bibliográficas, a utilização de uma rede de intercâmbio de informações bibliográficas reduz dramaticamente as disparidades decorrentes de vícios de digitação, ou mesmo de posicionamentos divergentes entre os responsáveis pela catalogação das obras. Isto se agrava ainda mais quando várias bibliotecas estão envolvidas no processo, por mais que todas utilizem as mesmas diretrizes para cadastrar suas obras, fazer parte de uma rede implicará em algumas mudanças na formataçãodo acervo. O uso de uma única ferramenta de desenvolvimento para tratar de todos os aspectos relativos ao sistema resultou em uma grande produtividade no sistema como um todo, pois, os módulos desktop, web, e de web services puderam compartilhar das mesmas classes, isto possibilitou que para incluir uma obra, para responder a uma consulta web ou para executar um web service, uma mesma classe fosse usada. Um ponto a destacar na criação de web services usando o Delphi, foi a transparência propiciada pela ferramenta no que tange as transformações XML necessárias para a especificação, publicação e execução dos web services. A maior vantagem do uso de web services é sem dúvidas o fato desta tecnologia usar o protocolo HTTP na porta 80 para trocar mensagens, isto garante a tecnologia uma simplicidade que além de superar as limitações das tecnologias 35 tradicionais de objetos distribuídos, cria uma infinidade de novas perspectivas para as aplicações web. 7.1. Sugestões para trabalhos futuros A rede foi concebida para trocar informações sobre uma obra do acervo, uma característica atrativa seria a extensão desta funcionalidade para os cadastros simples da base, como o cadastro de autoria, de assuntos, de editora etc. Um aspecto importante no acervo, e que não foi contemplado pela rede, é a base de periódicos. Um periódico é constituído por diversos artigos, cada qual com seu resumo, palavras chaves e autores. A ampliação da rede para suportar este tipo de documento traria grandes benefícios ao sistema. REFERÊNCIAS BIBLIOGRÁFICAS ALBUQUERQUE, F. TCP/IP Internet: Programação de sistemas distribuídos HTML, Javascript e Java. São Paulo: Axcel Books, 2001. CAMELO, D. M. Web Service. Disciplina Web Service do curso de Especialização de Sistemas de informação e aplicações Web – CESF/FUCAPI. 2002. Disponível em: <http://www.dizai.com.br/dino/selfpromotion/arquivos/articles/WebServices.pdf>. Acessado em: 15 mar 2003. FERREIRA, M. M. Introdução aos formatos bibliográfico e de autoridade USMARC. São Paulo: Fundação Editora da UNESP, [199-]. 109 p. FURGERI, S. Ensino didático da linguagem XML: Aprenda a criar padrões e documentos inteligentes com a XML. São Paulo: Érica, 2001. 277 p. DE LUCCA, J. Integração de aplicativos com web services. In: ESCOLA DE INFORMÁTICA DA SBC - SANTA CATARINA, 11., 2003, Lages. Anais ... Lages: UNIPLAC/SBC, 2003. p. 1-40. MENDES, F. V. Web Services: Dos conceitos à implementação. Clube Delphi, Rio de Janeiro, RJ, ano III. ed. 27, p. 29-33, abr 2002. RAY, E. T. Aprendendo XML. Rio de Janeiro: Campus, 2001. 372 p. BIBLIOGRÁFICA COMPLEMENTAR HOLZNER, S. Desvendando XML. Rio de Janeiro: Campus, 2001. 858 p. MENDES, F. V. Web Services – Parte 2: Clientes CLX e Web. Clube Delphi, Rio de Janeiro, RJ, ano III. ed. 28, p. 35-38, mai 2002. MENDES, F. V. Web Services no Delphi 7: Novos padrões e ferramentas. Clube Delphi, Rio de Janeiro, RJ, ano III. ed. 33, p. 24-25, out 2002. MENDES, F. V. Arquivos em Web Services: transferência binária com SOAP. Clube Delphi, Rio de Janeiro, RJ, ano III. ed. 34, p. 20-24, nov 2002. PAULI, R. de B. Web Services com DataSnap: Intercâmbio de dados pela web com SOAP e XML. Clube Delphi, Rio de Janeiro, RJ, ano III. ed. 32, p. 12-15, set 2002. SONNINO, B. Google em Delphi e Kylix: Pesquisas na web usando Web Services. Clube Delphi, Rio de Janeiro, RJ, ano III. ed. 30, p. 27-32, jul 2002. APÊNDICES Apêndice 1 - WSDL da interface Iacervo. <?xml version="1.0" encoding="utf-8" ?> - <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xs="http://www.w3.org/2001/XMLSchema" name="Iacervoservice" targetNamespace="http://tempuri.org/" xmlns:tns="http://tempuri.org/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:ns1="urn:acervoIntf"> - <types> - <xs:schema targetNamespace="urn:acervoIntf" xmlns="urn:acervoIntf"> - <xs:complexType name="teb_ws_acervo"> - <xs:sequence> <xs:element name="id" type="xs:string" /> <xs:element name="id_operador" type="xs:string" /> <xs:element name="data_cadastro" type="xs:string" /> <xs:element name="operador" type="xs:string" /> <xs:element name="dua" type="xs:string" /> <xs:element name="classificacao" type="xs:string" /> <xs:element name="cutter" type="xs:string" /> <xs:element name="isbn_issn" type="xs:string" /> <xs:element name="tipo_documento" type="xs:string" /> <xs:element name="tipo_trabalho" type="xs:string" /> <xs:element name="tipo_entrada" type="xs:string" /> <xs:element name="regra" type="xs:string" /> <xs:element name="titulo" type="xs:string" /> <xs:element name="sub_titulo" type="xs:string" /> xxxix <xs:element name="titulo_original" type="xs:string" /> <xs:element name="titulo_equivalente" type="xs:string" /> <xs:element name="titulo_alternativo" type="xs:string" /> <xs:element name="titulo_serie" type="xs:string" /> <xs:element name="titulo_volume" type="xs:string" /> <xs:element name="titulo_tomo" type="xs:string" /> <xs:element name="area_de_conhecimento" type="xs:string" /> <xs:element name="assunto" type="xs:string" /> <xs:element name="volume" type="xs:string" /> <xs:element name="tomo" type="xs:string" /> <xs:element name="edicao" type="xs:string" /> <xs:element name="ano" type="xs:string" /> <xs:element name="local" type="xs:string" /> <xs:element name="editora" type="xs:string" /> <xs:element name="autor" type="xs:string" /> <xs:element name="colaborador" type="xs:string" /> <xs:element name="funcao" type="xs:string" /> <xs:element name="entidade" type="xs:string" /> <xs:element name="evento" type="xs:string" /> <xs:element name="idioma" type="xs:string" /> <xs:element name="paginacao" type="xs:string" /> <xs:element name="notas_gerais" type="xs:string" /> <xs:element name="notas_tese" type="xs:string" /> <xs:element name="notas_resumo" type="xs:string" /> <xs:element name="saida" type="xs:string" /> <xs:element name="saida_html" type="xs:string" /> <xs:element name="existe_imagem" type="xs:boolean" /> <xs:element name="caminho_imagem" type="xs:string" /> <xs:element name="imagem" type="xs:string" /> <xs:element name="titulos_secundarios" type="xs:string" /> <xs:element name="autores_secundarios" type="xs:string" /> <xs:element name="areas_secundarias" type="xs:string" /> xl <xs:element name="assuntos_secundarios" type="xs:string" /> <xs:element name="locais_secundarios" type="xs:string" /> <xs:element name="editoras_secundarias" type="xs:string" /> <xs:element name="colaboradores_secundarios" type="xs:string" /> <xs:element name="entidades_secundarias" type="xs:string" /> <xs:element name="eventos_secundarios" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:schema> </types> - <message name="get_obra0Request"> <part name="id_acervo" type="xs:int" /> </message> - <message name="get_obra0Response"> <part name="return" type="ns1:teb_ws_acervo" /> </message> - <message name="download1Request"> <part name="arquivo" type="xs:string" /> </message> - <message name="download1Response"> <part name="return" type="xs:base64Binary" /> </message> - <message name="busca_obras_por_autor2Request"> <part name="autor_" type="xs:string" /> </message> - <message name="busca_obras_por_autor2Response"> <part name="return" type="xs:string" /> </message> - <message name="busca_obras_por_titulo3Request"> <part name="titulo_" type="xs:string" /> </message> - <message name="busca_obras_por_titulo3Response"> <part name="return" type="xs:string" /> </message> - <portType name="Iacervo"> - <operation name="get_obra"><input message="tns:get_obra0Request" /> <output message="tns:get_obra0Response" /> </operation> - <operation name="download"> <input message="tns:download1Request" /> <output message="tns:download1Response" /> </operation> xli - <operation name="busca_obras_por_autor"> <input message="tns:busca_obras_por_autor2Request" /> <output message="tns:busca_obras_por_autor2Response" /> </operation> - <operation name="busca_obras_por_titulo"> <input message="tns:busca_obras_por_titulo3Request" /> <output message="tns:busca_obras_por_titulo3Response" /> </operation> </portType> - <binding name="Iacervobinding" type="tns:Iacervo"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> - <operation name="get_obra"> <soap:operation soapAction="urn:acervoIntf- Iacervo#get_obra" style="rpc" /> - <input message="tns:get_obra0Request"> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/en coding/" namespace="urn:acervoIntf-Iacervo" /> </input> - <output message="tns:get_obra0Response"> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/en coding/" namespace="urn:acervoIntf-Iacervo" /> </output> </operation> - <operation name="download"> <soap:operation soapAction="urn:acervoIntf- Iacervo#download" style="rpc" /> - <input message="tns:download1Request"> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/en coding/" namespace="urn:acervoIntf-Iacervo" /> </input> - <output message="tns:download1Response"> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/en coding/" namespace="urn:acervoIntf-Iacervo" /> </output> </operation> - <operation name="busca_obras_por_autor"> <soap:operation soapAction="urn:acervoIntf- Iacervo#busca_obras_por_autor" style="rpc" /> - <input message="tns:busca_obras_por_autor2Request"> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/en xlii coding/" namespace="urn:acervoIntf-Iacervo" /> </input> - <output message="tns:busca_obras_por_autor2Response"> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/en coding/" namespace="urn:acervoIntf-Iacervo" /> </output> </operation> - <operation name="busca_obras_por_titulo"> <soap:operation soapAction="urn:acervoIntf- Iacervo#busca_obras_por_titulo" style="rpc" /> - <input message="tns:busca_obras_por_titulo3Request"> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/en coding/" namespace="urn:acervoIntf-Iacervo" /> </input> - <output message="tns:busca_obras_por_titulo3Response"> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/en coding/" namespace="urn:acervoIntf-Iacervo" /> </output> </operation> </binding> - <service name="Iacervoservice"> - <port name="IacervoPort" binding="tns:Iacervobinding"> <soap:address location="http://200.135.4.11/cgi/enio/ws/ws.exe/soap /Iacervo" /> </port> </service> </definitions> Apêndice 2 - Resposta do servidor no formato SOAP. <?xml version="1.0" ?> - <SOAP-ENV:Envelope xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"> - <SOAP-ENV:Body SOAP- ENC:encodingStyle="http://schemas.xmlsoap.org/soap/envelope/ "> - <NS1:get_obraResponse xmlns:NS1="urn:acervoIntf-Iacervo" xmlns:NS2="urn:acervoIntf"> - <NS2:teb_ws_acervo id="1" xsi:type="NS2:teb_ws_acervo "> <id xsi:type="xsd:string">33979</id> <id_operador xsi:type="xsd:string">5</id_operador> <data_cadastro xsi:type="xsd:string">18/02/2003 10:51:39</data_cadastro> <operador xsi:type="xsd:string">rod</operador> <dua xsi:type="xsd:string">18/02/2003 10:53:29</dua> <classificacao xsi:type="xsd:string">005.133</classificacao> <cutter xsi:type="xsd:string">F983e</cutter> <isbn_issn xsi:type="xsd:string">857194797- x</isbn_issn> <tipo_documento xsi:type="xsd:string">Livro [J]</tipo_documento> <tipo_trabalho xsi:type="xsd:string">[]</tipo_trabalho> <tipo_entrada xsi:type="xsd:string">por autor [A]</tipo_entrada> <regra xsi:type="xsd:string">"Localização: " %B% #classificacao# " " #cutter# %B% " [" #id# "]" " ["#tipo_documento# "]" %E% #autor# #autor_secundario_1# #autor_secundario_2# ". " %B% #titulo# %B% #sub_titulo# ". "#volume# " " #edicao# " " #local# #editora##local_secundario_1##editora_secundaria_1##l ocal_secundario_2##editora_secundaria_2##local_secund ario_3##editora_secundaria_3# ", "#ano# ". " #paginacao# " [" #qtd_exemplares# " exemplar(es)]"</regra> <titulo xsi:type="xsd:string">Ensino didático da linguagem XML</titulo> <sub_titulo xsi:type="xsd:string">: Aprenda a criar padrões e documentos inteligentes com a 44 XML</sub_titulo> <titulo_original xsi:type="xsd:string" /> <titulo_equivalente xsi:type="xsd:string" /> <titulo_alternativo xsi:type="xsd:string" /> <titulo_serie xsi:type="xsd:string" /> <titulo_volume xsi:type="xsd:string" /> <titulo_tomo xsi:type="xsd:string" /> <area_de_conhecimento xsi:type="xsd:string">Informática</area_de_conhecimen to> <assunto xsi:type="xsd:string">Linguagem de programação</assunto> <volume xsi:type="xsd:string" /> <tomo xsi:type="xsd:string" /> <edicao xsi:type="xsd:string" /> <ano xsi:type="xsd:string">2001</ano> <local xsi:type="xsd:string">São Paulo</local> <editora xsi:type="xsd:string">Érica</editora> <autor xsi:type="xsd:string">FURGERI, Sérgio</autor> <colaborador xsi:type="xsd:string" /> <funcao xsi:type="xsd:string">[]</funcao> <entidade xsi:type="xsd:string" /> <evento xsi:type="xsd:string" /> <idioma xsi:type="xsd:string">Português [por]</idioma> <paginacao xsi:type="xsd:string">277 p.</paginacao> <notas_gerais xsi:type="xsd:string" /> <notas_tese xsi:type="xsd:string" /> <notas_resumo xsi:type="xsd:string" /> <saida xsi:type="xsd:string">{\rtf1\ansi\ansicpg1252\deff0\defl ang1046{\fonttbl{\f0\fswiss\fcharset0 Arial;}}\viewkind4\uc1\pard\f0\fs20 Localização: \b 005.133 F983e\b0 [33979] [Livro]\par FURGERI, Sérgio. \b Ensino didático da linguagem XML\b0 : Aprenda a criar padrões e documentos inteligentes com a XML. São Paulo: Érica, 2001. 277 p. [6 exemplar(es)]\par}</saida> <saida_html xsi:type="xsd:string"><p> <table><tr><td><a href="http://200.135.4.11/cgi/bibliotecaib6.exe/show_exe mplares?id_acervo=33979"><img src="http://200.135.4.7/img/33979.jpg" border=0 onerror="this.width=0;this.heigth=0"> </a></td><td>Localização: <a href="http://200.135.4.11/cgi/bibliotecaib6.exe/show_exe mplares?id_acervo=33979"><strong>005.133 F983e</strong></a> [33979] [Livro]<br> FURGERI, Sérgio. <a href="http://200.135.4.11/cgi/bibliotecaib6.exe/show_exe mplares?id_acervo=33979"><strong>Ensino didático da linguagem XML</strong></a> : Aprenda a criar padrões e 45 documentos inteligentes com a XML. São Paulo: Érica, 2001. 277 p. [6 exemplar(es)]</td></tr></table> </p></saida_html> <existe_imagem xsi:type="xsd:boolean">true</existe_imagem> <caminho_imagem xsi:type="xsd:string">c:\Inetpub\cgi\enio\ws\img\</cam inho_imagem> <imagem xsi:type="xsd:string">33979.jpg</imagem> <titulos_secundarios xsi:type="xsd:string" /> <autores_secundarios xsi:type="xsd:string" /> <areas_secundarias xsi:type="xsd:string" /> <assuntos_secundarios xsi:type="xsd:string">XML</assuntos_secundarios> <locais_secundarios xsi:type="xsd:string" /> <editoras_secundarias xsi:type="xsd:string" /> <colaboradores_secundarios xsi:type="xsd:string" /> <entidades_secundarias xsi:type="xsd:string" /> <eventos_secundarios xsi:type="xsd:string" /> </NS2:teb_ws_acervo> <return href="#1"
Compartilhar