An Architectural Description Language for Secure Multi-Agent Systems

Haralambos Mouratidis1,a, Manuel Kolpb, Paolo Giorginic, Stephane Faulknerd aInnovative Informatics Group, School of Computing, IT and Engineering, University of East London, England b Information Systems Research Unit, Catholic University of Louvain (UCL), Belgium c Department. of Information and Communication Technology, University of Trento, Italy d Information Management Research Unit, University of Namur, Belgium

Abstract. Multi-Agent Systems (MAS) architectures are gaining popularity for building open, distributed, and evolving information systems. Unfortunately, despite considerable work in the fields of software architecture and MAS during the last decade, few research efforts have aimed at defining languages for designing and formalising secure agent architectures. This paper proposes a novel Architectural Description Language (ADL) for describing Belief-Desire-Intention (BDI) secure MAS. We specify each element of our ADL using the Z specification language and we employ two example case studies: one to assist us in the description of the proposed language and help readers of the article to better understand the fundamentals of the language; and one to demonstrate its applicability.

Keyword: Architectural Description Language, Multi-Agent Systems, Security, BDI Agent Model, Software Architecture

1 Corresponding Author: [email protected]

1. Introduction However, as the expectations of business stakeholders are changing day after day; and The characteristics and expectations of as the complexity of systems, information new application areas for the enterprise, and communication technologies and such as e-business, knowledge management, organisations is continually increasing in peer-to-peer computing, and web services, today’s dynamic environments; developers are deeply modifying information systems are expected to produce architectures that engineering. Most of the systems designed, must handle more difficult and intricate for this kind of application areas, are now de requirements than ever before. facto concurrent and distributed. They tend A critical issue in the design and to be open and dynamic, in that they exist in construction of any complex information a changing organizational and operational system is its architecture. That is, its gross environment where new components can be organization as a collection of interacting added, modified, or removed at any time. It components. A rigorous architectural design is also important that such systems are can ensure that a system will satisfy key secure, since they are often used for the requirements in such areas as performance, management and storage of sensitive reliability, portability, scalability, and information, such as medical, financial and interoperability [40]. To assist developers in private data. specifying information system architectures, Given these needs, many researchers are architectural description languages are used. looking for paradigms that will enable them An Architectural Description Language to conceptualize, design and implement (ADL) provides a concrete syntax for information systems that can operate specifying architectural abstractions in a effectively in such circumstances. In this descriptive notation. Architectural context, we advocate the use of Multi-Agent abstractions concern the structure of the Systems (MAS) to build today’s enterprise system’s components, their behaviour, and information systems. MAS architectures their interrelationships. appear to be more flexible, modular and Unfortunately, despite the progress on the robust than traditional; including object- field of software architectures (see for oriented ones. MAS do represent dynamic instance [2], [17], [28], [30], [39]) and the and evolving structures and components, simultaneous progress on MAS research; which can change at run-time to benefit few research efforts have aimed at truly from the capabilities of new system entities defining description languages for MAS or replace obsolete ones. Moreover, MAS architectures, and even these do not represent a suitable paradigm for the adequately include important issues of MAS consideration of security challenges such as security. This paper deals with this introduced by the current information problem and it proposes a novel ADL for systems. Security issues, within an agent MAS, which defines a “core” set of system context, will require for the agents of structural, behavioural and security the system to consider the security concepts, including relationships and requirements, when specifying their constraints, which are fundamental for a objectives and interactions, and therefore complete MAS ADL. The language, called cause the propagation of security requirements to the whole system [34].

SKwyRL-ADL2, aims to describe secure world, which force the agent to act and Belief-Desire-Intention (BDI) MAS. react to change in quasi real-time The paper is structured as follows. Section fashion. Pro-activeness means that an 2 overviews the notions of agent and MASs agent’s behaviour is not exclusively and identifies the main concepts of the BDI reactive but it is also driven by internal model, which is used in our ADL. Section 3 goals, i.e. an agent may take initiative. discusses security in MAS and Section 4 With these concepts in mind, a MAS can models SKwyRL-ADL using the Z be defined as a set of autonomous and specification language. An example case proactive agents that interact with each other study is used to assist reader understanding to achieve common or private goals. This of the language’s elements. Section 5 definition leads us to two different types of demonstrates the applicability of the MAS: Cooperative or Competitive. proposed ADL with the aid of a real case A Cooperative MAS has a unique high- study from the e-media domain. Section 6 level global goal (or set of goals) describes related work; it indicates how that decomposed recursively into parallel work has influenced the presented work, and activities to be performed by the set of it discusses how the presented work differs agents that compose that MAS. This kind of from related work. The last section system is typically adapted to perform summarizes the contributions of the paper distributed problem solving. In a and discusses future work. Competitive MAS, each of the component agents has its own set of goals that may or may not meet those of other agents. In this 2. Agents and Multi-Agent Systems case the MAS is an architecture that allows agents to interact, while each one pursues An agent defines a system entity, situated personal goals and defends own interests. in some environment that is capable of This kind of system meets typical flexible autonomous action in order to meet engineering requirements of e-commerce, its design objectives [46]. Three key information retrieval applications, web concepts support this definition: services or peer-to-peer networks. In such • Situatedness: an agent receives input environments, every agent generally from the environment it operates and can represents either a client, aiming at perform actions, which change the obtaining some resources or have some environment in some way; service accomplished; or a provider, aiming • Autonomy: an agent is able to operate at selling resources or services at a certain without direct, continuous supervision. (not necessarily financial) cost. Each agent In other words it has full control over its pursues the goals of the (human or system) own actions; actor it represents, and these goals can • Flexibility: an agent is not only reactive usually be in conflict. but also pro-active. Reactivity means In order to reason about these goals and that an agent has perceptions of the act in an autonomous way, agents are usually built on rationale models and

2 reasoning strategies that have roots in Socio-Intentional ArChitecture for Knowledge various disciplines including Artificial Systems & Requirements ELicitation (www.isys.ucl.ac.be/ skwyrl) Intelligence, Cognitive Science, Psychology

or Philosophy. Agent models are executed one step at a time. A step can proliferating; some include learning query or change the beliefs; it can perform capabilities, others intelligent agendas based actions on the external world; and it can on statistics, others yet are based on genetic submit new goals. The operations performed algorithms and so on. An exhaustive by a step may generate new events that, in evaluation of these models is out of the turn, may start new plans. A plan succeeds scope of this paper or even this research when all its steps have been completed; it work. However, a simple yet powerful and fails when certain conditions are not met. mature model coming from Cognitive Science and Philosophy that has received a great deal of attention, notably in Artificial 3. MAS and Security Intelligence, is the Belief-Desire-Intention (BDI) model [6]. This approach has been Security of software systems, agent- intensively used to study the design oriented, object-oriented or otherwise, is rationale of agents and is proposed as a concerned with methods providing cost keystone model in numerous agent-oriented effective and operationally effective development environments such as JACK3 protection from undesirable events[30]. In or JADE4. The main concepts of the BDI principle security is usually defined in terms agent model are (except the notion of agent of the existence of any of the following itself that we have just explained): properties: Confidentiality: The property of • Beliefs that represent the informational • state of a BDI agent, that is, what the guaranteeing information is only agent knows about itself and the world; accessible to authorized entities and inaccessible to others; • Desires (or goals) that are its motivational state, that is, what the agent • Authentication: the property of proving is trying to achieve; the identity of an entity; Integrity: the property of assuring that • Intentions that represent the deliberative • state of the agent, that is, what plans the the information remains unmodified agent has chosen for possible execution. from source entity to destination entity; In particular, a BDI agent has a set of • Access Control: the property of plans, which defines sequences of actions identifying the access rights an entity and steps available to achieve a certain goal has over system resources; or react to a specific situation. The agent • Non-repudation: the property of reacts to events, which are generated by confirming the involvement of an entity modifications to its beliefs, additions of new in certain communication; goals, or messages arriving from the • Availability: the property of environment or from another agent. An guaranteeing the accessibility and event may trigger one or more plans; the usability of information and resources to agent commits to execute one of them, that authorized entities. is, it becomes its intention. Plans are In MAS, each of these properties is associated with the characteristics of agents and need to be considered during the 3 http://www.agent-software.com.au/jack.html development. For instance, regarding 4 http://jade.tilab.com situatedness [46], the authentication,

confidentiality and availability of an agent (see Section 6 for a discussion of related needs to be considered according to the work), we have identified the following environment in which the agent operates. concepts as the common foundation of On the other hand, the social behaviour concepts and concerns for system property of an agent involves architecture descriptions: communication with other agents and other Component. Components are units of entities and as such the properties of non- computation and data store. Therefore, repudiation, integrity and access control are components are loci of computation and important. Therefore, it is crucial for the state. A component, in architecture, may be agents of a MAS to consider, during run- as small as a single procedure (e.g., Wright time, the systems’ and their individual [1] procedures) or as large as an entire security requirements when specifying their application (e.g., hierarchical components in objectives and interactions. For this to Rapide [28]). It may require its own data happen, agent developers must integrate and/or execution space, or it may share them security considerations when they define the with other components. architecture of their MAS [4]. However, Interface. Interfaces are set of interaction research efforts so far have been mainly points among components and the external focused on the solution of individual world. All ADLs support specification of security problems of MAS, such as attacks component interfaces. They differ in from an agent to another agent, attacks from terminology and the kinds of information a platform to an agent, and attacks from an they specify. For example, each interface agent to a platform. Developers of MAS point in ACME [17]and Wright is called a ADLs have mainly neglected security and port. In UniCon [39], an interface point is a have failed to provide evidence of player, and in Rapide a constituent. In successfully integrating security concepts as Darwin [29], the interface consists of a part of their ADLs. As a result, MAS collection of services that are either developers find no help when considering provided or required. security during the architectural design of a Type. A type describes how architectural MAS. element representation is built up. ADLs can support reuse by modelling abstract components as types and instantiating them 4. SKwyRL: An Architectural Language in an architectural configuration. All the for Secure MAS surveyed ADLs distinguish component types from instances. However, UniCon and 4.1. ADL Concepts Darwin lack explicit means of introducing new component types, as they support only Architectural description languages are a predefined set. Other ADLs such as formal languages that are used to specify the Rapide and Wright make explicit use of architecture of a system [40]. By parameterisation. architecture, we mean the components that Connector. Connectors are used to model compose a system, the behavioural interactions among components and the specification for those components, and the rules that govern those interactions. Some mechanisms for interactions among them. ADLs that model connectors as first-class Based on our analysis of existing literature entities are called explicit configuration

