Nghiên cứu và phát triển phương pháp quản lý, môi giới tài nguyên trên lưới dựa trên phần mềm agent based software

Đề tài này sẽ giới thiệu tổng quan về mô hình tác nhân phần mềm, sự tương tác, thương lượng giữa các agent để thực thi một yêu cầu công việc của người dùng và phương pháp thương lượng để

2

CÔNG TRÌNH ĐƯỢC HOÀN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH

Cán b ộ hướng dẫn khoa học :TS THOẠI NAM

Cán b ộ chấm nhận xét 1 :

Cán b ộ chấm nhận xét 2 :

Lu ận văn thạc sĩ được bảo vệ tại HỘI ĐỒNG CHẤM BẢO VỆ LUẬN VĂN THẠC SĨ TRƯỜNG ĐẠI HỌC BÁCH KHOA, ngày tháng năm 2009

3

Tôi xin cam đoan rằng, ngoại trừ các kết quả tham khảo từ các công trình khác như đã ghi rõ trong lu ận văn, các công việc trình bày trong luận văn này là do chính tôi th ực hiện và chưa có phần nội dung nào của luận văn này được nộp để lấy một bằng cấp ở trường này hoặc trường khác

Ngày 30 tháng 11 năm 2008

Võ H ồng Kiệt

4

Trãi qua th ời gian để hoàn thành đề tài này mặc dù gặp không ít khó khăn khi nghiên cứu và phát tri ển, nhưng qua đó đã mang lại cho em nhiều kiến thức bổ ích, tích lũy nhiều kinh nghiệm quý báo đồng thời nâng cao sự hiểu biết của em trong lĩnh v ực tính toán lưới nói chung và phương pháp quản lý và môi giới tài nguyên trên môi trường tính toán lưới nói riêng

Em xin chân thành cám ơn các Thầy, Cô trong trường Đại học Bách Khoa Tp Hồ Chí Minh và đặc biệt là các thầy cô trong khoa Khoa học máy tính của trường đã tận tình truyền đạt kiến

th ức cho em trong suốt thời gian học tập, nguyên cứu tại trường

Đặc biệt em xin chân thành cám ơn TS Thoại Nam, người đã mở đường, định hướng, tạo mọi điều kiện thuận lợi và tận tình hướng dẫn em thực hiện đề tài này

Con luôn ghi nh ớ mọi sự hỗ trợ và động viên của ba, mẹ khi con học tập, nguyên cứu chuyên ngành Khoa h ọc máy tính và quá trình con thực hiện đề tài này

Tôi xin cám ơn tất cả những người thân, các anh chị em đồng nghiệp, bạn bè đã động viên giúp

đỡ tôi rất nhiều trong thời gian qua

Xin chân thành cám ơn!

5

Tính toán lưới, nhắm tới mục tiêu cho phép chia sẽ và cộng tác tài nguyên trên vi mô

rộng lớn, đang nổi lên là một phương pháp tính toán phân tán đầy hứa hẹn Đây là một môi trường cho phép các nhà cung cấp tài nguyên chia sẽ và cộng tác với những người

sử dụng tài nguyên

Để quản lý việc môi giới tài nguyên giữa nhà cung cấp và người sử dụng được hiệu

quả nhất đang là một thách thức lớn Mặc dù đã có r ất nhiều nguyên cứu về các phương pháp định thời khác nhau nhưng kết quả cho đến nay vẫn chưa thỏa mãn

Gần đây người ta đã đ ề nghị phương pháp tác nhân phần mềm (software agents) Phương pháp này dựa trên sự tương tác, thương lượng giữa các agent để cung cấp hạ tầng cơ sở cho việc quản lý và môi giới tài nguyên trên lưới

Đề tài này sẽ giới thiệu tổng quan về mô hình tác nhân phần mềm, sự tương tác, thương lượng giữa các agent để thực thi một yêu cầu công việc của người dùng và phương pháp thương lượng để gia nhập team gồm các nhà cung cấp tài nguyên

Giải pháp trong đề tài được phát triển từ giải pháp thương lượng giữa các agent để thực thi một yêu cầu công việc Trong đó chú trọng các yếu tố: quản lý chặt chẽ hơn các team cung cấp tài nguyên, chất lượng dịch vụ cung cấp tài nguyên tốt hơn và độ hài lòng của người sử dụng tài nguyên Kết quả thử nghiệm cho thấy kết quả rất khả quan của phương pháp cải tiến

6

ABSTRACT

Grid computing, which aims at enabling wide-area resource sharing and collaboration,

is emerging as a promising distributed computing paradigm It involves sharing and collaboration among resource providers and resource consumers

Efficient managing and brokering resources in Grids is a big challenge Unfortunately, the uptake of the Grid, while speeding-up recently, is still unsatisfactory

Recently, it was suggested that software agents can provide an infrastructure for resource brokering and management in Grids This agent –based approach is based on collaborations, negotiations among agents to provide framework for resource brokering and management in Grids

We overview the model of software agents, interactions, negotiations among agents to select the team that execute the user job Moreover, the procedure that helps workers selecting the team proposed

In this work, we introduce an extended negotiation solution for selecting the team execute the user job In this case, we pay special attentions to the features: more closely team management, better service of managing resources, more satisfied resource consumers The experiments show that the solution is quite nice

7

M ỤC LỤC

M ỤC HÌNH 9

ươ 1 GI ỚI THIỆU 12

ươ 2 QU ẢN LÝ VÀ MÔI GIỚI TÀI NGUYÊN TRÊN LƯỚI BẰNG MÔ HÌNH AGENT 14

.1 L ịch sử phát triển 14

.2 Mô hình Agent theo ph ương pháp thương lượng 15

.2.1 Các đội agent quảng cáo thông tin 16

.2.2 Ng ười sử dụng muốn đóng góp tài nguyên cho Grid 17

.2.3 Ng ười sử dụng có nhu cầu sử dụng tài nguyên của Grid 19

.2.4 Quan h ệ LMaster - LMirror 19

.2.5 Thu th ập thông tin để tích lũy tri thức về hoạt động môi giới tài nguyên bằng mô hình agent 21

.3 Ki ến trúc CIC 22

.3.1 T ương tác LAgent – CIC 22

.3.2 Hi ện thực CIC 26

.4 Các quy trình nghi ệp vụ 31

.4.1 Ch ọn đội agent để thực thi công việc 31

.4.1.1 D ữ liệu người dùng nhập vào 31

.4.1.2 Th ương lượng (Negotiations) 35

.4.1.3 Phân tích đa tiêu chuẩn (MCA) 39

.4.2 Ch ọn team để tham gia vào 39

.4.2.1.Ch ọn team để tham gia vào 42

.4.2.2 Th ương lượng 43

.4.2.3 Qu ản lý team 44

ươ 3 MÔ HÌNH CH ỌN ĐỘI AGENT ĐỂ THỰC THI CÔNG VIỆC CẢI TIẾN 46

