SlideShare a Scribd company logo
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 specification
component decomposition and organization,
communication protocols, control and data flow
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 efficiency 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 find 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
-flexibility
-adaptability
-code reusability
1.2. Software Architectural
Aspects of Multi-agent Systems
 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.
1.2. Software Architectural
Aspects of Multi-agent Systems
 capable of interaction,
 typically by message passing in a predefined 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
1.2. Software Architectural
Aspects of Multi-agent Systems
 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 specifications
of such systems. Some effort in this direction was made by Weyns
(2010).
 Such specifications 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 specific
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 predefined.
 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 efficiency 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-
specific 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 difficult 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 and MAS Organization:
Agent Internal Architecture
 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.
Agents and MAS Organization:
Agent Internal Architecture
 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.
Agents and MAS Organization:
MAS Organization
 Generally speaking, MAS are organized in one of the following
ways:
 hierarchical organization,
 flat 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).
Agents and MAS Organization:
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).
Agents and MAS Organization:
MAS Organization: Flat MAS Organization
Agents and 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.
Agents and MAS 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.
Agents and MAS Organization:
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.
MAS Architectural Properties:
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
MAS Architectural Properties:
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:
MAS Architectural Properties:
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.
MAS Architectural Properties:
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.
MAS Architectural Properties:
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.
MAS Architectural Properties:
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
MAS Architectural Properties:
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.
MAS Architectural Properties:
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.
MAS Architectural Properties:
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.
MAS Architectural Properties:
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:
MAS Architectural Properties:
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.
MAS Architectural Properties:
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.
MAS Architectural Properties:
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.
MAS Architectural Properties:
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.
Federated MAS organization
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.

More Related Content

What's hot

Software architecture
Software architectureSoftware architecture
Software architecture
Udayna
 
Artificial Intelligence: Agent Technology
Artificial Intelligence: Agent TechnologyArtificial Intelligence: Agent Technology
Artificial Intelligence: Agent Technology
The Integral Worm
 
System design
System designSystem design
System design
Anand Grewal
 
Lq3620002008
Lq3620002008Lq3620002008
Lq3620002008
IJERA Editor
 
Gg
GgGg
Adaptive guidance model based similarity for software process development pro...
Adaptive guidance model based similarity for software process development pro...Adaptive guidance model based similarity for software process development pro...
Adaptive guidance model based similarity for software process development pro...
ijseajournal
 
Seminarie Computernetwerken 2012-2013: Lecture I, 26-02-2013
Seminarie Computernetwerken 2012-2013: Lecture I, 26-02-2013Seminarie Computernetwerken 2012-2013: Lecture I, 26-02-2013
Seminarie Computernetwerken 2012-2013: Lecture I, 26-02-2013
Vincenzo De Florio
 
Class notes
Class notesClass notes
Scenario based methods
Scenario based methodsScenario based methods
Scenario based methods
JoshuaU1
 
Ooad quest and ans
Ooad quest and ansOoad quest and ans
Ooad quest and ans
dhivyarangasamy
 
Object oriented analysis and design unit- iii
Object oriented analysis and design unit- iiiObject oriented analysis and design unit- iii
Object oriented analysis and design unit- iii
Shri Shankaracharya College, Bhilai,Junwani
 
Can “Feature” be used to Model the Changing Access Control Policies?
Can “Feature” be used to Model the Changing Access Control Policies? Can “Feature” be used to Model the Changing Access Control Policies?
Can “Feature” be used to Model the Changing Access Control Policies?
IJORCS
 
A&D - Use Case Diagram
A&D - Use Case DiagramA&D - Use Case Diagram
A&D - Use Case Diagram
vinay arora
 
Unit 3- requirements for software development
Unit 3-  requirements for software  development Unit 3-  requirements for software  development
Unit 3- requirements for software development
arvind pandey
 
IMPLEMENTATION OF DYNAMIC COUPLING MEASUREMENT OF DISTRIBUTED OBJECT ORIENTED...
IMPLEMENTATION OF DYNAMIC COUPLING MEASUREMENT OF DISTRIBUTED OBJECT ORIENTED...IMPLEMENTATION OF DYNAMIC COUPLING MEASUREMENT OF DISTRIBUTED OBJECT ORIENTED...
IMPLEMENTATION OF DYNAMIC COUPLING MEASUREMENT OF DISTRIBUTED OBJECT ORIENTED...
IJCSEA Journal
 
