1
ĐẠI HỌC QUỐC GIA HÀ NỘI
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 2
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
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
Hội sở chính của ngân hàng
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 8
Hình 3.6: Tại thời điểm t
1
, p
i
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 10
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.
- 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 12
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 đó
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.
- Các phương pháp sinh phần mềm
Các phương pháp này liên quan đến việc sinh phần mềm từ các đặc tả. Các kỹ thuật
này được dùng trong kỹ nghệ pháp triển phần mềm được mô tả ở trên. Các nghiên cứu
về lĩnh vực này được trình bày tại trang Web: -
ilmenau.de/~czarn/generate/engl.html.
- Các kỹ thuật lắp ráp
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,
để các thành phần có thể hoạt động[2].
D‟Souza và Wills: một gói phần mềm bao gồm sự thi hành với đặt tả các giao diện
được đề nghị và yêu cầu[3].
Hầu hết các định nghĩa đều quy tụ về một số độ đo nào đấy nhưng phát sinh khác
nhau trong thực tế vì có nhiều quan niệm khác nhau về thành phần phần mềm. Theo
truyền thống, một thành phần được coi là một đơn vị về mặt thi hành trong triển khai.
Tuy nhiên, quan điểm này lại không đề cập đến các đặc tả trừu tượng hay thậm chí là
các tài liệu thiết kế đi kèm với thành phần. Các thành phần sử dụng lại có thể xuất hiện
tại mức bất kỳ trong chu trình phát triển, cụ thể người ta ngày càng quan tâm nhiều 15
đế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
đá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)
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. 18
- 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.
19
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á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
Mã nguồn
Cần
Cần
Không cần
Cắt mã
Không
Không
Có
Chi phí
Cao
Thấp
Thấp
Hình 1.2: Các kiểu dò vết thành phần 21
Độ phức tạp
Thấp
Rất cao
Cao
Tính linh hoạt
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 22
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
23 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
Hình 1.5: Gói dò vết
Hình 1.4: Chuỗi tương tác 25
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
27
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
Copyright: Tài liệu đại học ©