Adaptive, Composite Trading
based on Agents ACTAS
Dipl.-Inform. Reinhold Kloos
SIT- Institute Secure Telecooperation
Fraunhofer, Darmstadt, Germany
Agent Group, Dep. of Computing
City University, London, UK
[email protected]
[email protected]
Supervisors:
Dr. Michael Schroeder, City University
Dr. Rolf Reinema, FhG-SIT
Communication Connection:
A Non-directed Composition
User 1
User 2
Gateway
H320-Device
H323-Device
User1 wants to communicate with User2 with a video conference
Booking of a Flight:
A Directed Composition
User wants to fly to Lisbon
User
Travel Agency 1
Challenges for the Trading:
Bank
 Composition Possibilities?
 Current Service Offers?
 Schedule of the Services?
Travel Agency 2
Wants to get payment
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
Collecting
Traders for
Service Offers
(FA)
Administrators of
the Facility Agents
Ontological
Repository
Personal
Agent
Users
Request
Request
Agent
Trader Agent for
Composition
Phase1 - Ontological Repository
Property Type
Property Types
Characteristics
Service Templates
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
Phase1 - Ontological Repository
Characteristic
Property Types
Characteristics
Service Templates
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
Phase1 - Ontological Repository
Service Template
Name, Description of Semantic
Property Types
Characteristics
Service Templates
[List of General Characteristics
with constraints for Properties]
...
Mode i
[General Characteristics]
A service
template
An
administrator
of a FA
describesthe
potential
describes
Service
service modes
(services)
Template
=> Advantage
a Facility
Agent (FA)
ofoflocal
administration
...
Socket j
Characteristic
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)
exporting
Service Offer
Service Template + Interface
Information to FA + current
constraints for modes and
properties
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
Service A
Gateway
Service B
mode 1
mode 1
mode 1
Connection
H323-Standard
Connection
H320-Standard
H320-Standard
H323-Standard
Connection is a Request Characteristic
H320-Standard, H323-Standard are Compatibility
Characteristics.
User 2
Connection
Phase3 –
Directed Composition
Booking of a Flight:
(User is a Adaptive Service Offer (ASO), which can take over a new
mode/role)
Travel Agency
User
Personal
Agent
(PA)
mode 1
mode/role 1
Flight – OUT
Flight – IN
New role
Payment – IN
(Checks with PA
If necessary,
new request for
Draft-Payment)
Payment – OUT
(condition: has to
be done by Actor
of Flight – IN)
Draft-Payment –
OUT
Bank
mode x
Draft-Payment - IN
Possibilities for the Composition
Multiple Connections with one service
(non-directed composition)
User1
Service
mode
mode
Connection
A
Connection
User2
Service
mode
mode
Connection
A
Connection
Service
mode
A
A
A
Service
mode
A
Connection
User3
mode
Connection
Possibilities for the Composition
Workflow like Connections
(directed composition)
Service
Service
mode
A-OUT
Service
mode
A-OUT
E-OUT
Service
mode
A-IN
A-OUT
A-IN
combining
mode
Service
B-IN
mode
A-IN
B-OUT
C-OUT
D-OUT
Service
mode
C-IN
splitting
Service
mode
D-IN
E-IN
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 preselecting 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.