Graph-Based Algorithm for a User-Aware SaaS Approach: Computing Optimal Distr...
Graph-Based Algorithm for a User-Aware SaaS Approach: Computing Optimal Distr...Graph-Based Algorithm for a User-Aware SaaS Approach: Computing Optimal Distr...
Graph-Based Algorithm for a User-Aware SaaS Approach: Computing Optimal Distr...
IJERA Editor
 
Design engineering
Design engineeringDesign engineering
Design engineering
Preeti Mishra
 
Applying user modelling to human computer interaction design
Applying user modelling to human computer interaction designApplying user modelling to human computer interaction design
Applying user modelling to human computer interaction design
Nika Stuard
 
Multi-Agent Architecture for Distributed IT GRC Platform
 Multi-Agent Architecture for Distributed IT GRC Platform Multi-Agent Architecture for Distributed IT GRC Platform
Multi-Agent Architecture for Distributed IT GRC Platform
IJCSIS Research Publications
 
System analysis and design Class 2
System analysis and design Class 2System analysis and design Class 2
System analysis and design Class 2
Dr. Mazin Mohamed alkathiri
 

What's hot (20)

Software architecture
Software architectureSoftware architecture
Software architecture
 
Artificial Intelligence: Agent Technology
Artificial Intelligence: Agent TechnologyArtificial Intelligence: Agent Technology
Artificial Intelligence: Agent Technology
 
System design
System designSystem design
System design
 
Lq3620002008
Lq3620002008Lq3620002008
Lq3620002008
 
Gg
GgGg
Gg
 
Adaptive guidance model based similarity for software process development pro...
Adaptive guidance model based similarity for software process development pro...Adaptive guidance model based similarity for software process development pro...
Adaptive guidance model based similarity for software process development pro...
 
Seminarie Computernetwerken 2012-2013: Lecture I, 26-02-2013
Seminarie Computernetwerken 2012-2013: Lecture I, 26-02-2013Seminarie Computernetwerken 2012-2013: Lecture I, 26-02-2013
Seminarie Computernetwerken 2012-2013: Lecture I, 26-02-2013
 
Class notes
Class notesClass notes
Class notes
 
Scenario based methods
Scenario based methodsScenario based methods
Scenario based methods
 
Ooad quest and ans
Ooad quest and ansOoad quest and ans
Ooad quest and ans
 
Object oriented analysis and design unit- iii
Object oriented analysis and design unit- iiiObject oriented analysis and design unit- iii
Object oriented analysis and design unit- iii
 
Can “Feature” be used to Model the Changing Access Control Policies?
Can “Feature” be used to Model the Changing Access Control Policies? Can “Feature” be used to Model the Changing Access Control Policies?
Can “Feature” be used to Model the Changing Access Control Policies?
 
A&D - Use Case Diagram
A&D - Use Case DiagramA&D - Use Case Diagram
A&D - Use Case Diagram
 
Unit 3- requirements for software development
Unit 3-  requirements for software  development Unit 3-  requirements for software  development
Unit 3- requirements for software development
 
IMPLEMENTATION OF DYNAMIC COUPLING MEASUREMENT OF DISTRIBUTED OBJECT ORIENTED...
IMPLEMENTATION OF DYNAMIC COUPLING MEASUREMENT OF DISTRIBUTED OBJECT ORIENTED...IMPLEMENTATION OF DYNAMIC COUPLING MEASUREMENT OF DISTRIBUTED OBJECT ORIENTED...
IMPLEMENTATION OF DYNAMIC COUPLING MEASUREMENT OF DISTRIBUTED OBJECT ORIENTED...
 
Graph-Based Algorithm for a User-Aware SaaS Approach: Computing Optimal Distr...
Graph-Based Algorithm for a User-Aware SaaS Approach: Computing Optimal Distr...Graph-Based Algorithm for a User-Aware SaaS Approach: Computing Optimal Distr...
Graph-Based Algorithm for a User-Aware SaaS Approach: Computing Optimal Distr...
 
Design engineering
Design engineeringDesign engineering
Design engineering
 
Applying user modelling to human computer interaction design
Applying user modelling to human computer interaction designApplying user modelling to human computer interaction design
Applying user modelling to human computer interaction design
 
Multi-Agent Architecture for Distributed IT GRC Platform
 Multi-Agent Architecture for Distributed IT GRC Platform Multi-Agent Architecture for Distributed IT GRC Platform
Multi-Agent Architecture for Distributed IT GRC Platform
 
System analysis and design Class 2
System analysis and design Class 2System analysis and design Class 2
System analysis and design Class 2
 

Viewers also liked

