drub0y / obvs.azureservicebus

Microsoft Azure ServiceBus transport support for the Obvs framework.

Obvs.AzureServiceBus

An Azure ServiceBus transport support for the Obvs framework.

---

Features

Azure Service Bus Supported Messaging Entities

The following Azure ServiceBus messaging entities are currently supported by this transport:

• Queues
• Topics
• Subscriptions

Peek-Lock Message Control

As of Obvs 3.x, the library offers no out-of-the-box control over peek-lock style messages like those you might receive from Azure Service Bus. Therefore this library offers a small API-subset that is designed to be agnostic of Azure Service Bus at the surface level, yet gives you the full control you would expect over peek-lock style messages as if you were working with Azure Service Bus's BrokeredMessage class directly.

Please note: you must opt-in to PeekLock mode as the default is ReceiveAndDelete. This is to stay consistent with the Azure Service Bus API itself.

You can read more on this subject here in the Wiki.

---

Basic Scenario Examples

The following examples show how you would configure the service bus for a variety of basic scenarios.

Sending commands from an Azure Service Bus Queue

Shows how to configure the bus to send commands to an Azure Service Bus Queue.

// Configure the bus with a queue
var serviceBusClient = ServiceBus<MyMessage, MyCommand, MyEvent, MyRequest, MyResponse>.Configure()
                .WithAzureServiceBusEndpoint()
                .Named("My Service Bus")
                .WithConnectionString(ConfigurationManager.AppSettings["MyServiceBusConnectionString"])
                .UsingQueueFor<MyCommand>("my-commands")
                .SerializedAsJson()
                .AsClient()
                .CreateServiceBusClient();                

// Send a command via the configured client
await serviceBusClient.SendAsync(new MyFancyCommand());

Sending events to an Azure Service Bus Topic

// Configure the bus with a topic
var serviceBus = ServiceBus<MyMessage, MyCommand, MyEvent, MyRequest, MyResponse>.Configure()
                .WithAzureServiceBusEndpoint()
                .Named("My Service Bus")
                .WithConnectionString(ConfigurationManager.AppSettings["MyServiceBusConnectionString"])
                .UsingTopicFor<MyEvent>("my-events")
                .SerializedAsJson()
                .AsServer()
                .CreateServiceBus();
                
// Publish an event via the configured service bus
await serviceBus.PublishAsync(new MySpecialEvent());

Receiving events from an Azure Service Bus Subscription using Peek-Lock mode

// Configure the bus with a specific subscription
var serviceBusClient = ServiceBus<MyMessage, MyCommand, MyEvent, MyRequest, MyResponse>.Configure()
                .WithAzureServiceBusEndpoint()
                .Named("My Service Bus")
                .WithConnectionString(ConfigurationManager.AppSettings["MyServiceBusConnectionString"])
                .UsingSubscriptionFor<MyEvent>("my-events", "my-subscription", MessageReceiveMode.PeekLock)
                .SerializedAsJson()
                .AsClient()
                .CreateServiceBusClient();
                
// Process all events that come in via my subscription
serviceBusClient.Events.Subscribe(myEvent =>
{
    // ... handle the incoming event with whatever domain specific logic here ...
    
    // Signal completion of the peek lock
    myEvent.GetPeekLockControl().CompleteAsync().Wait();     
});

obvs.azureservicebus's Issues

Delete messaging entities that are created with CreateAsTemporary

The entire idea behind MessagingEntityCreationOptions.CreateAsTemporary is that the framework will clean up the messaging entity when it's no longer being used.

The challenge here is that many MessageSource/MessagePublisher instances may be referencing the same temporary entity and we can only clean it up once we know all of those instances that are referencing it have been thrown away. I think this will require some kind of reference counting mechanism on the MessageTypePathMappingDetails instance that the MessageSource'/'MessagePublisher' instances will decrement in their ownDisposeimplementations. once the ref count reacheszerotheMessageTypePathMappingDetails` could perform the clean up of its temporary messaging entity.

Support for Sessions

Need to come up with a configuration method for indicating that sessions should be used to receive messages. Basic implementation would simply accept each session and iterate through all of its available messages before moving on to the next session. While this would work, it does not necessarily provide all the possible benefits of having sessions.

Should consider whether the fact that sessions are being used should be surfaced in the API by switching the result type to something like IObservable<IObservable<TMessage>> where each of the values emitted is an IObservable representing the messages within a session. Doing so would allow application logic to partition its work in terms of concurrency amongst sessions, but I'm not sure if the core Obvs [Configuration] API lends itself to presenting this kind of representation.

PeekLock default values

In the readme it is called out that the default is ReceiveAndDelete but PeekLock has the default value of 0 and in this overload the PeekLock value seems to be used as the default as well:

• Obvs.AzureServiceBus/Obvs.AzureServiceBus/Configuration/AzureServiceBusFluentConfig.cs

  Line 249 in cf5461c

  return UsingSubscriptionFor<T>(topicPath, subscriptionName, MessageReceiveMode.PeekLock, creationOptions);

• Obvs.AzureServiceBus/Obvs.AzureServiceBus/Configuration/AzureServiceBusFluentConfig.cs

  Line 16 in cf5461c

  PeekLock,

Either way I recommend explicitly assigning values to that enum.

The workaround for now is to just explicitly choose ReceiveAndDelete

Replace the requirement of inheriting from PeekLockMessage with a dynamic proxy class approach

Right now if someone wants to use peek-look message control they must inherit from the PeekLockMessage as their base class. This is terrible for all the known reasons in the software universe that I won't rehash here.

Instead of requiring inheritance, we can instead move towards a dynamic proxy class approach where the only requirement is that the user's custom message types cannot be marked as sealed. Then we will dynamically generate a proxy class per message type that provides the proper peek lock functionality.

Replace the requirement of inheriting from PeekLockMessage with the use of ConditionalWeakTable behind the scenes

Right now if someone wants to use peek-look message control they must inherit from the PeekLockMessage as their base class. This is terrible for all the known reasons in the software universe that I won't rehash here.

When a message comes off a queue/subscription that is using MessageReceiveMode.PeekLock we should store the message as the key of a ConditionalWeakTable and store the BrokeredMessage (or some custom data type if more data needs to be associated) as the value.

EnsureMessagingEntityExists creates entity unconditionally

In file Obvs.AzureServiceBus/Obvs.AzureServiceBus/Configuration/MessageClientEntityFactory.cs, the method MessageClientEntityFactory.EnsureMessagingEntityExists calls local function create() regardless of whether the target messaging entity already exists. If the entity does already exist, Azure Service Bus throws a MessagingEntityAlreadyExistsException.

The simplest (but not necessarily best) fix is to wrap if (!alreadyExists) { ... } around the try/catch block starting at line 244.

Update Obvs.AzureServiceBus to use Obvs v4.0

Hi, version 4.0 of Obvs is out, converted to new csproj format and depending on System.Reactive 3.x. Please can you update Obvs.AzureServiceBus to Obvs 4.0.