mframe: an application framework for mobile resource...

Journal of Computing and Information Technology - CIT 17, 2009, 2, 123–140doi:10.2498/cit.1000964

123

mFrame: An Application Frameworkfor Mobile Resource-constrainedComputing Environments

Hinko Vincar1, Hossein Saiedian2 and Serhiy Morozov2

1United Nations, Cologne, Germany2University of Kansas, Lawrence, USA

The component and architectural design reuse valueof application frameworks enables higher productivity,faster turn-around time, and reduced cost when comparedwith the traditional development approaches. Because ofthe constrained nature of mobile devices, the applicationframeworks for such a computing environment have toprovide a simple and lightweight implementation whilestill maintaining their flexibility and reusability value.This paper presents mobile Framework (mFrame) ap-plication framework that can be used for deployingsoftware applications to compact mobile devices such ascellular phones, personal digital assistants (PDA), globalpositioning systems (GPS) etc. It introduces a queuingand service layer architecture that provides simple dataexchange mechanism between the presentation compo-nents and local and remote business services. Compactmobile devices using this architecture will be able tohandle network disconnections, because the requests willbe saved; and information will be exchanged with theremote services upon reconnection.

Keywords: mFrame, application framework, mobilecomputing, resource-constrained

1. Mobile Resource-constrained Devices

1.1. Introduction

The market for compact mobile devices like cel-lular phones, personal digital assistants (PDA),and global positioning systems is growing ra-pidly. With the advent of third generation mo-bile networks (3G), and other improvements inhardware design, these devices are becomingmore suitable as a platform for application de-velopment. However, because of inconsistentdesign guidelines and lack of agreed upon spec-ification, reusability and modifiability quality

attributes are usually not considered during de-velopment of mobile applications.

When applied to mobile resource-constraineddevices, application frameworks can simplifythe application development. An applicationframework is a semi-finished application wherecore parts are already implemented and are inplace. An application developer who uses theapplication framework provides the other partsand completes the application. The componentand architectural design reuse value of applica-tion frameworks can enable higher productivity,rapid development and reduction in overall de-velopment cost.

1.2. Problem Definition

Development environment for compact mobiledevices has tight memory constraints and re-quires very careful and controlled allocationand de-allocation of memory. The reliabilityof mobile networks is very diverse and unpre-dictable. The networks are characterized byhigh latency, low bandwidth and interruptedconnections. Since information can be de-layed or lost over wireless links, mobile ap-plications must be able to tolerate some delaysthat can have a major impact on user’s percep-tion of an application’s performance (Varshney2002). An application framework for such aresource-constrained environment has to enablesimple and lightweight implementation, whilestill maintaining its flexibility and reusabilityvalue.

124 mFrame: An Application Framework for Mobile Resource-constrained Computing Environments

This paper presents the design, implementationand usage of mFrame (mobile Framework)application framework for deploying softwareapplications to compact mobile devices suchas cellular phones, personal digital assistants(PDA), global positioning systems (GPS) etc.The proposed application framework introducesa queuing and service layer architecture thatprovides simple data exchange mechanism be-tween the presentation components and localand remote business services. Compact mobiledevices using this architecture will be able tohandle network disconnections, because the re-quests will be saved; and information will beexchanged with the remote services upon re-connection.

Multiple related research efforts focus on main-taining a reliable connection and data transferduring mobile handoffs. In fact, the majority ofpublishedmaterial in this area is concerned withimproving the shortcomings introduced by thewireless links at lower OSI layers. One of theearliest successful solutions to this problem isdiscussed in “Improving reliable transport andhandoff performance in cellular wireless net-works”. The authors of this article were ableto improve the throughput performance by 20times and decrease the handoff latency by 10times (Balakrishnan, Seshan, & Katz 1995).Similarly, Ludwig, Konrad, and Joseph focusedon the link layer performance. The authors wereable to achieve a 25% improvement in networkthroughput that was capable of resuming dataexchange after minutes, hours and even days oflink unavailability (Ludwig, Konrad, & Joseph1999). A similar disconnection solution couldalso be done at a data level. Bayou is an infras-tructure designed specifically for collaborativeapplications. It is capable of maintaining itsdatabase integrity across multiple users that areloosely connected at any given time. Bayou isespecially well suited for mobile users, whosenetwork connections are often slow and unreli-able (Edwards et al. 1997). An alternative datalevel framework, called IBM Fluid Middleware,supports building applications that are not con-cerned with network connectivity, replication ofdata or concurrency. Unlike the client-serverBayou architecture, this framework adopts apeer-to-peer approach. Peers are allowed tocommunicate in real time as long as connectionexists and with small latency otherwise. IBMFluid Middleware is also based on a Model-

View-Controller pattern with special focus onconflict resolution and synchronization issues(Bourges-Waldegg, Duponchel, Graf & Moser2005).

A great number of existing solutionswith demon-strated results, while very impressive, do notguarantee that a mobile application built on topof such transport protocols is able to gracefullyhandle the loss of connectivity. This researchis focused specifically on this issue. When theconnection is absent, the application should beaware of it, yet remain functional. All user ac-tions are captured and transmitted into the net-work as soon as a connection becomes available.The mFrame architecture reduces the user’s de-pendency on the connection availability. Themain contribution of this paper is not to replacethe existing reliable data exchange solutions butto implement them at a different level. Appli-cation level implementations are abstracted byother network levels and should be much easierto implement. Additionally, mFrame is per-fectly suited for working in parallel with lowerlevel solutions, thus further improving the reli-ability of mobile communication.