Multi-agent systems
Multi-agent systemsMulti-agent systems
Multi-agent systems
R A Akerkar
 
Agent architectures
Agent architecturesAgent architectures
Agent architectures
Antonio Moreno
 
T0. Multiagent Systems and Electronic Institutions
T0. Multiagent Systems and Electronic InstitutionsT0. Multiagent Systems and Electronic Institutions
T0. Multiagent Systems and Electronic Institutions
EASSS 2012
 
Foundations of Multi-Agent Systems
Foundations of Multi-Agent SystemsFoundations of Multi-Agent Systems
Foundations of Multi-Agent Systems
Andrea Omicini
 
Topic 1 lecture 2
Topic 1 lecture 2Topic 1 lecture 2
Topic 1 lecture 2
farshad33
 
Topic 1 lecture 3-application imapct of mas&t
Topic 1 lecture 3-application imapct of mas&tTopic 1 lecture 3-application imapct of mas&t
Topic 1 lecture 3-application imapct of mas&t
farshad33
 
|.doc|
|.doc||.doc|
|.doc|
butest
 
Chapter 5 design patterns for mas
Chapter 5 design patterns for masChapter 5 design patterns for mas
Chapter 5 design patterns for mas
farshad33
 
Chapter 6 agent communications--agent communications
Chapter 6 agent communications--agent communicationsChapter 6 agent communications--agent communications
Chapter 6 agent communications--agent communications
farshad33
 
Auctions
AuctionsAuctions
Auctions
Mukesh Kumar
 
Presentation
PresentationPresentation
Presentation
Marlon Etheredge
 
Topic 1 lecture 1
Topic 1 lecture 1Topic 1 lecture 1
Topic 1 lecture 1
farshad33
 
Multiagent systems (and their use in industry)
Multiagent systems (and their use in industry)Multiagent systems (and their use in industry)
Multiagent systems (and their use in industry)
Marc-Philippe Huget
 
FIPA's mentoring program brochure
FIPA's mentoring program brochureFIPA's mentoring program brochure
FIPA's mentoring program brochure
TIVIA ry
 
Study and development of methods and tools for testing, validation and verif...
 Study and development of methods and tools for testing, validation and verif... Study and development of methods and tools for testing, validation and verif...
Study and development of methods and tools for testing, validation and verif...
Emilio Serrano
 
My research proposal slides.
My research proposal slides.My research proposal slides.
My research proposal slides.
Bu Sawoo
 
Jade V
Jade VJade V
Jade V
tmtm99
 
Introduction to Agents and Multi-agent Systems (lecture slides)
Introduction to Agents and Multi-agent Systems (lecture slides)Introduction to Agents and Multi-agent Systems (lecture slides)
Introduction to Agents and Multi-agent Systems (lecture slides)
Dagmar Monett
 
All about agents jade
All about agents jadeAll about agents jade
All about agents jade
Aryan Rathore
 
Final m.tech ppt_praveen
Final m.tech ppt_praveenFinal m.tech ppt_praveen
Final m.tech ppt_praveen
praveen dwivedi
 

Viewers also liked (20)

Multi-agent systems
Multi-agent systemsMulti-agent systems
Multi-agent systems
 
Agent architectures
Agent architecturesAgent architectures
Agent architectures
 
T0. Multiagent Systems and Electronic Institutions
T0. Multiagent Systems and Electronic InstitutionsT0. Multiagent Systems and Electronic Institutions
T0. Multiagent Systems and Electronic Institutions
 
Foundations of Multi-Agent Systems
Foundations of Multi-Agent SystemsFoundations of Multi-Agent Systems
Foundations of Multi-Agent Systems
 
Topic 1 lecture 2
Topic 1 lecture 2Topic 1 lecture 2
Topic 1 lecture 2
 
Topic 1 lecture 3-application imapct of mas&t
Topic 1 lecture 3-application imapct of mas&tTopic 1 lecture 3-application imapct of mas&t
Topic 1 lecture 3-application imapct of mas&t
 
|.doc|
|.doc||.doc|
|.doc|
 
Chapter 5 design patterns for mas
Chapter 5 design patterns for masChapter 5 design patterns for mas
Chapter 5 design patterns for mas
 
Chapter 6 agent communications--agent communications
Chapter 6 agent communications--agent communicationsChapter 6 agent communications--agent communications
Chapter 6 agent communications--agent communications
 
Auctions
AuctionsAuctions
Auctions
 
Presentation
PresentationPresentation
Presentation
 
Topic 1 lecture 1
Topic 1 lecture 1Topic 1 lecture 1
Topic 1 lecture 1
 
