Upload
aspen-rowland
View
32
Download
0
Embed Size (px)
DESCRIPTION
Adaptive, Composite Trading based on Agents ACTAS. Dipl.-Inform. Reinhold Kloos. SIT- Institute Secure TelecooperationAgent Group, Dep. of Computing Fraunhofer, Darmstadt, GermanyCity University, London, [email protected]@soi.city.ac.uk - PowerPoint PPT Presentation
Citation preview
SIT- Institute Secure Telecooperation Agent Group, Dep. of Computing
Fraunhofer, Darmstadt, Germany City University, London, UK
[email protected] [email protected] Supervisors: Dr. Michael Schroeder, City University
Dr. Rolf Reinema, FhG-SIT
Dipl.-Inform. Reinhold Kloos
Adaptive, Composite Trading based on Agents ACTAS
Communication Connection: A Non-directed Composition
User 2
H323-Device
User 1
H320-DeviceGateway
User1 wants to communicate with User2 with a video conference
Booking of a Flight: A Directed Composition
User wants to fly to Lisbon
Travel Agency 1
Travel Agency 2 Bank
Wants to get payment
Challenges for the Trading:
Composition Possibilities?
Current Service Offers?
Schedule of the Services?
User
Adaptive, Composite Trading based on Agent Systems (ACTAS)
• Agent based Trading in five phases– Phase1: Managing the Composition Model– Phase2: Collect Service Offers– Phase3: Composition of requested service– Phase4: Observe constraints, security, resources– Phase5: Schedule of the services
• Includes: transaction management and dynamic reschedule of requests
Principle Agents of ACTASService Provider
Facility Agent
(FA)
Collecting Traders for Service Offers
Ontological RepositoryAdministrators of
the Facility Agents
Trader Agent for Composition
Request Agent Request
Users
Personal Agent
Phase1 - Ontological Repository
Property Types
Characteristics
Service Templates
Property Type
Name, Description of Semantic
Declaration of Features with a
Basic Type or
another Property Type
Constraints for the Features
Methods for the access, comparison of features declared in this Property Type
Property Types
Phase1 - Ontological Repository
Property Types
Characteristics
Service Templates
Characteristic
Name, Description of Semantic
Declaration of Property with a
Property Type
Constraints for the Properties
(Semantic Concept Description)
A characteristic defines the semantic context of properties for describing of requests and service compatibility
Characteristics
Phase1 - Ontological Repository
Property Types
Characteristics
Service Templates
Service Template
Name, Description of Semantic
[List of General Characteristics with constraints for Properties]
...
Mode i
[General Characteristics]
...
Socket j
Characteristic
Service Templates
A service template describes potential service modes (services) of a Facility Agent (FA)
An administrator of a FA describes the Service Template => Advantage of local administration
Phase2 – Service OffersService TemplateName, Description of Semantic
[List of General Characteristics with constraints for Properties]
modes and sockets
Mode i
[General Characteristics]
Socket j
Characteristic
other modes and sockets
Facility Agent
(FA)
Service Offer
Service Template + Interface Information to FA + current constraints for modes and properties
exporting
Characteristics (Re-visited)
• A Characteristic defines a semantic context• Two main kinds of Characteristics exist:
– General Characteristicfor description of Service and Service Modecan be used for pre-selecting of Service Offers
– Compatibility Characteristicfor description of Compatibility between Service Offers (one per Service Socket or User-Request)
• A Request Characteristic is a special Compatibility Characteristic, which can be used in a User-Request
Compatibility• A Service Offer is compatible with another Service Offer
if both Service Offers have a Service Socket, which holds an identical Compatibility Characteristic.
• The used Service Socket determines the Service Mode. All other Service Sockets of this Service Mode must also be connected to compatible Service Offers.
• A Service Socket can contain constraints for the Compatibility.
• In a directed composition the Service Socket has a direction attribute, declaring IN or OUT. A Service Offer with a OUT socket is only compatible to a Service Offer with a IN socket.
RequestA request contains:
– One or more User-Requests:(user name, request characteristic,constraints for the properties of characteristic).
– If necessary, Compatibility Characteristics, which shall be in composition and constraints for their properties.
– If necessary, General Characteristics and constraints for selecting of Service Offers.(Federated traders could help with selection).
– If necessary, already pre-selected Service Offers.
Phase3 - Composition
• Step1: Creation of a Trader Agent responsible for the request.
• Step2: Migrate to a place, where information for composition exist.
• Step3: Create Adaptive Service Offers (ASO) for requesting users/actors.
• Step4: Getting the (next) Service Offers.• Step5: Do composition
(repeat step 4, if necessary).
Phase3 – Non-directed Composition
Communication via a gateway
User 1 Connection
User 2 Connection
Service A
mode 1
Connection
H320-Standard
Service B
mode 1
Connection
H323-Standard
Gateway
mode 1
H323-Standard
H320-Standard
Connection is a Request Characteristic
H320-Standard, H323-Standard are Compatibility Characteristics.
Phase3 – Directed Composition
Booking of a Flight: (User is a Adaptive Service Offer (ASO), which can take over a new
mode/role)
User
mode/role 1Flight – OUT
New rolePayment – IN(Checks with PAIf necessary, new request forDraft-Payment)
Draft-Payment – OUT
ASO
Travel Agency
mode 1
Flight – IN
Payment – OUT(condition: has to be done by Actor of Flight – IN)
Bank
mode xDraft-Payment - IN
Personal Agent
(PA)
Possibilities for the Composition
Multiple Connections with one service (non-directed composition)
Servicemode
AAA
Servicemode
AConnection
Servicemode
AConnection
Servicemode
AConnection
User2mode
Connection
User1mode
Connection User3mode
Connection
Possibilities for the Composition
Workflow like Connections (directed composition)
ServicemodeA-INA-OUTA-IN
Servicemode
A-OUT
Servicemode
A-OUTE-OUT
Servicemode
A-INB-OUTC-OUTD-OUT
Servicemode
D-INE-IN
Servicemode
C-IN
Servicemode
B-IN
combining
splitting
Possibilities for the CompositionUse of Capability Specifications
• Property Types could be specified, which uses specifications for capabilities of agents, which are providing Software Services. (e.g. LARKS (Klusch, Sycara), HyperType (Zapf)).
• A Characteristic could hold a Property of this Property Type and another Property in order to keep necessary ontology information (necessary for LARKS).
• This Characteristic could be used as a General Characteristic of the Service Mode of the Service Offer, describing this special capability of the agent.
• Special Compatibility Characteristics, held by the Service Sockets of such a Service Mode or by a User-Request, could describe the compatibility constraints and allow the composition.
Constraints
• Several kinds and locations of constraints exist:– In the ontological repository:
Property Type, Characteristic, Service Template.
– In the Request (phase 3).– In the collecting federated traders (phase 2).
• During the composition, constraints of a property a in characteristic A will be combined with the constraints of property b in characteristic B, if a service mode, used in the composition, has sockets with these characteristics and has a rule that these properties mean the same.
Phase4 – Checking Constraints
• During the Composition process (phase3) only relevant Service Offers (step4) were selected and used.
• The collected constraints for composition have to be checked in phase4, using methods of the properties.
• Available resources for the service have to be checked and reserved, using the interface methods to the Facility Agent (FA).
Phase4 - Transaction Control for Resource Management
• In order to check the availability of resources for the composite services and in order to reserve these resource, a trader agent must perform a transaction control.
• For every service, which is part of the composite service, the trader has to communicate with the Facility Agent.
• The Facility Agent must be able to reserve resources for one trader agent, distinguishing between the different composite services.
Phase4 – Selection of Composite Service
• Only Composite Services, fulfilling all constraints and having enough resources, can be selected.
• If preferences of users were learnt, then these could be used for selection.
• The request could name Properties, which are relevant for selection. They could be compared with methods defined in their Property Types.
• Composite Services, fulfilling more constraints better than others, could be preferred.
Phase5 – Scheduling of Composite Service
• A Service Offer contains the interface information for its Facility Agent (FA). This information get their information from the Service, Service Mode, and Service Sockets with their Characteristics and Properties.
• A schedule of an Adaptive Service Offer (ASO), which stands for a requesting user, can be a negotiation with the user (e.g. payment). It can lead to a new service request (e.g. draft-payment).
• If necessary, repeat of trading process (phase3).
Learning of Preferences
• The Trader waits for a feedback for learning of user preferences.
• Since ACTAS uses Request Characteristics for a User-Request, Properties defined in a fixed semantic context can be used for learning. This allows e.g. table-learning.
• It is up to the Agent system to give further information of the context of the user.
Security Aspects
• The Personal Agent (PA) should know the location of its user and his/her security rights.
• General Characteristics with Properties holding security information and methods could be defined.
• These Characteristics would allow pre-selecting of Service Offers and checking of constraints.
What Is ACTAS?• ACTAS allows non-directed and directed service composition.
• Flexible ontological contexts with Characteristics
• Simple compatibility operator
• Local definition of compatibility with different Service Modes for Service Templates and Service Offers.
• Adaptable for different trading applications with the use of Service Sockets.
• Using of federated traders for pre-selecting of Service Offers.
• Allows learning of user preferences.
• ACTAS is based on a Agent System
• Having several features and their constraints in a Property Type allows the composition and handling of simultaneous features.