Nâng cấp động các thành phần của hệ thống phân tán

iii



MỤC LỤC

LỜI CAM ĐOAN i
LỜI CẢM ƠN ii
MỤC LỤC iii
DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT v
DANH MỤC CÁC HÌNH VẼ vi
MỞ ĐẦU vii
CHƢƠNG 1. GIỚI THIỆU 1
1.1 Giới thiệu chung 1
1.2 Yêu cầu, thách thức hiện tại 2
1.3 Hƣớng đề xuất 3
CHƢƠNG 2. NGHIÊN CỨU LIÊN QUAN 4
2.1 UpgradeJ 4
2.2 Sử dụng kĩ thuật tái cấu trúc ngăn xếp 7
2.3 Xây dựng lớp động cho đối tƣợng tƣơng tranh không đồng bộ 9
CHƢƠNG 3. PHƢƠNG PHÁP NÂNG CẤP ĐỘNG HỆ THỐNG PHÂN TÁN 18
3.1 Hệ thống phân tán 18
3.2 Mô hình nâng cấp 21
3.3Hàm lịch trình 25
3.4 Đối tƣợng mô phỏng 26
3.5 Hàm chuyển 28
CHƢƠNG 4. THỰC NGHIỆM VÀ MÔ PHỎNG 30
4.1 Phân tích hệ thống 30
iv

4.1.1. Biểu đồ ca sử dụng (biểu đồ Use case) 31
4.1.2 Biểu đồ trình tự 32
4.1.3 Biểu đồ lớp 37
4.1.4. Thiết kế dữ liệu 37
4.2 Mô hình nâng cấp hệ thống 38
4.3 Thử nghiệm 40
KẾT LUẬN 43
TÀI LIỆU THAM KHẢO 44


v



DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT
Thuật ngữ,chữ viết tắt
Giải thích
SOs
Simulation Objects
Đối tƣợng mô phỏng
PastSOs
Past Simulation Objects
Đối tƣợng mô phỏng phiên bản cũ
FutureSOs
Future Simulation Objects
Đối tƣợng mô phỏng phiên bản mởi
TFs
Transform Functions
Hàm chuyển

SFs
Scheduling Functions
Hàm lịch trình
UML
Unified Modeling Language
Ngôn ngữ mô hình hóa thống nhất
Ngang hàng
Peer to peer


vi



DANH MỤC CÁC HÌNH VẼ
Hình 2.1 Revision upgrade 6
Hình 2.2 Evolution upgrade 6
Hình 2.3 Kiến trúc hệ thống UpStare 8
Hình 3.1 Kiểu phân chia chức năng giữa Client và Server 18
Hình 3.3 Kiến trúc ngang hàng 19
Hình 3.4 Liên lạc bằng phƣơng thức gọi hàm từ xa RPC 20
Hình 3.5 Làm thế nào để nâng cấp xảy ra 21
Hình 3.6 Nâng cấp 2 nút từ phiên bản V lên phiên bản V+1 23
Hình 3.7 Nâng cấp 4 nút từ phiên bản V lên phiên bản V+1 24
Hình 3.8 Gọi giữa các phiên bản. 27
Hình 3.9 Qua trình chuyển đổi SOs 28
Hình 3.10 Hàm chuyển trạng thái từ phiên bản V lên V+1 29
Hình 4.1 Biểu đồ ca sử dụng 31
Hình 4.2 Biểu đồ trình tự thiết lập chơi 32
Hình 4.3 Biểu đồ trình tự chơi game 33

Hình 4.4 Biểu đồ trình tự chơi lại 35
Hình 4.5 Biểu đồ trình tự chơi với ngƣời khác 36
Hình 4.6 Biểu đồ lớp 37
Hình 4.7 Biểu đồ trình tự nâng cấp. 38
Hình 4.8 Biểu đồ lớp phân tích khi nâng cấp 39
Hình 4.9 Thiết lập hai máy bắt đầu chơi 40
Hình 4.10 Khi máy A yêu cầu nâng cấp 41
Hình 4.11 Sau khi nâng cấp bản đồ chƣơng trình. 42

vii



MỞ ĐẦU
Các hệ thống thông tin ngày nay đang từng ngày mở rộngđể phục vụ với nhiều
mục đích khác nhau, nhất là các hệ thống phân tán đang dần khẳng định với những ƣu
thếvề chi phí, hiệu năng, khả năng mở rộng, độ tin cậy trong các hệ thốngứng dụng
nó. Với hệ thống phân tán nhƣ các cụm máy chủ, hệ thống ngang hàng trong quá trình
sử dụng luôn thƣờng xuyên đòi hỏi các yêu cầu thay đổi nhƣ thêm các tính năng, cải
thiện hiệu suất, sửa lỗi, mở rộng hệ thống. Các yêu cầu đó gọi chung là việc nâng cấp
hệ thống. Các hệ thống này rất lớn, vì vậy thực tế các quản trị viên không thể nâng
cấp các nút bằng tay (ví dụ, thông qua đăng nhập từ xa) hay nâng cấp tất cả các nút
cùng một lúc. Thay vào đó, phải có việc lan truyền tự động các yêu cầu thay đổi thông
qua hệ thống phân tán. Nhƣng yêu cầu vẫn có thể kiểm soát về trình tự, sự đồng nhất
tại đó các nút đƣợc nâng cấp để tránh làm gián đoạn dịch vụ đang cung cấp và không
làm ảnh hƣởng tới các ứng dụng có sẵn.
Vì vậy, việc nghiên cứu và đƣa ra các phƣơng pháp nâng cấp tự động cho các hệ
thống hiện nay là thực sự cần thiết. Với luận văn “Nâng cấp động các thành phần
của hệ thống phân tán”luận văn sẽ tập trung nghiên cứu làm thế nào thể đáp ứng các
yêu cầu thay đổi của hệ thống phân tán mà vẫn đảm bảo cho hệ thống hoạt động bình

