Abstract: A sharded, permissioned, distributed ledger may reduce the amount of work and communication required by each participant, thus possibly avoiding scalability bottlenecks that may be inherent in previous distributed ledger implementations and possibly enabling the use of additional resources to translate to increased throughput. A sharded, permissioned, distributed ledger may be made up of multiple shards, each of which may also be a distributed ledger and which may operate in parallel. Participation within a sharded, permissioned, distributed ledger may be allowed only with permission of an authority. A sharded, permissioned, distributed ledger may include a plurality of nodes, each including a dispatcher configured to receive transaction requests from clients and to forward received requests to verifiers configured to append transactions to individual ones of the shards.

Abstract: A sharded, permissioned, distributed ledger may reduce the amount of work and communication required by each participant, thus possibly avoiding scalability bottlenecks that may be inherent in previous distributed ledger implementations and possibly enabling the use of additional resources to translate to increased throughput. A sharded, permissioned, distributed ledger may be made up of multiple shards, each of which may also be a distributed ledger and which may operate in parallel. Participation within a sharded, permissioned, distributed ledger may be allowed only with permission of an authority. A sharded, permissioned, distributed ledger may include a plurality of nodes, each including a dispatcher configured to receive transaction requests from clients and to forward received requests to verifiers configured to append transactions to individual ones of the shards.

Abstract: A sharded, permissioned, distributed ledger may reduce the amount of work and communication required by each participant, thus possibly avoiding scalability bottlenecks that may be inherent in previous distributed ledger implementations and possibly enabling the use of additional resources to translate to increased throughput. A sharded, permissioned, distributed ledger may be made up of multiple shards, each of which may also be a distributed ledger and which may operate in parallel. Participation within a sharded, permissioned, distributed ledger may be allowed only with permission of an authority. A sharded, permissioned, distributed ledger may include a plurality of nodes, each including a dispatcher configured to receive transaction requests from clients and to forward received requests to verifiers configured to append transactions to individual ones of the shards.

Abstract: A sharded, permissioned, distributed ledger may reduce the amount of work and communication required by each participant, thus possibly avoiding scalability bottlenecks that may be inherent in previous distributed ledger implementations and possibly enabling the use of additional resources to translate to increased throughput. A sharded, permissioned, distributed ledger may be made up of multiple shards, each of which may also be a distributed ledger and which may operate in parallel. Participation within a sharded, permissioned, distributed ledger may be allowed only with permission of an authority. A sharded, permissioned, distributed ledger may include a plurality of nodes, each including a dispatcher configured to receive transaction requests from clients and to forward received requests to verifiers configured to append transactions to individual ones of the shards.

Abstract: A sharded, permissioned, distributed ledger may reduce the amount of work and communication required by each participant, thus possibly avoiding scalability bottlenecks that may be inherent in previous distributed ledger implementations and possibly enabling the use of additional resources to translate to increased throughput. A sharded, permissioned, distributed ledger may be made up of multiple shards, each of which may also be a distributed ledger and which may operate in parallel. Participation within a sharded, permissioned, distributed ledger may be allowed only with permission of an authority. A sharded, permissioned, distributed ledger may include a plurality of nodes, each including a dispatcher configured to receive transaction requests from clients and to forward received requests to verifiers configured to append transactions to individual ones of the shards.

Abstract: A sharded, permissioned, distributed ledger may reduce the amount of work and communication required by each participant, thus possibly avoiding scalability bottlenecks that may be inherent in previous distributed ledger implementations and possibly enabling the use of additional resources to translate to increased throughput. A sharded, permissioned, distributed ledger may be made up of multiple shards, each of which may also be a distributed ledger and which may operate in parallel. Participation within a sharded, permissioned, distributed ledger may be allowed only with permission of an authority. A sharded, permissioned, distributed ledger may include a plurality of nodes, each including a dispatcher configured to receive transaction requests from clients and to forward received requests to verifiers configured to append transactions to individual ones of the shards.