.1 Nh ững khuyết điểm của mô hình chọn đội Agent để thực thi công việc: 46

.2 Mô hình đề nghị cải tiến 47

ươ 4: TH Ử NGHIỆM VÀ ĐÁNH GIÁ 50

.1 K ịch bản 1: User chọn team để thực thi công việc (9 team và 9 worker) .50

.2 K ịch bản 2: Worker chọn team để join vào .57

8

.3 K ịch bản 3: User chọn team để thực thi công việc (45 team và 45 worker) .62

.4 K ịch bản 4: Kịch bản cho giải thuật cũ .71

.5 Đánh giá .72

ươ 5 K ẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 74

ươ 6 TÀI LI ỆU THAM KHẢO 75

9

ình 1: S ơ đồ Use Case của hệ ố .16

ình 2: User giao ti ếp với Lagent định nghĩa các điều kiện và LAgent request CIC cung cấp các team th ỏa mãn yêu cầu của .18

ình 3: Giao ti ếp LAgent và LMaster để tìm một team gia nhập vào / tìm team thực thi một yêu cầu công ệ .19

ình 4: Giao ti ếp LMaster và .21

ình 5: Lu ồng thực thi Request/Result trong kiến trúc CIC đa phân ồ .27

ình 6: Lu ồng Request/Result trong kiến trúc CIC đa Agent phân án 27

ình 7: S ơ đồ tuần tự: CIC xử lý các yêu cầu dùng thêm một CICIA (CIC Internal Agent) .28

ình 8: So sánh gi ữa hai kiến trúc phân CIC phân luồng và đa .30

ình 9: S ơ đồ tương tác của giao thức FIPA Contract Net .36

ình 10: S ơ đồ tuần tự tương tác khi một agent tìm một team để gia nhập ào .41

ình 11: S ơ đồ tương tác User-CIC-Master cải ế .47

ình 12: S ơ đồ tuần tự tương tác User-CIC- .49

ình 13: Giao di ện JADE Container - 1 CICAgent, 1 CICInternalAgent, 3 CICDbAgent, 9 Master, 9 Worker và .52

ình 14: Giao di ện User đặc tả yêu tài ên .53

ình 15: Danh sách team th ỏa mãn yêu cầu CICAgent truy vấn trong .54

ình 16: Giao di ện cho phép User chọn team để thực thi công ệ .55

ì 17: Team s ẽ gởi kết quả công việc về cho .55

ình 18: User nh ận kết quả thực hiện công ệ .56

ình 19: Giao di ện cho .57

ình 20: Worker đặc tả khả năng tài nguyên của ình .58

ình 21: Worker l ấy được danh sách các team có thể cho gia nhập à .59

ình 22: Worker c ập nhật trạng thái sau khi gia nhập .60

10

ình 23: Giao di ện .61

ình 24: Giao di ện JADE Container - 1 CICAgent, 1 CICInternalAgent, 3 CICDbAgent, 45 Master, 45 Worker và .64

ình 25: T ất cả các Master đã thông báo sự hiện diện của mình khi mỗi Worker khi đăng ký vào 65

ình 26: Worker l ựa chọn một team để tham gia ào .66

ình 27: WorkerD đã là thành viên và là Mirror của MasterD vì nó là Worker đầu tiên tham gia ào .67

ình 28: Giao di ện và trạng thái của MasterD cũng được cập ậ .68

ình 29: User đặc tả tài nguyên yêu cầu và Submit lên cho .69

ình 30: CICAgent tr ả về cho User danh sách các team sẵn sàng cho nó lựa ọ .70

ình 31: User đã luậ chọn team F để thực thi công việc và sau khi thực thi team F đã thông báo kết qu ả công việc về cho .70

ình 32: User đã nhận được thông báo kết quả công ệ .71

ình 33: User đặc tả tài nguyên yêu cầu - Giải thuật ũ .71

ình 34: Gi ải thuật MCA đã tự động chọn team I3 để thực thi công việc và thông báo cho .72

ình 35: team I3 đã thực thi công việc và thông báo kết quả về cho .72

ình 36: User nh ận được thông báo kết quả công việc 72

11

CÁC THU ẬT NGỮ

Agent: Thực thể phần mềm biểu diễn các đối tượng tương tác trên lưới

Resource Provider: Nhà cung cấp tài nguyên trên lưới

Service Level Agreement: Hợp đồng dịch vụ tài nguyên giữa người sử dụng và nhà cung cấp

Contract Net Protocol: Giao thức thực hiện hợp đồng dịch vụ

YellowPages: Phương pháp mà các team đưa thông tin quảng cáo lên CIC

Team: Một nhóm các worker kết hợp thành Các worker muốn gia nhập team phải thỏa mãn các tiêu chuẩn do trưởng nhóp (Master) đưa ra

Master: Agent đứng đầu và quản lý một team

Worker: Thành viên của team

Mirror: Worker sẽ đảm nhiệm vai trò của trưởng nhóm khi trưởng nhóm bị down

CIC: Nơi các team đưa thông tin quảng cáo lên

User: Người có nhu cầu sử dụng tài nguyên

JADE: Java Agent DEvelopment Framework

12

Chương 1 GIỚI THIỆU

Tính toán lưới đang nổi lên như một phương pháp đầy hứa hẹn để tận dụng các nguồn tài nguyên tính toán phân tán về mặt địa lý, không đồng nhất Người ta mong chờ trừu tượng hóa tài nguyên tính toán thực hiện bởi tính toán lưới sẽ tạo ra một cơ sở hạ tầng tính toán mới trong đó bao gồm những nguồn tài nguyên sẵn sàng đáp ứng Và kết quả

đó sẽ ảnh hưởng sâu rộng đến các lĩnh vực khoa học, kinh doanh và các ngành công nghiệp Mặc dù gần đây nhiều công ty và các trường đại học đã đầu tư nghiên cứu rất nhiều nhưng kết quả đạt được vẫn chưa thỏa mãn Hạ tầng phần mềm hiện hành của Grid còn quá phức tạp trong việc quản lý tài nguyên

Người ta đề nghị một phương pháp sử dụng các tác nhân phần mềm (software agents) (SA) để cung cấp hạ tầng cần thiết cho Grid trong việc quản lý tài nguyên Nó có thể truyền cho Grid sự thông minh Trước đây đã có các giải pháp hiện thực SA vào trong Grid, nhưng hầu hết đều có những hạn chế:

- Phạm vi ứng dụng hẹp, ít chức năng

- Không đưa ra mô hình tiết kiệm tài nguyên

- Dựa dẫm vào tính di động của agent, không xem xét chi phí của nó- agent mang các tác vụ, kích thướt của agent phụ thuộc vào kích thước của code và dữ liệu vì

vậy tính di động của nó nên được sử dụng một cách sáng suốt

