SIT- Institute Secure TelecooperationAgent Group, Dep. of Computing Fraunhofer, Darmstadt, GermanyCity University, London, UK 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-Device Gateway 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 2Bank 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 ACTAS Service Provider Facility Agent (FA) Collecting Traders for Service Offers Ontological Repository Administrators 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 Offers 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) 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 Characteristic for description of Service and Service Mode can be used for pre-selecting of Service Offers –Compatibility Characteristic for 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.

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.

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 1 Flight – OUT New role Payment – IN (Checks with PA If necessary, new request for Draft-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 x Draft-Payment - IN Personal Agent (PA)

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

Possibilities for the Composition Workflow like Connections (directed composition) Service mode A-IN A-OUT A-IN Service mode A-OUT Service mode A-OUT E-OUT Service mode A-IN B-OUT C-OUT D-OUT Service mode D-IN E-IN Service mode C-IN Service mode B-IN combining splitting

Possibilities for the Composition Use 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.