OdinTools – Model-Driven Development of Intelligent Mobile Services

Andrew Meads, Ian Warren Department of Computer Science University of Auckland Auckland, New Zealand Email: [email protected], [email protected]

Abstract—Today’s computationally able mobile devices are resources, limited and intermittent bandwidth, and device capable of acting as service providers as opposed to their tradi- mobility [1], [2]. Furthermore, differences in mobile comput- tional role as consumers. To address the challenges associated ing platforms (heterogeneity) makes writing applications that with the development of these mobile services, we have devel- oped Odin, a middleware which masks complexity, allowing target multiple devices a non-trivial process [3]–[5]. These rapid development of mobile services. Odin, however, does challenges have slowed the adoption of mobile services. not allow cross-platform development, which is an important The goals of our research are twofold: i) to create a mid- concern with today’s wide variety of mobile devices. To solve dleware and framework to enable mobile services, and ii) to this problem, we have designed OdinTools - a model-driven create a toolkit enabling developers to create mobile services toolkit for cross-platform development of mobile services. Leveraging appropriate metamodels, a prototype has been without concern for platform and network heterogeneity. implemented in Eclipse and Marama that allows developers The first part of this research has been completed, resulting to model mobile services in a platform-independent manner. in the creation of Odin, our mobile service provisioning We are currently working on transformations between levels middleware [2], [5]–[10]. of the model hierarchy which will allow full Odin-based service Odin provides a framework that developers can extend implementations to be generated automatically. to create services for Android or iOS devices. However, using Odin by itself, developers would still be required to I.INTRODUCTION create separate versions of their services for each platform. Historically, mobile devices such as phones and PDAs Similarly, Odin itself would need to be re-implemented if have acted as consumers of services hosted by a fixed infras- support for an entirely different platform (e.g. Windows tructure (e.g. a 3G phone may act as a web browser). Today’s Phone 7) was required. This paper focuses on the design and mid-range mobile devices are significantly more computa- development of OdinTools, an environment allowing cross- tionally able than their predecessors and are equipped with platform development of Odin-based services. OdinTools features such as GPS and the ability to connect to multiple has been created using a Model-Driven Engineering (MDE) networks such as 3G, Wi-Fi, and Bluetooth. Such advances approach. enable mobile services, where mobile devices act as service The remainder of this paper is organized as follows. providers, rather than their traditional role as consumers. Use Examples of related work in mobile service provisioning, of mobile devices as service providers allows mobile-specific service development, and cross-platform development are features, for example location awareness and the means given in Section II. A brief overview of Odin is given in Sec- to communicate with auxiliary devices, to be leveraged in tion III. We describe and justify our OdinTools metamodel offering novel services. in Section IV, followed by its implementation in Section V. The potential of mobile services can be illustrated with Finally, we conclude in Section VII following a discussion a collaborative health scenario. Consider a team of fire- of future work in Section VI. fighters, each equipped with a body area network of sen- sors to monitor vital signs; and a mobile device exposing II.RELATED WORK that information and the firefighter’s location, as a service. There has been significant work both in the areas of Team members can keep track of each other’s health and mobile Service Oriented Architecture (SOA) and cross- whereabouts using this system. Furthermore, if a member platform development. Furthermore, techniques such as of the team encounters trouble during a rescue operation, Model-Driven Engineering (MDE) have been used with SOA this will be detected by the vital sign monitor. The operation to provide solutions to similar problems. The most relevant coordinator, acting as a mobile service client, will see this of these approaches are examined here. and can then direct team members to provide assistance. To create services such as these, developers have tradi- A. Mobile Service Provisioning Approaches tionally had to overcome many difficulties associated with Aside from Odin, other approaches to mobile service mobile development. These include limited computational provisioning have been proposed. Relevant examples include attempts to incorporate mobile computers into traditional Mayer et al. [22], Srinivasmurthy et al. [23], and Ullberg SOAs. Cheng et al. [11] recognize the increased importance et al. [24] show how MDE can be used as an approach of privacy protection due to the nature of data traditionally to Service Orchestration. When using formal models to stored on users’ mobile devices, while Natchetoi et al. [12], specify service interactions, these can be validated using Pawar et al. [13], Srirama et al. [14], and Nokia [15] deal model checking to ensure correctness. Furthermore, visual with limited, intermittent network connectivity by using a notations can be more easily developed, enabling a faster Gateway in the fixed network to manage mobile-to-client development process. Furthermore, model transformations connectivity. Finally, Chou and Li [16] show how full can be used to automatically generate the interaction logic duplex web services communication can be supported on from the model, in well-known languages such as BPEL, low-powered hardware and maintained on unreliable mobile Java, or Jolie. networks. Dhanesha et al. [25] focus on single service creation, For a more comprehensive review of current work in this showing how models can be used to abstract away differ- area, we refer to [6]. ences in underlying service platforms. Menzel and Meinel [26] show how models can be used to specify enforceable se- B. Cross-Platform Mobile Development curity policies for services, and how model transformations Several promising approaches to cross-platform develop- can be used to integrate this cross-cutting concern with the ment have been proposed in the literature. XMLVM, devel- rest of the service architecture. oped by Puder and Yoon [17], allows Android developers to cross-compile their mobile applications to other platforms. D. Discussion Currently, iOS and Palm-Pre devices are supported. An- The existing work in mobile SOA is promising. Odin droid applications written in Java are compiled normally adopts many of the ideas discussed in the literature and into bytecode. The bytecode is then transformed into an combines them into a comprehensive mobile service pro- XML representation using a custom tool. XSL stylesheets visioning solution while providing support for the latest then transform this XML representation into code for the mobile platforms and providing additional features such as target language. The result is code written for the target component relocation and extensible context-awareness (see platform that emulates the Java stack machine. Instructions Section III). are emulated on a bytecode level. Recent work has enabled cross-platform native application Titanium Developer [18] and Open-Plug ELIPS [19] are development for mobile devices, but much of this work fo- commercially available cross-platform development tools cuses on GUI-centric and service-client applications, rather that allow developers to write mobile applications using than the mobile services we wish to create. Work with MDE a scripting language (JavaScript and ActionScript, respec- in services computing has abstracted away differences in tively). The scripting languages are augmented with mobile- service platforms, but not differences in underlying hardware specific APIs such as GUI development and location- and operating systems, as is the case with today’s wide awareness. Using Titanium, the developer’s code is com- variety of mobile devices. A comprehensive cross-platform bined with an application skeleton for the target platform, mobile service development toolkit would thus combine resulting in an application that runs the developer’s code principles in both fields to offer a novel solution. This is using a platform-specific engine (WebKit for iOS devices, the case with OdinTools, which uses an MDE approach to Rhino for Android systems). ELIPS takes this a step further, specify services as well as the Odin middleware itself. The transforming the developer’s code into equivalent C code. model-based specification of both Odin and the developer’s Whenever the developer’s code invokes a mobile-specific service is then transformed into a platform-specific service API, these calls are transformed into calls to APIs developed implementation (see Section IV). and provided by Titanium and ELIPS vendors. III.THE ODIN MIDDLEWARE C. Use of MDE in Services Computing Odin is a middleware designed to enable developers Model-Driven Engineering (MDE) techniques such as to create mobile services. Developers use and extend the Object Management Group’s Model-Driven Architecture provided framework to implement their services, while many (MDA) [20] promise to enable developers to abstract away challenges inherent in mobile service provisioning are ad- differences in underlying platforms, focusing solely on the dressed by Odin itself. software’s functional requirements [21]. In services comput- Odin is built upon the Jini service platform [27] and ing, MDE has primarily been used to provide interoperability Jini Surrogate Architecture [28]. Jini is a Java-based SOA. between different service platforms, abstract away cross- Services can be discovered and consumed based on arbitrary cutting concerns such as security, and allow developers to metadata, while the Jini middleware provides fault tolerance model services and service interactions without concern for in the form of multiple service registries (JLUS) and man- precise implementation details. agement of disconnected services. The Jini Surrogate Archi- tecture (JSA) extends Jini with the concept of a Surrogate network failure [6]. Proactive handover increases scalability, Host (SH). A SH can be used to allow resource-constrained while reactive handover increases availability. devices to communicate in a Jini federation when they would 2) Surrogate Migration: Using Odin, a device’s Surro- normally lack the resources to do so. It serves as a container gate can be migrated between any available SH in the cloud for one or more Surrogates. A Surrogate is a representation [7]. This is useful as hosts experiencing failure or heavy load of a service running on a resource-constrained device. The can be avoided, increasing availability. Furthermore, network Surrogate exposes itself as a Jini service, and communicates usage can be decreased by migrating to a SH closer to the with the device via a custom Interconnect protocol. Figure Device. 1 shows an overview of Odin, including the interactions 3) Relocatable Components: Service logic written by de- between the Client, Registry, SH, Interconnect, and Device velopers can be executed either on the Device or Surrogate. components. Furthermore, data can be stored at either location [10]. Developers can manually specify where logic and data are to be located, or they can let Odin choose automatically. 4) Context Awareness: During operation, Odin collects Context information including battery life, available net- works and bandwidth, Device and SH computational re- sources, and Device location [9]. This information is trans- formed into an OWL model [29] and reasoned upon to automate vertical handover, surrogate migration, and com- ponent relocation. Policies determining how Odin should react to changes are specified in SQWRL [30] and are configurable by developers. Furthermore, Odin’s context model is extensible, allowing developers to specify and respond to additional context information [8]. B. Evaluation Odin’s performance in several key areas has been exten- sively tested. Performance evaluations of vertical handover, migration, and context reasoning can be found in [6], [7], and [9] respectively, and the benefits of component reloca- Figure 1. Overview of Odin Middleware tion can be seen in [10]. Furthermore, several Odin-based services have been developed, including parcel-tracking soft- ware [8] and a social networking application [31], and work A. Features is underway with the University of Auckland Clinical Trials Odin extends the JSA in several key areas to provide Research Unit to adopt Odin for the purposes of m-health a comprehensive mobile service provisioning solution, ad- and patient monitoring. Battery life, network utilization, and dressing mobile service reachability, availability, and scala- computational power have been shown to improve compared bility issues. A brief summary of its key features is provided with a mobile device hosting a simple web server. This is due here; for further information we refer to [2], [5]–[10]. to intelligent use of available networks, and augmentation 1) Vertical Handover between Multiple Interconnect with external computational power (the SH). Channels: Odin supports communication over any available network interface, both IP-based (e.g. 3G, Wi-Fi) and non- IV. ODINTOOLS METAMODELS IP-based (e.g. Bluetooth) [6]. Furthermore, Odin supports OdinTools uses an MDE approach, both i) to allow cross- two paradigms for communication over these networks. In platform service development, and ii) to allow Odin to be the case where the SH can directly contact the device, a full- supported on new platforms in the future. To support both duplex stream-based protocol is used. When the SH cannot these goals, we have adopted a multi-level model hierarchy, contact the device directly (for example, when the device as shown in Figure 2. Service developers define their mobile is behind a mobile network operator’s firewall), a COMET- service with a Service Model (SM). Odin middleware fea- based approach is used in which a long-held HTTP request tures are introduced in the Odin Framework Model (OM). by the device allows the SH to push client requests and data Abstract platform features used to implement Odin services on the response [6]. are introduced in the Platform-Independent Model (PIM). Furthermore, Odin supports Vertical Handover between Details of how specific platforms realize the abstract PIM network interfaces. This occurs both proactively when a are given in the Platform-Specific Model (PSM), provided more suitable network is detected, and reactively in case of by platform developers. Finally, the implementation of the service for specific platforms can be generated. Each of these level of abstraction to show how the developer’s service stages in the hierarchy is explained in more detail in this is realized by the Odin middleware. We achieve this by section. transforming the developer’s SM into a model conforming to Odin’s Metamodel. This new model, known as the OM, is generated automatically by OdinTools. Its metamodel is shown in Figure 4. The Odin metamodel describes Odin’s features, as de- scribed in Section III. Service logic is decomposed into DeviceService and Surrogate components. Currently this decomposition is achieved through the use of tags on each of the developer’s service methods specifying where the method is to be placed. As described in Section III-A3, the runtime location of the components can change. Com- munication between the DeviceService and Surrogate com- ponents are achieved via Messages containing Data passed through an Interconnect. The SurrogateHostDiscovery util- ity allows the DeviceService to discover a SurrogateHost, Figure 2. Overview of OdinTools Model Hierarchy which executes the Surrogate and exposes it as a Service. A ContextProcessor utility, located on the SurrogateHost, controls the Interconnect and Surrogate, commanding them A. Service Metamodel to perform migration and handover when necessary. Figure 3 presents an overview of the metamodel that When transforming the SM to the OM, the following service developers use to model their services. All objects mappings are defined: in Odin-based services are known as Entities. An Entity 1) ContextItems and ContextSource invocations are trans- can contain arbitrary data, known as properties. Odin’s formed to interactions with Odin’s ContextProcessor. Context-Awareness framework uses ContextItems, while Ser- 2) Each method in the Service is transformed to logic vices can be both provided and consumed. Service has inside handleSurrogateRequest, handleAsyncMessage, a ServiceDescription which provides enough information or handleDeviceRequest in the Device or Surrogate, to uniquely identify it, and a proxy that can be used to depending on a tag provided by the developer. invoke the service operations. Services support both request- 3) Invocations to the Registry are transformed to interac- reply semantics (via invokeOperation) and publish-subscribe tions with the SurrogateHost. semantics (via subscribe). Developers may also model a 4) UIComponents defined by the SM are not transformed User Interface (UI) that will appear on the mobile device. to OM elements - they are transformed directly to PIM They do this by defining instances of UIComponents. De- elements (Section IV-C) as Odin has no knowledge of velopers model their own Entities, ContextItems, Services, any user interfaces. and UIComponents by extending the corresponding meta- C. Platform-Independent Metamodel model classes. Some common Entities, ContextItems, and UIComponents are already provided by OdinTools. The OM allows us to see how the service modeled by the The metamodel provides three utility classes, able to be developer is realized by the Odin middleware. At the next invoked by all Odin-based services. A DataStore provides a lowest level of abstraction, the Platform-Independent Model simple abstraction of persistent storage, allowing developers (PIM), we see how Odin itself is realized by an abstract to associate arbitrary data with a key, and recall it later platform. Figure 5 shows the main metamodel elements using that key. A ContextSource utility allows developers introduced at this stage. Only the Device-side elements are to subscribe to changes in any context information, as well shown, as the Surrogate-side model shows little change from as publish their own context items. Any Odin-based service the OM. We have modeled the Device-side elements after can listen to changes in context of any other Odin-based an Android application as the authors are most familiar with service. Finally, a Registry allows the developer’s service this paradigm. to be exposed to the outside world, while also allowing Each Odin service is packaged into an Application con- developers to consume other Services. sisting of one or more Activities and one Service. Each Ac- tivity represents one screen on the user interface and contains B. Odin Metamodel one or more Views (Android’s UI components) displaying The SM allows the developer to specify the logic of a mo- information to the user. The Service contains all the OM’s bile service without concern for the underlying middleware, DeviceService logic and uses a NetworkInterface utility to OS, or hardware. We need to generate a model at a lower create NetworkConnections. Messages from the OM are Figure 3. Overview of OdinTools’ Service Metamodel

