Transcript Diapositiva 1

AOT Lab
Dipartimento di Ingegneria
dell’Informazione
Università degli Studi di Parma
A Testbed for Agent Mediated
Service Composition
Agostino Poggi, Michele Tomaiuolo,
Paola Turci
AOT Lab - DII, University of Parma
Outline
 Overview of the network infrastructure
 Abstract Model
 FIPA2000 reification
 Evaluation and testing activities
 Dynamic service composition in Agentcities
 Provided services
 Event organizer - demonstration held at the end of the
project
 Concluding discussion
AT2AI04 – Vienna, April 14th, 2004
2
Agentcities.RTD Project
Testbed for a Worldwide Agent Network:
Research and Development
Motorola, Adetti, Agentscape, AEGIS, BT Exact,
Broadcom Eirean, Communication Technologies, DFKI,
EPFL, Fujitsu, Imperial College, Queen Mary College,
Telecom Italia Lab, UPC, University of Parma
Time span: 2 years from July 2001
AT2AI04 – Vienna, April 14th, 2004
3
Objectives
 Construct a worldwide, open network of platforms hosting
agent-based services
 Explore the deployment of agent technologies in an open
environment
 Realize a benchmark environment to validate and test compliance
to relevant technology standards and provide input to the standards
themselves
 Enable the dynamic, intelligent and autonomous composition of
services to achieve user and business goals
• Complex agent-based applications are currently deployed on the
network
• Two prototype applications
• The scope was not to advocate any particular technology or approach
but was simply demonstrative of the network potentiality
AT2AI04 – Vienna, April 14th, 2004
4
The Network
 Backbone of 14 agent
platforms
 Deployed as a 24/7
test bed
 Hosting services and
prototype applications
developed during the
project
 160 connected - 80
active platforms
 Heterogeneous network
 Zeus, FIPA-OS,
Comtec, Agentworks,
...
 2/3 are JADE, LEAP
and BlueJADE
AT2AI04 – Vienna, April 14th, 2004
5
Network Architecture
 Three layer Model
 Abstraction
 Reification
 Deployment
 Abstract Model - defining
the main elements found in
the network
 Actors
 Services
 Domains
 Main Features
 Structured around
domains and policies
• Arbitrary organizational
structures
 Abstract model +
reifications
• Bind in multiple
technologies
(WS/FIPA/GRID)
• Instantiated as Directories
with domain Policies
The Restaurants Directory is supported by the Members Directory
AT2AI04 – Vienna, April 14th, 2004
6
FIPA2000 Reification
 Mapping



Actors cast as FIPA agents
Agent directories as FIPA AMS services
Service directories as FIPA DF services
 Network services - central node
 Agent Platform Directory
 Agent Directory
 Service Directory
 These services are based on
•
Database of active platforms
•
A polling agent which uses the data
source of registered entities and
regularly polls the instances found
•
Interfaces
▫
▫
• Generic architecture for Agentcities network
directory services (platforms, agents and services)
FIPA standard interfaces, for agents
Web interfaces, for humans
AT2AI04 – Vienna, April 14th, 2004
7
Evaluation and Testing
Activities
 Network survey - goal, register
periodically and in a passive way data
related to the network characteristics
 Functional Test - goal, verify the
functionality of the central unit and of
the single connected platforms (e.g.
connectivity matrix, burst test, etc)
Unkow n
11%
Jade
60%
FIPA-OS
6%
BlueJade
4%
Opal
Genie1%
1% JDK1.3.1
1%
Comtec
1%
Mage
1%
FIPA-Jack
1%
AAP
Agentw orks
4%
2%
Leap
Zeus2%
F-Rock
2%
1%
LSystems
Jade-S
Fipa++
1%
1%
1%
Network Heterogeneity
 Service test - goal, verify the
functionality and potentiality of
the services available on the
network
Service Composition
AT2AI04 – Vienna, April 14th, 2004
8
Drawbacks
 The deployed network services, based on this first
reification, proved to be useful
 Despite this, a number of issues need to be
addressed :
 Centralization, robustness and scalability
 Services independence
 Services registration
• Services can only be registered locally
• Registering a platform in the system requires a human to access
a web site
AT2AI04 – Vienna, April 14th, 2004
9
Network Infrastructure:
2nd Reification
 Platform Directory agent
 Hierarchical structure
 Platform registration
 Platform Service agent
 Each Agentcities platform should host a PS agent
 The PS queries the PD service to obtain list of currently active platforms in
the network
• In the background the PS agent may proactively gain status information about
the network
 When requested, each PS agent provides
