Transcript E-Services and Transactions in Semantic Web Vagan Terziyan MIT Department, University of Jyvaskyla / / AI Department, Kharkov National University of Radioelectronics [email protected] http://www.cs.jyu.fi/ai/vagan +358 14 260-4618

E-Services and Transactions in
Semantic Web
Vagan Terziyan
MIT Department, University of Jyvaskyla /
/ AI Department, Kharkov National University of Radioelectronics
[email protected]
http://www.cs.jyu.fi/ai/vagan
+358 14 260-4618
Managing Transactions with Distributed Web-Services
and providing Integrated Service to a User - are among
the basic abilities of an Intelligent Agent
Contents
 Transactions with Mobile services in
Semantic Web
 Agent-Based Service Integration
Transaction with Mobile Services
in Semantic Web
Vagan Terziyan
University of Jyvaskyla, Finland
e-mail: [email protected]
Transactions in Databases
 A transaction is a sequence of database
actions which must either all be done, or
none of them must be done
 Another view of a transaction is that it is an
action, or sequence of actions, that takes the
database from one consistent state to
another
M-commerce transaction:
M-commerce transaction:
Any type of transaction of an economic value
having at least at one end a mobile terminal and
thus using the telecommunications network for
communication with the e-commerce infrastructure
Mobile e-commerce
e-commerce
based on m-commerce transactions
=
Basic (ACID) Transactional
Properties
Atomicity
Consistency
Isolation
Durability
Atomicity
 Transaction is atomic if either all operations necessary for
preserving e-commerce atomicity are executed or all
executed operations will become compensated.
 With money atomic protocols, funds are transferred from
one party to another without the possibility of the money
remaining in the middle.
 Goods-atomic protocols are such that a good is received if
and only if the money is transferred.
 Certified delivery protocols allow both a merchant and a
customer to prove exactly which goods were delivered.
Consistency
Transactions must preserve consistency at
various levels. For instance, a customer should
not be allowed to draw funds from an account if
this would result into a negative balance.
Isolation
Isolation means that various steps of a transaction
do not interfere with steps of other transactions.
Durability
Durability means that once a transaction completes
its execution, its results become permanent even in
the presence of failures.
Committed by a transaction data is saved by the
system such that, even in the event of a failure and
system restart, the data is available in its correct
state.
Server-Side Transaction Monitor
Web
resource /
service
Server
Client
wireless
TM
Transaction Service
Web
resource /
service
Server
Server-Side Transaction Monitor
Positive (1) Less wireless (sub)transactions
Web
resource /
service
Server
Client
wireless
!
TM
Transaction Service
Web
resource /
service
Server
Server-Side Transaction Monitor
Positive (2) Rich ontological support
Web
resource /
service
Server
Rich ontology
of resources,
services,
other metadata
TM
Transaction Service
Client
wireless
Web
resource /
service
Server
Server-Side Transaction Monitor
Positive (3) Smaller crash, disconnection vulnerability
Web
resource /
service
Server
TM
Transaction Service
OK
!
Client
wireless
Web
resource /
service
Server
Server-Side Transaction Monitor
Negative (1) Pure customer’s trust
Web
resource /
service
Server
Customer’s
private data
TM
Transaction Service
Client
wireless
Web
resource /
service
Server
Server-Side Transaction Monitor
Negative (2) Lack of customer’s awareness and control
Web
resource /
service
Server
Transaction
online control
Client
Transaction
data
TM
Transaction Service
wireless
Web
resource /
service
Server
Server-Side Transaction Monitor
Negative (3) Problematic TM’s adaptation to the customer
Web
resource /
service
Server
Client
Public TM
TM
Transaction Service
wireless
Web
resource /
service
Server
Example: Server-based transactions for
location based application
4
Application Server
6
5
Positioning
Service
3
10
Client
1
12
9
2
11
7
8
Content providers
Client-Side Transaction Monitor
Web
resource /
service
TM
wireless
Client
Server
wireless
Web
resource /
service
Server
Client-Side Transaction Monitor.
Positive (1) Customer’s firm trust
TM
Web
resource /
service
wireless
Client
Server
wireless
Web
resource /
service
Server
Customer’s
private data
Client-Side Transaction Monitor.
Positive (2) Customer’s awareness and involvement
TM
Web
resource /
service
wireless
Client
Server
wireless
Web
resource /
service
Server
Transaction
online control
Transaction
data
Client-Side Transaction Monitor.
Positive (3) Better TM’s adaptation to the customer
TM
Web
resource /
service
wireless
Client
Server
wireless
Web
resource /
service
Server
Personal TM
Client-Side Transaction Monitor.
Negative (1) More wireless (sub)transactions
TM
Web
resource /
service
wireless
Client
Server
wireless
!
Web
resource /
service
Server
Client-Side Transaction Monitor.
Negative (2) Restricted ontological support
TM
Web
resource /
service
wireless
Client
Server
wireless
Web
resource /
service
Server
Restricted
ontology of
resources, services,
other metadata
Client-Side Transaction Monitor.
Negative (3) High crash, disconnection vulnerability
TM
Web
resource /
service
wireless
Client
Server
wireless
Web
resource /
service
Server
Terminology
 e-Service = Web-Service, which assumes
