Nghiên cứu các thuật toán giám sát và xử lý cạnh tranh giữa các thành phần phần mềm trên môi trường phân tán

Với mô hình hoạt động như trên ta có thể thấy ngay rằng ứng dụng của ngân hàng là một ứng dụng phân tán và được phát triển từ nhiều thành phần phần mềm ghép nối lại.. Với mục tiêu đó, bà

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THỊ BÍCH NGỌC

NGHIÊN CỨU CÁC THUẬT TOÁN GIÁM SÁT VÀ XỬ LÝ CẠNH TRANH GIỮA CÁC THÀNH PHẦN PHẦN MỀM

TRÊN MÔI TRƯỜNG PHÂN TÁN

LUẬN VĂN THẠC SĨ

HÀ NỘI - 2007

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THỊ BÍCH NGỌC

NGHIÊN CỨU CÁC THUẬT TOÁN GIÁM SÁT VÀ XỬ LÝ CẠNH TRANH GIỮA CÁC THÀNH PHẦN PHẦM MỀM

TRÊN MÔI TRƯỜNG PHÂN TÁN

Chuyên ngành: Công nghệ thông tin

MỤC LỤC

Mở đầu 9

Chương 1 Thành phần phần mềm (software component) 11

1.1 Kỹ nghệ phần mềm hướng thành phần 11

1.1.1 Tổng quan kỹ nghệ phần mềm hướng thành phần 11

1.1.2 Thành phần phần mềm 14

1.2 Mô hình thành phần 15

1.3 Giám sát và dò vết thành phần 17

1.3.1 Giới thiệu 17

1.3.2 Dò vết thành phần 18

1.3.3 Cơ chế tăng khả năng dò vết cho thành phần 20

1.3.4 Mô hình hướng sự kiện của Java giúp hỗ trợ dò vết 22

1.3.5 Gói dò vết của Java 25

3.2.5 Môi trường dò vết cho phần mềm thành phần 26

Chương 2 Hệ thống đối tượng phân tán 28

2.1 Giới thiệu 28

2.2 Sự phân tán trong môi trường Java: RMI 30

2.2.1 Hệ thống đối tượng phân tán trong môi trường Java 30

2.2.2 Giới thiệu ứng dụng phân tán với RMI 31

2.2.3 Kiến trúc của cơ chế RMI 33

Chương 3 Thuật toán phân tán 38

3.1 Tổng quan về các thuật toán phân tán 38

3.2 Thuật toán trong mạng đồng bộ 38

3.2.1 Leader election trong mạng vòng đồng bộ 39

3.2.2 Leader Election trong mạng đồng bộ tổng quát 42

3.2.3 Leader election trong mạng vòng không đồng bộ 43

3.3 Thuật toán trong mạng không đồng bộ 46

3.3.1 Mutual Exclusion 49

3.3.2 Thuật toán mutual exclution của Dijkstra 52

3.3.3 Thuật toán Two-process của Peterson 56

3.3.4 Thuật toán mutual exclusion của Burn 57

3.3.5 Thuật toán Bakery của Lamport 59

Chương 4 Áp dụng thuật toán phân tán cho hệ thống ATM tại ngân hàng 64

4.1 Giới thiệu hệ thống ATM tại ngân hàng 64

4.2 Chuẩn ISO 8583 65

4.3 Xử lý phân tán hiện tại 72

4.4 Áp dụng thuật toán Mutual Exclution của Burn 73

Kết luận 76

Tài liệu tham khảo 78

Danh mục các chữ viết tắt và thuật ngữ

Chữ viết tắt/Thuật

ngữ

Giải thích

CBSE Component-based software engineering - Kỹ nghệ

phần mềm hướng thành phần UID Unique Identifier - Định danh duy nhất

Leader Election Bầu đại biểu – Trong mô hình mạng vòng đồng bộ,

cần tìm ra một tiến trình duy nhất có định danh lớn nhất làm Leader được phép thực hiện tiến trình, các tiến trình khác phải chờ cho đến lượt mình

LCR Lelann, Chang-Roberts – tên thuật toán

Mutual Exclution Vấn đề tương tranh– trong mô hình mạng không đồng

bộ, vấn đề này xảy ra khi có nhiều hơn một tiến trình cùng truy cập tài nguyên chia xẻ, cần phải có sự phân phối tài nguyên giữa các tiến trình

Danh mục các hình vẽ

Hình 1.1: Mô hình hệ thống ứng dụng của ngân hàng 5

Hình 1.2: Các kiểu dò vết thành phần 16

Hình 1.3: Cấu trúc mô hình dò vết hướng sự kiện 19

Hình 1.4: Chuỗi tương tác 20

Hình 1.5: Gói dò vết 21

Hình 1.6: Bộ phỏng theo Tracker 21

Hình 1.7: Sự thi hành của bindBeanTraker 22

Hình 1.8 Môi trường dò vết phân tán 23

Hình 2.1 : Mô hình đối tượng phân tán 25

Hình 2.2 : Đăng ký tham chiếu đối tượng từ xa 29

Hình 2.3: Kiến trúc của RMI 30

Hình 2.4: Sự hỗ trợ thi hành của RMI 30

Hình 2.5 : Quan hệ giữa giao diện và lớp 31

Hình 2.6: Các tầng kiến trúc của RMI 32

Hình 2.7 : Kết nối giữa các máy ảo 34

Hình 3.1: Thông điệp liên tiếp được gửi đi trong thuật toán Hirshberg-Sinclair38 Hình 3.2: Hệ thống bộ nhớ chia sẻ 43

Hình 3.3 : Chu kỳ hoạt động của một tiến trình 47

Hình 3.4: Đặc tả giao diện đối với NSD 47

Hình 3.5: Kiến trúc tổng thể của vấn đề mutual exclution 48

Hình 3.6: Tại thời điểm t1, pi thiết đặt flag[i]=2; tại thời điểm t2, pj lại thấy flag[i] ≠ 2; tại thời điểm t3 thì pi rời khỏi vùng C 51 Hình 4.1 : Qui trình xử lý giao dịch trên ATM 67

Mở đầu

Trước khi đi vào giới thiệu nội dung của luận văn, chúng ta hãy nghiên cứu mô hình ứng dụng của ngân hàng[1]

Trong mô hình hệ thống, hệ thống nghiệp vụ cốt lõi bao gồm các phân hệ nghiệp vụ

cơ bản của ngân hàng, đó là: Thông tin khách hàng(Customer Information File-CIF), Tiền gửi(Deposit), Khoản vay(Loan), Tài trợ thương mại(Trade Finance), Chuyển tiền(Remittance), Ngân quỹ(Tresury) và Sổ cái tổng hợp(General Ledger-GL) Các phân hệ này xử lý tất cả các nghiệp vụ cốt lõi của ngân hàng và giao tiếp với các phân

hệ khác, các hệ thống khác thông qua phần xử lý các dịch vụ phân phối Trên cơ sở các nghiệp vụ này, ngân hàng phát triển các sản phẩm dịch vụ của mình qua các kênh phân phối sản phẩm gồm có: hệ thống giao dịch của chi nhánh(Branch Delivery System - BDS), SWIFT/TELEX, IPBS, T5, ATM, POS, HomeBanking, Internet Banking…Đồng thời hệ thống còn có khả năng tích hợp với các hệ thống chương trình khác như: Quản lý mẫu dấu chữ ký, Trái phiếu, CIC, Quản lý TSCĐ, Quản lý phải thu/phải trả…

Hình 1.1 : Mô hình hệ thống ứng dụng của ngân hàng

Dữ liệu của toàn bộ hệ thống được lưu trữ tập trung về kho dữ liệu (Data warehouse) tại HSC Giao dịch tại các chi nhánh trên toàn quốc sẽ được xử lý trực tuyến tại máy chủ

Với mô hình hoạt động như trên ta có thể thấy ngay rằng ứng dụng của ngân hàng là một ứng dụng phân tán và được phát triển từ nhiều thành phần phần mềm ghép nối lại Mục tiêu của các ngân hàng đặt ra là ngày càng phát triển nhiều sản phẩm dịch vụ khách hàng chất lượng cao, an toàn, tiện lợi Để đạt được điều này, bênh cạch việc tìm hiểu thị trường về nhu cầu của khách hàng, các nghiệp vụ đáp ứng như cầu đó, một khía cạnh không kém phần quan trọng mà các ngân hàng đang hướng tới chính là lĩnh vực công nghệ thông tin Vấn đề nghiên cứu, nắm bắt và làm chủ hệ thống để từ đó có thể phát triển hệ thống là một yêu cầu cấp thiết đặt ra tại các ngân hàng Với mục tiêu

đó, bài luận văn đề cập đến các nội dung sau:

Chương 1: Thành phần phần mềm

Giới thiệu các khái niệm cơ bản về kỹ nghệ phần mềm hướng thành phần, giám sát

và dò vết các thành phần phần mềm

Chương 2: Hệ thống đối tượng phân tán

Giới thiệu tổng quan về hệ thống phân tán, một mô hình đang được áp dụng rất nhiều trong các phần mềm tại ngân hàng

Chương 3: Thuận toán ứng dụng trong môi trường phân tán, giới thiệu các vấn đề nảy sinh trong môi trường phân tán, thuật toán giải quyết các vấn đề đó

Chương 4: Áp dụng thuật toán phân tán cho hệ thống ATM tại ngân hàng

Kết luận

Tài liệu tham khảo

Ý tưởng này không phải là mới Phần mềm được thành phần hoá (Componentizing software) đã được đưa ra bởi Mcllorys khi nói về cuộc khủng hoảng phần mềm Ngày

nay, khi ngày càng có nhiều thành phần phần mềm thương mại trên thị trường thì thay

vì xây dựng, việc phát triển phần mềm hướng tới mua các thành phần và lắp ráp chúng lại với nhau Mục đích của CBSE là giảm chi phí phát triển phần mềm: các hệ thống thành phần có tính linh hoạt và dễ duy trì theo xu hướng plug-and-play của các thành phần

- Đánh giá chất lượng thành phần (Component qualification)

- Chỉnh sửa lại thành phần cho phù hợp (Component adaptation)