• The platform ping service
• Test results for remote platforms
 Network Service agent
 The main duty of a NS agent is to show one or more matrix of the network
platforms
 The NS agent makes use of the PD service to obtain a provisional list of up
platforms to survey
AT2AI04 – Vienna, April 14th, 2004
10
Current Priorities
 Deployment
 Wide deployment of the new services on the project
partners’ platforms
 Automated procedure for the deployment of an
Agentcities/OpenNET node
 Make it easier for each partner to test basic network
functionalities
 Testing
 More in deep tests of the new distributed architecture
AT2AI04 – Vienna, April 14th, 2004
11
Agent
generation
and hosting
Event
Organizer
service for businesses
Demonstration
 Supported actionsScenario
Agent creation
Agent deployment
Advertisement (DF and Trade House)
Advertisement,
discovery
and
Typical auction-style
trading
negotiation
activitiesof products
 Ontology
independence
 Concurrent
auctions
 Constraint-based
search Security
Repository
for ontologies
 Bidding strategies
infrastructure
to protect the
A set
offered by a virtual
 ofFederation
access
to the Banking
Service
 services
History function
 Ontology
language
(DAML+OIL)
agent-based
banking
institution
 Multi-attribute
negotiation
 Constraint-based
search
Two key
functionalities:

Ontologies are centrally maintained
 Servant
agents

The
payment
service
 Ontology independence  A Certificate Authority service
 Role-based access control
 The account management service
 A plug-in for agent security
 Authorization and authentication management
Interface (FIPA and Web)
Reference scenario of a demonstration held at the end of the project
AT2AI04 – Vienna, April 14th, 2004
12
Event Organizer Agent-Based Web-Application
 The EO enables small business in the entertainment area
 Book all needed venues and services
 Sell the tickets
 Web interface
 List a set of needed services
 Fix desired constraints on each individual service and among
different services
 Agent-based application
 Global goal is split into sub-goals, assigned to skilled solver agents
 Solver agents return a list of services that fulfill local constraints
 The organizer finds a solution that fulfills cross constraints
AT2AI04 – Vienna, April 14th, 2004
13
Event Organizer Matchmaking
 The Event Organizer uses the marketplace infrastructure
(Trade House) to search for suitable venues
 Service discovery is a two step process
• Components required by the application are discovered using the
global directory
• Single services are discovered and negotiated on a marketplace
 If found, a proper solution is proposed to the user as a list
of services that allow the arrangement of the event
 The constraint validation process is distributed between
 Trade House, which checks the constraints regarding individual
services
 Event Organizer, which instead checks the constraints that link the
features of different services
AT2AI04 – Vienna, April 14th, 2004
14
Event Organizer Negotiation
 The selected services are negotiated on the Trade
House with their providers
 The negotiation process involves the servant agents
(buyer and sellers) hosted on the TH
 If successful, the negotiation ends suggesting a point of
balance between the contrasting interests
• Can take into account multiple attributes of the traded good
 A list of contracts is proposed to the user for final
acceptance
 Finally some tickets can be sold on an Auction
House
AT2AI04 – Vienna, April 14th, 2004
15
Event Organizer Final Demonstration
 The demonstration included:
 Nearly 200 agents deployed on servers hosted at 14 different
geographical locations (FIPA HTTP MTP protocol)
 25 different services, configured with real and realistic data
• Each service was implemented independently by partners and run on
their own node
• Interoperation between services should have been achieved through
the FIPA ACL, FIPA-SL and DAML+OIL ontologies
▫ … but a lack on integration and of tools often forced developers to hard
code the agreed interactions
 The demonstration scenario was successful demonstrated
 … but the overall system clearly remained brittle and sensitive to
certain types of changes
 Despite this fragility the demonstration represents a significant
milestone
AT2AI04 – Vienna, April 14th, 2004
16
Conclusion
 FIPA agents proved to be a feasible solution to
achieve the dynamic composition of basic services
 The proposed scenario can be easily adapted to
different domains
 The Event Organizer and the Trade House are domain
and ontology agnostic
• Custom JSP forms are needed to define constraints about new
products
 The SME Access can be upgraded adding more agent
templates
 New ad-hoc service providers can interact directly with
the Trade House
AT2AI04 – Vienna, April 14th, 2004
17
Conclusion
 This kind of large test bed environment
is essential
 To progress theory into practice
 To improve the understanding of the issues connected
to large scale open system
 Activities in the test bed are ongoing with a range
of new projects using the infrastructure to extend
current features
 Integration with emergent technologies
AT2AI04 – Vienna, April 14th, 2004
18