Flexible Transaction Processing in Mobile Enviornment

8/14/2019 Flexible Transaction Processing in Mobile Enviornment

1/5

Transaction Service Discovery in Mobile Environments

Arne Ketil EidsvikComputer Science Department

University of Troms, [email protected]

Randi KarlsenComputer Science Department

University of Troms, [email protected]

Gordon BlairComputing Department

Lancaster University, [email protected]

Paul Grace

Computing Department,

Lancaster University, UK,

[email protected]

Abstract

Transaction execution in mobile environments needs to

be flexible, not only to support typical mobile comput-ing characteristics, like movement, disconnections and lim-

ited resources, but also to support the variety of transac-

tional properties that might be required by different appli-

cations. This paper presents an approach for flexible trans-

action processing in mobile applications, and describes

an adaptive middleware for mobile transaction services

(MobileTSe), that makes transaction services with different

properties available on the mobile unit. We suggest a so-

lution with transaction service discovery and control using

UPnP.

1 Introduction

Devices like mobile phones, PDAs and GPS navigators

are very common and the technology is advancing rapidly.

Increased processor and memory capacity enables more ad-

vanced mobile applications while wireless technology en-

ables mobile devices to be online almost anytime anywhere.

However, mobile technology will still suffer from discon-

nections due to movement and limitations in hardware re-

sources like bandwidth, battery life and memory capacity.

Mobile applications require transaction management to

reliably access resources in both fixed and mobile networks.

As a mobile unit operates in different environments and ex-ecute various applications, we argue that a variety of trans-

action services should be available. Current models for mo-

bile transactions handle different aspects of transaction exe-

cution such as movement and disconnections [4, 9, 13], but

do not support the variety of transactional properties that are

required in many applications (including ACID and differ-

ent beyond-ACID properties). Supporting different proper-

ties requires a flexibility which we believe is best provided

with a middleware which is able to adapt according to vari-

ous transaction models. We propose such a middleware andname it MobileTSe.

MobileTSe enables a limited number of transaction ser-

vices to be available on the mobile unit. We call these lo-

cal transaction services. In some cases the mobile unit is a

powerful laptop. In other cases the mobile unit is a mo-

bile phone or PDA with limited processing and memory

capacity. In the latter case the local transaction services

must be lightweight in terms of memory and processor con-

sumption. The transactional properties of local transaction

services may in some cases not be sufficient for a specific

transaction execution. Mobile transactions may, therefore,

need access to other transaction services than those avail-able in the mobile unit. Services with the required proper-

ties may be available on separate computers in the network

and we call these external transaction services. External

transaction services are in MobileTSe reached through a

service discovery protocol. By using MobileTSe, both ex-

ternal and local transaction services are thus available for

applications on the mobile unit.

In this paper we present an architecture of the

MobileTSe, a flexible transaction service framework for

mobile environments which can adapt according to vary-

ing transactional requirements. MobileTSe represents a

novel approach to mobile transaction management by of-

fering a number of transaction services with different prop-erties to mobile applications. MobileTSe allows deploy-

ment of transaction services in mobile units, and provides

the means to reach external transaction services available

on separate devices in the network. To enable access to ex-

ternal transaction services, we introduce transaction service

discovery through use of UPnP.

Proceedings of the 20th International Conference on Advanced Information Networking and Applications (AINA06)

550-445X/06 $20.00 2006IEEE


2/5

2 Scenario

Information sharing at an academic conference is an

example of transaction execution in mobile environments.

Conference participants and organizers meet and share in-

formation, traditionally through conference presentations

and informal chats at the conference area. A mobile in-formation system will facilitate further possibilities for in-

formation sharing, and the use of transaction services will

enable application programmers and users to secure a rel-

evant level of correctness. Participants can use their PDAs

and laptops to search for information from conference or-

ganizers and from fellow participants and also offer their

own information for sharing (for instance information about

themselves, their research projects, employers and a selec-

tion of their own articles). Conference organizers will typ-

ically provide downloadable conference proceedings, pow-

erpoint presentations, bulletin boards, further information

about profiled products from conference exhibitions and of-

fer ticket sales for conference happenings.In such an information system we will find both long and

short transactions, some with ACID properties and some

with loosened requirements. An example of a long trans-

action with loose properties is when a user downloads all

available information on a specific topic from both organiz-

ers and participants. This transaction could last long enough

for the user to move beyond the range of the wireless net-

work and get disconnected. When the user is reconnected

the transaction continues transparently. This kind of trans-

action need not require strict atomicity, but the user should

be notified whether the transaction was successful or not.

In another case a conference participant can require

transactions requesting information about him and his

projects to be atomic. In this way the user can assure that all

