Conceitos Básicos sobre o Padrão Z39.50

O padrão Z39.50 é um protocolo de troca de mensagens (especifica a estrutura e a

forma dos dados, e as regras de intercâmbio) permitindo que um cliente pesquise em bancos

de dados situados em servidores e recupere a lista de registros que satisfaz o critério de

pesquisa e os registros individuais (EVANS, 1997a).

O Z39.50 não especifica uma Interface de Programas de Aplicação (API

-Applications Program Interface) para os serviços de cliente e servidor, fornecendo uma

interface padronizada para lidar com as interações entre eles. (LYNCH, 1997).

Fazendo uma analogia com um banco de dados tradicional - que consiste em três

seções básicas, como indicado na figura abaixo - a interface do usuário é o computador ou o

terminal onde o usuário entra com os termos de pesquisa, utilizando uma interface API. Entre

a interface do usuário e o mecanismo de pesquisa existe uma camada (layer) que faz a ponte

entre os dois.

Figura C- Esquema de Banco de Dados Tradicional

O sistema Z39.50 substitui o componente da interface do usuário por um cliente

Z39.50 e a camada do SGBD por um servidor Z39.50. Pode-se, também, utilizar um cliente

WWW ou browser (como o Netscape ou Explorer) ao invés de um cliente Z39.50 e acionar um

serviço de tradução WWW–Z39.50 (o gateway) através de formulários (web-forms), como

indicado na figura abaixo:

Figura D - Esquema do Sistema Z39.50 com Cliente WWW

O servidor Z39.50 estabelece um mecanismo padrão de fazer pesquisas, o qual,

junto com um dicionário de dados, traduz para cada Sistema Gerenciador de Banco de Dados

a pesquisa requerida. A vantagem desse esquema sobre o esquema tradicional reside na clara

separação entre a interface do usuário e o mecanismo de pesquisa, significando, na prática,

que uma única interface possa ser usada para acessar diferentes tipos de mecanismos de

pesquisa e bancos de dados. Este novo componente - o servidor Z39.50 - fornece um serviço

de tradução de forma a tornar todo esse processo possível.

Analisando-se as três interações (“frontend”, cliente-servidor e “backend”) indicadas

na figura acima, tem-se um panorama básico sobre o protocolo Z39.50, como apresentado nas

próximas seções (SIRSI, 1996).

9.2.1. Interação “Frontend”

Para passar dados entre um cliente WWW (1) e um servidor Z39.50 (6) se utiliza, no

cliente WWW (1), um formulário para entrada dos dados que se quer consultar, com váriaveis

predefinidas, tudo montado numa cadeia (string) de consulta CGI. A Interface de Portão

Comum (CGI - Common Gateway Interface) é um padrão que define como intermediar um

servidor WWW com quaisquer outros programas. Esta cadeia é então enviada para um

servidor WWW (2). Um programa CGI, agindo como um gateway (portão) WWW/Z39.50 (3),

extrai as variáveis da cadeia de consulta, e as traduz num formato que possa ser reconhecido

pelo servidor Z39.50 (6).

No retorno, os dados recebidos pelo gateway, a partir do servidor Z39.50 (6), são

formatados adequadamente e enviados, como saída, dentro de uma estrutura de documento

html. Assim, se os registros retornados como resultado de uma pesquisa estiverem com um

formato particular (por exemplo, representado na linguagem SGML -Standard Generalized

Markup Language - que visa a estruturação de documentos eletrônicos, e descrita no capítulo

5), então o gateway deve ser capaz de formatar os registros adequadamente.

Embora a transmissão e a tradução de dados entre o WWW (1) e o Z39.50 (6) seja

relativamente simples, existe uma diferença em como os dois protocolos (http e Z39.50)

tratam as conexões. No protocolo http uma conexão permanece ativa enquanto o documento é

transmitido. O protocolo Z39.50, por outro lado, requer que durante a sessão a ligação seja

mantida (stateful), e composta de, no mínimo, três interações (init, search e present), definidas

na próxima seção.

O frontend age também como um filtro, permitindo que um cliente faça pesquisas

dirigidas através de parâmetros específicos para a base de dados disponibilizada. Por

exemplo, no capítulo 10 é apresentada uma conexão Z39.50 com o servidor da CPRM. Do

formulário de pesquisa exemplificado na seção 10.3.2, pode-se extrair o seguinte fragmento,

apresentado na figura abaixo, cujo correspondente código HTML é descrito logo em seguida.

Figura E - Fragmento de uma Tela de Pesquisa Z39.50

<SELECT NAME=”use_1”>

<OPTION VALUE=”1035”><!FullText> Qualquer Campo

<OPTION VALUE=”4”><!Title>Título

<OPTION VALUE=”3815”><!Edition>Edição

<OPTION VALUE=”1003”><!Originator>Autor

<OPTION VALUE=”3004”><!cntorpg>Organização para contato

<INPUT NAME=”rel_1” VALUE=”3” TYPE=”hidden”> contém

<INPUT NAME=”term_1” VALUE=>

<SELECT NAME=”BOOLEAN_OP_1”>

<OPTION SELECTED VALUE=”” >

<OPTION VALUE=”AND”>AND

