Baocao

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

MỤC LỤC Chương mở đầu: GIỚI THIỆU ĐỀ TÀI....................................................................................3 Đặt vấn đề............................................................................................................................. ................3 Yêu cầu của đề tài...................................................................................................... ..........................3 Giải quyết vấn đề............................................................................................................................... ...3

Chương 1: TỔNG QUAN VỀ MOBILE AGENT......................................................................6 TÓM TẮT.................................................................................................................................... .........6 1.1. Sự cần thiết của mô hình Mobile Agent.......................................................................... .............6 1.2. Sự tiến hóa từ các mô hình ứng dụng phân tán........................................................................... 8 1.3. Kiến trúc hệ thống Mobile Agent............................................................................. ....................9 1.4. Các đặc tính của Mobile Agent....................................................................................... ............11 1.5. Ứng dụng của Mobile Agent...................................................................................... .................12 1.5.1. Các lợi thế của Mobile Agent...................................................................................................................12 1.5.2. Các ứng dụng của Mobile Agent..............................................................................................................14

1.6. Các hệ thống Mobile Agent hiện hành........................................................................ ...............16 1.6.1. Aglets........................................................................................................................................................16 1.6.2. Voyager.....................................................................................................................................................17 1.6.3. Mole.........................................................................................................................................................19 1.6.4. ZEUS........................................................................................................................................................20 1.6.5. So sánh các hệ thống Aglet, Mole, Voyager và Zeus...............................................................................21

1.7. Vấn đề khó khăn và thách thức......................................................................................... .........22 KẾT LUẬN.............................................................................................................................. ...........24

Chương 2: BẢO MẬT TRÊN MOBILE AGENT (MOBILE AGENT SECURITY)...........25 TÓM TẮT................................................................................................................................. ..........25 2.1. Đe dọa sự an toàn bảo mật (Security Threats)........................................................ ..................25 2.1.1. Sự tấn công từ một Agent đến Agent Platform (Agent-to-Platform).......................................................26 2.1.2. Sự tấn công từ một Agent đến một Agent khác trong cùng một Platform (Agent to Agent)...................28 2.1.3. Sự tấn công từ Platform đối với Agent (Platform-to-Agent)...................................................................29 2.1.4. Những thực thể khác tấn công vào hệ thống Agent Platform (Other-to-Agent Platform).......................31

2.2. Những yêu cầu về an toàn bảo mật (Security Requirements)............................... ...................32 2.3. Biện pháp đối phó (Countermeasures)........................................................... ...........................35 2.3.1. Việc bảo vệ Agent Platform (Protecting the Agent Platform)..................................................................35 2.3.2. Việc bảo vệ các Agent (Protecting Agents)..............................................................................................39

KẾT LUẬN.............................................................................................................................. ...........42

Chương 3: CÁC MẪU THIẾT KẾ CỦA AGENT (AGENT DESIGN PATTERNS)...........43 TÓM TẮT................................................................................................................................. ..........43

Trang 1

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

3.1. Mẫu thiết kế đặc trưng cho sự di chuyển.................................................................................. .43 3.2. Mẫu thiết kế đặc trưng cho sự phân công các tác vụ..................................................... ...........44 3.3. Các mẫu thiết kế đặc trưng cho sự tương tác...................................................................... ......45 3.4. Một số mẫu thiết kế đặc trưng................................................................................................... .46 3.4.1. Mẫu thiết kế Master-Slave.......................................................................................................................46 3.4.2. Mẫu thiết kế Itinerary...............................................................................................................................51

KẾT LUẬN.............................................................................................................................. ...........57

Chương 4: KIẾN TRÚC AGLET CỦA IBM...........................................................................58 4.1. Mô hình của Aglet............................................................................................ ...........................58 4.1.1. Các yếu tố cơ sở (Basic Elements)...........................................................................................................58 4.1.2. Các sự kiện lắng nghe trong Aglet...........................................................................................................60

4.2. Aglet API (Aglet - Application Programming Interface)......................................... .................61 4.3. Giới thiệu về ATP (Agent Transfer Protocol)............................................................................. 67 KẾT LUẬN.............................................................................................................................. ...........71

Chương 5: XÂY DỰNG ỨNG DỤNG ĐỊNH THỜI GIAN BIỂU CHO CUỘC HỌP........72 TÓM TẮT................................................................................................................................. ..........72 5.1. Giới thiệu........................................................................................................... ..........................72 5.2. Các chức năng chính................................................................................................. ..................73 5.2.1. Chức năng lập lịch tại máy cục bộ...........................................................................................................73 5.2.2. Chức năng quản lý danh sách người dùng trong mạng............................................................................73 5.2.3. Chức năng lập lịch phân tán.....................................................................................................................73

5.3. Kết quả minh họa ứng dụng...................................................................................... .................77 KẾT LUẬN.............................................................................................................................. ...........80

Chương 6: CẤU HÌNH HOÀN CHỈNH ỨNG DỤNG............................................................81 6.1. Cài đặt Aglet-2.0.2 (Server Tahiti)......................................................................................... .....81 6.2. Hoàn chỉnh ứng dụng......................................................................................................... .........82

Chương 7: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN..............................................................84 7.1. Kết luận............................................................................................................................... .........84 7.2. Hướng phát triển............................................................................................................. ............84

TÀI LIỆU THAM KHẢO..........................................................................................................86 PHỤ LỤC....................................................................................................................................87

Trang 2

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Chương mở đầu: GIỚI THIỆU ĐỀ TÀI Đặt vấn đề Trong mô hình Client-Server, một giao dịch hoặc truy vấn giữa Client và Server sẽ yêu cầu nhiều vòng chu trình để hoàn tất. Mỗi chu trình sẽ tạo ra nhiều lưu thông trên mạng và làm tốn băng thông. Trong một hệ thống có nhiều Client hoặc nhiều giao dịch, tổng băng thông yêu cầu có thể sẽ vượt quá băng thông hiện có, điều đó sẽ làm giảm hiệu suất của ứng dụng. Mà đối với các ứng dụng phân tán, băng thông của mạng rất quan trọng và là một tài nguyên vô giá. Mô hình Mobile Agent ra đời dùng để giải quyết vấn đề này. Nó sẽ quản lý các truy vấn hay giao dịch bằng cách gửi các Agent từ Client đến Server, sau đó Client có thể ngắt nối kết và các Agent sẽ bảo vệ kết quả trả về cho Client khi các nối kết được thiết lập trở lại. Kiến trúc của Mobile Agent sẽ làm giảm sự tiêu tốn băng thông.

Yêu cầu của đề tài  Yêu cầu về lý thuyết: - Tìm hiểu các mô hình của ứng dụng phân tán. - Tìm hiểu sâu về mô hình tính toán phân tán Mobile Agents. - Khai thác chuẩn Java Aglet của IBM.  Yêu cầu về chương trình: - Xây dựng một ứng dụng phân tán minh họa theo mô hình Mobile Agents như: truy xuất nhiều CSDL, định thời biểu cuộc họp phân tán - Ngôn ngữ lập trình: Java.

Giải quyết vấn đề Dựa trên những yêu cầu đề tài trên nhóm nghiên cứu chúng tôi đã tiến hành triển khai nghiên cứu về lý thuyết cũng như viết chương trình và đã đạt được một số kết quả. Trang 3

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Trong luận văn này chúng tôi sẽ trình bày lại toàn bộ kết quả nghiên cứu mà chúng tôi đã triển khai. Do những tài liệu tham khảo hoàn toàn bằng tiếng Anh nên có một số thuật ngữ chuyên ngành không thể dịch sang tiếng Việt được, chúng tôi đã cố gắng chú thích kèm theo. Luận văn bao gồm 5 chương. Chương 1. Giới thiệu tổng quan về Mobile Agent  Sự cần thiết của mô hình Mobile Agent  Sự tiến hóa của các mô hình phân tán  Kíến trúc của hệ thống Mobile Agent

 Đặc tính của Mobile Agent  Các loại ứng dụng trên Mobile Agent  Các hệ thống hỗ trợ Mobile Agent  Vấn đề khó khăn và thách thức của Mobile Agent Chương 2. Bảo mật trên Mobile Agent  Vấn đề đe dọa đối với sự an toàn bảo mật trên Mobile Agent

 Nhu cầu bảo mật trên Mobile Agent  Các phương pháp giải quyết vấn đề bảo mật Chương 3. Các mẫu thiết kế của Agent  Mẫu thiết kế đặc trưng cho sự di chuyển  Mẫu thiế kế đặc trưng cho sư phân công tác vụ  Mẫu thiết kế đặc trưng cho sự tương tác  Một số mẫu thiết kế đặc trưng (Master – Slave và Itinerary) Chương 4. Kíến trúc Aglet của IBM  Mô hình của Aglet  Giới thiệu Aglet API (Aglet - Application Programming Interface) Trang 4

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

 Giới thiệu về giao thức ATP (Agent Transfer Protocol) Chương 5. Xây dựng ứng dụng định thời gian biểu cho cuộc họp  Giới thiệu mô tả ứng dụng  Giới thiệu về các chức năng chính  Kết quả minh họa ứng dụng Chương 6. Cấu hình hoàn chỉnh ứng dụng  Cài đặt Aglet-2.0.2 (Server Tahiti)  Cấu hình hoàn chỉnh ứng dụng Chương 7. Kết luận và hướng phát triển

Trang 5

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Chương 1: TỔNG QUAN VỀ MOBILE AGENT TÓM TẮT Mobile Agent là một trong những hướng nghiên cứu thu hút nhiều sự quan tâm nhất từ những năm 90 đến nay với những đặc điểm rất thích hợp cho việc phát triển các ứng dụng phân tán. Trong chương này, chúng tôi điểm lại những khái niệm cơ bản về Mobile Agent đồng thời đề cập đến những loại ứng dụng phù hợp với mô hình Mobile Agent đã và đang được nghiên cứu và phát triển trên thế giới. Thông qua việc xem xét các hệ thống hỗ trợ phát triển ứng dụng dựa trên Mobile Agent, chương này cũng bàn tới đến những khó khăn và thách thức cần phải giải quyết để có thể đưa Mobile Agent vào ứng dụng trong thực tế.

1.1. Sự cần thiết của mô hình Mobile Agent Sự phát triển không ngừng của các kỹ thuật tiên tiến về máy tính, đặc biệt là các giải pháp mạng, cùng với sự bùng nổ nhanh chóng các dịch vụ và nguồn thông tin trên mạng đã làm gia tăng số người sử dụng Internet đến con số hàng trăm triệu (theo International Data Corp, tính đến cuối năm 2002 sẽ có hơn 600 triệu người trên toàn thế giới kết nối Internet). Các đặc điểm của nguồn thông tin, tổ chức mạng, cũng như việc khai thác, xử lý thông tin ngày càng trở nên phức tạp và đa dạng hơn, có thể kể đến các khuynh hướng chính yếu: - Các thiết bị di động (Mobile devices): Việc cung cấp các phần mềm, các dịch vụ hỗ trợ hiệu quả cho các thiết bị di động (Laptop, PDAs đến điện thoại di động hay sổ tay điện tử...) này vẫn đang phải đối mặt với nhiều khó khăn vì các thiết bị di động thường có tài nguyên hạn hẹp, và thường dựa trên các kết nối với băng thông thấp, độ trễ cao của đường điện thoại, hay mạng không dây.

Trang 6

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

- Người dùng di động (Mobile users): Ngày nay người dùng thường có nhu cầu truy cập vào máy tính của mình, tài khoản của mình từ bất cứ đâu, vì thế việc hỗ trợ kết nối ở mọi nơi, mọi lúc và trên mọi thiết bị là một thách thức được đặt ra. - Nhu cầu chuyên biệt hoá: Việc khai thác thông tin, sử dụng dịch vụ đã không còn thỏa mãn với các cơ chế thụ động, mà người dùng thường có khuynh hướng muốn chuyên biệt hoá nhu cầu của mình một cách chủ động. Internet là cơ sở để thực hiện mong muốn này, vấn đề còn lại là khả năng hỗ trợ chuyên biệt hoá của các ứng dụng mạng dành cho người dùng. - Nguồn tin đa dạng, khối lượng cực lớn: Đã xuất hiện sự bùng nổ thông tin trên mạng với sự xuất hiện của nhiều kho dữ liệu khổng lồ. Các kho dữ liệu này lại được cung cấp từ nhiều nguồn nên thường không đồng nhất về tổ chức, đây sẽ lại là một khó khăn mới đối với người dùng khi truy vấn. - Gia tăng sử dụng mạng cục bộ: Việc các mạng Intranet được xây dựng phổ biến là một điều kiện tốt để triển khai các kỹ thuật mới trong việc xây dựng các ứng dụng mạng, vì Intranet cho phép việc thiết lập an toàn hệ thống dễ dàng hơn trong một tập hợp mang tính cộng tác và tin cậy. - Môi trường không đồng nhất: Khi kết nối các máy tính, các mạng cục bộ vào Internet, các ứng dụng và người dùng phải đối mặt với một môi trường không đồng nhất cả về phần cứng, lẫn về kiến trúc hệ điều hành…Và bài toán tương thích, dễ mang chuyển sẽ là vấn đề cần giải quyết ở đây. - Sự khập khiễng về đường truyền: Mặc dù ngành viễn thông đã đạt đến những tiến bộ đáng kinh ngạc, và cho ra đời các loại cáp quang với tốc độ truyền tải nhanh đáng kể, đa số người dùng vẫn bị giới hạn với các thiết bị kết nối như modem hay các đường truyền băng thông thấp với mạng không dây. Với tất cả các đặc điểm trên đây, các ứng dụng phân tán phát triển theo mô hình Client-Server truyền thống tỏ ra một số bất lợi vì đòi hỏi làm việc đồng bộ, đòi hỏi đường truyền băng thông cao, độ trễ thấp và cuối cùng là các dịch vụ thiếu linh động, khó thay đổi hay bổ sung. Mobile Agent là một mô hình trong đó các tiến trình, được Trang 7

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

gọi là Agent, có tính tự trị và khả năng di động từ máy chủ này sang máy chủ khác để hoàn tất tác vụ. Ý tưởng chủ đạo của Mobile Agent là di chuyển xử lý đến gần nguồn dữ liệu, nhờ đó có thể giảm tải mạng, khắc phục tình trạng trễ, hỗ trợ xử lý không đồng bộ và tạo ra sự tương thích mạnh trên các môi trường không đồng nhất. Mobile Agent với các ưu điểm này hứa hẹn một giải pháp mới, hiệu quả và dễ dàng hơn trong việc phát triển ứng dụng phân tán.

1.2. Sự tiến hóa từ các mô hình ứng dụng phân tán Mobile Agent có thể được xem như là sản phẩm kết hợp của kỹ thuật Software Agent và kỹ thuật xử lý phân tán. Mobile Agent khác với mô hình xử lý mạng truyền thống. Theo truyền thống, một ứng dụng phân tán có cấu trúc xây dựng trên mô hình Client-Server sẽ thực hiện việc giao tiếp thông qua cơ chế truyền thông điệp hoặc các lời gọi hàm từ xa (RPCs). Các mô hình giao tiếp này thường phải đồng bộ, nghĩa là phía Client tạm ngưng hoạt động của mình trong thời gian gửi yêu cầu đến Server và đợi đến khi nhận được kết quả trả về từ Server. Một kiến trúc tiến bộ hơn là Remote Evaluation (REV) do Stamos và Gifford đưa ra vào năm 1990. Trong mô hình REV, thay vì yêu cầu thực hiện các hàm từ xa thì Client chỉ việc gởi mã nguồn các hàm của nó đến Server và yêu cầu Server thực hiện rồi trả về kết quả. Một số hệ thống gần đây cũng đã giới thiệu khái niệm thông điệp chủ động (Active Messages) có thể di trú giữa các vị trí trên mạng, mang theo mã của chương trình để thực thi tại những vị trí này. Mobile Agent là mô hình tiến hóa tiên tiến nhất so với các mô hình trước đó. Mobile Agent là danh từ ghép giữa Agent (trợ lý) và Mobile (di động). Một Mobile Agent là một chương trình có khả năng di chuyển một cách tự trị từ nút mạng này sang nút mạng khác và thực hiện các xử lý thay thế cho con người để đạt được mục tiêu được giao phó. Khi di chuyển, các Mobile Agent đóng gói mã nguồn, dữ liệu và cả trạng thái thi hành, nhờ vậy Mobile Agent có thể dừng việc thi hành đang thực hiện tại máy này, di chuyển sang máy khác và khôi phục lại sự thi hành tại máy đích. Hình 1.1 cho thấy sự khác biệt của Mobile Agent so với RPC và REV. Trang 8

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 1.1

1.3. Kiến trúc hệ thống Mobile Agent Mobile Agent khác với các xử lý phân tán, vì các xử lý phân tán không quyết định địa điểm và khi nào thì nó di chuyển còn Mobile Agent có thể di chuyển tới bất kỳ nơi đâu và bất kỳ khi nào. Mobile Agent cũng khác với Java Applet, Applet chỉ có thể di chuyển một chiều từ Server đến Client, trong khi Mobile Agent thì có thể di chuyển giữa Client và Server và có thể tự định hướng. Thậm chí ngay trong kiến trúc của hệ thống Mobile Agent cũng có sự khác biệt, hầu hết tất cả hệ thống Mobile Agent đều chứa một Mobile Agent (MA) và một Mobile Agent Environment (MAE). Như hình 1.2

Trang 9

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 1.2 MAE tạo ra một môi trường thực thi chắc chắn và thích hợp cho MA, sau đó cung cấp cho MA các dịch vụ căn bản bao gồm tạo (creation), vận chuyển (transportation) và thực thi (execution). Nó cũng bao gồm các cơ chế như: chiến lược chịu đựng lỗi, điều khiển bảo mật và các kỹ thuật kết nối. Khả năng giải quyết vấn đề của các MA phụ thuộc vào trên các dịch vụ mà nó được MAE cấp. Một cách tổng quát thì MAE có các dịch vụ cơ bản sau: - Business service: các dịch vụ tạo, di chuyển, khả năng chịu đựng và thực thi trên môi trường phân tán. - Event service: cung cấp các giao thức truyền, kết nối và hỗ trợ các tương tác giữa các Agent. - Directory service: duy trì các thông tin về trạng thái về sự cục bộ của một Mobile Agent, và một thông điệp định tuyến dùng để phân phát các thông định tới Mobile Agent.

Trang 10

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

- Security service: cung cấp môi trường thực thi an toàn. - Application sevice: cung cấp các dịch vụ giao tiếp cho các tác vụ. Thông thường, một MAE chỉ có trên một máy tính trên mạng, nhưng nếu các máy tính được kết nối bằng đường truyền có tốc độ cao, một MAE có thể phân tán trên một mạng theo cách không đồng nhất của các máy tính mà không ảnh hưởng đến năng suất làm việc của toàn hệ thống. Agent Transfer Protocol (ATP) thì hoạt động trong MAE cho việc vận chuyển các MA qua các máy tính, và cung cấp một môi trường thực thi và các dịch vụ giao tiếp. Agent Communication Language (ACL) được khai thác bằng MA trong MAE để kết nối với các dịch vụ khác nhau được cung cấp bởi MAE. Trong một hệ thống kiến trúc của Mobile Agent, MA có thể được phân chia thêm nữa là User Agent (UA) và Service Agent (SA). UA có thể di chuyển từ một MAE đến MAE khác, thực thi trong MAE và kết nối với những MA khác hay các dịch vụ được cung cấp bởi MAE xuyên suốt trong ACL. Chức năng chính của UA là hoàn tất nhiệm vụ được giao bởi người dùng, và còn đóng vai trò di chuyển, điều khiển bảo mật và liên lạc với bên ngoài. SA không có tính di động, chức năng chính của nó là cung cấp những dịch vụ cho các MA cục bộ và các MA di chuyển đến. Thông thường có nhiều SA trong một MAE, và chúng cung cấp các dịch vụ khác nhau. Vì vậy SA không có tính di động và chỉ được khởi động (start up) và quản lý (manage) bởi admin của MAE nơi nó cư trú, điều này làm cho SA không nguy hiểm. UA không thể truy cập trực tiếp vào tài nguyên hệ thống, nó chỉ có thể truy cập vào tài nguyên được điều khiển thông qua các Interface được cung cấp bởi SA. Theo cách đó sự tấn công từ các Agent nguy hiểm có thể được tránh. Đây là cũng là một chính sách bảo mật mà hầu hết các hệ thống Mobile Agent chấp nhận.

