mBOSSS+: A Mobile Web Services Framework - IEEE Computer Society

0 downloads 0 Views 416KB Size Report
mobile devices by evaluating the mobile learning application. Keywords - mobile ... contributions: (a) we propose a web services mobile training framework for ... frameworks implement lightweight SOAP server architectures for Java2 Micro Edition ..... IBM WebSphere Everyplace Micro Environment that supports. Connected ...
2010 IEEE Asia-Pacific Services Computing Conference

mBOSSS+: A Mobile Web Services Framework Jingyu Zhang, David Levy

Shiping Chen, John Zic

School of Electrical and Information Engineering The University of Sydney NSW, 2006 Australia {jyzhang, dlevy}@ee.usyd.edu.au

Information Engineering Laboratory CSIRO ICT Centre PO Box 76 NSW 1710, Australia {shiping.chen, john.zic}@csiro.au

Abstract—Web services have been widely accepted as a platformindependent services-oriented technology. On the other hand, ubiquitous technologies are getting popular in a variety of domain applications. In particular, hosting web services from mobile devices became a way of extending knowledge sharing for teaching and learning purposes. This paper presents our design and implementation of a mobile web services framework for syndromic surveillance diagnosis and learning. This framework can assist farmers and veterinary students to study surveillance and diagnosis of farm animal diseases in the field. In this paper, we also present a performance study of hosting web services on mobile devices by evaluating the mobile learning application.

to a large database of symptoms and diseases to identify the potential cause of the disease and to guide further investigation. The method, ease of use and convenience of data capture are key aspects that will determine the success and quality of the system. However, when the database is too big to be hosted in single mobile devices, the data must be stored on multiple mobile devices to be shared across multiple farmers and veterinary students. Therefore, since mBOSSS cannot share and retrieve information in real time from other peers, the performance of learning and the capacity of data source limit mBOSSS from providing a complete syndromic surveillance service on mobile devices.

Keywords - mobile information sharing; in field learning; mobile web service; soap attachment; mobile web service performance

Web services technologies have been widely accepted as a platform-independent solution to interoperability of mobile applications. A mobile application using web services is an approach for mobile learners in the above special learning scenario. But, this scenario brings up many additional challenges arising from the specific environment, in which the information must be complete and the tool must be able to respond rapidly to users’ queries with accurate results.

I.

INTRODUCTION

Since mobile devices have become so popular in our lives, the demand for mobility is extending beyond traditional telecommunications. For example, the email service and web browsing are widely running on handheld devices. As mobile devices become increasingly powerful, “move to mobile” is one of the central themes in the services domain. Therefore, mobile devices have become the pervasive interface to web and cloud computing applications [1-2].

There are a few middleware packages available for mobile web services [5][7-10]. Most of them only provide simple text SOAP message. In our in-field learning application, we need to provide a vivid training scenario to users. The use of video and audio on the web is now an integrated and established area in learning. Sharing multimedia in a learning environment is well accepted by all participants for the purpose of clearer presentations and discussions [6]. Multimedia content normally is much large than text content. From our studies, whether it is feasible to use handheld terminals to send/receive multimedia information as Soap attachments and what are the performance results have investigated in neither web services nor mobile computing community.

In [3] and [4], we presented a mobile epidemiological surveillance learning system for on-field training of emerging infectious disease. However, this user-case scenario brings many additional challenges arising from the environmental conditions in which there is no the Internet access and the data is shared and synchronized in field. For a mobile-based collaborative application, the low bandwidth, intermittent network connectivity and scarcity of resources are major issues in mobile data sharing. Therefore, using a mobile interoperable architecture is important for system design, because it has a direct impact on the software’s availability, usability and performance.