Multiagent systems (and their use in industry)
Multiagent systems (and their use in industry)Multiagent systems (and their use in industry)
Multiagent systems (and their use in industry)
 
FIPA's mentoring program brochure
FIPA's mentoring program brochureFIPA's mentoring program brochure
FIPA's mentoring program brochure
 
Study and development of methods and tools for testing, validation and verif...
 Study and development of methods and tools for testing, validation and verif... Study and development of methods and tools for testing, validation and verif...
Study and development of methods and tools for testing, validation and verif...
 
My research proposal slides.
My research proposal slides.My research proposal slides.
My research proposal slides.
 
Jade V
Jade VJade V
Jade V
 
Introduction to Agents and Multi-agent Systems (lecture slides)
Introduction to Agents and Multi-agent Systems (lecture slides)Introduction to Agents and Multi-agent Systems (lecture slides)
Introduction to Agents and Multi-agent Systems (lecture slides)
 
All about agents jade
All about agents jadeAll about agents jade
All about agents jade
 
Final m.tech ppt_praveen
Final m.tech ppt_praveenFinal m.tech ppt_praveen
Final m.tech ppt_praveen
 

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

Software Architecture
Software Architecture Software Architecture
Software Architecture
ssuser9d62d6
 
Lecture-_-5-_SDA_software design and architecture.doc
Lecture-_-5-_SDA_software design and architecture.docLecture-_-5-_SDA_software design and architecture.doc
Lecture-_-5-_SDA_software design and architecture.doc
esrabilgic2
 
Unit 1
Unit 1Unit 1
Object oriented analysis and design unit- iv
Object oriented analysis and design unit- ivObject oriented analysis and design unit- iv
Object oriented analysis and design unit- iv
Shri Shankaracharya College, Bhilai,Junwani
 
Intelligent Buildings: Foundation for Intelligent Physical Agents
Intelligent Buildings: Foundation for Intelligent Physical AgentsIntelligent Buildings: Foundation for Intelligent Physical Agents
Intelligent Buildings: Foundation for Intelligent Physical Agents
IJERA Editor
 
Design Engineering is a topic of software engineering of second year fourth s...
Design Engineering is a topic of software engineering of second year fourth s...Design Engineering is a topic of software engineering of second year fourth s...
Design Engineering is a topic of software engineering of second year fourth s...
38aartidhage
 
Sda 2
Sda   2Sda   2
An agent based approach for building complex software systems
An agent based approach for building complex software systemsAn agent based approach for building complex software systems
An agent based approach for building complex software systems
Icaro Santos
 
Organizational security architecture for critical infrastructure
Organizational security architecture for critical infrastructureOrganizational security architecture for critical infrastructure
Organizational security architecture for critical infrastructure
Luxembourg Institute of Science and Technology
 
Software Patterns
Software PatternsSoftware Patterns
Software Patterns
Sudarsun Santhiappan
 
Software Architecture Design for Begginers
Software Architecture Design for BegginersSoftware Architecture Design for Begginers
Software Architecture Design for Begginers
Chinh Ngo Nguyen
 
Software Architecture.ppt
Software Architecture.pptSoftware Architecture.ppt
Software Architecture.ppt
MuhammadTalha416221
 
SA_UNIT_1.pptx
SA_UNIT_1.pptxSA_UNIT_1.pptx
SA_UNIT_1.pptx
ShwetaGajbhiye12
 
chapter-1 Software Design.pptx
chapter-1 Software Design.pptxchapter-1 Software Design.pptx
chapter-1 Software Design.pptx
haroon451422
 
A Survey of Service Oriented Architecture Systems Maintenance Approaches
A Survey of Service Oriented Architecture Systems Maintenance Approaches A Survey of Service Oriented Architecture Systems Maintenance Approaches
A Survey of Service Oriented Architecture Systems Maintenance Approaches
ijcsit
 
[2015/2016] Introduction to software architecture
[2015/2016] Introduction to software architecture[2015/2016] Introduction to software architecture
[2015/2016] Introduction to software architecture
Ivano Malavolta
 
Software Architecture and Design Introduction
Software Architecture and Design IntroductionSoftware Architecture and Design Introduction
Software Architecture and Design Introduction
Usman Khan
 
Full Paper
Full PaperFull Paper
Full Paper
Arash Heidarian
 
software engineering Architecture and design Unit 3.pptx
software engineering Architecture and design Unit 3.pptxsoftware engineering Architecture and design Unit 3.pptx
software engineering Architecture and design Unit 3.pptx
SomnathMule5
 
