1 / 26

Adaptive, Composite Trading based on Agents ACTAS

Adaptive, Composite Trading based on Agents ACTAS. Dipl.-Inform. Reinhold Kloos. SIT- Institute Secure Telecooperation Agent Group, Dep. of Computing Fraunhofer, Darmstadt, Germany City University, London, UK reinhold.kloos@sit.fraunhofer.de r.kloos@soi.city.ac.uk

aspen-rowland
Télécharger la présentation

Adaptive, Composite Trading based on Agents ACTAS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Adaptive, Composite Trading based on Agents ACTAS Dipl.-Inform. Reinhold Kloos SIT- Institute Secure Telecooperation Agent Group, Dep. of Computing Fraunhofer, Darmstadt, Germany City University, London, UK reinhold.kloos@sit.fraunhofer.de r.kloos@soi.city.ac.uk Supervisors: Dr. Michael Schroeder, City University Dr. Rolf Reinema, FhG-SIT

  2. User 1 User 2 Gateway H320-Device H323-Device Communication Connection: A Non-directed Composition User1 wants to communicate with User2 with a video conference

  3. User Travel Agency 1 Bank Travel Agency 2 Booking of a Flight: A Directed Composition User wants to fly to Lisbon Challenges for the Trading: • Composition Possibilities? • Current Service Offers? • Schedule of the Services? Wants to get payment

  4. 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

  5. Collecting Traders for Service Offers Facility Agent (FA) Administrators of the Facility Agents Trader Agent for Composition Request Agent Personal Agent Request Users Principle Agents of ACTAS Service Provider Ontological Repository

  6. Property Types Characteristics Service Templates Phase1 - Ontological Repository 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

  7. 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 Property Types Characteristics Service Templates Phase1 - Ontological Repository Characteristics

  8. Property Types Characteristics Service Templates Phase1 - Ontological Repository 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

  9. Service Template Name, 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) Phase2 – Service Offers exporting Service Offer Service Template + Interface Information to FA + current constraints for modes and properties

  10. 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

  11. 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.

  12. Request A 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.

  13. 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).

  14. User 1 Connection User 2 Connection Phase3 – Non-directed Composition Communication via a gateway Service A mode 1 Connection H320-Standard Gateway mode 1 H323-Standard H320-Standard Service B mode 1 Connection H323-Standard Connection is a Request Characteristic H320-Standard, H323-Standard are Compatibility Characteristics.

  15. Personal Agent (PA) Phase3 – Directed Composition Booking of a Flight: (User is a Adaptive Service Offer (ASO), which can take over a new mode/role) Travel Agency mode 1 Flight – IN Payment – OUT(condition: has to be done by Actor of Flight – IN) Bank mode x Draft-Payment - IN User mode/role 1 Flight – OUT New role Payment – IN(Checks with PAIf necessary, new request forDraft-Payment) Draft-Payment – OUT ASO

  16. User3 mode Connection User2 mode Connection User1 mode Connection Possibilities for the Composition Multiple Connections with one service (non-directed composition) Service mode AConnection Service mode AAA Service mode AConnection Service mode AConnection

  17. Possibilities for the Composition Workflow like Connections (directed composition) Service mode B-IN Service mode A-OUT Service modeA-INA-OUTA-IN Service mode A-INB-OUTC-OUTD-OUT Service mode C-IN combining Service mode A-OUTE-OUT splitting Service mode D-INE-IN

  18. 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.

  19. 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.

  20. 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).

  21. 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.

  22. 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.

  23. 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).

  24. 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.

  25. 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.

  26. 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.

More Related