thƣờng và ổn định.
Nội dung chính của luận văn đƣợc trình bày trong 4 chƣơng. Chƣơng 1 giới thiệu
chung về việc nâng cấp. Chƣơng 2 tìm hiểu các thực trạng nâng cấp và nghiên cứu các
thành phần để nâng cấp tự động hệ thống phân tán. Chƣơng 3 hƣớng đề xuất cho việc
nâng cấp động hệ thống phân tán. Chƣơng 4 thực nghiệm và mô phỏng hƣớng đề xuất.
Phần kết luận tóm tắt kết quả đã đạt đƣợc và hƣớng phát triển tiếp theo của luận văn.
1



CHƢƠNG 1. GIỚI THIỆU
Chƣơng đầu của luận văn sẽ giới thiệu chung nhấtnhu cầu thực thế của việc nâng
cấp tự động cho các hệ thống phân tán hiện nay, cũng nhƣ mục đích, yêu cầu, các
thách thực khi nâng cấp với các hệ thống thực tế hiện nay, và đƣa ra bài toán, hƣớng
giải quyết việc tự động nâng cấp hệ thống phân tán trong luận văn này.
1.1 Giới thiệu chung
Các dịch vụ hiện nay đang ngày phát triển với quy mô rộng lớn, luôn thay đổi
phù hợp với những thách thức và yêu cầu đặt ra.Chẳng hạn nhƣ các dịch vụ trên
Internet (ví dụ, máy tìm kiếm, trò chơi trực tuyến, thanh toán trực tuyến, emai) luôn
thƣờng xuyên phải quản lý số lƣợng lớn các dữ liệu có giá trị, thƣờng xuyên thay đổi
phù hợp với nhu cầu thƣờng trực của khách hàng[16]. Để cung cấp các dịch vụ đó yêu
cầu hệ thống gồm hàng trăm ngàn máy móc, các trung tâm xử lý dữ liệu khác nhau,
thƣờng xuyên phục vụ các yêu cầu gửi nhận của khách hàng và cũng có thể bị tấn công
hay lỗi phần cứng, phần mềm và gây ra nhiều thiệt hại nghiêm trọng không lƣờng
trƣớc. Trƣớc tình hình đó, các phần mềm của hệ thống này luôn cần nâng cấp hiện
thờiđể có thể chịu lỗi, thêm các tính năng mới và cải thiện hiệu suất nhƣng vẫn đảm
bảo đáp ứng liên tục các dịch vụ đang cung cấp.
Các yêu cầu đặt ra khi nâng cấp hệ thống cần đảm bảo các dịch vụ đang cung cấp
của hệ thống không bị ngƣng, các thành phần phải đồng đều và biết mối quan hệ giữa
các phiên bản [17]. Các phiên bản mới cho phép không đƣợc tƣơng thích với các phiên

bản cũ. Bởi hiện tại vẫn còn một vài phiên bản cũ khác của hệ thống vẫn phải tiếp tục
hỗ trợ. Và đặc biệt khi nâng cấp các trạng thái trong các nút vẫn đảm bảo các trạng
thái khác hoạt động bình thƣờng để cung cấp các dịch vụ hiện thời.
Quá trình nâng cấp là rất khó khăn đối với các hệ thống, đặc biệt là các hệ thống
phân tán, thƣờng đòi hỏi cung cấp dịch vụ liên tục. Có rất nhiều thách thức cũng nhƣ
nhiều yêu cầu đƣợc đƣa ra để giải quyết tốt vấn đề này. Trong một hệ thống ta không
thể nâng cấp tất cả các nút trong cùng một thời điểm, vì mỗi lần nâng cấp ta cần xác
2



định và định nghĩa lại lịch trình khi nâng cấp các nút, hay các nút đang chạy phiên bản
khác nhau vẫn có thể cần phải tƣơng tác với nhau để hoàn thành nốt những yêu cầu
nào đó.
1.2 Yêu cầu, thách thức hiện tại
Trƣớc những nhu cầu và thực trạng thực tế đòi hỏi, khi nâng cấp hệ thống phân
tán cần đảm bảo một số các yêu cầu sau:
Thứ nhất là tính đơn giản, nghĩa là mô hình nâng cấp cần phải dễ sử dụng, cần
phải biết mối quan hệ giữa các phiên bản khi nâng cấp xẩy ra.
Tiếp theo cần phải đảm bảo tính tƣơng thích, các phiên bản mới cho phép phải
đƣợc tƣơng thích với các phiên bản cũ, bởi trong thời gian nâng cấp, một vài phiên bản
khác của hệ thống vẫn phải tiếp tục hỗ trợ và cung cấp dịch vụ cho các yêu cầu đang
thực thi. Do vậy hệ thống phải luôn đảm bảo các dịch vụ xuyên suốt trong quá trình
nâng cấp.
Trên thực tế, các hệ thống phân tán hiện nay có rất nhiều các nút và đƣợc đặt rải
rác ở nhiều vị trí. Do vậy để đảm bảo cho việc nâng cấp nhanh chóng, không tốn nhiều
công sức, thời gian và tiền bạc thì quá trình nâng cấp nên tự động triển khai không cần
nâng cấp bằng tay tại từng nút. Nghĩa là khi một nâng cấp đƣợc định nghĩa tại một vị
trí trung tâm, thì từ đó hệ thống nâng cấp sẽ tự động lan truyền nhận biết việc nâng
cấp, sau đó tải các tệp tin và tự động cài đặt trên các nút khác trên cùng hệ thống.

Cuối cùng khi nâng cấp luôn cần kiểm soát các quá trình triển khai. Các trình
nâng cấp phải có khả năng kiểm soát khi các nút nâng cấp với độ chính xác giống nhƣ
khi nâng cấp bằng tay từng nút. Để tránh trƣờng hợp xẩy ra lỗi lan truyền và đồng thời
không nhận biết đƣợc nút nào nâng cấp thành công hay lỗi.
Chính từ những yêu cầu thực tế trên nhận thấy quá trình nâng cấp động tƣơng đối
khó khăn và có nhiều thách thức nhƣ:
 Không thể nâng cấp đồng thời các nút cùng một lúc.
 Một nút có thể chạy trên nhiều hơn một phiên bản hay không?
3



 Đảm bảo nâng cấp luôn đáng tin cậy mọi thời điểm hay không?
Để khắc phục những khó khăn trênmột cách triệt để là tƣơng đối khó thực hiện.
Do vậy để quá trình nâng cấp diễn ra thành công và luôn đảm bảo những yêu cầu đặt
ra, trong luận văn này tôi sẽ đƣa ra hƣớng giải quyết sẽ trình bầy chi tiết ở các phần
tiếp theo của luận văn.
1.3 Hƣớng đề xuất
Từ những yêu cầu và thách thực thực tế đặt ra ở trên, trong khuôn khổ luận văn
này, mục tiêu chính là hỗ trợ việc nâng cấp tự động các thành phần của hệ thống phân
tán và cho phép hệ thống vẫn cung cấp đầy đủ các dịch vụ trong quá trình nâng cấp.
Để nâng cấp thành công yêu cầu hệ thống cần đảm bảo những yêu cầu sau:
 Nâng cấp lan truyền từ một nút tới các nút tiếp theo;
 Nâng cấp tự động tại mỗi nút;
 Hệ thống vẫn cần phải cung cấp dịch vụ khi khác nút khác chạy với phiên
bản khác nhau.
Khi một nút nâng cấp thành công, các nút đang trỏ tới đó sẽ theo lịch trình lan
truyền để nâng cấp động tại các nút tiếp theo. Tại mỗi nút sẽ thực hiện cơ chế tự nhận
biết có phiên bản mới và tự tải các tệp tin theo đúng lịch trình. Để đảm bảo trong quá
trình nâng cấp các dịch vụ vẫn đảm bảo và đáp ứng đầy đủ khi các nút chạy với các

phiên bản khác nhau cần có các đối tƣợng mô phỏng các phiên bản trƣớc và sau đó.
4



CHƢƠNG 2. NGHIÊN CỨU LIÊN QUAN
Chƣơng này luận văn sẽ trình bày về một vàinghiên cứu trong việc nâng cấp tự
động cho hệ thống phân tán đã nghiên cứu trƣớc đó. Từ những nghiên cứu đó luận văn
sẽ đƣa ra những điểm làm đƣợc và chƣa làm đƣợcđể làm tiền đề để giải quyết bài toán
trong luận văn này.
2.1 UpgradeJ
Đây là một kỹ thuật mà khi một chƣơng trình chạy vẫn có thể đƣợc cập nhật các
mã mới và dữ liệu vào [10]. Các tính năng chính của UpgradeJ là đáp ứng chƣơng
trình với sự tồn tại nhiều phiên bản của lớp, nâng cấp lớp động, và một mở rộng tự
nhiên của hệ thống Java để hỗ trợ phiên bản và gia tăng kiểm soát kiểu.
UpgradeJ cho phép các lớp trong hệ thống có thể cập nhật với phiên bản mới tự
động. Lệnh nâng cấp đƣợc bắt đầu bởi bởi lệnh: upgrade.
Một số kí hiệu hỗ trợ nâng cấp
 Kí hiệu “exact”, =, tạo nguyên thể lớp tất cả việc nâng cấp
 Kí hiệu “upgradeable”, +, nâng cấp hiệu chỉnh của lớp
 Kí hiệu “latest”, ++, nâng cấp mới nhất của sự tiến hóa của một lớp
UpgradeJ hỗ trợ 3 hình thức nâng cấp: New class upgrade, Revision upgrade,
Evolution upgrade.
New class upgrade, cho phép định nghĩa lớp mới thêm vào (trong thời gian
chạy) vào bảng lớp hiện tại. Nâng cấp thêm lớp mới là một cơ chế cho phép thêm các
tính năng mới vào hệ thống.
new class AnimatedButton[1] extends Button[1] {
Object fancyPress() {
this.press(); }
}

5



Revision upgrade, cho phép định nghĩa một phiên bản mới của lớp để thay thế
một định nghĩa lớp hiện có, chỉ trong thân chƣơng trình. Nâng cấp sửa đổi là một cơ
chế để thực hiện sửa lỗi khi xẩy ra trong hệ thống.
class Button[1] extends Object {
Object press(){ }
Colour bgColour() {
return new BeigeColour[1](); }
}
new class Button[2] extends Object revises Button[1]{
Object press(){ }
Colour bgColour() {
return new GreyColour[1](); }
}

new class Button[3] extends Object revises Button[2]{
Object press(){ }
Colour bgColour() {
return new TransparentAquaColour[1](); }
}
Hình 2.1 Thể hiện sơ đồ lớp cho thấy các phiên bản nâng cấp một cách rõ ràng,
và sửa đổi các mối quan hệ với một mũi tên lƣợn sóng. Ba phiên bản của lớp Button
đƣợc thể hiện nhƣ sau:
6

Hình 2.1 Revision upgrade
Evolution upgrade, cho phép định nghĩa một phiên bản mới của lớp để thay thế
một định nghĩa lớp cũ. Có thể thêm thuộc tính và phƣơng thức. Nâng cấp tiến hóa
cung cấp sự hỗ trợ cho việc phá vỡ thay đổi hiện thời.
new class Button[6] extends Object evolves Button[3]
{
Integer animationRate;
void tick() {this.redraw(); }
Colour bgColour() {
return new VistaBlackColour[1](); }

}
Hình 2.2 thể hiện sơ đồ nâng cấp tiến hóa và mối quan hệ tiến hóa giữa các lớp
học đƣợc ký hiệu bằng cách sử dụng một mũi tên "răng cƣa".

Hình 2.2 Evolution upgrade
Các tính năng chính của UpgradeJ là đáp ứng những chƣơng trình với sự tồn tại
nhiều phiên bản của lớp, nâng cấp lớp động, và một mở rộng tự nhiên của hệ thống
Java để hỗ trợ phiên bản và gia tăng kiểm soát kiểu. Bên cạnh đó kĩ thật này chỉ áp
7