Presenting an Excusable Model of Enterprise Architecture for Evaluation of R...
Presenting an Excusable Model of Enterprise  Architecture for Evaluation of R...Presenting an Excusable Model of Enterprise  Architecture for Evaluation of R...
Presenting an Excusable Model of Enterprise Architecture for Evaluation of R...
Editor IJCATR
 

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

Software Architecture
Software Architecture Software Architecture
Software Architecture
 
Lecture-_-5-_SDA_software design and architecture.doc
Lecture-_-5-_SDA_software design and architecture.docLecture-_-5-_SDA_software design and architecture.doc
Lecture-_-5-_SDA_software design and architecture.doc
 
Unit 1
Unit 1Unit 1
Unit 1
 
Object oriented analysis and design unit- iv
Object oriented analysis and design unit- ivObject oriented analysis and design unit- iv
Object oriented analysis and design unit- iv
 
Intelligent Buildings: Foundation for Intelligent Physical Agents
Intelligent Buildings: Foundation for Intelligent Physical AgentsIntelligent Buildings: Foundation for Intelligent Physical Agents
Intelligent Buildings: Foundation for Intelligent Physical Agents
 
Design Engineering is a topic of software engineering of second year fourth s...
Design Engineering is a topic of software engineering of second year fourth s...Design Engineering is a topic of software engineering of second year fourth s...
Design Engineering is a topic of software engineering of second year fourth s...
 
Sda 2
Sda   2Sda   2
Sda 2
 
An agent based approach for building complex software systems
An agent based approach for building complex software systemsAn agent based approach for building complex software systems
An agent based approach for building complex software systems
 
Organizational security architecture for critical infrastructure
Organizational security architecture for critical infrastructureOrganizational security architecture for critical infrastructure
Organizational security architecture for critical infrastructure
 
Software Patterns
Software PatternsSoftware Patterns
Software Patterns
 
Software Architecture Design for Begginers
Software Architecture Design for BegginersSoftware Architecture Design for Begginers
Software Architecture Design for Begginers
 
Software Architecture.ppt
Software Architecture.pptSoftware Architecture.ppt
Software Architecture.ppt
 
SA_UNIT_1.pptx
SA_UNIT_1.pptxSA_UNIT_1.pptx
SA_UNIT_1.pptx
 
chapter-1 Software Design.pptx
chapter-1 Software Design.pptxchapter-1 Software Design.pptx
chapter-1 Software Design.pptx
 
A Survey of Service Oriented Architecture Systems Maintenance Approaches
A Survey of Service Oriented Architecture Systems Maintenance Approaches A Survey of Service Oriented Architecture Systems Maintenance Approaches
A Survey of Service Oriented Architecture Systems Maintenance Approaches
 
[2015/2016] Introduction to software architecture
[2015/2016] Introduction to software architecture[2015/2016] Introduction to software architecture
[2015/2016] Introduction to software architecture
 
Software Architecture and Design Introduction
Software Architecture and Design IntroductionSoftware Architecture and Design Introduction
Software Architecture and Design Introduction
 
Full Paper
Full PaperFull Paper
Full Paper
 
software engineering Architecture and design Unit 3.pptx
software engineering Architecture and design Unit 3.pptxsoftware engineering Architecture and design Unit 3.pptx
software engineering Architecture and design Unit 3.pptx
 
Presenting an Excusable Model of Enterprise Architecture for Evaluation of R...
Presenting an Excusable Model of Enterprise  Architecture for Evaluation of R...Presenting an Excusable Model of Enterprise  Architecture for Evaluation of R...
Presenting an Excusable Model of Enterprise Architecture for Evaluation of R...
 

Recently uploaded

বাংলাদেশ অর্থনৈতিক সমীক্ষা (Economic Review) ২০২৪ UJS App.pdf
বাংলাদেশ অর্থনৈতিক সমীক্ষা (Economic Review) ২০২৪ UJS App.pdfবাংলাদেশ অর্থনৈতিক সমীক্ষা (Economic Review) ২০২৪ UJS App.pdf
বাংলাদেশ অর্থনৈতিক সমীক্ষা (Economic Review) ২০২৪ UJS App.pdf
eBook.com.bd (প্রয়োজনীয় বাংলা বই)
 
Chapter 4 - Islamic Financial Institutions in Malaysia.pptx
Chapter 4 - Islamic Financial Institutions in Malaysia.pptxChapter 4 - Islamic Financial Institutions in Malaysia.pptx
Chapter 4 - Islamic Financial Institutions in Malaysia.pptx
Mohd Adib Abd Muin, Senior Lecturer at Universiti Utara Malaysia
 
