Amazon Technologies, Inc.

Zachary Mohamed Shalla

Marvin Michael Theimer

Michael J Hart

Anders Samuelsson

Brian Joseph Collins

John Petry

Salvador Salazar Sepulveda

Ji Luo

Serge Hairanian

Jeremy Boynes

Andrew Stuart Huntwork

Ross Vincent Korsky

Anand Victor

Ullas Sankhla

Léon Thrane

John Ingram Baker Dugaw

Nicholas J Giordano, Jr

Gaurav D Ghare

Gautam Shanbhag

Vaibhav Sharma

Jeremy Brian Hanni

Homan Lee

Nagesh V Honnalli

Shen Pan

Surendra Moolchand Bashani

Sushanth Tiruvaipati

Distributed system resources may be managed by applying user created policies to the resources. To ensure that valid policies are applied, remote validation for the policies may be implemented. A validation event for a policy may be detected. A remote validation agent may be identified for the policy and a validation request sent to the remote validation agent that includes information for validating the policy. The remote validation agent may return a validation result for the policy. If valid, a policy action that triggered the remote validation event for the policy may be allowed. If invalid, the policy action that triggered the remote validation event for the policy may be denied.

Remote policy validation for managing distributed system resources

Multiple edits to a hierarchical data structure may be atomically applied. A request to perform modifications with respect to a portion or the entire hierarchical data structure may be received. A copy of the requested portion of the hierarchical data structure may be created separate from the hierarchical data structure. The portion of the hierarchical data structure may remain available for read access. Modifications may be applied to the copy of the portion of the hierarchical data structure. In response to a request to commit the modifications to the portion of the hierarchical data structure, the copy of the portion of the hierarchical data structure may atomically replace the portion of the hierarchical data structure.

Atomic application of multiple updates to a hierarchical data structure

Resource data objects describing resources in a system may be maintained in multiple different hierarchies for applying policies to manage the resources. Lookup requests may access the different hierarchies to determine which policies are applicable to a given resource based on the policies identified in each of the hierarchies. Modifications to hierarchies may be performed in isolation so that the application of policies in other hierarchies is unchanged by modifications to a different hierarchy. Access restrictions may be enforced with respect to hierarchies so that different users may be permitted access to different hierarchies for system resource management.

Different hierarchies of resource data objects for managing system resources

Multi-party updates may be performed for distributed systems. An agreement request may be received that proposes updates to a distributed system. An authorization scheme for the agreement request may be determined and approvers for the proposed updates identified according to the authorization scheme. Notifications may be provided to the approvers indicating the proposed updates to the distributed system. Responses from the approvers may be evaluated to determine whether the authorization scheme is satisfied for the proposed updates. If the authorizations scheme is satisfied, then the proposed updates may be performed to the distributed system.

Multi-party updates to distributed systems

Disclosed are various embodiments for the mapping of behavior to data. Multiple behavior elements from a code library that are compatible with one or more data elements of a document are determined according to a data contract associated with each one of the behavior elements. Each of the behavior elements is configured to consume one or more data elements and produce a user interface feature. One or more of the behavior elements are selected according to one or more rules. A mapping of the selected behavior elements to the data elements is generated.

Mapping behavior to data

Disclosed are various embodiments for a service testing application. A service testing application executes test operations for services in a service-oriented architecture. If a test is failed, services that are dependent upon a failing service are reconfigured to instead call a corresponding service in a different installation of the service-oriented architecture. A dependency model of the service-oriented architecture may be searched to determine which service dependencies to reconfigure.

Service testing framework

To achieve long running batch updates, a transaction aggregator layer and one or more data aggregation queues, such as a command queue, are placed between one or more clients and a database. Writes go to the database aggregator layer and are enqueued in the appropriate data aggregation queue, which may be allocated by transaction. Committing the transaction drains the queue and writes the contents of the queue in one transaction-like update to the database. By using the transaction logic in the transaction aggregator layer, transaction-like behavior may be achieved that allows both updates and transactions to scale with less impact on database servers.

Concurrency control in database transactions

A messaging frame can be used to allow different domains to communicate in an electronic environment that are otherwise prevented from directly communicating. A messaging frame or other communication element can be configured to receive messages or communications from any frame, object, or element in the same domain as the messaging frame. The messaging frame then can switch to a target domain in order to provide the message or communication to a frame, object, or element in the target domain. The messaging frame can include an interface definition that allows only approved messages to be passed between domains, such that the risk of malicious attack is minimized.

Cross-domain communication in domain-restricted communication environments

Disclosed are various embodiments for performing cross-domain communication using messenger frames. One or more messenger frames are dynamically generated in response to determining that a message is to be sent from a first frame in one domain to a second frame in another domain in a client. The message is sent from the first frame to the second frame by embedding the message in addresses of the messenger frames. Code executing in the first frame and code executing in the second frame are restricted from direct communication in the client.

Cross-domain communication

Disclosed are various embodiments for the mapping of behavior to data. Multiple behavior elements from a code library that are compatible with one or more data elements of a document are automatically determined according to a data contract associated with each one of the behavior elements. Each of the behavior elements is configured to consume one or more data elements and produce a network page feature according to a behavior. One or more of the behavior elements are selected automatically according to a plurality of rules, thereby producing one or more selected behavior elements. A mapping of the one or more selected behavior elements to the one or more data elements is automatically generated.

Embodiments of systems and methods are described for reducing latency during invoice generation involving credit distribution. In some implementations, references to invoice line items are sorted by supplemental charge rate and credits are applied to the invoice line items in decreasing supplemental charge rate order. An invoice is generated that includes the invoice line items and associated credits. The process of generating applying the credits is optimized to minimize latency and to provide the greatest financial benefit to the user.

Growing community of inventors

Seattle, WA, United States of America

Zachary Mohamed Shalla