1.4. Các đặc tính của Mobile Agent Các đặc tính của Mobile Agent bao gồm: Tính tự trị (autonomous): là khả năng tự kiểm soát bản thân của Agent sau khi được giao việc mà không cần sự can thiệp nào của người dùng hoặc của Agent khác. Có Trang 11

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

nhiều hướng đánh giá về sự tự trị của Agent. Hai đặc tính hướng đích (goal-oriented) và tính chủ động (pro-activeness) thường được dùng để đánh giá mức độ tự trị của Agent. Khả năng tự trị của Agent chủ yếu được quyết định bởi tri thức trang bị cho Agent. Tính di động (mobility): là khả năng di chuyển từ môi trường thi hành này sang môi trường khác khác của một Agent. Khả năng di động của một Agent được phân thành hai loại. Di động mạnh (strong mobility) là khả năng mà hệ thống có thể di chuyển cả mã chương trình và trạng thái thi hành của Agent đến một môi trường khác. Di động yếu (weak mobility) là khả năng của hệ thống chỉ có thể di chuyển mã chương trình giữa các môi trường thi hành với nhau, mã nguồn có thể mang kèm theo một số dữ liệu khởi tạo nhưng trạng thái thi hành thì không thể di chuyển. Tính thích ứng (reactiveness): là khả năng của Agent có thể thực thi trên những môi trường lạ, và cảm nhận được sự thay đổi của môi trường. Khả năng cộng tác (collaboration): là khả năng liên lạc, phối hợp hoạt động của các Agent với các Agent của cùng môi trường khác hay với các loại đối tượng khác trong những môi trường khác.

1.5. Ứng dụng của Mobile Agent 1.5.1. Các lợi thế của Mobile Agent Có bảy lợi ích chính đối với việc ứng dụng Mobile Agent: 1.5.1.1. Mobile Agent làm giảm tải mạng Kỹ thuật Mobile Agent cho phép người dùng đóng gói cuộc trao đổi, gởi nó đến đích và thực hiện xử lý, trao đổi dữ liệu cục bộ tại đó. Như thế sẽ góp phần làm giảm những dòng dữ liệu thô trên mạng, và như thế tải mạng sẽ giảm đáng kể. Phương châm thực hiện của kỹ thuật Mobile Agent là mang xử lý đến nơi chứa dữ liệu hơn là mang dữ liệu về chỗ xử lý. 1.5.1.2. Mobile Agent khắc phục tình trạng trễ

Trang 12

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Việc điều khiển các hệ thống với quy mô lớn thông qua mạng sẽ phải chấp nhận một sự trễ hạn nhất định. Nhưng điều đó không được phép xảy ra trong các hệ thống điều khiển thời gian thực như robot, quy trình sản xuất… Khi đó, giải pháp Mobile Agent tỏ ra có hiệu quả trong việc khắc phục độ trễ nhờ vào việc các Agent có thể được gửi đi từ một trung tâm điều khiển và hành động cục bộ, tự trị, trực tiếp thi hành các chỉ dẫn của người điều khiển. 1.5.1.3. Mobile Agent gói gọn các giao thức Khi dữ liệu được trao đổi trong hệ thống phân tán, việc truyền và nhận dữ liệu phải được mã hóa bởi các giao thức cần thiết. Các giao thức này được sở hửu bởi mỗi máy trong hệ thống. Tuy nhiên, một khi các giao thức phải tiến hóa cho phù hợp với những yêu cầu mới về sự bảo mật hoặc tính hiệu quả, chúng bắt đầu trở nên cồng kềnh, nặng nề và trở thành vấn đề nan giải. Riêng với giải pháp Mobile Agent, các Agent có thể mang trên mình các giao thức thích hợp và di chuyển tới các máy ở xa để thiết lập các kênh truyền nhận thông tin tương ứng. 1.5.1.4. Mobile Agent có thể thi hành tự trị và không đồng bộ Thông thường, các thiết bị di động thường phụ thuộc và các kết nối mạng đắt tiền nhưng rất yếu ớt. Vì thế, những tác vụ cần có liên tục giữa thiết bị di động và mạng cố định có thể sẽ không có tính kinh tế hoặc không khả thi về mặt kỹ thuật. Giải pháp Mobile Agent giải quyết vấn đề này bằng cách nhúng tác vụ cần thực hiện vào Agent, rồi gửi lên mạng. Sau khi được gửi đi, Agent trở nên độc lập thi hành không đồng bộ và có khả năng tự trị. Các thiết bị di động sau đó có thể kết nối trở lại để nhận Agent về. 1.5.1.5. Mobile Agent có khả năng thích ứng nhanh Các Agent có khả năng cảm nhận nhanh những thay đổi của môi trường thi hành và tác động trở lại những thay đổi ấy một cách tự động. 1.5.1.6. Mobile Agent khắc phục tình trang không đồng nhất Việc xử lý tính toán trên mạng cơ bản là không đồng nhất vì sự đa dạng về phần cứng và phần mềm được sử dụng. Do Mobile Agent độc lập với máy tính (phần cứng và

Trang 13

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

hệ điều hành) và tầng vận chuyển, chỉ phụ thuộc vào tầng thi hành, nên chúng cung cấp một điều kiện tối ưu cho việc liên kết các hệ thống không liên quan gì lại với nhau. 1.5.1.7. Mobile Agent mạnh mẽ và khả năng chế ngự lỗi cao Với khả năng phản ứng năng động, với những sự kiện và những thay đổi bất lợi, Mobile Agent giúp cho việc xây dựng hệ thống mạnh mẽ và chịu lỗi cao được dễ dàng hơn. 1.5.2. Các ứng dụng của Mobile Agent 1.5.2.1. Thu thập dữ liệu từ nhiều nơi Tìm dữ liệu từ cơ sở dữ liệu phân tán là một ứng dụng phổ biến của Mobile Agent. Thay vì di chuyển một lượng dữ liệu đến bộ xử lý tìm kiếm (search engine) để tạo chỉ mục tìm kiếm, ta sẽ gửi các Agent đến nguồn chứa thông tin từ xa, nơi mà chỉ mục tìm kiếm sẽ được tạo. Một trong những khác biệt giữa Mobile code – như là Applets – và Mobile Agent là lộ trình. Trong khi Mobile code luôn di chuyển từ điểm A đến điểm B thì Mobile Agent có một lộ trình và có thể lần lượt di chuyển qua nhiều site. Do đó một ứng dụng rõ ràng của Mobile Agent là thu thập thông tin trên mạng. 1.5.2.2. Tìm kiếm và lọc dữ liệu Lượng thông tin trên Internet ngày càng nhiều, do đó việc tìm kiếm thông tin cần thiết trên mạng sẽ tốn nhiều thời gian. Vì vậy, việc lọc bớt một số thông tin không thích hợp là một vấn đề quan trọng. 1.5.2.3. Kiểm tra dữ liệu Một số thông tin không trải ra theo không gian mà theo thời gian. Các thông tin mới không ngớt được đưa ra và công bố trên mạng. Các Agent gửi đi có thể đợi cho tới khi lấy được thông tin chắc chắn. Chẳng hạn một Agent có thể tới một thị trường chứng khoán đợi cho tới khi thị trường chứng khoán đạt tới một giá chắc chắn, sau đó đặt mua nhân danh người dùng của nó. Trang 14

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Loại ứng dụng này nêu bật bản chất không đồng bộ của Mobile Agent. Nếu bạn gửi đi một Agent, bạn không cần ngồi đợi kết quả. Bạn có thể lập trình cho Agent để nó đợi lấy được thông tin chắc chắn. Ngoài ra bạn cũng không cần kết nối vào mạng cho tới khi Agent gửi kết quả. Một Agent có thể đợi cho đến khi nào bạn kết nối lại. 1.5.2.4. Đàm phán Bên cạnh việc tìm kiếm cơ sở dữ liệu và file, các Agent còn thu thập thông tin bằng cách tương tác với các Agent khác. Ví dụ bạn muốn lập một kế hoạch gặp gỡ một số người, bạn gửi một Agent tương tác với các Agent đại diện những người mà bạn muốn gặp. Các Agent có thể đàm phán và sắp xếp lịch. 1.5.2.5. Đặt hàng Thương mại điện tử là môi trường tốt để áp dụng công nghệ Mobile Agent. Một Mobile Agent có thể thay bạn đi mua sắm, bao gồm việc đặt hàng, trả tiền. Chẳng hạn như nếu bạn muốn bay từ thung lũng Silicon tới một quần đảo Nam Thái Bình Dương, một Agent có thể tới cơ sở dữ liệu các chuyến bay và tham khảo giá của các hãng hàng không. Nó tìm ra chuyến bay có giá rẻ và thời gian thích hợp, đặt một chỗ cho bạn, thanh toán số credit card của bạn. Thương mại điện tử cũng diễn ra giữa các Agent. Ví dụ có một host dành riêng để mua bán ô tô, nếu bạn muốn mua một chiếc ô tô, bạn có thể đưa cho Agent sở thích của bạn, giá cả và cách thức trả giá. Bạn gửi Agent của bạn tới host, ở đó nó mặc cả với Agent của host để tìm mua chiếc xe cho bạn. 1.5.2.6. Xử lý song song Vì các Mobile Agent có thể tạo ra nhiều bản sao của nó trên mạng, một ứng dụng đầy tiềm năng của Mobile Agent là quản trị các tác vụ song song. Một ứng dụng đòi hỏi quá nhiều tài nguyên bộ xử lý có thể được phân bố cho các Mobile Agent mang đi thực hiện trên nhiều máy tính khác nhau để tận dụng các tài nguyên rảnh rỗi và cân bằng tải. Hệ Mobile Agent không đồng nhất là một minh họa khai thác ưu điểm này của mô hình Mobile Agent. 1.5.2.7. Quản trị hệ thống mạng Trang 15

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Đối với những hệ thống mạng lớn, việc chuẩn đoán lỗi, duy trì sự ổn định của hệ thống là các công việc rất khó khăn. Việc ứng dụng Mobile Agent vào quản trị mạng sẽ giúp cho các công tác chẩn đoán lỗi và duy trì từ xa sự ổn định của hệ thống được dễ dàng hơn. 1.5.2.8. Hỗ trợ các thiết bị di động Do đặc điểm tài nguyên hạn chế và không kết nối thường xuyên, việc xây dựng các ứng dụng dựa trên Mobile Agent với khả năng di chuyển đến các máy tính có cấu hình mạnh hơn để hoạt động (truy vấn cơ sở dữ liệu, tìm tin…) rồi trả kết quả về sẽ là một giải pháp tốt cho người dùng các thiết bị di động. Trong số đề án về loại ứng dụng này có thể kể đến Sony Magics Link PDA (xây dựng trên Telescript), TACOMA, Mobile Agent Middlerware tại Darmouth College, và đề án Docking Laptop tại University of Maryland.

1.6. Các hệ thống Mobile Agent hiện hành Các hệ thống được lựa chọn để khảo sát ở đây bao gồm Aglets và Voyager (sản phẩm thương mại), cùng với Mole và Zeus (kết quả nghiên cứu). Cả bốn môi trường này đều sử dụng Java để hỗ trợ phát triển ứng dụng, nhưng mỗi hệ thống có những đặc thù riêng. 1.6.1. Aglets Aglets được xây dựng và phát triển bởi D. B. Lange và IBM Tokyo Research Laboratory. Hiện nay, bộ Aglets Software Development Kit (ASDK) do IBM phát triển đã dừng lại ở phiên bản 1.1 Beta3 trên nền JDK1.1. Phiên bản mới nhất của ASDK là 2.0.2 do SourceForge phát triển trên nền JDK1.3. Aglets là một hệ thống Java Mobile Agent hỗ trợ các khái niệm thi hành tự trị và định tuyến động trên lộ trình của nó. Có thể xem Aglets như là một khái quát hóa và mở rộng của Applet và Servlet. Aglet Server là chương trình cung cấp một môi trường thi

Trang 16

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

hành và một máy ảo Java cho Aglets hoạt động. Ngoài ra, Aglet Server cũng sử dụng một trình quản lý để tiếp nhận và kiểm soát Aglets một cách an toàn. Aglet API là bộ thư viện bao gồm các hàm chuyên biệt dành cho việc phát triển Agent. Nhờ vào Aglet API, khả năng nổi tiếng của Java là “viết một lần, thi hành bất cứ đâu” được viết lại là “viết một lần, lưu hành bất cứ đâu”. Một khi Aglets được tạo ra, nó sẽ chạy trên mọi máy có hỗ trợ Aglet API mà không quan tâm đến nguồn gốc hệ điều hành và phần cứng bên dưới hay nguồn gốc cụ thể của Aglet API được cài trên máy đang chạy. Trong mô hình đối tượng Aglets, một Mobile Agent là một đối tượng di động có luồng kiểm soát riêng của nó, làm việc theo sự kiện và liên lạc với các Agent khác bằng cách truyền thông điệp. Aglets có một cơ chế định danh duy nhất và toàn cục dựa trên URL. Aglet hỗ trợ cơ chế di động yếu (weak mobility). Các Aglets giao tiếp với nhau một cách đồng nhất, và độc lập với vị trí lưu trú thông qua đối tượng Proxy. Suốt chu kỳ sống, các Aglets sẵn sàng bắt những sự kiện (clone, mobility, persistence) phát sinh trong môi trường để có phản ứng thích hợp. Agent có thể giao tiếp đồng bộ hoặc không đồng bộ thông qua các loại thông điệp: synchronous, one-way, hay future reply. Aglets sử dụng ATP (Agent Transfer Protocol) cho việc di chuyển và giao tiếp. Aglets sử dụng hai loại mẫu thiết kế chính là chủ-tớ (Master-Slave) và hành trình (Itinerary) cho việc di chuyển của các Agent. 1.6.2. Voyager Voyager là một môi trường thương mại hỗ trợ phát triển các ứng dụng Agent được hãng Object Space phát triển từ giữa năm 1996. Voyager đã trải qua nhiều lần nâng cấp và thay đổi từ phiên bản 1.0 cho đến bây giờ là phiên bản 4.5. Tháng 03-2002 sản phẩm Voyager được nhượng lại cho Recursion Software, một công ty chuyên về các sản phẩm viết trên C++ và Java để đảm bảo cho việc phát triển Voyager sau này. Các phiên bản từ 1.0 đến 3.3 Voyager được phân phối cho các nhà phát triển như một freeware. Hiện tại Voyager đã có phiên bản 4.5 Evaluation hoàn toàn tương thích với JDK1.3, JDK1.2 và Trang 17

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

JDK1.1. Phiên bản này bao gồm 6 sản phẩm, trong đó sản phẩm chính yếu dùng cho các ứng dụng Mobile Agent là Voyager ORB Professional. Voyager sử dụng ngôn ngữ lập trình Java với cú pháp chuẩn để tạo dựng các đối tượng ở xa một cách rất dễ dàng, cho phép các đối tượng này trao đổi thông điệp với nhau, và di chuyển các đối tượng giữa các máy tính có hỗ trợ môi trường Voyager. Voyager hỗ trợ mạnh về tính di động với khả năng mang toàn bộ mã chương trình và dữ liệu di chuyển từ máy ảo Java này sang máy ảo Java khác nếu các máy ảo có hỗ trợ Voyager. Trạng thái hoạt động của Agent cũng sẽ được bảo toàn và tiếp tục thực thi tại nơi Agent đến. Một trong những đặc điểm nổi trội khác của Voyager là tính phổ quát. Các chương trình viết trong Voyager có thể trao đổi thông tin hai chiều với các chương trình viết bằng SOAP, CORBA, RMI và DCOM. Các dạng thông tin được trao đổi có thể là các lời gọi hàm từ xa, các dịch vụ đặt tên, dịch vụ thư mục. Voyager có thể được xem là một cửa ngõ, một cầu nối làm cho các chương trình theo chuẩn khác trở nên liên thông với nhau. Hơn nữa, tất cả các chương trình và đối tượng có thể được tổ chức thành một không gian chung, nhờ vậy việc liên lạc sẽ trở thành một–nhiều một cách tự động. Phiên bản 4.5 của Voyager đã được bổ sung thêm các tính năng rất quan trọng hỗ trợ cho các chuẩn dịch vụ Web. SOAP và WSDL cũng đã được phát triển trong phiên bản này giúp cho các nhà phát triển có khả năng triển khai các ứng dụng truy cập tới các dịch vụ Web từ xa và các chương trình Voyager có thể truy cập nhau thông qua các dịch vụ Web. Thế mạnh thật sự của Voyager nằm ở sự đơn giản và dễ dùng. Sự “trong suốt” hay cách mà Voyager che dấu các kỹ thuật lập trình phân tán phức tạp đã làm cho việc xây dựng các ứng dụng Mobile Agent trở nên dễ dàng hơn rất nhiều. Việc tích hợp các công nghệ mới và các chuẩn mới vào cùng một sản phẩm tạo cho Voyager sự hấp dẫn rất riêng biệt.

Trang 18

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

1.6.3. Mole Mole là hệ thống Mobile Agent được xây dựng với ngôn ngữ Java tại đại học Stuttgart (CHLB Đức). Phiên bản đầu tiên (Release 1.0) đã hoàn thành vào năm 1995, năm 1997 phiên bản Release 2.0 được hoàn thành, bản Release 3.0 được hoàn tất vào năm 1998 và đề án đã kết thúc với kết quả là môi trường ổn định để xây dựng ứng dụng theo mô hình Agent trên các hệ phân tán. Được xây dựng trên Java, Mole có khả năng thực thi trên tất cả các môi trường có hỗ trợ JDK1.1.x (Jdk1.1.7 và Jdk1.1.8), sử dụng giao thức TCP/IP trong quá trình giao tiếp. Mole hỗ trợ di chuyển yếu (weak migration). Để thực hiện giao tiếp giữa các Agent Mole sử dụng các cơ chế truyền thông điệp, gọi hàm từ xa RPCs, và cơ chế đặc trưng của Mole là session, badge. Ngôn ngữ giao tiếp giữa các Agent được Mole hỗ trợ là KQML. Việc trao đổi dữ liệu giữa các Agent được thực hiện theo nghi thức TCP/IP. Mole cho phép đa tiểu trình/Agent và quản lí tài nguyên và lập lịch các tiểu trình trong hệ thống thông qua bộ lập lịch trung tâm MCP. Khả năng bảo mật của Mole được đánh giá khá tốt trong các hệ thống Agent. Mole tuân theo mô hình bảo mật sandbox của Java. Agent trong hệ thống Mole được chia làm hai loại: User Agent và System Agent. User Agent là những Agent di động được kích hoạt bởi người dùng và không thể truy cập trực tiếp tài nguyên hệ thống. Ngược lại, System Agent (Service Agent) - được khởi động bởi người quản trị - không có tính di động và được phép truy cập tài nguyên hệ thống . Môi trường Mole phù hợp cho phát triển những ứng dụng trong các lĩnh vực: Truyền thông, ứng dụng thuộc lĩnh vực hệ thống thông tin điện tử. Một số ứng dụng được phát triển trên môi trường Mole: AIDA - Infrastructure for Mobile Agent, ASAP, ATOMAS, FESTIVAL (Mole office, Mole shopping), HAWK. Với hệ thống mã nguồn mở của Mole, ta có thể tiến hành cải tiến, nâng cấp những chức năng hiện có, và bổ sung những chức năng mới như các chức năng về công cụ hỗ