2. Related Works

Following is a brief description of applicationframeworks that address problems similar tothose addressed by the proposedmFrame frame-work.

2.1. Struts

Struts is a server-side application frameworkbased on the Model-View-Controller (MVC)architectural framework. It consists of helperclasses used for the development of Java 2 En-terprise Edition (J2EE) applications based onthe Model 2 design pattern (Carnell & Linwood2003). Web applications developed using Strutsframework are configured with an external con-figuration file. Struts includes a notion of taglibraries that helps to reduce the amount of Javacode in the presentation component. Anotherbenefit of this framework is its built-in valida-tion mechanism. Furthermore, Struts has a sup-port for internationalization and database con-nection pooling.

mFrame: An Application Framework for Mobile Resource-constrained Computing Environments 125

TheStruts application framework is built aroundan ActionMapping structure (Carnell & Lin-wood 2003). This structure is used to convertHTTP requests submitted by users into applica-tion actions. ActionMapping encapsulates in-formation about a handler that is intended toprocess the request.

2.2. Spring

Spring Framework is an open source applica-tion framework for Java. It is mostly used forimplementing complex business logic applica-tions that are very difficult to build from theground up. It is often considered a collectionof smaller sub-frameworks. Each one of thesecomponent frameworks is usually responsiblefor a common feature. Some of the componentsthat are most relevant to this research includedata access, model-view-controller, and remoteaccess framework. The data access frameworkis usually combined with transaction manage-ment, fault-recovery and caching components,which results in a very feature-rich yet reliablesolution. Similar to Struts, Spring is a request-based framework. It defines strict interfaces forevery exposed service. One of the most impor-tant aspects of this framework is the simplicityand clarity of purpose for each of these inter-faces (Spring Application Framework).

2.3. Maverick

Maverick is yet another MVC framework usedto build web applications. This framework isavailable in Java and Microsoft .NET environ-ments. Maverick is a minimalist frameworkwhich focuses solely on MVC logic, allowingdevelopers to generate user interface compo-nents using a variety of templating and trans-formation technologies (Maverick ApplicationFramework). In this process, Maverick uses thepipe-and-filter approach to chain the transfor-mations. These transformations are pluggableand customizable.

Maverick application framework automaticallypicks from different views based on user lan-guage, browser type, or any other characteristicof the request. This framework includes a sup-port for internationalization.

2.4. jShrunk

jShrunk is an open source framework for mo-bile application development. This frameworkis based on the J2MECLDCspecification and assuch it is used to develop applications for cellu-lar phones andPDAs. jShrunk includes commu-nication libraries to help developers build mo-bile applications quickly and efficiently. Thedata structures used to transmit data betweenremote and local components are very com-pact to complywith limited bandwidth available(jShrunk Application Framework).

One of the problems we have faced while inves-tigating jShrunk application framework is thatits documentation and binaries are not currentlyavailable. The documentation we found seemsto be obsolete and inaccurate.

2.5. Aranea

Aranea is a lightweight Java component frame-work. Like every other approach, it attempts toreduce the development complexity by reusingexisting components. One of the main featuresof this approach is that each component’s inter-face is restricted to only 4-6 methods. Suchstrict interaction constraints ensure low cou-pling and improve framework’s agility. Araneais also an event-driven framework. Each com-ponent within a network is constantly listeningfor user events and is able to react to them. Thisgreatly simplifies the development process ascertain functionality may be linked to user in-terface items without any additional code. Ad-ditionally, each component in this framework isa Java object which adds the benefit of object-oriented programming. This aspect of Araneais especially useful for application modifiabilityas each component may be extended, replaced,or partially modified without any changes madeto the framework code. Finally, this frameworkcomes with pre-built components responsiblefor user interface, validation and request han-dling which make it very easy to get started ondevelopment (Murk & Kabanov 2006).


2.6. Cocoon

Cocoon is a similar framework, maintained bythe Apache Software Foundation. It is basedon the concepts of separation of concerns andcomponent-based development. This approachencourages using components as building blocks,putting them together to solve the problem athandwithout any additional programming. Eventhough this framework focuses on XML andXSLTpublishing, its cachingmechanism is veryinteresting. Cocoon framework utilizes the lazyevaluation approach. In other words, the veri-fication of the cache validity of a componentis delayed until the last possible moment inthe hope that it might not be necessary. Infact, the framework provides as many as 10 lo-cations where the application may choose touse cached data. One of the main contribu-tions of the Cocoon developers is the adaptivecache algorithm that performs cache cost cal-culations. This feature compares the cost ofgenerating/transforming new data to the cost ofvalidating the cache. The authors of this frame-work claim better performance than traditionalcachingmechanisms becauseCocoon-based ap-plications always choose the least costly option(Cocoon Application Framework).

2.7. Grails

Grails is an open source web application frame-work based on Groovy programming language(extension of Java platform). Similarly to otherframeworks, Grails attempts to reduce the de-velopment time by removing the configuration