dụng cho các chƣơng trình Java và không ghi lại đƣợc mức độ cập nhật giữa các đối
tƣợng.
2.2 Sử dụng kĩ thuật tái cấu trúc ngăn xếp
Kĩ thuật này đƣợc trình bày kĩ trong bài báo của Kristis Makris and Rida Bazzi
[14], nó áp dụng cho các chƣơng trình có nhiều vòng lặp lồng nhau, các hàm đệ quy,
ứng dụng đa luồng. Nó đảm bảo tất cả các hàm gọi trong ngăn xếp đều đƣợc nâng cấp

trong cùng một thời điểm, do đó loại bỏ việc chờ đợi đối với các điểm nghỉ khi xuất
hiện. Hệ thống nâng cấp, UpStare, biên dịch các ứng dụng đặc biệt với khả năng xây
dựng lại ngăn xếp và không phụ thuộc mã nguồn tĩnh các kiểu phân tích. Thêm vào
đó, nó cho phép tiếp tục thực thi các tiến trình từ một thuật toán khác mạnh hơn trong
khi sử dụng lại trạng thái chƣơng trình đang tồn tại. Với kĩ thuật tái cấu trúc ngăn xếp
chƣơng trình viết bằng C đƣợc chuyển đổi ở cấp mã nguồn trong khi vẫn giữ ngữ
nghĩa thực hiện.
Kĩ thuật này cho phép cập nhật tại hầu hết các điểmngay mà không cần chờ đợi
tới lƣợt nâng cấp. Đồng thời nó phù hợp khi nâng cấp với những chƣơng trình có tính
tƣơng đồng về thuật toán có cùng các hành vi.
8




Hình 2.3 Kiến trúc hệ thống UpStare
Hình 2.3 [14] thể hiện một chƣơng trình đƣợc biên dịch khi nâng cấp hệ thống,
liên kết lặp lại khi câp nâng cấp động trong thời gian chạy và bắt đầu. Với một phiên
bản mới hơn, bộ phát triển sẽ tạo ra một bản cập nhật tự động vào nguồn đƣợc biên
dịch và áp dụng để thực thi trực tiếp thông qua một kết nối TCP.
Với kĩ thuật tái cấu trúc ngăn xếp việc nâng cấp hệ thống đƣợc thực hiện trong
hai bƣớc chính. Trƣớc tiên, ánh xạ tái cấu trúc ngăn xếp xác định trạng thái của ngăn
xếp cũ đƣợc ánh xạ nhƣ thế nào tới trạng thái ngăn xếp mới và kiểu dữ liệu cũ đƣợc
ánh xạ nhƣ thế nào tới kiểu dữ liệu mới.Sau đó tiếp tục việc thực thi các chƣơng trình,
tại bƣớc này việc ánh xạ tiếp tục thực thi sẽ xác định trạng thái của các hàm hoạt đang
hoạt động đƣợc ánh xạ tới phiên bản mới của hàm đó. Ánh xạ có thể sơ đồ các hàm từ
phiên bản cũ lên phiên bản mới với các thuật toán khác nhau.
Tái cấu trúc ngăn xếp hoàn thành thực hiện một số mục tiêu chính nhƣ sau:
Trƣớc tiên, nó cần phải lƣu trữ trạng thái trong ngăn xếp hiện tại khi gỡ bỏ hay phục
hồi nâng cấp khi xây dựng lại. Không giống nhƣ quá trình kiểm tra các điểm của tiến

9



trình khi thực hiện, ngăn xếp đƣợc lƣu trữ và phục hồi tạm dừng các tiến trình. Nó hỗ
trợ lƣu trữ và khôi phục các khung ngăn xếp, biến cục bộ của hàm đƣợc nhóm lại xác
định rõ ràng trong cấu trúc mới. Đoạn mã phía dƣới sẽ xác định rõ lƣu trữ khung ngăn
xếp đƣợc thực hiện nhƣ thế nào?


functionA()
{


functionB(param);









}
(*functionB_ptr) (int) =
&functionB_transformed;
functionA_transformed()
{

functionB_6_before:
functionB_ptr(param);
if (must_reconstruct)
if (must_unroll_up(‘‘functionA’’)) {
save_frame(‘‘functionA’’, 7);
return;
}
goto functionB_6_before;
}

}


Việc nâng cấp phần mềm động sử dụng kĩ thuật tái cấu trúc ngăn xếp đảm bảo
rằng cập nhật tự động có thể đƣợc áp dụng ngay lập tức, bất cứ lúc nào trong suốt quá
trình thực hiện, bao gồm cả các cơ chế đa luồng lồng nhau tồn tại lâu trong vòng lặp,
các chƣơng trình gọi đệ quy. Ngoài ra, nó tiếp tục thực hiện cơ chế cho phép để tiến
hành thực thi từ một thuật toán khác nhau trong khi tái sử dụng trạng thái chƣơng trình
hiện thời.
2.3 Xây dựng lớp động cho đối tƣợng tƣơng tranh không đồng bộ
Kĩ thuật trình bày trong [9] là một cơ chế nâng cấp lớp động, cho phép kế thừa
các lớp đƣợc nâng cấp trong hệ thống mà đối tƣợng sẽ phù hợp cho việc nâng cấp
trong thời gian chạy, nhƣ việc đóng gói để phân biệt rõ ràng giữa cấu trúc bên trong và
10



dịch vụ bên ngoài. Nhƣ vậy các đối tƣợng hiện tại của lớp nâng cấp và các lớp con của
nó đƣợc phát triển trong thời gian chạy. Cơ chế này đƣợc tích hợp trong Creol [7], một
ngôn ngữ lập trình bậc cao, dành cho các ứng dụng phân tán bằng biện pháp kết nối