Trang 19

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

trợ lập trình Agent để Mole trở thành hệ thống Agent hiện đại hỗ trợ tốt cho việc phát triển các ứng dụng dựa theo mô hình Agent. 1.6.4. ZEUS Zeus là môi trường do British Telecommunication phát triển để hỗ trợ xây dựng các hệ thống đa Agent. Ngoài các tính năng thông thường trong việc tạo lập và quản lý các Agent, Zeus đặc biệt chú trọng việc hỗ trợ một phương pháp luận và một bộ công cụ mạnh để phát triển ứng dụng đa Agent trên môi trường phân tán. Zeus là môi trường do British Telecommunication phát triển để hỗ trợ xây dựng các hệ thống đa Agent. Ngoài các tính năng thông thường trong việc tạo lập và quản lý các Agent, Zeus đặc biệt chú trọng việc hỗ trợ một phương pháp luận và một bộ công cụ mạnh để phát triển ứng dụng đa Agent trên môi trường phân tán. Zeus định nghĩa một phương pháp luận để phân tích, thiết kế, triển khai hệ thống và còn kèm theo các công cụ cho phép người phát triển có thể bắt lỗi hệ thống cũng như phân tích sự thực hiện của mình. Hai giai đoạn phân tích và thiết kế được miêu tả chi tiết trong nhưng chưa được hỗ trợ bởi các công cụ. Zeus Toolkit hỗ trợ hai giai đoạn cài đặt và bảo trì Zeus Toolkit qua các công cụ Zeus Agent Generator và Zeus Agent Visualiser. Zeus cung cấp nhiều Editor để định nghĩa Agent và các thuộc tính của Agent. Code Generator sẽ tự động phát sinh mã nguồn cho Agent từ những thuộc tính đã đặc tả. Hai đặc tính quan trọng của các Zeus Agent là tính tự trị và cộng tác. Bộ phận Planner trong mỗi Agent sẽ hỗ trợ Agent thể hiện tính tự trị. Khả năng thương lượng và cộng tác giữa các Agent cũng được Zeus tích hợp vào trong Toolkit thông qua một thư viện các giao thức, cùng các chiến lược thương lượng và cộng tác. Do có mã nguồn mở, người dùng có thể thêm vào thư viện này các chiến lược riêng phù hợp với ứng dụng của mình. Các Zeus Agent truyền thông theo Point-to-Point socket TCP/IP với mỗi message là một chuỗi các kí tự mã ASCII. Ngôn ngữ truyền thông Zeus sử dụng là FIPA ACL.

Trang 20

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Nhằm cung cấp khả năng “hiểu” lẫn nhau cho các Agent, Zeus cung cấp các công cụ cho việc định nghĩa các ontology - cơ sở khái niệm chung cho cộng đồng Agent. Các Agent của Zeus được phân tán qua mạng và có thể thực hiện các tác vụ đồng thời. Chính vì thế, việc quản lí các Agent cũng là một vấn đề mà môi trường đặt ra. Visualiser của Zeus cung cấp các công cụ để kiểm tra các quan hệ giao tiếp giữa các Agent, trạng thái tác vụ những Agent đang thực hiện và trạng thái bên trong của Agent. Đồng thời, Zeus Statistic Tool cho phép người dùng so sánh các thống kê khác nhau về cộng đồng Agent, chẳng hạn những loại thông điệp nào Agent đã gửi và tỉ lệ là bao nhiêu, một cách trực quan dưới những dạng đồ thị khác nhau. Cũng nhằm quản lí Agent, Zeus cung cấp những Agent tiện ích như Agent Name Server hoạt động như một Yellow Page, Facilitator như một White Page, Visualiser và Database Proxy. Một hạn chế của Zeus là tuy được liệt kê vào một trong những môi trường Mobile Agent nhưng hiện hướng nghiên cứu về tính di động của Zeus chỉ mới ở bước đầu, chưa được cài đặt. Do đó mà tính bảo mật của Zeus cho các Agent hầu như không có. Điều này có thể sẽ được khắc phục trong các phiên bản sau. Zeus đã và đang được triển khai trong một số ứng dụng như Agent Based Workflow Management, PTA: Personal Travel Assistance, Personal Computer Manufacture, Agent-based Electronic Commerce, Network Management, Home Shopping. 1.6.5. So sánh các hệ thống Aglet, Mole, Voyager và Zeus

Trang 21

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

1.7. Vấn đề khó khăn và thách thức Về mặt lý thuyết, mô hình Mobile Agent có những ưu điểm rất hứa hẹn cho việc phát triển một thế hệ các ứng dụng phân tán mới. Tuy nhiên, những nghiên cứu trong lĩnh vực Mobile Agent đa số tập trung phát triển các hệ thống Agent hỗ trợ khả năng di động và những vấn đề của các môi trường này như tính an toàn, cơ chế tự di chuyển của Agent, cơ chế giao tiếp giữa các Agent…Việc vận dụng mô hình Mobile Agent vào các ứng dụng thực tế gần như vẫn dừng lại ở mức thử nghiệm mà chưa có được những sản phẩm thương mại hoàn chỉnh. Nhìn chung, mô hình Mobile Agent vẫn chưa trở thành một kỹ thuật được chấp nhận rộng rãi trong thực tế. Những nguyên nhân dẫn đến tình trạng triển khai chậm chạp kỹ thuật mới này bao gồm cả về khía cạnh kỹ thuật lẫn xã hội:  Các vấn đề kỹ thuật: Thực hiện cơ chế di động, bảo đảm an toàn, nâng cao tốc độ thi hành, và chuẩn hoá công nghệ là những khó khăn đồng thời là các thách thức chủ yếu của mô hình Mobile Agent: - Thực hiện tính năng di động: Một số hệ thống về nguyên tắc hỗ trợ tính di động của Agent, nhưng trong thực tế hoặc chưa hỗ trợ, hoặc chỉ hỗ trợ tính di động yếu (weakmobility) với những cơ chế chuyển dời Agent chưa được tốt. Để hỗ trợ tính di động Trang 22

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

mạnh (strong-mobility) cũng như cho phép Agent di chuyển thuận tiện hơn, cần có những cơ chế hạ tầng, những phần mềm trung gian (middleware) giúp thực hiện việc chuyển dời mã nguồn tốt. - An toàn hệ thống: Việc chấp nhận các Agent di động từ máy này sang máy khác để thi hành, một mặt tạo ra những thuận lợi như đã trình bày, mặt khác gây ra những vấn đề về tính an toàn của hệ thống. Giải pháp bảo vệ máy chủ khỏi tác động xấu từ Agent du nhập vào, bảo vệ tính riêng tư và toàn vẹn của Agent trong môi trường mới, bảo vệ Agent khỏi tác động của các Agent khác hoạt động trên cùng môi trường… là những câu hỏi cần được trả lời thấu đáo trước khi có thể triển khai thực sự mô hình Mobile Agent, nhất là trên mạng Internet thay vì các mạng Intranet cục bộ. - Nâng cao tốc độ thi hành: Để giải quyết vấn đề dễ mang chuyển và tương thích trên các môi trường không đồng nhất trên con đường di chuyển và thi hành của Agent, hầu hết các hệ thống Agent đều phải sử dụng hình thức thông dịch mã nguồn tại đích đến. Và vì thế tốc độ thi hành của các hệ Agent vẫn còn rất kém. Một hướng tiếp cận nhằm tiết giảm thời gian du nhập và thi hành trên môi trường đích của Agent là sử dụng chiến lược biên dịch đúng thời điểm (just-in-time compilation). - Chuẩn hoá: Đây là một điều kiện quan trọng để đưa mô hình Agent vào ứng dụng thực tế trong đó cho phép các hệ thống Agent của những công ty, tổ chức khác biệt có thể tương tác với nhau. Các cố gắng chuẩn hoá của những tổ chức như OMG, FIPA… vẫn đang được bổ sung hoàn thiện dần. Bên cạnh đó, các chuẩn cho ngôn ngữ giao tiếp giữa các Agent như KQML, KIF… cũng là một hướng nghiên cứu được quan tâm.  Các vấn đề xã hội: Tuy được nhiều công ty lớn như HP, Mitsubishi, ObjecbSpace… cũng như các trường đại học danh tiếng như MIT, Darmouth, Maryland đầu tư nghiên cứu như một trong những hướng trọng điểm, nhưng Mobile Agent lại chưa được đón nhận nồng nhiệt trong các khách hàng thực tế. Một số trở ngại về mặt xã hội chính yếu bao gồm: - Thiếu ứng dụng đặc trưng: Hầu hết những bài tóan phân tán vẫn có thể giải quyết với mô hình Client-Server truyền thống mà không nhất thiết phải sử dụng Mobile Trang 23

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Agent. Trong nhiều trường hợp, Mobile Agent cung cấp một cách tiếp cận hiệu quả hơn cho vấn đề, nhưng cũng có những trường hợp các kỹ thuật truyền thống tỏ ra hữu hiệu hơn. Do sự thiếu vắng một lọai ứng dụng đặc trưng cho Mobile Agent nên mô hình chưa đủ thuyết phục đối với người dùng. - E ngại mất an toàn: Việc chấp nhận cho một Agent ở nơi khác đến khai thác tài nguyên ở máy mình làm cho người dùng cảm thấy các mối đe dọa bị tấn công tăng lên trong khi đó các lợi ích do Agent mang đến lại chưa rõ ràng. Ngoài ra, việc giao dịch thông qua mạng lưới Agent sẽ làm mất tác dụng quảng cáo cho hình ảnh của các công ty vì mất cơ hội tương tác trực tiếp với khách hàng.

KẾT LUẬN Trong chương này chúng tôi đã giới thiệu về mô hình Mobile Agent- một mô hình mới cho phép xây dựng nhiều ứng dụng phân tán hiệu quả hơn những kỹ thuật cũ. Tuy còn những khó khăn trong việc triển khai Mobile Agent vào thực tế, nhưng Mobile Agent có nhiều tiềm năng trong một số loại ứng dụng phù hợp, và nên là một công cụ cần có khi xây dựng các ứng dụng phân tán quy mô lớn. Trong vòng năm năm gần đây đã có một số hướng nghiên cứu rất hứa hẹn được tiến hành trong lĩnh vực Mobile Agent, nhưng kết quả chỉ mới dừng ở mức có thể vận dụng Mobile Agent vào một số ứng dụng với các điều kiện giảm nhẹ về môi trường thi hành. Do đó việc nghiên cứu để giải quyết những vấn đề tồn đọng của mô hình vẫn là những thách thức cần được đầu tư nghiêm túc. Trong chương tiếp theo chúng tôi sẽ đề cập đến vấn đề bảo mật trên Mobile Agent. Một trong những vấn đề quan trọng cần phải giải quyết để có thể đưa mô hình Mobile Agent vào những ứng dụng thực tiễn.

Trang 24

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Chương 2: BẢO MẬT TRÊN MOBILE AGENT (MOBILE AGENT SECURITY) TÓM TẮT Kỹ thuật Mobile Agent cung cấp một mô hình xử lý mới mà có thể tạm ngưng việc thi hành của nó tại một host và di chuyển nó đến một host khác trên mạng. Sự phức tạp của Mobile Agent gia tăng theo thời gian, vì vậy có quá nhiều mối đe dọa liên kết với nhau cùng ảnh hưởng đến vấn đề an toàn bảo mật. Trong chương này sẽ cung cấp khái quát về phạm vi của các mối đe dọa đối phó với những người thiết kế Agent Platform và những người phát triển những ứng dụng dựa trên Agent. Chương này cũng nhận dạng mục tiêu bảo mật chung.

2.1. Đe dọa sự an toàn bảo mật (Security Threats) Khả năng đe dọa đối với sự bảo mật nói chung rơi vào 3 loại chủ yếu: sự phơi bày thông tin (disclosure of information), sự từ chối của dịch vụ (denial of service), sự sửa đổi làm sai lạc thông tin (corruption of information). Có nhiều cách khác nhau để khảo sát những sự đe dọa này chi tiết hơn khi chúng áp dụng đối với hệ thống Agent. Ở đây chúng ta chỉ dùng các thành phần (components) của một hệ thống Agent để phân loại sự đe dọa như là cách để nhận biết nguyên nhân và mục đích của một sự tấn công.

Hình 2.1

Trang 25

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Có nhiều mô hình hiện có cho việc mô tả hệ thống Agent, tuy nhiên đối với vấn đề an toàn bảo mật này ta chỉ dùng một mô hình đơn giản bao gồm chỉ 2 thành phần chính: Agent và Agent Platform. Ở đây, một Agent gồm có mã nguồn (code) và thông tin trạng thái (state information) cần thiết để tiến hành một vài sự tính toán. Tính di động cho phép một Agent có thể di chuyển giữa các Agent Platform. Agent Platform cung cấp môi trường xử lý cho Agent hoạt động. Agent Platform mà ở đó một Agent được hình thành được xem như là Home Platform và thông thường Home Platform được xem như là môi trường tin cậy nhất cho một Agent mà nó tạo ra. Một hoặc nhiều hơn các host có thể bao gồm một Agent Platform và một Agent Platform có thể hổ trợ nhiều môi trường xử lý nơi mà các Agent có thể tác động lẫn nhau. Bốn loại đe dọa được định nghĩa: đe dọa xuất phát từ sự tấn công của một Agent đến một Agent Platform, một Agent Platform tấn công một Agent, một Agent tấn công một Agent khác trong một Agent Platform và những thực thể khác tấn công vào hệ thống Agent. Trong đó loại cuối cùng bao gồm các trường hợp một Agent tấn công một Agent trên một Agent Platform khác và một Agent Platform tấn công vào các Agent Platform khác. Những sự tấn công này tập trung trước hết vào khả năng liên lạc của các Agent Platform để lợi dụng những tiềm năng không được bảo vệ. Loại đe dọa cuối cùng cũng bao gồm nhiều sự tấn công theo tập quán chống lại hệ điều hành bên dưới của Agent Platform. 2.1.1. Sự tấn công từ một Agent đến Agent Platform (Agent-to-Platform) Agent-to-Platform mô tả sự nguy hiểm khi các Agent khai thác vấn đề bảo mật yếu ớt của một Agent nền (Agent Platform) hoặc có một sự tấn công chống lại một Agent Platform. Vấn đề này bao gồm: mạo danh (masquerading), từ chối dịch vụ (denial of service) và truy xuất bất hợp pháp (unauthorized access). 2.1.1.1. Mạo danh (masquerading) Khi một Agent bất hợp pháp yêu cầu một yêu cầu sự nhận dạng (identity) của một Agent khác thì nó được gọi là mạo danh. Agent mạo danh có thể có tính chất của Trang 26

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

một Agent hợp pháp để cố lợi dụng truy xuất vào các dịch vụ (services) và tài nguyên (resources) để sử dụng một cách hợp pháp. Một Agent mạo danh có cũng như các Agent mạo danh khác cố gắng tránh lỗi khi hoạt động và không muốn giữ trách nhiệm. Nói chung một Agent mạo danh thì nguy hiểm thực sự cho các Agent hợp pháp đã được thiết lập trong một sự kết nối giữa các Agent. 2.1.1.2. Từ chối dịch vụ (Denial of service) Mobile Agent có thể mở cuộc tấn công từ chối dịch vụ bằng việc chi phối một số lượng lớn tài nguyên máy tính của Agent Platform. Những cuộc tấn công từ chối dịch vụ có thể được mở một cách cố ý bằng việc thực thi các kịch bản tấn công (attack scripts) để khai thác hệ thống dễ nguy hiểm hay không cố ý thông qua các lỗi của chương trình. Một Agent xấu có thể mang những đoạn mã nguy hiểm mà nó được thiết kế để gây sụp đổ các dịch vụ (services) trên Agent Platform, hoặc lấy những thông tin cho các Agent bất hợp pháp có thể truy xuất. Phụ thuộc vào mức độ truy xuất, Agent có thể tắt hoàn toàn (completely shut down) hay ngắt (terminate) Agent Platform. 2.1.1.3. Truy xuất bất hợp pháp (Unauthorized Access) Cơ cấu điều khiển truy xuất (access control mechanisms) được dùng để ngăn chặn những người dùng hay những tiến trình (process) bất hợp pháp truy xuất vào các dịch vụ (services) hay tài nguyên (resources) mà chúng không có quyền truy xuất. Mỗi Agent khi đến một Agent Platform phải phụ thuộc vào chính sách bảo mật của Agent Platform. Việc áp dụng đúng cơ cấu điều khiển truy xuất là yêu cầu Agent Platform hay Agent trước tiên phải xác nhận (authenticate) sự nhận dạng (identity) của Agent trước khi nó được thực thi trên Agent Platform. Một Agent truy xuất tới Agent Platform và các dịch vụ của nó không có những thuộc tính xác thực có thể gây thiệt hại cho các Agent khác và cho chính Agent Platform đó. Trong một Agent Platform mỗi Agent sẽ đại diện một người dùng và tổ chức khác nhau phải được bảo đảm rằng các Agent đó không truy xuất đến việc đọc và ghi dữ liệu trong khi nó chưa có sự xác nhận chính xác, bao gồm cả việc truy xuất tới các dữ liệu thừa mà chúng có thể lưu trên bộ đệm (cache) hay trong các nơi lưu tạm khác. Trang 27

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

2.1.2. Sự tấn công từ một Agent đến một Agent khác trong cùng một Platform (Agent to Agent) Agent to Agent mô tả sự nguy hiểm khi các Agent khai thác vấn đề bảo mật yếu ớt của các Agent khác và tấn công chống lại các Agent khác. Vấn đề này bao gồm: Mạo danh (masquerading), tấn công từ chối dịch vụ (denial of service), truy xuất bất hợp pháp (unauthorized access), và từ chối quan hệ giao tiếp (repudiation). 2.1.2.1. Mạo danh (Masquerading) Sự liên lạc giữa Agent với Agent có thể diễn ra trực tiếp giữa hai Agent hay có thể yêu cầu sự tham gia của Agent Platform và các dịch vụ Agent (Services Agent) trên Agent Platform đó cung cấp. Trong cả hai trường hợp trên, một Agent có thể mạo danh ID của nó để đánh lừa Agent kia trong khi chúng đang liên lạc với nhau. Một Agent thì cố tìm cách để Agent kia tin tưởng để nó có thể đưa ra các thông tin cá nhân (private). Sự mạo danh một Agent khác có thể gây nguy hiểm cho cả hai Agent. 2.1.2.2. Từ chối dịch vụ (Denial of Service) Agent có thể tấn công từ chối dịch vụ chống lại Agent khác. Ví dụ, một Agent liên tục gửi các tin nhắn (message) tới Agent khác hoặc gửi các spam Agent cùng với tin nhắn đến Agent khác, đến một lúc nào đó thì Agent nhận trở nên quá tải. Khi Agent đang bị gửi các spam thì nó có thể chọn các tin nhắn từ các Agent bất hợp pháp, khi đó các tác vụ yêu cầu một số xử lý bởi Agent hoặc liên lạc qua proxy của Agent. Nếu một Agent bị tấn công vào số chu kỳ của CPU thì nó lãng phí Agent Platform. Các Agent nguy hiểm cũng có thể cố ý phân tán sai hay mang các thông tin vô ít để cản trở các Agent khác trong tác vụ của Agent. 2.1.2.3. Sự từ chối quan hệ giao tiếp (Repudiation) Sự từ chối quan hệ giao tiếp xảy ra khi một Agent tham gia vào giao tác (transaction) hay một sự kết nối (communication), sau đó đòi các giao tác hay các kết nối mà không bao giờ có được. Một trong hai nguyên nhân của việc từ chối quan hệ giao tiếp đó là một sự có tính toán hay ngẫu nhiên, sự từ chối quan hệ giao tiếp có thể dẫn đến

