Presentation Outline (1) -...

22
1 AOT Lab Dipartimento di Ingegneria dell’Informazione Università degli Studi di Parma From Distributed Objects to Multi-Agent Systems: Evolution of Middleware Giovanni Rimassa AOT Lab - DII, University of Parma ([email protected]) FRAMeTech s.r.l. ([email protected]) DS Seminar – Cesena, March 5 th , 2003 2 of 127 Presentation Outline (1) w Middleware Overview s What is Middleware s Why Middleware s Middleware and Models s Middleware Technologies and Standards w Object Oriented Middleware s Mission: OOP for Distributed Systems s OOPrinciples s Bringing Objects to the Network s Overview of the CORBA Standard DS Seminar – Cesena, March 5 th , 2003 3 of 127 Presentation Outline (2) w Agent Oriented Middleware s Mission: Mainstreaming Agent Technology s What is an Agent? s Autonomy, Sociality and Other Agenthood Traits s Overview of the FIPA Standard w JADE: A Concrete FIPA Implementation s Overview: The Software, the Project, the Community s JADE as a Runtime Support System s JADE as a Software Framework s JADE Internal Architecture DS Seminar – Cesena, March 5 th , 2003 4 of 127 Middleware Overview w What is Middleware? s The word suggests something belonging to the middle. s But middle between what? w The traditional Middleware definition. s The Middleware lies in the middle between the Operating System and the applications. w The traditional definition stresses vertical layers. s Applications on top of Middleware on top of the OS. s Middleware-to-application interfaces (top interfaces). s Middleware-to-OS interfaces (bottom interfaces). DS Seminar – Cesena, March 5 th , 2003 5 of 127 Why Middleware? w Problems of today. s Software development is hard. s Experienced designers are rare (and costly). s Applications become more and more complex. w What can Middleware help with? s Middleware is developed once for many applications. s Higher quality designers can be afforded. s Middleware can provide services to applications. s Middleware abstracts away from the specific OS. DS Seminar – Cesena, March 5 th , 2003 6 of 127 Middleware and Models (1) w A key feature of Middleware is Interoperability. s Applications using the same Middleware can interoperate. s This is true of any common platform (e.g. OS file system). w But, many incompatible middleware systems exist. s Applications on middleware A can work together. s Applications on middleware B can work together, too. s But, A-applications and B-applications cannot! w The Enterprise Application Integration (EAI) task. s Emphasis on horizontal communication. s Application-to-application and middleware-to-middleware.

Transcript of Presentation Outline (1) -...

1

AOT LabDipartimento di Ingegneria dell’Informazione

Università degli Studi di Parma

From Distributed Objects to Multi-AgentSystems: Evolution of Middleware

Giovanni Rimassa

AOT Lab - DII, University of Parma ([email protected])

FRAMeTech s.r.l. ([email protected])

DS Seminar – Cesena, March 5th, 2003 2 of 127

Presentation Outline (1)

w Middleware Overviews What is Middleware

s Why Middleware

s Middleware and Models

s Middleware Technologies and Standards

w Object Oriented Middlewares Mission: OOP for Distributed Systems

s OOPrinciples

s Bringing Objects to the Network

s Overview of the CORBA Standard

DS Seminar – Cesena, March 5th, 2003 3 of 127

Presentation Outline (2)

w Agent Oriented Middlewares Mission: Mainstreaming Agent Technology

s What is an Agent?

s Autonomy, Sociality and Other Agenthood Traits

s Overview of the FIPA Standard

w JADE: A Concrete FIPA Implementations Overview: The Software, the Project, the Community

s JADE as a Runtime Support System

s JADE as a Software Framework

s JADE Internal Architecture

DS Seminar – Cesena, March 5th, 2003 4 of 127

Middleware Overview

w What is Middleware?s The word suggests something belonging to the middle.

s But middle between what?

w The traditional Middleware definition.s The Middleware lies in the middle between the Operating

System and the applications.

w The traditional definition stresses vertical layers.s Applications on top of Middleware on top of the OS.

s Middleware-to-application interfaces (top interfaces).

s Middleware-to-OS interfaces (bottom interfaces).

DS Seminar – Cesena, March 5th, 2003 5 of 127

Why Middleware?

w Problems of today.s Software development is hard.

s Experienced designers are rare (and costly).

s Applications become more and more complex.

w What can Middleware help with?s Middleware is developed once for many applications.

s Higher quality designers can be afforded.

s Middleware can provide services to applications.

s Middleware abstracts away from the specific OS.

DS Seminar – Cesena, March 5th, 2003 6 of 127

Middleware and Models (1)

w A key feature of Middleware is Interoperability.s Applications using the same Middleware can interoperate.

s This is true of any common platform (e.g. OS file system).

w But, many incompatible middleware systems exist.s Applications on middleware A can work together.

s Applications on middleware B can work together, too.

s But, A-applications and B-applications cannot!

w The Enterprise Application Integration (EAI) task.s Emphasis on horizontal communication.

s Application-to-application and middleware-to-middleware.

2

DS Seminar – Cesena, March 5th, 2003 7 of 127

Middleware and Models (2)

w Software development does not happen in vacuum.s Almost any software project must cope with past systems.

s There is never time nor resources to start from scratch.

s Legacy systems were built with their own approaches.

w System integration is the only way out.s Take what is already there and add features to it.

s Try to add without modifying existing subsystem.

w First casualty: Conceptual Integrity.s The property of being understandable and explainable

through a coherent, limited set of concepts.

DS Seminar – Cesena, March 5th, 2003 8 of 127

Middleware and Models (3)

w Real systems are heterogeneous.s Piecemeal growth is a very troublesome path for software

evolution.

s Still, it is very popular (being asymptotically the most costeffective when development time goes to zero).

w Middleware technology is an integration technology.s Adopting a given middleware should ease both new

application development and legacy integration.

s To achieve integration while limiting conceptual drift,Middleware tries to cast a Model on heterogeneousapplications.

DS Seminar – Cesena, March 5th, 2003 9 of 127

Middleware and Models (4)

w Before: you have a total mess.s A lot of systems, using different technologies.

s Ad-hoc interactions, irregular structure.

s Each piece must be described in its own reference frame.

w Then: the Integration Middleware (IM) comes.s A new, shiny Model is supported by the IM.

s Existing systems are re-cast under the Model.

s New Model-compliant software is developed.

w After: you have the same total mess.s But, no, now they are CORBA objects, or FIPA agents.

DS Seminar – Cesena, March 5th, 2003 10 of 127

