On 30/01/2008, Stephens, Owen <o.stephens_at_imperial.ac.uk> wrote:
> Although clearly there is something to be said for building on what
> already exists, I also think that a new project is an opportunity to
> break away from the traditional ILS design. Although I haven't looked at
> Koha and Evergreen in great depth, they seem to me to be open source
> versions of the 'traditional' ILS (happy to be corrected) - there's
> nothing wrong with this, and clearly this may stimulate some competition
> and more innovative thinking in the market place.
Hi Owen:
Thanks for giving me the opportunity to offer you (and the rest of the
list) some more information about Evergreen - it is a library system
built on top of a service oriented architecture called Open Service
Request Framework (OpenSRF). If a component has an API that can be
wrapped in (currently) Perl, C, or Java (and soon Python), then that
component's methods can easily be exposed as an OpenSRF service and
invoked by any OpenSRF client (currently available in Perl, C, Java,
Python, and, via the OpenSRF Apache gateway, JavaScript).
There are two levels of integration that you're seeing in Evergreen
today. There are services that are integrated "at the glass" (in the
staff client UI and in the catalogue UI). I think we want a consistent
look and feel across the catalogue UI, so I would consider that level
of integration a "good thing".
The argument has been made that staff interfaces could be less
integrated if you have well-defined functional areas. If, say,
catalogers rarely have to perform circulation duties, and acquisitions
people rarely have to deal with cataloging or circulation, you could
have entirely different clients for each of these task areas. I think
the current staff client, as an integrated XUL application, simply
reflects that there weren't existing open source UI components that
could be taught how to call the appropriate Evergreen services to
perform their work, so the Evergreen team had to build it from the
ground up.
That could change: perhaps an Evergreen plug-in could be developed for
MarcEdit as a proof of concept that alternative cataloging clients can
be used with Evergreen.
http://oregonstate.edu/~reeset/marcedit/html/help/marcedit4_5/html/meProgramPluginHook.html
would be the place to start, if there are any interested ActiveX
programmers out there.
Then there are services that use an interface definition language that
acts as an object-relational model. Many Evergreen services use the
IDL today for CRUD operations, but it is not necessary for new
components that will provide services to use the IDL - they can either
act as an OpenSRF client and call the appropriate service, or
(although I wouldn't recommend this as it runs counter to the whole
purpose of having a service oriented architecture) they could directly
query and manipulate the underlying database schema.
So - hopefully that helps explain why Evergreen is _not_ a traditional
tightly coupled ILS, why we have chosen to contribute our efforts
towards enhancing Evergreen for use in academic institutions, and why
I believe it should be seriously considered as a platform for building
solutions for the use cases that will be one of the products of this
exercise.
--
Dan Scott
Laurentian University
Received on Sat Feb 02 2008 - 07:27:47 EST