Rozšírené služby protokolu Z39.50
Pojmom rozšírené služby, ktoré sú definované protokolom Z39.50, rozumieme také úlohy, ktoré sa vykonávajú mimo tej úlohy, ktorá ich iniciovala.
Hlavným cieľom, prečo boli definované tieto služby, je tvorba a údržba báz dát. Na zabezpečenie tohto cieľa sú definované jednotlivé dávky úloh, tzv. task packages. Tieto sa vytvárajú na serveri na základe požiadavky klienta, v ktorej parametrami definuje vytvorenie dávky úloh. Parametre využíva tiež server pri svojej odpovedi na požiadavku klienta. Niektoré parametre möžu byť spoločné pre klienta i server. K základným parametrom patrí:
1.1. Persistent ResultSet - trvalá množina výsledkov
1.2. Persistent Query - trvalá otázka
1.3. Periodic Query Sched ule- kalendár periodicky sa opakujúcich otázok
1.4. Item Order - objednávka, vyžiadanie
1.5. Database Update - tvorba, modifikácia a výmaz báz dát
1.6. Export Specification - špecifikácia exportu
1.7. Export Invocation - spustenie exportu
done – čo znamená, že požiadavka bola akceptovaná, úloha je skompletizovaná a je pripravený výsledok;
accepted – požiadavka bola akceptovaná a úloha je zaradená, resp. je už v spracovaní;
failure – požiadavka bola odmietnutá a je odoslaná jedna alebo viacero diagnostických správ.
Ak sa na základe požiadaviek klienta vytvorí na serveri požadovaná dávka úloh, má server dve možnosti:
V prvom prípade hovoríme o synchrónnom spracovaní. Znamená to, že klient vyšle požiadavku na server, ktorý na základe kladnej validácie vytvorí a bezprostredne na to spustí požadované úlohy. Klient v odpovedi dostane status dávky complete spolu s výsledkom úloh.
V druhom prípade ide o tzv. asynchrónne spracovanie. Na tento účel je na serveri vytvorená báza dát nazývaná IR-Extend-1, do ktorej sa jednotlivé dávky úloh zapisujú ako záznamy. Vtedy sa daná dávka dostáva do stavu čakania na svoje spracovanie, čo sa označuje statusom ”pending”. Podľa jednotlivých procesov, ktoré sú práve spracovávané, server rozhoduje sám o zaradení danej dávky úloh do spracovania.
Klient môže kedykoľvek, a to buď v rámci daného spojenia zo serverom, alebo počas ktoréhokoľvek nasledujúceho spojenia, vysielať požiadavky a prezerať stav ním požadovaných dávok úloh.
Aby sme si vedeli predstaviť, ako pracuje knihovnícky informačný systém, ktorý má v sebe integrovaný tento základný štandard pre komunikáciu, ukážeme si, ako spolupracujú jednotlivé časti systému s klientom i serverom tohto protokolu.
Najprv je nutné spustiť si svoj informačný systém – ja som na demonštráciu použila systém Rapid Library.
obr. 1
Zo systému je možné priamo vyvolať klienta Z39.50, ktorý je neoddeliteľnou súčasťou pri katalogizácii. Skôr ako katalogizátor začne vytvárať záznam, sa pomocou klienta pozrie do prístupných katalógov kooperujúcich knižníc, či niektorá z nich už daný dokument nemá spracovaný. Využije na to vyhľadávanie pomocou klienta Z39.50. V tomto prípade budeme hľadať dokument, ktorý má v názve reťazec ”pyron”.
obr. 2
Aby sme si uľahčili vyhľadávanie, použijeme funkciu Scan. Teda zadali sme len časť nami hľadaného reťazca a klikneme na otáznik, ktorý indikuje spomínanú funkciu Scan. Server nám odpovedá takto:
obr. 3
Vidíme, že sme dostali množinu výsledkov, ktorá obsahuje 1 záznam. Vyberieme si tento záznam a zvolíme funkciu present.
obr. 4
Dostaneme záznam do obrazovky vo formáte Unimarc. Zvýraznený reťazec označuje tú časť záznamu, ktorú chceme opraviť, a takto opravený záznam si preberieme do svojej lokálnej bázy dát. Okrem iného vytvoríme tiež nový záznam v súbore osobných autorít. Aby sme mohli pri oprave používať všetky validačné tabuľky a funkcie definované Unimarcom a nami prijatými katalogizačnými pravidlami AACR2, prenesiem záznam do editovacej masky, kde máme k dispozícii zoznam jednotlivých tagov a k nim prislúchajúcich podpolí, ako aj všetky validačné hodnoty. V ľavom rohu nás systém informuje o tom, aký tag a podpole editujeme.
obr. 5
Takto upravený záznam pomocou SAVE prenesieme späť do klienta a kliknutím na update vyvoláme proces, ktorý upraví daný záznam na serveri Z39.50, kde máme centrálnu bázu dát. Zvýraznená časť ukazuje pole 999$a, ktoré je použité ako identifikátor verzie záznamu. Táto sa po update zväčší o 1.
obr. 6
Druhý príklad, ktorý chcem použiť, bude tiež názorne demonštrovať to, aké správy sú vymieňané medzi klientom a serverom, než príde k vytvoreniu nového záznamu v báze dát osobných autorít. Na základe vyhľadávania sme zistili, že neexistuje záznam v súbore osobných autorít pre Pyron Darden Asbury:
obr. 7
Podobne ako v predchádzajúcom prípade, aj teraz budeme záznam vytvárať v editore Unimarcu, ktorý nám ponúka komfort práce ako v lokálnom systéme. Takto vytvorený záznam prenesieme do klienta a stlačením insertu odošleme. Záznam dostane nový kód a označenie verzie bude 1. Takto vytvorený záznam potom prenesiem do svojho lokálneho systému, kde, samozrejme, dostane iný kód, ale zostáva ponechaná väzba na kód v centrálnom systéme. V centrálnom systéme je naviac zachytené, ktorá z kooperujúcich knižníc má daný záznam v svojom lokálnom systéme. Kvôli zjednodušeniu uvádzame len časti záznamov, nie kompletný záznam (v príklade je použitá len časť záznamu).
obr. 8
obr. 9
Doteraz sme si ukázali len to, čo sa deje na obrazovke používateľa. Len málokto si však vie predstaviť, ako vyzerá skutočná výmena informácií, teda komunikácia medzi klientom a serverom. Nasledujúci príklad presne zachytáva túto komunikáciu pri tvorbe nového záznamu do bázy dát:
I.Init
initRequest {
protocolVersion BITSTRING(len=1)
options BITSTRING(len=2)
preferredMessageSize 1048576
maximumRecordSize 1048576
implementationId 'Cosmotron Systems (id=139)'
implementationName 'Rapid Library for Windows'
implementationVersion '1.0b'
}
initResponse {
protocolVersion BITSTRING(len=1)
options BITSTRING(len=2)
preferredMessageSize 1048576
maximumRecordSize 1048576
result TRUE
implementationId 'Cosmotron Systems (id=139)'
implementationName 'Server'
implementationVersion '1.5'
}
II. Scan
scanRequest {
databaseNames {
databaseNames 'marc'
}
attributeSet OID: 1 2 840 10003 3 1 /* Bib-1 */
termListAndStartPoint {
attributes {
attributes {
attributeType 1
numeric 1 /* Bib1 - Personal-name */
}
}
term choice
general OCTETSTRING(len=3) "pyr"
}
numberOfTermsRequested 20
preferredPositionInResponse 1
}
scanResponse {
scanStatus 5
numberOfEntriesReturned 17
positionOfTerm 1
entries {
entries {
entries choice
termInfo {
term choice
general "pyron"
globalOccurrences 1
}
entries choice
termInfo {
term choice
general "r."
globalOccurrences 1
}
entries choice
termInfo {
term choice
general "steinbeck"
globalOccurrences 1
}
....
....
}
}
}
III. Search
searchRequest {
smallSetUpperBound 0
largeSetLowerBound 1
mediumSetPresentNumber 0
replaceIndicator TRUE
resultSetName '1'
databaseNames {
databaseNames 'marc'
}
query {
query choice
type_1 {
attributeSetId OID: 1 2 840 10003 3 1 /* Bib-1 */
RPNStructure choice
{
simple choice
attributesPlusTerm {
attributes {
attributes {
attributeType 1
numeric 1
}
}
term choice
general OCTETSTRING(len=5) "pyron"
}
}
}
}
}
searchResponse {
resultCount 1
numberOfRecordsReturned 0
nextResultSetPosition 1
searchStatus TRUE /* success */
}
IV. Present (Retrieve)
presentRequest {
resultSetId '1'
resultSetStartPoint 1
numberOfRecordsRequested 1
recordComposition choice
{
simple choice
generic 'F' /* element specification = FULL */
}
preferredRecordSyntax OID: 1 2 840 10003 5 1
}
presentResponse {
numberOfRecordsReturned 1
nextResultSetPosition 2
presentStatus 0
records choice
databaseOrSurDiagnostics {
databaseOrSurDiagnostics {
databaseName 'marc'
record {
{
databaseRecord {
OID: 1 2 840 10003 5 1 /* UNIMARC */
databaseRecord choice
octetstring OCTETSTRING(len=595) 30 30 35 39 35 .. 33 1E 1D
}
}
}
}
}
}
V. Extended services
extendedServicesRequest {
function 1 /* create */
packageType OID: 1 2 840 10003 9 5 1 1 /* ESFormat-Update */
packageName 'update-pkg-name-1'
userId 'cosmotron'
retentionTime {
value 20
unitUsed {
unitSystem {
unitSystem 'SI'
}
unitType {
unitType choice
string 'time'
}
unit {
unit choice
string 'second'
}
scaleFactor 0
}
}
description 'This is simple record update package.'
taskSpecificParameters {
OID: 1 2 840 10003 9 5 1 1 /* ESFormat-Update */
taskSpecificParameters choice
{
IUUpdate choice
esRequest {
toKeep {
toKeep {
action 2 /* recordReplace */
databaseName 'marc'
}
}
notToKeep {
notToKeep {
notToKeep {
record {
OID: 1 2 840 10003 5 1 /* UNIMARC */
record choice
/* octet string encoded ISO2709 UNIMARC record */
octetstring OCTETSTRING(len=595) 30 30 35 39 35 .. 33 1E 1D
}
}
}
}
}
}
}
waitAction 1 /* wait */
}
extendedServicesResponse {
operationStatus 1 /* done */
taskPackage {
OID: 1 2 840 10003 9 5 1 1 /* ESFormat-Update */
taskPackage choice
{
IUUpdate choice
taskPackage {
originPart {
originPart {
action 2 /* recordReplace */
databaseName 'marc'
}
}
targetPart {
targetPart {
updateStatus 1 /* success */
taskPackageRecords {
taskPackageRecords {
recordOrSurDiag {
record {
OID: 1 2 840 10003 5 1 /* UNIMARC */
record choice
octetstring OCTETSTRING(len=595) 30 30 35 39 35 .. 34 1E 1D
}
}
recordStatus 1 /* success */
}
}
}
}
}
}
}
}
VI . Close
closeRequest {
closeReason 0 /* finished */
}
closeResponse {
closeReason 0 /* finished */
diagnosticInformation 'Association terminated by client'
}
Z uvedeného príkladu sú jasne vidieť jednotlivé parametre, ktoré používa klient a server pre špecifikovanie svojej požiadavky, resp. odpovedi.
Ing. N. Andrejčíková, Cosmotron systems, spol. s r. o.
http://www.cvtisr.sk/itlib/bc2000_1/andrejcik.htm
ITlib. Informačné technológie a
knižnice