presented information about him is complete. Transactions

involving payments like for instance buying tickets to a con-

ference concert will require complete ACID properties.

Few mobile transaction models have been implemented

in commercially available systems. One reason may be the

variation in requirements for mobile transactions as illus-

trated in the above example. Our proposition for a flexible

transactional middleware allows for a dynamic use of ex-

isting mobile transaction models through adaptation at run-

time. Such a middleware will make it more valuable for

application programmers to utilize the advantages of faulttolerant transaction services according to application spe-

cific requirements and environmental properties.

3 MobileTSe

MobileTSe is a flexible transaction service environment

in which local transaction service components can be de-

ployed and from which external transaction services can be

controlled. Transaction services may comply with different

models to support various mobile transaction requirements.

MobileTSe supports service discovery protocols which

enable mobile units to combine local and external transac-

tion services. The limited resources in the mobile unit sug-

gests a lightweight implementation while dynamical trans-

actional requirements demand a flexible solution whichmight require a larger software system. The solution is to

have a middleware (MobileTSe) in the mobile unit which

is flexible according to various transaction requirements, in-

teraction types and service discovery protocols.

The deployed transaction service can be used by appli-

cations which are running both locally on the same mobile

unit and externally. MobileTSe can also access external

transaction services on separate devices using service dis-

covery protocols. In figure 1 two applications issue requests

for transaction services. Application 1 requires a transac-

tion service with properties offered by service 1 while ap-

plication 2 requires the properties of the external transaction

service 2. Compatibility issues between transaction servicecomponents are resolved and the transactions are initiated.

Device 1

discovery

TSmanager

service 2Transaction

MobileTSannouncer

Transactionservice 1

Transaction servicemeta information

service 2Transaction

Application 2Application 1

MobileTSe

UPnP

Device 2 (external)

Request for service 1 Request for service 2

(Mobile unit)

MobileTS

Figure 1. MobileTSe architecture

MobileTSe consists of a TSmanager, a MobileTS-

discovery, a MobileTSannouncer and an information

base with meta information about available transaction ser-

vices. MobileTSe can offer a currently deployed local

transaction service or an externally available transactionservice. When TSmanager receives a request for a transac-

tion service it first tries to find a suitable service described

in the stored meta information. If no service is found, a

search is issued through the MobileTSdiscovery and the

UPnP interface.

The MobileTSdiscovery component presents an ex-

ternal transaction service as a virtual local service to the

TSmanager. A virtual local transaction service is shown


550-445X/06 $20.00 2006IEEE


3/5

with dotted lines in figure 1.

A mobile unit will, when entering a network, establish

which service discovery protocols are used (e.g. UPnP, SLP

or Jini), then the interaction type (RPC or publish subscribe)

and finally which transaction services are available. The

MobileTSdiscovery does a search for available transac-

tion services and stores their properties in the informationbase. When a request for transaction execution is subse-

quently received by the MobileTSe, the most appropriate

transaction service available is chosen.

The MobileTSannouncer will advertise - and respond

to requests for - local transaction services which the user

chooses to makes available for other units in the network.

In this way MobileTSe can act both as a server and a client

in a peer-to-peer network of transaction services.

Our work on flexibility with respect to interaction types

and service discovery protocols is based on ReMMoC [5].

ReMMoC is a reflective middleware [2] which can adapt

according to various interaction types and service discov-

ery protocols. MobileTSe has been influenced by TSen-vironment [7, 8], which is a component framework where

different transaction service components can be deployed,

modified and concurrently used. In contrary to TSenviron-

ment, MobileTSe is specifically designed for use in mobile

environments.

4 Transaction services and UPnP

This section shows how UPnP is used in MobileTSe to

make transaction services available to mobile applications.

UPnP is chosen as discovery protocol for MobileTSe be-

cause it supports wireless networks and state eventing mak-ing it possible to monitor transaction state.

4.1 UPnP

UPnP is a protocol for automatic discovery and device

interoperability on a peer-to-peer network. A UPnP-based

network consists of a set of devices (service providers) that

can be monitored and controlled by one or more control

points [12, 6]. PDAs, mobile phones and laptops are pos-

sible control points, while home entertainment systems, re-

mote controlled light switches, and in our case computers

with transaction services are possible devices.

For identification purposes, the device hosts a XML de-vice description document that contains a list of specific

properties about the device and a list of all its services. The

device description document also includes a Uniform Re-

source Locator (URL) to each service description. The ser-

vice description is an XML document that lists the actions

and state variables that apply to a specific service offered

by the device. The actions can be used to control the ser-

vice, and the variables to monitor the state of the service.

The control point can listen to advertising messages from

devices or do an active search for a particular device. For