languages, as opposed to in-line extracts of the aGent-Oriented Source configuration languages. The first-class Integration System (GOSIS) architecture to includes languages such as Wright. On the compliment our theoretical description of other hand, Rapide and Darwin are the language. GOSIS provides a MAS examples of in-line configuration languages. architecture that supports the integration of In these languages, connectors cannot be data coming from dynamic, distributed and named. They are described solely in terms heterogeneous sources. GOSIS is a hybrid of bindings between the provided service of approach that combines the advantages of a component and the required service of in-advance and on-demand processes[15]. In another component. such an approach, the user information Configuration. Configurations (or needs can be extracted in-advance or on- topologies) are connected graphs of demand by the mediator. The information components and connectors that describe extracted in-advance is stored in a central architectural structures. Configurations are database managed by the mediator. The needed to determine whether appropriate information contents of this central database components are connected, their interfaces can be seen as a materialized view where the match and their combined semantics result database resides at the information sources. in desired behaviour. Descriptions of In this way, in comparison with a basic configurations enable the assessment of mediator, a hybrid mediator adds concurrent and distributed aspects of functionalities essentially in order to architecture, e.g., potential for deadlocks perform materialized view maintenance. and starvation, performance, reliability, In particular, when a user wishes to send a security, etc. Configurations also enable request, it contacts the broker agent, which analysis for adherence to design heuristics serves as an intermediary to select one or and style constraints. In this sense, a major more mediator(s) that can satisfy the user role of configuration is to facilitate the information needs. Then, the selected understanding of systems at a high level of mediator(s) firstly decomposes the user’s abstraction. Therefore, configurations must query into one or more sub-queries model structural information with simple regarding the appropriate information and understandable syntax. sources and then it eventually compiles and Hierarchical Composition. A synthesizes results from the source and hierarchical composition allows the returns the final result to the broker. When representation of an entire architecture as a the mediator identifies repetitively the same single component in another, larger user information needs, this information of architecture. Several ADLs provide explicit interest is extracted from each source, features to support hierarchical composition. merged with relevant information from the For example ACME provides templates, other sources, and stored as knowledge by Darwin composition elements, and UniCon the mediator. Each of the stored knowledge and Wright maps. bases constitutes a materialized view that the mediator has to keep up-to-date. 4.2. The GOSIS example Moreover, two types of agents, a wrapper and a monitor, are connected to each To assist understanding the specification information source. The wrapper is used to of the language components, we represent translate the sub-query issued by the

mediator in the native format of the source that a port is either a sensor requiring a and also to translate the source response in service or an effector providing a service the data model used by the mediator. The for the agent environment. In this sense, monitor is responsible for detecting changes like Darwin, an interface can be seen as of interest (e.g., a change which affects a a collection of provided or required materialized view) in the information source services. and for reporting them to the mediator. • Type. We introduce parameterisation in Changes are then translated by the wrapper order to distinguish the different and sent to the mediator. instances of each agent type that can It may also be necessary for the mediator appear in a configuration or to expand to obtain information concerning the an agent description from a single localisation of a source, and for the system to families of systems. SKwyRL- associated wrapper to provide current or ADL permits any part of an agent future relevant information. This kind of description to be replaced with a information is provided by the matchmaker “placeholder”, which is then filled with agent, which allows a direct interaction a parameter when the type is between the mediator and the correspondent instantiated. wrapper. The matchmaker plays the role of a • Connector. SKwyRL-ADL follows the “yellow-page” agent. Each wrapper Rapide and Darwin notion of connectors advertises its capabilities by subscribing to according to the definition of agent the yellow page agent. Finally, the multi- interaction that we will discuss in the criteria analyzer reformulates a sub-query following section. (sent by a mediator to a wrapper) through a • Configuration. Because Wright offers set of criteria in order to express the user the most complete and formal definition preferences in a more detailed way, and of configuration specification, we follow refines the possible domain of results. it with the aim of describing a complete system architecture. Like a Wright 4.3. The ADL concepts configuration description, the components (i.e., agent) and connectors Following the identification of the (i.e., bindings between provided and common foundation of components required services) must be combined necessary for an ADL; an architecture based into a configuration. In this sense, in on the proposed SKwyRL-Architectural SKwyRL-ADL, a configuration is a Description Language (ADL) includes the collection of agent instances combined following concepts: via bindings between provided and • Component. In SKwyRL-ADL, we required services. consider an agent as a system • Hierarchical Composition. SKwyRL- component with a set of plans ADL allows for hierarchical determining its computation dimension composition, but provides no specific and a set of beliefs defining its data constructs to support it. In particular, space. SKwyRL-ADL permits replacing basic • Interface. SKwyRL-ADL specifies an components in an architecture by a (sub) interface point in the same way as configuration so as to form a new ACME and Wright, with the difference

configuration. This is done by by one or more detailed lower-level supporting the specification of an agent descriptions.

Architecture Configuration Protection Objective adds 1..* 1..* Security Constraint 1..* restrict imposed 1..* restrict

own Knowledge Base Agent 1..* 1..* 0..* react to has 0..* 1..* 1..* own 1..* 1..* 0..* Security Mechanism Capability

1..* trigger 0..* Belief Security Method Plan Event 1..* 0..* generate

1..* Service 1 generate Goal Action 1..* 1..* 1..* 1 1..* 1..* 1..* 1..* possess connect to Effector Sensor 1..* 1..*

Interface 1

Fig. 1: Conceptualization of SKwyRL-ADL. model; the security model; and the 4.4. Metamodel architectural model. The three following sub-sections describe these models in Figure 1 introduces the main entities and greater detail. Each entity is formalized relationships of the elements of SKwyRL- using the Z specification language [41]. We ADL. Each entity has been identified from have adopted Z in order to formalize the the generic features of current ADLs, from concepts and relationships of our ADL architectural security considerations, and model for a number of reasons. Firstly, Z from the concepts defined through the provides modularity and abstraction and is theoretical BDI architecture model. sufficiently expressive to allow for a For clarity we have further subdivided the consistent, unified and structured account of model into three sub-models: the agent

a software system and its associated more goals that represent its motivational operations. Such structured specifications state. enable the description of MAS architectures The intentional behaviour of an agent is at different abstraction levels, with system represented by its capabilities to react to complexity being added at successive lower events. A capability is a set of events that an levels. Secondly, Z is particularly suitable in agent can handle, post or send to its squaring the demands of formal modelling environment and a set of plans. An event is with the need for implementation by generated either by an action that modifies allowing for transitions between beliefs or adds new goals, or by services specification and software. Our approach to provided by another agent. Note that formalize the specification of SKwyRL is services also appear in the structural model thus pragmatic: we need to be formal to be because they involve interactions among precise about the concepts we discuss, yet agents that compose the MAS. we want to remain directly connected to Interactions serve as basic elements to implementation issues. support the construction of configurations. Furthermore, Z is widely used as formal An event may invoke (trigger) one or more specification language within the software plans; the agent is committed to executing engineering and the artificial intelligence one of them, that is, it becomes its intention. communities. Z has been shown to be clear, A plan defines the sequence of actions or concise and relatively easy to learn services to be chosen by the agent to compared with other languages [27]. accomplish a task or fulfil a goal. An action can query, add or remove beliefs, generate new events or submit new goals. 4.4.1. Agent Model As an example, consider the model shown in Figure 2 representing a partial The agent model, illustrated in Figure 1, is specification of the mediator agent of the composed of eight main design entities. An GOSIS case study. The Mediator agent has a agent needs knowledge about its set of interfaces, Knowledge Bases (KB), environment in order to make good Protection Objectives (PO), Security decisions. Knowledge is contained in an Mechanisms (SM) and a set of Capabilities agent in the form of one or many knowledge (CP). bases structuring its informational state. A This formalization is intended as an knowledge base consists of a set of beliefs intuitive aid to introduce the fundamental that the agent has about its environment. A design entities and relationships, and assist belief represents a view of the current in the comprehension of the ADL. However, environment of an agent. the description level chosen here does not However, beliefs about the current state of specify the details of the beliefs composing the environment are not always enough to the KB; the plans and events composing decide what to do. In other words, in each CP; or the security methods composing addition to a current state description, the each SM. For this reason, the proposed ADL agent needs goal information. A goal supports refinement specification, using the describes an environment state that is (or is Z language, for each of the main aspects of not) desirable. An agent pursues one or the agent: interface, knowledge base, security mechanisms and capabilities.

Agent: { Mediator base simply doesn’t exist. Inversely, Interface: Sensor[require(query_translation)] openWorld states that an agent accepts every Sensor[require(query reformulation)] belief that it “considers” possible [21]. Sensor[require(results)] Although closed-world states do not often Sensor[require(locate_wrapper)] Sensor[require(change_advertizings)] occur in the real world, they are useful in Effector[provide(found_items)] many simulation and programming KnowledgeBase: environments [12]. Results_KB MatchMaker_Info_KB [KBname] DataManagement_KB [KBtype]:= closedWorld | openWorld Request_KB Notification_KB KnowledgeBase Protection Objectives: Confidentiality_PO name: KBname Availability_PO composed_of: ℙ Belief Security mechanisms: type: KBtype DataIntegirty_SM AuthenticationExchange_SM Capabilities: name ≠∅∧composed_of ≠∅∧type ≠∅ Handle_Request_CP (∀kb:KnowledgeBase) (∃ ag : Agent ) •use(kb,ag) Handle_Results_CP Materialized_Views_CP Wrapper_Localization_CP Fig. 3: KnowledgeBase specification. Handle_Change_CP } An example of a KB specification for the