- Lắp ráp thành phần(Component assemblly)

- Phát triển và duy trì hệ thống

Mặc dù tiến trình này là khác biệt so với việc phát triển phần mềm truyền thống thì giữa chúng vẫn có những điểm chung, ví dụ như vấn đề quản lý sự thay đổi và duy trì khi phát triển phần mềm Sau đây chúng ta sẽ đi vào mô tả chi tiết cho từng hoạt động Đánh giá chất lượng

Đánh giá chất lượng là xác định khả năng thích ứng của phần mềm khi sử dụng trong hệ thống được tạo cuối cùng Khi có nhiều sản phẩm cạnh tranh trên thị trường thì vấn đề đặt ra là phải lựa chọn sản phẩm nào phù hợp nhất Sự lựa chọn sẽ phụ thuộc vào sự so sánh giữa thành phần này với thành phần khác cũng như sự thích ứng

trong sử dụng của các thành phần Vấn đề nảy sinh trong suốt hoạt động này là tính tin cậy(trust) và chứng thực(certification) Tiến trình chứng thực gồm có hai phần:

Thiết lập các sự kiện (fact) về một thành phần và xác định các thuộc tính của thành phần có phù hợp với bản đặc tả đã công bố, và

Thiết lập sự tin cậy đối với các sự kiện hợp lệ này, có thể nhờ một tổ chức tin cậy thứ ba chứng thực cho độ tin cậy của sự phù hợp này và cấp cho một bảng chứng thực

để xác nhận điều đó

Động cơ thúc đẩy việc chứng thực thành phần là do sự liên hệ giữa các thuộc tính được chứng thực của thành phần với các thuộc tính trong hệ thống cuối cùng Nếu ta hiểu biết về các thành phần được lựa chọn để lắp ráp thì ta có thể đoán được các thuộc tính của chúng trong hệ thống cuối cùng Độ chính xác của việc tiên đoán phụ thuộc vào độ tin cậy của thành phần cũng như độ hiểu biết về sự gắn kết các thành phần Đối với rất nhiều thành phần trên thị thường, sự tiên đoán thường là rất khó khăn do thiếu thông tin về các khả năng của thành phần và các thông tin về độ tin cậy của chúng Theo học thuyết phần mềm cổ điển, việc đặc tả thành phần phải đầy đủ, hoàn thành

và ổn định Tuy nhiên việc đặc tả đầy đủ là không thực tế: một số thành phần có các thuộc tính biểu lộ ra nhưng lại không thể làm thành tài liệu được, chưa kể là tài liệu đó dùng bộ ký hiệu chuyên biệt

Chỉnh sửa cho phù hợp(adaption)

Các thành phần khác nhau được viết để đáp ứng các yêu cầu khác nhau, mỗi thành phần đảm đương bối cảnh mà nó triển khai trong đó Mục đích của việc chỉnh sửa là đảm bảo sự xung đột giữa các thành phần là nhỏ nhất Việc sử dụng các cách chỉnh sửa khác nhau phụ thuộc vào khả năng truy nhập vào cấu trúc bên trong của thành phần

- Các thành phần hộp trắng (white-box) có thể viết lại đáng kể để vận hành cùng với các thành phần khác

- Các thành phần hộp xám (grey-box) cung cấp ngôn ngữ mở rộng hoặc giao diện lập trình ứng dụng (API)

- Các thành phần hộp đen (balck-box) không cung cấp ngôn ngữ mở rộng cũng như API

Nói chung, một thành phần thường là một hộp đen, các dịch vụ của nó chỉ truy cập thông qua giao diện cho trước Tuy nhiên, theo logic chúng ta vẫn có thể quan tâm đến các thành phần hộp trắng và hộp xám

Lắp ráp thành phần

Lắp ráp là tích hợp các thành phần bằng một số công cụ có sẵn để ghép các thành phần lại tạo ra một hệ thống Ví dụ, các thành phần thương mại thường được viết theo các mô hình thành phần như Enterprise JavaBeans, COM, CORBA và gần đây là NET

Phát triển và duy trì hệ thống

Các thành phần là các đơn vị thay đổi, sự phát triển của hệ thống là sự thay thế các thành phần đã lỗi thời bằng các thành phần mới hơn Cách nhìn nhận các thành phần là các đơn vị có thể thay thế được là một cách nhìn hơi quá đơn giản về phát triển hệ thống Trong thực tế, việc thay thế một thành phần không hề đơn giản, đặc biệt là khi thành phần mới và thành phần cũ không tương xứng với nhau sẽ phát sinh việc chỉnh sửa lại cho thành phần mới

Các lĩnh vực nghiên cứu của kỹ nghệ phần mềm hướng thành phần

Như đã để cập ở trên, phát triển phần mềm hướng thành phần có rất nhiều lĩnh vực nghiên cứu Sau đây là một số lĩnh vực

- Mô hình và đặc tả hoá thành phần

Ngôn ngữ mô hình hợp nhất UML đã trở thành chuẩn phổ biến cho hầu hết mô hình ứng dụng và được dùng trong các phương thức CBSD như là phương thức xúc tác

(Catalysis) Đối với các phiên bản trước phiên bản 2.0 cần phải mở rộng UML để cho

phép đặc tả riêng các thành phần phụ thuộc và các giao diện của chúng Vấn đề này được trình bày chi tiết trong cuốn sách UML Components (Cheesman and Daniels

2001)

Tuy nhiên, bên cạnh UML còn có một lượng lớn công việc quan trọng để sao cho tiến trình phát triển hướng thành phần được tiếp cận một cách chính thức Việc đặc tả chi tiết công việc này bao gồm đặc tả giao diện của thành phần, đặc tả các chức năng hoạt động hay các giao thức tương tác, các ràng buộc để một hoạt động được gọi như thế nào và khi nào

- Các kỹ thuật truy lục và khớp đặc tả

Vấn đề làm thế nào để truy lục các đối tượng (artefact) có thể sử dụng lại là một lãnh vực nghiên cứu từ lâu trong việc sử dụng lại phần mềm Việc truy lục đã tập trung vào các dạng mô tả thành phần (component descriptions) nào nên đặt trong thứ

tự mà các thành phần đó có thể được truy lục từ các kho chứa, trong khi các kỹ thuật khớp đặc tả được dùng để tìm kiếm các thành phần dựa trên các tiêu chuẩn chức năng hay hành vi

Như đã đề cập ở trên, các kỹ thuật lắp ráp gồm có các thành phần hộp đen, hộp xám

và hộp trắng Nghiên cức về việc lắp ráp trải khắp từ các kỹ thuật đóng gói cho đến các phương thức phức tạp như nhận biết các bộ điều chỉnh phù hợp để khớp đặc tả Vấn đề liên quan đến các kỹ thuật lắp ráp bao gồm cả việc làm thế nào để khả năng

dùng lại của một thành phần có thể cải tiến bằng cách tính đến làm thế nào để chúng

có thể lắp ráp thoái mái trong khi chúng vẫn đang được phát triển

- Các ngôn ngữ kết hợp và cấu tạo

Khi ta không có định nghĩa về các bộ phận tạo nên thành phần thì COM và CORBA, những ngôn ngữ kết hợp và cấu tạo sẽ được sử dụng để mô tả sự lắp ráp hay kết gắn của tập hợp thành phần Các ngôn ngữ này cũng có thể được sử dụng để định nghĩa cách thức phần mềm được kết hợp vào khung làm việc (framework) cho trước hoặc cách thức để các thành phần giữa các hệ thống tương tác với nhau

- Xác minh, kiểm tra và cấp chứng thực

Phát triển phần mềm hướng thành phần cũng chỉ ra rằng một thành phần phải trải qua hai giai đoạn test Giai đoạn test thứ nhất xảy ra trong quá trình phát triển phần mềm, xác minh liệu một thành phần có đáp ứng được bản đặc tả của nó và có đáp ứng được các yêu cầu chức năng Một thành phần có thể được chứng thực bởi bên thứ ba tùy theo cách thức mà thành phần thi hành trong quá trình test Giai đoạn test thứ hai liên qua đến việc kiểm tra cách thức thành phần được tích hợp với các thành phần khác khi phát triển hệ thống hướng thành phần Các chiến lược test khác nhau có thể được

sử dụng phụ thuộc vào mức độ rõ ràng của cấu trúc bên trong thành phần Thông thường, người ta dùng các kỹ thuật hộp đen đối với các thành phần thương mại và dùng kỹ thuật hộp trắng đối với các thành phần có mã nguồn

- Quản lý cấu hình

Quản lý cấu hình phần mềm là tiến trình điều khiển sự phát triển hệ thống, thiết lập khía cạnh của hệ thống tương lai và định nghĩa các kỹ thuật cho việc quản lý các phiên bản khác nhau của các khía cạnh đó

1.1.2 Thành phần phần mềm

Thành phần phần mềm là gì? Không có câu trả lời chính xác cho câu hỏi này Có rất nhiều định nghĩa về thành phần phần mềm

Szyperski: Một thành phần phần mềm là một đơn vị cấu tạo nên phần mềm có các

giao diện theo thoả thuận và các sự phụ thuộc vào bối cảnh Một giao diện(interface)

là tập các hoạt động được đặt tên có thể được gọi bởi các máy khách Sự phụ thuộc bối cảnh (Context dependencies) là các đặc tả về môi trường triển khai cần phải cung cấp,

đến các thành phần thương mại, độc lập với bất kỳ sự thi hành đặc biệt cũng như công nghệ middleware

1.2 Mô hình thành phần

Mô hình thành phần là một kiến trúc và tập các giao diện API cho phép người phát triển xác định các thành phần phần mềm và có thể kết hợp chúng lại với nhau để tạo ra một ứng dụng Một mô hình thành phần có hai thành phần chính: các thành phần phần mềm và các phần chứa đựng(container)[9]

Các thành phần phần mềm là một miền rộng về cả kích thước cũng như khả năng của nó, từ các giao diện đồ hoạ nhỏ như các nút bấm cho đến các applet có tính chức năng như các trình xem bảng biểu hoặc các ứng dụng đầy đủ hơn như trình duyệt HTML của các ứng dụng bố trí các trang tin Các thành phần có thể xuất hiện trực quan như các nút bấm, hoặc có thể không trực quan như các thành phần giám sát việc cung cấp dữ liệu