also an online payment;
 e-Service is a Web-Service in e- Commerce
Ontology-Based Client-Side
Transaction Monitor
 This design is based on assumption that TM
is an independent mobile terminal
application, which can integrate different
distributed external e-services by managing
appropriate transactional processes. For that
the ontology-based framework for
transaction management is used so that the
Transaction Monitor will be able to manage
transaction across multiple e-services.
Client 1
Transaction data
Client r
Services data
Services data
Parameter 1 Recent value
Service 1 ********
Parameter 1 Recent value
Service 1 ********
Parameter 2 Recent value
Service 2 ********
Parameter 2 Recent value
Service 2 ********
…
…
…
Parameter n Recent value
…
Service s ********
Transaction monitor
The conceptual
scheme of the
ontology-based
transaction
management
Transaction data
…
…
Parameter n Recent value
…
Service s ********
Transaction monitor
Ontologies
Service atomic action ontologies
Parameter ontologies
Parameter 1
Name 1
Default value / schema 1
Parameter 2
Name 2
Default value / schema 2
…
…
…
Parameter n
Name n
Default value / schema n
input parameters
input parameters
Name of action 1
Name of action 2
Name of action k
…
output parameters
Service 1
output parameters
output parameters
Service s
Subtransaction monitor
Service Tree
input parameters
Subtransaction monitor
Clients data
Service Tree
Clients data
Client 1 ********
Client 1 ********
Client 2 ********
Client 2 ********
…
Client r ********
…
…
Client r ********
Basic definitions: Action
Let an action be a single client-server query-response
session between the mobile terminal (hereinafter - terminal)
and the e-service provider (hereinafter - service), which has
following structure:
- action’s ID;
- Ids of p input parameters for the action, specified at the terminal
to create a query;
- Ids of q output parameters of the action, which the terminal
receives as the result to its query.
Basic definitions: Subtransaction
Subtransaction is a vector of one or more actions between a
terminal and the service and appropriate states managed by
the service with definitely stated final goal and common
memory of parameters.
Basic definitions: Transaction
Transaction is a vector of one or more subtransactions with
the same terminal and possibly different services managed
by the terminal, with definitely stated final goal and common
memory of parameters.
.
S1
S0
LOGIN (begin subtransaction)
Service Tree
A1
Service tree is a tree-like
structure of the set of
subtransactions, which a service
can offer to his clients and which
is used by a service to manage
subtransactions with clients.
Action of interest, toned for
every subtransaction in the
service tree is such an action,
which outcome is in particular
interest of a customer and has
an economic value.
A2
A4
S3
S6
A3
A6
A5
S8
S2
S4
S7
A4
A6
A6
S9
A7
S5
S11
S10
S0
LOGOUT (end subtransaction)
Service tree as a collection of subtransactions offered by the
Service to its customers. In the rectangles together with the Id
of an action there is also Id of a state, into which a
subtransaction is coming after performing this action
Constants and Ontologies
 basic constants, which define Ids of the terminal and services
used, basic screens for the interface, total numbers of services,
actions and parameters, which Transaction Monitor is
operating with;
 service atomic actions ontologies define basic actions with
their input and output, from which every service can be
composed, and which are used as a common procedural
language between a client and a service (include always
LOGIN and LOGOUT actions ontologies);
 parameter ontologies describe parameters, which can be used