Figure 4. Overview of OdinTools’ Odin Metamodel

tation artifacts can be created. The metamodel to use for this transformation depends on which platform the developer is targeting. A single Platform-Specific Metamodel corre- sponds to a single platform. Currently, a single PSM has been created, specifying an Android Device plus a Java-based Surrogate Host. Its components are similar to those shown in Figure 5 (in fact, the PIM was originally modeled from Android).

V. IMPLEMENTATION Currently, an initial prototype of OdinTools has been implemented, allowing developers to create Service Models. The prototype has been implemented using Marama, an Eclipse plug-in. Marama was designed at the University of Auckland and is intended to provide a rapid prototyping Figure 5. Overview of OdinTools’ PIM environment for multi-view, multi-user diagramming appli- cations and domain-specific visual languages [32]. Its ease- transformed into byte arrays and written to / read from these of-use for prototyping purposes was the primary motivator connections, thus emulating the OM’s Interconnect element. behind choosing this tool. Figure 6 shows a screenshot of the OdinTools prototype. D. Platform-Specific Metamodel Developers drag and drop shapes from the lefthand panel Once the PIM has been generated, a Platform-Specific onto a drawing surface. These shapes represent a Service’s Model (PSM) can be generated from which the implemen- components (ContextItems, Entities, ServiceDescriptions, Figure 6. OdinTools prototype using Eclipse and Marama

Services, etc). Developers may also drag EntityInstance- • The map will be updated in real-time as the user’s Shapes onto the surface to define instances of various Entity friends move around. classes (see “me” and “friends” in Figure 6). When the Using OdinTools, these are the steps the developer fol- developer clicks on the Service entity, a code window lows to create a mobile service based on the metamodel appears allowing the developer to write the business logic introduced in Section IV: for the service. Currently, the developer writes in Java, and 1) Upon creating a new service project, the developer this is transformed into another language if necessary (e.g. chooses a name for their service (in this case, So- Objective-C for iPhone service development). cialNetworkService). This is defined by the “Social- Figure 6 also shows the operation of the ContextManager NetworkService” shape on the drawing surface (see utility. In the screenshot, the developer has defined a context Figure 6). rule that binds the value of me.location to the context item 2) The developer next defines the Entities describing the Context.DeviceLocation. DeviceLocation isn’t visible on the types of data in the service. In this case, the types to drawing surface itself as it is built into Odin and thus already be created are Person and Location. A Person has a provided by OdinTools. name (type: string) and a location. A Location has a latitude and longitude (type: double). String and A. Use Case – A Social Networking Service double are provided by OdinTools, while Person and As an example of how a service is developed using Location are defined by the developer by dragging and OdinTools, consider a scenario in which a service developer dropping EntityShapes onto the surface and filling out wishes to create a social networking service. This service their properties (these shapes are shown in Figure 6). has the following functional requirements: 3) The social networking service needs to store one • P2P-style service: instances of the service running on Person representing a user, and one list of People rep- different devices may contact each other. resenting the user’s friends. The user’s representation • A map is visible on a user’s mobile device (similar to is called “me”, while the friends list is called “friends”. Google maps). The developer defines these concrete variables by • The map shows the location of the user’s friends (i.e. using EntityInstanceShapes (“me” and “friends” are peers). visible in Figure 6). 4) The service needs to expose the user’s details (rep- Specific Models in the same way they currently specify resented by “me”) to clients. The developer accom- Service Models. plishes this by defining a new service method, called Following the development of the prototype that fully getLocation() as part of the model’s Service object. supports Odin-based service development, we will conduct Once done, the method body can be filled in on the a usability analysis and use the results to refine the devel- code window while the Service shape is selected. opment. This may include switching to a different, more 5) A user must be able to identify an instance of the robust or expressive toolset, such as GMF or IBM’s Rational social network service as belonging to a friend, as software. opposed to a stranger. A Service has metadata which can be used for this purpose. In this case, the developer VII.CONCLUSIONS uses the person’s name as the metadata. The developer To address mobility issues associated with the provi- defines this in a Service’s ServiceDescription (“Social- sioning of mobile services, we have developed Odin, a NetworkService metadata” in Figure 6). middleware which masks complexity, allowing rapid devel- 6) When the user’s device location changes, the value opment of mobile services. Odin, however, does not allow of “me.location” needs to be updated. Odin supports cross-platform development, which is an important concern obtaining GPS data as part of its context framework. with today’s wide variety of mobile devices. To solve this The developer can set up a relationship between problem, we have designed OdinTools - a model-driven “me.location” and the provided context information. toolkit for cross-platform development of mobile services. The developer uses a rule shape (“ContextManager:” Leveraging appropriate metamodels, a prototype has been in Figure 6) to do this. implemented in Eclipse and Marama that allows developers 7) A UI needs be defined to display the locations of the to model mobile services in a platform-independent manner. user’s friends. Currently, the UI is scripted in XML, We are currently working on transformations between levels with no graphical editor. of the model hierarchy which will allow full Odin-based 8) When a friend’s location changes, the UI needs to be service implementations to be specified automatically. updated. In the UI XML file, the developer sets up a binding tag, to bind a specific element of the UI REFERENCES to certain values. In this case, the developer binds the Markers property of a GoogleMapsComponent to [SE- [1] C. Mascolo, L. Capra, and W. Emmerich, “Mobile Computing Lecture Notes in Computer Science LECT location FROM friends] Middleware,” , vol. 2497, - OdinTools supports 2002. SQL-like binding syntax similar to how Language Integrated Query (LINQ) functions in .Net languages. [2] A. Meads, “A Holistic Approach to Mobile Service Provision- 9) The social networking service needs to be able to ing,” in Automated Software Engineering, 2009. ASE ’09. 24th discover other instances of the service running on IEEE/ACM International Conference on, 16-20 2009, pp. 698 different devices, belonging to a user’s friends, in –702. order to receive updates when those friends’ locations [3] J. P. A. Almeida, M.-E. Iacob, H. Jonkers, and D. Quartel, change. To do this, the developer specifies instances “Model-Driven Development of Context-Aware Services,” of SocialNetworkService (“friendsServices” in Figure in Distributed Applications and Interoperable Systems, ser. 6). The developer then populates this list of services Lecture Notes in Computer Science, vol. 4025. Springer by dragging a rule between the friends list and the Berlin / Heidelberg, 2006, pp. 213–227. [Online]. Available: friendsServices list, telling the Registry to search for http://www.springerlink.com/content/334n0353vm15v4n1/ services with metadata matching the friends’ names. [4] J. Eisenstein, J. Vanderdonckt, and A. Puerta, “Applying model-based techniques to the development of UIs for mobile VI.FUTURE WORK computers,” in IUI ’01: Proceedings of the 6th international Currently, the OdinTools’ Service Metamodel, Odin Meta- conference on Intelligent user interfaces. New York, NY, model, and Platform-Independent Metamodel have been USA: ACM, 2001, pp. 69–76. specified, along with a Platform-Specific Metamodel for [5] A. Meads, I. Warren, and T. Weerasinghe, “Odin: A Mobile Android devices. Furthermore, a prototype visual language Service Provisioning Middleware,” in Software Engineering, has been implemented using Eclipse and Marama, allowing 2010. ASWEC’10. 21st Australian Conference on, Industry developers to specify their Service Model. Currently we are Track Proceedings, April 2010, pp. 155–158. working on the transformations that will generate an Odin- based service from the developer’s model. In addition, we [6] A. Meads, A. Roughton, I. Warren, and T. Weerasinghe, “Mobile Service Provisioning Middleware for Multihomed are investigating the creation of a second visual language to Devices,” in IEEE International Conference on Wireless and aid platform developers in enabling support for new mobile Mobile Computing, Networking and Communications. IEEE platforms. This will enable developers to specify Platform- Computer Society, 2009. [7] T. Weerasinghe and I. Warren, “Empowering Intermediary- [19] OpenPlug Group. (2010, October) Open Plug - Your Way to Based Infrastructure for Mobile Service Provisioning,” in Go Mobile. http://www.openplug.com/. [Online]. Available: Services Computing, 2009. APSCC ’09. 4th IEEE Asia Pacific http://www.openplug.com/ Conference on, December 2009. [20] J. Miller, J. Mukerji et al., “MDA Guide Version 1.0. 1,” [8] T. Weerasinghe, “Odin: Smart Middleware for Mobile Service Object Management Group, vol. 234, 2003. Provisioning,” Master’s thesis, Department of Electrical and Computer Engineering, University of Auckland, December [21] D. Schmidt, “Guest Editor’s Introduction: Model-Driven En- 2009. gineering,” Computer, vol. 39, no. 2, pp. 25–31, Feb. 2006.

