A Service-based Approach to Developing Android Mobile Internet Device (MID) Applications

Hyun Jung La and Soo Dong Kim

Department of Computer Science Soongsil University 511 Sangdo-Dong, Dongjak-Ku, Seoul, Korea 156-743 hjla@otlab.ssu.ac.kr sdkim777@gmail.com
AbstractMobile Internet Device (MID), as a portable handheld device, becomes a strong candidate for client-side computing. Android is a mobile operating system, being accepted as the operating system and a platform for MID applications. However, MID has a limited resource and computing power, and Android has an architecture and its components which are not commonly found in other operating systems and platforms. Hence, there is a demand for effective methodologies for modeling and implementing Android-based MID applications. In this paper, we present a practical and systematical process for develop applications for Androidbased MID. Our process utilizes both object-oriented and service-oriented engineering principles while considering features of MID and the architecture of Android. Keywords-Development Process, Mobile Internet Device (MID) Application, Android

I.

INTRODUCTION

Although there is no single standard definition of Mobile Internet Device (MID), it generally is known as a portable handheld device providing a down-graded computing capability and flexible wireless internet access. Earlier perception on utilizing MID was mainly for multimedia and entertainment, but recently its potential as a client-side computing machine for meeting personal and corporate computing demands. There is a common set of features among different MID products. It includes limited hardware resource, limited computing (CPU) power, strong support for Internet access, and location sensing services. However, the feature of limited resource forbids deploying and running complex software application on MID. This is the first motivation for our research. On the other hand, Android from Open Handset Alliance is a mobile operating system running on the Linux kernel [1]. It is being accepted as the operating system and a platform for MID applications. Android is not just an operating system, but it is a stack of multiple layers from Kernel layer to Application Framework. Android has four building blocks; activity, service, broadcast receiver, and content provider. Not their terms but also their definitions and usages are now; not having appeared in other representative operating systems and frameworks. Hence, conventional application developing methods such as object-oriented methods and component-based methods

have to be devised to enable effective Android-based MID applications. From our technical analysis and experiments on MID and Android, we observe the following two features which would pose difficulty in developing software applications on them; MID has limited resources to deploy and run relatively complex software applications. Android has an overall architecture and its components which are not conventional, posing a difficulty in designing and implementing the target applications with conventional object-oriented (i.e. UML-based) methods. Hence, we formulate a research goal for this paper as, how to design and implement complex software applications which will deploy and run on Android-based MID? There should be an effective methodology to model and implement software applications for Android-based MID, where the methodology supports the following requirements; Applications should function as desired even in the presence of limited resources on MID. Development artifacts (typically UML-based) should be optimally map to the key component types of Android architecture. The methodology should not surprise developers with excessively new modeling concepts and practices. Conventional OOAD activities should be maximally utilized in this new methodology. The methodology should be efficient and economical so that the target application can be developed with minimal efforts. In this paper, we present a practical and systematical process for develop applications for Android-based MID. Our process utilizes both object-oriented and serviceoriented engineering methods. In section 2, we present a survey of related works. In section 3, we identify key features of MID. In section 4, we sketch the rational why service-orientation is appropriate in developing MID applications. In section 5, we present our process and its instructions. And, we assess our process in terms of process quality criteria in section 6.

978-1-4244-5299-6/09/$26.00 (c)2009 IEEE

II.

RELATED WORKS

