Topic 4 -software architecture viewpoint-multi-agent systems-a software architecture-viewpoint

Multi-agent Systems:
A Software Architecture
Viewpoint
Onn Shehory and Arnon Sturm

Introduction to Software
Architecture
Software
Architecture
(SA)
increase in size and
complexity of
software systems
specification and
design
important
software
engineering
discipline
Methodologies
to develop the solution focus on specific
problem types or
solution types.
Identification of the
preferred architecture

Software Architecture
Abstract level SA involves the description of components of
which systems are comprised, the interaction
among these components, and the patterns
according to which the components are
combined to form the whole system.
Practical level SA refers to the design and speciﬁcation
component decomposition and organization,
communication protocols, control and data ﬂow
and structure, synchronization and access to
data, and so forth.

1.1. Introduction to Software
Architecture
 Applying the most appropriate architecture should reduce
development time and increase the efﬁciency and adequacy of
the resulting computational solution.
Solving a
computational
problem
1) Analyze the problem,
its characteristics, and
typical patterns
2) matched against similar
patterns of problems
encountered in the past
and common software
architectures

1.1. Introduction to Software
Architecture
Framework
what the components that
construct instances of the
architectural style
what the constraints on the
ways in which these
components can be combined
and interact are.
Topology
of the
system
Semantics of
execution
• Software architecture usually employs a common framework.
• The framework adopted in this chapter is based on treating a system as a
collection of components and a set of interactions between these components
(which is practically a MAS framework).
• Once the framework is used to describe styles and systems, one can have a
better understanding of the underlying computational model.
unique components,
interactions, and
constraints

1.2. Software Architectural
Aspects of Multi-agent Systems
 The analysis is typically done at the methodology level, which is at a
higher level of abstraction.
 We ﬁnd it necessary to analyze the relationship between the
software architecture of a MAS and its functionality.
to examine MAS mainly
with respect to their
software architecture
styles
attributes
-robustness
-ﬂexibility
-adaptability
-code reusability

 Viewing them as a software architecture style, MAS are
systems comprising components called agents.
 The agents are usually designed to be autonomous, where
autonomy refers to a component not depending on the properties
or the states of other components for its functionality.
MAS
analysis of MAS
should provide
whether:
1) a is an appropriate
computational solution
to a problem at hand
2)what type of MAS
provides the most
appropriate solution for
this problem.

 capable of interaction,
 typically by message passing in a predeﬁned protocol (agent
communication languages, e.g., FIPA-ACL and KQML).
 no direct function call or implicit event invocation between
components (that is, the agents) are allowed.
 the autonomy of an agent a means that although others can
request a service S which is provided by a, it has the sole control
over the activation of its service S and may refuse to provide it, or
ask for a (monetary) compensation for its service.
MAS
components

 Several architectural styles have been recognized and described in
the general SE literature; however, agents and MAS architectures
which are well-documented are not widely recognized by
practitioners.
 With the increase in the number of MAS industrial solutions, it is
necessary to increase the visibility and the accessibility of
agent and MAS architectures.
 Due to their unique suitability to several classes of computational
problems, it is important to characterize MAS as a software
architecture style and to provide the architectural speciﬁcations
of such systems. Some effort in this direction was made by Weyns
(2010).
 Such speciﬁcations should equip system designers with a family of
appropriate solutions for highly distributed problems in open,
heterogeneous, dynamic, and information-rich environments.

MAS Terminology:
Agent architecture
 For example, agents (in the context of MAS) usually have a
communication module to facilitate communication with other.
 Some types of agents have internal AI modules such as a reasoning
module or a planning module.
 Incoming messages received by the communication module may affect
reasoning and planning (e.g., reason to understand the effects of the
message and plan to address these effects).
 The internal AI modules may create outgoing messages to be processed
and sent out by the communication module.
Agent
architecture
modules relationships interactions
from which a single
agent is comprised
between, and
the among these modules

MAS Terminology:
MAS organization
 MAS organization describes the way in which a collection of
agents is organized to form a MAS.
 Relationships and interactions among the agents and speciﬁc