aspect of application development. It encour-ages the “coding by convention” approach. Infact, this framework does not have an XML con-figuration file that other frameworks rely on.The authors of Grails claim that maintaining acomplex and frequently changing configurationfile uses valuable development time that couldbe spent elsewhere. Instead, this framework re-lies on naming and coding conventions to gener-ate configuration. Additionally, this frameworkdynamically adds certain methods to many ofits base classes. It determines their associationfrom the type of class i.e. its name. This elim-inates the need for developers to write wrap-per and connectivity code (Grails ApplicationFramework).

3. Design of the mFrame Framework

The proposed mFrame framework is a cus-tomized version of the Model-View-Controller(MVC) architectural framework. As the namesuggests, MVC framework, shown in Figure 1,consists of a number of components that canbe grouped into three main categories: model,view and controller. Model encapsulates thecore business logic and maintains the state ofapplication; View presents the results of op-erations; and Controller provides navigationmanagement mechanism. MVC separates viewand model components by establishing a sub-scribe/notify relationship between them, whereview ensures that its appearance reflects thestate of the model (Gamma, Helm, Johnson,& Vlissides 1997). A set of well-defined ob-

uses

redirects

creates

response

request

User Interface (View)

Persistence

Controller

Service Handler (Model)

Computational Component

Control Flow

Persistence Store

Figure 1. Model-View-Controller architectural framework.


jects called domain objects are used to exchangeinformation between the components.

mFrame customizes the MVC framework to in-clude the following:

• Service component, which includes localand innovative remote service handler im-plementations.

• Presentation component responsible for ren-dering information retrieved from the servicecomponent.

• Controller, which provides the access au-thentication and reconfigurable presentationand service management.

• Domain objects used to exchange informa-tion between the framework components.

Portability of the system is achieved using J2ME.J2ME is a portable, compact programmingmodelwhich has been widely accepted in the mobilecomputing community. Using configurations(horizontal specification) and profiles (verticalspecification), a rich set of APIs is provided toallow access to functions that are specific to amobile device, without affecting portability.

Some of the most distinguishable aspects ofthis framework are its architecture, configura-tion, component coupling and cache function-ality. Similarly to Struts, mFrame is using ex-ternal xml configuration files. This method hasbeen chosen as opposed to “coding by conven-tion” approach, implemented in Grails, becausethe complexity and variability of the architec-ture does not justify loosing the configurationfile. Additionally, Struts, Aranea and mFramehave built-in user input validation functional-ity, which reduces the required traffic. Fur-thermore, like jShrunk, the proposed frame-work provides remote data exchange abstrac-tion in order to maintain application function-ality, especially if the available bandwidth islimited. Similarly to Spring and Aranea solu-tions, mFrame uses few, well-defined and strictinterfaces. This ensures the robustness andmodifiability of this framework. Like Aranea,mFrame is event-driven, as it reacts to user ac-tions as well as changes in connectivity. Likein many other classic MVC implementations(e.g. Maveric), the data, business logic and pre-sentation are completely separate and handledby dedicated components. Unlike the Cocoon

framework, mFrame does not offer a very so-phisticated cache and cache evaluation func-tionality. However, there is nothing in the pro-posed framework’s architecture that prevents itfrom being extended to include or mimic thisfeature. mFrame is, in fact, very similar tomany other frameworks. The goal of this re-search was to create a new solution built on thesuccess of the existing frameworks by combin-ing successful feature implementations.

3.1. Top-down Architectural Model

As mentioned previously, the mFrame frame-work is a customized version of the MVC archi-tectural framework. The top-down architecturalmodel has been shown in Figure 2.

3.1.1. Presentation Component

The user initiates an action by submitting a re-quest. The presentation component associatedwith the action creates the corresponding re-quest and performs a basic validation. In caseof error, the request is reverted back to the pre-sentation component; otherwise, it is passed tothe controller. Responsibilities of the presenta-tion component are as follows:

• Serve as a template for concrete view imple-mentation.

• Define commandbehavior of the screen com-ponents.

• Intercept the request and perform abasic userinput validation.

• Decide the actions that should be performedin response to specific user events.

• Present the results of the operation.

3.1.2. Controller Component

Controller handles the flow of individual re-quests and provides access control. The re-quests passed through the controller are autho-rized against action id-based permission struc-ture. If the permission is denied, the businesstransaction is stopped and the user is notifiedabout the exception. The Controller componentdelegates all the requests invoked by the mo-bile application to the service components, and


Framework Boundary Presentation Component

Controller Component

Service

Component

Cache Handler

Internet

Request Handler

Mobile Device

Data Access Component

Persistence

Computational Component

Control Flow

Persistence Store

SOAP Handler

Figure 2. Top-down architectural model.

the responses to the presentation components.The service components and presentation com-ponents are initialized at run-time using actionidentifiers. In thismanner, support for newbusi-ness logic and its presentation can be added eas-ily by providing new presentation and servicecomponent classes and registering them againstcorresponding actions. The registration is doneusing an external configuration file as explainedin section 5.1.1. Thus the reference model dy-namically adapts to the modifications done inthe navigation paths.

The controller manages the following:

• Provides navigation management of the ap-plication i.e. dispatches requests to the ser-vice components and responses to the pre-sentation components.

• Manages exceptions raised during the dis-patching process.

• Handles the flow of requests and providesaccess control by means of action level au-thorization.

3.1.3. Service Component

The actual business logic is executed either lo-cally or remotely. These details are encapsu-lated by the service component.

Local Business Logic. In case of the localbusiness implementation, a service componentdirectly invokes local Data Access Componentsand executes business logic. A Data AccessComponent provides access to mobile device’spersistence layer. Since a persistence imple-mentation is device-specific, the domain of theframework does not include this component. It


