Transaction Management for MCommerce at a Mobile Terminal

1
Transaction Management for M-Commerce at a Mobile
Terminal

• Jari Veijalainen
• Vagan Terziyan

2
Contents

• Introduction
• Modeling M-commerce transactions
• Application-driven MC-Transaction Manager Design
• Ontology-oriented MC-Transaction Manager Design
• More general trends in M-commerce
• Conclusions

3
Introduction

• Currently mobile Internet is advancing fast in
  Japan NTT DoCoMos i-Mode and similar services of
  the other operators have gathered 30-40 million
  users and it is expected that the penetration
  will reach saturation in a few years
• Telecom industry estimates that in 2003 there
  will be over 500 million Internet-enabled
  terminals in use in the world, the total number
  is now about 1 billion
• An important class of applications running on
  these terminals are M-commerce applications
• M-commerce is shortly said E-commerce
  conducted with wireless portable handsets, i.e.
  it is a special case of E-commerce
• the distinction between the Internet E-commerce
  are dynamic Location Based Services (LBS) that
  use the actual location of the terminal on earth
  in one way or the other to perform the
  transaction (cf. ordering taxi in a foreign city
  based on the positioning of the terminal and the
  taxi)

4
Introduction The big picture convergence of
Internet and digital telecom networks

PC
PC
Mobile terminal
TV set
IP Backbone Network
Mobile NW Operator sphere
E-commerce server
CA server
Service provider Server (e.g. GIS)
Community server
5
Introduction Some measures for the big picture

• there are about 700 GSM networks in 171 countries
  on earth and several other types of 2G networks
  (eg. CDMA-based)
• GSM technology is truly global with its roaming
  capability and coverage
• the number of digital telecom handsets will soon
  exceed 1 billion (this year 400 million handsets
  will be sold) and by 2005 perhaps 2 billions
• of these hundred of millions are
  Internet-enabled( WWW or WAP)
• There are over a hundred million of servers at
  the server side

6
Introduction Functional convergence on PTDs
7
Introduction Roaming heterogeneityovercoming it
an all levels
8
Introduction Technical enablers of advanced
services
9
Introduction M-commerce prospectives

• Due to the huge number of terminals and emerging
  Location-Based Services that are the most natural
  M-commerce applications, there is a rather
  considerable potential for M-commerce
• there are still obstacles currently the
  technology is not mature and it raises fears of
  security and privacy
• the terminals are not as convenient as PCs for
  conducting E-commerce transactions designed for
  PCs and wired Internet
• The importance of M-commerce applications is
  recognized by key players who have established
  Mobile electronic Transactions Forum
• MeT is an initiative founded to establish a
  framework for secure mobile transactions,
  ensuring a consistent user experience independent
  of device, service and network.
  http//www.mobiletransaction.org/
• Open Mobile Architecture (OMA) attempts to
  prevent the fragmentation of the Mobile Services,
  including M-commerce services, at all levels
  www.nokia.com/oma

10
Introduction problems of M-commerce transactions

• there are still problems with the M-commerce
  transactions not addressed by MeT or other
  bodies, like OMA
• the computations are inherently distributed
  (apply at least a wireless communication link),
  but no clear overall computational properties
  have been specified (termination of the
  computations, exact status, correctness of them
  etc)
• especially overall atomicity in an exact sense is
  not guaranteed M-commerce transaction succeeds
  only if all parts including ordering, payment and
  goods delivery succeed, but this is not really
  addressed by MeT
• if something goes wrong in some part of the
  transaction execution it is difficult to
  automatically find out what exactly has happened
  and how the situation could be recovered

11
Modeling M-commerce transactions Location-Based
Services (LBS)

• LBS in a broad sense Services accessible
  through the network that utilize location of
  various objects on earth (or in space)
• Location-aware services do not need the actual
  position of the terminals on earth in order to be
  provided
• example send me the map of Kyoto, or find all
  restaurants at most 500 m away from Jyvaskyla
  railway station
• Notice that these queries can be posed through a
  fixed PC or mobile terminal
• Location-dependent services Services utilizing
  the possibility to dynamically determine the
  actual position of terminals and the persons
  carrying them
• Typically services accessed with or offered by
  the mobile terminals
• Examples
• Finding a suitable restaurant
• Ordering of a taxi
• Finding the current position of a child or friend
  (I.e. location of another terminal)

12
Modeling M-commerce transactions GIS Supporting
LBS

• Geographic data collection and conversion
• Geographic data management
• Geographic data analysis
• Geographic data presentation
• Building advanced and usable LBS in global scale
  require
• Efficient data collection methods
• Extensive utilization of existing GIS databases
• Standardization and interoperability
• Knowledge and efficient methods for geographic
  data transformations
• Efficient geographic data analysis methods
• Knowledge and methods of geographic data
  presentation

13
Modeling M-commerce transactions

• we view the whole distributed computation
  facilitating the M-commerce transaction as a(n
  execution) graph that has a spanning tree
• the root of the (spanning) tree models the
  computation at the mobile terminal, the nodes
  computations at different players
• the arcs model messages sent between players
  according to a protocol also sending tangible
  goods are represented in the same way
• based on the graph one can specify when a
  transaction is complete/incomplete, when it is in
  a consistent/inconsistent state etc.
• the most important property of MC-transactions is
  certified delivery ala Tyger this can be
  specified based on the form of the execution
  graph

14
Modeling M-commerce transactions examples
15
Modeling M-commerce transactions

• the model is similar to the S-transaction model
  (see Elmagramid 92), but
• an MC transaction is business model-dependent
  different business models and customer
  relationships lead to structurally different kind
  of MC-transactions (whereas S-transactions are
  regular in structure)
