CRESTED: A Mobile Cloud Architecture for Next Generation Social Applications

barbarousmonthΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 11 μήνες)

69 εμφανίσεις

CRESTED:A Mobile Cloud Architecture for Next
Generation Social Applications
Flavio Ishii
MADMUC Lab
University of Saskatchewan
SK S7N 5C9,Canada
foi822@mail.usask.ca
ABSTRACT
This paper introduces CRESTED,a scalable architecture
that is a hybrid of the recently proposed Computational
REpresentational State Transfer (CREST) architecture and
the Event-Driven Architecture (EDA).The CRESTED ar-
chitecture supports a cloud-based middleware targeting next
generation social applications.CRESTED-based systems l-
ter user-aware content fromsocial networking sites to mobile
phones in near real-time by choosing eventually consistent
data over guaranteed consistent data.CRESTED's middle-
ware utilizes Cloud Computing's elasticity properties and
popular social networking site APIs.CRESTED's client uti-
lizes mobile phone capabilities and push services.
The key benets for developing CRESTED-based systems
include:ubiquitous user experience,decrease in information
overload,decrease in mobile network trac,improved mid-
dleware accessibility and reliability,context-free scalability,
and agility.A number of these benets are achieved by ap-
propriately distributing computations (processes) across all
of its networked and storage components.The unique design
of the CRESTED architecture oers a novel way of combin-
ing existing protocols,web services,and architectures.
Keywords
Software Architecture,Cloud Computing,Social Comput-
ing,Mobile Computing,CRESTED,Event-driven Architec-
ture,Mobile Push,Computational REST,REST,scalability
1.INTRODUCTION
The popularity of recent technologies such as Cloud Com-
puting Services (CCS),mobile phones with Push and GPS
capabilities,and Social Networking Site (SNS) Application
Programming Interfaces (APIs) have given rise to many mo-
bile cloud applications.However,there is a need for an archi-
tecture built for constrained clients that scales and adopts
with the current and future demands,prompting the cre-
ation of this paper's proposed architecture.
Next generation social applications can be thought of as
companion applications to existing and popular SNS [3,8,
14].They do not compete with SNSs but leverage their
user base and consume their API services to satisfy a more
focused demand for relevant information.Mobile phone ap-
plications are tting for such a social,focussed,and ad-hoc
context.
The architecture introduced in this paper takes a unique
approach for providing scalability with distributed compu-
tations (processes) and near real-time content delivery,with
a subscription-based and Event-Driven Architecture (EDA)
[24,31].It supports a distributed system through the use
of functional programming language concepts,in what has
been coined Computational Representational State Transfer
(CREST) by Erenkrantz et al in [29].CREST allows data
exchanges as well as computational expression exchanges be-
tween client and server,by having client accessible compu-
tational resources.
The use of CREST and EDA formalize the proposed ar-
chitecture called CRESTED.The CREST element allows
clients to communicate with the server in a richer format,
where the resource representation in a request or response
contains a computational expression,meta-data,and/or com-
mon data.The EDAelement of CRESTEDallows the server
to initiate the communication by pushing CRESTful content
for the client to act on.
The next section discusses how mobile and social require-
ments impact the design and selection of the dierent tech-
nologies involved in the CRESTED architecture.Section 3
provides the CRESTEDaxioms as well as a general overview
of the CRESTED network cycle.Section 4 goes in-depth
with the description of the CRESTED components,includ-
ing the suitable technologies for implementing them.The
last three sections go over the potential pitfalls of the archi-
tecture,the future work,and the conclusion for this work.
2.LITERATURE REVIEW
2.1 The Mobile Social Impact
There are many general Social Networking Sites (SNS)
with hundreds of thousands and in some cases millions of
users [16].The sheer number of SNS users can be leveraged
to create simpler companion social applications that target
specic needs of the users;this paper refers these applica-
tions as next generation social applications.
ASNS provides an overwhelming amount of social content
for users to consume,leading to information overload [12];
a major reason for users to ea from a SNS.There has been
a recent trend for SNS to streamline the information they
are supplying in the form of status updates or news feeds
and also to mashup information from other SNS [14,5,3].
However,this eort is a temporary solution for the informa-
tion overload issue,as more and more people are joining and
connecting with others in SNSs.
Information overload can result in the user retiring from
the social application or somehow changing his/her commu-
nication channels in the application.One of the goals of
social applications is to avoid loosing users,which means
avoiding information overload by mapping and ltering the
social content from SNS.As pointed out in [12] these solu-
tions go against virtual group behavior,since content from
the group may be missed resulting in decreased social par-
ticipation.But next generation social applications target
the individual's needs for relevant information,which has a
higher probability of sparking social participation.The ar-
chitecture proposed allows the development of applications
that make use of a User Awareness Computations Model
(UACM) to help lter the abundance of information.
The number of mobile phone subscriptions have been on
the rise and will continue to do so at alarming rates with 6
billion expected by 2013 [15],surpassing the number of com-
puters in use.Mobile phones are carried around most places
and are considered very personal by their owners [47],mak-
ing them ideal for social applications.Statistics [45] show
that over 81%of a mobile user's intent is to socialize through
dierent mediums as (but not including phone calls):social
application,text message,email,sharing photos and docu-
ments,and video games.There are many capabilities inte-
grated in mobile phones now that allow their users to have
a rich and ubiquitous experience [32].
Mobile social applications have been on the verge of main-
stream popularity as of lately.There is an abundance of
mobile applications with social elements found in online ap-
plication stores like Apple's AppStore,RIM's AppWorld,
and Android Market.There have also been some studies
done [27,37,33,39] discussing user-awareness in mobile
applications,which is what the CRESTED architecture is
targeting.
The research conducted in this paper takes a dierent ap-
proach from the architectural topics covered in similar stud-
ies [31,36,38,25,43].Past studies have covered the mashup
of SNS APIs,context-aware data,and architectures that sat-
isfy the current needs of a mobile social application.This
paper satises the current and future needs of mobile social
applications.
2.2 Protocols and Architectures
A number of protocols and architectures have been re-
viewed in order to adequately select themfor the CRESTED
architecture.This subsection discusses the following re-
searched technologies:Simple Object Access Protocol (SO-
AP),HyperText Transfer Protocol (HTTP),Service-Orien-
ted Architecture (SOA),Representational State Transfer (R-
EST),Computational REST (CREST),long polling pro-
tocols,EDA,mobile push services,and Publish-Subscribe
techniques.Out of these SOAP and long-polling protocols
were found to be unsuitable.
SOAP [17] is used to exchange XML messages across pre-
dened web services in a client-server architecture.It has
a well dened and easy to follow protocol stack.SOAP is
often used in a SOA,where web services can be mashed
up to create the required result and the provider and con-
sumer of the web services are bound to each other's state.
SOAP provides a higher level of abstraction and more se-
curity protocol options.However,SOAP requires the web
service provider to continuously add new web services or to
understand a number of web services to properly format the
data according to the needs of dierent clients.This cycle
and procedure tends to be costly,not scalable,and hard to
maintain for the provider and consumer.
Table 1:RESTful HTTP Method Conventions.
Method Mapped Action
POST Create a single record or all records
dened in the body,or/and replace
single specied record or a set of
matching records.
PUT Update a single specied record or all
matching records.
GET Retrieve a set of resources or a single
resource by specifying its ID.
DELETE Remove a resource or all resources.
REST [30] is an architecture as oppose to a protocol,like
SOAP;therefore it does not have built-in rules.Misinterpre-
tations of RESTguidelines [49] are common;however,REST
allows for ner granularity services in a stateless context,
providing scalability.Unlike SOAP,the REST architecture
fully embraces and makes use of HTTP.Table 1 lists the
mapping of the limited set of HTTP methods to RESTful
actions.
REST makes use of Unique Resource Identiers (URI)
to access dierent resources hosted in a server.A unique
resource may be a product or a customer prole in an e-
commerce store.AGETmethod request for http://www.est-
ore.com/product/5 contains a URI that returns a product
with an identier number of 5,if the resource exists and the
client has the authorization to access it.
There is some complexity in REST in the form of HTTP
method guidelines and HTTPcode handling (response codes)
[50],but this complexity may be handled by a number of
open toolkits [46,41].SOAP web services may be well suited
for the enterprise,where custom needs and costs are justi-
ed by the importance of mission critical data.In a social
application context the needs change rapidly,requiring a
granular set of RESTful web services for generic purposes.
The benets that come with SOAP based web services do
not outweigh the costs of supporting them and the exi-
bility of RESTful web services in the long run for a social
application.
A branch of REST that was studied is CREST,it adds
a computational expression option to a RESTful request
and/or response.In CREST,computations are transformed
into resources that are sent in a URL format or they are
enclosed within the content of a message.The capturing
of a computation into a resource is accomplished with the
functional programming language concepts of closures and
continuations [26],which are discussed in section 3.Adding
computations to RESTful web services not only inherits the
properties of REST but also creates a distributed computa-
tional system.CREST advocates the exchange of computa-
tions between clients and servers to decrease latency and
increase processing eciency,and ultimately energy con-
sumption eciency by making better use of the server or
client side capabilities.
Both RESTand CRESTsupport a stateless system,where
each request or computation contains all the information
necessary to performthe task.Similar to howfunctional lan-
guages treat functions as primitive,CREST treats compu-
tations as resources that are accessed via Uniform Resource
Identier (URI),stored in a message queue (or database),
and exchanged in a common notation format such as the
JavaScript Object Notation (JSON),or any other format
the middleware server recognizes.CREST is well suited for
constrained mobile platforms since it provides scalability,
decreases latency and network trac,and improves perfor-
mance.
EDAprovides a natural formof interaction in the Web and
social communication context.In a person's daily social lives
he/she initiates and reacts to various events.For example,
seeing his/her name mentioned in a Twitter status update
and replying to it is an event-driven activity.Events can
also occur on the server-side where nding some published
data in a web service request is an event that can trigger
some reaction.
A CRESTful system avoids the need for storing sessional
data in the server,but it still requires the client to poll the
middleware server for new data periodically.The alternative
to polling for recent data is the addition of a server-side EDA
component and mobile push service.Periodically requesting
data from services,also known as long polling,unnecessarily
consumes the systemresources,which must be avoided at all
costs when resource limited clients like mobile phones are a
part of the system.Implementing a server-side EDA further
de-couples the client's need to request for new data.
The need for long polling is avoided by using a service
subscription-based queue on the server-side that checks pe-
riodically for published content.A published event example
can be of a person updating their SNS's prole.The event
can match what a user had specied in the form of a sub-
scription computation item,stored in the queue,that can
trigger a proprietary mobile push service
1
call that channels
new content or computation to the mobile phone.Unlike
polling it does not require an active and ongoing commu-
nication link which consumes system resources,the client
simply listens for notications from the push server.
2.3 Cloud Computing Services
CCS oers a way to outsource dierent levels of the system
administration involved in an IT infrastructure.These levels
or layers of abstraction [22] include:Infrastructure as a Ser-
vice (IaaS),Platform as a Service (PaaS),and Software as
a Service (SaaS).IaaS being the lowest layer oers the most
control and exibility in terms of the development technolo-
gies that can be used;however,it requires more maintenance
work than the other layers.PaaS and SaaS have higher ab-
straction levels and require less maintenance,but they oer
less control over the development platform used.Providers
of CCS charge by an hourly rate,usage consumption,or a
combination of.These are tradeos that must be decided
on pragmatically,based on the application type,and future
intentions.
CCS has been the topic of many IT news stories and tech-
nical reviews.Many studies [28,35,22] discuss the benets
or pitfalls of CCS,but they do not discuss which CCS ab-
straction layer is adequate for a specic solution.There
is a lack of research in how to take advantage of CCS for
specic needs in an architecture.The CRESTED middle-
ware component is cloud-friendly,allowing the creation of a
scalable and distributed CCS network.Section 4.2 explores
1
Mobile push services are oered by the popular mobile plat-
forms,like Apple iPhone,PalmwebOS,and RIM.Since 2009
they have made push services available for any developer to
use for building real-time data applications.
the practical and adequate use of the CCS for the type of
applications the CRESTED architecture targets.
3.THE CRESTED ARCHITECTURE
3.1 The CRESTED Axioms
Table 2:CRESTED Axioms.
Clients generate the SNS API subscription computation,
or the RESTful web service request(s) for the SNS API.
These subscription may be repeatedly evaluated over a
period of time by the middleware.Computations are
accomplished with functional continuations and closures.
Subscription computations are stored as items in a mes-
sage queue,with a loosely structured and context-free
format for the purpose of agile development.
The message queue is stored in such a way that data
is eventually consistent as oppose to having guaranteed
consistency,something that is extremely complex if not
impossible to achieve in a social context due to limita-
tions imposed by SNS APIs.
An API response containing matched (or mapped) values
becomes a server-side event that triggers the mobile push
service,which sends the CRESTful message to the client
containing a CRESTful URL.Mapped data may be in-
serted into the closure,which is ltered with the latest
UACM values when necessary.
CRESTful URLs are spawned by the middleware and
consumed by the client for requesting mapped and l-
tered results.
Table 2 lists this paper's contribution as additional ax-
ioms to the REST and CREST axioms posed by [29].The
axioms describe the ability to generate,store,and commu-
nicate dynamic computations among the dierent architec-
ture components.These tasks are accomplished by having a
User Awareness Computations Model (UACM) to store the
computation and meta data in the form of functional lan-
guage concepts.UACM's meta data includes user awareness
parameters (i.e.user's current geo-location or dierent en-
vironment sensor readings) and user chosen parameters (i.e.
tag words for mashup services to match,or start and end
time).
The CRESTED architecture delegates computations us-
ing functional concepts to the component that has the ade-
quate capabilities to performthe task more eciently.Three
key functional concepts are recommended for a CRESTED
implementation:callback,closure,and continuation.
A callback allows for asynchronous calls to avoid stalling
a web application's screen (i.e.AJAX calls).Callbacks may
be used by the client's listener code,to invoke a function af-
ter receiving a pushed message.A closure uses the function
scope of the outer function by an inner function,granting
access to an outer function variable's value through the func-
tion from the object returned.Closures are used by contin-
uations,storing the state of a computation and allowing for
it to continute at a later time or in a dierent system com-
ponent.CRESTED uses continuations when a client-side
computation requires parameter values and results from the
middleware server in order to complete itself.
The functional concept of a closure and a continuation are
applied to the CRESTED process as follows:a client cre-
Figure 1:Typical Request/Response Scenario with
Middleware
Figure 2:CRESTED Client-Middleware-Service
Cycle
ates a closure containing the computational expression (an
HTTP request to the SNS API) along with a number of pa-
rameters;this closure is passed to the middleware's message
queue in order to be evaluated at a later time;the evaluation
of the computation map the results,which can require addi-
tional values fromthe client to further lter the results;once
the values arrive from the client the computation continues.
3.2 CRESTED Network Cycle
Figure 1 shows the typical RESTful request-response cycle
that a social mobile application may go through,in order
to retrieve information from SNS APIs.The middleware
is doing redundant and unnecessary work,keeping track of
SNS web services and user accounts in a database,querying
them,and then generating the appropriate requests.
The CRESTED version of this cycle,depicted in Figure 2,
adds the distribution of computations among the client and
server avoiding the extra work.It does add a subscription-
based EDA and the proprietary mobile push service,which
involves the periodic polling of the SNS APIs for near-real-
time data retrieval.This additional work done by the mid-
dleware is welcomed,since it has close to unlimited resources
due to its deployment in the cloud,unlike mobile phones.
These additions make the CRESTED architecture more e-
cient in terms of mobile network trac,while providing near
real-time data retrieval without the need for long-polling.
4.CRESTED COMPONENTS
Mobile applications require good network and power ef-
ciency;hence,the polling and push schemes done by the
middleware.The CRESTED architecture is designed for a
system that is event driven from Web published content.
Figures 3 and 4 help illustrate the components involved and
Figure 3:CRESTED System Components
Figure 4:CRESTED Sequence Diagram
the process of the exchanged computations,which depend
on the evaluating component's strengths and capabilities.
These illustrations can represent the scenario of a social no-
tication system,that allows users to subscribe to relevant
information from nearby published content of friends.Po-
tential results are mapped from SNS services,such as the
Twitter API for searching status updates and ltered using
the UACM.This scenario is implied throughout this section.
The architecture scenario showcases how well CRESTED
can guide developers for creating next generation social ap-
plications.The implementation tools should compliment
and enhance the benets of the architecture,while simpli-
fying its maintainability.This section discusses the archi-
tecture components in more detail and provides the recom-
mendation of certain open technologies for implementing a
CRESTED system.
4.1 Client
The CRESTED architecture's agile design considers up-
coming mobile client improvements such as:longer battery
life,widespread of Internet accessibility,bigger bandwidth,
more mobile phone capabilities,and better push services.
It also considers the current state of the art,making sure
that CRESTED built systems meet the constraints set by
current mobile phones.By doing so,the current CRESTED
features become more robust as the improvements emerge
over time.
The emergence of a number of thin-client solutions has
given the opportunity for a new set of rich Web-based ap-
plications.Social applications are among the most popular
to benet fromthese implementation technologies,which in-
volve the combination of:Web standard technologies (HTML,
Javascript,and CSS) for aiding with the cross-platformclient
development,and RESTful Proxy/Mashup Server.
Mobile development platforms based on Web standard
technologies tend to be ideal for CRESTED,with the poten-
tial of using JavaScript closures for representing the UACM.
Web standard technologies platforms also simplify the cross-
mobile-platform [44,20,10] deployment;even if they are
platform-specic frameworks [9,23],because the user inter-
face code written in HTML and CSS can be re-used across
the mobile platforms with minor changes.The only compo-
nent requiring major modications is the JavaScript code.
Web standard technologies also has the largest pool of in-
formation resources and developers.
A recent emergence of granting more access to lower level
functionality is occurring in WebKit-based (some HTML5
compliancy) browsers and thus Web-based mobile applica-
tions [21,40,9,23].This lower level accessibility allows
applications to perform more complex tasks in a more e-
cient manner.These new capabilities can be harvested by
performing more local computation and local storage.
As an example the BlackBerry Widget [23] development
platform may be used to build the client application in the
CRESTED scenario proposed.The BlackBerry Infrastruc-
ture for Push Communication uses PAP V2.2 [19,18],a two
way protocol that supports sending XML and an embedded
JSON resource to JavaScript callback function (the listener
code) in BlackBerry Widget client application.PAP pro-
vides a conrmation that the client received the push con-
tent,in which case the push initiator,the middleware,can
performthe appropriate action for a successful or unsuccess-
ful push to the client.
4.2 Middleware
In the typical proposed scenario,the social content ex-
tracted from the SNS API call is created by a single user
and rarely updated once created.Old social content tend
to be discarded by the middleware and user once viewed,
but the middleware can keep this content in a separate log
database for data mining purposes.This disregard for old
content removes the complexities of creating schemas for the
data synchronization and consistency for all the systemcom-
ponents,and lowers the costs of maintaining the system.If
a user needs to refer to archived content,hey/she can do so
by searching the system.
BASE (Basically Available,Soft state,Eventually consis-
tent) data [42] in a social context is acceptable,given that
he/she is aware of the inconsistent nature of SNSs.In most
SNSs the data is only eventually consistent since the sys-
tem can become slow or unavailable at times,and the user
may create,update,and archive a posting at anytime he/she
wishes.It is for this reason that CRESTED uses a message
queue for the temporary storage of computations and re-
sults as oppose to a full edged implementation relational
database.Scalable relational databases are costly to main-
tain;there is no need for the added complexity of a relational
database for managing CRESTED processes and data.
Figure 4 illustrates the sequence of all component interac-
tions in the CRESTED implementation scenario of a user-
aware notication system.It outlines the process from gen-
erating a subscription computation by the client,to storing
it on the middleware,to evaluating it periodically on the
middleware for fetching matched data,to pushing notica-
tions in the form of CRESTful URLs,and nally to sending
the computation results back to the client.The architec-
ture allows the middleware tasks to be done in a parallel
and distributed fashion,while also supporting clustered en-
vironments.The system can,therefore,handle more client
requests and subscription executions than in a conventional
fashion.Reliability can also be achieved,in case one server
goes down or takes more than a certain time threshold to
respond another server is used.
The rst URL request in Figure 4 shows that URIs have
a"fSubscription
JSONg"which includes a computation ex-
pression like"GET http://.../search
data/xyz".It can also
contain a"fUACM
JSONg",representing a JSON like"fun:
avio,lat:52.1167,lon:-106.6333,500g".The middleware then
accepts these computational expressions and complex data
instead of just simple data,freeing up resources by allowing
itself to focus more on the computation itself,as oppose to
parsing database queries and generating the computations.
The middleware deployment can be to a Platform as a
Service (PaaS) provider [7,4,6] or an IaaS provider [1,11].
The majority of PaaS providers suer from vendor lock-in
and target general purpose Web applications.The Smart
Platform PaaS,however does have some potential since it
provides an open platform,which can be installed in a dif-
ferent host,and it supports server-side JavaScript.Having
server-side JavaScript can simplify the implementation of
CRESTED systems since it would have a single language
across the client and server components.The present ideal
choice for the middleware deployment is in an IaaS,which
allows developers or systemadministrators to install any de-
velopment platform in a server instance and create a cluster
of cloned servers.This exibility and control gives applica-
tions horizontal scalability and allows the code to be simply
ported or cloned on to another IaaS provider.
Erlang [2] is a suitable developing platform language for
the cloud-based middleware.Erlang is an open source func-
tional language that is industry tested for distributed and
reliable systems.There is an Open Source Web toolkit that
is ideal for the CRESTED architecture called Webmachine,
that can take in computations as RESTful requests and sup-
ports spawned or dynamic CREST URLs.Erlang-based
tools and modules allow for a tighter integration coupling
across the server-side mapping between URI,computation,
and storage.
The Erlang-based Webmachine server has fault tolerance
and concurrent attributes for managing the client subscrip-
tions,client requests,server push requests to the proprietary
mobile push service,and mashup processing.It stores data
to be consumed by client requests as well as the JSON clo-
sures sent from the clients,used to gather the stored data.
The closures are stored in a queue in order to send requests
to third party APIs and lter the data received.Matched
data event triggers the push request,which does not contain
the data but rather meta-data so as not to force-feed data
to the thin clients.
The CRESTED middleware can also use Erlang's Term
Storage modules,ETS and DETS [34].These modules al-
lows for the storage of unstructured data or complex objects
with complex keys,ideal for storing UACM records.Each
middleware instance (node) can have its own Webmachine,
ETS and DETS processes.The termstorage nodes will share
Figure 5:The scalability,accessibility,and reliabil-
ity of CRESTED's middleware
data for resiliance and fault taulerance reasons.
The middleware can take advantage of the concurrent
properties of Erlang,providing the possibility to easily bun-
dle the middleware server and term storage as a node and
replicate it (not necessarily the data) across dierent nodes,
machines,and networks.These bundles can be hosted in
Rackspace Cloud Server [11] and AWS EC2 [1];the CREST-
ful URL pushed to the client will tell whether to use one CCS
provider over the other.Figure 5 illustrates this dependabil-
ity and scalability possibilities for the network interactions
between the client and middleware server clusters.Because
the system is being distributed across Rackspace and EC2,
an outage of a CCS provider should not prevent the client
from making some use of the system.
A middleware component that has been mentioned in this
section and does not interfere with the functionality of a
CRESTED application is the data mining of valuable data.
Data can be mined as events initiated by the user or server
occur,storing valuable information,such as user activity
logs tied with the user awareness information (time and
place).An SNS is valued for the data it retains not so much
for its features,making data mining a very important con-
sideration for next generation social applications.
4.3 Proprietary Mobile Push Service
The mobile device's middleware infrastructure is a re-
quired proprietary component in the CRESTED architec-
ture,since it makes the mobile push capability possible.
Dierent mobile platforms have dierent proprietary infras-
tructures.The proprietary push service can be deployed by
a telcom Carrier or a phone maker/platform (i.e.Apple,
RIM,Palm).They pose bottleneck and control limitations
but architectures need to embrace themin order to eciently
supply clients with real-time data,at least for the time be-
ing.The architecture may also support future alternatives
that may be more open as oppose to the proprietary solu-
tion.The alternative to push,long-polling,is far from ideal
for mobile devices.
5.POTENTIAL PITFALLS
There are some pitfalls to look out for when developing a
CRESTED system.One being the improper use of CREST
URLs for malicious reasons,unintentional,or laziness.Ma-
licious intent can be avoided by taking the right security
measurements such as authentication requirements,private
networks,or HTTPS.Unintentional and lazy use of CREST
URLs are harder to enforced by the implementation,they
are by-products of any architecture implementation,which
must be carefully avoided by fully understanding the con-
cepts,standards,and guidelines.
CRESTED's bottleneck and weak point is the proprietary
mobile push service infrastructure.These services can set
limitations in the data amount and data type transfered,and
the number of pushes for a period of time.Batch processing
the messages can be an option at the cost of loosing the real-
time user experience.The monitoring and regulation need to
be implemented at the client and middleware application
level to make the system fault tolerant.
The CRESTED client application also has a drawback in
that it needs to know in advance the supporting SNS API
call structures in order to generate the computations.This
is a minor issue since there are only a few popular SNSs that
social applications will likely support.But if there is a need
to support a custom or private SNS the client application
will either not be able to or has to allow the user to setup
such requests,a complex user interface design challenge.
One of the purposes of CREST is to clarify guidelines
for Web-driven RESTful development.However,CRESTful
guidelines (axioms) may take some time for an average Web
developer to embrace,since functional concepts such as con-
tinuations and closures are not common knowledge.These
systems are more complex to design and tend to add com-
plexity to the simplistic nature of the RESTful way.There-
fore,the trade o of using CREST,and thus CRESTED,
over REST must be considered.
6.FUTURE WORK
The system for the scenario described in this paper is cur-
rently being developed.As described in section 4,this sys-
temwill have near real-time notications of relevant content,
based on published events fromSNS APIs that a user is sub-
scribed to.The content is retrieved in a CRESTED fashion
by the mobile phone.This implementation will highlight
the key features of CRESTED as described in this paper
and will help evaluate the architecture.
The client-side evaluation will include the BlackBerry mo-
bile phone and an systemmonitoring application called Task
Manager for measuring the processing latencies,and energy
and memory consumptions.Evaluations will be conducted
for pre and post CRESTED interactions,in other words a
typical system (Figure 1) versus a CRESTED system (Fig-
ure 2).The middleware evaluation will help nd the upper
limits of the server requests for dierent machine congura-
tions,and based on the expected usage nd the most cost
optimal CCS setup for a particular type of application.The
Tsung [13] load testing evaluation tool will be used on the
middleware to record:stress test,maximum throughput for
one then for two middleware servers;latency from compu-
tation evaluation to result storage and push request;error
rates;resource consumption of memory and processing.
Another useful evaluation would be to compare and eval-
uate the systemwith and without the secondary middleware
server,as illustrated in Figure 5.The threshold for requests
served will be found and compared for each case,showing
whether the simple operations performed on the client make
an impact on the performance of the middleware.
The message queue schema can be replaced with PubSub-
Hubbub [48] in the middleware.More research needs to be
done on PubSubHubbub,a publish-subscribe system com-
ponent for fetching real-time updates from multiple third
party services.It uses long polling to nd published con-
tent,matching subscription record data with map,lter,
and reduce for soft real time.
A User evaluation can prove to be useful by raising the
issue of missed results from the subscription computations,
while also evaluating the information overload impression
and providing general feedback.As part of the user evalua-
tion it would help to conduct a social case study to demon-
strate people's expectations of how social mobile applica-
tions behave,and to provide a stronger case for the CREST-
EDapplication's requirements set forth;specically the data
consistency compromise.As previously discussed,data con-
sistency is not as crucial in social applications as they are in
mission critical enterprise applications.
The use of Bluetooth for nding nearby users of the same
network can prove to be very benecial.There is need in
social applications for users to communicate with each other
in real-time through means other than voice calls and text
messaging,which may apply extra charges.A user can nd
others nearby and communicate with them via bluetooth,
cutting down on latencies from network pings and server
processing.Future mobile applications may even have video
and voice streams over Bluetooth.
Future CCS oerings by the PaaS layer may make it more
suitable for the deployment of the middleware.There can
be new features for cloud interoperability such as the import
and export of server images fromdierent vendors.The pos-
sibility and eect of this scenario on the architecture needs
more careful analysis to have a more robust architecture.
7.CONCLUSIONS
Applications that combine social elements with mobile
phones are just starting to gain momentum among users.
The fast paced arena of social mobile applications requires
a novel architecture that allows future components and fea-
tures to be easily integrated.This paper introduced the
design and potential of the CRESTED architecture,a hy-
brid of Computational REST and Event-Driven architec-
tures.The CRESTED axioms presented,in addition to the
REST and CREST axioms posed by [29],serve as a guide for
developers to produce scalable,distributed,and agile social
applications.
The CRESTED architecture makes eective use of:mo-
bile phone capabilities,CCS-deployed middleware with a
computational message queue,intermediary map and lter
techniques,proprietary push service support,and mashup of
third party SNS APIs.CRESTED uniquely brings together
dierent protocols,functional concepts,and architectures to
solve the challenges of developing next generation social ap-
plications.This paper outlined the design,features,guide-
lines,and potential of the CRESTED architecture.
The next generation social applications act more like no-
tication systems due to the abundance of information that
is and will become available to users.The design decisions
discussed in this paper such as the use of a CREST-based
architecture over SOAP,the implementation of EDA with
the mobile push service over client long-polling,and the user
acceptance of eventual consistency over guaranteed consis-
tency are all justied by the mobile social context.However,
the implementation and evaluation work are still required to
ne tune the architecture and prove its eectiveness.
8.REFERENCES
[1] Amazon web services."http://aws.amazon.com/".
[2] Erlang."http://www.erlang.org".
[3] Facebook."http://www.facebook.com".
[4] Google app engine.
"http://code.google.com/appengine".
[5] Google buzz."http://www.google.com/buzz".
[6] Heroku."http://www.heroku.com".
[7] Joyent smart platform.
"http://www.joyent.com/products/joyent-smart-
platform/".
[8] Myspace."http://www.myspace.com".
[9] Palm webos."http://developer.palm.com".
[10] Phonegap."http://phonegap.com".
[11] Rackspace cloud."http://www.rackspacecloud.com".
[12] Time to split,virtually:Expanding virtuaal publics
into vibrant virtual metropolises.
[13] Tsung - a distributed load testing tool.
"http://tsung.erlang-projects.org".
[14] Twitter."http://www.twitter.com".
[15] Portio research mobile factbook 2009.Portio
Research,2009.
[16] List of social networking websites.
"http://en.wikipedia.org/wiki/List
of
social
networking
websites",March 2010.
[17] Soap."http://en.wikipedia.org/wiki/SOAP",March
2010.
[18] Alliance,O.M.Push access protocol specication,
version 29-apr-2001.
http://www.openmobilealliance.org/tech/aliates/
wap/wap-247-pap-20010429-a.pdf,April 2001.
[19] Alliance,O.M.Oma push v2.2.
"http://www.openmobilealliance.org/Technical/
release
program/push
v2
2.aspx",March 2010.
[20] Appcelerator.Appcelerator titanium.
"http://www.appcelerator.com".
[21] Apple,and Community,O.S.The webkit open
source project."http://webkit.org",February 2010.
[22] Armbrust,M.,Fox,A.,Griffith,R.,Joseph,
A.D.,Katz,R.,Konwinski,A.,Lee,G.,
Patterson,D.,Rabkin,A.,Stoica,I.,and
Zaharia,M.Above the clouds:A berkeley view of
cloud computing.Tech.rep.,UC Berkeley Reliable
Adaptive Distributed Systems Laboratory,2009.
[23] BlackBerry.Blackberry widgets.
"http://www.blackberry.com/developers/widget",
February 2010.
[24] Buford,J.,Wu,X.,and Krishnaswamy,V.
Spatial-temporal event correlation.In IEEE ICC 2009
Proceedings (233 Mt.Airy Road,Basking Ridge,NJ
07920,USA,2009),Avaya Labs Research.
[25] Chang,Y.-J.,Liu,H.-H.,Chou,L.-D.,Chen,
Y.-W.,and Shin,H.Y.A general architecture of
mobile social network services.In Proceedings of the
2007 International Conference on Convergence
Information Technology (2007),IEE Computer
Society,pp.151{156.
[26] Crockford,D.JavaScript:The Good Parts.
O'Reilly Media,2008.
[27] de Farias,C.R.G.,Leite,M.M.,Calvi,C.Z.,
Pessoa,R.M.,and Filho,J.G.P.A mof
metamodel for the development of context-aware
mobile applications.In Symposium on Applied
Computing - Proceedings of the 2007 ACM Symposium
on Applied Computing (Seoul,Korea,2007),no.2007,
ACM,pp.947{952.
[28] du Pre Gauntt,J.The service is the platform:
Mobile cloud computing's challenge to mobile & it
industries.Tech.rep.,2009.
[29] Erenkrantz,J.R.,Gorlick,M.M.,and Taylor,
R.N.Crest:A new model for decentralized,
internet-scale applications.Tech.rep.,Institute for
Software Research,University of California,Irvine,
2009.
[30] Fielding,R.T.,and Taylor,R.N.Principled
design of the modern web architecture.In ACM
Transactions on Internet Technology,vol.2.ACM,
May 2002,pp.115{150.
[31] Filho,R.S.S.,de Souza,C.R.B.,and
Redmiles,D.F.The design of a congurable,
extensible and dynamic notication service.In
Proceedings of the 2nd International Workshop on
Distributed Event-based Systems (2003).
[32] Fortunati,L.The mobile phone:Towards new
categories and social relations.Information
Communication Society 5,4 (2002),513{528.
[33] Humphreys,L.Mobile social networks and social
practice:a case study of dodgeball.Journal of
Computer-Mediated Communication 13,1 (2007).
[34] Ishii,F.Erlang data storage modules tutorial.Erlang
Workshop,
"http://www. avioishii.com/2009/10/erlang-
workshop-slides/",September
2009.
[35] Klems,M.,Nimis,J.,and Tai,S.Do clouds
compute?a framework for estimating the value of
cloud computing.WeB 2008 - The 7th Workshop on
e-Business,April 2008.
[36] Li,X.,Guo,L.,and Zhao,Y.E.Tag-based social
interest discovery.In International WWW Conference
(2008),pp.675{684.
[37] Melinger,D.,Bonna,K.,Sharon,M.,and
SantRam,M.Socialight a mobile social networking
system.In Poster Proceedings of the 6th International
Conference on Ubiquitous Computing (Nottingham,
England,2004).
[38] Miluzzo,E.,Lane,N.D.,Fodor,K.,Peterson,
R.,Lu,H.,Musolesi,M.,Eisenman,S.B.,Zheng,
X.,and Campbell,A.T.Sensing meets mobile
social networks:The design,implementation and
evaluation of the cenceme application.In Conference
On Embedded Networked Sensor Systems,Proceedings
of the 6th ACM conference on Embedded network
sensor systems (2008),ACM,pp.337{350.
[39] Mistry,P.,Maes,P.,and Chang,L.Wuw - wear
ur world:a wearable gestural interface.In Conference
on Human Factors in Computing Systems (2009),
pp.4111{4116.
[40] Nokia.Nokia ovi sdk.
"http://www.forum.nokia.com/Ovi",February 2010.
[41] Ogbuji,U.Mix and match web components with
python wsgi.
"http://www.ibm.com/developerworks/library/wa-
wsgi",August
2006.
[42] Pritchett,D.Base an acid alternative.ACM Queue
6,3 (May/June 2008),48{55.
[43] Rana,J.,Kristiansson,J.,Hallberg,J.,and
Synnes,K.Challenges for mobile social networking
applications.In Lecture Notes of the Institute for
Computer Sciences,Social Informatics and
Telecommunications Engineering (2009),vol.16,
Springer Berlin Heidelberg,pp.275{285.
[44] Rhomobile.Rhodes framework.
"http://rhomobile.com/products/rhodes/".
[45] RuderFinn.Mobile intent index.
"http://intentindex.com/mobile",February 2010.
[46] Sheehy,J.,and Vinoski,S.Developing restful web
services with webmachine.The Functional Web
(2008).
[47] Srivastava,L.Mobile phones and the evolution of
social behaviour.In Behaviour and Information
Technology (2005),vol.24,pp.111{119.
[48] Users,W.Pubsubhubbub.
"http://code.google.com/p/pubsubhubbub",February
2010.
[49] Vinoski,S.Restful web services development
checklist.Tech.rep.,Verivue,2008.
[50] W3C.Http 1.1:Method denitions.
"http://www.w3.org/Protocols/rfc2616/rfc2616-
sec9.html",March
2010.