in actions, by providing their Ids, default values and types (or
schemas), and which are actually a common declarative
language between a client and a service.
Basic constants
ID of the Constant
Cardinality
TERMINAL_ID
1
TOTAL_NUMBER_OF_SERVICES
1
TOTAL_NUMBER_OF_ACTIONS
1
TOTAL_NUMBER_OF_PARAMETERS
1
SERVICE_ID
TOTAL_NUMBER_OF_SERVICES
SCREEN_FRAME
16
Ontologies
ID of the Ontology
Cardinality
Service atomic action ontologies:
ACTION_ID
TOTAL_NUMBER_OF_ACTIONS
INPUT_PARAMETERS_FOR_ACTION
TOTAL_NUMBER_OF_ACTIONS×
TOTAL_NUMBER_OF_PARAMETERS
OUTPUT_PARAMETERS_FROM_ACTION
TOTAL_NUMBER_OF_ACTIONS×
TOTAL_NUMBER_OF_PARAMETERS
Parameter ontologies:
PARAMETER_ID
TOTAL_NUMBER_OF_PARAMETERS
PARAMETER_DEFAULT_VALUE
TOTAL_NUMBER_OF_PARAMETERS
PARAMETER_TYPE/SCHEMA
TOTAL_NUMBER_OF_PARAMETERS
Variables
 control variables have sense only for a Transaction
Monitor and are used to manage different states of the
terminal during going-on transactions, subtransactions and
actions;
 working variables are used to manage parameters' states
and provide common memory for different
subtransactions, which can be run with different services;
 billing variables are used to manage billing data in the