In this paper, we address the above challenges by developing a mobile web services framework for data sharing, which allows an embedded device to cooperate and synchronize with other peers for on-field training and diagnosis of farm animal diseases. Particularly, we make the following contributions: (a) we propose a web services mobile training framework for syndromic surveillance and diagnosis; (b) we developed a web services middleware for mobile computing application that each mobile terminal works as both a Mobile Host and Mobile Service Requestor; (c) we demonstrate and evaluate the feasibility and performance of our mobile middleware using real mobile phones.

The mobile Bovine Syndromic Surveillance System (mBOSSS) in [3] and [4] is a stand-alone application that is being developed to support the existing surveillance system within remote northern pastoral regions of Australia. The project aims to study the observation methods of diseased livestock from users (not necessarily veterinarians) in the farm industry. With mBOSSS, the users describe the signs of disease that they observe and these reported syndromes are compared 978-0-7695-4305-5/10 $25.00 © 2010 IEEE DOI 10.1109/APSCC.2010.95

91

II.

section, we focus on our attention on the integration of Mobile Host and Mobile Requestors.

RELATED WORKS

Since mobile-learning is relatively new, very little work has been done so far in the m-learning domain with hosting web services on small resource constrained devices. Chatti et al. [7] present a smart phone driven mobile web services architecture for collaborative learning. [7] emphasis on the importance of collaboration, and knowledge for learning described the integration of mobile and ubiquitous technologies to enhance collaborative learning activities and present the details of smart phone sent text-based Soap messages as an approach for mobile learning. There exist some works on enabling web services on mobiles [8]. Asif et al. [7-8] propose a lightweight web service engine, which includes an HTTP listener, a SOAP engine, and a security subsystem for providing web services on handheld devices. Srirama et al. [9-10] propose a Mobile Web Service Mediation Framework (MWSMF) for the efficient provision of web services in a mobile P2P network. They used a binary compression technology (BinXML) for efficient communication. Kim and Lee in [11], Pham and Gehlen in [12] proposed two web service platforms for mobile devices respectively. The two frameworks contain several built-in functionalities such as the processing of SOAP messages, the execution and migration of services and the management of context. The two frameworks implement lightweight SOAP server architectures for Java2 Micro Edition (J2ME) devices. The implementations of web services parts for mobile devices are based on the open source packages kSOAP for the client function (http://ksoap2.sourceforge.net/) and kXML for the xml parser (http://kxml.sourceforge.net/).

Figure 1.

A detailed description of the mBOSSS framework is presented in Figure 2. This architecture has been designed to support other types of applications that require large data sets to be stored and used on a handheld device, with wireless connectivity and with different display and user interface capabilities. The architecture consists of five separate layers: an Input/Output tier, a Core Procedure Management tier, a Data Access tier, a Data Storage tier, and a mobile Soap Engine.

To the best of our knowledge, all of the previous works on hosting web services on resource constrained handheld devices are still in an early stage. They study the feasibility of hosting Web services functions on handheld devices. However, there is less work on the scalability and performance evaluation of attached multimedia information with SOAP message for mobile web services. III.

Web Service Architecture in Pervasive Environment

The Input/Output tier aggregates methods by which users interact with the application. There is a user interface, a communications interface with the operating system, and tools to connect with the network and other software. The user interface is an extremely important aspect of the mobile database application because there are no existing displayscreen standards for mobile phones and other hand-held devices. While input methods are fairly standard (keypad, touch screen, and voice), the dimensions of the display-screen vary greatly.

SYSTEM OVERVIEW

In this section, we outline our mobile web service learning framework and provide an in-depth description of the diagnosis classifier engine and the mBOSSS attachment structures.

The Core Management tier encapsulates the core business model which provides the basis for all business transactions of the application. All syndromic surveillance and diagnosis cases are generated by the Case Generator. We apply a Naïve Bayes classifier in an Artificial Intelligence Engine. The algorithm is described in the next section. This tier determines the behavior of the application in response to different situations, including workflows and operating procedures. It generally includes the most complex components of the implementation.

A. Mobile Application Structure An overview of the mBOSSS architecture is presented in Figure 1. In this architecture, each handheld device publishes a WSDL description on a Service Broker. The Web Service Description Language (WSDL) describes the public interface to the Web Service. A mobile client in this network finds request service(s) from the Service Broker. Then the mobile client retrieves the WSDL file to determine what operations are available on the Mobile Host. The mobile client use SOAP via HTTP to call one of the operations listed in the WSDL. [11] and [12] propose a way to make a mobile Service Broker, thus we assume there is a Service Broker that provides published WSDL to Mobile Requestors. Therefore, in this

The Data Access tier provides a Data Access Interface (DAI), and a Data Centre (DC). The DAI provides a command interface to the database and isolates database operations (such as data retrieval) from data queries. This isolation allows the database structure to be adapted and modified independently of the data query functionality.

92

m B O S S S U s e r In te rfa c e S p e c ia l U I

C om m on U I

m B O S S S C o re M a n a g e r C a s e s G e n e ra to r A r tif ic ia l I n te llig e n c e E n g in e

m B O S S S D a ta A c c e s s D A I D a ta C a c h e

m B O S S S S O A P E n g in e

m B O S S S S to ra g e

M essag e M ap per D a ta b a s e

M C D (H B -n A rry T re e )

S O A P P a rse r

S O A P W ra p p er

S O A P D ecoder

SO A P E ncoder

S O A P R e c e iv e r

SO A P Sender

S O A P M e s s a g e H a n d le r

J2M E T h e P e rs o n a l P ro file T h e p e r s o n a l B a s is P r o f ile

O S K e rn e l K eypad D r iv e r

W iF i D r iv e r

F la s h M e m o r y D riv e r

Figure 2.

D is p la y D riv e r

Pow er M anagem ent

mBOSSS Framework

In other words, the DAI translates user requests into acceptable database commands. The DC is a mobile data cache with limited memory (in our system the available memory was restricted to 5 MB). The DC provides the standard services required of a data cache and parts of database interface functions: database authentication, query parsing, assembly of the search response.

whose structure is based on the sequence of binary digits. The nodes of the N-ary search tree are then mapped to folders, where each folder corresponds to one particular search key value. The files inside each folder contain the table entries matching the search key value that has been mapped to that specific folder. Suppose now that we have two database search keys. In this case, we proceed as before for the first search key, only this time inside each folder is another set of folders that has been mapped to single-attribute search tree for the second search key and so on. In this way, we construct a multiattribute N-ary search tree for a particular database query. The holey-brick nature of the multi-attribute N-ary search tree simply indicates that we can store pointers to data folders instead of the folders themselves. The pointers correspond to holes in the search tree and may be used to span multiple SD memory cards.

An Embedded Database and a Memory Card Database comprise the mBOSSS Storage system. The commercial Embedded Database can be used here for providing data query. The MCD stores the tables of the database as a system of folders and files on a SD memory card. The folders and files are arranged according to a holey-brick-N-ary (HB-Nary) search tree [13]. Consider first a single-attribute N-ary search tree. The data values of a single, specified database search key are coded as binary words. These binary words are then arranged according to a single-attribute N-ary search tree

93

The MCD stores the database tables in a redundant format because there is one HB-Nary search tree for each specified data query. The essential feature of the MCD, however, is that it guarantees that the data files (table entries) inside each folder can be entirely loaded into the memory space of the DC. In other words, we have subdivided the tables of the database such that portions of it can be loaded into memory and treated as an in-memory relational database by the DC.

dynamically show the diagnoses and treat individual cases of disease. C. mBOSSS message Attachment The use of multimedia in mobile learning provides a large scope for the purpose of clearer presentations and discussions. With multimedia content, complex stories can be described with a single image or a short video. [14] describes SOAP attachment as a feature. However, the SOAP attachment specification did not include in the SOAP Messaging Framework [15] and J2ME Web Services Specification JSR172 [16].

The mBOSSS SOAP Engine consists of eight parts. The function of the Message Handler is to transfer request messages to the SOAP Receiver and transfer SOAP messages from the SOAP Sender. The Hypertext Transfer Protocol is used as a protocol for transfer messages. Messages come to the SOAP Receiver, the SOAP Decoder, and the SOAP Parser and are then converted by the Message Mapper, which is responsible for transforming SOAP content to objects which mBOSSS can understand. B. Diagnostic Function with Naïve Bayes Classifiers We apply a Naïve Bayes classifier to assess training processes for learners of diagnostic and examination techniques of farm animals. Bayes’ rule of conditional probabilities says that if you have a hypothesis, for example a disease D , with a prior probability P ( D ) , and evidence, in our example a sign S with prior probability P ( S ) , then the conditional probability of D given S is

P( S | D) P( D) P ( S | D ) P ( D ) + P ( S | ¬D ) P (¬D ) S = sign and D = disease P( D | S ) =

Figure 3.

Attachment feature properties

Figure 3 presents SOAP attachment feature properties use in the mobile framework. mBOSSS’s request messages are transferred in an HTTP POST request. The response messages are transferred in an HTTP Response message. In figure 3, the message type is “text/xml” which is used for the messages containing the SOAP envelope only. In mBOSSS requests that carry a SOAP attachment. The Content-Type is “multipart/related”. The SOAP envelope is located in the first part of the Multipurpose Internet Mail Extensions (MIME) message along with the mBOSSS attachments. mBOSSS attachments are indicated by the Start parameter of the multipart/related Content-Type. If an mBOSSS attachment is included, it is encoded as a MIME part and is the second part of the HTTP Post message. The MIME part should have the appropriate content type(s) to identify the payload. This MIME part shall have two MIME headers - Content-Type and Content-ID fields. The Content-ID shall be referenced by the mBOSSS request.

The above formulation reduces the problem of diagnosing a disease based on observed signs to fully observable probabilities: (a) the probability of the sign S given that disease D is present ( P ( S | D ) ). (b) the probability of disease D within the population ( P ( D ) ). (c) the probability that sign S is present given that disease D is not present ( P ( S | D ) ), and (d) the probability that disease D is not present within the population ( P ( D ) ). The probabilities for P ( D | S ) and P ( D | S ) are stored as a relational table. Its three columns are named DiseaseNo, SignNo, and Prob. DiseaseNo identifies the disease from the disease table, SignNo is the unique ID of a particular sign, and Prob is the prior probability of the disease, initialized as the prevalence of the disease from the disease table.

IV.

PERFORMANCE EVALUATION

We performed a series of experiments to assess the performance of our web service engine in this mobile elearning application scenario. Performance is quite important to mobility software because the hardware cannot easily be updated and the capability of handheld hardware is normally lower than that of a PC due to the size and weight requirements for the device. In our evaluation, the response time is measured as the performance metric between the times when the client

In our diagnosis application, we employ a cattle diseases database as sample data. This dataset of conditional probabilities contains approximately two millions probability estimates, a combination of nearly 3,000 diseases and 2,000 signs. The table contains an average of 253 signs for each disease. The probability values are the result of complex calculations. Once the values are computed, the system can

94

mobile sends a request and the time when the client mobile receives the corresponding response.

increase to 20-80 times for Medium and Complex messages. We compare the average sizes of the SOAP messages used in our performance tests in Figure 5.

A. Case Selection A mobile client select four symptoms randomly from 3000 cases send to a mobile device for disease diagnosis processes. After diagnosis, three types of Messages (SimpleMessage, MediumMessage, ComplexMessage) were designed to reflect common data structures used in our applications in terms of data size and complexity as follows:

80000 Average Message Size (byte)



90000

Simple message, four most possible diseases along with their descriptions without multimedia attachments for those provided symptoms.



Medium message consists of four most possible diseases along with their descriptions and a 320X240 pix picture to image the most possible diseases.



Complex message, four top possible diseases with their descriptions combined with four 320X240 pix disease pictures.

70000 60000 50000 40000 30000 20000 10000 0 Simple

B. Benchmark We applied the cattle diseases database retrieved from the Australian Biosecurity Collaborative Research Centre (ABCRC) as our benchmark dataset. We used a request/reply-style RPC model as our test scenario, which consists of a client and a mobile web service. The client sends the web service a request with a list of animal disease symptoms. We design the request to contain information required for a test with the symptoms random selected from our dataset that contain more than 3000 symptoms. The web service receives the request and replies by sending back a specific diagnosis with/without applying multimedia attachments according to the information in the request.

Medium Message Type

Complex

Figure 4.

Differences in size among message types

Figure 5.

Response time for the three message types

Figure 5 shows the time spent in the three activities (business logic, web service processing and message transfer) on the mobile web service for the three types of messages. The business logic time includes the local processing time spent in searching animal diseases and presenting the contents to the observers in the AIE (Artificial Intelligence Engine); the Service Provider processing time is the time spent in preparing the SOAP responses according to the difference message size and message type; and the Service Requester is the time spent in processing SOAP requests, which includes the time of messages transmission over a wireless network.

C. Test Environment and Settings We conducted the performance tests in the following order. Both our web service and its client are developed using Java Platform, Micro Edition (J2ME). The web service is deployed and runs on a HTC 9500 mobile phone, which is running on IBM WebSphere Everyplace Micro Environment that supports Connected Device Configuration (CDC1.1). The web service client runs on a J2ME (CDC1.1) simulator via a 108.11g battery-powered wireless router. To ensure valid and accurate measurements, we ran each test multiple times and each test runs for ten hours to guarantee consistent and stable testing results. We also set 10% of testing time at the beginning and end of each test as warm-up and cool-down periods whose testing results are not taken into account, to reduce the effect of unstable measurements during these periods. We also waited half a second between messages.

According to the test results shown in Figure 5, the average response times for the three message types is that shortest for simple SOAP messages and increased as expected for more complex messages, with the multimedia based SOAP messages taking the longest. The business logic activity costs most of time, as it goes through the AIE and tge data retrieval process. The trends of increasing time and message size are described in Figure 6.

D. Testing and Observations Figure 4 shows the average size of Simple, Medium and Complex messages. The Simple messages include the text only, whose average message size is 1,280 Byte. However, once combined with multimedia data, the sizes dramatically

As the size of the message increases, the time difference among Diagnosis time, Service Provider processing time, and Service Requester processing time are shown in figure 6. From this experiment, it can be concluded that all times affected by the size of the diagnosis message, but the increase in response

95

time is much lower than the increase in message size. For instance, the service provider size increases 68.7 times, but the service provider processing time increases by 6.6%. From our observation, 84%-87% of the time cost is in the business logic. Thus, the trend of total processing time does not increase as quickly as the message sizes grow.

Besides a detailed description of our framework, we built a solid foundation for a mobile learning application that uses this framework to investigate and report cattle disease in the field and is designed to deliver benefits to cattle producers, government surveillance systems and to the cattle industry. Experimental evaluation on our real-world workload shows our framework has negligible overhead for transfer multimedia study materials of in wireless environment.

145 140

Time(msec)

ACKNOWLEDGMENT

Service Requester

135

Service Provider Diagnosis

130

This work is funded by Australian Biosecurity Collaborative Research Centre (CRC Grant No. 3.015Re).

125

REFERENCES

120

[1]

115 110 0

10000

20000

30000

40000

50000

60000

70000

80000

[2]

90000

Message Size(byte)

Figure 6. Response Time vs. Message Size in different stages [3] 21

[4]

Percentage of Increment(%)

19 17

[5]

15 13 11

[6]

9 7

[7]

5 Medium

Simple

Complex

[8]

Message Type

Figure 7.

Percentage of increment

[9]

The percentage of increment of response time between stand-alone mBOSSS and mBOSSS with Web Services feature is shown in figure 7. Hosting Web Services in mBOSSS results in slightly time delays compared to the stand-alone version. The increases are between 15% and 19% and the values of delay are 17.42ms, 18.24ms, and 21.56ms. This indicates that using web services attachments to multimedia messages in mBOSSS is unlikely to have a big impact on the system performance. V.

[10]

[11]

[12]

CONCLUSION

[13]

In this paper, we present the design and implementation of a mobile middleware that facilitates mobile web services in a distributed mobile computing environment. This work contributes to Web Services on mobile learning scenario that allows users to transfer SOAP messages with multimedia information as SOAP attachments to handheld devices. This framework consists of five core components, Soap Engine, Storage model, Data Access tier, Core Manager, and mBOSSS User Interface.

[14] [15] [16]

96

T. Berners-Lee. (2009, 6 May). Twenty Years: Looking Forward, Looking Back. Available: http://www.w3.org/2009/Talks/0422www2009-tbl/#(3) I. Giurgiu, et al., "Calling the cloud: enabling mobile phones as interfaces to cloud applications," presented at the Proceedings of the 10th ACM/IFIP/USENIX International Conference on Middleware, Urbanna, Illinois, 2009, pp. 83-102. J. Zhang, et al., "A Framework for Mobile Disease Report and Investigation," presented at The International Conference on Mobile Technology Applications and Systems, ACM, 2006, pp 33-38. J. Zhang, et al., "A Mobile Learning System For Syndromic Surveillance And Diagnosis," presented at the The 10th IEEE International Conference on Advanced Learning Technologies, Tunisia, 2010. M. A. Chatti, et al., "Mobile Web Services for Collaborative Learning," presented at the Proceedings of the Fourth IEEE International Workshop on Wireless, Mobile and Ubiquitous Technology in Education, 2006, pp 129-133. S. Pobiner, "Collaborative Multimedia Learning Environments," presented at the Conference on Human Factors in Computing Systems Québec, Canada 2006, pp 1235-1240. M. Asif, et al., "Hosting Web Services on Resource Constrained Devices," presented at the ICWS 2007. IEEE International Conference on Web Services, Salt Lake City, UT, 2007, pp. 583-590. M. Asif, et al., "Partitioning the WS Execution Environment for Hosting Mobile Web Services," presented at the IEEE International Conference on Computing Honolulu, Hawaii, USA, 2008, pp. 315-322. S. N. Srirama, et al., "Scalable Mobile Web Service Discovery in Peer to Peer Networks," presented at the Proceedings of the 2008 Third International Conference on Internet and Web Applications and Services, 2008, pp. 668-674. S. N. Srirama, et al., "MWSMF: a mediation framework realizing scalable mobile web service provisioning," presented at the Proceedings of the 1st international conference on MOBILe Wireless MiddleWARE, Operating Systems, and Applications, Innsbruck, Austria, 2007, pp. 1-7. Y.-S. Kim and K.-H. Lee, "A lightweight framework for mobile web services " Computer Science - Research and Development, vol. 24, pp. 199-209, 2009. L. Pham and G. Gehlen, "Realization and Performance Analysis of a SOAP Server for Mobile Devices," presented at the 11th European Wireless Conference, Nicosia, Cyprus, 2005, pp. 791-797. J. ZHANG, "A Mobile Surveillance Framework for Animal Epidemiology," Master by Research, The University of Sydney, 2008. W3C, "SOAP 1.2 Attachment Feature," ed. http://www.w3.org/TR/soap12-af/: W3C, 2004. W3C, "SOAP Version 1.2," ed. http://www.w3.org/TR/soap12-part1/: W3C, 2007. J. C. Process, "JSR 172: J2METM Web Services Specification," ed. http://jcp.org/en/jsr/detail?id=172: Java Community Process, 2004.

Suggest Documents