Fig. 2: Partial specification of the GOSIS mediator agent. Mediator agent of the GOSIS system is shown in Figure 4. In particular, three KBs Knowledge base. A knowledge base is a are specified in the agent specification set of beliefs that the agent has about the presented above: the Matchmaker_Info, environment and itself. A knowledge base WrapperSubscription and Translation_Management. (KB) is a means of structuring the The contents of these KBs concern, informational state of agents and it respectively, wrapper localisations and encapsulates a set of states describing a translation abilities; accepted and refused specific part of the current environment of wrapper subscriptions; mediator queries and an agent. Each individual state is called a the specific information needed to translate belief. A knowledge base specification is it. This specific information is represented also described by the type of KB (KBtype) and by the following beliefs: a name that assists to identify the KB. • source_resource that defines the kind of Whenever an agent wants to query or data available from the connected modify a KB, it does so by using this name. source; The set of all names is denoted by [KBname] • source_modeling that describes how the and a KB can be specified as in Figure 3. information is structured; The KBtype describes the kinds of formal • dictionary that provides the term knowledge used by agents that compose the correspondence between the mediator MAS. closedWorld states that an agent knows and the source. only the beliefs included in its knowledge base [25], and anything not in its knowledge

function, constant and variable symbols are KnowledgeBase: { name: MatchMaker_Info_KB denoted by [PredSymb],[Function],[Constant], and composed-of: [Variable], respectively. An AtomicBelief is wrapper(WrapperLocalization,TranslationServ formed from a predicate symbol followed by ice(+)) type: closed_world } a sequence of terms (Figure 5).

KnowledgeBase: { [PredSymb] name:WrapperSubscription_KB [Funtion] composed-of: [Constant] refusal_subscription(Id,TranslationType, [Variable] WrapperLocalization,Reason) [Term]:=Function(Term,…)|Constant| Variable accepted_subscribe(Id,TranslationType, WrapperLocalization,Date) AtomicBelief type: closed_world } head: PredSymb KnowledgeBase: { terms: seq Term name: Translation_Management_KB composed-of: search(RequestType,ProductType,Filte head ≠∅∧terms ≠∅ redKeyword(+)) source_resource(InfoType(+)) source_modeling(SourceType,Relation( Fig. 5: AtomicBelief Specification. +),Attributes(+)) dictionary(MediatorTerm,SourceType,C A Belief is specified either as an orrespondence) type: closed_world} AtomicBelief, a negated AtomicBelief, a series of AtomicBeliefs connected using logic Fig. 4: KB specification for the GOSIS mediator agent. connectives, or an AtomicBelief characterized Belief. A belief is a predicate describing a with a temporal pattern. We use the set of states about the current agent following temporal patterns: ○ (in the next environment being either true or false. state), ● (in the previous state), ◊ (some time Beliefs describe the environment of an agent in the future), ♦ (some time in the past), □ in terms of states of objects with individual (always in the future), ■(always in the past), identities and properties, and relations on W(always in the future unless), and U objects as being either true or false. We use (always in the future until). predicate symbols to specify a particular [Belief]:=AtomicBelief relation that holds (or fails to hold) between |¬AtomicBelief several objects, and terms to represent | Temp_Pattern AtomicBelief objects. Each term can be build from | AtomicBelief Connective AtomicBelief constant, variable or function symbols. [Connective] →∧ | ∨ | ⇒ Constant symbols are therefore terms. But [Temporal_Pattern]:=○ | ● | ◊ | ♦ | □ | ■ |W |U sometimes it is more convenient to use an expression to refer to an object. This is what Goal. A goal describes an environment function symbols are for. Thus a complex state that an agent wants to bring term can be formed by a function symbol about.Beliefs about the current state of the followed by a parenthesized list of terms as environment are not always enough to arguments to the function symbol. decide what to do. In other words, in From the above primitives, we can define addition to a current state description, the an AtomicBelief. The set of all predicate, agent needs goal information, which

describes situations that are (not) desirable. generate actions, plans, or events; maintain Goal information is an operational objective and avoid goals restrict them. When a goal to be achieved by an agent. Operational is required, the agent identifies a set of plans means that the objective can be formulated to achieve or maintain this goal. From then in terms of appropriate state transitions on, the agent chooses, according to its under the control of one agent. We consider current beliefs, which of these plans will be goals according to four patterns [10]: executed. Capability. A capability is a set of plans Achieve: P ⇒ ◊Q that an agent can execute and a set of events Pmeans “state P holds in the current that it can post to itself or send to its state” environment. The capability is a means of ◊Qmeans “state Q holds in the current structuring the intentional behaviour of or in some future state” agents. In a perspective of modularity, it Cease: P ⇒ ◊¬Q allows to encapsulate a set of agent Maintain: P ⇒ □Q functionalities that can be plugged in as □Qmeans “state Q holds in the current required. This component approach allows a and in all future states” system architect to build up a library. These Avoid: P ⇒□¬Q components can then be (re)used to add selected functionality to different agents of a With respect to beliefs, goals can be system. Also, some of these components can specified as in Figure 6. be temporally not available for the agents in the system. Capabilities are structured from [GoalPattern] := Achieve | Cease | Maintain | a set of events, plans or sub-capabilities that Avoid can be combined to provide complex [GoalStatus]:= Fulfilled | Unfulfilled functionality. A Capability specification Goal takes the form in Figure 7.

head: GoalPattern [CapName] state: Belief [AtomicCap] := Plan | Capability | Event Status: GoalStatus [CapAvaibility]:= Available | Unavailable

Capability head ≠∅∧state ≠∅ name: CapName (∀ g: Goal) ∧ g.status = Fulfilled composed_of: ℙ AtomicCap ⇒ (∃ blset = {bl1,…,bln: Belief} ∧ g.state ⊆ availability: CapAvailability blset)

name ≠∅∧composed_of ≠∅ Fig. 6: Goal specification. (∀ cap: Capability) ∃ ag: Agent ∧ cap ∈ ag.has ⇒ The state explicitly describes (in terms of cap.availability = “available” beliefs) the environment in which the goal is fulfilled. The status indicates whether the Fig. 7: Capability specification goal has been fulfilled or not. The goal patterns influence the set of possible agent behaviours: achieve and cease goals

Referring back to the GOSIS case study, perform may be classified as either external the mediator specification holds five (the domain of the operation is the capabilities: environment outside the agent) or internal • Handle_Request decomposes a user query (the domain of the operation is the agent into one or more sub-queries and sends itself). Actions concern only internal them to adequate wrappers; operations. We will explain later in the • Handle_Results synthesises the source paper how external operations are specified answers and returns the answers to the in SKwyRL-ADL and why they play an broker; important role in the definition of the system • Materialized_Views manages the storage, topology. From the set of all internal the updates, the queries and the results operations [Operation], we can specify an related to a set of materialized views; AtomicAction as in Figure 9. • Wrapper_Localization manages the [Operation] information (provided by the matchmaker) concerning the localisation AtomicAction of a source and its connected wrapper; head: Operation • Handle_Change executes the materialised input:Belief view updates when a monitor detects changes from its source. The proposed ADL allows the head ≠∅∧input ≠∅ specification of each capability with a name and a body (composed-of) containing the Fig. 9: AtomicAction specification plans that the capability can execute and the In order to design agents that present events that it can post to itself (handled by efficient behaviour in specific environment one of these plans) or send to other agents. states, preconditions can be defined allowing For example, the Handle_Request is specified the agent to choose a better action than it as in Figure 8. would otherwise have chosen. Once the Capability: { action is selected, the agent can execute it. name: Handle_Request_CP This affects (affect) the agent’s informational composed-of: Plan: DecompNmlRq or motivational states (Figure 10). Plan: DecompMCRq SendEvent: FaillUserRq Output:= Belief | Goal SendEvent: FailDecompMCRq function:= Add_KB | Rem_KB PostEvent: ReadyToHandleRst [Affect]:= function X output availability: available} Action Fig. 8: Handle_Request capability specification precondition: ℙ Belief The concept of Event and Plan are specified body: AtomicAction later in this section. affect: Affect Action. An action is an internal operation executed in order to achieve goals or body ≠∅∧affect ≠∅ accomplish tasks. An operation is a basic executable command of agent behaviour. Fig. 10: Action specification The type of operation that agents can

Event. An event is a belief or goal achieve a goal. Plans are selected by agents, occurrence generated by an action or a as described below. Selected plans constrain service, which triggers the execution of a the agent behaviour and act as intentions. A plan. Events are the origin of all activity plan can be specified as in Figure 12 and within an agent-oriented system. In the consists of: absence of events, an agent sits idle. • invocation condition, detailing the Whenever an event occurs, an agent selects circumstances, in terms of beliefs or between the available plans and executes the goals, that cause the plan to be triggered; selected plan (or plan set depending on the • context, that defines the preconditions of event processing model chosen), until it the plan, i.e., what must be believed by succeeds or fails. An event is either the the agent for a plan to be selected for effect of an action or a service, or it is execution; exogenous to the system, resulting from an • the plan body, which specifies either the action or a service not accomplished by an sequence of formulae that the agent agent in the system. We define an event as needs to perform. A formulae being in Figure 11. either an action or a service (i.e., action that involves interaction with other [ExogEffect] [TriggerEvent]:= Effect | ExogEffect agents) to be executed; [Evtype] = postEvent | sendEvent • end state, which defines the post- conditions under which the plan is Event succeeded; Trigger: TriggerEvent • a set of services or actions that specify destination: ℙ Agent what happens when a plan fails or type: EVtype succeeds.

Trigger ≠∅ [PlanName] [AtomicPlan]:= Action | Service (∀ ev: Event) ev.type = sendEvent ⇒ ev.dest ≠∅ Plan