There are some approaches to apply service-oriented architecture (SOA) concepts to mobile devices. Thanf and his colleague propose service-oriented architecture framework supporting mobile services [2]. They address several requirements that should be covered in the framework including personalized services and service continuity. These requirements are derived from the characteristics of mobile environments. To do so, they present the internal structure of generic mobile services. And, they discuss the equivalence of service components and mechanisms of service discovery and state transfer. This work only focuses on the ways to compose services dynamically in mobile environment. Tergujeff and his colleagues propose SOA for lightweight mobile devices by surveying enabling technologies, programming interfaces, and supporting devices [3]. Based on their survey, they also present demonstration architecture mainly based on JSR 172. This work just shows us possibility and applicability to extend SOA concepts to mobile device. However, technically detailed and systematically ways to develop mobile services is needed. Natchetoi and his colleagues present a lightweight SOAbased architecture for business applications running on J2ME enabled devices [4]. They focus on devising design methods that cover important features of mobile devices; minimizing data transferred to and stored on the device, proactive data loading, security, and so on. Although they touched key issues in mobile devices, their solutions need to be systematically defined. III. KEY FEATURES OF MID APPLICATION MID is defined as a handheld device providing wireless Internet access. By considering its name, MID emphasizes wireless internet accessibility and mobility. MID application is an application that deployed on the MID, which can be implemented as a standalone application like traditional software application or kind of web application. There is not yet a strong consensus on MID itself. Therefore, we should distinguish unique features of the MID which are the essential drivers to design MID applications. By its definition and its relevant technology such as mobile and embedded computing, we identify the following three characteristics of MID application. y Wireless Internet based access In the definition of MID, it emphasizes wireless Internet accessibility. MID can interact with remote services through several wireless internet standard protocol (e.g. Wi-Fi), including mobile phone standards (e.g. CDMA, GSM). Due to this feature, the user sometimes cannot use the functionality temporarily. Therefore, the MID application can be operated with any protocols and the user can request the functionality online and offline. y Resource Limitation Like any other handheld devices such as cellular phone, MID has limited resource capability. The MID

application runs with this limited amount of resource. To deliver the functionality successfully, the MID application should manage this feature of resource limitation. y Users Mobility The purpose of the MID is that the users can be provided with the functionality while theyre walking on the street. That means the users can move freely with their MID. If the users move one place to another, there may be changes on protocol, time zone, and even providers that offer the application deployed on the users device. Therefore, to deliver the functionality of the application successfully, the change derived from users movement should be carefully managed. Beyond these features, MID applications are executed on the different kinds of devices. There are many MID products in the market and there may not well-applied standards. To develop the MID application that can be used on the any devices, the MID application should be independent of any devices. To cover these unique features of MID, we propose service-oriented approaches in the further section IV. SERVICE ORIENTATION OF MID APPLICATION In developing MID applications, we should consider and reflect all the features addressed in the previous section. The main reason is that design methods of conventional software may not be applied to those of MID application. Therefore, we present new service- oriented approach to design and develop MID application in this section. Service-oriented approach means that the functionality of MID application is fulfilled by invoking services including services, which is similar to service-oriented architecture.
<Features > <Applicable Solutions>
Lightweight Installation Wireless Internet based Access
dealt with

Thin Client (Cloud/SOA Services) Resource Limitation Dynamic Composition with Service Continuity Users Mobility Standardized Service Hardware Independence

Browser-based Service Delivery

Figure 1. Relationship between Features and Solutions

Figure 1 shows how the features are covered by serviceoriented approach. There are two types of relationships between features and solutions; resolved_by and dealt_with. Resolved_by is derived to resolve the feature that can lead the problem. And Dealt_with is used to derive the applicable solution to fully reflect the feature. For example, the feature,

Resource Limitation, leads some design challenges which are resolved by designing thin-client architecture. And users mobility is dealt with dynamic composition so that the MID application can cover users moving around. Benefits of applying service-based approach to developing MID applications can be summarized as; Lightweight Installation: With the wireless Internet accessibility, MID can invoke the remove services. But, this is effective only when the MID can be connected to the Internet. To resolve this dependence on network stability, essential functionalities, not all functionalities, may run in MID client side. Thin Client: MID has only limited resources so that there is a limitation on the application that MID can execute. To resolve this problem, we apply thin client model, which is all the services and resources are placed on the provider side and users can request the services through their browser. This thin client model is also associated with the wireless internet accessibility. Dynamic Composition: Users can move while they use services. In this case, the provided services can be changed for some reasons such as unstable network and unavailable services due to the different context information. Although SOA deals with this issue, MID application can have more chances to dynamically change services. When the service is dynamically changed, we should carefully consider how to transfer the state and data used by the previous service to the new service. That is, we should ensure to deliver functionality to the users with maintaining service continuity. Standardized Service: The more devices can invoke the service, the higher reusability the service gets. Therefore, we should make the service run consistently on the different kinds of MIDs. To deal with this different kinds of MIDs, we should design the standardized interface of the service. Browser-based Service Delivery: If MID only invokes the remote services, we do not need to care about the different kinds of MIDs. Therefore, we suggest that the service is delivered though the browser. Then, when the users request the service, the service returns only responses to them. Beyond the rationales to derive service-oriented application solutions, our approaches have the other benefits as followings; Free of upgrades or patches Usage-based subscription In summary, our service-oriented approach is formed as shown in Figure 2. In this approach, some functionalities are fulfilled by invoking remote services and others are executed on the MID. To do so, MID requires adequate amount of capacity and resources such as memory. This type of service-based approach is realized by using key concepts of SOA.

