• 沒有找到結果。

1Runtime 環境係指包含在代理人平台(Platform)中的 “容器”(Container),而容器是放置 使用者載入代理人的空間。基本上,每一台電腦只有一個代理人平台,而一個代理人平台除 了包含一個預先設定的容器,稱之為主容器(Main Container),同時,使用者可以根據自己 的需求在此代理人平台中增加其他的容器。

圖 43 . DIM 系統環境

在圖 43 的例子中,DA 與三位 UA(UA_1、UA_2 和 UA_3)參與一個分散式的 想法連結工作。在此 DIM 的系統環境中,除了每一個代理人平台之 Main container 包含個自的 AMS 與 DF 外,在 DA 的代理人平台(Platform 4)中,還包括 StA、

ScA、RAS_4、RA_7 和 RA_8;在 UA_1 的代理人平台(Platform 1)中,還包括 RAS_1、RA_5 和 RA_6;在 UA_2 的代理人平台(Platform 2)中,還包括 RAS_2、

RA_1 和 RA_2;在 UA_1 的代理人平台(Platform 3)中,還包括 RAS_3、RA_3 和 RA_4。這些不同代理人平台中的代理人,藉由網路的 HTTP 訊息通訊協定,彼 此傳遞相關的訊息內容予以產生設計結果。

為了更進一步說明 DIM 系統環境中相關的分散式運算機制,以利本研究執行 DIM 代理人,有關代理人的身分定義、生命週期、行為、溝通機制與 Yellow Pages 服務 必須先加以說明。基本上,身分定義提供多重代理人彼此認識而進行溝通,生命 週期則是建立代理人在想法連結過程中 runtime 環境之狀態(如存活、死亡等),

而溝通提供多重代理人之間的訊息傳遞機制,另外,代理人的 Yellow Pages 服務允 許代理人搜尋適當服務內容的代理人,以便進行分散式想法連結的工作。

5.2.1 代理人身分定義

在DIM的系統環境中,所有參與分散式想法連結的DIM代理人(除了DA和UA外), 都需藉由繼承jade.core.Agent class和setup( )的method而產生。

public class RA extends Agent { protected void setup( ) { }

}

為了進行分散式的想法連結,這些DIM中的代理人必須同時存活在不同代理人平 台的容器中,同時,每一個代理人必須藉由jade.core.AID class定義代理人的AID而 彼此認識,以利代理人彼此之間的訊息傳遞。基本上,一個AID物件(object)包 含一個全域性且唯一性的名字和住址,主要以<nickname>@<platform-name>表示 之,例如:有一個RA的nickname為RA1,此代理人存活在一個platform-name為 lai:1099/jade的代理人平台中(1099為預先設定的RMI連接埠),因此,此角色代 理人的AID為RA1@ lai:1099/jade。進而,此代理人的AID可以從下列的語法而執行:

AID id = new AID (RA1@ lai:1099/jade);

5.2.2 代理人生命週期

所謂代理人生命週期是代理人在 runtime 環境中的啟始、終結與其它行為的執行序 列[156]。由於,在分散式的想法連結過程中,代理人會根據不同的設計情境,而 採取適當行為的執行序列以進行不同的相互作用,因此,代理人生命週期在想法 連結過程中是一個必須被考慮的因素。基本上,代理人的生命週期建立在執行序 列的三個階段:代理人起始階段、行為執行階段與終結階段,而這些執行序列主 要藉由 setup( )、doDelete( )、action( )、done( )和 takedown( )而達成(圖 44)。

在起始階段中,代理人必須被啟動而存活在一個代理人平台的容器中,並開始與 其他代理人進行相互作用,然而,在終結階段,代理人被終結而消失在此代理人 平台的容器中,且不能與其他代理人進行相互作用。另外,在行為執行階段,DIM 必須先了解代理人(以 RA_1 為例)是否已經被告知終結(kill)在此環境中,如 果答案為肯定(Yes),則 RA_1 將清除其行為並退場;如果答案為否定(No),則 RA_1 會從自己的啟動行為池(pool of active behavior)中得到下一個行為予以執 行,如果執行完成時,則 RA_1 會從這個啟動行為池中移除這個行為(例如:RA_1 的接收訊息行為執行完成後,會從啟動行為池移除這個接收行為,而自動的得到

下一個連結原則的行為,予以進行想法元件的連結)。上述的流程會被的重複進 行,直到 RA_1 被使用者(UA 或 DA)告知終結並清除這些行為。

圖 44 . 一個 DIM 代理人的生命週期

5.2.3 代理人溝通

在 DIM 的系統環境中,這些代理人的啟始與終結和他們執行行為的序列,主要關 係於代理人在訊息傳遞過程中的溝通機制。基本上,DIM 的溝通機制為非同步性 的訊息傳遞(asynchronous message passing),因此,每一個代理人有一個信箱,或 稱代理人訊息序列(the agent message queue),此信箱為放置其它代理人所寄出的訊 息,當一個訊息被投遞在一個代理人的訊息序列時,此接收的代理人會被通知而 進行此訊息內容的相關行為(圖 45)。