Các container được dùng để nắm được quá trình lắp ráp của các thành phần liên quan Các container sẽ cung cấp ngữ cảnh để các thành phần được sắp xếp và tương tác với các thành phần khác Các container đôi khi cũng có thể là các form, các trang, các frame hay các trình tiện ích giao diện người máy (shell) Các container lại cũng có thể chính là các thành phần, ví dụ một container có thể được sử dụng như là một thành phần bên ngoài của một container khác

Bên cạnh việc định nghĩa ra cấu trúc của các thành phần và các container, mô hình thành phần cũng hỗ trợ nhiều dịch vụ khác nhau Cụ thể hơn là, một mô hình thành phần đầy đủ chức năng thì nó phải hỗ trợ 6 dịch vụ chính dưới đây[12]:

Trưng bày nội quan: Introspection

Quản lý sự kiện: Event handling

Lưu trữ: Persistence

Bố trí vật lý: Layout

Hỗ trợ trình tạo ứng dụng: Application builder support

Hỗ trợ tính toán phân tán: Distribute computing support

Trưng bày nội quan (Introspection)

Introspection là một kỹ thuật để trưng bày các chức năng của thành phần với thế giới bên ngoài Thông qua introspection, một ứng dụng có thể truy vấn một thành phần để tìm ra các khả năng có thể và sau đó tương tác một cách tương ứng với thành phần Introspection là một trong những khía cạnh quan trọng nhất của mô hình thành phần

vì nó đảm nhận việc chỉ định cách thức xuất hiện của thành phần trong các ứng dụng

và các thành phần khác

Quản lý sự kiện (Event handling)

Event handling là kỹ thuật cho phép một thành phần sinh ra các khai báo sự kiện đáp ứng các thay đổi trạng thái bên trong của thành phần Khi trạng thái của thành phần bị thay đổi, thành phần sẽ sinh ra một khai báo sự kiện và truyền tới tất cả các thành phần liên quan Các thành phần liên quan có thể là một ứng dụng cha hay các thành phần khác Kỹ thuận event handling được thiết kế theo cách thức sao cho các sự kiện có thể dễ dàng nắm bắt và trả lời một cách nhất quán Ví dụ: việc gọi lại một thành phần nút bấm, lời gọi ấy sẽ sinh ra một sự kiện khi ta bấm chuột vào nút bấm Trong trường hợp này, sự thay đổi trạng thái button được mang lại khi ta kích vào nút

đó Sự thay đổi trạng thái này gây ra một sự kiện và sự kiện đó được quảng bá tới bất

cứ event listener liên quan nào(Một event listener là một ứng dụng hay một thành phần

được thiết kế để đáp ứng cho sự kiện)

Lưu trữ(Persistence)

Persistence là cách thức mà một thành phần được lưu trữ và khôi phục lại được từ một vị trí cố định, chẳng hạn như ổ cứng Thông tin về một thành phần, thực chất là các thông tin được lưu trữ và khôi phục, là trạng thái bên trong của thành phần, cùng với một số thông tin về mối quan hệ của thành phần đó với một container hoặc các thành phần khác Nhờ sử dụng những thông tin này, một thành phần có thể được lưu trữ một cách an toàn và được tạo lại tại một thời điểm sau đó Persistence là một dịch

vụ quan trọng đặc biệt trong việc thiết kế các công cụ, dịch vụ này cho phép các nhà phát triển sửa đổi các thuộc tính của thành phần để phù hợp với một ứng dụng cụ thể

Bố trí vật lý(Layout)

Layout là một dịch vụ quan trọng của bất cứ một mô hình thành phần nào để hỗ trợ sắp xếp vật lý cho các thành phần Mặc dù layout vật lý chỉ thực sự được đưa tới các thành phần trực quan, nhưng nó lại là một khía cạnh quan trọng của một mô hình thành phần Hỗ trợ của dịch vụ Layout có thể được chia ra là hai phần: sự sắp xếp một thành phần bên trong không gian của chính nó và sự sắp xếp của một thành phần đối với các thành phần khác có chia sẻ không gian trong cùng một container

Hỗ trợ trình tạo ứng dụng(Application Builder Support)

Hỗ trợ dành cho các công cụ xây dựng ứng dụng đã được đưa ra như là một yêu cầu chính cho các mô hình thành phần Hỗ trợ này cấp cho các người dùng khả năng để xây dựng một cách sinh động nên các ứng dụng phức tạp Hỗ trợ này chính là khả năng để các thành phần đưa ra các thuộc tính và hành vi của chúng cho các công cụ xây dựng ứng dụng, như là Visual J++ Các công cụ phát triển sử dụng các thuộc tính

và hành vi này để cho phép người dùng tích hợp và tuỳ chỉnh các thành phần trong

ngữ cảnh của một ứng dụng có ý nghĩa

Phần lớn các công cụ xây dựng ứng dụng cho phép người dùng không chỉ sắp xếp

và soạn thảo ra các thành phần riêng biệt, mà còn chỉ ra mối quan hệ giữa các thành phần, cả bên ngoài và bên trong Hỗ trợ layout, được cung cấp bởi một mô hình thành phần, hỗ trợ việc sắp xếp các thành phần ở bên ngoài, dịch vụ introspection giúp cho các công cụ xây dựng ứng dụng xác định rõ các khả năng của một thành phần và persistence cho phép người dùng lưu lại các thành phần mà đã được tuỳ chỉnh

Hỗ trợ tính toán phân tán(Distributed computing Support)

Dịch vụ cuối cùng của mô hình thành phần đó là sự hỗ trợ cho tính toán phân tán Gần đây vấn đề này ngày càng trở nên quan trọng do sự phát triển của Internet Ngày nay nó đang tiến tới xây dựng nên các ứng dụng mà có khả năng thực thi trong một môi trường phân tán, được kết nối các qua mạng rộng lớn

1.3 Giám sát và dò vết thành phần

1.3.1 Giới thiệu

Với tốc độ phát triển các chương trình phần mềm về cả kích thước cũng như độ phức tạp như hiện nay, điều quan trọng bây giờ là phải giảm giá thành và độ phức tạp đồng thời phải tăng độ tin cậy và tính sửa đổi được[11] Với sự phát triển của công nghệ Internet, rất nhiều hệ thống phân tán được xây dựng đáp ứng các ứng dụng khác nhau Ngày nay, công nghệ thành phần đã giành được sự quan tâm đáng kể trong cộng đồng công nghệ phần mềm Khi ngày càng có nhiều thành phần mềm thứ 3 trên thị trường thì ngày càng có nhiều xưởng phần mềm bắt đầu sử dụng công nghệ thành phần

để phát triển các chương trình hướng thành phần cho các ứng dụng phân tán

Mặc dù có rất nhiều tài liệu đề cập đến việc xây dựng chương trình hướng thành phần, tuy nhiên có rất ít đề cập tới các vấn đề và các thách thức trong việc kiểm tra và duy trì các thành phần phần mềm và các chương trình hướng thành phần phân tán Trên thế giới hiện nay đã đưa ra một số vấn đề về việc kiểm tra và duy trì các phần mềm hướng thành phần Trong đó có một số vấn đề liên quan đến việc dò vết thành phần và dò vết chương trình, gồm có các vấn đề sau:

 Việc hiểu được các hành vi của thành phần trong một hệ thống là rất khó khăn Trong việc kiểm tra và duy trì hệ thống, những người thực hiện thường thấy rất khó để có thể hiểu và giám sát các hành vi của thành phần hệ thống, do các nguyên nhân sau

- Các kỹ sư thường sử dụng những kỹ thuật đặc biệt để theo dõi các hành vi của các thành phần trong cùng nhóm phát triển (in-house component) Điều này

đã tạo ra sự không nhất quán về các thông điệp, các định dạng và các phương thức dò vết khiến người kiểm tra rất khó kiểm soát

- Không có một kỹ thuật hay hàm theo dõi nào được xây dựng sẵn trong các thành phần thứ ba để giám sát các hành vi bên ngoài của chúng

- Không có hàm cấu hình nào cho các client thành phần để điều khiển và cấu hình các kỹ thuật theo dõi có sẵn

- Không có một phương thức hay công nghệ hệ thống nào để điều khiển và giám sát các hành vi bên ngoài của các thành phần

 Việc cô lập, theo dõi và debug các lỗi trong các thành phần là rất khó Trong một hệ thống, các thành phần được phát triển bởi các đội khác nhau và sử dụng các kỹ thuật theo dõi, các định dạng theo dõi rất khác nhau Và các kỹ thuật theo dõi cũng như các thông điệp theo dõi đó làm cho việc xác định và cô lập lỗi rất khó khăn

 Chi phí kiểm tra và điều chỉnh các thành phần là rất cao Việc kiểm tra các chương trình hướng thành phần là một thách thức lớn trong việc kiểm tra hệ thống vì các nhà cung cấp các thành phần không cung cấp một thông tin thi hành nào Do đó, những người kiểm tra hệ thống cũng như các kỹ sư tích hợp phải cố gắng rất nhiều mới có thể nhận ra các vấn đề về thi hành và các thành phần gây

1.3.2 Dò vết thành phần

Theo chuẩn của IEEE (viện công nghệ và kỹ thuật hoa kỳ), “tracking” (dò vết) là tiến trình theo dõi một đối tượng di chuyển hoặc một số lượng lớn biến đầu vào biến đổi, sử dụng một cơ cấu phụ Một thường trình dò vết là một thường trình chương trình cung cấp bản ghi lịch sử của các sự kiện đặc biệt trong quá trình thi hành chương trình [11]

Dò vết phầm mềm bao gồm: dò vết dự án, dò vết sản phẩm và dò vết chương trình

Dò vết dự án là dò vết các kế hoạch, các hoạt động, các sự kiện của dự án trong suốt quá trình phát triển phần mềm Dò vết sản phẩm là chỉ việc điều khiển và giám sát sản phẩm một cách có hệ thống và quản lý được Đây là một tác vụ quan trong trong việc quản lý cấu hình Dò vết chương trình là các hoạt động và hiệu quả trong việc theo dõi các nhân tố của chương trình, bao gồm dữ liệu đầu vào, các kết quả đầu ra và các hành

