Abstract: An instance persistence command for an update to a state of an instance of an application can be issued. In response to the persistence command, a transaction with an instance store can be initiated. As part of the transaction, a first representation of the update can be stored in the instance store and a second representation of the update can be stored in a queue. The transaction can be committed after storing the first and second representations. After the transaction is committed, the second representation can be processed to store a third representation of the update in a query store. Application instance state information in the query store can be updated and queried without locking the instance store so that such operations in the query store can be performed asynchronously with operations in the instance store.

Abstract: Query models for document sets (such as XML documents or records in a relational database) typically involve a schema defining the structure of the documents. However, rigidly defined schemas often raise difficulties with document validation with even inconsequential structural variations. Additionally, queries developed against schema-constrained documents are often sensitive to structural details and variations that are not inconsequential to the query, resulting in inaccurate results and development complications, and that may break upon schema changes. Instead, query models for hierarchically structured documents that enable “twig” queries specifying only the structural details of document nodes that are relevant to the query (e.g., students in a student database having a sibling named “Lee” and a teacher named “Smith,” irrespective of unrelated structural details of the document).

Abstract: A document service may be provided by many document service packages, each presenting a particular set of service characteristics (e.g., the performance achievable on various storage device types; the available indexing models; and the types of transactions, scripts, and queries supported by the document service). For a particular project, an administrator may endeavor to select a document service package exhibiting characteristics that match some criteria of the project and to configure or adapt the document service for other criteria, but the range of adaptability for each document service package may be limited. Presented herein are architectures for document services involving a composable set of components respectively providing a service feature with a service characteristic.

Abstract: An application on a device may interact with a document service that provides access to a document service. The interaction may occur in a variety of contexts, such as a device context (e.g., the document service and the application provided on the same device), a local context (e.g., via a LAN), and a remote context (e.g., over the Internet). It may be advantageous to adapt the interaction to the current context, while also providing a consistent application interface that alleviates the application from context-specific implementations, and also achieving this adaptation in a performant manner. These considerations may be achieved in a balanced manner by providing a set of runtimes, where each runtime mediates the application/document service interaction between the application and the document service in a contextually adapted manner. The device may automatically detect the context of the interaction and select a contextually suitable runtime to service the application.

Abstract: A server set may provide a document service to one or more clients, and may be configured to do so in view of various considerations such as availability, fault tolerance, flexibility, and performance. Presented herein are document service architectures that involve partitioning the document set into at least two document ranges, and configuring respective servers of the server set to host one or more agents to which are respectively assigned one or more document ranges. A request for an operation involving at least one document may be routed to a server hosting an agent managing the document ranges of the documents involved in the operation. Moreover, respective servers may retain detailed information about neighboring servers (e.g., according to a logical or physical proximity) and scant information about distant servers, thereby avoiding both the extensive information exchange of highly informed network architectures and the inefficiency of uninformed routing algorithms.

Abstract: Object-oriented application languages often provide resources to applications for accessing objects stored in the volatile application memory region, and, separately, for packaging objects for persistent storage and network transport by serialization and deserialization involving a storage format. However, this design creates discrepancies between the application language and storage format, and depends on affirmative serialization and deserialization by the application. Presented herein are techniques for providing object access to objects involving persisting the objects as documents in a document store, where such persistence occurs automatically upon object creation and updating, and where such objects are stored in a language format integral to the application language (e.g., when a JavaScript application creates an object, the objects are automatically stored as documents of the document store in a JavaScript Object Notation (JSON) format).

Abstract: A computer user may use a computing environment comprising a set of computers that respectively feature a web browser having a browser cache containing many types of data objects, including application resources and user-generated data files. However, the contents of a browser cache significantly contribute to the computing environment of a computer, and the computing environments presented by each computer may diverge, providing an inconsistent computing environment. Instead, the contents of browser caches of the computers comprising the computing environment may be synchronized across computers. Additionally, the browser cache may be synchronized with the other data objects of a computing environment (such as relevant portions of the filesystem); the synchronizing may be implemented as an out-of-browser process executing independently of the applications, and even when the browser is not executing; and the synchronization may be exposed through a programmatic access with which web applications may interact.

Abstract: A service level agreement can be generated based on a data store configuration. In one instance, the configuration can be specified in terms of a data value such as high, medium, and low value, for example. In another instance, a workload configuration can be specified comprising a replica set and consistency level, among other things. More particularly, the service level agreement can include guarantees regarding one or more of consistency, availability, latency, or fault tolerance, among others, as a function of a data value or workload configuration. Further, operation of a service associated with a service level agreement can be monitored to determine satisfaction or violation of guarantees, and provide real time feedback.

Abstract: A data store is configurable in terms of various tradeoffs including consistency and availability, among others. Consistency can be specified in terms of one of a myriad of configuration levels. Availability can be specified with respect to a maximum and minimum number of replicas or failure tolerance. In operation, one or more of write or read quorums can be automatically adjusted to ensure satisfaction of a specified configuration level in light of changes in the number of replicas.

Abstract: Within a computing environment, an application may run in a variety of contexts, e.g., as a natively executable application, as a client-side interpretable application embedded in a web browser, or as a server-side application that communicates with the user through a web interface presented on a device. The application may also access resources of the computing environment stored on multiple devices. The configuration of the application to operate equivalently in these diverse environments may be facilitated by representing the application within an object hierarchy representing the computing environment. The application may be configured to operate on the objects of the object hierarchy regardless of the location of the stored objects, to execute on any device, and to execute upon a standard set of application programming interfaces. The configuration of the application in this manner promotes the versatility of the application in operating equivalently in different programming contexts.