đối tƣợng tƣơng tranh bởi phƣơng thức gọi không đồng bộ. Nâng cấp 1 lớp tác động
tới tất cả thể hiện của lớp định nghĩa lại và của các lớp con. Hơn nữa, tất cả sự tồn tại
của đối tƣợng là thể hiện của lớp và các lớp con của nó khi nâng cấp.
Đối tƣợng tƣơng tranh có bộ xử lý riêng, có thể đánh giá việc xử lý cục bộ, tức là
mã chƣơng trình với các điểm nhả xử lý. Xử lý có thể hoạt động, phản ánh hành vi bắt
đầu vào thời điểm tạo bởi chạy phƣơng thức, hoặc hoạt động lại, tức là đáp trả phƣơng
thức đƣợc gọi do các điểm nhả xử lý, ƣớc lƣợng việc xử lý có thể đƣợc chen vào. Giá
trị của biến chƣơng trình một đối tƣợng có thể phụ thuộc không xác định chen vào của
việc xử lý. Bởi vậy thể hiện của phƣơng thức có thể là những biến cục bộ bổ sung
thêm vào biến của đối tƣợng, đặc biệt giá trị của các biến hình thức đƣợc lƣu trữ cục
bộ. đối tƣợng có thể bao gồm một vài thể hiện (chƣa xử lý) của một vài phƣơng thức,
có thể với giá trị khác của biến cục bộ.
Tất cả các đối tƣợng tƣơng tác xẩy ra trong gọi phƣơng thức. Một phƣơng thức
có thể đƣợc gọi trong hai cách đồng bộ hoặc không đồng bộ. Khi một tiến trình gọi
phƣơng thức không đồng bộ, một tiến trình có thể tiếp tục các hoạt động của nó khi nó
yêu cầu đáp trả lời gọi hoặc nó đƣợc trì hoãn khi tới điểm nhả xử lý trong mã nguồn
của nó. Không đồng bộ thiết lập gọi phƣơng thức có thể luôn đƣợc phát ra, nhƣ nhận
đối tƣợng không thể khóa liên kết. Vƣợt phƣơng thức cho phép đƣợc: nếu các phƣơng
thức đƣa ra bởi việc đối tƣợng đƣợc gọi theo một thứ tự, đối tƣợng có thể bắt đầu ƣớc
lƣợng thể hiện của phƣơng thức trong một thứ tự khác.
Gọi phƣơng thức không đồng bộ trong [9] đƣợc thực hiện với câu lệnh t!x.m(E),
trong đó t Label cung cấp bởi lời gọi hàm cục bộ duy nhất, x là biểu thức của đối
tƣợng, m là tên phƣơng thức, và E là tập hợp biểu thức với những tham số hiện thời
đƣợc bổ sung phƣơng thức đang thực thi. Label xác định việc gọi và có thể bị bỏ qua
nếu đáp trả không rõ ràng với yêu cầu. Giá trị trả về từ việc gọi xác định, biểu diễn
trong danh sách biến V, bởi câu lệnh t?(V). Câu lệnh này xem nhƣ V là danh sách biến
11

đặc trƣng [1]: nếu trả lời đƣợc mang về, giá trị trả về đƣợc gán trong V và tiếp tục ƣớc
lƣợng. Trong trƣờng hợp lựa chọn lời gọi cục bộ, tức là khi giá trị của x đƣợc hiểu là
đối tƣợng this, xử lý đƣợc nhả cho bắt đầu ƣớc lƣợng của việc gọi. Bên cạnh đó, ƣớc
lƣợng xử lý đƣợc khóa. Thứ tự hủy bỏ việc chặn trong lựa chọn không đồng bộ, điểm
nhả xử lý đƣợc mở đầu với yêu cầu đáp trả: nếu không có đáp trả tới, ƣớc lƣợng bị trì
hoẵn nhiều hơn bị chặn.
Phƣơng thức gọi đồng bộ (RPC), ngay lập tức chặn xử lý trong khi đợi sự trả lời,
đƣợc viết p(E;V), đây là viết nhanh từ t!p(E);t?(V), trong đó t là nhãn của biến. Ngôn
ngữ không hỗ trợ việc đồng bộ lẫn nhau có thể vì thế dẫn tới tắc nghẽn.
Guards: g trong lệnh await g khai báo rõ ràng cho điểm nhả xử lý. Khi một
Guards nó ƣớc lƣợng giá trị false gặp suốt trong ƣớc lƣợng tiến trình, tiến trình bị trì
hoãn và nhả xử lý. Sau nhả xử lý, bất kì tiến trình chƣa xử lý có thể lựa chọn cho ƣớc
lƣợng. Kiểu Guards đƣợc định nghĩa nhƣ sau:
– wait  Guard (điểm nhả xử lý),
– t?  Guard, trong đó t  Label,
– b  Guard, trong đó b là biểu thức logic cục bộ và trạng thái đối tƣợng,
– g1 g2 và g1 g2, trong đó g1,g2  Guard.
Sử dụng wait sẽ luôn nhả xử lý. Trả lời guard t? cho phép nếu trả lời việc gọi
nhãn t đƣợc tới, đánh giá của trạng thái guard là nguyên tử. Chúng ta cho phép await g
t?(V) viết tắt await gt?;t?(V) và cho phép await p(E; V), trong đó p là một phƣơng
thức gọi (bên ngoài hoặc bên trong), viết ngắn gọn t!p(E); await t?(V) cho một số nhãn
t.
Lệnh có thể bao gồm việc phản ánh các yêu cầu luồng điều khiển đối tƣợng nội
bộ. Cho phép S1 và S2 kí hiệu danh sách các lệnh. Nâng cấp danh sách lệnh là luôn có
thể. Thành phần tuần tự có thể đƣa vào guard: await g là điểm nhả trong S1; await g;
S2. Không xác định chọn S1, S2 có thể chọn S1 một lần S1 đƣợc kích hoạt hoặc S2
12