agents’ roles within the organization are the focus of MAS
organization.
 The agent architecture is not part of the MAS organization (although
interrelations between the two may exist).
 For instance, the agents may be organized in a rigid hierarchy in
which the interrelations are predeﬁned.
 This may reduce the need to locate other agents and reason about
them, and the amount of communication necessary for the system
to function well.

MAS Terminology:
Multi-agent services
 Multi-agent services include services aimed to support a
variety of MAS needs.
 The service types listed below are examples of multi-agent
services:
 Dynamic organizational activity facilitation, notably agent location and
coordination mechanisms (possibly implemented by means of
middleware or middle agents)
 Increased system efﬁciency and resource utilization (e.g., technologies
for network sensing, mobility facilitation, dynamic resource allocation
and load balancing)
 Agent and MAS activation, interfacing and testing tools (possibly
delivered as part of agent frameworks)
 Security infrastructure and services (for protecting the agents,
information they hold and transactions they perform)
 Multi-agent services are usually associated with the MAS
infrastructure.

MAS Terminology:
Multi-agent infrastructure
 Thus providing an infrastructure that enables constructing a domain-
speciﬁc MAS.
 Commonly, the infrastructure is associated with services which facilitate
MAS activity and organization (e.g., agent naming service, agent
directory service, agent execution platform, etc.).
 The terms above are elaborated upon in the following sections to
facilitate the discussion of agent architectures.
Multi-agent infrastructure
agent
architecture
MAS
organization
multi-agent
services
dependencies dependencies

Agents and MAS Organization
 These properties and their evaluation should facilitate
comparison between, and assessment of, different MAS
infrastructures.
Architectural
Properties
agents MAS

Agents and MAS Organization:
Agent Internal Architecture
 Over the years, a large variety of agent internal architectures
were introduced by agent researchers and practitioners.
 Major focus on MAS architectures.
 It is important to note that the incorporation of an agent
architecture in a MAS may in times be difﬁcult or not possible
at all.
 This is because, for agents to be incorporated into MAS, it is
necessary to equip them with components that facilitate
interaction with other agents and users (e.g., communication
and cooperation components).
 Additionally, being part of a MAS imposes restrictions on the
admissible interactions among the agents.

 Agents, either stand-alone or as part of a MAS, must be able to
exhibit:
 behaviours
 perform tasks
 provide services
 Regardless of their internal architecture.
 In similarity to the information hiding provided via encapsulation in
object-oriented programming, agent designers and developers
typically prefer that the details of an agent’s internal
architecture be hidden from other agents and users.
 Will allow entities with which the agent interacts to assume some
capability of the agent’s and some interaction protocols,
 but will prevent the need that they know what methods and
components are employed by the agent to behave, perform its tasks,
and provide its services.

 In practice, although information hiding is a desired
architectural property, it is not always present in agent
implementations.
 Often, agents that take part in a MAS do assume some type and
structure with respect to the agents with which they interact.
 Another aspect of internal agent architecture is its influence on
the overall MAS behavior and the ability of the MAS to efficiently
perform its tasks.
 Although such influence seems an inevitable property of MAS, no
extensive software engineering research was performed to
investigate this issue.

MAS Organization
 Generally speaking, MAS are organized in one of the following
ways:
 hierarchical organization,
 ﬂat organization (in times referred to as democracy),
 subsumption organization, and
 modular organization.
 Hybrids of these and dynamic changes from one organization
style to another are also possible, though not very common in
implemented MAS (probably due to the complexity of implementing
dynamic reorganization and the limited merit stemming from it).

MAS Organization: Hierarchical MAS Organization
We summarize below the properties of these MAS organizational models.
 Hierarchical MAS (e.g., federated MAS) are organized such that
agents can only interact (and in times only communicate) subject to a
hierarchical structure.
 A prominent advantage of the hierarchical structure in MAS is:
 the significant reduction in complexity, and therefore in communication, in
the system.
 there is no need for a mechanism for agent registry and location, which are
