Hi Experts
I would like to build a new custom transport for NServiceBus. I couldn’t find any relevant documentation regarding the same. Can someone please point me to documentation or template for the same?
Regards
Sumeet
Hi Sunmeet,
Have you seen this article?
While there’s no detailed information, this document could be a good starting point. Once you have something going, you could share your repo link for a review/suggestions.
Hi Sean
Thanks for your reply.
Yes, I have seen this before and was looking for some detailed documentation around building custom transport. It certainly gives some pointers though.
Regards
Sumeet
Unfortunately that doesn’t exist 
You’re always welcome to ping here when you have specific questions.
Hi Sumeet
Can you explain what kind of custom transport you are thinking about? Maybe also elaborate a bit on why the existing supported transport don’t seem to fit your needs? Your information is hugely valuable for us when we further elaborate our transport offerings.
Regards
Daniel
Dear Daniel,
I am looking to build a generic OpenStandards based (REST, MQTT, AMQP) transport for queueing. There are some message brokers out there that supports Open Protocols and supporting that as a transport in NServiceBus will open lots of integration doors.
Do you have any useful information that will help me build such a transport?
Regards
Sumeet
Hi Sumeet
Ok, get it. We looked into for example into a generic AMQP transport pretty early. AMQP, as it stands now, is a client/server protocol and has no finalized specification yet for creating or managing entities. This means for now it is not possible to create a generic transport that only uses the AMQP protocol. Because for every transport you have to create a topology in the broker that represents the relationship of topics to queues. Once you need to create the topology you are forced to use the proprietary protocol and thus are is some tie into a specific broker middleware. In addition to that, you cannot change the topology anymore during runtime, if you had to the subscriber would need to use the proprietary protocol again to change the topology.
So if you look at an AMQP transport, for example, it could only do basic queue receives, and everything else needs to use the concrete SDKs provided by the broker middleware of choice. This seems to pretty much diminish the whole purpose of the generic transport in my viewpoint.
So we tend to look at it from an integration viewpoint. For a given system we would encourage to use a technology of choice (for example RabbitMQ with the AMPQ 1.0 plugin) to build your system upon and if third parties need to send messages to RabbitMQ those third parties can use a native AMQP client to send in payloads, but the topologies is something that you manage yourself.
Does that make sense?
Regards
Daniel