[9] T. Weerasinghe and I. Warren, “Odin: Context-Aware Mid- [22] P. Mayer, A. Schroeder, and N. Koch, “A Model-Driven dleware for Mobile Services,” in Engineering Mobile Service Approach to Service Orchestration,” in Services Computing, Oriented Systems; IEEE First International Workshop on, July 2008. SCC ’08. IEEE International Conference on, vol. 2, 2010. 2008, pp. 533 –536.

[10] A. Meads and I. Warren, “Extending Mobile Service Middle- [23] V. Srinivasmurthy, S. Manvi, R. Gullapalli, D. Sathya- ware with Support for Context-Aware Service Processing,” in murthy, N. Reddy, H. Dattatreya, S. Singhal, and J. Pruyne, IEEE Region Ten Conference, 2010. TENCON’10. Proceed- “Web2Exchange: A Model-Based Service Transformation and ings of, November 2010. Integration Environment,” in Services Computing, 2009. SCC ’09. IEEE International Conference on, 2009, pp. 324 –331. [11] W. Cheng, J. Li, K. Moore, and A. Karp, “A Customer- Centric Privacy Protection Framework for Mobile Service- [24] J. Ullberg, R. Lagerstrom, and P. Johnson, “A Framework for Oriented Architectures,” in Services Computing, 2008. SCC Service Interoperability Analysis using Enterprise Architec- ’08. IEEE International Conference on, vol. 2, 2008, pp. 13 ture Models,” in Services Computing, 2008. SCC ’08. IEEE –20. International Conference on, vol. 2, 2008, pp. 99 –107.