commonly part of MAS infrastructure.
 For example, in Sect. 4.4, where we present a federated MAS, the
components in the upper level of the hierarchy, the facilitators, are in charge
of locating agents.
 The disadvantage of the hierarchical organization is:
 the rigid structure, which does not allow agents to dynamically organize
themselves to best fit varying needs and specific tasks.
 Further, typically the hierarchy implies that the lower-level agents
depend on the higher-level agents (e.g., in OAA), and higher-level
agents may even be in partial or full control of the lower-level agents.
 This may contrast requirements for agent autonomy and for agent
self-interest.

 A flat organization of a MAS implies that each agent can directly contact any of the
other agents.
 No fixed structure is imposed on the system; however, agents may dynamically form
structures to perform specific tasks.
 In addition, no control of one agent by another agent is assumed.
 Such an organization requires that either the system is closed in the sense that each
agent knows all of the others ahead of time, or (when the system is open) an agent
location mechanism must be provided as part of the infrastructure.
 A flat organization is advantageous since it fully supports autonomy and self-interest
of agents as well as distribution and openness of the MAS.
 It also allows for dynamic adjustments of the MAS organization to changes in tasks and
the environment.
 However, openness and dynamism come at a cost:
 they impose communication overheads,
 a need for agent location mechanisms, and
 a need for mechanisms for dynamic MAS reorganization.
 Additionally, the amount of reasoning an agent performs with regard to other agents
(and consequently the local computational overhead of an agent) increases significantly
in a flat organization.
 An example of a flat MAS organization is presented in Sect. 4.1. MAS based on the Jade
platform are another example of a flat organization (although other organizations can be
implemented using Jade).
MAS Organization: Flat MAS Organization

MAS Organization: Subsumption MAS Organization
 There are MAS where some agents are components of other agents.
 These agents are subsumed by the container agents, which in turn may be
components of larger container agents. The subsumption model, which takes its
roots in robotics, however, applies well to distributed AI and MAS in general.
 It has some similarity with the hierarchical model; however, it takes it to the
extreme by requiring that the subsumed agents completely surrender to the
control of the container agent.
 From a software architectural viewpoint, such architecture resembles an inclusion
of objects within a larger object, except for the (important) difference in the
control methods.
 That is, while objects are usually controlled and activated by (possibly remote)
procedure call or by event invocation, agents are activated by high-level
communication, i.e., message transmission.
 The strict control relationships in the subsumption organization, which result in
efficient task execution and low communication overhead, however, restrict the
system to address a well-defined set of tasks, with limited flexibility and
adaptability.
 It is also not simple to modify a subsumption MAS (e.g., add a new component)
in the face of long-term changes in tasks and the environment of the system.
 An example of a MAS with a subsumption organization.

MAS Organization: Modular MAS Organization
 A MAS exhibits a modular organization when it is comprised of
several modules, where each of these modules can be perceived
as a virtually stand-alone MAS.
 Typically, the partition of the system into modules is done along
dimensions such as geographical vicinity or a need for intense
interaction among agents and services within the same module.
 Often, the system is comprised of such parts as a result of its
development process, during which new modules were gradually
added to an already existing system.

MAS Organization: Modular MAS Organization
 Modularity increases efficiency of MAS task execution and reduces
communication overhead.
 Also, in similarity to a flat organization, each module exhibits
internal high flexibility.
 On the other hand, cross-module reorganization is rather complex,
hence in this dimension flexibility is limited.
 In addition, modularity implies constraints on inter-module
communication.
 For instance, while intra-module communication is usually
connection-oriented, inter-module communication may be
connectionless, which prohibits the execution of tasks that require
inter-modular concurrency.
 The OSACA system provides an example of a modular MAS
architecture.

MAS Architectural Properties
 Communication structures and protocols, system
openness level, flexibility, infrastructure services,
and robustness, also take part in MAS
architecture.

MAS Architectural Properties:
Communication
 MAS require a specially designed communication protocol that best
fits
 agent architecture
 MAS organization
 the typical tasks of these systems
 For e.g., ARCHON or OAA, which uses an agent communication
