Bƣớc 1: Tra cứu tìm tin trên OPAC.
Bƣớc 2: Gửi yêu cầu mƣợn đến thƣ viện A: xác nhận họ tên cá nhân, tài liệu mƣợn, hình thức mƣợn, giá tiền có thể trả…
Bƣớc 3: Thƣ viện xử lý và gửi yêu cầu đến thƣ viện B, đồng thời cũng thông báo cho bạn đọc biết.
Bƣớc 4: Thƣ viện B, xử lý yêu cầu: thông báo cho thƣ viện A: Đồng ý, hoạc không đồng ý cho mƣợn. Nếu cho mƣợn thì thông báo gửi tài liệu. Bƣớc 5: Thƣ viện A: thông báo nhận đƣợc tài liệu.
Bƣớc 6: THƣ viện A: thông báo đến bạn đọc sẵn sàng tài liệu.
Nếu mƣợn không hoàn trr coi nhƣ đến dây là kết thúc. CÒn mwonj hoàn trả thì thêm bƣớc 7
Bƣớc 7: Thƣ viện A: nhận tài liệu từ bạn đọc và thông báo đến thƣ viện cho mƣợn B.
Chƣơng 3: CHƢƠNG TRÌNH THỬ NGHIỆM 3.1 Bài toán
Sự ra đời của giao thức Z39.50 đã đem lại một cuộc cách mạng trong việc truy hồi thông tin. Ngƣời dùng có khả năng tra cứu tới các cơ sở dữ liệu hỗ trợ Z39.50 chỉ bằng một ứng dụng Z39.50 client duy nhất. Tuy nhiên đối với một yêu cầu tìm kiếm đặc biệt ví dụ nhƣ: tài liệu hiếm mà ngƣời dùng không có thông tin chắc chắn về cơ sở dữ liệu chứa nó, ngƣời dùng có thể phải thực hiện lặp lại việc tìm kiếm nhiều lần với nhiều cơ sở dữ liệu để tìm ra kết quả mong muốn.
Trong thực tế, một thƣ viện hoặc trung tâm thông tin lớn thƣờng có nhiều cơ sở dữ liệu khác nhau nhƣ: mục lục sách, bài trích tạp chí, kết quả nghiên cứu…, số lƣợng cơ sở dữ liệu là đối tƣợng tìm kiếm của ngƣời dùng càng lớn khi phạm vi tìm kiếm vƣợt ra ngoài một thƣ viện cụ thể mà vƣơn tới một hiệp hội, toàn quốc gia hoặc toàn thế giới. Số lƣợng cơ sở dữ liệu cần tìm sẽ từ con số 1 đến hàng chục, hàng trăm và hàng nghìn. Nhƣ vậy, nếu việc tìm kiếm phải lặp lại với từng cơ sở dữ liệu thì đối với một truy vấn khó, ngƣời dùng sẽ phải mất nhiều thời gian và có thể không đủ kiên nhẫn để tìm ra tài liệu.
Phƣơng án tốt nhất đối với ngƣời dùng là một công cụ tìm kiếm song song trên nhiều cơ sở dữ liệu Z39.50, họ chỉ việc chọn các cơ sở dữ liệu cần tìm và thực hiện một lần cho một truy vấn giống nhƣ khi tìm trên một cơ sở dữ liệu vậy. Giải pháp tìm kiếm song song là một nhân tố quan trọng để xây dựng thành công các cổng thông tin tƣ liệu thƣ viện ở Việt Nam cũng nhƣ trên thế giới ngày nay, đặc biệt là cho các thƣ viện lớn và trung tâm học liệu với nguồn tin dồi dào với hàng chục cơ sở dữ liệu khác nhau.
Chƣơng trình thử nghiệm của luận văn này là một nỗ lực nhằm xây dựng cổng tìm kiếm liên hợp theo giao thức Z39.50 với giao diện Web. Sự thành công của hệ thống này cho phép các thƣ viện, trung tâm thông tin tích hợp vào cổng thông tin của mình và cung cấp cho ngƣời dùng sự tiện lợi trong việc tìm kiếm thông tin tƣ liệu trong và ngoài tổ chức.
3.2 Thiết kế chƣơng trình
3.2.1 Công cụ lập trình YAZ của IndexData
IndexData http://www.indexdata.com là một doanh nghiệp hoạt động trong lĩnh vực tƣ vấn và phát triển phần mềm có trụ sở tại Copenhagen - Đan Mạch với các văn phòng ở Đức, Anh, Canada, và Hoa Kỳ. IndexData LLC là một công ty con tại Hoa Kỳ, có trụ sở tại West Hartford, Connecticut, với các văn phòng bổ sung
ở New Hampshire, New Jersey và tiểu bang Massachusetts. Đƣợc thành lập vào năm 1994, IndexData chuyên về giải pháp quản lý và khai phá thông tin phân tán.
IndexData là một thành viên trong nhóm triển khai Z39.50 ZIG và ZING. YAZ là một bộ công cụ lập trình hỗ trợ phát triển Z39.50/SRW/SRU phía khách và chủ do IndexData phát triển. Z39.50-2003 (phiên bản 3) cũng nhƣ SRW / SRU phiên bản 1.1 đƣợc hỗ trợ trong cả hai vai trò khách/chủ.
YAZ đã đƣợc rộng rãi công nhận là bộ công cụ hàng đầu để xây dựng các hệ thống khách và chủ hỗ trợ Z39.50 kể từ bản phát hành đầu tiên vào năm 1995. Trong suốt một thập kỷ của dịch vụ đang hoạt động, bộ công cụ YAZ trở nên thiện chiến trong mọi loại hình ứng dụng, và lớn lên trong sự hỗ trợ cho ngay cả những khía cạnh bí truyền của các giao thức Z39.50 và SRW.
Nhiều ứng dụng Z39.50 khách và chủ sử dụng trên toàn thế giới dựa trên YAZ hơn bất kỳ bộ công cụ khác.
Thống kê từ trang Z39.50 IndexData của Target Directory biên soạn trong mùa thu năm 2004 cho thấy ít nhất 35% máy chủ Z39.50 của toàn thế giới đƣợc xây dựng với YAZ. Ƣớc tính rằng con số thực có lẽ là gần hơn với 50%, nhƣng một tỷ lệ phần trăm chính xác không đƣợc biết. Sử dụng số liệu thống kê thu thập đƣợc vào giữa năm 2004 từ cổng Z39.50 của Thƣ viện Quốc Hội Mỹ cho biết rằng tối thiểu là 65%, và có thể hơn nhiều, hệ thống khách truy cập vào LC dựa trên bộ công cụ YAZ.
Bộ công cụ YAZ là mã nguồn mở, miễn phí, và vì tất cả lý do trên, tôi chọn YAZ để phát triển giải pháp của mình.
YAZ là một bộ thƣ viện lập trình cho C/C++ nên tôi đã phát triển một thƣ viện chƣơng trình CSZOOMC.dll (Csharp Z39.50 Object Model Component) nhƣ là một vỏ bọc các API của YAZ để triệu gọi và sử dụng dễ dàng trong các ứng dụng phát triển bằng công nghệ Microsoft.NET.
3.2.2 Xây dựng ứng dụng đa luồng với Microsoft.Net
Đa luồng là một công cụ mạnh mẽ để tạo các ứng dụng hiệu suất cao, đặc biệt là các ứng dụng có yêu cầu tƣơng tác với ngƣời dùng hoặc làm việc với các dịch vụ và tài nguyên phân tán. Microsoft. NET đã phá vỡ những rào cản đó từng tồn tại trong việc tạo ra các ứng dụng đa luồng.
3.2.2.1 Khái niệm về luồng(thread)
Để hiểu đƣợc đa luồng đầu tiên chúng ta phải hiểu các luồng. Mỗi ứng dụng / chƣơng trình đang chạy trên một hệ thống là một tiến trình. Tiến trình cho mỗi
chƣơng trình bao gồm một hoặc nhiều luồng mà bộ xử lý cần một thời gian nhất định để thực hiện. Mỗi luồng có chứa tất cả các thông tin ngữ cảnh đƣợc yêu cầu bởi hệ thống để thực hiện các lệnh của chƣơng trình.
Hệ điều hành có trách nhiệm lập kế hoạch và thực hiện các luồng. Hãy nhớ những ngày của Windows 3.x? Một tiến trình luồng duy nhất có thể, và thƣờng làm, độc quyền tất cả các thời gian xử lý. Hệ thống sẽ chỉ ngồi và chờ đợi cho luồng đó hoàn thành trƣớc khi thực hiện bất kỳ tiến trình khác.
Các hệ điều hành mới hơn, chẳng hạn nhƣ Windows 2000, hỗ trợ đa nhiệm chặn trƣớc nó phân bổ mỗi luồng một lát thời gian. Khi thời lát gian của luồng hiện đang thực hiện đã trôi qua, luồng bị đình chỉ bởi hệ điều hành, bối cảnh của luồng đƣợc lƣu, bối cảnh của luồng khác đƣợc tải, và luồng khác thì tiếp tục thực hiện theo trạng thái trƣớc đó. Điều này đem đến sự xuất hiện nhiều luồng đƣợc thực hiện đồng thời và ngăn chặn hệ thống trở thành không phản hồi từ một luồng đơn (kết thúc nhiệm vụ bất cứ ai?). Trên các hệ thống có hơn một bộ xử lý, các luồng đƣợc phân bổ qua tất cả các bộ xử lý nhƣ vậy thực sự có nhiều luồng đang đƣợc thi hành tại cùng một thời điểm.
3.2.2.2 Căn bản về mô hình luồng
Single Thread - Đơn luồng có nghĩa là chỉ có một luồng trong một tiến trình và
nó đang làm tất cả các công việc cho tiến trình này. Tiến trình phải chờ đợi thực thi hiện tại của luồng hoàn thành trƣớc khi nó có thể thực hiện một hành động khác.
Kết quả đơn luồng ở thời gian nhàn rỗi của hệ thống và sự thất vọng của ngƣời dùng. Ví dụ, giả sử chúng ta đang lƣu một tệp tin vào một mạng từ xa bằng cách sử dụng một ứng dụng đơn luồng. Vì chỉ có một luồng duy nhất trong ứng dụng, ứng dụng sẽ không thể làm bất cứ điều gì khác trong khi tệp tin đang đƣợc lƣu giữ vào vị trí từ xa. Vì vậy ngƣời dùng chờ đợi và bắt đầu tự hỏi, liệu ứng dụng bao giờ sẽ tiếp tục.
Apartment Threading (Single Threaded Apartment – căn hộ đơn luồng)
Apartment threaded - Căn hộ luồng có nghĩa là có nhiều luồng trong ứng dụng. Trong căn hộ luồng đơn (single thread apartment - STA) mỗi luồng bị cô lập trong một căn hộ riêng biệt bên dƣới tiến trình. Tiến trình qui định khi nào và trong bao lâu luồng trong mỗi căn hộ có thể thi hành. Mọi yêu cầu đƣợc xếp hàng thông qua hàng đợi thông điệp của Windows, nhƣ vậy chỉ có một căn hộ luồng duy nhất đƣợc truy cập tại một thời điểm và do đó chỉ có một luồng đơn sẽ đƣợc thực hiện tại một thời điểm. STA là mô hình luồng mà hầu hết các nhà phát triển Visual Basic quen thuộc vì đây là mô hình luồng có sẵn cho các ứng dụng VB trƣớc khi có VB.NET. Bạn có thể nghĩ nó nhƣ một hàng các căn hộ một phòng mà có thể truy cập tới một tại một thời điểm thông qua một hành
lang duy nhất. Ƣu điểm của nó so với đơn luồng là nhiều lệnh có thể đƣợc ban hành cùng một lúc thay vì chỉ một lệnh duy nhất, nhƣng các lệnh vẫn tuần tự thực hiện.
Free Threading (Multi Threaded Apartment – căn hộ đa luồng)
Các ứng dụng luồng tự do giới hạn trong các ngôn ngữ nhƣ C++ cho tới khi Microsoft.NET ra đời. Mô hình Luồng tự do/Multi Threaded Apartment (MTA) có duy nhất một căn hộ đơn đƣợc tạo gia bên dƣới tiến trình chứ không phải nhiều căn hộ. Một căn hộ đơn chứa đựng nhiều luồng hơn là chỉ một luồng. Không cần hàng đợi thông điệp bởi vì tất cả các luồng là một phân của cùng một căn hộ và có thể chia sẻ dữ liệu mà không cần proxy. Bạn có thể nghĩ nó nhƣ là một công trình với nhiều phòng mà đều có thể vào đƣợc một khi bạn đã ở bên trong. Các ứng dụng này thƣờng thực hiện nhanh hơn so với đơn luồng và STA vì có ít hệ thống hơn và có thể đƣợc tối ƣu hóa để loại bỏ thời gian nhàn rỗi của hệ thống.
Các loại ứng dụng này là phức tạp hơn khi lập trình. Ngƣời phát triển phải cung cấp sự đồng bộ hóa giữa các luồng nhƣ một phần của mã lệnh để chắc chắn các luồng không đồng thời truy cập tới cùng các nguồn tài nguyên. Một điều kiện đƣợc biết đến nhƣ trƣờng hợp tranh đua có thể xuất hiện khi luồng truy cập tới tài nguyên chia sẻ và thay đổi tài nguyên tới một trạng thái không hợp lệ và khi luồng khác truy cập tới tài nguyên và sử dụng nó trong điều kiện không hợp lệ trƣớc khi một luồng khác trả tài nguyên về trạng thái hợp lệ. Vì vậy việc cần thiết đặt một khóa vào tài nguyên để ngăn chặn các luồng khác truy cập cho tới khi khóa đƣợc bỏ đi. Tuy nhiên, điều này có thể dẫn đến tình huống bế tắc nơi hai luồng cạnh tranh về tài nguyên mà không cái nào xử lý đƣợc. Ví dụ, luồng #1 có một tài nguyên bị khóa và đang chờ tài nguyên khác đang khóa bởi luồng #2. Luồng #2 lại xuất hiện tình trạng đang chờ đợi tài nguyên bị khóa bởi luồng #1. Nhƣ vậy, cả hai luồng đều đang chờ đợi lẫn nhau và không luồng nào sẽ đƣợc cho phép xử lý. Chỉ có một con đƣờng để tránh tình trạng trên là thông qua thiết kế và kiểm thử tốt.
3.2.3 Cấu trúc và Giải thuật
Ứng dụng đƣợc xây dựng với 3 thành phần chính:
- UI – User Interface (giao diện ngƣời dùng) là các trang web hiển thị giao diện tìm kiếm, kết quả và các thông tin khác. Từ giao diện này ngƣời dùng chọn lựa danh sách cơ sở dữ liệu cần tìm, đƣa vào câu truy vấn và gửi tới ZetMonitor – Bộ quản lý các luồng Z39.50 client. UI cũng nhận kết quả trả về và các thông tin khác để hiển thị cho ngƣời dùng.
- ZetMonitor – Bộ quản lý luồng Z39.50 client. ZetMonitor nhận câu lệnh truy vấn và danh sách cơ sở dữ liệu đích từ tầng UI. Khởi tạo các luồng
Z39.50 client, mỗi luồng làm việc với 1 cơ sở dữ liệu. Số lƣợng các luồng đƣợc qui định bằng kích thƣớc mảng các luồng Z39.50 client theo cấu hình đảm bảo hệ thống hoạt động hiệu quả. Mỗi luồng khi gặp lỗi hoặc hoàn thành nhiệm vụ sẽ đƣợc loại bỏ khỏi mảng các luồng và một luồng khác làm việc với cơ sở dữ liệu mới sẽ đƣợc đƣa vào cho đến khi hết danh sách cơ sở dữ liệu đích, hoặc lệnh hủy ZetMonitor đƣợc gọi. ZetMonitor quản lý một mảng kết quả trả về từ phía các luồng Z39.50 client và cung cấp theo yêu cầu của tầng UI. Mảng kết quả trả về không có độ dài cố định, nó sẽ đƣợc mở rộng khi ngƣời dùng duyệt tới gần cuối mảng.
- ZetThread – Luồng Z39.50 client là một Z39.50 client, khi đƣợc khởi tạo nhận câu truy vấn và thông tin cơ sở dữ liệu đích từ ZetMonitor. Khi chạy sẽ kết nối và gửi yêu cầu đến Z39.50 server. Nếu gặp lỗi sẽ gửi tình trạng đến ZetMonitor để ZetMonitor loại bỏ ZetThread này khỏi mảng và thêm ZetThread khác vào nếu có. ZetThread nhận thông tin số biểu ghi trả về từ Z39.50 server, thực hiện tải về bản ghi lần lƣợt. Với mỗi bản ghi tải về xong ZetThread cố gắng gửi tới ZetMonitor, nếu đƣợc ZetMonitor chấp nhận nó sẽ lấy bản ghi tiếp và gửi cho ZetMonitor, nếu không, nó nằm nghỉ một lát và gửi lại. Cứ nhƣ vậy cho đến khi hết kết quả hoặc nó bị hủy đi.
Việc xây dựng một lƣợc đồ cho loại ứng dụng đa luồng gặp nhiều khó khăn do tính chất phức tạp của các trạng thái. Do vậy tôi cố gắng đƣa ra mô tả về cấu trúc và hoạt động của các thành phần chƣơng trình nhƣ trên.
3.2.4 Sơ đồ lớp và mã nguồn chính 3.2.4.1 Class Diagram