Middleware Technologies

w Abstract Middleware: a common Model.

w Concrete Middleware: a common Infrastructure.

w Example: Distributed Objects.s Abstractly, any Middleware modeling distributed systems

as a collection of network reachable objects has the samemodel: OMG CORBA, Java RMI, MS DCOM, …ü Actually, even at the abstract level there are differences…

s Concrete implementations, instead, aim at actualinteroperability, so they must handle much finer details.ü Until CORBA 2.0, two CORBA implementations from different

vendors were not interoperable.

DS Seminar – Cesena, March 5th, 2003 11 of 127

Middleware Standards

w Dealing with infrastructure, a key issue is the so-called Network Effect.s The value of a technology grows with the number of its

adopters.

w Standardization efforts become critical to buildmomentum around an infrastructure technology.s Large standard consortia are built, which gather several

industries together (OMG, W3C, FIPA).

s Big industry players try to push their technology as defacto standards, or set up more open processes for them(Microsoft, IBM, Sun).

DS Seminar – Cesena, March 5th, 2003 12 of 127

Middleware Discussion Template

w Presentation and analysis of the model underlyingthe middleware.s What do they want your software to look like?

w Presentation and analysis of the infrastructurecreated by widespread use of the middleware.s If they conquer the world, what kind of world will it be?

w Discussion of implementation issues at theplatform and application level.s What kind of code must I write to use this platform?

s What kind of code must I write to build my own platform?

3

DS Seminar – Cesena, March 5th, 2003 13 of 127

Distributed Objects

w Distributed systems need quality software, and theyare a difficult system domain.

w OOP is a current software best practice.

w Question is:s Can we apply OOP to Distributed Systems programming?

s What changes and what stays the same?

w Distributed Objects apply the OO paradigm toDistributed Systems.s Examples: CORBA, DCOM, Java RMI, JINI, EJB.

DS Seminar – Cesena, March 5th, 2003 14 of 127

Back to Objects

w To describe the Distributed Objects model, let’sreview the basic OOP computation model.s The principles motivating OOP.

s The central concept.

s The central computation mechanism.

s The central software evolution mechanism.

w “Teach yourself OOP in 7 slides”.

DS Seminar – Cesena, March 5th, 2003 15 of 127

Five OOPrinciples (1)

w Modular Linguistic Units.s The language must support modules in its syntax.

w Embedded Documentation.s A module must be self-documenting.

w Uniform Access.s A service must not disclose whether it uses stored data or

computation.

w The three principles above are followed by OOlanguages, but also by Structured languages.

DS Seminar – Cesena, March 5th, 2003 16 of 127

Five OOPrinciples (2)

w Open/Closed Principle (OCP).s The language must allow the creation of modules closed

for use but open for extension.

w Single Choice Principle (SCP).s Whenever there is a list of alternatives, at most one

module can access it.

w The two principles above require Object-Orientation.s OCP requires (implementation) inheritance.

s SCP requires (inclusion) polymorphism.

DS Seminar – Cesena, March 5th, 2003 17 of 127

OOP Concept (1)

The fundamental concept of object-orientedThe fundamental concept of object-orientedprogramming is:programming is:

The Object

The Class

DS Seminar – Cesena, March 5th, 2003 18 of 127

OOP Concept (2)

w Def: Classs “An Abstract Data Type, with an associated Module that

implements it.”

Type + Module = Class

4

DS Seminar – Cesena, March 5th, 2003 19 of 127

Modules and Types

w Modules and types look very different.s Modules give structure to the implementation.

s Types specifies how each part can be used.

w But they share the interface concept.s In modules, the interface selects the public part.

s In types, the interface describes the allowed operationsand their properties.

DS Seminar – Cesena, March 5th, 2003 20 of 127

OOP Mechanism

res = obj.meth(par)

Parameter List

Fundamental OOP Computation Mechanism: Method Call

Method Name

Target Object

Result

Access Operator

DS Seminar – Cesena, March 5th, 2003 21 of 127

OOP Extensibility

w Subclassing is the main OOP extension mechanism,and it is affected by the dual nature of classes.s Type + Module = Class.

s Subtyping + Inheritance = Subclassing.

w Subtyping: a partial order on types.s A valid operation on a type is also valid on a subtype.

s Liskov Substitutability Principle.

w Inheritance: a partial order on modules.s A module grants special access to its sub-modules.

s Allows to comply with the Open/Closed Principle.

DS Seminar – Cesena, March 5th, 2003 22 of 127

Distributing the Objects

w Q: How can we extend OOP to a distributed system,preserving all its desirable properties?

w A: Just pretend the system is not distributed, andthen do business as usual!

w …

w As crazy as it may seem, it works!s Well, up to a point at least.

s But generally enough for a lot of applications.

w Problems arise from failure management.s In reliable and fast networks, things run smooth…

DS Seminar – Cesena, March 5th, 2003 23 of 127

(Distributed) Objects

The Object

The Class

The Remote Interface

The fundamental concept of Distributed Objects is:The fundamental concept of Distributed Objects is:

DS Seminar – Cesena, March 5th, 2003 24 of 127

(Distributed) Objects

res = obj.meth(par)

Parameter ListSent on the network

Method NameDeclared in the remote interface

Target ObjectEncapsulates address and protocol

ResultSent back

Access OperatorGrants location transparency

Fundamental Computational Mechanism: Remote Method Call

5

DS Seminar – Cesena, March 5th, 2003 25 of 127

Distributed (Objects)

Communication Mechanisms Structured Object Oriented

Explicit C Sockets java.net.*

Implicit RPC CORBA

java.rmi.*

DS Seminar – Cesena, March 5th, 2003 26 of 127

Distributed (Objects)

w The Distributed Objects communication model isimplicit.s Transmission is implicit, everything happens through

stubs.

s The stub turns an ordinary call into an IPC mechanism.

s One gains homogeneous handling of both local andremote calls (location transparency).

DS Seminar – Cesena, March 5th, 2003 27 of 127

Distributed (Objects)

w The Distributed Objects communication model isobject oriented.s Only objects exist, invoking operations on each other.

s The interaction is Client/Server with respect to theindividual call (micro C/S, not necessarily macro C/S).

s Each call is attached to a specific target object: the resultcan depend on the target object state.

s Callers refer to objects through an object reference.

DS Seminar – Cesena, March 5th, 2003 28 of 127

Broker Architecture

w Broker is an architectural pattern in [BMRSS96].s Stock market metaphor.

s Publish/subscribe scheme.

s Extensibility, portability, interoperability.