Abstract: Within a computing environment, an application may run in a variety of contexts, e.g., as a natively executable application, as a client-side interpretable application embedded in a web browser, or as a server-side application that communicates with the user through a web interface presented on a device. The application may also access resources of the computing environment stored on multiple devices. The configuration of the application to operate equivalently in these diverse environments may be facilitated by representing the application within an object hierarchy representing the computing environment. The application may be configured to operate on the objects of the object hierarchy regardless of the location of the stored objects, to execute on any device, and to execute upon a standard set of application programming interfaces. The configuration of the application in this manner promotes the versatility of the application in operating equivalently in different programming contexts.

Abstract: A data set may be managed by a host that provides access to clients through a protocol, such as a RESTful HTTP interface. A resource script may be expressed according to a script language featuring two types of instructions: data set instructions that correspond to the verbs of the protocol, and flow control instructions that alter the flow of execution of the resource script. At runtime, an execution context for the resource script may be selected as a local execution context (through a local script processor that issues protocol verbs to the host based on the data set operations) or a remote execution context (by sending the resource script to a script processor located on the host.) The runtime selection of data context may be executed without having to reconfigure the resource script, and with an equivalent effect on the data set.

Abstract: A computing environment may be represented as a deployable object hierarchy, which may be organized according to an object hierarchy schema that is commonly shared among the computing environment host and the devices that are configured to render the computing environment. A particular object hierarchy schema is presented in detail for representing a computing environment, wherein many objects of the computing environment are modeled as resources that may be distinctly addressable (e.g., in a RESTful object hierarchy.) Many types of objects and properties thereof are presented in order to elucidate an exemplary object hierarchy schema and to illustrate exemplary objects and object hierarchies organized according thereto. Additional properties of various object hierarchy schemas include extensibility, deployability, and object addressing models with various advantages.

Abstract: Systems and methods according to various embodiments disclose a worker process manager adapted to spawn one or more worker processes on a server and to load an application on each of the worker processes. The worker process manager is adapted to isolate the one or more worker processes from each other and to control resource usage by the worker processes. A resource manager is adapted to detect applications that overuse system resources. The worker process manager is adapted to isolate worker processes and to control resource usage using one or more of the following techniques: least-privilege execution, messaging isolation, credentials isolation, data isolation, network isolation, fair share resource usage, and managed runtime security. Heuristic algorithms are used to detect applications that frequently overuse system resources that are unchargeable and that cause system unresponsiveness.

Abstract: A container service is capable of hosting large numbers of middleware components for multiple tenants. A central container manager controls a plurality of compute nodes. The central container manager receives middleware components from external devices or services and assigns the components to containers on one or more designated compute nodes. Each compute node has a container management agent and one or more containers. The container management agents activate and manage the appropriate number of containers to run the assigned middleware components. The container management agent assigns each container on its compute node a limited set of privileges to control access to shared resources. The central container manager and each node's container management agent monitor container load levels and dynamically adjust the placement of the middleware components to maintain balanced operation. The compute nodes are grouped into clusters based upon the type of middleware components hosted on each compute node.

Abstract: Data sets of various types may be accessible through a host according to a protocol, such as a RESTful HTTP interface. Various domains may involve domain-specific processes to be executed as pre-triggers or post-triggers of various protocol requests (e.g., an HTTP GET request specifying a Read operation on an access-restricted data set may involve an authorization operations set that verifies the access privileges of the requester.) A host of the data set may be configured to receive a resource script expressing the operations set in a script language, to store the resource script, and to associated it with at least one data set and at least one verb of the protocol. Upon later receiving a protocol request specifying the verb and the resource, the host may then execute the resource script (as a pre-trigger and/or as a post-trigger) in accordance with the business logic of the domain.

Abstract: Applications executing on computer systems may execute in a virtual environment, such as a web application executing in a web browser. An application may access the actual computing environment (such as the filesystem), but this accessing may be complicated; e.g., the computing environment may be deployed across many computers and devices, and may be synchronized for offline access via a local cache. A computing environment component may service the complex computing environment (e.g., by managing the cache and retrieving remotely stored data objects) and expose it as a well-organized set of data objects. A virtual environment interface (e.g., a web browser plug-in) may allow applications hosted in the virtual environment to access the computing environment through the computing environment component. Programmatic interfaces may also be implemented to permit such accessing via familiar programming languages and techniques, such as JavaScript libraries exposed to web applications in the web browser.

Abstract: A framework and middleware services for developing, deploying and managing composite applications is disclosed. The middleware services may be deployed on-premises or in the cloud. The framework includes a rich collection of middleware services, an application model to compose services into a composite application, a high-density multi-tenant scalable container to host the composition logic, and unified lifecycle management of the composite application and its constituent services.

Abstract: A back-end locator service can be utilized to identify a specific computing device, from among multiple computing devices in a domain, that is the most appropriate computing device to handle a particular type of request for data or other resources. The data or resources hosted by the domain can be divided among multiple computing devices. The domain can expose a network-based application program interface where successive requests by a client computing device become more specific as to the data or resources requested. Responses from the computing devices in the domain can, at some point in time, be informed by the back-end locator service and can comprise location-specific resource identifiers. The client computing device can utilize such location specific resource identifiers to direct further communications to the appropriate, specific computing device without having to incur redirection inefficiencies.

Abstract: A method for of authoring and executing stateful components for a distributed application is disclosed. An application schema for the distributed application is declaratively defined and includes a plurality of distributed modules. Each module hosts a set of stateful components co-located in a physical tier of a distributed environment having logic to manipulate state. The runtime supports partitioning the stateful components. Control flow opaqueness of component logic is banished in each of the stateful components, which would otherwise occur if state was externalized.