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

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.