To avoid having to replicate this information
across all libraries all the time, replication messages are sent using JMS topics when there
is need for them. In this way, a new library can be opened without having to change the existing
instances of the application.
Communication between libraries is opened up when a user who already has an account
at another library walks into a library where he or she hasn??™t been before. When this happens
and the user tries to log in to loan a book, the LibLib instance will send out a general request
for information, and will update its own records if the user is found in any other system.
Otherwise, it will require the user to create a new identity in the system.
The third usage of the LibLib system is as an administrative user interface for adding and
removing books, and also for handling users. The admin interface is local to each library, but
new books added to the system will be available in the central legacy system so that searches
from other libraries can see it. At the moment there is only one way to add a new book to the
system, and that is through importing the information from Amazon and ???buying??? it. (In fact,
you won??™t buy anything from Amazon right now; it suffices to just extract the information
through AWS and add this to the legacy database.)
So, to recap, you have these moving parts:
??? A legacy system containing book information for each library.
??? A JMS system that allows communication between the legacy system and the different
LibLib instances.
Pages:
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324