Ontological Modelling of E-Services to Ensure Appropriate Mobile Transactions

Ontological Modelling of E-Services to Ensure Appropriate Mobile

Transactions

Vagan Terziyan

University of Jyvaskyla, Finland

e-mail: vagan@it.jyu.fi

ES2002, Cambridge, UK, 10 December 2002

Contents

Transactions Mobile e-Commerce Transactions Transaction Monitor Architectures Ontology-Based Transaction Monitor Transaction Management for Location-

Based Services Related Work

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

Recovery What if, during the execution of a

transaction, there is a failure of some sort? The DBMS must be able to recover the

database to a previous consistent state

Concurrency Control

The need for concurrency control arises from the presence of multiple transactions accessing the database concurrently

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.

Example Application:Location-sensitive, Continuous Queries

Nearest Japanese restaurant

Nearest hospital w/ certain capabilities and availability

travel info (nearest server station, hotel w/ pool, etc.)

Pizza Hut nearest to destination

Server-Side Transaction Monitor

Server Client

Server

Webresource /

service

Webresource /

service

Transaction Service

wireless

Server-Side Transaction MonitorPositive (1) Less wireless (sub)transactions

Server Client

Server

Webresource /

service

Webresource /

service

Transaction Service

wireless

Server-Side Transaction MonitorPositive (2) Rich ontological support

Server Client

Server

Webresource /

service

Webresource /

service

Transaction Service

wirelessRich ontology of resources,

services,other metadata

Server-Side Transaction MonitorPositive (3) Smaller crash, disconnection vulnerability

Server Client

Server

Webresource /

service

Webresource /

service

Transaction Service

wireless!!OK

Server-Side Transaction MonitorNegative (1) Pure customer’s trust

Server Client

Server

Webresource /

service

Webresource /

service

Transaction Service

wirelessCustomer’sprivate data

Server-Side Transaction MonitorNegative (2) Lack of customer’s awareness and control

Server Client

Server

Webresource /

service

Webresource /

service

Transaction Service

wirelessTransaction data

Transaction online control

Server-Side Transaction MonitorNegative (3) Problematic TM’s adaptation to the customer

Server Client

Server

Webresource /

service

Webresource /

service

Transaction Service

wirelessPublic TM

Example: Server-based transactions for location based application

Client

Application Server

Content providers

Positioning Service

Client-Side Transaction Monitor

ServerClient

Server

Webresource /

service

Webresource /

service

wireless

Client-Side Transaction Monitor. Positive (1) Customer’s firm trust

Server

Client

Server

Webresource /

service

Webresource /

service

wireless

Customer’sprivate data

Client-Side Transaction Monitor. Positive (2) Customer’s awareness and involvement

ServerClient

Server

Webresource /

service

Webresource /

service

wireless

Transaction data

Transaction online control

Client-Side Transaction Monitor. Positive (3) Better TM’s adaptation to the customer

ServerClient

Server

Webresource /

service

Webresource /

service

wireless

Personal TM

Client-Side Transaction Monitor. Negative (1) More wireless (sub)transactions

ServerClient

Server

Webresource /

service

Webresource /

service

wireless

Client-Side Transaction Monitor. Negative (2) Restricted ontological support

ServerClient

Server

Webresource /

service

Webresource /

service

wireless

Restrictedontology of

resources, services,other metadata

Client-Side Transaction Monitor. Negative (3) High crash, disconnection vulnerability

ServerClient

Server

Webresource /

service

Webresource /

service

wireless

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.

The conceptual scheme of the ontology-based transaction management

Transaction data

Service 1 ********

Service 2 ********

Service s ********

Services data

Transaction monitor

Client 1

Service 1 ********

Service 2 ********

Service s ********

Services data

Transaction monitor

Client r

Parameter 1

Parameter 2

Parameter n

Recent value

Transaction data

Parameter 1

Parameter 2

Parameter n

Recent value

Service atomic action ontologies

Parameter 1

Parameter 2

Parameter n

Parameter ontologies

Ontologies

Name 1

Name 2

Name n

Default value / schema 1

Default value / schema 2

Default value / schema n

Name of action 1

input parameters

output parameters

Name of action 2

input parameters

output parameters

Name of action k

input parameters

output parameters

