U.S. patent application number 16/829426 was filed with the patent office on 2020-09-24 for sync as a service for cloud-based applications.
The applicant listed for this patent is Citrix Systems, Inc.. Invention is credited to Steven Dale McFerrin, Gustavo Teixeira Pinto, Philip John Wiebe.
Application Number | 20200301887 16/829426 |
Document ID | / |
Family ID | 1000004842971 |
Filed Date | 2020-09-24 |
View All Diagrams
United States Patent
Application |
20200301887 |
Kind Code |
A1 |
McFerrin; Steven Dale ; et
al. |
September 24, 2020 |
SYNC AS A SERVICE FOR CLOUD-BASED APPLICATIONS
Abstract
A technique provides sync capability as an independent backend
service, which developers can include, at their option, in their
cloud-based applications. In accordance with the improved
technique, a sync service runs in a backend system in connection
with a set of data. The sync service syncs changes in the set of
data among application instances that have access to the set of
data. Sync services may be specified selectively for different sets
of data, e.g., by specifying syncing for one set of data but not
for another set of data.
Inventors: |
McFerrin; Steven Dale;
(Boynton Beach, FL) ; Pinto; Gustavo Teixeira;
(Boynton Beach, FL) ; Wiebe; Philip John; (Davie,
FL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Citrix Systems, Inc. |
Fort Lauderdale |
FL |
US |
|
|
Family ID: |
1000004842971 |
Appl. No.: |
16/829426 |
Filed: |
March 25, 2020 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14644909 |
Mar 11, 2015 |
10614041 |
|
|
16829426 |
|
|
|
|
61954174 |
Mar 17, 2014 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 9/46 20130101; G06F
16/178 20190101; H04L 67/1097 20130101; G06F 16/27 20190101; H04L
67/1095 20130101; G06F 16/1827 20190101; G06F 3/06 20130101 |
International
Class: |
G06F 16/178 20060101
G06F016/178; H04L 29/08 20060101 H04L029/08; G06F 3/06 20060101
G06F003/06; G06F 9/46 20060101 G06F009/46; G06F 16/182 20060101
G06F016/182; G06F 16/27 20060101 G06F016/27 |
Claims
1. A method, comprising: storing data on a remote computing device,
the data being for an application executable on at least one client
device; storing settings in a database of the remote computing
device, the settings configured to, on a per-container basis, sync
data of the at least one client device with data of a container of
the database; and in response to (i) a change in data of the client
device and (ii) the database including settings to sync the data of
the at least one client device with the data of the container,
updating the data of the container.
2. The method of claim 1, further comprising providing entries in
the database for respective ones of the containers, the entries
indicating, on a per-container basis, whether to sync the
respective containers.
3. The method of claim 2, further comprising the entries
indicating, on a per-container basis, whether the remote computing
device employs a badging service, the badging service assigning a
syncing status to respective containers on an individual basis and
communicating the syncing status to the at least one client
device.
4. The method of claim 3, wherein the syncing status includes any
of (i) sync complete, (ii) sync in progress, and (iii) sync
failed.
5. The method of claim 2, wherein the containers include a
file-type container configured to store file-type data, and wherein
storing the settings in the database includes specifying sync
settings for the file-type container at an individual file
level.
6. The method of claim 2, wherein the containers include a
file-type container configured to store file-type data, and wherein
storing the settings in the database includes specifying sync
settings for the file-type container at a folder level.
7. The method of claim 2, wherein storing the settings includes
receiving, via an API (Application Program Interface), an
instruction specifying a particular container and providing
settings for the particular container.
8. The method of claim 7, wherein the containers include
identifiers that uniquely identify the containers in the remote
computing device, and wherein receiving the instruction includes
the identifier of the particular container.
9. The method of claim 7, wherein receiving the instruction
providing sync settings for the particular data storage container
includes an instruction to create the particular container in the
remote computing device.
10. A computing device, comprising memory and processing circuitry
coupled to the memory, the computing device constructed and
arranged to: store data on a remote computing device, the data
being for an application executable on at least one client device;
store settings in a database of the remote computing device, the
settings configured to, on a per-container basis, sync data of the
at least one client device with data of a container of the
database; and in response to (i) a change in data of the client
device and (ii) the database including settings to sync the data of
the at least one client device with the data of the container,
update the data of the container.
11. The computing device of claim 10, further constructed and
arranged to provide entries in the database for respective ones of
the containers, the entries indicating, on a per-container basis,
(i) whether to sync the respective containers and (ii) whether the
computing device employs a badging service, the badging service
configured to assign a syncing status to respective containers on
an individual basis and communicate the syncing status to the at
least one client device.
12. The computing device of claim 11, wherein the containers
include a file-type container configured to store file-type data,
and wherein storing the settings in the database includes
specifying sync settings for the file-type container at an
individual file level.
13. The computing device of claim 11, wherein the containers
include a file-type container configured to store file-type data,
and wherein storing the settings in the database includes
specifying sync settings for the file-type container at a folder
level.
14. The computing device of claim 11, wherein storing the settings
includes receiving, via an API (Application Program Interface), an
instruction specifying a particular container and providing
settings for the particular container.
15. The computing device of claim 14, wherein the containers
include identifiers that uniquely identify the containers in the
computing device, and wherein receiving the instruction includes
the identifier of the particular container.
16. The computing device of claim 14, wherein receiving the
instruction providing settings for the particular container
includes an instruction to create the particular container in the
computing device.
17. A method, comprising: storing data on a remote computing
device, the data being from an application executable on at least
one client device; storing settings in a database of the remote
computing device, the settings configured to, on a per-container
basis, enable syncing of data of the at least one client device
with data of a container of the database; and in response to a
change in the data of the application of the client device,
updating the data of the container.
18. The method of claim 17, further comprising providing entries in
the database for respective ones of the containers, the entries
indicating, on a per-container basis, (i) whether to sync the
respective containers and (ii) whether the remote computing device
employs a badging service, the badging service configured to assign
a syncing status to respective containers on an individual basis
and communicate the syncing status to the at least one client
device.
19. The method of claim 18, wherein storing the settings includes
receiving, via an API (Application Program Interface), an
instruction specifying a particular container and providing
settings for the particular container.
20. The method of claim 18, wherein receiving the instruction
providing settings for the particular container includes an
instruction to create the particular container in the computing
device.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of copending U.S. patent
application Ser. No. 14/644,909, filed Mar. 11, 2015, which claims
the benefit of U.S. Provisional Patent Application No. 61/954,174,
filed Mar. 17, 2014. The contents and teachings of both prior
applications are incorporated by reference herein in their
entirety.
BACKGROUND
[0002] Cloud-based applications are software applications that
employ services available over the Internet or some other network
to assist the applications in performing their various tasks. In a
typical scenario, a user installs a frontend client (e.g., an
"app") on a client device, which connects to a backend server over
the Internet. The frontend client typically manages a user
interface and performs local processing on the client device,
whereas the backend server may access large databases, store user
data, and perform computationally intensive tasks. Users currently
enjoy a wide range of cloud-based applications, including
applications for data storage, video streaming, web conferencing,
mapping, banking, and many others.
[0003] A common use for a cloud-based application is to provide
user data storage in the cloud. For example, a user installs a data
storage client on the user's device and designates a local folder
for storing files. Any time the user adds a file to the local
folder, the data storage client automatically uploads the file to a
backend system running in the cloud. The user may install similar
data storage clients for the same application on other devices, and
cloud-based services on the backend system coordinate with the
different devices to ensure that all the devices share the same
files and file versions. For example, when a frontend client on one
of the devices creates a new file, the cloud-based services sync
the new file to the other devices, so that each device stores an
identical copy of the file.
SUMMARY
[0004] Unfortunately, sync features available to application
developers are often inflexible and cumbersome. For example, a
developer of a cloud-based application may use a third-party
service for storing data in the cloud. But the third-party service
may provide limited flexibility as to whether it provides sync
features and to which data such sync services apply. In addition,
some third-party services require users to maintain accounts, which
are in addition to any account required by the application itself.
Although it is possible for developers to build their own storage
and sync solutions, which do not require the use of third-party
services, such solutions are complex and add significantly to the
overall effort of developing applications.
[0005] In contrast with the above-described conventional approach,
an improved technique provides sync capability as an independent
backend service, which developers can include, at their option, in
their cloud-based applications. A sync service runs in a backend
system in connection with a specified set of data. The sync service
syncs changes in the set of data among application instances that
have access to the set of data. The sync service allows syncing to
be specified selectively for different sets of data, e.g., by
specifying syncing for one set of data but not necessarily for
another set of data.
[0006] Advantageously, the improved technique provides developers
of cloud-based applications with the ability to include sync
capabilities simply by requesting them, e.g., via a simple API.
Thus, the developer is not forced to choose between inflexible,
cumbersome solutions from third party suppliers and spending
resources on developing their own data storage and sync
features.
[0007] Certain embodiments are directed to a method of syncing data
in a backend system that provides services for supporting
cloud-based software applications. The method includes storing, by
a data storage service in the backend system, a set of data used by
a cloud-based application. the data storage service storing the set
of data in response to storage instructions received from the
cloud-based application, the cloud-based application having a set
of application instances running on respective computing machines
operatively connected to the backend system over a network. The
method further includes storing, by the backend system, a set of
sync settings for the set of data, the set of sync settings
indicating whether the backend system employs a sync service for
syncing the set of data stored in the backend system by the data
storage service. The method further includes syncing the set of
data among the backend system and the set of application instances
in response to (i) changes in the set of data, and (ii) having
stored sync settings indicating that the backend system employs the
sync service for syncing the set of data.
[0008] Other embodiments are directed to a backend server
constructed and arranged to perform the method described above.
Still other embodiments are directed to a computer program product
embodying a non-transitory, computer-readable medium. The
non-transitory, computer-readable medium stores instructions,
which, when executed on one or more processors units of backend
system, cause the backend system to perform the method described
above. Some embodiments involve activity that is performed at a
single location, while other embodiments involve activity that is
distributed over a computerized environment (e.g., over a
network).
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0009] The foregoing and other features and advantages will be
apparent from the following description of particular embodiments
of the invention, as illustrated in the accompanying drawings, in
which like reference characters refer to the same parts throughout
the different views. In the accompanying drawings,
[0010] FIG. 1 is a block diagram of an example environment in which
embodiments of the invention hereof can be practiced;
[0011] FIG. 2 is a block diagram of an example application sandbox,
as shown in FIG. 1;
[0012] FIGS. 3a-3c are diagrams showing example databases for
realizing data storage containers and/or metadata thereof, for
file-type data, relational data, and key-value data,
respectively;
[0013] FIG. 4 is a block diagram showing an example arrangement in
which a first data storage container stores files of an end user
and a second data storage container stores both a user ID of the
end user and a unique ID of the first data storage container;
[0014] FIG. 5 is a diagram showing an example arrangement for
removing redundant copies of data storage containers;
[0015] FIG. 6 is a diagram showing an example arrangement in which
a data storage container is accessed from multiple cloud-based
applications; and
[0016] FIG. 7 is a block diagram showing an example arrangement in
which change notifications are generated and pushed to application
instances via a push service;
[0017] FIG. 8 is a diagram showing an example arrangement in which
a logical channel resolves a change notification into subscribed
application instances;
[0018] FIG. 9 is a diagram showing an example arrangement in which
a change notification is generated for changes to a file stored in
a data storage container; and
[0019] FIG. 10 is a block diagram showing an example arrangement in
which sync features are provided as a service in a cloud-based
application.
[0020] FIG. 11 is a diagram showing an example arrangement in which
the sync features are is used by a cloud-based application to sync
a file between devices.
[0021] FIG. 12 is a flowchart showing an example process for
syncing data in a backend system that provides services for
supporting cloud-based software applications.
DETAILED DESCRIPTION OF THE INVENTION
[0022] Embodiments of the invention will now be described. It is
understood that such embodiments are provided by way of example to
illustrate various features and principles of the invention, and
that the invention hereof is broader than the specific example
embodiments disclosed.
[0023] An improved technique provides sync capability as an
independent backend service, which developers can include, at their
option, in their cloud-based applications. A sync service runs in a
backend system in connection with a set of data stored by a data
storage service on the backend system. The sync service syncs
changes in the set of data among application instances that have
access to the set of data. Developers may specify the sync service
selectively for different sets of data, e.g., by specifying syncing
for one set of data but not for another set of data.
[0024] To assist the reader, this detailed description is provided
in sections as follows: [0025] Section I provides an overview of an
example environment and techniques for storing data on a backend
system. [0026] Section II describes a technique for sending push
notifications in the environment described in Section I. [0027]
Section III describes a technique for providing sync as a service
to a cloud-based application.
Section I: Overview of Example Environment and Techniques for
Storing Data on a Backend System
[0028] FIG. 1 shows an example environment 100 in which embodiments
of the improved technique hereof can be practiced. Here, developer
machines 110 (110(1), 110(2), etc.) and client machines 120 (e.g.,
120(1), 120(2), etc.) connect to a backend system 140 over a
network 130. Typically, a software developer operates each of the
developer machines 110 and an end user operates each of the client
machines 120. Each of the developer machines 110 runs a development
version of a frontend client (e.g., App1D, App2D), such as a
software program or "app," as well as a software development kit
(e.g. SDK1, SDK2), which a developer may use for programing the
frontend client to access services on the backend system 140.
Different SDKs may be provided for different front-end computing
platforms (e.g., Windows, OSX, iOS, Android, etc.) and/or for
different computer languages (e.g., Java, Ruby, Rails, Python,
Node, Objective C, etc.). In some examples, developer machines 110
access backend services directly, e.g., using a REST
(Representational State Transfer) interface, without the need for
an SDK.
[0029] Each of the client machines 120 includes a production
version of one or more frontend clients (e.g., App1P, App2P). In
this example, App1P is a production version of App1D and App2P is a
production version of App2D. Of course, developer machines 110 may
also run production versions of client frontends. In addition, any
of the machines 110 and 120 may run any number of frontend clients.
It should be understood that the arrangement as shown is merely
illustrative.
[0030] In an example, the backend system 140 provides services both
for developing cloud-based applications and for hosting cloud-based
applications and features. Thus, the backend system 140 may be used
at various times or simultaneously both by developer machines 110
and by client machines 120. The backend system 140 is seen to
include one or more network interfaces 142 (e.g., Ethernet and/or
Token Ring cards), a set of processors 144 (e.g., one or more
processing chips, blades, and/or assemblies), and memory 150. The
memory 150 includes both volatile memory (e.g., RAM) and
non-volatile memory, such as one or more disk drives, solid state
drives, data storage arrays, and the like.
[0031] The memory 150 stores software constructs for realizing
application sandboxes 160(1), 160(2), etc. (as many as desired), as
well as services 166 and data storage containers 170. The data
storage containers 170 provide data storage for the above-described
first and second cloud-based applications, and, generally, for any
cloud-based applications that the backend system 140 supports. A
set of storage devices (e.g., disk drives, flash drives, memory
chips, etc.) of the memory 150 provide physical media for storing
the data storage containers 170.
[0032] In an example, each of the application sandboxes 160(1) and
160(2) is dedicated to a respective cloud-based application and
operates a respective application backend for supporting the
cloud-based application. For example, sandbox 160(1) operates a
backend App1BE for supporting a first cloud-based application and
sandbox 160(2) operates a backend App2BE for supporting a second
cloud-based application. Here, App1BE is the backend that supports
frontends App1D and App1P. Likewise, App2BE is the backend that
supports frontends App2D and App2P. Note that the backends may be
segregated into development and production versions, in a manner
similar to that shown for the frontends. In an example, application
developers write the application backends either in situ on the
backend system 140 (e.g., over a web interface) or on developer
machines (e.g., 110). Developers may upload backends written on
developer machines to the backend system 140 once the
locally-developed backends are ready to be deployed. It should be
understood that some cloud-based applications may not require
application backends, per se. For example, some frontend clients
110 or 120 may access the services 166 directly over the network
130 without the use of application backends.
[0033] As shown, the services 166 include a data storage (DS)
service 168. The data storage service 168 manages the creation and
destruction of data storage containers 170. The data storage
service 168 also manages the storage and retrieval of data to and
from the data storage containers 170 and performs other functions.
Although this document refers to a data storage service 168 in the
singular form, it should be understood such the data storage
service 168 may include any number of services, functions, methods,
procedures, and so forth, which operate to manage data storage and
associated activities. The services 166 and data storage service
168 are so named because they perform services for cloud-based
applications and not because they are categorized as "services"
according to any particular operating system (e.g., these
"services" are required to be Windows services in the Windows
operating system). Rather, the backend system 140 may implement the
services 166 and 168 in any suitable software construct or
constructs.
[0034] In the example shown, each of the application sandboxes
160(1) and 160(2) has a respective set of service interfaces,
162(1) and 162(2). Although the services 166 may be common across
the entire backend system 140, the service interfaces 162(1) and
162(2) are each particular to a respective sandbox, such that
developers can access services within the context of each of the
application sandboxes 160(1) and 160(2) as if those services were
specific to the respective application.
[0035] The developer machines 110 and the client machines 120 may
each be implemented with any type of device (or devices) having
control circuitry (e.g., processing circuitry and memory), which is
provisioned for executing application frontends and communicating
over the network 130. The different machines 110 and 120 may be
implemented with any type or types of devices, and the types of
devices need not be the same. Such devices may be stationary
devices (e.g., servers, desktop computers, set top boxes, gaming
systems, etc.) or mobile devices (laptops, tablet computers, smart
phones, personal readers, etc.). The environment 100 may include
any number of developer machines 110 and/or client machines 112,
and the environment 100 need not include both types of machines.
The network 130 may be realized with any type of network or
networks, such as the Internet, a WAN (wide area network), a LAN
(local area network), or any other network or combination of
networks. The network 130 may be implemented with various
technologies, such as with wired and/or wireless technologies,
telephone systems, cell phone systems, microwave systems, infra-red
systems, and the like.
[0036] The backend system 140 may be provided as a server-grade
computing system that includes any number of individual computers,
networking components, and data storage arrays, which operate
together as a single system. However, the server 140 is not limited
to large-scale deployments and may be implemented on any scale with
any number of computing devices, including with a single computing
device. The set of processors 144 and the memory 150 of the backend
system 140, within its constituent device or devices, together
realize control circuitry, which is constructed and arranged to
carry out various methods and functions as described herein. Also,
the memory 150 includes a variety of software constructs realized
in the form of executable instructions. When the executable
instructions are run by the set of processors 144, the set of
processors 144 are caused to carry out the operations of the
software constructs. Although certain software constructs are
specifically shown and described, it is understood that the memory
150 typically includes many other software constructs, which are
not shown, such as an operating system and various applications,
processes, and daemons. The backend system 140 is amenable to
implementation on physical machines as well as on virtual
machines.
[0037] An example will now be presented for creating a new data
storage container 170a in the backend system 140 at the request of
the first cloud-based application. Although this example relates to
a particular data storage container created at the request of the
first cloud-based application, it should be appreciated that this
example can be applied more generally to describe the creation of
any data storage container 170 by any cloud-based application.
[0038] In this example, the data storage service 168 in the backend
system 140 receives a request 116a from the first cloud-based
application to create a new data storage container 170a. The
request 116a may arrive from the frontend client App1D on the first
developer machine 110(1), as shown, or from any other instance of
App1D, or from any instance of App1P. Alternatively, the request
116a may arrive from the backend App1BE or from any of the services
166, i.e., from a location internal to the backend system 140.
[0039] In response to the data storage service 168 receiving the
request 116a, the data storage service 168 creates the new data
storage container 170a. For example, the data storage service 168
generates metadata for the data storage container 170a and stores
such metadata in a database in the backend system, the purpose of
the database being to track information about data storage
containers.
[0040] The data storage container 170a provides a logical container
for storing data and has no assignment by the data storage service
168 to any end user of the first cloud-based application. Although
the first cloud-based application may certainly have end users
(e.g., users of various client machines 120), the data storage
service 168 creates the data storage container 170a without any
assignment to any end user. For example, the data storage service
168 does not assign the data storage container 170a to any end user
account, nor does it store any end user ID in the metadata created
for supporting the data storage container 170a. Even if the request
116a arrives from one of the clients 120, which is operated by an
end user, the data storage service 168 still does not assign any
user ID to the data storage container 170a. Rather, the data
storage container 170a is user-agnostic. As far as the data storage
service 168 is concerned, no end user owns the data storage
container 170a. The data storage container 170a is thus completely
independent of any end user, both in its definition and in its
access by the data storage service 168. As will be described more
fully below, the user-agnostic nature of the data storage container
170a (and, similarly, of all data storage containers 170) confers
many advantages both to application developers and to users.
[0041] Rather than providing access to the data storage container
170a in connection with any end user, the data storage service 168
instead generates a unique identifier (ID) (e.g., 116b) for the
data storage container 170a. The data storage service 168 then
proceeds to provide access to the data storage container 170a via
the unique ID 116b. Generating the unique ID 116b may be conducted
before, after, or simultaneously with the act of creating the data
storage container 170a. The unique ID 116b uniquely identifies the
data storage container 170a from among other data storage
containers in the backend system 140. In an example, the unique ID
116b of the data storage container 170a is unique across all of the
cloud-based data services provided by the backend system 140, as
well as across any similar backend systems that may coordinate with
the backend system 140 to provide cloud-based data services to
applications. The unique ID 116b may be generated in any suitable
way. For example, the unique ID 116b may be generated as an
automatically-incrementing integer, by a hash function, or by any
other suitable method.
[0042] Once the data storage service 168 has created the unique ID
116b, the data storage service 168 provides the unique ID 116b to
the first cloud-based application. For example, the data storage
service 168 returns the unique ID 116b to the developer machine
110(1), or, for example, to whichever other machine or software
construct originated the request 116a (or to any other designated
entity). After the first cloud-based application has received the
unique ID 116b, the first cloud-based application may use the
unique ID 116b for accessing the data storage container 170a, such
as for writing data to the data storage container 170a and/or for
reading data from the data storage container 170a.
[0043] In an example, the backend system 140 (or a software
construct operating therein), receives a storage request 118 from
the first cloud-based application. The request 118 specifies a set
of data to be stored and the unique ID 116b of the data storage
container 170a. For example, the frontend client App1D on machine
110(1) sends the storage request 118 to the backend system 140.
Upon receiving the storage request 118, the backend system 140,
e.g., acting through the data storage service 168, stores the set
of data from the request 118 in the data storage container 170a.
The first cloud-based application may similarly send a read request
to the data storage service 168, by specifying the unique ID 116b
of the data storage container 170a, to read data from the data
storage container 170a. In response, the first cloud-based
application may receive back the contents of the data storage
container 170a.
[0044] Providing access to data storage containers 170 and their
contents based on unique IDs enables cloud-based applications
flexibly to assign data storage containers 170 and their contents
to particular end users, to groups of end users, or to no end users
at all. Because access to data storage containers is based on
access to their respective unique IDs, developers can write their
cloud-based applications to provide selected users, or no users,
with access to data storage containers at their own option. But
granting access to users is done at the application level and not
in the data storage services 168 or in the data storage containers
themselves, which remain user-agnostic.
[0045] Data storage containers need not ever be assigned to any
user at all. For example, a cloud-based application may request a
new data storage container and proceed to store application
settings for the cloud-based application in the newly created data
storage container. The application settings may pertain to the
application but not to any particular end user of the application.
The data storage container storing the application settings may
thus never have an assignment to any end user.
[0046] In some examples, in addition to being user-agnostic, data
storage containers 170 are also application-agnostic. For example,
a data storage container need not include in its definition any
application-based context Likewise, the data storage service 168
need not assign the data storage container to any cloud-based
application. Rather, the data storage service 168 may flexibly
provide the unique ID of a data storage container, upon request, to
any number of cloud-based applications, enabling multiple
cloud-based applications to share data amongst one another.
[0047] It is thus evident from the foregoing that software
developers may use the data storage service 168 to provide
cloud-based data storage in the applications they design, without
requiring such developers to build their own backend storage
solutions or requiring users to log on to a separate storage
service. Because the data storage service 168 is user-agnostic, it
can provide storage containers for use with any applications or
users that have the respective unique IDs. The burden and
inconvenience to users and developers associated with conventional
cloud-based storage solutions are therefore overcome.
[0048] FIG. 2 shows an example application sandbox 160 in
additional detail. The application sandbox 160 may be
representative of the application sandboxes 160(1) and 160(2) of
FIG. 1. For example, the sandbox 160 includes an application
backend 212, which may correspond, for example, to backends App1BE
and App2BE of sandboxes 160(1) and 160(2), respectively. The
sandbox 160 further includes service interfaces 162, which
correspond, for example, to the service interfaces 162(1) and
162(2) as seen in FIG. 1. The application sandbox 160 further
includes a REST (Representational State Transfer) interface 210,
for communicating with application frontends (e.g., App1D, App1P,
App2D, and App2P). In an example, the REST interface 210 exposes an
API (application programming interface) for providing the frontends
with access to the application backend 212 and to the backend
services 166 (FIG. 1), i.e., through the service interfaces
162.
[0049] In an example, the application sandbox 160 (or each instance
thereof running on the backend system 140) provides backend support
for a respective cloud-based application, from the standpoints of
both developers and end users. The application sandbox 160 may
support multiple instances of the cloud-based application
simultaneously, e.g., as a consequence of multiple frontends
running on machines 110 and 120.
[0050] The service interfaces 162 provide interfaces (e.g., APIs)
into the services 166 (FIG. 1) in such a way that the services 166
as accessed through the service interfaces 162 are scoped to the
application sandbox 160 and thus to the particular cloud-based
application supported by the application sandbox 160. The service
interfaces 162 are seen to include, for example, a data storage
service interface 222, a web documents service interface 224, an
analytics service interface 226, and a user management service
interface 228. The service interfaces 222, 224, 226, and 228
provide access to respective sets of services 166 (FIG. 1). For
example, the data storage service interface 222 provides access to
the data storage service 168. Likewise, the web documents service
interface 224 provides access to a web documents service (within
the services 166), the analytics service interface 226 provides
access to an analytics service, and the user management service
interface 228 provides access to a user management service.
[0051] In an example, the particular cloud-based application served
by the application sandbox 160 may operate any of the service
interfaces 222, 224, 226, and 228 at the application's own option,
in accordance with the application's own programming. For example,
some cloud-based applications may include their own user
management, analytics, and/or web documents, and thus may opt out
of using the corresponding services 166 on the backend system 140
in favor of using their own.
[0052] It should be understood that nothing in the backend system
140 in any way prevents the existence or management of end users of
cloud-based applications that the backend system 140 supports.
Indeed, a user management service may expressly be provided.
However, any such user management service is decoupled from data
storage service 168 accessed through the data storage interface
222. Thus, for example, applications may avail themselves of the
user management service (through interface 228) to authenticate end
users and authorize them to access various resources. But such user
management is provided by the cloud-based application itself, e.g.,
acting alone or in connection with the user management service. In
any case, any such user management service is separate and distinct
from the data storage containers 170 managed by the data storage
service 168.
[0053] In some examples, the application sandbox 160 is configured
to generate credentials for particular services upon request. For
example, the application sandbox 160 generates each credential
based on a key and a secret. Once a credential is generated for a
particular service, for example, the credential is thereafter
required for accessing that service. Each credential may be
selectively scoped to any of the services 166, including to the
data storage service 168. Thus, for example, a cloud-based
application may request a credential for accessing a particular
data storage container 170. The generated credential is agnostic to
any end user or application, but the cloud-based application
receiving the credential may provide it to any user, group of
users, and/or application. Any entity in possession of the
credential may then access the data storage container 170 by
supplying an access request, which includes both the data storage
container's unique ID and the credential.
[0054] Considering the data storage interface 222 in additional
detail, it is seen that the interface 222 includes sub-interfaces
230, 240, and 250. In an example, data storage containers 170 (FIG.
1) are provided in three distinct types: file, relational, and
key-value. Each of the data storage containers 170 is configured
for storing one of these three types of data. Other types of data,
and/or a greater or fewer number of types of data, may be provided;
those shown are merely illustrative. Here, the sub-interfaces 230,
240, and 250 provide access to the data storage service 168 for
file-type data, relational-type data, and key-value-type data.
[0055] Each of the sub-interfaces 230, 240, and 250 includes a
respective "store" service interface (i.e., 232, 242, and 252) for
accessing data storage service 168 to create and destroy data
storage containers of the respective type, to read and write data
storage containers of the respective type, and to maintain their
metadata. Each of the sets of sub-interfaces 230, 240, and 250 also
includes a respective "push" service interface (i.e., 234, 244, and
254). Each push service interface provides access to the data
storage service 168 for pushing changes in contents of underlying
data storage containers to one or more subscribing application
instances. In addition, the file-type sub-interface 230 includes a
file sync service interface 236. The file sync service interface
236 provides access to the data storage service 168 for
synchronizing changes in contents of underlying file-type data
storage containers among subscribing application instances.
[0056] In an example, each data storage container 170 for file-type
data may store any number of files and/or folders, organized in any
suitable folder structure. The hierarchy may reflect, for example,
a folder hierarchy as may be found on a typical Windows or OSX
computer.
[0057] Each data storage container 170 for relational data may
store data in database form. For example, a data storage container
170 storing relational data may store data in schemaless database
format, such as in NoSQL format. Rather than having to implement
relational databases in the backend system 140, developers may
instead operate an SDK (FIG. 1) to define classes and fields
specific to their applications. Developers may further operate the
SDK to establish relationships among classes and fields, such as
one-to-one, one-to-many, many-to-one, and many-to-many. Cloud-based
applications may then read and write relational data to the defined
fields and classes, and may execute queries and generate reports,
without having to deploy relational database solutions.
[0058] Each data storage container 170 for key-value data may
simply store a key and a corresponding value. For example, a data
storage container 170 may store data for a person's first name by
specifying a key, e.g., "FirstName," and a corresponding value,
e.g., "Phil."
[0059] It has thus been described that the application sandbox 160
performs various activities on behalf of a particular cloud-based
application. These activities include providing a REST interface
210 to application frontends, housing an application backend 212,
and providing interfaces 162 to a variety of backend services 166.
The backend services 166 include the data storage service 168 for
creating and managing data storage containers 170 for three types
of data (file, relational, and key-value), for pushing changes in
underlying content to subscribing application instances, and for
providing services for synchronizing file-type data across
subscribing application instances.
[0060] FIGS. 3a, 3b, and 3c show example databases 310, 320, and
330 for storing data and/or metadata for file-type data storage
containers, relational-type data storage containers, and
key-value-type data storage containers, respectively. In an
example, the databases 310, 320, and 330 are realized in the memory
150 of the backend system 140 and are accessible by the data
storage services 168. In some examples, certain of the databases
310, 320, and 330 store contents of particular data storage
containers 170 as well as metadata describing their contents,
although this is not required. In addition, the databases 310, 320,
and 330 may be realized in any number or type of database
structures. For example, the databases 310, 320, and 330 may be
provided together in a single database or separately in multiple
databases.
[0061] FIG. 3a shows the database 310 for storing metadata for
file-type data storage containers. In an example, each row of the
database 310 (rows are indicated with ellipsis) stores metadata
pertaining to a respective file-type data storage container, which
may contain a respective file or folder. In an example, the
database 310 organizes metadata for file-type data storage
containers in the following fields: [0062] "Unique ID." The unique
ID that the data storage services 168 have generated for the data
storage container represented in the current row. In an example,
each file has a unique ID and each folder has a unique ID. No two
rows have the same unique ID. [0063] "Alias." A developer-assigned
alphanumeric name, which may be used in place of the Unique ID when
accessing the data storage container. In an example, a request to
create a data storage container (like the request 116a) includes a
parameter that specifies an alias as alphanumeric text. When
creating a data storage container in response to the request, the
data storage services 168 store the alias as metadata in the
database 310 in connection with the data storage container, such
that subsequent accesses to the data storage container may specify
the alias in place of the unique ID, which may be long and/or
difficult to remember. [0064] "File ID." If the current row
identifies a file, then the File ID is a hash of the file's
contents. If the current row identifies a folder, then the File ID
is a hash of the folder's contents. File IDs uniquely identify
files and folders based on their contents, and thus may be useful
in identifying and removing redundant copies of files and folders.
[0065] "Path." A path to the file or folder on the user's machine.
In an example, the indicated Path is relative to some designated
root location, which has been created on the user's machine to
store application content. [0066] "Geo-Loc." Geolocation
information (if available) of the device that created the data
storage container represented in the current row. Geo-Loc may
include, for example, GPS coordinates of the user's machine at the
time the container was created, as well as a timestamp. [0067]
"Store-Loc." The location of the file or folder described by the
current row in physical or logical storage. The Store-Loc thus
provides a way of accessing the underlying contents of the file or
folder from one or more storage devices (e.g., disk drives). [0068]
"Last Modified" timestamp. The last date and time that the data
storage service 168 last modified the file or folder described by
the current row.
[0069] Those skilled in the art will recognize that the database
310 may be structured in a variety of ways and may include a
variety of fields, including fields that are different from those
shown and described.
[0070] FIG. 3b shows a database 320 for relational-type data
storage containers. The database 320 may include fields for "Unique
ID," "Alias," and "Last Modified," which are similar to the
like-named fields described in connection with the database 310.
Here, however, fields may also be provided for "Class," "Key,"
"Value," and "Relationship." In an example, a "Class" may represent
a table of a database structure being defined for a respective
relational-type data storage container. A "Key" may represent a
database field within the table, and a "Value" may represents the
value to which the "Key" has been set. A "Relationship" may
represent how a current field relates to other fields and classes.
The table 320 may include additional or different fields, depending
on the type of relational data to be stored. Unlike the database
310, which stores locations of underlying content (files and/or
folders), the database 320 may store the actual contents of
relational data. Thus, in some examples, the database 310 includes
both metadata and relational data. In other examples, however, the
metadata and relational data may be separated in different
databases or data structures.
[0071] FIG. 3c shows a database 330 for key-value-type data storage
containers. The database 330 may include fields for "Unique ID,"
"Alias," and "Last Modified," which are similar to the like-named
fields described in connection with the database 310. The database
330 may also include fields for "Key" and "Value," which hold keys
and respective values of key-value pairs stored in the
key-value-type data storage containers. As with the database 320,
the database 330 may store both metadata and data. Alternatively,
the metadata and data may be stored separately.
[0072] FIG. 4 shows an example of one data storage container
storing information about another. Here, a cloud-based application
creates a file-type data storage container 410 at unique ID 567 and
stores therein files and folders belonging to a user, "Steve." The
cloud-based application also creates a relational-type data storage
container 420 at unique ID 4285 and stores therein two key-value
pairs. A first key-value pair associates a "userID" key with a
corresponding value, "sMcFerrin," and a second key-value pair
associates a "fileStoreID" key with a corresponding value, "567."
In an example, the data storage service 168 writes this key-value
data to the data storage container 420 in response to a user
storage request directed to the second data storage container 420.
In accordance with its programming, the cloud-based application may
interpret these key-value pairs to mean that the unique ID for the
file-type data storage container belonging to "sMcFerrin" is "567."
This example thus shows how a cloud-based application can use
inherently user-agnostic data storage containers to store data that
assists with user management.
[0073] FIG. 5 shows an example arrangement for consolidating
storage of file-type data stored in different file-type data
storage containers, thus making more efficient use of backend
storage. The illustrated arrangement shows portions of the database
310 (FIG. 3a). Certain fields and entries of the database 310 have
been omitted from FIG. 5 for the sake of simplicity. The
arrangement of FIG. 5 shows the storage of metadata for file-type
data storage containers both in a first state 510, before removing
redundant storage, and in a second state 512, after removing
redundant storage.
[0074] As seen in the first state 510, the database 310 includes
metadata for seven file-type data storage containers having
consecutive Unique IDs ranging from 1234 to 1240. Some of the
illustrated data storage containers store files while others store
folders. Each data storage container has a respective Alias, File
ID, and Store-Loc, where the File ID provides a hash of the
contents of the data storage container and the Store-Loc provides a
location on physical media (e.g., disk) of those contents. In this
first state 510, each data storage container has a different value
of Store-Loc, indicating that each data storage container consumes
its own respective back-end storage.
[0075] In accordance with further improvements hereof, the data
storage service 168 searches the database 310 to find duplicate
file content and performs consolidation operations to liberate
backend storage if any duplicate content is found. As the File ID
provides a hash of a data storage container's contents, the data
storage service 168 can compare hash values as an efficient proxy
for comparing content. The data storage service 168 thus searches
the database 310 for matching values of File ID. For any matches
that are found, the data storage service 168 liberates the backend
storage of each redundant copy and changes the Store-Loc field of
each redundant copy to reflect the physical storage location of the
single retained copy.
[0076] For example, as shown in the second state 512, the data
storage service 168 has changed the Store-Loc value for Unique ID
1237 (alias "File 3) to match that of Unique ID 1236 (alias "File
2"). This change reflects the fact that the data storage service
168 has found a match between the contents of File 3 and those of
File 2, as indicated by their matching File IDs. Likewise, the data
storage service 168 has changed the Store-Loc value for Unique ID
1239 (alias "File 4) to match that of Unique ID 1235 (alias "File
1"). This change reflects the data storage service 168 having found
a match between the contents of File 4 and those of File 1. In this
example, the data storage service 168 has freed the backend storage
found at Loc D and Loc F, which is no longer needed to support
storage of File 3 and File 4. The data storage service 168 may
repurpose the freed storage to support storage of other data.
[0077] The scope of the above-described process of consolidating
redundant storage may be varied and may be controlled by the
developer. For example, a developer may expressly limit the scope
of consolidation services to (1) a set of data storage containers,
(2) a particular cloud-based application, or (3) a set of
cloud-based applications, for example. Consolidation then operates
within the designated scope but not outside it. For example, if the
scope of consolidation is limited to a particular cloud-based
application, then the data storage service 168 may search for and
free redundant backend storage for file-based data storage
containers created by that cloud-based application, but not in data
storage containers created by other cloud-based applications.
[0078] FIG. 6 shows an example arrangement in which a data storage
container may be shared among different cloud-based applications
served from respective application sandboxes. Here, a first
cloud-based application served by application sandbox 160(1) has
access to a data storage container 610 at unique ID 123. At the
same time, a second cloud-based application served by application
sandbox 160(2) has access to the same data storage container 610 at
unique ID 123. The second cloud-based application may further have
access to another data storage container 620 at unique ID 466. Both
the first cloud-based application and the second cloud-based
application can thus read and write contents of the data storage
container 610 via respective read and write requests. Although each
data storage container is typically created by a respective
cloud-based application served by a respective application sandbox,
the creating application may engage in a protocol with another
application to grant the other application access to the data
storage container. Thus, in this example, the data storage
container 610 is not only user-agnostic, but also application
agnostic, as it may be accessed from multiple cloud-based
applications served by respective application sandboxes.
Section II: Real-Time Push Notifications
[0079] FIG. 7 shows an example technique for supporting push
notifications in the example environment 100 described in Section
I. Here, the data storage service 168 is seen to include multiple
sub-services, including a store service 708, a push service 720,
and a sync service 710. Cloud-based applications can access the
store service 708, push service 720, and sync service 710 via
respective service interfaces (e.g., 232, 234, and 236) from
sandboxes 160 (FIG. 2). In an example, the store service 708
includes many of the above-described features from Section I for
managing the creation and destruction of data storage containers
170 and for managing the storage and retrieval of data of the data
storage containers 170. In accordance with additional improvements,
the store service 708 further includes notification generators 730
(e.g., 730(a) and 730(b)) for detecting changes in respective data
storage containers 170 (e.g., 170(a) and 170(b)) and for notifying
the push service 720 of such changes. The push service 720 acts to
push changes in data storage containers 170 to subscribing
application instances. To this end, the push service 720 includes
multiple channels 722, where a different channel (e.g., 722(a) or
722(b)) is provided for each data storage container 170 for which
the push service is desired. Each channel 722 includes a
notification receiver 724 (e.g., 724(a) or 724(b)) and a connection
manager 726 (e.g., 726(a) or 726(b)). The sync service 710 builds
upon the push service 720 and synchronizes changes in data storage
containers 170 across subscribing application instances.
[0080] In operation, the store service 708 generates change
notification 752 via notification generators 730 in response to
changes in contents of respective data storage containers 170. Each
of the notification generators 730 is configured to generate a
respective change notification 752 in response to a change in any
of the contents of a respective data storage container 170.
Notification generators 730 are further configured to transmit the
generated change notifications 752 to push service 720 for
distribution to recipients. In an example, notification generators
730 are implemented with instructions within the store service 708
and may be accessible via an API.
[0081] The notification generators 730 need not have any
information about intended recipients of push notifications.
Rather, notification generators 730 merely respond to changes in
contents of the respective data storage containers (e.g., 170(a) or
170(b)) by generating change notifications 752 and sending the
change notifications to the push services 720. Each change
notification 752 is specific to a respective data storage container
that has changed but is agnostic to recipient devices, users, and
even (in some cases) applications.
[0082] In an example, each change notification 752 is arranged to
provide a compact message indicating the fact that the contents of
a respective data storage container have changed without providing
the actual changed content. Messages are therefore typically small
and thus avoid burdening the backend system 140.
[0083] The push service 720 is configured to send change
notifications 752 to subscribing application instances. It should
be understood that "subscribing application instances" are
application instances that subscribe to change notifications for a
particular data storage container 170. Each subscription typically
involves a respective connection 750 between push service 720 and
each of the subscribing application instances (generally, a
front-end component thereof). In some arrangements, the push
service 720 subscribes an application instance to a data storage
container automatically, e.g., in response to the application
instance creating the data storage container 170 and/or in response
to the application instance accessing the data storage container
for a first time. However, subscriptions may be established in any
suitable way.
[0084] The push service 720 is arranged to process change
notifications using channels 722, where each channel is dedicated
to a respective data storage container 170. Each channel 722 is a
logical construct for organizing connections between push service
720 and any subscribing application instances. For example, channel
722(a) is configured to broadcast change notifications over
connections 750 as a result of changes in data storage container
170(a). Likewise, channel 722(b) is configured to broadcast change
notifications over another set of dedicated connections (not shown)
as a result of changes in data storage container 170(b).
[0085] Taking channel 722(a) as an example, notification receiver
724(a) is configured to receive all change notifications 752(a) for
data storage container 170(a). Notification receiver 724(a) is also
configured to provide change notifications for data storage
container 170(a) to connection manager 726(a) for distribution to
subscribing application instances. It should be understood that,
analogously, notification receiver 724(b) is configured to receive
all change notifications 752(b) for data storage container 170(b)
and to provide change notifications 752(b) to connection manager
726(b) for distribution to application instances subscribing to
data storage container 170(b).
[0086] Connection manager 726(a) is configured to distribute change
notification 752(a) for data storage container 170(a) to
subscribing application instances. Along these lines, connection
manager 726(a) manages dedicated connections 750 from channel
722(a) to each respective subscribing application instance. Each
subscribing application instance is configured to receive change
notifications via its dedicated connection 750.
[0087] Dedicated connections 750 are configured to distribute
change notifications 752 to subscribing application instances. In
an example, connections 750 are configured to send data to
subscribing application instances via a protocol, such as HTTP or
web sockets, that supports application layer communication. In some
arrangements, connections 750 are persistent, one-way connections
from connection managers 726 to subscribing application instances
under such a protocol.
[0088] In response to receiving change notifications, application
instances may respond by issuing requests 762 for the actual
content of changes. In cases where the dedicated connections 750
are implemented as persistent, one-way connections, channel 722(a)
is configured to receive requests 762 from the subscribing
application instances over secondary connections 760, which are
distinct from connections 750. For example, channel 722(a) may
receive a request 762 from each subscribing application instance
over a respective one of the connections 760.
[0089] In response to receipt of each request 762, channel 722(a)
is configured to send changed content to the requesting application
instance. It should be understood that either a dedicated
connection 750 or a secondary connection 760 may be configured to
provide actual changed content back to the requesting application
instance.
[0090] In an example, store service 708 effects a change in
contents of data storage container 170(a). When the change in the
contents of data storage container 170(a) has been effected, or
contemporaneously therewith, notification generator 730(a)
generates change notification 752(a) indicating that a change in
the contents of data storage container 170(a) has taken place.
[0091] Upon the generation of change notification 752(a),
notification receiver 724(a) receives change notification 752(a)
from notification generator 730(a). In an example, channel 722(a)
is expressly dedicated to data storage container 170(a), and
notification receiver 724(a) may constantly remain available to
receive change notifications from the notification generator
730(a), i.e., in order to obtain any change notifications that
concern data storage container 170(a) in real time. Connection
manager 726(a) then distributes change notification 752(a) (or some
notification derived thereof) over dedicated connections 750 to
subscribing application instances. Examples of application
instances include application frontends, such as may run on user
devices. Other examples of application instances include
application backends, which may run on the backend system 140.
[0092] At this point, it should be understood that there is
virtually no latency between a change in contents of data storage
container 170(a) and subscribing application instances being
notified of the change. The ability to provide change notification
752(a) in real time to subscribing application instances is at
least partially due to the significantly reduced burden on the
backend system 140, which merely sends notifications of the fact
that contents have changed, rather than sending the changes
themselves, coupled with the ability to send the change
notification 752(a) to each subscribing application instance over a
respective dedicated connection 750.
[0093] Upon receiving the change notification 752(a), each of the
subscribing application instances comes into possession of
information that a change in contents of data storage container
170(a) has occurred. The subscribing application instances may then
each respond to notification 752(a) at times determined by local
considerations, e.g., based on what other activities the devices
may be performing.
[0094] At some point, a subscribing application instance may
respond to the change notification 752(a) to acquire the changed
contents of data storage container 170(a). For example, the
application instance sends a request 762 for the changed contents
over secondary connection 760 between that application instance and
push service 720. A typical arrangement involves secondary
connection 760 being a non-persistent connection, as it is not
critical that the transmission of the actual changed contents
happens in real time. As an example, request 762 includes
information identifying the application instance from which it
originated, as well as a timestamp.
[0095] Upon receipt of request 762, the push service 720 forwards
request 762 to store service 708. In response, the store service
708 retrieves changed contents 764 of data storage container 170(a)
and forwards the changed contents 764 to channel 722(a). In some
arrangements, connection manager 726(a) sends changed contents 764
to the requesting application instance over one of the secondary
connections 760, as illustrated. In other arrangements, however,
the connection manager 726(a) sends changed contents over its
respective connection 750.
[0096] It should be noted that nowhere does the concept of a user
enter into operations for the push notification described above.
Rather, the push service 720 is preferably user-agnostic. Of
course, human or other users may operate the individual devices on
which application instances run. Such users may be managed by user
management services 228 (FIG. 2) or by other user management, but
they play no role in the above-described push notifications.
[0097] As discussed above, change notifications 752 are small
enough to avoid burdening backend server 140. In some arrangements,
the message contained in each change notification consists of at
most sixteen characters, although in other arrangements the message
may consist of more (e.g., 32, 64, 128, etc.) or fewer (e.g., 8, 4,
2, 1) characters. The message may even consist of 0 characters,
i.e., the message payload may be null. Application instances may be
programmed to call the backend system 140 for updates whenever they
receive transmissions having null payloads.
[0098] In some arrangements, the character text provided in the
change notifications 752 may indicate further detail about the
change to the contents of data storage container 170(a). For
example, if notification generator 730(a) has information that a
change to contents of a file is a deletion, then the message may
contain a "D". In this scenario, the application instance need not
send any request 762, as there are no changed contents to request.
Rather, the application instance may simply delete its own local
copy of the file.
[0099] It should be understood that the change in the contents of a
data storage container may originate from a subscribed application
instance or a source external to any subscribed application
instances. In the former case, for example, an application instance
may direct the store service 708 to update a data storage
container, and the push service 720 may act to push the change to
all (or all other) subscribing application instances. In the latter
case, for example, an application separate from the subscribing
application instances may direct the store service 708 to update a
data storage container, and the push service 720 may act to push
the changes to all subscribing instances.
[0100] In some arrangements, each data storage container 170 may be
subscribed to by application instances of multiple cloud-based
applications. For example, a bicycling application and a general
fitness application may both access the same data storage container
for data common to both applications. In such cases, push
notifications reflecting changes in the shared data storage
container would be sent to application instances of both
applications. Thus, the push service 720 operates in response to
changes in data storage containers by notifying application
instances, whether those application instances are instances of the
same application or of different applications. Push notifications
are therefore inherently application-agnostic as well as
user-agnostic.
[0101] FIG. 8 shows a case in which push service 720 provides
change notifications for both data storage containers 170(a) and
170(a) over channels 722(a) and 722(b) (see FIG. 7), respectively.
The scenario shown in FIG. 8 illustrates the special case in which
frontends of application instances run on different client devices.
In FIG. 8, three client devices, 820(1), 820(2), and 820(3), each
run a respective frontend instance of the first cloud-based
application, i.e., App1P. Further, client device 820(3) (i.e., a
single device) runs a frontend instance of the second cloud-based
application, i.e., App2P. Each of client devices 820(1), 820(2),
and 820(3) connect to backend server 140 via network 130.
[0102] When there is a change in the contents of data storage
container 170(a), notification generator 730(a) generates change
notification 752(a). Change notification 752(a) contains a message
810(a) that has a small amount of data, such as a single character
("N" for "new") that indicates that a change in the contents of
data storage container 170(a) has taken place. It should be
understood, though, that the message may contain any number of
characters or no characters, as indicated above.
[0103] As described above in connection with FIG. 7, connection
manager 726(a) of channel 722(a) distributes change notification
752(a) over dedicated connections 750. Here, the change
notification 752(a) is resolved into respective connections 750(1),
750(2), and 750(3) and sent to the respective client devices
820(1), 820(2), and 820(3).
[0104] With regard to data storage container 170(b), channel 722(b)
obtains generated change notification 752(b) in response to a
change in data storage container 170(b). Connection manager 726(b)
within channel 722(b) resolves change notification 752(b) at
channel 726(b) into a single dedicated connection 750(11) to
application instance App2P running on client device 820(3).
Consequently, connection manager 726(b) directs notification 752(b)
containing the single character, for example, of message 810(b) to
the client device 820(3).
[0105] As described above, each of the data storage containers 170
may be configured for storing file data, relational data, or
key-value data. Procedures for pushing requested changes to
respective application instances may vary depending on the type of
the data storage containers involved. For example, key-value and
relational data may be sent over dedicated connections 750, while
file data may be sent over secondary connections 760, as
described.
[0106] The dedicated connections 750 may be provided in the form of
persistent, one-way connections that use an HTTP or web sockets
protocol, for example. In one example, the connection managers 726
send push notifications 752 in the form of a server-sent event over
connections 750. As is known, a "server-sent event" is a real-time
event raised by a server and transmitted to a client over a
persistent, one-way connection. Server-sent events are sent over
HTTP using HTML5 or greater. If a connection drops, the server
fires an error event and automatically tries to reconnect.
[0107] An advantage of server-sent events stems from the fact that
they are sent over HTTP protocol. The use of HTTP means that
server-sent events are not blocked by firewalls unless the
firewalls are configured to block all HTTP traffic. Also,
developers can generally establish server-sent events in HTTP using
simple language commands.
[0108] An alternative to server-sent events is for a developer to
use web socket technology to establish persistent, one-way
connections 750. We have observed, however, that some firewalls may
be configured to block web socket traffic, such that server-sent
events are generally more reliable.
[0109] Yet another alternative for establishing the one-way
connections 750 is to use long polling technology. With long
polling, each subscribing application instance opens an HTTP
request with the backend system 140 and waits to receive a response
from the backend system 140 over the open request. The backend
system 140 may keep the request open for as long as possible. If
the request times out, the respective application instance may
issue a new request. When a channel 722 in the backend system 140
attempts to send a change notification 752 to the respective
application instance, the channel 722 uses the open request from
the application instance as the connection 750 over which to send
the change notification 752.
[0110] In some examples, the push service 720 establishes a
connection 750 by first attempting to use server-sent events. If
the attempt succeeds, the push service 720 uses server-sent events
for the connection 750. Otherwise, the push service 720 tries
instead to use web socket technology. If the attempt to use web
sockets fails, the push service 720 attempts to use long polling.
Thus, the first choice of the push service 720 is to use
server-sent events, the second choice is to use web sockets, and
the third choice is to use long polling. It should be understood
that the choice of technology for implementing the connections 750
may be made on a per-connection basis, such that application
instances that currently support server-sent events may use them,
whereas application instances that do not currently support
server-sent events may use either web sockets (as a first fallback
option) or long polling (as a last resort).
[0111] FIG. 9 shows example operations for generating change
notifications 752 for file-type data storage containers. Here, data
storage containers 170(a) and 170(b) contain files 910(a) and
910(b), respectively. Also shown in FIG. 9 are data storage
services 168, which are here seen to include the notification
generators 730 (see also FIG. 7) and the database 310 (FIG. 3) for
storing metadata for file-type data storage objects. Segregation of
structures and operations among the sub-services 708, 710, and 720
(FIG. 7) are omitted from FIG. 9 for the sake of simplicity;
rather, all structures and operations are merely shown as being
part of the larger data storage service 168.
[0112] As described in connection with FIG. 3, database 310 is
configured to store metadata describing file-type data storage
containers. Here, the database 310 has an entry 310(a) that stores
metadata for data storage container 170(a) and an entry 310(b) that
stores metadata for data storage container 170(b). In this example,
entry 310(a) specifies that data storage container 170(a) has a
unique ID of 740, an alias of "Bike", and a last-modified timestamp
T(a), such as Feb. 25, 2014, at 2:45 PM, for example. Similarly,
entry 310(b) specifies that data storage container 170(b) has a
unique ID of 741, an alias of "Bank", and a last-modified timestamp
T(b), such as Feb. 25, 2014, at 3:33 PM.
[0113] Notification generators 730 are configured to update the
"last modified" field of entries 310(a) and 310(b) in the database
310 each time a change is made in the contents of a respective data
storage container 170. Consider a case in which an application
instance subscribes to data storage container 170(a) including file
910(a). If a device on which this application instance runs has
been turned off, the device may never receive change notifications
752 concerning changes in the file 910(b) while the device was off.
When the device turns back on, the application instance running on
the device sends a request 762 (FIG. 7) for updates to the data
container 170(a). This request 762 may be sent automatically when
the device turns back on, even though the device did not receive
any change notification 752. The request 762 includes a timestamp
indicating the last time the application instance running on the
device received an update for the data storage container 170(a).
Upon the backend system 140 receiving the request 762, the data
storage service 168 compares the timestamp received in the request
762 with the last-modified timestamp in the database entry 310(a).
Push service 720 then sends the application instance on the device
contents of the data storage container 170(a) that have changed
since the time indicated in the timestamp from the request 762. In
this way, backend server 140 always sends all accumulated updates
to the application instance, regardless of how many changes have
occurred while the device was turned off.
[0114] This process of obtaining updates after the device turns
back on may be repeated for each data storage container to which
the application instance on the device subscribes. In some
variants, the application instance running on the device may send a
single request 762, which includes a timestamp indicating the last
time any update to a subscribed-to data storage container was
received. Upon receiving the request 762, the data storage service
168 iterates over all subscribed-to data storage containers and
provides updates for each of them. If a subscribed-to data storage
container contains a folder rather than a file, the data storage
service 168 may iterate over all files within the folder and send
updates only for the files that have changed.
Section III: Sync as a Service for Cloud-Based Applications
[0115] FIG. 10 shows example aspects of the environment 100 of FIG.
1 (Section I), arranged for providing sync services. As illustrated
in FIG. 10, example sync service 710 is arranged to provide sync
capabilities between and among multiple application instances,
e.g., frontend instances of one or more cloud-based applications,
via the backend system 140. As indicated in connection with FIG. 7,
the sync service 710 operates as a sub-service of the data storage
service 168. In addition, sync service 710 may be selectively
employed for respective sets of data. In some arrangements, sync
service 710 is enabled for data storage containers 170 on a
per-data-storage-container basis; i.e., for each data storage
container 170, sync service 710 is either enabled or disabled. Sync
service 710 includes a sync settings module 1042 and a badging
service 1100.
[0116] Sync settings module 1042 is arranged to record which data
storage containers employ the sync service 710 for syncing and
which do not. In some arrangements, the sync settings module 1042
may take the form of a table stored in memory 150. In some
examples, the sync settings module 1042 is implemented using one or
more of the databases 310, 320, or 330 (FIGS. 3a-3c). For example,
database 310, for storing metadata for file-type data storage
containers, may include one or more additional fields (not shown)
for storing sync settings. The additional fields specify whether
syncing should be performed for each data storage container
represented. Syncing may be enabled at the individual file level or
at the folder level for file-type data storage containers. Syncing
may be enabled at the individual data element level for
relational-type and key-value-type data storage containers. In some
examples, badging is provided only for file-type data storage
containers. It should be understood, however, that badging may be
provided for any type of data storage container.
[0117] In some examples, sync settings are established in the sync
settings module 1042 via a set of API calls into the REST interface
210 (FIG. 2). The set of API calls may be constructed using an SDK
running on a frontend client (FIG. 1), although this is not
required. The set of API calls may include a single API call,
multiple API calls, or even one or more arguments specified in one
or more API calls. In one example, the sync settings are provided
in the form of one or more arguments of an API call that specifies
the creation of a new data storage container. For instance, when
creating a new data storage container, a create command includes an
argument that specifies whether syncing should be performed on that
data storage container and, in some cases, whether badging should
be performed. In another example, the sync settings are provided in
API calls separate from those used to create data storage
containers. Such separate API calls may each specify an identifier
of a particular data storage container 170 (e.g., it's unique ID
116b--FIG. 1, its alias, etc.) for which the sync service 710 is to
be configured.
[0118] During example operation, a developer on developer machine,
e.g., 110(1), generates sync settings 1012(1) for establishing sync
services 710 for a data storage container, e.g., 170(b). The
developer machine 110(1) sends sync settings 1012(1) to the backend
system 140. In one example, the sync settings 1012(1) may specify
that data stored in data storage container 170(b) should be synced,
i.e., across all application instances having access to data
storage container 170(b). Going forward, any application instance
with access to 170(b) automatically receives updates to data made
by any other application instance or any other source. In another
example, the sync settings 1012(1) may specify that data stored in
data storage container 170(b) should not be synced, in which case,
going forward, application instances with access to 170(b) are not
automatically updated with changes made by other application
instances.
[0119] Once developer machine 110(1) sends sync settings 1012(1) to
backend system 140, backend system 140 directs the sync settings
1012(1) to the sync service 710.
[0120] In response to receiving sync settings 1012(1), the sync
service 710 identifies the data storage container to which the sync
settings 1012(1) pertain. Sync services 710 then updates the sync
settings module 1042, in this case to associate sync services 710
with the data storage container 170(b).
[0121] As discussed above, sync settings module 1042 may store sync
settings in a table in memory 150. In some arrangements, this table
includes two fields: the identifier for a data storage container
and a Boolean indicating whether syncing has been enabled for that
container. In an example, the value of that Boolean is TRUE by
default for all data storage containers 170. But the value of the
Boolean may be changed to FALSE (and, more generally, changed
between TRUE and FALSE) in response to new sync settings. The table
may include a third field that stores a Boolean indicating whether
badging should be performed.
[0122] It should be understood that the sync service 710 may thus
be selectively enabled and/or disabled for any data storage
container over time and that its status as enabled or disabled may
be changed. Also, different data storage containers may each have
their own respective sync settings, with the sync service 710 being
enabled for some while disabled for others, for example.
[0123] Continuing the operation, sometime later a machine, e.g.,
client machine 120(1), generates a data change 1026(1), e.g., as a
result of local operations of App1P. Client machine 120(1) applies
data change 1026(1) to data copy 1022(1), which, prior to applying
the change, stored a local copy of data stored in data storage
container 170(b). If syncing has been enabled for the data storage
container 170(b), then client machine 120(1) sends the data change
1026(1) to the backend system 140. The data change 1026(1) may be
the entire data copy 1022(1) or only an identified portion of the
data copy 1022(1) that has changed.
[0124] The backend system 140 receives data change 1026(1) and
hands data change 1012(1) off to the store service 708. The store
service 708, in response, changes data stored in data storage
container 170(b) according to data change 1026(1). It should be
understood that, after the change has been made, the data stored in
data storage container 170(b) matches the data copy 1022(1) stored
within client machine 120(1).
[0125] If the sync settings 1042 indicate that syncing is enabled
for data storage container 170(b), then a copy of data change
1026(2) is sent to each subscribing application instance, e.g., to
client machine 120(2), which also has access to data storage
container 170(b). For example, backend system 140 uses the protocol
described in Section II for real-time push to update subscribing
application instances. Here, client machines 120(1) and 120(2) may
both run frontend instances (e.g., App1P) of the same cloud-based
application. Data changes may similarly be synced to any other
application instances that have access to data storage container
170(b).
[0126] It should be understood that the sync service 710 binds to
particular data storage containers, but not to particular users or
even necessarily to particular cloud-based applications. Rather,
just as data storage containers 170 as described in Section I are
user-agnostic, so too is sync service 710 user-agnostic. In
addition, just as data storage containers 170 are described as
application-agnostic in certain arrangements, so too is sync
service 710 application-agnostic in certain arrangements. Thus,
different application instances to which changes in a data storage
container are sync'd need not relate to the same user, group of
users, or cloud-based application.
[0127] That said, nothing herein should be interpreted as
preventing a particular data storage container 170 and its
associated sync service 710 from operating on behalf of a
particular user and/or with a particular cloud-based application.
Indeed, it may be typical for a data storage container 170 to be
associated with a single user and a single application. In such
cases, however, it is up to the application developer to form such
associations, using the services provided in the backend system
140, as such associations are not required by the data storage
service 168 (including the sync service 710) itself.
[0128] FIG. 11 shows further details of environment 100 and
illustrates an example in which the sync service 710 syncs a local
data change 1026(1) made to data storage container 170(b) on client
machine 120(1) with client machine 120(2) using real-time push, as
described in connection with Section II above.
[0129] During an example operation, once data change 1026(1) has
been received from client machine 120(1), the store service 708
coordinates with the sync service 710 to check whether the sync
service 710 is enabled for data storage container 170(b). For
example, the store service 708 checks the sync settings for the
data storage container 170(b) in the database 310 (FIG. 3). If the
sync settings indicate that the sync service 710 is enabled for
data storage container 170(b), the store service 708 generates a
change notification 1130 and sends the change notification 1130 to
push service 720. Push service 720 then broadcasts the change
notification to all subscribing application instances, e.g., in the
manner described above in connection with FIGS. 7 and 8. For
example, push service 720 sends the change notification 1130 to
client machine 120(2). Client machine 120(2), upon receiving change
notification 1130, sends a request 1140 to obtain a copy of updated
data. In response to receiving the request 1140, push service 720
transmits a copy of data change 1026(1) to client machine 120(2).
App1P running on client machine 120(2) causes client machine 120(2)
to update a local data copy 1022(2) stored on client machine 120(2)
so that the data copy 1022(2) matches the data copy 1022(1) on
client machine 120(1). In an example, the request 1140 and the data
change 1026(1) are similar to the request 762 and change 764,
respectively, as described in connection with FIG. 7.
[0130] In some arrangements, the sync service 710 includes the
badging service 1100 for enabling client machines 120 to receive
and optionally to display sync status. For example, badging service
1100 may assign a syncing status to data copy 1022(2) and may
communicate that syncing status to client machine 120(2). In some
arrangements, the syncing status may be one of "SYNC_COMPLETE",
"SYNC_IN_PROGRESS", AND "SYNC_FAILED".
[0131] It should be understood that, like sync service 710, badging
service 1100 is also provided as an option to frontend clients.
Specifically, some frontend clients that employ sync service 710
may employ badging service 1100 while others may not. Of course,
clients that do not employ sync service 710 do not employ badging
service 1100, as badging service 1100 is part of sync service
710.
[0132] In some arrangements, badging service 1100 is enabled at the
same time sync service 710 is enabled. In this case, syncing
instructions 1012(1) (FIG. 10) would also contain an identifier,
such as "BADGING_ENABLED," from which sync service 710 would enable
badging service 1100.
[0133] In some arrangements, a sync settings module 1042 enables
the badging service 1100 using a badge settings module 1046, akin
to the sync settings module 1042. In other arrangements, a table in
sync settings module 1042 has an extra field in which badging
settings for a data storage container may be turned on or off. For
example, the database 310 may include an extra field that stores a
Boolean for enabling or disabling badging for each data storage
container 170.
[0134] When the badging service 1100 is enabled, the badging
service 1100 generates a command 1120 to include badging for data
copy 1022(2). For example, upon receipt of command 1120, client
machine 120(2) runs a local badging service. The local badging
service provides a badge 1122 to data 1022(2) upon receipt of the
change notification 1130.
[0135] In some further arrangements, sync service 710 is arranged
to provide a conflict avoidance operation when conflicting data
changes are provided simultaneously, or nearly simultaneously, to
backend system 140 from distinct machines, e.g., from machines
120(1) and 120(2). For example, if sync services 710 receive a data
change from client machine 120(1) just prior to receiving a
conflicting change from client machine 120(2), sync services 710
may process the data change and send a message to client machine
120(2) indicating that the conflicting data change has been
rejected and must be resubmitted. In other arrangements, the
conflicting data change would be placed in a queue while the data
change was being processed.
[0136] FIG. 12 shows an example process 1200 of syncing data in a
backend system that provides services for supporting cloud-based
software applications. The process 1200 may be carried out in
connection with the computing environment 100. Process 1200 is
typically performed by the software constructs described in
connection with FIGS. 1, 2, 7, 10, and 11, which reside in the
memory 150 of backend system 140 and are run by the set of
processors 144. The various acts of process 1200 may be ordered in
any suitable way. Accordingly, embodiments may be constructed in
which acts are performed in orders different from those
illustrated, which may include performing some acts simultaneously,
even though the acts are shown as sequential in the illustrated
embodiments.
[0137] At 1210, a set of data used by a cloud-based application is
stored by a data storage service in the backend system, the data
storage service storing the set of data in response to storage
instructions received from the cloud-based application. The
cloud-based application has a set of application instances running
on respective computing machines operatively connected to the
backend system over a network. For example, a request is received
from a frontend client running on one of the machines 110 or 120,
an application backend 212, or a service running within the backend
system 140 itself. The request directs the store service 708 to
create a data storage container (e.g., 170a, 170b, 170c, etc.) and
to store a set of data in the data storage container. The data
storage container is a logical container (e.g., defined by
metadata) for storing data and has no assignment by the store
service 708 to any end user of the cloud-based application.
[0138] At 1212, a set of sync settings is stored by the backend
system, the set of sync settings indicating whether the backend
system employs sync services for syncing the set of data stored in
the backend system by the data storage service. For example, upon
the creation of a data storage container 170(b), store service 708
sends an identifier for container 170(b) to developer machine
110(1). Developer machine 110(1) then issues sync instructions
1012(1) containing the identifier. The sync instructions 1012(1)
(FIG. 10) are for enabling or disabling the sync service 710 for
data storage container 170(b). It should be understood, however,
that typically the default settings involve the sync service 720
being enabled by the backend system.
[0139] At step 1214, in response to (i) changes in the set of data
and (ii) having stored the set of sync settings indicating that the
backend system employs the sync service for syncing the set of
data, the set of data are synced among the backend system and the
set of application instances. For example, when sync service 710
receives data change 1026(1) (FIG. 10), sync service 710 performs a
lookup in sync settings module 1042 on the data storage container
identified by data change 1026(1), i.e., data storage container
170(b). If the table in sync settings module 1042 indicates that
data storage container 170(b) indeed employs the sync service 710,
then the sync service 710 sends a copy of data change 1026(2) to
client machine 120(2), which subscribes to data storage container
170(b).
[0140] An improved technique provides sync capability as an
independent backend service, which developers can include, at their
option, in their cloud-based applications. A sync service 710 runs
in a backend system 140 in connection with a set of data stored on
the backend system by a store service 708. The sync service 710
syncs changes in the set of data among application instances that
have access to the set of data. The sync service 710 may be
specified selectively for different sets of data, e.g., by
specifying syncing for one set of data but not for another set of
data.
[0141] Having described certain embodiments, numerous alternative
embodiments or variations can be made. For example, although the
above examples describe scenarios involving two subscribing
application instances, other scenarios may involve greater than two
subscribing application instances, in which case, all such
instances would receive change notifications 1130 and send requests
to the backend system 140 for updates.
[0142] Further, although it has been described that the sync
service 710 is either enabled or disabled on a
per-data-storage-container basis, the sync service 710 may be
enabled or disabled based on other information, as well. For
example, certain cloud-based applications or certain users may opt
out of syncing across the board, regardless of the data storage
container involved. In such situations, the sync setting module
1042 may override any sync instructions that it receives for data
storage containers, to accommodate user or application
preferences.
[0143] Further, badging operations have been described in
connection with data storage containers. As pointed out in
connection with FIG. 3A, however, some data storage containers
represent entire folders, which may themselves include files and/or
sub-folders. If badging is enabled for a folder, then the badging
service 1100 (FIG. 11) may coordinate with client badging services
to provide information about the syncing status of the folder as a
whole, i.e., including all of its contents. Thus, the badging
service 1100 works not only for individual files but also for
folders. The badging service 1100 may further be extended to other
types of data storage containers, such as key-value and relational
data storage containers.
[0144] Further still, the improvement or portions thereof may be
embodied as a non-transient computer-readable storage medium, such
as a magnetic disk, magnetic tape, compact disk, DVD, optical disk,
flash memory, Application Specific Integrated Circuit (ASIC), Field
Programmable Gate Array (FPGA), and the like (shown by way of
example as medium 1250 in FIG. 12). Multiple computer-readable
media may be used. The medium (or media) may be encoded with
instructions which, when executed on one or more computers or other
processors, perform methods that implement the various processes
described herein. Such medium (or media) may be considered an
article of manufacture or a machine, and may be transportable from
one machine to another.
[0145] Further, although features are shown and described with
reference to particular embodiments hereof, such features may be
included and hereby are included in any of the disclosed
embodiments and their variants. Thus, it is understood that
features disclosed in connection with any embodiment are included
as variants of any other embodiment.
[0146] As used throughout this document, the words "comprising,"
"including," and "having" are intended to set forth certain items,
steps, elements, or aspects of something in an open-ended fashion.
Also, as used herein and unless a specific statement is made to the
contrary, the word "set" means one or more of something. Although
certain embodiments are disclosed herein, it is understood that
these are provided by way of example only and the invention is not
limited to these particular embodiments.
[0147] Those skilled in the art will therefore understand that
various changes in form and detail may be made to the embodiments
disclosed herein without departing from the scope of the
invention.
* * * * *