Abstract: An authenticated modular map library may support partial state for a key-value store. A key-value store may be created that is organized as a tree data structure that divides items into pages. Features to access the key-value store may also be specified when the key-value store is created. A portion of the key-value store may be sent to a participant of a blockchain network, which may attempt to access an item to be found in a page in the key-value store according to the specified features. If the page is not included in the portion, the page may be requested from another participant, received, and verified before being used to complete the attempted access of the item.

Abstract: A sharded, permissioned, distributed ledger may reduce the amount of work and communication required by each participant, thus possibly avoiding scalability bottlenecks that may be inherent in previous distributed ledger implementations and possibly enabling the use of additional resources to translate to increased throughput. A sharded, permissioned, distributed ledger may be made up of multiple shards, each of which may also be a distributed ledger and which may operate in parallel. Participation within a sharded, permissioned, distributed ledger may be allowed only with permission of an authority. A sharded, permissioned, distributed ledger may include a plurality of nodes, each including a dispatcher configured to receive transaction requests from clients and to forward received requests to verifiers configured to append transactions to individual ones of the shards.

Abstract: A system and method can support asynchronous request/response in a network environment. A network protocol can utilize a load balancer to balance requests, such as HTTP requests, over a fast network interface, such as InfiniBand, to one or more nodes of an application server cluster. The system and method can attach headers to the requests such that the requests can be sent in an interleaved manner. The system and method can further allow for sending of large requests by breaking up the large requests into smaller portions, and sending each portion, interleaved, with other requests.

Abstract: A sharded, permissioned, distributed ledger may reduce the amount of work and communication required by each participant, thus possibly avoiding scalability bottlenecks that may be inherent in previous distributed ledger implementations and possibly enabling the use of additional resources to translate to increased throughput. A sharded, permissioned, distributed ledger may be made up of multiple shards, each of which may also be a distributed ledger and which may operate in parallel. Participation within a sharded, permissioned, distributed ledger may be allowed only with permission of an authority. A sharded, permissioned, distributed ledger may include a plurality of nodes, each including a dispatcher configured to receive transaction requests from clients and to forward received requests to verifiers configured to append transactions to individual ones of the shards.

Abstract: An authenticated modular map library may support partial state for a key-value store. A key-value store may be created that is organized as a tree data structure that divides items into pages. Features to access the key-value store may also be specified when the key-value store is created. A portion of the key-value store may be sent to a participant of a blockchain network, which may attempt to access an item to be found in a page in the key-value store according to the specified features. If the page is not included in the portion, the page may be requested from another participant, received, and verified before being used to complete the attempted access of the item.

