Ijptt v8p404

International Journal of P2P Network Trends and Technology (IJPTT) – Volume 8 – May 2014

A Comparative Study on Java Mobile Clients with Data Caching in Accessing Information Systems P. Ravi Kiran#1 Y. K. Sundara Kirshna#2 #

Department of Computer Science, Krishna University, Machilipatnam, Andhra Pradesh, India

Abstract – Now-a-days ubiquitous, nomadic, and pervasive computing is not a longer vision but reality. Mobiles are using for voice communication, messaging, multimedia as well as clients for Information Systems (IS). Developing Mobile applications and services using MIDP are major challenges as these clients have limited computing and network resources. We present a comparative study on the two architectures of MIDP based Java mobile client in accessing Information Servers. (1) Implementation of mobile application for MIDP capable mobile phones that can handle data accessing with web services architecture as middleware. (2) MIDP based J2ME driver similar to JDBC embedded in our MIDP applications that directly communicating MySQL from mobile devices without middleware.

We also present efficient Data Caching Framework in Java mobile clients to minimize network traffic applicable for both the architectures and issues in accessing databases from them. We identified the problems in the MIDP based J2ME driver architecture and quoted the possibility of its improvement.

Keywords – Information Systems (IS), J2ME, Data Caching, MIDP, CLDC, Web Services, MySQL

I. INTRODUCTION AND MOTIVATION Mobile phones are far more ubiquitous when compared to PCs. From 2007 onwards the sales of smart phones exceeds the laptop computers. Mobile phone subscribers are more than 3.3 billion in the world. MIDP (Mobile Identification Device Profile) are dominantly using in designing mobile based applications for games, news, entertainment and many services. The mobile devices are working as clients for Information Servers in handling data access. As the mobile clients have limited computational and memory resources, needs a special architectures to lessen computation and memory requirements. Wireless connectivity is either slow, widely available (GSM, HSCSD, GPRS), or fast, less expensive but not accessible everywhere (WLAN, UMTS), data caching is necessary. In this paper we present a comparison between the two categories of architectures based on the middleware using, in accessing Information Systems (IS) which can utilize a common technique for data caching and issues relating to that. We also discussed the differences in the architectures and their limitations.

The remainder of this paper is described as follows. Section 2 briefly describes about the J2ME core concepts configuration, profiles and optional packages. Section 3 explains the web services architecture with middleware in accessing IS. Section 4 describes the architecture of the MIDP

ISSN: 2249-2615

driver which eliminates middleware. Section 5 includes the data caching strategies used in the both the architectures.

Section 6 discusses the differences and limitations between the architectures. Section 7 summarizes the study and concludes with the improvements in MIDP driver architecture.

II. J2ME CONCEPTS Mobile phone framework needs Java programming language known as Java Micro Edition (J2ME). Mobile phone applications can be used for data communications utilizing the standard protocols like HTTP/HTTPS or socket based communication [1]. These applications supports older GPRS technologies as well advanced technologies like UMTS (3G), EDGE and Wi-Fi [2]. The heart of J2ME consists of three core concepts: Configuration, Profiles and Optional Packages.

A.

Configuration

Configuration is a complete Java runtime environment that executes bytecode using Virtual Machine (VM), native code to interface to the underlying system. It provides a complete Java environment supplied by J2ME profiles. J2ME defines two configurations: the Connected limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). The devices with CLDC are in the 160k to 512k memory range and use Kilobyte Virtual Machine (KVM) [3]. The CLDC version 1.1 (JSR 139) mainly provides java.io package used for input and output through data streams and java.microedition.io for the generic framework. Object serialization and Java RMI (Remote Method Invocation) are not supported [7].

B.

Profile

A profile adds domain-specific classes to a configuration to fill in missing functionality and to support uses of a device.

There are several profiles in various stages of development.

The first profile to be released was the Mobile Identification Device Profile (MIDP), a CLDC based profile for running applications on cell phones and interactive pagers with small screens, wireless HTTP connectivity and limited memory. The most commonly used profile in mobile phones is MIDP 2.0 (JSR 118) is an enhancement for MIDP 1.0. Other profiles like foundation profile and personal profile extends with CDC are used in PDAs.

http://www.ijpttjournal.org

Page 17

International Journal of P2P Network Trends and Technology (IJPTT) – Volume 8 – May 2014 C.

Optional Packages An optional package is a set of APIs in support of additional, common behaviors that don’t really belong in one specific configuration or profile. Optional packages also have specific dependencies on a particular configuration and/or one or more profiles; they do not define a complete runtime environment, just sets of related APIs. Many optional packages define additional features like encryption, content handling, Bluetooth access and more.