language (ACL) developed specifically for OAA agents.
 MAS increasingly rely on standard communication languages
and protocols (typically FIPA2 ACL and protocols), although
proprietary languages and protocols are still in use.
 The advantage of proprietary protocols is in their efficiency:
 the agents are implemented using the same communication
infrastructure and
 transmit only the information necessary with very little overhead and
message packaging and parsing.

Communication
 The major disadvantage:
 the difficulty to facilitate conversations with agents that are not part of
the proprietary communication environment, as it is most unlikely that
other agents will have those specialized communication protocols
implemented in them.
 To overcome this limitation, some MAS platforms implement both a
proprietary and standard communication languages.
 Jade & FIPA-OS do not implement proprietary communication
infrastructure and focus on standard communication protocols
 FIPA-ACL support agent communication languages
 This, however, does not mean that two agents from different
systems that support the same ACL are able to understand each
another.
 Jade, RETSINA and D’Agents some of the publicly available
communication modules

Communication
 Distributed computational systems implement
several standard communication protocols.
 We distinguish three main attributes of such
protocols, which are relevant to MAS and to their
architecture:

Communication
Symmetry: • In many systems, client/server protocols are used for
communication
• They are well-supported and documented as part of
operating systems and programming languages
• Implementations are simple and efficient
• Drawback of client/server protocols is that they imply
asymmetry between the communicating entities: one
is in control of the communication, whereas the other
party can only respond upon request and cannot
initiate communication.
• In proprietary communication—agent communication
is implemented as a client/server architecture.
• Designers of MAS, especially open MAS with a flat
organization, have realized that the asymmetry
associated with such architecture is inappropriate for
these systems and have implemented symmetric
means of communication.
• This, however, increases protocol complexity and may
affect communication speed.

Communication
Message
Recipients:
• Messages in a network may be sent to:
• a single addressee,
• to multiple ones (multicast), and
• to all (broadcast)
• In an open system, broadcast is impractical, since an
agent does not know all of the other agents.
• Therefore, open MAS usually implement peer-to-peer
or multicast communication.
• In closed MAS, however, broadcast is commonly used.
• The advantage of the latter is in the simplicity of the
protocol.
• The disadvantage is that all of the agents receive the
message, even when it is completely irrelevant for
them, thus increasing network congestion.

Communication
Connection
Type:
• Connection-oriented and connectionless
communication are both implemented in MAS.
• The advantages and drawbacks of these are not
unique to MAS, and can be found in standard
networks’ textbooks.
• Typically, MAS implement connection-oriented
communication; however, in some cases
connectionless protocols are supported as well.
• Connection-oriented communication is preferred when
dependent tasks are performed concurrently by
multiple agents, and close coordination is necessary
during execution.
• In such situations, connectionless communication may
prohibit coordination and proper task performance.
• In MAS where task execution is loosely coordinated
and where concurrency is of minor importance,
connectionless communication is sufficient.

System Openness
 The openness of a MAS refers to:
 the ability of introducing additional agents into the system in excess to the
agents that comprise it initially, and
 the capability of agents to leave the system and of the system to cope with
such departures.
 While some MAS architectures do not allow the addition of agents (at
all),
 Others may be more open, allowing to add agents with different
styles of addition.
 In its basic level, MAS openness refers to the OSI (Open Systems
Interconnection) definition of system openness.
 However, in MAS, additional properties are considered. One can
classify MAS openness into three broad categories:
 Dynamic Openness
 Static Openness
 Offline Openness

System Openness: Dynamic Openness
Dynamic
Openness:
• In MAS, the level of dynamism allowed for adding
and removing agents has a significant effect on the
properties of the system.
• MAS that allow agents to leave or join the system
dynamically, during run time, without any explicit
message to all of the other agents in the system, are
the most open ones.
• The advantage of such openness is in the ability of
the system to dynamically adjust itself to changes in
the environment, tasks, and availability of resources.
• A prominent disadvantage of dynamic openness is the
additional services and computation required to
facilitate it.
• When agents can unpredictably appear and disappear,
a robust agent location mechanism is essential.
• Also, agents must be provided with methods to
alternate their tasks execution and planning, since
availability of necessary capabilities and resources
varies over time as the agent population changes.