Whole Functionality Required by Clients

Part of the Functionality run on Client

Most Part of the Functionality Offered by Provider <Providers side>

<Clients side>

Figure 2. Service Oriented Approach

V.

THE PROCESS AND INSTRUCTIONS

Based on our rationale in section IV, we define a process for developing MID application by using service-oriented methods as well as object-oriented methods. MID application delivers functionality that the MID user wants, while services may not convey the required functionality. To fill this gap, we first observe that there are three kinds of roles around the MID applications as shown in Figure 3; service provider, MID application developer, and end user.
role

MID Application Developer

Provide Services Provide MID Application

role

role

Service Provider

Invoke Services through MID application

End User

Figure 3. Three Kinds of Roles in MID Application

Service provider is a role who offers functionality as a form of service. The service, here, is the same as one in SOA. Service does not provide whole functionality that users require. Rather, it provides cohesive and reusable functionality. MID application developer is a participant who delivers the whole functionality that users require as a form an application. End user is a participant who carries MID to use MID application. When he/she uses the application, he/she can get the result by invoking the services. Service provider and MID application developer have clearly separate roles, but they are performed by one physical organizer. By considering these roles, we define a six-phase process to develop MID applications as shown in Figure 4.

P1. Defining Requirements for MID Application

P2. Analyzing Requirement

P3. Designing Architecture (Thin Client/Fat Server)

decision so that we should include this requirement. For example, if the response time is very critical, we may make the design decision that the functionality will be placed in the client side, rather than the server side. Requirements for inter-user collaboration: More and more MID users may use MID application to collaborate with others. This kind of requirement can also affect design decision so that we should specify them.

P4a. Designing MID Client System

P4b. Designing Services

P5a. Implementing MID Client System

P5b. Implementing Services

P6a. Deploying MID Client System

P6b. Deploying Services

Figure 4. Overall Process

We distinguish the phases from different kinds of roles. The green-colored phases indicate that they are performed by both service provider and MID application developer. However, the other phases are performed by only one role; the red-colored phases by MID application developer and the blue-colored by service provider. A. P1. Defining Requirements for MID Application This phase is to define the requirements for MID application. Input to this phase is any information related to the requirement. Output of this phase is MID Application Requirement Specification (MIDARS). Instruction of this phase is based on conventional approaches to requirement gathering can be utilized such as; Acquiring requirement specification prepared by service consumers Interviewing the service consumers and domain experts Although this is much similar to conventional approach, we should include the following MID-specific requirements in SRS. Mobility-related requirements: MID application should be run without being interrupted by location changes. That is, the MID application should maintain location stability. Network-related requirements: As the MID users move, the network protocol to interact with the MID can be also changed. Therefore, the MID application should maintain network stability. QoS-sensitive requirements: Some functionalities may require the strict QoS such as performance. This kind of requirement can affect the design