Trang 28

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

những tranh chấp nghiêm trọng. Một Agent Platform không thể ngăn cản một Agent từ chối tham gia vào giao tác, nhưng Agent Platform có thể bảo đảm rằng có thể đủ mạnh để giải quyết các tranh chấp. Một Agent có thể từ chối tham gia vào một giao tác vì kết quả của một sự hiểu sai, điều này thì quan trọng cho các Agent và Agent Platform dính trong các giao tác duy trì các bảng ghi (records) để giúp cho việc giải quyết các mâu thuẫn. 2.1.2.4. Truy xuất bất hợp pháp (Unauthorized Access) Nếu Agent Platform có cơ cấu điều khiển yếu hoặc không có, thì một Agent có thể giao tiếp trực tiếp với Agent khác bằng cách gọi các phương thức public của nó hay truy cập và sửa đổi dữ liệu (data) hay mã (code) của Agent. Việc sửa đổi mã (code) của một Agent là một kiểu tấn công đặc biệt nguy hiểm, vì khi đó hành vi của Agent có thể đã bị thay đổi so với lúc đầu. Một Agent có thể tìm kiếm được thông tin về các Agent khác đang hoạt động bằng cách dùng các dịch vụ Agent Platform để nghe trộm trên các liên lạc của chúng. 2.1.3. Sự tấn công từ Platform đối với Agent (Platform-to-Agent) Loại tấn công này diễn tả một bộ các mối đe dọa mà trong đó các Agent Platform làm tổn thương đến sự an toàn của Agent. Phần này bao gồm các vấn đề: mạo danh (masquerading), tấn công từ chối dịch vụ (denial of service), nghe trộm (eavesdropping), và sửa đổi (alteration). 2.1.3.1. Mạo danh (Masquerade) Một Agent Platform có thể mạo danh một Agent Platform khác để đánh lừa một Agent di động nào đó, để Agent di động tưởng rằng nó là đích đến của Agent đó. Một Agent Platform cũng có thể giả dạng như một người thứ ba đáng tin tưởng (trusted third party) để có thể nhử các Agent dễ tin đến Agent Platform và khai thác thông tin nhạy cảm trên các Agent đó. Các Agent Platform mạo danh có thể gây nguy hiểm cả cho Agent và Agent Platform thực. Một Agent giả dang một Agent khác thì có thể nguy hiểm cho các Agent khác chỉ thông qua các thông điệp (messages) mà chúng trao đổi và các Trang 29

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

hoạt động do các tin nhắn đó gây ra, nhưng một Agent Platform nguy hiểm mà nó giả dạng một Agent Platform đã được xác thực (authorized) thì có thể gây ra nhiều nguy hiểm hơn là một Agent giả dạng. Sự nguy hiểm của một Agent Platform là việc thay đổi mã (code), trạng thái (state), hay dữ liệu của Agent. 2.1.3.2. Từ chối dịch vụ (Denial of Service) Khi một Agent đi đến một Agent Platform, nó đợi Agent Platform thực thi các yêu cầu của nó một cách trung thực, cung cấp sự chỉ định hợp lý tài nguyên, và tuân theo đặc tính của sự thỏa thuận về dịch vụ. Tuy nhiên, một Agent Platform nguy hiểm có thể bỏ qua (ignore) các yêu cầu dịch vụ của Agent, hay không thực thi đoạn mã của Agent, hay thậm chí có ngắt (terminate) Agent mà không có thông báo. Các Agent trên Agent Platform khác chờ kết quả của một Agent không trả lời trên một Agent Platform nguy hiểm phải cẩn thận để tránh bị deadlock. 2.1.3.3. Nghe trộm (Eavesdropping) Mối đe dọa của nghe trộm cổ điển gồm chặn (interception) và giám sát (monitoring) các thông tin riêng tư. Tuy nhiên, mối nguy hiểm của việc nghe trộm trên hệ thống Mobile Agent thì nghiêm trọng hơn bởi vì Agent Platform không những giám sát các kết nối liên lạc mà còn có thể giám sát mỗi chỉ dẫn thực thi bởi Agent, tất cả dữ liệu (data) không mã hóa hay public nó mang đến Agent Platform, và tất cả dữ liệu sau khi được sinh ra trên Agent Platform. Agent Platform có thể truy xuất đến mã (code), trạng thái (state) và dữ liệu (data) của Agent, vì thế các Agent đến (visiting Agent) phải thận trọng cho các sự kiện của mình, bởi vì điều này có thể làm tiết lộ các thuật toán độc quyền, các giao dịch riêng, các chiến lược đàm phán, hay các thông tin nhạy cảm khác. Thậm chí ngay khi Agent không trực tiếp để lộ các thông tin riêng, nhưng Agent Platform có thể suy ra từ các kiểu của dịch vụ yêu cầu và từ các kết nối liên lạc trên các Agent khác. 2.1.3.4. Sự sửa đổi (Alteration) Khi một Agent đi đến một Agent Platform thì nó đang để lộ ra mã (code), trạng thái (state), và dữ liệu (data) của nó trên Agent Platform. Một Agent có thể đến nhiều Trang 30

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Agent Platform dưới sự bảo vệ khác nhau trong suốt chu trình của nó, vì thế các Agent Platform phải bảo đảm tính toàn vẹn về mã (code), trạng thái (state), và dữ liệu (data) của Agent. Một Agent Platform nguy hiểm phải được ngăn cản việc sửa đổi mã nguồn, trạng thái và dữ liệu của Agent. 2.1.4. Những thực thể khác tấn công vào hệ thống Agent Platform (Other-toAgent Platform) Sự tấn công này diễn tả một bộ các mối đe dọa mà trong đó các thực thể bên ngoài bao gồm các Agent và Agent Platform đe dọa đến sự bảo mật của Agent Platform. Các mối đe dọa là: Mạo dạnh (masquerading), từ chối dịch vụ (denial of service), truy xuất bất hợp pháp (unauthorized access), và sao chép và truyền lại (copy and replay). 2.1.4.1. Mạo danh (Masquerade) Các Agent có thể yêu cầu các dịch vụ trên Agent Platform kể cả từ xa và trên cục bộ. Một Agent trên một Agent Platform từ xa có thể giả dạng như một Agent khác và yêu cầu những dịch vụ và tài nguyên cho mình ngay khi nó chưa được chứng thực. Các Agent giả mạo như các Agent khác có thể làm nhiệm vụ liên kết với các Agent Platform nguy hiểm để lừa một Agent Platform từ xa khác hay chúng có thể hoạt động riêng lẻ. Một Agent Platform từ xa cũng có thể giả dạng một Agent Platform khác và lừa các Agent Platform hay các Agent khác. 2.1.4.2. Truy xuất bất hợp pháp (Unauthorized Access) Các user, process và các Agent từ xa có thể yêu cầu các tài nguyên cho mình mà không chứng thực. Truy xuất từ xa tới Agent Platform và host thì bản thân nó cũng phải được bảo vệ cẩn thận, vì các sự các kịch bản (scripts) tấn công có sẵn trên Internet có thể làm sụp đổ hệ điều hành và chiếm quyền điều khiển tất cả các tài nguyên. Thuộc tính quản trị từ xa của Agent Platform hay chính sách bảo mật thì có thể mô tả cho người quản trị điều này thì cho các Agent Platform phân tán, nhưng việc cho phép quản trị từ xa có thể làm cho hệ thống account hay session của người quản trị là mục tiêu cho cuộc tấn công. Trang 31

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

2.1.4.3. Từ chối dịch vụ (Denial of Service) Các dịch vụ trên Agent Platform có thể được truy cập cả từ xa và trên cục bộ. Các dịch vụ Agent cung cấp bởi sự kết nối Agent Platform và inter-Platform có thể bị phá vỡ bởi các tấn công từ chối dịch vụ phổ biến. Các Agent Platform cũng rất dễ bị ảnh hưởng do các tấn công từ chối dịch vụ trên hệ điều hành hay các giao thức kết nối. 2.1.4.4. Sao chép và truyền lại (Copy and Replay) Mỗi khi Mobile Agent di chuyển từ một Agent Platform này đến Agent Platform khác thì càng làm lộ ra các vấn đề về bảo mật. Một ai đó muốn chặn một Agent hay Agent message, trên đường di chuyển cố gắng copy Agent hay Agent message và nhân bảng truyền lại nó. Thí dụ, người ta có thể chặn bắt một Agent “buy order” và replay nó nhiều lần. Người ta có thể chặn bắt một Agent hay Agent message sau đó copy và replay nó.

2.2. Những yêu cầu về an toàn bảo mật (Security Requirements) Các người dùng trong hệ thống mạng máy tính có bốn yêu cầu bảo mật chính sau: sự cẩn mật (confidentiality), tính toàn vẹn (integrity), tính sẵn sàng (availability), và trách nhiệm giải trình (accountability). Các người dùng của Agent và Mobile Agent cũng có các yêu cầu bảo mật giống như vậy. 2.2.1. Sự cẩn mật (Confidentiality) Mọi dữ liệu được chứa trên Agent Platform hay được mang theo bởi một Agent phải được giữ nguyên tính cẩn mật. Agent Frameworks phải bảo đảm rằng sự liên lạc bên trong hoặc ngoài Agent Platform phải giữ nguyên tính cẩn mật. Những kẻ nghe trộm có thể lấy thông tin về các hoạt động của một Agent không chỉ từ nội dung của thông điệp (message) được trao đổi mà còn từ các luồng tin nhắn (message flow) từ một Agent đến một hay nhiều Agent khác. Việc giám sát các luồng tin nhắn có thể suy luận ra được các thông tin có ích mà không cần phải truy xuất vào nội dụng các tin nhắn thực đó. Một Agent nghe trộm có hay một thực thể ngoài (external entity) có thể dùng các thông tin này để kiếm lợi bất chính. Các Agent có thể dò tìm ra ngôn ngữ kết nối Agent (Agent Trang 32

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Communication Language-ACL) trong cuộc đàm thoại giao dịch giữa các Agent khác, từ đó có thể suy ra ý nghĩa xa hơn từ cuộc đàm thoại đó. Các Agent di động (Mobile Agent) cũng muốn giữa kín vị trí của chúng. Các Mobile Agent có thể kết nối thông qua một proxy của nó nếu nó muốn che giấu sự hiện diện trên Agent Platform. Các Agent phải được phép quyết định nếu sự hiện diện của chúng được công khai một cách sẵn sàng thông qua sự chỉ dẫn của Agent Platform, và Agent Platform có thể buộc Agent phải tuân theo các chính sách bảo mật khác nhau. 2.2.2. Tính toàn vẹn (Integrity) Agent Platform phải bảo vệ các Agent không được phép sửa đổi mã (code), trạng thái (state) và dữ liệu (data) của Agent. Agent tự nó không thể ngặn cản các Agent Platform nguy hiểm can thiệp vào mã (code), trạng thái (state) hay dữ liệu (data), nhưng Agent có thể theo dõi được sự xâm hại này. Sự hoạt động an toàn của hệ thống Mobile Agent cũng phụ thuộc vào tính toàn vẹn của chính các Agent Platform cục bộ và từ xa. Một host nguy hiểm có thể dễ dàng làm hại đến tính toàn vẹn của Mobile Agent trong khi nó đến một Agent Platform ở xa. Một Agent Platform nguy hiểm có thể làm thay đổi nhỏ trong luồng thực thi mã (code) của Agent, và làm thay đổi đến kết quả tính toán mà điều này thì rất khó phát hiện. Một Agent Platform nguy hiểm cũng có thể gây trở ngại cho các Agent trong việc liên lạc trao đổi thông tin. Các hệ thống điều khiển truy xuất phải được đưa ra để bảo vệ tính toàn vẹn (integrity) của Agent Platform tránh các user truy cấp bất hợp pháp. Các việc cố ý sửa đổi hay xâm hại đến Agent Platform bởi các user hợp pháp hay bất hợp pháp đều làm tăng khó khăn cho Mobile Agent có thể được phát hiện và loại bỏ. 2.2.3. Trách nhiệm giải trình (Accountability) Mỗi xử lý (process), người dùng, hay Agent trên Agent Platform phải có trách nhiệm cho các hoạt động của mình. Để giữ trách nhiệm đó thì mỗi xử lý, người dùng, hay Agent phải có ID duy nhất, được xác thực, và được kiểm tra. Thí dụ, các hoạt động mà chúng phải có trách nhiệm bao gồm: truy xuất tới một đối tượng, như là một tập tin, hay làm một sự thay đổi thuộc quyền quản trị đến cơ cấu bảo mật của Agent Platform. Trang 33

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Trách nhiệm giải trình (accountability) yêu cầu giữ một sổ nhật ký kiểm tra (audit log) của các sự kiện bảo mật có liên quan mà các sự kiện đó đã xảy ra, và lắng nghe mỗi sự kiện và Agent hay xử lý (process) chịu trách nhiệm cho sự kiện đó. Các sự kiện có liên quan đến bảo mật được định nghĩa trong chính sách bảo mật của Agent Platform, ví dụ như: tên user/Agent (user/Agent name), thời gian của sự kiện (time of event), loại của sự kiện (type of event) và thành công hay thất bại của sự kiện (success or failure of the event). Sổ theo dõi (audit log) phải được bảo vệ tránh việc truy xuất bất hợp pháp và sửa chữa. Kích thước của audit log cũng phải được chú ý đến tránh để bị mất khi thiết bị lưu trữ đầy. (Audit logs) giữ cho những người dùng (user) hay xử lý (process) chịu trách nhiệm trước các hành động của họ. Mobile Agent tạo sổ kiểm tra (audit) kéo dọc trên nhiều Agent Platform, với mỗi Platform nhật ký (logging) các sự kiện riêng, và sổ nhật ký sẽ khác nhau cho các sự kiện giống nhau. Trong một trường hợp nào đó một Agent phải truy xuất đến thông tin phân tán trên các Agent Platform khác nhau thì có khó khăn để dựng lại chuỗi nối tiếp của các sự kiện. Các Agent Platform mà nó giữ các sổ nhật ký phân tán (distributed audit log) thì phải duy trì được một khái niệm thuộc thời gian chung (globlal time) hoặc thứ tự của các sự kiện (ordering of events). Sổ nhật ký ghi các hành động của Agent (audit log Agent actions) thì rất quan trọng xem như một trách nhiệm pháp lý. Sổ ghi nhật ký (audit log) cũng rất cần thiết và có giá trị khi Agent Platform phải phục hồi (recover) từ một lỗi bảo mật, hay một phần mềm (software) hay phần cứng (hardware) bị lỗi. Audit log thì cũng cần thiết trong trường hợp các Agent chối bỏ nhiệm vụ cho các hành động của mình và cho trách nhiệm pháp lý sau này. Các cơ chế xác nhận đúng (Authentication mechanisms) cung cấp trách nhiệm cho các hành động của user. Các Agent phải có thể xác thực đúng ID của chúng với các Agent Platform và với các Agent khác, trong khi đó các Agent Platform phải xác thực đúng ID của chúng đến các Agent và các Agent Platform khác. 2.2.4. Tính sẵn sàng (Availability)

Trang 34

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Agent Platform phải bảo đảm tính sẵn sàng cả về dữ liệu (data) và dịch vụ (service) cho các Agent cục bộ và Agent ở xa. Agent Platform phải có thể cung cấp các điều khiển đồng thời, hỗ trợ các truy xuất đồng thời, quản lý sự đình trệ (deadblock) ... Dữ liệu chia sẽ cũng phải được sẵn sàng để sử dụng, sức chứa (capacity) cũng sẵn sàng cho các dịch vụ khi cần, và các chuẩn bị về tài nguyên hợp lý và các dịch vụ đúng lúc cũng phải được thực hiện. Agent Platform phải có thể phát hiện và phục hồi được từ các hỏng hốc của phần mềm và phần cứng. Trong khi Agent Platform có thể cung cấp một số khả năng chịu đựng lỗi và khả năng phục hồi thiếu (fault-tolerance and faultrecovery), thì các Agent phải được yêu cầu chịu trách nhiệm cho các fault-recovery của chính nó. Agent Platform phải có thể tiếp nhận được các yêu cầu của hàng trăm hay hàng ngàn các Agent đến hay Agent ở xa.

2.3. Biện pháp đối phó (Countermeasures) Nhiều kỹ thuật bảo mật thường dùng trong các ứng dụng phân tán đương thời, cũng có ứng dụng trong phạm vi mô hình Mobile Agent. Ngoài ra, có một số mở rộng của kỹ thuật thông thường và kỹ thuật được phát minh (devised) đặc biệt cho việc điều khiển mã di động (mobile code) và nội dung có thể thực thi (executable content) mà có thể ứng dụng cho việc bảo mật của hệ thống Mobile Agent. Chúng ta xem lại các biện pháp đối phó và xem như các kỹ thuật đó có thể được dùng để bảo vệ Agent Platform. 2.3.1. Việc bảo vệ Agent Platform (Protecting the Agent Platform) Một trong những vấn đề chính liên quan đến việc thực thi một hệ thống Agent là việc đảm bảo rằng các Agent không thể gây trở ngại đến một Agent khác hoặc với Agent Platform. Một sự thăm dò chung cho việc hoàn hảo điều này là thiết lập các phạm vi cô lập cho mỗi Agent và mỗi Agent Platform và quản lý tất cả các truy xuất trong phạm vi đó.

Trang 35

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Những kỹ thuật được phát triển gần đây nhằm vào mã lệnh di chuyển (mobile code) và bảo mật trên Mobile Agent, được phát minh cho việc bảo vệ các Agent Platform bao gồm: - Phần mềm dựa trên sự cô lập khuyết điểm (Software-Based Fault Isolation) - Sự trình diễn mã lệnh an toàn (Safe Code Interpretation) - Đánh dấu mã lệnh (Signed Code) - Sự đánh giá trạng thái (State Appraisal) - Lịch sử đường đi (Path Histories) - Sự kiểm chứng mang theo mã lệnh (Proof Carrying Code) 2.3.1.1. Phần mềm dựa trên sự cô lập khuyết điểm (Software-Based Fault Isolation) Software-Based Fault Isolation là một phương pháp ép buộc cô lập các module ứng dụng bị lỗi. Kỹ thuật này cho phép các chương trình không tin cậy (untrusted programs) được viết bằng một ngôn ngữ không an toàn (unsafe language), như C, được thực thi an toàn ở trong một không gian địa chỉ ảo của ứng dụng. Máy không tin cậy (Untrusted machine) có thể hiểu được các modules mã (code) đã được thay đổi, vì vậy tất cả việc truy xuất tới bộ nhớ thì được giới hạn tới các đoạn mã (code) và dữ liệu (data) trong vùng lỗi của nó. Truy xuất tới tài nguyên hệ thống cũng có thể được điều khiển thông qua ID duy nhất kết hợp với mỗi phạm vi. 2.3.1.2. Sự trình diễn mã lệnh an toàn (Safe Code Interpretation) Các hệ thống Agent thường được phát triển bằng việc sử dụng một script được phiên dịch hay một ngôn ngữ lập trình. Sự thúc đẩy chính để làm điều đó là việc hỗ trợ của Agent Platform trên hệ thống máy tính không đồng nhất. Ngoài ra, các khái niệm cao hơn ở mức trừu tượng được cung cấp trong môi trường trình diễn có thể làm cho dễ dàng phát triển mã Agent (Agent Code). Ý kiến đằng sau “Safe Code Interpretation” là những lệnh được xem như nguy hiểm có thể hoặc làm an toàn hoặc từ chối đến một Agent. Một ngôn ngữ trình diễn được sử dụng rộng rãi là Java. Ngôn ngữ lập trình Java và môi trường thực thi buộc phải tuân theo sự bảo mật một cách chính yếu thông qua kiểu an Trang 36

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

