Uncoupling of Mobile Cloud Computing Architecture using Tuple Space: Modeling and Reasoning Sabyasachi Abadhan
Sohini De
Suddhasil De
Dept. of Computer Sc. & Engg., National Institute of Technology, Silchar, Assam, INDIA
Dept. of Computer Appl., Siliguri Institute of Technology, Siliguri, West Bengal, INDIA
Dept. of Computer Sc. & Engg., Indian Institute of Technology, Guwahati, Assam, INDIA
[email protected]
[email protected]
ABSTRACT Mobile Cloud Computing architecture provides the services of cloud computing to the mobile applications executing in users’ mobile/portable devices. By facilitating these applications with the cloud services, it helps to overcome the inherent limitations of mobile/portable devices that are faced by their mobile applications. However, the cloud services in existing architecture become tightly coupled with the mobile applications while delivering the service, which is highly undesirable in the dynamic and unreliable mobile cloud computing paradigm. In this paper, a new mobile cloud computing architecture is proposed, where the mobile applications remain uncoupled from the leased cloud services during the service delivery. In this architecture, the tuple space model is used for uncoupling these interactions. The proposed approach of uncoupling improves the flexibility and efficiency of mobile cloud computing. This paper also suggests an approach for formalizing and reasoning of the proposed architecture, in order to properly validate its flexibility and efficiency while uncoupling the service access and delivery to the mobile applications. The formalization is carried out using Mobile UNITY.
Categories and Subject Descriptors C.2.4 [Distributed Systems]: Client/server; D.2.4 [ Software/Program Verification]: Validation; D.3.1 [ Formal Definitions and Theory]: Semantics
Keywords Cloud computing, mobile cloud computing, uncoupling, tuple space, formalization, Mobile UNITY
1.
INTRODUCTION
The Cloud Computing paradigm [2], a recent infrastructure of utility computing, provides the end users with lease to the different computing resources, operating platforms and/or application software of the cloud service providers
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
[email protected]. Compute ’13, August 22 - 24 2013, Vellore, Tamil Nadu, India. Copyright 2013 ACM 978-1-4503-2545-5/13/08 ...$15.00.
[email protected]
on pay-per-use basis. Cloud computing becomes popular for the multiple commercial significances, e.g. less initial capital investment, fast startup of new services, low maintenance and operating overhead, easy disaster recovery etc. In fact, several service providers have already started leasing their cloud services to the different users [1, 15, 18, 22]. They are leasing resources as IaaS (i.e. I nfrastructure as a S ervice) (e.g. Amazon Elastic Compute Cloud [1]), platforms as PaaS (i.e. P latform as a S ervice) (e.g. Google App Engine [15]) and software as SaaS (which stands for S oftware as a S ervice) (e.g. Microsoft Office 365 [18], Salesforce [22] etc.) to their customers. Cloud computing has also been extended to include support for mobile computing devices (like smartphone, PDA, Ultra-Mobile PC, Tablet PC etc.) and portable computing devices with wireless connectivity (like Notebook, Laptop etc.). This extension of the cloud computing paradigm over the dynamic and unreliable environment has been referred as the Mobile Cloud Computing paradigm [11, 3, 13]. The mobile cloud computing paradigm also supports a wide variety of applications, including mobile commerce, mobile learning, mobile healthcare, mobile gaming, (mobile) social networking etc.; such applications are referred as the mobile applications. These applications may require to lease different resources of the cloud service providers as IaaS, PaaS or SaaS. In fact, some mobile service operators, including Vodafone, Orange, Verizon etc., have started mobile cloud computing services on pay-per-use basis for their customers. However, the recent reports [16, 19] suggest that the soaring cloud computing market (including, the mobile cloud computing market) is targeting towards large-scale business enterprises as their potential customers, and disregarding the personal use of the cloud services by the individual subscribers (particularly, the mobile users). This market trend is most likely due to the challenges in synergy of the personal usage of end users (mostly, via mobile/ portable devices) and the cloud services. In mobile cloud computing, such challenges arise chiefly because of the inherent limitations of heterogeneous wireless/mobile communications and the built-in shortcomings of mobile/portable devices, which hinders the anticipated growth of the mobile cloud computing market. In the existing architectures of mobile cloud computing [11, 13], synergy of mobile computing and cloud computing lies at the junction of mobile/portable devices on one side, and base stations (e.g. access points, broadcast towers etc. of different wireless infrastructure networks) and the Internet on other side. Flexibility in the interaction models at this point of synergy can mitigate the hinderance in intercommu-
nication between mobile computing and cloud computing. However, the existing communication techniques between the mobile/portable devices and the cloud service providers is limited, due to the high degree of coupling in interactions between the mobile applications and the cloud services. Whether requiring services as IaaS, PaaS or SaaS, such applications are being tightly coupled with their leased cloud services. Any form of coupling in the dynamic mobile cloud computing paradigm restricts its flexibility as well as efficiency, which is undesirable. This paper stresses on the need for uncoupling in the mobile cloud computing paradigm, and discusses a new approach of uncoupling the mobile applications from the cloud services. In order to achieve the uncoupling in mobile cloud computing, interactions of the leased cloud services are uncoupled from their leaser (i.e. the mobile applications) by adding some uncoupling media into the mobile cloud computing architecture [6]. These uncoupling media are distributed in mobile/portable devices as well as base stations of the wireless infrastructure networks. Uncoupling ability of the mobile cloud computing architecture depends on the dimensions and degrees of uncoupling provided by the plugged media. Three primary dimensions of uncoupling has been identified in [12], viz. time, space and synchronization uncoupling. According to [12], very few media satisfies these three dimensions of uncoupling at the same time, namely the message queue model [4], the publish/subscribe model [12], and the tuple space model [14]. Among them, the tuple space model additionally provides the inherent persistence capability and some additional dimensions of uncoupling, viz. reactivity uncoupling [10]. Moreover, the passive uncoupling medium like tuple space is more appropriate to uncouple the predominately static environment of cloud services from the highly dynamic mobile applications running in unreliable networks. So, this paper considers the tuple space model as the uncoupling media for mobile cloud computing. Contribution of this paper is twofold. First, it proposes a new uncoupled mobile cloud computing architecture with the tuple space model as its uncoupling media, which not only facilitates development and deployment of the largescale mobile applications to avail the cloud services, but also is ideal for developing such applications for the dynamic and unreliable wireless networks. In this architecture, the mobile applications remain uncoupled from their leased cloud services during service invocation and delivery, thereby improving flexibility and efficiency of mobile cloud computing. Secondly, this paper also suggests an approach for formal representation and subsequent reasoning of the proposed architecture using Mobile UNITY [21]. The formalization and reasoning of the proposed mobile cloud computing architecture not only helps in defining precise semantics of the interactions of applications with services, but also properly validates its flexibility and efficiency in uncoupling service access and delivery to the mobile applications. Rest of the paper is organized as follows. Section 2 briefly overviews the tuple space model. Section 3 proposes the new mobile cloud computing architecture, and also presents the formal representation of the proposed architecture with reasoning of that representation. Finally, section 4 concludes the paper.
of tuples, equally accessible to all the interacting parties. Any one of them can dynamically deposit new tuples, or read/withdraw existing ones from tuple space. No updatein-place, however, is defined for tuples and, as such, tuples are immutable. A tuple is considered as the basic unit of information exchanged during interaction of the involved parties. Each tuple is a set of several heterogeneously-typed fields having values (called actual ), e.g. {1,“Bob”,10.55,“Hello”}. An antituple is considered as the basic unit of search key to identify some specific tuples (called the sought tuples) residing in tuple space. Each antituple is also a set of heterogeneously-typed fields, with some fields being the actual, while others having placeholders for the actual (called the formal ), e.g. {int,“Bob”,10.55,—}, {1,string,—,“Hello”} etc., (where, ‘—’ represents absence of the actual /formal in antituple field). Antituple uses the associative matching operation to determine the sought tuples from tuple space. Typically, a tuple space includes several primitives to carry out insertion, reading and withdrawal of tuples. These primitives are: tuple-producing primitives like out and outg, tuple-reading primitives like rd, rdp, rdg and rdgp, and tuple-consuming primitives like in, inp, ing and ingp (here, p and g in primitive name stand for ‘probe’ and ‘group’ respectively). The tuple-producing primitives deposit given tuples in tuple space; e.g. to place tuple {1,“Bob”,10.55,“Hello”} in tuple space, out({1,“Bob”,10.55,“Hello”}) is invoked. Tupleconsuming primitives withdraw one/more tuples matching the given antituple; e.g. in({1,string,—,“Hello”}) searches and withdraws above tuple successfully from tuple space, while inp({1,int,—,string}) does not match that tuple. A tuple-antituple matching algorithm searches the entire tuple space to determine a positive match of any residing tuple with the given antituple. An antituple will match a tuple, if all the following conditions hold: (i) both of them must have an identical number of fields; (ii) all fields must be pairwise of same type; (iii) for the actual in the both cases, the values must be same; and (iv) an antituple formal can match any tuple actual of same type. If more than one tuple match positively, either one (chosen nondeterministically) or all of them are withdrawn from tuple space and returned back as result of that operation. The tuple-reading primitives read one/more tuples that match the given antituple. They operate in same way as the tuple-consuming primitives, except that tuples are read and not withdrawn from tuple space. If the tuple-antituple matching operation cannot provide a suitable tuple, the invoker gets blocked indefinitely till a positively-matched tuple is available. rd, rdg, in and ing exhibit this blocking behavior. The nonblocking primitives (e.g. rdp, rdgp, inp and ingp) are also supported. The literature shows that the tuple space model is a popular coordination model for the concurrent, distributed and mobile computing paradigms [20, 5]. Its popularity is due to its ability in providing the multiple dimensions of uncoupling during the coordination of interacting parties. Next section shows the uncoupling approach in the mobile cloud computing paradigm using the tuple space model.
OVERVIEW OF TUPLE SPACE MODEL
PROPOSED UNCOUPLING IN MOBILE CLOUD COMPUTING
The tuple space model came into existence with the proposal of Linda [14]. A tuple space is a common repository
The focus of the cloud computing facility is widened to cater not only the large business enterprises in the static en-
2.
3.
Wireless Network 1 (WLAN)
Mobile Device 1
Portable Device 1
TS TS TS Access Point
Existing Cloud Facility
Internet Mobile Device 2
TS
Broadcast Tower TS
Wireless Network 2 (Cellular Network)
Portable Device 2 TS
. . .
Figure 1: Schematic view of the Proposed Mobile Cloud Computing Architecture.
vironments, but also the individual consumers in the mobile, dynamic and unreliable environments. This approach of expanding the cloud facility requires a radical change in the architecture of mobile cloud computing. This section proposes a new architecture of mobile cloud computing, which depicts the uncoupling in interactions of the mobile applications and the cloud services. The proposed architecture will become highly suitable for the mobile, dynamic and unreliable environments, without modifying the existing cloud infrastructure.
3.1
Proposed Architecture
Figure 1 presents the proposed architecture of mobile cloud computing that includes the support of uncoupling using the tuple space model. In this architecture, the cloud services can be communicated and leased by the different mobile applications via base stations and the Internet. As pointed out in [11], the mobile cloud computing architecture must incorporate both static as well as dynamic environments. In the proposed architecture, the static environment spans from the cloud services to base stations of the wireless infrastructure networks. However, the dynamicity is present in mobile/portable devices and their communication with base stations in the proposed architecture. Multiple tuple spaces are distributed as the uncoupling media in these dynamic segments, as mobile cloud computing is inherently decentralized in nature. Each tuple space is added to the device of each interacting party (viz. mobile/portable device or base station). Benefit of the proposed mobile cloud computing architecture is that the mobility, dynamicity and unreliability factors, present in communication between mobile/portable devices and base stations, can be mitigated. This, in turn, reduces the effect of unavailability or unreachability of the mobile applications, while being serviced by some cloud services. Irrespective of the nature of the mobile applications, the proposed architecture will support flexible and efficient servicing by the existing cloud facility to the users of mobile/portable devices over the dynamic and unreliable wireless infrastructure networks.
Tuple spaces, incorporated in the proposed mobile cloud computing architecture, are tailored to carry out the uncoupling functionalities efficiently. Both the tuple and antituple structures in these tuple spaces are unordered in nature [9]. Need for the unordered tuple/antituple structure is to improve the flexibility of mobile/portable devices in supporting the multiple mobile applications, as well as to simplify their design and development. On the other hand, these tuple spaces are indexed in their structures [7], which improve the performance of mobile/portable devices and base stations. Also, the set of tuple space primitives for these tuple spaces are customized as per the requirement of uncoupling. No tuple-reading primitives (viz. rd, rdp, rdg and rdgp) are supported in these tuple spaces, as the reading operations are not required for uncoupling. Again, the blocking tupleconsuming primitives (viz. in and ing) are not supported by these tuple spaces, as they are deadlock-prone and may indefinitely suspend the execution of mobile/portable devices and base stations. The tuple-producing primitives, viz. out and outg, are combined as a new tuple space primitive, namely inject, which inserts one/more given tuple(s) into these designated tuple spaces. Also, the remaining tupleconsuming primitives, viz. inp and ingp are clubbed as another new tuple space primitive, called eject, which withdraws one/more sought tuple(s) from these tuple spaces. An illustration clears the uncoupling abilities of the proposed mobile cloud computing architecture. Considering a mobile application (say, A) requesting any cloud service (say, S), A interacts with S via tuple spaces of host H of mobile/portable device executing A (denoted by TH ), and base station B through which H accesses the cloud (denoted by TB ). Interacting data are transformed into tuples, and are stored successively in TH and TB on their way to be delivered to the assigned destinations. For instance, tuple t 1A , generated by A to inform S about the service parameters, is stored in TH , and depending on reachability of B from H, t 1A is withdrawn from TH to transfer to B, from where it eventually reaches S. Similarly, the response from S is converted to tuple t 2A and stored in TB , and on the direct/indirect reachability of H, t 2A is withdrawn from TB to be handed over to H or another ‘en route’ base station B0 , where it may be stored in TB0 depending on the availability of H. Thus the proposed mobile cloud computing architecture reduces the effect of mobility, dynamicity and unreliability that result in the unavailability/unreachability condition during the application-service interaction.
3.2
Proposed Formal Representation
This section expresses the uncoupling ability of the proposed architecture using Mobile UNITY.
3.2.1
Foundation
A mobile application is a set of several attributes, like identity, nature of services required, service parameters etc., viz. A = {aidA , λA , η A , η s , P s }. Here, A represents a mobile application running within a particular mobile/portable device environment (called host) and having identity aidA and location λA . Also, intrinsic properties of A are specified by η A = {η1A , η2A , . . .}, attributes about the nature of required cloud service are denoted as η s = {η1s , η2s , . . .}, and input parameters to are designated using P s = {P1s , P2s , . . .}. A host of a mobile/portable device is designated by several properties, including its identity, viz. H = {hidH , λH , η H }
s s
where, H represents the host of a mobile/ portable device having identity hidH and location λH . Nature of H are denoted by η H = η1H , η2H , . . .. A host is needed to provide the execution environment for the mobile applications. A base station is also designated by several properties, including its identity, viz. B = {bsidB , λB , η B }. Here, B represents the base station having identity bsidB and location λB . Its nature is denoted by η B = η1B , η2B , ... The base station provides the interface between wired and wireless network infrastructures during application-service interaction in mobile cloud computing. A cloud service is specified by several attributes, including its identity, its nature, its input and output sets etc., viz. S = {srvidS , λS , η S , I S , OS }. This definition abstracts away the inner details of each cloud service to keep the formal representation simple and focused on decoupling functionality of the proposed architecture. Here, S represents a cloud service, running in a particular data center. Nature of S is abstracted via η S = {η1S , η2S , . . .}, whereas its input parameters are denoted by I S = {I1S , I2S , . . .}. Similarly, the output parameters of S are designated using OS = {O1S , O2S , . . . etc.
3.2.2
Service Invocation
When a mobile application A requires assistance of the cloud service , it invokes that desired service by specifying its nature, instead of invoking it by its identity. This is represented formally as: invokeA (λA , η1A , . . . , η1s , . . . , P1s , . . .) (1)
s
s
In the above invoke, selective attributes of A and are specified by η1A , η2A etc. and η1s , η2s etc. respectively. Also, the required parameters for are specified by P1s , P2s etc. Stating the nature of service required during invocation has several implications. First, this process of service invocation advocates temporal, spatial and synchronization uncoupling during service access inside the cloud. These uncoupling dimensions within the cloud are also orthogonal to the uncoupling abilities considered in this paper. Second, separating the invocation from the access fits well with the service-oriented architecture, which is beneficial in many aspects. Third, the scalable data center networks work efficiently with this process of service invocation. Above invoke is next converted into the invoke tuple by H that is executing A. The invoke tuple, which is unordered in nature, comprises of several fields, each corresponding to an argument needed for the invoke of A. Formally, t A = {ti , aidA , λA , λH , η1A , . . . , η1s , . . . , P1s , . . .} (2)
s
where, aidA represents an identity of application A and ti denotes that it is of invoke tuple type (represented by subscript “i”). An approach of formalizing tuples, tuple spaces and tuple space operations can be found in [8]. Tuple spaces, present in the host H and the base station B, are denoted as TH and TB respectively. Both TH and TB follow the indexed structure, and they accomplish the uncoupling abilities via inject and eject. H and B decide on their usage during the application-service interactions. For instance, H inserts t A into TH by invoking inject(t A , TH ) (3) when the destination base station B, en route to the required cloud service , is not reachable. It is to be noted here that the unreachability of B is sporadic in nature, and is mainly due to the user-centric movement of host H, housed in a
s
mobile/portable device. However, once B is reachable, H withdraws t A from TH by invoking eject({ti }, TH ) (4) The routing decision of invoke tuple is system-independent, and so, no such information is embedded in that tuple. In the above call of eject, {ti } acts as the invoke antituple, which matches the invoke tuple t A present in TH . Nature of that tuple (viz. ‘invoke’) is sufficient to identify the pending invoke tuple(s) routed through B, and only one field corresponding to this attribute is present in the invoke antituple. Withdrawn invoke tuple(s), like t A , are then transferred to B for subsequent delivery to the cloud utility for granting access to the required service(s).
3.2.3
Service Response Delivery
Based on the nature of required cloud service the mobile application A provides during the service invocation (viz. η1s , η2s etc.), some service S is assigned by the cloud facility. Then, S extracts the service-related arguments from t A (viz. P1s , P2s etc.), and take them as input (viz. I1S , I2S etc.) to discharge the required service. While discharging service, S may use the additional information, like the different features of A specified by η1A , η2A etc. Output of S (viz. O1S , O2S etc.) for A is next converted into a response tuple. Like the invoke tuple, this tuple is also unordered in nature and comprises of multiple fields, corresponding to the results of service invocation by A. Formally, t S = {tr , aidA , λA , λH , O1S , O2S , . . .} (5) where, aidA and λA represent the identity and location of invoker A, λH denote the location of host of A, and tr denotes that this tuple is a response tuple (represented by subscript “r”). Also, the results of invokeA () are specified by O1S , O2S etc., which are the output of S. Eventually, t S reaches the base station B, where t S is inserted into TB by invoking inject(t S , TB ) (6) if the destination H supporting A is not available. The unavailability of H is also mainly due to the sporadic and user-centric movement of mobile/portable device hosting H. When H becomes available, B withdraws t S from TB by invoking eject({tr , λH }, TB ) (7) In this call of eject, {tr , λH } acts as the response antituple, which matches the response tuple t S present in TB . The nature of tuple (viz. ‘response’) as well as the location of target host H are sufficient to identify its response tuple, and so fields corresponding to these attributes are present in the response antituple. Withdrawn t S is then transferred to H for subsequent delivery to A.
3.2.4
Discussion
The formal representation of uncoupling abilities of the proposed mobile cloud computing architecture is presented in Section 3.2.2 and Section 3.2.3. In this representation, every invoke of the cloud service by any mobile application is propagated through the tuple space of the host supporting the application. Thus, the tuple space at the host-side uncouples the application invoke from its process of forwarding, as well as from its servicing. Similarly, in this representation, the response from the cloud service of each invoke of the mobile application is also propagated through
the tuple space of the ‘en route’ base station(s). This tuple space uncouples the service delivery from its process of forwarding. Moreover, the tuple spaces also separate the unavailability/unreachability concerns arising due to the mobile, dynamic and unreliable environments of wireless network infrastructures. Thus, the tuple space model uncouples the mobile applications and the cloud services during service invocation and delivery that improves the flexibility and efficiency of mobile cloud computing.
3.2.5
Validation
This work claims that the proposed architecture improves both the flexibility and efficiency of mobile cloud computing. This section validates both the claims by informal reasoning. The detailed proofs of verification are avoided here, as they are too much lengthy as well as cryptic.
versa respectively are represented in earlier sections. Tuple spaces in these representations can handle the case of unavailability of mobile hosts from base stations, by preserving these tuples in the designated tuple spaces until the targets become available. Using the proof logic of Mobile UNITY, it can be shown that these tuples are indeed transferred between mobile hosts and base stations. • Delivery of the received invoke or response tuples by hosts or base stations to the mobile application or the cloud service respectively is also specified in earlier sections. Using the proof logic of Mobile UNITY, it can be shown that these tuples are finally delivered to the mobile applications or the cloud services.
1) Reasoning about improvement in flexibility of mobile cloud computing. Intuitively, this claim can be shown to satisfy by the following steps.
• Above three reasoning combinedly ensure that the service invocation and delivery works correctly in the proposed architecture.
1. [Tuple space improves flexibility] First, it is argued that use of the tuple space model improves flexibility in mobile cloud computing. The tuple space model is renowned for uncoupling the interactions among the coordinating entities in several dimensions (namely, time uncoupling, space uncoupling, synchronization uncoupling, producer and consumer uncoupling, data access uncoupling etc.; most of these have been pointed out in [12], [14] and [10]). These multiple facets of uncoupling undoubtedly reduce the effect of tight coupling between the interacting entities when they use tuple space as coordination medium. Based on this behavior of tuple space, it can be concluded that reducing the tight coupling, by virtue of the tuple space model, in turn, improves flexibility between the applications and the services in mobile cloud computing.
3. Step (2) reasons about the correct working of the proposed architecture, whereas Step (1) argues that the flexibility improves when using tuple space for uncoupling. Combining these two facts, it can be concluded that the flexibility improves in the proposed mobile cloud computing architecture that incorporates the tuple space model as their uncoupling media.
2. [Proposed architecture works correctly] Next step is to show that the proposed mobile cloud computing architecture incorporating the tuple space model works correctly. This proof is based on the formal representation of the proposed architecture, which is presented earlier. • Insights of wireless communication between mobile host (that is executing a mobile application) and base station (that is en route to the cloud service) are abstracted away by formalizing the communication link as a (shared) variable. This approach is well-documented in literature (e.g. [17]). Transmission of the messages (containing the invoke tuples or the response tuples) from mobile host to base station and vice versa is modeled by assigning them to this variable at one host and subsequently reading them at another host. Based on the proof logic of Mobile UNITY, this abstraction can be used to show that the messages are transmitted at a time from mobile hosts to base stations and vice versa. • Transfer of the invoke or response tuples present inside the above messages in an uncoupled manner from mobile hosts to base stations or vice
2) Reasoning about improvement in efficiency of mobile cloud computing. This claim can be intuitively argued as follows. 1. The factors like mobility, dynamicity, and unreliability are crucial in performing data transmission in the wireless infrastructure networks. These factors together lead to the unreachability/unavailability condition that frequently and unpredictably occurs in such networks. The sporadic unreachability or unavailability is costly for every communicating device, including mobile device, base station etc. (for example, the repetitive attempts to transmit the data successfully during sudden unreachability and error-prone availability increases the bandwidth consumption). 2. In mobile cloud computing, these factors are prevalent to the same extent. Moreover, the service invocation and delivery in the existing mobile cloud computing architecture is mostly synchronous in nature. As a result, the effect of synchronous communication, in presence of the frequent and sporadic unreachability or unavailability condition, leads to the expensive applicationservice interactions in mobile cloud computing. 3. With the tuple space model as the uncoupling media, interaction between the mobile application and the cloud service is uncoupled in several dimensions, one of them being the asynchronous communication. These uncoupling effects minimize the expenses of sporadic unreachability or unavailability during data communication through wireless networks. Consequently, the efficiency of the proposed mobile cloud computing architecture improves.
4.
CONCLUSION
Mobile cloud computing is a future uprising segment of cloud computing, where the mobile applications can be supported by the cloud services. This paper has discussed a notion of uncoupling, which is not considered in the existing mobile cloud computing architectures, as a vital factor to improve the flexibility and efficiency of mobile cloud computing. This paper has also presented a new mobile cloud computing architecture, where uncoupling is introduced by distributing multiple tuple spaces in strategic locations. Furthermore, this paper has also exhibited an approach of representing the proposed architecture for analyzing its robustness during application-service interaction. Thus, the proposed mobile cloud computing architecture will truly abolish the fundamental constraints of mobile/portable devices, and enable the mobile users to enjoy genuine “ubiquity”.
5.
REFERENCES
[1] Amazon.com, Inc. “http://aws.amazon.com/ec2/”, 2006. [2] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia. A View of Cloud Computing. Communications of the ACM, 53(4):50–58, April 2010. [3] P. Bahl, R. Y. Han, L. E. Li, and M. Satyanarayanan. Advancing the State of Mobile Cloud Computing. In Proc. 3rd ACM Workshop on Mobile Cloud Computing and Services (MCS ’12), pages 21–27, June 2012. [4] B. Blakeley, H. Harris, and J. Lewis. Messaging and Queuing using the MQI. McGraw-Hill Pub., New York, USA, 1995. [5] G. Cabri, L. Ferrari, L. Leonardi, M. Mamei, and F. Zambonelli. Uncoupling Coordination: Tuple-Based Models for Mobility. In P. Bellavista and A. Corradi, editors, The Handbook of Mobile Middleware, chapter 10, pages 229–255. Auerbach Pub, 2007. [6] S. De and S. De. Uncoupling in Services of Mobile Cloud Computing using Tuple Space model: Design and Formal Specifications. In Proc. 1st ACM Workshop on Mobile Cloud Computing and Networking (MobileCloud 2013), pages 27–31, July 2013. [7] S. De, D. Goswami, and S. Nandi. A New Tuple Space Structure for Tuple Space based Mobile Middleware Platforms. In Proc. 2012 Annual IEEE India Conference (INDICON 2012), pages 705–710, December 2012. [8] S. De, S. Nandi, and D. Goswami. Tuple space enhancements for mobile middleware. Intl. Journal of Communication Networks and Distributed Systems. In Press. [9] S. De, S. Nandi, and D. Goswami. On Performance Improvement Issues in Unordered Tuple Space based Mobile Middleware. In Proc. 2010 Annual IEEE India Conference (INDICON 2010), December 2010. [10] S. De, S. Nandi, and D. Goswami. Modeling an Enhanced Tuple Space based Mobile Middleware in UNITY. In Proc. 11th IEEE Intl. Conf. on Ubiquitous Computing and Communications (IUCC ’12), pages 1684–1691, June 2012.
[11] H. T. Dinh, C. Lee, D. Niyato, and P. Wang. A Survey of Mobile Cloud Computing: Architecture, Applications, and Approaches. Wireless Communications and Mobile Computing, 2011. Available Online (http://dx.doi.org/10.1002/wcm.1203). [12] P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec. The many faces of Publish/Subscribe. Computing Surveys, 35(2):114–131, June 2003. [13] N. Fernando, S. W. Loke, and W. Rahayu. Mobile cloud computing: A survey. Future Generation Computer Systems, 29(1):84–106, January 2013. [14] D. Gelernter. Generative Communication in Linda. Transactions on Programming Languages and Systems, 7(1):80–112, January 1985. [15] Google Inc. “https://appengine.google.com/”, 2011. [16] R. Hunter. The why of cloud. “http://www.gartner.com/”, December 2011. [17] P. J. McCann and G.-C. Roman. Modeling Mobile IP in Mobile UNITY. Transactions on Software Engineering and Methodology, 8(2):115–146, April 1999. [18] Microsoft Corp. “office365.microsoft.com/”, 2011. [19] A. Monaco. A view inside the cloud. “http://theinstitute.ieee.org/technologyfocus/technology-topic/a-view-inside-the-cloud”, June 2012. [20] G. A. Papadopoulos and F. Arbab. Coordination Models and Languages. In M. V. Zelkowitz, editor, The Engineering of Large Systems, volume 46 of Advances in Computers, pages 329–400. Academic Press, 1998. [21] G.-C. Roman, P. J. McCann, and J. Y. Plun. Mobile UNITY: Reasoning and Specification in Mobile Computing. Transactions on Software Engineering and Methodology, 6(3):250–282, July 1997. [22] Salesforce.com Inc. “http://www.salesforce.com/service-cloud/”, 2009.
