Search code examples
nservicebus

Webservice integration from endpoint

I need to integrate a third party WebService into a messaging based architecture. We are using NServiceBus.

From a PluralSight course on NServiceBus, it was recommended that when integrating a WebService, to create a specific WebService gateway endpoint for this integration.

The 3rd party WebService has API methods for pulling down notifications and acknowledging these. A client of this WebService is required to regularly (for example every 15 mins) pull notifications and acknowledge each of these notifications when correctly processed.

The suggested flow would be as follows:

  1. The NServiceBus WebService Gateway endpoint would pull notifications and send messages to another NServiceBus endpoint, based on the type of notification. For example: a "new customer notification" would mean sending a NewCustomer message to another NServiceBus endpoint. A "customer renewed" notification would mean sending a CustomerUpdated message etc.
  2. Once a message has been passed on to the other endpoint, we will have to acknowledge the notification by WebService API call to the 3rd party. The idea here would be to send a "AcknowledgeNotification" message to the same NServiceBus gateway endpoint (self) and have it picked up by a message handler.

See diagram here: Diagram

My questions are:

  1. Is it a design smell to send the AcknowledgeNotification messages from an endpoint to the same endpoint. (self)
  2. We would like to host the messaging infrastructure in Azure. Any tips on how to host the endpoints, when the gateway endpoint will require a worker role, which pulls notifications at a regular interval? Would it be possible to host all endpoints in one Azure Cloud Service or is it better to host each endpoint in it's own cloud service?

Cheers

Solution

  • Question Part 1

    I don't think it is a code smell. I've done this several times myself. It's a reliable way of ensuring an interaction with a dependency occurs successfully.

    I would lean on acknowledgements being driven from events. This will allow more extensible points in your software. For example: CreateCustomer command would publish CustomerCreated event. UpdateCustomer command would publish CustomerUpdated event.

    You can have one handler handle both events generically and submit an acknolwedgement AckHandler: IHandle<CustomerCreated>, IHandle<CustomerUpdate>.

    But to recap to your actual question, I don't believe it is a code smell.

    Question Part 2

    (Next time I suggest creating a separate question all together)

    As for hosting in Azure, I would probably lean towards hosting them in a WebJob. The WebApp is just a hosting platform and can host both a WebSite AND a series of WebJobs. They are a little cheaper with less control but super easy scaling story.

    Remember, before you need to scale horizontally, you can scale the vertically by tweaking the concurrency setting of each host to find the right amount of threads it can handle (NSB < 5 is max 20 threads; NSB >=6 is 100 threads).

    You can host them all in one to start out with.