- Không thể hiện được bản chất linh động cao của Grid, để cho người dùng có thể

gặp nguy khi có sự thay đổi, giao động thất thường của tải trọng của các node

cũng như các node có thể thoát ẩn, thoát hiện mà không cảnh báo

- Không cung cấp phương pháp quản lý sự tin tưởng – rất cần thiết khi phải chọn

những nhà cung cấp tài nguyên mà không có kiến thức gì về họ

Để khắc phục những hạn chế này, đề tài giới thiệu một phương pháp dựa trên các đội tác nhân cộng tác lại với nhau cùng giải quyết bài toán quản lý và môi giới tài nguyên Trong đó các agent biểu diễn tài nguyên (resource provider) và những người sử dụng tài nguyên (cũng được biểu diễn bằng Agent) sẽ thương lượng một hợp đồng dịch vụ (Service Level Agreement) Việc thương lượng dựa trên giao thức Contract Net Protocol Tuy nhiên, sự giao tiếp, thương lượng giữa nhà cung cấp dịch vụ tài nguyên

và người sử dụng tài nguyên vẫn tồn tại những vấn đề:

- Chưa quản lý chặc chẽ được các team cung cấp dịch vụ tài nguyên

- Chất lượng dịch vụ cung cấp tài nguyên thấp Chỉ cung cấp các team thỏa mãn yêu cầu, chưa tính đến tính sẵn sàng của team cung cấp dịch vụ tài nguyên

13

- User không có quyền lựa chọn team cung cấp dịch vụ tài nguyên

Đề tài này đưa ra một mô hình thương lượng cải tiến giải quyết được những tồn tại trên đây

Phần còn lại của luận văn được tổ chức thành 5 chương Chương 3 trình bày chi tiết về

mô hình SA Tóm tắt những kết quả thí nghiệm để tìm ra một phương pháp hữu hiệu trong việc hiện thực dịch vụ yellowpage trong một hệ thống dựa trên agent Mô hình này đảm bảo dịch vụ yellowpage chạy thông suốt tránh tình trạng nút thắt cổ chai Mô hình tổng thể của một hệ thống dựa trên agent cũng được trình bày Tiếp đó trình bày cách các agent thương lượng để tìm ra một team thực thi công việc của nó Phần cuối cùng của chương này bàn về cách quản lý thành viên trong một agent team Cách một worker thương lượng để join vào trong một team cũng được đề cập

Chương 4 phân tích những khuyết điểm của mô hình chọn team để thực thi công việc

đề xuất một mô hình ưu việt hơn, khắc phục được những nhược điểm của phương pháp cũ Phần thử nghiệm và đánh giá được trình bày trong chương 5 và cu ối cùng

phần kết luận và hướng phát triển được trình bày trong chương 6

hệ thống phần mềm lớn Với đề tài này, mục tiêu quan trọng là software agent sẽ đóng vai trò quan trọng hơn trong sự phát triển của Grid Trước đây đã có nh ững nguyên

cứu phát triển về software agent như sau:

1 Nghiên cứu đầu tiên trong việc áp dụng phương pháp agent trong Grid phải kể đến

là của J Cao và các đồng nghiệp J Cao và các đồng nghiệp kết hợp phương pháp PACE với một cấu trúc phân cấp dựa trên agent sử dụng để khám phá tài nguyên trên lưới [2] Công việc này chẳng đi đến đâu vì PACE đã bị lãng quên

2 Gần đây, B Di Martino và O Rana đã đề nghị phương pháp MAGDA (Mobile AGent Distributed Aplication) [6] Đã thiết kế ra một bộ kit agent để hỗ trợ:

a Khám phá tài nguyên (resource discovery)

b Giám sát hiệu suất và cân bằng tải (performance monitoring and load balancing)

c Thực thi công việc trên lưới

Phương pháp này dựa trên sự cộng tác của các agent, tuy nhiên nó lại không có mô hình cho phép tiết kiệm tài nguyên Đây là một hạn chế lớn vì mô hình Grid mà ta đang quan tâm cho phép các nhà cung cấp tài nguyên đặt tài nguyên của họ trên lưới và người ai muốn sử dụng phải trả phí

3 Xuất phát từ mô hình tiết kiệm tài nguyên, năm S.S Manvi và các đồng nghiệp đã

đề nghị tận dụng các agent di động quét qua mạng để hoàn thành một công việc do người dùng định nghĩa [13] Trong quá trình viếng thăm các node mạng các agent này sẽ xác minh các điều kiện cục bộ để thực thi công việc Nếu các điều kiện này (phải tính tới việc tiết kiệm) chấp nhận được các agent sẽ thực thi công việc ở đó (nếu không thì sẽ tiếp tục di chuyển qua node khác) Thật không may là phương pháp này có nguy cơ bị tổn thương cao bởi những sự kiện bất lợi - chẳng hạn khi

một node biến mất khi agent đang thực thi công việc ở đó

Cũng trong năm 2005, D Ouelhadj và các đồng nghiệp đã xem xét phương pháp thương lượng (hoặc thương lượng lại) một hợp đồng dịch vụ (Service Level

15

Agreement) giữa các agent biểu diễn tài nguyên (resource provider) và những người sử dụng tài nguyên [14] Việc thương lượng dựa trên giao thức Contract Net Protocol Phương pháp mà đề tài này quan tâm sẽ dựa theo ý tưởng này

2.2 Mô hình Agent theo phương pháp thương lượng

Trong mô hình này lư ới tính toán được xem là một môi trường mà ở đó có những worker (agent worker) muốn đóng góp tài nguyên của mình và những người sử dụng (agent user) muốn sử dụng tài nguyên thì phải trả công/ thù lao, nó đáp ứng và tương tác với những người sử dụng dịch vụ để hoàn thành công việc của họ

Ta thấy rằng một máy đơn có sức mạnh rất giới hạn, sự thành công của các ứng dụng

như SETI@home – đây là một dự án thí nghiệm khoa học tận dụng sức mạnh của các

