using Azure.Messaging.SerivceBus.Transport.Amqp;
var message = DoSomethingToCreateTheServiceBusMessage();
var amqpBody = message.GetAmqpBody();
Jesse Squire jsquire
jsquire
/ brainstorm-amqpbody.md
Created
June 5, 2020 17:10
Brainstorming: Service Bus Message Transport Body
jsquire
/ custom-endpoint-address.md
Last active
October 9, 2023 15:05
Event Hubs: Custom Endpoint Support
Connections to the Azure Event Hubs service are made using the fully qualified namespace name assigned for the Event Hubs namespace as the root of the endpoint address. Because the Event Hubs service ensures the appropriate CNAME records are configured in DNS as part of the provisioning process, this provides an endpoint address that is strongly associated with the Event Hubs namespace and easier for developers to remember.
While the standard approach works well under normal circumstances, it can be troublesome in certain environments when a proxy is in use or when an Express Route circuit is used with certain configuration. In these scenarios, an alternative host name is needed to allow for proper routing to the Event Hubs service.
- The names used in this document are intended for illustration only. Some names are not ideal and will need to be refined during discussions.
jsquire
/ receiver-redirect.md
Last active
June 1, 2020 18:29
Event Hubs: Direct Partition Connections
Connections to the Azure Event Hubs service are typically made to a gateway endpoint, which holds responsibility for routing traffic to the appropriate service node for a given partition. This allows for a simplified client view of the service, without the need for awareness of individual nodes nor use of a discovery service as an intermediate step for opening connections.
The use of the gateway as an intermediary does incur additional latency when compared to the efficiency of using a direct node connection. In cases in which require maximum throughput, bypassing the gateway is desirable. The Event Hubs service offers the ability to opt-into a mechanism to discover the node currently hosting a given partition and the ability to directly connect to it, eliminating the gateway as an intermediary. This feature of the Event Hubs service is colloquially known as "receiver redirect."
As the familiar name implies, discovery of the Event Hubs node for a partition use
jsquire
/ messaging-transport-formatter.md
Last active
May 15, 2020 17:42
Azure Messaging: Allow control of the transport formatting
The Azure Messaging client libraries endeavor to provide an API surface that is protocol-agnostic and shaped such that it would be suitable for use with a variety of protocols and transport formats. Developers using the client libraries should not have to understand or be aware of the details related to AMQP, MQTT, STOMP, HTTP, JMS, or other protocols and transport formats that may be supported by the service - now or in the future; these details are considered the responsibility of the library.
Another goal of the Messaging client libraries is to support heterogeneous environments; when using the official Azure client libraries, data that was published with an SDK for one language should be understood when consumed with an SDK for any of the other supported languages.
There are, however, specialized scenarios when developers have need to participate in the preparation of transport messages. One such example is ensuring interoperability with
jsquire
/ eventhubs-retry-design.md
Created
February 28, 2020 15:23
Event Hubs Retry Design Proposal
Because Event Hubs is based on the AMQP protocol, there is no request/response cycle that defines an operation. Both the Event Hubs client and service make use of an operation timeout as means of coordination for managing their resources. When communicating with the Event Hubs service, the client library is required to specify an operation timeout on the AMQP link.
If an operation has not been completed within this timeout period, the client library will consider it a transient failure and apply its retry policy. Likewise, if the server is expecting communication from the client, such as a message acknowledgment, that does not occur within the timeout period, it will consider the operation to have failed.
The guidance for .NET design has been to strongly prefer cancellation tokens with timeout over explicit timeouts. However, this presents a challenge in the case of Event Hubs where t
jsquire
/ iot-hub-connection.md
Last active
November 9, 2020 13:44
IoT Hub: Connection String Translator Proposal
IoT Hub is a managed service that acts as a central message hub for bi-directional communication between an IoT application and the devices it manages. IoT Hub supports communications both from the device to the cloud and from the cloud to the device. IoT Hub supports multiple messaging patterns and may be integrated with other Azure services to build complete, end-to-end solutions.
One of the Azure services that IoT Hub is frequently integrated with is Azure Event Hubs. This document describes a proposed approach to helping developers using IoT Hub leverage the Event Hubs client library.
- The names used in this document are intended for illustration only. Some names are not ideal and will need to be refined during discussions.
jsquire
/ event-hubs-skeleton-january-2020.md
Last active
February 5, 2020 21:26
This skeleton represents the public API surface of the .NET Event Hubs client libraries in skeletal form, as they were proposed and reviewed for the preview 6 and January 2020 milestone releases.
public class EventHubConnection : IAsyncDisposable
{
This design is focused on the fifth preview of the track two Event Hubs client library, and limits the scope of discussion to those areas with active development for that preview. For wider context and more general discussion of the design goals for the track two Event Hubs client, please see:
- The names used in this document are intended for illustration only. Some names are not ideal and may not fully conform to guidelines; these will be refined during prototyping and board reviews.
jsquire
/ concept-event-hubs-track-2-retry-with-timeout.md
Last active
July 8, 2019 19:57
Because Event Hubs is based on the AMQP protocol, there is no request/response cycle that defines an operation. Both the Event Hubs client and service make use of an operation timeout as means of coordination for managing their resources. When communicating with the Event Hubs service, the client library is required to specify an operation timeout on the AMQP link.
If an operation has not been completed within this timeout period, the client library will consider it a transient failure and apply its retry policy. Likewise, if the server is expecting communication from the client, such as a message acknowledgment, that does not occur within the timeout period, it will consider the operation to have failed.
The guidance for .NET design has been to strongly prefer cancellation tokens with timeout over explicit timeouts. However, this presents a challenge in the case of Event Hubs where t
jsquire
/ event-hubs-concept-streaming-receive-track-two.md
Last active
June 28, 2019 14:54
When receiving events, Event Hubs typically offers two different conceptual approaches: requesting a batch of events or receiving events as they are published, whether by pull (iterating against a generator) or push (callback handler). The approach used for implementation varies by language, with the track one .NET client opting for push-via-callback.
var client = new EventHubClient("<< Connection String >>", "SomeHub");