is left up to the application developer to imple-ment this component using appropriate device-specific APIs. The device access package willinclude classes to execute query procedures, re-trieve result sets from the storage etc.

Remote Business Logic. The reference archi-tecture employs a Simple Object Access Proto-col (SOAP)-based interface to exchange datawith remote services via HTTP communica-tion protocol. Support for tightly coupled syn-chronous remote object protocols like IIOP orDCOM is not provided, but nothing in the archi-tecture precludes the addition of another proto-col. This framework uses Enhydra kSOAP, anOpen Source package designed to enable SOAPapplications to run on resource-constrained en-vironments, specifically on J2ME CLDC-baseddevices.

Due to the strict constraints on available band-width and reliability, Cache component, a com-munication component that is not dependentupon continuous network connectivity has beenused. It utilizes the asynchronous point-to-pointmessaging pattern as shown in Figure 3. Userscan access remote services even if the connec-tivity is interrupted since the information wouldbe exchanged upon the reconnection (Bellav-ista, Corradi & Stefanelli 2001). Depending onthe type of request, the controller componenteither invokes a local service repository handleror, if the connection to remote server is avail-

able, a SOAP handler. If the connection is notavailable, the request is queued in an OutputQueue in the cache handler for future submis-sion when the connection becomes available.The cache handler checks for the availability ofexternal web service; and once the service isavailable, it processes the queued requests onfirst-in-first-out (FIFO) basis, using an encap-sulated SOAP handler. The responses receivedfrom the remote service are stored in the InputQueue. When the request and response objectsare no longer needed, the cache handler removesthem safely and cleans up the resources. A re-quest’s expiration time is defined in the config-uration file as explained in section 5.1.1. Thus,the service component is responsible for the fol-lowing:

• Interpret input request objects

• Interact with a local persistent storage

• Control the remote execution sequence re-quired to fulfill the request

• Pass the processing results back to presenta-tion component

3.2. Design Patterns

The following design patterns have been usedwhen developing the top-down architecturalmodelexplained above.

System Component

Asynchronous Call

Mobile Device

Cache Handler

Synchronous Call

External

Web Service

Local Cache

Output Queue

Input Queue

SOAP

Handler

Request

Response

Figure 3. Cache component architectural model.


Figure 4. Front controller pattern class diagram.

3.2.1. Front Controller Pattern

The Front Controller Pattern (Alur, Crupi &Malks 2001) is used to handle the flow of infor-mation between presentation and service com-ponents. See Figure 4. This model authorizesuser requests and handles exceptions that couldbe raised in the dispatching process. By cen-tralizing the control, this pattern helps reducesize of the application, which is a key require-ment for resource-constrained computing envi-ronment.

ClientObject submits requests to the Controller.The requests are validated against the frame-work’s security model (Authorizer). Depend-ing on whether the request is for local service orremote service, the Controller invokes an appro-priate business object (ServiceHandler). TheController then synchronously waits for the re-

sponse from ServiceHandler. Finally, the re-sults of processing are dispatched to the Presen-tationObject.

3.2.2. Simple Factory Pattern

Extensibility of the architecture has been achievedusing the Simple Factory Pattern. See Figure5. This pattern describes an object that createsone or more class instances in response to acertain action. All the classes that the factoryobject instantiates have a common super classand common methods, but the implementationof the methods is usually different.

Consider an example of a presentation objectfactory. The getInstance() method of Presen-tationObjectFactory returns an appropriate in-

ClientObject

+getInstance(in response : Response) : PresentationObject

PresentationObjectFactory

ConcretePresentationObject1 ConcretePresentationObject2

+submit()

PresentationObject

1*

Figure 5. Simple factory pattern class.


Figure 6. Cache management pattern class diagram.

stance of ConcretePresentationObject depend-ing on the Response. If a new Response typeis to be added, we just have to implement onemore ConcretePresentationObject that extendsthe PresentationObject, and registers it in thePresentationObjectFactory. This pattern hasalso been used for instantiating a ServiceHan-dler, depending on the Request type.

3.2.3. Cache Management Pattern

Reliability of the system has been achieved us-ing the Cache Management pattern (Larman2004). See Figure 6. The pattern has beenused to queue the requests until they can bepassed to the remote service for further pro-cessing. As shown in Figure 6, the Requests forremote services are queued in the CacheHan-dler. The addRequest() and processAndPurge()methods are used for cache inserts and purges.

4. Implementation

As explained in the previous section, the top-down architectural model consists of three ma-jor components; model, view and controller.The implementation details of these compo-nents are explained in this section. Exchangeof information between these components is ac-complished using domain objects.

4.1. Domain Objects

Action object is used to store the informationabout the action performed by the user. It holdsthe class name of the service handler to be usedfor processing the request. In addition, it en-capsulates the callback details – the presenta-tion objects to be called in case of successful orerroneous processing (see Figure 7).

Figure 7. Domain objects implementation.


The Request object serves as a container forthe parameters being passed from the presenta-tion component to the service component. Thisclass encapsulates the Action performed by theuser and the date and time when the request wassubmitted. Request is initiated by a presenta-tion object and passed to an appropriate servicehandler via the Controller.

