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

ĐẠI HỌC QUỐC
GIA HÀ NỘI
1
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
NGUYỄN THỊ BÍCH NGỌC

NGHIÊN CỨU CÁC THUẬT TỐ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 TỐ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


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 tố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
Giải thích
ngữ
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 tố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 ngun 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 tố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 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


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

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

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ả…


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 tốn giải quyết các vấn đề đó.
Chương 4: Áp dụng thuật tố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ể đố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 đố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ả hố 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: />- 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 ngồ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 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 ngồ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 tố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 tố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 số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 ngun 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
q 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 ngồ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 ngồ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 ngồ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 khn 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 ngồ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.

Hình 1.2: Các kiểu dò vế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ã
Tự động thêm
Tự động đóng
dựa trên khung làm đoạn mã
gói thành phần

việc
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


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
Cho tất cả các
Dò vết hoạt
Dò vết hoạt
dụng

kiểu dò vết
động, dò vết thi động, dò vết thi
hành
hành
Các thành phần
Các thành phần
Các thành phần
Các thành phần
áp dụng được
in-house
in-house
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 ngồ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

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

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.


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.4: Chuỗi tương tác

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

25

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

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


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

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

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


27

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

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 khn 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 khn 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: