1 / 72

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

marcia-mcfarland
Download Presentation

Ontological Modelling of E-Services to Ensure Appropriate Mobile Transactions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Contents • Transactions • Mobile e-Commerce Transactions • Transaction Monitor Architectures • Ontology-Based Transaction Monitor • Transaction Management for Location-Based Services • Related Work

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

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

  5. Concurrency Control • The need for concurrency control arises from the presence of multiple transactions accessing the database concurrently

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

  7. Basic (ACID) Transactional Properties • Atomicity • Consistency • Isolation • Durability

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

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

  10. Isolation Isolation means thatvarious steps of a transaction do not interfere with steps of other transactions.

  11. Durability Durability means that once a transaction completes its execution, its results become permanent even in the presence of failures.

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

  13. Server-Side Transaction Monitor Web resource / service Server Client wireless Web resource / service TM Transaction Service Server

  14. Server-Side Transaction MonitorPositive (1) Less wireless (sub)transactions Web resource / service Server Client wireless ! Web resource / service TM Transaction Service Server

  15. Server-Side Transaction MonitorPositive (2) Rich ontological support Web resource / service Server Client wireless Rich ontology of resources, services, other metadata Web resource / service TM Transaction Service Server

  16. Server-Side Transaction MonitorPositive (3) Smaller crash, disconnection vulnerability Web resource / service Server ! ! OK Client wireless Web resource / service TM Transaction Service Server

  17. Server-Side Transaction MonitorNegative (1) Pure customer’s trust Web resource / service Server Client wireless Customer’s private data Web resource / service TM Transaction Service Server

  18. Server-Side Transaction MonitorNegative (2) Lack of customer’s awareness and control Web resource / service Server Client wireless Transaction online control Transaction data Web resource / service TM Transaction Service Server

  19. Server-Side Transaction MonitorNegative (3) Problematic TM’s adaptation to the customer Web resource / service Server Client wireless Public TM Web resource / service TM Transaction Service Server

  20. Example: Server-based transactions for location based application 6 4 Application Server 5 Positioning Service 3 10 9 2 Client 7 8 1 11 Content providers 12

  21. Client-Side Transaction Monitor TM Web resource / service wireless Client Server wireless Web resource / service Server

  22. Client-Side Transaction Monitor. Positive (1) Customer’s firm trust TM Web resource / service wireless Client Server Customer’s private data wireless Web resource / service Server

  23. Client-Side Transaction Monitor. Positive (2) Customer’s awareness and involvement TM Web resource / service wireless Transaction online control Client Server Transaction data wireless Web resource / service Server

  24. Client-Side Transaction Monitor. Positive (3) Better TM’s adaptation to the customer TM Web resource / service wireless Client Server Personal TM wireless Web resource / service Server

  25. Client-Side Transaction Monitor. Negative (1) More wireless (sub)transactions TM Web resource / service wireless Client Server wireless ! Web resource / service Server

  26. Client-Side Transaction Monitor. Negative (2) Restricted ontological support TM Web resource / service wireless Client Server Restricted ontology of resources, services, other metadata wireless Web resource / service Server

  27. Client-Side Transaction Monitor. Negative (3) High crash, disconnection vulnerability TM Web resource / service wireless Client Server wireless Web resource / service Server

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

  29. The conceptual scheme of the ontology-based transaction management

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

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

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

  33. Service Tree 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. 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

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

  35. Basic constants

  36. Ontologies

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

  38. Service Actions service query service response

  39. An Example of Action

  40. An Example of Action

  41. LBS example: ontology for the LOCATE_BY_ID action

  42. LBS example: ontology for the LOCATE_BY_ADDRESS action

  43. LBS example: ontology for the GET_MAP action

  44. LBS example: ontology for the GET_INFO action

  45. LBS example: service tree for the Positioning Service

  46. LBS example: service tree for the Location Based Service

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

  48. <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> <ParameterID="user_ID” Type="text” Value="vagan"/> <ParameterID="password” Type="text” Value="4321"/> </Input_Parameters> </Query> “Login” Query Positioning Service Terminal

  49. <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 Positioning Service Terminal

  50. <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” Value="43"/> <ParameterID="street_name” Type="text” Value="Nokatu"/> <ParameterID="city_name" Type="text” Value="Jyvaskyla"/> <Parameter ID="country_name” Type="text” Value="Finland"/> </Input_Parameters> </Query> “Locate by Address” Query Positioning Service Terminal

More Related