B. P2. Analyzing Requirements This phase is to analyze the requirements for MID application. Input to this phase is MIDARS. Outputs of this phase are Functional Model such as Use Case Model and a list of services. Instruction of this phase consists of two steps by utilizing conventional approaches to object-oriented analysis. Step 1 is to identify all the highly-cohesive functionality that is mapped to a use case by drawing use case diagram. Step 2 is to extract the activities that are used in several use cases as a form of services by using the methods proposed in [5]. To do so, we specify use case description for each use case. After that, we should count how many use cases require the common activities C. P3. Designing Architecture This phase is to design the system architecture for the target MID application. The architecture should be designed completely by considering different viewpoints [6]. We propose guidelines to analyze the functional viewpoint for the architecture, and other viewpoints such as information and concurrency viewpoints should be applied subsequently. Inputs to this phase are MIDARS, Functional Model, and a list of services. Output of this phase is Architecture Description which contains key decisions made on architectural components, relationships, and their rationales. Instruction of this phase consists of two steps. A key concern in designing architectures for MID applications is the fact that MIDs have limited computing capability and resources. Hence, a considerable amount of computing loads has to be migrated to the server side to ease the computing overhead on the client side. We now propose a method for load balancing between client and server sides. Step 1 is to derive a set of functional items from the use case model. A use case is in general coarse-grained functionality, and it has to be decomposed into smaller functional units (called functional items) so that they can be allocated to appropriate tiers of the architecture. A use case is further refined into a use case description, which illustrates a sequence of interactions between them. A functional item represents a portion of the sequence, i.e. a group of logically related interactions.

An example of functional items is shown in Figure 5, where functional items are derived by user input actions.
Actor Enters information. . . Enter another input. Return the result. Functional Item #2 Functional Item #1 System

Functionality requiring strict performance thru. local computing Functionality to coordinate interactions between users & system Functionality shared by multiple MID applications Functionality managing & manipulating shared data Functionality with intended high reusability Functionality requiring large resource & computation Other items can be added and considered here.

9 9 9 9 9 9

Figure 5. Way to Group Related Actions

Step 2 is to assign functional items to the layers of the architecture. By evaluating functional items for all the use cases, we determine the layer which each functional item has to be assigned. The effect of this step is same as the conventional load balance tasks. As stated in the rationales for service orientation to MID application development in section IV, the MVC-based Thin Client SOA would technically be the most appropriate for MID applications. It is a stack of three layers; view, control and model layers, as shown in Figure 6.
MID Client Side MID Server Side

Using the decisions shown in the table, we draw a system architecture diagram which includes the allocated functional items. D. P4a. Designing MID Client Side This phase is to design the client side of the MID application, i.e. the portion of the application which will deploy and run on the MID. Inputs of this phase are the Functional Model and Architecture Description. Output of this phase is the design model for the client side, which consists of object model, dynamic model, and user interface design. Instruction of this phase consists of four steps. Since the client side of the application runs on the MID, the unique features and architecture of Android should be considered when designing the client program. Android defines a few building blocks to which all applications must conform; activity, service, broadcast receiver, and content provider. Activity presents a visual user interface which interacts with the user and requests data or services from other activities or services via queries or Intents. Service runs in the background for an indefinite period of time like Linux Daemon, generally not exposing a user interface. Broadcast Receiver is a component that receives and responds to system-wide broadcast announcements of an event. Content provider makes a specific set of the application's data shared with other activities or services. The data can be stored in the file system, in an SQLite database, or in any other manner that makes sense. Now, we present a method to design MID client application by using these Android-specific constructs. Step 1 is to discover externally available services, as an alternative to implementing the required functional items. If such services are found, they are invoked typically by the controllers of the control layer. Some services can be invoked by model layer objects which serve the role of proxy. In SOA, UDDI-based service repositories maintain those services. Step 2 is to construct an object model using class diagram for the client side. Conventional methods for object modeling are used. This object model is almost same as conventional one. The difference is that this object model

View Layer

Control Layer

Model Layer

Model Layer

Figure 6. MVC layers with Functional items assigned

As shown in the figure, both components in view and control layers are typically located on the client side of the MID application. The rationale for putting view layer is trivial. The rationale for putting control layer on the client is to efficiently coordinate the interaction between users and the system. And, the main role of control layer is to run business logics for specific users, and hence they are to be on the client side. Note that functional items can be assigned either the client side or the server side. If a functional item is specific to each user or user session, it is to be located to the client side. If the behavior of a functional item is concerning interuser information manipulation or requires a high computing power, it ought to be located on the server side. To show the allocation of the functional items, we propose to use Functionality Allocation Table as shown in Table 1. The first column specifies the characteristics of functional items, and the appropriate layers of the functional items are marked in the right columns.
TABLE 1. FUNCTIONALITY ALLOCATION TABLE Characteristics of Functional Items View Layer Control Layer Model Layer