peer-to-peer networking a mobile unit can take the roles of

both a control point and an advertised device.

UPnP can be divided into 5 phases: discovery, descrip-

tion, control, eventing and presentation. During discovery a

new device on the network is allowed to advertise itself andits services with Simple Service Discovery Protocol (SSDP)

notify messages. When new control points are entering the

network they can do a qualified search for specified de-

vices by multicasting a SSDP search message. All devices

matching the qualifications in the discovery message must

respond to the control point with a message that contains a

URL to the device description.

The device description document is retrieved by the con-

trol point. The document specifies a schema for embedded

devices and services, commands and actions which the ser-

vices respond to and also variables modeling the state of

the service at runtime. The XML schema for describing de-

vices is called a UPnP template language (UTL). The con-trol point issues an HTTP GET request on the URL from

the discovery message to retrieve the document.

4.2 Transaction services

In MobileTSe we use UPnP to advertise, discover and

control transaction services. This paper focuses on the parts

of the device description and service description which are

most relevant to transaction service discovery. The device

description contains information like manufacturer, model,

some general description and serial number. It also includes

information about its services. In our example the devicecontains a transaction service which we name FlexTrans-

action service. The information in the device description

about the service is type, name and URLs for service de-

scription, control and eventing. This is shown in figure 2.

...

...

urn:domain-name:service:FlexTransaction:2

urn:domain-name:serviceID:FlexTransaction

URL to service description

URL for control

URL for eventing

...

Figure 2. Device description


550-445X/06 $20.00 2006IEEE


4/5

The URL to service description identifies another XML-

document. In figure 2 this is a URL to the service descrip-

tion document for the transaction service FlexTransaction.

Information in the service description document is about ac-

tions, arguments to actions and state variables.

...

XbeginTransaction

XtransactionID

out

XtransactionID

...

...

Figure 3. Action XbeginTransaction

An XML-sequence in the service description document

for the action XbeginTransaction is shown in figure 3. Simi-

lar sequences describe other actions like commit, abort, split

and so on. Each argument for an action is tied to a related

state variable. This variable can be monitored for state and it

also specifies the type of arguments. The XML-sequence in

figure 4 describes the state variable XtransactionID which

is tied to the argument with the same name in the action

XbeginTransaction.

...

XtransactionID

ui4

0

4294967295

1

...

Figure 4. State variable XtransactionID

When MobileTSe has received information about the

device and its transaction services, it controls the ser-

vices by invoking actions and receiving return values.

MobileTSe invokes an action by sending a message to the

transaction service, and the service returns any results when

the action is completed or has failed. The control message

is sent to the services control URL specified in the device

description.

Control messages with actions, responds and errors are

formatted using Simple Object Access Protocol (SOAP)

and delivered via HTTP. In the example above, a transac-

tion owner, here MobileTSe, issues an XtransactionBegin

action to the service to initiate a transaction. It receives a

transaction identifier, XtransactionID for later use when in-teracting with the transaction service. Action, arguments

and state variables are shown in figures 3 and 4, and the

control message for issuing the action is shown in figure 5.

POST host of control URL HTTP/1.1

HOST: host of control URL: post of control URL

CONTENT-LENGTH: bytes in body

CONTENT-TYPE: text/xml; charset="utf-8"

SOAPACTION: "urn:domain-name:service:

FLexTransaction:2#XtransactionBegin"

Figure 5. Issuing the action XtransactionBe-

gin

An action may lead to a change in state variables that

are of interest for several control points. Therefore con-

trol points may subscribe to notifications of changes in state

variables. Publication of changes in state variables is calledeventing. Upon receiving a subscription from a control

point on particular events, the service returns the values

of corresponding state variables and all subsequent changes

for a period of time.

5 Related Work

Several models for mobile transactions have been pro-

posed, for instance [4, 9, 13], in which disconnects and

movement are handled differently. Even though these mod-

els allow flexibility with respect to mobile behavior, they do

not provide the necessary flexibility with respect to transac-tional properties. They all describe transaction processing

according to a predefined set of properties, and do not have

the ability to adapt according to different needs.

Flexible transactional systems have previously been de-

scribed in [1, 14]. Barga et al. describe in [1] a reflective

transaction framework that implements extended transac-

tion models on top of TP-monitors. The framework uses

transaction adapters on the meta level to extend TP-monitor


550-445X/06 $20.00 2006IEEE


5/5

behaviour. In [14] Reflective Java is used to implement a

flexible transaction service that allows application devel-

opers to provide application-specific information to a con-

tainer so that this can be used to customize the transaction

service. Related research on dynamic combination and con-

figuration of transactional and middleware systems is found