s A broker reduces logic links from Nc•Ns to Nc + Ns .

Broker

Client 1

Client 2

Client 3

Server 1

Server 2

Server 3

Client 1

Client 2

Client 3

Server 1

Server 2

Server 3

DS Seminar – Cesena, March 5th, 2003 29 of 127

Proxy and Impl, Stub and Skeleton

Network

DS Seminar – Cesena, March 5th, 2003 30 of 127

What’s CORBA

w The words An acronym for Common ORB Architecture.

s ORB is an acronym again: Object Request Broker.

s CORBA is a standard, not a product.

w The proponentss Object Management Group (OMG).

ü A consortium of more than 800 companies, founded in 1989.

ü Present all major companies. http://www.omg.org

ü The same institution that took up the Unified Modeling Languagespecification from its original creator, Rational Software Corp.

6

DS Seminar – Cesena, March 5th, 2003 31 of 127

Object Management Architecture

w The OMA architecture wasOMG overall vision fordistributed computing.s The Object Request Broker is

OMA backbone.

s The IIOP protocol is thestandard application transportthat grants interoperability.

w Now, the OMA vision hasbeen superceded by theModel Driven Architecture,almost a meta-standard initself.

DS Seminar – Cesena, March 5th, 2003 32 of 127

Object Management Architecture

w The Common ObjectServices serve as CORBAsystem libraries, bundledwith the ORB infrastructure.s Naming e Trader Service.

s Event Service.

s Transaction Service.

s ...

DS Seminar – Cesena, March 5th, 2003 33 of 127

Object Management Architecture

w The Common Facilities areframeworks to developdistributed applications invarious domains.s Horizontal Common Facilities

handle issues common tomost application domains(GUI, Persistent Storage,Compound Documents).

s Vertical Common Facilitiesdeal with traits specific of aparticular domain (Financial,Telco, Health Care).

DS Seminar – Cesena, March 5th, 2003 34 of 127

OMA - ORB Core

w Part of the OMA dealing with communicationmechanisms.

w Allows remote method invocation regardless of:s Location and network protocols.

s Programming language.

s Operating System.

w The transport layer is hidden from applications usingstub code.

DS Seminar – Cesena, March 5th, 2003 35 of 127

Remote invocation: Participants

w A Request is the closure of an invocation,complete with target object, actualparameters, etc.w The Client is the object making the request.w The Object Implementation is the logical

object serving the request.w The Servant is the physical component that

incarnates the Object Implementation.w The ORB connects Client and Servant.

DS Seminar – Cesena, March 5th, 2003 36 of 127

ORB Core Components

ORB Core

DynamicInvocation

IDLStubs

ORBInterface

ObjectAdapter

Static IDLSkeleton

DynamicSkeleton

Client Object Implementation

Interfaccia identica per ogni implementazione di ORB

Possono esistere molti Object Adapter

Ci sono stub e skeleton per ogni typo di oggetto

Interfaccia dipendente dallo specifico ORB

Invokes a method creating a request Implements a method

accepting the request

Request Path

7

DS Seminar – Cesena, March 5th, 2003 37 of 127

ORB Core Interfaces

w Client side interfaces:s Client Stub.

s Dynamic Invocation Interface(DII).

w Server side interfaces:s Static Skeleton.

s Dynamic Skeleton Interface(DSI).

s Object Adapter (OA).ü CORBA 2.0 Æ BOA.

ü CORBA 2.3 Æ POA.

ORB Core

DynamicInvocation

IDLStubs

ORBInterface

ObjectAdapter

Static IDLSkeleton

DynamicSkeleton

Client Object Implementation

Interfaccia identica per ogni implementazione diORBPossono esistere molti ObjectAdapterCi sono stub e skeleton per ogni typo dioggettoInterfaccia dipendente dallo specificoORB

ORB Core

DynamicInvocation

IDLStubs

ORBInterface

ObjectAdapter

Static IDLSkeleton

DynamicSkeleton

Client Object Implementation

Interfaccia identica per ogni implementazione diORBPossono esistere molti ObjectAdapterCi sono stub e skeleton per ogni typo dioggettoInterfaccia dipendente dallo specificoORB

DS Seminar – Cesena, March 5th, 2003 38 of 127

ORB Core Interfaces

w Client (IDL) Stub.s Specific of each remote interface and operation, with static

typing and dynamic binding.

s Automatically generated by compilation tools.

s Conversion of request parameter in network format(marshaling).

s Synchronous, blocking invocation.

DS Seminar – Cesena, March 5th, 2003 39 of 127

ORB Core Interfaces

w Dynamic Invocation Interface (DII)s Generic, with dynamic typing and dynamic binding.

w Directly provided by the Object Request Broker.

w Both synchronous and deferred synchronousinvocations are possible.

w Provides a reflective interfaces Request, parameter, ...

DS Seminar – Cesena, March 5th, 2003 40 of 127

ORB Core Interfaces

w Static skeleton (IDL)s Corresponds to the Client Stub on Object Implementation

side.

s Automatically generated by compilation tools.

s Builds parameters from network format (unmarshaling),calls the operation body and sends back the result.

w Dynamic Skeleton Interface (DSI)s Conceptually alike to Dynamic Invocation Interface.

s Allows the ORB to forward requests to ObjectImplementations it does not manage.

s Can be used to make bridges between different ORBs.

DS Seminar – Cesena, March 5th, 2003 41 of 127

ORB Core Interfaces

w Object Adapter (OA)s Connects the Servant (the component containing

an Object Implementation) to the ORB.

s In CORBA the Object Implementation is reactive.ü The OA has the task of activating and deactivating it.

s There can be many Object Adapters.ü The CORBA 2.0 standard specifies the Basic Object

Adapter (BOA).

ü The CORBA 2.3 standard specifies the Portable ObjectAdapter (POA).

DS Seminar – Cesena, March 5th, 2003 42 of 127

ORB Core Interfaces

w ORB Interfaces Common interface for

maintenance operations.

s Initialization functions.

s Bi-directional translationbetween Object Referenceand strings.

s Operations of this interfaceare represented as belongingto pseudo-objects.

ORB Core

DynamicInvocation

IDLStubs

ORBInterface

ObjectAdapter

Static IDLSkeleton

DynamicSkeleton

Client Object Implementation

Interfaccia identica per ogni implementazione diORBPossono esistere molti ObjectAdapterCi sono stub e skeleton per ogni typo dioggettoInterfaccia dipendente dallo specificoORB

8

DS Seminar – Cesena, March 5th, 2003 43 of 127