[12] Y. Natchetoi, H. Wu, and Y. Zheng, “Service-Oriented Mobile [25] K. Dhanesha, A. Hartman, and A. Jain, “A Model for Design- Applications for Ad-Hoc networks,” in Services Computing, ing Generic Services,” in Services Computing, 2009. SCC ’09. 2008. SCC ’08. IEEE International Conference on, vol. 2, IEEE International Conference on, 2009, pp. 435 –442. 2008, pp. 405 –412. [26] M. Menzel and C. Meinel, “SecureSOA Modelling Security [13] P. Pawar, K. Wac, B. van Beijnum, P. Maret, A. van Halteren, Requirements for Service-Oriented Architectures,” in Services and H. Hermens, “Context-Aware Middleware Architecture Computing (SCC), 2010 IEEE International Conference on, for Vertical Handover Support to Multi-homed Nomadic 2010, pp. 146 –153. Mobile Services,” in ACM symposium on Applied computing. ACM, 2008, pp. 481–488. [27] I. Kumaran and S. Kumaran, Jini Technology: An Overview. Upper Saddle River, NJ, USA: Prentice Hall PTR, 2001. [14] S. Srirama, M. Jarke, and W. Prinz, “MWSMF: A Mediation Framework Realizing Scalable Mobile Web Service Provi- [28] Sun Microsystems, “Jini Technology Surrogate Architecture sioning,” in International Conference on Mobile Wireless Specification, v1.0.” [Online]. Available: {https://surrogate. Middleware, Operating Systems, and Applications. ICST, dev.java.net/doc/sa.pdf} 2007, pp. 1–7. [29] D. McGuinness, F. Van Harmelen et al., “OWL web ontol- [15] J. Wikman and F. Dosa, “Providing HTTP Access to Web ogy language overview,” W3C recommendation, vol. 10, pp. Servers Running on Mobile Phones.” Nokia Research Center, 2004–03, 2004. May 2006. [30] I. Horrocks, P. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, [16] W. Chou and L. Li, “WIPdroid - A Two-way Web Services and M. Dean, “SWRL: A semantic web rule language com- and Real-time Communication Enabled Mobile Computing bining OWL and RuleML,” W3C Member Submission, World Platform for Distributed Services Computing,” in Services Wide Web Consortium, 2004. Computing, 2008. SCC ’08. IEEE International Conference on, vol. 2, 2008, pp. 205 –212. [31] D. Brooker, T. Carey, and I. Warren, “Middleware for Social Networking on Mobile Devices,” in Software Engineering, [17] A. Puder and I. Yoon, “Smartphone Cross-Compilation 2010. ASWEC’10. 21st Australian Conference on, April 2010. Framework for Multiplayer Online Games,” in Mobile, Hy- brid, and On-Line Learning, 2010. ELML ’10. Second Inter- [32] J. Grundy, J. Hosking, J. Huh, and K. N.-L. Li, national Conference on, feb. 2010, pp. 87 –92. “Marama: an eclipse meta-toolset for generating multi-view environments,” in Proceedings of the 30th international [18] Appcelerator Inc. (2010, October) Titanium Developer conference on Software engineering, ser. ICSE ’08. New Center. http://developer.appcelerator.com. [Online]. Available: York, NY, USA: ACM, 2008, pp. 819–822. [Online]. http://developer.appcelerator.com Available: http://doi.acm.org/10.1145/1368088.1368210