Pride Month Slides 2024 David Douglas School District
Pride Month Slides 2024 David Douglas School DistrictPride Month Slides 2024 David Douglas School District
Pride Month Slides 2024 David Douglas School District
David Douglas School District
 
How to Make a Field Mandatory in Odoo 17
How to Make a Field Mandatory in Odoo 17How to Make a Field Mandatory in Odoo 17
How to Make a Field Mandatory in Odoo 17
Celine George
 
Life upper-Intermediate B2 Workbook for student
Life upper-Intermediate B2 Workbook for studentLife upper-Intermediate B2 Workbook for student
Life upper-Intermediate B2 Workbook for student
NgcHiNguyn25
 
World environment day ppt For 5 June 2024
World environment day ppt For 5 June 2024World environment day ppt For 5 June 2024
World environment day ppt For 5 June 2024
ak6969907
 
Hindi varnamala | hindi alphabet PPT.pdf
Hindi varnamala | hindi alphabet PPT.pdfHindi varnamala | hindi alphabet PPT.pdf
Hindi varnamala | hindi alphabet PPT.pdf
Dr. Mulla Adam Ali
 
Executive Directors Chat Leveraging AI for Diversity, Equity, and Inclusion
Executive Directors Chat  Leveraging AI for Diversity, Equity, and InclusionExecutive Directors Chat  Leveraging AI for Diversity, Equity, and Inclusion
Executive Directors Chat Leveraging AI for Diversity, Equity, and Inclusion
TechSoup
 
Pengantar Penggunaan Flutter - Dart programming language1.pptx
Pengantar Penggunaan Flutter - Dart programming language1.pptxPengantar Penggunaan Flutter - Dart programming language1.pptx
Pengantar Penggunaan Flutter - Dart programming language1.pptx
Fajar Baskoro
 
Advanced Java[Extra Concepts, Not Difficult].docx
Advanced Java[Extra Concepts, Not Difficult].docxAdvanced Java[Extra Concepts, Not Difficult].docx
Advanced Java[Extra Concepts, Not Difficult].docx
adhitya5119
 
DRUGS AND ITS classification slide share
DRUGS AND ITS classification slide shareDRUGS AND ITS classification slide share
DRUGS AND ITS classification slide share
taiba qazi
 
Pollock and Snow "DEIA in the Scholarly Landscape, Session One: Setting Expec...
Pollock and Snow "DEIA in the Scholarly Landscape, Session One: Setting Expec...Pollock and Snow "DEIA in the Scholarly Landscape, Session One: Setting Expec...
Pollock and Snow "DEIA in the Scholarly Landscape, Session One: Setting Expec...
National Information Standards Organization (NISO)
 
MARY JANE WILSON, A “BOA MÃE” .
MARY JANE WILSON, A “BOA MÃE”           .MARY JANE WILSON, A “BOA MÃE”           .
MARY JANE WILSON, A “BOA MÃE” .
Colégio Santa Teresinha
 
C1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptx
C1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptxC1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptx
C1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptx
mulvey2
 
Azure Interview Questions and Answers PDF By ScholarHat
Azure Interview Questions and Answers PDF By ScholarHatAzure Interview Questions and Answers PDF By ScholarHat
Azure Interview Questions and Answers PDF By ScholarHat
Scholarhat
 
Natural birth techniques - Mrs.Akanksha Trivedi Rama University
Natural birth techniques - Mrs.Akanksha Trivedi Rama UniversityNatural birth techniques - Mrs.Akanksha Trivedi Rama University
Natural birth techniques - Mrs.Akanksha Trivedi Rama University
Akanksha trivedi rama nursing college kanpur.
 
How to Build a Module in Odoo 17 Using the Scaffold Method
How to Build a Module in Odoo 17 Using the Scaffold MethodHow to Build a Module in Odoo 17 Using the Scaffold Method
How to Build a Module in Odoo 17 Using the Scaffold Method
Celine George
 
The simplified electron and muon model, Oscillating Spacetime: The Foundation...
The simplified electron and muon model, Oscillating Spacetime: The Foundation...The simplified electron and muon model, Oscillating Spacetime: The Foundation...
The simplified electron and muon model, Oscillating Spacetime: The Foundation...
RitikBhardwaj56
 