máy tính kết nối mạng internet trong việc tìm kiếm trí thông minh ngoài trái đất (tham

khảo thêm trang web http://setiathome.berkeley.edu/) - dựa trên việc khai thác sức

mạnh của hàng triệu “home-PC’s”, ứng dụng này có bản chất đặc thù Ở đó một tài nguyên biến mất trong quá trình tính toán là không quan trọng, bất kỳ phần tử dữ liệu nào cũng có thể được xử lý tại bất kỳ thời điểm nào Hơn nữa, phần tử dữ liệu chưa được xử lý xong do PC biến mất (vanishing PC) có thể được hoàn thành trong tương lai bởi tài nguyên khác Tuy nhiên điều này không áp dụng cho những trường hợp ứng

dụng kiểu doanh nghiệp, ở đó sự tính toán phải được hoàn thành theo một thứ tự nhất định, trong một khung thời gian được định nghĩa rõ ràng Nói cách khác trong phần lớn các ứng dụng theo dạng hợp đồng dịch vụ (Service Level Agreement (SLA)), phải đảm

bảo liên quan đến các điều kiện hoàn thành công việc Đảm bảo một SLA như thế trong trường hợp một máy đơn “home-PC” là điều hầu như không thể Do đó, để giải quyết

vấn đề này, chúng ta giới thiệu những tổ chức ảo, gọi là agent team dựa trên những giả

định sau đây:

• Các agent làm việc trong các nhóm (team) (nhóm các agent)

• Mỗi team có một trưởng nhóm – LMaster agent

• Mỗi LMaster có một mirror LMirror agent có thể thay thế công việc của nó trong

16

• Quyết định về việc gia nhập hay chấp nhận (đối với User chấp nhận nhà cung

cấp tài nguyên thực thi công việc) liên quan đến việc phân tích nhiều tiêu chí

• Mỗi worker (nếu cần) có thể đóng vai trò là một LMaster (hoặc một LMirror)

• Tra cứu thông tin trên CIC được hỗ trợ bởi CICAgent

Kết hợp các giả định này, ta phát triển mô hình hệ thống được trình bày trong hình 1 –

sơ đồ Use Case

Request information/

Propositions

Proposition creation/update

Collaboration

Negotiation CIC

Mirror LMaster Recreation

LAgent MSDM

LMaster MCDM

Hình 1: S ơ đồ Use Case của hệ thống

2.2.1 Các đội agent quảng cáo thông tin

Ta thấy rằng, một đội agent phải được nhìn thấy bởi những user tiềm năng hoặc thành viên của team, nó phải đưa thông tin quảng cáo của team lên theo cách người khác có

thể tiếp cận một cách dễ dàng Có nhiều cách đưa thông tin được sử dụng trong việc

17

so trùng vào trong một hệ thống phân tán và mỗi cách có những ưu khuyết điểm riêng Trong trường hợp này, chúng ta sử dụng phương pháp kiểu yellow-page: các LMaster agent sẽ post những thông tin quảng cáo trong Client Information Center (CIC) Những thông tin quảng cáo như vậy chứa cả thông tin về các nguồn tài nguyên được cung cấp (phần cứng, phần mềm, giá cả…) và ‘team metadata’ (thí dụ: các điều kiện để gia nhập team (join), sự cung cấp (provisioning), đặc tả …) theo cách này yellow page có thể được sử dụng: (1) bởi user agent để tìm các tài nguyên thỏa mãn yêu cầu của họ và (2)

bởi worker agent tìm team đ ể join vào Chẳng hạn worker agent đại diện cho một máy tính có cài phần mềm Matlab, có thể muốn tham gia vào một team chuyên dùng Matlab

để giải quyết vấn đề

Bây giờ, chúng ta bắt đầu mô tả các tiến trình động được mô tả theo dạng tĩnh ở hình

1 Giả sử hệ thống đang chạy một thời gian vì vậy đã tồn tại những đội agent rồi và

những đội này sẽ “quảng cáo” (mô tả cả tài nguyên mà các agent này cung cấp và các agent mà chúng muốn join vào trong team của chúng) được post lên trong CIC Đầu tiên quan sát ta thấy : User được biểu diễn trong hình 1, có thể là một người nào đó

muốn đóng góp tài nguyên cho Grid hoặc ai đó muốn sử dụng tài nguyên do Grid cung cấp Sơ đồ Use Case chỉ ra cả hai tình huống có thể được mô hình theo cách “UML đối

xứng”

2.2.2 Ng ười sử dụng muốn đóng góp tài nguyên cho Grid

Ta bắt đầu từ trườg hợp “User muốn đóng góp tài nguyên” - “User-contributor” Hình 2 bên dưới được trích ra một phần từ hình 1 để chúng ta dễ nhìn

18

Request information/

Propositions

Definition Conditions

thể loại bỏ những team nhất định ra khỏi danh sách

Chẳng hạn, nếu nó làm việc với một team nào đó trong quá khứ và “không hạnh phúc” với “sự tưởng thưởng”, nó có thể không muốn làm việc với team đó nữa Đối với tất cả các team còn lại trong danh sách, LAgent giao tiếp với LMaster dùng giao thức FIPA dự trên sự điều đình (negotiation) và phân tích đa tiêu chí (multicritial analysis) – sẽ đề cập đến ở những phần sau để đánh giá các lời đề nghị nhận được Kết quả sự tương tác

giữa LAgent và LMaster có thể hai mặt: (1) nó sẽ tìm thấy một team mà nó sẽ muốn làm việc với và tham gia vào đó, (2) không tìm thấy team nào hết (hoặc nó không quan tâm đến bất kỳ lời đề nghị (offer) nào từ các LMaster hoặc không có LMaster nào gởi offer) Trong trường hợp này LAgent có thể quyết định bỏ qua công việc đó và thông báo cho User của nó Cũng có thể LAgent quyết định trở thành LMaster của một team

mới Trong trường hơp này, nó chuẩn bị một offer mô tả (1) những ai mà nó muốn mời tham gia vào team của nó, và (2) những tài nguyên nào mà nó có thể cung cấp cho

2.2 3 Người sử dụng có nhu cầu sử dụng tài nguyên của Grid

Bây giờ chúng ta xem xét chuyện gì xảy ra khi User yêu cầu LAgent của nó sắp xếp

thực hiện một công việc (sẽ thảo luận chi tiết hơn ở phần sau) Người dùng đặc tả các điều kiện để thực thi công việc LAgent sẽ truy vấn CIC để tìm ra team nào có thể thực thi công việc của nó Khi nhận được danh sách các team mà trùng khớp với sự truy vấn LAgent sẽ loại bỏ những team không tin tưởng Tiếp theo nó giao tiếp với các LMaster

của những team còn lại và dùng giao thức FIPA và phân tích đa tiêu chí để tìm ra team

tốt nhất để thực thi công việc của nó Nếu không có team nào thỏa mãn đi ều kiện do User áp đặt thì sẽ không đạt đến một thỏa thuận nào Trong trường hợp này LAgent sẽ báo cáo trường hợp này cho User của nó và đợi các chỉ thị tiếp theo.

2.2.4 Quan h ệ LMaster - LMirror

Bây giờ chúng ta miêu tả các quan hệ giữa LMaster và LMirror Khi tạo ra một team mới thì “agent sáng lập” sẽ trở thành LMaster của team Agent đầu tiên tham gia vào team đó trở thành LMirror (agent có thể đảm nhiệm việc đứng đầu team trong trường

hợp LMaster chết) Những agent tiếp theo sau khi tham gia vào team sẽ trở thành worker agent

Chúng ta chưa quyết định rằng LMirror nên làm việc như 1 worker agent hay vai trò của

nó chỉ được giới hạn là phản ánh LMaster, quyết định này nên dựa trên sự phân tích

20

thực nghiệm về tải trọng công việc của các LMirror và sẽ được thực thi khi phiên bản

hoàn thành đầu tiên của hệ thống được hiện thực LMaster và LMirror sẽ chia sẽ tất cả

các thông tin có ý ngh ĩa cho sự tồn tại của team, thí dụ danh sách các worker và những tính năng của nó, danh sách các công việc được ký ước và phải được thực thi Cơ sở tri

th ức chứa thông tin về tất cả những tương tác trong quá khứ với những user đến

LMaster và LAgent kiểm tra sự tồn tại của nhau theo định kỳ Trong trường hợp LMaster không phản hồi với tin nhắn ACL, LMirror sẽ liên lạc với hệ thống để kiểm tra

trạng thái của LMaster Nếu LMaster bị chết nó sẽ thay thế vai trò của LMaster Hành động đầu tiên của nó là thăng chức cho một trong những worker agent trở thành LMirror và truyền cho nó tất cả các thông tin cần thiết Rồi nó thông báo cho tất cả các agent có liên quan về sự thay đổi này (thông báo là nó bây giờ đã trở thành LMaster) Tương tự LMaster khi thấy rằng LMirror bị chết sẽ thăng chức cho một trong những worker agent của nó trở thành LMirror và truyền cho nó tất cả thông tin Trong hai trường hợp, việc thăng chức cho một worker lên vai trò của LMaster và LMirror có thể

cần phải đề cập đến công việc mà worker được chọn đang thực thi tại thời điểm nó thăng chức

Giải pháp này chưa giải quyết được toàn diện vấn đề Trường hợp cả LMaster & LMirror cùng chết đồng thời và team sẽ bị phá hủy Tuy nhiên, trường hợp như vậy tương đối hiếm khi xảy ra và mục tiêu của chúng ta là không tao ra một hạ tầng hoàn

hảo, giải quyết được toàn diện vấn đề Mà mục tiêu là cung cấp một hạ tầng với mức

độ kiên cường chỉ mang tính tương đối khi xảy ra failure hệ thống Rõ ràng trong một môi trường sản xuất mức độ bảo vệ chống lại sự tan rã của team sẽ phải được phát triển, tăng cường dần dần Hình 4 bên dưới được trích ra một phần từ hình 1 để chúng

ta dễ nhìn

Mirror LMaster Recreation

LMaster MCDM

Hình 4: Giao ti ếp LMaster và LMirror

2.2.5 Thu th ập thông tin để tích lũy tri thức về hoạt động môi giới tài nguyên b ằng mô hình agent

Cuối cùng, chúng ta đề cập ngắn gọn một vài đối tượng phụ thêm xuất hiện trong hình

1 Các chức năng thu thập tri thức (Gathering Information) bao hàm sự thu thập thông tin về các tiến trình đang xảy ra trong hệ thống LMaster thu thập thông tin về tất cả các

sự tương tác với các agent mang tác vụ đến incoming (task-carrying) agent cũng như

về các thành viên của team nó Bằng cách này, sau đó nó có thể quyết định không tương tác với những client nhất định hoặc loại bỏ những worker nhất định ra khỏi team của nó Tương tự, LAgent thu thập tri thức về việc điều gì sẽ xảy ra khi nó sử dụng các

dịch vụ của nhiều team, cũng như khi nó là một worker của nhiều team LAgent có thể đóng bất kỳ vai trò nào trong hệ thống, có thể LMaster sẽ biến thành LAgent biểu diễn User của nó đang cố gắng tìm vị trí để thực thi công việc của nó Liệu nó sẽ trở về với team trước đây sở hữu nó để làm hay không? Những câu hỏi này sẽ được trả lời bằng

các module LAgent MCDM và LMaster MCDM

22

2.3.1 Tương tác LAgent – CIC

Như ta thấy, bất kể hoàn cảnh, tương tác với CIC rất quan trọng Do đó, ta sẽ nói về những sự tương tác xảy ra khi LAgent truy vấn CIC về team nào sẽ thực thi công việc

của nó

Giả sử dữ liệu trong hệ thống được chứa theo dạng có phân ranh giới về mặt ngữ nghĩa Trong đó, trường hợp lý tư ởng nhất là tồn tại một “mô hình dữ liệu về Grid” đã được thống nhất chung Tuy nhiên, người ta vẫn đang tự thiết kế những mô hình riêng không tương thích, lẽ tẽ và tự phát như vậy Do đó, thay vì ch ọn một trong những mô hình như vậy và trả một cái giá là cố gắng giải quyết việc tương thích với nhu cầu của chúng ta Công việc của ta tập trung vào các khía cạnh có liên quan đến agent của hệ

thống (thiết kế và hiện thực sườn của hệ thống agent) tận dụng những mô hình dữ liệu đơn giản Trong tương lai, khi mô hình d ữ liệu Grid được thống nhất chung, hệ thống

của chúng ta vẫn sẵn sàng tương thích Hiện tại, mô hình dữ liệu (ontology) của các tài nguyên Grid tập trung vào các khía cạnh “tính toán”, thí dụ bộ vi xử lý, bộ nhớ và đĩa

cứng Sau đây là một trích đoạn mô hình dữ liệu trong OWL Lite:

Giả sử ta có agent LMaster007 có team worker là PC1410 có bộ vi xử lý của Intel 3.5

GHz, bộ nhớ 1024 Mbytes và đĩa cứng 600MB Ontology được biểu diễn như sau: : LMaster007

của nó) với bộ vi xử lý Intel ít nhất 3.0 GHz, RAM ít nhất 512 Mbytes và đĩa cứng ít nhất