vi Việc này hỗ trợ các kỹ sư trong việc hiểu và debug chương trình cũng như trong việc kiểm tra và duy trì phần mềm

Khả năng dò vết thành phần

Theo Schmauch Chareles H, khả năng dò vết (traceability) là khả năng có thể xem một item, trạng thái của nó, vị trí nó đã từng ở tại bất kỳ thời điểm nào Khả năng dò vết của một thành phần mềm là phần mở rộng được xây dựng sẵn trong thành phần có khả năng theo dõi trạng thái của thuộc tính và hành vi thành phần Khả năng dò vết thành phần gồm có hai khía cạnh sau:

- Khả năng dò vết hành vi: đây là mức độ để một thành phần dễ dàng dò vết các hành vi bên trong và bên ngoài của nó Có hai cách để dò vết hành vi Thứ nhất là dò vết các hành vi bên trong Cách này thích hợp với việc kiểm tra và debug bằng hộp trắng Mục đích là để dò vết các hàm bên trong, các trạng thái đối tượng bên trong, các điều kiện dữ liệu, các sự kiện và thi hành bên trong thành phần Cách dò vết thứ hai là

dò vết hành vi bên ngoài Cách này thì dùng hộp đen để kiểm tra, tích hợp và duy trì

hệ thống Mục đích chính là để dò vết các dữ liệu, trạng thái đối tượng có thể nhìn thấy, các sự kiện có thể nhìn thấy, các hàm bên ngoài có thể truy cập được và các tương tác với các thành phần khác

- Khả năng điều khiển dò vết: đây là phần mở rộng của khả năng điều khiển trong thành phần để các hàm dò vết có khả năng tuỳ biến dễ dàng Với khả năng điều khiển

dò vết, các kỹ sư có thể điều khiển và thiết lập các hàm tuỳ biến khác nhau, ví dụ như bật và tắt các hàm tuỳ biến và lựa chọn các khuôn dạng dò vết

Ta có thể phân loại dò vết thành phần thành 5 loại như sau:

 Dò vết hoạt động(Operation Trace): ghi lại những tương tác của các hoạt động của thành phần, ví dụ như các lời gọi hàm Dò vết hoạt động được chia thành hai nhóm

o Dò vết hoạt động bên trong: dò vết các lời gọi hàm bên trong thành phần

o Dò vết hoạt động bên ngoài: ghi lại các tương tác giữa các thành phần Dò vết hoạt động bên ngoài ghi lại hoạt động của thành phần qua giao diện của nó, gồm các lời gọi hàm đến và các lời gọi hàm đi ra

 Dò vết thi hành(Performance Trace): ghi lại dữ liệu thi hành và chuẩn hoá các hàm của thành phần trên một nền và môi trường định sẵn Dò vết thi hành rất hữu ích đối với người phát triển và người kiểm tra để nhận ra những điểm tắc nghẽn trong thi hành cũng như chỉnh sửa và kiểm tra thi hành Để dò vết thi hành, các kỹ

sư có thể tạo ra các đo đạc thi hành cho mỗi hàm trong thành phần, bao gồm tốc

độ trung bình, tốc độ lớn nhất, nhỏ nhất

 Dò vết trạng thái(State Trace): là dò vết trạng thái đối tượng hay trạng thái dữ liệu trong một thành phần Trong một kiểm tra thành phần bằng hộp đen, dò vết

trạng thái rất hữu dụng cho người kiểm tra theo dõi được các đối tượng(hay dữ liệu) công cộng nhìn thấy được trong thành phần

 Dò vết sự kiện(Event trace): ghi lại sự kiện và dãy các sự kiện xuất hiện trong thành phần Dò vết sự kiện cung cấp một cách có hệ thống cho các thành phần GUI để theo dõi các sự kiện và dãy sự kiện GUI

 Dò vết lỗi(Error Trace): ghi lại các thông điệp lỗi sinh ra từ thành phần Dò vết lỗi cung cấp tất cả các thông điệp lỗi, các ngoại lệ, và các thông tin xử lý liên quan được sinh ra từ thành phần

1.3.3 Cơ chế tăng khả năng dò vết cho thành phần

Khi một chương trình hướng thành phần được tích hợp vào một thành phần phần mềm thì khả năng dò vết của chương trình sẽ phụ thuộc vào khả năng dò vết của thành phần Khả năng quan sát thành phần cũng phụ thuộc vào khả năng dò vết thành phần Trong thực tế, chúng ta phải sử dụng các kỹ thuật đặc biệt để thêm các đoạn mã theo dõi vào chương trình Tuy nhiên ta cũng thấy việc hỗ trợ các thành phần phát triển bởi các tổ chức khác nhau hay các thành phần thương mại là rất khó khăn Chúng ta sẽ thảo luận ba kỹ thuật dò vết có hệ thống sau

Bảng liệt kê ba các tiếp cận cơ bản

Cách dò vết Thêm đoạn mã

dựa trên khung làm việc

Tự động thêm đoạn mã

Tự động đóng gói thành phần phần mềm

Hình 1.2: Các kiểu dò vết thành phần

Dò vết hoạt động, dò vết thi hành

Dò vết hoạt động, dò vết thi hành

Các thành phần

áp dụng được

Các thành phần in-house

Các thành phần in-house

Các thành phần in-house và thương mại

Phương thức 1: Dò vết dựa trên khung (framework-base tracking) Trong cách tiếp

cận này, người ta định nghĩa một khung dò vết (ví dụ như một thư viện lớp) cung cấp cho các kỹ sư phát triển để thêm vào các đoạn mã dò vết chương trình để có thể điều khiển các tham chiếu bằng tay được Phương thức này thường thực hiện dựa trên thư viện dò vết chương trình Các kỹ sư phát triển các thành phần thường sử dụng thư viện này để thêm các đoạn mã dò vết vào trong các thành phần Cách tiếp cận này rất linh hoạt và dễ sử dụng Nó có thể hỗ trợ tất cả các kiểu dò vết, đặc biệt là dò vết lỗi và dò vết GUI Tuy nhiên cách thức này lại có một số hạn chế Thứ nhất là chi phí cao Thứ hai là phụ thuộc vào người thực hiện thêm mã dò vết Và cuối cùng là phải có mã nguồn của chương trình Điều này là rất khó đối với các thành phần thương mại vì chúng không bao giờ cung cấp mã nguồn

Phương thức 2: Tự động thêm đoạn mã Cách tiếp cận này là phần mở rộng của

trên Bên cạnh một khung dò vết còn có một công cụ tự động để thêm các đoạn mã dò vết vào trong mã nguồn của thành phần Một ví dụ điển hình cho phương thức này là công cụ thêm đoạn dò vết dựa vào phân tích cú pháp Để dò vết hoạt động, ta thêm các đoạn dò vết hoạt động vào mỗi hàm của lớp tại vị trí bắt đầu và kết thúc hàm để theo dõi được giá trị đầu vào và các biến đầu ra Tương tự, ta có thể thêm đoạn mã dò vết hoạt động vào trước và/hoặc sau mỗi lời gọi hàm Đoạn mã dò vết thi hành cũng có thể thêm vào tương tự như vậy để dò vết thi hành của các hàm Mặc dù cách tiếp cận này

có thể giảm được chi phí, nhưng nó cũng có những hạn chế của nó Thứ nhất là nó đòi hỏi phải có mã nguồn Như vậy là không thể áp dụng cho các thành phần thương mại được Thứ hai là nó không linh hoạt, do phụ thuộc vào tính chất tự động, không thể thêm đoạn mã dò vết vào bất kỳ nơi nào ta muốn Thứ ba là công cụ phân tích rất phức tạp Khi chương trình hướng phần mềm có các thành phần được phát triển từ nhiều ngôn ngữ khác nhau thì việc xây dựng các công cụ phân tích rất phức tạp, đòi hỏi chi phí cao

Phương thức 3: Tự động đóng gói thành phần Cách tiếp cận này là một cách mở

rộng khác của các thứ nhất Cách tiếp cận này sẽ thêm các đoạn mã dò vết để giám sát giao diện bên ngoài và các hành vi của thành phần bằng cách đóng gói chúng vào các hộp đen Tư tưởng là đóng gói tất cả các thành phần có thể sử dụng lại được (hoặc các

thành phần thứ ba) với các đoạn mã dò vết để tạo thành thành phần có thể theo dõi được trong một hộp đen Với đoạn mã dò vết, các kỹ sư có thể giám sát được các tương tác giữa thành phần thứ ba với các thành phần ứng dụng Cách tiếp cận này rất hữu dụng trong việc xây dựng phần mềm hướng thành phần dựa vào các thành phần phần mềm thứ ba, ví dụ như EJB So với hai phương thức trên, phương thức này có một số điểm tiến bộ Thứ nhất là chi phí thấp Thứ hai là ta có thể tách biệt được đoạn

mã dò vết thêm vào với mã nguồn thành phần Do không cần mã nguồn, phương thức này có thể dùng cho cả thành phần in-house lẫn thành phần thương mại Tuy nhiên nó không hỗ trợ dò vết lỗi và dò vết trạng thái do tính độc lập của nó đối với các thành phần

Như vậy mỗi cách tiếp cận có điểm mạnh và điểm yếu riêng Trong thực tế, chúng đều được sử dụng cho các kiểu dò vết khác nhau Để thiết kế và xây dựng các thành phần dò vết, các kỹ sư cần phải có hiểu biết về kiến trúc của thành phần, giao diện dò vết và các phương tiện hỗ trợ Họ phải đối mặt với các thách thức sau:

(1) Làm thế nào để thiết kế và thực thi các thành phần có thể dò vết và quan sát được trong một môi trường phân tán?

(2) Làm thế nào để cung cấp một khung dò vết xác định và kỹ thuật dò vết hiệu quả với chi phí và sức lực thấp nhất?

(3) Làm thế nào để hỗ trợ và giám sát hành vi của các thành phần thương mại trong phần mềm hướng thành phần?