<OPTION VALUE=”OR”>OR

<OPTION VALUE=”ANDNOT”>ANDNOT </SELECT>

<SELECT NAME=”use_2”>

<OPTION VALUE=”1035”><!FullText> Qualquer Campo

<INPUT NAME=”rel_2” VALUE=”3” TYPE=”hidden”> contém

<INPUT NAME=”term_2” VALUE=>

<SELECT NAME=”num_use_1”>

Este exemplo, usando o software ISite (apresentado no capítulo 10), usa os nomes

de variáveis rel_1 para o primeiro termo de pesquisa e use_1 para o valor do atributo

associado. Neste caso, o valor escondido 1035 representa o atributo bib1 (anexo 1) Anywhere

(Qualquer Campo), fornecendo uma pesquisa em todo o texto. Para uma pesquisa mais

detalhada, diferentes valores para a variável use_1 podem ser utilizados, correspondendo a

campos específicos listados no conjunto de atributos bib1 (anexo 1), como por exemplo: título

(valor escondido 4) ou edição (valor escondido 3815). Estes conceitos ficarão mais claros na

seção que explica os perfis, neste mesmo capítulo.

9.2.2. Interação Cliente-Servidor

É importante destacar que o servidor Z39.50 (6) é cliente para o servidor de Banco

de Dados. Nesse sentido, a interação descrita nesta seção é a que ocorre entre o cliente

Z39.50 e o servidor de Banco de Dados.

Os dados que transitam pelo Z39.50 são transportados em Unidades de Dados de

Protocolo (PDU - Protocol Data Units). Além dos dados propriamente ditos (termos de

pesquisa do cliente para o servidor, registros do servidor para o cliente, etc.), cada PDU

carrega informação adicional sobre a sessão, além de descrições dos dados e dos parâmetros

de pesquisa.

Uma sessão Z39.50 básica se compõe de três serviços:

•Init: estabelecimento de uma conexão e negociação dos parâmetros da sessão.

Durante o intercâmbio Init, que começa quando um cliente Z39.50 conecta-se a

um servidor Z39.50, são trocadas informações sobre as capacidades e

preferências do cliente e do servidor.

•Search: envio de comandos de pesquisa e o recebimento de um conjunto de

resultados da pesquisa. Uma PDU de search consiste de um conjunto de

atributos, de tipo de consulta, seguidos de uma consulta, segundo o formato de

Notação Polonesa Reversa² (RPN - Reverse Polish Notation). Algumas

características desse serviço são:

♦ Podem existir, geralmente, dois tipos de consultas: os Tipo-1 e o

Tipo-101. O Tipo-1 é uma consulta RPN e o Tipo-101 é uma consulta

RPN Estendida (ERPN). Esta última permite a inclusão de atributos

que definem campos, proximidade, etc.

♦ Na versão 3 do protocolo Z39.50 (Z39.50-1995), apresentado no

apêndice 4, os dois tipos de consultas são efetivamente idênticos. Na

PDU são incluídas também as seguintes informações: sintaxe

preferencial de registro, nomes dos bancos de dados e limites do

conjunto de resultados.

♦ O servidor de banco de dados cria um conjunto de resultados

consistindo de ponteiros para registros que satisfaçam a requisição

de pesquisa, modificados, se necessário, por restrições no tamanho e

faixa de valores do conjunto de resultados.

• Present: escolha de itens, a partir do conjunto de resultados da pesquisa, e o

recebimento dos registros correspondentes. A requisição Present do cliente

2

A Notação Polonesa Reversa foi apresentada, pela primeira vez, num livro do matemático

polonês Jan Lukasiewicz sobre lógica formal. Mostrou-se que as expressões matemáticas poderiam ser

especificadas sem parênteses, posicionando-se os operadores antes (Notação Polonesa) ou depois

(Notação Polonesa Reversa) dos operandos. Por exemplo, a expressão (4 + 5) * 6 pode ser

expressa em RPN como 4 5 + 6 * , ou seja, a expressão é avaliada da esquerda para a

direita, num esquema de pilha (o último elemento a entrar é o primeiro a sair). A Notação Polonesa

Reversa também é conhecida como notação pósfixada.

WWW, especifica alguns ou todos os ponteiros de registros referidos na

resposta Search. Em adição aos parâmetros descrevendo o número e faixa de

valores dos registros, a requisição Present também inclui a Sintaxe

Preferencial de Registro, como na requisição Search.

Estes três serviços constituem um conjunto mínimo de serviços para o

funcionamento do protocolo Z39.50.

9.2.3. Interação “Backend”

O backend do sistema é onde o servidor de banco de dados, através de um

mecanismo de pesquisa particular do Sistema Gerenciador de Banco de Dados, interage com

o servidor Z39.50.

O formato do banco de dados não é relevante, desde que o mecanismo de pesquisa

seja capaz de consultar os dados. A complexidade da interação backend depende da

sofisticação do mecanismo de pesquisa do Sistema Gerenciador de Banco de Dados utilizado.

No documento UNIVERSIDADE FEDERAL DO RIO DE JANEIRO Centro de Ciências Matemáticas e da Natureza Instituto de Geociências (páginas 81-86)