System Openness: Static Openness
Static
Openness:
• Less dynamic, yet considered open, is the case where agents
can be added to the system without restarting it, but either
all of the agents are notified on such an addition, or they all
hold in advance a list of prospective additional agents.
• This type of openness eliminates the need for a complex
agent location mechanism, and reduces the complexity of
contingent execution and planning computation (although
these are not eliminated).
• On the other hand, the flexibility of the system and its ability
to adjust itself to dynamic changes is restricted.
• Such openness is insufficient for environments with high
levels of uncertainty.
• It can better fit cases in which changes are more gradual
and predictable.
• Online addition of third-party agents is not supported by this
architecture, which in turn limits adaptability of MAS to
changing conditions and tasks.

System Openness: Offline Openness
Offline
Openness:
• The most restricted type of openness is the one that allows the
addition of new agents only offline, by halting the system, adding
agents, updating some connection information, and restarting the
system.
• This approach allows for changes in the system over time; however,
dynamic changes are not supported.
• While this restricts flexibility, it eliminates the need for infrastructure
services and for additional computation to handle dynamic changes in
the system.
• Hence, such systems perform more efficiently in cases of well-
defined, predictable, and relatively static problem domains.
• The classes of MAS openness listed above are part of a wide
spectrum of openness levels and styles.
• Modifications of these classes and hybrids thereof allow gaining
some advantages and compromising others.

Infrastructure Services
 In some MAS infrastructure services are
inseparable from the system, whereas in others
they are optional or even unnecessary.
 We provide details of some of these services:

Infrastructure Services Agent Naming
Agent
Naming
• An open MAS must be provided with an agent naming service, so
that no two agents will have identical names, and the consequent
confusion be avoided.
• Close systems or slightly open systems, where all of the agents (or
the possible ones—in the latter systems) are known in advance do
not need a naming service.
Agent
Location
• Another type of service necessary in open MAS is an agent
location service (e.g., brokering or matchmaking).
• When the existence and availability of agents are not common
knowledge, this service is a precondition to the ability of a MAS to
perform its tasks.
• An agent location service is sometimes implemented in a
centralized manner, which may be simpler to implement and
maintain, however more vulnerable, and creates a single point of
failure of the MAS.
• In contrast, distributed location mechanisms are more complicated
to design, implement, and maintain, and increase communication
and computation overheads; however, they can provide a reliable,
robust service.

Infrastructure Services Agent Location
Security,
Privacy,
and Trust
• Security, privacy, and trust are optional services which
can be very useful in open MAS.
• In such systems, an agent may be uncertain with regards to
the true identity and the trustworthiness of other agents.
• Security mechanisms can reduce the risks that stem from
this uncertainty.
• Security infrastructure is not commonly provided as part
of MAS infrastructure; however, some support to agent trust
and secure transactions among agents can be found.
• For MAS in which such services are absent, the addition of
such services may require introducing trusted third parties
such as electronic Certification Authorities as well as
implementing protocols to be followed by the agents.
• This, inevitably, increases computation (e.g., for encryption
and decryption) and communication (e.g., for reputation
management) overheads, and may create bottlenecks at the
third parties.

Infrastructure Services Agent Naming
Mobility • There is a unique family of MAS—those that allow for
agent mobility (e.g., Agent Tcl, D’Agents, Aglets Jade),
where an infrastructure service that supports mobility
may be required.
• The most common way to provide this service is via
mobility servers, sometimes called agent docks.
• Agent docks are servers which are running on machines
where mobile agents are allowed to arrive.
• The mobile agent “docks” at the dock, and the dock
provides interface and access to resources on that
machine subject to the restrictions applicable to the
arriving agent.
• Mobility servers increase computation overheads on the
machines they run.
• On the other hand, they provide an essential service in
case that mobility is necessary.

System Robustness
 One of the advantages of MAS is the distribution of execution, which
