Copyright, 1996 © Dale Carnegie & Associates, Inc.

Custom SiteSearchAccess Client:

System Integration at theUniversity of Chicago

Tod A. Olson <tod@uchicago.edu>Programmer/Analyst

University of Chicago Library

University of Chicago environment

• Horizon as integrated library system

• SiteSearch – CIC VEL access– Interlibrary Loan

Why do custom access authorization?

• All VEL patrons (faculty, students, staff) already in Horizon

• Avoid maintaining another production database

Guidelines

• Separate customizations from the distribution

• Hide database interaction under an abstraction layer

• Test the pieces individually• Avoid touching the user interface• Code should support policy, not set

it

Planning

• Components to build• Organizing customizations

Components

• Database abstraction: hides database interaction

• HorizonAccessServer: holds server and policy information

• HorizonAccessClient: implements/enforces access policy

Organizing customizations

• Java classes• .ini files• HTML files

Java classes

• DB abstraction and JDBC classes– May be used by other projects– Install outside of SiteSearch

• Access classes– Install under SiteSearch classes

directory– reside in own package, edu.uchicago.lib.webz

.ini files and HTML files

• Less flexible lookup mechanism• Local files in default SiteSearch

directories• Distinguish by “Uchi” prefix

Database abstraction

• Use JDBC for database interaction• Hide JDBC code behind abstraction

layer• Simple abstraction:

– One getXXXX() method per index– next() gets next row– One getXXXX() method per column,

gets value in current row

Comments on the DB Abstraction

• Exposes tables, hides JDBC detail• Extensible: could add insert,

update, where• Suitable for code generation• Currently not full-featured

– Cf. Commercial code-generators

HorizonAccessServer

• Implements AccessServerConnect• Reads .ini files, stores data for

AccessClient• .ini files organized like default

Access .ini files

HorizonAccessServer implementation

Starting point:• All methods are stubs• toString() reports object state• Use main() to test methods

HorizonAccessServer.main()

• Sets up ServerLog.out• Looks up JaSSIServer.ini• Calls init()

HorizonAccessServer.init()

• Gets server name and JaSSIServer.ini as args

• Parses .ini files– Server connection data in

[servername].ini– JaSSI data: Look up file name in

JaSSIServer.ini

HorizonAccessClient

Implements access policy:• Authenticates patron• Gets patron data• Determines databases patron may

use

HorizonAccessClient implementation

Starting point:• Implements AccessClient• All methods are stubs• toString() reports object state• Use main() to test methods

HorizonAccessClient.main()

• Sets up ServerLog.out• Sets up a UserStateObject• Looks up JaSSIServer.ini• inits HorizonAccessServer• Calls initialize()• Calls authorizeByName()

HorizonAccessClient.initialize()

• Loads SQL driver• Connects to Horizon database

HorizonAccessClient.authorizeByName()

• isFacStuStaff()– Authenticates patron by (barcode and

PIN) – Checks patron has correct privileges

• getBorrowerInformation()– shows use of DB abstraction

HorizonAccessClient.setDbList()

• Takes Hashtable of ZDb objects• Stores Vector of ZDb names

– Only what patron is allowed

• authorizeByXXX() can edit this list– local policy– licensing agreements

Use the logs

• Gather usage information:traceLevel=TRACE_ENTERS_AND_EXITS

traceLevel= TRACE_ENTERS_AND_EXITS+TRACE_PARMS

• TRACE_ALL usually reports too much– Use TRACE_DEBUG in examples

Use the logs

• Usually use method, trace level, String version

log.println(“FooClass.initFlange()”,TRACE_DEBUG,“flange.value = “ + flange.value);

• Can grep by class and method name

[ . . . ] [FooClass.initFlange()]

flange.value = null

Log useful information

• Report program/object statelog.println(method, TRACE_DEBUG, flange.toString());

• Always report errorslog.println(“FooClass.initFlange()”, “Bad flange = “ + flange.toString());

Leave logging statements in production code

• May be useful in future• Disable via traceLevel• Negligible performance impact

Conclusions

• Custom access client worthwhile– eliminates extra production DB

• Test outside of JaSSI– shorter development cycle

• Separate customizations from distribution

• Logs are often useful