500 Mbytes Câu truy vấn SPARQL có dạng như sau:

PREFIX : <http://gridagents.sourceforge.net/grid#>

SELECT ? contact

: hasWorker

[

: a : Computer ; : hasCPU

[ a: CPU ;

: hasCPUType : Intel ; : hasCPUFrequency ? freq ; ];

: hasUserDiskQuota ? quota ; : hasMemory ? mem ;

] FILTER (? freq >= 3.0)

26

2.3.2 Hi ện thực CIC

CIC là một trong những thành phần chính của hệ thống Tương tác giữa CIC và user agent là một phần thiết yếu để chuẩn bị thực thi công việc Khi người dùng tham gia vào một agent team sự phản hồi chậm từ CIC sẽ trở thành một nút thắt cổ chai của hệ thống Do đó CIC phải xử lý hiệu quả một số lượng lớn request

Giải pháp cho các dịch vụ CIC là một phương pháp lấy yellow-page làm trung tâm Chúng ta đã tìm ra hi ện thực tối ưu cho việc truy xuất CSDL trong CIC [3] Theo thí nghiệm được trình bày trong [3] giải pháp truy vấn CSDL hiệu quả nhất là một agent

nhận và đưa vào hàng đợi các request của client, trong khi nhiều agent truy cập database (SQLAgents) sẽ lấy các request ra khỏi hàng đợi và thực thi nó trên database Hơn nữa tất cả các agent xử lý truy vấn (SQL) và CSDL chạy trên những máy riêng và khi ta sử dụng 5 SQLAgent, độ lợi hiệu suất là 33% Ở đây, ta trình bày