allows for an increase in overall performance.
 In addition, failure of one agent does not necessarily imply a failure of the
whole system.
 The robustness provided by MAS is further increased by replicated
capabilities.
 This replication is enabled by having multiple agents with the same or
similar capabilities in the system.
 In such cases, when an agent that has some capability becomes
unavailable, another agent with a similar capability may be approached.
 Replicated capabilities are more natural (and useful) in open MAS;
however, they can support robustness in close MAS as well.
 The disadvantage of this replication is in the resulting redundancy, which in
times is merely a waste of resources.
 The robustness of a MAS depends also on the type of services it uses and
the way in which these are implemented, as mentioned above.
 Other software architectural properties, although important, are of lesser
significance for the design of multi-agent systems and therefore not
included in the discussion above.

Illustrative Examples
 Early MAS Infrastructure
 Agent-Agency Infrastructure
 Flexible MAS Organization
 Federated MAS
 FIPA Specifications

Earlier MAS infrastructures
 Archon, which provides a system organization as well as agent
internal architecture.
 developed at the time where no agents’ standards and no common
agent communication languages were available
 goal was to reduce the complexity of control in large, complex
(usually pre-existing) computational systems.
 achieved via distribution of execution and control.
 A set of existing domain-specific applications which solve specific
problems are assumed.
 The whole system is comprised of these component systems, and
the MAS infrastructure provided by Archon facilitates this.
 To implement cooperation among the component systems, Archon
provides a layered organization, somewhat similar to the OSI
layered communication protocol.

Early MAS Infrastructure
The Archon agent architecture
SM holds a model
of the IS and
reasons about its
state
The AAM contains
models of other
agents in the
community.
PCM Assesses interactional
situations and plans and
monitors cooperation with
other agents.
The HLCM provides the
other modules with
three key services:
intelligent addressing,
and message filtering
and scheduling.
Monitors and
manages the IS by
checking the states
of its tasks, starting
and stopping tasks,
and supplying data
from external
sources
Provides a model and a
language for information
manipulation, for local
and remote access and
update.

Early MAS Infrastructure
The Archon agent architecture
Layers
Session layer Delivers interconnection services between agents
Archon layer • Is attached to each application to provide two
interfaces:
• one to the underlying application
• one to the rest of the agent community via the
session layer.
• Each Archon layer component controls itself, its
application system, and its interaction with other
agents.
• In the Archon approach, an agent is the combined
entity that includes the application system and its
attached Archon layer.
• The application systems implement domain-specific
functionality, and the Archon layer serves only for
coordination and cooperation among domain-specific
components.

Archon architecture
 To be an open architecture:
 Applications may be added to the whole system by attaching an
Archon layer component to the added domain-specific application.
 Although Archon openness complies with the OSI approach to
openness, it is somewhat confined.
 First, the addition (or removal) of components cannot be done
dynamically.
 Agents can locate (and communicate with) other agents using two
complementing methods:
(1) Hardwired addresses in the local address list of each agent;
(2) Agents broadcast their availability to a single matching services agent,
well known to all agents, which serves as a blackboard-like mechanism.
 The latter constitutes a centralized mechanism which results in a
single point of failure, whereas the former limits the openness of
the system, since only predefined agents can be added to it, or at
least all of the addresses of agents that may potentially join the
system must be known in advance.

Archon architecture
 New agents that appear dynamically cannot add themselves or be added
to the system.
 In the case of dynamic multi-agent systems, such an organization is
somewhat closed.
 Additionally, even when agents are known in advance, their ability to join
the system depends on their ability to appear as Archon agents.
 That is, an agent can be connected to an Archon-based MAS only by using
the Archon session layer, which requires following its communication
protocols.
 OSACA, an Open System for Asynchronous Cognitive Agents, is a
general multi-agent infrastructure which exhibits similar properties
 In addition to its MAS organization, Archon supports agent architecture as
well. An Archon agent architecture is comprised of two components:
 the Archon layer and
 the Intelligent System (IS),
 which the Archon layer interfaces with, and monitors.
 The IS is usually a pre-existing, separately designed, developed, and