Functionality to directly interact with users

should consider service operations that are already published. Step 3 is to construct a dynamic model showing the flow of messages needed to carry out each use case. By referring to the use case description and the load-balancing decision of the system architecture, we draw sequence diagrams. Typically, the controllers in sequence diagrams will coordinate message passing to the server side of the application when invoking services on the server side. Step 4 is to design the user interface. The main information on this step is the actor part in the use case description and functional items in view layer of system architecture. User interface design contains layout of each screen and navigation tree among the screens. Step 5 is to map the object model, dynamic model, and user interface design to the implementation constructs of Android, as shown in Figure 7.
Object Model Dynamic Model User Interface Design
Android

Dynamic Model to Service: Similar to the relationship between dynamic model and activity, if the subsequent methods can run for a specific amount time, the methods can be designed as Service.

Activity

Android

Service
Android

Broadcast Receiver
Android

E. P4b. Designing Service This phase is to design the server side of the MID application, i.e. the portion of the application which will deploy and run on the application server. Inputs of this phase are the Functional Model and Architecture Description. Output of this phase is the design model for the services, which consists of service interface specification, object model, and dynamic model. Instruction of this phase is similar to service design in conventional SOA. A key concern in designing services is that the several users can share the services. Hence, the services should be capable of handling multiple users by considering the commonality [5] and adaptability [7]. With the advances of service-oriented engineering such as SOA and cloud computing, it becomes feasible and economical to reuse published services, rather than implementing the required functionality from scratch. Hence, we consider two ways of realizing the server side functionality as shown in Figure 8.
Published Services Functionality of Server Side Newly Developed Components

Content Provider
Figure 7. Mapping Design Artifacts to Android Constructs

For the mapping, we suggest the following guidelines. Object Model to Content Provider: Some classes in the object model show the reusable data, which are located to MID server side. Content providers also expose the dataset that other activities can use. CRUD operations in such classes are mapped to on insert(), query(), update(), and delete() of the content provider. Dynamic Model to Activity: Dynamic model represents workflows among multiple objects. In activity, we can define interaction workflow by using EventListener. That is, classes implementing EventListener have information on the next operation to be invoked when some widget triggers events. User Interface Design to Activity: User interface design contains information on layout of the screen. Activity is a virtual user interface. Therefore, user interface design gives information to define design Activity. Each widget in user interface is designed by defining main.xml with element tags in such as <LinearLayout> and <TextView> or making instances of View, Layout, Container, and other classes in Activity.

Figure 8. Two Ways of Realizing Server Side Functionality

That is, the required functionality of the server side can be fulfilled by reusing published services and/or developing new components for the application. Step 1 is to discover available services for the functional items assigned to the server side in MID application architecture. Service repository such as UDDI repository contains published services that are reusable among multiple MID applications. Step 2 is to design the remaining portion of the server side by using typical object-oriented or component-based development paradigm. Since server side components can be used by multiple users and the users can change their locations, adaptability of the components and services should be considered in the design. For example, Android provides location sensing service in its framework layer. When it broadcasts the change of the users location through broadcast receiver, the server side component or service has to be adapted for its new location for the items like locationspecific currency, time, units, and facility information. However, implementing adaptability in components and services is challenging. Especially, the information about the component/service state, data sets, and user session must be transferred to the newly adapted components/services