hiệu suất của 2 kiến trúc CIC tốt nhất (1) Kiến trúc phân luồng, (2) Kiến trúc agent truy

vấn CSDL phân tán và có thêm một CIC Internal Agent (CICIA)

Trong kiến trúc phân luồng, chúng ta tận dụng phương pháp một công việc thực hiện trên 1 luồng nổi tiếng Sử dụng các thread của Java và truy cập tới CIC agent trong container (một môi trường JVM là 1 container) Mỗi worker thread có kết nối riêng đến database Việc tạo ra các tài nguyên này về mặt tính toán rất đắt đỏ, và đó là lý do t ại sao thay vì sinh ra những thread mới, chúng ta sử dụng những thread được khởi tạo trước trong thread pool CIC agent sẽ nhặt ra những request (query-request) từ hàng đợi message được cung cấp bởi JADE Mỗi JADE agent có hàng đợi message của riêng nó do môi trường JADE cung cấp CIC agent trích từ message queue tất cả các message cần truy cập database và xếp vào một hàng đợi khác gọi là request queue

hi ện thực bằng Java. Từ những hàng đợi này worker thead sẽ lấy các request để thực thi Sau khi thực thi truy vấn họ sẽ gởi những kết quả nhận được về nơi yêu cầu

Main CIC Container = single JVM

outgoing result message

Hình 5: Lu ồng thực thi Request/Result trong kiến trúc CIC đa phân luồng

outgoing result message

CICAgent

JADE provided message queue

(1) enqueue

request queue

(2) dequeue

(3) delegation

(4) send result (5) enqueue result

(6) dequeue result

(7) send result

shared result queue

Hình 6: Lu ồng Request/Result trong kiến trúc CIC đa Agent phân tán

Phương pháp thứ 2 ta sử dụng CICDbAgent thay vì worker thread Mỗi agent này nằm trên một máy riêng, các message đến được chứa trong message queue do JADE cung

cấp như ở hình 6 Các message mà request truy cập CSDL được rút khỏi message

queue và được đưa vào request queue được hiện thực bằng Java Queue này hoạt

động như 1 buffer giữa CICAgent và CICDbAgent và do đó giảm số message chứa

trong message queue của JADE

28

Các request đến được CIC agent giao phó cho CICDbAgent Mỗi database agent sẽ thực thi câu truy vấn tại một thời điểm và gởi kết quả về cho CIC Internal Agent CICIA (3) (các kết quả này được chứa trong JADE message queue của CICIA) CICIA sẽ lấy

ra khỏi message queue của nó và đưa vào result-queue (4), từ đây CICAgent sẽ dequeue (6) và gởi kết quả về cho requester (7) Nói cách khác, sự giao tiếp giữa

CICIA và CIC agent thông qua m ột result-queue chia sẽ Đây là lý do tại sao (CICIA và

CIC agent) phải chạy trên cùng agent container (CIC container chính) Kiến trúc này

được mô tả trong hình trên) CIC có 3 tác vụ: (1) nhận request-message từ message

queue và đưa vào hàng đợi request queue (2) lấy request ra khỏi hàng đợi request

queue và g ởi nó cho CICDbAgent, và (3) lấy message ra khỏi hàng đợi result queue và

gởi nó cho requester Sơ đồ tuần tự xử lý request được trình bày trong hình 4

Requestor: Agent

UserAgent or

LMaster CIC

CICAgent: Agent

CIC Main Container

29

Để so sánh hiệu suất cũng như sự hiệu quả của từng phương pháp người ta đã tiến hành thí nghiệm Trong thí nghiệm, để mô phỏng các request đến từ các user agent ta dùng 4 Querying Agents (QA), request CIC thực thi các truy vấn tài nguyên SPARQL Chú ý rằng, dạng của câu truy vấn SPARQL có thể thay đổi hiệu năng của hệ thống Trong Jena [11], ARQ engine chịu trách nhiệm thực thi truy vấn trên các tài nguyên OWL tồn tại trong CSDL Nó chỉ dịch một vài phần của câu truy vấn SPARQL thành SQL Các phần còn lại (ví dụ các tác vụ lọc FILTER) của câu truy vấn SPARQL không được thực thi thông qua truy vấn SQL, mà bởi ARQ, tận dụng tài nguyên máy ảo Java

cục bộ Các câu truy vấn có dạng:

PREFIX : <http://Gridagents.sourceforge.net/Grid#>

SELECT ? master

WHERE {

? comp : cpuClockSpeedMhz ? cpu

? master : offersResource ? comp

FILTER (? cpu > 1000)

}

Mỗi QA chạy trên một máy và gởi 2500 request và nhận các kết quả truy vấn Như vậy, trong mổi thí nghiệm CIC phải xử lý 10.000 truy vấn Người ta đã ti ến hành nhiều thí nghiệm (đặc biệt là cố gắng để điều chỉnh hiệu suất thực thi), một framework thí nghiệm

để chạy kiểm tra tự động cũng đã được thiết kế, thay đổi các thông số (như thay đổi số thread, số CICDbAgents …) Tất cả các lần thí nghiệm được điều khiển bởi Test

Coordinator Agent (TCA) Trước mỗi khi test, các agent container của môi trường JADE được khởi động lại để cung cấp các điều kiện giống nhau Các thí nghiệm được thực

hiện sử dụng 11 Athlon 2500+, các máy 512MB RAM chạy Gentoo Linux và JVM 1.4.2

Rõ ràng, trong trư ờng hợp giải pháp phân luồng, chỉ một máy dùng để chạy CIC Các máy tính được kết nối với nhau bằng 1 mạng LAN tốc độ 100 Mbit CSDL MySQL 4.1.13 được dùng bởi cơ chế bền vững của Jena để chứa dữ liệu trang vàng được cài trên một máy riêng Trong tất cả các trường hợp, thủ tục thí nghiệm như sau:

1 Khởi động lại các agent container từ xa

2 Những thành phần tham gia thí nghiệm gởi tin nhắn ready đến cho TCA – chỉ

sau khi tất cả đã sẵn sàng

3 Khi nhận tín hiệu ready từ tất cả các agent, TCA gởi lời nhắn start đến tất cả các

QA, kích hoạt thí nghiệm

30

4 Khi nhận được tất cả các kết quả trả về, các QA sẽ gởi 1 lời nhắn finish đến TCA

5 Khi TCA nhận được tất cả các tín hiệu finish sẽ kết thúc quá trình thí nghiệm

multithreaded (VP – number of worker threads) distributed multi-agent with CICIA (VP – number of CICDbAgents)