CORBA Interoperability

w CORBA is heterogeneous for Operating System,network transport and programming language.

w With the 1.2 version of the standard, interoperationwas limited to ORBs from the same vendor.

w In CORBA 1.2 two objects managed by ORBs fromdifferent vendors could not interact.

w CORBA 2.x grants interoperability among ORBsfrom different vendors.

DS Seminar – Cesena, March 5th, 2003 44 of 127

CORBA Interoperability

w Recipe for interoperability1) Communication protocols shared among ORBs.

2) Data representation common among ORBs.

3) Object Reference format common among ORBs.

fi Only ORBs need to be concerned withinteroperability.

DS Seminar – Cesena, March 5th, 2003 45 of 127

CORBA Interoperability

w Common communication protocolss The standard defines the General Inter-ORB Protocol

(GIOP), requiring a reliable and connection-orientedtransport protocol.s With TCP/IP one has Internet Inter-ORB Protocol (IIOP).

w Common data representations As part of GIOP the CDR (Common Data Representation)

format is specified.s CDR acts at the Presentation layer in the ISO/OSI stack.

w Common Object Reference formats Interoperable Object Reference (IOR) format.

ü Contains all information to contact a remote object (or more).

DS Seminar – Cesena, March 5th, 2003 46 of 127

OMA - Common Object Services

w Design guidelines for CORBAservicess Essential and flexible services.

s Widespread use of multiple inheritance (mix-in).

s Service discovery is orthogonal to service use.

s Both local and remote implementations are allowed.

w CORBAservices are ordinary ObjectImplementations.

DS Seminar – Cesena, March 5th, 2003 47 of 127

OMA - Common Object Services

w Naming Service.s Handles name ¤ Object Reference associations.

s Fundamental as bootstrap mechanism.

s Allows tree-like naming structures (naming contexts).

w Object Trader Service.s Yellow Page service for CORBA objects.

s Enables highly dynamic collaborations among objects.

DS Seminar – Cesena, March 5th, 2003 48 of 127

OMA - Common Object Services

w Life Cycle Service.s Object creation has different needs with respect to object

use fi the Factory concept is introduced.

s Factory Finders are defined, to have location transparencyeven at creation time.

s This service does not standardize Factories (they areclass-specific), but copy, move and remove operations.

9

DS Seminar – Cesena, March 5th, 2003 49 of 127

OMA - Common Object Services

w Event Service.s Most objects are reactive.

s The Event Service enables notification delivery,decoupling the producer and the consumer with an eventchannel.

s Supports both the push model (observer) and the pullmodel for event distribution.

s Suitable administrative interfaces allow to connect eventsupplier and event consumer of push or pull kind.

w Notification Services Improves the Event Service, with more flexibility.

DS Seminar – Cesena, March 5th, 2003 50 of 127

OMA - Common Object Services

w Transaction Service.s Transactions are a cornerstone of business

application.

s A two-phase commit protocol grants ACIDproperties.

s Supports flat and nested transactions.

w Concurrency Control Service.s Manages lock objects, singly or as part of groups.

s Integration with the Transaction Service.ü Transactional lock objects.

DS Seminar – Cesena, March 5th, 2003 51 of 127

The OMG IDL Language

Motivation for an Interface Definition Language.

w CORBA is neutral with respect to programminglanguages.

w Different parts of an application can be written indifferent languages.

w A language to specify interactions across languageboundaries is needed fi Interface DefinitionLanguage (IDL).

DS Seminar – Cesena, March 5th, 2003 52 of 127

The OMG IDL Language

Overall OMG IDL language features.

w Syntax and lexicon similar to C/C++/Java.

w Only expresses the declarative part of a language.

w Services are exported through interfaces.

w Support for OOP concept as inheritance orpolymorphism.

DS Seminar – Cesena, March 5th, 2003 53 of 127

Programming with CORBA

w The Broker architecture allows to build distributedapplications, heterogeneous with respect to:s Operating System.

s Network Protocol.

w The OMG IDL language allows to build distributedapplications, heterogeneous with respect to:s Programming Language.

w But, the system will have to be implemented in somereal programming languages at the end.s The IDL specification have to be cast into those languages

DS Seminar – Cesena, March 5th, 2003 54 of 127

Programming with CORBA

w CORBA programming environment feature a toolcalled IDL compiler.s It accepts OMG IDL as input, and generates code in a

concrete implementation language.

w With respect to a given IDL interface, a componentmay be a client and/or a server.s The client requests the service, the server exports it.

s The IDL compiler generates code for both.

10

DS Seminar – Cesena, March 5th, 2003 55 of 127

Programming with CORBA

DS Seminar – Cesena, March 5th, 2003 56 of 127

Programming with CORBA

w For each supported programming language,the CORBA standard specifies a LanguageMapping:s How every OMG IDL construct is to be translated.

s Programming techniques that are to be used.

w C++ Language Mapping.

w Java Language Mapping.

w Smalltalk Language Mapping.

w Python Language Mapping.

DS Seminar – Cesena, March 5th, 2003 57 of 127

Objects and Metadata

w Compile-time vs. Run-times In C++ and Java the state of an object can change at

runtime, but its structure is carved by the compilationprocess.

s Usually, the overall set of classes and functions belongingto the system is defined at compile time and cannot vary .

w With dynamic linking these rules can be overcome,but traditional systems tend to follow them anyway.

DS Seminar – Cesena, March 5th, 2003 58 of 127

Objects and Metadata

w To increase system flexibility, one has to add a newlevel that:s Describes system capabilities.

s Allows changing them at runtime.

w Data belonging to this second level are “data aboutother data”, that is they are metadata (e. g. theschema of a DB).s Systems have a (usually small) number of meta-levels

(e.g. objects, classes and metaclasses in Smalltalk, ot thefour-layer meta-model of UML).

DS Seminar – Cesena, March 5th, 2003 59 of 127

Objects and Metadata

w Object oriented software system were soon givenmetadata:s Smalltalk has Metaclasses.

s CLOS (Common Lisp Object System) introduced theconcept of Meta-Object Protocol.

s Java has a Reflection API since version 1.1.

w In the book “Pattern Oriented System Architecture: Asystem of Patterns”, Reflection is an architecturalpattern.

DS Seminar – Cesena, March 5th, 2003 60 of 127

CORBA Metadata

w CORBA is an integration technology.

w Therefore, the issue of metadata and Reflection wasgiven appropriate attention.

w In a distributed system, metadata have to bepersistent, consistent and available.

11

