Buscar

REDE DE INTERCÂMBIO DE DADOS PARA ACERVOS BIBLIOGRÁFICOS BASEADA EM WEB SERVICES

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 64 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 6, do total de 64 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 9, do total de 64 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

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"

Materiais relacionados

Perguntas relacionadas

Materiais recentes

Perguntas Recentes