Has anyone built an NServiceBus system which allows many interested / 3rd parties to host an endpoint? Consider for example, an airport, which is the system owner for both flights and baggage handling.
Let’s say we’re providing a NSB architecture for a baggage handling system and we want to let baggage handlers / airlines know about bags which have been routed to their baggage loading points via a sortation system.
We would have an event BagDelivered which would have properties like flight, airline, baggage handler, chute number etc.
We want to inform the baggage handler and the airline about this event and preference would be to do it over the bus.
The baggage handler / airline would be responsible for providing their own endpoint to handle these events and process them into whatever systems they would like. (i.e. pass the cost of integration onto them)
Now, obviously, we only want airlines to receive the events specific to their airline. Considering the number of airlines, it would be impractical to create a BagDelivered event for each airline, particularly as new airlines may start serving an airport etc.
Now, how can this be made to work with NSB? The pub/sub pattern does not allow for this (effectively content based routing but shh!)
Is NSB the wrong kind of architecture for this type of application?
I’m not sure if I have the correct picture in front of me, after reading your question. So bear with me if I make incorrect assumptions and correct me where I’m wrong.
What I (think I) understand is that there will be a custom build system that sends messages to an unknown number of 3rd parties that are interested in messages about processed-baggage. Although they need to be filtered, so that they only get messages that concern them. This is the concern of the custom-build system.
If there aren’t a thousand 3rd party systems, one option would be to create a subscriber per 3rd party. I explicitly say ‘subscriber’ because you have the option to have multiple handlers (one for each 3rd party, for example) in a single endpoint. Or have an endpoint (with multiple handlers) per 3rd party. That’s completely up to you.
The idea is that each subscriber would then be able to filter messages. This is still your endpoint and therefore able to filter based on whatever you want. That would mean no content-based routing, but message filtering based on content in the endpoint for a specific 3rd party. WIth you being totally in control.
From there, I would likely not go with the 3rd parties delivering their own endpoint. That would require them to know C# and more. It’s likely one supports push (via webhooks or anything) and others would be able to pull. In the push scenario you would immediately push based on an incoming message. In the pull scenario you would prepare data for the 3rd party and have them acknowledge anything they have received. In both cases it is their responsibility to acknowledge your information correctly. Once you have the ack, it’s your job to mark the items as dispatched. In the push scenario this is basically telling NServiceBus everything was processed correctly. In the pull scenario this is marking it in the database (or deleting it).
In this case you’ll be in control, have the ability to provide multiple options and every subscriber is responsible for its own implementation. So one implementation could work with webhooks, another with a ASP.NET WebApi providing an http endpoint to pull messages, etc, etc.
But it could also be as simple as some configuration that based on a value in a certain field that it needs to go to some webhook, and otherwise another webhook. Kind of like a mapping file, where based on 1 or 2 properties it should push data to a certain webhook.
Does that make sense? If you want to discuss this more, we also have the ability to get on a conference call, if you’d like. Let me know what your preference is.