Fig. 11: Event specification name: PlanName invocation: ℙ Event SKwyRL-ADL allows the specification of Context: ℙ Belief Body: seq AtomicPlan two types of events: postEvent and sendEvent. endState: ℙ Affect A postEvent describes an event that the agent succeed: seq Atomicplan can post. Posting an event means that an Failure: seq AtomicPlan agent creates an instance of the event and posts it internally (i.e., sends the event to name ≠ ∅∧invocation ≠ ∅∧body ≠ ∅ itself). Such as event needs to be handled by the agent’s own plan. Inversely, a sendEvent identifies events that the agent sends Fig. 12: Plan specification externally (i.e., to another agents) or A Plan is said to have succeeded when it considered exogenous to the system. reaches its end state, and it is said to have Plan. A plan defines a sequence of actions failed if it is not in the end state and there or/and services to accomplish a task or are no available actions or services. For

instance, the DecompNmlRq and the are required by the Ask(user_info-needs) DecompMCRq plans of the mediator agent service that the mediator initiates. However, deal with the decomposition of normal and the plan is only executed if a materialized_view multi-criteria (expressing the user belief which has the same argument values preferences) requests. as the invocation user_keyword belief does not exist. A materialized_view belief represents a Plan: { name: DecompNmlRq repetitive user information need whose invocation: Add(Request_KB, content is extracted from each source, user_keyword(pt(+),kw(+)) merged with relevant information from /* with pt:ProductType From Mediator.Ask(user_info- needs).reply_with and with kw:Keyword other sources, and stored as a belief by the FromMediator.Ask(user_info-needs).reply_with mediator. The complementary condition on context: ¬ materialized_view(ProductType materialized_view = pt(+),Keyword = kw(+)) the existence of a belief is body: ∀ pt : ProducType ∈ specified by the context. The context helps user_keyword(pt(+),kw(+)) for the selection of the most appropriate Do plan in a given situation. Action: select_wrapper(wrapper(WrapL As soon as the invocation condition and ocalization,TranslationService(+)) the context are true, the sequence of actions as wp(+): Wrapper or services specified in the plan body can be Service: performative: executed. The plan body of the DecompNmlRq Ask(query_translation) plan is composed by the sequence of an sender: Mediator action and a service. The mediator selects parameters: rt:RequestType∧ pt:ProductType∧ from their wrapper beliefs one or more kw(+):Keyword wrappers (wp(+)) capable of translating the receiver: wp(+): Wrapper decomposed subqueries. Then, a translation Affect: Add(Translation_Management service Ask(query_translation) is asked from the _KB, search(rt,pt,kw(+)) selected wrappers. End-Do The plan will only succeed if the

endstate: ∀ pt : ProducType ∈ statement described by the end state is user_keyword(pt(+),kw(+)) successful. Moreover, SKwyRL-ADL also Do allows specifying what happens when a plan Add(Translation_Management_KB, search(rt,pt,fk(+)) reaches its endstate or fails, by considering End-Do further courses of action or service. For example, the succeed specification of the suceed: Action: count(search(rt,pt,kw(+)) DecompNmlRq plan counts the number of Affect: Add(Request_Kb, occurrences of the current subquery in order old_user_keyword(pt,kw(+)) to identify a possible new materialized view, Failure: Plan: DecompMCRq } while the fail specification returns to the execution of the DecompMCRq plan. Fig. 13: DecompNmlRq plan specification 4.4.2. Security Model The DecompNmlRq plan, shown in Figure The security model is composed of four 13, is triggered each time a new user_keyword main design entities. An agent has zero or belief is added to the Request KB. The more protection objectives and each security argument values of the user_keyword belief objective imposes one or more security

constraints on the agent. Security In particular, a Protection Objective constraints might restrict the goals and/or specification is described by a name the capabilities of an agent. On the other (Name), which assists to identify the hand, an agent owns security mechanisms. A Protection Objective, and an imposer security mechanism represents a set of (Imposed_by), which describes who imposes standard security methods that an agent the Protection Objective to the agent. might have and they help towards the Imposed_to indicates the agent the satisfaction of the protection objectives of Protection Objective is imposed to, and the agent. A security method defines a Constraints provides the set of security sequence of actions and/or services to constraints imposed as a result of the satisfy an agent’s security mechanisms. specific protection objective. Protection Objective. A protection Referring to the Mediator agent objective indicates a desirable security specification, there are two protection attribute that an agent might have, such as objectives (Confidentiality_PO and integrity, and availability. An agent might Availability_PO). Following the Protection impose a security objective by itself or more Objective specification of the proposed likely a protection objective is imposed to ADL, the Availability_PO is specified as an agent through its environment (e.g. from shown in Figure 15. In particular, the a security policy or through other agents Mediator agent is imposed an Availability and/or stakeholders/developers). Moreover, Protection Objective from its Environment. a protection objective alters the agent’s As a result of this, a security constraint motivational state by adding constraint(s) to (ConfirmServiceAvailability) is imposed to the agent with respect to security. A the Mediator. protection objective imposes one or more Protection Objective: { security constraints to an agent, and each name: Availability_PO agent might have zero or more protection imposed_by: Environment objectives. A protection objective is imposed_to: Mediator specified as in Figure 14. constraints: ConfirmServiceAvailability} Fig. 15: Availability_PO specification [POname], [POimposer]:= self | environment ProtectionObjective Security Constraint. A security name: POname constraint defines a set of restrictions to the imposed_by: POimposer goals and the capabilities of an agent. These imposed_to: Agent restrictions are security related and are constraints: ℙ SecurityConstraint imposed by the agent’s environment (either from a security policy, other systems/agents, Name ≠∅∧ imposed_to ≠∅∧ constraints ≠∅ the developers or the stakeholders). When a security constraint restricts a goal, the agent (∀ po: ProtectionObjective) must identify a possible way of achieving (∀ ag: Agent) (∀ sc: SecurityConstraint) the goal without endanger the security [(sc  po) ∧ (po  ag)] ⇔ constrain(ag,sc) constraint. On the other hand, when a security constraint restricts a capability (in Fig. 14: Protection objective specification reality the security constraint will restrict plans and/or events of the capability) the

agent must identify alternative ways of Security Mechanism. A security satisfying its goals without using the mechanism represents a set of standard specific capability. It is possible that some security methods that an agent might have restrictions are communication related. For and they help towards the satisfaction of the instance, a restriction that might apply for protection objectives of the agent. The the communication of one agent with security mechanism allows structuring the another agent, might not apply for the security behaviour of an agent with respect communication of the same agent with a to its security information. Internally, each third agent or vice versa. Also, a security security mechanism is structured by a set of constraint might restrict the different security methods, allowing system goals/capabilities of an agent for a specific architects firstly to build up a library of time frame. For instance, a restriction that different security methods, and secondly to might apply today may not be valid build different security mechanisms for tomorrow. A security constraint can be different agents of the system, by adding specified as in Figure 16. and removing security methods from the library. Because of this, a security [SCname], [SCrestriction] : Goal | Capability mechanism could be either available or [SCtimeFrame]:= All | Function, [SCcommunication]:= Agent | All unavailable to an agent at a specific point of time. SecurityConstraint The security mechanism could be structured by different types of security name: SCname restricts: SCrestriction methods. Some of them related to the timeFrame: SCtimeFrame detection of security breaches, some of them constraints: SCcommunication related to the prevention of security

breaches, and some of them related to the name ≠∅∧ restricts ≠∅ recovery from security breaches. Therefore, the type of a security mechanism could be (∀ ag: Agent) [(g: Goal  ag) (cap: Capability  ag) one of the following: (1) detecting: which (sc: SecurityConstraint  ag)] restrict(g, sc) restrict(cap,sc) involves only security methods that aim to detect anomalies; (2) preventing: which Fig. 16: Security constraint specification involves only security methods used to Going back to the Mediator specification, prevent security intrusions; (3) recovering: the ConfirmServiceAvailability security which involves security methods used only constraint restricts the Mediator’s Keep to recover after a security incident; (4) Materialized View Up-to-date goal at all combinational: which involves security times and for every communication. This is methods of all types. A security mechanism specified in Figure 17. is specified in Figure 18. Going back to the GOSIS example, the Security Constraint: { Mediator agent has two security name: ConfirmServiceAvailability_SC mechanisms (see Figure 2): Data Integrity restricts: Keep_MaterialisedView_Uptodate timeFrame: All and Authentication Exchange. The Data constraints: All Integrity security mechanism } (DataIntegrity_SM) is composed of a Fig. 17: ConfirmServiceAvailability_SCspecification security method (Error Detection), which is

available for the Mediator agent; it is a perform with respond to the security combinational type of Security Mechanism method invocation; and it helps towards the Confidentiality • an end condition that specifies the Protection Objective of the agent. desirable conditions of the security action; [SMname], [SMavailability]:= Available| Unavailable the results report if the security action [SMtype]:= Detecting | Preventing | Recovering | • Combinational has failed or succeeded and what the next steps should be (these steps SecurityMechanism would be determined by whether the security action succeeded or failed). A name: SMname composed_of : ℙ SecurityMethod security action has succeeded if and type: SMtype only if the output condition availability: SMavailability corresponds to an end condition. help: ℙ Protection Objective

A security method is specified as in name ≠∅∧ composed_of ≠∅∧ type ≠∅ Figure 20.

( SM: SecurityMechanism) ( ag : Agent ) ∀ ∃ • [SMETname], [SMEToutput]:= Success| Fail use(sm,ag) [SMETtype]:=Detect|Prevent|Recovery

Fig. 18: Security mechanismspecification SecurityMethod

Using the Security mechanisms name:SMETname type: SMETtype specification of the proposed language, the entry_condition: SMETentrycondition above example is specified as shown in action:SMETaction Figure 19. end_condition:SMETdesirable output:SMEToutput next_step: SMETnextstep Security Mechanism: { name: DataIntegrity_SM name ≠∅∧ type ≠∅∧ output ≠∅ composed_of: Error_detection type: Combinational (∀ SMET: SecurityMethod) (∃ ag : Agent ) • availability: Available use(smet,ag) help: Confidentiality } Fig. 19: DataIntegrity security mechanismspecification Fig. 20: Security method specification Security Method. A security method Referring to the GOSIS example, previous defines a sequence of actions and/or analysis has identified that the Data services such as cryptographic algorithms Integrity security mechanism of the and secure protocols used to realise the Mediator agent is composed of the Error protection objectives of the agent. Each Detection security method. Error detection security method consists of the following: is a method that allows some • an entry condition, indicating the communication errors to be detected (for factor(s) that cause the method to be instance on communication between the triggered; various agents of the system). The data is • the security action, which specifies the encoded so that the encoded data contains actions/services that the agent needs to additional redundant information about the

data. The data is decoded so that the architecture, which is composed of a set of additional redundant information must configurations. The concept of architecture match the original information. This allows allows representing an agent by one or more some errors to be detected. A number of detailed, lower-level configuration error detection methods are currently used. descriptions. In the rest of this section, we For the sake of this paper we assume that define and specify, using Z, each entity of the Mediator agent employs a Cyclic this structural model. Redundancy Check (CRC) method. CRC is Interface. An interface defines a calculated by dividing the bit string of the collection of connection points through block by a generator polynomial. The value which an agent interacts with its of the cyclic redundancy check is the environment. An interface is a specification reminder of the calculation which is one bit of how an agent appears to the rest of the shorter than the generator polynomial. system. Its primary constituents are a set of Figure 21 shows an example of the CRC effectors and a set of sensors, which model security method specification. the points through which an agent interacts. An effector provides a service for other Security Method: { name:CRC_SM agents and/or human users. A sensor type: Detect requires a service from another agent and/or entry_condition:EncodedData human user. For each interaction, there is action:RunCrcAlgortihm end_condition:NoError always a correspondence between a service output:SMEToutput provided by an effector and a service } required by a sensor, e.g. the send and Fig. 21: Data Integrity security mechanism specification receive request services of a client-server application. 4.4.3. Architectural Model We specify an interface as a non-empty, The main entities and relationships of the finite set of effectors or sensors that represents architectural model are illustrated in Figure the complete set of interaction points 1. It is composed of seven main design through which an agent communicates. entities. It describes interactions among the These two basic interfaces are distinct, yet agents that compose the MAS. they share many characteristics. It can be Configurations are the central concept of useful (when appropriate) to consider them architectural design, consisting of as specialisations of the same type. In Z, this interconnected set of agents. The topology can be accomplished by defining them as of a configuration is defined by a set of disjoint subsets of the Interface type. We bindings between provided and required introduce the AgentInterface type as the services. An agent interacts with its infinite set of all possible effectors and environment through an interface composed sensor definitions (Figure 22). of sensors and effectors. An effector provides a set of services to the environment. A sensor requires a set of services from the environment. A service is performed by an agent that interacts by [AgentInterface] dialoguing with one or several agents. Interface Finally, the whole MAS is specified with an

effector: ℙ AgentInterface of the architectural description. Such sensor: ℙ AgentInterface relationships are not only part of the

specification of the agent behavior but (effector, sensor) partition AgentInterface reflect the potential patterns of communication that characterize the ways the system reason about itself. However, the Fig. 22: Interface specification required query translation service needs to be specified in greater detail. This is The predicate partition indicates that the possible with the aid of a service. sets of effectors and sensors are disjoint. We Service. A service is an operation define an Effector (Figure 23) or a Sensor performed by a sender agent that interacts (Figure 24) as an individual connection by dialoguing with one or more receiver point that defines a set of required or agents. We represent a service as a kind of provided services. action called speech act in the literature [3]. A speech act is an action available to [EffectorName] communicate what an agent knows about Effector the environment. It has the effect of changing the state of the environment just as name: EffectorName provide:Service any action. A service is specified using the model of action defined in Section 4.4.1, i.e., with name ≠ ∅∧provide ≠ ∅ preconditions and affects, as described in Figure 25. Fig. 23: Effector specification Service

[SensorName] precondition: ℙ Belief body: AtomicService Sensor affect: Affect

name: SensorName require:Service body ≠∅∧affect ≠∅

name ≠ ∅∧require ≠ ∅ Fig. 25: Service specification

We define an AtomicService (Figure 26) in Fig. 24: Sensor specification the same way as a KQML [10] inter-agent Referring to the GOSIS example, the communication. It consists of: Mediator needs the query_translation service a performative that names the services; a sender that the Wrapper provides. Such interface that identifies the agent initiating the definition points two aspects of an agent. services in the architecture; the reply-with that Firstly, it indicates the expectations the defines the information about which the agent has about the agents with which it service expresses an interaction; a set of interacts. Secondly, it reveals that the receivers that identify the agent’s interaction interaction relationships are a central issue with the sender; the parameters that define the

information required to execute the service; performative: Ask(query_translation) sender: Mediator and an optional ontology that defines the parameters: rt: RequestType ∧ pt:ProductType agreed-upon terms that will be used in the ∧ fk(+):FilteredKeyword exchange. receiver: Wrapper Affect: Add(Translation_Management_KB, search(rt,pt,fk(+)) [Performative] [Ontology] Fig. 27: Example of service specification

AtomicService Configuration. A configuration is an

name: Performative interconnected set of agent instances. A sender: Agent MAS modelled at the architectural level of parameter: ℙ Term design is represented as a configuration of reply-with: Belief receiver: ℙ Agent instantiated agent components. The ontology: Ontology topology of the system is defined by a set of bindings between services provided by effector instances and services required by name≠ ∅∧sender ≠ ∅∧receiver ≠ ∅ sensor instances. The configuration (∀ s: Service) s.sender ≠ s.receiver separates the descriptions of composite structures from the elements in those (∀ s: Service) ∃ ag1: s. sender∧∃ ag2: s. compositions. This allows reasoning about receiver⇒ s.parameter ∈ ag2.belief the composition as a whole and changing of the composition without having to examine Fig. 26: AtomicService specification each of the individual components in a Referring back to the GOSIS case study, system. Because there may be more than we can see (Figure 27) that the mediator one uses of a given agent in a MAS, we (sender) initiates the service by asking the distinguish the different instances of each wrapper (receiver) to translate a query. To agent type that appear in a configuration. To this end, the mediator provides to the this end, in our ADL we define the type wrapper a set of parameters allowing the Instance representing the name given to an definition of the contents of this query. Such agent instance that has been instantiated mediator query is specified as belief with within a configuration: [IAgent]. the predicate search and the following terms: Instantiating an agent also has the search(RequestType,ProductType(+),FilteredKeyword(+)) secondary effect of instantiating the services that are defined by its interface. We define Each term represents, respectively, the provided and required service instance type of the request (normal or advanced in types: [IRService] and [IPService]. the case of multi-criteria refinement); the Once the instances have been declared, a type of product; and one or more keywords configuration is completed by describing the that must be included in or excluded from collaborations. The collaborations define the the results. topology of the configuration, by showing The Affect indicates that a new search which agent instance participates in which belief is added to the Translation_Management interactions. This is done by defining a one- knowledge base of the wrapper. to-many mapping relation between provided

Service:

and required services. A configuration can Description Agent Broker[nb: 1…] be then specified as in Figure 28. Agent Mediator[nm: 1…] Agent Wrapper[nw: 1…nS] [AgentDescription] /*with nS = number of information sources [IAgent] Agent Monitor[nmo: 1…nS] [Instance] := IAgent | IPService | IRService Agent Matchmaker Agent Multi-Critria-analyzer Configuration Service Tell(query_translation) Service Ask(query_translation) description: ℙ AgentDescription Service Achieve(result) inst:ance: ℙ Instance Service Do(result) collaboration: (IAgent X IRService) → ( IAgent Service Tell(subscription_info) X IPService) Service Ask(subscription_info) … Instance BR : Broker description ≠ ∅∧instance ≠ ∅∧collaboration ≠ ∅ nb ME : Mediator nm WRnw: Wrapper Fig. 28: Configurationspecification MOnmo: Monitor MA: Matchmaker MCA: Multi-Criteria-Analyzer Part of the GOSIS configuration with Tellquerytrans: Tell(query_translation) instance declarations and collaborations is Askquerytrans: Ask(query_translation) given in Figure 29. Achres: Achieve(result) Dores: Do(result) “(min)...(max)” indicates the smallest Tellsubs: Tell(subscription_info) acceptable integer, and the largest. An Asksubs: Ask(subscription_info) omitted cardinality (as is the case with … (max) in the broker, mediator and wrapper Collaborations MEnm.Askquerytrans - Tellquerytrans.WRnw; agents), means no limitation. Dynamic and MEnm.Achres --- Tellres.WRnw; evolving structures can change at runtime. MEnm.Asksubs --- Tellsubs.MA; … Such a configuration allows for dynamic End GOSIS reconfiguration and architecture resolvability at run-time. Configurations Fig. 29: Part of the GOSIS configuration separate the description of composite This is usually referred to as hierarchical structures from the description of the refinement in software architecture. To elements that form those compositions. This support hierarchical descriptions, SKwyRL- permits reasoning about the composition as ADL permits the representation of an agent a whole and allows reconfiguration without by one or more detailed, lower-level having to examine each component of the descriptions. This is specified with the system. concept of architecture. The architecture Architecture. Architecture models the full models a complete specification. Each set of design information defined within an design has at least one configuration architectural specification. An important corresponding to the top-level system property for an ADL is to allow basic model. However, our model also supports components in architecture to be replaced by hierarchical system descriptions; that is, an (sub) configurations, in order to form new agent may be further specified as being configurations. implemented by a configuration. An

Configuration GOSIS architecture maintains the set of all of the

configurations that have been defined, and it solution was implemented and we provide can be specified as a non-empty set of illustrations of the system’s implementation. configurations that has been defined in the specification (Figure 30). 5.1. E-Media

Architecture E-Media provides an on-line interface that allows customers to examine the items on composed_of: ℙ Configuration the E-Media catalogue and place orders.

Customers can search the on-line store by composed_of ≠∅ either browsing the catalogue or querying the item database. An online search engine

Fig. 30: Architecture configuration allows customers to search title, author/artist and description fields through keywords or full-text search. If an item is not available in 5. The e-commerce system Case Study the catalogue, the customer has the option to order it. Moreover, Internet communications 5 E-Media is a typical business-to-consumer are supported. All web information (e.g., application we have developed using the product and customer turnover, and sales ADL described in the previous sections. The average) of strategic importance is recorded application offers an e-commerce for monthly or on-demand statistical architecture supporting the creation of analysis. Based on this statistical and information sources that facilitate the on- strategic information, the system line transaction of products, services, and continuously manages and adapts the stock, payments resulting in an effective and pricing and promotions policy. For example, efficient interaction among sellers, buyers for each product, the system can decide to and intermediaries. increase or decrease stocks or profit This section describes how we have margins. It can also adapt the customer on- applied SKwyRL ADL to formally specify line interface with new product promotions. architectural aspects of the system, such as Apart from the main functional features of interfaces, knowledge bases, and security the system, security is a very important mechanisms. In particular, in section 5.1, we factor in the development of the E-Media introduce the case study and we discuss with system. Customers need to know that their the aid of secure Tropos [5] and i*[47] information remains secure and accessible diagrams the analysis of the system, its only to intended participants, and also that requirements and the selected architectural the risks, such as receiving wrong product style for the e-media system. In Section 5.2 because someone intercepted and changed we illustrate how the proposed ADL was the order, associated with online purchases used to support the architectural description are minimized. Therefore, from the of the system by focusing on one of the customer’s point of view the main security system’s main components; the Billing objectives are confidentiality and integrity. Processor Agent. Then in section 5.3, we Confidentiality guarantees that the explain how the developed architectural information is accessible only to authorized entities and inaccessible to others, whereas 5 integrity guarantees that information (http://www.isys.ucl.ac.be/skwyrl/emedia)

remains unmodified from source entity to Dependency introduces security destination entity. constraint(s) that must be respected by On the other hand, the stakeholder of the actors for the dependency to be satisfied E-Media system needs to make sure that the [35]. This means that the depender expects system will always be available for from the dependee to satisfy the security customers to buy; it can confirm the constraint(s) and also that the dependee will involvement of an entity in certain make effort to deliver the dependum by communications; and it can prove the satisfying the security constraint(s). identity of an entity. In other words, the Actors are represented as circles; main security objectives from the e-media’s dependums – goals, softgoals, tasks and stakeholder point of view are availability, resources – are respectively represented as non-repudiation, and authentication. ovals, clouds, hexagons and rectangles; Availability guarantees the accessibility dependencies have the form depender → and the usability of information and dependum → dependee. Security constraints resources to authorized entities, non are represented as hexagons. repudiation confirms the involvement of an entity in certain communications, and authentication proves the identity of an entity. For both, the customer and the e-media stakeholder actors to satisfy their security objectives, some security constraints are imposed on their dependencies. Figure 31 models the dependencies between the customer, the E-Media stakeholder and the E-Media system along with the security constraints imposed by the first two actors on the system, using the secure Tropos language [35] where each node represents an actor (or system component) and each link between two actors indicates a dependency. A dependency describes an “agreement” (called dependum) between two actors: the depender and the dependee.

The depender is the depending actor, and the dependee, the actor who is depended upon. Figure 31: E-Media dependencies The type of the dependency describes the Following the secure Tropos analysis nature of the agreement. Goal dependencies process, the structure-in-5 organizational represent delegation of responsibility for architectural style, presented in [23], was fulfilling a goal; soft-goal dependencies are identified as suitable for the e-media system. similar to goal dependencies, but their More information about alternative fulfilment cannot be defined precisely; task architectural selections can be found in [13]. dependencies are used in situations where According to the structure-in-5 style, the the dependee is required. A Secure

organisation of the software architecture can increase or decrease, performance charts, be considered an aggregate of five sub- best sales, and sales prevision) is also structures [33]. The Operational Core, provided to the Decision Maker. which carries out the basic tasks and procedures directly linked to the production of products and services; the Strategic Appex, which makes executive decisions ensuring that the organization fulfills its mission in an effective way and defines the general strategy of the organization in its environment. The Middle Line, which establishes a hierarchy of authority between the Strategic Apex and the Operational Core; the Technostructure, which serves the organization by making the work of others more effective, typically by standardising work processes, outputs and skills; the Support, which provides specialized services, at various levels of the hierarchy, outside the basic operating workflow. Figure 32: The E-Media Architecture in Structure-in-5 These sub-structures are realized in the case of the e-media architecture by the Store The Billing Processor handles customer Front, the Back Store, the Billing Processor, orders and bills. To this end, it provides the the Coordinator and the Decision Maker, as customer with on-line shopping cart shown in Figure 32. capabilities. It also handles, under the The Store Front interacts with customers responsibility of the Coordinator, stock and provides them with a usable front-end orders to avoid shortages or congestions. web application for consulting, searching Finally, it ensures the secure management of and shopping media items. The Back Store financial transactions for the Decision constitutes the support component. It Maker. The Coordinator assumes the central manages the product database and position of the architecture. It is responsible communicates to the Store Front relevant to implement strategic decisions for the product information. To be able to produce Decision Maker. It supervises and statistical information (e.g., analyses, coordinates the activities of the Billing average charts and turnover reports), the Processor (initiating the stock and pricing Back Store stores and backs up all the policy), the Front Store (adapting the front appropriate web information about end interface with new promotions and customers, products and sales. Such kind of recommendations) and the Back Store information is analysed either for a (parameterize statistical computing) predefined product (when the Coordinator ensuring that the system fulfils its mission in asks it) or on a monthly basis for every an effective way. Finally, the Decision product. Based on this monthly statistical Maker assumes strategic roles. It defines the analysis, strategic information (e.g., sales strategic behaviour (e.g., sales and turnover,

product visibility, and hits) of the system Protection Objectives indicating the desired ensuring that objectives and responsibilities security attributes of the agent, the Security delegated to the Billing Processor, Mechanisms representing a set of standard Coordinator and Back Store are consistent security methods that an agent might have with respect to their capabilities. and help towards the satisfaction of the protection objectives of the agent, and the 5.2. Architectural Description Capabilities defining agent behaviours. In particular, the Billing Processor agent The initial analysis of the case study, as Interface consists of a number of effectors partially presented in the previous section, and sensors for the agent. Effectors provide provides an organizational representation of services to other agents, and sensors require the system-to-be including relevant actors, services provided by other agents. An security constraints and their respective interaction is then defined by the goals, tasks and resource inter- correspondence between a required and a dependencies. Such analysis can serve as a provided service. As shown in Figure 33 the basis to understand and discuss the BP agent’s interface consists of four assignment of system functionalities and effectors and two sensors. security issues but it is not adequate to Agent:{Billing-Processor provide a precise specification of the system Interface details. As introduced in the previous Effector[provide(shopping_cart)] sections, SKwyRL-ADL provides a finite Effector[provide(billing)] Effector[provide(stock_orders)] set of formal agent-oriented constructors Effector[provide(finance_security)] that allow detailing, in a formal and Sensor[require(strategic_behavior)] consistent way, the software architecture as Sensor[require(statistical_info)] KnowledgeBase: well as its agent components, their Stock_KB Pricing_Kb behaviours and the corresponding security BP_Customer_KB Providers_KB issues. The rest of the section describes the BP_System_KB Statistical_KB Protection Objectives: specification, in SKwyRL-ADL, of one of Confidentiality_PO Integrity_PO the main components of the e-media system Availability_PO Non_Repudiation_PO as introduced in 5.1 and 5.2; the Billing Authentication_POAccessControl_PO Security mechanisms: Processor agent. Focusing on this Encipherment_SMDIgitalSignature_SM component of the system allows us to AccessControl_SM DataIntegirty_SM demonstrate the applicability of the AuthenticationExchange_SM TrafficPadding_SMRoutingControl_SM proposed ADL and also in the same time to Notarization_SM keep the description to a reasonable and Capabilities: manageable length. For a complete Shopping_Cart_Management_CP Billing_CP Stock_Management_CP specification of the E–Media case study, we Statistic_CP refer the reader to [14]. }

There are five main aspects of the Billing Figure 33: Billing Processor agent specification Processor (BP) agent that need to be considered: the Interface representing the Moreover, the BP agent has a number of interactions in which the agent will knowledge bases related to customers, participate; the Knowledge Base defining providers, pricing and stock as well as a the agent knowledge capacity, the number of protection objectives, such as

(amongst others) confidentiality, integrity, customer turnover and product sales. Since and availability. The BP agent also has a the BP agent only knows the beliefs number of security mechanisms, such as included in its KB, the type of the Statistical access control and notarization, as well as a KB is closed world. number of capabilities, such as stock management and billing. KnowledgeBase: {Statistical_KB KB_body: Once all the five aspects have been statistic_computation(Date,Subject) defined, more detail specifications are product_turnover(Id_Prod,TimeWindows,Turnover) constructed for each one of these. For customer_turnover(Id_Card,TimeWindows,Turnove) product_sales(Id_Prod,TimeWindows,Sales) instance, the BP agent Interface components extrapol_sales(Id_Prod,TimeWindows,setoffSales) are further specified. In particular, each KB_type: closed_world } provided or required service can be detailed Figure 35: Statistical Knowledge Base for BP specification by describing the sender agent that initiates the service, a set of receiver agents that The high-level specification of the BP interact with the sender, the “reply-with” agent indicates that the agent has six (6) that defines the information with which the protection objectives. These protection service expresses an interaction, and objectives have been identified by the optionally a set of parameters that define the security analysis that took place for the e- information required to execute the service. media system and partially presented in The parameters as well as the “reply-with” section 5.1. In particular, the initial security information can be represented with a belief constraints (illustrated in Figure 31) were or a set of terms (e.g., function, constant or further analysed into secure goals and plans variable) as shown in Figure 34. which in turn allowed us to identify a

Service: {Ask(statistical_info) number of protection objectives to satisfy sender: Coordinator the secure goals and plans of the BP agent. parameters:(tw:TimeWindows),(id:Id_product) Following the ADL structure and in reply_with: to: Turnover ∨ sl: Sales particular the Protection Objective receiver: Back-Store Effect:Add(Statistical_KB, specification (as presented in previous Achieve(statistic(“today”,“on_product”)} sections), each of protection objective of the

Figure 34: Ask statistical specification BP agent is specified with a name, information of who imposed it to the agent, As discussed above, the BP agent has six the agent to which it is imposed to (in this KBs. Following the ADL specification for case the Billing Processor), and the Knowledge Bases, introduced in the constraints that it imposes to the agent. For previous sections, each KB is specified with example, the specification of the a name, a KB_body and a KB_type. For Non_Repudiation Protection Objective is example, the specification of the illustrated in Figure 36. Statistical_KB for the BP agent is shown in

Figure 35. Protection Objective: { That specification describes the formal name: Non_Repudiation_PO knowledge that the BP agent has with imposed_by: Environment imposed_to: Billing_Processor respect to the statistical analysis required. constraints: ConfirmInvolvementInTransactions} As shown in Figure 35, this includes, amongst other things, product turnover, Figure 36: Non Repudiation Protection Objective specification

Our security analysis, during the analysis Plan Stock_Orders SendEvent Grade stage of the development process, indicated SendEvent Best_Sales that the BP agent should have 8 different SendEvent Promotion security mechanisms in order to satisfy its } security requirements. Following the Figure 38: Billing Processor Statistic_CP capability specification specification for Security Mechanisms presented in the previous section, each The Stock_Order plan of the Billing- security mechanism is specified with a Processor (Figure 39) ensures that the level name, the security methods it is composed of stock of each product is constantly higher of, a type, its availability to the agent, and than the minimal quantity, which is an indication to which protection objective determined by the coordinator on the basis helps. For instance, the Notarization security of the strategic orientation provided by the mechanism specification for the Billing Decision-Maker. Processor agent is shown in Figure 37. It is Plan:{ important to emphasise that the notarisation Name: Stock_Orders mechanism is provided by a third-party invoc: notary, which must be trusted by all Maintain(current_stock(id,Availability > lb) // with id: Id_Product participants. The notary can assure integrity, // From Coordinator.Ask(stock_orders).reply_with origin, time or destination of data. For // with lb: Lower_Bound example, a message that has to be submitted // From Coordinator.Ask(stock_orders).reply_with context: by a specific deadline may be required to current_stock(id,Availability < lb) bear a time stamp from a trusted time ∧¬ time (now > “11 am”) service proving the time of submission. ∧ (day(now =“monday” ∨ day(now =“wednesday”) Security Mechanism: { body: name: Notarization_SM action: proceed_order(id, lb) composed_of: third_party_notary effect:Add(Stock_Kb, type: Combinational Sent_Orders(id,qu,date)) availability: Available endstate: help: Non_Repudiation} Add(Stock_Kb, Sent_Orders(id,qu,date)) succeed: Figure 37: Notarization security mechanism specification action: update_stock(id, av) //with av: availability The Billing Processor agent has also some effect: Add(Stock_Kb, Stock(id, av)) capabilities. A capability is composed of fail: action: search_last(sent_orders(),id) as plans and events that together serve to give qu: Quantity an agent certain abilities. For example, the Add(Stock_Kb,Sent_Orders(id,qu,d Billing Processor Statistic_CP capability is ate)) update_stock(id, av) specified as shown in Figure 38. The body effect: Add(Stock_Kb, Stock(id, av)) contains the plans that the capability can } execute and the events it can post to be Figure 39: Stock_Order plan specification handled by other plans or it can send to other agents. In the plan body, the quantity to order is Capability:{Statistic_CP determined and then the order is sent to the CP_body: Plan Prov_Turnover_On_Demand publisher. Eventually, the level of stock is Plan Prov_Turnover updated in the system. In case of plan Plan Sales_Average failure, the “fail” instructions are carried

out. So the Billing Processor searches for promotions and consequently adapts the the last order sent for this product and it Store Front layout. The Coordinator acts reorders the same quantity. Then the stock similarly for the best sales: the Back-Store level is updated with the quantity ordered. computes the five best sellers and the Coordinator accordingly updates the Store- Front. Figure 40 illustrates the Store-Front 5.3. E-Media Implementation interface for the DVD section. To search the E-Media DVD catalogue, Following the analysis of the system the user must fill in at least one field of the (partially presented in 5.1) and the search engine (see section 1 in Figure 40). specification of its architecture (partially The Store-Front sends the query parameters presented in 5.2), the next step included the to the Back Store which provides the results implementation of the system based on the back to the Store-Front (see section 2 in developed architecture. In the rest of this Figure 40). section, we briefly describe the E-Media At any moment during the session, the implementation to illustrate the roles of the user can click on a product (best seller, agents (Front Store, Decision Maker, Back query result, and shopping cart); a request is Store, Coordinator and Billing Processor) then sent to Back Store to provide more identified in 5.1 and their interaction. We information on this product (see section 3 in also focus the discussion on implementation Figure 40). aspects of the Billing Processor agent described in section 5.2. The E-Media application was implemented (~ 10.000 lines of code) using JACK [26]; a BDI agent-oriented development environment for JAVA. When an on-line customer gets connected to E-media, an instance of the Front-Store is created to display an interface that allows the user to sign in. Then, the Back-Store handles the information provided by the user and checks its validity. If the access is granted, the user can purchase products on E-Media by adding catalogue items to the Figure 40: Interface of e-media DVD section shopping cart managed by the Billing- The implementation for the Billing Processor. At any time the user can use a Processor has followed the architectural navigation-bar to switch from one section of description presented in the previous section the website to another. Moreover, (5.2). In particular, when a user starts the promotions and best sales are part of the billing process, the Billing Processor agent strategic behaviour objective. The invokes the shopping cart and billing promotions’ policy is initiated by the effectors and displays all the items of the Decision-Maker based on the strategic shopping cart and it computes the total and information provided by the Back-Store. sub-total for each product. It then employs a The Coordinator chooses the best

number of its KBs, POs and SMs to validate ([2], [17], [28], [30] and [39]) for the user id and process the payment card. As representing and analysing architectural discussed in the previous section (5.2) a designs. In particular, a number of third party is used to support the Architectural Description Languages notarization security mechanism of the BP (ADLs) have been proposed such as agent. During all this time, the BP agent Rapide[29], Darwin[32], Aseop[18], communicates with the user, through user Unicon[39],Wright [2] and ACME[17]. messages on the screen, as illustrated in However, these efforts have not been Figure 41, by employing its sensors and undertaken with agent orientation in mind, effectors. Once the payment is accepted, the and therefore the resulted languages are not Billing Processor uses again its interface to applicable for specifying MAS communicate with the Store-Front. architectures. Nevertheless, the study and Furthermore, a confirmation message is careful examination of the above efforts has displayed and the shopping cart is cleared. enable us to identify the essential aspects that any ADL should be able to specify, and develop the common foundation of concepts and concerns for the language proposed in this paper (see Section 4 for details). On the other hand, few efforts have been made to define an architectural description language (ADL) for MAS. MAS-adl[10]is a simple customized architectural description language for MAS used to describe the various classes of agents involved in the MAS and the interconnections between their instances. In particular, for any given class Figure 41: Secure Payment Information. the architectural description provides information about the kind of the 6. Related Work architecture; the interpreters and the services of agents in that class. ADLMAS [48] is an architectural description language for MAS, Over the past decade, the field of software which adopts Object-Oriented Petri nets as a architecture has received increasing formal theory basis. ADLMAS is suitable attention as an important subfield of for representing concurrent, distributed and software engineering. Practitioners have synchronous MAS. ADLMAS can visually come to realise that getting an architecture and intuitively depict a formal framework “right” is a critical success factor for system for MAS, from the agent level and social design and development. They have begun level, which describes the static and to recognise the value of making explicit dynamic semantics, and analyse, simulate architectural descriptions and choices in the and validate MAS and interactions among development of new systems. In this agents with formal methods. Similarly Yu et context, a number of researches have al. [49], have developed a MAS ADL based proposed architectural description languages on π-net. The proposed ADL supports the Belief-Desire-Intention (BDI) model and it

makes use of two formalisms, namely exploit the services of new agents, or Agent-Oriented Petri nets (AOPN) and π- replace existing ones. calculus. AOPNs are used to visualize the Based on the analysis of existing classical static architecture and model the behaviors ADLs, security consideration for multi- of the MAS under development, while π- agent systems and the BDI agent model, this calculus is used to represent the dynamic article has defined a set of system architecture of MAS. These works are architectural concepts to propose an ADL important, but they fail to adequately for secure BDI-MAS. This ADL allows consider the issue of security in MAS. specification of agent components (such as There is, of course, a large effort of works knowledge base, interface and capabilities), in the area of MAS, with respect to security. agent behaviour (such as belief, goal and These include policy specification languages plan), agent security (such as security (for example [23],[4]), Trust and Reputation constraints, protection objectives and mechanisms(for example [20], [22], [30]), security mechanisms) and agent interactions agent-oriented software engineering (such as service and configuration). methodologies for the analysis and design of The research reported here calls for secure MAS [35], security patterns[36], and further work. We are currently working on: security mechanisms and protocols [4]. - the development of a CASE tool to Although such works do not directly input automatically generate the code skeleton into our proposed language; their study has of the future multi-agent information enable us to consider a variety of security system from their specification with the considerations, issues and challenges faced ADL; for the development of secure MAS and - the definition of a set of rules to perform therefore develop a security model for the consistency analysis that could be proposed ADL that supports appropriate included in commercial verification tools architectural concepts. such as PVS (http://pvs.csl.sri.com/); - the identification of a suitable set of core abstractions, inspired by an 7. Conclusion organizational metaphor, to be used during the design of multi-agent systems; Today’s information systems must be - the development of a clear methodology, based on open architectures to accommodate centred around these organizational new components and meet fast evolving abstractions, for the design of multi-agent requirements. MAS architectures provide an systems architectures. effective way to design such systems since they do support open and evolving configurations that can change at run-time to

[2] R. Allen and G. Garlan, “Formal Connectors,” Software Architecture Lab., Carnegie Mellon University, Pittsburgh, USA, Technical Report CMU-CS-94-115, 1994. References [3] J. L. Austin, How to do things with worlds, Oxford University Press, 1962. [4] M. Barley, H. Mouratidis, A. Unruh, D. Spears, P. Scerri, and [1] R. Allen, “A Formal Approach to Software Architecture,” F. Massacci,(eds.) (2008) "Safety and Security in Multiagent Ph.D. Thesis, Carnegie Mellon University, Technical Report Systems: The Early Years",Springer-Verlag, forthcoming. Number: CMU-CS-97-144, 1997.

[5] P. Bresciani, P. Giorgini, F. Giunchiglia, J. Mylopoulos, A. [21] J. Hintikka, Knowledge and belief, Cornell University Press, Perini. TROPOS: An Agent-Oriented Software Development 1962. Methodology. Journal of Autonomous Agents and Multi- [22] Y. Hu. Some thoughts on Agent Trust and Delegation. In Agent Systems. Kluwer Academic Publishers Volume 8, Issue Proceedings ofAutonomous Agents 2001, 2001. 3, Pages 203 - 236, May 2004. [23] L. Kagal and T. Finin. Modeling conversation policies using [6] M. Bratman, Intentions, Plans and Practical Reasoning, permissions and obligations. Autonomous Agents and Multi- Harvard Univ. Press, 1988. Agent Systems 14, 2 (Apr. 2007), 187-206. [7] P. C. Clements, “A Survey of Architecture Description [24] M. Kolp, P. Giorgini, and J. Mylopoulos. An Organizational Languages,” in Proc. of the 8th Int. Workshop on Software Perspective on Multi-agent Architectures. In Proc. of the 8th Specification and Design, Paderborn, Germany, 1996, pp. Int. Workshop on Agent Theories, architectures, and= 123-131. languages, ATAL’01, Seattle, USA, Aug. 2001. [8] D. Calvanese, S. Castano, F. Guerra, D. Lembo, M. Melchiori, [25] K. Konolige, “A first order formalization of knowledge and G. Terracina, D. Ursino, and M. Vincini, “Towards a action for multi-agent planning system,” Machine Comprehensive Methodological Framework for Semantic Intelligence, 10: 41-72, 1982. Integration of Heterogeneous Data Sources,” in Proc. of the [26] JACK Intelligent Agents. http://www.agent-software.com/ 8th Int. Workshop on Knowledge Representation meets [27] M. Luck and M. d’Inverno, “A formal framework for agency Databases, Rome, Italy, 2001. and autonomy,” In Proc. of the 1st Int. Conf. on Multi-Agent [9] D. Calvanese, G. De Giacomo, M. Lenzerini, D. Nardi, and R. Systems,San Francisco, USA, 1995. pp. 254-260. Rosati, “Schema and Data Integration Methodology for [28] D. C. Luckham, J. J. Kenney, L. M. Augustin, J. Vera, D. DWQ,” Foundations of Data Warehouse Quality Project, Bryan and W. Mann, “Specification and Analysis of System Dipartimento di Informatica e Sistemistica, Università di Architecture Using Rapide,” IEEE Transactions on Software Roma "La Sapienza", Report DWQ-UNIROMA-004, 1998. Engineering, 21(4):336–355, 1995. [10] A. Cuppari, P. L. Guida, M. Martelli, V. Mascardi, and [29] D. C. Luckham, and V. Vera, “An Event-Based Architecture F. Zini. “An Agent Based Prototype for Freight Trains Traffic Definition Language,” IEEE Transactions on Software Management”. In Proc. of FMERail'99 Workshop, Toulouse, Engineering, 21(4):717-734. 1995. France, September 1999. [30] B. B. Madan and K. Goseva-Popstojanova and K. [11] A. Dardenne, A. van Lamsweerde and S. Fickas, “Goal- Vaidyanathan and K. S. Trivedi, “Modeling and Directed Requirements Acquisition,” Science of Computer Quantification of Security Attributes of Software Systems”, in Programming, 20(1): 3-50, 1993. Proc. of the 2002 International Conference on Dependable [12] A. Dal Formo and U. Mendenlo, “A Multi-Agent Simulation Systems and Networks (DSN’02), Washington, DC, USA, pp. Platform for Modeling Perfectly Rational and Bounded- 505-514, 2002. Rational Agents in Organizations,” Artificial Societies and [31] Y. Mass and O. Shehory. Distributed Trust in Open Multi Social Simulation, 5(2):166-177, 2001. Agent Systems. InWorkshop on Deception, Fraud and Trust in [13] T. T. Do, S. Faulkner and M. Kolp. Organizational Multi- Agent Societies, Autonomous Agents2000, 2000. Agent Architectures for Information Systems. in Proc. of the [32] J. Magee and J. Kramer, “Dynamic Structure in Software 5th Int. Conf. on Enterprise Information Systems (ICEIS Architectures,” in Proc. of the 4th Int. Conf. on the 2003), Angers, France, April 2003. Foundations of Software Engineering, San Francisco, CA, [14] S. Faulkner, An Architectural Framework for DescribingBDI USA, 1996. pp. 3-14. Multi-Agent Information Systems, Ph.D. thesis,Department of [33] H. Mintzberg. Structure in fives: designing Management Science, University of Louvain,Belgium, May effectiveorganizations. Prentice-Hall, 1992. 2004. [34] H. Mouratidis, S. Faulkner, M. Kolp, and P. Giorgini, “A [15] S. Faulkner, M. Kolp, T. Nguyen and A. Coyette, “A Multi Secure Architectural Description Language for Agent Agent Perspective on Data Integration Architectural Design”. Systems”. In Proc. of the 4th International Joint Conference In Knowledge-Based Intelligent Information & Engineering on Autonomous Agents and Multi-Agents Systems Systems (KES), 8(1):1150-1156, LNCS 3213, Springer, 2004 (AAMAS'05), Utrecht, The Netherlands, pp. 578-585, 2005. [16] T. Finin, R. Fritzson, D. McKay and R. McEntire, “KQML as [35] H. Mouratidis and P. Giorgini. Enhancing secure Tropos to an Agent Communication Language,” in Proc. of the 3rd Int. effectively deal with security requirements in the development Conf. on Information and Knowledge of multiagent systems, in the proceedings of the 1st Management,Gaithersburg, USA, 1994, pp. 456-463. International Workshop on Safety and Security in Multiagent [17] D. Garlan and R. Monroe, “Acme: an architecture description Systems, AAMAS 2004, N.Y. USA, 2004 interchange language,” in Proc. of the 7th Annual IBM Centre [36] H. Mouratidis, P. Giorgini, M. Schumacher . Security Patterns for Advanced Studies Conference, Toronto, Ontario, 1997, pp. for Agent Systems. In Proceedings of theEight European 78-86. Conference on Pattern Languages of Programs (EuroPLoP), [18] D. Garlan, R. Allen, and J. Ockerbloom.Exploiting Style in Irsee, 2003. Architectural Design Environments. InProceedings of [37] Y. Papakonstantinou, H. Garcia-Molina and J. Ullman. SIGSOFT’94: Foundations of SoftwareEngineering, pages Medmaker, “A mediation system based on declarative 175–188, New Orleans, Louisiana,USA, December 1994. specification,” in Proc. of the 12th Int. Conf. On Data [19] H. Garcia-Molina, Y. Papakonstantinou, D. Quass, A. Engineering, New Orleans, 1996, pp. 132-141. Rajaraman, Y. Sagiv, J.D. Ullman, and J. Widom, “The [38] V. S Subrahmanian, S. Adali, A. Brink, R. Emery, J. J. Lu, TSIMMIS Approach to Mediation : Data Models or A. Rajput, T. J. Ross, C. Ward, “Hermes: A Heterogeneous Languages,” Journal of Intelligent Information Systems, Reasoning and Mediator System,” in Proc. of the Int. Conf. 8(2):117-132, 1997. On Database Theory, Delphi, Greece, 1997, pp 19-40. [20] A. Herzberg, Y. Mass, J.Mihaeli,D.Naor, and Y. Ravid, [39] M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young Access Control meets Public Key Infrastructure : OrAssigning and G. Zelesnik, “Abstractions for Software Architecture and Roles to Strangers. In Proceedings of 2000 IEEE Symposium Tools to Support Them,” IEEE Transactions on Software onSecurity and Privacy, Oakland, May 2000, 2000. Engineering, 21(4):314-335, 1995.

[40] M. Shaw and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, 1996. [41] J. M. Spivey, The Z Notation: A Reference Manual. Prentice- Hall, second edition, 1992. [42] S. Vestal, “A Cursory Overview and Comparison of Four Architecture Description Languages,” Honeywell Technology Center, Technical Report, 1993 [43] J. Widom, “Research Problems in Data Warehousing,” in Proc. of the 4th Int. Conf. on Information and Knowledge Management, Baltimore, Maryland, USA, 1995, pp. 25-30. [44] G. Wiederhold, “Mediators in the architecture of future information system,” IEEE Computer, 25(3): 38-49, 1992. [45] G. Wiederhold, “Intelligent Integration of Information,” in Proc. of the ACM SIGMOD Conference on Management of Data, Washington, USA, 1993, pp. 434-437. [46] M. Wooldridge and N.R Jennings, “Special Issue on Intelligent Agents and Multi-Agent Systems,” Applied Artificial Intelligence Journal, 9(4):74–86, 1996. [47] E. Yu, “Modelling Strategic Relationships for Process Reengineering,” Ph.D. thesis, Department of Computer Science, University of Toronto, Canada, 1995. [48] Z. Yu, Z. Li. “Architecture description language based on object-oriented Petri nets for multi-agent systems” In Proc. of the 2005 Int. Conf on Networking, Sensing and Control, Tucson, USA, pp. 256-260, 2005. [49] Z. Yu, Y. Cai, R. Wang, J. Han, “π-net ADL : An architecture description language for multi-agent systems”, In Proc. Of International Conference on Intelligent Computing, Lecture Notes in Computer Science vol. 3645, Springer-Verlag, 2005.