The Diamonds of 2023-2024 in the IGRA collection
The Diamonds of 2023-2024 in the IGRA collectionThe Diamonds of 2023-2024 in the IGRA collection
The Diamonds of 2023-2024 in the IGRA collection
Israel Genealogy Research Association
 
Community pharmacy- Social and preventive pharmacy UNIT 5
Community pharmacy- Social and preventive pharmacy UNIT 5Community pharmacy- Social and preventive pharmacy UNIT 5
Community pharmacy- Social and preventive pharmacy UNIT 5
sayalidalavi006
 

Recently uploaded (20)

বাংলাদেশ অর্থনৈতিক সমীক্ষা (Economic Review) ২০২৪ UJS App.pdf
বাংলাদেশ অর্থনৈতিক সমীক্ষা (Economic Review) ২০২৪ UJS App.pdfবাংলাদেশ অর্থনৈতিক সমীক্ষা (Economic Review) ২০২৪ UJS App.pdf
বাংলাদেশ অর্থনৈতিক সমীক্ষা (Economic Review) ২০২৪ UJS App.pdf
 
Chapter 4 - Islamic Financial Institutions in Malaysia.pptx
Chapter 4 - Islamic Financial Institutions in Malaysia.pptxChapter 4 - Islamic Financial Institutions in Malaysia.pptx
Chapter 4 - Islamic Financial Institutions in Malaysia.pptx
 
Pride Month Slides 2024 David Douglas School District
Pride Month Slides 2024 David Douglas School DistrictPride Month Slides 2024 David Douglas School District
Pride Month Slides 2024 David Douglas School District
 
How to Make a Field Mandatory in Odoo 17
How to Make a Field Mandatory in Odoo 17How to Make a Field Mandatory in Odoo 17
How to Make a Field Mandatory in Odoo 17
 
Life upper-Intermediate B2 Workbook for student
Life upper-Intermediate B2 Workbook for studentLife upper-Intermediate B2 Workbook for student
Life upper-Intermediate B2 Workbook for student
 
World environment day ppt For 5 June 2024
World environment day ppt For 5 June 2024World environment day ppt For 5 June 2024
World environment day ppt For 5 June 2024
 
Hindi varnamala | hindi alphabet PPT.pdf
Hindi varnamala | hindi alphabet PPT.pdfHindi varnamala | hindi alphabet PPT.pdf
Hindi varnamala | hindi alphabet PPT.pdf
 
Executive Directors Chat Leveraging AI for Diversity, Equity, and Inclusion
Executive Directors Chat  Leveraging AI for Diversity, Equity, and InclusionExecutive Directors Chat  Leveraging AI for Diversity, Equity, and Inclusion
Executive Directors Chat Leveraging AI for Diversity, Equity, and Inclusion
 
Pengantar Penggunaan Flutter - Dart programming language1.pptx
Pengantar Penggunaan Flutter - Dart programming language1.pptxPengantar Penggunaan Flutter - Dart programming language1.pptx
Pengantar Penggunaan Flutter - Dart programming language1.pptx
 
Advanced Java[Extra Concepts, Not Difficult].docx
Advanced Java[Extra Concepts, Not Difficult].docxAdvanced Java[Extra Concepts, Not Difficult].docx
Advanced Java[Extra Concepts, Not Difficult].docx
 
DRUGS AND ITS classification slide share
DRUGS AND ITS classification slide shareDRUGS AND ITS classification slide share
DRUGS AND ITS classification slide share
 
Pollock and Snow "DEIA in the Scholarly Landscape, Session One: Setting Expec...
Pollock and Snow "DEIA in the Scholarly Landscape, Session One: Setting Expec...Pollock and Snow "DEIA in the Scholarly Landscape, Session One: Setting Expec...
Pollock and Snow "DEIA in the Scholarly Landscape, Session One: Setting Expec...
 
MARY JANE WILSON, A “BOA MÃE” .
MARY JANE WILSON, A “BOA MÃE”           .MARY JANE WILSON, A “BOA MÃE”           .
MARY JANE WILSON, A “BOA MÃE” .
 
C1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptx
C1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptxC1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptx
C1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptx
 
Azure Interview Questions and Answers PDF By ScholarHat
Azure Interview Questions and Answers PDF By ScholarHatAzure Interview Questions and Answers PDF By ScholarHat
Azure Interview Questions and Answers PDF By ScholarHat
 
Natural birth techniques - Mrs.Akanksha Trivedi Rama University
Natural birth techniques - Mrs.Akanksha Trivedi Rama UniversityNatural birth techniques - Mrs.Akanksha Trivedi Rama University
Natural birth techniques - Mrs.Akanksha Trivedi Rama University
 