toàn mạnh. Java theo sau một mô hình bảo mật khuôn mẫu, được dùng để cô lập bộ nhớ và phương pháp truy cập, và duy trì các miền thực thi loại trừ lẫn nhau. Sự bảo mật thì buộc phải thông qua một biến của hệ thống. 2.3.1.3. Đánh dấu mã lệnh (Signed Code) Một kỹ thuật cơ bản cho việc bảo vệ một hệ thống Agent là đánh dấu (signing) mã (code) hoặc các đối tượng (object) khác với một chữ ký số (a digital signature). Một chữ ký số (a digital signature) phục vụ như một phương tiện như thừa nhận việc xác thực của một đối tượng, gốc của nó, và tính toàn vẹn của nó. Đặc trưng của người ký mã (code signer) là hoặc người tạo ra Agent hoặc user của Agent hoặc một vài thực thể mà xem xét lại Agent. Bởi vì một Agent hoạt động trên một nhân danh (behalf) của người dùng (end-user) hay một tổ chức (organization), các hệ Mobile Agent phổ biến sử dụng chữ ký của user như một dấu hiệu của sự xác nhận cho Agent hoạt động. Code signing bao gồm việc mã hóa các khóa công cộng (public key), điều này dựa trên một cập khóa kết hợp. Một khóa được giữa riêng bởi thực thể và khóa kia thì được công khai. 2.3.1.4. Sự đánh giá trạng thái (State Appraisal) Mục đích của việc đánh giá trạng thái (State Appraisal) là để bảo đảm rằng một Agent không bị phá hoại do việc sửa đổi các thông tin trạng thái của nó. Sự thành công của kỹ thuật này dựa trên việc sửa đổi có hại đến trạng thái của Agent mà có thể được dự đoán trước. Các hàm đánh giá thì được dùng để xác định những quyền gì để cấp cho một Agent. Dựa trên cả hai nhân tố điều kiện và trạng thái nhận dạng lượng không đổi, một Agent mà trạng thái của nó vi phạm một lượng không đổi có thể không được cấp quyền, trong khi một Agent mà trang thái của nó sai (fail) để gặp các nhân tố điều kiện có thể được cấp một quyền hạn chế. Cả người tạo ra và người chủ của một Agent làm ra các hàm đánh giá mà nó trở thành một phần của mã Agent. Một người chủ áp dụng trạng thái ép buộc để làm giảm trách nhiệm pháp lý (liability) và/hoặc điều khiển giá (control cost). Khi đó người tạo ra và người chủ phân việc ký dấu lên Agent, những hàm đánh giá riêng của họ được bảo vệ khỏi không thể phát hiện sự sửa đổi. Một Agent Platform dùng những hàm để kiểm tra trạng thái đúng của một Agent đi vào và quyết định những quyền Trang 37

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

gì mà Agent này có được trong suốt quá trình thực thi. Những quyền được cấp bởi một Agent Platform dựa trên các kết quả của hàm thẩm tra và chính sách bảo mật của Agent Platform. 2.3.1.5. Lịch sử đường đi (Path Histories) Ý tưởng cơ bản của “Path Histories” là để duy trì một hồ sơ (record) của một Agent đã được chứng thực trên các Agent Platform khác, vì thế khi Agent đi đến một Agent Platform mới có thể quyết định có hay không và những tài nguyên nào được cấp cho Agent đó. Việc tính toán “Path Histories” thì yêu cầu mỗi Agent Platform phải thêm vào một ký hiệu (signing) lên đường đi (path), cho biết ID của nó (tức của Agent Platform) và cái ID của Agent Platform kế tiếp để đến, và cung cấp “Path Histories” đầy đủ cho Agent Platform kế tiếp. Để ngăn chặn sự xâm hại, thì chữ ký của đường đi vào mới phải bao gồm cả những cái trước đó trong sự tính toán của tóm lược tinh nhắn (message). Cách trên, thì Agent Platform kế tiếp có thể xác định theo hai hướng hoặc là nó tin tưởng vào các Agent Platform trước đó mà Agent đã đi đến, hoặc xem lại trong “path histories” danh sách các ID được cung cấp hay các chữ ký xác nhận. Kỹ thuật này không ngăn chặn hành vi nguy hiểm của một Agent Platform, nó phục vụ để ngăn cản, vì vậy chữ ký của Agent Platform trên đường đi thì không đáng tin. 2.3.1.6. Sự kiểm chứng mang theo mã lệnh (Proof Carrying Code) Proof Carrying Code là ép buộc người viết mã (code proceder) phải chính thức chứng minh rằng chương trình có đặc tính an toàn trước các quy định của khác hàng (code consumer). Proof Carrying Code là một kỹ thuật ngăn cản (prevention technique), trong khi Code Signing là kỹ thuật nhận dạng và chứng thực, nhưng không ngăn cản việc thực thi của mã không an toàn (unsafe code). Mã (code) và sự kiểm chứng (proof) thì được gửi đến người dùng (code consumer) ở đó các đặc tính an toàn có thể được kiểm tra.

Trang 38

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

2.3.2. Việc bảo vệ các Agent (Protecting Agents) Một số kỹ thuật để bảo vệ Agent bao gồm: - Tóm lược kết quả từng phần (Partial Result Encapsulation) - Ghi lại hành trình chung (Mutual Itinerary Recording) - Ghi lại hành trình bằng việc tạo bảng sao và biểu quyết (Itinerary Recording with Replication and Voting) - Lần theo dấu vết của sự thực thi (Execution Tracing) - Sự phát sinh khóa môi trường (Environmental Key Generation) - Xử lý chức năng mã hóa (Computing with Encrypted Functions) - Mã lệnh khó hiểu (Obfuscated Code) 2.3.2.1. Tóm lược kết quả từng phần (Partial Result Encapsulation) Phương pháp này dùng để phát hiện sự can thiệp vào bởi các host nguy hiểm (malicious hosts), mà nó được tóm lược trong các kết quả của các hành động của Agent. Việc tóm lược này có thể được làm cho các mục đích khác với các cơ chế khác nhau, như là cung cấp sự cẩn mật dùng cho mã hó, hay cho tính toàn vẹn và trách nhiệm giải trình, dùng chữ ký số. Thông tin đã tóm lược phụ thuộc vào những gì trên các đích của Agent (goals of Agent). Có ba phương pháp để tóm lược các kết quả: - Cung cấp cho Agent một cách cho việc tóm lược thông tin, - Dựa vào bảng tóm lược của Agent Platform, - Dựa vào một sản phẩm thứ ba (third-party) để lấy bảng kết quả. Phương pháp khác cho một Agent tóm lược kết quả thông tin là dùng Partial Result Authentication Codes (PRAC), nó bằng mật mã, sử dụng khóa mật mã kín (secret key cryptography). Kỹ thuật này yêu cầu Agent và nơi khởi tạo (originator) duy trì hoặc tăng thêm một danh sách các khóa kín (a list of secret keys) được dùng trong sự tính toán PRAC. Một khi một khóa (key) thì được ứng dụng để tóm lược thông tin thu thập được, Agent hủy nó (key) trước khi di chuyển đến Agent Platform kế tiếp để chắc chắn tính toàn vẹn về sau. Tính toàn vẹn về sau bảo đảm rằng nếu có một trong các server đến

Trang 39

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

nguy hiểm thì các kết quả tóm lược đó vẫn còn đúng. Tuy nhiên chỉ có nơi khởi tạo (originator) mới có thể kiểm tra những kết quả,vì không có ai khác giữ khóa kín. 2.3.2.2. Ghi lại hành trình chung (Mutual Itinerary Recording) Một sự thay đổi đáng chú ý của “Path Hietories” là một sự sắp xếp có hệ thống tổng quát cho phép hành trình của Agent (Intierary of Agent) được ghi lại và theo dõi bởi Agent hợp tác khác, trong một sự sắp xếp hỗ trợ lẫn nhau. Khi di chuyển giữa các Agent Platform, một Agent chuyển thông tin của Agent Platform cũ, Agent Platform hiện hành và Agent Platform mới đến Agent hỗ trợ cùng cấp (ngang hàng) thông qua một kênh xác thực. Agent ngang hàng đó duy trì một bảng ghi (record) của hành trình và giữ lấy hành động thích hợp khi sự mâu thuẫn được thông báo. Một thông báo được đáp lại bởi Agent ngang hàng với nó, vì thế Agent tránh các Agent Plaform đã đi qua rồi. Điều này thì được xây dựng trên sự thừa nhận rằng chỉ có một vài Agent Platform là nguy hiểm, và thậm chí nếu một Agent gặp một Agent Platform mà Agent Platform này không thích có thể nó hợp tác với một Agent Platform nguy hiểm khác đã được đến bởi Agent ngang hàng. Vì vậy, phân chia theo hoạt động và ứng dụng giữa hai Agent, chắc chắn hành vi nguy hiểm của Agent Platform đã được phát hiện. Sự sắp xếp theo hệ thống có thể được tổng quát hóa cho nhiều hơn hai Agent hợp tác. Kỹ thuật này có thể nhập vào ứng dụng thích hợp nào đó. 2.3.2.3. Ghi lại hành trình bằng việc tạo bảng sao và biểu quyết (Itinerary Recording with Replication and Voting) Một Agent Platform mắc lỗi có thể đối xử giống như một Agent Platform nguy hiểm. Vì vậy, cho phép khả năng chịu đựng lỗi trong môi trường nên tính đến các ảnh hưởng của các Platform nguy hiểm. Như một kỹ thuật bảo đảm cho Mobile Agent đến đích an toàn là thông qua sự tái tạo và chọn (Replication and Voting). Ý kiến này thì tốt hơn một bảo sao của một Agent thực thi sự tính toán, nhiều bảng sao của Agent thì được dùng. Mặc dù một Agent Platform nguy hiểm có thể làm hư hỏng một vài bản sao của Agent, đủ tái tạo để tránh đụng độ để hoàn thành trọn vẹn việc tính toán. Mỗi lần tính Trang 40

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

toán, Agent Platform bảo đảm rằng các Agent đến thì không bị ảnh hưởng, kèm theo các thông tin hợp lý. 2.3.2.4. Lần theo dấu vết của sự thực thi (Execution Tracing) Execution Tracing là một kỹ thuật phát hiện các sự sửa đổi bất hợp pháp của một Agent trên một các ghi chép đúng các hành vi của Agent trong suốt quá trình thực thi của nó trên mỗi Agent Platform. Kỹ thuật này yêu cầu mỗi Agent Platform bao gồm việc tạo ra và giữ lại một nhật ký (a log) hay dấu vết của các hoạt động thực thi bằng một Agent nội trú ở đó, và trình về (submit) một mật mã của các dấu vết trên sự kết thúc. Kỹ thuật này cũng định nghĩa một giao thức bảo mật để mang các Agent và kết hợp các thông tin có liên quan với nhau giữa các thành phần liên quan, có thể bao gồm của một thành phần thứ ba được tin cậy (a trusted third party) để giữ lại các bảng tóm tắt dấu vết liên tiếp của toàn bộ hành trình của Agent. Nếu bất kỳ kết quả nghi ngờ nào xảy ra, thì các dấu vết riêng và các dấu vết trong bảng tóm tắt có thể được lấy lại và kiểm tra, và một host nguy hiểm được nhận ra. 2.3.2.5. Sự phát sinh khóa môi trường (Environmental Key Generation) Environmental Key Generation mô tả một sự sắp xếp có hệ thống cho phép một Agent giữ hành động được định nghĩa trước khi điều kiện môi trường đúng. Kỹ thuật này bảo đảm rằng Agent Platform hay một người theo dõi Agent không thể phát hiện các tin nhắn (message) xảy ra hay các phản ứng hành động bằng cách đọc trực tiếp trên code của Agent. Thủ tục này gần giống như “password” trong hệ điều hành. 2.3.2.6. Xử lý chức năng mã hóa (Computing with Encrypted Functions) Mục đích của Computing with Encrypting Functions là xác định một phương pháp nào cho mã di động (mobile code) có thể an toàn tính toán mật mã, như là một chữ ký số (digital signature), thậm chí thông qua mã đã được thực thi trong môi trường tính toán không tin cậy và hoạt động tự trị mà không ảnh hưởng lẫn nhau với Platform chủ (Home Platform). Gần như là Agent Platform thực thi một chương trình kể cả một hàm được mã hóa mà không thể nhận được hàm gốc; gần như yêu cầu sự phân biệt giữa một hàm và một chương trình mà chương trình thực thi hàm. Trang 41

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Kỹ thuật này, trong khi rất mạnh, không ngăn cản từ chối dịch vụ (denial of service), replay, và một số kiểu tấn công khác chống lại Agent. 2.3.2.7. Mã lệnh làm khó hiểu (Obfuscated Code) Một khái quát ngắn gọn về các mối đe dọa xuất phát từ một Agent đụng độ với một host nguy hiểm được đề cập đến như sự thúc đẩy đối với cơ chế bảo mật hộp đen (Blackbox-Security). Chiến lược bên dưới kỹ thuật này thì đơn giản, sự tranh giành mã lệnh, một cách mà không ai có thể đạt tới một sự hiểu biết hoàn chỉnh về chức năng của nó hoặc sửa đổi kết quả của mã lệnh mà không cần đến sự dò tìm. Một vấn đề nghiêm trọng với kỹ thuật này là không có thuật toán nào được biết hoặc thăm dò việc cung cấp sự bảo vệ hộp đen. Một lần, sự biến đổi giới hạn của cơ chế bảo mật hộp đen được đưa ra như là một cách lựa chọn hợp lý, bằng cách đó sức mạnh của sự tranh giành không nhất thiết bao hàm sự mã hóa đối với đối tượng không đủ tư cách, nhưng phần lớn dựa trên những thuật toán khó hiểu. Từ đó, một Agent có thể trở nên vô hiệu hóa trước khi hoàn tất công việc xử lý của nó. Mã lệnh khó hiểu này phù hợp cho những ứng dụng không vận chuyển thông tin mong đợi cho sự che dấu lâu dài.

KẾT LUẬN Các kỹ thuật ứng dụng cho việc thực hiện cơ chế bảo mật trên các hệ thống Agent thì rất đa dạng. Có thể chúng không tương thích với nhau hoặc có thể chúng phù hợp với hầu hết các ứng dụng. Nhiều trong số những kỹ thuật này phải được thi hành trong phạm vi Framework của hệ thống Agent. Trong khi một số lượng lớn các kỹ thuật khác lại có thể áp dụng một cách độc lập trong phạm vi ngữ cảnh của ứng dụng. Trong chương này chúng tôi đã trình bày các vấn đề bảo mật trên hệ thống Mobile Agent. Qua đó chúng tôi đã giới thiệu về các mối đe dọa về an toàn trên hệ thống Agent đồng thời chúng tôi cũng đưa ra một số kỹ thuật giúp giải quyết vấn đề này.

Trang 42

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Chương 3: CÁC MẪU THIẾT KẾ CỦA AGENT (AGENT DESIGN PATTERNS) TÓM TẮT Trong lập trình hướng đối tượng, các ứng dụng thường được xây dựng trên nền tảng của một số lớp đối tượng cơ sở. Ví dụ, các ứng dựng trên Windows thường được xây dựng từ các lớp đối tượng như Cwindows, Cmenu, Cdialog… Các lớp đối tượng này được gọi là các mẫu thiết kế. Các mẫu thiết kế cũng cung cấp một cơ sở hoàn chỉnh cho các môi trường phát triển phần mềm một cách trực quan. Dựa trên các cài đặt chuẩn của những mẫu này, môi trường phát triển có thể sinh ra các Agent với các thuộc tính như ý. Việc tìm hiểu và đưa ra các mẫu thiết kế đóng vai trò quan trọng trong xây dựng các ứng dụng dựa trên Mobile Agent vì Mobile Agent khác với chương trình thông thường ở đặc tính di chuyển của nó. Các mẫu thiết kế dùng cho các ứng dụng dựa trên Mobile Agent có thể được chia thành ba lớp: lớp đặc trưng cho việc di chuyển của Agent, lớp đặc trưng cho sự phân công các tác vụ mà Agent thi hành tại mỗi máy, lớp đặc trưng cho sự tương tác của các Agent.

3.1. Mẫu thiết kế đặc trưng cho sự di chuyển Di chuyển là bản chất của các Mobile Agent. Các mẫu thiết kế đặc trưng cho sự di chuyển giải quyết các vấn đề trong việc quản lý sự di chuyển của các Mobile Agent như tìm đường đi và xác định chất lượng của dịch vụ. Những mẫu thiết kế này cho phép chúng ta thực hiện được việc đóng gói việc quản lý tính di động, từ đó sẽ nâng cao tính dùng lại và đơn giản hóa thiết kế Agent. Trong các mẫu thiết kế đặc trưng cho sự di chuyển có thể tìm thấy hai dạng cụ thể đó là: mẫu thiết kế mô tả lộ trình và định tuyến (tìm đường đi) của Agent trong số nhiều

Trang 43

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

đích đến (ta gọi là Itinerary), mẫu thiết kế mô tả một địa chỉ đích và tóm lược của dịch vụ và các sự cho phép cần thiết để gửi Agent tới và thi hành tại máy đó (ta gọi là Ticket). Mẫu thiết kế Itinerary liên quan đến việc tìm đường đi trong số nhiều đích đến. Một Itinerary duy trì một danh sách các đích đến, xác định các bảng tìm đường đi, xử lý các trường hợp đặc biệt, ví dụ như làm gì nếu đích đến không tồn tại và cho biết đâu là nơi đến kế tiếp. Thể hiện của Itinerary cho phép chúng ta lưu trữ và dùng lại nó sau này như cách ta lưu các URL dưới dạng các bookmark. Mẫu thiết kế Ticket bao gồm các yêu cầu liên quan đến chất lượng của dịch vụ, sự cho phép, và các dữ liệu khác. Ví dụ, nó có thể chứa các thông tin time-out cho việc gửi một Agent đến một máy ở xa. Như vậy thay vì cứ “ngây thơ” gửi liên tục các Agent tới các máy không được kết nối, Agent bây giờ đã có thông tin cần thiết để đưa ra các quyết định hợp lý khi di chuyển.

3.2. Mẫu thiết kế đặc trưng cho sự phân công các tác vụ Mẫu thiết kế này liên quan đến sự phân rã các tác vụ và làm thế nào để các tác vụ này được ủy thác cho một hay nhiều Agent. Nói chung, các tác vụ có thể được gán động cho các Agent có mục đích tổng quát. Hơn nữa, một tác vụ cho trước có thể được hoàn thành bởi một hay nhiều Agent làm việc song song và cộng tác. Trong mẫu thiết kế này có thể tìm thấy hai dạng cụ thể đó là: mẫu thiết kế mô tả sự ủy thác tác vụ của Agent này cho Agent khác (ta gọi là Master- Slave), mẫu thiết kế liên quan đến các dòng tác vụ phức tạp mà Agent tùy vào hoàn cảnh mà thực hiện (ta gọi là Plan). Mẫu thiết kế Master - Slave, cho phép một Agent (gọi là Agent chủ) giao một tác vụ cho một Agent khác (gọi là Agent thợ). Agent thợ sẽ di chuyển tới máy đích, thực hiện các tác vụ được giao rồi sau đó gửi kết quả của tác vụ đó về. Mẫu thiết kế Plan phức tạp hơn, dựa theo khái niệm quy trình để tổ chức nhiều tác vụ được thực hiện tuần tự hay song song bởi nhiều Agent. Mẫu thiết kế này đóng gói dòng các tác vụ. Agent chỉ đơn thuần cung cấp khả năng di chuyển cần để thực hiện các Trang 44

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

hành động tại các máy đích. Mẫu thiết kế (Plan) làm tăng khả năng dùng lại các tác vụ, gán các tác vụ động cho Agent, thậm chí là kết hợp của nhiều tác vụ.