Sau đây chúng ta sẽ xem xét một giải pháp dò vết hệ thống

1.3.4 Mô hình hướng sự kiện của Java giúp hỗ trợ dò vết

Mô hình dò vết hướng sự kiện là một kỹ thuật hệ thống hỗ trợ các kỹ sư giám sát, kiểm tra các hành vi của thành phần và các tương tác của chúng trong một chương trình hướng thành phần Tư tưởng cơ bản của mô hình này dựa trên mô hình sự kiện Java cho các thành phần GUI Tất cả các thành phần phần mềm và các phần tử của chúng đều được coi là nguồn sự kiện dò vết Trong một thành phần phần mềm, các kỹ

sư phát triển thành phần hoặc công cụ dò vết tự động có thể đưa vào đoạn mã dò vết để đưa ra 5 loại dò vết sự kiện Đó là dò vết thi hành, dò vết hoạt động, dò vết lỗi, dò vết trạng thái và dò vết các sự kiện GUI Những sự kiện này được đóng gói thành thông điệp dò vết sự kiện và được đưa vào các hành đợi thông điệp dò vết theo từng loại

Để bắt được các sự kiện dò vết khác nhau, chúng ta sử dụng bộ nghe (listener) dò vết để tiếp nhận các sự kiện, gửi chúng đến bộ xử lý dò vết để tạo ra dò vết thích hợp

và đưa chúng vào nơi lưu trữ dò vết đặc biệt

Trong hình ta thấy kỹ thuật dò vết theo mô hình sự kiện dựa trên một agent dò vết cung cấp một tập các thành phần có thể dò vết được (traceable component) trong một máy tính Một thành phần có thể dò vết được là một thành phần phần mềm được thiết

kế để hỗ trợ việc quan sát và giám sát hành vi, dữ liệu, trạng thái đối tượng, thi hành các hàm và tương tác với thành phần khác Trong giải pháp này, một thành phần có thể

dò vết được có thêm hai phần khác nữa:

 Tracking interface: được sử dụng để thiết lập kết nối đến agent dò vết Hình a đưa ra một thủ tục sinh ra một bộ dò vêt (tracker) cho thành phần bằng cách đưa ra

yêu cầu liên kết tới agent dò vết thông qua giaodiện dò vết ItraceableBean trong

đoạn mã là một giao diện dò vết trong gói dò vết Java

 Dynamic generated traker: được tạo ra bởi Agent dò vết Mỗi thành phần sẽ tiếp nhận một bộ dò vêt sau khi nó kết nối đến Agent Khi đó, người phát triển có thể sử dụng các giao diện để cung cấp các hàm dò vết khác nhau cho các loại dò

vết khác nhau IBeanTracker trong đoạn mã là chi tiết các giao diện đối với các

hàm dò vết

Một agent dò vết gồm các phần cơ bản sau:

Bộ nghe dò vết(Tracking listener): là một chương trình đa luồng, nghe và tiếp nhận tất cả các sự kiện dò vết qua hàng đợi thông điệp dò vết và gửi chúng tới bộ xử lý dò vết Hình b là chuỗi tương tác giữa thành phần có thể dò vết, bộ nghe dò vết và bộ xử

lý dò vết

Bộ xử lý dò vết(Tracking processor): sinh ra các dò vết chương trình theo các sự kiện dò vết dựa trên kiểu, thông điệp và dữ liệu dò vết, và lưu giữ chúng vào nơi thích hợp

Hình 1.3 : Cấu trúc mô hình dò vết hướng sự kiện

Cấu hình dò vết (Tracking Configuration): cung cấp một giao diện người sử dụng cho phép người dùng có thể phát hiện và cấu hình các tính năng dò vết khác nhau cho mỗi thành phần

Hình 1.5: Gói dò vết Hình 1.4: Chuỗi tương tác

1.3.5 Gói dò vết của Java

Các công nghệ hướng thành phần hiện thời (như JavaBean, EJB và CORBA) không

cung cấp được các kỹ thuật có tính hệ thống cũng như khả năng dò vết và giám sát các

hành vi thành phần Vì vậy những người phát triển sử dụng thêm các phương thức đặc

biệt để xây dựng các thành phần có thể dò vết Gói dò vết Java cung cấp cho người

phát triển một số giao diện chung nhất để tạo nên các thành phần Java có thể dò vết

được Bao gồm:

Một giao diện cho bộ dò vêt thành phần(xem IBeanTracker trong đoạn mã Gói dò

vết) Giao diện này cung cấp một giao diện chức năng dò vết tổng quát giữa một bộ dò

vết thành phần với agent dò vết Các sự kiện và yêu cầu dò vết khác nhau đều có thể

gửi tới agent dò vết

Giao diện Agent (xem ITRAgent trong đoạn mã Gói dò vết)Nó là một phần của

agent dò vết Sử dụng giao diện này, người phát triển có thể đưa ra yêu cầu tới agent

dò vết để tạo ra một bộ dò vết và thiết lập các kết nối cho một thành phần

Giao diện thành phần có thể dò vết được (xem ITracbleBean trong đoạn mã Gói dò

vết) Giao diện này cho phép người phát triển ghép bộ dò vết với thành phần (Xem

Hình 1.6: Bộ phỏng theo Tracker

đoạn mã thi hành bindBeanTraker) Hàm getTracePropertie() có thể dùng để phát hiện

ra các thuộc tính dò vết của một thành phần

Giao diện phỏng theo bộ dò vết (xem BeanTrackerAdaptor và GUIListenerAdaptor

trong đoạn mã bộ phỏng theo Traker) Giao diện này cung cấp một bộ dò vết trong trường hợp môi trường dò vết thành phần không được thiết lập

3.2.5 Môi trường dò vết cho phần mềm thành phần

Trong hình 1.8, chúng ta đã phát triển một môi trường hỗ trợ cho phần mềm dựa thành phần

Hệ thống này sẽ bao gồm một số các bộ Tracking Agent và một server dò vết Mỗi một máy tính trên mạng sẽ có một bộ Tracking Agent dựa trên công nghệ của EJB Nó tương tác với những bộ dò vết bên trong của các thành phần trong cùng một máy sử dụng hàng đợi thông điệp dò vết (trong Java Message Queue)

Một chức năng chính của Tracking Agent là điều khiển, ghi lại và giám sát những hành vi khác nhau của thành phần trong một mô hình không đồng bộ Hơn nữa, Tracking Agent giao tiếp với server dò vết để truyền dữ liệu dò vết vào trong khuôn thức dò vết đã cho Server dò vết đóng vai trò là server trung tâm cho phép các kỹ sư giám sát các Tracking Agent để tập hợp dữ liệu dò vết khác nhau và phân tích chúng

Hình 1.7: Sự thi hành của bindBeanTraker

Server dò vết sẽ bao gồm những phần sau:

- Giao diện giao tiếp với Tracking Agent để chuyển các loại dò vết chương trình thông qua mạng

- Bộ xử lý dữ liệu dò vết: Đóng vai trò xử lý các dò vết chương trình đã được tập hợp từ những Tracking Agent khác nhau qua môi trường phân tán

- Kho chứa dò vết chương trình: Lưu trữ và quản lý tất cả các loại dò vết chương trình từ các thành phần qua một môi trường phân tán

- Bộ phân tích và báo cáo dò vết: Làm cho người dùng có thể phân tích và báo cáo các loại dò vết chương trình khác nhau đối với những thành phần khác nhau trong một hệ thống phân tán

- Giao diện GUI: Hỗ trợ các tương tác người dùng giữa server dò vết và các kỹ

sư để kiểm tra và giám sát những hành vi chương trình trong một giao diện tập trung

Sử dụng khuôn thức dò vết chuẩn là cần thiết để đưa ra các thông điệp dò vết phù hợp cho mỗi thành phần trong một chương trình phân tán Một khuôn thức dò vết rõ ràng sẽ tạo điều kiện dễ dàng để đưa ra các thông điệp dò vết có thể hiểu được Điều này làm tăng khả năng hiểu các thành phần và giúp cho sự phân lập, sửa chữa các lỗi Một môi trường dò vết phân tán sẽ cung cấp hai loại thông tin dò vết:

Hình 1.8 Môi trường dò vết phân tán

+ Các lệnh dò vết: Hỗ trợ cho server dò vết điều khiển và giao tiếp với Tracking Agent trong môi trường phân tán Mỗi một lệnh sẽ gồm có ID thông điệp lệnh (00), mã lệnh, nhãn thời gian, và các tham số lệnh

+ Dữ liệu dò vết: Dữ liệu dò vết gồm có ID thông điệp (01), loại dữ liệu, nhãn thời gian, ID thành phần, dữ liệu dò vết Dữ liệu dò vết sẽ chỉ ra ở đâu và khi nào thông điệp dò vết được đưa ra Mỗi một loại dữ liệu sẽ có khuôn thức dữ liệu dò vết riêng của nó Các Tracking Agent sẽ đưa ra dữ liệu dò vết khác nhau đối với mỗi thành phần

có thể dò vết trong một kho chứa dò vết cục bộ

Chương 2 Hệ thống đối tượng phân tán

2.1 Giới thiệu

Mô hình hệ thống đối tượng phân tán được hình thành từ các đối tượng tồn tại trên

hệ thống phân tán Không giống như đối tượng cục bộ (chỉ được gọi bởi tiến trình cục

bộ trên cùng một máy tính có chứa đối tượng), đối tượng phân tán có thể được bởi một tiến trình từ xa chạy trên một máy tính khác kết nối qua mạng với máy tính chứa các đối tượng[7]

Trong mô hình đối tượng phân tán, tài nguyên trên mạng chính là các đối tượng phân tán Để yêu cầu dịch vụ từ một tài nguyên mạng, một tiến trình sẽ gọi một trong các hoạt động (hay phương thức) của nó, truyền dữ liệu dưới dạng các tham số tới phương thức Phương thức sẽ thực thi trên host từ xa và trả về các giá trị kết quả cho tiến trình yêu cầu

object state data item object operation

Một tiến trình đang chạy trên máy chủ A thực hiện lời gọi một phương thức tới một đối tượng phân tán trên máy chủ B, truyền dữ liệu thông qua các biến (nếu có)

Phương thức gọi đến một hoạt động được thực hiện bởi một phương thức trên máy chủ B và giá trị trả về (nếu có) sẽ được gửi từ máy chủ B về máy chủ A

Tiến trình thực hiện việc sử dụng đối tượng từ xa sẽ được gọi là tiến trình xử lý phía khách (client process) của đối tượng đó và các phương thức của đối tượng sẽ được gọi

là phương thức từ xa (remote method)

Mô hình đối tượng phân tán tập trung vào lời gọi các phương thức, còn việc truyền

số liệu chỉ đóng vai trò thứ yếu

Đối tượng phân tán sẽ được cung cấp bởi tiến trình xử lý từ máy phục vụ đối tượng (object server) Để thuận tiện, việc đăng ký đối tượng (object registry) cần phải thể hiện trong kiến trúc hệ thống để các đối tượng từ xa có thể được đăng ký

Để truy cập vào đối tượng từ xa, tiến trình xử lý từ máy khách (object client) sẽ tra cứu các đối tượng đăng ký để tham chiếu tới đối tượng Tham chiếu ở đây được coi như là “một điều khiển” (handle) tới đối tượng; nó là sự trình diễn mà qua đó có thể xác định vị trí đối tượng tại máy tính chứa đối tượng đó Sự tham chiếu này được máy khách đối tượng dùng để thực hiện lời gọi tới các phương thức

Về mặt logic, các object client có thể thực hiện lời gọi trực tiếp đến phương thức từ

xa Trong thực tế, các lời gọi lại thường được điều khiển bởi các thành phần phần mềm, còn được gọi là uỷ quyền máy khách (client proxy), nó sẽ tương tác với phần mềm trên máy chủ phía khách (máy chủ thực hiện lời gọi)…

Việc hỗ trợ trong thời gian chạy là để đáp ứng việc truyền thông liên tiến trình cần thiết cho việc truyền lời gọi đến máy chủ từ xa, bao gồm cả việc sắp xếp thứ tự các biến dữ liệu cần thiết cho việc truyền tới các đối tượng từ xa

Một kiến trúc tương tự cũng cần phải có ở phía server, nơi mà sự hỗ trợ thời gian chạy cho hệ thống đối tượng từ xa điều khiển việc nhận các thông điệp, không sắp xếp

dữ liệu, và chuyển tiếp lời gọi đến thành phần phần mềm được gọi là uỷ quyền máy chủ (server proxy)

Server proxy giao tiếp thông qua giao diện với đối tượng phân tán qua lời gọi đến phương thức cục bộ, chuyển tiếp các dữ liệu không sắp xếp lại(để nguyên) cho các biến

Kết quả trả về của lời gọi phương thức sẽ được thực hiện bởi một số công việc (task) ở trên máy chủ server Kết quả trả về của việc thi hành phương thức, bao gồm cả

dữ liệu được sắp xếp sẽ được truyền từ máy chủ server tới máy chủ client thông qua hỗ trợ thời gian chạy (runtime support) và hỗ trợ mạng (network support) ở cả hai phía

Mô hình đối tượng phân tán được kế thừa trong các ứng dụng phân tán, theo đó hầu hết các kỹ thuật trên mô hình này đều có thể áp dụng được Một số kỹ thuật được biết đến là:

- Triệu gọi phương thức từ xa trong Java (Java Remote Method Invocation - RMI)

- Kiến trúc môi giới gọi các đối tượng chung (Common Object Request Broker Architecture – CORBA)

- Mô hình đối tượng thành phần phân tán (Distributed Component Object Model - DCOM)

- Các kỹ thuật hỗ trợ Giao thức truy nhập đối tượng đơn giản (Simple Object Access Protocol SOAP)

2.2 Sự phân tán trong môi trường Java: RMI

2.2.1 Hệ thống đối tượng phân tán trong môi trường Java

Các hệ thống phân tán đòi hỏi sự truyền thông giữa các quá trình tính toán diễn ra trong các không gian địa chỉ khác nhau, rõ hơn đó là các host khác nhau Đối với kĩ thuật truyền thông cơ bản, ngôn ngữ lập trình Java hỗ trợ các socket, một cơ chế khá mềm dẻo và hiệu quả cho sự truyền thông thông thường Tuy nhiên, các socket đòi hỏi client và server phải tham gia vào các giao thức mức ứng dụng (applications-level protocols) để mã hóa và giải mã các thông điệp được trao đổi, và việc thiết kế các giao thức đó là nặng nề và có thể dễ gây lỗi[10]

Một sự thay thế các socket đó là lời gọi thủ tục từ xa (RPC - Remote Procedure Call), trừu tượng hóa giao diện truyền thông tới mức của một lời gọi thủ tục Thay cho

sự làm việc trực tiếp với các socket, lập trình viên có cảm giác như đang gọi một thủ tục địa phương, khi mà trong thực tế các đối số của lời gọi được đóng gói và được gửi tới đích ở xa của lời gọi Các hệ thống RPC mã hóa các đối số và trả về các giá trị, sử dụng một sự biểu diễn dữ liệu bên ngoài, ví dụ như XDR

RPC, tuy nhiên lại không truyền đạt tốt vào trong các hệ thống đối tượng phân tán, nơi mà sự truyền thống giữa các đối tượng mức chương trình (program-level objects)

cư trú trong các không gian địa chỉ được yêu cầu Để so khớp các ngữ nghĩa của lời gọi đối tượng, các hệ thống đối tượng phân tán cần đến lời gọi phương thức từ xa hay RMI (Remote Method Invocation) Trong các hệ thống được đề cập trên, một đối tượng đại diện địa phương (local surrogate (stub) object) sẽ quản lý các lời gọi trên một đối tượng từ xa

Mục đích hỗ trợ đối tượng phân tán trong ngôn ngữ Java là:

- Hỗ trợ liền mạch triệu gọi từ xa đối tượng trên các máy ảo khác nhau

- Hỗ trợ callback từ các server tới các applet

- Tích hợp mô hình đối tượng phân tán vào ngôn ngữ lập trình Java một cách tự nhiên trong khi vẫn giữ lại được hầu hết ngữ nghĩa đối tượng của ngôn ngữ lập trình Java

- Tạo nên sự khác biệt giữa mô hình đối tượng phân tán với mô hình đối tượng của nền Java cục bộ

- Làm cho việc viết các ứng dụng phân tán đáng tin cậy càng đơn giản càng tốt

- Duy trì được các kiểu an toàn (type-safety) cung cấp bởi môi trường runtime của nền Java

- Hỗ trợ các kiểu tham chiếu ngữ nghĩa khác nhau cho các đối tượng từ xa; ví dụ các kiểu tham chiếu trực tiếp (live), không liên tục hay các kiểu tham chiếu liên tục hay lazy activation

Duy trì nền an toàn của nền Java được cung cấp bởi các security manager và các class loader

Các mục đích trên cũng chính là yêu cầu đối với mô hình RMI sao cho đơn giản (dễ

sử dụng) và tự nhiên (hợp với ngôn ngữ)

Sự khác biệt giữa mô hình phân tán và không phân tán trong môi trường Java như sau

Trong nền Java, mô hình đối tượng phân tán và mô hình đối tượng có những điểm chung:

 Một tham chiếu đến một đối tượng từ xa có thể được gửi như là một đối số hay được trả về như là một kết quả của lời gọi phương thức (cả cục bộ hay từ xa)

 Một đối tượng từ xa có thể đặt(cast) trong tập các giao diện từ xa bất kỳ hỗ trợ bởi các thi hành có sử dụng cú pháp cho việc đặt được cài sẵn trong ngôn ngữ lập trình Java

 Toán tử cài sẵn instanceof có thể sử dụng để test các giao diện từ xa được cung cấp bởi một đối tượng từ xa

Trong nền Java, mô hình đối tượng phân tán khác với mô hình đối tượng ở những điểm sau:

 Các client của các đối tượng từ xa tương tác với các giao diện từ xa chứ không tương tác với lớp thi hành của các giao diện đó

 Các đối không từ xa gửi tới, và kết quả trả về từ lời gọi phương thức từ xa được gửi bằng một bản copy chứ không phải là tham chiếu Đó là vì các tham chiếu tới đối tượng chỉ có tác dụng trong một máy ảo đơn

 Một đối tượng từ xa được gửi đi bằng tham chiếu chứ không phải là một bản copy của sự thực thi từ xa thật sự

 Ngữ nghĩa của một số phương thức được định nghĩa trong lớp

java.lang.Object cũng thích ứng với các đối tượng từ xa

 Khi chế độ lỗi của triệu gọi đối tượng từ xa phức tạp hơn chế độ lỗi của triệu gọi đối tượng cục bộ thì phía client sẽ phải thêm vào các ngoại lệ (exception) có thể xảy ra trong quá trình triệu gọi phương thức từ xa

2.2.2 Giới thiệu ứng dụng phân tán với RMI

Trong mô hình đối tượng phân tán Java, một đối tượng từ xa (remote object) là đối tượng có các phương thức có thể được gọi từ một máy ảo Java khác, có thể nằm trên

một máy chủ khác Đối tượng dạng này sẽ được mô tả bởi một hay nhiều giao diện từ

xa (remote interface), đó là các giao diện được viết bởi ngôn ngữ lập trình Java khai báo các phương thức của đối tượng từ xa[10]

Lời gọi phương thức từ xa (Remote method invocation - RMI) là một hành động gọi đến một phương thức của một đối tượng từ xa Điều quan trọng là việc gọi phương thức trên đối tượng từ xa phải có cú pháp tương tự như gọi phương thức trên đối tượng cục bộ

Các ứng dụng RMI thường được chia thành hai phần chương trình riêng biệt: một ở phía server và một ở phía client Ứng dụng phía server sẽ tạo các đối tượng từ xa, tạo các tham chiếu để truy cập đến các đối tượng này và chờ phía client gọi các phương thức trên các đối tượng này Ứng dụng phía client lấy tham chiếu từ xa tới một hoặc nhiều đối tượng và sau đó sẽ gọi các phương thức trên chúng RMI cung cấp kỹ thuật cho phép server và client kết nối và truyền thông tin qua lại với nhau Một ứng dụng như vậy được gọi là ứng dụng đối tượng phân tán