另外,DIM 元素在訊息傳遞中所使用的連結溝通語言(LCL),在此系統環境中,

必須建立在 FIPA 所定義的代理人溝通語言(ACL)的標準。基本上,ACL 主要包 括下列的空格(field):1) 訊息的發送者(sender)、2) 訊息的接收者(receiver)、

(language)與 6)知識實體論(ontology),而這些空格可以分別對應 DIM 之 LCL 元素(詳見 4.4.3 小節),例如:LCL 的語言行動對應於 ACL 的溝通意圖。

圖 45. DIM 系統代理人之溝通機制

因此,一個在 DIM 系統的訊息必須包含相關的 ACL 欄位(slot),並藉由 jade.lang.acl.ACLMessage 的 class 執行成一個物件(objects),予以提供代理人進行 訊息傳遞的相關行為(包括訊息的接收與發送)。架構在 JESS 的機制中,這些 ACL 的空格可以用 JESS 的樣板(template)加以定義,此樣板名稱是 ACLMessage,其 包含了上述 ACL 空格的不同欄位,這些欄位主要提供 DIM 代理人在訊息傳遞的 知識基礎。(有關 JESS 機制的樣板名稱、欄位在 5.3 章節再予以說明)

(deftemplate ACLMessage

(slot communicative-act) (slot sender) (multislot receiver) (slot language) (slot ontology) (slot content)

)

除了上述欄位外,ACLMessage 樣板也包含其他的欄位(如 protocol、envelope、

reply-with、conversation-id 等),有助於 DIM 系統的延伸,並處理 DIM 代理人進 行複雜的溝通機制,包括同時間進行許多對話的控制,或有關超時設定的訊息接 收等問題,有關這些溝通機制與分散式想法連結的關係將為未來的後續研究。

5.2.4 代理人 Yellow Pages 服務

為了提供代理人之間在進行分散式的想法連結過程中,可以找尋到具有相關需求 的代理人進行想法連結(例如:場景代理人找尋具有相關設計技能的角色代理 人),DIM 提供 Yellow Pages 的服務,允許代理人將它們的服務內容公佈,以便讓 其他代理人發現它們。基本上, Yellow Pages 服務包含公佈代理人提供的服務內 容與搜尋所需服務內容的代理人。

在 DIM 系統中,服務內容係指角色代理人的設計技能。角色代理人藉由發佈自己

提供設計技能的服務,提供場景代理人根據不同的議題,搜尋到具有相關設計技 能的角色代理人,以進行此分散式的想法連結(圖 46)。上述的公佈與搜尋服務,

主要藉由使用者代理人與導演代理人之代理人平台的 DF 代理人負責執行。

圖 46 . DIM 的 Yellow Pages 服務

為了公佈服務內容,代理人必須提供適當服務內容的描述(如服務類型、服務名 稱),並藉由 DFService class 中的 register( )的方法予以執行。例如:一個角色代理 人具有住宅型態之設計技能,並從事想法元件連結的設計工作,此角色代理人的 服務類型為“house”,服務名稱為“linking-ideas”,此語法的定義如下:

protected void setup( ) {

DFAgentDescription dfd = new DFAgentDescription( );

dfd.setName(getAID( ));

ServiceDescription sd = new ServiceDescription( );

sd.setType(“house”);

sd.setName(“linking-ideas”);

dfd.addServices(sd);

try {

DFService.register(this, dfd);

}

… }

另外,一個代理人如果要找尋相關服務內容的其他代理人,此代理人必須向 DF 提

供相關服務內容的描述(如服務類型),藉由與上述代理人公佈服務內容的描述相 互比對,進行具有此服務內容代理人的搜尋,此搜尋機制由 DFService class 中的 search( )的方法予以執行。例如:一位場景代理人希望在不同代理人平台中,尋找 具有設計技能和設計工作分別是“house”和“linking-ideas”的角色代理人,以進行分 散式想法連結,其語法定義如下:

protected void setup( ) {

DFAgentDescription template = new DFAgentDescription( );

ServiceDescription sd = new ServiceDescription( );

sd.setType(“house”);

sd.setType(“linking-ideas”);

template.addServices(sd);

try {

DFAgentDescription[ ] result = DFService.search(myAgent, template);

roleAgents = new AID[result.length];

for (int i = 0; i < result.length; ++i) { roleAgents[i] = result.getName( );

} 案中,RA1 可以藉由繼承 jade.core.Agent class 中的 addBehaviour ( )功能,創造 RA1 並賦予它相關行為,其語法如下:

public class RA1 extends Agent { protected void setup( ) {

addBehaviour(new BasicJessBehaviour (this,"c:/DIM/RA1.clp",1));

} }