Transaction Monitor. The terminal will collect bills
separately for every service adding online price for
appropriate service actions to it, when it is requested.
Service Actions
service query
TERMINAL_ID
Terminal
CURRENT_STATE_OF_SUBTRANSACTION
PARAMETER_ID1 /PARAMETER_RECENT_VALUE1/
…
SERVICE_ID
…
ACTIVE_ACTION ID
Terminal
response
Service
PARAMETER_ID1 /PARAMETER_RECENT_VALUE1/
PARAMETER_IDq /PARAMETER_RECENT_VALUEq/
PRICE_FOR_LAST_ACTION
OUTPUT_PARAMETERS_FROM_ACTION
CURRENT_STATE_OF_SUBTRANSACTION
LIST_OF_AVAILABLE_ACTIONS
…
Service
ACTIVE_ACTION_ID
PARAMETER_IDp /PARAMETER_RECENT_VALUEp/
INPUT_PARAMETERS_FOR_ACTION
service response
query
An Example of Action
"Client 0501234567 …
…of active subtransaction…
0501234567
S0
LOGIN
… being in S0 state …
"Server MMM-2001 reports …
MMM-2001
For that the client entered his login…
login /vagan/
password /1234/
… has made LOGIN query to server.
…your LOGIN action…
LOGIN
…that during active subtransaction …
Now you come to state S1 ,…
LOGIN_REPLY /OK/
…was OK !
…and password."
S1
A1
…after which the only action you may choose is A1."
An Example of Action
"Client 0501234567 …
0501234567
S1
… during active subtransaction…
"Server MMM-2001 reports …
MMM-2001
A1
For that the client entered
requested input parameters.
…and being in S1 state of it…
A1
Input parameters for action A1
… has made A1 action (query) to server.
…your action (query) A1
has been processed and…
Output parameters from action A1
…that during active subtransaction…
Now you come
to state S2 ,…
Price for outcomes is $1 .
$1
…following outcomes are obtained.
S2
A2,
A3,
A4
…after which the actions you
may choose are A2, A3 and A4."
LBS example: ontology for the
LOCATE_BY_ID action
INPUT_PARAMETERS_
FOR_ACTION
Terminal ID
ACTION_ID
OUTPUT_PARAMETERS
_FROM_ACTION
Latitude
Locate by ID
Longitude
Altitude
LBS example: ontology for the
LOCATE_BY_ADDRESS action
INPUT_PARAMETERS
_FOR_ACTION
Street_Number
Street_Name
City_Name
State/Province_Name
Country_Name
ACTION_ID
OUTPUT_
PARAMETERS_
FROM_ACTION
Locate by address
Latitude
Longitude
LBS example: ontology for the
GET_MAP action
Latitude
Longitude
INPUT_
PARAMETERS_
FOR_ACTION
ACTION_ID
OUTPUT_
PARAMETERS_
FROM_ACTION
Get map
Map
LBS example: ontology for the
GET_INFO action
point_of_interest
OUTPUT_
PARAMETERS
_FROM_ACTION
Get Info
ACTION_ID
OUTPUT_
PARAMETERS
_FROM_ACTION
point_address
point_phone
point_info
LBS example: service tree for the
Positioning Service
S0
Locate by ID
LOGIN
S1
S1
Locate by Address
LOGOUT
S0
S1
LBS example: service tree for the
Location Based Service
S0
LOGIN
S2
Get map
Get info
LOGOUT
S1
S2
S0
LBS example: Case when a user locates
himself and submits coordinates to LBS
LocationBased Service
Terminal
Login (user_ID, password)
Login (Login - OK)
Locate by address (address)
Locate by address (Coordinates)
Logout (user_ID)
Logout (Logout - OK)
Login (user_ID, password)
Login (Login - OK)
Get map (coordinates)
Get map (map)
Get info (point of interest)
Get info (point information)
Logout (user_ID)
Logout (Logout - OK)
Positioning
Service
<Query
Query_ID="01-03-2002_12:33:57"
Type="Service"
To_Service="Positioning_Service"
From_Terminal="0501234567"
Terminal_State="S0"
>
<Action ID="LOGIN"/>
<Input_Parameters>
<Parameter ID="user_ID” Type="text” Value="vagan"/>
<Parameter ID="password” Type="text” Value="4321"/>
</Input_Parameters>
</Query>
“Login” Query
Terminal
Positioning Service
<Response
Response_ID="01-03-2002_12:34:42” Type="Service” To_Query="01-03-2002_12:33:57”
To_Terminal="0501234567” From_Service="Positioning_Service” Terminal_State="S1"
>
<Action ID="LOGIN"/>
<Output_Parameters>
<Parameter
ID="login_reply” Type="binary” Value="OK"/>
</Output_Parameters>
<Price_for_Action
Currency="EURO" Value="0.0"/>
<Bill_Recent_Value
Currency="EURO" Value="0.0"/>
<Actions_Allowed>
<Action ID="LOGOUT"/>
<Action ID="LOCATE_BY_ID"/>
<Action ID="LOCATE_BY_ADDRESS"/>
</Actions_Allowed >
</Response>
“Login” Response
Terminal
Positioning Service
<Query
Query_ID="01-03-2002_12:34:53"
Type="Service"
To_Service="Positioning_Service"
From_Terminal="0501234567"
Terminal_State="S1"
>
<Action ID="LOCATE_BY_ADDRESS"/>
<Input_Parameters>
<Parameter ID="street_number” Type="integer”
<Parameter ID="street_name”
Type="text”
<Parameter ID="city_name"
Type="text”
<Parameter ID="country_name” Type="text”
</Input_Parameters>
</Query>
Value="43"/>
Value="Nokatu"/>
Value="Jyvaskyla"/>
Value="Finland"/>
“Locate by Address” Query
Terminal
Positioning Service
<Response
Response_ID= "01-03-2002_12:35:14” Type= "Service"
To_Query=
"01-03-2002_12:34:53” To_Terminal=
"0501234567"
From_Service= "Positioning_Service”
Terminal_State=
"S1"
>
<Action ID="LOCATE_BY_ADDRESS"/>
<Output_Parameters>
<Parameter ID="latitude"
Type="integer"
Value="54321"/>
<Parameter ID="longitude" Type="integer"
Value="98765"/>
</Output_Parameters>
<Price_for_ActionCurrency="EURO" Value="0.23"/>
<Bill_Recent_Value
Currency="EURO" Value="0.23"/>
<Actions_Allowed>
<Action ID="LOGOUT"/>
<Action ID="LOCATE_BY_ID"/>
<Action ID="LOCATE_BY_ADDRESS"/>
</Actions_Allowed >
</Response>
“Locate by Address” Response
Terminal
Positioning Service
<Query
Query_ID="01-03-2002_12:35:20"
Type="Service"
To_Service="Positioning_Service"
From_Terminal="0501234567"
Terminal_State="S1"
>
<Action ID="LOGOUT"/>
<Input_Parameters>
<Parameter ID="user_ID” Type="text” Value="vagan"/>
</Input_Parameters>
</Query>
“Logout” Query
Terminal
Positioning Service
<Response
Response_ID= "01-03-2002_12:35:25” Type=
"Service"
To_Query=
"01-03-2002_12:35:20” To_Terminal= "0501234567"
From_Service= "Positioning_Service” Terminal_State= "S0"
>
<Action ID="LOGOUT"/>
<Output_Parameters>
<Parameter ID="logout_reply” Type="binary” Value="OK"/>
</Output_Parameters>
<Price_for_Action
Currency="EURO"
Value="0.0"/>
<Bill_Recent_Value
Currency="EURO"
Value="0.23"/>
<Actions_Allowed>
<Action ID="LOGIN"/>
</Actions_Allowed >
</Response>
“Logout” Response
Terminal
Positioning Service
<Query
Query_ID="01-03-2002_12:35:47"
Type="Service"
To_Service="Location_Based_Service"
From_Terminal="0501234567"
Terminal_State="S0"
>
<Action ID="LOGIN"/>
<Input_Parameters>
<Parameter ID="user_ID” Type="text” Value="vagan"/>
<Parameter ID="password” Type="text" Value="1234"/>
</Input_Parameters>
</Query>
“Login” Query
Terminal
Location-Based Service
<Response
Response_ID= "01-03-2002_12:36:01”
Type=
To_Query=
"01-03-2002_12:35:47”
To_Terminal=
From_Service="Location_Based_Service” Terminal_State=
>
<Action ID="LOGIN"/>
<Output_Parameters>
<Parameter ID="login_reply” Type="binary"
</Output_Parameters>
"Service"
"0501234567"
"S1"
Value="OK"/>
<Price_for_Action
Currency="USD" Value="0.0"/>
<Bill_Recent_Value Currency="USD" Value="0.0"/>
<Actions_Allowed>
<Action ID="LOGOUT"/>
<Action ID="GET_MAP"/>
</Actions_Allowed >
</Response>
“Login” Response
Terminal
Location-Based Service
<Query
Query_ID="01-03-2002_12:39:07"
Type="Service"
To_Service="Location_Based_Service"
From_Terminal="0501234567"
Terminal_State="S1"
>
<Action ID="GET_MAP"/>
<Input_Parameters>
<Parameter ID= "latitude” Type= "integer” Value="54321"/>
<Parameter ID= "longitude” Type= "integer” Value="98765"/>
</Input_Parameters>
</Query>
“Get Map” Query
Terminal
Location-Based Service
<Response
Response_ID= "01-03-2002_12:41:34”
Type=
"Service"
To_Query=
"01-03-2002_12:39:07”
To_Terminal= "0501234567"
From_Service=
"Location_Based_Service” Terminal_State= "S2"
>
<Action ID="GET_MAP"/>
<Output_Parameters>
<Parameter
ID= "map”
Type= "GML”
Value= "GML Data"/>
</Output_Parameters>
<Price_for_Action
Currency="USD" Value="0.15"/>
<Bill_Recent_Value Currency="USD" Value="0.15"/>
<Actions_Allowed>
<Action ID="LOGOUT"/>
<Action ID="GET_MAP"/>
<Action ID="GET_INFO"/>
</Actions_Allowed >
</Response>
“Get Map” Response
Terminal
Location-Based Service
<Query
Query_ID="01-03-2002_12:50:12"
Type="Service"
To_Service="Location_Based_Service"
From_Terminal="0501234567"
Terminal_State="S2"
>
<Action ID="GET_INFO"/>
<Input_Parameters>
<Parameter ID= "point_of_interest” Type="text” Value="Alba_Hotel"/>
</Input_Parameters>
</Query>
“Get Info” Query
Terminal
Location-Based Service
<Response
Response_ID= "01-03-2002_12:51:04” Type= "Service” To_Query= "01-03-2002_12:50:12"
To_Terminal= "0501234567” From_Service= "Location_Based_Service” Terminal_State= "S2 "
>
<Action ID="GET_INFO"/>
<Output_Parameters>
<Parameter ID="point_address"
<Parameter ID="point_phone"
<Parameter ID="point_info”
Type="text"
Value="Mattilaniemi A1"/>
Type="text"
Value="0509876543"/>
Type="text”
Value="Rooms available:
single (60 EURO), double (80 EURO)"/>
</Output_Parameters>
<Price_for_Action
Currency="USD" Value="0.10"/>
<Bill_Recent_Value
Currency="USD" Value="0.25"/>
<Actions_Allowed>
<Action ID="LOGOUT"/>
<Action ID="GET_MAP"/>
<Action ID="GET_INFO"/>
</Actions_Allowed >
</Response>
“Get Info” Response
Terminal
Location-Based Service
<Query
Query_ID="01-03-2002_12:58:03"
Type="Service"
To_Service="Location-Based_Service"
From_Terminal="0501234567"
Terminal_State="S2"
>
<Action ID="LOGOUT"/>
<Input_Parameters>
<Parameter ID="user_ID” Type="text” Value="vagan"/>
</Input_Parameters>
</Query>
“Logout” Query
Terminal
Location-Based Service
<Response
Response_ID= "01-03-2002_12:58:55”
Type=
"Service"
To_Query=
"01-03-2002_12:35:20”
To_Terminal=
"0501234567"
From_Service= "Location_Based_Service” Terminal_State= "S0"
>
<Action ID="LOGOUT"/>
<Output_Parameters>
<Parameter
ID="logout_reply" Type="binary"
Value="OK"/>
</Output_Parameters>
<Price_for_Action
Currency= ”USD”
<Bill_Recent_Value
Currency= ”USD”
<Actions_Allowed>
<Action ID="LOGIN"/>
</Actions_Allowed >
</Response>
Value=
Value=
"0.0"/>
"0.25"/>
“Logout” Response
Terminal
Location-Based Service
Atomicity consideration
 Money atomicity: Money is either entirely