TheResponse object includes information aboutthe business processing results (either local orremote) and the original Request object. Theencapsulated Request object is used to fetch in-formation about the original request in case oferror. In addition, Response object has a respon-seCode attribute, which specifies if the process-ing was successful or not. In case of failure, theresponse object holds the information describ-ing the error. Response object is created by aservice handler and passed via Controller to thetarget presentation object.

The Errors domain object stores errors gener-ated by PresentationObject’s validate() method.These errors are generated within the presen-tation component and, as such, do not crossthe presentation to service component bound-ary. Rather, user interface errors are inter-cepted by PresentationObject’s commandAc-tion() method and shown to the user.

All domain objects extend from an abstract Do-mainObject class, which hides the specifics ofthe underlying map data structure. This classprovides convenient methods to store/retrieveproperties, and to clear the internal data struc-ture.

4.2. Presentation Component

mFrame application framework contains a sin-gle MIDlet object called MFrameApplication.The MFrameApplication class extends fromJ2ME’s abstract class javax.microedition.midlet.MIDlet. startApp() method serves as an en-try point of the application and is responsibleto pass the thread of execution to the Con-troller which, in turn, invokes the first presen-tation object. PresentationObjects are alwaysdisplayed by means of MFrameApplication’sshow() method.

PresentationObject abstract class serves as atemplate for the concrete view implementations.It is displayed on a per-screen basis and is pri-marily used to present a choice of actions anduser interface components. PresentationObjectimplements J2ME’s CommandListener inter-face. As shown in the sequence diagram (Fig-ure 8), commandAction() method is invoked inresponse to a submitted event.

This method calls buildRequest() to instanti-ate the corresponding Request object. Userinterface validation is performed by means ofvalidate() method enforced via IRequestVal-idator interface. If the validation fails, Errorsobject holding error information is passed toMFrameApplication, which displays a mode-less dialog on top of the current presentation ob-ject. This dialog shows an error as name/value

Figure 8. PresentationObject sequence diagram.


Figure 9. Presentation layer implementation.

pair. If the validation is successful, Request isdispatched via the Controller component.

The PresentationObjectFactory takes the Re-sponse received from the Controller, and createsan instance of the concrete PresentationObject.See Figure 9.

The framework provides two concrete imple-mentations of PresentationObject: Switchboardand CacheBrowser (shown below). Switch-board is the first presentation object invokedupon the application initialization. It presentsthe list of available applications read from theconfiguration file as explained in Section 5.1.2.

CacheBrowser displays queued Response ob-jects in the CacheHandler. This component dis-plays information about the action performed

by the user and the date and time when the orig-inal request was submitted. Upon selection of aResponse from the list, the user is taken to theappropriate results screen.

4.3. Service Component

The ServiceHandlerFactory takes the Requestreceived from the Controller and creates an in-stance of the ServiceHandler. ServiceHandlersimplement process() method to perform busi-ness logic. In case of the local service imple-mentation, thismethod invokes local data accessobjects, performs business logic and returns theresults in the form of a Response object.


Figure 10. Model layer implementation.

SoapHandler encapsulates remoting details ofthe framework. It uses kSOAP libraries to buildand parse XML messages exchanged betweenlocal application components and remote webservice. SoapHandler converts input Requestobject into a corresponding SOAP request us-ing kSOAP’s getSoapRequest() method. Next,SoapHandler opens an HTTP connection to theexternal Web service and submits the SOAPmessage. Remote Web service parses the in-coming SOAP request, converts it to server-sidedomain objects, and forwards it to middle-tiercomponents responsible for business process-ing. Upon completion, Web service sends aresponse message over the same HTTP connec-tion used to submit the request. SoapHandlerreads the HTTP response stream and builds aSoapObject, which contains the SOAP responsedata. Next, the handler parses the response datausing the SoapObject.getProperty() method. Itis the responsibility of kSOAP libraries to au-tomatically convert primitive SOAP elementsinto the appropriate Java types. Finally, theseJava object are used to build the Response ob-ject that, in turn, is sent back to Controller orCacheHandler. See Figure 10.

The CacheHandler extends the ServiceHandlerand encapsulates the collection of Request ob-jects that are locally queued until the connec-tion is re-established. The CacheHandler im-plements a worker thread to check the avail-ability of the remote server, and to purge anyexpired Requests and Responses in the localcache. The cacheHandler uses an encapsulatedSoapHandler to communicate with the external

service. Whenever the external communicationis restored, CacheHandler processes queuedRe-quest objects and queues Responses objects thatare made available to the client application bymeans of theCacheBrowser presentation object.

MainFormHandler provides a list of availableapplications to be displayed by the Switchboardpresentation object. This service object usesConfigurationManager to retrieve the applica-tion list from the configuration file, as explainedin Section 5.1.2.

4.4. Controller Component

This framework does not support multiple con-trollers – all the traffic will be handled throughthe single instance of the Controller object.Therefore, Controller is implemented as theSingleton pattern. The Singleton pattern is areusable solution where the class itself is re-sponsible for keeping track of its sole instance,while ensuring that no other instance of the ob-ject can be created, and providing a way to ac-cess the instance (Gamma et al. 1997).

As shown in the framework’s sequence dia-gram (Figure 11), at the initial call, the Con-troller invokes the ConfigurationManager classthat loads the information from the configura-tion file into an internal map structure. Thisinformation can then be retrieved by calling ap-propriate methods exposed by Configuration-Manager class.