without any loss or alternation. Methods such as dynamic composition [8], context-awareness [9], and dynamic adaptation [7] can be used. F. P5a. Implementing MID Client System and P5b. Implementing Service For the implementation of the client side, the design model produced during phase P4a including mapping artifacts to Android constructs is the base document. For the implementation of the server side, the design of acquired services and newly developed components is the basis. For Android-based MID applications, it is required to use Java language and adapt the Android architecture. Hence, the phases for implementation are Android-specific, and we do not recapture that redundant content. G. P6a. Deploying MID Client System and P6b. Deploying Service The deployment of the client side will be on the MID, and the deployment of the server side will be on an application server on the server side. Running both client and server sides will be identical to the conventional approach. VI. ASSESSMENTS Evaluating software process or methodology is challenging due to the conceptual nature of the work. However, we use representative process-evaluation criteria available in [10],[11], and [12]. Systematic Process Architecture: Each phase in our proposed process performs a single cohesive engineering task, and all the artifacts from previous phases are utilized in subsequent phases. That is, the process reveals the free of redundant and irrelevant information. Preciseness of Instruction: Each phase is elaborated with an overview, related artifacts, and instructions in steps. For example, the Functionality Allocation Table in Table 1 provides necessary guidelines. Specification of Artifacts: Each phase is specified with inputs and outputs. We only described the artifacts but their representational details are not presented here due to the limit of the paper. Coverage of MID specific phases: All the phases in the process are devised by considering MID-specific features and Android Architecture. Especially, the design-related phases are more specific to the MID and Android. For example, although phase name, P3. Designing are architecture, is somewhat general, detailed instruction of the phase deal with MID-specific features such as limited resources. VII. CONCLUSION Mobile Internet Device (MID) has a limited resource and computing power compared to conventional personal computers for client-side device. Android is a strong candidate for the operating system for MID applications, but

is has an architecture which is not commonly found in other operating systems and platforms. Conventional objectoriented methods would not be effective enough to develop Android-based MID applications. In this paper, we proposed a practical and systematical methodology for develop applications for Android-based MID. Our process considers both the client and server sides, and utilizes both object-oriented and service-oriented engineering principles. Our proposed process was devised with consideration of features of MI D and the architecture of Android. By using the methodology, we believe that high quality Android-based MID applications can be developed in cost-effective manner. ACKNOWLEDGMENT This research was supported by the National IT Industry Promotion Agency (NIPA) under the program of Software Engineering Technologies Development and Experts Education. REFERENCES
Android Developers, The Developers Guide, http://developer.android.com/guide/ (accessed August 11, 2009) [2] Thanh, D. and Jorstad, I., A Service-Oriented Architecture Framework for Mobile Services, In Proceedings of the Advanced Industrial Conference on Telecommunications/Service Assurance with Partial and Intermittent Resources Conference / E-Learning on Telecommunications Workshop (AICT/SAPIR/ELETE'05), pp. 65-70, 2005. [3] Tergujeff, R., Haajanen, J., Leppanen, J., and Toivonen, S., Mobile SOA: Service Orientation on Lightweight Mobile Devices, In Proceedings of 2007 IEEE International Conference on Web Services (ICWS 2007), pp. 1224-1225, 2007. [4] Natchetoi, Y., Kaufman, V., and Shapiro, A., Service-Oriented Architecture for Mobile Applications, In Proceedings of the 1st international workshop on Software architectures and mobility (SAM 08), pp. 27-32, 2008. [5] Her, J.S., La, H.J., and Kim, S.D., A Formal Approach to Devising a Practical Method for Modeling Reusable Services, In Proceedings of 2008 IEEE International Conference on e-Business Engineering (ICEBE 2008), pp. 221-228, 2008. [6] Rozanski, N. and Woods, E., Software Systems Architecture, Addison Wesley, 2005. [7] Chang, S.H., La, H.J., and Kim, S.D., A Comprehensive Approach to Service Adaptation , In Proceedings of IEEE International Conference on Service-Oriented Computing and Applications (SOCA 2007), pp.191-198, 2007. [8] Chang, S.H., La, H.J., Bae, J.S., Jeon, W.Y., and Kim, S.D., "Design of a Dynamic Composition Handler for ESB-based Services, In the Proceedings of IEEE International Conference on e-Business Engineering (ICEBE 2007), pp.287-294, 2007. [9] Gu, T., Pung, H.K., and Zhang, D.Q., A Service-oriented middleware for building context-aware services, Journal of Network and Computer Applications, Vol. 28, pp. 1-18, 2005. [10] IEEE Computer Society and ACM, Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE Computer Society, 2004. [11] Pressman, R., Software Engineering: A Practitioners Approach, 6th edition, McGraw-Hill, 2005. [12] Tran, Q.N.N. and Low, G., MOBMAS: A Methodology for Ontology-Based Multi-Agent Systems Development, Information and Software Technology (IST), Vol. 40, No. 7-8, pp. 697-722, June 2008. [1]