 |
 |
|
 |
|
 |
|
 |
|
     
|
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
The IMesh Toolkit
[ Work In Hand > Technical Review > Information Sources ]
Search Middleware and the Simple Digital Library Interoperability Protocol: a digest
A. Paepcke et al
D-Lib Magazine March 2000
http://www.dlib.org/dlib/march00/paepcke/03paepcke.html
Gives a brief but illuminating view of the problems confronting search middleware design and shows how
SDLIP may be able to provide acceptable solutions.
____________________________________________________________________________________
The article aims to consider what can be implemented to improve upon the restricted nature of HTML
forms for searching the web and their text-based limitations. Given there is no agreed
programmatic interface for accessing information, there is a call for some form of search
middleware to transport search queries and results and negotiate search parameters.
The authors indicate the continuing culture clash between ad hoc lightweight protocols that abound
in web development versus the all-singing heavyweight Z39.50 which can be too complex. They regard
SDLIP as a suitable compromise between the two approaches, citing its origins at SDSC and the
influence of DASL. They equally cite implementations of SDLIP including an SDLIP to Z39.50 gateway
by UC Berkeley.
The article then moves on to SDLIP as a search middleware design with an initial diagram
demonstrating the role of SDLIP in an architecture involving client, a Library Service Proxy and
remote repositories which do not implement SDLIP themselves. The article goes on to detail the
search scenario.
The authors then begin an examination of four features of search middleware design:
1 maintenance of search state
The benefits and disadvantages of state maintenance are examined. The SDLIP solution to the
drawbacks resides in the adoption of a parking meter where the server determines load and the
maximum time results will be maintained for the user.
2 management of protocol complexity
The authors examine the various strategies to be adopted in preserving clarity and maintainability
of software and their flaws: feature exclusion, rich core functionality with specialised
functionality and finally metaobject protocols, (MOPS). The SDLIP solution is the partitioning of
interfaces into search , results access and source metadata interfaces, claiming that some
configurations will not even need to implement all of them.
3 query language formats
Once again the authors consider the options that exist in terms of design decisions. The imposed
single query language is feasible in a stable search 'monoculture'; where standardisation is
weak then the use of a single client query language but which translates to languages native to
the search engines is another valid approach. Both strategies have their faults. A third way is to
translate the query language to an abstract form interpretable by all servers. The SDLIP solution
is a common compromise: it defines a simple search language called Basicsearch which all search
services can support whilst nonetheless permitting the user to elect other query languages.
4 transport of requests and results
Whilst it cites 3 well-known methods for transporting, CORBA , HTTP and DCOM, the article examines
their effectiveness but promotes the notion of "Transport Neutrality" to enhance SDLIP's
usability. A diagram, "SDLIP Implementation Architecture", demonstrates how this is assured
through layered abstraction. It shows how SDLIP interacts between the Library Service Proxy,
the various flavours of client- and server-side transport modules and the user.
Conclusions
Search middleware design benefits the development of information-intensive applications.
There is a balance to be found between the need for simplicity and the right functionality.