A Dynamic Architecture for Multi-Agent Systems’ Wenpin Jiao Institute of Computing Technology, CAS F! 0.BOX2704-28 Beijing I00080 I? R. China E-mail: j i a o w p @ i c s .ict.ac.cn
Zhongzhi Shi Institute of Computing Technology, CAS F? 0.BOX2704-28 Beijing I00080 F? R. China E-mail:
[email protected]
Abstract: In this papel; multi-agent systems ore investigated from the point of view of software architectures, and formalized using a process calculus, the pi-calculus. To build a dynamic architecturefor multi-agent systems, two models for agents and multi-agent systems are put forward respectively. Then a kind of architecturefor multi-agent systems, called CARBA which is similar to CORBA, is built based on the roles played by agents in multi-agent systems. Finally, the dynamic characteristics of the architecture are analyzed as well.
1. Introduction Multi-agent systems are very fit for representing those problems with multiply problemsolving methods, multiply views, and multiply entities[ I]. However, the majority of the agent systems are developed in an ad hoc fashion following little or no rigorous design methodology 121. To make multi-agent systems more practical, we might adopt mainstream software engineering tools and techniques to multi-agent development. In this paper, we will study multi-agent systems from the point of view of software architectures [3]. In multi-agent systems, agents are autonomous and their behaviors are parallel; on the other hand, agents are not isolated and the systems may have their own structures in which agents will play different roles. The architectures of multi-agent systems are dynamic, and the dynamic characteristics may be shown in: Agents’ structures are dynamic. The role of an agent playing is determined by what services it can offer in multi-agent systems. Once its role changed, the agent should provide corresponding services, and its structure should also change to adapt to this requirement. The interaction structures between agents are dynamic. At different stage of an agent’s lifetime and when dealing with different problems, the agent’s communicating opposite may change timely. Since the behaviors of agents are concurrent and the architectures of multi-agent systems are dynamic, we can use process algebra to specify these dynamic aspects. In our specifications, all aspects of an agent, such as belief, goal, intention, and actions, are defined as processes. Then the agent is a composition of its behaviors and mental attitudes. Finally, a multi-agent system can be defined by composing a series of concurrent agent processes. In this paper, we choose the polyadic pi-calculus as the formalizing method [4].This is because: ‘Supported by National ‘863’ Hi-Tech Project of China.
0-7695-0393499 510.00 Q 1999 IEEE
253
254
The pi-calculus is a model of concurrent computation based upon the notion of naming, and it is a way of describing and analyzing systems consisting of agents which interact among each other, and whose configuration or neighborhood is continually changing. Behaviors in an agent are crudely concurrent, and an agent is a process-like, concurrent entity. It is difficult for classical or non-classical logic to describe the concurrency among agents, but it is easy for pi-calculus to do so. As we have discussed, the architectures of multi-agent systems are dynamic. It requires that the formal method should be capable of coping with those dynamic aspects, and the picalculus can precisely satisfy this requirement. A good formal method for multi-agent systems should be able to express interactions among agents [ 5 ] . In a logic framework, one should add some non-logic approaches to achieve this goal, whereas the pi-calculus naturally takes the advantage of the ability to describe interactions among agents. In the rest sections, we will first describe formally models for agents and multi-agent systems respectively. Then we will build a dynamic architecture for multi-agent systems according to the roles played by agents in the systems. Finally, we will analyze the dynamic characteristics of the architecture. Conventions: Within all expressions described in the pi-calculus in this paper, processes begin with an upper case letter, whereas names begin with a lower case letter.
2. Model of agents An agent can be used to denote a hardware or software-based computer system situated in a specific environment, which has some properties such as autonomous, pro-active, social ability, and reactive capability. An agent in multi-agent systems consists of components as follows. 1) Mental attitudes, such as knowledge, belief, goal, intention, capability, perception, motivation, and so on. 2) Specifications of the agent’s behaviors, for specifying the mode of the agent’s behaviors. 3)Interface of the agent. It is inevitable for an agent situated in a specific environment to interact with its outside world. The interface will provide a support for interacting. 4)Adaptation module. An agent is autonomous and pro-active, and it can adjust itself to adapt to its environment. In [6], we have described agents’ mental attitudes in details using the polyadic pi-calculus; therefore, we will not define them again in this paper.
2.1. Interface An agent’s interface includes: (1) services the agent can provide, (2) requests to ask for services, and (3) channels for its communicating with others, which are not only the media of services transmitting, but also the ports for sendindaccepting messages.
2.3.1. Services: The process that an agent provides a service can be informally described as “what and to whom the agent will offer”. That is: prov(x,s) =d#
!(hd
(x. y ) ’(?s) I
fact,(s>)
r11
Where, y is the request from outside, s is the service the agent will provide, and x is the place that the service will go. It means that when the agent receives a request for service, it will export the service, meanwhile searching its own knowledge base to query knowledge related to the service to implement the service.
255
2.3.2. Requests: The process that an agent requests for services can be described informally as “what the agent requests - for and where the service should go”. That is: 121 RedW. r ) =d./ r(W,r ) W ( X ) Where, r is the request, w is the place to which the service will be applied, and x is the replied service. It means that the agent first sends a request and announces that where it needs the service, and then waits for reply.
-
2.4. Adaptation.module During an agent’s lifetime, the agent will be learning all the time and mastering new skills or capabilities to provide more services. The agent can adjust itself timely by using its adaptation module, therefore, it can play a new role at an appropriate time when its environment requires. The agent’s adaptability can be shown on the aspects of adjusting its (1) goals, (2) knowledge, and (3) capabilities. The number of goals and capabilities of an agent can be increased, ‘as well as they can be decreased. In this paper, we will only consider the increment or redefinition of goals and capabilities of an agent.
2.4.1. Acquiring new services or capabilities: While an agent is learning and once it finds its knowledge rich enough to achieve autonomously some goal that cannot be achieved before, it will know that it has got some new capability and can provide a new service to others. An agent can update its capabilities via introspecting. While an agent is achieving its goal according to its specification, it will first inspect whether it has possessed enough knowledge to achieve the goal by itself. RenewCap [x = req]((fact,(x)I FactBasedBelief(x)).UpduteCap(x)) [31 Before the agent sends a request req, it will search its knowledge base and judge whether its knowledge is rich enough. If so, it will renew its capability and not send that request again. 2.4.2. Adjusting goals: An agent may adjust its goals for the sake of its own as well as others. When the agent knows that some agent needs its help, it will judge first whether it can meet that requirement. Once the agent has possessed enough knowledge and capabilities to achieve the goal implied in the requirement, i t g a d a p t the goal as one of its new goals. RenewGoul [x = g]((fuct,(x) I FacrBasedBelief(x)).UpdareGoal(x)) 141
3. Model of multi-agent systems In multi-agent systems, people are concerned with how to collect existing agents to cooperate for some common purposes beyond an agent’s competence [ 13. A multi-agent system can be constructed by the following components. 1) Multiply existing agents. 2) Joint intentions among multiply agents, i.e. multiply agents jointly intent team actions that they are jointly committed to complete those team actions [7]. 3) Common sense, i.e. common knowledge among agents. 4) Common specifications for behaviors. Similarly to the specification for behaviors of a single agent, common specifications for behaviors specify actions that multiply agents should take to achieve their joint goals. 5 ) The environment agents rely on, such as network facilities for agents’ communication, other entities coexisting with agents, and users interacting with agents.
256
3.1. Joint intentions
If multiply agents want to achieve a common goal, they should establish appropriate mutual beliefs and commitments [l]. Each agent should believe mutually that others are capable of finishing their own tasks or sub-goals, and only if all agents participating the joint goal have been committed to their own sub-goals, the joint intention can be achieved eventually. Assumed that a joint intention I, is a set of sub-intentions {11,12,...,I"), where some of them can be accomplished by an individual agent (for instance, agents idl,id2,.. .,idkare committed to sub-intentions Il,12,...,Ikrespectively), and others (i.e. Zk+f.. ..,In)are sub-joint intentions which should be jointly completed by several agents. The joint intention can be defined as the following process. Jointlnrention(t,I,) =der jintenrion(t,1,). PI
... ... I (befieve,d,(idl,r,il)I ...Ibefieve,d,(id~-l.t.i~-l)) .intention,d,(t,&) I Jointlntemion(t,jk+J I ...I Jointlntention(r, in) ) Where, the second line indicates that agent idf believes others such as id2, ..., id, will complete ( (befieve,d,(id2,t,i*) I I befieve,d,(idt.r,ik)) .inrention,dt(t.ii)I
their sub-tasks at a specific time t, and it will be committed to a sub-task as well, in which the commitment is done via informing what agent idf should do at time t through the port intention,,. The last line indicates some sub-joint intentions should be refined further.
3.2. Common sense Common sense is a kind of knowledge that all agents in the system have known. To define the common sense process, we should not only point out what the knowledge is, but also provide means for agents to refer to the knowledge. In an individual agent, its knowledge is agent-specific and can only be referred by itself. Nevertheless, in multi-agent systems, common sense is shared by all agents and can be accessed by them. ComrnonSense(x) =dcf sence(id,x ) Sense(x) [61 By receiving messages from port sense, the process knows which agent is trying to access what kind of common sense, and it will query for that knowledge by using sub-process Sense. Meanwhile, common sense is also a part of knowledge of all agents, and each agent can access them by refining its own knowledge process. + CommonSenseBusedBefief ( x ) =de, factid( x ) sense(id,x ) [71
-
-.
-
-
--
3.3. Common specificationsfor behaviors
The common specifications for behaviors in multi-agent systems specify what actions each agent should take to complete joint intentions, i.e. the responsibility of each agent. Meanwhile, the specifications stipulate the relationships among agents' behaviors, such as the dependence and executing orders of those behaviors. JointZntenrionSpec(z,) TuskDisputch(~ j ) I JZntentionScheduZe(zj ) [81 Where, the sub-process TuskDisputch allocates tasks, and JintentionSchedule plans the actions of multiply agents.
4.Architecture of multi-agentsystems In the community of multiply agents, agents are playing different roles because of their
257
Client/Applicalion
CARBA Facilities
Agents
(server Agents)
Common Sense
CARBA Services
Figure 1. The architecture CARBA of multi-agent systems Like CORBA, the aim we construct CARBA is to provide transparent communications and cooperation among agents by creating transparent links between client agents and server agents via agent request brokers. In CARBA: 1)Agent request brokers are agents who can coordinate others’ behaviors and are responsible for transmitting requests and responses and dynamically establishing links between client agents and server agents in the distributed environment. Meanwhile, the brokers manage and maintain common senses in multi-agent systems, and provide a series of CARBA services such as lifecycle, security, and naming. 2) The facilities of CARBA are composed of a series of server agents who can individually or cooperatively provide services for other agents. 4.1. Client/application agents Client/application agents are responsible for interacting with users to provide domainspecific applications. In CARBA, while a client agent asks for services to achieve its goals, it needs not know who can provide services it requests, and can ask an agent request broker to query the services and the responding server agent. Queryberuice(r) =de, q ( r ) . r(s) Req(w,s) [91 It means that the client agent sends the request name r through port q to agent request brokers to query who can satisfy the request, and then waits for a response from an agent request broker. After the client agent receives the identity of the server agent, it sends the request directly to that server agent for service by using the sub-process Req defined as above. By learning from others, once the client agent knows who can provide services it needs, it can directly establish a request link with the server agent instead of asking for agent request brokers’ help. [I01 DirecrService(r) =del Req(w,r ) I (r(x,y ) Snid(X? y ) )
.
-
258
It means that while the client agent is sending a service request (i.e. Req(w,r)), it will capture the request r(x,y) and directly transmit the request to the agent nid.
4.2. Server agents A server agent can provide services to others, but it need not know whom it will provide to; and it replies with its services only when those services are requested. In CARBA, there are no direct links between server agents and client agents, and requests from client agents are transmitted via agent request brokers. In order that brokers can find the correct server agent who can provide requested services and transmit requests to the server agent, a server agent should announces its capabilities to brokers, i.e. service registration, for services querying. An agent knows what services it is capable of providing, and the service registration acts as a procedure to provide brokers knowledge about “capable of providing some service”. EnrollService enroll(id)aid Service,d VI1 It will transmit a pointer to a specific service to brokers.
-
4.3. Broker agents
In CARBA, broker agents act as connectors between client and server agents. The brokers take charge of (1) transmitting requests and responses between client and server agents, (2) establishing communicating links, (3) managing common senses in the systems, (4) coordinating agents’ behaviors, and (5) assisting other brokers to provide CARBA services, A broker agent has all features as a normal agent, and it may have some special characteristics such as containing common knowledge and common specifications for behaviors. Before broker agents can assist client and server agents to establish communicating links, they should first collect capabilities of server agents in order to query services when some client agents request. The process corresponding to the service - registration is defined as follows. EnrolledService=de/ enroll(x) x - Sld r121 It will obtain a pointer to the service exported by a service registration process. The service querying process is defined as follows. r131 ReplyService(r) = d.f (vs)q(x) [ x = slx(s Id) After the process receives a request x from a client agent, it will judge first whether there is a specific service s corresponding to that request. If so, the process will transmit the address of the server agent who can provide the service in order that the client agent can establish communicating link with the server agent.
-
4.4. Analyzing dynamic characteristics of the architecture As pointed out above, the dynamic characteristics of the architecture of multi-agent systems are shown on two aspects: (1) an agent’s structure, and (2) the communicating configuration of agents. Since an agent is capable of adapting itself to its environment, and it can learn and introspect timely to improve its knowledge and capabilities in order to adjust its behaviors, the dynamic characteristics of its structure can be reflected from its adaptation capability. Therefore, in the following context, we will put more attentions on the later aspect.
4.4.1. The Dynamic communicating configurations: As we have pointed out above, client agents obtain their requesting services via broker agents. When a broker agent receives a
259
request from a client agent, it should first query server agents who can provide the service and then assist to establish communicating links between the client agent and the server agent. This procedure can be defined as a process calculus computation as follows. Querysemi ce(r) I ReplyServr ce(r) I Prov(x,s)
- -
-
= ( q ( r ) r ( s ) R e q ( w , s ) )I ((vr)q(x) [ x = rl&d) -+
( d s ) Req(w.8)) I( ( v r ) b= rI?sd))
+ ( r ( s ) R e q ( w , s ) )I ( ; ( s d ) ) -+ ( R e q ( w , s , d )
-
I( ! ( s d ( x . y )
I ( ! ( s d (x, y ) . (%)
I( ! ( s d ( x . y )
- 6%~) I facr,(s)))
-
fact,($)))
(&) I
1 fact,(s)))
I(!(s~(x,Y).(;(s)I~(s))
= s , d ( w . s d . w ( x ) l (!(Sld(X,Y).(;(S)Ifacf.(s))) -+ w ( x ) I(W(s)I fact,,(s)) I Ns”i( x . y ) * (?s) I facr(s))) Where, the first three lines indicate that the client ageit is communicating with a broker instead of a server agent. Until after the communication in the third line finishes, in which the broker sends s,,, to the client agent through port r, the client agent establishes a link with the server agent. After the fourth line, the client agent will communicate with the server agent and the server agent will directly transmit the service to the client agent. That indicates the communicating configuration among the client, the server and the broker is changing during communicating. The change of communicating configuration described above is temporary. Once the client agent obtains the service provided by the server agent, the link between these two agents will be disconnected. In sub-section 4.1,we defined a process for a client agent to request services directly from a server agent. After the client agent has learned which server agent can provide the requested service, it can establish a link with the server agent by itself. In that case the client agent needs no longer brokers to assist to build a temporary link while it requests for the same service again. That indicates that the communicating configuration has changed permanently.
4.4.2. The dynamic system structures: In multi-agent systems, the system structures will be evolving timely. For example, once all client agents know which server agents can provide services, they may communicate directly with server agents instead of asking brokers for helps. In this case, the system mode will degenerate into a typical clienUservermode. Meanwhile, a server agent may learn from some broker agents by asking for brokers’ providing knowledge. Once the server agent has enough capabilities to act as a broker, it can evolve into a broker agent and enter the agent request brokers layer. Thus, even though some broker agent cannot be charged with its responsibility, there are other agents who can replace it on time, which will make the system more reliable. The roles’ conversion, for instance a server agent converts into a broker, is another kind of changes of the system’s structures.
5. Summary In this paper, we investigate the architecture of multi-agent systems and its dynamic characteristics from a new point of view of software architectures, and adopt a formal method of software engineering to study multi-agent systems. To build a dynamic architecture for multi-agent systems, we put forward an agent model first. In that model, an agent can not only interact with others via its interface, but also autonomously adjust its role and its behavior specifications to adapt to its environment. And then we describe a multi-agent system model, which is composed of some existing autonomous agents who have common goals and are restricted under common specifications. After that, we establish a kind
260
of architecture for multi-agent systems, called CARBA which is similar to CORBA, which is based on the roles played by agents in multi-agent systems. Finally, we analyze the dynamic features of that architecture on the aspects of its communicating structures and system structures. While we are describing the models of agents and multi-agent systems and the architecture of multi-agent systems, we describe them and their components formally in the polyadic picalculus. At next stage, we will study cooperation and cooperative protocols among agents based on that architecture of multi-agent systems. Further more, we will build an agent-oriented software development environment using that architecture.
References [I] Nicholas R. Jennings, Katia Sycara, and Michael Wooldridge. A Roadmap of Agent Research and Development. Int. Journal of Autonomous Agents and Multi-Agent System, 1(1), pp.275-306, 1998. [2] Frances
M..T. Brazier, Barbara M. Dunin-Keplicz, Nick R. Jennings, and Jan Treur. DESIRE: Modeling Multi-Agent Systems in a Compositional Formal Framework. Int. Journal of Cooperative Information Systems, 6(I), pp.67-94, 1997.
[3] Mary Shaw and David Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, April 1996. [4] R. Milner. The polyadic IT-calculus: a tutorial, in Logic and Algebra of Specification, ed. EL.Bauer, W. Brauer and H. Schwichttenberg, Springer Verlag, 1993, pp.203-246. [5] Mark dhverno, Michael Fisher, et.al. Formalisms for Multi-Agent Systems. The Knowledge Engineering Review, 12(3), 1997. [6] Wenpin Jiao and Zhongzhi Shi, Formalizing Agent’s Attitudes with the Polyadic pi-Calculus. in Proceedings of the Fourth Workshop on Practical Reasoning and Rationality (IJCAI’99 workshop KRR-I). 1999. [7] H. J. Levesque, P. R. Cohen, and J. H. T. Nunes. On acting together. In Proceedings of the Eighth
National Conference on Artificial Intelligence ( M I - 9 0 ) , pp.94-99, Boston, MA, 1990. [8]A. H. Bond and L. Gasser, editors. Readings in Distributed Artificial Intelligence. Morgan Kaufmann Publishers: San Mateo, CA, 1988.
[9] Http://www.acl.lanl.gov/CORBA, ‘The Object Management Group’s Common Object Request Broker Architecture”. 1996.