Hình 8: So sánh gi ữa hai kiến trúc phân CIC phân luồng và đa Agent

Hình 5: So sánh các ki ến trúc phân luồng và agent; thời gian xử lý 10.000 truy vấn khi thay đổi số thread trong kiến trúc phân luồng/ số CICDbAgent trong kiến trúc agent

Trong hình 5, ta minh họa thời gian xử lý 10.000 request bởi 2 kiến trúc khi số agent/ thread tăng từ 1 – 6 Có thể thấy rằng, kiến trúc phân luồng có độ lợi hiệu suất trong 3 thread đầu Có thể dự đoán rằng, nếu sử dụng các bộ xử lý đa lõi đ ộ lợi hiệu suất sẽ càng tăng, phương pháp này bị hạn chế bởi tổng sức mạnh xử lý bởi bộ xử lý Khi số

CICDbAgent tăng lên 6 hiệu suất của phương pháp multi-agent cải thiện đáng kể Đặc

biệt có thể dự đoán rằng, nếu số CICDbAgent tăng hơn nữa thì độ lợi hiệu suất cũng

sẽ tăng không bao nhiêu Tóm lại, với 6 CICDbAgent, độ lợi hiệu suất của hệ thống với

1 CICAgent là bậc 3 Hơn nữa, độ lợi đối với thread là bật 2 (ở đây, ta so sánh giải pháp phân luồng tốt nhất - với 3 thread - với giải pháp agent tốt nhất với 6

CICDbAgent)

31

Chúng ta sửa kiến trúc agent trên một chút, CICIA agent trở thành người ủy nhiệm các request và nhận kết quả luôn rồi đánh giá lại Kiến trúc này chứng tỏ nhanh hơn một chút, tuy nhiên phức tạp hơn về góc nhìn khái niệm Do đó, ta không chọn nó như giải pháp kiến trúc cuối cùng Ta cũng đã thí nghi ệm một vài phương pháp để cân chỉnh

hiệu suất hơn nữa, nhưng độ lợi hiệu suất của nó cũng nh ỏ, ta đi đến kết luận rằng, phương pháp agent cấu thành nền tảng cơ bản của kiến trúc CIC

2.4.1 Ch ọn đội agent để thực thi công việc

Chúng ta mô tả các công việc có liên quan khi chọn một team để thực thi công việc do user yêu cầu Như mô tả trong phần 3, bước đầu tiên trong quá trình này là dành cho người dùng cung cấp cho LAgent của nó những thông tin cần thiết, như miêu tả công

việc, các thông số thương lượng và có thể là các ràng buộc

Người dùng cung cấp cho LAgent của nó những thông tin cần thiết, như miêu tả công

việc, các thông số thương lượng và có thể là các ràng buộc Trong phần 3.1, đã trình bày cách biểu diễn mô hình dữ liệu các tài nguyên tính toán Phần này ta tập trung vào các tham số thương lượng, sử dụng mô hình dữ liệu Yellow Pages của Grid để diễn tả

Hiện tại công việc của ta là tận dụng 3 thông số thương lượng: chi phí, thời gian bắt đầu công việc và thời gian kết thúc công việc Với mỗi thông số này, người dùng đặc tả

tầm quan trọng của nó bằng cách gán trọng số sau đó tiến hành phân tích đa tiêu chuẩn Ngoài các thông số thương lượng này chúng ta đặc tả các ràng buộc thực thi Giá tối đa được tính cho công việc Ngoài ra, chúng ta giả sử rằng nếu bất kỳ thông số

thực thi nào không được đem ra xem xét, thì ho ặc là gán cho thông số đó trọng số 0

ho ặc thông số đó không được đưa vào trong tập các thông số thương lượng Tùy theo,

c ũng có thể một thông số được cho được ràng buộc nhưng không được cho một trọng

s ố Điều này cho thấy phương pháp dựa trên ontology cho phép chúng ta linh hoạt

trong việc diễn đạt Đoạn code sau đây thể hiện sự kết hợp tập các thông số thương lượng:

### negotiation parameters ###

: NegotiationSet a owl : Class

: negotiationParam a owl : ObjectProperty ;

: NegotiationParamConstraint a owl : Class

: FloatConstraint a owl : Class ;

rdfs : subClassOf : NegotiationParamConstraint : maxFloatValue

a owl : FunctionalProperty, owl : DatatypeProperty; rdfs : domain : FloatConstraint ;

rdfs : range xsd : float

: minFloatValue

bằng cách thêm vào, thí dụ, lỗi không hoàn thành công việc đúng thời hạn, chỉ cần một

động tác mở rộng ontology rất đơn giản, và thay đổi một chút về agent code là có thể

mở rộng được Tập trung vào tương tác agent, chứ không phát triển một tập thông số

sử dụng thực tế Giả sử, user nói rằng chi phí thực thi quan trọng gấp hai lần thời gian

kết thúc công việc JobEndTime thì ta cho cost trọng số 2 và JobEndTime trọng số 1

Thực thể tập thông số có dạng:

@prefix nego : <http://Gridagents.sourceforge.net/Negotiation#>

: NegotiationSetInstance a nego : NegotiationSet ;

35

Nego : negotiationParam [

a nego : JobEndTime ; nego : paramWeight “1.0”^^xsd : float ] , [

a nego : Cost ; nego : paramWeight “2.0”^^xsd : float ]

Ngoài các tập thông số có liên quan đến thực thi công việc, người dùng đặc tả các thông số mô tả tài nguyên dùng để truy vấn CIC (xem phần 3.1 và câu truy vấn mẫu)

Ta đã hiện thực một User Agent GUI để cho User giao tiếp với LAgent của nó

Giả sử rằng, để trả lời cho truy vấn, LAgent đã lấy từ CIC danh sách agent team có

những tài nguyên cần thiết để hoàn thành công việc và lọc ra các agent team không

đáng tin cậy, và tiến hành thương lượng LAgent-LMaster

Mô hình thương lượng được hiện thực trong Software Agent như sau:

Hình 9 : Sơ đồ tương tác của giao thức FIPA Contract Net Protocol

LAgent sử dung giao thức FIPA (Foundation for Intelligent Physical Agents) để điều đình với các LMaster LAgent sẽ thương lượng với nhiều hơn một LMaster Và do đó cùng tập các giao tiếp sẽ xảy ra trong tất cả các cuộc thương lượng này Hình 9 biểu

diễn sơ đồ giao tiếp giữa User và các Master của team

Đầu tiên LAgent sẽ phát ra một CFP (Call For Proposal) đến tất cả các LMaster trong danh sách cuối cùng (sau khi cắt tỉa) CFP chứa đặc tả công việc và tập các thông số ràng buộc, theo đó các LMaster sẽ xây dựng các offer (các trọng số User gán cho các thông số sẽ không được User gởi cho LMaster) Trong trường hợp tập thông số của chúng ta, CFP có dạng như sau:

(CFP

:receiver (set ( agent-identifier :name MasterB@KIETVH ) ( agent-i

dentifier :name MasterC@KIETVH ) ( agent-identifier :name MasterG@KIETVH ) ( age nt-identifier :name MasterE@KIETVH ) ( agent-identifier :name MasterD@KIETVH ) ( agent-identifier :name MasterH@KIETVH ) ( agent-identifier :name MasterF@KIETVH

37

) ( agent-identifier :name MasterI@KIETVH ) ( agent-identifier :name MasterA@KI

ETVH ) )

:content "((action (agent-identifier :name cic-agent@KIETVH :addre

sses (sequence http://10.151.86.69:7778/acc)) (JobExecutionEnquiry :jobConstrain

ts (JobExecutionConstraints :startTime \"Sat Jan 03 19:15:33 PST 2009\" :cost 10

:endTime \"Sun Jan 04 19:15:33 PST 2009\" :cpusNo 2 :cpuMHz 1000 :memoryAmount

500 :flag 0))))"

:language fipa-sl0 :ontology Messaging :protocol fipa-contract-net

Trong ví dụ này LAgent đang tìm 1 máy với bộ vi xử lý 1000 MHz và đặc tả deadline cho công việc bằng thông số JobEndTime

Dựa trên CFP nhận được và thông tin về các worker, LMaster sẽ chuẩn bị các proposal

và gởi về cho LAgent, dùng PROPOSE message LMaster có thể từ chối CFP bằng cách dùng một REFUSE message Chẳng hạn vào thời điểm giữa lần update cuối cùng thông tin về các team trên CIC và request của LAgent, một số tài nguyên biến mất

và team không thể hoàn thành công việc Hơn nữa vì nhiều lý do, một số team không

thể trả lời đúng hẹn Trong tin nhắn phản hồi của LMaster có chứa một offer

:cost 17 :endTime \"Sun Jan 04 19:15:33 PST 2009\" :cpusNo 2 :cpuMHz 1000 :memoryAmount 500 :flag 0))) (TeamEnquiryResult :jobExecutionConstraints (JobExecutionConstraints :startTime \"Sat Jan 03 19:15:33 PST 2009\" :cost 17 :endTime \"Sun Jan 04 19:15:33 PST 2009\" :cpusNo 2 :cpuMHz 1000 :memoryAmount 500 :flag 0))))"

:reply-with userC@KIETVH1231038935872 :in-reply-to R1231038935822_1 :language fipa-sl0 :ontology Messaging :protocol fipa-contract-net

38

:conversation-id C13572035_1231038935792 )

Tin nhắn phản hồi thông báo cho LAgent rằng LMaster sẽ sẵn lòng hoàn thành công việc và cung cấp tài nguyên cho nó trong một khung thời gian xác định và tổng chi phí

sẽ là 17 đơn vị Giao thức Contract Net, gởi một PROPOSE message như một lời cam

kết của LMaster trước các điều kiện được đặc tả

Trong thi ết kế hiện tại của hệ thống, LAgent đợi phản hồi đến khi tất cả các phản hồi đến hoặc deadline Cần phải áp đặt một deadline để tránh deadlock Thí dụ, một trong

nh ững LMaster không kết nối đến internet được và không thể giao tiếp lại với các offer

c ủa nó Nếu sau khi deadline mà không có proposal nào thì LAgent không thể thực thi công vi ệc và báo cáo lại cho User Ngược lại nếu có ít nhất một offer, LAgent bắt đầu

đánh giá để loại bỏ các offer Đánh giá Proposal gồm 2 giai đoạn:

• Các offer không đáp ứng các ràng buộc thực thi (thí dụ, chi phí, thời gian bắt đầu công việc, thời gian kết thúc công việc) được loại bỏ Nếu tất cả các offer bị loại

bỏ tại giai đoạn này, do constraint, thì LAgent không thể thực thi công việc và báo cáo về cho User

• Các offer còn lại được đánh giá dùng Multi Criterial Analysis (MCA)

Có một câu hỏi là tại sao LMaster phải gởi một offer mà xung đột với các ràng buộc với

chính nó Đây là một hạn chế vì hệ thống này còn tương đ ối đơn giản, trong tương lai

sẽ mở rộng hệ thống này ra Sự đơn giản hóa này liên quan đến LAgent , nó sẽ lọc ra tất cả các offer xung đột các ràng buộc Điều này không cho người dùng đặc tả các

ràng bu ộc mềm, biểu diễn một “sự ưa thích hơn”, nhưng offer xung đột không phải lúc

nào cũng có nghĩa là offer đó không chấp nhận được Chẳng hạn, tôi thích làm công

việc này hôm nay, nhưng nếu nó có thể được thực hiện với chi phí rất rẽ vào tối mai, thì tôi có thể sẵn lòng chấp nhận offer này Do đó, khi mở rộng hệ thống trong tương lai cần phải tính đến sự hiệu quả hơn của bước này Phải xử lý các ràng buộc một cách linh hoạt hơn

Sau khi MCA được áp dụng cho các offer còn lại, một team nào đó sẽ được chọn để

thực thi công việc Trong trường hợp này, ACCEPT-PROPOSAL được gởi cho LMaster

của team đó Các team còn l ại bị reject bằng cách gởi REJECT-PROPOSAL message Team được chọn xác nhận bằng cách gởi lại 1 INFORM-DONE message Rõ ràng, Contract Net Protocol (CNP), cũng quan tâm đ ến nhiều trường hợp khẩn cấp, thí dụ

team được chọn phản hồi không thành công

39

Giai đoạn này ta sử dụng mô hình tuyến tính cộng thêm (LAM) Mô hình này được chọn

vì tính đơn giản của nó Tuy nhiên, bất kỳ phương pháp MCA nào khác cũng có thể được áp dụng để đánh giá các offer nhận được

Trong LAM, đánh giá được thực hiện bằng cách nhân các điểm số giá trị trên mỗi tiêu chuẩn với trọng số của tiêu chuẩn đó, rồi cộng các điểm trọng số này lại với nhau Ta

có 3 tiêu chuẩn tham gia vào quá trình MCA: chi phí, thời điểm bắt đầu công việc và

thời điểm kết thúc công việc Nếu giao tiếp với m team và có n proposal (m-n team bị từ

chối) Điểm tiêu chuẩn của team thứ i được tính như sau:

Start Time Score:

e currentTim startTime

e currentTim startTime

STS

i

n j

e currentTim endTime

ETS

i

n j

CS

Điểm cuối cùng của team được tính như sau:

TSi = startTimeWeight*STSi + endTimeWeight*ETSi + costWeight*CSi

Team có tổng score cao nhất, được tính bằng tổng trọng số của các score thành phần, được chọn là người thắng cuộc

2.4.2 Ch ọn team để tham gia vào