{"id":918,"date":"2021-01-26T11:26:33","date_gmt":"2021-01-26T19:26:33","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/azure-sdk\/?p=918"},"modified":"2021-03-03T10:33:32","modified_gmt":"2021-03-03T18:33:32","slug":"eventhubs-clients","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/azure-sdk\/eventhubs-clients\/","title":{"rendered":"How to choose the right Azure Event Hubs .NET client library type for your application"},"content":{"rendered":"

Azure Event Hubs<\/a> is a highly scalable publish-subscribe service that can ingest millions of events per second and stream them to multiple consumers. This lets you process and analyze the massive amounts of data produced by your connected devices and applications. Once Event Hubs has collected the data, you can retrieve, transform, and store it using any real-time analytics provider, such as Azure Stream Analytics<\/a>, or with batching\/storage adapters.<\/p>\n

Since its introduction, the Event Hubs service and the libraries used to interact with it have been evolving to offer more features and a world-class experience for developers. As a consequence of continual improvement while avoiding changes that may break existing applications, several generations of libraries for Azure Event Hubs have been released into the ecosystem. In addition to there being multiple libraries, each offers a slightly different set of clients for use in applications. Because of the number of options, it can be confusing to know which is best suited for your application.<\/p>\n

This article will focus on the current generation client library, Azure.Messaging.EventHubs<\/code>, which we recommend for developing of new applications and, where possible when enhancing existing applications. Our goal is that, after reading, you have an understanding of the producer, consumer, and processor types that are offered and the scenarios where they are best applied.<\/p>\n

Event Hubs Client Library Packages for .NET<\/h2>\n

Azure.Messaging.EventHubs<\/h3>\n

Azure.Messaging.EventHubs<\/a> is the current generation of the library and is under active development, with improvements and new features being released on a regular cadence. It supports the netstandard2.0<\/code> platform, allowing it to be used with a wide range of host environments including .NET 5, .NET Core, and the full .NET Framework. The library retains high-level feature parity with the previous generation, Microsoft.Azure.EventHubs<\/code>, but with a more discrete client hierarchy and improved API.<\/p>\n

The Azure.Messaging.EventHubs<\/code> library is part of the initiative to improve the development experience across Azure services. To this end, it follows a set of uniform design guidelines<\/a> intended to drive a consistent experience across development languages and employ established API patterns for all Azure services. The library also follows a set of .NET-specific guidelines<\/a> to ensure that the .NET SDK has a natural and idiomatic feel that mirrors that of the .NET base class libraries.<\/p>\n

The Azure.Messaging.EventHubs<\/code> library also provides the ability to share in some of the cross-service improvements made to the Azure development experience, such as a unified diagnostics pipeline offering a common view of the activities across each of the client libraries. Another key improvement is a streamlined and simplified experience for authentication using the new Azure.Identity<\/a> library to share credentials between the clients for different Azure services.<\/p>\n

Microsoft.Azure.EventHubs (legacy)<\/em><\/h3>\n

This is the previous generation library, the first to be dedicated to Event Hubs. This library is still supported by Microsoft, and will be well into the future. However, development is focused only on bug fixes and critical updates. It will not be receiving the new features and enhancements developed for Azure.Messaging.EventHubs<\/code>.<\/p>\n

We recommend using this library only for legacy applications that have an existing dependency on it, not for developing new applications.<\/p>\n

Windows.Azure.ServiceBus (legacy)<\/em><\/h3>\n

This is the oldest of the legacy libraries, supporting the Azure Messaging offerings as a whole rather than being dedicated to any one service. This design stems from when Event Hubs was still bound to Service Bus and was not a true stand-alone product. The library supports only the full .NET Framework and is not compatible with .NET Core. It offers a different feature set than the more recent client libraries, and does not have high-level feature parity with the newer generations.<\/p>\n

While this library is still supported by Microsoft, development is limited to critical bug fixes. It will not be receiving the new features and enhancements developed for Azure.Messaging.EventHubs<\/code>. We recommend using this library only for legacy applications that have an existing dependency on it, not for developing new applications.<\/p>\n

Choosing a Client from Azure.Messaging.EventHubs<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\n I want to…\n <\/th>\n\n Event Hubs clients\n <\/th>\n\n More information\n <\/th>\n<\/tr>\n<\/thead>\n
\n Explore Event Hubs by publishing and reading events\n <\/td>\n\n EventHubProducerClient
and
EventHubConsumerClient\n <\/td>\n		\n Sample<\/a>\n <\/td>\n<\/tr>\n
\n Publish events\n <\/td>\n\n EventHubProducerClient\n <\/td>\n\n Sample<\/a>\n <\/td>\n<\/tr>\n
\n Read events from all partitions of an Event Hub in a typical production application, using Azure Storage Blobs to store checkpoint and load balancing data\n <\/td>\n\n EventProcessorClient\n <\/td>\n\n Sample<\/a>\n <\/td>\n<\/tr>\n
\n Read events from a single partition of an Event Hub\n <\/td>\n\n EventConsumerClient\n <\/td>\n\n Sample<\/a>\n <\/td>\n<\/tr>\n
\n Read events from all partitions of an Event Hub and store checkpoint and load balancing data somewhere other than Azure Storage Blobs\n <\/td>\n\n EventProcessor\n <\/td>\n\n Article<\/a>\n <\/td>\n<\/tr>\n
\n Read events from a single partition of an Event Hub for an application with high-throughput needs\n <\/td>\n\n PartitionReceiver\n <\/td>\n\n Sample<\/a>\n <\/td>\n<\/tr>\n
\n Read events from all partitions of an Event Hub for an application with high-throughput needs\n <\/td>\n\n EventProcessor\n <\/td>\n\n Article<\/a>\n <\/td>\n<\/tr>\n
\n Read events from a single partition of an Event Hub using a batch-based approach\n <\/td>\n\n PartitionReceiver\n <\/td>\n\n Sample<\/a>\n <\/td>\n<\/tr>\n
\n Read events from all partitions of an Event Hub using a batch-based approach\n <\/td>\n\n EventProcessor\n <\/td>\n\n Article<\/a>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Azure.Messaging.EventHubs Client Details<\/h2>\n

The Azure.Messaging.EventHubs<\/code> library has the goal of providing an approachable onboarding experience for developers new to messaging and\/or Event Hubs, focusing on enabling a quick initial feedback loop for publishing and consuming events. As developers shift from exploration to tackling real-world production scenarios, the library offers a gradual step-up path, building on the onboarding experience with additional robustness while maintaining a familiar API surface. For applications with high-throughput or special needs, a set of primitives are available to allow developers to work at a low-level and assert more control.<\/p>\n

Each Event Hubs client targets a specific area of Event Hubs functionality, presenting an API focused on a concrete set of scenarios. We believe this avoids the distraction of a more complex API surface with areas which are likely to be needed only for more specialized scenarios. To support this design, the client hierarchy has been organized to align with two general categories, mainstream and specialized.<\/p>\n

The mainstream set of clients were designed to address the most common production application scenarios and to provide an onboarding experience for those new to Event Hubs. The specialized set of clients focus on high-throughput and enabling developers to assert a higher degree of control. This section will briefly introduce the clients in both categories, though samples will continue to focus heavily on the mainstream clients.<\/p>\n

Mainstream<\/h3>\n

Event Hub Producer Client<\/h4>\n

The EventHubProducerClient<\/a> is responsible for publishing event data to the associated Event Hub. The client supports a flexible set of options when publishing, offering a reasonable set of defaults for exploring Event Hubs and for the majority of production scenarios. As application needs become more specialized, the options can be tuned to allow for greater control over publishing and optionally bypassing some of the validation offered by the client for higher throughput.<\/p>\n

Event Hub Consumer Client<\/h4>\n

The EventHubConsumerClient<\/a> serves as the onboarding point for consuming events by reading from all partitions without the rigor and complexity that you would need in a production application. This is intended to streamline and simplify exploration, allowing developers a feedback loop without the need to understand many of the underlying details.<\/p>\n

The production scenario for the EventHubConsumerClient<\/code> is focused on reading events from a single partition with an iterator-based approach, providing a streaming experience using the await foreach<\/code> syntax of an asynchronous enumerable. This pattern allow events to be read in a continuous fashion, waiting if no events are available, or with a timeout that allows control to be returned to the body of the loop on a predictable schedule for heartbeats and other activities.<\/p>\n

For reading events from all partitions in a production scenario, we strongly recommend using the EventProcessorClient<\/code> or EventProcessor<TPartition><\/code> over the EventHubConsumerClient<\/code>.<\/p>\n

Event Processor Client<\/h4>\n

The EventProcessorClient<\/a> is intended to serve as the primary consumer of events in production scenarios for the majority of workloads. It is responsible for reading and processing events for all partitions of an Event Hub and collaborates with other EventProcessorClient<\/code> instances using the same Event Hub and consumer group to balance work between them. A high degree of fault tolerance is built-in, allowing the processor to be resilient in the face of errors.<\/p>\n

A key feature of the EventProcessorClient<\/code> is allowing the application to track which events have been processed and persisting them to some form or durable storage so that progress is resilient across failures and observed as instances scale up or down and load-balance. This process is commonly referred to as checkpointing<\/a> and the persisted state as a checkpoint. This version of the EventProcessorClient<\/code> supports only Azure Storage Blobs as a backing store; the EventProcessor<\/a> supports implementing other storage providers.<\/p>\n

The EventProcessorClient<\/code> is located in the Azure.Messaging.EventHubs.Processor<\/a> package.<\/p>\n

Specialized<\/h3>\n

Partition Receiver<\/h4>\n

The PartitionReceiver<\/a> is responsible for consuming events from a specific partition of an Event Hub, offering a lower-level API with greater control over resource use. The PartitionReceiver<\/code> utilizes a batch-based pull model for applications requesting events. This allows Event Hubs service communication and network activities to be deterministic, initiated by an application request and avoids the need for implicit background operations.<\/p>\n

Each PartitionReceiver<\/code> represents a single consumer scope with one lifespan, able to read events from a partition in a stateful manner and with predictable resource use. Because each instance is self-contained, the PartitionReceiver<\/code> supports creating multiple receivers for the same partition concurrently, with each able to independently read from a different location in the event stream.<\/p>\n

Event Processor<\/h4>\n

The EventProcessor<\/a> provides a base to create a custom client for reading and processing events for all partitions of an Event Hub. It collaborates to balance work with other clients derived from EventProcessor<TPartition><\/code> as well as EventProcessorClient<\/code> instances using the same Event Hub and consumer group. A high degree of fault tolerance is built-in, allowing the derived processors to be resilient in the face of errors.<\/p>\n

Though it serves a similar role to the EventProcessorClient<\/code>, the EventProcessor<TPartition><\/code> provides a lower-level API with less ceremony and greater control over resource use. It offers native batch-based processing via method override rather than using the event handler pattern to process a single event at a time. The EventProcessor<TPartition><\/code> also enables defining a custom partition context for applications that wish to track additional state while processing.<\/p>\n

While the EventProcessorClient<\/code> is an opinionated implementation strongly bound to Azure Storage Blobs, the EventProcessor<TPartition><\/code> has no affiliation to a specific storage provider, allowing data-bound operations to be fully controlled by the derived client via method overload.<\/p>\n

Azure Event Hubs Information<\/h2>\n

The Event Hubs client library offers an extensive set of samples, covering many of the core concepts of messaging and Event Hubs as well as usage of the client. They are organized by package and can be found in the GitHub repository:<\/p>\n