Odin: A Mobile Service Provisioning Middleware ∗
Andrew Meads
Department of Computer Science University of Auckland Auckland, New Zealand
†
Thiranjith Weerasinghe
Department of Electrical and Computer Engineering University of Auckland Auckland, New Zealand
ABSTRACT With the ever-increasing capabilities in today’s mobile devices, it is possible for them to move from their traditional role as service consumers to one in which they act as service providers. The act of making these mobile services available to clients is known as mobile service provisioning. In this paper, we highlight key challenges in mobile service provisioning and mobile application development. Furthermore, we review existing approaches in these areas, and give an overview of Odin, our mobile service provisioning middleware. Finally, we propose a model-driven toolkit for mobile application and service development that will generate Odinbased applications in a platform-independent manner. Such a tool differs from current work in that it will be designed to support the mobile application and service development lifecycle in its entirety, rather than focusing on one specific area. We believe that such a toolkit is necessary to promote the rapid adoption of mobile services.
Categories and Subject Descriptors D.2.2 [Software Engineering]: Design Tools and Techniques
General Terms Mobile service provisioning, heterogeneity, model-driven engineering
1.
INTRODUCTION
Historically, mobile devices such as phones and PDAs have acted as consumers of services hosted by a fixed infrastructure (e.g. a 3G phone may act as a web browser). Today’s mid-range mobile devices are significantly more computationally able than their predecessors and are equipped with features such as GPS and the ability to connect to multiple ∗
[email protected] †
[email protected] ‡
[email protected]
‡
Ian Warren
Department of Computer Science University of Auckland Auckland, New Zealand
networks such as 3G, WiFi, and Bluetooth. Such advances enable mobile services, where mobile devices act as service providers, rather than their traditional role as consumers. Use of mobile devices as service providers allows mobilespecific features, for example location awareness and the means to communicate with auxiliary devices, to be leveraged in offering novel services. To demonstrate the potential of mobile services, consider a parcel tracking scenario. Traditionally, clients request information concerning the location of their parcels from courier websites. The information is taken from a database which is updated periodically by the courier, typically via SMS which requires the company to pay fees to the mobile network operator regardless of whether or not the information was accessed by clients. By exposing parcel tracking information as a mobile service hosted on a device carried by the courier, the company need only pay for data usage when it is needed by clients. There is also the option of offloading those costs to clients. Furthermore, as clients are obtaining the information directly from the source, it is likely to be more accurate than the information on the server, which is only updated periodically. While the creation of services such as this are technically possible with today’s mobile devices, the lack of middleware and development support means that developers of such applications must routinely deal with challenges inherent in mobile computing, such as reachability and device heterogeneity (see Section 2). This fact has slowed the creation of novel mobile services. The aim of our research is twofold: i) to create a middleware solution to enable mobile service provisioning, and ii) to create a toolkit allowing developers to create mobile services and deploy them in execution environments consisting of a variety of different device and network types (i.e. a heterogeneous environment). In this paper we present Odin, our mobile service provisioning middleware, and our research plan to provide toolkit support for mobile service development. The remainder of this paper is organised as follows. In Section 2, an overview of key challenges for mobile service provisioning, development, and deployment is given. Relevant related work in mobile service provisioning and mobile application development is discussed in Section 3. Odin, our mobile service provisioning middleware, is introduced in Sec-
tion 4. Finally, our plan to evolve Odin and create a mobile service development toolkit is outlined in Section 5 prior to concluding in Section 6.
There are several challenges that must be addressed in order to enable service provisioning on mobile devices. Five noteworthy challenges are discussed below.
recognized as an important concern. However, this issue has tended to be treated as peripheral, hence it is unclear whether existing security mechanisms, such as sandboxing and protocols for secure channels, are sufficient or appropriate in the context of mobile service provisioning. In particular, limited CPU and bandwidth capacity might offer an environment that renders established security mechanisms of limited value.
2.1
2.6
2.
CHALLENGES
Limited resources
While mobile devices are becoming more computationally able, they still possess relatively inferior computational power and memory compared to other computers. In addition, traditional mobile networks often suffer from intermittent connectivity and fluctuating bandwidth [15], and devices are subject to a limited power supply. These issues affect the scalability and availability of any services that are to be hosted on these devices. For example, a mobile service that streams media from a remote camera would require a certain level of bandwidth in order to stream at a specified quality. Furthermore, should the device’s power supply be exhausted, without any form of redundancy the streaming service would become unavailable. Any infrastructure for mobile service provisioning must also provide measures to use the limited resources as effectively as possible.
2.2
• Scalability: a mobile service must be able to scale to support varying numbers of clients, despite limited resources of the host device and mobile network. • Availability: a mobile service must remain available to clients, despite the addressability, limited bandwidth and intermittent connectivity problems associated with mobile networks. • Adaptability: a mobile service must be able to adapt to changes in the operating environment of its host device.
Mobility
As a mobile device moves around a mobile network (i.e. from base station to base station) or from network to network (e.g. from WiFi to Bluetooth to GPRS), its address necessarily changes. Furthermore, addresses in mobile networks such as 3G are often private, and thus unavailable to potential clients outside the mobile network. This affects the accessibility of services hosted on these devices, making the problem of locating such services a non-trivial one. Furthermore, some services must also be able to preserve session state with various clients across address and network changes.
2.3
Dynamic operating environment
Operating conditions of mobile services are inherently dynamic. Some examples of this include a finite and diminishing power supply, resource usage by other applications, fluctuating bandwidth, and changes in the availability of network connections. Hence, there is a need to adapt to this changing operating context. Context is not limited to resource usage – a service could take into account such information as location, time, and client identity as well.
2.4
Service development and deployment
To facilitate ubiquitous mobile services, it must be possible for developers to easily design and implement such services and deploy them to target devices, irrespective of the heterogeneous nature of mobile devices such as differences in resourcing, and without reliance on particular mobile network operators. It is also desirable that changes be applied to these services at runtime while keeping any disruption to clients and the devices themselves to a minimum.
2.5
Security
Within the limited research that has been conducted in the area of mobile service provisioning, security is generally
Discussion
From the challenges described above, we can draw a set of non-functional requirements for mobile service provisioning middleware and its corresponding development environment:
• Security: a mobile service and its clients must be secured from malicious access, despite limited resources and bandwidth impeding traditional distributed security measures. • Simplicity: software developers should be able to concentrate their efforts on developing mobile services themselves, rather than be concerned with addressing challenges in mobile service provisioning.
3.
RELATED WORK
In this section we present an overview of related work in mobile service provisioning (and technologies that can be leveraged to enable it) and mobile application development. We then discuss the limitations of the varying approaches to determine the gap in the current research, where innovation can be applied.
3.1
Mobile service provisioning
Related work in enabling mobile service provisioning can be categorized as i) embedded middleware solutions, ii) intermediarybased middleware solutions, and iii) network-oriented solutions.
3.1.1
Embedded middleware solutions
Embedded middleware solutions are those in which middleware, usually with a reduced footprint, is deployed directly within a device. It should be noted that such solutions typically rely on mobile infrastructure support to enable clients to overcome the reachability and mobility problems, and they assume the host device to be capable of supporting the number of clients necessary for the useful operation of the service.
SoapME [26] allows J2ME CLDC-enabled devices to host SOAP/HTTP web services. The framework supports dynamically deploying and removing web services at runtime. Web service requests to different services on a given device are routed through the web service manager component to the target service via Java sockets. Embedded Ice (Ice-E) [34] is an embedded version of the CORBA-based Ice middleware platform [11], specifically targeted to resource constrained devices. As such it boasts a noticeably smaller footprint while stil being able to utilize Ice middleware services such as location and activation services.
3.1.2
Intermediary-based middleware solutions
The intermediary-based middleware approach involves a machine on a fixed network i.e. the intermediary. The deviceservice communicates with the intermediary, which in turn acts as a proxy for the device-service in the fixed network. Work at Nokia [33] has involved hosting HTTP servers on mobile devices, and, in doing so, has tackled the problems of addressing and accessing mobile servers. Their approach uses an intermediary to which a device hosting an HTTP server creates a TCP connection. As the connection is initiated from within the mobile network, the reachability issue is addressed. Clients connect with the gateway using a normal URL which the intermediary maps to a specific device. A proprietary protocol is used to relay HTTP traffic and keep-alive messages (needed to stop the connection going stale when not in use) over the TCP connection. Mobile Service Platform (MSP) [10, 22, 23] is based on the Jini Surrogate Architecture specification (JSA) – a formal specification to enable resource constrained devices to participate as Jini services [29] (See Section 4.1). Using MSP, a device connects with its intermediary (called a Surrogate in this case) through an HTTP channel. Using a network resource abstraction [24], MSP can gain information on any TCP/IP networks available to the device, and perform vertical handover among them. Recently, MSP has been augmented with context awareness to aid in determining when and to which network to switch [23]. In MobileHost [27, 28], services are exposed both as standard Web Services and as peers in a JXTA peer-to-peer network [9]. MobileHost relies on the network operator to support the JXTA protocol by providing an intermediary component in the base stations. JXTA-aware Clients contact this intermediary to discover and consume services. Alternatively, clients may consume the service as a Web Service, if the device IP address is static and known. Enterprise Service Bus (ESB) [5, 20] is a middleware infrastructure that mediates between service providers and consumers, providing support for security, third-party integration, billing, load balancing, and interoperability. While not designed specifically with mobile service provisioning in mind, ESB could be used as a foundation for this, thereby addressing some of the challenges introduced in Section 2.
3.1.3
Network-oriented solutions
Network-oriented solutions are aimed to allow the infrastructure of mobile networks to provide solutions to such problems as reachability and mobility. While they are not specifically designed to enable mobile service provisioning, if the existance of a ubiquitous network-oriented solution was assumed, one would not need to add such functionality in the middleware. MobileIP [21] overcomes the mobility problem by allowing connections to mobile devices using a static IP address. When the device is located in its original mobile network, requests to this IP address are routed, via a Home Agent (HA), to the device. When the device roams to a different mobile network, the Foreign Agent (FA) in that network notifies the HA of this handover, and provides the device a Care-of Address (CoA). Requests to the public IP address are tunnelled to the CoA via the HA and FA, hiding the mobility from the client. GPRS Tunnelling Protocol (GTP) [1] is a collection of protocols used by GSM and UMTS networks to ensure link layer mobility when moving from one point of attachment to another in the same network. Media Independent Handover (MIH, IEEE802.21) [7] is a recent IEEE standard that allows network-enabled vertical handover amongst heterogeneous networks (e.g. 3G, Wi-Fi, Bluetooth). When combined with MobileIP, it promises to allow clients to connect to a device using a known static IP address, while taking advantage of the multihoming capabilities of modern devices.
3.1.4
Discussion
With embedded middleware solutions, all middleware, and the mobile service itself, is contained within the device. However, as the mobile device is fully responsible for hosting the service, scalability necessarily suffers due to the limited resource capabilities of mobile devices. Furthermore, accessibility is not guaranteed as the underlying mobile network is responsible for managing connections between clients and devices. Reliance on network-oriented solutions is a possible solution to this problem, but in practice they are not widely available on current-generation mobile networks and a premium is usually charged when they are available, hampering the ubiquity of mobile services. Using an intermediary, it has been shown that one can overcome the reachability and mobility issues. Furthermore, by allowing the intermediary to manage device connections, scalability can be increased. However, it is our view that the intermediary can be further utilized compared with current implementations. With Nokia’s work, the sole purpose of the intermediary is to mediate device-client connections. MobileHost requires network operator involvement, reducing its ubiquity. MSP allows vertical handover to increase resource utilization, but does not allow handover to non-IP networks, such as Bluetooth. Due to the benefits of an intermediary as shown by the related work, we have chosen this model as a base for implementing our middleware, Odin (see Section 4).
3.2
Mobile application development
Traditionally, developers of mobile applications have had to manually create many variations in their applications in order to target the devices and mobile networks with wildly varying capabilities. As such, the design of environments and abstractions that lift this burden on developers is an important area of research. Most notibly, there has been growing intrest in the use of Model-Driven Engineering (MDE) techniques [25] in providing solutions to this problem. A notable MDE specification is that of OMG’s Model Driven Architecture (MDA) [18]. In MDA, several models and transformations are defined. In the Computation Independent Model (CIM), the software requirements are modeled without concern for how they will be implemented. In the Platform Independent Model (PIM), the CIM is modeled at a lower level of abstraction, but without targeting any specific technology (for example, a PIM for a service-oriented architecture may be created, without specifying whether CORBA or Web Services may be used). Thee Platform Specific Model (PSM) shows how the PIM is to be implemented using a specific platform, which may be an operating system, middleware, or some specific hardware platform. Transformations are generally used to generate one model from another model at a higher level of abstraction, with some degree of automation. Transformations are also used to generate runnable systems from the models (usually the PIM, but in some cases, directly from the PSM).
3.2.1
4.
ODIN MIDDLEWARE
In this section we present an overview of Odin, our middleware for mobile service provisioning.
4.1
In providing a coherent user experience across many devices, one must consider the differences in screen capabilities of mobile devices. Work in this area [8, 19] generally involves the definition of a set of abstract widgets, each responsible for the presentation of a certain kind of information or the execution of some task. An abstract UI is created using these widgets, and then transformed into one or more concrete implementations targeting different platforms. As an example, take a parcel tracking application. When deployed to a highend smartphone, location information may be displayed on a graphical map. When deployed to a low-end mobile device, a different concrete widget would be deployed, perhaps a text-based component that simply displays the street name where the package is currently located. In a more general case, there has been work in freeing developers from the burden of creating multiple application variants for mobile applications [4, 32]. In these Product-Line Architectures (PLAs), mobile applications are represented as component-based systems. The correct components are chosen for a target platform by solving a constraint satisfaction problem with the capabilities of the mobile device and requirements of the components as inputs.
Underlying Technologies
Odin is an intermediary-based mobile service provisioning middleware (see Section 3.1.2) built upon the Jini service platform and Jini Surrogate Architecture.
4.1.1 The A-MUSE Service Platform [2] is designed to allow developers to create mobile applications that use mobile network and middleware-specific functionality - such as sending SMS messages, establishing calls, and discovering services in a service-oriented architecture (SOA) - without concern for how that functionality is provided by the mobile network operator or middleware. Developers follow an MDA approach, in which a CIM specifying the requirements of the application is created, then transformed into a PIM for an abstract platform, then finally into a PSM for a specific combination of SOA middleware and telecommunications infrastructure.
Discussion
There has been much promising research in the area of mobile application development, mostly concerned with overcoming variability in mobile devices. However, current solutions are geared towards mobile devices as clients, rather than service providers. To enable truly heterogeneous mobile application development, there is a need to integrate a solution for mobile service provisioning with a solution to mobile application development. Such a hybrid solution would ideally allow developers to create applications targeted to a variety of different platforms with simple, accessible configuration options. When such applications are services, middleware dealing with the challenges in mobile service provisioning should also be generated, such that it meets the developer’s quality of service requirements.
Jini
Jini is a Java based middleware technology that enables discovery and consumption of services within a Jini federation. A Jini federation is a collection of entities – clients and services – within a distributed environment that communicate using transport protocols of choice [14]. Jini makes allowances for network failures and manages dynamic changes to the network such as the arrival and departure of services. Decentralised lookup services (LUS) and distributed transaction services are some of the services provided as part of the Jini distribution. Typically there are multiple LUSs within a Jini federation and they serve as a repository for service proxies. Services are expected to register themselves with all available LUSs, thereby avoiding reliance on a centralised LUS and making the federation more robust. Once a client locates a service through LUSs, it will be served with a service proxy containing logic to connect to the remote service and to remotely invoke service methods.
4.1.2
Jini Surrogate Architecture
The Jini middleware requires that the host device support a full JVM, which is often not the case with mobile devices due to resource constraints. The Jini Surrogate Architecture (JSA) [29] is a specification that defines how such resourceconstrained devices can participate as service providers in a Jini environment using an intermediary machine, known as a surrogate host (SH). As shown in Figure 1, a SH sits between a device and its Jini clients. The SH is capable of interacting with the Jini federation and serves as a container that manages one or more surrogates. A Surrogate represents the service running on a resource constrained device (device-service) and contains logic to expose itself as a Jini service. A surrogate also implements a protocol used to communicate with its device.
Figure 1 also shows the basic interactions within the JSA. The device first registers with the SH by sending the surrogate as a JAR file. The host then registers it as a Jini service, which enables clients to obtain a service proxy and to start consuming the device-service. Once a client request is received, the surrogate may communicate with the device if necessary. Communication between the device and the SH occurs over an Interconnect, whose purpose is to facilitate the exchange of application and control messages. The implementation of the interconnect is left up to the developer.
We have also developed a Bluetooth IC that transmits data over a full-duplex connection and which supports both L2CAP and RFCOMM protocols. Such an IC is useful as Bluetooth offers a low power connection that can be utilized when battery life is a concern. Furthermore, Odin is extensible, allowing the developer to write new ICs to take advantage of other network types if necessary. This allows an Odin-enabled mobile service to remain available to clients in a truly heterogeneous network environment.
4.2.3
Figure 1: Jini Surrogate Architecture JSA provides a useful solution to allow resource-constrained devices to host services while allowing these services to be written in any convenient language (only the Surrogate must be written in Java). However, it does not directly deal with any of the problems associated with mobile service provisioning, such as reachability, availability, or scalability.
4.2
Features
Odin extends JSA in several key areas to provide a more comprehensive mobile service provisioning middleware.
4.2.1
Caching
As part of the surrogate, Oding provides a caching system that can be used by service developers. This improves service scalability as similar requests by multiple clients need only result in one instance of surrogate-device communication, freeing device computational resources and network bandwidth.
4.2.2
Vertical Handover
Odin supports vertical handover between ICs, allowing the device to utilize whichever network interface is available to communicate with the surrogate [17]. The advantage of this is threefold. First, scalability is improved as the device can handover to a faster connection (e.g. Wi-Fi) to increase bandwidth when such a connection is available. Second, availability is improved as a low-power connection (e.g. Bluetooth) can be used to prolong battery life, and the failure of one connection can be masked by handing over to another. Third, costs are reduced as costly mobile network connections (e.g. 3G) need only be used when they are the only available connections. Figure 2 shows the high-level details of the normal operation of Odin’s transport layer. Above this layer, the service developer works with messages (see Section 4.2.4). Messages to be sent from the device to the surrogate (or vice versa) are converted to bytes and stored in the Outgoing Data Reservoir (ODR). From here the data is sent, in chunks, to the other party via the currently active IC. Each chunk is associated with a sequence number. Upon receipt a chunk, the receiving party deposits it in its Incoming Data Reservoir (IDR), ready to be consumed by the messaging layer. Then, an ACK is returned to the sending party. Following receipt of the ACK, the chunk is permanently deleted from the ODR.
Multiple Interconnect Channels
Odin provides access to two interconnect channels (ICs) - an HTTP IC and a Bluetooth IC. Our HTTP IC has been designed to be used over IP networks such as Wi-Fi and 3G and allows the mobile service to overcome the reachability and mobility problems (see Section 2). To overcome these problems, the device periodically sends HTTP requests to the SH. Upon receipt of such a request, the SH appends any pending messages (for example, service requests from clients) onto the response. In addition to these periodic “keep-alive” requests, the device also sends messages back to the surrogate (for example, responses to earlier requests) over a secondary HTTP channel. The reliance on pinging introduces a tradeoff between service responsiveness and bandwidth wastage by empty ping requests, which is managed by dynamically altering the keep-alive period based on the current service utilization by clients [3].
Figure 2: Normal operation of the transport layer Odin is capable of performing handover both proactively (when a “better” network is detected) and reactively (in response to failure). Figure 3 shows the reactive case. When the ODR fails to receive an ACK after a certain timeout (due to a failure of the active IC during chunk or ACK delivery) that chunk will be redelivered over another available IC. If no such IC is available, the ODR will continue to act as a buffer to store outgoing data until such time as another IC becomes available. If a chunk is received at an IDR that has previously been re-
ceived, it will be dropped. Similarly, a chunk is only deleted from an ODR once the corresponding ACK has been received. In this way, data loss and duplication is prevented.
with that contained in the new proxy, and proceeds to consume the service in its new location. Figure 4 details this process further. This process appears to clients as a single service invocation, freeing the client developer from needing to write custom migration-handling code.
Figure 3: Transport layer during reactive handover
4.2.4
Messaging Abstraction
Odin provides a messaging abstraction to enable service developers to work with higher-level data structures, as opposed to raw byte streams. Odin supports synchronous, asynchronous, and streaming messages for device-surrogate communication [17].
4.2.5
Surrogate Migration
Odin supports the migration of surrogates from one SH to another [31]. The motivation for this is threefold: i) optimising use of mobile device resources by allowing migration to a SH accessible over a preferred network, ii) optimising use of fixed-network resources by migrating surrogates experiencing high load to a more capable SH, and iii) ensuring mobile service availability in the case of SH error or maintenance. Figure 4: Overview of Surrogate Migration There are two phases to surrogate migration. First, the actual migration is performed. Second, clients must obtain references to the new service endpoint in a transparent manner. Upon detection of a desired target SH, the device initiates the migration by notifying its surrogate (in the current SH ) of the target SH location. The current SH blocks further incoming client calls to the surrogate, then waits for all ongoing calls to complete. This ensures the surrogate will be in a consistent state during migration. The current SH then serializes the surrogate and sends it to the target SH in a migration request. The target SH then registers the surrogate with the Jini LUS so new clients can locate the surrogate in its new location. The current SH is notified of whether this process was successful. If migration failed, the current SH unblocks client calls and execution resumes as normal. If the migration succeeded, the surrogate is deleted from the current SH and the device is notified. Upon notification of a successful migration, the device will update its IC endpoints to point to the target SH. After migration, clients that were consuming the service prior to migration must update their references to point to the new service endpoint, without user intervention. This is accomplished using a smart proxy through which clients consume services. When a smart proxy makes a service call to a surrogate that has since been migrated, a particular Exception will be thrown. The smart proxy catches this exception and recognizes it as a surrogate migration. Following this, the smart proxy will perform lookup with the Jini LUSs to locate the new proxy. It then replaces its service reference
4.2.6
Context Awareness
Dey [6] defines context as “any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application”. A context-aware system is one that can use context information to alter itself in order to provide better or more relevant service to users. Odin is context-aware in that it reasons on changes in context to perform handover and migration to more desirable networks and SHs [30]. Odin supports context sources on both the device and the SH [30]. Device context sources send raw context data to the SH, where all context processing takes place. This frees the device’s CPU from computationally intensive reasoning tasks. Raw context information is transformed into a Web Ontology Language (OWL) model [16]. Use of an ontology allows Odin to more easily reason on context changes. The Context Processor, located in the SH, preforms such reasoning using the Prot´eg´e-OWL API [13] coupled with rules defined in the Semantic Query-Enhanced Web Rule Language (SQWRL) [12]. Upon detecting the need for adaptation, a recommendation is forwarded to the appropriate mechanism. Service developers have the option of intercepting the recommendation if they do not which for it to take place.
4.3
Evaluation
Odin has been evaluated both by i) quantitative performance analysis and ii) the development of a social networking application using Odin as the middleware of choice.
4.3.1
in vendor-specific code or removing vertical handover logic to save space if this is provided by the mobile network. • Users will be able to augment devices with external computational resources, context sources, and services, without worrying about the underlying implementation of those items.
Performance Analysis
Performance analysis has been carried out showing the performance costs and benefits of the messaging system, vertical handover, surrogate migration, and context-awareness. The results confirm that Odin enables scalable, available services to be developed while imposing an acceptable overhead. Due to space constraints these results cannot be shown here; for detailed performance analysis we refer to the relevant sections in [17, 30, 31].
4.3.2
• Users will be able to deploy their applications onto target platforms automatically.
Social Networking Application
To demonstrate the usefulness of Odin to mobile service developers, a social networking application for the iPhone has been developed by Brooker and Carey [3] using Odin as the underlying middleware. They use Odin’s ability to overcome the reachability problem (Section 2) to enable users of the application to receive notification about changes in their friends’ status, reagardless of their location. Such status consists of user context such as user location and planned activities. Furthermore, Odin’s caching system is used to ease device resource consumption and provide a method of receiving user context even when the corresponding user is offline or their device is temporarily unavailable.
5.
• When creating mobile services, users will be able to specify how clients discover and consume those services. For example, developers may wish that services be exposed as Web Services Jini services, and / or CORBA services.
FUTURE WORK
Odin is an extensible mobile service provisioing middleware that provides solutions to scalability, addressability, and accessibility concerns while providing service developers with an extensible API from which novel mobile services can be constructed. However, such APIs are written in J2ME, and as such, the social networking application authors (Section 4.3.2 were forced to rewrite the device APIs in Objective-C to support iPhone development. Furthermore, no consideration is currently given to the need to use ventor-specific APIs to obtain context information such as device and network capabilities. A platform-independent method of designing mobile services and taking advantage of heterogeneous context sources is desired. To this end, we propose a model-driven approach, drawing on the examples of the use of MDE in the current literature (Section 3.2) to create a toolkit for developing mobile services, and other mobile applications. We envisage the following features in our toolkit: • Users will be able to develop mobile applications and services in a platform-independent manner. • Users will be able to specify certain Quality of Service (QoS) requirements for their service (for example, they may deem high availability or high scalability as being important concerns). The toolkit will use these policies to determine the generated middleware configuration. • Users will be able to specify target devices and network infrastructures independently of the service specification itself. Again, the toolkit will configure the middleware based on these targets, such as weaving
• Users will not need to use any other tool to create their applications. Furthermore, the tool itself will be usable (as determined by a usability evaluation). To construct the toolkit, techniques such as Model-Driven Engineering and Aspect-Oriented Programming will be used to generate Odin-based applications specific to target device / network platforms from the developer’s platform-independent application models.
6.
CONCLUSIONS
In this paper, we have highlighted key challenges in mobile service provisioning and mobile application development. Furthermore, we have reviewed existing approaches in each area to determine the extent to which current technologies meet those challenges. We have given an overview of Odin, our mobile service provisioning middleware, with a discussion of its benefits compared with existing solutions, and its current drawbacks with regards to service development. Finally, we propose a model-driven toolkit for mobile application and service development that will generate Odinbased applications in a platform-independent manner. Such a tool differs from current work in that it will be designed to support the mobile application and service development lifecycle in its entirety, rather than focusing on one specific area. We believe that such a toolkit is necessary to promote the rapid adoption of mobile services.
7.
REFERENCES
[1] 3GPP. 3GPP TS 29.060: General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface. In Technical Report v8.8.0. 3GPP Technical Specification Group Core Network and Terminals, June 2009. [2] J. P. A. Almeida, M.-E. Iacob, H. Jonkers, and D. Quartel. Model-driven development of context-aware services. In Distributed Applications and Interoperable Systems, volume 4025 of Lecture Notes in Computer Science, pages 213–227. Springer Berlin / Heidelberg, 2006. [3] D. Brooker, T. Carey, and I. Warren. Middleware for Social Networking on Mobile Devices. In Software Engineering, 2010. ASWEC’10. 21st Australian Conference on, April 2010.
[4] A. Childs, J. Greenwald, G. Jung, M. Hoosier, and J. Hatcliff. Calm and cadena: metamodeling for component-based product-line development. Computer, 39(2):42–50, Feb. 2006. [5] M. Decker and R. Bulander. A Platform for Mobile Service Provisioning Based on SOA-Integration. Communications in Computer and Information Science, 23:72–84, 2008. [6] A. Dey. Understanding and Using Context. Personal and Ubiquitous Computing, 5(1):4–7, February 2001. [7] A. Dutta, S. Das, D. Famolari, Y. Ohba, K. Taniuchi, T. Kodama, and H. Schulzrinne. Seamless Handover across Heterogeneous Networks–An IEEE 802.21 Centric Approach. In Proc. IEEE WPMC, 2005. [8] J. Eisenstein, J. Vanderdonckt, and A. Puerta. Applying model-based techniques to the development of uis for mobile computers. In IUI ’01: Proceedings of the 6th international conference on Intelligent user interfaces, pages 69–76, New York, NY, USA, 2001. ACM. [9] L. Gong. JXTA: A Network Programming Environment. Internet Computing, IEEE, 5(3):88–95, May/Jun 2001. [10] A. Halteren and P. Pawar. Mobile Service Platform: A Middleware for Nomadic Mobile Service Provisioning. In IEEE International Conference on Wireless and Mobile Computing, Networking and Communications, pages 292–299. IEEE Computer Society, 2006. [11] M. Henning and M. Spruiell. Distributed Programming with Ice - Revision 3.3.1b, 2009. [12] I. Horrocks, P. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, and M. Dean. SWRL: A semantic web rule language combining OWL and RuleML. W3C Member Submission, World Wide Web Consortium, 2004. [13] H. Knublauch, R. W. Fergerson, N. F. Noy, and M. A. ˜ Al’ ˜ OWL plugin: An open Musen. The protAl’g development environment for semantic web applications. 3298:229–243, 2004. [14] I. Kumaran and S. Kumaran. Jini Technology: An Overview. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2001. [15] C. Mascolo, L. Capra, and W. Emmerich. Mobile Computing Middleware. Lecture Notes in Computer Science, 2497, 2002. [16] D. McGuinness, F. Van Harmelen, et al. OWL web ontology language overview. W3C recommendation, 10:2004–03, 2004. [17] A. Meads, A. Roughton, I. Warren, and T. Weerasinghe. Mobile Service Provisioning Middleware for Multihomed Devices. In IEEE International Conference on Wireless and Mobile Computing, Networking and Communications. IEEE Computer Society, 2009. [18] J. Miller, J. Mukerji, et al. MDA Guide Version 1.0. 1. Object Management Group, 234, 2003. [19] G. Mori, F. Paterno, and C. Santoro. Design and development of multidevice user interfaces through multiple logical descriptions. Software Engineering, IEEE Transactions on, 30(8):507–520, Aug. 2004. [20] F. Ning, Z. Xingshe, W. Kaibo, and Z. Tao. Distributed Enterprise Service Bus based on JBI.
pages 292–297, May 2008. [21] B. Patil. IP Mobility Ensures Seamless Roaming. Communication Systems Design, 9(2):10–20, 2003. [22] P. Pawar, B. van Beijnum, A. Peddemors, and A. van Halteren. Context-Aware Middleware Support for the Nomadic Mobile Services on Multi-homed Handheld Mobile Devices. In Computers and Communications, 2007. ISCC 2007. 12th IEEE Symposium on, pages 341–348, July 2007. [23] P. Pawar, K. Wac, B. van Beijnum, P. Maret, A. van Halteren, and H. Hermens. Context-Aware Middleware Architecture for Vertical Handover Support to Multi-homed Nomadic Mobile Services. In ACM symposium on Applied computing, pages 481–488. ACM, 2008. [24] A. Peddemors, I. Niemegeers, and H. Eertink. An Extensible Network Resource Abstraction for Applications on Mobile Devices. pages 1–10, Jan. 2007. [25] D. Schmidt. Guest Editor’s Introduction: Model-Driven Engineering. Computer, 39(2):25–31, Feb. 2006. [26] H. Schmidt, A. K¨ ohrer, and F. J. Hauck. SoapME: a Lightweight Java ME Web Service Container. In MW4SOC ’08: Proceedings of the 3rd workshop on Middleware for service oriented computing, pages 13–18, New York, NY, USA, 2008. ACM. [27] S. Srirama, M. Jarke, and W. Prinz. MWSMF: A Mediation Framework Realizing Scalable Mobile Web Service Provisioning. In International Conference on Mobile Wireless Middleware, Operating Systems, and Applications, pages 1–7. ICST, 2007. [28] S. N. Srirama, M. Jarke, and W. Prinz. Mobile Web Service Provisioning. In AICT-ICIW ’06: Proceedings of the Advanced Int’l Conference on Telecommunications and Int’l Conference on Internet and Web Applications and Services, page 120, Washington, DC, USA, 2006. IEEE Computer Society. [29] Sun Microsystems. Jini Technology Surrogate Architecture Specification, v1.0. [30] T. Weerasinghe. Odin: Smart Middleware for Mobile Service Provisioning. Master’s thesis, Department of Electrical and Computer Engineering, University of Auckland, December 2009. [31] T. Weerasinghe and I. Warren. Empowering Intermediary-Based Infrastructure for Mobile Service Provisioning. In Services Computing, 2009. APSCC ’09. 4th IEEE Asia Pacific Conference on, December 2009. [32] J. White and D. Schmidt. Model-Driven Product-Line Architectures for Mobile Devices. In Proceedings of the 17th Annual Conference of the International Federation of Automatic Control, Seoul, Korea, 2008. [33] J. Wikman and F. Dosa. Providing HTTP Access to Web Servers Running on Mobile Phones. Nokia Research Center, May 2006. [34] ZeroC, Inc. Ice-E, 2009.