Controller ConfigurationManager Authorizer ServiceHandlerFactory ServiceHandler PresentationObjectFactory PresentationObject mFrameApplication

1:dispatch(request)

2:getPopulatedAction(action)

3:parseConfigurationXML

4:action

5:canTransact(action)

6:getInstance(request)7:<<create>>

8:serviceHandler

9:process(request)

10:response

11:getInstance(response)

13:presentationObject

12:<<create>>

14:show(presentationObject)

Figure 11. Controller sequence diagram.

Configuration file parsing is done using kXMLpull-based APIs. In pull-based parsing (Sarang,Browne, Ayala & Chopra 2002), the parser in-tercepts an event and traverses the XML datawhile issuing callbacks to a previously regis-tered event listener whenever it encounters par-

ticular structures in the data. This approach isvery efficient since it does not have to build thecomplete document’s tree in memory. Configu-rationManager is also implemented as a single-ton class. See Figure 12.

Figure 12. Overall implementation.


Controller class exposes a public method calleddispatch(). This method sends the Request ob-ject to the corresponding ServiceHandler. De-pending on the Response, an appropriate Pre-sentationObject is instantiated, which is thenpassed to MFrameApplication’s show()methodto display processing results.

The Controller uses the Authorizer utility classto determine if the user is authorized to performthe requested business action. The Authorizer’scanTransact() method is implemented on top ofa device’s role permission model. If such a per-mission model is not provided, the method re-turns true (i.e. the action is always authorized).Finally, this framework provides a basic errorlogging service. Similarly to Controller andConfigurationManager classes, Logger utilityclass is implemented as a singleton class. Log-ger’s error() and debug() methods are imple-mented to write loggingmessages to device spe-cific persistent storage. Logging informationincludes source class and method name infor-mation. In the mFrame, all critical exceptionsthrown within the framework are caught andstack traces are logged to enable fault analysis.

5. A Case Study

In this section, a case study will be used to ex-plain the Configuration and Client Implementa-tion of an application usingmFrame framework.

The case study presents a prototype for a realapplication that was deployed later. An appli-cation will be constructed for a brokerage com-pany that needs to access real-time stock pricesand call clients with quote updates. Therefore,the application should fulfill the following re-quirements:

• Retrieve current quote for a specified stocksymbol. The services.xmethods.net getQuoteweb service will be used for this purpose.

• Display a list of the stored phonebook en-tries. The phonebook entries will be re-trieved from the local persistence storage.

• Resulting application has to be smaller than128kB due to maximum mobile applicationdownload size.

5.1. Configuration

Configuration of mFrame application frame-work is done using a configuration.xml file. Theconfiguration file has three major sections: ap-plication action descriptions, startup applicationlist, and logging state. Following is the Config-uration file specific to this application.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE Application SYSTEM "configuration.dtd">

<Application name="Test" description="Testing Application"><Logging state="true"/><MainForm actionId="switchboard">

<Item label="Stock Quote" actionId="get quote"/><Item label="Phonebook" actionId="phonebook"/><Item label="Cache Browser" actionId="cache browser"/>

< /MainForm><Actions>

<Action actionId="switchboard" description="Switchboard"><CallbackSuccess presentationObject="org.mframe.view.Switchboard"/><CallbackError presentationObject="org.mframe.view.Switchboard"/><Process serviceHandler="org.mframe.model.MainFormHandler"/>

< /Action><Action actionId="cache browser" description="Cache Administration">

<CallbackSuccess presentationObject="org.mframe.view.CacheBrowser"/><CallbackError presentationObject="org.mframe.view.CacheBrowser"/><Process serviceHandler="org.mframe.model.CacheHandler"/>

< /Action><Action actionId="get quote" description="Get Quote">

<CallbackSuccess presentationObject="org.mframe.view.StockQuote"/><CallbackError presentationObject="org.mframe.view.StockQuote"/>


< /Action><Action actionId="view quote" description="View Quote">

<CallbackSuccess presentationObject="org.mframe.view.StockQuoteResult"/><CallbackError presentationObject="org.mframe.view.StockQuote"/>

<Process serviceHandler="org.mframe.model.SoapHandler"/><Parameters>

<Parameter name="cache request" value="true"/><Parameter name="expire in milliseconds" value="300000"/><Parameter name="url" value="http://services.xmethods.net/soap"/><Parameter name="urn" value="urn:xmethods-delayed-quotes"/><Parameter name="soap action" value="getQuote"/>

< /Parameters>< /Action>

<Action actionId="phonebook" description="Phonebook"><CallbackSuccess presentationObject="org.mframe.view.Phonebook"/>

<CallbackError presentationObject="org.mframe.view.Phonebook"/><Process serviceHandler="org.mframe.model.PhonebookHandler"/>

< /Action>< /Actions>

< /Application>

5.1.1. Action Description

As explained in the design and implementa-tion sections of this paper, presentation and ser-vice objects are delegated at runtime. config-uration.xml defines these objects in terms of<Action> XML element that describes: pre-sentation object, service handler, and a list ofoptional application parameters. An <Action>element also includes a unique action id anddescription attributes:

• <CallbackSuccess> and <CallbackError>sub-elements identify presentation objects tobe called in case of success and failure re-sponse codes. If needed, the same Presenta-tionObject can be used for both success andfailure callbacks.

• The service object responsible for handlingthe request is specified in the <Process>element.