một lần S2 đƣợc kích hoạt, và bị trì hoãn nếu cả hai nhánh đƣợc kích hoạt. Không xác
định kết sắp S1|||S2 biểu thị lệnh S1 và S2 trong một số thứ tự xen kẽ và kích hoạt.
Ngoài ra còn có tiêu chuẩn xây dựng cho lệnh if và phƣơng thức gọi bên trong, bao
gồm gọi đệ quy. Lƣu ý rằng với mục đích nâng cấp năng động, gọi đệ quy thay thế
vòng lặp trong ngôn ngữ. Gán cho các biến địa phƣơng và các đối tƣợng đƣợc thể hiện
nhƣ V:=E cho cho một danh sách phân chia của biến chƣơng trình V và danh sách một
biểu thức E, kết hợp các loại. Các tham số nhƣ this, label, và caller là biến chỉ đọc.
Với điểm nhả, đối tƣợng không cần block trong khi đợi trả lời. Hƣớng đề xuất
này mềm dẻo hơn với những biến đặc trƣng: trì hoãn xử lý hoặc gọi phƣơng thức mới
có thể biểu thị trong khi đợi. Nếu phƣơng thức gọi không bao giờ trả lời, tắc nghẽn là
tránh đƣợc nhƣ các hoạt động khác trong đối tƣợng có thể. Tuy nhiên, khi trả lời tới,
việc tiếp tục quá trình này phải hoàn thành với các quá trình khác đang chờ và đƣợc
kích hoạt.
Ngôn ngữ Creol cung cấp cơ chế cho đa kế thừa [8] ở đó tất cả các thuộc tính và
phƣơng thức của superclass đƣợc kế thừa bởi lớp con, và ở đó phƣơng thức của các
superclass có thể đƣợc định nghĩa lại. Kế thừa lớp đƣợc khai báo bởi từ khóa inherits;
tức là, một danh sách của tên lớp C(E) trong đó E cung cấp tham số của lớp hiện thời.
Ta thấy rằng phƣơng thức và thuộc tính đƣợc định nghĩa phía trên lớp C nếu nó đƣợc
khai báo trong C hoặc ít nhất 1 lớp kế thừa bởi C. Gọi bên trong đƣợc thực thi trong
việc gọi và có thể. Kĩ thuật này giới thiệu cú pháp t!m@C(E) cho gọi không đồng bộ
và m@C(E; V) cho gọi nội tại đồng bộ của phƣơng thức trên C trong đồ thị kế thừa từ
C hoặc lớp con của C. Việc gọi có thể kết nối với lớp xác định của đối tƣợng this, vì
vậy đƣợc gọi static. Ngƣợc lại có thể gọi bên ngoài với @, đƣợc gọi ảo, cần xác định
lớp hiện thời gọi trong thời gian chạy có thứ tự kết nối việc gọi. Do đó, một phƣơng
thức khai báo trong lớp C có thể truy cập duy nhất thuộc tính khai báo trên C. Trong
lớp con, thuộc tính x của một superclass C bị truy cập bởi khả năng liên quan x@C.
Cú pháp dƣới đây định nghĩa phương thức điển hình cho mỗi thể loại. Với S, V, E
biểu thị cú pháp các danh sách, tập hợp, hoặc multisets cho từng loại, tùy thuộc
vào ngữ cảnh.
13

g in Guard
p in MtdCall
s in Stm
t in Label
v in Var
e in Expr
x in ObjExpr
b in Bool
m in Mtd
g ::= wait | b | t? | g1 g2 | g1 g2
p ::= x.m|m@classname |m
S ::= s | s; S
s ::= skip| (S) | S1,S2 | S1|||S2
| V := E | v := new classname(E)
| if b then S1 else S2 fi
| t!p(E) | !p(E) | p(E;V) | t?(V)
| await g | await gt?(V) | await p(E;V)
Kết nối ảo. Khi một phƣơng thức gần nhƣ đƣợc gọi trong một đối tƣợng o của
lớp C, khai báo một phƣơng thức đƣợc định danh trong đồ thị kế thừa của C và kết nối
(ràng buộc) để gọi. Để đơn giản, lời gọi đƣợc kết nối với các phƣơng thức định nghĩa
kết hợp đầu tiên ở đỉnh C trong đồ thị kế thừa, trong một lệnh đầu tiên bên trái sâu đầu
tiên. Giả sử cho một mối quan hệ kiểu thuộc kiểu con nhƣ là một phản xạ từng phân
của kiểu với lệnh , bao gồm giao diện. Kiểu dữ liệu duy nhất kiểu con của kiểu dữ
liệu và giao diện (interface) có thể có duy nhất kiểu con của giao diện. Nếu T T’ khi
đó bất kì giá trị nào của T có thể giả danh nhƣ giá trị của T’. Kiểu con của bộ kiểu dữ
liệu là mở rộng theo từng phần của mối quan hệ kiểu con: T T’ nếu bộ T và T’ có
chiều dài giống nhau l và Ti  T’i cho mỗi i (0   ) và kiểu Ti và T’i cùng vị trí I

ở T và T’. Giải thích về kiểu và kết nối của phƣơng thức, kiểu con là mở rộng của
không gian hàm   , trong đó A và B là bộ kiểu:
A→B  A’→B’ = A A’  B’ B
Phân tích tĩnh cho lời gọi bên trong m (E; V) sẽ chỉ định kiểu duy nhất cho các
tham số vào và ra tùy thuộc vào ngữ cảnh văn bản. Nói cách khác các tham số hiện
thời khai báo theo ngữ cảnh nhƣ E: TE và V: TV. Lời gọi là type correct nếu đó là
phƣơng thức khai báo m: A→B phía trên lớp C nhƣ là TE → TV  A → B. Kết nối
14



không đồng bộ gọi t!m(E) với thay thế t?(V) hoặc await t?(V), đƣợc điều khiển nhƣ
phù hợp với lời gọi đồng bộ m(E; V).
Trong thời gian chạy đối tƣợng thực hiện lời gọi bên trong m: TE → TV sẽ là
của lớp con C’ của C và cơ chế kết nối ảo sẽ kết nối tới khai báo của m: A’→B’ nhƣ
vậy mà TE→TVA’→B’, lấy m đầu tiên nhƣ phía trên C’. Bởi vì C đƣợc kế thừa bởi
C’, kết nối ảo đƣợc đảm bảo thành công. Mở rộng lời gọi t!o.m(E) là kết nối thực sự
trong đỉnh của đồ thị lớp định danh động của o. Với điều kiện là khai báo giao diện
của o hỗ trợ kí hiệu đối tƣợng, kết nối thành công đảm bảo cho bất kì một nguyên thể
nào của lớp kiểu chính xác thực thi giao diện.
Thay đổi hệ thống đƣợc giải quyết thông qua một cơ chế để nâng cấp lớp, cho
phép các đối tƣợng hiện tại và tƣơng lai của lớp nâng cấp và các lớp con của nó để
phát triển. Một lớp có thể chịu một số nâng cấp. Trong nâng cấp, thuộc tính mới,
phƣơng pháp, và siêu lớp có thể đƣợc thêm vào một định nghĩa lớp, và các phƣơng
thức cũ có thể đƣợc sửa đổi. Để cho phép thể hiện của phƣơng thức cũ phát triển một
cách an toàn và tránh các kiểu lỗi thời gian chạy, không có các thuộc tính, phƣơng
thức, hoặc các lớp kế thừa có thể đƣợc gỡ bỏ một phần của nâng cấp lớp. Mặc dù hạn
chế hơn, các nghiên cứu thực nghiệm cho thấy bổ sung và xác định lại dịch vụ đến nay
hình thức phổ biến của sự tiến hóa phần mềm hơn so với loại bỏ[9].
Các thuộc tính có thể đƣợc thêm vào. Các thuộc tính mới có thể đƣợc thêm vào