Service Tree

Client 1 ********

Client 2 ********

Client r ********

Clients data

Subtransaction monitor

Service 1

Service Tree

Client 1 ********

Client 2 ********

Client r ********

Clients data

Subtransaction monitor

Service s

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.

Service Tree

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

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.

LOGIN (begin subtransaction)S0

LOGOUT (end subtransaction)

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

TERMINAL_ID 1 From settings

TOTAL_NUMBER_OF_SERVICES 1 From settings

TOTAL_NUMBER_OF_ACTIONS 1 From settings

TOTAL_NUMBER_OF_PARAMETERS 1 From settings

SERVICE_ID TOTAL_NUMBER_OF_SERVICES From settings

SCREEN_FRAME 16 From settings

ID of the Constant Dimension Value

Ontologies

Service atomic action ontologies:

ACTION_ID TOTAL_NUMBER_OF_ACTIONS From settings

INPUT_PARAMETERS_FOR_ACTION TOTAL_NUMBER_OF_ACTIONS ×TOTAL_NUMBER_OF_PARAMETERS

From settings

OUTPUT_PARAMETERS_FROM_ACTION TOTAL_NUMBER_OF_ACTIONS ×TOTAL_NUMBER_OF_PARAMETERS

From settings

Parameter ontologies:

PARAMETER_ID TOTAL_NUMBER_OF_PARAMETERS From settings

PARAMETER_DEFAULT_VALUE TOTAL_NUMBER_OF_PARAMETERS From settings

PARAMETER_TYPE/SCHEMA TOTAL_NUMBER_OF_PARAMETERS From settings

ID of the Ontology Dimension Value

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 ActionsTerminal Servicequery

CURRENT_STATE_OF_SUBTRANSACTION ACTIVE_ACTION_ID

PARAMETER_ID1 /PARAMETER_RECENT_VALUE1/ …

TERMINAL_ID

PARAMETER_IDp /PARAMETER_RECENT_VALUEp/

INPUT_PARAMETERS_FOR_ACTION

service query

Terminal Serviceresponse

CURRENT_STATE_OF_SUBTRANSACTION

ACTIVE_ACTION ID PARAMETER_ID1 /PARAMETER_RECENT_VALUE1/ …

PARAMETER_IDq /PARAMETER_RECENT_VALUEq/

SERVICE_ID

LIST_OF_AVAILABLE_ACTIONS

PRICE_FOR_LAST_ACTION…

OUTPUT_PARAMETERS_FROM_ACTION

service response

An Example of Action

LOGIN login /vagan/ password /1234/0501234567

"Client 0501234567 …

… has made LOGIN query to server.

For that the client entered his login…

…and password."

…of active subtransaction…

… being in S0 state …

LOGIN LOGIN_REPLY /OK/ S1MMM-2001 A1

"Server MMM-2001 reports …

…that during active subtransaction …

…your LOGIN action…

…was OK !

Now you come to state S1 ,…

…after which the only action you may choose is A1."

An Example of Action

A10501234567

"Client 0501234567 …

… has made A1 action (query) to server.

For that the client enteredrequested input parameters.

…and being in S1 state of it…

… during active subtransaction…

Input parameters for action A1

A1 S2MMM-2001 A2,

"Server MMM-2001 reports …

…that during active subtransaction…

…your action (query) A1

has been processed and…

Now you cometo state S2 ,…

…after which the actions youmay choose are A2, A3 and A4."

Output parameters from action A1

…following outcomes are obtained.

A3, A4$1

Price for outcomes is $1 .

LBS example: ontology for the LOCATE_BY_ID action

Locate by ID

Terminal ID

Latitude Longitude

ACTION_ID

Altitude

LBS example: ontology for the LOCATE_BY_ADDRESS action

Locate by address

Country_Name

Latitude Longitude

ACTION_ID

State/Province_Name

City_Name

Street_Name

Street_Number

LBS example: ontology for the GET_MAP action

Get map

Latitude Longitude

ACTION_ID

LBS example: ontology for the GET_INFO action

Get Info

point_address

point_of_interest

OUTPUT_PARAMETERS

_FROM_ACTION

ACTION_ID

point_phone

point_info

OUTPUT_PARAMETERS

_FROM_ACTION