• Parameter cache request specifies that therequest should be cached if connection isnot available.

• Parameter expire in milliseconds defines du-ration for which the request will be valid

• Parameters url, urn, and soap action de-scribe the web service being invoked.

5.1.2. Startup Application List

As pointed out in Section 4.2, Switchboard ob-ject is the first user interface component dis-played upon the application initialization. It

presents a list of available top-level applicationsthat the user can choose from. This list is de-fined by means of the <MainForm> element.<Item> sub-element defines a top-level appli-cation, including the label which is presented tothe user, and the corresponding actionId. Ap-plication items are displayed in the same orderas they appear in the <MainForm> element. IfSwitcboard does not fulfill requirements of themail form component, a different action valuecan be used.

5.1.3. Logging State

For the performance and storage limitation rea-sons, mFrame introduces a check compared be-fore the actual logging, which defines if thelogging should be executed. Therefore, an over-head of the data manipulation and persistenceI/O activity can be controlled. This check isconfigured within configuration.xml file, as fol-lows: <Logging state="true"/>

5.2. Client Implementation

As described in the previous sections, an Au-thorizer can be implemented optionally. Thisis typically a job of framework developers andconstitutes the first step in the conception of theapplication. The second step is the implemen-tation of presentation and service objects and isthe responsibility of application developers.


5.2.1. Authorizer

The Authorizer’s canTransact() method can beoptionally overridden to customize to a specificcellular device. The default Authorizer imple-mentation returns true value.

5.2.2. Presentation Object

The steps towards implementing a presentationobject will be demonstrated by the means ofStockQuote object, shown in Figure 13. First,user interface components are created and ini-tialized:

private Form form=new Form ("Stock Quote");private TextField symbolField=new TextField ("Sym-bol", "", 5, TextField.ANY);Command getCommand=new Command("Get", Com-mand.SCREEN, 1);

Figure 13. StockQuote presentation object.

Next, the user interface controls are populatedand positioned using populateControls()

public void populateControls() {form.append(symbolField);form.addCommand(getCommand);

form.setCommandListener (this);}This method registers with the command lis-tener responsible for events fired by the get-Command component. Normally, the populate-Controls() method would retrieve informationfrom the Response object and populate controls,but in this example we are building a presenta-tion object without any input values.

The buildRequest()method sets the internal Re-quest object that is passed to Controller for fur-ther processing. Request object is built with

view quote action id and the parameter namedSymbol:

protected Request buildRequest(Command command,Displayable displayable) {

Request request=new Request();Action action=new Action();action.setActionId("view quote");request.add("Symbol", symbolField.getString());request.setAction(action);return request;

}Finally, validate() method is implemented to in-clude any presentation specific validation logic.In this example, information has to be enteredin the symbolField field before it is passed toSOAPHandler for remote processing:

public Errors validate(Request request) {Errors errors = new Errors();if (symbolField.getString()==null ||

symbolField.getString().length()==0) {errors.add("Symbol", "Cannot be empty");

}return errors;

}This method takes the populated Request objectand performs validation on it. Any errors identi-fied in the validation are registered in Errors col-lection and returned to the client. StockQuoteuses SoapHandler to retrieve quote value, andas such does not require custom handler imple-mentation. Therefore, the last step to completethis business service would be to build Presen-tationObject to display the stock’s value.

5.2.3. Service Handler

Business logic is defined bymeans of the servicehandlers. Method process() performs businesslogic and sends the results in the form of a Re-sponse object back to the presentation layer viathe Controller object. Here is an example ofPhonebookHandler’s process() method:

public Response process(Request request) {Response response=new Response();PhonebookDataAccess phonebook=new Phone-bookDataAccess();response.add("phonebook", phonebook.getPhone-book());return response;

}This method uses PhonebookDataAccess mockdata layer object to create static enumeration ofphonebook entries. PresentationObject’s popu-lateControls() method presents the resulting listof phonebook entries:


public void populateControls() {Vector phonebook=(Vector) response.get("phone-book");for (int i=0; i < phonebook.size(); i++) {

String phone=(String)phonebook.elementAt(i);menu.append(phone, null);

}}Significant cost and effort savingswere achieveddue to:

• Simplified navigation management via con-figuration file – the configuration file al-lows centralized setting and makes it easyto switch to a different operation mode.

• Convenient application packaging and de-ployment – the simplicity (both in terms ofinterface as well as implementation) allowseasy deployment.

The resulting application size is 69.7kB and sat-isfies the size requirement.

6. Conclusion and Future Work

mFrame is an innovative, reliable and exten-sible framework that supports rapid applica-tion development for compact mobile devices.mFrame enables dynamic presentation and ser-vice management where objects are registeredby means of an external configuration facilityprovided by the architecture. Thus, new busi-ness services can be easily added. This frame-work introducesmessage queuing between com-pact mobile devices and external service provi-ders. This caching model enables uninterruptedapplication execution, even though a communi-cation channel could be lost due to resourcepreservation or remote service unavailability.However, this framework primarily focuses onflexibility and reusability, and hence applica-tions built on top of it may perform slower thanconventional applications.

Future work would include improving the vali-dation mechanism such that validation routinesare applied to the corresponding fields via theconfiguration file instead of specifying them inthe validate() method. If form values are miss-ing or in an incorrect format, the current formwould be automatically redisplayed with errormessages, which is defined in the configurationfile. Another improvement is to implement thedata access layer to enable interaction with a