implemented component, which does not follow a dictated Archon
architecture.

Modules Functions
Information
management
module (AIM)
Provides a model and a language for information
manipulation, for local and remote access and update.
Two internal modules:
• self model (SM)
• agent
acquaintance
module (AAM)
• SM holds a model of the IS and reasons about its state
• The AAM contains models of other agents in the
community.
Monitor module Monitors and manages the IS by checking the states of its
tasks, starting and stopping tasks, and supplying data from
external sources
Planning and
coordination module
(PCM)
Assesses interactional situations and plans and monitors
cooperation with other agents.
High-level
communication
module (HLCM)
The layer between the session layer and other Archon
modules (collectively referred to as the Archon layer). The
HLCM provides the other modules with three key services:
intelligent addressing, and message filtering and scheduling.
The internal architecture of an Archon layer consists of modules as follows:

Summary: Archon architecture
 Archon is a multi-agent infrastructure with a flat organization and static
openness.
 It allows for cooperation between previously existing specialized systems.
 It supports distributed control of these systems as well as high-level
communication and information exchange among them.
 Archon enables adding new specialized subsystems to the system without
recompiling the system.
 This addition is limited to previously known names and addresses of the
components to be added.
 Archon was designed as a layered architecture.
 Conceptually, each layer may be replaced by a component that complies
with the interface requirements of the adjacent layers.
 Issues such as security, privacy, and trust are not explicitly addressed in
Archon, and mobility is not supported.

Agent-Agency Infrastructure
 ADEPT (Advanced Decision Environment for Process Tasks) is
another example of an early multi-agent infrastructure. It was aimed at
facilitating collaboration among autonomous units of organizations.
 ADEPT suggests a subsumption MAS organization:
 the MAS is comprised of agencies, where each agency may either be:
 a single agent or,
 recursively, a collection of several agencies.
 Communication and cooperative task execution are performed either :
 within an agency,
 among its members, or between agencies,
 However not directly between members of an agency and agents or
agencies outside this agency.
 Each agency is represented by a single responsible agent.
 Consequently, ADEPT can support both hierarchical and flat
organizational structures, and combinations thereof; however, the
specific organization style must be set in advance and cannot be altered
dynamically.
 While this organization is more flexible than the ones provided in
Archon and OSACA, the partition into agencies limits dynamic changes in
organizational structure.

The ADEPT MAS Organization
For example,
agencies 5 and
8, which are
subagencies of
agency 4,
cannot directly
communicate
with agencies 1
and 3.
They can use the
responsible agent 4
to contact entities
external to agency
4 (however, they
are not assumed to
know these
entities).

Agent-Agency Infrastructure: ADEPT
 The ADEPT system organization is depicted in Figure.
 Agents and agencies can only communicate and (directly) cooperate with
agents and agencies within their encapsulating agency.
 In ADEPT, communication requires that agents, agencies, and tasks, which
are all objects, register themselves with an Object Request Broker
(ORB) as defined in the CORBA specifications.
 The ADEPT internal agent architecture is similar to the one provided
by Archon.
 In summary, ADEPT supports a more flexible organization than other
early MAS infrastructures do.
 Yet, dynamic organizational changes are not supported.
 An interesting property of ADEPT is of tasks being autonomous entities.
 This allows mobility of tasks among agents and agencies and thus may
support dynamic mobility and load balancing.
 Issues of openness are not explicitly addressed in ADEPT, and it seems to
allow a rather close openness level.

Flexible MAS Organization
 Examples presented thus far show specific MAS organizations such as
hierarchy, flat organization, and subsumption. Clearly, flexibility in
MAS design is necessary.
 DESIRE is a framework for DEsign and Specification of Interacting
Reasoning components which facilitates such flexibility.
 It was used for developing reusable multi-agent applications. Using
logic, DESIRE enables specification of generic multi-agent models.
 DESIRE specifications are based on compositional, hierarchical
architecture.
 In similarity to object-oriented design, each component has its input
