Lời cảm ơn
Kính gởi lời cảm ơn chân thành nhất đến thầy Trương Hồng Lónh, người đã tận tình hướng
dẫn, giúp đỡ để đề tài luận văn này được hoàn thành.
Xin trân trọng cảm ơn thầy Lê Nam Hiến đã nhiệt tình chỉ dẫn chúng em trong giai đoạn
thực tập tốt nghiệp.
Xin gởi lời cảm ơn thương yêu nhất đến gia đình đã rất quan tâm và khuyến khích trong
suốt thời gian thực hiện đề tài tốt nghiệp này.
Cũng xin cảm ơn tất cả các thầy cô đã nhiệt tâm giảng dạy và những bạn bè đã gắn bó, hỗ
trợ chúng tôi.
Nguyễn Thanh Bình
Nguyễn Thò Thu Hiền
1
Giới thiệu đề tài
- IĐề tài
Tìm hiểu cơ chế RMI của Java và xây dựng một môi trường hỗ trợ
tính toán song song và phân bố .
- IIGiới thiệu
Luận văn này giới thiệu một phương hướng suy nghó và hiện thực một môi trường hỗ trợ
việc tính toán song song và phân bố bằng cách sử dụng cơ chế RMI trong Java. Chương
trình hiện thực của luận văn này là một ứng dụng cung cấp cho người sử dụng những tính
năng cơ bản để có thể điều khiển môi trường tính toán một cách dễ dàng tiện dụng.
Về những tính năng kỹ thuật của môi trường ta có thể nói rằng môi trường cho phép người
sử dụng có thể sử dụng các tài nguyên phân bố trên mạng. Cụ thể hơn, môi trường cung
cấp cho người sử dụng khả năng sử dụng bộ nhớ và khả năng xử lý của CPU của những
máy tính được nối với nhau trên mạng.
Chương trình hiện thực còn phục vụ được nhu cầu cần có một cơ chế truy xuất và quản lý
hiệu quả các tài nguyên tính toán trên mạng. Ngoài ra, chương trình còn thỏa mãn nhu cầu
về tính dễ sử dụng bằng cách cung cấp một giao diện thân thiện.
Tính dễ sử dụng là nhờ môi trường hiện thực ra không đòi hỏi một sự nổ lực lớn nào từ
phía người sử dụng hệ thống. Chiến lược về cân bằng tải và các chiến lược về Fault
• Admin có thể quản lý, thống kê việc truy xuất các dòch vụ từ các Client.
• Admin có thể quản lý, kiểm soát và thống kê hoạt động của các Server, cũng như
Service trên các Server ấy, để cho hệ thống hoạt động đạt hiệu quả cao nhất.
• Làm sao để có một cơ chế thuận lợi cho người phát triển thêm các dòch vụ cho hệ
thống mà không làm ảnh hưởng đến hoạt động của các dòch vụ đã có sẵn trước đó.
• Vấn đề khắc phục lỗi xảy ra trong quá trình vận hành hệ thống.
• Làm sao để thực hiện việc phân chia công việc sao cho hiệu quả nhất có thể.
Chiến lược để thực hiện việc phân chia này như thế nào.
• Cách giải quyết tình trạng tắc nghẽn có thể xảy ra của hệ thống.(Mô hình phải như
thế nào để giảm tình trạng tắc nghẽn này).
• Làm sao giải quyết các vấn đề ưu tiên trong hệ thống. Vì rất có thể trong quá trình
hoạt động của hệ thống sẽ có một số dòch vụ cần phải có độ ưu tiên cao.
Chương trình sẽ được hiện thực bằng ngôn ngữ Java. Tuy nhiên, bên cạnh việc tìm hiểu cơ
chế RMI, cần có thêm một cơ sở lý thuyết về một số cơ chế nhằm hỗ trợ trong việc xây
dựng chương trình. Các cơ sở lý thuyết cơ bản chẳng hạn thế nào là ứng dụng phân bố, các
cơ chế Serialization, Dynamic Class Loading, Security, Multithread, Registry, Codebase,
Activation, Naming… sẽ được trình bày cụ thể ở phần sau đây.
1
Phần 1 : Nghiên cứu lý thuyết
Chương 1 : Distributed
Application
Một ứng dụng phân bố là ứng dụng được phân bố trên nhiều không gian đòa chỉ khác nhau
hay trên nhiều máy khác nhau. Có nhiều phương pháp để xây dựng một ứng dụng phân
bố, ở đây ta sẽ quan tâm đến Distributed Object.
Cơ chế Distributed Object là cơ chế cho phép những object trên một máy tính nào đó gởi
những message đến những object chạy trên vùng không gian đòa chỉ bộ nhớ khác, thông
thường là thông qua mạng.
Khi cần thiết kế một hệ thống sử dụng cơ chế Distributed Object thì ta cần phải quản lý
được những vấn đề sau:
♦ Độc lập platform :
Giải pháp Distributed Object
Xây dựng một mô hình Distributed Object , theo chuẩn phải đáp ứng ít nhất những yêu cầu
sau:
• Hỗ trợ vấn đề platform không đồng nhất.
• Cho phép đònh vò một Object một cách dễ dàng.
• Giải quyết được các vấn đề về quản lý bộ nhớ.
• Hỗ trợ giao tiếp giữa nhiều ngôn ngữ lập trình.
• Quản lý giao tiếp network ở các mức dưới.
• Cung cấp một cơ chế lưu trữ những tham khảo đến một remote object.
• Thỏa mãn những tiêu chuẩn công nghiệp.
Với những hỗ trợ cho cơ chế Distributed Object hiện nay, những vấn đề cơ bản sau đây đã
được giải quyết :
• Cơ chế cho việc quản lý vấn đề giao tiếp giữa những Object với nhau thông qua
các protocol chuẩn như TCP/IP.
• Cơ chế cho việc đònh vò Remote Object.
• Cơ chế cho việc Marshaling và Unmarshaling những dữ liệu truyền qua lại trên
mạng.
• Cơ chế cho việc cung cấp một Interface cho một remote object trong không gian
đòa chỉ cục bộ .
• Các kỹ thuật để có thể tham khảo tới một Remote Object.
Hiện nay, có nhiều giải pháp thông dụng cho mô hình Distributed object, chẳng hạn như:
1
• CORBA ( Common Object Request Broker Architecture) được phát triển bởi
Object Management Group (OMG)
• DCOM (Distributed Component Object Model), được phát triển bởi Microsoft.
• RMI (Remote Method Invocation ), được phát triển bởi Sun.
Mỗi cơ chế có những đặc trưng của nó. Tùy vào tính chất đề tài mà có sự chọn lựa. Ngoài
ra khó có thể có sự so sánh chính xác. Đề tài đang được thực hiện là tìm hiểu một trong
những cơ chế về distributed object ,đó là RMI.
1
The Remote Object là một Object được tạo ra để cho phép những Object khác trên một
JVM khác gọi tới nó. Remote Object chứa một số các Method, những Method này cho
1
phép gọi từ xa và các Method này sẽ được thực thi bởi JVM gọi là Server. Các Method
này gọi là các Remote Method.
Hình 1. Remote Object, Remote Method.
- 3Name Server
Như trong RPC, Name Server là một Process đóng vai trò trung gian trong việc tìm kiếm
tham khảo tới một Remote Object nào đó, cụ thể là nó giúp Client tìm kiếm một tham
khảo (Reference) tới một Remote Object mà Client đó cần. Trong hệ thống Java RMI,
Name Server có thể là một máy bất kỳ trong hệ thống của chúng ta, Name Server phải có
một vùng nhớ gọi là Name Space dùng để chứa lại tên và đòa chỉ tương ứng của các
Remote Object trong hệ thống.
Hình 2. Name Server.
- 4Stub và Skeleton
Trong RPC, thì một phần không thể thiếu để một Process trên một máy từ xa có thể gọi
thực thi các Remote Method của các Remote Object trên một máy Server nào đó là các
1
chương trình Client Stub và Server Stub (Java RMI gọi là Stub và Skeleton). Để có một
cái nhìn cụ thể hơn, ta sẽ trình bày về nhiệm vụ của Stub và Skeleton.
Những công việc được thực hiện bởi Stub trong Java RMI:
• Tạo một cầu nối với JVM có chứa Remote Object mà Client cần.
• Marshals các tham số cần cho việc gọi hàm và thực hiện việc gửi chúng đi.
• Chờ kết quả trả về từ lời gọi hàm.
• Unmarshals gói dữ liệu nhận được để đọc các giá trò trả về hay các Exception trả
về từ lời gọi hàm.
• Trả kết quả về cho chương trình Client thực sự.
• Ngoài ra, Stub còn đóng một vai trò khác quan trọng, đó là Stub sẽ nắm giữ một
tham khảo tới Remote Object để Remote Object không bò Giải phóng bởi trình
Gabage Collection tự động của Java.
truyền nhận thông tin qua lại với nhau.
- 1Cơ chế hoạt động :
Hoạt động cụ thể của một chương trình RMI chúng ta có thể biểu diễn như sau :
Hình 4. Cơ chế hoạt động của chương trình RMI.
Như hình trên ta có thể thấy cơ chế hoạt động của một chương trình RMI như sau :
1
(1) Trên Server có một số các Remote Object với các Remote Method muốn cho phép gọi
từ xa, thì người viết các Remote Object đó phải bố trí các Stub, Skeleton và các Remote
Interface trên WEB Server sao cho JVM khác có thể truy cập được, cụ thể hơn là Client
hay RMIRegistry có thể truy cập được.
(2) Server đó phải đăng ký với Registry để báo cho các JVM đóng vai trò Client biết là
Server đã sẵn sàng phục vụ.
(3) Registry nhận được lời yêu cầu đăng ký, nó sẽ tự động thực hiện việc Load Stub Class
trên Web Server dựa vào codebase mà Remote Object cung cấp. Việc làm này được thực
hiện một cách tự động nhờ cơ chế Load Class động trong Java, vì vậy thao tác này người
lập trình không phải quan tâm đến mà chỉ cần cung cấp một codebase chính xác để
Registry có thể đi tìm.
Chú ý : Registry sẽ truy cập Stub Class File bằng URL Protocol. Nghóa là Registry chỉ
gửi một yêu cầu truy cập Stub Class File theo URL Protocol đến cho WEB
Server để nhờ WEB Server trả về cho Registry Stub Class File. Một cách rõ
ràng hơn là Registry sẽ không trực tiếp thực hiện việc truy cập Stub Class
File trên một JVM khác.
(1) (4) Khi Client cần gọi thực thi một Remote Method nào đó, Client phải gửi một
Message đi hỏi Registry để có được tham khảo tới Remote Object mà nó cần.
(2) (5) Sau khi đã có tham khảo tới Remote Object cần thiết rồi, Client sẽ tự động thực
hiện việc Load Stub Class theo cơ chế Load Class động trong Java.
(3) (6) Client gửi yêu cầu thực thi một Method nào đó mà nó cần với đầy đủ các tham số
cần thiết.
Các đường không liên tục là biểu diễn cho các bước mà người lập trình không nhìn thấy
được do Java đã tự động làm.
có một tên gợi nhớ. Những client từ xa sẽ tham khảo đến các Object này bằng tên
này.
Hinh 6. Naming Service
. b Vấn đề truyền tham số trong lời gọi hàm
Trong Java RMI, tham số cho lời gọi hàm hay giá trò trả về từ lời gọi hàm đều có thể là
một Object nào đó, với điều kiệu Object đó có thể “Serialize” được. Ở đây ta xét đến việc
1
Naming
bind()
Naming Reg istry
name
Remote Object
name
Naming Reg istry
Remote Object
Server
rmi://server/name
Client
Remote
reference
truyền nhận cụ thể trong Java là thực chất là truyền cái gì, khi một Object nào đó được gọi
là truyền đi.
♦ Truyền Non-Remote Object :
Khi một Non-Remote Object được truyền đi, thực chất là Object đó được Copy thành
một Object mới sau đó nó được Serialize rồi được truyền đi cho người nhận. Vì vậy,
Non-Remote Object là một tham số nó sẽ được Copy từ một Object có sẵn và bên
nhận sẽ khôi phục lại Object đó từ chuỗi các Byte, còn nếu Non-Remote Object là
giá trò trả về nó sẽ được tạo mới và truyền đi.
Hình 7. Truyền Non-Remote Object.
♦ Truyền Remote Object :
Các đặc điểm này sẽ được trình bày một cách rõ ràng hơn trong các phần sau .
Tóm tắt
Tóm lại, cơ chế RMI trong Java là một cơ chế cho phép gọi hàm từ xa. Cơ chế này
giải quyết việc đònh vò Remote Object bằng cơ chế Name Server như đã nêu trên. Về
nguyên tắc hoạt động thì nhìn chung có 6 bước nhưng Java đã đảm nhận cho ta một
phần và người lập trình chỉ còn phải thực hiện 3 bước mà thôi.
Thêm vào đó là RMI có những đặc điểm chính yếu là : cho phép sử dụng Thread
trong RMI, RMI có hỗ trợ cơ chế dọn rác và RMI có hỗ trợ việc Load Class động. Với
đặc điểm cuối cùng này, RMI cho phép Client có thể gửi một Object lên cho Server
thực thi hộ một vài Method. Điều này lợi thế hơn hẳn so với các hiện thực cho việc
gọi hàm từ xa đã có trước đây.
1
Chương 3 : Một số kỹ thuật liên quan
- VIIDynamic Class Loading
Java RMI khác với RPC là nó cho phép các giá trò trả về hay các tham số truyền cho hàm
là một Object thực thụ, Object với những dữ liệu và các hành vi như đã khai báo Object
đó. RMI sử dụng kỹ thuật Serialization một Object để gửi nhận Object giữa các Java
Virtual Machine(JVM) với nhau. Và cũng nhờ kỹ thuật này Java cũng cho phép Load
Class động.
Ta nói Java cho phép người sử dụng có thể Load Class động, vậy Load Class động là như
thế nào ? Load Class động có ưu điểm gì ? Phần trình bày sau đây sẽ trả lời các câu hỏi
này.
- 1Ví dụ về Load Class động
Với ý tưởng về RPC, trên thực tế đã có nhiều hiện thực của ý tưởng này. Ví dụ như Sun
RPC, Xerox Courier,…nhưng hầu hết các hiện thực đó việc Load Class động không được
đề cập đến. Khi một hàm cho phép gọi từ xa được biên dòch trên Server, các Client Stub
và Server Stub được tạo ra và vì vậy đối với Client Stub thì nó chỉ phục vụ cho Client
những hàm đã có khai báo trong Client Stub bởi Server, hơn thế nữa là Client Stub chỉ
phục vụ những hàm với các kiểu dữ liệu của tham số và kiểu dữ liệu của trò trả về là một
kiểu nhất đònh nào đó không thể thay đổi được nữa.
và chạy chương trình bởi vì dễ thấy rằng nếu muốn truyền các giá trò trả về hay các tham
số cho một hàm từ xa nào đó, mà các giá trò này thuộc kiểu dữ liệu khác với khai báo hàm
thì ta phải thực hiện biên dòch lại chương trình tại Server.
Trên đây là một ví dụ cụ thể đối với Remote Method. Qua đó ta cũng có thể phần nào
thấy được việc Load Class động là như thế nào !
- 2Load Class động là gì ?
Java đã cung cấp cho ta một cách để khắc phục được yếu điểm không uyển chuyển đã
trình bày ở ví dụ trên, đó là Java cho phép Load Class động.
Load Class động là một cơ chế sẽ được Java thực hiện nếu như trong lúc thực thi chương
trình mà Java phải tham khảo đến một Object thuộc một Class A mới nào đó mà JVM
hiện tại chưa có đònh nghóa của Class A này thì Java sẽ tự đi load Bytecodes của A và tạo
mới một Instance của A để công việc được tiếp tục. Từ đó, ta dễ thấy rằng việc tìm kiếm
Bytecode Class mới của JVM phải do người lập trình chỉ đònh để chương trình có thể chạy
một cách chính xác. Do đó, Java cho phép người lập trình có thể chỉ đònh nơi tìm kiếm các
Bytecode này thông qua CLASSPATH và codebase. Chúng ta sẽ xem xét sau về phần
này.
1
Hình 9. ClassA là một Class mới đối với Server.
Java RMI cũng cho phép việc Load Class động, nghóa là trong các gói dữ liệu truyền qua
lại giữa Client và Server có một vùng thông tin để chứa lại thông tin đặc tả Class A nào
đó mà Object của A đó được truyền đi trong gói dữ liệu tương ứng. Điều này giúp Java có
thể xác đònh xem có cần phải đi Load Bytecode để phục vụ cho mục đích tạo lại Object từ
dữ liệu nhận được hay không ?
Chú ý là chỉ đối với những Object mới được thực hiện điều này, với kiểu dữ liệu nguyên
thủy (ví dụ: kiểu int, float …) thì do Java không hỗ trợ việc tự động chuyển đổi kiểu nên
RMI cũng không hỗ trợ việc chuyển đổi kiểu trong việc gọi hàm từ xa.
Điều này có nghóa là khi có một khai báo hàm tại Server và hàm này có các giá trò trả về
hay các tham số là Object của một Class A nào đó, thì khi gọi hàm hay khi trả kết quả về
thì ta có thể thay Object thuộc chính xác Class A đó bằng một Object thuộc Class B, với
điều kiện là Class A và Class B là hai Class tương đương nhau. Đây chính là ưu điểm của
đó, khi cần ta có thể khôi phục lại Object đó bằng các Byte biểu diễn đối tượng đó, với tất
cả các dữ liệu và hành vi giống như Object trước đó. Công việc chuyển đổi một Object
trong bộ nhớ thành một chuỗi các Byte vật lý gọi là Serialize một Object.
Hình 10. Serialization
Việc lưu trữ và phục hồi những object không đơn giản như việc lưu trữ là phục hồi các
kiểu dữ liệu nguyên thủy. Không phải chỉ lưu object bằng cách ghi các byte biểu diễn
Object đó xuống, và khi phục hồi một object cũng vậy. Những Object được lưu trữ (store)
và phục hồi (retrieved) thường xuyên tham khảo đến những object khác. Trong khi đó
việc lưu chứa một Object trong bộ nhớ thì dễ dàng nhờ trong bộ nhớ việc biểu diễn các
mối liên hệ giữa các Object dễ dàng, nhưng khi lưu Object đó xuống dóa thì khó có thể
biểu diễn được các mối liên hệ đó, và khi khôi phục lại Object đó trong bộ nhớ thì việc
tạo lại mối liên hệ giữa các Object là một vấn đề, vì một lý do đơn giản là không chắc lúc
nào ta cũng tạo được các Object tại các đòa chỉ trong bộ nhớ mà chúng giống như vò trí
của Object trước đó. Do đó, cần có một cơ chế để quản lý vấn đề này, làm sao để lưu trữ
và lấy những object lên mà vẫn đảm bảo chính xác những tính chất , trạng thái , duy trì
được những quan hệ giữa những đối tượng . Serialization là một cơ chế thực hiện công
việc này.
1
Vấn đề Serialization cũng được đặt ra khi truyền một Object từ JVM này đến JVM khác,
đó là do khi truyền một Object ta phải truyền thành một chuỗi các Byte, rồi sau đó ta cũng
phải khôi phục lại Object đó dựa trên các Byte này.
Vì vậy, vấn đề Object Serialization cũng là một vấn đề cần quan tâm trong RMI. Trong
Java, người ta đã cung cấp cho chúng ta một số các Interface tên là Serializable Interface
và Externalizable Interface, nhằm phục vụ cho mục đích Serialize một Object. Do đó, nếu
ta khai báo một Interface extends từ java.io.Serializable thì những Object nào implements
từ Interface này đều là những Object có khả năng Serialize, lúc đó ta gọi Object đó là
Seriaizable Object.
Đối với những Java Object, cách Serialized một Object là phải xác đònh và những đònh
nghóa lớp cho Object phải được kiểm tra bởi Java, để từ đó nội dung của Object được store
một cách chính xác và việc restore nội dung thành một instance mới được thực hiện một
khiển qua external format và trạng thái của supertype được save và restore như thế vào.
Trong việc xây dựng ứng dụng phân bố sử dụng RMI, vấn đề Serialization luôn được
quan tâm vì có việc truyền các Object xảy ra.
- IXMultiThread
- 1Khái niệm MultiThread
Có thể nói Process ( Quá trình ) là một chương trình đang chạy. Trong một hệ thống, đối
với một Process để nó có thể thực thi được, thì nó cần được hệ thống cung cấp một vùng
nhớ để chứa lại các thông tin quản lý Process, vùng nhớ để chứa mã lệnh của chương
trình, vùng nhớ để chứa dữ liệu của chương trình, một vùng Stack và quan trọng là một
dòng xử lý (Thread). Dòng xử lý là dòng điều khiển CPU để xử lý công việc nào đó, trong
một dòng điều khiển cụ thể sẽ có một số câu lệnh được thực thi một cách tuần tự nhằm
mục đích thi hành một việc gì đó. Vì vậy, một Process ít nhất phải có một Thread để có
thể làm việc được. Và có thể có nhiều Thread thực hiện một số công việc độc lập nào đó.
Một chương trình Multithread là một chương trình ở cùng thời điểm có nhiều Thread cùng
chạy, có nghóa là tồn tại nhiều tập những dãy lệnh tuần tự (Instruction Sequence) được
thực thi đồng thời. Mỗi Instruction Sequence có một dòng điều khiển độc lập với những
dòng khác.
Phân biệt Multiprocess và Multithread
Multiprocess cung cấp sự đồng thời giữa các process. Mỗi Process được cấp vùng không
gian đòa chỉ riêng, có các tài nguyên riêng.
Hình 11 Phân biệt MultiThread và MultiProcess.
1
Multithread cung cấp sự đồng thời trong ngữ cảnh của một Process. Multithread chia sẻ
dòng điều khiển trong một Process. Những Thread trong một chương trình MultiThread
được thực thi trên cùng một vùng dữ liệu chung, chính là vùng dữ liệu của hệ thống cấp
cho Process. Nếu có một biến global nào đó thay đổi trong một Thread nào đó thì tất cả
các Thread khác cũng bò thay đổi. Nói tóm lại, các Thread dùng chung tài nguyên và
cùng không gian đòa chỉ.
Lợi điểm của Thread
• Thread mất ít thời gian để tạo và loại bỏ so với việc tạo và loại bỏ Process.
• Hàm suspend() được gọi
• Thread gọi hàm wait
• Thread gọi một thao tác input/output.
♦ Dead:
Một thread dead bởi một trong hai lý do sau:
• Nó dead vì run method exit
• Nó bò kill bởi hàm stop() được gọi.
- 4Garbage collector thread
Java cung cấp Garbage Collector Thread để giải phóng một cách tự động và đònh vò
lại bộ nhớ động (dynamically allocated memory).
Bộ thu dọn rác của Java chạy như một thread có độ ưu tiên thấp, khi Java xác đònh
không có một tham khảo nào đến đối tượng điều khiển Thread nhất đònh nào đó nữa,
nó đánh dấu đối tượng đó. Garbage collector thread chạy khi hệ thống cho phép
(processor time available) và không có một Runable thread có độ ưu tiên cao hơn.
Tuy nhiên, garbage collector thread sẽ chạy ngay tức thì khi hệ thống hết bộ nhớ để
cung cấp cho chương trình khác(out of memory).
Cơ chế Garbage Collection của Java không phải là một cơ chế quản lý bộ nhớ động
hiệu quả, nhưng nó là một cơ chế nhằm mục đích an toàn cho người lập trình.
- 5Thread Synchronization
Một thread đang chạy có thể truy cập bất cứ đối tượng nào mà nó có một reference
đến. Điều gì xảy ra khi hai thread cùng truy cập một đối tượng, và mỗi thread gọi
một method mà nó modify trạng thái của object đó . Synchronization giải quyết vấn
đề này.
Java dùng monitor để thao tác đồng bộ . Mọi đối tượng với method synchoniation là
một monitor. Monitor chỉ cho phép tại một thời điểm chỉ có một thread thực hiện một
method synchronization trên đối tượng. Nếu có nhiều phương thức synchonization thì
chỉ có một method active còn các method còn lại phải chờ. Điều này được thực hiện
bởi việc locking đối tượng đó khi có một phương thức synchronization đang active.
Khi method đó hòan thành, lock sẽ được giải phóng và thread nào ở trạng thái ready
có độ ưu tiên cao nhất sẽ được tiếp tục .
Cú pháp cho cách này như sau :
Javac -classpath <đøng dẫn> JavaFile.java
Java -classpath <đường dẫn> JavaFile
1
• Tạo lập một biến môi trường để có thể dùng cho cả phiên làm việc. Cú pháp cho
cách này như sau :
Set CLASSPATH = <đường dẫn> ;
Javac JavaFile.java
Java JavaFile
Với Unix ta cũng có các cách set Classpath tương tự như trên nhưng với cú pháp khác
đi. Cụ thể cho việc này chúng ta có thể sẽ trình bày sau.
- 3URL
Để hiểu về codebase thì đầu tiên ta sẽ trình bày một cách sơ lược về URL.
URL là viết tắt của Uniform Resource Locator, có thể nói URL là một “đường dẫn”
của một file hay Directory trên mạng. URL dùng để chỉ đến một vò trí xác đònh trên
mạng.
Có 5 loại URL : file, http, gopher, news, partials.
Cú pháp chung của một URL là :
<protocol>://<đòa chỉ máy>:<port>/<đường dẫn resource>/<tên resource>
♦ File URL :
Áp dụng cú pháp chung trên thì file URL chỉ tới file foobar.txt trong thư mục
pub/files/ trên máy file Server tên là “ftp.yoyodyne.com”:
file://ftp.yoyodyne.com/pub/files/foobar.txt
tương tự ta có file URL chỉ tới thư mục "pub" trên máy FTP Server :
file://ftp.yoyodyne.com/pub
♦ Http URL :
Ví dụ :
/>:1234/pub/files/foobar.html
♦ Gopher URL :
Ví dụ :
Copyright: Tài liệu đại học ©