3.3. Các mẫu thiết kế đặc trưng cho sự tương tác Khả năng các Agent liên lạc với các Agent khác là sống còn cho việc hợp tác giữa các Agent. Mẫu thiết kế Interaction liên quan đến việc định vị các Agent và tạo điều kiện thuận lợi cho việc tương tác của chúng. Trong các mẫu thiết kế này có thể tìm thấy hai dạng cụ thể là: mẫu thiết kế mô tả sự tương tác của hai hay nhiều Agent tại một máy nào đó (ta gọi là Meeting), mẫu thiết kế định nghĩa không gian lưu trữ riêng cho dữ liệu để lại của các Agent trước khi tạm di chuyển tới đích khác (ta gọi là locker), mẫu thiết kế mô tả một đại diện của Agent mang thông điệp từ Agent này tới Agent khác (ta gọi là Messenger), mẫu thiết kế mô tả cho việc nhân dạng Agent (ta gọi là Finder), mẫu thiết kế mô tả một nhóm các Agent được di chuyển tự do với nhau (ta gọi là Organized Group). Mẫu thiết kế Meeting là một mẫu tương tác cung cấp cho một, hai hay nhiều Agent thiết lập việc tương tác cục bộ tại một máy cho trước. Nó trừu tượng tính đồng bộ về mặt thời gian và địa điểm cần cho việc tương tác cục bộ. Các Agent có thể tự gửi đi tới mục đích nào đó, gọi là “diễn đàn”, ở đó chúng có thể tiến hành tương tác cục bộ với các Agent đại diện cho các người khác. Các Agent có thể sử dụng mẫu thiết kế Locker để lưu trữ dữ liệu dành riêng một cách tạm thời. Bằng này chúng có thể tránh mang dữ liệu theo. Sau này, Agent có thể trở lại và lấy lại các dữ liệu đó lưu trữ trong Locker. Ví dụ trong một hệ thống mua bán dựa trên Mobile Agent, một Agent có thể ghé máy của một khác hàng nằm ngoài mạng công ty. Trong trường hợp nó có thể lưu các dữ liệu dễ bị xâm phạm trong một Locker trước khi rời mạng của công ty. Kết quả là giảm được tải mạng và cải thiện tình trạng an toàn dữ liệu. Các Agent có thể thiết lập mối liên lạc ở xa bằng cách sử dụng thiết kế Messenger, nó sẽ tổ chức các thông điệp thành dạng Agent mang và phân phối thông Trang 45

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

điệp giữa các Agent. Ví dụ, nếu một Agent thợ muốn báo cáo một kết quả trung gian về Agent chủ, nó có thể gửi kết quả bằng Messenger Agent trong khi tiếp tục các tác vụ hiện hành của nó. Mẫu thiết kế Finder mô tả dịch vụ định danh và định vị cho các Agent. Thật là thuận lợi khi gán một tên tượng trưng cho một Agent để định vị nó sau này. Ví dụ, một Agent thu thập thông tin có thể tiếp tục di chuyển trong mạng và các Agent khác có thể liên tục nhận được các cập nhật từ Agent thông tin mà không thực sự biết vị trí hiện hành của nó. Sử dụng mẫu thiết kế Oranized Group để kết hợp nhiều Agent thành một nhóm, trong đó tất cả các thành viên của nhóm di chuyển cùng với nhau. Mẫu được xem như là thành phần cơ sở của sự cộng tác giữa nhiều Agent.

3.4. Một số mẫu thiết kế đặc trưng Chúng ta sẽ lần lượt tìm hiểu một số mẫu thiết kế đại diện cho các lớp trên: Master-Slave và Itinerary. 3.4.1. Mẫu thiết kế Master-Slave 3.4.1.1. Định nghĩa Mẫu thiết kế Master-Slave là sự trừu tượng hóa cho mô hình Agent chủ giao các tác vụ cho một Agent thợ. 3.4.1.2. Mục đích Có rất nhiều lý do để một Agent – gọi là Agent chủ, cần tạo các Agent khác – gọi là Agent thợ, và giao các tác vụ cho chúng. Lợi ích có được là hiệu quả công việc. Một Agent chủ có thể tiếp tục thực hiện các tác vụ khác song song với các Agent thợ. Xét một ứng dụng dựa trên Mobile Agent cung cấp một giao diện đồ họa cho việc nhập dữ liệu và hiển thị các kết quả trung gian của một tác vụ nào đó được thi hành ở xa. Nếu chỉ một Agent cung cấp giao diện và thi hành tác vụ, nó sẽ không duy trì giao diện sau khi Agent đó di chuyển tới máy ở xa. Thay vào đó, một Agent chủ tĩnh có thể cung cấp

Trang 46

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

và duy trì giao diện trong khi các Agent thợ di chuyển tới các đích khác, thi hành các tác vụ cho trước, và gửi các kết quả trở về Agent chủ, để hiển thị nó tại client. Ý tưởng chính của mẫu thiết Master-Salve là việc sử dụng lớp trừu tượng Slave để cục bộ hóa các thành phần bất biến của việc giao một tác vụ giữa Agent chủ và Agent thợ: gửi một Agent thợ tới một đích ở xa, thiết lập việc thi hành tác vụ đó. ConcreteSlave Agent được định nghĩa như là một lớp con của Slave, trong đó chỉ gồm các thành phần thay đổi như là tác vụ thi hành cài đặt.

Hình 3.1 Trong thực tế, Agent chủ định nghĩa một trình xử lý thông điệp để quản lý các kết quả của tác vụ. Lớp Slave có hai phương thức trừu tượng – initializeTask và doTask – định nghĩa các bước khởi tạo sẽ được thực hiện trước khi Agent di chuyển tới một đích đến và thực hiện tác vụ được giao. 3.4.1.3. Khả năng ứng dụng Sử dụng mẫu thiết kết Master-Salve trong các trường hợp sau: - Khi một Agent cần thi hành một tác vụ song song với các tác vụ khác mà nó có trách nhiệm trong đó. - Khi một Agent tĩnh muốn thi hành một tác vụ ở một máy ở xa. 3.4.1.4. Các thành viên

Trang 47

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Có ba lớp tham gia vào mẫu thiết kế Master-Slave. - Lớp Slave định nghĩa khung của Agent thợ, sử dụng các phương thức trừu tượng (initializeTask và doTask) sẽ được định nghĩa chồng trong lớp ConcreteSlave cài đặt hai phương thức trừu tượng của lớp Slave. - Lớp Master cài đặt Agent, tạo Agent thợ và nhận các thông điệp kết quả của Agent thợ. 3.4.1.5. Sự cộng tác Sự cộng tác giữa các thành viên trong mẫu thiết kết Master-Slave như sau: - Agent chủ tạo Agent thợ. - Agent thợ khởi các tác vụ của nó. - Agent thợ khởi tạo di chuyển đến máy đích để thi hành tác vụ của nó. - Agent thợ gửi kết quả của tác vụ trở về Agent chủ. - Agent thợ tự hủy.

Hình 3.2 3.4.1.6. Kết quả