một lớp. Việc bổ sung một thuộc tính mới có cùng tên nhƣ là một thuộc tính đã đƣợc
xác định trong lớp học không đƣợc phép. Việc bổ sung một thuộc tính có tên giống
nhƣ một thuộc tính kế thừa đƣợc cho phép. Các thể hiện của lớp sau đó sẽ có cả hai
thuộc tính, đƣợc truy cập bằng tên tiêu chuẩn.Nhƣ tên thuộc tính đƣợc tĩnh mở rộng
vào tên tiêu chuẩn, mã cũ sẽ tiếp tục sử dụng các thuộc tính giống nhƣ trƣớc khi nâng
cấp.
Các phƣơng thức có thể đƣợc thêm hoặc định nghĩa lại. Kĩ thuật này xem xét tác
động của việc thêm hoặc định nghĩa lại một phƣơng thức trong một lớp C đối với các
lớp con và siêu lớp của C. Nếu một phƣơng thức là định nghĩa lại trong C, mã phƣơng
15



thức là thay thế trong tất cả các thể hiện của C và định nghĩa phƣơng thức cũ không
còn nữa. Điều này dẫn đến một quy tắc kiểu con cho định nghĩa lại phƣơng thức để
đảm bảo rằng ảo liên kết thành công. Do đó, chúng tôi cho phép cấu trúc dữ liệu nội
bộ của phƣơng thức phải đƣợc thay thế, nhƣng đối với hiệp phƣơng sai và xác định lại
hiệp phƣơng sai là cần thiết cho phƣơng thức của tham biến trong và ngoài tƣơng ứng.
Nếu một phƣơng thức đƣợc thêm vào một lớp, đảm bảo ràng buộc ảo cho các lời
gọi cũ là đúng kiểu mà không đặt bất kỳ hạn chế về phƣơng thức mới. Tất cả các loại
quá tải các phƣơng thức kế thừa đƣợc cho phép, bao gồm cả quá tải đối với tham số
trong hay ngoài. Đối với các khai báo phƣơng thức với cùng một số tham số trong và
ngoài quá tải có thể là đối với các kiểu tham số, có thể chỉ cho tham số ngoài. Nếu một
phƣơng thức m đƣợc thêm vào C và m là đã định nghĩa trƣớc trong một lớp cha C’của
C, định nghĩa mới trong C sẽ ghi đè lên (và ẩn) các m phƣơng thức kế thừa của C’ theo
nghĩa là một cuộc gọi mà phù hợp cả hai định nghĩa sẽ bị ràng buộc khác nhau sau khi
nâng cấp. Phƣơng thức siêu lớp vẫn còn có sẵn của các lời gọi tĩnh m@C’. Ràng buộc
ảo đảm bảo rằng cuộc gọi đúng kiểu trƣớc khi nâng cấp lớp vẫn còn đúng kiểu. Nếu
một phƣơng thức m đƣợc thêm vào C và m là đã định nghĩa trƣớc trong một lớp con
C’’ của C, ghi đè lên một mối quan hệ mới sẽ đƣợc giới thiệu. Tuy nhiên, kết nối ảo

đảm bảo đúng kiểu của lời gọi cũ cũng nhƣ các lời gọi hầu nhƣ bị ràng buộc của lớp
nâng cấp. Việc bổ sung một phƣơng thức để một lớp C không cần phải đƣợc giới hạn
bởi định nghĩa trong lớp con va lớp cha của C.
Siêu lớp (superclasses) có thể đƣợc thêm vào. Nếu một lớp C đƣợc thêm vào nhƣ
là một siêu lớp trong nâng cấp lớp, các thuộc tính và phƣơng thức định nghĩa tại C và
siêu lớp của nó trở nên có sẵn. Các cơ chế ràng buộc các thực hiện theo một thứ tự
left-first depth-first, do đó thứ tự của danh sách các lớp kế thừa là rất quan trọng: để
giảm thiểu tác động của superclasses mới trên cơ chế ràng buộc ảo, các siêu lớp mới
đƣợc thêm vào cuối danh sách thừa kế.
Chúng ta hãy xem xét việc nâng cấp động qua một ví dụ. Nâng cấp đƣợc sử dụng
để thêm một dịch vụ mới cho một lớp hiện có, với các hiệu ứng hiển thị cho ngƣời
dùng của lớp này, và để thay đổi một giao thức truyền thông trong thời gian chạy, để
16



tăng hiệu suất hệ thống một cách rõ ràng.Xem xét một tài khoản ngân hàng của giao
diện Account, với phƣơng thức đối với tiên gửi và tài khoản giao dịch, nhƣ vậy giao
dịch cần phải đợi cho đến khi tài khoản có đủ tiền.
Version 1
class BankAccount implements Account
beginvar bal : Int = 0
with Any
op deposit (in sum : Nat) == bal := bal+sum
op transfer (in sum : Nat, acc : Account ) ==
await bal ≥ sum ; bal := bal−sum; acc.deposit(sum)
end
Nâng cấp lớp động cho phép thêm các dịch vụ mới của ứng dụng mà không cần
dừng hệ thống. Chúng tôi xem xét việc thêm điều khiện rút quá số tiền gửi. Nâng cấp
lớp BankAccount sẽ thêm phƣơng thức overdraft_open nhƣ một đối tƣợng hỗ trợ giao