LBS example: service tree for the Positioning Service

S1Locate by ID

S1LOGINS0

S0LOGOUT

S1Locate by Address

LBS example: service tree for the Location Based Service

Get map

S2Get info

S1LOGINS0

S0LOGOUT

LBS example: Case when a user locates himself and submits coordinates to LBS

TerminalLocation-

Based ServicePositioning

Service

Login (user_ID, password)

Login (Login - OK)

Get map (coordinates)

Get map (map)

Locate by address (address)

Locate by address (Coordinates)

Login (user_ID, password)

Login (Login - OK)

Get info (point of interest)

Get info (point information)

Logout (user_ID)

Logout (Logout - OK)

Logout (user_ID)

Logout (Logout - OK)

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

Terminal Positioning Service

“Login” Query

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

</Actions_Allowed >

</Response>

“Login” Response

<Input_Parameters> <ParameterID="street_number” Type="integer” Value="43"/> <ParameterID="street_name” Type="text” Value="Nokatu"/> <ParameterID="city_name" Type="text” Value="Jyvaskyla"/> <ParameterID="country_name” Type="text” Value="Finland"/> </Input_Parameters>

</Query>

“Locate by Address” Query

<Price_for_Action Currency="EURO" Value="0.23"/><Bill_Recent_Value Currency="EURO" Value="0.23"/> <Actions_Allowed>

</Actions_Allowed ></Response>

“Locate by Address” Response

<Input_Parameters> <Parameter ID="user_ID” Type="text” Value="vagan"/> </Input_Parameters>

</Query>

“Logout” Query

<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

<Input_Parameters> <Parameter ID="user_ID” Type="text” Value="vagan"/> <Parameter ID="password” Type="text" Value="1234"/></Input_Parameters>

</Query>

Terminal Location-Based Service

“Login” Query

<Output_Parameters> <Parameter ID="login_reply” Type="binary" Value="OK"/> </Output_Parameters>

<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

<Input_Parameters> <Parameter ID= "latitude” Type= "integer” Value="54321"/> <Parameter ID= "longitude” Type= "integer” Value="98765"/> </Input_Parameters>

</Query>

“Get Map” Query

<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

<Input_Parameters> <Parameter ID= "point_of_interest” Type="text” Value="Alba_Hotel"/> </Input_Parameters>

</Query>

“Get Info” Query

<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

<Input_Parameters> <Parameter ID="user_ID” Type="text” Value="vagan"/> </Input_Parameters>

</Query>

“Logout” Query

<Output_Parameters><Parameter ID="logout_reply" Type="binary" Value="OK"/> </Output_Parameters>

<Price_for_Action Currency= ”USD” Value= "0.0"/>

<Bill_Recent_Value Currency= ”USD” Value= "0.25"/>

<Actions_Allowed> <Action ID="LOGIN"/> </Actions_Allowed >

</Response>

“Logout” Response

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

Customer

Service 1

Service 2

Distributedindependent purchase

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.

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.

MapCustomer

Service 1

Service 2

Distributed sequentialpurchase

Connection to MeT (Mobile Electronic Transactions) initiative

According to MeT "Consistent User Experience" framework the user interface should allow to people to transfer their knowledge and skills from one application to any other application. Consistency of visual interface and terminology helps people to learn and then easily recognize the "language" of the interface.

The Transaction Monitor, due to implementation of the concept of ontology-based transaction management, offers such a consistent standardize interface of a user with multiple services.

Connection to Hewlett Packard’s E-Speak platform

E-speak is an open software platform designed specifically for the development, deployment, intelligent interaction, and management of globally distributed e-services. E-Speak makes services capable to interact with each other on behalf of their users, and compose themselves into more complex services. The E-Speak Service Engine actually is a transaction monitor software that performs the intelligent interaction of e-services.

The Transaction Monitor in the hands of user is a good example of an E-Speak engine, which expands the E-Speak internet-based framework to wireless.

Connection to the OntoWeb network platform

The goal of the OntoWeb (Ontology-based information exchange for knowledge management and electronic commerce) Network is to promote Semantic Web standardisation efforts in e-commerce such as those based on RDF and XML.

The implementation of the concept of ontology-based transaction management for mobile terminal allows expanding a target for the OntoWeb framework also to m-commerce.