Trang 48

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Mẫu thiết kế Master-Slave cung cấp một cách cơ bản việc sử dụng lại các Agent. Trong thực tế, việc thiết kế và cài đặt Mobile Agent được đơn giản hóa bằng cách cho những nhà phát triển và cài đặt những biến đổi của các mẫu được định nghĩa trước. Một hạn chế của mẫu thiết này đó là các thao tác của Agent thợ được cố định tại thời điểm thiết kế. Ví dụ, một Agent không thể biến đổi thành một Agent thợ vào thời điểm thi hành, cũng như không thể dễ dàng gán các tác vụ mới cho Agent thợ. Một phiên bản phức tạp hơn của mẫu thiết kế này có thể sử dụng mô hình dựa trên ủy quyền, trong đó tác vụ được hiện thực và Agent thợ có thể được gán bất kỳ tác vụ nào trong thời gian tồn tại của nó. 3.4.1.7. Cài đặt Lớp Slave cài đặt phương thức onCreation dùng để khởi tạo các thông số cần thiết cho Agent thợ, và hai phương thức trừu tượng đó là initializeTask và doTask. Hai phương thức này sẽ được định nghĩa chồng trong lớp ConcreteSlave. Các thông số được dùng cho phương thức onCreation đó là thông tin về đích đến để Agent thợ biết đi đến đâu và một tham chiếu tới Agent chủ để nó nơi trả kết quả về. Một khi được khởi tạo, Agent thợ sẽ gọi phương thức initializeTask() sau đó được gửi đi. Khi đến đích, nó sẽ gọi phương thức doTask() để thực hiện tác vụ của mình và gửi kết quả về cho Agent chủ. Sau khi thực hiện xong nó sẽ tự hủy. public abstract class Slave extends Aglet{ URL destionation = null; AlgetProxy master = null; public void onCreation(Object args){ try{ // Get the setup destionation = (URL)((Object[])args)[0]; master = (AgletProxy)((Object[])args[1]; intializeTask();

Trang 49

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

addMobilityListener(new MobiliyAdapter(){ public void onArrival(MobilityEvent me){ try{ master.sendMessage(new Messeage("Result", doTask())); dispose(); }catch(Exception e){ // Fail to send result to master } } }); } catch(Exception e){ // Fail to create Slave } abstract void initializeTask(); abstract ObjectdoTask(); } }

Bây giờ chúng tao sẽ tạo hai Agent đó là MyMaster và MySlave đóng vai trò Agent chủ và Agent thợ như trong thiết kế mẫu Master-Slave. MyMaster đầu tiên sẽ tạo các thông số dùng để khởi tạo cho Agent thợ, sau đó nó sẽ tạo Agent MySlave. Tiếp theo Agent chủ có nhiệm vụ chờ và xử lý các kết quả do Agent thợ gửi về sau khi nó thực hiện xong nhiệm vụ được giao. public class MyMaster extends Aglet { // Create the slave Agent public void run { try { Object[] args = new Object[] {

Trang 50

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến destination, getAgletProxy()};

getAgletContent().createAglet(getCodeBase(),“MySalve”,args); }catch(Exception e) { // Fail to create the child } } // Handle the slave result message. Public boolean handleMessage(Message msg) { If(msg.sameKind(“Result”)) // Process return true; } }

Lớp MySlave kế thừa từ lớp Slave. Yêu cầu chủ yếu của lớp này đó là cài đặt hai phương thức trừu tượng của lớp Slave: initializeTask và doTask. public class MySlave extends Slave { // Concrete initialize method public void initializeTask(){ } // Concrete task method public Object doTask(){ // Performs some task return result; } }

3.4.2. Mẫu thiết kế Itinerary 3.4.2.1. Định nghĩa Mẫu thiết kế Itinerary cài đặt các lộ trình của Agent và chiến lược di chuyển trong nhiều đích đến. Trang 51

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

3.4.2.2. Mục đích Là một thực thể tự trị, một Agent dựa trên Itinerary có thể di chuyển độc lập qua nhiều máy. Đặc biệt, nó có thể xử lý các tình huống ngoại lệ như là máy đó không tồn tại trong khi cố gửi chính nó tới máy đích. Nó cũng có thể hiệu chỉnh lộ trình của nó một cách linh hoạt tùy thuộc vào các thông tin cục bộ khi cần. Ví dụ, nó có thể gửi chính nó để hỏi về các dịch vụ trang vàng cục bộ ( local yellow pages), trích ra các đích thích hợp và thêm nó vào lộ trình của nó. Ý tưởng chính của mẫu thiết kế này là chuyển trách mhiệm di chuyển từ Agent cho đối tượng Itinerary kết hợp với nó. Lớp Itinerary sẽ cung cấp một giao diện để duy trì hay hiệu chỉnh lộ trình của Agent và gửi Agent tới đích. Đối tượng Agent và đối tượng Itinerary sẽ được kết nối theo cách sau: Agent sẽ tạo đối tượng Itinerary và khởi tạo nó với: (1) Một danh sách các đích có thể được ghé qua một cách tuần tự. (2) Một tham chiếu đến Agent. Sau đó Agent sẽ sử dụng phương thức go() để gửi chính nó đến đích tồn tại ở trong lộ trình của nó. Để hỗ trợ điều này, đối tượng Itinerary được di chuyển cùng với Agent. 3.4.2.3. Khả năng ứng dụng Sử dụng mẫu thiết kế này khi ta cần thực hiện những điều sau: - Che dấu các chi tiết của kế hoạch di chuyển của Agent khỏi các hành vi để đẩy mạnh tính module của cả hai phần. - Cung cấp giao diện nhất quán nhất quán cho việc di chuyển các Agent. - Định nghĩa kế hoạch di chuyển có thể dùng lại và chia sẽ giữa các Agent.

Trang 52

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 3.3 3.4.2.4. Các thành viên - Lớp Itinerary định nghĩa khung của lộ trình, với hai phương thức trừu tượng go() và hasMoreDest() - Lớp ConcreteItinerary cài đặt hai phương thức trừu tượng của lớp Itinerary. - Lớp Agent mô tả Agent. 3.4.2.5. Sự cộng tác - Đối tượng ConcreteItinerary được khởi tạo bởi Agent. - ConcreteItinerary gửi Agent tới đích đầu tiên. - Khi Agent gọi phương thức go() của Itinerary, Agent được gửi đến đích kế tiếp.

Trang 53

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 3.4 3.4.2.6. Kết quả Mẫu thiết kế này hỗ trợ các sự biến đổi trong chiến lược di chuyển. Ví dụ, một hàm xử lý các tình huống ngoại lệ có thể được định nghĩa nếu một Agent thất bại trong việc tự gửi nó tới đích mới: hủy chuyến đi và quay trở về nơi ban đầu, cố chuyển tới một đích khác, và thử lại vào lần sau. Mẫu thiết kế này làm cho dễ dàng khi cung cấp những biến đổi như vậy đơn giản bằng cách thay một đối tượng Itinerary bởi một đối tượng khác. Quan trọng hơn cả, nó sẽ không đòi lớp Mobile Agent phải bị thay đổi. Mẫu thiết kế này cũng làm cho việc chia sẽ các kế hoạch di chuyển giữa các Agent khác dễ dàng. Ví dụ, hai Agent có thể sử dụng một chuyến (tour) tới nhiều desktop của người dùng: một lên thời khóa biểu hẹn gặp giữa các người dùng, một Agent khác phân phối các thông điệp thông báo. 3.4.2.7. Cài đặt

Trang 54

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Lớp Itinerary có một constructor dùng để thiết lập các thông số cho _origin, một trong hai biến của lớp. Biến thứ hai là Agent được thiết lập bằng phương thức init(). Phương thức này cũng gửi Agent tới đích đầu tiên trên lộ trình của nó. Lớp Itinerary định nghĩa ba phương thức trừu tượng đó là: go(), hasMoreDest(), getNextDest(). Các phương thức này sẽ được định nghĩa chồng trong các lớp kế thừa. public astract class Itinerary implements Serializable { protected URL _origin = null; protected AgletProxy _aglet = null; // Constructor public Itinerary(URL origin) { _origin = origin; } // Initalizes the itinerary public void init(Aglet aglet) { _aglet = aglet.getAgletContext().getAgletProxy(aglet.getAgletID()); go(); } // Get the origin information public URL getOrigin() { return _origin; } // ‘go()’ to be imlemented in subclass public abstract void go(); // ‘hasMoreDestinations()’ to be imlemented in subclass public abstract boolean hasMoreDest(); // ‘getNextDestination()’ to be imlemented in subclass public abstract URL getNextDest(); }

Trang 55

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Dựa trên lớp Itinerary, chúng ta sẽ tạo Agent ItinerantAglet di chuyển theo lộ trình và thực hiện các tác vụ định trước. Agent này sẽ cài đặt phương thức onCreation với thông số truyền vào là một đối tượng Itinerary. public class ItineraryAglet implements Aglet { private Itinerary _itinerary = null; public onCreaion(Object init){ try{ _itinerary = (Itinerary)init; addMobilityListener( new MobilityAdapter() { public void onArrival(MobilityEvent me){ try{ if(_itinerary.hasMoreDestinations()){ // Go to next destination… _itinerary.go(); }else{ // Done… dispose(); } catch(Exception e){ // Fail to dispatch.. } } }); // go to first destination _itinerary.init(this) }catch(Exception e){ // Fail initialize the itinerary } } } Trang 56

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

KẾT LUẬN Việc tìm hiểu và đưa ra các mẫu thiết kế đóng vai trò quan trọng trong xây dựng các ứng dụng dựa trên Mobile Agent. Chương này chúng tôi đã giới thiệu các mẫu thiết kế đặc trưng cho mô hình Mobile Agent. Dựa trên các cài đặt chuẩn của những mẫu này, môi trường phát triển có thể sinh ra các Agent với các thuộc tính như ý. Chúng tôi sẽ triển khai cụ thể hai mẫu thiết kế đã giới thiệu là Master – Slave và Itinerary vào ứng dụng “Định thời gian biểu cho cuộc họp” (được giới thiệu trong chương 5). Chương sau chúng tôi sẽ giới thiệu chi tiết về hệ thống Aglet của IBM, một trong những công cụ phát triển ứng dụng trên Mobile Agent.

Trang 57

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Chương 4: KIẾN TRÚC AGLET CỦA IBM Chúng tôi đã giới thiệu về các hệ Mobile Agent hiện hành, nhưng trong khuôn khổ luận văn này, chúng tôi chỉ tập trung đi sâu nghiên cứu về hệ thống Aglet của IBM.

4.1. Mô hình của Aglet IBM’s Aglets Workbench (Aglets) phản ánh lại mô hình của Applet trong Java. Mục đích là mang lại tính di động vào trong đối tượng Applet. Cụm từ “Aglet” được ghép từ hai từ “Agent” và “Applet”. 4.1.1. Các yếu tố cơ sở (Basic Elements) Những lớp trừu tượng chính là Aglet, Proxy, Context, Message, Future Reply và Identifier. - Aglet. Một Aglet là một đối tượng Java di động, mà nó ghé thăm những host có thể có Aglet trên mạng máy tính. Nó thì tự trị, ngay khi nó chạy trong cái tiến trình thực thi chủ của nó sau khi nó đến một host và thích ứng, bởi vì khả năng phản ứng đối với các thông điệp gửi đến. - Proxy. Một Proxy là một thể hiện của một Aglet. Nó phục vụ như là một sự bảo vệ cho Aglet, điều đó thì bảo vệ Aglet tránh sự truy xuất trực tiếp tới những phương thức mà khai báo “public”. Proxy cũng cung cấp các định vị cho Aglet; điều này thì nó có thể ẩn các vị trí thực sự của Aglet. - Context. Một Context là một nơi làm việc (workplace) của Aglet. Nó là đối tượng đứng yên, cung cấp một không gian để duy trì và quản lý việc chạy Aglet trong các môi trường thực thi giống nhau nơi mà các host thì được chắc chắn chống lại các Aglet thù địch. Một node trên mạng máy tính có thể chạy nhiều server và mỗi server có thể nhiều host ngữ cảnh. Các ngữ cảnh (context) thì được đặt tên và do đó có thể xác định vị trí bằng sự kết nối qua địa chỉ server và tên của chúng.

Trang 58

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

- Message. Một Message là một đối tượng trao đổi giữa các Aglet. Nó cho phép các thông điệp đồng bộ và bất đồng bộ trao đổi qua lại giữa các Aglet. Việc trao đổi thông điệp giữa các Aglet được dùng để hợp tác hay trao đổi thông tin. - Future Reply. Thuộc tính Future Reply thì được dùng trong việc gửi và nhận các thông điệp bất đồng bộ. - Identifier. Một Identifier là biên giới cho mỗi Aglet. Cái Identifier là duy nhất và không thay đổi trong suốt vòng đời của Aglet. Một Aglet trải qua nhiều sự kiện trong chu trình sống của nó. Các hoạt động chính của Aglet: Creation, Cloning, Dispatching, Retraction, Deactivation, Activation, Disposal, và Messaging như hình 4.1.

Hình 4.1 - Creation. Một Aglet mới được ra đặt vào trong một Context. Aglet mới được cấp cho một Identifier, đặt nó vào trong Context và khởi tạo Aglet được, Aglet bắt đầu thực thi ngay sau khi nó đã khởi tạo xong. - Cloning. Bản sao của một Aglet được tạo ra, Aglet này thì giống như Aglet gốc. Chỉ khác nhau Identifier và thực thi lại như một Aglet mới. Chú ý rằng là tiến trình thực thi thì không được nhân bản. - Dispatching. Gửi một Aglet từ một Context tới một Context khác sẽ di chuyển nó từ một Context hiện hành tới một Context đích và đặt nó vào trong đó, tại Context Trang 59

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

này Aglet sẽ khởi động lại việc thực thi (sự thực thi thì không di chuyển theo). Ta nói rằng Aglet được đẩy (“pushed”) tới một Context mới. - Retraction. Sự thu hồi của một Aglet, sẽ đẩy (di chuyển) Aglet từ một Context hiện hành và đặt nó vào trong một Context mà nơi có yêu cầu thu hồi. - Deactivation and Activation. Việc ngưng hoạt động (Deactivation) của một Aglet là khả năng ngưng tạm thời việc thực thi của nó và lưu trữ trạng thái của nó xuống đĩa. Activation của một Aglet sẽ phục hồi Aglet vào trong Context của nó. - Disposal. Việc Disposal của một Aglet sẽ ngắt việc thực thi của nó và di chuyển nó ra khỏi Context hiện hành. - Messaging. Messaging giữa các Aglet thì bao gồm việc gửi, nhận và bắt tay những thông điệp đồng bộ cũng như bất đồng bộ. 4.1.2. Các sự kiện lắng nghe trong Aglet Trong Aglet gồm 3 kiểu sự kiện lắng nghe (Listener) - Clone Listener. Lắng nghe cho sự kiện tạo bản sao. - Mobility Listener. Lắng nghe cho sự kiện di chuyển. - Persistence Listener. Lắng nghe cho sự kiện tiếp tục tồn tại, được dùng khi một Aglet chuyển sang trạng thái deactivation và từ deactivation chuyển sang activation. CloneLimiter là một ví dụ của việc sử dụng lại đối tượng listener. Nó có thể nhúng vào các Aglet mà chúng ta muốn giới hạn số bảng sao của một Aglet. CloneLimiter Listener thi hành ba phương thức: onCloning, onClone và onCloned.Ví dụ sau đây chỉ cho tạo năm bảng sao từ Aglet gốc. public class CloneLimiter implements CloneListener() { final integer MAX = 5; boolean original = true; int number_of_clones = 0; // Called when the aglet is about to be cloned. public void onCloning(CloneEvent ev) {

Trang 60

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

if (original == false) throw new SecurityException("Clone cannot create a clone"); if (number_of_clones > MAX) throw new SecurityException("Exceeds the limit"); } // Called in the cloned aglet. public void onClone(CloneEvent ev) { original = false; } // Called in the original aglet after the cloning. public void onCloned(CloneEvent ev) { number_of_clone++; } }

4.2. Aglet API (Aglet - Application Programming Interface) Đây là API mà người lập trình sẽ dùng để tạo và kích hoạt các Aglet. Nó chứa đựng các phương thức initializing, message handling, dispatching, retracting, deactivating/activating, cloning, và disposing của Aglet. Aglet API thì đơn giản và chưa linh động. Aglet API là một gói Java (Java package) gồm nhiều lớp (class) và giao diện (interface), trong đó đáng kể nhất là: Aglet, AgletProxy, AgletContext, và Message. 4.2.1. Lớp Aglet (Aglet class) Lớp Aglet là một lớp chính trong Aglet API. Đó là một lớp trừu tượng mà người phát triển Aglet sử dụng như một lớp cơ bản, khi họ tạo ra một Aglet theo yêu cầu. Lớp Aglet định nghĩa các phương thức để điều khiển chu trình sống của chính nó như Cloning, Dispatching, Deactivating, Activating, Disposing. Ngoài ra Aglet còn định nghĩa một số phương thức mà có thể “override” trong những lớp con bởi người lập trình Aglet. Những phương thức này được gọi bởi hệ thống khi có sự kiện nào đó diễn ra trong cho trình sống của Aglet. Trang 61

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Chúng ta hãy miêu tả một vài phương thức trong lớp Aglet. Phương thức Dispatching làm cho một Aglet di chuyển từ một host cục bộ tới những đích được truyền vào từ tham số. Phương thức Deactivate cho phép một Aglet được lưu tạm trên đĩa. Phương thức Clone tạo ra một bản sao mới của một Aglet, mà trạng thái giống với trạng thái của Aglet gốc. Lớp Aglet cũng sử dụng để truy xuất tới các thuộc tính liên kết với một Aglet. Đối tượng AgletInfo, cái mà tồn tại trong phương thức getAgletInfo(), chứa các thuộc tính gắn liền với một Aglet như là thời gian tạo, code base, cũng như những thuộc tính động như là thời gian đến, địa chỉ Context hiện hành của Aglet. Để chứng minh rằng Aglet được tạo ra đơn giản như thế nào, đầu tiên ta import một package Aglet mà trong đó nó chứa tất cả những định nghĩa của Aglet API. Sau đó ta định nghĩa một lớp MyAglet thừa kế từ lớp Aglet. import aglet.*; public class MyFirstAglet extends Aglet { //… }

Trong ví dụ này nếu ta muốn Aglet thi hành một số khởi tạo đặc biệt khi nó được tạo, ta cần “override” phương thức onCreation(): public void onCreation(Object init) { // Do some initialization here... }

Khi một Aglet được tạo hoặc khi nó đến một Context mới, nó bắt đầu thi hành thông qua phương thức run() của nó. Lời yêu cầu này đồng nghĩa với việc cấp cho Aglet một mức độ tự trị. Phương thức run() được gọi mỗi lần Aglet đến hoặc được kích hoạt trong Context mới. Điều này có thể nói rằng phương thức run() trở thành phương thức chính cho sự thi hành của Aglet. Bằng việc “override” phương thức này ta có thể điều chỉnh được hành vi tự trị của Aglet.

Trang 62

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

public void run() { // Do something here... }

Chẳng hạn ta có thể dùng phương thức run() để cho phép Dispatch chính nó đến một vài Remote Context bằng cách gọi phương thức dispatch() của nó với đối số là URL của máy remote. URL này nên là tên miền và tên máy đặc biệt của Context đích, và giao thức “atp” được dùng để vận chuyển Aglet trên mạng. URL có thể bao gồm tên của Remote Context nếu có hơn một Context được hỗ trợ ở Remote Server. Nếu không có tên Context, Aglet sẽ di chuyển vào Context mặc định. dispatch(new URL("atp://some.host.com/context"));

Như vậy điều gì thực sự sẽ diễn ra đối với một Aglet khi một phương thức được gọi? Điều cơ bản là Aglet sẽ không còn xuất hiện ở máy hiện hành nữa mà nó sẽ xuất hiện với trạng thái tương tự ở host đích. Đầu tiên, một kỹ thuật đặc biệt gọi đối tượng serialization được sử dụng để bảo vệ thông tin trạng thái của Aglet bằng việc tạo ra một chuỗi byte đại diện cho Aglet. Sau đó chuỗi đại diện này sẽ được gởi tới lớp vận chuyển nền (the underlying transfer layer) mà nó sẽ mang Aglet (bao gồm byte code và thông tin trạng thái) an toàn trên mạng. Cuối cùng, những byte này được phục hồi lại để khởi tạo lại trạng thái của Aglet.

Trang 63

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 4.2 – Sự vận chuyển một Aglet. Sau đây là một ví dụ nhỏ tên của lớp là Aglet là DispatchingExample cho phép nó tự dispatch chính nó. DispatchingExample mở rộng từ lớp Alget và “override” hai phương thức onCreation và run. Một Mobility Listener được định nghĩa như một lớp cục bộ. Listener này dùng để lắng nghe sự kiện di động. Chúng ta dùng một biến có kiểu Boolean là _theRemote để phân biệt Aglet trước và sau khi nó dispatch. Khi Alget được tạo và bắt đầu chạy (run()), nó tạo ra một URL cho đích của nó. Khi Aglet đã được dispatch, tất cả các tiểu trình của đều bị hủy. Khi Aglet đến một host mới, phương thức onArrival được gọi và biến _theRemote được gán lại giá trị. Bây giờ Aglet sẽ phục hồi lại tại host đó cho đến khi nó được giải phóng (dispose). public class DispatchingExample extends Aglet { boolean _theRemote = false; public void onCreation(Object o) { addMobilityListener(new MobilityAdapter() { public void onDispatching(MobilityEvent e) { // Print to the console... } Trang 64

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

public void onArrival(MobilityEvent e) { _theRemote = true; //-- Yes, I am the remote aglet. // Print to the console... } }); } public void run() { if (!_theRemote) { // The original aglet runs here try { dispatch(destination); // You should never get here! } catch (Exception e) { System.out.println(e.getMessage()); } } else { // The remote aglet runs here... } } }

4.2.2. AgletProxy Interface AgletProxy Interface hành vi như một “cánh tay” của Aglet và cung cấp một phương pháp chung của việc truy xuất phía sau Aglet. Một Aglet có nhiều phương thức “public”, nhưng không nên được truy xuất trực tiếp từ các Aglet khác vì lý do bảo mật, bất kỳ một Aglet mà nó muốn kết nối một Aglet khác đầu tiên phải có một Proxy, và sau đó thông qua Interface này. AgletProxy hành động như một sự che chở cho các đối tượng, bảo vệ Aglet tránh sự nguy hiểm từ những Aglet khác.

Trang 65

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Một vai trò quan trong khác của AgletProxy Interface là cung cấp cho Aglet một vị trí rõ ràng. Nếu Aglet hiện hành đang ở tại một host từ xa thì Proxy forward sẽ yêu cầu host từ xa và gửi trả kết quả tới host cục bộ. Tạo một Aglet là một phương thức để lấy một proxy. Phương thức AgletContext.createAglet sẽ trả về proxy của một Aglet mới tạo. Một số phương thức khác bao gồm: AgletContext.retractAglet, AgletContext.activateAglet, AgletProxy.clone, AgletProxy.dispatch,

AgletContext.getAgletProxies,

AgletContext.getAgletProxy,

AgletContext.setProperty… 4.2.3. AgletContext Interface Một Aglet trải chu trình sống trong một Context của nó. Nó được tạo ra trong đó rồi cũng hủy trong đó. Khi nó di chuyển trên mạng, thực ra nó di chuyển từ Context này sang Context khác. Nói cách khác Context là một môi trường thực thi cho Aglet. AgletContext Interface thì được dùng bởi một Aglet để lấy thông tin về môi trường và gửi thông điệp tới môi trường, bao gồm những Aglet khác hoạt động trong môi trường thực thi hiện. Nó cung cấp các phương thức cho việc duy trì và quản lý việc chạy của các Aglet trong một môi trường, ở đó host được bảo vệ chống lại các Agent nguy hiểm. IBM’s Aglets Workbench cung cấp môt giao diện người sử dụng đồ họa. Nó là được gọi là Tahiti và người dùng có thể tạo, tạo bản sao, tạm nghỉ/hoạt động lại (deactivate/activate), hủy, gửi thông điệp và thu hồi Aglet. Tahiti cho phép người dùng theo dõi Aglet chạy trong Context cục bộ. Tahiti là một ứng dụng cơ bản xây dựng trên Aglet API.

Trang 66

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 4.3 4.2.4. Message Class Aglets liên lạc bằng cách trao đổi những đối tượng của lớp Message. Khi một đối tượng (object) Message được tạo, chúng ta có thể gửi chúng đến một Aglet bằng một trong các phương thức được định nghĩa trong lớp AgletProxy: - Object sendMessage(Message msg) - FutureReply sendFutureMessage(Message msg) - void sendOnewayMessage(Message msg)

4.3. Giới thiệu về ATP (Agent Transfer Protocol) Mobile Agent là những chương trình có khả năng vận chuyển đến các máy ở xa để mang theo những nhiệm vụ thay mặt cho những người sử dụng chúng. ATP là một giao thức ở lớp ứng dụng cho hệ thống Agent phân tán. Nó có thể được dùng để vận chuyển các Mobile Agent giữa các máy tính trong mạng. 4.3.1. Mục đích của ATP Một Agent là một chương trình mang theo những hoạt động thay mặt cho người dùng. Nó làm như vậy với một mức độ tự trị nào đó để thỏa mãn mục đích của người sử

Trang 67

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

dụng nó. Mobile Agent có khả năng di chuyển trên mạng trong khi vẫn duy trì được trạng thái của nó, và lấy lại quyền thực thi trên host đích. ATP cho phép một giao thức đơn giản và độc lập Platform để vận chuyển các Agent giữa những máy tính trong mạng. ATP tạo cơ hội để vận dụng tính di động của Agent theo cách chung nhất:  Một máy chứa Agent sẽ có một dịch vụ Agent ATP cơ sở để cung cấp khả năng gửi và nhận những Agent từ các máy Remote theo giao thức ATP. Dịch vụ Agent được nhận biết bởi một địa chỉ duy nhất độc lập với Platforms được hỗ trợ bởi máy. Một máy có thể chạy nhiều dịch vụ Agent.  Một máy có thể chứa nhiều loại Agent khác nhau, nó có khả nănng hỗ trợ các Agent Platform tương ứng.  Bất kỳ một Agent Platform nào cũng nên vận dụng giao thức truyền thông điệp của ATP.  Một thông điệp của ATP mang theo những thông tin đầy đủ để nhận ra Agent Platform đặc biệt (tại máy nhận) và gọi đến giao thức điều khiển ATP để nhận thông điệp.

Hình 4.4

Trang 68

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 4.4 là ví dụ về một máy chứa Agent hỗ trợ hai Agent Platform (vendor A và vendor B) và một dịch vụ Agent ATP cơ sở được nhận biết bởi một địa chỉ duy nhất (atp://john.doe.com). 4.3.2. Tầm vực của ATP Giao thức ATP cho phép các dịch vụ Agent trên Internet hỗ trợ tính di động của Agent, thậm chí nếu những Agent này dựa trên nhiều loại Platform nhiều nguồn khác nhau và được hỗ trợ bởi nhiều ngôn ngữ lập trình khác nhau. Khu vực được bao phủ bởi ATP là: - Tên của dịch vụ Agent - Bộ nhận biết Agent - Sự vận chuyển Agent 4.3.3. Một số thuật ngữ - Connection. Một lớp vận chuyển được hình thành giữa hai chương trình nhằm mục đích liên kết. - Message. Đơn vị cơ bản của giao thức truyền thông tin ATP bao gồm một luồng byte có cú pháp nhất định được truyền qua một Connection. - Request. Thông điệp yêu cầu của ATP. - Reponse. Thông điệp hồi đáp của ATP. - Sender. Vai trò của ứng dụng hình thành kết nối nhằm mục đích gửi yêu cầu. - Recipient. Vai trò của ứng dụng chấp nhận kết nối để dịch vụ yêu cầu và gởi lại thông điệp hồi đáp. - Agent Service. Một hệ thống có khả năng hoạt động với cả hai bên Sender và Recipient của Agent. - Proxy. Một dịch vụ trung gian làm việc với cả Sender và Recipient với mục đích thực hiện những yêu cầu thay mặt cho Sender. 4.3.4. Toàn bộ quá trình hoạt động

Trang 69

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Giao thức ATP dựa trên mô hình Request/Response giữa các Agent Service (AS). Một AS A hình thành kết nối với AS B sau đó gửi Request tới B và chờ Reponse. Như vậy A hoạt động giống như một Sender và B hoạt động như một Recipient. Một Request bao gồm một dòng yêu cầu, chỉ rõ phương thức yêu cầu, phiên bản của giao thức và tài nguyên yêu cầu. Một Request theo sau bởi thông điệp chứa đựng các yêu cầu, thông tin của Sender, và nội dung chi tiết. Một Response bao gồm một dòng trạng thái, chỉ rõ mã thành công hoặc mã lỗi và phiên bản của giao thức. Một Response theo sau bởi thông điệp chứa đựng các hồi đáp, thông tin của Sender và nội dung chi tiết. ATP định nghĩa bốn phương thức Request chuẩn cho AS: -

Dispatch (gởi đi).

-

Retract (thu hồi).

-

Fetch (tìm về).

-

Message (thông điệp).

4.3.4.1. Dispatch một Agent Để dispatch một Agent từ một dịch vụ Agent A đến một dịch vụ Agent B, A chỉ cần gửi một yêu cầu dispatch đến B. Agent chứa trong nó thông điệp Request. Khi B nhận được Agent, nó sẽ trả lời cho A một thông điệp Response chứa một mã trạng thái. 4.3.4.2. Retract một Agent Để thu hồi một Agent từ dịch vụ Agent B về dịch vụ Agent A. A chỉ cần gửi thông điệp yêu cầu retract đến B. B sẽ trả về một Reponse với mã trạng thái và nội dụng của Agent. 4.3.4.3. Tìm về lớp (Fetch the Class) Để thi hành một Agent, dịch vụ Agent B cần lấy lại mã code từ Agent gốc (dịch vụ Agent A). Để làm điều đó B gửi yêu cầu fetch đến A. A sẽ trả lời một Reponse với một mã trạng thái và mã thực thi được yêu cầu. 4.3.4.4. Gửi một thông điệp (Send a message)

Trang 70

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Để gửi một thông điệp từ dịch vụ Agent A đến một Agent trong hệ thống Agent B, A gửi một yêu cầu message chứa thông tin cần gửi. B sẽ trả lời một Reponse với một mã trạng thái.

KẾT LUẬN Trong chương này chúng tôi đã giới thiệu những nét cơ bản về thế giới Mobile Agent. Đặc biệt, chúng tôi đã giới thiệu sơ lược về bản chất của Aglet API và mô hình lập trình cơ bản của nó. Mô hình lập trình dựa trên sự kiện của Aglet nhấn mạnh sự ủy quyền và khả năng dùng lại của các thành phần như bộ lắng nghe sự kiện (listener), một công cụ định nghĩa một cách hiệu quả các hành vi của các Agent. Những đoạn mã lệnh (code) được nêu ra để chứng tỏ cho người đọc rằng không có điều gì khó hiểu về việc lập trình Mobile Agent bằng ngôn ngữ Java. Dự án về Aglet là một dự án được nghiên cứu thành công, thậm chí nó còn vượt quá trí tưởng tượng của chúng ta. Chúng tôi tin chắc rằng toàn bộ các lĩnh vực khác của Mobile Agent sẽ tiếp tục là đề tài hấp dẫn và thú vị trong những năm tiếp theo. Căn cứ vào những kết quả nghiên cứu Java Aglet trong chương này, cũng như sau khi đã hiểu rõ về Mobile Agent, chương sau chúng tôi sẽ triển khai viết ứng dụng minh họa cho những kết quả nghiên cứu lý thuyết đạt được.

Trang 71

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Chương 5: XÂY DỰNG ỨNG DỤNG ĐỊNH THỜI GIAN BIỂU CHO CUỘC HỌP TÓM TẮT Trên cơ sở những kết quả nghiên cứu lý thuyết về Mobile Agent, phần này chúng tôi sẽ trình bày ứng dụng minh họa hiện thực các kết quả trên. Điểm mạnh của Mobile Agent là triển khai trên ứng dụng phân tán với khả năng làm giảm tải mạng, giải quyết vấn đề không đồng bộ… Ứng dụng mà luận văn này cài đặt mang tên “Định thời gian biểu cho cuộc họp” (Distributed Meeting Schedulling). Ứng dụng sẽ triển khai các mẫu thiết kế đã giới thiệu ở chương 3: Master – Slave và Itinerary.

5.1. Giới thiệu Ứng dụng được xây dựng cho hệ thống lập lịch phân tán tại một công ty, giúp cho các thành viên trong một công ty có thể quản lý được thời gian biểu của riêng mình, đồng thời có thể chủ động đề nghị một cuộc họp khi cần thiết thông qua ứng dụng, tránh được sự đụng độ lịch công tác giữa các thành viên trong công ty. Ứng dụng cung cấp chức năng đàm phán trực tiếp, giúp cho người tổ chức cuộc họp có thể điều chỉnh lại lịch họp cho phù hợp. Ứng dụng này sẽ được cài đặt tại các nốt mạng trong công ty, giành cho các thành viên có thẩm quyền tổ chức và đề nghị cuộc họp. Tất cả những người sử dụng chương trình này đều phải có quyền ngang nhau. Nghĩa là ứng dụng này không giải quyết bài toán về độ ưu tiên và tính chất quan trọng của những người tham gia cuộc họp. Mục của ứng dụng này là hiện thực những gì đã nghiên cứu được từ lý thuyết bằng việc sử dụng các mẫu thiết kế đặc trưng cho Mobile Agent trên nền Java Aglet. Việc lập lịch một cuộc họp diễn ra theo kiểu phân tán và không đồng nhất thật sự vì không có một hệ thống lịch trung tâm.

Trang 72

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Nhiều Client di động có thể tổ chức những cuộc họp theo kiểu này vì không nhất thiết tất cả những người tham gia cần thiết để được kết nối vào mạng cùng một lúc.

5.2. Các chức năng chính Chương trình sẽ dùng hệ quản trị dữ liệu SQL Server để lưu các thông tin về lịch họp cá nhân cũng như thông tin thu thập được từ trên mạng. 5.2.1. Chức năng lập lịch tại máy cục bộ Mỗi Agent được gán cho một người dùng trong mạng và mỗi người dùng sẽ thường xuyên tự định thời gian biểu tại máy tính của mình.

Hình 5.1 5.2.2. Chức năng quản lý danh sách người dùng trong mạng Chức năng này cho phép người dùng cập nhật danh sách người dùng trong mạng để phục vụ cho chức năng lập lịch phân tán (sẽ trình bày trong phần sau). 5.2.3. Chức năng lập lịch phân tán Khi một thành viên nào đó muốn tổ chức một cuộc họp, tùy vào tính chất quan trong của cuộc họp, thành viên đó có thể chọn thời gian họp phù hợp dựa vào việc thu thập thông tin hay đàm phán trực tiếp.

Trang 73

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

5.2.3.1. Thu thập thông tin Đối với các cuộc họp không khẩn cấp, người tổ chức cuộc họp có thể sử dụng chức năng này để quyết định thời gian họp thích hợp nhất. Agent chủ (Master) sẽ phái một Agent tớ (Slave) đi đến lần lượt các máy tính của những thành viên khác trong mạng làm nhiệm vụ thu thập thông tin. Agent tớ này sẽ đi theo thứ tự của một hành trình (Itinerary) được người sử dụng cung cấp. Agent chủ sẽ quy định khoảng thời gian mà Agent tớ cần lấy thông tin. Dựa vào thông tin mà các thành viên đã lập lịch (chức năng lập lịch lại máy cục bộ), Agent tớ sẽ lấy thông tin cá nhân của từng thành viên trong khoảng thời gian mà nó được giao phó. Sau khi đi hết hành trình, Agent tớ sẽ gửi báo cáo về những gì mà nó thu thập được về cho Master, khi đó Master (người mời họp) sẽ ra quyết định và chọn ra thời gian họp phù hợp.

Hình 5.2 Sau đây chúng tôi sẽ trình bày chi tiết về cách tổ chức thông tin của Agent tớ (Thuật toán khe thời gian). Trang 74

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Ý tưởng về thuật toán khe thời gian như sau Khi đến mỗi máy Agent tớ sẽ dùng câu lệnh select để lấy dữ liệu từ cơ sở dữ liệu, dữ liệu lấy được từ câu lệnh select có thể có nhiều dòng (record), mỗi record sẽ tương ứng với một cuộc họp của người dùng tại máy đó. Ở đây, trên mỗi record, Agent tớ chỉ quan tâm đến giá trị ngày và khoảng thời gian mà thành viên tại máy này bận công việc. Agent tớ sẽ dùng một mảng các ngày, và một mảng các khe thời gian (kiểu int ) để lưu trữ. Mỗi ngày sẽ có một khe thời gian tương ứng từ 0 giờ đến 23 giờ. Mỗi khe thời gian ban đầu khởi tạo giá trị là 0, nghĩa là không có ai bận công việc trong thời điểm đó. Agent sẽ duyệt lần lượt các record, kiểm tra ngày trong record đó đã tồn tại trong mảng danh sách mà nó quản lý chưa. Nếu có rồi, Agent tớ chỉ việc cập nhật khe thời gian. Giả sử trong ngày đó thành viên tại máy đó phải họp từ 8 giờ đến 9 giờ, thì hai khe thời gian thứ 8 và thứ 9 sẽ được tăng lên một đơn vị. Nếu ngày của record đó chưa có trong danh sách ngày mà Agent tớ quản lý thì Agent tớ sẽ thêm ngày đó vào danh sách và cập nhật khe thời gian. 5.2.3.2. Đàm phán Đối với các cuộc họp khẩn cấp, người tổ chức cuộc họp có thể đàm phán trực tiếp với những thành viên khác. Agent chủ sẽ dùng một hành trình (Itinerary) để lưu các địa chỉ đích của những thành viên khác. Sau khi soạn thảo xong nội dung của thư mời họp, Agent chủ khởi tạo các Agent tớ và gửi (dispatch) chúng đến các máy có địa chỉ như trong hành trình. Các Agent tớ có nhiệm vụ thu thập ý kiến của những thành viên được mời họp sau đó thông báo lại cho Agent chủ. Agent chủ làm nhiệm vụ tổng hợp tất cả những thông tin nhận được từ các Agent tớ mà nó đã ủy thác để quyết định thời gian và địa điểm cụ thể mà những thành viên có thể tham gia. Sau đó gửi thư mời chính thức đến những thành viên đó. Trong chức năng này, chúng tôi cũng sử dụng mô hình Master – Slave, nhưng khác với chức năng thu thập thông tin là ở đây một Agent chủ sẽ phái nhiều Agent tớ đi tại một thời điểm, mỗi Agent tớ sẽ đến và trao đổi thông tin một thành viên khác. Chính Agent chủ sẽ nắm lịch trình đi của các Agent tớ.

Trang 75

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 5.3

Trang 76

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

5.3. Kết quả minh họa ứng dụng

Hình 5.4 Màn hình chính của chương trình

Trang 77

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 5.5 Màn hình xử lý chức năng thu thập thông tin và đàm phán

Trang 78

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 5.6 Màn hình xử lý chức năng quản lý danh sách người dùng trong mạng

Trang 79

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 5.6 Màn hình xử lý chức năng lập lịch tại máy cục bộ.

KẾT LUẬN Việc xây dựng các ứng dụng trên Mobile Agent có nhiều điểm khác so với ứng dụng thông thường. Bằng cách sử dụng các mẫu thiết kế Master – Slave và Itinerary, việc thiết kế các ứng dụng sẽ trở nên dễ dàng cho việc đóng gói từng phần riêng biệt đặc trưng cho Mobile Agent. Nhìn chung ứng dụng này đã khai thác được mô hình Mobile Agent trên nền Java Aglet. Mặc dù ứng dụng chưa được đưa vào sử dụng trên thực tế, thiếu tính xác thực nhưng ứng dụng đã chứng tỏ được tiềm năng và sức mạnh của Mobile Agent trong lập trình phân tán.

Trang 80

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Chương 6: CẤU HÌNH HOÀN CHỈNH ỨNG DỤNG Một chương trình ứng dụng của Mobile Agent sử dụng Java Aglet muốn thực thi phải có môi trường hỗ trợ JDK và Server Tahiti hỗ trợ giao thức ATP.

6.1. Cài đặt Aglet-2.0.2 (Server Tahiti) - Tạo biến môi trường JAVA_HOME chỉ đến thư mục cài đặt JDK

Hình 6.1 - Giải nén tập tin Aglets-2.0.2.jar - Trên màn hình Command Line, chuyển đến thư mục \Aglets-2.0.2\bin - Chạy lệnh ant.bat install-home để cài đặt Aglet

Hình 6.2 -

Để

chạy

Aglet

theo

cấu

hình

agletsd -f ..\cnf\aglets.props

Hình 6.3

Trang 81

mặc

định,

ta

dùng

lệnh:

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 6.4

6.2. Hoàn chỉnh ứng dụng - Copy thư mục DMSA trong \SETUP vào thư mục \Aglets-2.0.2\public. - Trong màn hình CommandLine chạy dòng lệnh: C:\aglets-2.0.2\bin>agletsd -f ..\cnf\aglets.props ta sẽ được màn hình như hình 6.5.

Trang 82

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Hình 6.5 - Trên của sổ Tahiti click chuột vào nút Create. Xuất hiện của sổ, chọn (gõ) tên ứng dụng.

Hình 6.6

Trang 83

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Chương 7: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 7.1. Kết luận Trong các chương trước chúng tôi đã trình bày toàn bộ quá trình nghiên cứu của mình trong lĩnh vực Mobile Agent từ việc nghiên cứu lý thuyết đến việc triển khai ứng dụng. Nhìn chung chúng tôi đã cơ bản đáp ứng về yêu cầu đề tài đặt ra.  Yêu cầu về lý thuyết: - Tìm hiểu các mô hình của ứng dụng phân tán. - Tìm hiểu sâu về mô hình tính toán phân tán Mobile Agents. - Khai thác chuẩn Java Aglet của IBM.  Yêu cầu về chương trình: - Xây dựng một ứng dụng phân tán minh họa theo mô hình Mobile Agents như: truy xuất nhiều Cơ Sở Dữ Liệu, định thời biểu meeting phân tán - Ngôn ngữ lập trình: Java. Tuy nhiên, chúng tôi vẫn còn một số khó khăn trong việc chọn và tìm ra loại ứng dụng phù hợp cho mô hình Moblile Agent. Ứng dụng “Định thời gian biểu cho cuộc họp” chỉ mang tính minh họa cho những kết quả nghiên cứu từ lý thuyết.

7.2. Hướng phát triển Về mặt lý thuyết công nghệ Mobile Agent không chỉ dừng lại tại đây mà còn sẽ được phát triển nhiều hơn thế nữa. Với lợi thế phát triển ứng dụng trên ngôn ngữ Java, mã nguồn mở, độc lập hệ điều hành, Mobile Agent là một ứng cử viên sáng giá cho những người phát triển ngôn ngữ lập trình Java cũng như những người thích yêu thích sự tìm tòi và sáng tạo. Lĩnh vực Mobile Agent thì vô cùng rộng lớn, với tiềm năng sẵn có và những hạn chế của các mô hình lập trình phân tán cũ, Mobile Agent cần được đầu tư và phát triển nghiêm túc. Việc lựa chọn và tìm ra ứng dụng phù hợp cho mô hình Mobile Agent cũng Trang 84

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

là một vấn đề cần quan tâm không chỉ của nhóm nghiên cứu chúng tôi, mà của tất cả những ai quan tâm đến lĩnh vực này. Bằng cách khắc phục những nhược điểm của Mobile Agent (cơ chế an toàn bảo mật…), nhất định trong một tương lai không xa, Mobile Agent sẽ trở thành một kỹ thuật được chấp nhận rộng rãi trong thực tế. Việc nghiên cứu và phát triển Mobile Agent trên nền Java Aglet vẫn còn rất nhiều vấn đề tồn đọng cần phải giải quyết. Do đó muốn phát huy tìm năng của Mobile Agent, đòi hỏi những người nghiên cứu phải không ngừng củng cố kiến thức về Mobile Agent, đồng thời phải biết khai thác tối đa những gì mà Java Aglet mang lại.

Trang 85

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

TÀI LIỆU THAM KHẢO  

[1] http://www.trl.ibm.com/aglets/ [2] http://sourceforge.net/projects/aglets/ [3] M. L. Liu, Distributed Computing Concepts and Applications, Addision Wesley, 2003 (Book Online) [4] Mobile Agent with Java: The Aglet API (eBook) [5] Mobile Agent: New Model of Intelligent Distributed Computing (eBook) [6] Mobile Agent: Mobile Agent Security (eBook)

Trang 86

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

PHỤ LỤC

Trang 87

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Phụ lục 1: Quy trình tổ chức thu thập thông tin và gửi thư mời hợp Giao diện cho phép Agent chủ cấu hình thuộc tính về khoảng thời gian truy xuất dữ liệu và hành trình di chuyển cho Agent tớ để Agent tớ thực hiện nhiệm vụ thu thập thông tin.

Trang 88

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Giao diện cho phép Agent chủ xem kết quả mà Agent tớ sau khi thu thập thông tin gửi gửi trả về cho Master.

Sau đây là một ví dụ về các khe thời gian trong một ngày của tất cả các thành viên mà Agent tớ thu thập được:

Trang 89

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Sau khi Agent chủ đã xem xét, lúc đó người dùng có thể tiến hành mời họp, quá trình như sau:

Nhấn Next để tiếp tục và điền đầy đủ thông tin về ngày và giờ mời họp:

Trang 90

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Nhấn Next để tiếp tục và điền đầy đủ thông tin về chủ đề cuộc họp, nơi họp…

Nhấn Next và tổ chức hành trình để Agent đến gửi thư mời.

Nhấn nút Send để tiến hành gửi thư mời.

Trang 91

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Phụ lục 2: Quy trình tổ chức lập lịch tại máy cục bộ

Nhấn Next để tiếp tục điền thông tin về ngày và giờ họp

Trang 92

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Nhấn Next để điền đầy đủ thông tin về cuộc họp

Cuối cùng nhấn nút Finish để hoàn tất để hoàn tất quá trình lập lịch. Sau khi đã lập lịch, người dùng có thể xem lại và chỉnh sửa những thông tin này khi cần thiết

Trang 93

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Phụ lục 3: Quy trình tổ chức đàm phán

Nhấn nút Make new Negotiation để điền đầy đủ thông tin cần thiết

Nhấn nút Send để bắt đầu gửi thư đàm phán.

Trang 94

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Sau khi nhấn nút Send, bên nhận sẽ nhận chương trình sẽ đầy một Agent sang bên nhận với giao diện như sau:

Nhấn View negotiation để xem thông tin đàm phán

Trang 95

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Bên nhận tiến hành lựa chọn thích hợp và trả lời lại cho bên gửi biết bằng cách nhấn Submit. Sau đó bên nhận có thể check vào bảng sau để cập nhật lại thông tin làm việc của mình cho bên gửi.

Nhấn Submit gửi cho người mời họp. Sau đây là màn hình kết quả đàm phán từ phía tổ chức đàm phán:

Trang 96

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Dựa trên những thôi tin thu thập từ màn hình trên, bên tổ chức đàm phán có thể gửi thư mời bằng cách chọn ngày giờ từ Combobox phía dưới màn hình. Sau đó nhấn Submit để gửi thư mời Lúc này bên nhận sẽ nhận được thư mời với nội dung như sau:

Trang 97

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

Phụ lục 4: Một số mã code tiêu biểu package DMSA; import com.ibm.aglet.*; import com.ibm.aglet.util.*; import java.util.Vector; import java.util.Enumeration; import java.awt.*; import java.awt.event.*; import java.net.*; import javax.swing.*; import java.sql.*; public class MasterDMSAglet extends Aglet { String fromdate; String todate; String datastr; AgletProxy slaveProxy = null ; MasterFrame masterframe = null; MessageBox msgBox = null; public com.ibm.agletx.util.SeqPlanItinerary itinerary; transient AgletProxy[] remoteProxy; public void dispatchSlave(String dest,int i) { try { AgletContext context = getAgletContext(); AgletProxy proxy = context.createAglet(null, "DMSA.Meeting_Invitation_Aglet", getProxy()); URL url = new URL(dest); remoteProxy[i] = proxy.dispatch(url); } catch (InvalidAgletException ex) { ex.printStackTrace(); } catch (Exception ex) { Trang 98

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

ex.printStackTrace(); } } public void createSlave() { try { AgletContext context = getAgletContext(); AgletProxy proxy = context.createAglet(null, DMSA.SlaveDMSAglet", getProxy()); slaveProxy = proxy; } catch (InvalidAgletException ex) { ex.printStackTrace(); } catch (Exception ex) { ex.printStackTrace(); } } public void createSlaveNegotiate() { try { AgletContext context = getAgletContext(); AgletProxy proxy = context.createAglet(null, "DMSA.Negotiate_MasterDMSAglet", getProxy()); slaveProxy = proxy; } catch (InvalidAgletException ex) { ex.printStackTrace(); } catch (Exception ex) { ex.printStackTrace(); } } public void onDisposing() { if (masterframe != null) { Trang 99

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

masterframe.dispose(); masterframe = null; } for (int i=0;i
GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

this.fromdate = (String)msg.getArg(); } if(msg.sameKind("To date")){ this.todate = (String)msg.getArg(); } if(msg.sameKind("Server is not found")){ this.todate = (String)msg.getArg(); } if(msg.sameKind("sendData")){ datastr = (String)msg.getArg(); saveInfo(); JOptionPane.showMessageDialog(this.masterframe,"The mobile agent completed it's itinery. The information has been collected."); return true; } if(msg.sameKind("Arrive")){ String add = (String)msg.getArg(); System.out.println("I arrived: "+add); return true; } return false; } public void saveInfo(){ connectData cd = new connectData(); Connection con; Statement stmt; String queryString; ResultSet rs; try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Trang 101

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

} catch(java.lang.ClassNotFoundException e) { System.err.print("ClassNotFoundException: "); System.err.println(e.getMessage()); } queryString = "exec AddMAInfo '"+this.fromdate+"','"+this.todate+"','"+this.datastr+"'"; try { con = DriverManager.getConnection(cd.getUrl(), cd.getUsername(), cd.getPassword()); stmt = con.createStatement(); stmt.executeUpdate(queryString); stmt.close(); con.close(); } catch(SQLException ex) { System.err.println("SQLException: " + ex.getMessage()); } } public void sendText(String str,String text){ try { if (slaveProxy == null) { return; } slaveProxy.sendMessage(new Message(str,text)); } catch (Exception ex) {} } public void sendMeetingInvitation(String msg, String str,int i){ try { if (remoteProxy[i] == null) { return; } Trang 102

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

remoteProxy[i].sendMessage(new Message(msg,str)); } catch (Exception ex) { ex.printStackTrace(); } } public void onCreation(Object ini) { masterframe.setDefaultLookAndFeelDecorated(true); masterframe = new MasterFrame(this); itinerary = new com.ibm.agletx.util.SeqPlanItinerary(this); LoadDataBasetoIntinery(); remoteProxy = new AgletProxy[100]; } public void LoadDataBasetoIntinery(){ Connection con; Statement stmt; String queryString1; ResultSet rs; connectData cd = new connectData(); try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); } catch(java.lang.ClassNotFoundException e) { System.err.print("ClassNotFoundException: "); System.err.println(e.getMessage()); } queryString1 = "Select * from Participant"; try { con = DriverManager.getConnection(cd.getUrl(), cd.getUsername(), cd.getPassword()); stmt = con.createStatement(); Trang 103

GVHD: Thầy Lê Quốc Tuấn

SVTH: Nguyễn Tuấn Tài – Hà Thị Bạch Yến

rs = stmt.executeQuery(queryString1); String address, name, id; while(rs.next()){ address = rs.getString(2); itinerary.addPlan(address,(String)"Meeting Invitaion"); } stmt.close(); con.close(); } catch(SQLException ex) { System.err.println("SQLException: " + ex.getMessage()); } } }

Trang 104