Các ứng dụng đối tượng phân tán cần phải:

- Định vị các đối tượng từ xa

Các ứng dụng có thể sử dụng một trong hai kỹ thuật để giành được các tham chiếu tới các đối tượng từ xa Kỹ thuật thứ nhất là đăng ký đối tượng từ xa với tiện ích đặt

tên đơn giản của RMI, rmiregistry, kỹ thuật thứ hai là gửi và trả lại các tham chiếu đối

tượng từ xa như là một phần của vận hành bình thường

- Giao tiếp với các đối tượng từ xa

Các chi tiết của sự giao tiếp giữa các đối tượng từ xa được điều khiển bởi RMI; đối với người lập trình, sự giao tiếp từ xa giống như là một lời gọi phương thức chuẩn

- Tải các mã bytecode cho các đối tượng được chuyển như các tham số hoặc giá trị trả về

RMI cho phép một đối tượng gọi (caller) chuyển các đối tượng tới các đối tượng từ

xa, RMI sẽ cung cấp các kỹ thuật cần thiết cho việc tải mã của đối tượng (object‟s code) cũng như sự truyền nhận dữ liệu của nó

Hình minh hoạ dưới đây mô tả một ứng dụng phân tán RMI sử dụng bản đăng ký (registry) để lấy các tham chiếu của một đối tượng từ xa Phía server gọi đăng ký để gán tên cho một đối tượng từ xa Phía client sẽ tìm kiếm đối tượng theo tên của nó trên bản đăng ký phía server và sau đó gọi một phương thức trên nó Hình minh hoạ cũng chỉ ra rằng hệ thống RMI sử dụng một web server để tải các đoạn mã lớp được viết bằng ngôn ngữ lập trình Java, từ server đến client và từ client đến server, cho các đối tượng khi cần thiết RMI có thể nạp các đoạn mã lớp sử dụng bất kỳ giao thức URL nào hỗ trợ nền Java (HTTP, FTP, File…)

2.2.3 Kiến trúc của cơ chế RMI

2.2.3.1 Interfaces nòng cốt của RMI

Kiến trúc RMI dựa trên một yếu tố quan trọng đó là: việc định nghĩa ra các hành vi

và sự thi hành của các hành vi đó, các hành vi đó là các nội dung khác nhau RMI cho phép các đoạn mã định nghĩa ra các hành vi và các đoạn mã thi hành các hành vi đó duy trì ở hai vị trí tách biệt nhau và chạy trên các máy ảo Java khác nhau Yếu tố này rất phù hợp với các nhu cầu của một hệ thống phân tán, hệ thống phân tán là một hệ thống mà có các client quan tâm đến định nghĩa (giao diện của dịch vụ) của một dịch

vụ và các server thì tập trung vào việc cung cấp các dịch vụ[10]

Một cách cụ thể hơn, trong RMI, định nghĩa của một dịch vụ từ xa được viết mã nhờ sử dụng một interface của java, sự thi hành của dịch vụ từ xa được viết mã bên trong một lớp Do đó chìa khoá để hiểu được cơ chế RMI là đó là: các interface thì định nghĩa ra các hành vi, còn các lớp thì định nghĩa ra các thi hành của hành vi đó

Hình 2.3: Kiến trúc của RMI

Interface của Java không chứa các mã thi hành RMI hỗ trợ hai lớp thi hành trên cùng một interface Lớp thứ nhất là sự thực thi của hành vi và nó chạy trên server Còn lớp thứ hai hoạt động như là một sự uỷ quyền của một dịch vụ từ xa và nó chạy trên client

Hình 2.2 : Đăng ký tham chiếu đối tượng từ xa

Hình 2.4: Sự hỗ trợ thi hành của RMI

Một chương trình phía client tạo ra các lời gọi phương thức trên đối tượng uỷ quyền RMI sẽ gửi yêu cầu này tới các máy ảo ở xa, tiến hành thực thi yêu cầu Bất cứ giá trị trả về nào được trả về bởi sự thi hành lời gọi phương thức đều được gửi trở lại dịch vụ uỷ quyền (Proxy) và sau đó tới chương trình của phía khách

Các giao diện và lớp mô tả các hành vi từ xa của hệ thống RMI được định nghĩa trong gói Java.rmi Hình minh hoạ dưới đây sẽ mô tả mối quan hệ giữa giao diện và lớp

Trong RMI, giao diện từ xa khai báo tập các phương thức có thể được gọi từ một máy ảo Java từ xa RMI cung cấp một giao diện từ xa có tên Remote Khi một lớp muốn đối tượng của nó có thể truy cập được từ xa thì lớp đó phải thi hành giao diện này Một giao diện từ xa phải thoả mãn các yêu cầu sau:

- Một giao diện từ xa phải là mở rộng (trực tiếp hoặc gián tiến) của giao diện java.rmi.Remote

Mỗi phương thức khai báo trong một giao diện hoặc trong các siêu giao diện của chúng phải thoả mãn khai báo phương thức từ xa như sau:

Một khai báo phương thức từ xa phải bao gồm ngoại lệ java.rmi.RemoteException (hoặc một trong các siêu lớp của nó phải là java.io.IOException hoặc java.lang

Hình 2.5 : Quan hệ giữa giao diện và lớp

Exception) trong mệnh đề throws của nó, khi thêm vào các ngoại lệ ứng dụng đặc biệt bất kỳ (chú ý rằng các ngoại lệ ứng dụng đặc biệt không cần thiết phải là mở rộng của java.rmi.RemoteException)

Trong một khai báo phương thức từ xa, một đối tượng từ xa, được khai báo như là một biến hay giá trị trả về (có thể khai báo trực tiếp trong danh sách các biến hoặc có thể nhúng trong một biến của đối tượng không phải là từ xa), phải khai báo như là một giao diện từ xa chứ không phải là lớp thi hành của giao diện

Giao diện java.rmi.Remote là giao diện rỗng không có phương thức nào:

Public interface Remote()

Một giao diện từ xa phải ít nhất là mở rộng của giao diện java.rmi.Remote ( hoặc là một giao diện từ xa mở rộng của giao diện java.rmi.Remote) Tuy nhiên một giao diện

từ xa cũng có thể là mở rộng của một giao diện không từ xa với điều kiện sau:

Một giao diện từ xa có thể là mở rộng của một giao diện không từ xa, miễn là tất cả các phương thức của giao diện mở rộng thoả mãn các yêu cầu của phương thức khai báo từ xa

Ví dụ sau đây, giao diện BankAccount định nghĩa một giao diện từ xa để truy cập vào tài khoản ngân hàng Nó bao gồm các phương thức gửi tiền vào ngân hàng, lấy số

dư tài khoản, rút tiền từ tài khoản

public interface BankAccount extends java.rmi.Remote {

public void deposit(float amount)

throws java.rmi.RemoteException;

public void withdraw(float amount)

throws OverdrawnException, java.rmi.RemoteException;

public float getBalance()

throws java.rmi.RemoteException;

}

Ví dụ sau sẽ thể hiện một giao diện từ xa hợp lệ Beta là mở rộng của giao diện không từ xa Alpha, có các phương thức từ xa và giao diện java.rmi.Remote:

public interface Alpha {

public final String okay = "constants are okay too";

public Object foo(Object obj)

throws java.rmi.RemoteException;

public void bar() throws java.io.IOException;

public int baz() throws java.lang.Exception;

}

public interface Beta extends Alpha, java.rmi.Remote {

public void ping() throws java.rmi.RemoteException;

}

2.2.3.2 Kiến trúc các tầng giao thức RMI

Các thi hành của RMI cần thiết phải được tạo nên từ ba tầng trừu tượng Tầng thứ nhất đó là tầng của Stub và Skeleton, là tầng nằm ở ngay phía dưới tầm nhìn thấy của

nhà phát triển, tầng này nó chặn lại các lời gọi phương thức của phía client và nó gửi một lần nữa tới một dịch vụ RMI ở xa Tầng tiếp theo đó là tầng tham chiếu từ xa , tầng này nó sẽ biết cách để thể hiện và quản lý các tham chiếu mà được tạo ra từ phía client tới các đối tượng dịch vụ từ xa Trong JDK 1.1 (phiên bản Java) tầng này nó sẽ kết nối các client tới các đối tượng dịch vụ từ xa đang chạy và được xuất khẩu trên một server Kết nối này là liên kết một-một Và trong Java 2 SDK thì tầng này được nâng cấp để hỗ trợ việc kích hoạt các đối tượng dịch vụ từ xa đang không hoạt động qua Remote Object Activation Tầng cuối cùng là tầng giao vận, tầng này dựa trên các kết nối TCP/IP giữa các máy tính trên một mạng[10]

Hình 2.6: Các tầng kiến trúc của RMI

Bằng cách sử dụng một kiến trúc được phân tầng, thì mỗi tầng của nó có thể được nâng cấp và được thay thể mà không ảnh hưởng gì tới những tầng còn lại của hệ thống

Ví dụ tầng giao vận có thể được thay thế bởi một tầng UDP/IP mà không hề ảnh hưởng tới các tầng ở trên Bây giờ ta đi vào tìm hiểu chi tiết từng tầng

Tầng Stub và Skeleton

Tầng Stub và Skeleton của RMI nằm ở ngay phía dưới tầm nhìn của các nhà phát triển Java Trong tầng này thì RMI sử dụng kiểu thiết kế Proxy Trong kiểu thiết kế Proxy, thì một đối tượng trong một ngữ cảnh này thì sẽ được trình diễn bởi một đối tượng khác trong một ngữ cảnh khác Proxy sẽ biết cách để gửi các lời gọi phương thức giữa các đối tượng tham gia

Skeleton là một lớp trợ giúp, nó được sinh ra để cho RMI sử dụng Lớp Skeleton sẽ biết cách để giao tiếp với lớp Stub qua một liên kết RMI Lớp skeleton điều khiển cuộc trao đổi với lớp stub Nó đọc các tham số từ lời gọi phương thức từ liên kết, sau đó tạo

