第2期 LI Xining ,et al Dispatching mobile Agents for DDM applications ·185 tion.Once a database has been disconnected,all and migrate back to its stationary server,or invoke resources allocated for this connection are released dispatch($oneway_messenger,'home',Results) and the connection handler is no longer valid. to create a messenger which is responsible to deliv- To facilitate DDM applications,the IMA GO er Results to the home server. system provides two different ways of database ac- Communication among agents takes place by cess operations,namely,the set retrieval and the means of an Agent Communication Language tuple retrieval.The former returns the entire (ACL).The essence of an ACL is to make data matching data set to the requesting agent,whereas mining agents understanding the purpose and the latter allows the requesting agent to consume meaning of their exchanged data.In general,a the matching data on the tuple by tuple basis.For message consists of two aspects,namely,perfor- example,to issue a database query,a simple predi-mative and content.The performative specifies the cate db query (conn,sql)can be invoked,purpose of a message and the content gives a con- where argument sql represents a standard SQL crete description for achieving the purpose.In or- statement.If the query succeeds,user may either der to facilitate open standards of ACL's,the I- issue a subsequent call to db_store_result(+conn,MA GO agent-based communication model is in rest,+options)to save the entire result set into compliance with the FIPA ACL message structure the agent's memory as a two dimensional list,or specification!Of course,the performative and to db_use_data(+conn,-rest)to initiate the result content of a message often determine the reaction set and then issue a sequence of calls to db_next_ of the receiver.In addition to the various types of row(+rest,row,+options)for row-wise data system built-in messengers for sending agents,the processing,and finally invoke a db_free_result ( IMA GO system provides a set of predicates for re- rest)when all rows have been exhausted. ceiving agents.The predicate which is similar to an In a DDM application,agents are not working unblocking receive is accept(Sender,Msg).An in- alone and they need to communicate with each oth- vocation to this procedure succeeds if a matching er to cooperate and generate a global data aggrega-messenger is found,or fails if either the caller's tion for further analysis.Most existing mobile a- messenger queue is empty or there is no matching gent systems adopt some kind of communication messenger in the queue.Likewise,the predicate models/protocols from traditional distributed sys- which implements the concept of blocking receive tems.However,the IMA GO system adopts a dif- is wait_accept(Sender,Msg).A call to this proce- ferent strategy to cope with this issue.The idea is dure succeeds immediately if a matching messenger to deploy intelligent mobile messengers for inter-a- is found.However,it will cause the caller to be gent communication!31.Messengers are thin agents blocked if either the caller's messenger queue is dedicated to deliver messages.Like normal agents, empty,or no matching messenger can be found.In a messenger can move,clone,and make decisions. this case,it will be automatically re-executed when Unlike normal agents,a messenger is anonymous a new messenger attaches to the caller's messenger and its special task is to track down the receiving queue.Pragmatically,the semantics of matching agent and reliably deliver messages in a dynamic, messengers is implemented by logic unification. changing environment.The IMA GO system pro- 3 A simple example of DDM appli- vides a set of built-in messengers as a part of its programming interface.A data-mining agent at cation any remote sites and at any time may dispatch mes- In order to illustrate the usage of the IMA GO sengers to deliver data to designated receivers.For database facilities,we show a very simple example example,suppose that a mobile agent has comple- in this section.Although not very practical,this ted its data mining work at a remote database serv- example provides a typical sample of how to deploy er,it can either call move('home')to carry results mobile agents in DDM applications.As a reference 1994-2009 China Academic Journal Electronic Publishing House.All rights reserved.http://www.cnki.nettion. Once a database has been disconnected , all resources allocated for t his connection are released and t he connection handler is no longer valid. To facilitate DDM applications , the IMA GO system p rovides two different ways of database ac2 cess operations , namely , the set retrieval and the t uple retrieval. The former ret urns t he entire matching data set to t he requesting agent , whereas t he latter allows t he requesting agent to consume t he matching data on the t uple by t uple basis. For example , to issue a database query , a simple predi2 cate db _ query ( + conn , + sql) can be invoked , where argument sql rep resents a standard SQL statement. If t he query succeeds , user may eit her issue a subsequent call to db_store_result ( + conn , ? rest , + options) to save the entire result set into t he agent’s memory as a two dimensional list , or to db_use_data ( + conn , 2rest) to initiate the result set and t hen issue a sequence of calls to db_ next _ row ( + rest , ? row , + options) for row2wise data processing , and finally invoke a db_free_result ( + rest) when all rows have been exhausted. In a DDM application , agents are not working alone and they need to communicate wit h each oth2 er to cooperate and generate a global data aggrega2 tion for f urt her analysis. Mo st existing mobile a2 gent systems adopt some kind of communication models/ protocols from traditional distributed sys2 tems. However , the IMA GO system adopts a dif2 ferent strategy to cope wit h t his issue. The idea is to deploy intelligent mobile messengers for inter2a2 gent communication [ 13 ] . Messengers are thin agents dedicated to deliver messages. Like normal agents , a messenger can move , clone , and make decisions. Unlike normal agents , a messenger is anonymous and its special task is to track down t he receiving agent and reliably deliver messages in a dynamic , changing environment. The IMA GO system p ro2 vides a set of built2in messengers as a part of its programming interface. A data2mining agent at any remote sites and at any time may dispatch mes2 sengers to deliver data to designated receivers. For example , suppose t hat a mobile agent has comple2 ted its data mining work at a remote database serv2 er , it can eit her call move‘( home’) to carry results and migrate back to its stationary server , or invoke dispatch ( oneway_messenger ,‘home’, Results) to create a messenger which is responsible to deliv2 er Results to t he home server. Communication among agents takes place by means of an Agent Communication Language (ACL) . The essence of an ACL is to make data mining agents understanding t he p urpose and meaning of their exchanged data. In general , a message consists of two aspects , namely , perfor2 mative and content. The performative specifies t he p urpose of a message and t he content gives a con2 crete description for achieving t he p urpose. In or2 der to facilitate open standards of ACL’s , the I2 MA GO agent2based communication model is in compliance with the FIPA ACL message struct ure specification [14 ] . Of course , t he performative and content of a message often determine t he reaction of t he receiver. In addition to t he various types of system built2in messengers for sending agents , t he IMA GO system provides a set of p redicates for re2 ceiving agents. The predicate which is similar to an unblocking receive is accept (Sender , Msg) . An in2 vocation to t his procedure succeeds if a matching messenger is found , or fails if either t he caller’ s messenger queue is empty or t here is no matching messenger in t he queue. Likewise , t he predicate which implements the concept of blocking receive is wait_accept (Sender , Msg) . A call to t his proce2 dure succeeds immediately if a matching messenger is found. However , it will cause the caller to be blocked if eit her t he caller’ s messenger queue is empty , or no matching messenger can be found. In t his case , it will be automatically re2executed when a new messenger attaches to t he caller’s messenger queue. Pragmatically , t he semantics of matching messengers is implemented by logic unification. 3 A simple example of DDM appli2 cation In order to illustrate t he usage of t he IMA GO database facilities , we show a very simple example in t his section. Although not very p ractical , this example provides a typical sample of how to deploy mobile agents in DDM applications. As a reference 第 2 期 L I Xi2ning ,et al :Dispatching mobile Agents for DDM applications ·185 ·