DS Seminar – Cesena, March 5th, 2003 61 of 127

CORBA Metadata

w In the OMA architecture, metadata are used inseveral parts:s The Dynamic Invocation Interface allows to act on the

remote operation invocation mechanism itself.

s The Interface Repository allows runtime discovery of newIDL interfaces and their structure.

s The Trader Service gathers services exported by objectsinto a yellow-page structure.

DS Seminar – Cesena, March 5th, 2003 62 of 127

The Dynamic Invocation Interface

w Goals of the DIIs The DII provides a complete and flexible interface to the

remote invocation mechanism, around which CORBA isbuilt.

s The central abstraction supporting the DII is the Requestpseudo-object, which reifies an instance of a remote call(see the Command design pattern in the Gang of Fourbook).

DS Seminar – Cesena, March 5th, 2003 63 of 127

The Dynamic Invocation Interface

w IDL interfaces for the DIIs Firstly, a request attached to a CORBA object needs be

created.s The create_request() operation, belonging to theObject pseudo-interface (minimum of the inheritancegraph), is to be used.

s When a request is created, it is associated to its originalObject Reference for its whole lifetime.

DS Seminar – Cesena, March 5th, 2003 64 of 127

The Dynamic Invocation Interface

w To create a request, one uses the IDL:s module CORBA { // PIDL pseudo interface Object { typedef unsigned long ORBStatus; ORBStatus create_request(in Context ctx, in Identifier operation, // Operation name in NVList arg_list, // Operation arguments inout NamedValue result, // Operation result out Request request, // Newly created request in Flags req_flags; // Request flags); }; // End of Object pseudo interface}; // End of CORBA module

DS Seminar – Cesena, March 5th, 2003 65 of 127

The Dynamic Invocation Interface

w After creation, a request object can be used:s module CORBA {

typedef unsigned long Status; pseudo interface Request { Status add_arg(in Identifier name, in TypeCode arg_type, in any value, in long len, in Flags arg_flags); Status invoke(in Flags invoke_flags); Status delete(); // Destroy request object Status send(in Flags invoke_flags); Status get_response(in Flags response_flags); }; // End of Request interface}; // End of CORBA module

DS Seminar – Cesena, March 5th, 2003 66 of 127

The Dynamic Invocation Interface

w The DII, through request objects, allows selectingthe rendezvous policy:s Synchronous call with invoke().

s Deferred synchronous call with send().

w With deferred synchronous invocations, a group ofrequests can be sent all at once.

w The new Asynchronous Method Invocation (AMI)specification of CORBA 2.4 also introducesasynchronous calls.

12

DS Seminar – Cesena, March 5th, 2003 67 of 127

Synchronous Call with the DII

:Client

add_arg()

serve request and do operation

wake up client

clientblocks

:Object Implementation

:Request {new}

createRequest()

create()

add_arg()

invoke()

DS Seminar – Cesena, March 5th, 2003 68 of 127

Deferred Synchronous Call

:Client

get_response()

add_arg()

serve request and do operationclient

computes

:Object Implementation

:Request {new}

createRequest()

create()

add_arg()

send()

DS Seminar – Cesena, March 5th, 2003 69 of 127

The Interface Repository

w The Interface Repository keeps the descriptions ofall the IDL interfaces available in a CORBA domain.

w Using the Interface Repository, programs candiscover the structure of types they don’t have thestubs for.w The TypeCode interface provides an encoding of

the OMG IDL type system.

DS Seminar – Cesena, March 5th, 2003 70 of 127

The Interface Repository

w Object oriented representation of the syntaxof a language:s The formal grammar (e.g. in BNF notation) can be

turned into a structure of classes andassociations.

s To do this, one defines a class for each non-terminal symbol of the given grammar.

w Approach followed by OO parser generators(ANTLR, JavaCC).s Interpreter design pattern from Gang of Four book.

DS Seminar – Cesena, March 5th, 2003 71 of 127

The Interface Repository

w The BNF expression of alist of words (with rightrecursion) results in theComposite design patternof the Gang of Four book:

<list> ::= <word> | <list> <word>

1..*

contents

1

Word

List

DS Seminar – Cesena, March 5th, 2003 72 of 127

The Interface Repository

w The OMG IDL language representation:s A complete OO representation of the IDL language is

stored within the Interface Repository.

s The IDL BNF results in both has-a and is-a links in theobjects structure.

w The Repository interface is the root of thecontainment hierarchy, whereas the IRObjectinterface is the root of the inheritance hierarchy.w The two Container and Contained interfaces

form a Composite structure.

13

DS Seminar – Cesena, March 5th, 2003 73 of 127

The Interface Repository

0..* 1

IRObject

Contained Container

AttributeDef

ConstantDef ExceptionDef

TypedefDef

InterfaceDef

ModuleDef RepositoryOperationDef

Composite

DS Seminar – Cesena, March 5th, 2003 74 of 127

The Interface Repository

w Using the Interface Repository:s Objects stored within the Interface Repository are an

equivalent representation of actual OMG IDL source code.

s Browsing the Interface Repository, one can even rebuildIDL sources back.

w With Repository IDs, more interface repositories canbe federated.

DS Seminar – Cesena, March 5th, 2003 75 of 127

The Interface Repository

w Every interface derived from IRObject supportstwo kinds of operations.s Read Interface to explore metadata (Introspective

Protocol).

s Write Interface to modify them and create new ones(Intercessory Protocol).

w Every interface derived from Container supportsnavigation operations, as well as new elementscreation operations.

DS Seminar – Cesena, March 5th, 2003 76 of 127

Dynamic Collaboration

w CORBA objects are more adaptable thanordinary, programming language objects suchas Java or C++ objects.w Two CORBA objects A and B, initially

knowing nothing about each other, can set upa collaboration.s Object A uses get_interface() to get anInterfaceDef describing B.s Browsing the Interface Repository, A discovers

the syntax of B supported operations.s Using DII, A creates a request and sends it to B.

DS Seminar – Cesena, March 5th, 2003 77 of 127

Dynamic Collaboration

w With CORBA, the syntax of the operations can bediscovered at runtime.

w But the semantics of the operation is missing: OMGIDL lacks preconditions, postconditions andinvariants.

w More complex systems (like multi-agent systems)need languages to describe the domain of thediscourse (ontologies).

DS Seminar – Cesena, March 5th, 2003 78 of 127

Summary on Distributed Objects

An impressive technology!Extends OOP to Distributed Systems.Hides DS programming complexity.

Supported by an open standard (OMG CORBA).Integration across OSs, networks and languages.

A lot of free implementations available.

wNext in line: Multi-Agent Systemss An emergent technology.s Can they do better than Distributed Objects?

14

DS Seminar – Cesena, March 5th, 2003 79 of 127

Agent Middleware

w According to our previous discussion schema, anAgent middleware is supposed to:s Promote an agent-oriented Model.

s Realize an agent-oriented Infrastructure.

w We will have to go through some steps:s Describe what agents and multi-agent system are.

s Compare the agent/MAS model with the OO model.

s Describe what kind of software components agents are.

s Provide an infrastructure example: the FIPA standard.

s Provide an implementation example: JADE.

DS Seminar – Cesena, March 5th, 2003 80 of 127

What is a software agent?

w A software agent is a software system that can operate indynamic and complex environments.s It can perceive its environment through senses.

s It can affect its environment through actions.

Agent Environment

Sensory data

Actions

DS Seminar – Cesena, March 5th, 2003 81 of 127

Agenthood properties

w Fundamental features.s An agent is autonomous.

s An agent is reactive.

s An agent is social.

w Useful features.s An agent can be proactive (or goal-directed).

s An agent can be mobile.

s An agent can be adaptive (or learning).

Autonomous Agents

Multi Agent Systems

IntelligentAgentsLearning Agents

Mobile Agents

DS Seminar – Cesena, March 5th, 2003 82 of 127

Application areas

w Information management.s Information Filtering.s Information Retrieval.

w Industrial applications.s Process control.s Intelligent manufacturing.

w Electronic commerce.w Computer Supported Cooperative Work.w Electronic entertainment.

DS Seminar – Cesena, March 5th, 2003 83 of 127

Autonomy and Reactivity

w First fundamental trait of an agent: autonomy.s An agent can act on the environment, on the basis of its

internal evolution processes.

w Second fundamental trait: reactivity.s An agent can perceive changes in the environment,

providing responses to external stimuli.

w How do these qualities compare with objects?s Objects are reactive.

s Objects are not autonomous.

DS Seminar – Cesena, March 5th, 2003 84 of 127

Master and Servant (1)

w Fundamental computational mechanism of the OOP:s Method invocation.

s An object exposes its capabilities (public methods).

s Then other objects exploit them how and when they like(they decide when to invoke the methods and whichparameters to pass to them).

w An object decides its behaviour space, but does notfurther control its own behaviour.

w The object is servant, its caller is master.

15

DS Seminar – Cesena, March 5th, 2003 85 of 127

Master and Servant (2)

w Method invocation follows Design by Contract:s It is a synchronous rendezvous, so the caller object has to

wait until the called object completes its task.

s The caller must ensure the correctness precondition of themethod are verified before invoking it.

w Though the caller object chooses the method toinvoke, then it surrenders itself (i.e. its thread ofcontrol) to code that it is controlled by the called.

w The object is master, its caller is servant.

DS Seminar – Cesena, March 5th, 2003 86 of 127

Concurrent OOP

w Classical method invocation is a tight bond betweencaller and called object.s Not that this is always a bad thing (cohesion vs. coupling).

w However, in concurrent OOP things change a lot.s To exploit parallelism, other rendezvous policies are used,

such as deferred synchronous or asynchronous.

s In concurrent method invocation, correctnesspreconditions become synchronization guard predicates.

w The bond of classical Design by Contract isextremely loosened!

DS Seminar – Cesena, March 5th, 2003 87 of 127

A Stairway to Agents

Objects

Active Objects

Actors Agents

Intelligent Agents

Reactive Method Invocation

Invocation Thread != Execution Thread

Persistently running, Mailbox

Sociality

Reasoning

DS Seminar – Cesena, March 5th, 2003 88 of 127

Building a single agent

w Various proposals for an agent architecture.

Autonomy

Reactivity

HybridArchitectures

Deliberative Architectures

ReactiveArchitectures

w Deliberativearchitecturess Explicit, symbolic model of

the environment.

s Logic reasoning.

w Reactive architecturess Stimulus fi Response.

w Hybrid architecturess BDI, Layered, ...

DS Seminar – Cesena, March 5th, 2003 89 of 127

Sociality: From Agent To MAS

w Autonomy and Reactivity are about an agent and itsenvironment.

w Sociality is about having more than one agent andthey building relationships.

w The shift towards the social level marks the borderbetween Agent research and Multi-Agent Systems(MAS) research.s This is the major trait differentiating (non-intelligent)

agents from classical actors.

DS Seminar – Cesena, March 5th, 2003 90 of 127

Communication in MAS

w MASs need a richer, more loosely coupledcommunication model with respect to OO systems.w Approach: trying to mimick human communication

with natural language.s When people speak, they try to make things happen.s Listening to someone speaking, something of her internal

thoughts is revealed.s When institutionalized, word is law (“I pronounce you…”).

w A linguistic theory results in a communication model.s Speech Act Theory.s Agent Communication Languages (ACLs).

16

DS Seminar – Cesena, March 5th, 2003 91 of 127

Speech Act Theory and ACLs

w Theory of human communication with language.s Considers sentences for their effect on the world.

s A speech act is an act, carried out using the language.

w Several categories of speech acts.s Orders, advices, requests, queries, declarations, etc.

w Agent Communication Languages use messages.s Messages carry speech act from an agent to another.

s A message has transport slots (sender, receiver, …).

s A message has a type (request, tell, query).

s A message has content slots.

DS Seminar – Cesena, March 5th, 2003 92 of 127

Say What?

w An Agent Communication Language captures:s The speaker (sender) and hearer (receiver) identities.

s The kind of speech act the sender is uttering.

s This should be enough to understand the message.

w “I request that you froznicate the quibplatz”.s …

w There is more to the world than people and words.s There are also things.

s A common description of the world is needed.

s Describing actions, predicates and entities: ontologies.

DS Seminar – Cesena, March 5th, 2003 93 of 127

Interaction and Coordination

w A MAS is more than a bunch of agents.s In order to get something useful, some constraints

have to be set on what agents can do.s Agents can represent different stakeholders.

w The society metaphor as a modeling tool.s Social Role Model: which parts can be played in the

society (static, structural model).s Interaction and Coordination Model: which patterns

conversation can follow (dynamic, behavioralmodel).

w Specifying conversation patterns withInteraction Protocols.

DS Seminar – Cesena, March 5th, 2003 94 of 127

Standards for Agents

w To achieve interoperability among systemsindependently developed, a common agreement isneeded.

w Several institutions are interested in buildingstandards for agent technology.s Agent Society;s Foundation for Intelligent Physical Agents;s Internet Engineering Task Force;s Object Management Group;s World Wide Web Consortium.

DS Seminar – Cesena, March 5th, 2003 95 of 127

FIPA

w FIPA is a world-wide, non-profit association ofcompanies and organizations.

w FIPA produces specifications for generic MASand agent technologies.

w Promotes agent-level and platform-levelinteroperability among MAS developedindependently.

Foundation for Intelligent Physical Agents

http://www.fipa.org

DS Seminar – Cesena, March 5th, 2003 96 of 127

FIPA Platform Architecture

Agent Platform

AgentManagement

System

DirectoryFacilitator

Message Transport System

Agent

Software

Message Transport System

17

DS Seminar – Cesena, March 5th, 2003 97 of 127

FIPA ACL Message

(REQUEST :sender ( agent-identifier :name da0) :receiver (set ( agent-identifier :name df) ) :content "((action (agent-identifier :name df ) (register (df-agent-description :name (agent-identifier :name da0) :services (set ( service-description :name sub-sub-df :type fipa-df :ontologies (set fipa-agent-management ) :languages (set FIPA-SL) :protocols (set fipa-request ) :ownership JADE )) :protocols (set ) :ontologies (set ) :languages (set ) )) ) )" :reply-with rwsub1234 :language FIPA-SL0 :ontology FIPA-Agent-Management :protocol fipa-request :conversation-id convsub1234)

DS Seminar – Cesena, March 5th, 2003 98 of 127

FIPA ACL Message Layers

w The previous message is a Speech-Act Level message.

w A Speech-Act Level message has an encapsulated content.s Expressed in a content language, according to an ontology.

w For transport and delivery reasons, it is encapsulated again.s An envelope is added, to form a Transport-Level message.

DS Seminar – Cesena, March 5th, 2003 99 of 127

FIPA Ontologies and IPs

w FIPA specifications heavily rely on ontologies.s All significant concepts are collected in standard

ontologies (fipa-agent-management , etc.).

s An Ontology Service is specified for ontology brokering.

w A set of standard Interaction Protocols is provided.s Elementary protocols directly induced by the semantics of

the single communicative acts (fipa-request, fipa-query, etc.).

s More sophisticated negotiation protocols (fipa-contract-net, fipa-auction-dutch, etc.).

DS Seminar – Cesena, March 5th, 2003 100 of 127

FIPA and JADE

w FIPA is a world-wide, non-profit association of companiesand organizations (http://www.fipa.org).

w FIPA produces specifications for generic MAS and agenttechnologies.

w Promotes agent-level and platform-level interoperabilityamong MAS developed independently.

A FIPA 2000-compliant agent platform.A Java framework for the development of MAS.An Open Source project, © TI Labs, LGPL license.

JADE is a joint development of TI Labs and Parma University.Project home page: http://jade.cselt.it.

DS Seminar – Cesena, March 5th, 2003 101 of 127

History of JADE

w Project started July 1998

w Present at both the first(Seoul, 1999) and thesecond (London, 2001)FIPA test.

w Many users worldwide.s 13 released versions.

s Internet-based support.

s Leading Open Sourceplatform.

DS Seminar – Cesena, March 5th, 2003 102 of 127

JADE Family

w JADE has solved the basic MAS infrastructureproblem.s Most new AgentCities nodes fire up JADE and go.

s With JADE-LEAP, FIPA runs on wireless devices.

s With BlueJADE, runs within J2EE app servers.ü Palo Alto HP Labs OS spinoff project.

(http://sourceforge.net/projects/bluejade).

w Users are moving on to higher level tasks.ü Ontology design (Protegé plugin, WSDLTool).

ü Intelligent agents design (ParADE, Corese, JESS).

18

DS Seminar – Cesena, March 5th, 2003 103 of 127

JADE Features

w Distributed Agent Platform.s Seen as a whole from the outside world.s Spanning multiple machines.

w Transparent, multi-transport messaging.s Event dispatching for local delivery.s Java RMI for intra-platform delivery.s FIPA 2000 MTP framework.

– IIOP protocol for inter-platform delivery.– HTTP protocol and XML ACL encoding.

s Protocol-neutral, optimistic address caching.

DS Seminar – Cesena, March 5th, 2003 104 of 127

JADE Features

w Two levels concurrency model.s Inter-agent (pre-emptive, Java threads).

s Intra-agent (co-operative, Behaviour classes).

w Object oriented framework for easy access toFIPA standard assets.s Agent Communication Language.

s Agent Management Ontology.

s Standard Interaction Protocols.

s User defined Languages and Ontologies.

DS Seminar – Cesena, March 5th, 2003 105 of 127

JADE Features

w User defined content languages and ontologies.s Each agent holds a table of its capabilities.

s Message content is represented according to a meta-model, in a content language independent way.

s User defined classes can be used to model ontologyelements (Actions, Objects and Predicates).

w Agent mobility.s Intra-platform, not-so-weak mobility with on-demand class

fetching.

DS Seminar – Cesena, March 5th, 2003 106 of 127

JADE Features

w Event system embedded in the kernel.s Allows observation of Platform, Message, MTP and

Agent events.s Synchronous listeners, with lazy list construction.

w Agent based management tools.s RMA, Sniffer and Introspector agents use FIPA

ACL.s Extension of fipa-agent-management ontology for

JADE-specific actions.s Special jade-introspection observation ontology.

DS Seminar – Cesena, March 5th, 2003 107 of 127

JADE Platform Architecture

w Software Agents are software components.s They are hosted by a runtime support called Agent Container.

s Many agents can live in a single container (about 1000 per host).

w Selective Network Awareness and Flexible Deployment.s Any mapping between agents, containers and hosts.

Agent Container

Network Host Network Host

Main Container Agent Container

Link

DS Seminar – Cesena, March 5th, 2003 108 of 127

JADE Main Container

19

DS Seminar – Cesena, March 5th, 2003 109 of 127

JADE Message Dispatching

Message DispatcherAGENT CONTAINERMessage DispatcherAGENT CONTAINER (FE)Message DispatcherAGENT CONTAINERJava RMIAgent2eventLocalcacheAgentGlobalDescriptorTableeventAgent3Agent1AgentContainerTable

DS Seminar – Cesena, March 5th, 2003 110 of 127

JADE Agent Architecture

DS Seminar – Cesena, March 5th, 2003 111 of 127

JADE Concurrency Model

w Multithreaded inter-agentscheduling.

w Behaviour abstractions Composite for structure

s Chain of Responsibility forscheduling.

s No context saving.

x:SequentialBehaviour y:SequentialBehaviour

x1:SimpleBehaviour x2:SimpleBehaviour y1:SimpleBehaviour y2:SimpleBehaviour

1 2

:Agent

1.1 1.2 2.1 2.2

run()

mainLoop()

b1 = schedule()

Exc. handler

run()

mainLoop()

Exc. handler

run()

mainLoop()

Exc. handler

run()

mainLoop()

b2 = schedule()

Exc. handler

b1.action() b1.done()?

a) b) c) d)

run()

mainLoop()

Exc. handler

run()

mainLoop()

Exc. handler

b2.action() b2.done()?

e) f)