How to Build a Module in Odoo 17 Using the Scaffold Method
How to Build a Module in Odoo 17 Using the Scaffold MethodHow to Build a Module in Odoo 17 Using the Scaffold Method
How to Build a Module in Odoo 17 Using the Scaffold Method
 
The simplified electron and muon model, Oscillating Spacetime: The Foundation...
The simplified electron and muon model, Oscillating Spacetime: The Foundation...The simplified electron and muon model, Oscillating Spacetime: The Foundation...
The simplified electron and muon model, Oscillating Spacetime: The Foundation...
 
The Diamonds of 2023-2024 in the IGRA collection
The Diamonds of 2023-2024 in the IGRA collectionThe Diamonds of 2023-2024 in the IGRA collection
The Diamonds of 2023-2024 in the IGRA collection
 
Community pharmacy- Social and preventive pharmacy UNIT 5
Community pharmacy- Social and preventive pharmacy UNIT 5Community pharmacy- Social and preventive pharmacy UNIT 5
Community pharmacy- Social and preventive pharmacy UNIT 5
 

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

  • 1. Multi-agent Systems: A Software Architecture Viewpoint Onn Shehory and Arnon Sturm
  • 2. 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
  • 3. 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 specification component decomposition and organization, communication protocols, control and data flow and structure, synchronization and access to data, and so forth.
  • 4. 1.1. Introduction to Software Architecture  Applying the most appropriate architecture should reduce development time and increase the efficiency 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
  • 5. 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
  • 6. 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 find 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 -flexibility -adaptability -code reusability
  • 7. 1.2. Software Architectural Aspects of Multi-agent Systems  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.
  • 8. 1.2. Software Architectural Aspects of Multi-agent Systems  capable of interaction,  typically by message passing in a predefined 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
  • 9. 1.2. Software Architectural Aspects of Multi-agent Systems  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 specifications of such systems. Some effort in this direction was made by Weyns (2010).  Such specifications should equip system designers with a family of appropriate solutions for highly distributed problems in open, heterogeneous, dynamic, and information-rich environments.
  • 10. 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
  • 11. 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 specific 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 predefined.  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.
  • 12. 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 efficiency 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.
  • 13. MAS Terminology: Multi-agent infrastructure  Thus providing an infrastructure that enables constructing a domain- specific 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
  • 14. Agents and MAS Organization  These properties and their evaluation should facilitate comparison between, and assessment of, different MAS infrastructures. Architectural Properties agents MAS
  • 15. 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 difficult 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.
  • 16. Agents and MAS Organization: Agent Internal Architecture  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.
  • 17. Agents and MAS Organization: Agent Internal Architecture  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.
  • 18. Agents and MAS Organization: MAS Organization  Generally speaking, MAS are organized in one of the following ways:  hierarchical organization,  flat 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).
  • 19. Agents and MAS Organization: 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.
  • 20.  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). Agents and MAS Organization: MAS Organization: Flat MAS Organization
  • 21. Agents and 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.
  • 22. Agents and MAS 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.
  • 23. Agents and MAS Organization: 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.
  • 24. MAS Architectural Properties  Communication structures and protocols, system openness level, flexibility, infrastructure services, and robustness, also take part in MAS architecture.
  • 25. 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.
  • 26. MAS Architectural Properties: 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
  • 27. MAS Architectural Properties: 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:
  • 28. MAS Architectural Properties: 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.
  • 29. MAS Architectural Properties: 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.
  • 30. MAS Architectural Properties: 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.
  • 31. MAS Architectural Properties: 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
  • 32. MAS Architectural Properties: 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.
  • 33. MAS Architectural Properties: 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.
  • 34. MAS Architectural Properties: 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.
  • 35. MAS Architectural Properties: 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:
  • 36. MAS Architectural Properties: 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.
  • 37. MAS Architectural Properties: 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.
  • 38. MAS Architectural Properties: 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.
  • 39. MAS Architectural Properties: 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.
  • 40. Illustrative Examples  Early MAS Infrastructure  Agent-Agency Infrastructure  Flexible MAS Organization  Federated MAS  FIPA Specifications
  • 41. 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.
  • 42. 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.
  • 43. 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.
  • 44. 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.
  • 45. 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.
  • 46. 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:
  • 47. 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.
  • 48. 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.
  • 49. 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).
  • 50. 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.
  • 51. 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.
  • 52. 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.
  • 53. 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.
  • 55. 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.
  • 56. 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.