Connection to the Mediators and Wrappers framework

Wrappers and mediators can be considered as useful addition to the ontology-based framework in cases when some existing service cannot be easily adapted to the ontology of some e-services community.

Wrapper for a Transaction Monitor can be considered as an interface to each e-service, which defines the service schema. Mediator can be considered as an interface to a group of e-services, which defines a global schema from the local schemas and combines the schemas and the information of the local e-services.

Connection to the Mobile Agents framework

With the increasing market of electronic commerce it becomes an interesting aspect to use autonomous mobile agents for electronic business transactions. Being involved in money transactions, supplementary security features for mobile agent transaction management architecture have to be ensured. Architecture should guarantee security for the host as well as security for the agent. To handle these issues for mobile agents various encryption mechanisms should be used. Due to this security architecture an agent will be enabled to carry out money transactions.

Connection to the DAML-S framework

DAML-S - semantic markup for Web services is one of the Semantic Web community efforts to enable not only content but also services on the Web. It will enable users and software agents to automatically discover, invoke, compose, and monitor Web resources offering services, under specified constraints. The DAML-S coalition is developing ontology of services, service profiles and appropriate process model. The use of DAML (DARPA Agent Markup Language) supposes that artificial agents will do most of future transactions across multiple web services. The mobile terminal-based TM is one step towards agent based future of e-services in a mobile environment.

References

1. Terziyan V., Veijalainen J., Tirri H., Mobile e-Commerce Transaction Model, Multimeetmobile Project Report, TITU, University of Jyvaskyla, January 2001.

2. Terziyan V., Veijalainen J., M-Commerce Transaction Model Implementation at a Mobile Terminal, Multimeetmobile Project Report, TITU, University of Jyvaskyla, April 2001.

3. Terziyan V., Ontology-Driven Transaction Monitor for Mobile Services, In: Proceedings of the Semweb@KR2002 Workshop on Formal Ontology, Knowledge Representation and Intelligent Systems for the World Wide Web, Toulouse, France, 19-20 April, 2002.

AcknowledgementsInformation Technology Research Institute (University of Jyvaskyla):

Customer-oriented research and development in Information Technology

http://www.titu.jyu.fi/eindex.html

Multimeetmobile (MMM) Project (2000-2001):

Location-Based Service System and Transaction Management in Mobile Electronic Commerce

http://www.cs.jyu.fi/~mmm

Agora Center(University of Jyvaskyla):

Innovations in Business, Communication and Technology Research Project (InBCT)

http://www.jyu.fi/agora/

Ontological Modelling of E-Services to Ensure Appropriate Mobile Transactions

Documents

Transcript of Ontological Modelling of E-Services to Ensure Appropriate Mobile Transactions

Scalable Ontological Sense Matching

Anselm Ontological Argument

Reiner Schürmann_The ontological diference

HOMME: Ontological Explorer

Apresentação do PowerPoint - Terra Global · Thiago Chagas Ludovino Lopes Advogados. Types of Transactions Forward Transactions •often long-term •non-standardized •more appropriate

An Ontological Exposition

Ontological Argument Ppt edited

Ontological status of evil

The Ontological Argument Revisited

Schelling Ontological

Ontological considerations

Ontological Commitments - Alston

Ontological Arguments Peter van Inwagen Noûs, Vol. 11, No ...commonsenseatheism.com/.../uploads/2009/09/Ontological-Arguments.pdf · ONTOLOGICAL ARGUMENTS 377 objects, to wit, mathematical

Ontological Navigation

Distinguishing Ontological Frameworks

An Ontological Inquiry in Early Qur' an Commentariesdigitool.library.mcgill.ca/thesisfile83194.pdf · An Ontological Inquiry in Early Qur' an Commentaries by ... 2. Part 1: Ontological

Ontological designing our future

Ontological Routing & POI linking

The Ontological Presuppositions of the Ontological Argumentcommonsenseatheism.com/wp-content/uploads/2009/09/Mann-Ontological... · THE ONTOLOGICAL PRESUPPOSITIONS OF THE ONTOLOGICAL

The Ontological Status of Persons*schopra/Persons/Baker.pdfOn Animalism, animals have ontological significance, but persons do not. After explaining the notion of ontological significance,