DS Seminar – Cesena, March 5th, 2003 112 of 127

Behaviours and Conversations

w The behaviours concurrency model can handlemany interleaved conversations.s Using the Composite structure, arbitrarily fine grained task

hierarchies can be defined.s The new FSMBehaviour supports nested FSMs.

w FIPA Interaction protocols are mapped to suitablebehaviours:s An Initiator Behaviour to start a new conversation.

s A Responder Behaviour to answer an incoming one.

DS Seminar – Cesena, March 5th, 2003 113 of 127

JADE Behaviours Model

DS Seminar – Cesena, March 5th, 2003 114 of 127

JADE Behaviours Example

Fipa-Request interaction protocol (FIPA 97 spec).

requestaction

not-understood refusereason agree

failurereason

informDone(action)

inform(iota x (result action) x)

20

DS Seminar – Cesena, March 5th, 2003 115 of 127

JADE Behaviours Example

Object structure for FipaRequestInitiatorBehaviour.

main:FipaRequestInitiatorBehaviour

step1:SenderBehaviour step2:NonDeterministicBehaviour step3:NonDeterministicBehaviour

NotUnderstood:SimpleBehaviour refuse:SimpleBehaviour agree:SimpleBehaviour

failure:SimpleBehaviour inform:SimpleBehaviour