transfer or not transfer at all;
 Goods atomicity: Customer receives the
ordered goods if and only if merchant is
paid;
 Distributed Purchase Atomicity: Products
bought from different suppliers are either
both delivered or none.
Distributed independent purchase case
Assume a customer wants to purchase specialised software (SW) from a
merchant. In order run this software, he also needs an operating system (OS),
which is, however, only available from a different merchant. As both goods
individually are of no value for the customer, he needs the guarantee to perform
the purchase transaction with the two different merchants atomically in order to
get either both products or none.
Service 1
Customer
SW
Distributed
independent purchase
OS
Service 2
Distributed sequential purchase case
Assume that a customer needs a Map from Service 2 but to apply for that map he is
requested to provide his coordinates (CR). Coordinates he can get from Service 1.
Assume that Service 1 does not care about how a customer is going to use
coordinates delivered - the service has made job and got money for it. Even if the
rest of a transaction will fail and for some reason a customer will not get his Map
from Service 2, full compensation for the transaction as whole cannot be guaranteed.
Service 1
Customer
Map
Distributed sequential
purchase
CR
Service 2
Reference
Terziyan V., Ontological Modelling of E-Services to Ensure Appropriate
Mobile Transactions, In: International Journal of Intelligent Systems in
Accounting, Finance and Management, J. Wiley & Sons, Vol. 11, No.3,
2002, pp. 159-172.
Available in:
http://www.ingenta.com/isis/searching/Expand/ingenta?pub=infobike://jws/isaf/2002/00000011/00000003/art00221
Acknowledgements
Information Technology
Research Institute
(University of Jyvaskyla):
Agora Center
Customer-oriented research and
development in Information
Technology
Innovations in Business,
Communication and Technology
Research Project (InBCT)
http://www.titu.jyu.fi/eindex.html
http://www.jyu.fi/agora/
Multimeetmobile (MMM) Project
(2000-2001):
Location-Based Service System and
Transaction Management in Mobile
Electronic Commerce
http://www.cs.jyu.fi/~mmm
(University of Jyvaskyla):
Agent-Based Service
Composition
Vadim Ermolayev, Natalya Keberle, Sergey Plaksin
Zaporozhye State Univ., Ukraine
Int. Conference on Web Services Europe (ICWS-Europe’03), Erfurt, Germany, Sept. 23-25, 2003
Semantic Web Services’ Orchestration:
the field is becoming increasingly hot