and output interfaces specifications defined and known to other
components, whereas the internal structure is hidden from the rest of
the system.
 This allows for reuse.

Flexible MAS Organization
 DESIRE classifies agent types including reflective, reactive, cognitive, social and
BDI (believe, desire, intend) agents.
 This classification, although important for multi-agent research, has a limited
significance when software architecture properties are examined.
 While reactive and proactive activity of agents can be referred to as software
architecture issues, cognitive and social behaviors are not so.
 Nevertheless, the compositional approach of DESIRE presents interesting
architectural properties.
 Some such properties can be found, e.g., in the weak agent type.
 The DESIRE framework does not dictate a specific agent organization.
 It allows for a variety of organizational styles, each designed to fit the properties of
a specific problem domain.
 This results in flexibility in the design stage of MAS based on DESIRE; however,
once such a system is implemented its organization is no longer flexible or
dynamically adaptable.
 Similarly, agent mobility is not supported, although it can be implemented using an
agent factory (thus providing generative agent migration).
 Issues such as security, privacy, and trust are not explicitly addressed either.
 Communication follows standard inter-object communication architectures.

Federated MAS
 Genesereth and Ketchpel introduce a system organization which consists of agents
and facilitators as a means for interoperability.
 Facilitators and agents are organized into a federated system (see Figure).
 An example of a federated system is OAA.
 The federated organization suggests that agents communicate via facilitators.
 This way, each group of agents who are facilitated by a single facilitator is a
federation in which an agent surrenders some of its autonomy to the facilitator.
 In this organization, the facilitator’s role is to translate messages and direct them to
agents that can handle them.
 In a federated MAS organization, agents can dynamically connect and disconnect
from a facilitator, thus exhibiting dynamic openness.
 Upon connection to a facilitator, an agent specifies its capabilities and needs in an
agent communication language (ACL).
 The federated organization facilitates application interoperability, however,
compromises agent autonomy.
 Flexible interoperability can be supported by other types of middle agents (e.g.,
matchmakers).
 Issues such as security, privacy and trust are not explicitly addressed either but are
partly supported by facilitators.

FIPA Specifications
 FIPA, the Foundation for Intelligent Physical Agents has
produced a set of specifications for various aspects of agent
architectures.
 These focus mainly on the communication and the agent location
aspects of the architecture, e.g., agent communication language and
agent interaction protocols, among others.
 Yet, FIPA does not provide specifications for MAS organization.
 Implicitly, the communication and agent location as specified by FIPA
facilitate a variety of MAS organizations.
 Indeed, specific implementation of FIPA specifications in agent
frameworks (e.g., Jade) suggest several different MAS organizations.
 Dynamic openness is well-supported by FIPA specification and its
implementations.
 Agents from various FIPA-compliant frameworks can interoperate,
and can join MAS dynamically.
 FIPA also has security and mobility specifications.

Conclusion
 Software architecture involves the structure and organization of a software
system as well as non-structural properties associated with the system.
 Many architectural properties presented here are not unique to MAS.
 However, when combined in a single system they typically constitute a MAS,
establishing a unique architectural style.
 This combination and style facilitate the suitability of MAS for solving
problems where information, location, and control are distributed, where
heterogeneous autonomous (i.e., self-controlled) components comprise the
system, where the system is open, the environment is dynamically
changing, and uncertainty is present.
 In some cases, only a subset of these problem domain characteristics is
present.
 This does not mean that MAS are no longer relevant as an architecture and
as a solution approach.
 Yet, in such cases it may be advisable to consider architectures other than
MAS as a solution approach.
 One should bear in mind that the high complexity of MAS and the amount of
code replication in such systems may result in excessive, unnecessary
efforts in the development and maintenance phases as well as inefficient
solution and poor system performance.

Topic 4 -software architecture viewpoint-multi-agent systems-a software architecture-viewpoint

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Topic 4 -software architecture viewpoint-multi-agent systems-a software architecture-viewpoint (20)

Recently uploaded (20)

Topic 4 -software architecture viewpoint-multi-agent systems-a software architecture-viewpoint