jsquire

Azure.Core: AzureNamedKeyCredential

When using a shared key for authorization, some services require that the name of the key be used as a component of the algorithm to form the authorization token. For these cases, AzureKeyCredential and AzureSasCredential aren't adequate as they track only a single value. A new credential type, AzureNamedKeyCredential has been approved to address this gap.

Things to know before reading

• The names used in this document are intended for illustration only. Some names are not ideal and will need to be refined during discussions.

• Some details not related to the high-level concept are not illustrated; the scope of this is limited to the high level shape and paradigms for the feature area.

jsquire

Streaming Producer: Early Concept

The current story for publishing events offers a natural idiom when an application has a discrete set of events that it would like to treat as a single unit. When the producer is invoked, it offers a strong contract what allows the application to immediately understand whether publishing was successful or not. This approach is has many advantages, such as ensuring the client is not bound to any particular partition and can support publishing concurrently.

For applications that unable to efficiently batch events into a discrete set, the approach is less compelling. Publishing a single event or a small set can be inefficient and may impact throughput. For applications that view an event as a single item of data, the responsibility of managing batches introduces additional overhead and boilerplate code to collect those single events, track them, and package them as a batch efficiently.

Things to know before reading

• This is an early concept meant to serve as a po

jsquire

Event Hubs: BinaryData Member for EventData

In order to take advantage of integration with the ObjectSerializer for Schema Registry support as well as use a common idiom for data access and translation, the EventData type in the Event Hubs client library would like to take advantage of the BinaryData type introduced for the Azure.Core ecosystem.

Because Event Hubs is generally available and backwards compatibility needs to be preserved for existing applications using EventData, it is not possible to directly change the type on the existing Body member. This document outlines some of the considerations and options for doing so.

Things to know before reading

• The names used in this document are presented for discussion as potential final choices. Please provide feedback during discussion.

jsquire

Follow-Up: Client creation for application deployments across environments

This serves to illustrate some of the ideas surfaced during discussion of the options outlined in the Client creation for application deployments across environments and assumed familiarity with content of that document.

To ensure focus continues to be aligned, the goals and baseline illustrations have been brought forward for convenience.

Goal

Allow developers working with the Azure Messaging libraries to instantiate client types using a code path that adapts to changes in configuration without requiring code to be recompiled. Client creation between different environments should have minimal friction and require only simple, straightforward, and safe code that is appropriate for applications.

jsquire

Client creation for application deployments across environments

Things to know before reading

• The names used in this document are intended for illustration only. Some names are not ideal and will need to be refined during future design discussions.

• Where a specific Azure Messaging service was needed for illustration, Event Hubs was used. The concepts and options described herein would be applied for both Service Bus and Event Hubs.

• Some details not related to the high-level concept are not illustrated; the scope of this is limited to the high level shape and paradigms for the feature area.

jsquire

Event Hubs: Idempotent Event Publishing

Things to know before reading

• The names used in this document are intended for illustration only. Some names are not ideal and will need to be refined during discussions.

• Some details not related to the high-level concept are not illustrated; the scope of this is limited to the high level shape and paradigms for the feature area.

• Fake methods are used to illustrate "something needs to happen, but the details are unimportant." As a general rule, if an operation is not directly related to one of the Event Hubs types, it can likely be assumed that it is for illustration only. These methods will most often use ellipses for the parameter list, in order to help differentiate them.

jsquire

Event Hubs: Idempotent Event Publishing

When publishing events to Event Hubs, timeouts or other transient failures may introduce ambiguity into the understanding of whether a batch of events was received by the service. Because Event Hubs has an at-least-once guarantee for delivery and consumers are strongly encouraged to be idempotent in their processing, the common approach is to resend any batch where the status of receipt was unknown.

In some specialized scenarios, producers have a need to make efforts to avoid publishing duplicate events. To support these scenarios, the Event Hubs service is adding support for annotating messages with metadata to indicate the sequence in which events were intended to be published and to use that as an indicator of which events were already received by a the target partition. This functionality comes at a performance cost, however, and requires producers to follow a strict set of semantics to allow the service to perform server-side deduplication based on the intent

jsquire

Event Hubs: Idempotent Event Publishing

When publishing events to Event Hubs, timeouts or other transient failures may introduce ambiguity into the understanding of whether a batch of events was received by the service. Because Event Hubs has an at-least-once guarantee for delivery and consumers are strongly encouraged to be idempotent in their processing, the common approach is to resend any batch where the status of receipt was unknown.

In some specialized scenarios, producers have a need to make efforts to avoid publishing duplicate events. To support these scenarios, the Event Hubs service is adding support for annotating messages with metadata to indicate the sequence in which events were intended to be published and to use that as an indicator of which events were already received by a the target partition. This functionality comes at a performance cost, however, and requires producers to follow a strict set of semantics to allow the service to perform server-side deduplication based on the intent

jsquire

Applying the Alan.Parser Project to the AMQP Translation Layer

Azure Messaging Size Restrictions

Event Hubs Size Limits

• Basic: 256k
• Standard: 1MB
• Dedicatd: 1MB

Service Bus Size Limits

jsquire

Stress Thoughts

Requirements

Hosting

• The platform hosts multiple developer-authored test scenarios, encapsulating end-to-end use cases for the client library with varied complexity.

• The platform can execute test scenarios for a prolonged duration spanning multiple days, while monitoring and managing scenarios that are not in a responsive or healthy state.