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

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Ệ

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ã số: 1.01.10
LUẬN VĂN THẠC SĨ

Người hưóng dẫn khoa học:
PGS.TS. Hồ Sĩ Đàm

I. HÀ NỘI - 2006


5
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

6
Tài liệu tham khảo 78



7
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.
HSC

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

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




9
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


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.

Tài liệu tham khảo.


11
Chương 1. Thành phần phần mềm (software
component)
1.1 Kỹ nghệ phần mềm hướng thành phần
1.1.1 Tổng quan kỹ nghệ phần mềm hướng thành phần
Kỹ nghệ phần mềm hướng thành phần(CBSE) có nghĩa là lắp rắp các thành phần
phần mềm có sẵn trước thành một phần mềm lớn hơn[9]. Khái niệm cơ bản của tiến
trình này là các thành phần phần mềm được viết để cung cấp các chức năng chung
nhất cho nhiều hệ thống khác nhau. Dựa trên ý tưởng các thành phần phần cứng, mục
đích của CBSE là cho phép các phần của một hệ thống phần mềm có thể được thay thế
bởi các thành phần mới hơn có chức năng tương tự.
Ý 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.

Tiến trình phát triển[9]
Phát triển phần mềm có hai tiến trình chính:
- Lắp ráp hệ thống phần mềm từ các thành phần phần mềm và
- Phát triển các phần mềm để có thể sử dụng lại được
Các hoạt động lắp ráp các thành phần phần mềm thành một hệ thống phần mềm có
thể chia thành 4 hoạt động sau:
- Đá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


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 đó

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


13
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.
- 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

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


14
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,
để 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

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)


16
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.


17
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.


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.

 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
ra lỗi.
 Không có sự xác nhận tính hợp lệ tài nguyên hệ thống cho các thành phần. Hầu
hết các thành phần đều không cung cấp được thông tin về tài nguyên hệ thống, do
đó người kiểm tra và duy trì hệ thống rất khó định vị tài nguyên hệ thống gây ra
lỗi.
Như vậy là có hai thách thức chính trong việc phát triển phần mềm phân tán hướng
thành phần. Thứ nhất là việc thiết kế các thành phần phần mềm với các kỹ thuật và
giao diện nhất quán để hỗ trợ cho việc theo dõi và giám sát các hành vi, các hàm, sự
thi hành và các tài nguyên của thành phần. Thách thức thứ hai là việc phát triển một
phương thức và môi trường có tính hệ thống để giám sát và phân tích các hành vi của
các thành phần và sự thi hành hệ thống trong môi trường phân tán.
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

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ủ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


20
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
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

Cao
Thấp
Thấp
Khả năng ứng
dụng
Cho tất cả các
kiểu dò vết
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


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

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.

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

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


24
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


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

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


26
đ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

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