diện Banker có thể thiết lập nhiều nhất quá số tiền gửi cho tài khoản. Phƣơng thức giao
dịch này sẽ nâng cấp để có thêm điều kiện mới này vào tài khoản.
Version 2
upgradeclass BankAccount
beginvar overdraft : Nat = 0
with Any
op transfer (in sum : Nat, acc : Account) ==
await bal ≥ sum−overdraft; bal := bal−sum;
acc.deposit(sum)
with Banker
op overdraft_open (in max : Nat) == overdraft := max
end
Biến overdraft đƣợc thêm vào trong suốt quá trình nâng cấp. Tiến trình giao dịch
chƣa xử lý xong trong đối tƣợng await của guard cũ, trong khi đó gọi giao dịch mới tới
đối tƣợng ở guard mới.
17



Với kĩ thuật nâng cấp này, có tác dụng triệt để trên các lớp con và các thể hiện
của nó. Việc nâng cấp này cho phép thêm các thuộc tính mới, phƣơng thức mới, các
lớp mới trong khi vẫn tồn tại phƣơng thức cũ có thể định nghĩa lại. Nhƣng vẫn chƣa
giải quyết đƣợc nâng cấp các lớp kế thừa.

18



CHƢƠNG 3. PHƢƠNG PHÁP NÂNG CẤP ĐỘNG CHO HỆ THỐNG
PHÂN TÁN

Trong chƣơng này, luận văn sẽ trình bầy phƣơng pháp luận nâng cấp tự động các
thành phần của hệ thống phân tán, và nghiên cứu các thành phần của hệ thống phân
tán.
3.1 Hệ thống phân tán
Hệ phân tán là một tập hợp các máy tính độc lập đƣợc sử dụng một cách kết hợp
để thực hiện một tác vụ đơn hoặc để cung cấp một dịch vụ đơn. Hệ phân tán thể hiện
dƣới nhiều kiến trúc khác nhau [8]: Kiến trúc client – server, kiến trúc peer to peer,
kiến trúc lai,

Hình 3.1 Kiểu phân chia chức năng giữa Client và Server
Hình 3.1 thể hiện kiến trúc phân chia chức năng giữa Client và Server. Hình
(a) giao diện người dùng nằm cả hai phía client và server, mọi yêu cầu đều được
xử lý phía Server. Tương tự như vậy, việc xử lý các chức năng ở phía server được
giảm thiểu, được xử lý cả phía client.
19




Hình 3.2 Kiến trúc ngang hàng.
Mô hình hệ thống phân tán là tập hợp các đối tƣợng giao tiếp với nhau bằng cách
chia sẻ bộ nhớ hay truyền thông điệp [2]. Với nhiều dạng liên lạc khác nhau, ví dụ nhƣ
liên lạc hƣớng điều khiển: truyền điều khiển theo thông điệp, mô hình hệ thống xây
dựng bằng cách gọi hàm từ xa (RPC) hay gọi phƣơng thức từ xa (RMI). Khi đó mỗi
phần trạng thái đối tƣợng (mỗi đối tƣợng là một thể hiện của một lớp) có thể nằm trên
đĩa hoặc nằm trên một nút khác. Các nút khác nhau có khả năng chạy các lớp khác
nhau. Đa phần các đối tƣợng không bao giờ mất hoàn toàn trên hệ thống, nó có thể
phục hồi trên các vị trí khác nhau.
Với cách thức liên lạc bằng cách gọi hàm từ xa (RPC - Remote Procedure Call).
Đây là cách thức thay thế mô hình truyền thông điệp kiểu input/output bằng cách chạy

một lời gọi hàm tại một máy ở xa bằng cách:
 Đồng bộ - block khi gửi thông điệp gọi hàm
 Ứng dụng không cần biết chi tiết truyền thông điệp
 Dùng các tham số lời gọi hàm để truyền dữ liệu
 Client gọi hàm stub địa phƣơng, stub thực hiện việc truyền thông điệp và
đóng gói dữ liệu (marshalling)
 Dùng cơ chế gọi hàm để che dấu liên lạc giữa bên gọi và bên đƣợc gọi
20



Cách liên lạc này có thể bị lẫn giữa thao tác địa phƣơng và thao tác trên máy ở
xa.

Hình 3.3 Liên lạc bằng phương thức gọi hàm từ xa RPC
Hình 3.3 thực thi ở phía client bằng cách: Client gọi client stub. Stub dựng thông
điệp; gọi hệ điều hành địa phƣơng. HĐH gửi thông điệp tới HĐH ở xa. HĐH ở xa
chuyển thông điệp cho server stub. Stub tháo gỡ các tham số và gọi server. Ở phía
server: Server trả kết quả cho stub. Stub dựng thông điệp; gọi HĐH. HĐH gửi thông
điệp cho HĐH của client. HĐH của client chuyển thông điệp cho client stub. Stub tháo
dỡ kết quả và trả về cho client.
Sự chuyển dịch từ RPC tới RMI (gọi phƣơng thức từ xa) là sự chuyển dịch từ tƣ
tƣởng server sang tƣ tƣởng đối tƣợng. Với RPC: phải chỉ định tƣờng minh server của
hàm cần gọi, server lƣu thông tin trạng thái của client. Trong khi đó RMI: đích là một
đối tƣợng cụ thể, thông tin trạng thái đƣợc đóng gói trong đối tƣợng đích. Các đối
tƣợng là các “công dân” hạng nhất trong RMI: tham chiếu tới đối tƣợng có thể đƣợc
truyền dƣới dạng tham số; Có thể đƣợc trả về dƣới dạng kết quả của phƣơng thức; Giải
quyết vấn đề dữ liệu con trỏ của RPC. Nhƣng RMI và đối tƣợng phân tán là mô hình
đƣợc sử dụng rộng rãi hiện nay.