mobile device’s persistence storage. The dataaccess package would include classes to exe-cute query procedures and retrieve result setsfrom the storage. This research did not pre-scribe any rules about the external Web serviceimplementation. It is up to the server devel-opers to implement these services and corre-sponding business objects and deploy them tothe application server. One of the architecture’sfuture improvementswill be development of theserver Web service-based framework that willtransparently map mobile application’s requestobjects to underlying remote business services.

References

[1] ALUR, D., CRUPI, J., MALKS, D. Core J2EE Pat-terns: Best Practices and Design Strategies, Pren-tice Hall, NJ, June 2001.

[2] BALAKRISHNAN, H., SESHAN, S., KATZ, R., Improv-ing reliable transport and handoff performance incellular wireless networks, Wireless Networks, Vol.1, No. 4, December 1995, pp. 469–481.

[3] BELLAVISTA, P., CORRADI, A., STEFANELLI, C., Mo-bile Agent Middleware for Mobile Computing,IEEE Computer, Vol. 34, No. 3, March 2001, pp.73–81.

[4] BOURGES-WALDEGG, D., DUPONCHEL, Y., GRAF,M., MOSER, M., The Fluid Computing Middle-ware: Bringing Application Fluidity to the MobileInternet. Proceedings of the 2005 Symposium onApplications and the Internet, Trento, Italy, 2005.

[5] CARNELL, J., LINWOOD, J., Professional Struts Ap-plications: Building Web Sites with Struts, ObjectRelational Bridge, Lucene, and Velocity, WroxPress Inc., Birmingham, UK, March 2003.

[6] Cocoon Application Framework,http://cocoon.apache.org

[7] EDWARDS, W., MYNATT, E., PETERSEN, K., SPRE-ITZER, M., TERRY, D., AND THEIMER, M., Design-ing and implementing asynchronous collaborativeapplications with Bayou, Proceedings of the 10thAnnual ACM Symposium on User Interface Soft-ware and Technology, pp. 119–128, Banff, Alberta,Canada, 1997.

[8] GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES,J., Design Patterns: Elements of Reusable Object-oriented Software, Addison-Wesley ProfessionalComputing Series, MA, 1997.

[9] Grails Application Framework.http://grails.codehaus.org

[10] jShrunk Application Framework.http://jshrunk.sourceforge.net


[11] LARMAN, C., UML and Patterns: An Introductionto Object-oriented Analysis and Design, and theUnified Process, 3rd edn, Prentice Hall, NJ, July2001.

[12] LUDWIG, R., KONRAD, A., JOSEPH, A., Optimiz-ing the end-to-end performance of reliable flowsover wireless links. Proceedings of the 5th AnnualACM/IEEE International Conference on MobileComputing and Networking, pp. 113–119, Seattle,Washington, 1999.

[13] Maverick Application Framework.http://mav.sourceforge.net

[14] MURK, O., KABANOV, J., Aranea: web frameworkconstruction and integration kit. Proceedings ofthe 4th International Symposium on Principles andPractice of Programming in Java, Vol. 178, pp.163–172, Mannheim, Germany, 2006.

[15] SARANG, P. G., BROWNE, C., AYALA, D., CHOPRA,V., Professional Open Source Web Services, WroxPress Inc., Birmingham, UK, July 2002.

[16] SATYANARAYANAN, M., Fundamental Challenges inMobileComputing.Proceedings of the Fifteenth An-nual ACM Symposium on Principles of DistributedComputing, pp. 1–7, ACM Press, 1996.

[17] Spring Application Framework.http://www.springframework.org

[18] VARSHNEY, U., Multicast Support in Mobile Com-merce Applications, IEEE Computer, Vol. 35, No.2, February 2002, pp. 115–117.

[19] WELLING, G., BADRINATH, B., An Architecture forExporting Environment Awareness to Mobile Com-puting Applications, IEEE Transactions on Soft-ware Engineering, Vol. 24, No. 5, pp. 391–400,May 1996.

Received: October, 2006Revised: September, 2008Accepted: January, 2009

Contact address:

Hossein Saiedian, PhDProfessor and Assoc Chair

Department of EECSSchool of EngineeringUniversity of Kansas

Lawrence, KS 66045, USATel: +1 785-864-8812

e-mail: [email protected]: http://people.eecs.ku.edu/ saiedian

HINKO VINCAR is an Information Systems Officer at the United Nations(in Cologne, Germany). He received a Master’s degree in computerscience from the University of Kansas (USA) in 2004 and a Bachelor’sdegree in computer information systems from the Ottawa University(USA). Before joining the United Nations, he was a software engineerand systems architect at the YRC Logistics.

HOSSEIN SAIEDIAN is currently a professor of software engineering inthe Department of Electrical Engineering and Computer Science at theUniversity of Kansas (KU) and a member of the KU Information andTelecommunication Technology Center (ITTC). Professor Saiedian’sprimary area of research is software engineering. He received a Ph.D.in computer science from the Kansas State University (USA) in 1989.

SERHIY MOROZOV is currently working on his Ph.D. in computer sci-ence at the University of Kansas (USA). He received a Master’s degreein computer science from the University of Kansas (USA) in 2007 anda Bachelor’s degree, also in computer science, from the WestminsterCollege (USA) in 2003.

mframe: an application framework for mobile resource...

Documents