Transaction Management for M-Commerce 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 DoCoMo’s 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 heterogeneity:overcoming 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 PC:s for conducting E-commerce transactions designed for PC:s 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. Map image User-Interface Render Mobile-Manager Analysis Geographical Data Data-Source Transaction Monitor XML-Parser 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 iteration;it 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