Trong phần này chúng ta sẽ giải quyết vấn đề là làm thế nào để RMIRegistry hay một JVM khác đang chạy chương trình Client có thể truy cập được Stub, Skeleton tại JVM Server.
Khi một Remote Object đăng ký với RMIRegstry thì do Java có hỗ trợ việc load Class động nên RMIRegistry sẽ tự động thực hiện việc truy cập tới các Stub Class và Skeleton. Điều này dẫn đến một vấn đề là Java sẽ tự động tìm các Stub (Skeleton) Class ở nơi nào ? Với cơ chế load class động của Java thì các class sẽ được tìm theo trình tự sau:
• Tìm trong các đường dẫn được đặt trong biến môi trường CLASSPATH. • Tìm trong các đường dẫn được cung cấp khi chạy chương trình.
• Tìm trong các đường dẫn đặt trong Property codebase.
Về vấn đề này đã được trình bày chi tiết trong phần CLASSPATH và CODEBASE. Trong trường hợp của chúng ta, vì chúng ta đang hiện thực một môi trường phân bố, do đó cách chúng ta lựa chọn là codebase, vì CLASSPATH chỉ phục vụ cho những yêu cầu về Load Class tại Local JVM và mỗi khi chạy chương trình chúng ta không muốn phải thực hiện lại việc cung cấp đường dẫn cho Stub Class. Vì vậy xin nhắc lại cách chúng ta lựa chọn ở đây là CODEBASE.
Mặt khác, theo nguyên tắc, thì một chương trình trên một Host không thể tự nó truy cập vào một file nào đó trong hệ thống file của một Host từ xa, bởi vì một lý do đơn giản là Local Host không biết Host từ xa tổ chức hệ thống file của chính nó như thế nào. Vì vậy, khi chương trình trên một JVM muốn truy cập thông tin trên một file nào đó trên một JVM từ xa thì đầu tiên nó phải có quyền truy cập file đó, sau đó nó phải gửi tới một chương trình trên JVM từ xa một yêu cầu truy cập file, nhờ chương trình đó truy cập và trả kết quả truy cập về cho nó.
Hình 33 . Machine B không truy cập trực tiếp được File trên Machine A
Do đó, khi RMIRegistry hay chương trình Client trên một JVM từ xa muốn truy cập Stub class trên Server JVM thì chúng cũng phải tuân theo đúng nguyên tắc này. Và cũng vì lý do đó mà nguyên tắc hoạt động của cơ chế RMI bắt buộc chúng ta phải bố trí Stub và Skeleton trên Web Server, để Web Server đóng vai trò là người trung gian trực tiếp thực hiện việc truy cập File tại Local JVM.
Chúng ta có thể xem xét rõ ràng hơn về việc Load class động của Java và chúng ta có thể thấy rằng khi cần một Class mới mà JVM hiện tại chưa có, mà Java bắt buộc phải dùng codebase để truy cập tới Stub class trên một máy từ xa, thì theo nguyên tắc nêu trên, Java sẽ chỉ tự động gửi một lời yêu cầu truy cập file class đó đến máy và port mà nó biết được thông qua codebase. Java chỉ thực hiện gửi yêu cầu tới mà không thực hiện việc truy cập thực sự, điều này có nghĩa là khi một Remote Object chạy trên một máy bất kỳ, không phải là File Server hay WEB Server mà là một máy nào đó trên mạng các máy tính được nối với nhau, thì khi nhận được yêu cầu này sẽ không có chương trình nào đứng ra thực sự thực hiện việc truy cập tới file class cần thiết để trả về cho lời yêu cầu đó, điều đó dễ dàng dẫn đến việc RMIRegistry không tìm thấy file Stub class mà nó cần.
Vì vậy cách giải quyết cho vấn đề này là đối với chương trình Server ngoài việc tạo ra Remote Object nó còn tạo ra một chương trình (Object), giả lập Web Server, ra đứng chờ tại port có trong codebase, để chờ nhận lời yêu cầu truy cập file Class và thực hiện việc truy cập tới file Class sau đó trả về file Class cho chương trình yêu cầu. Object này được tạo ra từ một định nghĩa Class, trong chương trình này thì Class này được đặt tên là ClassFileServer.
Ngoài ra, có một điều cần phải chú ý là khi một JVM gửi một yêu cầu đến cho một JVM từ xa thì lời yêu cầu này được format theo dạng chuẩn là HTTP Request.
Hình 34. Machine B có thể truy cập File trên Machine A nhờ ClassFileServer.
ClassFileServer Yêu cầu :
Giả lập chương trình Web Server hay File Server trên một mạng máy tính. Nghĩa là chương trình này sẽ đứng tại một Port nào đó của Local JVM, chờ nhận một yêu cầu truy cập file từ một máy nào đó, sau đó thực hiện việc truy cập file đó tại Local JVM và thực hiện việc truyển file cần thiết về cho chương trình yêu cầu.
Giải thuật :
Đây là một chương trình tham khảo của Sun Microsystems, Inc. Do đó, những phần trình bày sau đây là phần đọc hiểu để có thể sử dụng chương trình một cách hiệu quả.
Hình 35. Thuật giải chương trình ClassFileServer
Giải thích :
• Tạo ServerSocket tại một port do ta cung cấp cho chương trình qua hàm tạo của ClassFileServer.
• Chương trình sẽ thực hiện đọc file tại Local JVM dựa vào đường dẫn chỉ đến nơi chứa file cho phép truy cập, đường dẫn này do ta cung cấp qua hàm tạo của ClassFileServer.
Kết luận
Với giải thuật như trên thì ta đã hoàn thành việc viết một chương trình giả lập Web Server nhằm hoàn tất cho cơ chế load class động của Java.
Tóm lại, ta đã giải quyết được vấn đề là làm thế nào để RMIRegistry hay một JVM khác đang chạy chương trình Client có thể truy cập được Stub, Skeleton tại JVM Server.