Several ongoing initiatives define compositional
notations for web services
E.g.:


IBM, Microsoft and BEA have released BPEL4WS as the
specification for coordinating business processes over the
Web
Such notations express the flow of control
and data across a collection of web services
whose choreography performs a workflow
…Having a Recipe
doesn’t yet Grant Having a Meal…

A pro-active component is required

Pro-active understanding of the process
specification is:



Not only the ability to ensure the right sequence
and the proper combination of the components
But also the capability to find the best provider
in the dynamic and open environment
This is why much attention is paid to the field
of agent-enabled web service composition
What should be offered is:

A new understanding of a web service as:


An agent capability implemented as a self-contained proactive software component and the subject of negotiation
and trade
It implies the appearance of the rational service
providing agent , which demands the negotiable
incentive and behaves to increase its utility

E.g.: if a service requested from a travel agency is
‘BookRoundtrip(‘Kiev’, ‘Erfurt’, 22/09/03, 25/09/03, …)’,
the price paid by the requestor will comprise:
 the prices of consumable resources (air fare, hotel room, …)
 plus the incentive paid to the contracted service provider
for ‘BookRoundtrip’ service usage
What’s behind the scenes …

The agent performing ‘BookRoundtrip’ service
should be able to realize
that the requested task is composite
and will require RATIONAL cooperation
with at least:



Air Companies’ service providing agents
And hotel booking service providing agents
These actors will also intend to increase their
own utilities by requesting fees for their service
provision
‘BookRoundtrip’ Scenario
Agent roles (played by human actors):






AUTHOR (A) – acts on behalf of the one of the paper
authors attending ICWS’03-Europe , requests
‘BookRoundtrip’ service
TRAVEL AGENT (T) –provides ‘BookRoundtrip’ service,
generates and conducts corresponding task execution
behind the scenes
FARE AGENT (F) – provides air fare information
and booking services
ICWS INFO (I) – provides information services
on ICWS’03-Europe: local arrangements, infrastructure,
accommodation, etc
HOTEL AGENT (H) – provides hotel room reservation
services
BUSINESS PARTNER (P) – acts on behalf of A’s business
partner in Austria with whom A intends to meet in Germany
in time of the conference to discuss a joint proposal
‘BookRoundtrip’ Exercise Inputs

Semi-formally (enough for human actors
to understand unambiguously):
A
Starting_Point= “Kiev, Ukraine”
Destination=“Erfurt, Germany”
Beg_Date=22/09/2003
End_Date=25/09/2003
Event=“ICWS’03-Europe”
Preferences=(“low fare”, “non-stop flights”, “fast connections”, “4-star hotel”,
“continental breakfast”, “conference discounts”)
Constraints=(Budget = €1500, Payment=(VISA, USD),
Hotel >= 3-star, Room-per-night <= €110, Hotel_Location=”in Max 20 min walk
from the Conference venue”)
Special_Arrangements=((Event=“business dinner”,
Agent=(“Prof. Heinrich C. Mayr”, http://www.ifi.uniklu.ac.at/IWAS/HM/Staff/Heinrich.Mayr/),
Date=(23/09/2003, 24/09/2003),
Location=(Erfurt, Munich)),…)
What are the parties supposed to
do?

Negotiates with T-s about
which A believes that they
are:





Capable to provide
‘BookRoundtrip’
Reliable partners
Collects proposals from T-s
and selects the best of them
Hires the T which has given
the best proposal
Pays and gets the results
A



Analyses if A’s inputs allow
to accept the job
Prepares the proposal based
on its previous experience
IF hired:

Conducts the performance
of ‘BookRoundtrip’ according to:




Its knowledge about the job
Its beliefs about the other service
providers which might be involved
Provides the best result possible
to prove that it is reliable
But does it rationally for not
to loose its income
T
And why do they do it?
A desires:



Not to go behind the scenes
To rely on the T-s
competencies
To pay a reasonable
incentive for that
A believes:


‘BookRoundtrip’ is an
atomic activity – just
a piece of cake
‘BookRoundtrip’ may be
outsourced to T
T desires:



To be hired and paid
for the job
To spend the money most
efficiently (remain
competitive)
To remain a reliable
partner for A
T believes:

‘BookRoundtrip’
is a complex, dynamic,
composite task
T: ‘BookRoundtrip’ is a Complex Task

The knowledgebase of T
contains facts:




BookRoundtrip is a Task
Book
Roundtrip
It contains at least PlanTrip
Task and MakeHotelRes,
ApplyForVisa, SpecArrangements
Activities as its phases
MakeHotelRes requires PlanTrip
results as the PreCondition
SpecArrangements and
ApplyForVisa may be
performed concurrently
with PlanTrip and
Spec
MakeHotelRes
Arrangements
These facts are formulated
in the terms of the Task
Ontology (namespace
for the compositional notation)
Part_of

Task
Activity
Make
HotelRes
PlanTrip
ApplyForVisa
Part_of here
is a Phase-Activity
kind of meronimy
relationship
PlanTrip
Results
Approved
!!! Another T may have a different idea of ‘BookRoundTrip’ composition
PreCondition
T: ‘BookRoundtrip’ – More Facts

The knowledgebase of T
contains facts:



HasPLP
Activity
PlanTrip
Partial
Local
Plan
PlanTrip
PLP
DefineCapability

Tasks and Activities have
Partial Local Plans (PLP)
PLPs among other facts
define the Capability
to perform an Activity
either by itself or by
outsourcing it to another
agent
According to PlanTripPLP
T is capable to perform
PlanTrip by itself
According to MakeHotelResPLP
T needs to outsource
MakeHotelRes to another
agent (via Contract Net
negotiation)
Task
Make
HotelRes
Make
HotelRes
PLP
SelfPerformance
Capability
!!! Another T may have different
Capabilities and PLPs wrt ‘BookRoundTrip’phases
Outsource
T: behaves pro-actively
– Adjusts Inputs

An intelligent service provider may
propose to pro-actively change
the Task Inputs in order to get
better overall result




PlanTrip
DaysOf
AWeek
E.g., for PlanTrip the following
alternative dates:


Date
Beg_Date=20.09, End_Date=25.09
Or
Beg_Date=22.09, End_Date=28.09
End_Date
Is<=
May significantly lower the cost
of the air fare because of the
Sunday Rule Discounts
Beg_Date
Assertions on Task Inputs will
form, e.g., the initial proposal for
EndDOW
AirFare negotiation
BegDOW
T should undertake it to outsource
InquireFares Activity while
SundayRuleDates (Beg_Date, End_Date):
performing PlanTrip Task
(End_Date-Beg_Date>6) Or (BegDOW>EndDOW)
T-F-s: Negotiation on Air Fares





Some F-s are capable to
perform InquireFares
Some of them are trusted
partners
Erfurt
700
450
20.09
-25.09
22.09
-25.09
22.09
-28.09
2500
T starts Contract Net
negotiation by declaring
Activity Inputs and the Intended Price 1600
F-s invoke Web Services they 700
wrap and respond with …
450
These responses are not
satisfactory for T …
20.09
22.09
-25.09
22.09
-28.09
-25.09
Not available

T knows from his
knowledgebase that InquireFares
should be outsourced
T knows from his previous
experience that:
Not available

T: yet one more Adjustment




T has got
unsatisfactory
responses from F-s
T pro-actively tries to
alter the destination
point to the one
close to Erfurt …
Negotiations on
Frankfurt and Munich
fares result in:
Frankfurt is chosen
as the destination point
German
City
700
650
Munich
Frankfurt
Munich
Frankfurt
900
Erfurt
Region
IntAirPort
$1014=€892 1600 $984=€865
€671
€609
500
$513=€609
22.09
20.09
22.09
-28.09
-25.09
-25.09
700
650
€681
$1574=€1385
€751
€602
500
20.09
-25.09
22.09
-25.09
22.09
-28.09
T: Additional Activity is Required



…But Frankfurt is not Erfurt
So, T needs to explore
Frankfurt’s Properties
for Connections
Luckily, there is an
appropriate fact in T-s
knowledgebase:




German
City
Erfurt
Region
IntAirPort
Frankfurt HasRWConn to Erfurt
This leads T to incorporate
one more Activity to PlanTrip
Task: BookRWFare …
Further on, Die Bahn Web
Service provides the result
The mechanism seems to be
the same as for InquireFares
Munich
Frankfurt
Bingo!
Erfurt
‘BookRoundtrip’
Service Composition
F
Negotiate
A
T
T
Negotiate
BookRoundTrip
Service Providers
Middle
Layer
T
Precond: MakeHotelRes
InquireEventInfo
PlanTrip
ApplyConstraints
results are
ApplyPreferences
available
AdjustPreferences
AdjustConstraints
BookHotelRoom
ApproveSolution
Task Ontology
Service Requestor
Event: PlanTrip
PlanTrip
InquireFares
Allocating
MakeHotelRes
+(ConvertCurrencies)
PlanTrip Task
ApplyForVisa
ApplyConstraints
for selfSpecArrangements
ApplyPreferences
perforApproveSolution
AdjustPreferences
mance
AdjustConstraints
+(BookRWFare)
Agent
BookFare
ApproveSolution
Task Ontology
T
Task Ontology
T
Lufthansa
Infoflyway
Frankfurt
700
650
500
Cyber
Flyer
F
$1014=€892
900
€609 €671
$513=€609
22.09
20.09
22.09
-25.09 -25.09 -28.09
A
R
F
A
I
H
CNN Currency Converter
Service: $1=€0.88
Die Bahn
Booking Service
Conference
Info Service
All-hotels.com
Reservation Service
Negotiate
H
Hotel reservation
Service (hrs.de)
Services
Conclusions:

Agent Middle Layer is required for scalable,
intelligent, dynamic service composition

Service Mediator is formed dynamically
as the coalition of service providing agents
(SPAs) participating in the Task execution

Services are self-contained modular loosely
coupled program components wrapped by SPAs