JADE được viết hoàn toàn bằng ngơn ngữ Java và gồm nhiều gói khác nhau cho phép người phát triển sau này có thể tận dụng lại các tính năng và giao diện trừu tượng có sẵn.
4.2.1. Ngơn ngữ truyền thơng ACL
Các JADE Agent sử dụng một ngôn ngữ riêng để giao tiếp với nhau, đó là ngôn ngữ truyền thông ACL (do tổ chức chuẩn quốc tế về liên tác Agent - FIPA định nghĩa). Định dạng thông điệp ACL khá phức tạp nhưng tựu trung lại có một số thành phần đặc biệt quan trọng sau đây:
Danh sách địa chỉ bên nhận
Mục đích giao tiếp: Những cái mà bên gửi muốn đạt được khi gửi thơng điệp đó. Ví dụ, khi bên nhận gửi cho bên nhận thơng điệp REQUEST tức là bên gửi muốn bên nhận thực hiện một hành động nào đó, thơng điệp INFORM là thông báo cho bên nhận một sự thực nào đó, REJECT là từ chối một đề nghị thương lượng nào đó…
Nội dung: Các thông tin thực sự chứa trong thơng điệp, ví dụ nội dung của thơng điệp INFORM của người điều khiển phiên đấu giá gửi cho người trả giá có thể là start auction để thơng báo bắt đầu cuộc đấu giá.
Ngôn ngữ nội dung: Là cấu trúc được dùng để diễn tả nội dung. Cả Agent gửi và nhận đều phải hiểu được ngôn ngữ này.
4.2.2. Cơ chế truyền thông giữa các Agent
Kỹ thuật truyền thông được sử dụng ở đây là truyền thông điệp không đồng bộ. Mỗi một Agent sẽ có một hộp thư (hàng đợi các thơng điệp của Agent) trong đó đặt các thơng điệp do các Agent khác gửi tới. Agent sẽ được thông báo mỗi khi có thơng điệp được thêm vào hàng đợi. Khi Agent thực sự xem xét đến thơng điệp đó (lấy thông điệp ra khỏi hàng đợi) thì người lập trình mới thực sự xử lý nội dung thơng điệp.
Hình 4.5. Cơ chế truyền thơng điệp khơng đồng bộ của Jade
Quy trình truyền thơng ACL giữa các Agent có thể được mơ tả qua Hình 4.10 ở trên. Quá trình này gồm một số bước cơ bản sau đây:
Chuẩn bị nội dung thông điệp: chỉ đơn giản là điền đầy các trường của
đối tượng ACLMessage.
Gửi thông điệp: bằng cách gọi phương thức send() của một đối tượng
thuộc lớp Agent. Đoạn code sau đây sẽ gửi một thơng điệp đến Agent có tên BidderA với thông báo „Auction is Over‟.
ACLMessage msg = new ACLMessage(ACLMessage.INFORM); msg.addReceiver(new AID(“BidderA”, AID.ISLOCALNAME)); msg.setLanguage(“English”);
msg.setOntology(“Auction-ontology”); msg.setContent(“Auction is Over”); send(msg);
Nhận thông điệp vào hàng đợi: Trong thời gian chạy, JADE tự động gửi
thông điệp vào hàng đợi thông điệp cá nhân của Agent nhận.
Nhận và xử lý thông điệp: Một Agent có thể lấy các thơng điệp từ hàng
đợi của mình bằng cách gọi thực hiện phương thức receive(). Phương thức
A1 A2
Chuẩn bị thông điệp gửi A2
Gửi thông điệp Lưu thông điệp vào hàng đợi của A2
Lấy thông điệp từ hàng đợi và xử lý
này trả về thông điệp đầu tiên trong hàng đợi thơng điệp, sau đó xóa nó khỏi hàng đợi. Sau khi lấy được thông điệp từ hàng đợi, Agent sẽ tiến hành xử lý thông tin nhận được và đưa ra quyết định hành động tiếp theo.
4.2.3. Ví dụ minh họa truyền thơng ACL
Chúng ta hãy xem xét chi tiết cách thức truyền thông điệp giữa hai Agent đã đảm nhận hai role Bidder và Auctioneer trong một hệ đấu giá.
Trong hệ thống đấu giá,thông điệp CFP được sử dụng để thực hiện việc Auctioneer gửi giá đề nghị cho mặt hàng chào bán tới các Bidder. Thông điệp PROPOSE có thể được Bidder sử dụng để chứa lời xác nhận sẵn sàng trả giá Auctioneer đã đặt ra cho mặt hàng. Thông điệp ACCEPT_PROPOSAL để thể hiện việc Auctioneer chấp nhận lời trả giá của Bidder.
ACLMessage msgACL = new ACLMessage(ACLMessage.REQUEST); msgACL.addReceiver(addressee.getAgent());
try {
msgACL.setContentObject(msgR); } catch (java.io.IOException ioe) {
System.err.println(ioe); throw new RoleException(); }
myAgent.send(msgACL);
4.3. Cài đặt role
Role được cài đặt bằng một lớp trừu tượng trong đó các tính năng của role được biểu diễn dưới dạng các trường tĩnh và phương thức tĩnh [15]. Lớp biểu diễn role có tên trùng với tên của role và là một phần của gói (package) biểu diễn ngữ cảnh ứng dụng của role đó. Ví dụ, ở hệ thống eAuction là gói auction.
package rolesystem.roles.auction; import rolesystem.core.RoleAction; import rolesystem.roles.KnownEvent; /**
This role is the bidder of an auction. Keywords: auction, bidder.
*/
public abstract class Bidder {…}
Mỗi hành động được biểu diễn bởi một phương thức tĩnh, có nhiệm vụ tạo ra một thể hiện thích hợp của lớp RoleAction và trả nó về cho đối tượng gọi phương
thức đó. Tên của phương thức tĩnh này cũng trùng với tên của hành động tương ứng và có thể có một hoặc hai tham số: tham số thứ nhất là địa chỉ của Agent nhận sự kiện tương ứng với hành động, tham số thứ hai (có thể có hoặc khơng) là nội dung thơng tin để thực thi hành động. Ví dụ, dưới đây là mã nguồn cài đặt hành động trả giá (bid) của Bidder.
public static RoleAction bid(Id addressee,Price content) { return new RoleAction("bid", addressee,content);}
Đối với sự kiện, ta có hai lớp cài đặt sự kiện khác nhau. Một là lớp RoleEvent, lớp kia là KnownEvent. Lớp RoleEvent biểu diễn các sự kiện được Server Agent dịch từ hành động mà nó nhận được từ Agent. Lớp này cài đặt các sự kiện với các thông tin như: tên của sự kiện, ID của Agent gửi, role mà Agent gửi đang đảm nhận và lớp nội dung thông tin của sự kiện.
public class RoleEvent implements Serializable {
private String name; private int sender;
private String senderRole; private Serializable content; ….
}
Lớp thứ hai cài đặt sự kiện là lớp KnownEvent, thể hiện các sự kiện nằm trong phạm vi xử lý của một role nào đó. Mỗi một sự kiện là instance của lớp RoleEvent cũng sẽ có một sự kiện tương tự là instance lớp KnownEvent. Với cùng một sự kiện, tên của các instance ở hai lớp này là giống nhau, instance của lớp KnownEvent có thêm kí tự KE ở trước để phân biệt. Ví dụ, sự kiện bid là instance
của lớp RoleEvent, ta sẽ có một instance tương ứng của lớp KnownEvent là
KE_bid.
Các sự kiện một role có thể nhận biết là instance của lớp KnownEvent, được khai báo dưới dạng các trường dữ liệu tĩnh. Ví dụ, sự kiện bid mà Auctioneer nhận được dưới đây:
public static final KnownEvent KE_bid=new KnownEvent("bid", Bidder.ROLE_ID, Price.class);
Mối quan hệ giữa các lớp được thể hiện qua lược đồ dưới đây:
Hình 4.6. Lược đồ quan hệ giữa các lớp trong hệ Auction.
Như đã trình bày ở chương 3, việc cài đặt role bằng ngơn ngữ Java có thể được thực hiện dễ dàng và nhanh chóng hơn nhờ các tài liệu XRole. Bằng cách dùng các XSL thích hợp, ta có thể chuyển các định nghĩa role Seller, Bidder và Auctioneer tương ứng thành các lớp trừu tượng như dưới đây:
public abstract class Seller {
String description="role to make resources available"; String keyword[]= {"seller", "auction"};
/*Request to put the good on sale*/
public static RoleAction ReqOnSale(AgentID addressee); /*Put the good to be sold on sale*/
public static RoleAction putGoodOnSale(String Good_ID, String Description);
/*Auctioneer accept seller's request or not*/
public static final KnownEvent KE_acceptSale(AgentID addressee); /*the good cannot be sold at the auction*/
public static final KnownEvent KE_unSold(AgentID addressee); /*payment from the auctioneer*/
public static final KnownEvent KE_pay(AgentID addressee, String content);
}
Hình 4.7. Mã nguồn Java tương ứng với Seller.xml.
Role A (Abstract) ROLE_ID:String=Auction x RoleA KE_A: KnownEvent KE_B: KnownEvent … ActionA: RoleAction ActionB: RoleAction Auction KnownEvent RoleAction
public abstract class Auctioneer {
String description="role to control the auctions"; String keyword[]= {"Auctioneer", "auction"};
/*notify requesting bidders the current goods on sale*/
public static RoleAction notifyGood(AgentID addressee, string content); /*notify bidders the current situation*/
public static RoleAction notifySituation(AgentID addressee, string content);
/*notify bidders the final winner*/
public static RoleAction youWon(AgentID addressee, Price content); /*request to put goods on sale from sellers*/
public static final KnownEvent KE_reqOnSale(AgentID sender); /*put goods on sale*/
public static final KnownEvent KE_putGoodOnSale(AgentID sender, string content);
/*bidder ask about the current goods*/
public static final KnownEvent KE_askGood(AgentID sender); /*ask about the current situation of the auction*/
public static final KnownEvent KE_askSituation(AgentID sender, string content);
/*bid from the bidders*/
public static final KnownEvent KE_bid(AgentID sender, string content); }
Hình 4.8. Mã nguồn Java tương ứng với Auctioneer.xml
public abstract class bidder {
public string description="role to make a bid for the good "; public string keyword[]= {"bidder"};
/*ASK AUCTIONEER ABOUT GOODS ON SALE*/
public static RoleAction askGood(AgentID addressee); public static RoleAction askSituation(AgentID addressee); /*make a bid for the good interested*/
public static RoleAction bid(AgentID addressee, Price content); /*PAY THE MONEY TO AUCTIONEER*/
public static RoleAction pay(AgentID addressee, Money content); /*Auctioneer notify the requested bidder the current price*/
public static final KnownEvent KE_notifySituation(String content); /*sellers notify the winning bidder about the win*/
public static final KnownEvent KE_youWon(AgentID addressee, String content);
}
Tuy nhiên, những mã nguồn Java này mới chỉ là khung của các lớp cài đặt role tương ứng. Nội dung cài đặt chi tiết cho từng role, chúng ta sẽ tiếp tục hoàn thiện trong quá trình cài đặt thực sự. Sau đây là một phần mã nguồn cài đặt role Bidder.
...
public static final KnownEvent KE_askSituation=new KnownEvent("askSituation", Bidder.ROLE_ID);
/**
A bidder makes a bid. Sender role: Bidder Content: Bid.
*/
public static final KnownEvent KE_bid=new KnownEvent("bid", Bidder.ROLE_ID, Price.class);
/**
A bidder pays. Sender role: Bidder Content: Payment. */
public static final KnownEvent KE_pay=new KnownEvent("pay", Bidder.ROLE_ID, Money.class);
/**
Notifies to a seller that its sale has been accepted. @param addressee Seller
*/
public static RoleAction saleAccepted(int addressee) {
return new RoleAction("saleAccepted", addressee); }
... }
Hình 4.10. Mã nguồn Java cài đặt Bidder
4.4. Cấu trúc role agent
4.4.1. Cấu trúc hai tầng của hệ thống
Hệ thống đa Agent của chúng ta được phát triển dựa trên môi trường JADE được phân chia thành hai phần [11]: phần phụ thuộc và phần độc lập tương đối với nền JADE (Hình 4.9). Chúng ta phải thấy rằng khơng thể có một bản cài đặt cơ sở tương tác hoàn toàn độc lập với platform mà chúng ta chỉ có thể cố gắng để giảm bớt các phần phụ thuộc platform. Trong ứng dụng này, chúng tôi phát triển một số lớp Java bao gồm cả những lớp độc lập với nền và các lớp gắn với nền JADE.
Hình 4.11. Cấu trúc phân tầng của hệ đa agent dựa trên role
Với cấu trúc như Hình 4.11, chúng ta càng thấy rõ hơn sự tách biệt giữa role và agent. Role và agent là hai thực thể độc lập tương đối với nhau, có thể được phát triển một cách riêng rẽ. Tuy nhiên, nếu tách hai thành phần này khỏi nhau thì khơng thành phần nào có thể hoạt động được trong hệ thống. Khi chưa đảm nhận một role nào đó thì agent chưa có được bất kỳ khả năng nào liên quan đến thương mại. Ngược lại, khi role chưa được agent đảm nhận, role chỉ là tiềm năng, không thể hoạt động được. Chỉ khi agent đảm nhận một role của hệ thống, chúng ta mới có một thành phần hoạt động thực sự, gọi là role agent. Ví dụ, một agent đảm nhận role Bidder, ta gọi role agent này là Bidder agent.
Theo cách này, một role agent thể hiện hai khía cạnh độc lập khi nhìn theo hai cách hướng khác nhau. Một mặt, role agent là các role, là các subject của hệ thống role, mặt khác là các agent của nền JADE. Như vậy, role agent sẽ gồm hai tầng: tầng subject, biểu diễn chủ thể của hệ thống role độc lập với nền và tầng
Môi trường tương tác cục bộ Wrapper layer Ro le y st e m Subject Layer Role A Ro le Re g is tra ti o n Agent 1 Wrapper layer Ro le y st e m Subject Layer Role B Ro le Re g is tra ti o n Agent 2 Server Agent A CL m e ss a g e Jade P la tfor m H ệ th ống rol e A CL m e ss a g e
wrapper là các JADE agent có nhiệm vụ hỗ trợ tầng subject. Vấn đề đặt ra là kết nối giữa hai tầng này để tạo thành một role agent thống nhất. Kết nối giữa tầng subject và tầng wrapper đạt được nhờ hai đối tượng Java, là thể hiện của hai lớp cài đặt hai giao diện RoleSystem và RoleRegistration.
Giao diện RoleSystem cho phép agent thực hiện các thao tác cơ bản để đảm nhận một role như: tìm kiếm role phù hợp, yêu cầu đăng ký đảm nhận…Vì vậy, giao diện này có các phương thức sau:
reqRegistration: để đăng ký đảm nhận một role nào đó với hệ thống. Khi
đó server agent sẽ ghi nhận agent yêu cầu và trả về một đối tượng cài đặt giao diện RoleRegistration để cho phép agent sử dụng role đã yêu cầu.
SearchForRole, SearchForRoleNoWait: tìm kiếm agent đảm nhận một role,
có hoặc khơng thời gian chờ nhất định. Nếu là NoWait thì ngay khi tìm thấy một agent đảm nhận role cần tìm hoặc tìm thấy một đăng ký mới phù hợp phương thức sẽ lập tức trả về giá trị. Nếu không sẽ trả về một mảng các đăng ký đảm nhận role của các agent.
Giao diện RoleRegistration cho phép agent thực hiện các thao tác trên hệ thống thông qua một đăng ký cụ thể (tức là sau khi đã đảm nhận thực sự một role nào đó). Giao diện này sẽ có các phương thức sau:
listen, listenNoWait: lắng nghe để nhận biết một sự kiện xảy ra. Đối với
các phương thức khơng có thời gian chờ, chúng sẽ đóng băng (blocking) cho đến khi có một sự kiện xảy ra. Phương thức này sẽ trả về giá trị là một đối tượng của lớp event hoặc null.
doAction: để thực hiện một hành động bất kỳ.
whoAmI: để biết định danh gắn với đăng ký role của chính role Agent đó.
4.4.2. Quá trình tương tác giữa các role agent
Trong mỗi role, sự kiện được cài đặt bằng các trường dữ liệu tĩnh còn hành động bằng phương thức tĩnh (Hình 4.8) Mỗi khi role agent chọn thực hiện một hành động bằng cách gọi phương thức tương ứng của role, một instance RoleAction sẽ được tạo ra. Tuy nhiên, hành động được lựa chọn chỉ có thể thực sự được thực thi khi role agent gọi phương thức doAction của giao diện RoleRegistration. Sau đó,
khi Server agent (agent có nhiệm vụ quản lý các role và role agent) nhận được yêu cầu thực hiện hành động thông qua tầng wrapper, agent này sẽ dịch hành động thành một sự kiện (thuộc lớp RoleEvent).
if (!permissionMatrix.checkPermission(sender.getRole(), addressee.getRole()))
throw new RoleException(RoleException.NOT_ALLOWED);
RoleMsg msgR = new RoleMsg(addresseeID, new RoleEvent(action .getName(), senderID, sender.getRole(),
action.getContent()));
Đầu tiên, Server agent sẽ kiểm tra quyền tương tác giữa role gửi và role nhận. Nếu tương tác không được cho phép, gửi thông báo tương tác không được phép (NOT_ALLOWED) tới role gửi. Ngược lại, tiến hành dịch một hành động thành sự kiện tương ứng bằng đoạn mã dưới đây:
new RoleEvent(action.getName(),senderID,sender.getRole(), action.getContent()));
Cuối cùng, Server agent gửi sự kiện vừa tạo ra tới role agent nhận. Các role agent luôn đợi các sự kiện đến bằng cách gọi thực hiện phương thức listen của giao diện RoleRegistration. Khi sự kiện đến, phương thức listen sẽ trả về một instance của lớp RoleEvent và sau đó agent sẽ đánh giá xem sự kiện này có nằm trong số các sự kiện mà nó có thể nhận biết hay không nhờ phương thức match của lớp
KnownEvent.
public boolean match(RoleEvent event) {
return name.equals(event.getName()) && senderRole.equals(event.getSenderRole()) &&
( (contentClass==null && event.getContent()==null) || (contentClass!=null &&
contentClass.isInstance(event.getContent())) ); }
Phương thức match này so sánh các sự kiện đã biết (thể hiện của lớp
KnowEvent) với sự kiện vừa xảy ra (thể hiện của lớp RoleEvent). Nếu trùng tên, trùng địa chỉ bên gửi và nội dung thơng tin thì sự kiện vừa nhận được thuộc tầm quản lý của role đó. Khi đó, role sẽ lấy thơng tin từ sự kiện để xử lý.
4.5. Kết quả thử nghiệm
Mục tiêu của hệ thống đấu giá trước hết minh họa quá trình thương lượng đấu giá tự động giữa các agent, sau đó là lợi ích của việc sử dụng role cho hoạt động đấu giá. Một số mục tiêu khác như sự thân thiện đối với người dùng, tính cơng bằng giữa các bên tham gia đấu giá cũng được đặt ra. Sau khi cài đặt hệ thống, chúng tơi đã chạy thử nghiệm chương trình và khảo sát kết quả thu được khi thay đổi một số thông số khác nhau như số lượng Bidder tham gia vào một phiên đấu giá, gia số giá và thời gian chờ giữa các lần trả giá…. Sau đây là một vài kết quả thực nghiệm đối với hệ thống đấu giá đã thực hiện.