DS Seminar – Cesena, March 5th, 2003 116 of 127

JADE Content Metamodel

Element

AgentAction

IRE VariableConcept AggregatePrimitive

Can be used as the content of an ACL message

Indicated entities (abstract or concrete)

An ontology deals with these types of element

Predicate Term

ContentElementList

ContentElement

Can be true or false

DS Seminar – Cesena, March 5th, 2003 117 of 127

JADE Content Processing

Parser

Encoder

Parser

Encoder

Content Language

Codec Ontology

String/byte[] AbsContentElement ContentElement

content of the ACL Message

Agent internal representation

ContentManager

Validation

DS Seminar – Cesena, March 5th, 2003 118 of 127

JADE Support Tools

w Administration tools.s RMA Management Agent.

ü White pages GUI.

ü Agent life cycle handling.

s Directory Facilitator GUI.ü Yellow pages handling.

w Development tools.s DummyAgent.

ü Endpoint Debugger.

s Message Sniffer.ü Man-in-the-middle.

DS Seminar – Cesena, March 5th, 2003 119 of 127

JADE Support Tools

DS Seminar – Cesena, March 5th, 2003 120 of 127

JADE Internals

w JADE is a MAS infrastructure.s Applications developed over JADE use agent-level

modeling and programming.

s Software components hosted by JADE exhibit agent-levelfeatures (they comply with the weak agent definition).