ra lời gọi phương thức tới đối tượng thi hành dịch vụ từ xa, sau đó nhận giá trị trả về, rồi chuyển giá trị trả về đó cho lớp Stub

Tầng tham chiếu từ xa

Tầng này hỗ trợ một đối tượng RemoteRef, đối tượng này thể hiện một liên kết tới một đối tượng thực thi dịch vụ từ xa Các đối tượng stub sử dụng phương thức invoke() trong đối tượng RemoteRef để gửi lời gọi phương thức

Sự thi hành của RMI trong phiên bản JDK 1.1 chỉ cung cấp một cách thức để các client kết nối tới các đối tượng thi hành dịch vụ từ xa, đó là kết nối điểm - điểm Trước khi một client có thể sử dụng một dịch vụ từ xa, thì dịch vụ từ xa đó phải được trình diễn trên server và được đăng ký tới hệ thống RMI ( nếu nó là dịch vụ chính, thì

nó cũng phải được đặt tên ,và được đăng ký trong register RMI)

Trong phiên bản Java2 JDK sự thi hành của RMI thêm vào một semantic cho kết nối client-server Trong phiên bản này RMI hỗ trợ các đối tượng từ xa có khả năng tự kích hoạt, khi một lời gọi phương thức được tạo ra từ Proxy tới đối tượng có khả năng

tự kích hoạt Lúc đó RMI sẽ xác định xem: nếu sự thi đối tượng dịch vụ từ xa là chưa được kích hoạt, thì RMI sẽ kích hoạt nó và khôi phục trạng thái của nó tới một file trên đĩa

Như chúng ta đã biết, TCP/IP cung cấp kết nối có tính liên tục, theo luồng giữa hai máy dựa trên địa chỉ IP và số của cổng (port number) tại mỗi điểm cuối Thông thường, tên một DNS được sử dụng thay cho địa chỉ IP; điều đó có nghĩa là chúng ta

có thể nói về kết nối TCP/IP giữa flicka.magelang.com:3452 và

rosa.jguru.com:4432 Trong phiên bản này, kết nối TCP/IP được sử dụng cho tất cả các kết nối máy tới máy

Trong top của TCP/IP, RMI sử dụng mức giao thức dùng dây gọi là Java Remote Method Protocol (JRMP) JRMP là một giao thức dựa trên luồng, và hiện tại có hai phiên bản Phiên bản thứ nhất JDK 1.1 yêu cầu phải sử dụng các lớp Skeleton trên server Phiên bản thứ hai Java 2 SDK được tối ưu cho sự thi hành và không yêu cầu các lớp skeleton

Hình 2.7 : Kết nối giữa các máy ảo

Tầng giao vận RMI được thiết kế để tạo kết nối giữa client và server Thường thì tầng giao vận được sử dụng cho các kết nối đa TCP/IP, nhưng có một số cấu hình mạng chỉ cho phép kết đơn TCP/IP giữa một client và server

Trong biểu đồ trên, máy ảo đa thành phần kết nối trong một TCP/IP đơn

Chương 3 Thuật toán phân tán

3.1 Tổng quan về các thuật toán phân tán

Thuật toán phân tán là một phạm vi rộng lớn các thuật toán song song, được phân loại bởi rất nhiều cách khác nhau dựa trên các tính chất khác nhau: [4][5]

- Phương thức truyền thông liên quá trình (IPC): bộ nhớ dùng chung, truyền thông điệp, luồng dữ liệu

- Mô hình định giờ: đồng bộ, không đồng bộ, đồng bộ một phần

- Failure Model: hệ thống tin cậy, faulty linhks, các bộ xử lý lỗi

- Các vấn đề định địa chỉ: định vị tài nguyên, truyền thông, thoả thuận (agreement), kiểm soát trùng hợp cơ sở dữ liệu (database concurrency control), phát hiện tắc nghẽn,

3.2 Thuật toán trong mạng đồng bộ

Trong mô hình đồng bộ, các thành phần thực hiện các bước một cách đồng thời và

sự thi hành được thực hiện trong các vòng đồng bộ [4]

Mô hình tính toán của các thuận toán đồng bộ được định nghĩa như sau:

Cho một tập các nút tạo thành đồ thị G=(V,E) Đặt n=|V|, M là tập các thông điệp, giá trị null thể hiện sự vắng mặt của thông điệp

Mỗi nút i  V sẽ có

states(i): tập các trạng thái

start(i): tập con của states(i)

msgs(i): ánh xạ states(i) × out-nbrs(i) tới các phần tử của tập M hoặc null

trans(i): ánh xạ states(i) và một vectơ thông điệp thuộc M U {null}

Ban đầu các nút ở trong trạng thái start và tất cả các kênh đều rỗng Sau đó, trong

các bước tiếp theo, các nút thực hiện lặp lại thủ tục sau gọi là round(vòng)

Dùng hàm sinh thông điệp msgs để tạo ra các thông điệp cho các láng giềng

Đặt chúng vào các kênh

Áp dụng hàm chuyển tiếp trans cho các thông điệp đến và trạng thái hiện tại để

chuyển sang trạng thái mới

Chú ý: các đầu vào đã được mã hoá trong các trạng thái start Mô hình thể hiện ở

đây là xác định, các hàm chuyển tiếp và hàm sinh thông điệp chỉ nhận đơn giá trị

Các vấn đề cần giải quyết trong mô hình này gồm có:

Đối với mạng vòng, vấn đề đặt ra là cần tìm một Leader duy nhất trong mạng gồm các bộ xử lý, mỗi bộ xử lý được định danh duy nhất bởi Unique Identifier (UID) Các thuật toán gồm có Lelann – Chang – Roberts Hirshberg-Sinclair và các thuật toán Counterexample

Đối với mạng tổng quát có các vấn đề: tìm Leader, tìm đường đi ngắn nhất, xác định cây khung tối thiểu, tìm tập lớn nhất các nút độc lập…

Ngoài ra còn có các vấn đề liên quan đến xử lý lỗi : stopping - một tiến trình khi đang thực hiện các giao thức cục bộ thì dừng lại; hoặc omission - thông điệp bị mất trên đường đi; hoặc Byzantine - tiến trình lỗi có những hoạt động không thể kiểm soát được

Chúng ta sẽ nghiên cứu một số thuật toán giải quyết vấn đề Leader Election

3.2.1 Leader election trong mạng vòng đồng bộ

Ta có đồ thị của chúng ta là một vòng có n nút và có một hướng duy nhất theo chiều kim đồng hồ Độ lớn của mạng là tuỳ ý, các bộ xử lý cũng là tuỳ ý Bài toán đặt

ra là chọn ra một tiến trình duy nhất có thông điệp leader đi ra khỏi kênh[4]

Một điểm nhận thấy ngay là nếu tất cả các nút đều giống hệt nhau thì bài toán của chúng ta không có lời giải

Định đề 1: Nếu tất cả các nút trong mạng đều giống nhau về tập các trạng thái, tập các trạng thái ban đầu, các hàm sinh thông điệp và các hàm chuyển tiếp thì chúng ta không thể giải quyết được vấn đề leader election đối với n>1

Chứng minh: Bằng phương pháp quy nạp áp dụng cho số vòng quay của mạng, các

bộ xử lý đều có chung một trạng thái sau bất kỳ số vòng quay Do đó, nếu có một bộ

xử lý nào gửi thông điệp leader thì tất cả các bộ xử lý còn lại cũng gửi thông điệp leader tại cùng một thời điểm, và như vậy là vi phạm yêu cầu của bài toán

Theo như định đề 1, để giải quyết được vấn đề leader election thì ta phải phá vỡ đi

sự cân bằng Mỗi nút sẽ được gán cho một định danh duy nhất (UID) đảm bảo sao cho định danh của các nút là khác nhau

Giải quyết bài toán này có một số thuật toán sau

1 Thuật toán Lelann, Chang-Roberts (LCR)

Tư tưởng của thuật toán như sau:

Mỗi tiến trình sẽ gửi ID của mình vòng quanh mạng Khi một nút nhận được một ID đến, nó sẽ so sánh ID đó với ID của mình Nếu ID đến lớn hơn, nó sẽ để ID đó tiếp tục

đi qua Nếu ID đến nhỏ hơn, nó sẽ loại bỏ ID đến Nếu bằng thì tiến trình sẽ thông báo

nó là leader Rõ ràng, tiến trình có ID lớn nhất sẽ đưa ra thông điệp leader[4] Sau đây

là thuật toán

Tập thông điệp M là có các UID cùng với thông điệp leader

Tập trạng thái states(i) sẽ có các thành phần sau:

own, có kiểu của UID, khởi tạo là UID của i

send, có kiểu của UID hoặc null, khởi tạo là UID của i

status, có giá trị trong tập {unknown, chosen, reported}, khởi tạo là unknown

Trạng thái bắt đầu start(i) được khởi tạo như ở trên

Hàm thông điệp msg(i) được định nghĩa như sau Gửi thông điệp m, tức UID, theo chiều kim đồng hồ tớn nút láng giềng nếu m là giá trị của send Nếu status=chosen thì

gửi leader tới nút tiếp theo

Hàm chuyển được định nghĩa theo đoạn giả mã sau

Giả sử thông điệp mới là m

End case

Bây giờ ta sẽ chứng minh tính đúng đắn của thuật toán Đặt imax là chỉ số của tiến trình có UID lớn nhất Ta có hai bổ đề sau:

Bổ đề 1: Nút imax sẽ sinh ra thông điệp leader tại vòng thứ n+1

Chứng minh: Đặt trạng thái own của tiến trình i max là v max : own=v max Chú ý rằng,

theo đoạn mã trên thì giá trị của own không bao giờ thay đổi Theo đoạn mã, ta có thể

thấy rằng sau n vòng

status(imax)=chosen Điều này có thể chứng minh bằng phương pháp quy nạp đối với số lượng các bước tính toán, mà ở đây là số các vòng Ta sẽ chứng minh khẳng định sau

Với mọi r mà 0≤r≤n-1 thì sau r vòng send(i max +r)=v max

Tức là giá trị lớn nhất sẽ xuất hiện tại vòng thứ r kể từ vòng thứ i max