III. USING MIDDLEWARE In the following we briefly present how MIDP capable mobile clients can access Information system server or Websites via web-services as Middleware. Figure 1 shows the Java Mobile client accessing Information server/Website via web services as middleware. We also introduced the Record Management Store (RMS) for data caching. Web services are accessed by Mobile clients using the standard JSR 172: Java Web Services Specification. The specification provides two new capabilities to the J2ME platform: (a) access to remote SOAP/XML based web services and (b) parsing XML data. In addition to the Web services we use Hotsync and SyncML as the additional middleware which helps in making the websites accessing by MIDP based mobile clients.

Web services involve bundling of XML documents.

However, saving XML data on a mobile phone is not feasible due to the limited amount of storage. A pragmatic method is used to map the XML data record to RMS within the mobile keeping an efficient index structure.

IV. WITHOUT USING MIDDLEWARE In previous, we had seen the mobile client with a web service as a middleware to access information server. Now here we present how a MIDP based mobile client can access the Information server without a middleware. Figure 2 represents a MIDP based J2ME driver similar to JDBC driver that allows direct communication of Java mobile clients to Information servers without a middleware. We consider the Information server as MySQL database only as it has the capability of accessing by the remote machines.

Figure 2: Mobile Client without Middleware Technology

Figure 1: Mobile Client with Middleware Technology

The method applied in Web services is like the synchronous request-response model of client-server interaction. A mobile client invokes a request to a remote web service. The web service processes the request and sends back the queried results. The results are received by the mobile client and represents in a form. With the help of JSR 172 stub and runtime the encoding of the method and arguments, serialization, decoding, de-serialization, sending request and receiving response and keeping all these transparent to the application can be handled.

The implementation of this specification is lacking in some mobile devices. Such mobile clients use a method for accessing a web service by sending SOAP messages and parsing the replies. This method is obsolete and is prone to XML processing errors.

ISSN: 2249-2615

We also set ourselves some goals in developing this architecture: (1) Keep the driver API as near to the JDBC specification as possible. (2) Keep the .jar file size below 32kB – half the popular 64kB limit – to leave enough space for the application. (3) Implement required features only. (4) Keep the implementation code as simple as performant as possible.

This development had reached the goals set by us and also using the same caching by Record Management Store (RMS).

Figure 3 shows the class diagram of the J2ME driver. The J2MEdriver consists of 3 major classes which are functioning almost similar to JDBC driver classes. 5 minor classes are helpful in fulfilling the functionality of the driver. The three major classes: (1) the Connection class provides the methods like opening and closing a connection and changing the database. It also owns the instance of MysqlIO. (2) The Statement class provides method execute the database queries and fetch results. It implements packet sequence logic by relying on MysqlIO class hold by the Connection class. (3) The ResultSet class provides the row-pointer based access methods. It uses an array of Field class instances to store and process all column specific data. The ResultSet class is a Façade to the Field class.

http://www.ijpttjournal.org

Page 18

International Journal of P2P Network Trends and Technology (IJPTT) – Volume 8 – May 2014 B. Replacement

Cache can use only limited storage memory. In this memory the software has to decide which cached data has to be replaced when new received data has to load in record store.

This usually happens when the cache memory is full. It uses many replacement approaches, among them FIFO replacement strategy is implemented.

The controlling of cache replacement strategy is done by two simple steps. First, the cache manager identifies the obsolete cache entries and returns them in the order to be deleted. Second, the identified cache entry is removed and the new cache entry is added to the Record Store.

Figure 3: J2ME Driver Class overview

C. Lookup The remaining minor classes: (4) The buffer class is responsible for encoding and decoding packet fields as well as for the conversion between MySQL and Java data types. (5) the MysqlIO class handles the communication with the database server. It uses two Buffer class instances, one for sending and another for receiving. (6) The Query class provides basic functionality for parameterized queries. (7) The OkResultSet class is an simple query information storage and is not directly available to the application developer but must be accessed through methods provided by the Statement class.

(8) The Field class provides column wise storage for database result set and Meta data. ResultSet class uses it internally.

V. DATA CACHING Data Caching is a common approach for reusing and sorting stored data in order to reduce volumes of data transferred from database perspective caching means, creating redundant data that needs to be maintained by the Java mobile clients. The cached data is kept in MIDP’s Record Management Store (RMS). RMS is a nonvolatile collection of records of binary data. The serialized set of records is written to a record store.

Data caching both in middleware technology and without middleware technology needs to consider the following major issues: A. Coherency The caching software has to guarantee that the stored data is up to date. We apply caching every time when a query which is not cached is executing. We also decided to reuse a special attribute that specifies how long a data item is valid. If the data expires the item is removed from the cache and re-requested with the next query.

ISSN: 2249-2615