• MC- transactions are heterogeneous in the sense
  that at different levels there can be different
  protocols in use these do not always offer
  commit/abort facilities they might also be
  unreliable (cf. HTTP request-responses)
• the terminal cannot always control the fate of
  the overall transaction for the above reason
• Thus The actual scope or sphere of control of an
  MC transaction is the root and first level of the
  execution graph

16
LBS-oriented client design

• The actual application in our case is a
  location-based service that first checks the
  position of the terminal and then provides a menu
  for the user to select the features of the city
  she is interested in
• after that, the client side asks the server to
  compile the requested vector map from the
  database and sent it to the client
• after receiving the map (in XML encoded format),
  the client renders it and shows it to the user
• The application can also use locally stored
  compressed maps in the above format
• with the help of the component TM the application
  can recover (forward) an earlier session after
  any crash

17
LBS-oriented client architecture

18
Application-driven M-commerce TM design

• A MC TM tries to guarantee transactional
  properties for the first level of the execution
  graph
• it is assumed that it runs at the mobile terminal
• it acts against
• terminal crashes
• application crashes
• connection losses
• server crashes
• it facilitates forward and backward recovery of
  an interrupted transaction
• technically, it can be designed in various ways
• as an application-driven software running as part
  of the application process
• as a separate demon process
• it can control itself the application-server
  communication or let application do it also
  during the recovery

19
Application-driven MC TM design

• we chose a design, where the TM is rather close
  to a logger thus, a large portion of the
  responsibility for the transactional properties
  remain at the application
• it runs as part of the application process and
  logs data asked by the application
• upon recovery, it checks for the non-closed
  transactions in the log and asks the application
  to choose one to be finalized
• it is assumed that the TM is not able to decide
  what to do for an interrupted transaction, but
  the application perhaps together with the user
  must do the right steps, this is because the
  semantics of the MC transactions varies and it is
  rather difficult to describe for a
  general-purpose TM all variations of the recovery.

20
Application-driven TM design

• Due to the structure of the M-commerce
  transactions at the root we decided to record
  into the log
• Each request-response pair towards servers
  (action)
• A sequence of actions towards a certain server
  (subtransaction)
• The overall sequence of subtransactions
  (transaction)
• For all these the application attempts to
  guarantee atomicity (either happens or did not
  happen)
• This is marked by begin tag and end tag in the
  log
• The TM understands the non-atomicity of the
  actions, subtransactions and transactions during
  recovery end tag is missing
• The TM also writes the parameters of each action,
  including the entire map, into the log so that
  they can be reused either when requests are
  resubmitted or results displayed upon recovery
• the actual log is stored in a special XML-format
  that can be rendered e.g. by a browser the maps
  are stored in a local format used by the Java
  programs

21
Application-driven MC TM design
22
An alternative TM design Ontological TM

• there are certain problems with the above design
• It is very difficult to provide action atomicity
  so that it is recorded correctly into the log
  now we have if there is a log record then
  certainly the atomicity is guaranteed, but
  lacking end-record does not mean that the action
  did not succeed (crash only prevented to close
  the log record)
• A more clever TM could also automatically try to
  recover now the application must be able to
  decide what to do with the log records it finds,
  whether to recover forward or backward
• The TM should guarantee security features
  (message encryption and decryption using WPKI,
  storing them in an encrypted form)
• The TM should take care of the communication
  towards the servers

23
An alternative TM design Ontological TM
Application
Transaction Monitor
Log
Security manager
Communication Manager
TO/From Server
24
An alternative TM design Ontological

• How much should TM understand about the
  ontology of the communicated messages between the
  application and various servers?
• if the TM cannot automatically deduce all
  intentions of the application, how should the
  application signal the intentions (e.g. that a
  signature is required to authorise the M-commerce
  transaction)?
• that is, what kind of interface specification
  should there be between the application and TM?

25
MLS Pilot System

• Multimeetmobile Location-based Service system
• Developed in MultiMeetMobile research project
• www.cs.jyu.fi/mmm
• Offering map and navigation service accompanied
  with access to location-based information

26
MLS Pilot System

• The constraints of mobile computing environment
  where taken into account
• Mobile terminals memory, computing power, screen
  size and resolution, means of input, power
  consumption
• Mobile networks bandwidth, latency, connection
  stability, availability, cost
• Using conditions unpredictable and cognitively
  demanding environments
• Features
• Based on geographic vector data
• XML-based vector data
• Some computation delegated to the client (e.g.
  zooming and panning)
• Programmed with Java (runs on Symbian 5 and 6
  devices, MS Windows))
• Intelligent selection of geographic data (up to
  certain distance of the current location)
• Transaction management feature recovers
  (forward) to the current state

27
Business model issues

• How to load the map software
• By the terminal manufacturer?
• By the user over Internet/PC? (in advance)
• By the user over a wireless network on the spot?
• By the user at a special Internet Kiosk on the
  spot?
• How to load the maps?
• By the user over Internet/PC (in advance)
• By the user over a wireless telecom network on
  the spot?
• By the user at a special Internet kiosk on the
  spot (BT)?

28
MLS Future Work

• Improving the user interface
• Implementing analysis functions, such as advanced
  search and route finding
• Further development of Transaction Monitor
• Implementing client to J2ME
• More efficient utilization of Oracle Spatial GIS
  functions
• Support for dynamic geographic objects
• XML-based interaction with content servers
• Utilization of existing location services
• Testing the solutions with different devices and
  operating systems

29
Conclusions and further research

• The level of the persistency of the log state is
  determined by the most persistent programmable
  memory offered at the terminal
• The Application-driven TM design is the first
  iterationit implements 3-level MC transaction
  concept and the application interface is
  accordingly complicated
• a more intelligent TM design with more automatic
  analysis and recovery features is for further
  study