Abstract: The present disclosure relates generally to techniques for improving reliability of message communications. In certain embodiments, techniques are described for facilitating reliable communication of messages between a source (e.g., a client system) and a destination (e.g., a target system) via an intermediary communication handler system. In certain embodiments, a message can include a request to be communicated to a destination for a target service. An intermediary communication handler system can store information indicative of the delivery status for a message to ensure reliable communication. The information indicative of the delivery status for a message can be managed in association with a unique identifier corresponding to the message. The information indicative of the delivery status for a message may also be used to determine whether to retry communication of a message in satisfaction of reliability parameters (e.g.

Abstract: A sharded, permissioned, distributed ledger may reduce the amount of work and communication required by each participant, thus possibly avoiding scalability bottlenecks that may be inherent in previous distributed ledger implementations and possibly enabling the use of additional resources to translate to increased throughput. A sharded, permissioned, distributed ledger may be made up of multiple shards, each of which may also be a distributed ledger and which may operate in parallel. Participation within a sharded, permissioned, distributed ledger may be allowed only with permission of an authority. A sharded, permissioned, distributed ledger may include a plurality of nodes, each including a dispatcher configured to receive transaction requests from clients and to forward received requests to verifiers configured to append transactions to individual ones of the shards.

Abstract: The present disclosure relates generally to techniques for improving reliability of message communications. In certain embodiments, techniques are described for facilitating reliable communication of messages between a source (e.g., a client system) and a destination (e.g., a target system) via an intermediary communication handler system. In certain embodiments, a message can include a request to be communicated to a destination for a target service. An intermediary communication handler system can store information indicative of the delivery status for a message to ensure reliable communication. The information indicative of the delivery status for a message can be managed in association with a unique identifier corresponding to the message. The information indicative of the delivery status for a message may also be used to determine whether to retry communication of a message in satisfaction of reliability parameters (e.g.

Abstract: A system and method for providing a dynamic invocation and service interface for use in a middleware or other environment. At the service-side, messages can be inserted into an inbound processing chain. After service-side inbound processing, messages are given to the user via a provider request function. The user gives a response by using a provider response function that inserts messages into a service-side outbound processing chain. After service-side outbound processing, messages are given to the user's service response transport. On the client side, the user can insert messages into the outbound processing chain using a dispatcher request. After client-side outbound processing, messages are given to the user's client request transport. This decouples message processing from the transport and makes the message processing asynchronous in nature. When the response is received, a user uses a client response transport function to insert the response into the client-side inbound processing chain.

Abstract: The present disclosure relates generally to techniques for improving reliability of message communications. In certain embodiments, techniques are described for facilitating reliable communication of messages between a source (e.g., a client system) and a destination (e.g., a target system) via an intermediary communication handler system. In certain embodiments, a message can include a request to be communicated to a destination for a target service. An intermediary communication handler system can store information indicative of the delivery status for a message to ensure reliable communication. The information indicative of the delivery status for a message can be managed in association with a unique identifier corresponding to the message. The information indicative of the delivery status for a message may also be used to determine whether to retry communication of a message in satisfaction of reliability parameters (e.g.

Abstract: A system and method can support asynchronous request/response in a network environment. A network protocol can utilize a load balancer to balance requests, such as HTTP requests, over a fast network interface, such as InfiniBand, to one or more nodes of an application server cluster. The system and method can attach headers to the requests such that the requests can be sent in an interleaved manner. The system and method can further allow for sending of large requests by breaking up the large requests into smaller portions, and sending each portion, interleaved, with other requests.

Abstract: A system and method for providing a dynamic invocation and service interface for use in a middleware or other environment. At the service-side, messages can be inserted into an inbound processing chain. After service-side inbound processing, messages are given to the user via a provider request function. The user gives a response by using a provider response function that inserts messages into a service-side outbound processing chain. After service-side outbound processing, messages are given to the user's service response transport. On the client side, the user can insert messages into the outbound processing chain using a dispatcher request. After client-side outbound processing, messages are given to the user's client request transport. This decouples message processing from the transport and makes the message processing asynchronous in nature. When the response is received, a user uses a client response transport function to insert the response into the client-side inbound processing chain.

Abstract: A system and method for providing a dynamic invocation and service interface for use in a middleware or other environment. At the service-side, messages can be inserted into an inbound processing chain. After service-side inbound processing, messages are given to the user via a provider request function. The user gives a response by using a provider response function that inserts messages into a service-side outbound processing chain. After service-side outbound processing, messages are given to the user's service response transport. On the client side, the user can insert messages into the outbound processing chain using a dispatcher request. After client-side outbound processing, messages are given to the user's client request transport. This decouples message processing from the transport and makes the message processing asynchronous in nature. When the response is received, a user uses a client response transport function to insert the response into the client-side inbound processing chain.

Abstract: The present disclosure relates generally to techniques for improving reliability of message communications. In certain embodiments, techniques are described for facilitating reliable communication of messages between a source (e.g., a client system) and a destination (e.g., a target system) via an intermediary communication handler system. In certain embodiments, a message can include a request to be communicated to a destination for a target service. An intermediary communication handler system can store information indicative of the delivery status for a message to ensure reliable communication. The information indicative of the delivery status for a message can be managed in association with a unique identifier corresponding to the message. The information indicative of the delivery status for a message may also be used to determine whether to retry communication of a message in satisfaction of reliability parameters (e.g.