Before a statement is executed, the driver scans through the cache index to check, whether the statement is already cached or not. This is done by the cache handler in tracking the result sets and retrieving them as required. The workflow of the caching strategy is shown in the figure 4.

VI. DIFFERENCES AND LIMITATIONS Java mobile clients can use web services or J2ME driver in accessing Information Servers. The major difference is that web services act as middleware but while we use J2ME driver, no middleware. The MIDP mobile clients can access only MySQL database but cannot have middleware in parsing Website content accessed by mobile clients. Another difference is that Information Server database is restricted to MySQL while we use J2ME driver. The driver cannot be efficiently used for all kind of applications due to the limitations as stated below.

For the MIDP client accessing MySQL server with J2ME driver without using middleware has the following limitations: (1) The J2ME driver do not support for pre MySQL 4.1 server which increases the coding in turn the size of .jar file. (2) The diver is also not supporting for prepared statements which increases the complexity of the driver. (3) It has very limited data type support as it has not supporting prepared statements we restricted for data types like character strings, signed integers, floating-point numbers and timestamps. (4) The character information is based on the Unicode standard version 3.0, as the CLDC specification by default the character property and case conversion done in ISO Latin-1 range of characters only. Limited character support leads the driver small and fast. (5) Transaction handling needs very large amount of code to use the commands like START TRANSCTION, ROLLBACK and COMMIT are not implemented in our driver. (6) No analysis for Meta data and

http://www.ijpttjournal.org

Page 19

International Journal of P2P Network Trends and Technology (IJPTT) – Volume 8 – May 2014 no support for parallel processing. (7) Limited features are implemented in error handling and SQL support.

REFERENCES [1]

[2]

[3] [4] [5] [6] [7]

[8]

[9[ [10]

[11]

[12]

[13]

[14] [15]

Kozel, T., & Slaby, A. (2008, June). Mobile access into information systems. Paper presented at the 30th International Conference on Information Technology Interfaces, Cavtat/Dubrovnik, Croatia.

Knyziak, T., & Winiecki, W. (2003, Sept.). The new prospects of distributed measurement systems using Java™ 2 Micro Edition mobile phone. Paper presented at the Proceedings of the Second IEEE International Workshop on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications, Lviv, Ukraine.

Helal, S. (2002). Pervasive Java. Pervasive computing, 1(1), 82 - 85.

Sun Microsystems. (2009). Connected limited device confi guration (CLDC). from http://java.sun.com/products/cldc/ Sun Microsystems. (2009). Mobile Information Device Profi le (MIDP). from http://java.sun.com/products/midp/ Sun Microsystems. (2009). Sun Java wireless toolkit for CLDC. from http://java.sun.com/products/sjwtoolkit/ Mock, M., & Couturier, S. (2005). Middleware - integration of small devices. Paper presented at the Proceedings of the 10th IEEE Conference on Emerging Technologies and Factory Automation.

Hagen H¨opfner and J¨org Schad and Sebastian Wendland and Essam Mansour MIDP: An JDBC driver for accessing MySQL from mobile devices A. Caracas¸, I. Ion, M. Ion, and H. H¨opfner. Towards Javabased Data Caching for Mobile Information System Clients.

H. H¨opfner, J. Schad, S. Wendland, and E. Mansour. MIDP and MIDP-Client: Direct Access to MySQL Databases from Cell Phones, Mar. 2009. BTW-DEMO. I. Ion, A. Caracas¸, and H. H¨opfner. MTrainSchedule: Combining Web Services and Data Caching on Mobile Devices. Datenbank-Spektrum, 21:51–53, May 2007.

MySQL AB. MySQL Internals ClientServer Protocol, 2008. Retrieved on January 18, 2008 from http://forge.mysql.com/wiki/MySQLInternalsClientServerProtocol.

Ali Kattan, Rosni Abdullah, Rosalina Abdul Salam and Sureswaran Ramedas: Building Distributed Heterogeneous Smart Phone Java applications an Evaluation from a Development Perspective, Journal of ICT, 8, pp: 67-83.

Alexandru Caracas, Iulia Ion, Mihaela Ion: Web Services and Data Caching for Java Mobile Clients, 2007.

Want, R. (2009). When cell phones become computers. Pervasive computing,IEEE, 8(2), 2-5.

Figure 4: Cache framework general workflow

VII. CONCLUSIONS AND DISCUSSION In this paper we presented a comparative study on the two different architectures for Java mobile clients in accessing Information Systems. Handling data access with web services are prominently using in majority, where as the J2ME driver is also very successful, but due to limitations and accessibility with MySQL databases only they are not implementing everywhere. To improve the significance of J2ME driver for accessing through MIDP based mobile clients, they need high computational capacity and more memory resources which reduce the limitations.

ISSN: 2249-2615

http://www.ijpttjournal.org

Page 20