in [15, 11, 10, 3]. These works recognize the diversity ofsystems and their different transactional requirements, and

describe approaches to support these needs. However, they

do not specifically address mobile systems and do not allow

the type of flexibility described in this paper.

MobileTSe contrasts previous work in the ability to

adapt to varying mobile transactional requirements by of-

fering a number of available transaction services, that are

both local and external to the mobile unit. Allowing re-

mote transaction execution through transaction service dis-

covery is a novel approach to mobile transaction execution.

Our proposition allows adaptation to new transaction mod-

els during runtime, and opens up for adaptation to models

that did not exist when the application was implemented.

6 Conclusion

We have presented MobileTSe, a flexible transaction

service framework for mobile environments which can

adapt according to the varying requirements and constraints

for mobile transaction execution. MobileTSe provides an

environment in which a limited number of transaction ser-

vices can be deployed, and from where a suitable transac-

tion service can be chosen for the execution of a transaction.

Transaction services external to the mobile unit is also

made available in MobilTSe through transaction servicediscovery. We have in this paper described how UPnP is

used for discovery and control of available transaction ser-

vices in the network.

MobileTSe uses information about the mobile environ-

ment and requirements from the application to choose an

appropriate transaction service. A qualified search for a

suitable transaction service in the the network can be per-

formed if the chosen set of transaction properties cannot be

met by any of the locally available services. If a transaction

service is found and accepted, transaction management is

transparently propagated to the chosen service.

A prototype of MobileTSe and a set of simple transac-

tion services for local deployment and external access willbe implemented to test the applicability of the proposed so-

lution and to further investigate the issue of remote transac-

tion service management.

References

[1] R. S. Barga and C. Pu. Reflection on a legacy transaction

processing monitor. In Proceedings of the Reflection 96

Conference, San Francisco, California, USA, April 1996.[2] G. S. Blair, G. Coulson, P. Robin, and M. Papathomas. An

architecture for next generation middleware. In Proceed-

ings of the IFIP International Conference on Distributed

Systems Platforms and Open Distributed Processing: Mid-

dleware98, The Lake District, UK, September 1998.[3] P. K. Chrysanthis and K. Ramamritham. Synthesis of ex-

tended transaction models using ACTA. ACM Trans. Data-base Syst., 19(3):450491, 1994.

[4] M. H. Dunham, A. Helal, and S. Balakrishnan. A mobile

transaction model that captures both the data and movement

behaviour. Mobile Networks and Applications, 2(2):149

162, 1997.[5] P. Grace, G. S. Blair, and S. Samuel. A reflective frame-

work for discovery and interaction in heterogeneous mobile

environments. SIGMOBILE Mob. Comput. Commun. Rev.,

9(1):214, 2005.[6] M. Jeronimo and J. Weast. UPnP Design by Example, A

Software Developers Guide to Universal Plug and Play. In-

tel Press, April 2003.[7] R. Karlsen. An adaptive transactional system - framework

and service synchronization. In LNCS 2888. SpringerVerlag, 2003.

[8] R. Karlsen and A. B. A. Jakobsen. Transaction service man-

agement an approach towards a reflective transaction ser-

vice. In 2nd International Workshop on Reflective and Adap-

tive Middleware, Rio de Janeiro, Brazil, June 2003.[9] E. Pitoura and B. K. Bhargava. Maintaining consistency of

data in mobile distributed environments. In Proceedings

of 15th International Conference on Distributed Comput-

ing Systems, pages 404413, Vancouver, British Columbia,

Canada, MayJune 1995.[10] M. Prochazka. Advanced transactions in enterprise java

beans. Lecture Notes in Computer Science 1999, 2000.[11] H. Ramampiaro and M. Nygard. CAGISTrans: providing

adaptable transactional support for cooperative work. InProceedings of the 6th INFORMS conference on Informa-

tion Systems and Technology (CIST2001). SpringerVerlag,

2001.[12] UPnP Forum. UPnP device architecture 1.0.1.

http://www.upnp.org, 2003.[13] G. D. Walborn and P. K. Chrysanthis. Supporting semantics-

based transaction processing in mobile database applica-

tions. In Proceedings of the 14th IEEE Symposium on Reli-

able Distributed Systems, pages 3140, September 1995.[14] Z. Wu. Reflective java and a reflective component-based

transaction architecture. In OOPSLA Workshop, 1998.[15] A. Zarras and V. Issarny. A framework for systematic syn-

thesis of transactional middleware. In Proceedings of Mid-

dleware98. IFIP. Chapman-Hall, September 1998.


550-445X/06 $20.00 2006IEEE

Flexible Transaction Processing in Mobile Enviornment

Documents

Transcript of Flexible Transaction Processing in Mobile Enviornment