s JADE API is an agent-level API.

w JADE is implemented in Java.s JADE applications integrate well with Java technology.

s JADE runtime exploits object-oriented techniques.

s JADE API is an object-oriented API.

21

DS Seminar – Cesena, March 5th, 2003 121 of 127

JADE Layered Architecture

w JADE architecture is divided into two layers:s Platform layer (uses object-oriented concepts, distribution via RMI).

s Agent layer (uses agent-level concepts, distribution via ACL).

w JADE architecture has two kind of interfaces:s Vertical interfaces (bidirectional connections between layers).

s Horizontal interfaces (HRMI at platform layer, HACL at agent layer).

HRMI

HACL

V V

Agent Container

Network Host Netw ork Host

Main Container Agent Container

Link

V

DS Seminar – Cesena, March 5th, 2003 122 of 127

Inter-layer Relationships

s Def.: X meta-of Y: Layer X describes and possibly controls layer Y.

s Def.: X support-of Y: Layer X provides services to layer Y.

w Platform support-of Agent: It’s the runtime system for agents.

w Agent meta-of Platform: Description with JADE ontologies.

w Agent meta-of Agent: It’s a self describing layer.

JADE Agent Level

JADE Platform Level

meta-of

support -of

meta-of

DS Seminar – Cesena, March 5th, 2003 123 of 127

JADE Core Classes

AgentManager<<Interface>>

java.rmi.Remote<<Interface>>

AgentContainer<<Interface>>

MainContainer<<Interface>>

0..* 10..* 1register with

MainContainerImpl

GADT

1

1

1

1

maintains

AgentDescriptor

agentID : AID

1

0..1

1

agentID : AID

0..1

AgentToolkit<<Interface>>Agent

10..* 10..*

uses

LADT

agentID : AID

1

0..1

1

agentID : AID

0..1

acc

AgentContainerImpl

1 11 1

maintained by

1

1

1

1

communicates using

DS Seminar – Cesena, March 5th, 2003 124 of 127

Agent Suspension

A : Agent theAMS : AMS runtime : AgentManager

B : AgentcontainerForB: AgentContainer

frontEnd: MainContainer

ACL request to suspend B

verify

suspend suspend

suspend suspend

suspend yourself

Horizontal, Remote Operation (Platform level)

Horizontal, Remote Operation (Agent level)

Vertical, Local Operation (DOWN)

Role switch

Vertical, Local Operation (UP)

From here, it is as if B decided to suspend itself

DS Seminar – Cesena, March 5th, 2003 125 of 127

JADE Agent Class

DS Seminar – Cesena, March 5th, 2003 126 of 127

Summary on Multi-Agent Systems

An interesting technology!Connects Artificial Intelligence and Distributed Systems.

Hides DS programming complexity.Promotes loosely coupled, multi-authority systems.

Supported by an open standard (FIPA).Integration across OSs, networks and languages.

A lot of free implementations available (e.g. JADE).

w Now, Agent Technology is almost famous.s Will it mainstream?s Will it replace Web Services? EJBs? .NET?

22

DS Seminar – Cesena, March 5th, 2003 127 of 127

Any Order of Business

w Live Demo of JADE.

w Students Projects with JADE?

w …